Motorola 89FT7629 Users Manual

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 401

CMMmicro

Object Name

Value Syntax

Operation Allowed

pkts256to511Octets

Counter32

monitor

pkts512to1023Octets

Counter32

monitor

pkts64Octets

Counter32

monitor

pkts65to127Octets

Counter32

monitor

pldVersion

DisplayString

monitor

portIndex

Integer

monitor

portNumber

Integer

monitor

powerStatus

Integer

monitor

rxAlignmentErrors

Counter32

monitor

rxBroadcastPkts

Counter32

monitor

rxDropPkts

Counter32

monitor

rxExcessSizeDisc

Counter32

monitor

rxFCSErrors

Counter32

monitor

rxFragments

Counter32

monitor

rxGoodOctets

Counter64

monitor

rxJabbers

Counter32

monitor

rxMulticastPkts

Counter32

monitor

rxOctets

Counter64

monitor

rxOversizePkts

Counter32

monitor

rxPausePkts

Counter32

monitor

rxSAChanges

Counter32

monitor

rxSymbolErrors

Counter32

monitor

rxUndersizePkts

Counter32

monitor

rxUnicastPkts

Counter32

monitor

satellitesTracked

DisplayString

monitor

satellitesVisible

DisplayString

monitor

softwareVersion

DisplayString

monitor

syncStatus

DisplayString

monitor

systemTime

DisplayString

monitor

trackingMode

DisplayString

monitor

txBroadcastPkts

Counter32

monitor

txCollisions

Counter32

monitor

txDeferredTransmit

Counter32

monitor

txDropPkts

Counter32

monitor

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 402

CMMmicro

Object Name

Value Syntax

Operation Allowed

txExcessiveCollision

Counter32

monitor

txFrameInDisc

Counter32

monitor

txLateCollision

Counter32

monitor

txMulticastPkts

Counter32

monitor

txMultipleCollision

Counter32

monitor

txOctets

Counter64

monitor

txPausePkts

Counter32

monitor

txSingleCollision

Counter32

monitor

txUnicastPkts

Counter32

monitor

upTime

DisplayString

monitor

24.5 OBJECTS DEFINED IN THE PTP 400 AND PTP 600 SERIES BRIDGES MIB

The objects that the PTP 400 and PTP 600 series bridges’ MIB defines are listed in Table

64.

Table 63: PTP 400 and PTP 600 series bridge MIB objects

Object Name

Value Syntax

Operation Allowed

iPAddress

IpAddress

manage

subnetMask

IpAddress

manage

gatewayIPAddress

IpAddress

manage

targetMACAddress1

DisplayString

manage

masterSlaveMode

Integer

manage

maximumTransmitPower

Integer

manage

receivePower2

Integer

manage

vectorError2

Integer

manage

transmitPower2

Integer

manage

range

Integer

manage

linkLoss2

Integer

manage

receiveChannel

Integer

manage

transmitChannel

Integer

manage

receiveModulationMode

Integer

manage

transmitModulationMode

Integer

manage

receiveSnr2

Integer

manage

systemReset

Integer

monitor

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 403

Object Name

Value Syntax

Operation Allowed

softwareVersion

DisplayString

monitor

hardwareVersion

DisplayString

monitor

NOT ES:

1. Of the other BH in the link.

2. max, mean, min, last during the past hour.

24.6 OBJECTS SUPPORTED IN THE CANOPY 30/60-Mbps BH

The 30/60-Mbps BH supports the following MIBs:

◦ MIB II, RFC 1213, System Group

◦ MIB II, RFC 1213, Interfaces Group

◦ WiMAX 802.16 WMAN-IF-MIB

◦ Bridge MIB, RFC 1493, dot1dBaseGroup

◦ Bridge MIB, RFC 1493, dot1dBasePortTableGroup

◦ 30/60-Mbps Backhaul Canopy proprietary MIB

24.7 OBJECTS SUPPORTED IN THE CANOPY 150/300-Mbps BH

The 150/300-Mbps BH supports the following MIBs:

◦ MIB II, RFC 1213, System Group

◦ MIB II, RFC 1213, Interfaces Group

◦ WiMAX 802.16 WMAN-IF-MIB

◦ Bridge MIB, RFC 1493, dot1dBaseGroup

