4motion ver.3.0m1 troubleshooting guide 110803

4Motion

Troubleshooting GuideSoftware Version: 3.0M1August 2011P/N: 215889

Document History

Document History

Changed Item Description Date

This is this document’s first publication Rel.3.0M1, August, 2011

4Motion Troubleshooting Guide ii

Legal Rights

Legal Rights© Copyright 2011 Alvarion Ltd. All rights reserved.

The material contained herein is proprietary, privileged, and confidential and owned by Alvarion or its third party licensors. No disclosure thereof shall be made to third parties without the express written permission of Alvarion Ltd.

Alvarion Ltd. reserves the right to alter the equipment specifications and descriptions in this publication without prior notice. No part of this publication shall be deemed to be part of any contract or warranty unless specifically incorporated by reference into such contract or warranty.

Trade Names

Alvarion®, BreezeCOM®, WALKair®, WALKnet®, BreezeNET®, BreezeACCESS®, BreezeLINK®,

BreezeMAX®, BreezeLITE®, BreezePHONE®, 4Motion®, and/or other products and/or services referenced here in are either registered trademarks, trademarks or service marks of Alvarion Ltd.

All other names are or may be the trademarks of their respective owners.

“WiMAX Forum” is a registered trademark of the WiMAX Forum. “WiMAX,” the WiMAX Forum logo, “WiMAX Forum Certified, ”and the WiMAX Forum Certified logo are trademarks of the WiMAX Forum.

Statement of Conditions

The information contained in this manual is subject to change without notice. Alvarion Ltd. shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance, or use of this manual or equipment supplied with it.

Warranties and Disclaimers

All Alvarion Ltd. ("Alvarion") products purchased from Alvarion or through any of Alvarion's authorized resellers are subject to the following warranty and product liability terms and conditions.

Exclusive Warranty

(a) Alvarion warrants that the Product hardware it supplies and the tangible media on which any software is installed, under normal use and conditions, will be free from significant defects in materials and workmanship for a period of fourteen (14) months from the date of shipment of a given Product to Purchaser (the "Warranty Period"). Alvarion will, at its sole option and as Purchaser's sole remedy, repair or replace any defective Product in accordance with Alvarion' standard R&R procedure.

(b) With respect to the Firmware, Alvarion warrants the correct functionality according to the attached documentation, for a period of fourteen (14) month from invoice date (the "Warranty Period")". During the Warranty Period, Alvarion may release to its Customers firmware updates, which include additional performance improvements and/or bug fixes, upon availability (the "Warranty"). Bug fixes, temporary patches and/or workarounds may be supplied as Firmware updates.

Additional hardware, if required, to install or use Firmware updates must be purchased by the Customer. Alvarion will be obligated to support solely the two (2) most recent Software major releases.

ALVARION SHALL NOT BE LIABLE UNDER THIS WARRANTY IF ITS TESTING AND EXAMINATION DISCLOSE THAT THE ALLEGED DEFECT IN THE PRODUCT DOES NOT EXIST OR WAS CAUSED BY PURCHASER'S OR ANY THIRD PERSON'S MISUSE, NEGLIGENCE, IMPROPER INSTALLATION OR IMPROPER TESTING, UNAUTHORIZED ATTEMPTS TO REPAIR, OR ANY OTHER CAUSE BEYOND THE RANGE OF THE INTENDED USE, OR BY ACCIDENT, FIRE, LIGHTNING OR OTHER HAZARD.

4Motion Troubleshooting Guide iii

Legal Rights

Disclaimer

(a) The Software is sold on an "AS IS" basis. Alvarion, its affiliates or its licensors MAKE NO WARRANTIES, WHATSOEVER, WHETHER EXPRESS OR IMPLIED, WITH RESPECT TO THE SOFTWARE AND THE ACCOMPANYING DOCUMENTATION. ALVARION SPECIFICALLY DISCLAIMS ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT WITH RESPECT TO THE SOFTWARE. UNITS OF PRODUCT (INCLUDING ALL THE SOFTWARE) DELIVERED TO PURCHASER HEREUNDER ARE NOT FAULT-TOLERANT AND ARE NOT DESIGNED, MANUFACTURED OR INTENDED FOR USE OR RESALE IN APPLICATIONS WHERE THE FAILURE, MALFUNCTION OR INACCURACY OF PRODUCTS CARRIES A RISK OF DEATH OR BODILY INJURY OR SEVERE PHYSICAL OR ENVIRONMENTAL DAMAGE ("HIGH RISK ACTIVITIES"). HIGH RISK ACTIVITIES MAY INCLUDE, BUT ARE NOT LIMITED TO, USE AS PART OF ON-LINE CONTROL SYSTEMS IN HAZARDOUS ENVIRONMENTS REQUIRING FAIL-SAFE PERFORMANCE, SUCH AS IN THE OPERATION OF NUCLEAR FACILITIES, AIRCRAFT NAVIGATION OR COMMUNICATION SYSTEMS, AIR TRAFFIC CONTROL, LIFE SUPPORT MACHINES, WEAPONS SYSTEMS OR OTHER APPLICATIONS REPRESENTING A SIMILAR DEGREE OF POTENTIAL HAZARD. ALVARION SPECIFICALLY DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY OF FITNESS FOR HIGH RISK ACTIVITIES.

(b) PURCHASER'S SOLE REMEDY FOR BREACH OF THE EXPRESS WARRANTIES ABOVE SHALL BE REPLACEMENT OR REFUND OF THE PURCHASE PRICE AS SPECIFIED ABOVE, AT ALVARION'S OPTION. TO THE FULLEST EXTENT ALLOWED BY LAW, THE WARRANTIES AND REMEDIES SET FORTH IN THIS AGREEMENT ARE EXCLUSIVE AND IN LIEU OF ALL OTHER WARRANTIES OR CONDITIONS, EXPRESS OR IMPLIED, EITHER IN FACT OR BY OPERATION OF LAW, STATUTORY OR OTHERWISE, INCLUDING BUT NOT LIMITED TO WARRANTIES, TERMS OR CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, SATISFACTORY QUALITY, CORRESPONDENCE WITH DESCRIPTION, NON-INFRINGEMENT, AND ACCURACY OF INFORMATION GENERATED. ALL OF WHICH ARE EXPRESSLY DISCLAIMED. ALVARION' WARRANTIES HEREIN RUN ONLY TO PURCHASER, AND ARE NOT EXTENDED TO ANY THIRD PARTIES. ALVARION NEITHER ASSUMES NOR AUTHORIZES ANY OTHER PERSON TO ASSUME FOR IT ANY OTHER LIABILITY IN CONNECTION WITH THE SALE, INSTALLATION, MAINTENANCE OR USE OF ITS PRODUCTS.

Limitation of Liability

(a) ALVARION SHALL NOT BE LIABLE TO THE PURCHASER OR TO ANY THIRD PARTY, FOR ANY LOSS OF PROFITS, LOSS OF USE, INTERRUPTION OF BUSINESS OR FOR ANY INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE OR CONSEQUENTIAL DAMAGES OF ANY KIND, WHETHER ARISING UNDER BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), STRICT LIABILITY OR OTHERWISE AND WHETHER BASED ON THIS AGREEMENT OR OTHERWISE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

