RedMAX Admin and Maintenance Guide

RedMAX AN100U/AN100UX
Administration and Maintenance Guide

December 2009
Version: 2.1.0
Part Number: 70-00133-01-01
Disclaimer:
The statements, configurations, technical data, and recommendations in this document are believed to be accurate and reliable;
however, they are presented without express or implied warranty. Additionally, Redline makes no representations or warranties,
either expressed or implied, regarding the contents of this document.
Redline Communications Inc. shall not be liable for any misuse regarding this product.
The information in this document is subject to change without notice.
Safety Notice:
Operators should read the Users Manual and Installation Guide for the RedMAX wireless products described in this manual to
understand and follow all operating and safety instructions. Keep all product information for future reference.
Confidential and Proprietary Information:
This document constitutes confidential and proprietary information of Redline Communications Inc.. The contents of this document
may be accessed and/or used solely by a licensee of Redline Communications Inc. software product(s) and solely in connection with
the licensees authorized use of such product(s), or as otherwise expressly permitted by Redline Communications Inc. in writing. All
other uses are prohibited. This document may not in any event be disclosed to any third party without the prior written
authorization of Redline Communications Inc.
Trademark Information:
Redline Management Suite, Redline, RMS, RedACCESS, RedCONNEX and RedMAX are trademarks of Redline
Communications Inc. All other brands and product names identified in this publication are trademarks or registered trademarks of
their respective companies or organizations.
Copyright 2009, Redline Communications Inc.
All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means, electronic or
mechanical, including photocopying, recording, or information storage and retrieval systems for any purpose without the express
written permission of Redline Communications Inc.
Contact Information
Head Office: Redline Communications Inc.
302 Town Centre Blvd.
Markham, ON
Canada L3R 0E8
Web Site: http://www.redlinecommunications.com
Sales Inquiries:
North America:
Toll Free Line:
International:
nainfo@redlinecommunications.com
1-866-633-6669
Intlinfo@redlinecommunications.com
Support:
Web Site:
Email:
Telephone:
www.redlinecommunications.com/support/support_portal.html
support@redlinecommunications.com
Contact your local Redline Distributor
Table of Contents
1
Redline Communications Inc. Confidential and Proprietary
CHAPTER 1 About This Guide
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
About This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Other Documents in the Redline Product Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Supported Redline Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
CHAPTER 2 Overview
Maintenance Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Required Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Establishing a Spares Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Reference Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Monitoring Your System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
Connecting to the Sector Controller Web Client . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
Connecting to the Sector Controller Command Line Interface . . . . . . . . . . . . . . . 2-5
Connecting to the Subscriber Unit Command Line Interface . . . . . . . . . . . . . . . . . 2-6
Monitoring System Event Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
Monitoring Statistical Results Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
Monitoring the System Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Using the Ping Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
Using the Iperf Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
Network Sniffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
Using the rfMonitor Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
Planning/Scheduling Equipment Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
Personnel Required for Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
Establishing and Recording the Baseline Configuration . . . . . . . . . . . . . . . . . . . 2-15
Maintenance Record Keeping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
Establishing Secure, Remote Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
2
VPN Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
Remote Management of an SUO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18
Configuring a DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18
Configuring a Time of Day Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
CHAPTER 3 Indoor Equipment Maintenance
Performing a Visual Inspection of the IDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
Rebooting the Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Rebooting the AN100U/UX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Rebooting the Subscriber Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Redundant Power Supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
RPS Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
Uplink Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
Sector Controller Synchronization with the GPS Clock . . . . . . . . . . . . . . . . . . . . . . . . 3-5
Local Synchronization versus GPS Synchronization . . . . . . . . . . . . . . . . . . . . . . . 3-6
Verifying Network Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
Changing from Local to GPS Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
AN100U/UX Operation in GPS Holdover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
Working with Service Classes, Service Flows and Classifiers . . . . . . . . . . . . . . . . . . 3-13
Checking RF and PHY Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14
CHAPTER 4 Outdoor Equipment Maintenance
Radio Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
Replacing a Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
Antenna Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Antenna Positioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Replacing the Antenna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
Verifying Power and RF Signal Cabling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
Interface (IF) Cable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
RF Cable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Performing a Spectrum Sweep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
Sources of Potential Interference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
Inspect and Repair Lightning Protection System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
Ground Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
Components of Your Lightning Protection System . . . . . . . . . . . . . . . . . . . . . . . 4-11
Verifying Your Lightning Protection System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
Inspecting and Re-Applying Weatherproofing on Outdoor Connections . . . . . . . . . . 4-12
Testing to Validate Repair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
3
CHAPTER 5 AN100U/UX Troubleshooting
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
Troubleshooting RedMAX Boot Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
AN100U/UX Does Not Power-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
Subscriber Unit Does Not Power-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
AN100U/UX Occasionally Reboots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
AN100U/UX Fault LED is Blinking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
Inrush Current at Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
Troubleshooting Ethernet Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
Cross-over versus Straight-through Cables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
Cannot Establish a Connection to the Management Port . . . . . . . . . . . . . . . . . . . 5-9
Duplex Mismatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
Troubleshooting Device Management Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
Sector Controller Serial Communication Issues . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
Sector Controller IP Connectivity Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
Subscriber Unit IP Communication Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16
Troubleshooting Wireless Link Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18
Cannot Establish a Wireless Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18
LO1, LO2 and Radio Reference Frequency Errors . . . . . . . . . . . . . . . . . . . . . . . 5-21
Indoor Subscriber Unit (SUI) Connectivity Issues . . . . . . . . . . . . . . . . . . . . . . . . 5-24
Gauging Link Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24
Link Optimization and Reference RSSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-27
Subscriber Unit De-Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-28
RF Interference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-29
Viewing Noise Level Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-32
Performing a Site Spectrum Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-33
Troubleshooting Data Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-34
Troubleshooting Data Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-34
Example of Working with Service Flow Classifiers . . . . . . . . . . . . . . . . . . . . . . . 5-35
Troubleshooting the Data Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-39
Common Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-39
MAC Auto Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-40
Tracing Downlink Connectivity Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-41
Tracing Uplink Connectivity Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-42
Software Upgrade Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-43
High Latency on Secondary Management Channel (SMC) Latency . . . . . . . . . . 5-44
CHAPTER 6 Self-Install End User Troubleshooting
Troubleshooting Self-Install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
No Data Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
4
Redline Management Suite Administration and Maintenance Guide
Enabling the Secondary Management Channel . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
The Bridge Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
Low Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
CHAPTER 7 Disaster Recovery
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
Impact Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
Lightning Strike . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Wind Damage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Extreme Temperature Exposure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
APPENDI X A Event Log Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
Script - scan.pl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
Input Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3
Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3
Script errorReport.pl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-5
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-5
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-5
Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-5
Script checkTime.pl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-7
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-7
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-7
Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-7
Script checkDailyPerSector.pl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-8
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-8
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-8
Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-8
Script findNoisefloor.pl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-8
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-8
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9
Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9
5
APPENDI X B AN100U/UX Event Log Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1
Interference Messages at Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-19
Detecting Interference with Local or GPS Synchronization . . . . . . . . . . . . . . . . B-19
Noise Floor Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-20
APPENDI X C Subscriber Unit Event Log Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1
APPENDI X D Synchronization Event Log Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-1
I NDEX
6
1-1
1
About This Guide
Overview
Redlines RedMAX family of products, includes the AN100U sector controller, the
AN100UX Macro sector controller, the RedMAX SU-I indoor subscriber unit and RedMAX
SUO outdoor subscriber unit.
The RedMAX AN100U/UX facilitate the rapid provisioning of new fixed and nomadic
wireless broadband services, while their very low latency ensures reliable delivery of
time-sensitive services, including circuit-switched voice traffic, voice-over-IP (VoIP), video
and prioritized data traffic.
RedMAX sector controllers can be deployed in clusters of up to six sectors, supporting
hundreds of simultaneous subscribers per sector.
The hardware is fully upgradeable in the field by software download, to accommodate
future enhancements for scalability, extended packet classifiers, alternative encryption
standards, and the continued development of the 802.16 standard.
About This Document
Scope
This document provides detailed instructions for administering and maintaining the various
components of your AN100U/UX sector controller installation.
This document is intended for Redline-certified network maintenance personnel. It covers
basic maintenance procedures for AN100U/UX and its optional accessories.
Note Unless indicated otherwise the procedures throughout this guide require that you
are either logged into a Web or CLI client session and have the correct user account
privileges to access the network equipment, perform upgrades and other diagnostic
functions.
1-2
RedMAX Administration and Maintenance Guide
Working with RedMAX network elements requires a comprehensive understanding of data
networking. You should also have extensive experience with configuration and operation
of Redlines broadband, fixed, wireless access products as part of a WiMAX network or
backhaul infrastructure. Additional background knowledge should include data networking
theory.
You should be familiar with the device interface. A detailed description of both the Web and
command line interface are provided in the RedMAX AN100U/UX Base Station User
Guide.
Comprehensive operator and administrator training programs are available from Redline
Communications. Please contact support@redlinecommunications.com for detailed
information.
Document Conventions
The following document conventions are used throughout his guide.
In addition to the above formatting conventions a number of naming conventions are also
used to denote customer-specific information.
Table 1-1 Document Conventions
Format Description
Bold Commands, titles, and keywords that are displayed in the RMS or the OS graphical
user interface are shown in bold.
<Italic>
User Guide:
Arguments, for which you must supply a value are shown in italics with angle
brackets.
Other Redline documents are also denoted in italics.
Ellipsis
...
An ellipsis before or after example text, indicates that there is more content either
before or after the examples that are shown. The entire contents of the file are not
shown.
[ ] Elements in square brackets are optional.
{ x | y | z } Required alternative command options are grouped in braces and separated by
vertical bars.
[ x | y | z ] Optional command options are grouped in square brackets and separated by vertical
bars.
Navigation
Steps >
Successive navigational steps are indicated with an arrow. You will need to progress
through the navigational path using your mouse or keyboard shortcuts.
Ctrl+click Hold down the Ctrl key and click on line items, to select multiple items in tables or
drop-down menus.
1-3
Chapter 1 About This Guide
Other Documents in the Redline Product Suite
The following documentation is available for the Redline Management Suite.
Table 1-2 Document Conventions for Customer-Specific Information
Name Description
<host> This is the name or IP address of the host machine, connected to one or
more sector controllers, via the data port.
<password> This is the password for accessing the sector controller Web or CLI interface.
<version> This is the software or firmware version number.
Table 1-3 Redline Documentation Suite
Title Part Number
RedMAX Hardware
RedMAX Base Station AN100U/AN100UX Install Guide 70-00059-01-02
RedMAX Base Station AN100U/AN100UX User Manual 70-00058-01-01
RedMAX Base Station AN100U/AN100UX SUO Quick Test 70-00116-01-00
RedMAX AN100U/AN100UX Subscriber Outdoor Unit (SUO)
Quick Install Guide
70-00091-01-02
RedMAX AN100UX Release Notes 70-00091-01-00
RedMAX Subscriber Outdoor Unit (SUO) Quick Install Guide 70-00067-01-01
RedMAX Subscriber Outdoor Unit (SUO) Installation Guide 70-00068-01-02
RedMAX Subscriber Outdoor Unit (SUO) User Manual 70-00057-01-01
RedMAX Subscriber Indoor Unit (SUI) Quick Install Guide 70-00077-01-02
RedMAX Subscriber Indoor Unit (SUI) Installation Guide 70-00079-01-01
RedMAX Subscriber Indoor Unit (SUI) User Manual 70-00078-01-01
Redline Management Suite
Redline Management Suite Installation Guide 70-00065-01-11
Redline Management Suite User Guide 70-00066-01-12
Redline Management Suite Troubleshooting Guide 70-00084-01-01
Redline Management Suite Quick Reference 70-00097-01-02
Redline Management Suite Release Notes 70-00106-01-04
Redline Management Suite Online Help (printed version) 70-00119-01-01
Redline Management Suite Administration and Maintenance Guide 70-00124-01-01
Redline Management Suite Northbound Interface Functional Specification 70-00131-01-00
1-4
Supported Redline Equipment
Refer to the RedMAX AN100U/UX Release Notes for a list of supported equipment.
2-1
2
Overview
Effective preventive maintenance routines are essential to ensure the ongoing optimal
performance of your sector controllers and outdoor equipment following initial installation
and deployment. Effective remedial maintenance routines are also essential to ensure that
when a fault does occur, the base station is up and running as soon as possible in order
to minimize customer disruption and degradation of QoS.
The information and procedures in this manual are intended as a guideline. You will need
to define a maintenance plan that addresses the unique concerns of your specific network
installation.
Maintenance Schedule
You will need to monitor your equipment and make your decision about how frequently you
need to perform various maintenance tasks based on the number of components,
environmental conditions and the location of the your outdoor equipment.
The following table provides general guidelines for system maintenance. You will need to
modify this schedule based on your particular network installation and configuration.