◦ Bridge MIB, RFC 1493, dot1dBasePortTableGroup

◦ High-capacity counter MIB, RFC 2233

◦ 150/300-Mbps Backhaul Canopy proprietary MIB

24.8 INTERFACE DESIGNATIONS IN SNMP

SNMP identifies the ports of the module as follows:

◦ Interface 1 represents the Ethernet interface of the module. To monitor the status

of Interface 1 is to monitor the traffic on the Ethernet interface.

◦ Interface 2 represents the RF interface of the module. To monitor the status of

Interface 2 is to monitor the traffic on the RF interface.

These interfaces can be viewed on the NMS through definitions that are provided in the standard MIB files.

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 404

24.9 TRAPS PROVIDED IN THE CANOPY ENTERPRISE MIB

Canopy modules provide the following SNMP traps for automatic notifications to the NMS:

◦ whispGPSInSync, which signals a transition from not synchronized to

synchronized.

◦ whispGPSOutSync, which signals a transition from synchronized to not

synchronized.

◦ whispRegComplete, which signals registration completed.

◦ whispRegLost, which signals registration lost.

◦ whispRadarDetected, which signals that the one-minute scan has been

completed, radar has been detected, and the radio will shutdown.

◦ whispRadarEnd, which signals that the one-minute scan has been completed,

radar has not been detected, and the radio will resume normal operation.

NOTE:

The PTP 400 and PTP 600 series bridges do not support the traps listed above.

24.10 TRAPS PROVIDED IN THE PTP 400 SERIES BRIDGE MIB

PTP 400 series bridges (previously known as 30/60-Mbps Backhauls) provide the following SNMP traps for automatic notifications to the NMS:

◦ coldStart

◦ linkUp

◦ linkDown

◦ dfsChannelChange, which signals that the channel has changed.

◦ dfsImpulsiveInterferenceDetected, which signals that impulsive interference has

been detected.

24.11 TRAPS PROVIDED IN THE PTP 600 SERIES BRIDGE MIB

PTP 600 series bridges (previously known as 150/300-Mbps Backhauls) provide the following SNMP traps for automatic notifications to the NMS:

◦ coldStart

◦ linkUp

◦ linkDown

◦ dfsChannelChange, which signals that the channel has changed.

◦ dfsImpulsiveInterferenceDetected, which signals that impulsive interference has

been detected.

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 405

24.12 MIB VIEWERS

Any of several commercially available MIB viewers can facilitate management of these objects through SNMP. Some are available as open source software. The Canopy division does not endorse, support, or discourage the use of any these viewers.

To assist end users in this area, Canopy offers a starter guide for one of these viewers— MRTG (Multi Router Traffic Grapher). This starter guide is titled Canopy Network Management with MRTG: Application Note, and is available in the Document Library section under Support at http://www.motorola.com/canopy. MRTG software is available at

http://mrtg.hdl.com/mrtg.html.

Other MIB viewers are available and/or described at the following web sites:

http://ns3.ndgsoftware.com/Products/NetBoy30/mibbrowser.html

http://www.adventnet.com/products/snmputilities/

http://www.dart.com/samples/mib.asp

http://www.edge-technologies.com/webFiles/products/nvision/index.cfm

http://www.ipswitch.com/products/whatsup/monitoring.html

http://www.koshna.com/products/KMB/index.asp

http://www.mg-soft.si/mgMibBrowserPE.html

http://www.mibexplorer.com

http://www.netmechanica.com/mibbrowser.html

http://www.networkview.com

http://www.newfreeware.com/search.php3?q=MIB+browser

http://www.nudesignteam.com/walker.html

http://www.oidview.com/oidview.html

http://www.solarwinds.net/Tools

http://www.stargus.com/solutions/xray.html

http://www.totilities.com/Products/MibSurfer/MibSurfer.htm

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 407

25 USING THE CANOPY NETWORK UPDATER TOOL

(CNUT)

The Canopy Network Updater Tool manages and automates the software and firmware upgrade process for Canopy radio and CMMmicro modules across the network. This eliminates the need for an administrator to visit each radio in the network (or each AP while using the Autoupdate feature) to upgrade the modules.

25.1 CNUT FUNCTIONS