(b) TO THE EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL THE LIABILITY FOR DAMAGES HEREUNDER OF ALVARION OR ITS EMPLOYEES OR AGENTS EXCEED THE PURCHASE PRICE PAID FOR THE PRODUCT BY PURCHASER, NOR SHALL THE AGGREGATE LIABILITY FOR DAMAGES TO ALL PARTIES REGARDING ANY PRODUCT EXCEED THE PURCHASE PRICE PAID FOR THAT PRODUCT BY THAT PARTY (EXCEPT IN THE CASE OF A BREACH OF A PARTY'S CONFIDENTIALITY OBLIGATIONS).

Disposal of Electronic and Electrical Waste

Disposal of Electronic and Electrical Waste

Pursuant to the WEEE EU Directive electronic and electrical waste must not be disposed of with unsorted waste. Please contact your local recycling authority for disposal of this product.

4Motion Troubleshooting Guide iv

Important Notice

Important NoticeThis user manual is delivered subject to the following conditions and restrictions:

This manual contains proprietary information belonging to Alvarion Ltd. Such information is supplied

solely for the purpose of assisting properly authorized users of the respective Alvarion products.

No part of its contents may be used for any other purpose, disclosed to any person or firm or

reproduced by any means, electronic and mechanical, without the express prior written permission of

Alvarion Ltd.

The text and graphics are for the purpose of illustration and reference only. The specifications on

which they are based are subject to change without notice.

The software described in this document is furnished under a license. The software may be used or

copied only in accordance with the terms of that license.

Information in this document is subject to change without notice. Corporate and individual names

and data used in examples herein are fictitious unless otherwise noted.

Alvarion Ltd. reserves the right to alter the equipment specifications and descriptions in this

publication without prior notice. No part of this publication shall be deemed to be part of any

contract or warranty unless specifically incorporated by reference into such contract or warranty.

The information contained herein is merely descriptive in nature, and does not constitute an offer for

the sale of the product described herein.

Any changes or modifications of equipment, including opening of the equipment not expressly

approved by Alvarion Ltd. will void equipment warranty and any repair thereafter shall be charged for.

It could also void the user's authority to operate the equipment.

4Motion Troubleshooting Guide v

Contents

Contents

Chapter 1 - Introduction........................................................................................ 1

1.1 Troubleshooting Process ......................................................................................2

1.1.1 The General Troubleshooting Process .................................................................2

1.1.2 Problem Scenario.................................................................................................2

1.1.3 Problem Level ......................................................................................................2

1.1.4 Problem Cause Category......................................................................................3

1.1.5 Stage in Life-Cycle ...............................................................................................3

1.1.6 Troubleshooting Tools.........................................................................................3

1.2 General Guidelines and Prerequisites....................................................................5

1.2.1 Approved Elements/Versions...............................................................................5

1.2.2 Configuration Change..........................................................................................5

1.2.3 New/Modified Neighboring Site...........................................................................5

Chapter 2 - No Network Entry Problems................................................................. 6

2.1 No Network Entry - Entire Network Level..............................................................7

2.1.1 Problem Indicators...............................................................................................7

2.1.2 Possible Problem Source .....................................................................................7

2.2 No Network Entry - Area/Market Level ..................................................................8

2.3 No Network Entry - Site Level...............................................................................9

2.3.1 Possible Problem Sources....................................................................................9

2.3.2 Hardware/Installation Problems ..........................................................................9

2.3.3 Interference Problems.......................................................................................16

2.4 No Network Entry - Sector Level.........................................................................18

2.4.1 Hardware/Installation Problems ........................................................................18

2.4.2 IF/RF Chain Hardware/Installation Problems......................................................19

2.4.3 Interference Problems.......................................................................................23

2.5 No Network Entry - CPE Level .............................................................................24

2.5.1 During Initial Commissioning (installation) ........................................................24

2.5.2 During On-Going Operation...............................................................................24

4Motion Troubleshooting Guide vii

Contents

Chapter 3 - Cut-Offs/ Deregistration Problems..................................................... 26

3.1 Cut-Offs/Deregistration - Entire Network Level...................................................27

3.1.1 Problem Indicators.............................................................................................27

3.1.2 Possible Problem Source ...................................................................................27

3.2 Cut-Offs/Deregistration - Area/Market Level .......................................................28

3.3 Cut-Offs/Deregistration - Site Level....................................................................29

3.3.1 Possible Problem Sources..................................................................................29

3.4 Cut-Offs/Deregistration - Sector Level ................................................................31


3.5 Cut-Offs/Deregistration - CPE Level ....................................................................33

Chapter 4 - Low/Degraded Throughput Problems.................................................. 34

4.1 Low/Degraded Throughput - Entire Network Level...............................................35



4.2 Low/Degraded Throughput - Area/Market Level...................................................36

4.3 Low/Degraded Throughput - Site Level................................................................37


4.3.2 Throughput Problems in the Downlink ..............................................................37

4.3.3 Throughput Problems in the Downlink ..............................................................37

4.4 Low/Degraded Throughput - Sector Level............................................................39

4.5 Low/Degraded Throughput - CPE Level ................................................................40

Chapter 5 - Miscellaneous Problems .................................................................... 41

5.1 Handover Problems ............................................................................................42



5.2 Idle Mode Problems............................................................................................43

5.3 Services Related Problems..................................................................................44

5.3.1 Ethernet CS (VPWS) Service Problem.................................................................44

5.3.2 IP CS Service Problems.......................................................................................44

5.4 QoS Related Problems........................................................................................45

5.4.1 Problem in Services Using High QoS ..................................................................45

4Motion Troubleshooting Guide viii

Contents

5.4.2 Problems in Services Using Low QoS .................................................................45

Appendix A - Interference Test ........................................................................... 46

A.1 Purpose and Overview........................................................................................47

A.2 Test Procedure...................................................................................................48

A.2.1 Required Equipment ..........................................................................................48

A.2.2 Test Setups........................................................................................................48

A.2.3 Testing Process .................................................................................................48

4Motion Troubleshooting Guide ix

Chapter 1 - IntroductionThis document is a high-level guide to help you troubleshoot the 4Motion System.

In This Chapter:

“Troubleshooting Process” on page 2

“General Guidelines and Prerequisites” on page 5

Chapter 1 - Introduction Troubleshooting Process

1.1 Troubleshooting Process

1.1.1 The General Troubleshooting Process

The general troubleshooting process comprises the following steps:

1 Identify the problem scenario (see Section 1.1.2).

2 Identify the problem level (see Section 1.1.3).

3 According to problem scenario and problem level, and using relevant troubleshooting tools (see

Section 1.1.6), identify the possible problem cause (see Section 1.1.4). Note that in some cases

possible cause and identification process may vary according to the stage in life-cycle of the relevant

entity (see Section 1.1.5).

4 Take the necessary corrective action and verify that the problem is fully resolved.

1.1.2 Problem Scenario

The common scenarios indicating the existence of a problem are:

No Network Entry: All CPEs in the relevant level cannot complete network entry. Refer to “No

Network Entry Problems” on page 6.

Cutoffs/de-registration of CPEs: All or a large number of CPEs in the relevant level are subject to

repeated de-registration/registration activity. Refer to “Cut-Offs/ Deregistration Problems” on

page 26

Low/Degraded/No throughput: The throughput in the relevant level is null or has been significantly

degraded or is significantly below the expected throughput according to the Radio Network Planning.

Refer to “Low/Degraded Throughput Problems” on page 34.

Other Problems:

» “Handover Problems” on page 42

» “Idle Mode Problems” on page 43

» “Services Related Problems” on page 44

» “QoS Related Problems” on page 45

1.1.3 Problem Level

The possible problem levels are:

Entire network: The problem exists in the entire managed network

Area/market: The problem exists in a specific group of sites.

Site (BTS): The problem exists in all sectors of the BTS.

4Motion Troubleshooting Guide 2


Sector: The problem exists in a specific sector.

CPEs group: The problem exists in a specific group of CPEs.

A single CPE: The problem exists in a single CPE.

1.1.4 Problem Cause Category

The possible problem causes can belong to the following categories:

Installation problem: Problems related to cables and connections such as wrong connections,

improperly prepared or damaged cables, improper connections including loose connections or

environmental damage due to improper sealing of outdoor connections.

Hardware failure: A malfunctioning component.

Configuration/implementation mistakes: A configuration mistake that affects the operation of the

relevant or other element(s). Note that a configuration mistake in one element can affect proper

operation of other elements (for example, a wrong configuration of a sector can cause strong

interference in neighboring sectors).

Interferences: Either external interference (caused by a device that is not part of the operator’s

network) or internal interference (caused by other elements of the network).

Radio Network Planning (RNP): Errors in the Radio Network Planning, related to either the network

components associated with the problem or neighboring network components.

1.1.5 Stage in Life-Cycle

In some cases, the probable cause and troubleshooting process may vary according to the stage in the

life-cycle of the relevant entity:

Initial commissioning: A problem detected during commissioning (acceptance tests) of a new entity

that has never been fully operational

On-going operation: A problem that occurred after a period in which the relevant entity operated

properly.

1.1.6 Troubleshooting Tools

According to the specific problem scenario and problem level, the following can be used to support the

troubleshooting process:

AlvariSTAR real time counters/alarms/status indications

StarQuality*

StarACS

Sniffers (Wireshark WiMAX.dll) R6/R3

Logs



Connectivity tests (e.g. Ping)

LED indications

Spectrum analyzer

Where applicable, it is assumed that relevant tools are available and that the person responsible for

troubleshooting has the necessary know-how.

* It is highly recommended to define in StarQuality the following reports:

1 Failed NE per ASN (distributed topology or Alvarion’s Mini-Centralized ASN-GW)

2 Failed NE per BS

3 Authentication Rejects per ASN (distributed topology or Alvarion’s Mini-Centralized ASN-GW)

4 Uplink Median Noise per BS

These reports will support fast identification of problematic sites/BSs.

To further improve ability for fast notification of possible problems, define in StarQuality relevant alarms

for events such as when the number of Dropped CPEs per BS exceeds a certain threshold.


Chapter 1 - Introduction General Guidelines and Prerequisites

1.2 General Guidelines and Prerequisites

1.2.1 Approved Elements/Versions

To eliminate possible problems due to inter-operability issues or incorrect software versions, verify that:

1 All relevant third party elements such as AAA server, ASN-GW and CPEs have passed inter-operability

(IOT) tests and are approved by Alvarion. Verify also that they use an approved software version

(taking into account, if applicable, the software version used by the NPU/AUs).

2 All NPUs and AUs use the last approved software version of the relevant release.

1.2.2 Configuration Change

As a general rule, if a problem is experienced following a configuration change, try reverting the

configuration to the previous one. Investigate the change that caused the problem and if necessary

contact Alvarion for analysis of the issue. This document does not cover problems resulting from

configuration changes in sites that operated properly prior to the change(s).

1.2.3 New/Modified Neighboring Site

In some cases, a problem in a site/sector may be experienced following activation of a new neighboring

site or following configuration changes in a neighboring site. The new/modified site may seem to

operate properly but its configuration may affect proper operation of its neighbor (in most cases due to

strong interference). In this case, check carefully the Radio Network Planning and its implementation in

the new site.


Chapter 2 - No Network Entry Problems

In This Chapter:

The No Network Entry problem exists when all CPEs in the relevant problem level

cannot properly complete the network entry process and are not getting any

service.

This Chapter describes the troubleshooting process for the No Network Entry

problem for the following problem levels:

“No Network Entry - Entire Network Level” on page 7

“No Network Entry - Area/Market Level” on page 8

“No Network Entry - Site Level” on page 9

“No Network Entry - Sector Level” on page 18

“No Network Entry - CPE Level” on page 24

Chapter 2 - No Network Entry Problems No Network Entry - Entire Network Level

2.1 No Network Entry - Entire Network Level

2.1.1 Problem Indicators

At the Entire Network level, a No Network Entry problem will be indicated by a flood of customer’s

complaints. Depending on problem source, it may also be indicated by specific alarms in AlvariSTAR and

StarQuality.

2.1.2 Possible Problem Source

No Network Entry problem in the Entire Network indicates a problem in one of the core components of

the Connectivity Service Network, such as AAA server(s), ASN-GW(s), relevant networking devices, or

connections between any of these components and the network.

Specific problem source identification process for this problem depends on specific implementation of

the Connectivity Service Network and is beyond the scope of this document. However, the following

4Motion alarms may be useful in identifying the possible problem source:

A No NE problem will be indicated also by Management > Initial NE real-time counters in AlvariSTAR and

Failed Initial NE in StarQuality (ASNGW>MS Registration graphs).

Table 2-1: General AN-GW/AAA Related Alarms

Alarm Possible Problem

BS ASNGW Keep Alive Failure If generated in all BSs, may indicate a failure in the ASN-GW (centralized topology) or in the communication path with the ASN-GW.

ASNGW AAA Unreachable If generated in all BTSs (distributed topology) or Mini Centralized ASN-GWs, may indicate a failure in the AAA server(s) or in the communication path with the AAA server(s)


Chapter 2 - No Network Entry Problems No Network Entry - Area/Market Level

2.2 No Network Entry - Area/Market Level

The possible sources for a No Network Entry problem at the Area/Market level are very similar to those

for the Entire Network level (see Section 2.1). It indicates a problem in one of the core components of

the Connectivity Service Network associated with the specific area/market such as AAA server(s),

ASN-GW(s), relevant networking devices or connections between any of these components and the

network.


Chapter 2 - No Network Entry Problems No Network Entry - Site Level

2.3 No Network Entry - Site Level

2.3.1 Possible Problem Sources

A No Network Entry problem in the entire BTS can be caused by any of the following:

Hardware/Installation problem

» A problem in the power supply to the BTS that caused a failure of the NPU. This includes

problems in the following components:

◊ The power source or power connection to the BTS

◊ PIU (if there is no redundant PIU)

◊ PSU (if there is no redundant PSU)

» A failure in the AVU that caused shut-down of the BTS

» A malfunctioning NPU

» A problem in the GPS or connecting cable (without synchronization for a certain time, ODUs will

not transmit)

» Wrong connections of all ODUs

» A problem in the connection to the ASN-GW and/or AAA server

Interference problem: A strong interference that affects the entire site.

Configuration problem: A wrong implementation of the RNP. Applicable only for a new site (or a new

neighboring site).

If the site operated properly in the past, wrong RNP problems are not relevant.

2.3.2 Hardware/Installation Problems

2.3.2.1 Power Supply/PIU Card Problems

The BTS can function properly with one PIU card. To support PIU redundancy two PIU cards should be

installed.

If PIU card(s) operate properly, the LEDs indications are as follows:

If one PIU is installed, PWR = green, MASTER = green, Hot Swap LED = off.

If two PIU modules are installed, PWR of both PIUs should be green. The MASTER LED of one PIU should

be green, and the other one should be off. Hot Swap LEDs of both PIUs should be off.

Otherwise, refer to the following table:



Relevant PIU alarm is:

In addition, verify that the power source can supply the required current (including power to all ODUs).

2.3.2.2 PSU Card Problems

The minimum number of required PSU cards (without PSU redundancy) is:

Table 2-2: PIU Card Problems

Problem and Indication Possible Cause Corrective Action

No Power to the card

PWR LED is off

Master LED is off

1 Chassis is not connected to the power.

2 Power Cable is not properly connected or is faulty.

3 Power Supply is not properly tuned or is faulty.

4 PIU card is not properly connected or is damaged.

1 Verify that the power cable is properly connected.

2 Verify that external power supply output DC power is in the permitted range (-48 VDC).

3 Verify proper output power on the power cable connector.

4 Replace the PIU card.

PWR LED is Red

Master LED is off (chassis is powered by redundant PIU) or green (chassis is powered by PIU)

1 Power input is out of range.

2 power cable is not properly connected or is faulty.

3 PIU card is not properly connected or is damaged.

4 Chassis is damaged.

1 Verify that external power supply output DC power is in the permitted range (-48 VDC).

2 Verify that the power cable is properly connected.

3 Verify proper output power on the power cable connector.

4 Disconnect the power cable, eject and re-insert the card and reconnect the power cable.

5 Move the PIU module to another PIU slot.

6 Replace the PIU card.

7 Replace the Chassis.

Table 2-3: PIU Alarms

Alarm Problem Description

PIU Power Problem The PIU is faulty, or the -48VDC input power to the PIU is outside the permitted range.



If a PSU card operates properly, the LEDs indications are: PWR = green, ALRM = off.


Relevant PSU alarms are:

2.3.2.3 AVU Module Problems

If the AVU module operates properly, the LEDs indications are: PWR = green, ALRM = off.


Table 2-4: PSU Requirements (excluding PSU redundancy)

Number of AUs Minimum Required Number of PSUs

1 - 4 2

5 - 6 3

Table 2-5: PSU Card Problems

Problem and Indication

Possible Cause Corrective Action

No Power to all cards (PIU's LEDs are OK)

PWR LED is OFF

ALRM LED is OFF

1 PSU card is not properly connected or is damaged.

2 Chassis is faulty.

1 Move the PSU module to another PSU slot (preferably at the other side of the chassis).

2 Replace the PSU.

3 Replace the Chassis.

PWR LED is OFF

ALRM LED is Red

1 Power input is out of range.

2 PSU is damaged.

3 PSU is inhibited by NPU.

1 Verify that external power supply output DC power is in the permitted range.

2 Replace the PSU.

Table 2-6: PSU Alarms


PSU Faulty No Backup The PSU is malfunctioning and does not have a backup module, which may cause the system to shut down.

PSU Unit Missing No Backup The PSU is configured but not installed in the appropriate slot. In addition, there is no backup PSU module available for the missing PSU module, and this condition may impact the functioning of the cell site.

PSU Unit Over Temp No Backup

The PSU is providing degraded output power because it is overheated. In addition, no backup exists for this PSU, and this condition may impact the functioning of the cell site.



Relevant AVU alarms:

2.3.2.4 NPU Card Problems

If the NPU card operates properly, the LEDs indications are:

PWR=green, ALRM=off, MASTER=green, Hot Swap LED=off.

In addition:

GPS/SYNC should be green when the GPS operates properly and the NPU clock is synchronized.

BST ALRM should be off when there is no failure detected in other cards.

EXT ALRM should be off when no external alarm is detected.

Integrity LED of the DATA/MGMT port (if applicable) should be green indicating proper Ethernet link.

Activity LED of these ports (if applicable) should be blinking yellow when there is Ethernet activity.

Table 2-7: AVU Module Problems



PWR LED is OFF

ALRM is OFF

No 5V power input to the module.

1 Eject and re-insert the module.

2 Replace the AVU.

3 Replace the chassis.

PWR LED is Red

ALRM is Red

No 12V power input to the fans.

1 Eject and re-insert the module.

2 Replace the AVU.

3 Replace the chassis.

PWR LED is Green

ALRM is Red

Failure of at least one fan. Replace the AVU.

Table 2-8: AVU Alarms


AVU Unit Missing The AVU module is not properly installed in the chassis. (The PIU may shut down after this alarm is raised.)

AVU Total Failure A fault has occurred in the internal AVU circuitry (the system is automatically shut down after this alarm is raised).

AVU Any Fan Failure An AVU fan has failed.



Relevant NPU alarms:

2.3.2.5 GPS Problems

When the GPS operate properly:

GPS/SYNC LED of the NPU is green

In the GPS screen: Software Versions are available, Number of Satellites is 4 or higher.

Table 2-9: NPU Card Problems



PWR LED is OFF

(PIU(s) and PSUs are OK)

NPU is not powered. 1 Eject and re-insert the card in the same slot (No.5).

2 Move the NPU module to slot No.6. If OK, replace the chassis.

3 If not, replace the NPU card.

PWR LED is Red

(PIU(s) and PSUs are OK, Hot Swap LED is off)

NPU power failure. 1 Eject and re-insert the card in the same slot (No.5).

2 Move the NPU module to slot No.6. If OK, replace the chassis.

3 If not, replace the NPU card.

PWR LED is Red

Hot Swap LED is Blue

The card is not properly locked or is faulty.

1 Eject and re-insert the card. Secure the handles until you hear the locking click. Secure the module in place by closing the screw at the top of the front panel.

2 Replace the NPU card.

Table 2-10: NPU Alarms


NPU Temp High Threshold Exceed

The NPU temperature is very high. The system is automatically shut down after this alarm is raised.

NPU Internal Clock Failure The NPU clock that provides the internal 16 MHz signal has failed.

NPU 12 Volt Failure The NPU module is unable to provide 12 Volts to the appropriate devices.

INFORMATION4 satellites may not be sufficient for initial synchronization. If the Number of Satellites is constantly 4 for more than 40 minutes and synchronization is not achieved, disconnect/reconnect the GPS cable. If the problem persists, it may indicate an NPU card failure.



In a new site, before starting the following troubleshooting process, verify in the GPS screen that the

correct GPS Type is defined and External 1 PPS Clock is enabled.

Relevant GPS or NPU alarms are:

Table 2-11: GPS Problems



GPS/SYNC LED of the NPU is off

Software Versions are not available in the GPS screen

GPS receiver failure

GPS receiver is not properly connected

Faulty NPU card

1 Disconnect and reconnect GPS cable.

2 Replace the NPU.

3 Replace the GPS cable.

4 Replace the GPS.

GPS/SYNC LED of the NPU is off

Software Versions are available in the GPS screen

Number of Satellites indicated in GPS screen is lower than 4

(note that initial synchronization may take up to 40 minutes)

Number of received satellites is too low

1 Verify that there are no obstacles interfering with the reception of GPS satellites.

2 Try to improve the reception by changing the location of the GPS receiver.

Table 2-12: NPU Alarms


NPU Ext One PPS Input Failure The NPU has lost synchronization with the external 1PPS signal.

NPU External Clock Failure The NPU has lost synchronization with the GPS and is unable to receive the external 16 MHz signal.

NPU Interference Clk Holdover Timer Expired

The timer that determines the maximum period for which the NPU should provide holdover has expired. This alarm is raised after the NPU entered holdover mode indicated by the NPU Clock Holdover Mode alarm.

NPU Tx St Down Clk Holdover Timer Expired

The NPU has stopped data transmission after the timer that determines the maximum period for which the NPU should provide holdover expires. This alarm is raised after the NPU Interference Clk Holdover Timer Expired alarm is raised.



2.3.2.6 ODUs Definitions/Connections Problems

In a new site, there may be a problem in definitions or connections of all ODUs, resulting in No Network

Entry problem in the entire site.

Verify that all ODUs are detected (Installed ODU Type and Serial Number are available in ODU screens). If

no ODU is detected as installed, although they are physically installed and connected:

1 Check proper configuration of all Sector Associations.

2 Check proper configuration of Required ODU Type in all ODUs.

3 Check proper configuration of Central Frequency in all BSs.

4 Check correct connections of all IF cables (no crossed connections). Verify that all IF cables are

properly prepared and undamaged.

2.3.2.7 Connectivity to AAA Server/ASN-GW Problems

1 Check the Integrity (green) LED of the DATA port. If off, there is a problem in the Ethernet connection.

Check the connection to the networking device, check the networking device.

Table 2-13: GPS Alarms


GPS Communication Failure

A failure has occurred in the communication between the GPS receiver and the NPU.

GPS Rcv Less Satellites The GPS is synchronized to less than the minimum number of satellites (4).

GPS Lock Not Achieved In a Macro BTS - either the external 1PPS or the number of received satellites are not OK for 60 sec in initialization state.

In a Micro BTS - either the external 1PPS or the number of received satellites are not OK for 7 minutes in initialization state.

GPS UnHealthy GPS problem



2 In a new site: Check proper configuration of all parameters related to connectivity and (in Distributed

Topology) Service Profiles’ Status:

» Default Authenticator in all BSs

» IP parameters of the Bearer Interface in all BSs

» IP parameters of the ASN-GW Bearer Interface (Distributed Topology)

» IP Routes related to the ASN-GW/AAA server.

» VLAN Mapping of the External Management and Bearer Interfaces.

» Verify that all Service Profiles are enabled (Distributed Topology).

3 Use the Telnet Ping command to check connectivity with the AAA server and (if applicable) ASN-GW.

4 Check R6 signalling messages (using WireShark via CSCD port):

» If fails in SBC (pre-attachment) stage, there is a problem in communication with the ASN-GW.

Check the ASN-GW configuration.

» If fails during Authentication stage, there may be a problem in communication with either AAA

server or ASN-GW. It may also be due to configuration mistakes in CPEs:

◊ Verify proper configuration of the ASN-GW (e.g. Shared Secret, missing attributes, etc.)

◊ Check the configuration of AAA server.

◊ Check the User Name and Password configuration in CPEs.

» If you do not see any R6 signalling, there may be a configuration problem in all BSs. Check proper

configuration of Cell Radius, Central Frequency, and Bandwidth parameters.

2.3.3 Interference Problems

A No Network Entry problem in the entire site may be the result of a very strong interference that affects

all sector. The existence of interference in all sectors will be indicated by a BS High UL Median Noise

alarm in all BSs. The source of the interference can be:

Internal Interference generated by a neighbor sector:

» Check that none of the neighbor BTSs is operating without a GPS (GPS Type configured as None).

» Check that there is no neighbor BTS with a GPS related problem.

» Verify the correct implementation of the Radio Network Plan (in the site and its neighbors).

» Verify that there is no error in the Radio Network Plan.

External Interference generated by an external source that is not a part of the network: Use a

Spectrum Analyzer to identify such interference. Refer to Appendix A for test guidelines.



INFORMATION

The BS High UL Median Noise alarm will also be generated if ODUs are not connected.


Chapter 2 - No Network Entry Problems No Network Entry - Sector Level

2.4 No Network Entry - Sector Level

A No Network Entry problem in a single sector can be caused by any of the following:


» A malfunctioning AU

» A malfunctioning ODU

» A problem in AU-ODU IF connections

Interference problem.


neighboring site).

If the sector operated properly in the past, wrong RNP problems are not relevant.

2.4.1 Hardware/Installation Problems

2.4.1.1 AU Card Problems

If the AU card operates properly, the LEDs indications are:

PWR=green, ALRM=off, MASTER=green, WACT=green, WLNK=green when at least one CPE is

registered, IP blinking green when there is IP activity, ODU PWR of connected ODU ports=green, ODU

ALRM of connected ODU ports=off, Hot Swap LED=off.

Table 2-14: AU Card Problems



PWR LED is OFF

(PIU and PSUs are OK, sufficient PSU cards are installed)

AU hardware problem

Problem in the chassis

1 Eject and re-insert the card.

2 Move the AU module to a spare AU slot. If OK, the problem is in the chassis.

3 Replace the AU card.

PWR LED is Red

(PIU and PSUs are OK, sufficient PSU cards are installed)

AU hardware problem. 1 Replace the AU card.

PWR LED is Green

ALRM is Red

AU hardware problem 1 Eject and re-insert the card.




2.4.2 IF/RF Chain Hardware/Installation Problems

Various problems in the AU-ODU-Antenna chain may be indicated by one or more alarms. In general,

the target is to start by trying to identify the problem from the location of the AU(s) because typically

access to the ODU/Antenna is more difficult.

Before executing the following troubleshooting activities, verify the proper configuration of all relevant

elements (AUs, ODUs, Antennas) and sector associations.

ODU AU Comm Lost Alarm or ODU HW Failure Alarm with Communication with AU Lost reason.

ODU ALRM LED = Red.

PWR LED is Red

Hot Swap LED is Blue

The card is not properly locked.

AU hardware problem

1 Eject and re-insert the card. Secure the handles until you hear the locking click. Secure the module in place by closing the screw at the top of the front panel.


WACT LED is OFF

PWR LED is Green

(No CPE is connected)

AU hardware problem

ODU is not connected properly

ODU malfunctioning

1 Eject and re-insert the card.

2 Refer to “IF/RF Chain Hardware/Installation Problems” on page 19.

ODU PWR LED is OFF

(AU PWR is Green)

No AU to ODU power output (ODU's PWR LED is OFF)

Replace the AU card.

ODU PWR LED is Red

(AU PWR is Green)

AU to ODU power output failed.

Replace the AU card.

ODU PWR LED is Green

ODU ALRM LED is Red

Communication problem with the ODU.

AU Initialization Failure

1 Eject and re-insert the card

2 Refer to “IF/RF Chain Hardware/Installation Problems” on page 19.

Table 2-14: AU Card Problems





ODU HW Failure Alarm with reason other than communication lost (No ODU AU Comm Lost Alarm,

ODU ALRM LED = red)

ODU High VSWR Detection Alarm

May cause various problems: No Network Entry, Reduced Throughput, Cut-Offs, Handover Failures.

Table 2-15: IF/RF Chain Problems: ODU-AU Communication Lost


Faulty AU

Faulty AU-ODU IF cable or cable is not connected properly

Faulty ODU

1 Disconnect/reconnect the IF cable(s) on the AU side.

2 Disconnect the cable(s) from the AU and reconnect to either other port(s) of the same AU or to port(s) of another AU that are known to operate properly. If no alarm is sent, the problem is in the AU or in the chassis. Check the problematic AU in another slot (reconfigure the relevant sector association). If the problem disappears, the failure is in the chassis. If the problem persists, replace the AU.If the alarm still exists after connecting the cables to other AU/ports, the problem is either in the IF cable(s) or in the ODU.

3 Disconnect/reconnect the IF cable(s) on the ODU side.

4 Disconnect the cable(s) from the ODU and reconnect them to another ODU that is known to operate properly. If the alarm is generated by the “new” ODU, the problem is caused by faulty IF cable(s). Replace the IF cable(s).

5 Replace the ODU.

Table 2-16: IF/RF Chain Problems: ODU HW Failure


Faulty ODU 1 Disconnect/reconnect the IF cables.

2 Shut down/enable the AU channels.

3 Replace the ODU.



BS RSSI Indication Failure Alarm

May cause various problems: Reduced Throughput, Cut-Offs, Handover Failures.

Table 2-17: IF/RF Chain Problems: ODU High VSWR Detection


Faulty ODU

Faulty ODU-Antenna RF cable or cable is not connected properly

Faulty Antenna

1 Disconnect/reconnect the RF cable(s) of the Tx ports on the ODU side.

2 Disconnect the RF cable(s) from the ODU and reconnect to the port(s) of another ODU that is known to operate properly. If no alarm, the problem is in the ODU. Replace the ODU. If the alarm persists, the problem is either in the RF cable(s) or in the Antenna. Alternatively, disconnect the RF cables of the Tx ports and connect 20 dB attenuators. If the problem persists, replace the ODU. Otherwise, the problem is in the RF cables or Antenna.

3 Disconnect/reconnect the RF cable(s) of the Tx ports on the Antenna side.

4 Disconnect the cable(s) from the Antenna and reconnect them to another Antenna that is known to operate properly. If the alarm is generated by the “new” Antenna, the problem is caused by faulty RF cable(s). Replace the RF cable(s).

5 Replace the Antenna.



2.4.2.1 Configuration Problems

In a new site:

1 Check the proper configuration of all parameters related to relevant BS connectivity:

» Default Authenticator

» IP parameters of Bearer Interface

» VLAN Mapping of Bearer Interface.

Table 2-18: IF/RF Chain Problems: BS RSSI Indication Failure


Faulty AU

Faulty AU-ODU IF cable or cable is not connected properly

Faulty ODU

Faulty ODU-Antenna RF cable or cable is not connected properly

Faulty Antenna

1 Disconnect/reconnect the IF cable(s) on the AU side.

2 Shut down/enable the channels (reset).

3 Disconnect the cable(s) from the AU and reconnect them to the port(s) of another AU that is known to operate properly. If no alarm is sent, the problem is in the AU or in the chassis. Check the problematic AU in another slot (reconfigure the relevant sector association). If the problem disappears, the failure is in the chassis. If the problem persists, replace the AU.

4 Disconnect/reconnect the IF cable(s) on the ODU(s) side.

5 If the relevant BS is associated with a single ODU, disconnect the cables from the ODU and reconnect them to another ODU that is known to operate properly. If the alarm is generated by the “new” ODU, the problem is caused by one or more faulty IF cables. Replace the IF cable(s). If two or four ODUs are associated, execute the process for each ODU.

6 Disconnect/reconnect the RF cable(s) on the ODU(s) side.

7 If the relevant BS is associated with a single ODU, disconnect the cable(s) from the ODU and reconnect them to ports of another ODU that is known to operate properly. If no alarm is sent, the problem is in the ODU. Replace the ODU.

8 Disconnect/reconnect the RF cables on the Antenna(s) side.

9 If the relevant BS is associated with a single Antenna, disconnect the cables from the Antenna and reconnect them to another Antenna that is known to operate properly. If the alarm is generated by the “new” Antenna, the problem is caused by faulty RF cable(s). Replace the RF cables. If two or four Antennas are associated, execute the process for each Antenna.

10 If the relevant BS is associated with a single Antenna, replace the Antenna. If two or more antennas are associated, disconnect the cable(s) from one antenna and reconnect them to another Antenna that is known to operate properly in order to identify the faulty antenna.



2 Use the Telnet Ping command to check the connectivity with the ASN-GW (if applicable).

3 Check R6 signalling messages (using WireShark via CSCD port):

» If fails in SBC (pre-attachment) stage, there is a problem in communication with ASN-GW. Check

the ASN-GW configuration.

» If fails during Authentication stage, there may either be a problem in communication with the

ASN-GW or configuration mistakes in the CPEs:

◊ Verify the proper configuration of the ASN-GW (e.g. Shared Secret, missing attributes, etc.)

◊ Check the User Name and Password configuration in the CPEs

If you do not see any R6 signalling, there may be a configuration problem related to the BS radio

parameters. Check the proper configuration of Cell Radius, Central Frequency, and Bandwidth

parameters.

2.4.3 Interference Problems

A No Network Entry problem may be the result of a very strong interference. The existence of

interference in the sector will be indicated by a BS High UL Median Noise alarm. The source of the

interference may be:


» Check that none of the neighbor BTSs is operating without a GPS (GPS Type configured as None).

» Check that there is no neighbor BTS with a GPS related problem.

» Verify the correct implementation of the Radio Network Plan (in the sector and its neighbors).




INFORMATION

The BS High UL Median Noise alarm will also be generated if ODUs are not connected.


Chapter 2 - No Network Entry Problems No Network Entry - CPE Level

2.5 No Network Entry - CPE Level

2.5.1 During Initial Commissioning (installation)

If a CPE (or several CPEs) cannot successfully complete Network Entry, check the following:

1 Verify correct Firmware version.

2 Use the GUI to check if the CPE receives a signal from the BS. If not, check the correct configuration

of the radio parameter (frequency, BW, scanning, etc.).

3 If BS is received but the signal level is too low (check expected quality according to RNP), try to

improve by changing the location/direction of antenna. If the signal quality is good, check that the

distance from the BS is within the range of the Cell Radius configured in the BS (you can check in

CPE’s logs/status if the CPE completed the ranging phase successfully).

4 A high RSSI with a CINR that is too low indicates a possible local interference. Try to improve the

conditions by changing the location/direction of the antenna. If this does not help, check the RNP, try

identifying the source of interference using a spectrum analyzer (refer to Appendix A for test

guidelines).

5 Check that there is no Authentication problem related to mismatch of definitions between the CPE

and the AAA server (Authentication Mode, User Name, Password).

6 Check relevant R6 signalling messages (using WireShark via CSCD port of NPU). If Authentication

completed successfully but Network Entry is not completed, check if there are any configuration

problems in the AAA/ASN-GW:

» The profile that should be used by the CPE

» Filter ID mismatch between AAA ASN-GW

» In Explicit Mode - R3-IF-Descriptor in AAA

2.5.2 During On-Going Operation

If a CPE that operated properly in the past cannot complete Network Entry:

1 Check the CPE’s indicators. If they indicate a hardware problem, replace the CPE.

2 If you cannot access the CPE’s GUI, replace the CPE.

3 If you cannot receive a BS, check the location/direction of the antenna, if applicable, check the

connecting cable. Verify that there are no obstacles in the line-of-sight to the BS. If the configuration

was not changed, replace the CPE.

4 If the received signal quality is good, check for changes in the BS configuration or in the CPE’s

SW/configuration.


Chapter 2 - No Network Entry Problems No Network Entry - CPE Level

5 A high RSSI with a CINR that is too low indicates a possible local interference. Try to improve the

conditions by changing the location/direction of the antenna. If this does not help, check the RNP, try

identifying the source of the interference using a spectrum analyzer (refer to Appendix A for test

guidelines).


Chapter 3 - Cut-Offs/ Deregistration Problems

In This Chapter:

The Cut-Off/Deregistration exists when all or many CPEs in the relevant problem

level register/deregister repeatedly.

This Chapter describes the troubleshooting process for the Cut-Offs/Deregistration

problem for the following problem levels:

“Cut-Offs/Deregistration - Entire Network Level” on page 27

“Cut-Offs/Deregistration - Area/Market Level” on page 28

“Cut-Offs/Deregistration - Site Level” on page 29

“Cut-Offs/Deregistration - Sector Level” on page 31

“Cut-Offs/Deregistration - CPE Level” on page 33

Chapter 3 - Cut-Offs/ Deregistration Problems Cut-Offs/Deregistration - Entire Network Level

3.1 Cut-Offs/Deregistration - Entire Network Level


At the Entire Network level, a Cut-Offs/Deregistration problem will be indicated by a flood of customer’s

complaints. Depending on problem source, it may also be indicated by specific counters in AlvariSTAR

and certain graphs in StarQuality.


Cut-Offs/Deregistration problems in the Entire Network indicate a problem in one of the core

components of the Connectivity Service Network (CSN), such as AAA server(s), ASN-GW(s), relevant

networking devices, or connections between any of these components and the network:

AAA server configuration problem, AAA connectivity problem (e.g. a too high delay), or a

configuration mismatch between the local ASN-GW (distributed topology) and the AAA server.

ASN-GW configuration or connectivity problem (will be indicated by ASNGW Keep Alive Failure

alarms from all NPUs).

DHCP server configuration problem (if applicable), or a problem in another device in the CSN.

The specific problem source identification process for this problem depends on specific implementation

of the Connectivity Service Network and is beyond the scope of this document. However, the following

tools may be useful in identifying the possible problem source:

Real Time AAA counters in AlvariSTAR

Registered MSs Qty in StarQuality (ASNGW > MS Registration graphs)

Failed Initial NE in StarQuality (ASNGW > MS Registration graphs): If increases significantly and the

increase occurs together with an increase in Authentication Rejections, it indicates a problem either in

the AAA configuration or in th connectivity with the AAA server.

Use a sniffer to check R3/R6 signalling to identify the exact problem by identifying the entity that

initiated the deregistration and the exact stage of the deregistration message.

Cut-Offs/Deregistration problem in the Entire Network may also be due to wrong RNP creating

interference in the entire network (particularly with reuse 1 deployments).


Chapter 3 - Cut-Offs/ Deregistration Problems Cut-Offs/Deregistration - Area/Market Level

3.2 Cut-Offs/Deregistration - Area/Market Level

The possible sources of a Cut-Off/Deregistration problem at the Area/Market level are very similar to

those for the Entire Network level (see Section 3.1). It indicates a problem in one of the core

components of the Connectivity Service Network associated with the specific area/market, such as AAA

server(s), ASN-GW(s), relevant networking devices, or the connections between any of these

components and the network (see also th previous section - Cut-Offs/Deregistration - Entire Network

Level).

Cut-Offs/Deregistration problem in the area/market may also be due to wrong RNP creating interference

in the entire area (particularly with reuse 1 deployments).

Depending on area size, Cut-Offs/Deregistration problem in the Area/Market may also be due to a very

strong local interference (internal or external). The existence of interference in all BTSs will be indicated

by a BS High UL Median Noise alarm in all BSs. Check also the UL Median Noise graph for relevant BSs in

StarQuality. The source of the interference may be:


» Check that none of the BTSs in the area is operating without a GPS (GPS Type configured as

None).

» Check that there is no BTS with a GPS related problem.






Chapter 3 - Cut-Offs/ Deregistration Problems Cut-Offs/Deregistration - Site Level

3.3 Cut-Offs/Deregistration - Site Level


A Cut-Offs/Deregistration problem in the entire BTS can be caused by any of the following:


» A problem in the power supply to the BTS that affects the proper operation of the BTS.

» A problem in the NPU.

» A problem in the connection to the ASN-GW.

Interference problem: A strong interference that affects the entire site (applicable primarily in reuse 1

deployments).


neighboring site).

If the site operated properly in the past, wrong RNP problems are not relevant.

In general, to identify a potential problem source, filter the alarms in AlvariSTAR to view alarms of the

specific site and check correlation between cut-offs (significant drops in Number of Connected SUs as

displayed by the relevant StarQuality graph) for the relevant site and different AlvariSTAR alarms or

changes in other StarQuality graphs.

3.3.1.1 Hardware/Installation Problems

3.3.1.1.1 Power Supply Related ProblemsCut-offs of all CPEs served by the BTS may occur due to:

A marginal power supply: The DC voltage of the external power supply is not in the correct range. A

higher DC voltage is required.

Number of PSUs is too small.

A failure in the PIU or PSU. Check the correlation between occurrences of cut-offs and PIU/PSU

alarms.

3.3.1.1.2 NPU Related ProblemsA malfunctioning NPU can also cause cut-offs of all CPEs served by the BTS. Check NPU alarms,

especially NPU Temp Low Threshold Exceed alarm (if High Threshold is exceeded, the system will shut

down). NPU CPU Soft Limit Exceed, NPU CPU Hard Limit Exceed, NPU Reset Int Reason, and AU Reset Int

Reason (in all AUs) alarms will also cause cut-offs: If these occur, contact Alvarion.

3.3.1.1.3 Connectivity ProblemA problem related to connectivity with the ASN-GW will be indicated by BS ASNGW Keep Alive Failure

alarms correlated with drops in Registered MSs Qty in StarQuality (ASN-GW > MS Registration or Active


Chapter 3 - Cut-Offs/ Deregistration Problems Cut-Offs/Deregistration - Site Level

MSs per BS in relevant BSs graphs) will be indicated also by Real Time AAA counters in AlvariSTAR

(distributed topology).

Use a sniffer to check R3/R6 signalling to identify the exact problem by identifying the entity that

initiated the deregistration and the exact stage of the deregistration message.

3.3.1.2 Interference Problems

A Cut-Off/Deregistration problem in site level may also be due to a strong local interference (internal or

external) that affects the entire site. This is applicable primarily for reuse 1 deployments.

The existence of interference in the entire site will be indicated by a BS High UL Median Noise alarm in all

BSs. Check also the UL Median Noise graph for relevant BSs in StarQuality.

The source of the interference may be:



None).