Table 2-1 RedMAX Maintenance Schedule
Daily Maintenance Description/Required Tasks
Check Alarm Indicators Review the alarm indicators as outlined in the User's
manual.
Log all results and perform any corrective action.
Archive syslog messages Store syslog files to your network archive or backup sector
controller log files if you are not using a syslog server.
Weekly Maintenance
Run the syslog analysis scripts. Check for GPS, synchronization and IF issues,
characterize rates of de-registrations
Monthly Maintenance
Visually inspect all connections
2-2
Required Equipment
You should have the following items on site to perform both routine maintenance and
corrective maintenance.
RF AnalyzerA portable, good quality hand held spectrum analyzer is best suited to
this task. Anritsu Model MS2721A or Rohde & Schwarz model FSH6 are both suitable
devices. The spectrum analyzer should include a 12V power supply and ~25dB LNA
cable. Refer to the Guide to Field Spectral Analysis for details on the requirements and
use of a spectrum analyzer
iPerf Network Packet Sniffing software tooliPerf is a free, open source utility used
for testing TCP and UDP performance. It's available for download from:
http://dast.nlanr.net/Projects/Iperf/.
Torque wrench with gauge
Weatherproofing materials including:
Scotch 130C Linerless Rubber Splicing Tape
Scotch 2210 Vinyl Mastic RollsThese are self-fusing, rubber-based insulating
compounds laminated to a flexible, all-weather grade vinyl (PVC) backing. These
tape rolls are designed to insulate, moisture-seal connections up to 600 volts, and
have excellent resistance to abrasion, moisture, alkalies, acid, copper corrosion
and varying weather conditions (including sunlight).
Scotch Vinyl Electrical TapeSuper 88 is a premium grade, 8.5-mil thick,
all-weather vinyl insulating tape. It is designed to perform continuously in ambient
temperatures up to 105C (220F). The tape is conformable for cold weather
Check Spares Check the quantity, model number and version number of
spare parts. Ensure that the spare parts are stored in
accordance with the manufacturer's instructions with
regard to temperature, humidity and anti-static
requirements.
Backup Sector Controller
configuration
Backup the running configuration file to an FTP server.
Refer to the User guide for detailed information.
Log the date on which the backup was performed. Also
record the software version number. This will make it
easier to identify the required backup file when it is
required to restore the device's configuration.
Annual Maintenance
Inspect RF system Review wireless configuration and signal values.
Log all of your results and store it with your maintenance
records.
Reapply weather proofing on
outdoor connections.
Log all dates and replace components/seals. Log all of
your results and store it with your maintenance records.
Table 2-1 RedMAX Maintenance Schedule (continued)
Daily Maintenance Description/Required Tasks
2-3
Chapter 2 Overview
applications down to -18C (0F). It has excellent resistance to abrasion, moisture,
alkalies, acids, corrosion and varying weather conditions (including ultraviolet
exposure).
Weatherproofing putty. Refer to your local supplier for detailed specifications. The
type of material to be used will depend on your expected weather conditions.
Establishing a Spares Program
In order to minimize possible network downtime, you should stock a few
maintenance-related items with your base station equipment.
Ensure that the spare parts are stored in accordance with the manufacturer's instructions
with regard to temperature, humidity and anti-static requirements
.
Refer the RedMAX Base Station Installation Guidelines for details of the required parts, for
part numbers and ordering information.
Reference Information
You will also need to gather the following network-specific information:
Device Configuration including both hardware and software configuration of each
RedMAX device, as well as any other devices that are either physically or logically
connected to your RedMAX devices.
Many network devices make provisions for saving their running configuration to text
format and then storing this file on an FTP server. If that is not an option, you will need
to collect and store screen captures of the necessary configuration screens. Make sure
to include the currently active software versions.
Network diagram: That may consist of multiple drawings. Your network diagram must
show the following information.
The physical connections between network devices;
Table 2-2 AN100U/UX Spare Parts
Part Description
IF cable This cable connects the indoor unit (IDU) to the radio.
RF Cable This cable connects the radio to the antenna.
Fuses These fuses are located in the IDU to protect the unit from power surges.
SUO/SUI Subscriber unit, with know characteristics can be used when troubleshooting
and can be used as a replacement for customer devices, as required.
Power Cord This cord is used to connect the IDU to power outlet
Hardware You should keep the following items on hand: nuts, bolts, washers and lock
washers for the outdoor unit) to replace damaged or corroded parts.
2-4
The manufacturer and the model number of each device;
LAN and WAN protocols used for all types of network communication.
Logical connections. These may be listed on a separate diagram.
The network interface of each manageable interface.
User data and management paths must be clearly defined with appropriate VLAN
IDs and IP subnets, if applicable.
Note It is crucial that your RedMAX system be operating on a supported software pair.
Refer to the RedMAX AN100U/UX Base Station User Guide for list of supported software
which specifies which subscriber unit software is supported with each AN100U/UX
software version. You must ensure that you are using compatible software versions.
Monitoring Your System
The ability to access your sector controllers and actively monitor various items is
imperative in order to keep the system operational at a carrier class level.
Ideally, you can install a client VPN system on the computer that you are using to monitor
your sector controllers. This allows you to both monitor and configure your system
remotely. Once the VPN is installed, you should be able to log into any of the sector
controllers using either the CLI or the Web interface.
Connecting to the Sector Controller Web Client
The following table lists the Web browsers supported in this release. This release supports
English only.
.
You will need to connect to the web interface of the sector controller to perform most
maintenance or troubleshooting procedures. You must have connectivity from your
computer to the sector controller or be connected directly to the sector controller before
you can use this procedure.
Step 1 Open one of the supported browsers.
Step 2 Enter the following command:
http:// 192.168.101.3
Table 2-3 Supported Web Browsers
Web Browser Supported Versions
Internet Explorer 7.x
Mozilla Firefox 2.0.0.5, 3.0.5 and above
2-5
Chapter 2 Overview
If you have configured another local or network IP address you must use that address.
Step 3 When the command prompt screen appears, login using the following values:
Username: admin
Password: admin
You are now connected to the sector controller and can display and modify its current
configuration. Refer to the RedMAX AN100U/UX Base Station User Guide for details on
using the sector controller Web client.
Connecting to the Sector Controller Command Line Interface
The sector controller also provides a command line interface, through which you can
display and modify the devices current configuration. You require Telnet or a similar
application to connect to this interface.
You must have connectivity from your computer to the sector controller before you can use
this procedure.
Step 1 Open the Windows Start Menu and select Run:
telnet 192.168.101.3
Username: admin
Password: admin
You are now connected to the sector controller CLI. Refer to the RedMAX AN100U/UX
Base Station User Guide for detailed information on using the CLI.
Accessing the Debug Mode
Debug mode is used for factory test and advanced troubleshooting. Logging in to the Web
GUI or Telnet session using the debug user name and password provides access to
advanced configuration controls. Debug mode should be used only under the explicit
direction of Redline field service or their representatives. It is recommended to change the
debug mode default password to restrict access to this feature.
telnet 192.168.101.3
2-6
Username: debug
Password: debug
Connecting to the Subscriber Unit Command Line Interface
The subscriber unit provides a command line interface, through which you can display and
modify the devices current configuration. You require Telnet or a similar application to
connect to the subscriber unit.
The IP address 192.168.101.2 is also available, but this address can be changed. The IP
address, 192.168.101.1 is always available, regardless of build date or custom
configuration.
Note The default IP address may differ depending on the firmware build date.
You must have connectivity from the sector controller to the subscriber unit before you can
use this procedure.
Start > Run
telnet 192.168.101.1
If you have configured another local IP address you must use that address.
Username: admin
Password: admin
You are now connected to the CLI of the subscriber unit. Refer to the RedMAX Outdoor
Wireless Access Subscriber Modem (SUO) User Guide for detailed information on using
the CLI.
Monitoring System Event Logs
System events for both the AN100U/UX and subscriber unit are captured in an event log.
The event log for both devices can be accessed via their respective command line
interfaces (CLI).
Both devices order their event log chronologically with the most recent event first in the
list. Each event is time stamped with either the system time, or a time of day obtained from
a time server, if one has been configured in your system.
2-7
Chapter 2 Overview
Neither device stores its event log in non-volatile memory, meaning that all information will
be lost when the unit reboots. If you plan on rebooting or otherwise interrupting power to
your device, make sure to capture the event logs before initiating the reboot.
A number of Perl scripts are available to parse your syslog files and generate reports. See
Appendix A, Event Log Scripts for details on running these scripts.
AN100U/UX Web Client
Step 1 Login to the Web client as outlined in Connecting to the Sector Controller Web Client on
page 2-4.
Step 2 From the Main menu select Monitoring > Event Log.
Step 3 Review the Event log, looking for any of the messages listed above. You can use the find
feature (Ctrl + F in most browsers).
AN100U/UX CLI
Step 1 Login to the CLI client as outlined in Connecting to the Subscriber Unit Command Line
Interface on page 2-6.
Step 2 Enter the Show command and re-direct the output to a file for review:
show event
Step 3 Since it is likely that the event log is longer than a single terminal window, and possibly
longer than your client machine's buffer, you can optionally use the following command:
show eventLog paged
This will display the event log one page at a time. Press any key or the display the next
page.
Step 4 Right-click on the Telnet window and select Select All. Then copy <Ctrl-c> and paste
<Ctrl-p> the content into another file for review. This option allows you to collect the event
log data for further analysis, if you are not using a syslog server.
Step 5 Review the resulting file for any of the messages listed above.
Refer to the RedMAX AN100U/UX Base Station User Guide for detailed information on
using the CLI.
SUO CLI
Step 1 Open a Telnet session to the IP address of the sector controller. The default address is
192.168.101.3. When the command prompt screen appears, login using the following
values:
Username: admin
Password: admin
2-8
Step 2 Enter the Show command and re-direct the output to a file for review:
show event
Step 3 Since it is likely that the event log is longer than a single terminal window, and possibly
longer than your client machine's buffer, you can optionally use the following command:
show eventLog paged
This will display the event log one page at a time. Press any key or the display the next
page.
Step 4 Right-click on the Telnet window and select Select All. Then copy <Ctrl-c> and paste
<Ctrl-p> the content into another file for review. This option allows you to collect the event
log data for further analysis, if you are not using a syslog server.
Step 5 Review the resulting file for any of the messages listed above.
Refer to the RedMAX AN100U/UX Base Station User Guide for detailed information on
using the CLI.
Monitoring Statistical Results Screens
Both the AN100U/UX and the subscriber units provide various screens showing wireless,
Ethernet, and service flow performance. You can find statistical information on the
subscriber unit in the CLI Monitor screen (accessed by simply typing "monitor" from the
root menu. The same menu is available via the AN100U/UX's CLI, but most of the
AN100U/UX's crucial information is more easily accessed via the GUI using the SS Info
and Status menus.
page 2-4.
Step 2 From the Main menu select Monitoring > SSInfo.
The Subscriber Information page is displayed. You can review this page to view
statistical information on each of the connected subscriber units.
Step 3 From the Main menu select Monitoring > Status.
The Wireless Status page is displayed. You can review this page to view statistical
information on the wireless interface.
AN100U/UX CLI
Step 1 Login to the CLI as outlined in Connecting to the Sector Controller Command Line
2-9
Chapter 2 Overview
Step 2 Enter the monitor command:
monitor
Step 3 You can now view a dynamically updated screen of statistics. Press any key to exit
monitoring mode.
Step 4 Enter the interfaces command to monitor the wireless interface:
interfaces wireless show
Step 5 Select and then copy and paste the output, in the Telnet window, to a file for review.
Step 6 Enter Ctrl-Z to return to the root mode.
SUO CLI
Step 1 Login to the CLI as outlined in Connecting to the Subscriber Unit Command Line
monitor
monitoring mode.
Step 4 Enter the diagStatistics command to monitor the wireless interface:
diagStatistics show
Step 5 Select and then copy and paste the output, in the Telnet window, to a file for review.
Step 6 Enter Ctrl-Z to return to the root mode. You can now logout or keep the session for further
access.
Monitoring the System Parameters
You can monitor basic operation of the sector controller and its registered subscribers
through the sector controller GUI or CLI.
The baseline RSSI levels for each radio should be monitored in order to establish the
performance level for each device. These levels should be recorded when the radios are
installed and then regularly thereafter to see any potential trends.
You can set threshold traps based on your performance guidelines or within an acceptable
range of peak performance and that level is set as the trigger to create an alarm. The exact
value of what constitutes an acceptable range is determined by your network
performance requirements. For example, a range of 15% allows the radio to continue to
perform, but alerts you to a potential problem well before the radio link goes down.
When an SNMP trap or TCA has been triggered you can specify what type of alarm will be
generated and using applications, such as RMS, you can also perform various actions
such as emailing the system administrator or rebooting support equipment.
2-10
Verifying fixed WiMAX performance requires that you monitor and record many different
parameters including:
Channel Power (RSSI)measures the average time domain power within the selected
bandwidth and is expressed in dBm.
Occupied Bandwidth (BW)calculated as the bandwidth containing 99% of the
transmitted power in the given RF span.
Carrier Frequencythe measured frequency of the received signal. It is equal to the
specified frequency plus the Frequency Error described above.
Base Station IDEach transmitter has a unique ID. BTS Master displays it as Base
Station ID by decoding the Frame Control Header (FCH) part of the downlink frame.
Adjacent Subcarrier Flatness Peakthe absolute difference between adjacent
subcarriers.
Using the Ping Utility
The most basic tool available for verifying network connectivity is the ping utility. There are
a few parameters that are frequently used during RedMAX maintenance and
troubleshooting.
The following information applies to ping as implemented on a Windows platform. Details
may differ slightly for other operating systems.
Step 1 Open a console window on the PC behind the subscriber unit:
Start > Programs > Accessories > Command Prompt
Step 2 In the console window enter the following co mm an dr:
ping <IP Address>
where <IP address> is the address of the destination device
Step 3 Review the results. The output should resemble the following:
Example 2-1 ping Output
Reply from 192.168.101.3: bytes=32 time=3ms TTL=30
Ping statistics for 192.168.101.3:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in subscriber unit -seconds:
Minimum = 3ms, Maximum = 3ms, Average = 3ms
2-11
Chapter 2 Overview
By default, four packets are sent, at approximately 1-second intervals. The timeout for
each request depends on the version of Windows. For Windows XP the timeout is 4
seconds.
The default packet size is 32 bytes. This is the size of the data field in the ICMP packet,
but it is not the size of the entire packet. When you add 8 bytes of ICMP overhead, 20 bytes
of IP overhead and 18 bytes of Ethernet overhead, we get an Ethernet frame size (for a
default ping) which is actually 78 bytes. If you want to test how ping works with the
maximum Ethernet frame size, use the following command:
ping 192.168.101.3 -l 1472
If the specified size is larger than 1472 bytes, your computer will send more than one IP
packet. It will send fragments that will be reassembled at the destination. If the transfer is
completed successfully, then a packet (or packets) of the same size will be sent back.
The maximum value that you can enter for the ping size is 65500. With 8 bytes of ICMP
header, this makes the 65508 bytes of IP payload. IP will fragment this into 45 packets. So
for the "maximum ping" to succeed, 45 Ethernet packets of maximum size (actually 44
packets will be 1518 Bytes, the last one will be 426 Bytes long) have to be successfully
transmitted, and then in response, an additional 45 packets have to be successfully
received.
Although ping sends packets at approximately 1-second intervals, fragmentation is under
control of the TCP/IP stack, and all of the 45 packets will be sent at the line rate of the
network card, which in some cases could cause ping to drop packets simply because
buffers across the network are full.
Using the Iperf Utility
Iperf is a free, open source utility that can be used for testing TCP and UDP performance.
It is available for download at http://dast.nlanr.net/Projects/Iperf/.
In order to perform an iperf test, you need two computer's, one at either end of the
RedMAX link. The first computer acts as the client, and the other acts as the server. The
determination of which computer operates in which mode, and how they are configured,
depends on the nature of the test to be performed.
Iperf is a CLI-based tool. Arguments are supplied during execution determine the nature
of the test to be performed. The following table lists the most commonly used arguments:
Where: -l indicates the buffer size.
In this example 1472 bytes of data are sent. 1472 bytes of ping "data" maps to
1518 bytes of an Ethernet packet.
2-12
The first step is to decide on your test scenario. For example, if you want to measure
overall sector capacity, you should provision a service flow with a maximum rate well
above what you expect to achieve. If you plan to test the throughput of a given service
package, you should ensure that your subscriber unit is provisioned using the service flow
in question. Either way, once you have completed provisioning your subscriber unit, you
should first perform a basic connectivity test, using ping as outlined in Using the Ping
Utility on page 2-10.
Once you have verified connectivity between the devices, you can proceed with one of the
iperf tests as described below. Ensure that the server is started first, and then the test is
initiated from the client. The server does not have to be restarted between tests unless the
nature of the test is to be modified. The server and client devices will change depending
on the test that you running. Details of which devices should be configured as the client
and as the server are provided for each test.
Depending on the system characteristic to be tested, you will use on of the following tests:
Downlink TCP Throughput
For this test, the computer connected to the subscriber unit is configured as the server.
Step 1 Open a console window on the computer behind the subscriber unit:
Table 2-4 iPerf Options
Flag Description
i This argument specifies the interval at which iperf will output an update of the current
measured throughput. Without this argument, iperf will only display a summary at the end
of the test.
t This argument defines the duration of the test. It is measured in seconds. Generally, 30
seconds is recommended as a minimum.
u This argument specifies UDP traffic. Without this argument, iperf will use TCP
b This argument is used with the -u argument. It specifies the rate at which to pass UDP
packets. Specifying the argument automatically implies the -u argument.
d This argument specifies that iperf should perform a bidirectional test; throughput
performance is measured in both the uplink and downlink simultaneously. It is not
recommended that this argument be used with TCP tests.
P This argument is used to specify the number of parallel streams to be used for a given test.
If you are trying to simulate multiple customers, or multiple network applications in use
simultaneously, you can specify how many with this argument.
w This is used to specify the TCP window size to be used by the TCP stack. The default
Windows window size is 8k. You will need to need to specify 64k TCP window for TCP tests
on both client and server by adding the "-w 64k" argument
This argument is not relevant for UDP tests.
s This specifies that iperf will run as a server.
c This specifies that iperf will run as a client.
2-13
Chapter 2 Overview
Step 2 In the console window enter the command to start the server:
iperf -s
Step 3 Open a console window on the second computer connected to the sector controller:
Step 4 In the console window enter the command to start the client and run the test:
iperf -c <ip_address> -i 5 -t 60 -w 64k
Uplink TCP Throughput
For this test, the computer connected to the subscriber unit is configured as the client.
iperf -s
iperf -c <ip_address> -i 5 -t 60 -w 64k
Bi-directional UDP Throughput
For this test, it does not matter which computer is configured as the server.
iperf -s -u
iperf -c <ip_address> -u -b <rate> -i -t 60 -d
2-14
If you are checking for packet loss, ensure that the rate you specify is low enough so as
not to cause packet loss simply by overloading your service flow.
In general you do not need to perform bi-directional TCP throughput tests as this type of
test does not accurately replicate any typical usage scenarios. You may find that the net
bi-directional throughput of the system is lower than the results of the separate
uni-directional tests, where performed. This is due to the fact that TCP acknowledgements
for the downlink flow will be caught in the same data queue as data packets for the uplink
flow, and vice versa.
Network Sniffers
In order to ensure that your system is performing as expected or for troubleshooting
purposes you may need to see exactly what packets are sent from a certain device; what
packets are received, etc. Software (and hardware) tools that allow you to do this are
called network sniffers and there are a few available on the market.
Ethereal is a popular, open-source application that contains almost all of the features of
the more expensive tools. Some of the better-known, commercial applications are Network
General's Sniffer and Wild Packet's Etherpeek. The usage of each of these applications
currently is beyond the scope of this document.
Using the rfMonitor Application
The rfMonitor application is provided by the Redline Technical Services department and
can be used for monitoring your wireless performance over time. It monitors the RSSI and
CINR values at set intervals (500ms ~ 10s) and graphs the results. The results can be
saved as either an image, or as a .csv file for use in any spreadsheet program.
The latest version can be found on the Redline Partner website, under Support Tools. A
User Guide is also provided on the partner site.
Planning/Scheduling Equipment Maintenance
Most RedMAX equipment maintenance, such as upgrading software, replacing cables or
replacing antennas, will require you to shut down the sector controller or subscriber unit
impacting service. Before performing any maintenance you should first perform the visual
inspection outlined in Performing a Visual Inspection of the IDU on page 3-1 and
determine the scope of the required work.
Where: <rate> represents the rate at which you wish to send UDP traffic. If you are
testing system capacity then specify a rate higher than you expect to transfer,
and monitor the achieved rate.
2-15
Chapter 2 Overview
Once you have determined the work that needs to be done, you will need to schedule a
maintenance window. When setting the date and duration for this maintenance window you
need to consider a number of things:
1. What replacement parts are required? Are these parts on hand or do they need to be
ordered? If parts need to be ordered, what is the delivery time?
2. If work must be done on the outdoor equipment, do you need to book appropriate
personnel?
3. Do you have all of the required test equipment? See Required Equipment on
page 2-2.
Personnel Required for Maintenance
Due to the nature of wireless communications, you will need specialized personnel for both
installation and maintenance of your network.
Your local maintenance team should also be available for dispatch when problems do
occur that cannot be addressed remotely. If any RedMAX equipment is installed on a tower
or at any location in which accessibility is an issue you will require an experienced tower
climber or rigger when installing or replacing outdoor components. Contact your local
Redline representative for information on local companies.
The local support personnel must be capable of connecting to the equipment via serial or
Ethernet connection in order to resolve local device issues. They will need administrative
login accounts. Additionally they should have access to the RedMAX documentation
provided with the equipment. They should also have access to the logged records for each
sector controller so that they can establish baseline performance.
They will also need all necessary information to gain access to the site during off hours as
well as have access to tower riggers in case of a lightning strike or antenna failure.
All maintenance personnel should follow the RedMAX installation and operation
specifications strictly, and avoid any operation on the equipment beyond the required
maintenance, e.g., opening the chassis, arbitrarily plugging/unplugging, resetting, starting
and switching over the equipment, or changing the configuration.
Maintenance personnel must wear an anti-static wrist strap when working with any
hardware system. You must store any damaged parts and the spare parts in anti-static
bags, which must be labeled correctly and stored properly. This is especially important if
any parts are being returned for warranty replacement.
Establishing and Recording the Baseline Configuration
Once your system is installed and configured correctly, you need to record a number of
values to define the baseline operating guidelines. You will then use these measurements
to verify that your system is functioning as expected. You will also use these values after
performing any maintenance to ensure your system has been returned to its optimum
performance level.
2-16
page 2-4.
Step 2 From the Main menu, select Monitoring > Status.
Step 3 Record the following values or perform a screen capture of the selected screen and save
the file in a maintenance directory. Rename the file accordingly.
Step 4 From the Main menu, select Interface Configuration > Wireless Interface.
the file in a maintenance directory. Rename the file accordingly.
Table 2-5 Wireless Status Page
Parameter Value Parameter Value
CINR [dB] 21.3 RF Tx Power [dBm] 36
Traffic Downlink [kbps] 0 Traffic Uplink [kbps]
BW Margin Downlink [kbps] 4601 BW Margin Uplink [kbps] 4752
CRC Errors 0 Registered SS's 1
Air Interface Status enabled SC Synchro Status No Synchro
IDU Temperature [Celsius] 39 ODU Temperature [Celsius] 36
Power Supply Status A-On Fans Status main
Active DL Service Flows 1 Active UL Service Flows 1
DL SMC Rate [kbps] 0 UL SMC Rate [kbps] 0
DL Bandwidth Usage [%] 0 UL Bandwidth Usage [%] 0
Reference RSS [dBm] -75 Noise Level [dBm] -102.7
Table 2-6 Interface Status Page
Parameter Value Parameter Value
Speed 28.8 Mbps Operational Status Up
Last Change 00:00:25
Ingress
In Octets 3702085 In Unicast Pkts 26429
In Broadcast Pkts 0 In Multicast Pkts 0
In Discards 0 In Errors 0
Egress
Out Octets 10473071 Out Unicast Pkts 24496
Out Broadcast Pkts 9300846 Out Multicast Pkts 0
Out Discards 0 Out Errors 0
2-17
Chapter 2 Overview
Maintenance Record Keeping
You need to retain all of this information, as a hardcopy and optionally in electronic format.
Printed versions of all installation settings and measurements as well as regular
maintenance logs should be printed and maintained in a binder or file for quick and easy
reference. This is usually a requirement of your operational license.
All installation and maintenance logs should be dated clearly and contain the name, serial
number and MAC address of the device from which they were obtained.
Establishing Secure, Remote Access
LAN
If you have configured a LAN that includes your sector controllers, you need to have the
correct routing in place, you can then log into the AN100U/UX remotely to monitor its status
and change its configuration.
VPN Client
Ideally, you can install a client VPN system on the computer that you are using to monitor
your sector controllers. The VPN client allows you to both monitor and configure your
system remotely.
Refer to the instructions provided with your VPN client software for details on installing and
configuring the software for use. Once the VPN is installed, you should be able to log into
any of the sector controllers using either the CLI or the Web interface.
Table 2-7 Wireless Interface Status Page
Parameters Values
RF DL Channel (KHz) 3496000
RF Channel Separation (KHz) 0
Tx Output Power (dBm) 5
SS Tx Power Control Enable Yes
Reference RSS (dBm) -69
Auto Rx Gain Enable Yes
2-18
Remote Management of an SUO
In order to remotely access an SUO you need to assign an IP address to the SUO's "air
interface". This address can be assigned through a DHCP server. You can also assign a
static SMC IP address.
Note Statically-assigned IP addresses are supported in RedMAX v2.1 and higher.
Each SUO can have up to three IP addresses:
The default IP address that is assigned at the factory and cannot be deleted or
modified: 192.168.101.1
The local IP address that can be set. This is the IP address that should be used to
connect the SUO directly to a local computer.
The remote IP address for the air interface that must be assigned by a DHCP server.
Note All three IP addresses should be on different subnets.
You must ensure that Management Support has been enabled on each SUO.
Configuring a DHCP Server
You can use a DHCP server to assign IP addresses to registering subscriber units. You do
not need to set up service flows for DHCP traffic. The sector controller acts as a DHCP
relay.
When assigning IP addresses with a DHCP server, the basic DHCP lease must include
your default gateway, subnet mask, and an IP offer. Time of Day (ToD) is also highly
recommended (option 4).
Step 1 Install and configure the DHCP server as outlined in the documentation provided with the
application. Redline recommends commercially-available products, such as Cisco CNR
or Nominum Dynamic Configuration Server.
Step 2 Specify the following parameters when configuring your DHCP server:
:
Table 2-8 DHCP Server Configuration Parameters
Parameter Description
Name Specify a name and/or description for a new policy. i.e.
RedMAX_DHCP_One
IP Address Range Specify the addresses to be assigned as a device requests them. You will
need to specify a start and end for the range. i.e. Start=172.29.228.21;
End =172.29.228.41. You must ensure that your sector controller(s) and
the computer are not within this range.
2-19
Chapter 2 Overview
Note The ToD server required here is different from the SNTP that is required for the
sector controller event log. These devices operate using different protocols and
cannot be used interchangeably.
You will need to update the following parameters on each sector controller:
page 2-4.
Step 2 From the Main menu select Interface Configuration > Management Interface.
Step 3 Enable the option, Obtain IP Parameters from DHCP Server, if you want the sector
controller to obtain its IP address from the DHCP server.
Step 4 Select one of the following options for the subscriber units:
SS-s should use the same DHCP Server as SCSelect this option to have the
sector controller forward all subscriber DHCP requests to the same DHCP server, used
by the sector controller to obtain its IP address. This option is valid only if the field
Obtain IP Parameters from DHCP Server is selected.
SS-s should use the following DHCP ServerSelect this option to specify the
DHCP server to be used by subscriber units. You must also specify the IP address of
the DHCP server. The sector controller will forward all subscriber DHCP requests to
this IP address.
Step 5 Click Save to save the required changes to the sector controller configuration.
Step 6 Reboot the sector controller to activate these changes. See Rebooting the AN100U/UX
on page 3-2
Subnet Mask i.e. 255.255.255.0
IP Address of the Relay
Agent
You will need to specify the sector controller as the Relay Agent. i.e.
Start=172.29.228.11
Time Offset This value is set in seconds, so for example, to obtain a 5-hour time offset
you have to set this value to 18000s. 18000 seconds = 5 hours for the
Eastern Time difference from GMT
Gateway IP Address If you are using an ASN gateway, specify the IP address of the host
machine.
Time of Day (ToD)
Server IP Address
Specify the IP address if you are using a Time of Day (ToD) Server (option
4). It is important to understand that the IP address for ToD server must
be a valid IP address with a functional ToD server. The ToD server must
respond to a valid time request.
Syslog Server IP
address
Specify the IP address if you are using a syslog server.
Table 2-8 DHCP Server Configuration Parameters (continued)
2-20
When a subscriber unit registers with the sector controller, the IP address will now be
assigned by the DHCP server.
Step 1 You can verify the subscribers IP address from the main menu by selecting Monitoring >
SS Info.
Step 2 You can also verify the IP address by connecting directly to the subscriber unit using
Telnet. The SUO IP address is displayed on the SS Info page. See Connecting to the
Subscriber Unit Command Line Interface on page 2-6.
Configuring a Time of Day Server
Time servers are stand-alone devices that obtain and distribute the correct time to all
devices and host machine in your network. It is important to note that the AN100U/UX
supports only SNTP (RFC-2030), while the subscriber units support only ToD (RFC-868).
Network Time Protocol (NTP) is a TCP/IP protocol used to synchronize the real-time clock
in computers, network devices and other electronic equipment that is time sensitive.
The Coordinated Universal Time (UTC) can be obtained over the Internet, which contains
numerous primary and secondary time servers, or it can be acquired from stand-alone
devices that receive atomic clock signals from the GPS system.
ToD (RFC-868) provides timestamps for logged events. This is required for
troubleshooting. Network elements periodically request the time of day from the time
server that is specified in their DHCP response.
Both Windows and Solaris provide ToD services. Refer to the documentation provided with
your OS for details on configuring ToD services.
3-1
3
Indoor Equipment Maintenance
For maintenance purposes it is easier to divide maintenance work between indoor and
outdoor maintenance. In some case the personnel required to perform maintenance of the
indoor equipment will be different than those required for the outdoor work.
Routine maintenance of the indoor equipment will be covered, in this chapter.
Performing a Visual Inspection of the IDU
Visually inspect data connections, power cables and grounding connections for indoor
equipment on a monthly basis. Ensure all connections are secure and look for any signs
of rust or other types of corrosion.
Step 1 Inspect all connections on the AN100U/UX IDU. All connections must be secure and
cables in good repair. Cables and connectors should be clearly labelled to facilitate
troubleshooting.
Step 2 Inspect all connections to the RPS, if installed. The RPS must be powered down before
disconnecting or re-connecting any devices.
Note The AN100UX redundant power supply is a DC-type supply. The RPS power
must be connected using positive polarity, i.e. the +48 VDC RPS output
must be connected to positive input on the AN100UX. Refer to the RedMAX
Base Station Installation Guidelines for detailed instructions.
Step 3 Inspect all connections for local synchronization, if configured. Refer to the RedMAX Base
Station Installation Guidelines for details.
Step 4 Inspect all connections to the GPS, if installed. Refer to the Redline GPS Clock User
Manual and to the RedMAX Base Station Installation Guidelines for details.
Step 5 Inspect all connections to the computer, syslog server and any other computers that are
components of your OSS. Refer to the RedMAX Base Station Installation Guidelines for
details.
Step 6 Ensure all cables are secured and do not pose a tripping hazard.
Step 7 Ensure cables are not pinched or bound too tightly.
3-2
Step 8 Ensure RF cables are not located next to high voltage cables. Ensure all cables are clearly
labelled.
Step 9 Log all of your results and store the inspection results with your maintenance records.
Rebooting the Devices
Most changes that you make to the sector controller configuration require that you save
the changes and then reboot the device in order to activate your changes.
Changes made to the subscriber unit configuration may also require that you save the
changes and then reboot the device in order to activate your changes.
This procedure is service impacting and should only be performed during a scheduled
maintenance window. However, in general the interruption is only a few minutes and could
be done during a period of low network activity.
Rebooting the AN100U/UX
Step 1 Log into the sector controller and scroll to the bottom of the main menu.
Step 2 Click on the Reboot button at the bottom of the main menu.
The device will terminate all of its connections and reboot itself. This will typically take 1-2
minutes. Any configuration changes that were made will now be active.
Step 3 Verify your changes and ensure the device is operating as expected.
Backing up, restoring and upgrading the sector controller software is covered in the
RedMAX AN100U/UX Base Station User Guide.
Rebooting the Subscriber Unit
Step 1 Log into the sector controller and click SS Info in the menu.
Step 2 Click on the Reset button at the top of the page.
The device will terminate all of its connections and reboot itself. This will typically take 1-2
minutes. Any configuration changes that were made will now be active.
Step 3 Verify your changes and ensure the device is operating as expected.
Redundant Power Supply
The redundant power supply (RPS) is a stand-alone power supply that can be used as a
backup power supply for deployments of up to six AN100UX base stations. The RPS can
support one AN100UX unit with a failed power supply. It is not intended to be used as an
uninterruptable power supply (UPS).
3-3
Chapter 3 Indoor Equipment Maintenance
Note The RPS can only be used for the AN100UX.
The RPS scans and sets the power outputs at power-on and following a detected failure
of a connected AN100UX. <
During this time you need to obtain a replacement device and configure it using the most
recent backup from the disabled device and then replace it within the network.
Replacing the Indoor Unit of the AN100U/UX
Note This procedure is service impacting and should only be performed during a
scheduled maintenance window.
Step 1 If possible, perform a configuration backup from the disabled device. Refer to the RedMAX
AN100U/UX Base Station User Guide for detailed instructions.
Step 2 Power off the RPS and the disabled device.
Step 3 Unplug the primary power cable from the supply and then from the disabled device.
Step 4 Remove the device from the mounting rack, if applicable.
Step 5 Install the replacement device in the rack and connect the power cable from the RPS.
Step 6 Connect the primary power cable and then connect the other end to the power supply.
Step 7 If the device does not power up automatically, then turn it on.
Step 8 Verify the successful restart and correct operation. Review the event log to ensure the
correct radio type is listed.
Step 9 Verify that the software version of the new device is the same or higher than the disabled
device.
Step 10 Restore the configuration of the disabled device. Refer to the RedMAX AN100U/UX Base
Station User Guide for detailed instructions.
Step 11 Log into the Web client and navigate to Monitoring > Status. Review the Status page to
verify that the air interface is enabled and to ensure the sector controller is operating
normally.
Step 12 Navigate to Monitoring > SS Info and verify any subscriber units are registered as
expected.
Step 13 Verify the wireless interface configuration: Interface Configuration > Wireless Interface.
The subscriber units should re-connected as soon as the sector controller is powered up.
You can verify the other operating parameters as required.
3-4
RPS Maintenance
In terms of required maintenance, you only need to verify the connections to the RPS from
each of the sector controllers. After verifying the connections, you should test each sector
controller in turn, to ensure that the RPS will cut in as required in the case of a failed power
supply.
Note This work should be done in a maintenance window in case you encounter any
issues and a sector controller is powered down.
Step 1 Connect each sector controller to the RPS. Detailed instructions, for connecting each
sector controller to the RPS, are provided in the RedMAX Base Station Installation
Guidelines.
Step 2 Disconnect the first sector controller from its primary power source. The RPS scans the
devices and when a power outage is detected, sets and delivers the required power to the
device.
Step 3 Verify that the sector controller continues to operate as outlined in Establishing and
Recording the Baseline Configuration on page 2-15.
Step 4 Re-connect the primary power source for the sector controller and again verify that the
device continues to operate as outlined in Establishing and Recording the Baseline
Configuration on page 2-15.
Step 5 Repeat this for each sector controller that is connected to the RPS.
Step 6 Record all of your results and file the written report with your other maintenance logs.
Uplink Power Control
An important factor in overall network performance is the uplink power control of a
RedMAX AN100U/UX.
This feature allows the sector controller to automatically adjust the transmit power level for
all registered subscriber units in its sector. This is done by enabling, the SS TX Power
Control Enable option on the sector controller and specifying an associated Reference
RSS value.
When this option is enabled, the sector controller continually monitors the registered
subscriber units and adjusts their transmission power to maintain optimum levels
according to the preset reference RSS. This feature allows the overall system to achieve
a determined noise level for the uplink whenever the network is fully loaded.
The Reference RSS can be set between -40 and -95dBm. For optimum performance this
parameter should be carefully configured dependant on the following factors that are
initially determined during the design of the network and adjusted after installation, to
satisfy practical network requirements for each sector controller. The exact Reference
RSS value depends on the following factors:
3-5
Expected minimum modulation scheme offered over the uplink (64QAM, 16QAM,
QPSK etc.).
RedMAX receive sensitivities per modulation scheme and channel size.
Designed cell radius.
Expected fading conditions within the cell.
The expected noise rise from other cells when the network is fully loaded with the
expected traffic.
Path condition for the wireless link between the sector controller and the subscriber
unit (e.g., LOS, OLOS, NLOS).
Frequency reuse factor in the network or distance to the closest cells where the
frequency is reused.
As an example, for a system with 3.5 MHz channel size and offering 64QAM, 3/4 in the
uplink, ideally the RSSI at the sector controller should be no less than -77 dBm, under no
external noise conditions and assuming a fading of 5 dBm, and expected noise rise of 2
dBm, the ideal requested RSSI should be:
-77dBm + 5 dBm + 2 dBm = -70 dBm.
For the same case, but offering 16 QAM, , with receive sensitivity at -89 dBm under no
external noise conditions and again assuming a fading of 5 dBm, and expected noise rise
of 2 dBm, the ideal requested RSSI should be:
-89 dBm+ 5 dBm + 2 dBm = -82 dBm.
In general, this parameter should be initially defined as part of the system design
recommendations. Incorrect configuration of the "Reference RSS" parameter may result in
less-than-optimum uplink performance or higher inter-system interference.
The higher the setting for Reference RSS, the higher the power levels that all of the
subscriber units in the sector will need to transmit and you may also see higher noise rise
in the neighboring cells. For this reason a reasonable Reference RSS according to the
frequency re-use factors and noise floor level should be selected, in order to satisfy the
expected service levels in the sectors while avoiding unnecessary power transmitted from
the subscriber units in the sector, and hence lowering the inter-system interference.
Step 1 Based on your channel size and modulation, determine the reference RSS value for each
sector controller.
Sector Controller Synchronization with the GPS Clock
Sector controller synchronization must be used to coordinate RF transmissions when
operating two or more co-located sector controllers in order to minimize inter-sector RF
interference.
3-6
Local Synchronization versus GPS Synchronization
Each RedMAX sector controller has synchronization ports to send and receive clock
synchronization pulses. When using the sector controllers internal synchronization
feature, one sector controller is designated as the master and generates the clocking
pulses to synchronize the operation of up to five slave sector controllers, thus providing
full 360-degree coverage. All slave sector controllers monitor these clocking pulses and
synchronize their transmission and receive periods.
If your co-located sector controllers are at an isolated location, at which there are no
adjacent cells belonging to the same network, then you can use local synchronization and
a GPS clock is not required. Refer to the RedMAX Base Station Installation Guidelines for
details of installation and initial configuration of local synchronization.
If your network consists of geographically co-located cells, then an external GPS clock is
required at each site. As with local synchronization, one sector controller is designated as
the master. The master now receives the GPS clocking pulses and then uses this to
synchronize the operation of up to five slave sector controllers. Refer to the RedMAX Base
Station Installation Guidelines and Redline RedMAX GPS Clock User Manual for details of
installation and initial configuration of GPS synchronization.
Verifying Network Synchronization
Use the Web interface or the CLI to view the event log in order to confirm the correct
operation of each sector controller. See Monitoring System Event Logs on page 2-6.
Additionally, Appendix B, AN100U/UX Event Log Messages lists messages that will
appear in the event log. Messages specific to both local and GPS synchronization are
listed in Synchronization Messages (See also Appendix D, Synchronization Event Log
Messages on page B-15.
Changing from Local to GPS Synchronization
The following procedure is applicable to sites consisting of two or more sector controllers
that are already operating with local synchronization. Please refer to the RedMAX GPS
Clock User Manual for detailed information on correct installation and cabling of the
required hardware.
Note This procedure is service impacting and should only be performed during a
scheduled maintenance window.
To minimize the service impact and ensure successful switch over from local to GPS
synchronization, you must follow the procedure in the exact order listed below.
3-7
Setting the Required Wireless Interface Parameters
The following wireless interface parameters affect transmitter timing and must be set to the
same value on each of the sector controllers in all geographically, co-located cells:
Frame Duration (ms)
Frame Downlink ratio (%)
Cell Range (km)
Determine the correct settings and ensure all of the sector controllers are configured
correctly before performing any of the following steps.
page 2-4.
Step 2 Click Wireless Interface in the menu to view the MAC parameters.
Step 3 Update the values of Frame Duration (ms), Downlink ratio (%) and Cell Range (km).
Step 4 Click the Save button to save these changes.
Step 5 Reboot the sector controller as outlined in Rebooting the Devices on page 3-2.
This can also be done from RMS by modifying the device configuration for the impacted
network from the Topology tree. You can also create and apply device configuration
templates. Refer to the Redline Management Suite User Guide for details.
Configuring the Master Sector Controller for GPS Synchronization
If a GPS signal is detected at startup, the Master with GPS immediately synchronizes its
clock to this signal and then enables the Master capability and sends synchronization
pulses to all connected Slaves. If the GPS signal is not detected at startup, the Master
capability is not enabled and the sector controller does not send synchronization pulses.
If the GPS signal is detected while the Master with GPS is operating asynchronously
(startup completed but master function not enabled), the Master with GPS transitions its
clock to match the external GPS signal and then enables the master capability and sends
synchronization pulses to slaves.
Identify the sector controller that is currently the local master clocking source. It should be
clearly labeled in the rack.
Change the master sector controller Synchronization Mode from Master to Master with
GPS Sync.
Step 1 Log into the sector controller that is currently the local master clocking source, as outlined
in Connecting to the Sector Controller Web Client on page 2-4.
Step 2 Click Wireless Interface in the menu to view the MAC parameters.
Step 3 Set the Synchronization Mode to Master with GPS.
Step 4 Click the Save button to save these changes
3-8
Verifying GPS Receiver Operation
Step 1 Verify that the GPS receiver, GPS antenna, the cabling between the receiver and antenna,
and GPS are configured correctly. Refer to the RedMAX GPS Clock User Manual for
detailed information.
Step 2 Lighting protection must be properly installed and operating as outlined in the RedMAX
Base Station Installation Guidelines and the RedMAX GPS Clock User Manual.
Step 3 Verify that all sector controllers at the site are wired correctly for GPS time synchronization.
Refer to the RedMAX GPS Clock User Manual for detailed information.
Step 4 Turn on the GPS receiver, wait for approximately 15-30 minutes to ensure that a valid
satellite signal has been received and that time synchronization, with the satellite, has
been achieved.
Step 5 Verify that the GPS clock is generating a clocking pulse on its 1 PPS port. The event log
for the sector controller configured as the Master with GPS should log an event message
"GPS Detected". Review the event log as outlined in Monitoring System Event Logs on
page 2-6.
If any of these steps cannot be verified DO NOT PROCEED any further, and contact
support@redlinecommunications.com for assistance.
Step 6 On the Status page of the master sector controller verify that the device is the Active
Master. This confirms that the master sector controller is fully operational and is providing
a clocking pulse at its Sync Out port.
Configuring the Backup Master Sector Controller
If a Master is detected at startup, the Backup Master immediately synchronizes its clock to
the Master synchronization pulses and enables the backup capability. If at startup, the
Backup Master does not detect an active master, but a GPS clock signal is detected, the
Backup Master immediately synchronizes its clock to the GPS signal and enables the
backup capability.
Identify the Backup Master sector controller, if configured. The device should be clearly
labeled.
page 2-4.
Step 2 Navigate to Interface > Wireless Interface to verify the values of Frame Duration (ms),
Downlink ratio (%) and Cell Range (km). These values must be same on all sector
controllers that will be synchronized with the GPS clock.
Step 3 Set the Synchronization Mode to Backup Master.
Step 6 Verify the successful restart and correct operation of the sector controller.
3-9
Step 7 Click Status on the main menu to open the Status page. Verify that the SC Synchro
Status is Backup Master This confirms that this device is receiving the GPS clocking
pulse from the Master.
Configuring the Slave Sector Controller(s)
Step 1 Log into the sector controller and click Wireless Interface to verify the values of Frame
Duration (ms), Downlink ratio (%) and Cell Range (km). These values must be same on
all sector controllers that will be synchronized with the GPS clock.
Step 2 Set the Synchronization Mode to Slave.
Step 5 Verify the successful restart and correct operation of the sector controller.
Step 6 Click Status on the main menu to open the Status page. Verify that the SC Synchro
Status is Slave.
Step 7 Verify that the device is receiving a clocking pulse on the Sync Out port. The event log for
the sector controller should log an event message "Master Detected" or Synchronization
OK. Review the event log as outlined in Monitoring System Event Logs on page 2-6.
Step 8 Repeat steps 1 through 7 for each of the remaining sector controllers at the base station
site.
All sector controllers will now be fully operational and time-synchronized from the GPS
satellite's clocking source.
AN100U/UX Operation in GPS Holdover
When the GPS clocks input module is locked to a GPS signal, its internal oscillator and
memory function ensure the reference synchronization signal adheres to the Timing
Characteristics of Primary Reference Clocks standards (ITU-T recommendation G.811).
If the input module loses the satellite signal, the GPS clock goes into a holdover function
in which the 1PPS is provided by the GPS clock's internal oscillator. If the GPS clock
cannot re-acquire the satellite signal the GPS clock's internal oscillator can maintain time
accuracy for a few hours. The exact duration of the holdover period depends on the type
of GPS clock.
In order to notify you that the GPS clock has entered holdover, thirty (30) minutes after
entering holdover, the GPS clock receiver will temporarily suppress its 1PPS signal for 30
seconds (i.e. no signal). The AN100U/UX detects when the 1PPS signal stops and
restarts, and this is reflected in the event log and syslog. See Figure 3-1.
When the GPS clock goes into holdover, it tries to re-acquire the satellite signal. Whether
or not the GPS clock is able to re-acquire the satellite signal, there is no clear indication
to the RedMAX sector controllers. As far as the RedMAX sector controllers can determine,
a signal is being received on the Sync Out port. If the GPS clears holdover and is again
3-10
tracking from the satellite signal there is no problem; however, If the signal is not
re-acquired, then when the internal oscillator can no longer maintain the signal, your
system timing will drift and result in significant RF interference issues.
Figure 3-1 AN100UX Event Log Showing Synchronization Messages
You need to be aware when your GPS goes into holdover.
SNMP traps are sent under certain condition and if you have configured trap receivers,
these traps can be configured to trigger alarms.
If you are not using trap receivers, then you need to monitor the event log and understand
that the sequence of events, shown in Figure 3-1, above, likely means that the GPS has
entered holdover. You can use the Perl script, errorReport.pl, as described in Script
errorReport.pl on page A-5.
Note There is no specific sector controller event log message associated with the GPS
clock entering holdover mode.
There is no other indication, to the AN100U/UX, that the GPS has entered holdover.
Additionally, there is no clear indication that the GPS has re-acquired the signal and is
receiving the satellite signal as opposed to its internal holdover signal.
You will need to investigate the GPS device to either clear the holdover manually by
resetting the device or verify that it is operating correctly and is receiving the satellite
signal.
3-11
SNMP Traps in RedMAX Version 2.1
In RedMAX sector controllers with version 2.1 software, two SNMP traps are provided for
both local and GPS synchronization. When the AN100U/UX does not detect the clock input
signal (from either the Master or Master with GPS), a trap is sent. When the signal is
detected again, the trap state is cleared.
Similarly, when the AN100U/UX internal clock is out of phase with the Master or Master
with GPS clock, a trap is sent. When the internal clock is locked and tracking again, this
trap is cleared.
When either of these states are resolved, the trap is cleared, however another trap is not
sent to advice trap receivers such as RMS, that the internal clock is locked and tracking
again.You can only determine this by inspecting the GPS clock.
Refer to the RedMAX GPS Clock User Manual for information on clearing holdover mode
and re-arming the alarm indicator.
Refer to the Redline Management Suite User Guide for information on configuring and
using these SNMP traps as alarm indicators.
Managing SNMP Traps
Through your trap receiver (i.e. RMS) you can configure SNMP traps to provide notification
when any of the above traps have been received.
You must first configure an access control list (ACL) that includes all SNMP managers, to
which traps will be sent. Any SNMP get/set requests received from managers that are not
on the ACL, will be dropped. Refer to the RedMAX AN100U/UX Base Station User Guide
for details of creating and maintaining the SNMP access control lists.
You then need to configure the actual trap destinations. SNMP traps generated by the
sector controller will be sent to each of the defined trap destinations. You must then
configure your trap receiver to provide notification upon receipt of the trap. Refer to the
RedMAX AN100U/UX Base Station User Guide for details of maintaining the SNMP trap
destinations.
Table 3-1 AN100U/UX Local Synchronization Trap
Trap Name and Setting Description
RedMAXSynchronization
Trap
synchLost =set
The sector controller has detected a signal on the Sync OUT port, but
it is out of phase and synchronization is not currently possible. This will
result in an event log and status page message showing "No synchro".
A trap is sent to specified trap receivers such as RMS.
synchLost =cleared When the AN100U/UX internal clock is locked and tracking again, this
trap is cleared.
RedMAXSynchronization
Trap
synchSignalLost=set
When a slave AN100U/UX does not detect the clock input signal from
the Master, a trap is sent to RMS. This trap can also be sent if the
Master with GPS can no longer detect the signal from the GPS.
synchSignalLost=cleared When the signal is detected again, the trap state is cleared.
3-12
If you are using RMS to manage your network, then refer to the Redline Management Suite
User Guide for information on how RMS configures itself as the trap destination and
instructions on configuring alarm notification rules.
If you are using another trap receiver, then you need to configure each sector controller to
send SNMP traps to the your trap receivers and configure those applications to provide
notification.
Troubleshooting the GPS Clock Module
Management of the GPS clock module is performed via the local console port. There is no
remote access to the GPS. If a holdover condition is detected and not cleared, a technician
must be sent on-site to investigate. It may be necessary to reset the GPS clock module
and this can only be done locally.
The RedMAX GPS clock module does not require any periodic maintenance. You may only
encounter issues with the loss of satellite signal.
The following table lists symptoms and possible investigative/corrective actions for
antenna outages (red LED lit) and corresponding loss of signal.
Table 3-2 Troubleshooting Antenna Problems
Possible Cause Investigative/Corrective Action
The antenna has been
knocked/blown down
Remount antenna dome within >5of vertical.
There is excessive snow/ice/dust
buildup on the antenna
Clear off the antenna and ensure the antenna dome is within
>5of vertical.
The antenna mount has failed. Remount antenna dome within >5of vertical.
Receiver fault Check for the presence of ~ +4.85 to +5.15 VDC power from
the GPS receiver BNC output. If the voltage is below this
range, contact support@redlinecommunications.com.
Lightning/EMP protection shorted Check for the presence of > +4.25 VDC at the antenna
side of the lightning/EMP protector BNC/TNC/Nm. The tip
= positive (+), Sleeve = negative (-).
Remove the EMP and replace it with a joiner temporarily.
If the problem clears up occurs, replace gas tube
protection element, or replace the EMP, as required.
Cable fault Check for the presence of > 4.25 VDC at the antenna
coaxial connection. The tip = positive (+), Sleeve =
negative (-).
Check the roof fly lead portion, roof demarcation
entrance, cable transits, conduits and clamps to make
sure the cables are not pinched or cut or damaged in any
way.
Check all coaxial cable connections and crimps. Ensure
all exterior connections are weatherproofed as outlined in
the RedMAX Base Station Installation Guidelines
3-13
Working with Service Classes, Service Flows and Classifiers
The MAC layer at the sector controller is responsible for allocating bandwidth to all users,
in both the uplink and the downlink. For the downlink, the sector controller can allocate
bandwidth to each subscriber unit, based on the needs of the incoming traffic, without
involving the subscriber unit. For the uplink, allocations are based on requests from the
subscriber unit.
The 802.16 MAC describes a number of Convergence Sub-layers (CS) which describe
how wireline technologies such as Ethernet, ATM and IP are encapsulated for transport
over the air interface, and how data is classified, etc.
Service Classes allow you to define the parameters of various service flows in order to
create a template that can be easily re-used when provisioning new subscriber units. The
service class is implemented at the sector controller and is associated with services flows
that will deliver data at the specified QoS.
Service Flows are a MAC transport service that provides uni-directional transport to uplink
packets sent from the subscriber unit to the sector controller or downlink packets from the
sector controller to the subscriber unit. A service flow is characterized by a set of QoS
parameters, including details of the subscriber unit requests for uplink bandwidth
allocations and the expected behaviour of the sector controller uplink scheduler.
Each service flow is specified by classifiers that are interpreted by the sector controller.
Classifiers defines how upstream flows are scheduled.
Service flows provide the ability to set up multiple uplink and downlink connections from
the sector controller to each subscriber unit. Each service flow may be assigned a
classifier that provides a unique service level category and QoS settings. A service flow is
not fully activated until at least one classifier is assigned to the service flow.
Typically you will define one or more uplink and downlink service flows for type of service
you are offering. You will then assign these service flows to subscriber units as they are
provisioned. When creating and assigning your service flows, you must keep in mind,
maximum number of both service flows and classifiers that are supported for each sector
controller.
Antenna connection Check all of the connections under the antenna for corrosion
or moisture damage. Replace any damaged connections and
weatherproof all connections as outlined in the RedMAX
Base Station Installation Guidelines
Obstruction of sky view Remove any obstruction or move the antenna mast location
to allow for an un-obstructed view of the sky. Refer to the
Redline GPS Clock User Manual for details on antenna
placement.
Table 3-2 Troubleshooting Antenna Problems
Possible Cause Investigative/Corrective Action
3-14
:
The service flow limit is defined by the subscriber unit. The subscriber unit communicates
its capabilities (ed uplink and dowlink connection IDs) to the sector controller when it
registers. If you provision more service flows than the subscriber unit can manage, the
sector controller will log an error message indicating, : SFID too many
Proper classifiers need to be defined for all service flows. Additionally, the priority value on
each classifiers must be set correctly.
Note The pass-all classifier is intended for point-to-point links only. Do not assign
pass-all classifier to subscriber units.
If a pass-all classifier is mistakenly applied to a service flow, you should see the following
message in the event log: "NOTICE: Pass-All Classifier has been Created for SFID nn".
All the downlink classifiers (including pass-all) had the same priority zero. In this case the
traffic was either classified correctly for some subscribers or forwarded to SF15 depending
on service flow creation order. This is why some subscribers worked fine while the others
were not getting their downlink traffic. When you started to change the classifier priority for
each service flow then classification started to work for those service flows.
Refer to the RedMAX AN100U/UX Base Station User Guide for instructions on creating
services classes, service flows and classifiers.
Checking RF and PHY Parameters
When you install a new radio it will be necessary to check the RF and PHY parameters and
update your system when a new radio is connected to an AN100U/UX, and it is of a
different frequency range than previously configured. For example a 3.4-3.6GHz radio is
connected to an AN100U/UX previously configured to use a 3.6-3.8GHz radio.
page 2-4.
Table 3-3 Maximum Values for AN100U/UX
Description Max. Number
The maximum number of subscribers. 512
The maximum number of downlink data service flows, including the default. 512
The maximum number of default uplink service flows (one per subscriber unit). 512
The maximum number of uplink data service flows. 512
The maximum number of downlink classifiers. 4096
The maximum number of learned MAC destination addresses. 16383
3-15
Step 2 From the Main menu select Interface Configuration > Wireless Interface.
The Wireless Interface Configuration page is displayed. You can review this page to
view RF, PHY and MAC settings for the sector controller.
Step 3 Update the parameters to match the installed radio. Refer to the RedMAX AN100U/UX
Base Station User Guide for detailed information on setting these parameters.
Step 4 Reboot the sector controller in order for your changes to take effect. See Rebooting the
Devices on page 3-2.
Step 5 Once the device has completed the reboot operation, select Interface Configuration >
Wireless Interface and verify that your changes have taken effect.
Step 6 Click the Enable RF button to re-enable the RF interface.
AN100U/UX CLI
Step 2 Review the existing wireless configuration:
monitoring mode.
Step 4 Update the parameters to match the installed radio. Refer to the RedMAX AN100U/UX
Base Station User Guide for detailed information on determining the values and setting
these parameters in the CLI.
Step 5 Reboot the sector controller in order for your changes to take effect. See Rebooting the
Devices on page 3-2.
Step 6 Once the device has completed the reboot operation, review the wireless configuration to
verify that your changes have taken effect:
3-16
4-1
4
Outdoor Equipment
Maintenance
This chapter provides basic information on maintenance of your outdoor equipment. Both
the radio and antenna are weather-proof assemblies that require no maintenance. The
units are sealed and cannot be opened.
The only required maintenance for these devices is routine inspection and replacement of
the weatherproofing materials used to seal connections.
Radio Maintenance
There are no user-replaceable components on the RedMAX radio. If you suspect the radio
is defective it must be replaced and returned to Redline.
Replacing a Radio
If this task will be performed aloft, it will be necessary to arrange for the assistance of a
tower climber or rigger. It will likely be necessary to make these arrangements well in
advance and schedule this work within a maintenance window. See Planning/Scheduling
Equipment Maintenance on page 2-14.
The following procedure requires two people. The first person should be at the indoor unit,
able to disconnect and reconnect the power supply to the indoor unit; the second person
should be at the radio. Detailed diagrams are provided in the RedMAX Base Station
Installation Guidelines.
If you have determined that the radio needs to be replaced, use the following procedure.
Ensure you have the correct replacement radio before starting.
.
Table 4-1 Replacement Radios
Part Number Description
23-00076-00 Assembly, High Power Base Station Transceiver Radio, AN100UX HTB3436
23-00076-01 Assembly, High Power Base Station Transceiver Radio, Die Cast, HTB3436
4-2
Outdoor Procedure
Step 1 Power off the AN100U/UX sector controller. Disconnect the device from the AC or DC
supply. This step needs to be at the indoor unit.
Step 2 Remove the weather proofing material from the RF and IF connections. Use your fingers
to remove the putty and then unwind the splicing tape.
Note Do not use a knife to cut away the materials as you may damage the cables.
Step 3 Disconnect the short RF cable from the radio. This connector should be just slightly past
finger-tight. Use caution and avoid excessive twisting force that may damage the
connector on the antenna or radio. Use the torque wrench.
Step 4 Disconnect the IF cable from the radio. As with the RF cable, avoid excessive twisting
force that may damage the connector on the radio. Use the torque wrench.
Step 5 Disconnect the radio from the earth ground connections.
Step 6 Remove the 4 mounting screws securing the HTB radio to the mounting bracket. If you are
replacing a TB radio, there are only two mounting screws. If the screws are damaged or
corroded in anyway, use care not to strip the head of the screw.
Step 7 Remove the old radio from the installation.
Step 8 Mount the new radio to the bracket. If the screws were damaged or corroded, then replace
the screws, washers and lock washers with new ones. Do not tighten the screws at this
point.
Step 9 Connect the short RF cable between the transceiver and the antenna. Ensure that the
cable drops downward to assist water runoff. The connectors must be finger-tight plus
1/8th turn only. For N-type connections torque=135 N-cm (12 lb-in). Excessive force may
damage the connector at the antenna or radio.
Step 10 Connect the transceiver and mounting bracket to earth ground using the grounding
connections provided.
Step 11 Connect the IF cable between the indoor unit and the radio. The connectors must be
finger-tight plus 1/8th turn only. For F-type connections torque=165 N-cm (15 lb-in). As
above, excessive force may damage the connector.
23-00060-02 Assembly, TB3436F7 Base Station Transceiver
Table 4-1 Replacement Radios (continued)
Part Number Description
4-3
Chapter 4 Outdoor Equipment Maintenance
Indoor Procedure
Step 1 Power up the system. Log into the Web interface.
Step 2 From the Main menu, select Monitoring > Status. Record the values or perform a screen
capture of the selected screen and save the file in a maintenance directory.
Step 3 Ensure the values are within 5% of the optimum values as defined in Table 2-5 on
page 2-16.
Step 5 Record the values or perform a screen capture of the selected screen and save the file
accordingly.
Step 6 Again, ensure the values are close to the optimum values as defined in Table 2-7 on
page 2-17.
Step 7 Once you have verified that the new radio is installed correctly, power off the indoor unit
and continue with the replacement procedure.
Completion of the Outdoor Procedure
Step 1 Tighten the screws on the mounting bracket, securing the radio to the bracket.
Step 2 Weather proof the IF and RF connections as outlined in the RedMAX Base Station
Installation Guidelines.
Step 3 Secure any loose cables with cable ties.
Step 4 Ensure all connections are labeled clearly for ease of later identification.
Completion of the Indoor Procedure
Power up the system. Log into the Web interface and record a second set of status and
interface measurements. Print copies of the pages and ensure they are clearly dated and
contain the name, serial number and MAC address of the device from which they were
obtained. These pages should be added to your maintenance records.
Antenna Maintenance
As with the radio, there are no user-replaceable components on the RedMAX antennas. If
you suspect the antenna is defective it must be replaced and returned to Redline.
Antenna Positioning
The positioning of your antenna dictates the general direction of your transmission. The
following suggestions are not intended to be definitive, since, as with all radio
transmission, many additional factors can affect the actual direction of the radiated
4-4
signal.Traditionally, the position of the antenna is the first step in the network design. Each
antenna in the network can be described by its parameters which should include antenna
type, coordinates, height, azimuth, tilt, transmission power, maximum capacity, etc.
Currently, the process of locating antennas involves the simulation of a few scenarios and
makes incremental adjustments until an acceptable position is found. Once the antenna is
installed, you will again make incremental adjustments until you achieve optimum
performance.
Inspect and Record Azimuth and Down-Tilt Adjustments. You will need an inclinometer and
a specialized compass is required for this task.
Adjust the direction and pitch angle of the antenna every 4-6 months. Again, an
inclinometer and a specialized compass is required for this task.
Replacing the Antenna
If you have determined that your antenna is faulty replace it using the following procedure.
Record all of the required information on the exact position of the antenna before you
remove the disabled part.
Note It is imperative to maintain the exact antenna position when replacing a defective
part.
If you have determined that the antenna needs to be replaced, use the following
procedure. Ensure you have the correct replacement radio before starting.
Contact support@redlinecommunications.com doe details on obtaining a replacement
antenna.
Outdoor Procedure
Step 1 Power off the AN100U/UX sector controller. Disconnect the device from the AC or DC
supply. This step needs to be performed at the indoor unit.
Step 2 Remove the weather proofing material from the RF connection on the antenna. Use your
fingers to remove the putty and then unwind the splicing tape. Do not use a knife to cut
away the materials as you may damage the cable.
Step 3 Disconnect the short RF cable from the antenna. This connector should be just slightly past
finger-tight. Use caution and avoid excessive twisting force that may damage the
connector on the antenna or radio. Use a torque wrench.
Step 4 If you have any filters installed, they must be removed from the antenna as well. This will
be defined in your frequency plan.
Step 5 Disconnect the antenna from the earth ground connections. Does the antenna need to be
grounded separately from the radio?
4-5
Step 6 Remove the mounting screws securing the antenna to the mounting bracket. If the screws
are damaged or corroded in anyway, use care not to strip the head of the screw.
Step 7 Remove the old antenna from the bracket.
Step 8 Mount the new antenna to the bracket. If the screws were damaged or corroded, then
replace the screws, washers and lock washers with new ones. Do not tighten the screws
at this point.
Step 9 Connect the short RF cable to the antenna. Ensure that the cable drops downward to assist
water runoff. The connectors must be finger-tight plus 1/8th turn only. For N-type
connections torque=135 N-cm (12 lb-in). Excessive force may damage the connector at
the antenna or radio.
Step 10 If you are using filters on the RF cable, replace the filters.
Step 11 Connect the antenna and mounting bracket to earth ground using the grounding
connections provided.
Indoor Procedure
Step 2 From the Main menu, select Monitoring > Status. Record the values or perform a screen
capture of the selected screen and save the file in a maintenance directory.
Step 3 Ensure the values are within 5% of the optimum values as defined in Table 2-5 on
page 2-16.
Step 5 Record the values or perform a screen capture of the selected screen and save the file
accordingly.
Step 6 Again, ensure the values are close to the optimum values as defined in Table 2-7 on
page 2-17.
Step 7 Once you have verified that the new radio is installed correctly, power off the indoor unit
and continue with the replacement procedure.
Completion of the Outdoor Procedure
Step 1 Tighten the screws on the mounting bracket, securing the radio to the bracket.
Step 2 Weather proof the RF connections as outlined in the RedMAX Base Station Installation
Guidelines.
Step 3 Secure any loose cables with cable tie.
Step 4 Ensure all connections are labeled clearly for ease of later identification.
4-6
Completion of the Indoor Procedure
Power up the system. Log into the Web interface and record a second set of status and
interface measurements. Print copies of the pages and ensure they are clearly dated and
contain the name, serial number and MAC address of the device from which they were
obtained. These pages should be added to your maintenance records.
Verifying Power and RF Signal Cabling
Cable testing is required to detect imperfections or damage that may cause reflection of
incident energy throughout the length of the cable. The detection should also include
Distance-to-Fault (DTF) measurements to accurately determine the location of the cable
fault. Damage along a cable length can take the form of a small dent or a change in the
diameter of the cable that occurred in transport or during installation.
Imperfections in the cable may often be caused during the manufacturing process. Cables
may also contain one or more discrete faults, due to a bent or damaged cable,
contaminated dielectric, a poor cut or a bad connector, for example.
Whatever the cause of the damage or imperfection, the resulting defect may cause signal
reflections. The reflections from the individual imperfections may add up to the point that
that they can be measured as cable loss or return loss. With periodic faults the energy
reflected can appear in the loss measurement as a reflection spike at a frequency
corresponding to the spacing of the imperfections, where the spacing between the periodic
imperfections is one half of the wavelength at the frequency of the reflection spike.
Cable testing techniques include loss measurements (return loss, insertion loss) and
transmission measurements (e.g., VSWR). Return loss measurements are expressed in
dB with 0 dB being recorded when measuring an open or short circuit, and typically 40 to
60 dB being displayed when measuring a load condition with proper impedance matching.
With transmission tests, the transmitted and reflected signals combine to create a standing
wave. The voltages of the peaks and troughs of the standing wave are measured and
expressed in terms of the voltage standing wave ratio (VSWR).With no reflections, i.e., a
perfect transmission system, the VSWR is unity. With higher reflections the VSWR will
increase to the point where the reflections become unacceptable.
Interface (IF) Cable
The interface cable connecting the IDU to the ODU is a critical component of your system.
The cable quality and loss profile have a significant impact on the performance of the
wireless link. If you opt to purchase this cable separately, the cable must be of an approved
type and be assembled using the recommended connectors. Refer to the RedMAX Base
Station Installation Guidelines for a list of approved cables that can be used for this
purpose.
4-7
The IF cable path should also be checked, to ensure it's not being shared with any other
cables (example AC power cables), as these can cause interference to the communication
between the radio and the IDU. If possible the IF cables should be separately routed and
shielded from any source of interference along its path between the ODU and IDU.
If you are replacing this cable, you should characterize the loss profile before using the
assembled cable in your system.
Annually you should re-characterize the loss profile of the cable and record the results in
your maintenance records. A network analyzer is required for this task.
RF Cable
Inspecting the Complete RF System
The quality of service (QoS) that you can provide is largely dependent on the performance
of the antenna and cables connecting your radio to the antenna and to the sector controller
indoor unit.
Before any useful maintenance can be performed it is essential to know how your system
is supposed to operate and also to know the licensed operating parameters. Your installers
need to verify the performance of the IF and RF cables and antenna before installation and
then again immediately after installing and commissioning a system. All performance
values should be recorded and used as a reference point when performing routine
maintenance.
To ensure continued high quality performance a regular maintenance policy should be
implemented. Factors such as corroded connectors, bends and joints, water ingress into
the coaxial feeder and a detuned antenna can all degrade the system performance.
In the case of a directional antenna many factors such as current, phase, self and mutual
impedance, monitoring system and transmission lines can interact to impact performance
and affect a service area.
Regular maintenance must include the inspection of all connections and connectors in all
circuits, tower-mounted antenna monitor loops, or current transformers at the output of the
tee-matching network in the ATU. Lighting circuits and photo-electric controls must be
checked and tested as well as pattern change contacts and control circuits.
Inspecting Outdoor Equipment
Perform the following inspection for your outdoor equipment installation.
Step 1 Ensure the ODU and antenna serial number's match your site's bill of materials or packing
list. Record all of the serial numbers.
Step 2 Ensure the tower or mast is stable and secured correctly.
Step 3 Ensure the antenna elevation and physical tilt match the values in your Network Design
and Cell Planning documents. Record these values.
4-8
Step 4 Ensure the antenna polarization matches the polarization in the Network Design and Cell
Planning documents. Record the polarization values for each sector controller.
Step 5 Ensure the antenna azimuth (bearing) matches the value in your Network Design and Cell
Planning documents. Record the bearings for each antenna.
Step 6 Ensure the antenna and bracket nuts, bolts and washers and lock washers are in place
and secured.
Step 7 Ensure the interface (IF) cable is securely connected to the radio.
Step 8 Ensure the IF cable is tightened correctly and completely weatherproofed. Mastic putty
completely covers the gap between the connection and the ODU. Refer to the RedMAX
Base Station Installation Guidelines for reference diagrams.
Step 9 Ensure co-located sector antennas are separated in accordance with the minimum
distances indicated in the RedMAX Base Station Installation Guidelines.
Step 10 Ensure the RF cable is securely connected to the radio and the connection has been
completely weatherproofed. Splicing tape covers the N-Type connection and extends
along the cable.
Step 11 Ensure the Polyphaser IF lightning arrestor is installed on the antenna mounting bracket.
Step 12 Ensure the second Polyphaser IF lightning arrestor is installed at the point of entry to the
building.
Step 13 Ensure the lightning protection (rods and/or wires) is installed and secured at ground level.
Step 14 Ensure the data and management cables are securely connected.
Step 15 Ensure all cables/wiring are labeled clearly at both ends with relevant connection
information. This is imperative for ease of troubleshooting and reducing system downtime.
Step 16 Ensure the RG-58 cables are bundled and formed correctly for multi-sector deployments.
Step 17 Ensure all cables are correctly shielded. There are no cuts or abrasions in the exterior
shielding.
Step 18 Ensure all cables are securely fastened to the brackets or masts and cable ties are cut
flush.
Step 19 Ensure all cables are protected from sharp edges and abrasive surfaces to avoid possible
damage, as required.
AC or DC Power Cabling
Main and redundant (RPS) power cords are securely connected and labeled clearly at both
ends, for the IDU.
Step 1 Using a multi-meter measure and record the power voltage at the end of power cord.
Record the results for each sector controller.
4-9
Performing a Spectrum Sweep
The proper operation of your RedMAX network requires clear and stable operating
conditions within the RF spectrum in all of your sectors. It is a good idea to verify the RF
spectrum during the site selection, again during the deployment phase to guarantee the
spectrum conditions of the network and again on a routine maintenance schedule for
optimization or potential system troubleshooting.
Basic spectrum sweep measurements can be made in the 3.5 GHz band with the use of
an external spectrum analyzer.
In order to discard the influence of external sources of interference in a particular network,
you should conduct these spectrum sweeps at the sector controller antenna port and under
the following two conditions for comparative analysis on interference suppression between
the same system cells:
Under no influence of the same system frequencies used in the area (all sector
controllers should be off.
Under the regular operation conditions of the system (all sector controllers are on).
Since the system needs to be powered off for part of this test, you should take these
measurements during a scheduled maintenance window.
The following procedure and analysis techniques can be used to identify potential sources
of RF interference. This procedure should have been conducted prior to commissioning
the site and can be performed periodically to verify the results.
Detailed instructions on performing a spectrum sweep are provided in the Guide to Field
Spectral Analysis. This document is available on the Redline partner Web site or you can
contact support@redlinecommunications.com.
Sources of Potential Interference
If you have encountered interference in your spectrum scan, the following sources may be
causing the interference:
Newly deployed sector controllers that have not yet been optimized for prospective
frequency or antenna alignment.
Sector controllers that have not been optimized for prospective frequency or antenna
alignment from a competitors network.
Poorly implemented major frequency design resulting in interference.
Poorly implemented major frequency design resulting in interference from a
competitors network.
Unregistered RF equipment within or near your sector.
Before taking any action you will need to further analyze the nature of the interference.
Is it constant in time?
Does it interfere at all times or only at a specific times and days
4-10
Does it have a repetitive pattern?
Is it sporadic without any relation to a specific channel
Inspect and Repair Lightning Protection System
Ground Connections
A good ground connection is one that has a low resistance to the Earth at radio
frequencies. A ground connection that is good enough for DC or low frequency power lines
(60 Hz) is not necessarily a good ground at radio frequencies.
Figure 4-1shows the most basic form of a radio antenna ground connection. A conductive
ground rod is driven into the Earth for a certain distance. A proper radio ground for high
frequency (HF) band operations should be 8-feet long. Anything less than that usually
results in poor performance, and may not provide proper lightning protection.
Figure 4-1 Radio Antenna Ground Connection
Some ground rods are made of copper, but most are made of copper-clad steel. Such rods
are composed of a steel core with a thin layer of copper on the outer surface. The
low-resistance copper is sufficient for grounding purposes because RF currents flow on the
outside of a conductor (a phenomenon called skin effect).
The ground rod in driven into the Earth within a few inches of its top, and then a wire clamp
is fastened. This clamp is used to hold the ground wire securely to the ground rod.
4-11
Components of Your Lightning Protection System
The purpose of your lightning protection systems is to re-direct a lightning strike a
preferential path to the ground. A typical lightning protection system has five major
components: strike termination, down conductor, grounding, ground reference and surge
suppression subsystem.
Strike TerminationStrike terminations are objects that intercept the lightning strike.
Commonly, pointed metal rods are used for this purpose and are called air terminals
or lightning rods. Strike terminations can also take the form of overhead wires or
structural components of buildings. Strike terminations only influence the path of
lightning through the air at very close ranges (approximately twenty feet).
Note These termination objects do not attract lightening. If a strike termination on your
building is hit, it likely would have bit by lightening regardless of whether strike
terminations were present.
Down ConductorsThis is an electrical path of low impedance that connects the strike
termination subsystem to the grounding subsystem. Commonly, these are wires but a
buildings steel-frame structural components can also be used.
GroundingThe grounding subsystem sinks the lightning current into the earth.
Commonly, the grounding subsystem consists of ground rods, copper or steel rods
driven into the earth. The key parameter for the grounding system is low impedance.
The impedance of the grounding system is the total of the overall impedance of the
lightning protection system, so a high impedance grounding system can increase the
chance of flashover resulting in other damaging effects.
Ground Reference (including bonding)The ground reference subsystem and
electrical bonding is often the most elusive portion of a lightning protection system.
This subsystem electrically bonds all other electrical grounds and metal parts that may
provide an alternate ground path in a structure to your lightning protection system.
Despite the need for bonding, designers have to be careful not to install bonding that
provides an incidental ground path through sensitive electronics - a common oversight.
The CADWELD process is a method of making electrical connections of copper to
copper or copper to steel. CADWELD connections can be used to make grounding
connections for RedMAX outdoor equipment.
Crimped or bolted connections cannot be inspected visually, but CADWELD
connections can be visually inspected and such an inspection provides an indication
of the quality of the weld. Refer to the Installers and Inspectors Guide for CADWELD
Electrical Connections for detailed information and a visual reference of acceptable
welds.
Surge SuppressionOnce the building has physical lightning protection, protection
from the indirect effects of a lightening strike is essential, especially if sensitive
electronics are involved. Surge suppressors should be installed on the main data and
power entries and several devices should be installed inline to protect the sensitive
electronic equipment.
4-12
Note Surge suppression devices installed in the plug-in power bars are ineffective
against any significant lightning strike.
in order to ensure that lightning protection systems are designed and installed in
compliance with local safety standards, these systems must installed by experienced
contractors that specialize in lightning protection.
Verifying Your Lightning Protection System
Note Like other types of electrical connections, a visual inspection does not guarantee
of performance.
You will need to inspect the following connections. If any of connections are rejected, they
need to be removed and replaced.
Step 1 Verify and record the location of the grounding source.
Step 2 Verify that the lightning protectors, the antenna-mounting bracket, the antenna and the
radio all have a direct connection to the same ground point.
Step 3 Verify that only the shield of the IF cable is bonded to the grounding points.
Step 4 Verify that there are no sharp bends in the ground wires.
Step 5 Verify that the IDU is grounded by connecting the grounding cable from the grounding
screw on the rear of the terminal to the building ground point.
Inspecting and Re-Applying Weatherproofing on Outdoor
Connections
Many antenna problems are caused by coaxial cable connections that loosen due to
vibration, or degrade over time allowing moisture to penetrate and corrode the connector
interface.
On an annual basis, you should remove and re-apply weatherproofing on the ODU
connections. The exact period will depend on your outdoor environment and the location
of your ODU.
Step 1 Visually inspect the connections and look for signs of wear, such as cracking, fading or
shrinkage.
Step 2 Use your fingers to remove the existing weatherproofing. Do not use a knife or any other
sharp tools around the cable as this may result in damage to the cable.
Step 3 Clean the area around the connection to ensure proper adhesion of the new weather
proofing materials.
4-13
Step 4 Ensure the connections as still tight. If necessary, loosen the connections and ensure they
clean and dry at both ends before re-connecting and tightening to the correct torque
setting.
For N-type connections torque=135 N-cm (12 lb-in).
For F-type connections torque: 165 N-cm (15 lb-in).
Step 5 Test the connections by powering up the system and ensuring the signal values are the
same as before.
Step 6 Apply the weatherproofing materials as outlined in the RedMAX Base Station Installation
Guidelines.
Step 7 When applying tape, wrap from the bottom up, or if you are working on a horizontal
connection, wrap from the smaller diameter to the larger. Overlap each turn by 1/2. Stretch
the tape slightly for most of the wrappings, reducing the tension near the last few turns.
Apply the last wrap of tape with no tension to prevent flagging. Cut the tape end - do not
pull when cutting the tape. Compress the wrappings with both hands to insure complete
contact with all layers of tape.
Testing to Validate Repair
In order to verify that repairs and/or maintenance have been performed correctly and that
your network has been returned to optimum performance you can perform some basic
system tests.
Ideally you should establish a reference system that consists of one or two subscriber units
located at fixed locations at the farthest points within the sector or at a location that is
typically difficult to cover.
You should measure and record a set of interface readings when your system is first
installed and then use these values as a reference whenever any changes/upgrades are
made to your network.
Step 2 From the Main menu, select Monitoring > Status.
the file in a maintenance directory.
Step 4 Ensure the values are within 5% of the optimum values. The optimum values will likely be
from the time of the initial installation.
the file accordingly.
Step 7 Again, ensure the values are within 5% of the optimum values. The optimum values will
likely be from the time of the initial installation.
4-14
Step 8 Print copies of the pages and ensure they are clearly dated and contain the name, serial
number and MAC address of the device from which they were obtained. These pages
should be added to your maintenance log.
In order to perform these tests, you need to configure a test system on which you can
easily quantify the sector controller performance.
5-1
5
AN100U/UX Troubleshooting
Overview
This chapter provides some basic troubleshooting techniques for resolving issues that you
may encounter while using the RedMAX equipment. The information, provided here, is
organized with basic hardware issues listed first, followed by issues related to Ethernet
and serial communications, management connectivity, wireless links and finally data flow.
If after completing the steps detailed in this document you are still unable to resolve your
issue, you should open a ticket at support@redlinecommunications.com. If the issue is
considered "Major" or "Critical", you need to fill out the document entitled "RedMAX
Major-Critical Ticket Requirements" prior to contacting Redline Technical Support. This
document is available on the Redline Partner Web Site, located at
http://partners.redlinecommunications.com.
The flow charts on the following pages will help you identify a probable and resolution
cause for many general issues.
5-2
Figure 5-1 Troubleshooting Flow Chart
5-3
Chapter 5 AN100U/UX Troubleshooting
Figure 5-2 Troubleshooting Flow Chart
5-4
Troubleshooting RedMAX Boot Issues
This section covers troubleshooting procedures for various hardware and software issues
which may affect the startup of the your RedMAX sector controllers.
AN100U/UX Does Not Power-up
The first step in troubleshooting power-up issues is to inspect the power source and all
related connections.
Verify that your AC and/or DC power supplies are able to meet the power demands for your
network configuration. Refer to the RedMAX Base Station Installation Guidelines foe
details of the power supply requirements.
AC Powered Devices
Step 1 If the unit has an AC power supply, check that the power cord is securely connected to both
the device and to the power bar or wall outlet.
Step 2 Verify that power cord is not the source of the failure, by replacing the existing cord with
another cord that you know is working. If the device is restarts and there are no issues,
then mark the defective power cord and discard it.
Step 3 If you are using a power bar, ensure the power cord is connected and that the power bar
is on.
Verify that the power bar is not the source of the failure, by connecting a different device
(your desk light, for example) to the same power bar port to which the AN100U/UX was
initially connected.
If your power bar has a fuse, ensure the fuse has not been blown. If the fuse has been
blown, disconnect all of the devices and reset the fuse. Add devices one at a time to ensure
the fuse does not blow again. If your power load exceeds the capacity of the power bar or
the outlet, you may need to use another power bar or split the electrical load over two
separate circuits.
Step 4 Check the power outlet. Ensure the power bar or the device cord is securely connected to
the power outlet.
Verify that the power outlet is not the source of the failure, by connecting a different device
(your desk light, for example) to the same power bar port to which the AN100U/UX was
initially connected.
Step 5 Ensure that you have not blown a fuse or breaker. The same considerations apply to the
power outlet as listed above for the power bar: disconnect all of the devices and reset the
fuse. Add devices one at a time to ensure the fuse does not blow again.
Use caution when connecting power-intensive devices such as air conditioners, heaters,
motors to your indoor circuits. To avoid power issues refer to the plans for your indoor
facility to ensure the existing circuits can support the required electrical load. It may
necessary to rewire some circuits in order to distribute the load effectively.
5-5
DC Powered Devices
If the unit is DC powered, then there is no power switch on the device. Once the D/C power
cord is connected and power is available, the device should start its boot procedure
immediately.
Step 1 If your DC powered device does not start as expected, check the power cord, as indicated
above for the AC devices.
Step 2 A common issue with the D/C powered devices is that the black and blue wires are
connected incorrectly to the power source. This results in a reversal of polarity. If this is
the case the unit will not power on, and will, hopefully not be permanently damaged.
RedMAX equipment contains a diode-protection circuit built into the power sub-system
that should prevent permanent damage.
In the specific case of the AN100U/UX, to properly connect these wires to the power
source, you need to understand that the DC power input is floating. This allows for positive,
negative or floating power connections. A floating power connection is a power-supply that
has no direct connection to a local ground reference:
When connected to a DC power supply providing negative D/C voltage, the black cable
should be connected to the power return, and the blue cable to the negative voltage.
When connected to a DC power supply providing positive D/C power, the black cable
should be connected to the positive voltage, and the blue cable to the power return.
In other words, the black cable should always be connected to the point of the higher
potential.
Step 3 If the DC power cord is properly connected to the power source, and the unit still does not
start, you need to verify the maximum amount of current that your power source can
deliver.
The AN100U/UX can draw up to 4 A of rush-in current. Rush-in current is required during
the first half-second while the unit is powering up and it depends on the voltage provided
by the power source. The higher the voltage, the lower the rush-in current that is required.
Step 4 Both of the AC and DC versions of the AN100U/UX have a fuse in each of their power
supply units which protects the system from current overloads.
After eliminating the above-listed sources of failure, you need to verify that these fuses are
intact and if not replace them as necessary. If these fuses have been blown, then you will
need to determine the cause.
Step 5 Verify that the AN100U/UX IDU is connected to the correct connector on the ODU. Both
the IF and RF ports on the AN100U/UX radio are female N-type, so it is possible to connect
the IF cable to the RF port or vice versa.
If you connect the ODU RF port to the IF cable and port on the IDU, the IDU will not power
up. There is a component in the transmission line, at the entrance of the RF port that
protects the radio from a power surge. When the IDU is connected to the RF port, this
transmission line (cable) acts as a short, causing the IDU power supply to enter its own
protected mode, since the 24 V power supply is now essentially connected to ground.
5-6
Subscriber Unit Does Not Power-up
If you are having power up issues with your subscriber unit, verify power connections as
indicated above for the sector controller.
Also verify that the subscriber unit is connected to the Power & Data Out port of the indoor
power injector, and that the local network device is connected to the Data In port.
AN100U/UX Occasionally Reboots
Internal Device Issue
In this case troubleshooting your device is more difficult as the reboot may appear to occur
randomly. The most likely cause of an occasional reboot is a hardware fault.
Step 1 Check the event log as outlined in Monitoring System Event Logs on page 2-6. Look for
any unusual messages such as "P1 Watchdog reset.
Step 2 If you observe any such messages you need to capture the event log for further
investigation. See Monitoring System Event Logs on page 2-6 for instructions on
capturing the contents of the event log to a file.
When the device does reboot, you can now review the logged event information prior to
the reboot for an indication of the cause.
It is also possible that the device will provide a reason for the reboot during its boot
sequence.
External Power Source
Occasional reboots may also be caused by fluctuations in the power supply. Possible
external causes should be investigated, such as the quality of the external power source.
Step 1 Monitor and record your supply line voltage. If a device reboot corresponds to fluctuations
in the supply, you will need to resolve the power supply issue.
Step 2 If the system reboots without providing an error message and the power supply remains
consistent, you should try swapping out one component at the time in order to isolate the
cause.
Note IDU power supplies are not field-swappable.
AN100U/UX Fault LED is Blinking
The blinking fault LED generally means that one of the AN100U/UXs power supplies is
faulty or not connected properly.
5-7
Check the event log to determine which of the power supplies is causing the fault. See
Monitoring System Event Logs on page 2-6
Follow the steps listed above, in AC Powered Devices on page 5-4 to ensure that the
power cables are connected properly and that the power bar or power outlet is not
defective.
Note The AN100U/UX power supplies are not user-serviceable. If the power supply is the
cause of the fault, you must return the AN100U/UX to Redline for
repair/replacement.
Inrush Current at Startup
You may see a the message Invalid Radio Type in the event log, even though both the
radio and the IDU are correct and have been installed correctly. If you are unsure whether
your radio is compatible with your AN100U/UX, please contact
support@redlinecommunications.com for a list of ODU devices supported by your IDU.
Also verify that connections between the IDU and the ODU are correct and that all
connectors and cables are in good repair. See Replacing a Radio on page 4-1.
When the DC source is powered up with the IDU connected, the radios power up
sequence results in an input surge current. If the power supply is not able to accommodate
this initial surge, it will interrupt the power supply to the IDU until this overload condition
stabilizes. The IDU, is then unable to accurately detect the radio.
Cold Restart of the AN100U/UX
If you encounter this message and are certain that the correct radio is installed, then you
need to perform a cold restart of the IDU as follows:
Step 1 Power down the IDU and disconnect it from the power supply.
Step 2 Ensure the DC power supply is connected and is powered up.
Step 3 Wait for 30 seconds and then reconnect the IDU.
Step 4 The radio should be detected. If you still see the message then your power supply may not
be able to meet the power requirements at system startup. You will need to replace the
power supply.
AN100U/UX Power Requirements
To avoid this situation, you need to verify that your power supply is able to accommodate
the estimated inrush current values. This may require investigation as the inrush current
is dependent on many external factors, such as the number and type of devices connected
to the circuit.
5-8
Verify that your AC and/or DC power supplies are able to meet the power demands for your
network configuration. Refer to the RedMAX Base Station Installation Guidelines for
details of the power supply requirements.
Troubleshooting Ethernet Issues
Connectivity issue can be attributed to a number of things. Establishing basic Ethernet
connectivity it the first step. You will need to be familiar with your existing network
configuration and how Ethernet traffic is intended to pass, in order to troubleshoot these
issues.
Cross-over versus Straight-through Cables
Wired connections require that you use cable, rated Category 5 (Cat5) or better.
You can use either a cross-over or straight-through cable when connecting the
AN100U/UX to your computer or router, since the sector controller can auto-sense the
cable polarity.
The outdoor subscriber unit requires a straight-through cable when it is being connected
to a switch/hub, and a cross-over cable if it is being connected directly to a computer.
The appropriate power-over-Ethernet (PoE) cable must be used to connect the outdoor
subscriber units (SUO) to its power injector, located indoors. The connection at the outdoor
unit must be weather-proofed as outlined in the Outdoor Wireless Access Subscriber
Modem (SUO) Installation Guidelines.
A standard Category 5 Ethernet cable can be used to connect the power injector to the
network device.
Table 5-1 AN100U/UX Power Requirements
Main Input Voltage Range [V] Tolerance
(%)
Maximum Power
Consumption (W)
Maximum
Current (A)
Estimated Inrush
Current (A)
AN100U
100-240 VAC 10% 75 2 35
24-60 VDC 20% 75 6 40
AN100UX
100-240 VAC 10% 120 2 100
48-60 VDC 20% 120 5 70
48VDC; Aux. DC Input 5% 120 5 30
5-9
Figure 5-3 Subscriber Unit Ethernet Connections
Cannot Establish a Connection to the Management Port
The sector controller has two Ethernet ports, one for data and the other for management.
The management port is not used in the factory default settings; however once the sector
controller is installed and used within a network it must be configured so that it directs all
the management traffic through the management port.
Figure 5-4 shows a managed RedMAX network as an example of how management traffic
(DHCP in this case) is managed on a separate and secure path from the customers data
traffic.
5-10
Figure 5-4 Segregation of Management And Data Traffic
When the subscriber unit is installed, the wireless interface is configured for a specific
frequency and the remote management interface is enabled. As soon as the subscriber
unit achieves a successful wireless connection, the subscriber unit registers itself with the
sector controller and the secondary management channel (SMC), on the sector controller
is activated. The SMC is a segregated tunnel, accessed only by the trusted subscriber unit
management interface on the wireless interface.
Traffic entering the subscriber unit on the customer host side is insecure and cannot
access the SMC. Customer data traffic is only allowed to pass over the service flows and
can only exit from the sector controller data port.
If the AN100U/UX is configured for integrated management, then management will be
done inline via the data port. If the AN100U/UX is configured for management via the
management port then device management will be done out of band, via the management
port. It is important to note that traffic destined for the management interface of any
connected subscriber unit is considered management traffic, and must be sent across the
appropriate connection.
If the appropriate cables are used, and a connection to the AN100U/UX's management
port still cannot be established, it is possible that the AN100U/UX is configured for
integrated management (i.e via the data port). When configured in this way, the
AN100U/UX completely disables the Management port.
5-11
Configuring the AN100U/UX for Management via the Management Port
Configure the AN100U/UX for separated management, which will enable an Ethernet
connection with the management port.
page 2-4.
Step 2 From the Main menu select Interface Configuration > Ethernet.
The Ethernet Interface page is displayed. You can review this page to view the
configuration of the devices Ethernet interface.
Step 3 Check the value of Management. This parameter should be set to Via Mgt port, then
device management will be done out of band via the management port.
Step 4 Select Via Mgt port and click Save to make the changes and return to the main menu.
Duplex Mismatch
Duplex conflicts are a common source of performance degradation. This problem is easy
to correct but difficult to identify and localize.The issue may recur, as interfaces go up and
down over time and network elements are upgraded and replaced.
Ethernet devices with different speeds and duplex modes can exist on the same physical
network. Auto-negotiation is a protocol that allows two devices to agree on the highest
possible speed that both devices can support. Both devices advertise all of their supported
speed and duplex combinations and the highest, common set is selected and used by both
devices.
This only works if both devices support auto-negotiation. If only one device supports the
feature, and the other device has a fixed configuration, one device will recognize the speed
of the remote end, but it will not be able to recognize whether the remote end operates in
half or full duplex mode. It will, according to the standard, always assume half duplex
mode.
A typical error is to configure one side of the link for full duplex, and the other one for
auto-negotiation. This combination will result in a duplex mismatch, which causes a lot of
collisions and bad frames. The link will work, but the end-user will experience erratic
behavior, especially if their traffic is delay-sensitive. If you test the connection using the
ping utility, you may sometimes see no loss, while at other times you may see up to 60%
loss on a 100 Mbps path.
When collisions occur, the device that is configured for half-duplex mode will detect it, send
the "jamming signal", discard the received frame, and prepare its own packet for
re-transmission. The problem is that the device is configured for full-duplex mode ignores
the jamming signal, so the packets that it was sending are lost.
In the case of a duplex mismatch, you can expect to see many collisions reported on the
half-duplex side, and a lot of received error frames on the full-duplex side.
5-12
Configuring Duplex Mode for the AN100U/UX
Use the following procedure to set the speed and duplex mode for the sector controller.
page 2-4.
Step 2 From the Main menu select Interface Configuration > Ethernet.
The Ethernet Interface page is displayed. You can review this page to view the
configuration of the devices Ethernet interface.
Step 3 Check the value of Management. If this parameter is set to Via Mgt port, then device
management will be done out of band via the management port. If this parameter is set to
Via Data port, then management will be done inline via the data port
Step 4 Check the value of the Mgt Port Setting parameter and set this to the required speed and
duplex mode for the sector controller management port
.
Step 5 Click Save to make your changes and return to the main menu.
SUO CLI
Step 2 Enter the set command:
set
Step 3 Set the options for speed and duplex mode. Use the following command to enable
auto-negotiation:
set ethernet AutoNegEnabled 1
Step 4 If you do not want to use auto-negotiation, then enter the required speed and duplex mode.
See Table 5-3 for details of the available options.
set ethernet LinkSpeed 1 LinkDuplex 0
Table 5-2 Speed/Duplex Settings for the AN100U/UX Management Port
Speed Description
Auto Detect Auto-negotiate the speed and duplex mode with the subscriber unit.
10 Mbps Half Duplex Operate at 10Base-T and half duplex mode only.
10 Mbps Full Duplex Operate at 10Base-T and full duplex mode only. When using this setting
the subscriber unit must be set accordingly.
100 Mbps Half Duplex Operate at 100Base-T and half duplex mode only.
100 Mbps Full Duplex Operate at 100Base-T and full duplex mode only. When using this
setting the subscriber unit must be set accordingly.
5-13
Step 5 Ensure the subscriber unit is configured for remote management. See Table 5-3 for details
of the available options
Step 6 Enter Ctrl-Z to return to the root mode.
Refer to the RedMAX Outdoor Wireless Access Subscriber Modem (SUO) User Guide for
detailed information on using the CLI.
Troubleshooting Device Management Issues
Establishing a connection with the management interface of the RedMAX system is
essential to network productivity. Management of the sector controller can be done
primarily via the HTTP GUI (web client). Device connectivity is also available via Telnet,
Serial port, or SNMP. For larger networks, you should consider the Redline Management
Suite element management application.
Configuration of the subscriber unit is available only via a Telnet session.
Sector Controller Serial Communication Issues
As indicated previously, the most common problem is that you are using a straight-through
cable and require a cross-over connection.
Table 5-3 Speed/Duplex Settings for the SUO Management Port
Command Options
ethernet Use this setting to modify the Ethernet port auto-negotiation, link speed, and duplex
settings.
AutoNegEnabled <value>
Where a value of 0 corresponds to disabled and a value of 1 corresponds to
enabled.
LinkSpeed <value>
Where a value of 0 corresponds to 10Mbps and a value of 1 corresponds to
100Mbps.
LinkDuplex <value>
Where a value of 0 corresponds to Half Duplex and a value of 1 corresponds to
Full Duplex.
managedSS The managedSS command allows you to configure the subscriber unit for
independent operation, or enable management using the Redline Management
Suite (RMS). The managedSS parameter is controlled from root mode.
managed SS <value>
Where a value of 0 corresponds to Disable remote management and a value of 1
corresponds to Enable remote management.
5-14
The AN100U/UX has a DB-9 male connector for serial communications. The AN100U/UXs
serial port is configured as Data Terminal Equipment (DTE), so in order to connect it to your
computer, which also has a DTE serial port, you need to have a RS-232 crossover cable
(also known as null-modem cable).
In order to establish serial communication between your computer and the AN100U/UX,
the serial port on your computer must also be configured as follows:
::
Sector Controller IP Connectivity Issues
In this case, the AN100U/UX is running properly, but connectivity via IP to either the GUI,
Telnet, or SNMP interfaces cannot be established. Use the following troubleshooting
procedure to isolate the problem:
Step 1 Verify that your computer is connected directly to the Ethernet port of the RedMAX sector
controller in question.
If you cannot connect directly to the device, then you must properly configure the routing
necessary to establish communication between your computer and the sector controller
through your network.
If you can communicate with the device when it is directly connected to your computer, but
cannot connect when using your network connection, then you will know that routing is
likely the issue. Contact your network administrator for required routing information. A
detailed explanation of IP addressing is beyond the scope of this document.
Step 2 Verify that there are no routers between your computer and the AN100U/UX which are
filtering ICMP/HTTP traffic.
Table 5-4 AN100U/UX Serial Communication Configuration
Parameter Required Setting Description
Baud Rate 57,600 bps This is the data transfer rate. The receiver and the transmitter
must be set to the same baud rate.
Data Bits 8 Data Bits The number of bits of data sent after the start bit. The receiver
and the transmitter must be set to the same number of data
bits, as well as the baud rate.
Stop Bits 1 Stop Bit After the data has been transmitted, a stop bit is sent.
Typically the stop bit has a value of 1.
Parity No Parity A parity bit provides minor error checking, to detect data
corruption that might occur during transmission.
Flow Control No Flow Control. Flow control provides the ability to reduce the flow of data. For
serial ports this means the ability to stop and then restart the
data flow without any loss of bytes. This parameter is required
for modem communications
Terminal
Emulation:
VT-100 terminal. This is the type of terminal that your computer must emulate
in order to communicate with the sector controller.
5-15
Step 3 You can use a basic ping test to verify IP connectivity. See Using the Ping Utility on
page 2-10.
Step 4 Log into the serial interface as outlined in Sector Controller Serial Communication Issues
on page 5-13 and verify that the IP address configured for the AN100U/UX's management
interface is reachable based on your computer's routing table.
Step 5 Check the IP address of the AN100U/UX using the CLI by entering the following command:
show ipaddess
This will display the IP address of the selected device. Refer to the RedMAX AN100U/UX
Step 6 Check the IP address of the subscriber unit using the CLI by entering the following
command:
show ssInfo
Step 7 Verify that the computer is connected to the appropriate Ethernet port on the AN100U/UX.
If the device is configured for integrated management, connect the ethernet cable to the
Data port. If configured for separated management, connect the cable to the Management
port. See Configuring the AN100U/UX for Management via the Management Port on
page 5-11 for detailed information on determining how the device is managed.
Connectivity from Behind a Subscriber Unit
The AN100U/UX is inaccessible from behind any of its registered subscriber units, for
security purposes. If your computer is connected downstream of the AN100U/UX, you will
need to either move your computer upstream from the sector controller, or install a router
upstream of the AN100U/UX which will be able to route the management traffic from your
computer, regardless of its location, to the AN100U/UX.
Connectivity with Internet Explorer
If you are using Internet Explorer, and you find that it hangs or freezes occasionally when
you are connected to a sector controller, you can try running the application without
extensions.
Step 1 Open a the Windows Start Menu and select Run:
Start > Run
Step 2 Enter the following command
iexplore -extoff
Step 3 Alternatively, you can use Mozilla Firefox, available at www.getfirefox.com.
5-16
Subscriber Unit IP Communication Issues
Each subscriber unit has three available IP addresses as listed below:
Each of these three IP addresses must be used in a different subnet. If you do not separate
these IP addresses, there is a chance that the subscriber unit may be unable to determine
to which interface, packets should be sent. This could cause many problems, such as
DHCP/ToD timeouts, or loss of remote management connectivity.
Local Connectivity
If local connectivity (computer connected directly to the subscriber units Ethernet port)
cannot be established, you must verify the following:
Step 1 Verify that your computers IP address is in the same subnet as the subscriber units local
IP address. Attempt to ping the local IP address.
ping 192.168.101.2
Step 2 Configure your computer with an IP address in the 192.168.101.0/24 subnet (i.e.
192.168.101.10).
Step 3 Ping the subscriber unit from your computer.
ping 192.168.101.2
Table 5-5 Subscriber Unit IP Addresses
IP Address Description
192.168.101.1 This is the rescue IP address. It is always available, and is
non-configurable.
192.168.101.2 This is the local IP address. This address is only available when your
computer is connected directly to the subscriber unit. the default address
is 192.168.101.2.
You can change this address using the CLI set command. Refer to the
Outdoor Wireless Access Subscriber Modem User Manual for
detailed information on using the CLI.
Wireless Secondary
Management IP
When a subscriber unit is enabled for remote management
(managedSS=1), the IP address for the wireless secondary management
channel (SMC) can be assigned by:
DHCP request through the sector controller (acting as a DHCP relay
agent).
The operator assigning a static IP address using the smcIpAddress
command. Refer to the Outdoor Wireless Access Subscriber
Modem User Manual for detailed information on using the CLI.
There is no default value assigned for this IP address.
5-17
Step 4 Try to establish a telnet session with the subscriber unit.
a. Open a the Start Menu and select Run:
Start > Run
b. Enter the following command
telnet 192.168.101.2
Step 5 If this works, it is likely that there is a mis-configuration of the local IP address. Verify the
subscriber unit configuration using the following command:
show ipaddess
This will display the IP address of the selected device. Refer to the RedMAX AN100U/UX
Remote Connectivity
If remote connectivity is not possible, verify the following:
Step 1 In order to manage the subscriber unit remotely, across the wireless link, the device must
be configured as a "managed SS". Doing this will require the installation of a DHCP server
and a ToD server, as specified in the 802.16-2004 standard.
If the subscriber unit is configured for remote management, then it requires a valid
response from both a DHCP server, and a ToD server specified in the DHCP lease it
received. If one or the other is not received properly, the subscriber unit will not complete
its network entry.
You can log into the subscriber unit locally and verify whether remote management is
enabled using the following commands:
a. Connect your computer directly to the subscriber unit.
b. Open the Start Menu and select Run:
Start > Run
c. Enter the following command
telnet 192.168.101.2
d. When the command prompt screen appears, login using the following values:
Username: admin
Password: admin
e. Enter the show command
show managedSS
Step 2 Verify that the subscriber unit has properly received its DHCP lease, and ToD response by
checking the event log. The appropriate message (i.e. DHCP timeout) will be entered into
the log if this is the case. See Monitoring System Event Logs on page 2-6.
5-18
Step 3 Check the SS Info page of the AN100U/UX to see if the subscriber unit has an IP address
listed under the appropriate column. See Monitoring the System Parameters on
page 2-9.
Troubleshooting Wireless Link Issues
This section covers common configuration issues when establishing a wireless link
between an AN100U/UX and an SU.
In addition to the configuration issues covered here, you may also need to consider field
deployment issues such as antenna alignment. See Chapter 4, Outdoor Equipment
Maintenance for more information on outdoor equipment.
Cannot Establish a Wireless Link
There are many reasons for a failure to establish a wireless link. This section covers a
number of the most common problems.
Configuration Mismatch
There are a number of RF parameters on both the AN100U/UX and subscriber unit which
must match in order to establish a wireless link. The following parameters need to set to
the same value on both the sector controller and the subscriber unit:
Band Select MHz
Channel Size MHz
Guard Interval
Step 1 Login to the Web interface as outlined in Connecting to the Sector Controller Web Client
on page 2-4.
Step 2 Click Interface Configuration > Wireless Interface > PHY Parameters.
Step 3 Check the values of the following parameters and record the values.
Table 5-6 AN100U/UX PHY Parameters
Sector Controller
Parameter
Corresponding
Subscriber Unit
Band Select kHz RFFreq1-16
(rfConfig Menu)
This is the channelization type (802.16 OFDM PHY
system profiles).
5-19
Step 4 Login to the subscriber unit CLI as outlined in Connecting to the Subscriber Unit
Command Line Interface on page 2-6.
phyConfig show
Step 6 Check the values of the corresponding subscriber unit parameter and ensure they match
the values from the sector controllers.
Refer to the appropriate user guide for instructions on configuring each of these
parameters.
Cable Compensation
The term "cable compensation" refers to the amplification of the signal traveling up the IF
cable to the ODU, that is provided by the AN100U. Depending on the cable characteristics
(such as length, and quality) the AN100U will have to vary its amplification to achieve
signal levels appropriate for stable communication.
Note The cable compensation-related error/warning messages are not displayed when
HTB is used.
Step 1 Login to the Web interface as outlined in Connecting to the Sector Controller Web Client
on page 2-4.
Step 2 Check the sector controller event log, as outlined in Monitoring System Event Logs on
page 2-6. If you do not see the message "Cable Compensation OK" at the beginning of the
event log, it means that the quality of the cable was such that the AN100U was not able to
compensate for the loss, introduced by the cable, and thus communication with your ODU
will likely be unreliable.
The value shown in the event log is not important for practical purposes. It is the value
used internally by the AN100U when calculating the gain necessary. This value is
dependent on the calibration data stored within the ODU, and is not exposed via the user
interface.
Channel Size MHz Bandwidth (kHz) This is the channel size. Available options are based on
the type of radio installed.
Guard Interval CyclicPrefix The OFDM implementation uses a guard interval between
each of the sub-channels. This guard interval is filled with
redundant data taken from the end of the same channel
symbol and repeated at the beginning of each channel
symbol.
Table 5-6 AN100U/UX PHY Parameters (continued)
Sector Controller
Parameter
Corresponding
Subscriber Unit
5-20
AN100U/UX Tx Power
The transmit (Tx) power of the AN100U/UX is statically set. If the power is set too high or
too low, it is possible that the SU's RSSI is either too high or too low to obtain the CINR
required for a wireless link.
The expected RSSI for a particular subscriber unit can be calculated using the following
formula:
Subscriber Unit RSSI = Tx + Gain
SC
+ Gain
SU
- Path Loss.
Verify the value of the average measured RSSI value of the radio (RFRSSI) for the
subscriber unit.
monitor
monitoring mode.
Step 4 Enter the diagStatistics command to monitor the wireless interface and re-direct the output
to a file for review:
diagStatistics show > c:\su_list.txt
access.
Step 6 Open the file in your text editor and ensure the value of RfRssiAvg is above -89dBm. If it
is not, the Tx power of the AN100UX should be increased.
If the value is above -50dBm, it may be that the RSSI is too strong for the SU, so the Tx
power of the AN100UX should be reduced.
Where: The Sector Controller Gain is dependant on the gain of the antenna connected
to the AN100UX.
Tx is the Transmit power of the sector controller.
Gain
SC
is the gain applied by the sector controller.
Gain
SU
is the subscriber unit antenna gain of 13.5dBm.
Path loss can be calculated by the following formula, assuming that the system
is operating in the 3.5GHz spectrum.
Path Loss = 103.2 + 20log(Distance in km).
5-21
Cell Range
The AN100U/UX specifies a maximum distance beyond which SU's will be unable to
register. Verify that this set distance is greater than the distance between the AN100U/UX
and the SU. If not, increase the set value to include all subscriber units within the sector.
Step 1 Log into the Web interface as outlined in Connecting to the Sector Controller Web Client
on page 2-4.
Step 2 Click Interface Configuration > Wireless Interface > MAC Parameters.
Step 3 Check the value of Cell Range. The maximum value is 72 km, for devices with software
version 2.1 or higher.
If your subscriber units are beyond this range, contact
support@redlinecommunications.com.
Subscriber Unit Distance
The subscriber distance is calculated during subscriber unit network entry.
The distance is calculated during subscriber unit network entry. If the subscriber unit is
continuously registered between 0 and 2.5 km, then the reported distance will be zero.
The only indication that a subscriber unit has disconnected and re-registered further away
is that maximum CINR value at the further location is less than that at 2.5 km. Additonally
if the new location is further than 2.5 km the new distance will be reported.
LO1, LO2 and Radio Reference Frequency Errors
LO1 and LO2 Errors
There are two local oscillators within the sector controllers ODU. These oscillators, LO1
and LO2 are responsible for different aspects of the RF signal. Primarily the conversion to
the intermediate frequency (IF) is done via the LO2. The conversion from the intermediate
frequency to the actual radio frequency (RF) is done by the LO1.
Errors from either of these oscillators could result from a hardware failure, but may also be
seen in cases where the physical installation of either the IDU or ODU may be incomplete
or incorrect. The associated error message will appear in the event log.
During sector controller startup there is a sequence of messages exchanged between the
IDU and the ODU on the communication channel before the ODU becomes operational.
These messages include the IDU querying the ODU for the following information:
Intermediate Frequency (IF)
Radio reference frequency
Power for the PLL.
Additionally, each local oscillator provides an indication at to whether it is locked or not.
The following errors occur when the local oscillator becomes unlocked:
5-22
LO1 ErrorIndicates that the RF PLL is not locked
LO2 ErrorIndicates that the intermediate frequency (IF) PLL is not locked
If you observe either of there errors in the event log, then it is possible that:
There may be a defective component in the PLL circuitry;
The PLL is not receiving the required voltage;
The PLL is not getting the correct Reference Frequency;
A problem with the communication channel may result in false reporting
The following troubleshooting procedure is the same for both of these errors.
Step 1 Check the AN100U/UX event log for any local oscillator (i.e. LO) errors. See Monitoring
System Event Logs on page 2-6.
Step 2 Check the AN100U/UX event log to ensure that the air interface has not been disabled due
to problems communicating with the radio. See Monitoring System Event Logs on page
2-6.
Step 3 Ensure your sector controller is running the latest software: Version 2.0 or later.
a. Login to the Web client as outlined in Connecting to the Sector Controller Web Client
on page 2-4.
b. Navigate to Monitoring > General info. The Software Version and release date are
listed on the General Information page.
Step 4 Verify the physical installation of the sector controller:
a. You must verify that there is good connectivity across the length of your IF cable; check
for loose or rusted connectors, and faulty surge protectors. See Inspecting Outdoor
Equipment on page 4-7. Loose IF connectors may result in these types of error
messages.
b. Verify the IF cable integrity, i.e. IF cable is of the correct length with the correct
connectors at each end as per Redline recommendations. Ensure there are no breaks
or shorts in the cable. Ensure the connectors are the right type for the cable and they
have been tightened to the correct torque. See Interface (IF) Cable on page 4-6.
c. Verify that lightening protection devices are installed correctly. See Inspect and
Repair Lightning Protection System on page 4-10.
d. Verify that the radio is grounded correctly. See Verifying Your Lightning Protection
System on page 4-12. Incorrect or incomplete ground connection can affect the FSK
communication channel between the IDU and ODU if there are potential differences
between the two units.
Step 5 Verify that the site power supply is stable and not fluctuating. The indoor unit DC input
source must be an isolated secondary DC SELV supply at 60V DC maximum. Power
fluctuations may trigger these errors on your system. Refer to the RedMAX AN100U/UX
Base Station User Guide for more details.
5-23
Step 6 Verify that the IF cable path is not shared with any other cables (i.e. AC power cables), as
these cables can cause interference to the communication between the radio and the IDU,
thus triggering the LO1/LO2 error messages. The IF cable should be separately routed and
shielded from any other cables and potential sources of interference, along the entire path
between the ODU and IDU.
Step 7 After verifying all of the information above, reboot the IDU to see ensure the error clears.
See Rebooting the Devices on page 3-2.
Step 8 If the error persists, and you have verified the devices software version, then replace the
ODU hardware. See Replacing a Radio on page 4-1 and Replacing the Antenna on
page 4-4. Contact support@redlinecommunications.com to obtain an RMA number to
return the equipment to Redline.
Radio Reference Frequency Errors
A related error message, Radio Reference Frequency Error may result.
The radio reference frequency is sent from the IDU to the ODU, and is then passed through
the PLL which generates its own system clock which is then used to program the two local
oscillators LO1 and LO2.
The radio reference frequency is the first check before the LO1 and LO2 are programmed.
This is done during sector controller startup as indicated above.
Once the radio type has been determined and the FPGA boots up it will get its clock signal
from the PLL indicating that the communication between IDU and ODU has been
established.
If the ODU does not receive the correct reference frequency from the IDU or if the
reference frequency is too low, then a Radio Reference Frequency Error will result and the
radio interface will be disabled.
If you observe this error in the event log, then it is possible that the radio is not receiving
the required voltage for the following reasons:
the IDU may be defective
the communication channel between the IDU and ODU is experiencing errors.
if the ODU does not receive the correct Reference Frequency from the IDU, or if the
Reference Frequency is too low, it will result in a Radio Reference Frequency Error,
thus disabling the radio interface.
The troubleshooting procedure is the same as listed above for LO1/LO2 errors with the
following exceptions:
Step 1 After verifying all of the information as outlined in steps 1 to 5 above, reboot the IDU to
ensure the error clears. See Rebooting the Devices on page 3-2.
Step 2 If the error persists, and you have verified the devices software version, then replace the
IDU hardware. See Replacing the Indoor Unit of the AN100U/UX on page 3-3.
Step 3 If the error still persists, and you have verified the devices software version, then replace
the ODU. See Replacing a Radio on page 4-1 and Replacing the Antenna on page 4-4.
5-24
Contact support@redlinecommunications.com to obtain an RMA number to return the
defective equipment to Redline or authorized partner.
Indoor Subscriber Unit (SUI) Connectivity Issues
Predicting link budgets for indoor links is exceedingly difficult, as there are many factors
which affect the path loss of an indoor link, which do not apply to outdoor links of similar
distances. Use the following list of steps to take, to establish a connection or to improve
an existing connection, when using an indoor subscriber station (SU-I).
If the subscriber station is located next to a window, ensure that the window does not
contain any metal. Many windows contain lead to reduce incident sunlight, or may be
inter-woven with a metal wire mesh to increase their strength.
If you do not have an appropriately facing window, place the subscriber unit near an
exterior wall facing the direction of the sector controller. Interior walls and obstructions
such as appliances and the buildings metal framework can severely impact link quality.
Place the subscriber unit as high as possible. Moving the subscriber up away from the
clutter of a room can significantly improve link quality. Objects such as desks, chairs, filing
cabinets, even people walking in and out of a room within the path of the subscriber unit
can disrupt the link.
Gauging Link Performance
In order to be able to gauge how well a sector or even a particular wireless link is working
it's important to understand what statistics to monitor, and how to interpret them. The
statistics available on the AN100U/UX and its subscribers differ, as each device has
different information available. It's important to observe the statistics available on both
devices before attempting to come to any sort of conclusion.
AN100U/UX
In general, the AN100U/UX is able to display statistics regarding the quality of the uplink
signal received from any given subscriber, as well as the overall status of the sector's
traffic and health. It also displays some basic information regarding signal levels in the
downlink, which are reported to the AN100U/UX by the subscribers. The following table
lists the statistics/parameters to monitor, and a brief description on how they should be
interpreted.
You can access these parameters on the Status and SS Info pages of the sector
controllers web interface. See Monitoring Statistical Results Screens on page 2-8.
5-25
.
Table 5-7 AN100U/UX Statistical Parameters
Status Page
Uplink/Downlink
Throughput
These statistics report the amount of traffic passed sector-wide in each
direction.
You should verify that the throughput reported here matches with your
expected data rates.
Uplink/Downlink Usage These statistics report the amount of the uplink and downlink subframes
which has been utilized. If you frequently see utilization in either direction
at 100% your sector has reached its maximum capacity for that direction.
There are a few solutions to this problem. You could change your frame
ratio to a value which provides more bandwidth in the direction which has
reached capacity.
You could also try to improve the link quality of any subscribers operating
at lower modulation rates.
Noise Level This value is measured by the AN100U/UX during silent parts of the
uplink sub-frame. It can be used to determine whether your sector is
experiencing any uplink interference from any outside sources.
The value should normally be around -108dBm; the exact value will
depend on individual radio calibration. If a significant noise level is
detected, you should check the event log on system startup. There will
be a message there which will provide more information regarding the
potential source of the interference, possibly even its MAC address.
SS Info page
Uplink / Downlink
Modulation
These values denote the current maximum supported modulation rate
that any given subscriber is capable of. This is directly based on CINR
levels. If the modulation rate is lower than expected, efforts should be
taken to improve the link's CINR.
Uplink RSSI This value is a measurement of the signal strength, not signal quality. If
the signal strength fades significantly from the value recorded during
installation, then the first thing to verify is antenna alignment.
It is normal for this value to be up to 8dBm above the Reference RSS;
however, try not to let the RSSI exceed -50dBm. Signals above this level
will start to have an adverse effect on link quality, and may begin
damaging the receiver.
5-26
Subscriber Unit
The subscriber unit provide statistics for its local configuration. Unlike the sector controller,
it has no knowledge of other devices in the sector. As such, if you are attempting to
troubleshoot a sector-wide problem, a sample of a subset of the affected subscriber units
will need to be taken in order to obtain an accurate picture of the sector as a whole.
The subscriber unit can only report the downlink conditions of a link. The sector controller
does not provide the subscriber with any report on uplink conditions, other than to specify
when a subscriber should increase or decrease its transmit power in order to satisfy the
Reference RSS requirements.
You can access these parameters on the Diagnostic Statistics page of the subscriber
units web interface. See Monitoring Statistical Results Screens on page 2-8.
.
Uplink/Downlink CRC This is the number of CRC errors experienced on a given subscriber unit.
The uplink counters reset after each de-registration, while the downlink
counters only reset after a subscriber unit reboots. As such, before
performing any characterization of CRC totals or rate, it's advised that
you reboot the SS to synchronize the counters.High CRC rates are
normally a result of poor signal quality, and can also indicate
interference.
Tx Power This value displays the transmit power of the given subscriber station. If
the value displayed is -64, then the subscriber station does not support
this feature. Often when signal levels are higher or lower than expected,
it is a result of the fact that the subscriber has reached its
maximum/minimum transmit power. This parameter can be used to verify
whether this is the case.
Table 5-7 AN100U/UX Statistical Parameters (continued)
Table 5-8 Subscriber Unit Statistical Parameters
RSSI This is the received signal strength as received by the subscriber's PHY, and is
measured after internal amplification. It should always be within a few dBm of -16.
SnR This is a measurement of the downlink signal quality received by the SS. The higher
the better. This value normally does not exceed 31dB. A value less than around 9dB
will likely result in link-loss.
5-27
Link Optimization and Reference RSSI
Aside from field characteristics such as antenna alignment and positioning, the primary
method of optimizing a sector controller's wireless performance is by adjusting the
AN100U/UX's Reference RSSI. This is an increasingly difficult parameter to set properly
as the number of SU's per sector increases. It is vital to have a good understanding of this
parameter since it has both an immediately obvious effect, as well as a subtle yet equally
important effect.
The obvious impact is on the Tx power of the SU, and therefore the uplink RSSI of that
particular SU. Assuming that the AN100U/UX is configured with Tx Power Control
enabled (highly recommended), then the Tx power of each subscriber unit in the sector will
be controlled such that the RSSI as measured by the AN100U/UX will be set as close as
possible to the reference RSSI.
The subscriber unit can only be set to the approximate reference RSSI, in the case of SU's
with a high level of path loss along their link, it is possible for the subscriber unit to reach
its maximum Tx power and still be lower than the reference RSSI. This situation should be
avoided, if at all possible.
The less-obvious impact of setting this parameter is that it directly controls the gain along
the AN100U/UX's IF cable. Since the AN100U/UX does not support automatic gain control
(AGC, it cannot adapt its IF gain for each SU. That means that a single gain value must be
applied to all SU's. The gain, as received at the Phy, (the device in the IDU which performs
the actual decoding of the OFDM signal) must be as close to -16dBfs, as possible. The
Reference RSSI configured in the Wireless Interface page specifies the target RSSI for all
SU's, which means that the AN100U/UX can calculate what the IF gain must be in order
to achieve -16dBfs.
For example, if the AN100U/UX's Reference RSSI is set to -63dBm, then due to path-loss,
the subscriber unit can only achieve an uplink RSSI of -80dBm even when transmitting at
its maximum power of 20dBm.
RfRSSI This value represents the signal strength as received by the subscriber unit before
internal amplification. It is this value that should be used during alignment, as it will
actually change to reflect signal strength (unlike the Rssi value, which should remain
fixed!).
Total CRC
Errors
Ideally, this value would remain at 0. It is normal however even good links to
experience occasional CRC errors. If you see CRC errors continuously however, this
is an indication of link instability. You should check for wireless interference, wireless
reflections or refractions, and you should also verify that adaptive modulation has not
been disabled, and the Snr is high enough to support the SU's minimum coding level.
This can be checked using the command "show modThresh Rate1Exit"
Table 5-8 Subscriber Unit Statistical Parameters (continued)
5-28
A configured reference RSS of -63dBm means that the actual signal power received from
the subscriber is 17dBm weaker than expected, and as such, the IF gain is insufficient. If
the reference RSS were changed to -80dBm, the IF gain would be increased. Thus, by
decreasing the reference RSS, we increase the IF gain.
Unfortunately, in doing so we also increase the amount of distortion introduced by
amplification, so although we improve the RSSI, and thus the CINR of the link, the signal
quality may still not be such that we can achieve 64QAM 3/4. It will however be better than
it would have been had we left a 17dBm difference between the reference RSS and the
SU's best achievable uplink RSSI.
Complications arise when you have a large number of SU's, some with low pathloss, and
some with relatively high pathloss. If you set the reference RSS to accommodate only
those SU's with low pathloss, then those with high path loss may have their signal quality
significantly impacted due to radio saturation. However, if you configure the reference RSS
to accommodate those SU's with a high pathloss, then those with low pathloss may not
have sufficient gain to register at all. You should set the initial reference RSS to the mean
average of the uplink RSSI of all of the SU's in the sector. You then move the value up or
down to determine the optimum value for the each link.
Subscriber Unit De-Registration
Event Log Entries
When an subscriber unit de-registers, two pieces of information are logged to assist in
troubleshooting. First, when the subscriber unit de-registers, its event log is updated with
a message and timestamp detailing the cause of the de-registration. Search through the
SU's event log and look for messages like:
DHCP Timeout
DL Map Lost
The second piece of information is located in the AN100U/UX's event log. This message
contains a timestamp, the SU's MAC Address, and a reason in brackets. The reason can
be:
re-rangingindicates that the subscriber station initiated network entry while the
AN100U/UX believed it was still connected. The only method the AN100U/UX has to
determine whether an subscriber unit is still connected is by receiving traffic from it. If
there is no network traffic, the only data sent by the subscriber unit is a periodic range,
which occurs every 25 seconds. Thus, it can take up to 25 seconds for the AN100U/UX
to detect that an subscriber unit has gone offline. During this 25 seconds, it is entirely
possible for the subscriber unit to attempt to register again. If it is successful, this will
cause a "Re-ranging" message.
rngRetriesmeans that the ranging process failed. See Sector Controller Serial
Communication Issues on page 5-13 and Sector Controller IP Connectivity Issues
on page 5-14 to troubleshoot the wireless interface.
5-29
Possible Causes of Subscriber Unit De-Registration
The subscriber unit can disconnect for a number of reasons such as:
Unstable Link ConditionsThis is a frequent cause of subscriber unit de-registration.
See Gauging Link Performance on page 5-24 and Link Optimization and Reference
RSSI on page 5-27 for information on verifying and improving the stability of the link.
Subscriber Unit Power Source IssuesProblems with the SU's power source are also
a frequent cause of subscriber unit de-registration. Refer to the Outdoor Wireless
Access Subscriber Modem Installation Guide for information on troubleshooting power
supply issues.
Remote Management IssuesIf remote management is enabled, the subscriber unit
requires communication with a DHCP server and a ToD server (as defined in RFC-868)
in order to operate. If the subscriber unit is not able to connect to both a DHCP server,
and the ToD server specified in the lease it obtained, then within 2 minutes it will reset
and try again. If you are seeing Re-Ranging messages in your AN100U/UX's event log
at approximately 2 minute intervals, it is likely that you have a problem with either your
DHCP or ToD server.
Step 1 Check the sector controllers SS Info page to see if the subscriber unit is shown with a
valid IP address, other than "0.0.0.0". See Monitoring Statistical Results Screens on
page 2-8.
Step 2 If the subscriber unit has been assigned a valid IP address, then try to ping the subscriber
unit in order to ensure that the management channel is configured correctly. See Using
the Ping Utility on page 2-10 for details.
RF Interference
Avoiding RF Interference
RF interference can originate from many sources, both internal and external to your
network. Implementing local and GPS synchronization across your network is a vital step
in avoiding interference caused either by sector controllers, co-located in the same base
station, or by sector controllers located in adjacent base stations.
It is equally important that a carefully designed frequency plan be in place across the
network and that you are following this plan. If you do not have a plan or are adding
devices, outside the scope of your existing plan, then even with GPS synchronization you
will not be able to compensate for locally-introduced interference.
Eliminating Other Causes for the Symptoms
Before you suspect interference, first verify that your wireless link has acceptable signal
quality for all your subscriber units, for each particular coding rate. Subscriber units with
poor link conditions may also generate CRC's in your system even without interference. If
5-30
your wireless link is stable, and you are still experiencing wireless CRC errors, then there
is a high probability that they are caused by interference. See Gauging Link Performance
on page 5-24 to verify that your link is stable.
Wireless interference is generally observed in the signal quality statistics for a given
subscriber unit. Assuming no interference, the relationship between signal quality and
signal strength is predictable. The chart below provides a range of signal strengths, along
with the minimum signal quality that should be expected for each signal level.
Field results may vary slightly as a result of channel size and individual radio calibration
differences. In general however, if you experience signal quality levels below those listed
in the following table, wireless interference is the likely cause.
Isolating the Source of the Interference
After identifying the presence of interference, the next step is to isolate the source. The
location of any reported CRC errors can help isolate the source of the problem.
If you are observing a high rate of CRC errors in the uplink, then the interference is most
likely affecting the sector controller's uplink reception.
Similarly, if the CRC errors are seen in the downlink, then the interference is most likely
affecting subscriber unit reception. Identifying those subscriber units that are specifically
experiencing higher rates of CRC errors can often help identify the source of the
interference.
Excessive subscriber unit de-registrations may also indicate wireless interference.
Normally you would expect RF interference to be observed in one of the available RF
statistics. For example, a change in RSSI, a reduction in CINR/SNR or a higher than
normal rate of wireless errors are all possible indicators of RF interference. Review the RF
statistics on the sector controller's SS Info page. The page is updated continuously so you
can look for changes. See Monitoring Statistical Results Screens on page 2-8.
Depending on the nature of the interference, it is not always possible to determine its
impact in the reported RF statistics. Signal quality (i.e. CINR in the uplink and SNR in the
downlink) is the metric typically used to gauge link stability. However due to the fact that it
is generally an averaged value, as well as the fact that it is periodically sampled as
opposed to continuously measured, there are situations where it can report misleading
signal quality. You may be able to see the effects by monitoring the signal noise level. See
Viewing Noise Level Measurements on page 5-32.
Table 5-9 RF Signal Quality Reference Values
RSSI (dBm) Minimum DL SNR Minimum UL CINR
-85 12 12
-80 17 13
-75 20 17
-70 24 21
-65 26 23
5-31
CRC error rates may not always be the ideal metric for link quality, as there must be traffic
present in order to see CRC error rates and then interpret it in a meaningful way. You could
find yourself in a position of not detecting any CRC errors (as a result of there being no
traffic) while still observing subscriber unit de-registrations as a result of significant uplink
or downlink MAC management interference.
Identifying the presence of interference when no CRC errors are observed is done
primarily through the interpretation of subscriber unit behavior and event log analysis. The
SU's provide a great deal of information in their event logs regarding the wireless channel.
Along with entries such as periodic channel maintenance messages and service
provisioning details, it is normal to see intermittent wireless error messages when the
subscriber unit is unable to decode a frame header, or the CRC fails on a wireless packet,
etc. These types of errors will occur occasionally during day-to-day operation. However,
when the subscriber unit starts to report significant numbers of wireless errors, or even
constantly, then interference is the likely cause.
Wireless interference most often generates subscriber unit messages describing some
form of packet loss or modem error. For example, a "DLFP Error" means that the frame
profile sent at the beginning of the downlink portion of the frame was corrupted, resulting
in the loss of the entire frame. This message is particularly telling since the DLFP is
transmitted at BPSK1/2, meaning that the interference would likely have to be very strong
in order to corrupt this message. Similarly, any modem errors (such as "Spare0 timeout")
imply the corruption of a MAC management message, which are all transmitted at
BPSK1/2, and would again imply fairly strong wireless interference.
The corruption of data bursts is reflected via the CRC counter, and not logged. The
exception to this is the case of fragmented MPDU's. When a wireless packet is fragmented
across multiple wireless frames, if one of the fragments is lost a message will be logged.
Similar to CRC errors, the scope and location of the performance degradation (e.g.
de-registrations, signal degradation, frame loss) can be used to determine the source of
the interference. For example:
Does the issue occur network-wide, or only on a single sector controller?
Are multiple subscriber units affected simultaneously, or is the effect more sporadic
and scattered?
Of the subscriber units that are affected, what do they have in common? Do they all
use the same modulation/coding rate? Do they all have a similar azimuth? You can use
the RMS or Syslog service to keep track of the rates and times of de-registrations.
Is there a particular time of day when the rates are better or worse?
Has the rate of de-registration increased since first observed, or has it remained
constant?
All of this information can be useful when trying to isolate the source of interference.
In some circumstances, your devices may experience interference, which is not observed
in the usual signal quality statistics. In this case, connectivity issues may be the only
symptom of the wireless interference. You should first eliminate network and
configuration-related de-registrations before attempting to troubleshoot possible wireless
interference issues.
5-32
Unfortunately, no amount of planning can avoid interference caused by external sources,
or "rogue" sectors. If you suspect that you are experiencing problems due to external
interference, perform the spectrum sweep as outlined in Guide to Field Spectral Analysis.
If the spectrum tests shows any unknown source of interference in your bands, you need
to contact your local regulator, as the frequency spectrum used by the RedMAX system is
licensed.
Viewing Noise Level Measurements
RedMAX devices can report the background noise level as measured by the AN100U/UX
radio. This measurement is extremely useful when attempting to troubleshoot uplink
stability issues and CRC errors.
The reported value can be found in two locations:
At the beginning of the AN100U/UX's event log.
On the AN100U/UX's Web client Wireless Status page.
Each of the two values is measured slightly differently. In either case, the lower bound of
the value (interpreted as no detected background noise) is around -108.6dBm, depending
on the calibration of the individual radio.
If the noise level is greater than the lower bound, then it must be at least 30dBm less than
the sensitivity threshold of the current operating modulation/coding rate. If the noise level
is not 30dBm less than the sensitivity threshold, then it impacts signal quality (i.e. CINR).
Note An elevated noise floor value is a strong indicator of interference in the uplink;
however, the absence of an elevated noise floor value does not necessarily indicate
the absence of interference. The noise floor value is one of many indicators that
must be considered. See RF Interference on page 5-29 for more details.
The noise floor value that is shown on the status page is an average value, that may not
reflect peak values. Please refer to Noise Floor Calculation on page B-20 for detailed
information on how this value is calculated.
AN100U/UX Event Log Value
The noise level reported in the AN100U/UX's event log on system boot-up is an
instantaneous value measured during the first 3 seconds after the AN100U/UX radio's
receive chain is powered up. This value is not updated or reported again.
See Monitoring System Event Logs on page 2-6, to view the sector controller event logs.
This value of this noise level measurement will result in one of 3 event log messages:
Average Noise Floor on the Uplink Channel = [dBm]
This message is part of normal system operation, and indicates that the radio was not
able to synchronize on any interfering signal.
WARNING: Uplink Channel Conflict with [sector controller MAC] (RSSI dBm)
5-33
This message indicates that the radio was able to synchronize on an interfering signal.
Additionally, it was able to detect the sector controller ID (i.e. MAC address) of the
interfering WiMAX sector controller.
Note In order to detect the sector controller ID of the interfering sector controller, it must
be operating with the same cyclic prefix and channel bandwidth.
When you see this message you will need to further isolate the source of the
interference and the impact on your sector.
WARNING: Unknown Interference was Detected on the Uplink Channel (RSSI dBm)
This message indicates that the radio was able to synchronize on an interfering signal.
However, it was not able to detect the sector controller ID of the offending system.
The interfering signal is not necessarily a WiMAX system, nor is it necessarily even an
OFDM system.
See Interference Messages at Startup on page B-19 for details on how these messages
are determined and details on noise floor calculations.
AN100U/UX Web Client Status Page
The noise level is also reported in the Web clients Status page. See Monitoring Statistical
Results Screens on page 2-8.
This value is measured in a slightly different manner than the value reported in the event
log. This value is measured once the system has become fully operational, and is updated
continuously. It is also an averaged value, as opposed to an instantaneous measurement.
The AN100U/UX uses any remaining (i.e. unused) space in the uplink to perform channel
measurements. It collects 200 samples, averages them, and then updates the noise level
measurement. Since the AN100U/UX only uses unused space, this means that it has no
effect on QoS or sector capacity. Additionally, it means that the frequency at which this
value is updated depends on sector usage. In sectors with low usage, where the
AN100U/UX can collect the required sample very quickly, the value may be updated at
1-second intervals. In sectors with a high volume of uplink traffic, it may take much longer
to collect the 200 samples.
Both the event log and Status page values are measured during the uplink sub-frame only.
Thus, if you are using synchronization in your network, adjacent/co-located sectors should
not be detectable. If you are seeing interference from supposedly synchronized sectors
within your own network, you need to verify the configuration/status of your
synchronization solution.
Performing a Site Spectrum Analysis
The purpose of a spectrum site analysis is to identify potential sources of RF interference
that might be found at a current or prospective site. Refer to the document, A Guide to Field
Spectral Analysis, for a detailed description of the equipment required, the recommended
5-34
methodology, step-by-step instructions, and information on how to interpret the results.
This document can be obtained from your Redline partner, or
Refer to Performing a Spectrum Sweep on page 4-9 for details on performing the various
types of spectrum sweeps.
Troubleshooting Data Throughput
All units boot properly, Ethernet and IP connectivity are confirmed, and the wireless link
looks good. Yet there are still issues passing data traffic. Why? Usually, it's caused by an
issue with either the Service Class, Service Flow, or Classifier configuration.
Note: As mentioned in the introduction to this document, this is not intended to be used as
a system manual. A step-by-step discussion of the configuration of data services is beyond
the scope of this document. For details on service configuration, please see the respective
device's user manual. This section is intended only as a summary of common configuration
pitfalls.
Troubleshooting Data Services
This section lists a number of quick steps to ensure that you have properly configured your
service flows and classifiers.
Verifying Service Flows
page 2-4.
Step 2 From the Main menu select Service Configuration > Service Flows.
On the Service Flows Configuration page, check the SF State column to ensure that all
of your service flows are in the Active state.
If the service flows are in the Authorized state, then it's likely that you have not configured
any valid classifiers. Service flows do not become active until there are classifiers
associated with them.
Refer to the RedMAX AN100U/UX Base Station User Guide for information on creating
service classes and service flow.
Verify Service Flow Classifiers
page 2-4.
Step 2 From the Main menu select Service Configuration > Classifiers.
On the Classifier Configuration page, check the State column to ensure that all of your
classifiers are in the Active state.
5-35
When you are creating classifiers, if you see a status of "Rejected", there is a conflict with
an existing classifier. Check the event log of the AN100U/UX for a classification conflict
error message.
Refer to the RedMAX AN100U/UX Base Station User Guide for information on creating
service classifiers.
Example of Working with Service Flow Classifiers
When working with data throughput issues, it is generally easy to understand that a service
class defines a QoS template which is then used by service flows to define a "pipe"
between a subscriber unit and an AN100U/UX.
Service flow classifiers are more difficult to understand because they require knowledge
of the network layer, to which most people are not exposed.
In the following example, you will use the following configuration:
A computer is connected directly to an SU, and a router is connected directly to the
AN100U/UX. In this example, it does not matter what is beyond the router upstream,
since classification will be done at Layer 2.
There is only one service class, and it is defined as a 1Mbps Best Effort class called
"Class1".
There are two service flows (one in each direction). SF1 is the down stream flow, and
SF2 is the up stream flow.
Classifiers are identified by "dotted" notation, where the first number is the number of
the service flow, and the second number is the number of the classifier. Thus, the first
classifier associated with SF1 is identified as 1.1, and the first classifier associated
with SF2 is 2.1.
In this example, we will be classifying data based on the MAC address of the computer
behind the SU.
Step 1 As the administrative user, navigate to the Windows command line interface on computer
connected to the subscriber unit.
Step 2 Generate a report of the computers IP configuration:
ipconfig /all
In Windows, the MAC address is called the Physical Address. The ipconfig command
provides the following statistics:
5-36
We want to create a classifier based for packets heading towards the computer and SF1
which is the downstream service. Classifier 1.1 would therefore have a destination MAC
address of 00-0D-60-FC-B7-7A, and a mask of FF-FF-FF-FF-FF-FF.
Since SF2 is an upstream service flow, we want to classify based on packets heading away
from the computer, thus classifier 2.1 would have a source MAC address of
00-0D-60-FC-B7-7A with the same mask. See Figure 5-5.
Example 5-1 ipconfig Statistics
Windows IP Configuration
Host Name . . . . . . . . . . . . : redmax_SUtest
Primary Dns Suffix . . . . . . . : redmax.com
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : redmax.com
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : redline.com
Description . . . . . . . . . . . : Intel(R) 82567LM-3 Gigabit
Network Connection
Physical Address. . . . . . . . . : 00-0D-60-FC-B7-7A
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.45.33
.
.
.
5-37
Figure 5-5 Example of Service Flow Classifiers with Subscriber Computer Configured as
Source/Destination
The Hosts' MAC Address(es) is Unknown
The above example is based on the assumption that you know the MAC address of devices
behind the SU. If the hosts' MAC address is unknown then there are two options.
Option 1You can classify based on the MAC address of the router. The downlink
classifier 1.1, in the above example, would have a source MAC address equal to that
of the router.
While the uplink Classifier 2.1 would have a destination MAC address equal to that of
the router. In this way it doesn't matter which downstream host the traffic is originating
from, as long as it's all heading to the same router/server.
Figure 5-6 Example of Service Flow Classifiers with Router Configured as Source/Destination
5-38
Unfortunately, this does not work well with multiple subscribers, since the AN100U/UX
needs to uniquely assign downstream traffic to each SF. If you're classifying based on
upstream source, and it's all coming from the same source, the AN100U/UX has to
"guess", and that is not the ideal solution.
Option 2If you have multiple SU's, and unknown hosts behind them, then you need
to enable VLAN tagging on the subscriber unit (ethTag in the subscriber unit's CLI).
This feature causes the subscriber unit to insert a VLAN tag onto each incoming
upstream packet, and strip that same tag from every downstream packet. On the
AN100U/UX, you can then classify based on this packet or VLAN tag. in the
downstream, thereby uniquely identifying traffic destined to each subscriber unit.
Classification in the upstream can be done using "wildcard" classifier where the MAC
destination is 00:00:00:00:00:00 with a mask of 00:00:00:00:00:00, indicating that all
destination MAC addresses are to be used.
Note This solution requires that your network support VLANs upstream of the
AN100U/UX.
Figure 5-7 Example of Service Flow Classifiers with VLAN Tagging
Point-to-Point Pass-through Mode
The RedMAX system does not have a pass-through mode option available. It is designed
to be an access system with many registered subscribers operating simultaneously. In this
scenario, a point-to-point pass-through mode does not make any sense. The closest
5-39
configuration available is the configuration using subscriber unit VLAN tagging, as detailed
above, though this would require some external hardware to strip and add VLAN tags
appropriately, upstream of the AN100U/UX.
Troubleshooting the Data Path
The purpose of this section is to describe a step-by-step procedure for diagnosing data
connectivity problems. It will examine each section of the data path and describe how to
identify potential problems at each stage of the path.
Note It is crucial that a steady source of data traffic be present across the wireless link
in question.
The procedures below make use packet/byte counters, which require traffic in order to be
meaningful. A simple ping between two hosts on either end of the link should be sufficient,
but sending UDP packets using iPerf will make it easier to distinguish any potential
background traffic. You can use iperf to send obvious spikes in traffic rates.
Note You must send test traffic in the direction that you are testing. Do not send traffic in
both directions.
Common Issues
Most connectivity issues are due to improper classification. Before proceeding, make
absolutely sure that your classification is done properly:
If you're classifying based on VLAN tags, make sure that your switches are configured
properly, or that your computers recognize and accept VLAN-tagged traffic.
If you are classifying based on MAC addresses, make sure that you've specified the
source and/or destination MAC addresses properly.
Make sure that you are not trying to classify using wildcard MAC addresses on more
than one service flow in the downstream direction. You can use wildcard classifiers on
all subscriber units upstream, but you cannot do this in the downlink, because all
classifiers must be unique.
If you are not expecting VLAN-tagged traffic in your network, make sure that subscriber
unit tagging is disabled. Do this by typing "show ethTag".
Step 1 Login to the CLI client as outlined in Connecting to the Subscriber Unit Command Line
ethTag show
5-40
This command shows the current settings for VLAN tagging and the data traffic, using
802.1Q, that is passing through this subscriber unit.
access.
MAC Auto Learning
If you are using MAC Auto Learning in your RedMAX sector, ensure that all of your
subscriber units are configured with learning enabled. The typical, auto-learning
provisioning template uses a blank downlink and uplink classifier for each service flow.
When learning is disabled, a blank classifier is treated as "pass-all".
Each service flow must have unique classification rules sector-wide in the downlink. This
is not the case for the uplink, where uniqueness must only be subscriber-wide. A pass-all
downlink classifier matches any packet coming into the AN100U/UX. Combine this with the
fact that classifiers of the same priority are checked in order of creation, then you can see
how this one classifier can quickly cause sector-wide connectivity issues.
Changing the Learning Mode
When Learning Enabled is disabled (set to No) on a subscriber unit, then all generic
classifiers on active service flows on that subscriber unit will operate as pass-all filters
directing all same/lower priority downlink traffic in the sector to the particular subscriber
unit.
If you opt to disable MAC auto learning on one or more subscriber units, you should delete
all classifiers before disabling auto-learning in order to prevent network connectivity
issues.
Step 1 Identify the subscriber unit to be modified. (Learning Enabled = Yes). You will need the
devices MAC address.
a. Login to the CLI as outlined in Connecting to the Subscriber Unit Command Line
b. Enter the following command:
show interfaces
c. Record the MAC address for this subscriber unit.
Step 2 Identify the downlink service flow(s) associated with this subscriber unit.
a. Login to the Web client as outlined in Connecting to the Sector Controller Web Client
on page 2-4.
b. Navigate to Service Configuration > Service Flows.
c. On the Service Flows Configuration page, locate the downlink service flow(s)
associated with this subscriber units MAC address, have "no-criteria" or blank
classifiers.
5-41
d. Select the corresponding service flow ID (SFID) and click Edit.
e. The page will be updated to show the selected service flow. Verify that is this the
downlink service flow associated with your subscriber units MAC address.
f. Click Delete to remove this service flow.
g. Remove any other downlink service flow associated with your subscriber units MAC
address.
Step 3 Alternatively, you can delete the generic downlink classifier associated with each service
flow:
a. Navigate to Service Configuration > Classifiers.
b. On the Classifier Configuration page, locate the no criteria or blank classifiers
associated with each service flow.
c. Locate the generic classifier, associated with this subscriber units MAC address.
d. Enter the corresponding classifier ID (SFID.ClsID) in the Remove Classifier box and
click Delete.
Step 4 Disable the Learning Enabled option= No (subscriber will reregister):
a. Navigate to Service Configuration > Subscribers.
b. On the Subscribers Configuration page, select your subscriber unit from the drop
down list and click Edit.
c. The page will be updated to show the selected device. Select No from the drop down
list drop down list.
d. Click Modify. You will be warned that service flows and classifiers will be re-created
and subscriber unit will need to re-register. Click OK to continue.
Figure 5-8 Modifying Subscriber Unit Learning Enabled Status - Warning Message
Tracing Downlink Connectivity Issues
Step 1 Ensure that your test traffic (i.e. iperf) is running.
Command:
Step 2 Log into the Web interface as outlined in
Step 3 Navigate to your Monitoring > SS Info.
5-42
Step 4 Click on the subscriber unit in question and look at the throughput column for your
downlink service flow.
If you are running 1Mbps of iperf traffic, you should expect to see approximately 1000kbps.
If not, the problem (99% of the time) is classification-related.
If you are certain that the problem is not related to provisioning, then you will need to verify
that the packets are being received properly by the AN100U/UX.
Step 5 The best way to do this is to connect a hub directly to the AN100U/UX's data-port, and
capture the traffic being received at that point using Ethereal (http://www.ethereal.com/).
Step 6 If you see traffic across your service flow, then the test traffic is being received by the
AN100U/UX, classified, scheduled, and sent to the SU. The problem must be downstream.
Interface on page 2-6 and enter the following command:
show interfaces
Step 8 Observe the DlByteCount statistic (4th column, 7th row).
Step 9 If you see the downlink byte counter incrementing by about 1000kbps, this implies that the
traffic is being received properly by the SU. The problem must then be further downstream.
Step 10 Log into your subscriber unit using the super/super credentials and enter the following
commands:
shell
brgStat
Step 11 Wait 15 seconds then type "brgStat" again. Observe the difference between the first and
second values of the Wireless Unicast Pkt to Ethernet counter. Is this counter
incrementing as expected? If not, then the problem may be related to one of the filters
implemented in the subscriber unit in order to avoid VLAN leakage when CPE-to-CPE
communication is enabled in the sector. At this point, you should call Redline technical
support for further assistance.
Step 12 If you do see the packet counters incrementing, then the problem must be downstream of
the RedMAX system.
Tracing Uplink Connectivity Issues
Step 1 Ensure that your test traffic (i.e. iperf) is running.
Step 2 Navigate to your Monitoring > SS Info.
Step 3 Click on the subscriber unit in question and look at the throughput column for your
downlink service flow.
If you are running 1Mbps of iperf traffic, you should expect to see approximately 1000kbps.
If not, the problem (99% of the time) is classification-related.
5-43
Step 4 If your service flow counters are indicating uplink throughput, yet you are still having
connectivity issues, then the problem is most likely upstream of the AN100U/UX. Call the
Redline technical support department if you still have concerns about the RedMAX system.
Step 5 If the service flow counters show no uplink throughput, and you are certain that the
problem is not related to provisioning, verify that the packets are being received properly
by the SU.
Step 6 Log into your subscriber unit using the super/super credentials and enter the following
commands:
shell
brgStat
Step 7 Wait 15 seconds then type "brgStat" again. Observe the difference between the two values
of "Ethernet pkts received". Are they incrementing by an appropriate rate? If not, the
problem is downstream of the SU, and you'll need to trace it out yourself. If so, take a look
at the counter for "Ethernet pkts sent to class". Does it equal "Ethernet pkts received"? If
not, the packets being received by the subscriber unit may be corrupted. It's also possible
that you've hit the maximum number of MAC addresses for this SU, as specified in the
AN100U/UX's "Subscriber" menu.
Step 8 If the counters in step 5 are incrementing appropriately, but the uplink service flow counters
still show no throughput, call Redline technical support for assistance.
Step 9 Type "myQuit" to exit the SU's shell, then type "monitor". Observe the "UlByteCount"
statistic (1st column, 9th row). Is it incrementing as expected? If not, then the problem is
related to provisioning.
Step 10 Verify your classification, and ensure that your sector is not over-subscribed to the point
of not having sufficient bandwidth to grant the required allocation to the subscriber.
Software Upgrade Issues
Both the AN100U/UX and the subscriber unit use the FTP protocol for software
upgrades.You can specify the user name and password to be used when upgrading sector
controllers; however the subscriber unit uses a default user name of "target", and a default
password of "secret". These values cannot be changed.
If the file transfer process is failing, use the following troubleshooting procedure to isolate
the problem:
Step 1 Verify the IP address of the FTP server.
Step 2 Verify that the IP address of the FTP server has been entered correctly at the CLI:
a. Login to the CLI as outlined in Connecting to the Subscriber Unit Command Line
5-44
b. When the command prompt screen appears, login using the following values:
Username: admin
Password: admin
c. Enter the subscriber unit loadimage command
loadImage
Server IP Address: [enter ftp server IP address here]
File Name: [enter binary file name here]
d. The command for the sector controller is:
softwareUpgrade loadImage
Server IP Address: [enter ftp server IP address here]
File Name: [enter binary file name here]
Note The subscriber unit assumes the user id is set to target with the password
set to secret. Your FTP server must be configured at accept these login
credentials.
Step 3 Verify that the FTP server is running. You will need to log into the computer that is hosting
the FTP server and ensure all of the FTP processes are running. Open the Windows Task
Manager. Click on the Processes tab and check the status of the FTP processes. Process
name names will vary depending on the utility that you are using.
Step 4 Verify that the binary upgrade file (.bin) is located in the home directory of the active user.
When you create a user account on the FTP server, a home directory will be allocated to
the account. When you access the server using the UID and PW you are automatically in
your home directory. The binary upgrade file must be located in this directory.
Step 5 Verify that the extension (.bin) is specified for the binary upgrade file.
Step 6 Obtain a new copy of the binary installation file. It is possible that it has been corrupted
somewhere between obtaining the file from Redline, and loading the file onto your FTP
server.
Step 7 Verify that the proper file is loaded onto the proper device. AN100U/UX files have the prefix
"IBU_", while subscriber unit files have the prefix "SUO_". The prefix for UX, SU-I files are
IUX and SUI.
High Latency on Secondary Management Channel (SMC) Latency
The SMC carries the traffic destined for the management processor of the subscriber unit.
Telnet sessions, FTP sessions and ICMP packets destined for a subscriber unit use this
connection. This connection is restricted by the AN100U/UX to 16 kbps, and is considered
very low priority by the scheduler. Thus, this channel is an extremely poor indication of
wireless latency.
6-1
6
Self-Install End User
Troubleshooting
Troubleshooting Self-Install
The RedMAX self-install solution requires the inter-operational functionality between
various system components. Incorrect configuration of any one of these components will
result in problems.
Before beginning the troubleshooting procedures listed here, you must ensure that you
have established wireless connectivity between the subscriber unit and the sector
controller. as outlined in Troubleshooting Device Management Issues on page 5-13. The
sector controller must also be performing according to your baseline values. See
Establishing and Recording the Baseline Configuration on page 2-15.
Basic troubleshooting for the subscriber unit is provided in Appendix , Self-Install End
User Troubleshooting.
Note RMS interoperability issues are addressed in the RMS-specific Redline
Management Suite Administration and Maintenance Guide.
No Data Connectivity
The following sections describe the possible cause of a loss of connectivity between the
subscriber unit and the sector controller.
Enabling Default Uplink Service Flow
The default downlink service flow is always enabled, but the default uplink service flow is
disabled by default in RedMAX 2.0 and later. You can enable the default uplink service flow
as follows:
6-2
interfaces wireless defaultUlSfEnable 1
Updating Subscriber Unit for Default Uplink Service Flow
Any subscriber units that were registered before this command is executed will need to be
reset in order for the change to take effect. You will need to reboot each impacted
subscriber unit:
reboot
The telnet session will be terminated and you will need to login again, once the subscriber
unit has restarted to verify the changes.
Enabling the Secondary Management Channel
The communication protocol between the AN100U/UX and subscriber unit used to
provision the MAC addresses of hosts located behind the SU, relies on the secondary
management channel (SMC). If the SMC is disabled on a particular subscriber unit, the
sector controller will not be notified of the new MAC addresses, and no traffic will be
passed down stream to the SU. The SMC is a subscriber-specific configuration option, and
is disabled by default. Enabling it is a matter of issuing a single command on the selected
subscriber unit:
Step 2 Enter the following command
set managedSS 1
The subscriber unit will automatically reboot, and upon registration, it will attempt to obtain
an IP address. See section 9.3 for any issues regarding establishing the SMC.
The Bridge Filter
An important aspect of RedMAX's self-install functionality is the subscriber unit's built-in
filtering mechanism. These filters are required for the subscriber unit's auto-learning
feature. You must ensure these filters are enabled, otherwise self-install will not work.
These filters are enabled by default, but you can check their status by issuing the following
command in the subscriber unit's CLI:
6-3
Chapter 6 Self-Install End User Troubleshooting
show bridgeFilter
This command is valid for software versions 2.0.21 and later. It replaces the command,
dlLearnFilter, available in earlier versions: The displayed value should be 1, indicating that
the bridge filter is enabled.
The Subscriber Unit Host Limitation
In addition to the operator-configured MAC limitation, the bridge filters impose a maximum
limit of 256 MAC addresses per SU. Additionally, a new host device must transmit traffic
upstream before any traffic will be permitted downstream to that host.
If you are experiencing connectivity issues with a specific host device, while other devices
are working as expected, use the following command to verify that the subscriber unit has
properly learned the host device's MAC:
show learnedHosts
You will see the MAC address of any CPE detected behind the subscriber unit. You can
also verify that detected number of host devices is less than or equal to the maximum
allowed.
Verifying the Host Devices from the Sector Controller
Verify that the host device has been properly provisioned on the sector controller by
issuing the same command on the sector controller, followed by the SU's MAC address.
show learnedHosts 00:09:02:03:ab:cd
Low Throughput
The first step in resolving poor subscriber unit throughput is to verify that device has a
functional wireless link. The link should be configured to allow the maximum data
throughout.
6-4
See Sections 8 and 9 for general instructions on improving link performance. The following
section covers specific causes of low throughput, related to self-install, once wireless
stability has been confirmed.
Classification
Self-install, specifically the auto-MAC learning function, only affects the downlink portion
of provisioning. You must still provision your uplink service flows with the appropriate
service classifiers.
Normally, classification is either pass-all, MAC-based classification, or blank. If uplink
classification is done improperly, it is likely that the traffic will continue to pass across the
default uplink service flow, which is restricted to 8Kbps.
Table 6-1 Self-Install End User Troubleshooting
Problem Corrective Action
Lights on modem are not on. The modem is not powered on, and/or is not working.
Ensure the power adapter and power cords are securely connected to both the
modem and to the wall outlet.
Verify the power outlet is functional. Connect device know working device such as a
radio into the outlet to verify that power is supplied.
Ensure that you have the correct power cords/injectors for the type of device you are
using. Refer to the Outdoor Wireless Access Subscriber Modem (SUO) Installation
Guidelines or to the Indoor Wireless Access Subscriber Modem (SUI) Installation
Guidelines for the required specifications.
Power cycle the modem by disconnecting and re-connecting it to the power supply.
6-5
Chapter 6 Self-Install End User Troubleshooting
Modem is powered on, but
receiving weak or no wireless
signal.
The wireless signal strength as indicated on the modem front panel, labeled WAN
Signal, displays less than 2 lights or the lights are continuously cycling.
The modem is not receiving the proper wireless signal.
Ensure the modem is placed directly in front of a window without any object blocking
the view, including drapes or blinds.
Try repositioning the modem so that it is on its side (i.e. horizontal instead of upright).
and then power cycle the modem.
Turn your modem very slowly to scan the entire view from the window. The lights may
blink as you turn, indicating it has found another wireless signal. If this happens wait
until the blinking stops, and the lights are steady.
Perform a complete scan and note the direction that provides the best signal strength
(most number of lights). Place the modem in this optimum position and keep it there,
using adhesives tape if necessary.
Re-locate the modem to another window facing a different direction and again, scan
the view from the window looking for the strongest signal. This may mean moving to
another room.
Note Windows treated for UV protection, heat shielding, soundproofing, etc may block
your wireless signal. You can check if this is the case, by placing the modem in
front of an open the window. If the signal improves significantly, then this is likely
the problem. However, do not place the modem outside your window as it is
designed for indoor use only.
Modem is on and there is a
wireless signal, but no network
connection.
You cannot connect to the Internet.
Check that your Ethernet cable is securely connected to the modem and to your
device/computer. The LAN System light on the modem front panel should be on.
Ensure that you are using the correct Ethernet cable and connectors.
Verify the Ethernet cable is good, by connecting the cable to another device and then
to your computer. If your computer can still see the other device, then cable is ok. If
the computer loses connection with the other device, the cable needs to be replaced.
Ensure the defective cable is marked accordingly and discarded, so that it is not
re-used.
Ensure that your device/computer is powered on.
Ensure the Ethernet card/port is configured correctly.
Verify the network settings on the your device/computer that is connected to the
modem. Reboot the computer to make sure and changes to your network settings are
updated and take effect.
Table 6-1 Self-Install End User Troubleshooting (continued)
6-6
Network connection fails often. The connection works, but with frequent interruptions.
Make sure the modem is placed directly in front of the window and its direction is
fixed. If the modem orientation has changed (for example, it is moved from its original
location and direction due to cleaning, placement of books or other objects, etc.) then
you may experience interruptions.
Turn your modem very slowly to scan the entire view from the window. The lights may
blink as you turn, indicating it has found another wireless signal. If this happens wait
until the blinking stops, and the lights are steady.
Perform a complete scan and note the direction that provides the best signal strength
(most number of lights). Place the modem in this optimum position and keep it there,
using adhesives tape if necessary.
Network connection is too slow. The connection is established, but is much slower than expected.
The speed (bandwidth) may depend on the time of day, and how many other users
are active. For faster speeds use the service during off-peak hours.
The bandwidth depends on the service type selected. You may wish to consider
upgrading your service in order to get more bandwidth.
Table 6-1 Self-Install End User Troubleshooting (continued)
7-1
7
Disaster Recovery
Overview
This chapter provides some very basic guidelines for recovery of your RedMAX
network.These guidelines can be used in addition to other plans that you may have for your
entire network.
If you are new to recovery planning, make sure that you research the subject thoroughly
before starting your disaster recovery project. You may want to consider hiring a consultant
to help with your project planning. Disaster recovery planning is not a two-day project, nor
is it a project that once completed, you can forget about. An effective recovery plan must
be maintained constantly and tested regularly.
The primary objective of your plan is to enable your network to survive a disaster and to
re-establish normal business operations within a reasonable time frame. The goals of your
plan should be to:
Identify potential weaknesses and address any issues;
Minimize the duration of a serious disruption to network operations;
Facilitate effective co-ordination of recovery tasks; and
Reduce the complexity of the recovery effort.
Some basic examples are provided here as well as suggestions for a recovery plan.s
Impact Assessment
The first step of your plan is to define an impact assessment plan for all equipment and
applications that are part of the network environment. This plan will require you to:
identify critical systems, processes and functions;
assess the economic impact of incidents and disasters that result in denial of access
to systems, services and facilities;
assess the length of time that your business can survive without access to systems,
services and facilities.
Your impact assessment plan should then be used as a basis for identifying systems and
resources required to the critical systems, processes and functions.
7-2
Lightning Strike
Lightning damage may occur either as a result of a direct lightning strike to the building or
tower or more commonly, as a result of the induced effects of a lightning strike some
distance away. Lightning which strikes kilometres away may cause electrical surges which
travel long distances on power and telecommunications lines.
When preparing a disaster recovery plan for a lightning strike you may first want to look up
the lightning ground-flash density (LGD) of your area. This is the average number of direct
lightning strikes per square kilometre of your area in one year.
The next step is to investigate the geography of your area and use the rules outlined in the
applicable standards to determine what percentage of those strikes to your area are likely
to terminate on your building and what percentage are likely to cause induced surges.
Quantifying the risk will allow you to make an informed decision about the lightning
protection measures which need to be employed at your site.
If you are not able to investigate this issue, consider contacting a lightning protection
company who can provide both a a lightning protection system and a disaster recovery
plan.
No matter how comprehensive your lightning protection system is, your network equipment
may still incur damage from a lightning strike.
Step 1 When it is safe to access the outdoor equipment, you need to inspect all of the outdoor
equipment as outlined in Verifying Power and RF Signal Cabling on page 4-6.
Step 2 You will need to compile a list of required replacement equipment. Ideally, the required
replacement items will be among your available spares, possibly reducing network
downtime. See Planning/Scheduling Equipment Maintenance on page 2-14.
Wind Damage
In most cell planning designs, your antenna needs to be installed at the highest point in a
given area. However, gusting wind will also be a common occurrence at this same location
and it is therefore, important to take wind loading into consideration.
As with the lightning example above, preparing a disaster recovery plan for wind damage
should start with characterizing the your site exposure to excessive wind. For example a
site located in a coastal area will have increased exposure to wind and corrosion than a
site that is inland.
Wind loading specifications are provided with the antenna. You may want to perform you
own calculations based on your proposed antenna locations.
Another consideration is repetitive strain on antenna mounting hardware and brackets. If
your antenna is subject to constant windy conditions, you will need to check your outdoor
installation regularly and ensure all connections are secure. Additional strain from ice
buildup or sand abrasion will also contribute to metal failure. To avoid failure due to metal
fatigue you may need to replace mounting hardware every few years.
7-3
Chapter 7 Disaster Recovery
Step 1 If you notice any degradation in signal strength after a wind storm, you will need to verify
the position of your antenna. Refer to your recorded values for antenna placement and
ensure the antenna matches these settings.
Step 2 If the antenna has been damaged, it must be replace as outlined in Replacing the
Antenna on page 4-4. Depending on the severity of the damage, you will also need to
replace the RF cable between the radio and the antenna.
Step 3 Ideally, the required replacement items will be among your available spares, possibly
reducing network downtime. See Planning/Scheduling Equipment Maintenance on
page 2-14.
Extreme Temperature Exposure
Another factor to consider when preparing your disaster recovery plan is equipment
exposure to extreme temperatures.
Indoor equipment can be protected with heating and air conditioning systems; however the
outdoor equipment may be exposed to both hot and cold temperature extremes.
Additionally high humidity levels can also impact performance if not addressed by proper
installation and routine maintenance.
7-4
A-1
A
Event Log Scripts
Overview
Redline provides a set of scripts that can be used to parse the syslog output generated by
Redlines AN100U/UX system.These scripts are available from the Redline Partner
website.
In order to use these scripts on your computer you must install and configure Perl 5.10.
(http://dev.perl.org/perl5/).
All of these scripts are based on the following format for the syslog files, unless indicated
otherwise:
If your source files are in another format you will need to either update the scripts or modify
the contents of the syslog files to obtain the desired results. Always retain the original files,
by making backup copies and storing them separately from the files on which you are
working.
Script - scan.pl
Overview
This script provides a per-subscriber and per-sector summary of the de-registrations
recorded in the supplied syslog files.
This script supports both RedMAX 2.0 and 2.1 subscriber unit naming conventions (i.e.
MAC or subscriber unit name.
Example A-1 Syslog File Format
Dec 02 05:39:59 SC-5001-1 SS Deregistered: 00:09:02:03:DB:78 (rngRetries)
A-2
Example A-2 Example of Inventory.csv
Index NE
name
NE type IP address MAC address Software
active
version
Software
inactive
version
Downlink
frequency
(MHz)
Uplink
frequency
(MHz)
Serial number
18 SC_1 AN100U 192.168.0.6 00:08:02:01:22:c3 2.0.26 2.0.26 3775.25 3775.25 3324-0100-01376
19 SC_2 AN100U 192.168.0.7 00:08:02:00:d1:6a 2.0.26 2.0.26 3782.25 3782.25 3324-0100-01377
20 SC_3 AN100U 192.168.0.8 00:08:02:00:d1:2e 2.0.26 2.0.26 3789.25 3789.25 3324-0100-01378
21 SC_4 AN100U 192.168.0.9 00:08:02:00:c0:a3 2.1.13 2.0.26 3796.25 3796.25 3324-0100-01379
22 SC_5 AN100U 192.168.0.10 00:08:02:00:c0:0f 2.1.17 2.0.26 3675.25 3675.25 3324-0100-01380
23 SC_6 AN100U 192.168.0.11 00:09:02:00:d1:b3 2.1.17 2.0.26 3682.25 3682.25 3324-0100-01381
24 SC_7 AN100U 192.168.0.12 00:09:02:00:d1:2f 2.1.17 2.0.26 3689.25 3689.25 3324-0100-01382
25 SC_8 AN100U 192.168.0.13 00:09:02:00:c0:6b 2.1.17 2.0.26 3696.25 3696.25 3324-0100-01383
26 SC_9 AN100U 192.168.0.14 00:09:02:01:22:9d 2.1.17 2.0.26 3771.75 3771.75 3324-0100-01384
27 SC_10 AN100U 192.168.0.15 00:09:02:01:22:7a 2.1.17 2.0.26 3778.75 3778.75 3324-0100-01385
A-3
Appendix A Event Log Scripts
Redline Communications Inc.. Confidential and Proprietary
Input Requirements
This script scans every file within the working directory with the extension of .log.
This script requires that the file inventory.txt be present in the working directory. This file
is used to provide a translation between IP address and sector name.
Optionally, a file named exceptions.txt can be placed in the working directory. This file
should contain, one per line, the name or IP address of any sector controllers you wish to
exclude from the generated report.
Usage
To use the script, enter the following at the command line:
perl scan.pl
Once processing is complete, the results are saved directly to the.csv file, that is named
based on the date/time that the script was executed.
You can limit the execution to a single subscriber unit based on the following command line
argument:
perl scan.pl -s <MAC Address> or <subscriber name>
Output
The output for this script will be output to a.csv file. This file is divided into four sections.
First, the script will print an overall summary that includes the following:
the total number of de-registrations found
the number of unique subscriber units that de-registered
the number of de-registrations due to re-ranging
the number of de-registrations due to retries.
In the second section, a list of the top 100 subscribers is provided. This list is ordered by
the number of de-registrations from greatest to least. For each subscriber, its sector and
frequency are also be included, as well a breakdown of the number of de-registrations due
to re-ranging and retries.
In the third section, the script prints the total number of de-registrations for each sector.
and in the last section the total number of de-registrations encountered at each frequency.
See Subscriber Unit De-Registration on page 5-28 for information on possible causes of
de-registration.
A-4
Example A-3 Sample scanOutput.csv
Total deregistrations: 48742
Total number of SSs deregistered: 3873
Total due to Re-Ranging: 8863
Total due to rngRetries: 39873
Top 100 worst subscribers:
SSId Total Dereg # of RRNG
Dereg
# of RRET
Dereg
SCId SC Freq
00:08:02:03:CC:32 504 132 372 SC_3 3778.75
00:08:02:12:53:60 498 175 323 SC_1 3675.25
00:08:02:03:CC:32 441 191 250 SC_1 3671.75
00:08:02:03:D0:FE 383 160 223 SC_1 3671.75
00:09:02:12:99:7A 287 92 195 SC_3 3685.75
...
De-registrations per sector:
SCId Total Dereg # of RRNG
Dereg
# of RRET
Dereg
SC_4 9078 20 9058
SC_2 1788 224 1564
SC_1 1490 453 1037
SC_2 986 117 869
SC_2 888 175 713
...
De-registrations per frequency:
Frequency Total Dereg # of RRNG # of RRET
3792.75 10818 565 10253
3671.75 5972 1523 4448
3675.25 3735 1059 2675
3685.75 3661 752 2909
3778.75 3593 693 2899
3785.75 2471 413 2056
3696.25 2453 633 1820
3775.25 2295 455 1840
A-5
Script errorReport.pl
Overview
This script provides a report on the number of GPS detection failures, and GPS loss of
synchronization errors reported in the supplied syslog files.
Additionally, this script monitors the elapsed time between the following event log
messages:
Synchronization with GPS is Not Detected is logged
GPS Synchronization Ok.
If the elapsed time is 30 seconds then this sequence indicates that the GPS has likely gone
into holdover mode.
Lastly, this script reports cable disconnects, LO1, LO2 and RRF errors.
Input Requirements
Usage
To use the script, enter the following at the command line:
perl errorReport.pl
Once processing is complete, the results will be printed to the screen. You can store the
report directly to file, by redirecting the output to a file using the following command:
perl errorReport.pl > errorReport.txt
Output
This script is divided into different sections for each type of error.
A-6
Example A-4 Sample Output from errorReport.pll
GPS not detected for each SC:
10.20.128.6 -> 1
10.16.128.21 -> 1
10.16.144.16 -> 3
...
GPS sync lost for each SC:
10.18.0.6 -> 1
10.20.80.16 -> 1
10.16.144.16 -> 4
...
The following potential squelches were found:
10.20.128.21 -> OCT/28 18:16:40 -> 32 seconds
10.20.128.21 -> OCT/28 18:28:24 -> 29 seconds
10.20.128.21 -> OCT/28 18:36:24 -> 33 seconds
...
Local sync lost for each SC:
10.16.32.13 -> 1
10.16.48.16 -> 1
...
IF cable disconnects for each SC:
10.27.0.16 -> 32
10.20.64.16 -> 1
...
LO1 errors for each SC:
10.27.0.16 -> 30
10.20.64.11 -> 1
...
LO2 for each SC:
10.27.0.16 -> 6
10.20.64.11 -> 2
...
RRF errors for each SC:
10.20.128.6 -> 1
10.27.0.16 -> 4
...
A-7
Script checkTime.pl
Overview
This script is used to generate a report on de-registration rates per hour each day. For
example, if the syslog files provided, encompasses 15 days, this script will allow you to
determine the total number of de-registrations encountered between 9h00 and 10h00 on
each day, during that time period.
Input Requirements
Usage
To use the script, enter the following command at the command line:
perl checkTime.pl
perl checkTime.pl > checkTime.txt
Output
This script prints the total number of de-registrations recorded at a given hour. It does not
print any time periods for which no de-registrations were found, so keep this in mind when
you are importing this data into another application for further analysis.
Example A-5 Sample Output from checkTime.pl
00 hrs: 15551
01 hrs: 13102
02 hrs: 12250
03 hrs: 6235
04 hrs: 5191
20 hrs: 17615
21 hrs: 16607
22 hrs: 16635
23 hrs: 18429
A-8
Script checkDailyPerSector.pl
Overview
This script is used to determine the number of de-registrations encountered by each
sector, for each day within the syslog time span.
Input Requirements
Usage
perl checkDailyPerSector.pl
Output
This script will generate a comma-separated file (.csv) for each sector encountered in the
syslog files. Within each file, each line will denote the date and total de-registrations
encountered on that date. These files can be easily imported into a spreadsheet
application for further analysis.
The output for this script will be separated into a single.csv file for each sector controller.
The following shows one example.
Script findNoisefloor.pl
Overview
This script is used to gather the measured noise-floor value from a large number of
sectors.
Example A-6 Sample Output from checkDailyPerSector.pl
17-Jun 24
19-Jun 60
20-Jun 71
21-Jun 61
22-Jun 50
A-9
Input Requirements
A text file named ips.txt must be located in the working directory. It must include the IP
address of each sector to be polled, one per line.
Note This script requires that the login and password on each sector is the same, and
uses the default debug/Redline account. If this account information has been
modified, you will need to modify the script accordingly.
Usage
perl findNoisefloor.pl
perl findNoisefloor.pl > report.txt
Output
At each iteration, this script will print to screen the IP address of the sector polled, and the
returned noise floor value.
Example A-7 Sample Output from findNoisefloor.pl
172.27.0.4 -> -96.7 dBm
172.27.0.5 -> -102.7 dBm
172.27.2.4 -> -103.8 dBm
172.27.2.5 -> -105.5 dBm
172.27.2.6 -> -97.5 dBm
172.27.4.4 -> -99.7 dBm
172.27.4.5 -> -99.7 dBm
172.27.4.6 -> -105.5 dBm
172.27.6.4 -> -105.5 dBm
172.27.6.5 -> -105.5 dBm
172.27.8.4 -> -100.1 dBm
172.27.8.5 -> -102.0 dBm
172.27.8.6 -> -100.1 dBm
A-10
B-1
B
AN100U/UX Event Log
Messages
The following events are displayed in the sector controller event log. This list provides a
description of the message and some basic information regarding the probable cause and
possible corrective action, as applicable.
Additional information on specific messages and how the event messages are determined
are provided at the end of the table and reference from the corresponding event log
message within the table.
This following messages are grouped by functionality. Within each group, the messages
are sorted alphabetically.
Classification Messages RF-Related Messages
Developer Messages Startup Messages
IDU-Related Messages Sub-Channelization Messages
Initial Ranging Messages Synchronization Messages (See also
Appendix D, Synchronization Event
Log Messages.
ODU-Related Messages Upgrade Messages
Restore Messages
Table B-1 AN100U/UX Event Log Messages
Message Description Comment
Classification Messages
NOTICE: Default Uplink
Service Flows are Disabled
No traffic will be received from the
subscriber unit while the uplink flows
are disabled.
Enable the flows as required.
NOTICE: Pass-All Classifier
has been created for SFID [x]
All unclassified traffic will be
forwarded to this downlink service
flow.
This is security issue and should not be allowed.
B-2
WARNING: Classification
Failure - Invalid DSAP
The following conditions must be true:
The value of the Destination Service
Access Point (DSAP) must be <256
and not equal to 170.
Set the DSAP to a value less than 256, but not
equal to 170.
DSAP is the Destination Service Access Point,
an 8-bit field that allows the upper layer of the
network stack (such as the Logical Link Control
(LLC) layer) to keep track of multiple
connections. This is one of the packet
classification criteria.
Failure - Invalid Ethertype
The following condition must be true:
The value of Ethertype must be
between 1500 and 65536.
The Ethertype indicates the length of an LLC
frame. The range (between 1500 and 65536) is
used as Ethertype sub-protocol identifier.
Set Ethertype to a value between 1500 and
65536.
WARNING: Invalid IP
source/destination Port
PortLo < PortHi < 65536.
The source/destination port may be used for
classification purposes. If the port value from the
packet is between Port Low and Port High, then
the packet matches this classification criterion.
This is 16-bit field and the maximum value can be
65535.
Failure - Invalid IP Protocol
IP Protocol < 256
IP Protocol is 8-bit field. The maximum value is
255.
Warning: Invalid Source Mask The IP Mask shall be specified by a
number of contiguous one-bits starting
from left to right.
For example, the IP mask of 255.255.255.0 is
correct, but 255.0.255.255 is incorrect.
Failure - Invalid MAC
Destination Mask
The MAC Mask must be specified by a
number of contiguous bits starting
from left to right.
For example, the MAC mask of
FF:FF:FF:00:00:00 is correct, but
FF:00:00:FF:FF:FF is incorrect.
Failure - Invalid MAC Source
Mask
The MAC Mask must be specified by a
number of contiguous bits starting
from left to right.
For example, the MAC mask of
FF:FF:FF:00:00:00 is correct, but
FF:00:00:FF:FF:FF is incorrect.
Failure - Invalid User Priority
UserPriLo < UserPriHi < 8
The User Priority is a 3-bit field (the maximum
value is 7) which can be used to classify packets.
If the User Priority value from the packet is
between [UserPriLo, UserPriHi], then the packet
matches this classification criterion.
Failure - Invalid VLAN
VLAN ID < 4096
Set the VLAN ID to a value less than 4096.
Failure: Too many Destination
Port Ranges
The current setting exceeds the
maximum value of 63.
Reduce the number of destination port ranges.
Table B-1 AN100U/UX Event Log Messages (continued)
B-3
Appendix B AN100U/UX Event Log Messages
Failure: Too many Destination
Ports
Reduce the number of destination ports.
Failure: Too many Ethertype
values
Reduce the number Ethertype values.
Failure: Too many IP
Destination Addresses
Reduce the number of IP destination addresses.
Failure: Too many IP Source
Addresses
Reduce the number of IP source addresses.
Failure: Too many Compound
Rules
maximum value of 511 (maximum
number of active DL classifiers)
Reduce the number of compound rules.
Failure: Too many IP
Destination Ranges
Reduce the number of destination IP ranges.
Failure: Too many IP Source
Ranges
Reduce the number of source IP ranges.
Failure: Too many MAC
Destination Addresses
maximum value of 16383 (Including
learned MAC Hosts).
Reduce the number of destination MAC
addresses.
Destination Ranges
Reduce the number of destination MAC ranges.
Source Addresses
Reduce the number of source MAC addresses.
Source Ranges
Reduce the number of source MAC ranges.
Failure: Too many Source Port
Ranges
Reduce the number of source port ranges.
Failure: Too many Source
Ports
Reduce the number of destination port ranges.
B-4
Developer Messages
Access Address: [value in
hex]
This message is displayed only after a
watchdog reset occurs. It provides
information about the software
exception which caused the watchdog
to reset.
This message is not intended for the end
user/operator. If you see this message please
Cause Register: [value in hex] This message is displayed only after a
to reset.
Error address: [value in hex],
Error ID: [value in hex]
to reset.
Exception Program Counter:
[value in hex]
to reset.
P2-Task: [task name] This message is displayed only after a
exception which caused the
watchdog.
IDU-Related Messages
Error when reading from i2c
memory
Hardware failure. There was an error
while reading configuration data.
No action will be taken by the AN100U/UX
software to correct this error. The unit should be
returned. Please contact
Error when writing to i2c
memory
Hardware failure. There was an error
while writing some configuration data.
No action will be taken by the AN100U/UX
software to correct this error. The unit should be
returned. Please contact
Event log cleared by user Self explanatory Information only. There is no action required.
B-5
NOTICE: Watchdog is
Disabled
A jumper installed during factory
burn-in was not properly removed
before shipping.
This unit must be returned. Contact
support@redlinecommunications.com for an
RMA number.
P1 Watchdog Reset The P1 processor has encountered an
exception, and has prompted a reboot
of the AN100U/UX.
Please send the complete contents of the
AN100U/UXs event log to
P2 Watchdog Reset The P2 processor has encountered an
exception, and has prompted a reboot
of the AN100U/UX
Please contact
support@redlinecommunications.com and then
send the complete contents of the AN100U/UXs
event log.
Parameters are reset to
factory defaults
This message appears after the user
has initiated a long-reset to restore the
device's factory default settings.
Information only. There is no action required.
Parser Watchdog Event The air interface was temporarily
disabled due to an error in the receive
path.
The air interface will be re-enabled automatically
and the sector controller will be able to operate
normally. Reboot is not required.
Software Exception A system reboot was caused by a
software exception. You may also see
the additional messages: P1 or P2
Watchdog Reset.
Reboot the system again to see if the message
clears.
If the message re-appears, contact
WARNING: DL aggregated
Guaranteed Rate exceeds
capacity
The aggregate guaranteed minimum
rates configured for service flows
using nRTPS, RTPS and UGS
scheduling exceeds the downlink
capacity of the sector.
Minimum rates can no longer be guaranteed. You
can either improve your links such that the use of
a less robust coding rate is possible, or remove
some guaranteed services.
If you wish to over subscribe, you should use a
non-guaranteed scheduling type such as Best
Effort.
WARNING: Indoor Unit
Temperature too Low
This message is displayed when the
IDU temperature drops below -10C.
Check your heating/cooling (HVAC) system.
WARNING: Invalid IP
Destination Port
The specified IP port is not available or
is invalid.
Review your device configuration and verify the
IP address of the destination port.
WARNING: Invalid IP Source
Port
The specified IP port is not available or
is invalid.
Review your device configuration and verify the
IP address of the source port.
B-6
WARNING: UL aggregated
Guaranteed Rate exceeds
Capacity
The aggregate guaranteed minimum
rates configured for service flows
using nRTPS, RTPS and UGS
scheduling exceeds the uplink
capacity of the sector.
Minimum rates can no longer be guaranteed.
You need to improve your links such that the use
of a less robust coding rate is possible, or
remove some guaranteed services.
If you wish to over subscribe, you should use a
non-guaranteed scheduling type such as Best
Effort.
WRONG CRC over I2C The stored interface configuration
data has failed an integrity check.
All interface (other than service provisioning)
configuration will be reset to their default values.
This is only a problem if it happens more than
once, concurrently.
Wrong DCD Count in DBPC:
[SS Id]
A subscriber unit [SS Id] sent a
Downlink Burst Profile Change
(DBPC) request with an incorrect DCD
counter.
If this event occurs continuously for the same
subscriber, then a subscriber reset (from the
sector controllers SS Info page) is
recommended. See Rebooting the Subscriber
Unit on page 3-2.
Initial Ranging Messages
Broadcast Downlink DSA
Failure: [SS Id] (rsp)
DSA (Dynamic Service Addition) for
the default downlink/uplink service
flow failed because the subscriber unit
(SS ID) sent an unsuccessful
response code (rsp).
These messages may be logged during initial
ranging, registration and service flow creation
Default Uplink DSA Failure:
[SS Id] (rsp)
DSA (Dynamic Service Addition) failed
because the subscriber unit (SS ID)
sent an unsuccessful response code
(rsp).
The sector controller will try to create the service
flow after 10 seconds. The maximum retry limit is
3.
If this event occurs more than 3 times and the
service flow remains rejected, reboot the
subscriber unit. See Rebooting the Subscriber
Unit on page 3-2.
Also make sure that adaptive modulation is
enabled (Admin Tools > Advanced
Configuration page). if you are not using
Adaptive Modulation, then reduce the downlink
modulation.
DSA Failure: [SS Id], SFID [x]
(retries)
because of message retransmissions.
DSA Failure: [SS Id], [SFID [x]
(rsp)
sends n unsuccessful response code
(rsp).
B-7
DSA Failure: [SS Id], SFID [x]
(too many)
[nn]DSA (Dynamic Service Addition)
failed because there are too many
provisioned service flows for this
subscriber unit.
Try to reduce the number of active service flows
for the subscriber unit, identified by [SS ID].
DSC Failure: SFID [x] (retries)
{nn]
DSC (Dynamic Service Change) failed
because of message retransmissions.
DSC Failure: [SS Id], SFID [x]
(RuleIndex not found)
DSC (Dynamic Service Change)
because a classifier for a downlink
service flow cannot be changed
because the classification rule index
cannot be found.
Contact support@redlinecommunications.com.
DSC Failure: [SS Id], SFID [x]
(rsp)
DSC (Dynamic Service Change) failed
sends an unsuccessful response code
(rsp).
FPC: [SS Id] (power: x) The sector controller has sent a Fast
Power Control message to the
subscriber unit (SS ID).
The power (x) is a signed integer that
represents quarters of a dBm.
This is not an alarm condition.
SBC Failure: [SS Id] The subscriber unit (SS ID) has sent
an SS Basic Capabilities (SBC)
request before the initial ranging was
complete.
SS Basic Capabilities (SBC) negotiation is a
protocol stage during the network entry process
described by the 802.16 standard.
SS Deregistered: (corrRetries
[t], [f])
A subscriber unit (SS ID) is
deregistered due to a maintenance
ranging failure.
The correction retries counter has
been reached.
The time offset [t] and the frequency
offset [f] are reported.
After subscriber unit de-registration due to
maintenance ranging failure the subscriber unit
will re-entry the network.
This event may be the result of the subscriber
unit link quality being affected by multipath
interference.
SS Deregistered: [SS Id]
(DREG-Req)
The user forces a subscriber unit (SS
ID) to deregister.
(Re-Ranging)
A registered subscriber unit (SS ID)
attempts initial ranging because it has
lost the link and is restarting the
registration process from the
beginning.
(rngRetries)
A subscriber unit (SS ID) is
deregistered because the sector
controller did not receive OFDM signal
from that subscriber unit.
Information only. There is no required action.
This event may be logged if the path loss
(attenuation) is too high or strong interference is
present.
B-8
SS Registration Failure: [SS
Id] (Auth)
A subscriber unit (SS ID) fails to
register because the HMAC key (Hash
Message Authentication Code) is
wrong.
The subscriber unit will re-register automatically.
Id] (T13)
Registration failed because T13 timer
(the time between registration
response and TFTP complete
message) expired.
This subscriber unit was not able to get an IP
address.
Check your DHCP server, if IP addresses are
being assigned by a DHCP.
Id] (T17)
A subscriber unit (SS ID) fails to
register because the T17 timer (SS
Authorization timeout) has expired.
This event indicates that there is an issue with
the subscriber unit certificates. If this event
occurs continuously, then reload the certificates
into the subscriber units flash memory. Refer to
the Outdoor Wireless Access Subscriber Modem
(SUO) Installation Guidelines
Id] [nn](T9)
T9 Registration Timeout expired. Information only. There is no action required.
If this event occurs rarely, there is no action
required. If it happens frequently (more than
once, daily), then make sure make sure that
adaptive modulation is enabled (Admin Tools >
Advanced Configuration page). if you are not
using Adaptive Modulation, then reduce the
downlink modulation.
SS Rejected The subscriber unit (SS ID) did not
successfully complete the initial
ranging process.
The subscriber unit (SS ID) will automatically
retry the initial ranging process.
SS Rejected. Unsupported
MAC Version
A subscriber unit which reports an
unsupported MAC version tried to
perform initial ranging.
Unsupported MAC version should never happen
with Redline subscriber units.
If this event occurs with other vendor CPE, then
contact the CPE vendor.
AN100U/UX support MAC version 4.
SS Rejected: (corrRetries
[nn],)
A subscriber unit (SS ID) is forced to
restart the network entry process due
to maintenance ranging failure.
The correction retries counter has
been reached.
SS Rejected: (rngRetries) A subscriber unit (SS ID) is forced to
restart the network entry process
because the sector controller is not
receiving OFDM signal from that
subscriber unit.
B-9
SS Reset Command: [SS Id]. The user has reset the SS. Information only. There is no action required.
SS Reset: [SS Id] The sector controller sent a reset
command because the default
(downlink or uplink) service flow
creation failed.
SS: [SS Id] (Re-Init Ranging) A subscriber unit was re-attempting
initial ranging while it was in the
middle of the registration process.
The subscriber unit (SS ID) has lost
the link and starts the registration
process from the beginning.
Timing anomalies reported by
SS: [SS ID]
The subscriber unit (SS ID) cannot
apply the timing corrections sent by
the sector controller.
If this event occurs continuously, then contact
NTP-Related Messages
NTP Client: Invalid address The IP address of SNTP server cannot
be resolved
Verify that you have specified the proper address
for your SNTP server.
NTP Client: Server Unsync The received timestamp is 0, or the
SNTP server suggests it is not
synchronized
Problems with excessive network congestion or
delay can cause synchronization to fail.
Allow the AN100U/UX to refresh the time again.
If the problem persists, verify the network
connectivity between the AN100U/UX and the
SNTP server
NTP Client: Timeout The SNTP server does not reply to
SNTP requests
Verify that the SNTP service is started on your
server, and that there are no firewalls interfering
with communication between the AN100U/UX
and the time server.
NTP Client: Version
unsupported
SNTP server version number is
greater than 3.
SNTP versions greater than 3 are only
used for IPv6 networks. The
AN100U/UX currently, only supports
IPv4.
Verify the version number of your SNTP server
and downgrade the application as required.
ODU-Related Messages
Cable Compensation Ok.
Value = [v]
The attenuation of the IF cable is
within normal operating parameters.
The cable compensation-related messages are
not displayed when an HTB is used.
B-10
CRITICAL: Cable
Compensation Failed
The cable compensation procedure
initiated at startup, has failed.
Repeat the procedure, if the cable compensation
procedure fails again, consider replacing the
cable. See Interface (IF) Cable on page 4-6.
The cable compensation-related messages are
not displayed when HTB is used.
CRITICAL: High Power Radio
FPGA loading Failed
After the ODU upgrade, the new
firmware cannot be loaded into the
ODU FPGA.
The default firmware is re-loaded.
This message is displayed when the default
image cannot be loaded after an ODU upgrade
failure.
If this event repeat itself and the upgrade cannot
be completed successfully, then contact
CRITICAL: IF Cable
Disconnected
The IF cable between the IDU and
ODU has been disconnected.
If this was not done intentionally for maintenance
purposes, then ensure that you do not have any
loose connections at the radio or the IDU. See
Interface (IF) Cable on page 4-6.
CRITICAL: IF PLL Error The IF chain has encountered a PLL
error. Communication with the ODU
has been interrupted.
This may be a hardware problem with the ODU.
Please contact
CRITICAL: IF PLL Error The IF chain has encountered a PLL
Please contact
CRITICAL: LO[X] Error There has been a hardware problem
with local oscillator 1 or 2.
There is a problem on the AN100U/UXs ODU.
See LO1, LO2 and Radio Reference Frequency
Errors on page 5-21.
CRITICAL: ODU Temperature
is too High
The operating temperature of the
AN100U/UX ODU is too high to
continue operation.
The IDU will temporarily suspend
operation to avoid damage.
This is most often caused by excessive ambient
temperatures.
CRITICAL: Radio Reference
Frequency Error
There has been a hardware problem
with the synchronization of the ODUs
reference frequency.
See LO1, LO2 and Radio Reference Frequency
Errors on page 5-21
CRITICAL: Rx PLL Error The IF chain has encountered a PLL
Please contact
Flash Erase Operation Failed.
Default Image Selected.
The ODU upgrade process failed. This message is specific to the AN100UX. Retry
the upgrade procedure. If the upgrade fails again
then contact
B-11
ODU upgrade process failed. The ODU upgrade process failed. This message is specific to the AN100UX. You
can retry the upgrade procedure or contact
Power Supply [X] is On Where X is either A or B. This signifies
that the relevant power supply has
been detected and is properly
supplying power to the AN100U/UX.
Primary RF Programming This message indicates which one of
the three programming methods
succeeded when programming the
TB3436F7 radio (radio types 17 or 19
only).
Secondary_0 RF Programming
Secondary_1 RF Programming
Radio Type [XX]: TBXXXXFX This message confirms the type of
radio connected to the IDU. It should
match the radio type printed on the
ODUs sticker.
Secondary_0 RF
Programming
This message indicates which one of
the programming methods succeeded
when programming the TB3436F7
radio.
Upgrade Failed. Default
Image Selected
The ODU upgrade process failed. This message is specific to the AN100UX. You
can retry the upgrade procedure or contact
Upgrading the ODU... The ODU upgrade is in progress. This
operation takes about 6 minutes.
WARNING: Default Image is
Loaded
After the ODU upgrade, the new
firmware cannot be loaded into the
ODU FPGA. The default firmware is
loaded.
This message is displayed when the default
image cannot be loaded after an ODU upgrade
failure.
WARNING: ODU Temperature
is [c] Celsius
The operating temperature of the
AN100U/UX ODU is nearing the limit
of its operating temperature.
No action is taken until the
temperature exceeds the limit.
Most often caused by excessive ambient
temperatures.
Restore Messages
Restore configuration into
active image
The user-provided configuration file
has been applied to the active image
B-12
Restore configuration into
alternate image
The user-provided configuration file
has been applied to the alternate
(non-active) image
RF-Related Messages
Air Interface is Disabled The RF interface has been disabled by
the user.
The option to enable/disable the air/RF interface
is in the Wireless Interface menu of the
AN100U/UXs GUI or CLI interface.
Air Interface is Enabled The RF interface has been enabled by
the user.
The option to enable/disable the air/RF interface
is in the Wireless Interface menu of the
AN100U/UXs GUI or CLI interface.
RF capabilities have changed.
Check RF and PHY
parameters and re-activate
the RF interface.
This message usually occurs when a
new radio is connected to an
AN100U/UX, and it is of a different
frequency range than previously
configured.
For example a 3.4-3.6GHz radio is
connected to an AN100U/UX
previously configured to use
3.6-3.8GHz)
Check RF and PHY parameters and re-activate
the RF interface. See Checking RF and PHY
Parameters on page 3-14.
WARNING: Unknown
Interference was Detected on
the Uplink Channel [-x dBm]
The sector controller has detected
unknown interference.
The sector controller may also report the
interference strength (-x dBm). You may need to
perform a spectrum analysis to determine the
source of the interference. See A Guide to Field
Spectral Analysis.
Also see Interference Messages at Startup on
page B-19 for information on how the sector
controller determines that there is interference
on the uplink channel.
WARNING: Uplink Channel
Conflict with [BS ID] [-x dBm]
A conflict with another sector
controller was detected. The BS ID
and the interference strength are
reported.
Verify proper synchronization between the sector
controllers in question, and revisit your channel
plan if problems persist.
Also see Interference Messages at Startup on
page B-19 for information on how the sector
controller determines that there is interference
on the uplink channel.
B-13
Startup Messages
Average Noise Floor on the
Uplink Channel = -x dBm
The sector controller reports the level
of noise measured at the RF input.
There is no required action, if the reported level
is below -100 dBm for 7 MHz and -103 dBm for
3.5 MHz.
See Noise Floor Calculation on page B-20 for
information on how the sector controller
calculates the average noise floor.
CRITICAL: Default FPGA
code loaded. Waiting for
upgrade...
The default firmware has been loaded
into the PHY and MAC FPGAs.
A system upgrade is required. Refer to the
RedMAX AN100U/UX Base Station User Guide.
CRITICAL: FPGA
Programming Failed
PHY and MAC FPGAs cannot be
programmed properly. Possible
firmware corruption.
Upgrade the sector controller to the latest
software version. If you are currently at the latest
software version, then contact
CRITICAL: PHY Initialization
Failed
PHY does not respond to initialization
commands.
CRITICAL: PHY programming
failed.
The PHY is not able to execute Tx/Rx
commands with the current
configuration (channel bandwidth and
cyclic prefix).
CRITICAL: RF programming
failed
The RF does not respond to
initialization commands.
Repeat the system upgrade operation. Refer to
the RedMAX AN100U/UX Base Station User
Guide.
Invalid Radio Type The radio that is connected to the
AN100U/UX is not compatible with the
IDU.
Ensure that you are using the proper radio type.
If you are unsure whether your particular ODU is
compatible with your AN100U/UX, please
This message can also be displayed if the radios
inrush current at startup exceeds that available
from your power supply. In this case the power to
the IDU is interrupted resulting in the message.
See Inrush Current at Startup on page 5-7.
Invalid Radio Type The IDU does not detect an ODU
connected to the IF port.
Ensure all cables are in good repair and are
connected properly. See Replacing a Radio on
page 4-1 for details on verifying the connections.
Long Reset The AN100U/UX has been reset to
factory defaults by the user.
This is accomplished by pressing and holding the
Reset button on the front of the
AN100U/UXchassis for 10+ seconds.
B-14
MAC exception: DL EoF
Interrupt Timeout
A system reboot was caused by a
MAC exception. You may see the
following additional messages:
UL EoF Interrupt Timeout;
Start Scheduling Signal Timeout
MAC exception: Start
Scheduling Signal Timeout
DL EoF Interrupt Timeout;
UL EoF Interrupt Timeout;
MAC exception: UL EoF
Interrupt Timeout
DL EoF Interrupt Timeout;
Start Scheduling Signal Timeout
RedMAX Ver. 2.1.x started Normal startup message indicating
current software version.
Shown once at system startup.
Unknown Hardware Exception A system reboot was caused by a
following additional messages: DL
EoF Interrupt Timeout; UL EoF
Interrupt Timeout; Start Scheduling
Signal Timeout
This does not generate an alarm.
Sub-Channelization Messages
PHY Exception: PUSHERR !!! This message indicates the PHY
exceptions (Rx push error) when
subchannelization is enabled.
This message is specific to the AN100UX. After
one of these exceptions occurs the AN100UX
may recover itself or will need to be rebooted.
PHY Exception: RXOVF !!! This message indicates the PHY
exception (Rx buffer overflow) when
PHY Exception: RXOVLP !!! This message indicates the PHY
exception (Rx overlap) when
B-15
Synchronization Messages (See also Appendix D, Synchronization Event Log Messages
A Slave has failed to detect
the clock signal of a master
The master or slave may not be
configured correctly. The master may
not be generating the required timing
signal. If this is a Master with GPS,
then the GPS signal may be lost.
Follow the synchronization installation guidelines
for installation and troubleshooting of local or
GPS synchronization. Refer to the RedMAX
Base Station Installation Guidelines.
Backup Detected This AN100U is configured as a
Master, and it has detected the
presence of a Backup Master
Backup Function Activated This AN100U is configured as a
Backup Master, and has been
successfully activated
You should see a corresponding message on the
Master device event log, indicating that the
timing signal has been lost.
GPS Detected An external GPS clock source has
been properly detected.
GPS is not Detected A Master with GPS or a Backup
Master cannot detect the signal from a
GPS device on the Synch In port, at
startup.
A trap will be sent to designated SNMP trap
destinations/receivers.
GPS is not Detected A Master with GPS or a Backup
Master can no longer detect the GPS
signal on the Synch In port.
This message, followed by the message GPS
Detected being logged 30-seconds later may be
an indication that your GPS has gone into
holdover mode. See AN100U/UX Operation in
GPS Holdover on page 3-9.
This 30-second signal suppression indicates that
the GPS receiver has been in holdover
continuously for 30 minutes.
GPS is not Detected. Waiting
for GPS...
The Master with GPS cannot detect
the GPS module connected to Synch
In port. The RF interface will not be
started until this problem is resolved.
GPS Synchronization Lost A Master with GPS or a Backup
Master detects the GPS signal, but the
phase offset between the GPS signal
and the internal pulse per second is
outside the tolerable limits of the
system.
A trap will be sent to the designated SNMP trap
destinations/receivers.
Master Detected A slave has detected the presence of
a master.
B-16
Master Function Activated This AN100U/UX is configured as
Master, and it has successfully
activated.
Master or GPS must be
connected. Waiting...
A Backup Master or Slave has not
detected the presence of a Master
with GPS or GPS clock source at the
Synch In port, at startup.
Master with GPS Function
Activated
This AN100U/UX is configured as
Master, and has been successfully
activated.
Other Backup Detected.
Waiting...
The AN100U/UX configured as a
Backup Master has detected another
backup device connected to Synch
Out port.
Only one Backup Master may be configured per
base station. You must configure one of the two
devices as a Slave.
Other Master Detected.
Waiting...
The AN100U/UX configured to act as
a Master or a Master with GPS has
detected another Master connected to
Synch Out port.
Only one Master may be configured per base
station. Set one of the two AN100U/UXs to act
either as a Slave, or Backup Master
Reference Clock Calibration
Done
The reference clock calibration
procedure initiated by the user has
been completed.
Synchronization Failed.
Waiting for Synchronization
Signal...
A sector controller configured as a
Slave has detected the Master or
Master with GPS on start up, but
synchronization failed. It will wait and
try again.
Synchronization Ok Synchronization with the Master or
Backup Master was successful.
Synchronization Signal
Detected
A Slave has detected the clock signal
of from the Master or Backup Master.
B-17
Synchronization Signal not
Detected
The Slave or Backup Master has
previously been synchronized with a
Master, but has since lost the signal
and may have drifted out of phase.
The Slave will continue transmitting, however its
clock will eventually drift out of phase with the
rest of the sector if synchronization is not
restored.
A Slave, previously synchronized with
a Master, has since lost the signal.
The Slave will continue operating, however its
clock will eventually drift out of phase with the
rest of the sector, if synchronization is not
restored.
Synchronization Signal not
Detected. Waiting...
Slave cannot detect the
synchronization signal from the
Master or the Backup Master.
Synchronization with Backup
Failed
Master, has been rebooted, then
detected the presence of a Backup
Master, but has failed to resume
control of the Backup Masters clock.
Synchronization with Backup
Ok
A sector controller configured as
Master, has been rebooted, then
detected the presence of a Backup
Master, and successfully resumed
control of the Backup Masters clock.
Synchronization with GPS is
Lost
Synchronization with a previously
detected external clock source has
been lost
Synchronization with GPS Ok Synchronization with an external GPS
clock has been successfully
completed.
Synchronization with Master is
Lost
A Backup Master that previously
detected the presence of a the Master
clock signal, has since lost the signal.
The Backup Master will provide a clock signal for
the rest of the Slave devices within the base
station until the signal from the Master returns.
Please follow the synchronization installation
guidelines for installation and troubleshooting of
local and GPS synchronization.
Synchronization with Master
Ok
A Backup Master has successfully
synchronized with a Masters clock
signal.
B-18
WARNING: Clock Offset
Close to End of Scale
The reference clock calibration
procedure initiated by the user has
been completed, but the clock offset is
at the boundaries of the AN100U/UXs
capabilities
Consider using a more accurate clock source for
reliable base station synchronization.
Upgrade Messages
Another Upgrade operation is
currently running. Skip SNMP
[CLI,WEB] backup
The user has tried to backup the active
image to the alternate while a software
upgrade is in progress. The command
has been ignored.
[CLI,WEB] restore
The user has tried to apply a
configuration file to either the active or
alternate images while a software
upgrade is in progress. The command
has been ignored.
[CLI,WEB] synchronization
The user has tried to synchronize the
active and alternate images while a
software upgrade is in progress. The
command has been ignored.
[CLI, WEB] upgrade
The user has tried to initiate an
upgrade while another upgrade is
already in progress. The command
has been ignored.
currently running. Skip switch
over
The user has tried to switch software
versions while an upgrade is in
progress. The command has been
ignored.
Synchronization of alternate
completed successfully
Software image and configuration
have been applied to the alternate
image, overwriting its previous
contents.
Synchronization of
configurations not possible
The synchronization of software and
configuration from the active image to
the alternate has failed.
If you see this message, place the AN100U/UX
into monitoring mode in order to further diagnose
the problem. See Monitoring Your System on
page 2-4
B-19
Interference Messages at Startup
At startup, the AN100U/UX (Version 1.2 and higher) performs an RF channel listening
sequence for the purpose of detecting interference on the uplink channel. During this
sequence, the RF is in continuous Rx mode while the PHY is programmed to receive and
interpret a long preamble.
If no preamble is detected by PHY during a one-second period, then no event message
will be displayed in the event log regarding this action and the sector controller will start
and continue with normal operation.
If any preamble is received, the sector controller will continue to listen to the channel for
another 3 seconds trying to decode a DL-Map. If any 802.16d DL-Map is decoded
correctly, the following message will be displayed in the event log:
WARNING: Uplink Channel Conflict with [BS Id] ([x] dBm)
This message indicates the BS Id of another sector controller that has the following
RF-PHY configuration that is the same as the uplink channel frequency of this sector
controller
same DL channel frequency
same Cyclic Prefix
same Channel Bandwidth
If a preamble was received but no DL-Map was decoded, the following message is
displayed:
WARNING: Unknown Interference was Detected on the Uplink Channel ([x] dBm)
When interference is detected one of the above messages is displayed in the event log,
however the sector controller will not change the state of the air Interface. The sector
controller will continue with normal operation.
Interference on the uplink can be difficult to detect, so please note the following:
Interference may be present on the uplink channel without being detected at startup.
In this case no message is displayed.
The sector controller may detect a preamble even though the interference is not
caused by another 802.16d system. You may see the second message, in this case.
Even if the RF and PHY parameters are the same (frequency, channel bandwidth,
cyclic prefix), this sector controller may not be able to receive a DL-Map and the
second message will be displayed in this case.
Detecting Interference with Local or GPS Synchronization
The channel listening sequence is slightly more complicated when local or GPS
synchronization is used. In this case the sector controller synchronizes its signal first with
the Master or Master with GPS. After synchronization (frame aligning) is achieved, the
sector controller tries to detect the interference only in the uplink interval of the frame.
B-20
The sector controller will not generally report interference from any other sector controllers
that are synchronized with the clocking signal (local or GPS). However, if the configuration
parameters are not set correctly (for example two synchronized sector controllers use
different frame durations), then interference may be reported, as indicated above
Noise Floor Calculation
During Startup
At startup, if no interference is detected, the sector controller calculates the noise floor
during the one-second (20 receptions of 50 milliseconds each) interval of measurement
and reports this value in the event log. The noise level is the average of all 20
measurements.
During Normal Operation
The noise floor is also updated during normal operation and displayed on the AN100U/UX
Status page.
Whenever there is more than one unused OFDM symbol in the uplink sub-frame, the
sector controller performs a noise measurement and then updates the average noise level
as follows.
The averaging formula used for noise level measurement is:
If Noise(N) < AvgNoise(N-1) then the following averaging calculation is used:
AvgNoise(N) = 0.7 * AvgNoise(N-1) + 0.3 * Noise(N)
If Noise(N) > AvgNoise(N-1) then the following averaging calculation is used:
AvgNoise(N) = 0.3 * AvgNoise(N-1) + 0.7 * Noise(N)
All the values in the formula are expressed in milliwatts, and then the result, AvgNoise(N)
is converted to dBm.
C-1
C
Subscriber Unit Event Log
Messages
The subscriber unit records its status in a log file. You can monitor the contents of the file
when troubleshooting or on a regular basis to monitor subscriber unit operation.
The following table lists most of the messages that can be displayed by the subscriber unit.
This list provides a description of the message and some basic information regarding the
probable cause and corrective action, if required.
Table C-2 on page C-16 lists the remaining messages that are rarely encountered during
normal operation.These messages are provided for information only.
This list is sorted alphabetically be message.
Table C-1 Subscriber Event Log Messages
Message Description Analysis
[nn] based [nn] RF interface
detected.
Reports the RF head/frequency band
detected at startup.
This is the radio which this subscriber will use.
7030-based 3436 RF
(extended cal) interface
detected
This unit is operating in the 3436 RF
range.
This is the radio which this subscriber will use.
Add detected BS ...[BS ID]
f=[nn] kHz,
A new sector controller [BS ID] has
been detected at [nn] kHz, during the
initial scan.
This message is displayed during initial ranging
each time a sector controller is detected. The
new sector controller will be added to the list of
sector controllers to scan during startup.
Add SA ID [nn], Security association ID has been
added.
When privacy is enabled, this is one of the many
steps that subscriber must perform to complete
the authentication process.
Add TEK [nn] for SA ID [nn] Security encryption key has been
added.
C-2
Attempt connection to BS [BS
ID] f=[nn] kHz
The subscriber unit is attempting to
connect to one of the detected sector
controllers.
Authorization and key
exchange complete.
The subscriber unit has been
authenticated by the sector controller.
Authorization FSM state [nn] This is current FSM status. Information only. There is no action required.
Bad Rf Rx Calibration Rev.2
EEPROM
The RF calibration data is invalid
There is an issue with the radio.
The subscriber unit must be replaced.
Contact support@redlinecommunications.com
for details on returning the device.
Add classifier [CID: nnnn, Idx:
nn]
A classifier associated with service
flow ID [CID], with classifier index [Idx]
has been added.
Broadcast Opportunity
Corrupted
Opportunities have been received for
initial ranging, but the opportunity is
not appropriate (i.e. too short) for this
subscriber unit.
This is a problem with the sector controller.
Normally the sector controller will allocate
opportunities based on worst-case modulation
rate.
Broadcast Ranging
Opportunity Received
This message indicates that the sector
controller has provided an opportunity
for subscriber registration.
This message is part of the normal registration
process.
Broadcast Ranging
Opportunity Timeout
This message indicates that the sector
controller has not provided an
opportunity for a new subscriber
registration within the last 10 seconds.
This message may indicate a problem with your
sector controller. Check your sector controller for
any error messages. See Appendix B,
AN100U/UX Event Log Messages.
If this message appears repeatedly, contact your
sector controllers vendor for assistance. Refer to
the RedMAX AN100U/UX Base Station User
Guide.
Classification deleted for CID
XXXX
All of the classifiers have been deleted
for a service flow [CID XXXX].
Classifier deleted [Idx: nn] The classifier [Index: Idx] has been
deleted.
Classifiers deleted for SF with
CID XXXX
All classifiers have been cleared for
the service flow [CID XXXX].
CLI reboot request A system reboot command has been
initiated from the command line
interface,
Table C-1 Subscriber Event Log Messages (continued)
C-3
Appendix C Subscriber Unit Event Log Messages
Configuration restore failed The restore operation failed. You can retry the restore operation. Ensure you
have configured the correct FTP server for the
selected subscriber unit.
Ensure that there is connectivity with the sector
controller.
Ensure the software version that you are
restoring is compatible with the selected
subscriber unit.
Configuration restore
successful
The restore operation was successful. Information only. There is no action required.
Configuration save failed An attempt to save the configuration of
this device encountered an error after
CLI/SNMP request.
Ensure you have configured the correct FTP
server for the selected subscriber unit.
Ensure that there is connectivity with the sector
controller.
Configuration save successful The configuration of the selected
device was saved successfully after a
CLI/SNMP request.
Current BS connection lost.
Restart Initial Scan
The subscriber unit lost connection to
the last detected sector controller and
will restart a scan.
Current BS connection lost.
Skip to next one
During the initial scan, the subscriber
unit lost connection to the last
detected sector controller and will try
registering with the next device on the
list of sector controllers to scan.
Decode Certificate Done [nn] The security certificate is ok. Information only. There is no action required.
Decode Certificate Error The security certificate that was
installed is invalid.
You need to update the security certificate on this
subscriber unit.
See the RedMAX AN100U/UX Base Station User
Guide.
Detected BS table empty.
Restart Initial Scan.
No sector controllers were detected
during the initial scan. The initial scan
is restarted.
Detected BS table reset The detected sector controller table
was reset either at the users request
or as result of changes to the RF
configuration.
DCD Receiving Timeout Five downlink channel descriptors in a
row have been expected and not
received. The subscriber unit will now
restart the ranging process in an
attempt to re-establish wireless
synchronization.
This message is normally a result of some
underlying RF problems.
Follow the steps detailed in the RF
troubleshooting section of this guide to resolve
this problem.
C-4
Deregistration DREG-CMD,
action code: nn
The subscriber unit has de-registered. Check the event log for prior messages. They will
indicate the reason for the deregistration. This
message in itself does not provide the full story.
Deregistration DREG-CMD,
action code: nn
The sector controller has requested
that the subscriber unit should
deregister.
Check the sector controller event log for a
reason. This action is not generated by the SU,
and would not normally occur with a Redline
sector controller.
DHCP Error There has been an error in obtaining a
DHCP lease
Verify that you have a DHCP server properly
configured to provide a lease to your SU. Ensure
that it accepts relayed DHCP requests, as the
sector controller acts as a DHCP relay between
the subscriber unit and DHCP server. Ensure that
the DHCP lease provides the IP address for a
valid ToD server.
Dlfp Error This message indicates that the
subscriber unit could not properly
decode the frames DLFP. As a result,
the entire frame was lost.
It is normal to see these messages occasionally,
especially in unstable or NLOS links. If you see a
lot of these messages, you should attempt to
improve the quality of your SSs link. If your
signal is weak, antenna realignment and an
adjustment of your sectors Reference RSS are
good first steps. You should also verify that you
are not experiencing any interference.
DlfpSignal t/o This is a debug message. An error
was detected in the map (i.e. bad
reception, RF issues, interference)
The DLFP specifies the burst structure of the
frame. No DLFP was detected at all within the
allotted time.
This could be the result of poor reception, RF
issues, or interference. See Troubleshooting
Wireless Link Issues on page 5-18.
Downlink Burst Profile
Adjusted [BP: nn]
Downlink modulation rate has been
adjusted by the sector controller.
Downlink Burst Profile
Change Attempt [BP: nn]
A request to change the downlink
modulation rate has been made based
on locally configured CINR thresholds.
Downlink Channel Inoperable This message is displayed when the
subscriber unit detects the presence
of a sector controller, but is unable to
properly synchronize with it.
Follow the steps detailed in the RF
troubleshooting section of this guide to resolve
this problem.
Downlink SF nn changed Changes have been successfully
applied to the specified downlink
service flow.
Downlink SF nn created [CID:
XXXX, No.Cls: nn]
A downlink service flow has been
successfully created.
C-5
Downlink SF nn not created
(no space) [CID: XXXX]
The subscriber unit cannot create the
specified DL service flow, as there is
not enough remaining memory.
This message should not normally be
encountered. Check the number of service flows
and classifiers you have created per subscriber
unit, and verify that it is within Redlines
supported limits.
DSA Err - DSA-ACK send
retries exhausted [SF Id:
XXXX]
The subscriber unit has attempted to
acknowledge a DSA transaction
unsuccessfully and has exceeded the
maximum number of retries.
Communication error occurred. One message in
transaction was lost. The transaction is
unrecoverable and must be retried.
DSA Rejected - Service Flow
exists [SF Id: XXXX]
The service flow ID assigned by sector
controller already exists locally in this
subscriber unit.
This can occur if the subscriber unit is
de-registered by a sector controller but is not
aware.
This can also happen if DCD is rejected by the
subscriber unit at the final stages of transaction.
Whatever the cause, it is a problem with
inconsistencies between the SF ID database
located on the sector controller and subscriber
unit respectively.
DSC abort by DSC-ACK [SF
Id: XXXX]
A DSC transaction has been aborted
due to an acknowledgement message
not being received by the SU.
This message can be caused by transient
wireless errors. It does not indicated a serious
problem unless it occurs repeatedly. If it does in
fact occur repeatedly, follow the steps in the RF
troubleshooting section of this guide.
DSC Err - DSC-ACK send
retries exhausted [SF ID:
XXXX]
acknowledge a DSC transaction
unsuccessfully and has exceeded the
maximum number of retries.
DSC Err - DSC-RSP send
retries exhausted [SF ID:
XXXX]
acknowledge a DSC-RSP transaction
message unsuccessfully and has
exceeded the maximum number of
retries.
DSC Err - SF or CLS rejected
[SF ID: XXXX]
DSC transaction has been rejected by
sector controller.
See the sector controller event log for a reason.
This event is not initiated by the subscriber unit.
DSC Success [SF ID: XXXX] DSC transaction has been successful. Information only. There is no action required.
DSC-DSD Reject - SF ID not
found
the deletion of a SFID which does not
exist.
Same reasons as above.
DSD Success [SF ID: XXXX] DSD transaction has successfully
completed.
C-6
DSX Action [error] There has been an error in the
creation of a service flow. The
particular failure is detailed in the
message text.
Fundamental system problem, indicating
possible software incompatibilities, provisioning
bug etc. Likely to be caused by an interoperability
problem if a third party sector controller is used.
DSX Add Reject [reason] This message signifies that the
addition of a service flow has been
rejected by the subscriber unit. The
reason for the failure is included in the
message text.
Possible reasons could include:
a lack of system resources
a specified parameter is not supported
a required parameter is not provided
a conflict with another provisioned service
an error during the DSX transaction.
This message is only of concern if it happens
repeatedly.
Error decrypt key System Error Contact support@redlinecommunications.com
Failed to acquire the
time-of-day
Communication with a ToD (RFC-868)
server has not been successful. The
correct time of day has not been
acquired. According to standard, the
subscriber unit must now perform a
MAC reboot and begin network entry
again.
This message implies that an IP address for the
ToD server has been successfully obtained from
a DHCP server, but that communication with said
ToD server has failed. Check network
connectivity between the ToD server and your
sector.
Finished Initial Scan. The initial scan has been listed.
Another message will also be logged
to provide the status of the scan.
Flash configuration updated This message is the result of a restore
operation.
The systems flash configuration was
updated and all settings have been
restored successfully.
Flash parameters set to
default
This message is the result CLI/Web
client operation that changed specific
parameters.
The systems flash configuration was
invalid at boot and has been reset to
the default.
If systems flash configuration was previously ok,
you may want to investigate further.
Flash parameters updated Specific flash parameters have been
updated.
This message is the result CLI/Web
client operation that changed specific
parameters.
FPC (nn) Current: [nn].
Anomaly: Too High
Fast power control (FPC) request log Information only. There is no action required.
C-7
Anomaly: Too Low
Success
Frag: Missing last fragment.
Chain lost
Debug message. Fragmentation error This could be the result of poor reception, RF
issues, interference. See Troubleshooting
Frag: Prev fragment missing.
Subheader: XXXX
Debug message. Fragmentation error. This could be the result of poor reception, RF
Frag: Wrong fsn. Subheader:
XXXX, expected [nn]
Debug message. Fragmentation error. This could be the result of poor reception, RF
Initial Ranging at Maximum
Power [Adj.: +nn]
The subscriber unit has begun initial
ranging with a sector controller, and
has reached its maximum Tx power
while attempting to establish
communication.
During ranging, the subscriber unit will adjust its
power up until it receives an acknowledgement
from the sector controller. If it reaches its
maximum Tx power, it displays this message,
then begins the cycle again at its lowest Tx
power.
Frame number nn nn This message provides additional
information for another message.
Frequency Table Invalid, Can't
start Initial scan
System Error Contact support@redlinecommunications.com
Initial Ranging Req Tx (nn x
0.01 dBm)
Initial range request transmission
reporting the power level reported.
Initial Ranging at Minimum
Power [Adj.: +nn]
The subscriber unit has started initial
ranging with a sector controller, and
has reached its minimum Tx power
while attempting to establish
communication.
Initial Ranging Backoff Contention was encountered with
another subscriber unit while
attempting to perform initial ranging.
The subscriber unit will wait and try
again after the backoff interval.
This message is normal when a number of SSs
are attempting to register at the same time.
Initial Ranging Parameters
Adjusted [TLV Map:
XXXXXXX]
This message displays the parameter
adjustments, requested by the sector
controller.
Initial Ranging Success [TLV
Map: XXXXXXX]
Initial ranging has been completed
successfully. Parameter settings that
are being used are displayed.
C-8
Invalid MAC address This message is displayed when the
MAC address of the subscriber unit
does not belong to Redline.
The system will not function in this
state.
This only happens when Redline software is
loaded onto a non-Redline subscriber unit. This
is not supported by Redline.
Invalid private key file The installed security certificate is
invalid.
subscriber unit.
Guide.
Invalid private/public key.
Deactivate privacy
The installed security certificate is
invalid. Encryption has been
deactivated
subscriber unit.
Guide.
Large Time Adjustment
Received
An excessively large timing correction
has been sent by the sector controller.
This correction has not been applied,
though it has been acknowledged.
This is a problem with your sector controller. It is
possible that the sector controller is
mis-calculating the timing offset of your
subscriber units uplink bursts. Try adjusting the
sector controllers reference RSSI to minimize
the difference between the strongest and
weakest uplink RSSI.
Learn: Ack Add Host
SeqNum[nn]
These 7 messages are part of the host
learning sequence. As host devices
are being added or deleted, these
messages will be added to the event
log.
Normal operation. There is no action required.
Learn: Ack Del Host
SeqNum[nn]
Learn: Add New Host[XXXX
XX:XX:XX:XX:XX:XX]
Learn: Del Old Host[XXXX
XX:XX:XX:XX:XX:XX]
Learn: Deregistered Normal operation. There is no action required.
Learn: Prov LearnCtrl[nn]
NumOfHosts[nn]
Learn: Registered to
BS[XXXX
XX:XX:XX:XX:XX:XX]
Lost DL-MAP The time since the last valid DL MAP
was received by the subscriber unit
has exceeded the timeout.
The subscriber unit will now begin the
ranging process in an attempt to
re-establish wireless synchronization.
This message is normally the result of some
See Troubleshooting Wireless Link Issues on
page 5-18.
C-9
Lost UL-MAP The time since the last valid UL MAP
was received by the subscriber unit
has exceeded the timeout. The
subscriber unit will now begin the
This message is very unlikely to be received. If a
frame is lost, then the absence of a DL-MAP will
be detected first. It is possible, however, that
other vendors sector controllers may not send a
UL-MAP every frame.
MAC Address:
XXXXXX:XX:XX:XX:XX:XX
This is the detected MAC add res ss,
at startup, for this CPE.
MAC Initialized The MAC processor has completed
initialization.
MAC Reset: Configuration
Change
The MAC has required a reset to apply
a configuration change that was made
by the user.
Normal operation. Some configuration changes
require a reboot of the MAC in order to be
applied.
MAC Reset: SC Request
(RES-CMD)
that the subscriber unit reset its MAC.
Check the sector controller event log for reason.
This action is not generated by the SU, and
would not normally occur with a Redline sector
controller.
MAC Started The MAC processor has been started. Information only. There is no action required.
Missed Frame: DlfpSignal t/o This means that the subscriber unit did
not detect the beginning of the frame.
It is not serious to see one or two of these
messages. If they persist it could indicate a
timing offset problem.
Check other subscriber units within the same
sector to see if they experience the same
problem. If multiple subscriber units experience
this problem, it could indicate a sector-wide
issue. Contact
support@redlinecommunications.com for further
assistance.
Modem Error: [message] This message provides details
regarding any errors encountered by
the PHY. A message specific to the
error will be appended to this
message.
An error of this sort normally results in link loss.
It may require a subscriber reboot to restore
connectivity. Contact
support@redlinecommunications.com if this
message persists.
MpiInit failed The subscriber unit software did not
initialize the PHY/Low level hardware
driver
Perform a cold restart of the subscriber unit by
removing the power, and waiting for 30 seconds
before powering up the device.
New Cls for SF with CID XXXX A new classifier has been added to
service flow [CID XXXX].
New Ksn nn, lifetime nn This message provides information on
the status of your encryption key.
C-10
No Maintenance Data Grant
Slot T4
If the subscriber has nothing to send,
the sector controller should grant
unsolicited bandwidth.
The subscriber unit should respond
with padding. This message indicates
that the sector controller has not
granted this data for 35 seconds.
This message indicates that sector controller
may have de-registered the subscriber unit due
to inactivity.
Non-buffered software
upgrade failed
A software upgrade, written directly to
flash due to lack of available RAM,
failed.
Reboot the subscriber unit, to minimize the
amount of memory fragmentation.
Non-buffered software
upgrade successful
A software upgrade, written directly to
flash due to lack of available RAM,
was completed successfully.
Old Ksn nn, lifetime nn This message provides information on
Overlapping UlMap IE
eliminated
Debug message. Error detected in
maps.
Provision: Corrupted Config
File
Error during TFTP self-provisioning You need to correct and update the required
configuration file stored on the TFTP server.
You can manually configure the subscriber
through the sector controller or RMS.
Provision: Invalid Config Field
[nn]
Error during TFTP self-provisioning You need to correct and update the required
Provision: Invalid digest TFTP self-provisioning error You need to correct and update the required
Provision: Invalid vendor ID TFTP self-provisioning error You need to correct and update the required
Provision: Missing field id [nn] TFTP self-provisioning log You need to correct and update the required
C-11
Provision: reboot request TFTP self-provisioning log You need to correct and update the required
Provision: updated
configuration
TFTP self-provisioning log You need to correct and update the required
Provision: upgrade image has
same version
TFTP self-provisioning log You need to correct and update the required
Pwr IE (nn) Current: nn.
Anomaly: Too High
Anomaly: Too Low
Success
Rng Assigned Diuc nn. These messages are part of the
ranging sequence. As the subscriber
progresses through the initial ranging
procedure, these messages may be
added to the event log.
Ranging in progress cancelled
by watchdog
Debug message. The watchdog has
been triggered to avoid data traffic
loss due to range lock.
During ranging, data traffic is temporarily halted
to facilitate the ranging operation. If for some
reason the ranging does not completed as
expected, then after a preset delay the watchdog
is triggered and it re-establishes data traffic.
Read BS Table ([nn] valid
entries)
The subscriber is trying to determine
the number of sector controllers were
listed at startup
Remove SA ID [nn] Security association ID deleted. Information only. There is no action required.
Reset Button Pressed The reset button on the subscriber unit
has been activated.
RF PLL Error PLL in the RF module failed to lock
(hardware issue),
Contact support@redlinecommunications.com.
C-12
REG Failure - Retries
Exhausted
The timeout (T6) has been reached 3
times in a row. The subscriber unit will
now reboot and begin scanning for a
sector controller again.
You may be experiencing a problem with your RF
path. Usually indicates that a sector controller
was detected, but that the signal was not strong
enough to synchronize with that particular sector
controller.
Verify the alignment of your subscriber unit. Try a
sector controller with a stronger signal if
possible.
Verify that there is no RF interference present.
See Consider using a higher gain antenna if you
have an SUI.
REG Success [TLV Map:
XXXXXXXX]
The subscriber unit has successfully
registered.
REG Wait Timeout T6 [nn
retries]
The subscriber unit has not received a
response to its registration request
within 3 seconds.
This is likely caused by RF problems. Check that
your path loss is not such that one end of the link
cannot receive the other.
Verify that there is no interference on your
channel (internal or external). See
Troubleshooting Wireless Link Issues on
page 5-18.
REG_REQ authentication
failure - HMAC [CC: nn]
With privacy enabled, authentication
failed.
This subscriber is not authorized for registration
with this sector controller.
REG-REQ not sent - no bw
granted
The subscriber unit has not been able
to send a registration request
message to the sector controller, since
the sector controller has not granted it
bandwidth to do so. It cannot request
bandwidth, because it is not yet
registered.
This is likely a problem with the sector controller.
The sector controller should grant bandwidth
periodically in order for new subscriber units
register.
Reset [reason] The subscriber unit has reset itself.
The reason for the reset is included in
the message text.
Rf Rx Calibration Error Receive (Rx) calibration data located
in the subscriber units EEPROM has
failed CRC
If this message occurs repeatedly, the subscriber
unit should be returned. Contact
Rf Tx Calibration Error Transmit (Tx) calibration data located
in the subscriber units EEPROM has
failed CRC
If this message occurs repeatedly, the subscriber
unit should be returned. Contact
Rng Freq Correction (nn). Normal operation. There is no action required.
Rng Maintenance Correction
Anomaly [TLV Map:
XXXXXXXX]
An adjustment requested by the sector
controller has failed.
This is not a fatal error.
This is generally caused by the sector controller
requesting a parameter be adjusted outside the
supported range of the subscriber unit. For
example, adjust Tx power above 20dBm.
C-13
Rng Maintenance Correction
Success [TLV Map:
XXXXXXXX]
An adjustment requested by the sector
controller has been successfully
applied.
Normal operation. Changing RF conditions will
frequently require an adjustment to RF
parameters. This message indicates that one of
these changes has been successfully applied as
requested by the sector controller.
Rng Pwr (nn) Current: nn.
Anomaly: Too High
Anomaly: Too Low
Success
Rng Req Tx time corr:nn pwr:
nn x0.01 dBm
Rng Time Correction (nn)
Current: nn.
Rng Time Correction
(nnXX:XX:XX:XX:XX:XX).
Anomaly.
Rx Error symbols:nnnn prev
symbols: nnnn
This is a debgging message. Normal operation. There is no action required.
SBC Failure - Retries
Exhausted
T18 expired beyond the maximum
number of allowed retries.
underlying RF problems. See Troubleshooting
SBC Success [TLV Map:
XXXXXXXX]
negotiated its basic capabilities with
the sector controller.
process.
SBC Wait Timeout T18 [nn
retries]
A SBC request response is not
received within 50ms.
page 5-18.
SBC-REQ not sent - no BW
granted
The sector controller has not allocated
bandwidth to allow subscriber unit to
do SBC and registration
The sector controller is supposed to grant
bandwidth for registration and SBC/ subscriber
unit cannot request bandwidth because its not
yet registered.
This may also be the result of RF problems if
bandwidth was granted but not received by SU.
page 5-18.
Scanning channel [nn] f=[nn]
kHz
During a scan the current channel [nn]
khx is listed.
SF CID=XXXX Erased (not
found in tables)
The service flow [CID=XXXX] has
been deleted
C-14
SF CID=XXXX Erased The service flow [CID=XXXX] has
been deleted.
SNMP reboot request The subscriber unit is being rebooted
based on an SNMP request.
Software upgrade failed The upgrade operation failed. Retry the upgrade.
Software upgrade successful The upgrade operation was completed
successfully.
Started CLI configuration
restore
The subscriber unit restore operation
has been initiated by a CLI request.
Started CLI software upgrade The subscriber unit software upgrade
operation has been initiated by a CLI
request.
Started Provisioning software
upgrade
The subscriber unit software upgrade
operation has been initiated by TFTP
self-provisioning
Started SNMP configuration
restore,
has been initiated by an SNMP
request
Started SNMP software
upgrade
has been initiated by RMS.
StartFrameRx failed Debug message. Error detected in
maps.
issues, interference.
page 5-18.
Subch IRng: SCh Number:nn
Frame: nn
These messages are part of the
ranging sequence, when
subchannelization has been enabled.
Synchronization Completed The subscriber unit has completed
scanning for a downlink channel, and
established synchronization with a
sector controller. It will now begin its
initial ranging process.
process.
System startup [status] The subscriber unit has begun the
bootup sequence. The startup status
will be included in the text of this
message. Modes specify a possible
reason for reboot. (i.e. (power cycle,
reset, CLI/SNMP request, crash, etc)
TEK nn expired This message provides information on
C-15
TFTP - no response T26 [nn
retries]
SMC setup has not completed within
the allowed time.
In addition to individual DHCP and ToD timeouts,
the subscriber unit has a timer which monitors
the overall SMC registration process. If it
exceeds a timer, this message is displayed, and
network entry is restarted.
TFTP Completed Successfully This message confirms that SMC
registration has completed.
Communication with DHCP and ToD
servers was successful.
Normal operation for subscriber units using SMC.
TFTP Success SMC IP, ToD, have been successfully
obtained via DHCP.
TFTPC failed send SMC has failed, and the subscriber
unit will reset the MAC and begin
registration process again.
This message is displayed when any one of the
TFTP failures/timeouts are encountered.
TFTP_FILE_CRC, TFTP
Failed - File checksum error
The file, specified for upgrade or
restore has experienced a checksum
failure and may be corrupted.
Replace the required file with clean version.
TFTP_FILE_NOT_FOUND,
TFTP Failed - File Not found
restore cannot be found.
Ensure that you have specified the correct
location for the file. Place the required file in the
specified location.
TFTP_FILE_TOO_BIG, TFTP
Failed - File too long
restore is too large.
Ensure that you have specified the correct file.
Place the required file in the specified location.
TFTP_HMAC_FAILED, TFTP
- HMAC authentication failed
restore cannot be authenticated.
TFTP_PKTS_INORDER,
TFTP Failed - Packets out of
order
restore cannot be verified.
Time-of-day acquired Communication with a ToD (RFC-868)
server has been successful and the
correct time of day has been acquired.
UCD Receiving Timeout 5 uplink channel descriptors in a row
have been expected and not received.
The subscriber unit will now restart the
underlying RF problems. Follow the steps
detailed in the RF troubleshooting section of this
guide to resolve this problem.
Unicast Initial Ranging No
Response T3 [nn retries]
The sector controller has not
responded to an initial ranging request
sent by the subscriber unit within
200ms.
Unicast Initial Ranging Retries
Exhausted [nn retries]
perform initial ranging 16 times and
has failed each time.
C-16
The following table lists messages that are rarely encountered during normal
operation.These messages are provided for information only. If you do encounter any of
the following messages contact support@redlinecommunications.com.
Unicast Initial Ranging Start
[CID: XXXX]
The subscriber unit has received a
unicast ranging opportunity
Redline sector controllers never send unicast
ranging opportunities, but it is possible with other
vendors equipment. This is normal behaviour for
802.16 standards compliant devices.
Unicast Ranging Abort Indicates that the sector controller has
sent the subscriber unit a ranging
abort, telling it to halt the ranging
process.
This indicates that the subscriber unit was unable
to adjust parameters as requested by the sector
controller. Most likely to be a Tx power or
frequency adjustment problem. Can indicate
either a path issue, or a bad SU
Uplink Channel Parameters
Acquired
obtained the uplink channel descriptor
process.
Uplink SF nn changed Changes have been successfully
applied to the specified uplink service
flow.
Uplink SF nn created [CID:
XXXX, No.Cls: nn]
An uplink service flow has been
successfully created.
Uplink SF nn not created (no
space) [CID: XXXX]
The subscriber unit cannot create the
specified UL service flow, as there is
not enough remaining memory.
This message should not normally be
encountered. Check the number of SFs and
classifiers you have created per subscriber unit,
and verify that it is within Redlines supported
limits.
Wrong RF module. Restart The subscriber unit cannot detect the
RF chip. It is rebooting in an attempt to
correct the issue.
Table C-2 Additional Subscriber Event Log Messages
***Failed to alloc initial RX buffer Developer Message
***Failed to alloc initial RX MPI structure Developer Message
***Failed to alloc initial RX seg. Chain Developer Message
***Failed to build DlMap RxMpdus Developer Message
***Failed to build DmMap RxMpdus (nn) Developer Message
***Failed to build Initial RxMpdus Developer Message
***Failed to build Last Burst Rx seg. Chain Developer Message
***Failed to build Last Burst RxBuffer Developer Message
C-17
***Failed to build Last Burst RxMpdus Developer Message
***Failed to build RxMpdus Developer Message
***Frag Bcast Mgmt: first fragment missing,
drop
Developer Message
***Frag Bcast Mgmt: fragment list not empty,
drop
Developer Message
***Frag Bcast Mgmt: unfragmented sdu, drop
all
Developer Message
***Frag Bcast Mgmt: wrong fsn, drop Developer Message
***Frag Bcast Mgmt: wrong fsn, drop Developer Message
***Frame 2nd Start failed Developer Message
***Frame End t/o Developer Message
***Frg Bcast Management: : Extended flag
alone
Developer Message
***Frg Bcast Management: Mesh/Pack/Gm
found
Developer Message
***MpiInit failed Developer Message
***mpiRxMacPdus failed Developer Message
***mpiTxMacPdus failed Developer Message
***RxHandler failed Developer Message
***StartFrameRx failed Developer Message
***TxHandler failed Developer Message
Core 1 Restart System Failure Contact
DSX_ADD_ABORT,DSA abort by DSA-ACK
[SF Id: XXXX]
System Error Contact
DSX_ADD_ACK_RECOVER_RETRY,DSA
recovery - DSA-ACK lost [SF Id XXXX]
DSX_ADD_RSP_RECOVER_RETRY,DSA
recovery - DSA-RSP lost [SF Id: XXXX]
DSX_ADD_SUCCESS,DSA Success [SF Id:
XXXX]
DSX_CHNG_ABORT,DSC abort by DSC-ACK
[SF Id: XXXX]
DSX_CHNG_ACK_RECOVER_RETRY,DSC
recovery - DSC-ACK lost [SF Id: XXXX]
C-18
DSX_CHNG_RSP_RECOVER_RETRY,DSC
recovery - DSC-RSP lost [SF Id: XXXX
DSX_CHNG_RSP_RETRY_EXH,DSC Err -
DSC-RSP send retries exhaustes [SF Id:
XXXX]
DSX_DEL_RSP_RECOVER,DSX recovery -
DSD RSP [SF Id: XXXX]
DSX_DEL_SUCCESS, DSD Success [SF Id:
XXXX]
DSX_DYN_SERVICE_LIMIT,DSX Reject -
service limit exceeded [Info:
XX:XX:XX:XX:XX:XX]
DSX_NO_RESOURCE,DSx Add Reject System Error Contact
DSX_PARAM_NOT_PRESENT,DSx Add
Reject
DSX_SF_CLS_ADD_REJECTED,DSA Err -
SF or CLS rejected [SF Id: XXXX]
DSX_SF_CLS_CHNG_REJECTED,DSC Err -
SF or CLS rejected [SF Id: XXXX]
DSX_SF_EXISTS,DSA Rejected - Service
Flow exists [SF Id: XXXX]
DSX_SF_NOT_FOUND,DSC-DSD Reject -
SF ID not found
DSX_UNK_CONF_SETTINGS,DSx Add
Reject
DSX_UNK_TRANSACTION_ID,DSx Action System Error Contact
DSX_VAL_PARAM_NOT_SUPP,DSx Add
Rejected
UL_CH_UNUSABLE, Uplink Channel
Unusable
System Error. Contact
D-1
D
Synchronization Event Log
Messages
The following events are specific to sector controller synchronization. Additional
troubleshooting information has been provided here as well as the corresponding event log
messages that may be displayed by the other devices within the base station.
If you are using RMS, this table is also provided in the Redline Management Suite
Administration and Maintenance Guide with the corresponding RMS alarm condition and
log messages. The RMS messages will only be displayed if the corresponding
synchronization traps are configured for use.
D-2
Table D-1 AN100U/UX Synchronization Event Log Messages
Message Reported
By
Event Log Message
(Logged starting from bottom to top) Probable Cause Recommended Troubleshooting
Master with GPS Master with GPS Function Activated
GPS Synchronization Ok
Backup Master is not active. Normal Operation
Backup Master Synchronization with Master Ok
Master Detected
Backup Master is ready, but not active. Normal Operation
Slave Synchronization Ok
Master Detected
Slave synchronized to Master is active. Normal Operation
Backup Master Synchronization with GPS Ok
GPS Detected
Backup Function Activated
Master is not Detected
Master has become disconnected, during normal operation. Normal Operation
Backup Master Backup Function Activated
Synchronization with GPS Ok
GPS Detected
Backup Master is now active.
Master is Offline after reboot.
Normal Operation
Backup Master 17:33:06 GPS Synchronization Ok
17:33:02 GPS Detected
17:32:31 GPS is not Detected
17:01:33 Master with GPS Function
Activated
GPS is in holdover mode
GPS antenna may have become disconnected, during normal
operation. After 30 Minutes of satellite signal loss, the GPS halts
(squelches) its signal for 30 seconds to indicate its holdover
status to the Master with GPS sector controller.
Check the GPS connection to its
external antenna. Refer to the
RedMAX GPS Clock User Manual.
Slave Synchronization Signal not Detected Master and Backup Master have become disconnected, during
normal operation.
Check the Master with GPS and the
Backup Master and ensure they are
online and that the GPS is
connected to the Sync Out port.
Appendix D Synchronization Event Log Messages
D-3
Backup Master
(after rebooting)
Master or GPS must be connected.
Waiting...
No connection between the GPS and the Master with GPS.
The Master with GPS is offline.
Check the Master with GPS and
ensure it is online and that the GPS
is connected to the Sync In port of
the Master with GPS.
Ensure that the Master with GPS is
also connected to the Sync In port
of the Backup Master.
Slave Synchronization Signal not Detected.
Waiting...
Master and Backup Master are offline, after rebooting. Check the Master with GPS and the
Backup Master and ensure they are
online and that the GPS is
connected to the Sync Out port.
Master Other Master Detected. Waiting... More than one sector controller has been configured as the
Master with GPS.
Change the configuration of one
sector controller so that you have
only one device configured as the
Master with GPS.
Backup Master Other Backup Detected. Waiting... More than one sector controller has been configured as the
Backup Master
Change the configuration of one
sector controller so that you have
only one device configured as the
Backup Master
Master Synchronization Signal not Detected.
Waiting...
No Connection between the Master with GPS and the GPS Clock Check the Master with GPS and
is connected to the Sync In port.
Check that the Master and Backup
Master are synchronized.
Master GPS is not Detected No Connection between the GPS and the Master with GPS.
No event log message is displayed by the Backup Master or the
Slave devices.
Check the Master with GPS and
is connected to the Sync In port.
Table D-1 AN100U/UX Synchronization Event Log Messages (continued)
Message Reported
By
Event Log Message
D-4
Backup Master State changes from Synchronization OK
to GPS Synchronization Ok. All of the
following messages are displayed:
Synchronization with GPS Ok
GPS Detected
Backup Function Activated
Synchronization with Master is Lost
Synchronization OK
50-ohm termination has been disconnected. Check the wiring of the GPS and the
50-ohm load termination.
Verify that the load termination on
the Backup Master is correctly
connected and is secure.
Verify that the synchronization
cables on the Backup Master is
correctly connected and is secure.
Slave State changes from Synchronization OK
to Synchronization Lost. All of the
following messages are displayed:
Synchronization Signal Detected
Synchronization Signal not Detected
Synchronization Lost
Synchronization OK
50-ohm termination has been disconnected. You should see the
above-listed messages on the Backup Master.
Check the wiring of the GPS and the
50-ohm load termination.
the Backup Master is correctly
connected and are secure.
the last slave device is correctly
connected and is secure.
cables on the Backup Master is
correctly connected and are secure.
Message Reported
By
Event Log Message
Appendix D Synchronization Event Log Messages
D-5
Slave Synchronization Ok
Backup Detected
Master is offline, after rebooting. Check the Master with GPS and
is connected to the Masters Sync In
port.
cables from the Master with GPS
and/or the Backup Master are
correctly connected to the Slaves
Sync Out port.
Master GPS is not Detected on the Master No connection between the GPS and Master with GPS and the
Backup Master on Sync In or Sync Out port.
No corresponding event log messages are displayed by the Slave
devices.
Check the wiring connections
between Master with GPS and
Backup Master, check the
connection to the GPS unit.
Backup Master Backup Function Activated
No connection between the GPS and Master with GPS and the
Backup Master on Sync In or Sync Out port.
You should see the above-listed messages on the Master.
devices.
between Master with GPS and the
Backup Master.
Also check the connections to the
GPS unit.
Master GPS is not Detected No connection between the GPS and the Master with GPS and
between the Master with GPS and Backup Master on the Sync In
port.
devices.
between the Master with GPS amd
the Backup Master.
Check the connection to the GPS
unit.
Message Reported
By
Event Log Message
D-6
1-1
Index
A
AN100U/UX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
Configuring Management . . . . . . . . . . . . . . 5-11
Event Messages . . . . . . . . . . . . . . . . . . . . . . . B-1
Inrush Current . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
Monitoring System Event Log . . . . . . . . . . . . 2-6
Operation in GPS Holdover . . . . . . . . . . . . . . 3-9
Rebooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Replacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Synchronization with GPS Clock . . . . . . . . . 3-5
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . 5-1
Uplink Power Control . . . . . . . . . . . . . . . . . . . 3-4
Visual Inspection of IDU . . . . . . . . . . . . . . . . 3-1
Antenna
Replacing ODU . . . . . . . . . . . . . . . . . . . . . . . . 4-4
Auto-negotiation . . . . . . . . . . . . . . . . . . . . . . . . 5-11
B
Bidirectional UDP Throughput, Measuring . . 2-13
Bridge Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
Subscriber Unit Host Limitation . . . . . . . . . . 6-3
C
Cable
AC/DC Power . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
Compensation . . . . . . . . . . . . . . . . . . . . . . . . 5-19
Cross-Over vs Straight . . . . . . . . . . . . . . . . . . 5-8
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
RF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Classifiers
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-35
Maximum Number per SC . . . . . . . . . . . . . . 3-13
Verifying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-34
Cold Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
Sector Controller . . . . . . . . . . . . . . . . . . . . . . . 5-7
Command Line Interface
Connecting to Sector Controller . . . . . . . . . . 2-5
Connecting to Subscriber Unit . . . . . . . . . . . 2-6
Communication
Connectivity with Internet Explorer . . . . . . 5-15
Downlink Connectivity Issues . . . . . . . . . . . 5-41
Duplex Mismatch . . . . . . . . . . . . . . . . . . . . . . 5-11
Remote Connectivity . . . . . . . . . . . . . . . . . . . 5-17
Serial Configuration . . . . . . . . . . . . . . . . . . . 5-13
Uplink Connectivity Issues . . . . . . . . . . . . . . 5-42
Configuring
DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . 2-18
1-2
D
Data Path
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . 5-39
Data Throughput . . . . . . . . . . . . . . . . . . . . . . . . 5-34
Subscriber Unit . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Debug Mode
Sector Controller . . . . . . . . . . . . . . . . . . . . . . . 2-5
Device Boot Issues, Troubleshooting . . . . . . . 5-4
DHCP Server, Configuring . . . . . . . . . . . . . . . 2-18
Disaster Recovery
Extreme Temperature . . . . . . . . . . . . . . . . . . . 7-3
Impact Assessment . . . . . . . . . . . . . . . . . . . . . 7-1
Lightning Damage . . . . . . . . . . . . . . . . . . . . . . 7-2
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
Distance of Subscirber Unit . . . . . . . . . . . . . . 5-21
Document
Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Other Redline Guides . . . . . . . . . . . . . . . . . . . 1-3
Downlink TCP Throughput, Measuring . . . . . 2-12
E
Equipment
Baseline Configuration . . . . . . . . . . . . . . . . . 2-15
Required for Maintenace . . . . . . . . . . . . . . . . 2-2
Secure Remote Access . . . . . . . . . . . . . . . . 2-17
Spares for Replacement . . . . . . . . . . . . . . . . . 2-3
Error Messages
LO1/LO2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21
Radio Reference Frequency . . . . . . . . 5-21, 5-23
Sector Controller . . . . . . . . . . . . . . . . . . . . . . . B-1
Subscriber Unit . . . . . . . . . . . . . . . . . . . . . . . . C-1
Synchronization . . . . . . . . . . . . . . . . . . . . . . . . D-1
Ethernet
Cross-Over vs Straight Cables . . . . . . . . . . . 5-8
Management Port Connection . . . . . . . . . . . 5-9
Event Log
Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
Reported Noise Level . . . . . . . . . . . . . . . . . . 5-32
Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
Sector Controller Messages . . . . . . . . . . . . . B-1
Subscriber Unit De-registration . . . . . . . . . 5-28
Subscriber Unit Messages . . . . . . . . . . . . . . . C-1
Subscriber Unit Synchronization Messages D-1
Example
Working with Classifiers . . . . . . . . . . . . . . . . 5-35
F
Fault LED
Sector Controlller . . . . . . . . . . . . . . . . . . . . . . 5-6
G
GPS Synchronization
Backup Master . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
Detecting Interference . . . . . . . . . . . . . . . . . B-19
Holdover Mode . . . . . . . . . . . . . . . . . . . . .3-9, D-2
Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
Reporting Sync Errors . . . . . . . . . . . . . . . . . . A-5
Required Wireless Interface Parameters . . 3-7
Slave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . D-1
Ground Connections
Inspecting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
Index
1-3
I
Indoor Unit
Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
Replacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Visual Inspection . . . . . . . . . . . . . . . . . . . . . . . 3-1
Inrush Current at Startup . . . . . . . . . . . . . . . . . . 5-7
Inspecting
Indoor Unit (IDU) . . . . . . . . . . . . . . . . . . . . . . . 3-1
Outdoor Unit (ODU) . . . . . . . . . . . . . . . . . . . . 4-7
RF System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Weatherproofing . . . . . . . . . . . . . . . . . . . . . . 4-12
Interface Cable . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
Interference
Detecting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-32
Detecting at Startup . . . . . . . . . . . . . . . . . . . B-19
Detecting with Synchronization . . . . . . . . . B-19
RF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-29
Site Spectrum Analysis . . . . . . . . . . . . . . . . 5-34
IP Address
SUO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18
Iperf
Bidirectional UDP Throughput . . . . . . . . . . 2-13
Downlink TCP Throughput . . . . . . . . . . . . . 2-12
Uplink TCP Throughput . . . . . . . . . . . . . . . . 2-13
L
Lightning
Damage Recovery . . . . . . . . . . . . . . . . . . . . . 7-2
Protection Components . . . . . . . . . . . . . . . . 4-11
LO1, LO2, Errors . . . . . . . . . . . . . . . . . . . . . . . 5-21
M
MAC Address
Auto-Learning . . . . . . . . . . . . . . . . . . . . . . . . .5-40
Learning Mode . . . . . . . . . . . . . . . . . . . . . . . .5-40
Subscriber Unit Host Limitation . . . . . . . . . . .6-3
Unknown Host . . . . . . . . . . . . . . . . . . . . . . . . .5-37
Maintenance
Baseline Configuration . . . . . . . . . . . . . . . . . .2-15
Indoor Unit (IDU) . . . . . . . . . . . . . . . . . . . . . . . .3-1
Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1
Redundant Power Supply . . . . . . . . . . . . . . . .3-4
Required Equipment . . . . . . . . . . . . . . . . . . . . .2-2
Required Personnel . . . . . . . . . . . . . . . . . . . .2-15
Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-1
Scheduling Window . . . . . . . . . . . . . . . . . . . .2-14
Management
Configuring AN100U/UX . . . . . . . . . . . . . . . . 5-11
Configuring Speed/Duplex Settings . . 5-12, 5-13
Configuring Subscriber Unit . . . . . . . . . . . . .5-12
Enabling SMC . . . . . . . . . . . . . . . . . . . . . . . . . .6-2
High Latency on SMC . . . . . . . . . . . . . . . . . .5-44
Management Port
Establishing Connection . . . . . . . . . . . . . . . . .5-9
Maximum Values
for AN100U/UX . . . . . . . . . . . . . . . . . . . . . . . .3-13
Messages
Sector Controller . . . . . . . . . . . . . . . . . . . . . . . B-1
Subscriber Unit . . . . . . . . . . . . . . . . . . . . . . . . C-1
Monitoring
Statistical Results . . . . . . . . . . . . . . . . . . . . . . .2-8
System Event Log . . . . . . . . . . . . . . . . . . . . . . .2-6
System Parameters . . . . . . . . . . . . . . . . . . . . .2-9
Your System . . . . . . . . . . . . . . . . . . . . . . . . . . .2-4
1-4
N
Noise Floor
Detecting Interference . . . . . . . . . . . . . . . . . 5-32
Noise Floor Calculations . . . . . . . . . . . . . . . . . B-20
Noise Measurements
Viewing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-32
Viewing on Status Page . . . . . . . . . . . . . . . . 5-33
O
Outdoor Unit
Inspecting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Lightening Protection . . . . . . . . . . . . . . . . . . 4-10
Replacing Antenna . . . . . . . . . . . . . . . . . . . . . 4-4
Replacing Radio . . . . . . . . . . . . . . . . . . . . . . . 4-1
Weatherproofing . . . . . . . . . . . . . . . . . . . . . . 4-12
Overview
Iperf Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
Maintenance Guide . . . . . . . . . . . . . . . . . . . . . 1-1
Ping Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
rfMonitor Utility . . . . . . . . . . . . . . . . . . . . . . . . 2-14
System Maintenance . . . . . . . . . . . . . . . . . . . 2-1
P
Perl Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
checkDailyPerSector.pl . . . . . . . . . . . . . . . . . A-8
checkTime.pl . . . . . . . . . . . . . . . . . . . . . . . . . . A-7
errorReport.pl . . . . . . . . . . . . . . . . . . . . . . . . . . A-5
findNoisefloor.pl . . . . . . . . . . . . . . . . . . . . . . . . A-8
scan.pl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
PHY
Viewing/Modifying Parameters . . . . . . . . . . 3-14
Power Cable
AC/DC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
Verifying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
Power Control, Uplink . . . . . . . . . . . . . . . . . . . . 3-4
Power Injector . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
Power Supply
Inrush Current at Startup . . . . . . . . . . . . . . . . 5-7
Redundant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
R
Radio
Maintenace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
Reference Frequency Errors . . . . . . . . 5-21, 5-23
Replacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
Rebooting
AN100U/UX . . . . . . . . . . . . . . . . . . . . . . . . 3-2, 5-7
See also Cold Restart
Subscriber Unit . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Redundant Power Supply . . . . . . . . . . . . . . . . . 3-2
Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
Reference Information . . . . . . . . . . . . . . . . . . . . 2-3
Remote Connectivity . . . . . . . . . . . . . . . . . . . . 5-17
Replacing
Indoor Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
RF
Cable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Possible Causes of Interference . . . . . . . . 5-29
Re_Enabling Interface . . . . . . . . . . . . . . . . . 3-15
Viewing/Modifying Parameters . . . . . . . . . . 3-14
RSSI
Link Optimization . . . . . . . . . . . . . . . . . . . . . . 5-27
Index
1-5
S
Scripts
checkDailyPerSector.pl . . . . . . . . . . . . . . . . . A-8
checkTime.pl . . . . . . . . . . . . . . . . . . . . . . . . . . A-7
errorReport.pl . . . . . . . . . . . . . . . . . . . . . . . . . . A-5
findNoisefloor.pl . . . . . . . . . . . . . . . . . . . . . . . . A-8
scan.pl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
System Event Log . . . . . . . . . . . . . . . . . . . . . . A-1
Sector Controller
AC Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
Backup Master with GPS . . . . . . . . . . . . . . . . 3-8
Cell Range . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21
Configuration Mismatch . . . . . . . . . . . . . . . . 5-18
Connecting to CLI . . . . . . . . . . . . . . . . . . . . . . 2-5
Connecting to Web Client . . . . . . . . . . . . . . . 2-4
DC Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
Debug Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
Device Boot Issues . . . . . . . . . . . . . . . . . . . . . 5-4
Does Not Power Up . . . . . . . . . . . . . . . . . . . . 5-4
Fault LED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
Master with GPS . . . . . . . . . . . . . . . . . . . . . . . 3-7
Reboots Unexpectedly . . . . . . . . . . . . . . . . . . 5-6
Serial Communicaton . . . . . . . . . . . . . . . . . . 5-13
Slave with GPS . . . . . . . . . . . . . . . . . . . . . . . . 3-9
Troubleshooting Ethernet Issues . . . . . . . . . 5-8
Troubleshooting Wireless Link . . . . . . . . . . 5-18
Self-Install
Troubleshooting . . . . . . . . . . . . . . . . . 6-1, 6-4, 6-5
Serial Communication Configuration . . . . . . . 5-14
Server
Configuring DHCP . . . . . . . . . . . . . . . . . . . . . 2-18
Time of Day . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
Service Class . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
Service Flow
Enabling Default Uplink . . . . . . . . . . . . . . . . . .6-1
Maximum Number . . . . . . . . . . . . . . . . . . . . . .3-13
Maximum per Sector Controller . . . . . . . . . .3-13
Service Classifier . . . . . . . . . . . . . . . . . . . . . .3-13
Verifying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-34
Verifying Classifiers . . . . . . . . . . . . . . . . . . . .5-34
Signal Cabling
Verifying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6
Site, Spectrum Analysis . . . . . . . . . . . . . . . . . .5-34
SMC
High Latency . . . . . . . . . . . . . . . . . . . . . . . . . .5-44
Software Upgrade
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . .5-43
Spare Equipment . . . . . . . . . . . . . . . . . . . . . . . . .2-3
Spectrum Sweep Testing . . . . . . . . . . . . . . . . . .4-9
Statistical Results
Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-8
Subscriber Unit
Configuration Mismatch . . . . . . . . . . . . . . . . .5-18
Configuring Management . . . . . . . . . . . . . . .5-12
Connecting to CLI . . . . . . . . . . . . . . . . . . . . . . .2-6
Connectivity Behind . . . . . . . . . . . . . . . . . . . .5-15
De-registration . . . . . . . . . . . . . . . . . . . . . . . . .5-28
Device Does Not Boot . . . . . . . . . . . . . . . . . . .5-6
Distance from Sector Controller . . . . . . . . . .5-21
Ethernet Connection . . . . . . . . . . . . . . . . . . . . .5-8
Host Limitation with Bridge Filter . . . . . . . . . .6-3
Indoor Connectivity Issues . . . . . . . . . . . . . .5-24
IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-18
Low Data Throughput . . . . . . . . . . . . . . . . . . . .6-3
Power Injector . . . . . . . . . . . . . . . . . . . . . . . . . .5-6
Rebooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2
Updaing for Default Service Flow . . . . . . . . .6-2
Supported
1-6
Web Browsers . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
Synchronization
Changing to GPS . . . . . . . . . . . . . . . . . . . . . . . 3-6
Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-1
System Event Log
Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
System Parameters
Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
T
Temperature
Extreme Exposure . . . . . . . . . . . . . . . . . . . . . . 7-3
Testing
Spectrum Sweep . . . . . . . . . . . . . . . . . . . . . . . 4-9
Time of Day Server . . . . . . . . . . . . . . . . . . . . . . 2-20
Timestamps . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
Troubleshooting
Data Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-39
Data Throughput . . . . . . . . . . . . . . . . . . . . . . 5-34
Device Boot Issues . . . . . . . . . . . . . . . . . . . . . 5-4
Device Management . . . . . . . . . . . . . . . . . . . 5-13
Duplex Mismatch . . . . . . . . . . . . . . . . . . . . . . 5-11
Ethernet Issues . . . . . . . . . . . . . . . . . . . . . . . . 5-8
Flow Charts . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Flowcharts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Management Port Connection . . . . . . . . . . . . 5-9
Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
Required Reference Information . . . . . . . . . . 2-3
Self-Install . . . . . . . . . . . . . . . . . . . . . . 6-1, 6-4, 6-5
Software Upgrade . . . . . . . . . . . . . . . . . . . . . 5-43
Wireless Link Issue . . . . . . . . . . . . . . . . . . . . 5-18
U
Uplink
Default Service Flow . . . . . . . . . . . . . . . . . . . . 6-1
Power Control . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
Uplink Channel
Detecting Interference . . . . . . . . . . . . . . . . . B-19
Uplink TCP Throughput, Measuring . . . . . . . 2-13
Using
Iperf Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
Ping Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
rfMonitor Utility . . . . . . . . . . . . . . . . . . . . . . . . 2-14
Utility
Iperf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
Network Packet Sniffer . . . . . . . . . . . . . . . . . 2-14
Ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
rfMonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
V
Verifying
GPS Reciever Operation . . . . . . . . . . . . . . . . 3-8
Lightning Protection System . . . . . . . . . . . . 4-12
Power and Signal Cabing . . . . . . . . . . . . . . . 4-6
Repairs/Maintenance Work . . . . . . . . . . . . . 4-13
Service Flows . . . . . . . . . . . . . . . . . . . . . . . . . 5-34
Service Flows Classifiers . . . . . . . . . . . . . . . 5-34
Visual Inspection . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
W
Weatherproofing . . . . . . . . . . . . . . . . . . . . . . . . 4-12
Web Browsers
Supported Versions . . . . . . . . . . . . . . . . . . . . 2-4
Web Interface
Index
1-7
Connectiong to Sector Controller . . . . . . . . . 2-4
Wind Damage . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Disaster Recovery . . . . . . . . . . . . . . . . . . . . . . 7-2
Wireless Interface . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Required Pararmeters for GPS
Synchronization . . . . . . . . . . . . . . . . . . 3-7
Wireless Link
Gauging Performance . . . . . . . . . . . . . . . . . 5-24
Optimization and Reference RSSI . . . . . . . 5-27
RF Interference . . . . . . . . . . . . . . . . . . . . . . . 5-29
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . 5-18
1-8

RedMAX Admin and Maintenance Guide

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

RedMAX Admin and Maintenance Guide

Hochgeladen von

Copyright:

Verfügbare Formate

RedMAX AN100U/AN100UX

Administration and Maintenance Guide

Das könnte Ihnen auch gefallen