The Canopy Network Updater Tool

◦ automatically discovers all Canopy network elements

◦ executes a UDP command that initiates and terminates the Autoupdate mode

within APs. This command is both secure and convenient:

− For security, the AP accepts this command from only the IP address that you specify in the Configuration page of the AP.

− For convenience, Network Updater automatically sets this Configuration parameter in the APs to the IP address of the Network Updater server when the server performs any of the update commands.

◦ allows you to choose among updating

− your entire network.

− only elements that you select.

− only network branches that you select.

◦ provides a Script Engine that you can use with any script that

− you define.

− Canopy supplies.

25.2 NETWORK ELEMENT GROUPS

With the Canopy Network Updater Tool, you can identify element groups composed of network elements that you select. Identifying these element groups

◦ organizes the display of elements (for example, by region or by AP cluster).

◦ allows you to

− perform an operation on all elements in the group simultaneously.

− set group-level defaults for telnet or ftp password access and SNMP

Community String (defaults that can be overridden in an individual element when necessary).

25.3 NETWORK LAYERS

A typical Canopy network contains multiple layers of elements, each layer lying farther from the Point of Presence. For example, SMs are behind an AP and thus, in this context, at a lower layer than the AP. Correctly portraying these layers in Network Updater is essential so that Network Updater can perform radio and AP cluster upgrades in an appropriate order.

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 408

IMPORTANT!

Correct layer information ensures that Network Updater does not command an AP that is behind another AP/SM pair (such as in a remote AP installation) to perform an upgrade at the same time as the SM that is feeding the AP. If this occurs, then the remote AP loses network connection during the upgrade (when the SM in front of the AP completes its upgrade and reboots).

25.4 SCRIPT ENGINE

Script Engine is the capability in Network Updater that executes any user-defined script against any network element or element group. This capability is useful for network management, especially for scripts that you repetitively execute across your network.

The Autodiscovery capability in Network Updater finds all of your Canopy network elements. This comprehensive discovery

◦ ensures that, when you intend to execute a script against all elements, the script

is indeed executed against all elements.

◦ maintains master lists of elements (element groups) against which you

selectively execute scripts.

The following scripts are included with CNUT:

◦ AP Data Import from BAM

◦ AP Data Export to BAM

◦ Set Autoupdate Address on APs

◦ Set SNMP Accessibility

◦ Reset Unit

25.5 SOFTWARE DEPENDENCIES FOR CNUT

CNUT functionality requires

◦ one of the following operating systems

− Windows® 2000

− Windows XP

− Red Hat Linux 9

− Red Hat Enterprise Linux Version 3

◦ Java™ Runtime Version 1.4.2 or later

◦ Perl 5.8.0 or ActivePerl 5.8.3 software or later

25.6 CNUT DOWNLOAD

CNUT can be downloaded together with each Canopy system release that supports CNUT. Software for these Canopy system releases is packaged on the Canopy Support web page as either

◦ a .zip file for use without the CNUT application.

◦ a .pkg file that the CNUT application can open.

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 409

26 USING INFORMATIONAL TABS IN THE GUI

26.1 VIEWING GENERAL STATUS (ALL)

See

◦ General Status Tab of the AP on Page 201.

◦ General Status Tab of the SM on Page 198.

◦ General Status Tab of the BHM on Page 213.

◦ Beginning the Test of Point-to-Point Links on Page 210.

26.2 VIEWING SESSION STATUS (AP, BHM)

The Session Status tab in the Home page provides information about each SM that has registered to the AP. This information is useful for managing and troubleshooting a Canopy system. This tab also includes the current active values on each SM for MIR, CIR, and

VLAN, as well as the source of these values, representing the SM itself, BAM, or the AP and cap.

An example of the Session Status tab is displayed in Figure 142.

Figure 142: Session Status tab data, example

An additional example and explanations of the fields on this tab are provided in Session

Status Tab of the AP on Page 193.

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 410

26.3 VIEWING REMOTE SUBSCRIBERS (AP, BHM)

See

◦ Remote Subscribers Tab of the AP on Page 197.

◦ Continuing the Test of Point-to-Point Links on Page 212.

26.4 INTERPRETING MESSAGES IN THE EVENT LOG (ALL)