» Verify correct implementation of the Radio Network Plan (in the site and its neighbors).


External Interference - generated by an external source that is not a part of the network: Use a



Chapter 3 - Cut-Offs/ Deregistration Problems Cut-Offs/Deregistration - Sector Level

3.4 Cut-Offs/Deregistration - Sector Level


A Cut-Off/Deregistration problem in the sector can be caused by any of the following:

Hardware/Installation problem: A problem in the AU-ODU-Antenna chain

Interference problem.

Configuration problem:

» A wrong implementation of the RNP. Applicable only for a new site (or a new neighboring site).

» Verify that neighbors lists in all relevant sites are symmetrical (run the Mutual Neighbors task in

AlvariSTAR and correct the configuration if necessary).

If the site operated properly in the past, wrong RNP problems are not relevant. For a new site, check the

StarQuality graph for Downlink SINR Distribution. If the radio conditions are too poor compared to what

is expected according to the RNP (over 20% with SINR of 4 dB or lower) for all or many CPEs, there is an

RNP implementation problem.

In general, to identify a potential problem source, filter the alarms in AlvariSTAR to view alarms of the

specific sector and check the correlation between cut-offs (significant drops in Number of Connected

SUs as displayed by the relevant StarQuality graph) for the relevant sector and different AlvariSTAR