Each line in the Event Log of a module Home page begins with a time and date stamp. However, some of these lines wrap as a combined result of window width, browser preferences, and line length. You may find this tab easiest to use if you widen the window until all lines are shown as beginning with the time and date stamp.

26.4.1 Time and Date Stamp

The time and date stamp reflect either

◦ GPS time and date directly or indirectly received from the CMM.

◦ the running time and date that you have set in the Time & Date web page.

NOTE:

In the Time & Date web page, if you have left any time field or date field unset and clicked the Set Time and Date button, then the time and date default to 00:00:00 UT : 01/01/00.

A reboot causes the preset time to pause or, in some cases, to run in reverse. Additionally, a power cycle resets the running time and date to the default 00:00:00 UT : 01/01/00. Thus, whenever either a reboot or a power cycle has occurred, you should reset the time and date in the Time & Date web page of any module that is not set to receive sync.

26.4.2 Event Log Data Collection

The collection of event data continues through reboots and power cycles. When the buffer allowance for event log data is reached, the system adds new data into the log and discards an identical amount of the oldest data.

Each line that contains the expression WatchDog flags an event that was both

◦ considered by the system software to have been an exception

◦ recorded in the preceding line.

Conversely, a Fatal Error() message flags an event that is recorded in the next line. Some exceptions and fatal errors may be significant and require either operator action or technical support.

An example portion of Event Log data is displayed in Figure 143. In this figure (unlike in the Event Log web page)

◦ lines are alternately highlighted to show the varying length of wrapped lines.

◦ the types of event messages (which follow the time and date stamps and the file

and line references) are underscored as quoted in Table 64 and Table 65.

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 411

Figure 143: Event Log tab data, example

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 412

26.4.3 Messages that Flag Abnormal Events

The messages listed in Table 64 flag abnormal events and, case by case, may signal the need for corrective action or technical support. See Troubleshooting on Page 463.

Table 64: Event Log messages for abnormal events

Event Message

Meaning

Expected LUID = 6 Actual LUID = 7

Something is interfering with the control messaging of the module. Also ensure that you are using shielded cables to minimize interference. Consider trying different frequency options to eliminate or reduce interference.

FatalError()

The event recorded on the line immediately beneath this message triggered the Fatal Error().

Loss of GPS Sync Pulse

Module has lost GPS sync signal.

Machine Check Exception

This is a symptom of a possible hardware failure. If this is a recurring message, begin the RMA process for the module.

RcvFrmNum = 0x00066d ExpFrmNum = 0x000799

System Reset Exception -- External Hard Reset

The unit lost power or was power cycled.

System Reset Exception -- External Hard Reset WatchDog

The event recorded on the preceding line triggered this WatchDog message.

26.4.4 Messages that Flag Normal Events

The messages listed in Table 65 record normal events and typically do not signal a need for any corrective action or technical support.

Table 65: Event Log messages for normal events

Event Message

Meaning

Acquired GPS Sync Pulse.

Module has acquired GPS sync signal.

FPGA Features

Type of encryption.

FPGA Version

FPGA (JBC) version in the module.

GPS Date/Time Set

Module is now on GPS time.

PowerOn reset from Telnet command line

Reset command was issued from a telnet session.

Reboot from Webpage

Module was rebooted from management interface.

Software Boot Version

Boot version in the module.

Software Version

Canopy release version and authentication method for the unit.

System Log Cleared

Event log was manually cleared.

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 413

26.5 VIEWING THE NETWORK INTERFACE TAB (ALL)

Figure 144: Network Interface tab of AP, example

Figure 145: Network Interface tab of SM, example

In any module, the LAN1 Network Interface section of this tab displays the defined Internet Protocol scheme for the Ethernet interface to the module. In slave devices, this tab also provides an RF Public Network Interface section, which displays the Internet Protocol scheme defined for network access through the master device (AP or BHM).

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 414

26.6 INTERPRETING RADIO STATISTICS IN THE SCHEDULER TAB (ALL)

Figure 146: Scheduler tab of SM, example

Statistics for the Scheduler are displayed as shown in Figure 146.

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 415

26.7 VIEWING THE LIST OF REGISTRATION FAILURES (AP, BHM)

An example of the SM Registration Failures tab is displayed in Figure 147.

Figure 147: SM Registration Failures tab of AP, example

The SM Registration Failures tab identifies SMs (or BHSs) that have recently attempted and failed to register to this AP (or BHM). With its time stamps, these instances may suggest that a new or transient source of interference exists.

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 416

26.8 INTERPRETING DATA IN THE BRIDGING TABLE (ALL)

An example of the Bridging Table tab is displayed in Figure 148.

Figure 148: Bridging Table tab of AP, example

If NAT (network address translation) is not active on the SM, then the Bridging Table tab provides the MAC address of all devices that are attached to registered SMs (identified by LUIDs). The bridging table allows data to be sent to the correct module as follows:

◦ For the AP, the uplink is from RF to Ethernet. Thus, when a packet arrives in the

RF interface to the AP, the AP reads the MAC address from the inbound packet and creates a bridging table entry of the source MAC address on the other end of the RF interface.

◦ For the SM, BHM, and BHS, the uplink is from Ethernet to RF. Thus, when a

packet arrives in the Ethernet interface to one of these modules, the module reads the MAC address from the inbound packet and creates a bridging table entry of the source MAC address on the other end of the Ethernet interface.

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 417

26.9 TRANSLATION TABLE (SM)

When Translation Bridging is enabled in the AP, each SM keeps a table mapping MAC addresses of devices attached to the AP to IP addresses, as otherwise the mapping of end-user MAC addresses to IP addresses is lost. (When Translation Bridging is enabled, an AP modifies all uplink traffic originating from registered SM’s such that the source MAC address of every packet will be changed to that of the SM which bridged the packet in the uplink direction.)

An example of the Translaton Table is displayed in Figure 149.

Figure 149: Translation Table tab of SM, example

26.10 INTERPRETING DATA IN THE ETHERNET TAB (ALL)

The Ethernet tab of the Statistics web page reports TCP throughput and error information for the Ethernet connection of the module.

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 418

Figure 150: Ethernet tab of AP, example

The Ethernet tab displays the following fields.

inoctets Count

This field displays how many octets were received on the interface, including those that deliver framing information.

inucastpkts Count

This field displays how many inbound subnetwork-unicast packets were delivered to a higher-layer protocol.

Innucastpkts Count

This field displays how many inbound non-unicast (subnetwork-broadcast or subnetworkmulticast) packets were delivered to a higher-layer protocol.

indiscards Count

This field displays how many inbound packets were discarded without errors that would have prevented their delivery to a higher-layer protocol. (Some of these packets may have been discarded to increase buffer space.)

inerrors Count

This field displays how many inbound packets contained errors that prevented their delivery to a higher-layer protocol.

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 419

inunknownprotos Count

This field displays how many inbound packets were discarded because of an unknown or unsupported protocol.

outoctets Count

This field displays how many octets were transmitted out of the interface, including those that deliver framing information.

outucastpkts Count

This field displays how many packets for which the higher-level protocols requested transmission to a subnetwork-unicast address. The number includes those that were discarded or not sent.

outnucastpkts Count

This field displays how many packets for which the higher-level protocols requested transmission to a non-unicast (subnetwork-broadcast or subnetwork-multicast) address. The number includes those that were discarded or not sent.

outdiscards Count

This field displays how many outbound packets were discarded without errors that would have prevented their transmission. (Some of these packets may have been discarded to increase buffer space.)

outerrrors Count

This field displays how many outbound packets contained errors that prevented their transmission.

RxBabErr

This field displays how many receiver babble errors occurred.

EthBusErr

This field displays how many Ethernet bus errors occurred on the Ethernet controller.

CRCError

This field displays how many CRC errors occurred on the Ethernet controller.

RxOverrun

This field displays how many receiver overrun errors occurred on the Ethernet controller.

Late Collision

This field displays how many late collisions occurred on the Ethernet controller. A normal collision occurs during the first 512 bits of the frame transmission. A collision that occurs after the first 512 bits is considered a late collision.

IMPORTANT!

A late collision is a serious network problem because the frame being transmitted is discarded. A late collision is most commonly caused by a mismatch between duplex configurations at the ends of a link segment.

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 420

RetransLimitExp

This field displays how many times the retransmit limit has expired.