alarms, or changes in other StarQuality graphs.

If necessary, use a sniffer to check R3/R6 signalling to help identifying the exact problem by identifying

the entity that initiated the deregistration and the exact stage of the deregistration message.

3.4.1.1 Hardware/Installation Problems

In general, to identify the potential source of HW problems, check the correlation between cut-offs

(significant drops in Number of Connected SUs as displayed by the relevant StarQuality graph) and

different alarms or changes in other StarQuality graphs.

Check especially power related alarms, GPS related alarms, AU and ODU alarms.

See also ODU High VSWR Detection alarm and BS RSSI Indication Failure alarm in “IF/RF Chain

Hardware/Installation Problems” on page 19.

3.4.1.2 Interference Problems

A Cut-Off/Deregistration problem in sector level may also be due to a local interference (internal or

external).

In AlvariSTAR, the existence of interference will be indicated by a BS High UL Median Noise alarm.

In StarQuality: Interference problems will be indicated by increased values in Burst Error Rate Ratio

Uplink/Downlink graphs. For sectors using Beam Forming, check the Number of Connected SUs against


Chapter 3 - Cut-Offs/ Deregistration Problems Cut-Offs/Deregistration - Sector Level

the BS Traffic graph. If there is a correlation between drops in the number of connected SUs and the

changes in traffic type from BF (Beam Forming) to CDD, then most probably there is an interference

problem.

To verify the existence of interference, check the correlation of cut-offs with increased noise levels in UL

Median Noise graph.

The source of the interference may be:



None).




External Interference generated by an external source that is not part of the network: Use a Spectrum

Analyzer to identify such interference. Refer to Appendix A for test guidelines.


Chapter 3 - Cut-Offs/ Deregistration Problems Cut-Offs/Deregistration - CPE Level

3.5 Cut-Offs/Deregistration - CPE Level

A Cut-Offs/Deregistration problem in the CPE level can be caused by any of the following:

The CPE’s temperature is too high (HW problem).

Poor radio conditions: poor radio conditions are indicated by very low DL CINR and DL MCS. If the

MS’s average CINR is close to 1 and DL MCS is QPSK 1/2 Repetition 2 or lower, the radio conditions

are poor. Check the results against the RNP. You may try improving the conditions by changing

location/direction of the antenna.

Local interference (most likely due to internal interference): A high RSSI with a CNR that is too low

indicates a possible local interference.

Try to improve the conditions by changing the location/direction of the antenna. If this does not help, check the RNP; try identifying the source of the interference using a spectrum analyzer (refer to Appendix A for test guidelines).

If none of the above applies:

1 Try identifying the problem source by using an R6 sniffer (with a filter on specific MAC).

2 Check logs in the CPEs (if applicable).

INFORMATION Rule of thumb: DL RSSI+DL SNR ~ 100.

If DL SNR is above 20 dB the rule is not applicable.

If DL SNR is below 20 dB, then 100-(DL RSSI+DL SNR) ~ Interference level


Chapter 4 - Low/Degraded Throughput Problems

In This Chapter:

A Low/Degraded Throughput problem exists when the throughput is null or

significantly below its expected/previous level.

This Chapter describes the troubleshooting process for the Low/Degraded

Throughput problem for the following problem levels:

“Low/Degraded Throughput - Entire Network Level” on page 35

“Low/Degraded Throughput - Area/Market Level” on page 36

“Low/Degraded Throughput - Site Level” on page 37

“Low/Degraded Throughput - Sector Level” on page 39

“Low/Degraded Throughput - CPE Level” on page 40

Chapter 4 - Low/Degraded Throughput Problems Low/Degraded Throughput - Entire Network Level

4.1 Low/Degraded Throughput - Entire Network Level


At the Entire Network level, a Low/Degraded Throughput problem will be indicated by a flood of

customer’s complaints. Depending on problem source, it may also be indicated by specific counters in

AlvariSTAR and certain graphs in StarQuality.