TxUnderrun

This field displays how many transmission-underrun errors occurred on the Ethernet controller.

CarSenseLost

This field displays how many carrier sense lost errors occurred on the Ethernet controller.

26.11 INTERPRETING RF CONTROL BLOCK STATISTICS IN THE RADIO TAB (ALL)

Figure 151: Radio tab of Statistics page in SM, example

The Radio tab of the Statistics page displays the following fields.

inoctets Count

This field displays how many octets were received on the interface, including those that deliver framing information.

inucastpkts Count

This field displays how many inbound subnetwork-unicast packets were delivered to a higher-layer protocol.

Innucastpkts Count

This field displays how many inbound non-unicast (subnetwork-broadcast or subnetworkmulticast) packets were delivered to a higher-layer protocol.

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 421

indiscards Count

inerrors Count

This field displays how many inbound packets contained errors that prevented their delivery to a higher-layer protocol.

inunknownprotos Count

This field displays how many inbound packets were discarded because of an unknown or unsupported protocol.

outoctets Count

This field displays how many octets were transmitted out of the interface, including those that deliver framing information.

outucastpkts Count

This field displays how many packets for which the higher-level protocols requested transmission to a subnetwork-unicast address. The number includes those that were discarded or not sent.

outnucastpkts Count

outdiscards Count

This field displays how many outbound packets were discarded without errors that would have prevented their transmission. (Some of these packets may have been discarded to increase buffer space.)

outerrrors Count

This field displays how many outbound packets contained errors that prevented their transmission.

26.12 INTERPRETING DATA IN THE VLAN TAB (AP, SM)

The VLAN tab in the Statistics web page provides a list of the most recent packets that were filtered because of VLAN membership violations. An example of the VLAN tab is shown in Figure 152.

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 422

Figure 152: VLAN tab of AP, example

Interpret entries under Most Recent Filtered Frames as follows:

◦ Unknown—This should not occur. Contact Canopy Technical Support.

◦ Only Tagged—The packet was filtered because the configuration is set to

accept only packets that have an 802.1Q header, and this packet did not.

◦ Ingress—When the packet entered through the wired Ethernet interface,

the packet was filtered because it indicated an incorrect VLAN membership.

◦ Local Ingress—When the packet was received from the local TCP/IP stack,

the packet was filtered because it indicated an incorrect VLAN membership. This should not occur. Contact Canopy Technical Support.

◦ Egress—When the packet attempted to leave through the wired Ethernet

interface, the packet was filtered because it indicated an incorrect VLAN membership.

◦ Local Egress—When the packet attempted to reach the local TCP/IP stack,

the packet was filtered because it indicated an incorrect VLAN membership.

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 423

26.13 DATA VC (ALL)

Figure 153: Data VC tab of SM, example

The Data VC tab page displays the following fields.

This field displays the virtual channel number. Low priority channels start at VC18 and count up. High priority channels start at VC255 and count down. If one VC is displayed, the high-priority channel is disabled. If two are displayed, the high-priority channel is enabled

CoS

This field displays the Class of Service for the virtual channel. The low priority channel is a CoS of 00, and the high priority channel is a CoS of 01. CoS of 02 through 07 are not currently used.

Queue Overflow Cnt

This is a count of packets that were discarded because the queue for the VC was already full.

inoctets Cnt

This field displays how many octets were received on the interface, including those that deliver framing information.

inucastpkts Cnt

This field displays how many inbound subnetwork-unicast packets were delivered to a higher-layer protocol.

Innucastpkts Cnt

This field displays how many inbound non-unicast (subnetwork-broadcast or subnetworkmulticast) packets were delivered to a higher-layer protocol.

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 424

indiscards Cnt

inerrors Cnt

This field displays how many inbound packets contained errors that prevented their delivery to a higher-layer protocol.

outoctets Cnt

This field displays how many octets were transmitted out of the interface, including those that deliver framing information.

outucastpkts Cnt

This field displays how many packets for which the higher-level protocols requested transmission to a subnetwork-unicast address. The number includes those that were discarded or not sent.

outnucastpkts Cnt

outdiscards Cnt

This field displays how many outbound packets were discarded without errors that would have prevented their transmission. (Some of these packets may have been discarded to increase buffer space.)