A Low/Degraded Throughput problem in the Entire Network indicates a problem in one of the core

components of the Connectivity Service Network (CSN), such as relevant networking devices or

connections between any of these components and the network.

The specific problem source identification process for this problem depends on specific implementation

of the Connectivity Service Network and is beyond the scope of this document.


Chapter 4 - Low/Degraded Throughput Problems Low/Degraded Throughput - Area/Market Level

4.2 Low/Degraded Throughput - Area/Market Level

The possible sources for a Low/Degraded Throughput problem at the Area/Market level are very similar

to those for the Entire Network level. It indicates a problem in one of the relevant networking devices or

connections between any of these components and the network (see also previous section -

Low/Degraded Throughput - Entire Network Level).

A Low/Degraded Throughput problem in the area/market may also be due to wrong RNP creating

interference in the entire area (particularly with reuse 1 deployments).

Depending on area size, a Low/Degraded Throughput problem in the Area/Market may also be due to a

very strong local interference (internal or external). The existence of interference in all BTSs will be

indicated by a BS High UL Median Noise alarm in all BSs. Check also theUL Median Noise graph for

relevant BSs in StarQuality. The source of the interference may be:



None).







Chapter 4 - Low/Degraded Throughput Problems Low/Degraded Throughput - Site Level

4.3 Low/Degraded Throughput - Site Level


A Low/Degraded Throughput problem in the entire BTS can be caused by any of the following:

Interference problem: A strong interference that affects the entire site (applicable primarily in reuse 1

deployments).

Changes in demand (oversubscription): A significant growth in the number of CPEs with poor air-link

conditions.

4.3.2 Throughput Problems in the Downlink

Check Real-Time R6 downlink traffic counters in AlvariSTAR vs. R1 downlink traffic statistics. If R6 traffic

is very low (or null) in all BSs, check the relevant networking device and its connections. Other

throughput problems in the downlink will be indicated by a total R1 traffic that is lower than the total R6

traffic.

In StarQuality, check the DL HARQ Retransmissions and Airlink Utilization graphs. If in the Airlink

Utilization graph the frame is fully occupied, the problem is most probably due to oversubscription. An

increase in the number of CPEs is also indicated in relevant StarQuality graphs.

An increase in HARQ retransmissions indicates a possible problem due to either oversubscription or

interference.

The source of an interference may be:



None).




External Interference generated by an external source that is not a part of the network: Use a Spectrum

Analyzer to identify such interference. Refer to Appendix A for test guidelines.

4.3.3 Throughput Problems in the Downlink

Check Real-Time R6 uplink traffic counters in AlvariSTAR. A throughput problem in the downlink will

cause R6 uplink traffic that is lower than expected.

In StarQuality, check the UL HARQ Retransmissions and UL MCS Distribution graphs. An increase in

HARQ retransmission or decreased MCS indicate a possible problem due to either oversubscription or


Chapter 4 - Low/Degraded Throughput Problems Low/Degraded Throughput - Site Level

interference. The existence of interference in the entire site will be indicated by a BS High UL Median

Noise alarm in all BSs. Check also the UL Median Noise graph for relevant BSs in StarQuality.


Chapter 4 - Low/Degraded Throughput Problems Low/Degraded Throughput - Sector Level

4.4 Low/Degraded Throughput - Sector Level

The possible source and indicators for Low/Degraded Throughput problems in the Sector level are

practically the same as described for the Site level. See Low/Degraded Throughput - Site Level.


Chapter 4 - Low/Degraded Throughput Problems Low/Degraded Throughput - CPE Level

4.5 Low/Degraded Throughput - CPE Level

A Low/Degraded Throughput problem in the CPE level can be caused by any of the following:

The CPE’s temperature is too high (HW problem).

Poor radio conditions: poor radio conditions are indicated by very low DL CINR and DL MCS. If the

MS’s average CINR is close to 1 and the DL MCS is QPSK 1/2 Repetition 2 or lower, radio conditions

are poor. Check the results against the RNP. You may try improving the conditions by changing the

location/direction of the antenna.

Local interference: A high RSSI with a CNR that is too low indicates a possible local interference.

Try to improve the conditions by changing the location/direction of the antenna. If this does not help, check the RNP; try identifying the source of interference using a spectrum analyzer (refer to Appendix A for test guidelines).

If none of the above applies:

1 Try identifying the problem source by using R6 sniffer (with a filter on specific MAC).

2 Check the logs in the CPEs (if applicable).


If the DL SNR is above 20 dB, the rule is not applicable.

If the DL SNR is below 20 dB, then 100-(DL RSSI+DL SNR) ~ Interference level


Chapter 5 - Miscellaneous Problems

In This Chapter:

“Handover Problems” on page 42

“Idle Mode Problems” on page 43

Chapter 5 - Miscellaneous Problems Handover Problems

5.1 Handover Problems


A handover problem will be indicated by a sudden increase in the number of Failed HO Attempts in

StarQuality’s MS Handover graph for the affected BS.


Possible sources for HO problems are:

Configuration problems:

» Incomplete neighbors definitions: Run the Mutual Neighboring task to check consistency of

neighboring BSs definition across the entire managed network. If necessary, use the task to fix all

neighboring definitions.

» Verify identical and proper definitions for all Scan and Handover Triggers in the entire relevant

area.

» Verify that the same Operator ID is configured in all relevant BSs.

DHCP related problems: Handover problems will occur if an MS tries moving to a neighbor BS before

being assigned an IP address. According to the problem level (entire network/market/site/MS), verify

proper configuration of DHCP server and connections to it.


Chapter 5 - Miscellaneous Problems Idle Mode Problems

5.2 Idle Mode Problems

Idle Mode problems exist when there are configuration errors related to the Idle Mode feature. If Idle

Mode is enabled (Paging Group ID is not 0), the Paging Group ID of each BS must be unique in the

network. Idle Mode should be either enabled in all units in the network (Paging Group ID other than 0)

or disabled in all units (Paging Group ID = 0). A combination in the same network of units with Paging

Group ID of 0 (Idle Mode disabled) and units with Paging Group ID other than 0 (Idle Mode enabled)

must be avoided.

If the same Paging Group ID is configured in two (or more) neighboring BSs, an MS that moves between

these BSs will not be able to receive services from the new BS and it will be deregistered. This will cause

repeated deregistrations of certain MSs in relevant sectors (indicated by Registered MSs Qty graph in

StarQuality.

Verify that unique Paging Group IDs are configured in all BSs.


Chapter 5 - Miscellaneous Problems Services Related Problems

5.3 Services Related Problems

5.3.1 Ethernet CS (VPWS) Service Problem

Problem description: Service is disconnected because a re-authentication request was rejected by the

AAA server.

Reason: Accounting for VLAN CS services is not supported by the standard. Certain AAA servers support

the non-standard accounting implemented by Alvarion. If the AAA server does not support Alvarion’s

solution, it will reject the accounting packets and re-authentication requests will be rejected.

Solution: A by-pass solution is to add an IP CS Management Service Flow to enable accounting. This

solution does not provide proper accounting, but it enables re-authentication of the MS:

1 In each relevant BTS, add all the components required for an IP CS management service flow (Service

Interface, Service Group).

2 In the AAA server, add to relevant profiles the suitable IP CS service flow.

Verify that the Service Group’s VLAN ID does not conflict with any VLAN ID used by either host interfaces

or other Service Groups defined in the BTS. Verify that the Service Group Name is unique in the

managed network (note that the name is case sensitive).

5.3.2 IP CS Service Problems

Problems related to IP CS services are typically caused by configuration mistakes. If there are problems

associated with a specific profile:

1 Verify the proper configuration of relevant Service Interface and Service Group (according to the

applicable DHCP mode).

2 For Service Group operating in Server/Proxy DHCP mode, the default Vendor Class Identifier is

dslforum.org. Alvarion’s CPEs support this value. Other CPEs may not support it. If the defined Vendor

Class Identifier is not supported by the CPE, the CPE will not be allocated IP parameters. In this case,

either define the correct value or configure it to null (empty string), meaning that the definition in the

CPE will be ignored.

3 For Service Groups associated with a VLAN Service Interface, verify that in the Service Group VLAN is

enabled.

4 Verify that the Service Profile is enabled.

5 In Distributed ASN-GW configurations, Service Flow IDs must be unique in the ASN-GW.

6 QoS configuration should be in accordance with recommended values.


Chapter 5 - Miscellaneous Problems QoS Related Problems

5.4 QoS Related Problems

5.4.1 Problem in Services Using High QoS

Problem: Packet of high QoS service flows are transferred in service flows with lower QoS.

Reason: mismatching configuration of the classifier.

Solution: Use a LAN Analyzer to check that the content of the packet matches the definition of the

relevant classifier in the ASN-GW (in the downlink check source of packets arriving from the backbone,

in the uplink check the source in or behind the CPE).

5.4.2 Problems in Services Using Low QoS

Problem: Reduced bandwidth is allocated for services with low QoS.

Reason: Starvation of available air-link resources: CPE(s) with very poor MCS (indicated by changes in UL

MCS Distribution graph) or oversubscription (unexpected increase in demand, indicated by increase in

the number of Registered MSs and increase of Throughput).


Appendix A - Interference Test

In This Appendix:

“Purpose and Overview” on page 47

“Test Procedure” on page 48

Appendix A - Interference Test Purpose and Overview

A.1 Purpose and Overview

The non-harmful interference test enables measuring and detecting interfering signals to the WiMAX

system (within band) without turning off the system.

The assumption is that an interfering signal is not correlated to the WiMAX signal and that both signals

(WiMAX and interference) are not synchronized.

This method is applicable where a dense interference is assumed due to low SNR vs. good RSSI or other

indications (such as high UL median noise measurement in StarQuality). It is less applicable to sporadic

interferences where the time gap between two occurrences of interference is very high (hours/days).

If an interfering signal was not observed during the test, it may indicate that the interference signal is

correlated to the WiMAX signal and probably it is an internal interference due to either mistakes in RNP

or wrong implementation of the RNP.

If you cannot explain results of this test, send all results to Alvarion Customer Services.

NOTE! All end-user devices such as cellular phone and other devices using wireless communication should not transmit during the test period. Otherwise, the transmission can be interpreted as an external interference.


Appendix A - Interference Test Test Procedure

A.2 Test Procedure

A.2.1 Required Equipment

Spectrum analyzer - covering the relevant frequency range

Low Noise Amplifier (LNA) with a known gain, if not included in the spectrum analyzer

Band pass filter with known loss and filter shape

Antennas with known gains (Omni, directional, Horn)

Drive test tool

A.2.2 Test Setups

Test Setup 1 (without filter):

Test Setup 2 (with filter):

A.2.3 Testing Process

A.2.3.1 Test Stages

The test is divided into several stages:

1 Search of the location of the suspected interference.

Figure A-1: Test Setup 1

Figure A-2: Test Setup 2



2 Monitor the location with a reference CPE and by the drive test tool for correlation (with and without

the external filter)

3 Measure wide band Frequency mapping

4 Measure adjacent and in band frequency mapping

5 Measure Time domain signals for interference.

A.2.3.2 Location Search

The interference tests should be done in a location that represents the typical phenomena that the

end-user is experiencing. The location is selected according to the pre-gathered data from the field

indicating the area where there is a high probability of interference.

The exact location search within the area is done by monitoring the CPE radio parameters (RSSI, SNR, Tx

power, etc.) operating under normal conditions and searching for a location where the CPE parameters

indicate that there is a problem that is similar to the problem experienced by the end-user.

The location can be either indoor or outdoor depending on the nature of the phenomenon and the

limitation in the field. For external interference an outdoor test environment is preferred.

There could be several locations selected for cross-correlation between the results and detecting the

source of the interference.

A.2.3.3 Area Monitoring

Once a decision is taken on the locations, a monitoring process should be performed in order to

understand the conditions that the CPE is facing. The monitoring is performed by applying the drive test

tool to view the base stations that are covering the location and the levels of received signal from each

relevant base station.

The data should be correlated with the data taken from the CPE’s downlink RSSI and SNR

measurements.

Connect the filter to the CPE antenna port and on the drive test tool and check for improvement of

performance: Improved performance may indicate an out of band interference.

By the end of the location search and area monitoring there should be a clear picture of the environment

that the CPE is facing.


If the DL SNR is above 20 dB, the rule is not applicable.

If the DL SNR is below 20 dB, then 100-(DL RSSI+DL SNR) ~ Interference level



A.2.3.4 Wide Band Frequency Mapping

This test is used to check the out of band environment of the system. The test searches for out of band

signals that may interfere with the WiMAX signals due to harmonics or high power adjacent signals.

Test Procedure:

1 Connect the setup according to setup #1

2 Set the spectrum for full span

3 Set the spectrum to max hold

4 Take a screen capture.

A.2.3.5 Adjacent and In-Band Frequency Mapping

This test is used to check the in-band and adjacent channels environment of the system. The test

searches for adjacent out of band signals or in band signals that may interfere with the WiMAX signals.

Test Procedure:

1 Connect the setup according to setup #1

2 Set the spectrum covering the relevant channel and adjacent and alternate channels (Operational

Span=7xBW)

3 Set the spectrum to max hold

4 Capture the picture.

If the WiMAX spectrum does not look as expected it may indicate an interfering signal that is above the

WiMAX signal. Low power interfering signals will not be detected by this test.

A.2.3.6 Time Domain Testing

This test is used to check the existence of external interfering signals. The basic principle is that an

external interfering signal is neither correlated nor synchronized with the WiMAX signal. Setting the

spectrum to time domain enables to differentiate the TX and RX time intervals of the BS. Uncorrelated

interference will appear in the RX time as non-correlated bursts.

Test Procedure:

1 Connect the setup according to setup #1 or #2.

2 Set the spectrum to the WiMAX center frequency.

INFORMATION

The reference CPE should be turned off during the test.



3 Set the spectrum to zero span.

4 Set the RBW to the maximum value.

5 Set the VBW to 100 KHz (or near value that enables to see clearly the WiMAX signal).

6 Set to trigger mode and set the Video threshold level for stabilizing the image.

7 Set to maximum hold and check for interfering signals.

8 Repeat the process to cover the entire WiMAX signal BW (i.e 5MHz, 10MHz etc.) by setting the

spectrum analyzer center frequency in RBW steps (Example RBW=3MHz WiMax C.F=2490, Spectrum

analyzer Freq 2487MHz, 2490MHz, 2493MHz).

A.2.3.7 Example

In the example above we do not see any external non-correlated interference.

Figure A-3: Example 1


4motion ver.3.0m1 troubleshooting guide 110803

Documents