outerrrors Cnt

This field displays how many outbound packets contained errors that prevented their transmission.

26.14 FILTER (SM)

The Filter tab displays statistics on packets that have been filtered (dropped) due to the filters set on the SM’s Protocol Filtering tab. An example of the Filter tab is shown in

Figure 154.

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 425

Figure 154: Filter tab on SM, example

26.15 NAT STATS (SM)

When NAT is enabled on an SM, statistics are kept on the Public and Private (WAN and LAN) sides of the NAT, and displayed on the NAT Stats tab. An example of the NAT Stats tab is shown in Figure 155.

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 426

Figure 155: Nat Stats tab on SM, example

26.15.1 NAT DHCP Statistics (SM)

When NAT is enable on an SM with DHCP client and/or Server, statistics are kept for packets transmitted, received, and tossed, as well as a table of lease information for the DHCP server (Assigned IP Address, Hardware Address, and Lease Remained/State). An example of the NAT DHCP Statistics tab is shown in Figure 156.

Figure 156: NAT DHCP Statistics tab in SM, example

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 427

26.15.2 Interpreting Data in the GPS Status Page (AP, BHM)

The GPS Status tab is only displayed when the Sync Input is set to Sync to Received Signal (Timing Port), which is the configuration desired when connecting an AP or BHM to a CMM2. See Sync Input on Page 237.

The page displays information similar to that available on the web pages of a CMM3, including Pulse Status, GPS Time and Date, Satellites Tracked, Available Satellites, Height, Lattitude and Longitude. This page also displays the state of the antenna in the Antenna Connection field as

◦ Unknown—Shown for early CMM2s.

◦ OK—Shown for later CMM2s where no problem is detected in the signal.

◦ Overcurrent—Indicates a coax cable or connector problem.

◦ Undercurrent—Indicates a coax cable or connector problem.

IMPORTANT!

If Unknown is displayed where a later CMM2 is deployed, then the connection is not working but the reason is unknown.

This information may be helpful in a decision of whether to climb a tower to diagnose a perceived antenna problem.

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 429

27 USING TOOLS IN THE GUI

27.1 USING THE SPECTRUM ANALYZER TOOL (SM, BHS)

See Monitoring the RF Environment on Page 363.

27.2 USING THE ALIGNMENT TOOL (SM, BHS)

An example of the Alignment tab in an SM or BHS is displayed in Figure 157.

Figure 157: Alignment tab of BHS, example

Proper alignment must achieve all of the following indications for an acceptable link between the modules:

◦ RSSI typically at least 10 dBM above receiver sensitivity

◦ jitter value between 0 and 4

◦ uplink and downlink efficiency greater than 90%, except as described under

Comparing Efficiency in 1X Operation to Efficiency in 2X Operation on Page 135.

Rele ase 8 Operations Guide

Issue 2, November 2007 Draf t 5 for Regulatory Review 430

IMPORTANT!

If any of these values is not achieved, a link can be established but will manifest occasional problems.

In the Alignment tab, you may set the following parameters.

RSSI Only Mode

In the RSSI Only Mode, the screen displays the signal strength based on the amount of energy in the selected frequency, regardless of whether the module has registered. This mode simplifies the aiming process for long links. To invoke the RSSI Only Mode, select

Enabled.

Radio Carrier Frequency

If you enabled the RSSI Only Mode, select the frequency (in MHz) for the aiming operation.

The Alignment tab also provides the following buttons.

Enable

A click of this button launches the slave device into alignment mode. Each further click refreshes the data in the tab to display the latest measurements collected.

Disable

A click of this button changes the slave device from alignment mode back to operating mode.

The Alignment tab also provides the following read-only fields.

Current Status

This field indicates either SM is in Alignment Mode or SM is in Operating Mode. This syntax is used in an SM and in a BHS.

RSSI

This field displays the Radio Signal Strength Indicator units and, in parentheses, the current power level, of the signal received from the AP or BHM.

Jitter

This field displays the jitter level of the signal received from the AP or BHM.

Number Registered Users

This field displays how many slave devices are currently registered to the master device whose beacon is being received during the aiming period.

In addition, the Alignment tab includes the following Detailed Beacon Information where it is available.

+ 91 hidden pages