Strix Outdoor Deployment Guide Rev A

SSttrriixx MMeettrroo--WWiiFFii OOuuttddoooorr DDeeppllooyymmeenntt GGuuiiddee

Outdoor Deployment Guide

Table of Contents 1. Introduction................................................................................................................. 3 2. Requirements .............................................................................................................. 4 3. Network Design .......................................................................................................... 4

3.1 Applications and Services .................................................................................... 5 3.2 Network Topologies............................................................................................. 6

3.2.1 Strix Wireless Mesh Topology ..................................................................... 7 3.2.2 Overall Network Topology ........................................................................... 8

3.3 Node Spacing and Density Considerations .......................................................... 8 3.4 Management Traffic Segmentation.................................................................... 10 3.5 User Traffic Segmentation – VLANs................................................................. 12 3.6 IP Addressing Considerations ............................................................................ 13 3.7 Client Connect Privacy (CCP) Considerations .................................................. 14

4. Criteria for Selecting Locations ................................................................................ 15 4.1 Pre- Site Survey Design ..................................................................................... 16

4.1.1 Information Gathering ................................................................................ 16 4.1.2 RF Environment Analysis........................................................................... 17 4.1.3 Preliminary Map Designs ........................................................................... 18

4.2 Site Survey ......................................................................................................... 22 4.2.1 Qualifying Backhaul Locations .................................................................. 23 4.2.2 Pole Qualifying Techniques........................................................................ 24

4.3 Antenna Selection .............................................................................................. 27 4.3.1 Unlicensed Spectrum and FCC Limitations ............................................... 27 4.3.2 Node-to-Client Spacing (802.11g).............................................................. 29 4.3.3 Node-to-Node Spacing (802.11a) ............................................................... 29

5. Pre-Staging Nodes .................................................................................................... 31 6. Deployment Phase - Node and Antenna Installation ................................................ 33

6.1 Requirements Prior to Deploying Nodes ........................................................... 33 6.2 Node Deployment Strategy ................................................................................ 34 6.3 Node Mounting .................................................................................................. 35

6.3.1 Rooftops...................................................................................................... 35 6.3.2 Towers......................................................................................................... 37 6.3.3 Light Poles .................................................................................................. 38

6.4 Antenna Installation ........................................................................................... 39 6.4.1 Antenna Isolation ........................................................................................ 39

6.5 Grounding and Powering Considerations .......................................................... 40 6.6 Checking Node Connectivity ............................................................................. 41

7. Starting and Configuring the Network...................................................................... 42 7.1 Including Nodes in the Network ........................................................................ 42 7.2 Including Remote Networks or Subnets............................................................. 42 7.3 Recommended Client Connect Settings............................................................. 44

Appendix........................................................................................................................... 45

P/N 210-1038-01 Copyright © 2007 Strix Systems, Inc. All rights reserved. of 45


1. Introduction The SCOPE of this document is to provide Strix Systems customers and partners with guidelines to deploy the mesh Access/One Network® in a metro or city environment. The different sections of this guide will help companies that are planning to deploy Strix outdoor wireless networks to understand what is required and what logical steps to follow. These sections contain information that go from general considerations on network design and planning to product specifications and third party products integration. It is based on real world examples of networks that have been successfully deployed and are currently operational. This document should be used in conjunction with the Access/One User Guide as well as any other Strix Systems training material that will be referenced throughout this document. This document is not intended to be a comprehensive guide for RF site surveys or RF propagation calculations, although these topics will be discussed. The reader should use other specific tools for these purposes. Also, since no two deployments are alike and each one has its unique considerations, this document can NOT be used as a generic tool to calculate node density or to generate purchase orders without performing a site survey.



2. Requirements The reader is required to have some level of expertise in data networking, routing and Ethernet switching as well as some experience in RF propagation. It is also necessary to understand how the Strix Wireless Mesh works, either through experience or attendance at a Strix training course. To start, the first item that is required is a wired egress location, or Ethernet drops that connect to the customer network resources, Internet or other services. Other networking infrastructure is required or highly recommended so that the traffic flow can be segmented or routed to different destinations. Below is a list of items that systems integrators need to deploy a Strix mesh network, which will be discussed in further detail in the subsequent sections.

- Backhaul fiber, Ethernet, or other connections throughout the deployment that will provide access between the wireless mesh traffic and the rest of the world

- VLAN Ethernet Switches - Routers (if implementing multiple subnets) - 1 Core L2/L3 Switch (“Switch/Router”) - DHCP server(s) and/or Access Gateways - RF interference monitoring devices (spectrum analyzers or 802.11 analyzers) - Mapping software or web mapping tools - Site survey equipment - Installation tools

3. Network Design A successful deployment begins with a strong network design that takes into consideration many important factors, both on the wired and wireless side of the network, such as network topology, capacity, node density, antennas, etc. But in order to properly design the network, the first significant items to consider are the applications and services that are intended to be offered. For example, some of the information below is necessary to provide a comprehensive network design.

- Types of traffic: applications and services - Types of users: fixed or portable subscribers, nomadic or guest, commercial,

government, public safety mobile, etc. - Tiered service levels: Free, 512 kbps, 1 Mbps, 2 Mbps, etc. - Total number of users in the network and average simultaneous usage - User density, subscribers per radio/unit - Capacity of the network and available bandwidth per user - Wireless user devices such as residential customer-premises equipment (CPE),

personal digital assistant (PDA), Laptops, WiFi phones, etc



- Environmental information such as tree density and other obstacles - Available locations for node placement (e.g. light poles, roof tops, towers)

3.1 Applications and Services The applications and services that will be offered in the network will determine what features need to be enabled in the Access/One Network and will be a crucial factor in completing the network design. The following are the most common application and services that are offered by service providers that deploy Strix wireless networks:

- Hotspot/Hotzone Internet access - Residential broadband access - Public Safety infrastructure - Voice services - Video surveillance - Meter reading, mobility and other outdoor enterprise

Independent of the applications that will be offered, the most important factor that determines the network design is the amount of expected traffic within the network. For instance, internet voice and data traffic may require 1.5 Mbps (DSL rates) of bandwidth per user; public safety may require 200 kbps per user, etc. Since each Strix radio can support multiple service set identifiers (SSIDs), each with their own unique security schemes, and preserve the aggregated bandwidth via a dual radio backhaul, a Strix multi-radio node offers the flexibility and superior performance in supporting various customer applications and services. As wireless clients connect to different SSIDs on the same radio, their traffic can be separated and put onto unique virtual LANs (VLANs) for added security and performance. As an example, a typical municipal WiFi application would offer services to residential customers, public safety and first responders, city employees, and voice



over WiFi (VoFi) phone customers: each on a separate VLAN. Meanwhile, a wholesale ISP could potentially offer services for customers of other ISPs by simultaneously broadcasting other SSIDs. 3.2 Network Topologies There are a variety of network topologies that can be considered when designing Strix mesh networks. In general they will have a similar hierarchical structure and, among other things, the topologies will be regulated by the egress point locations. The components involved in such topologies (from the outside in) include:

- Mesh Access Layer - Mesh Distribution Layer

• Strix Mesh Network (Layer 2) - Core Network Layer

• L2/L3 Edge Switch • Core Switch/Router

- Access Gateway and other services - An Internet or private broadband connection point



In the mesh distribution layer, Strix highly recommends supplying (2) egress points per Ethernet segment or subnet, which will provide a few benefits: load balancing, failover/redundancy, and controlling the total number of hops (when deploying larger subnets as will be discussed in Section 3.4).

3.2.1 Strix Wireless Mesh Topology The Strix Access/One Network is a high-performance wireless mesh network that forms a distributed Layer 2 switching architecture. Decisions are made locally at the individual radio and node, so there is no need for a routing protocol which creates overhead thereby increasing latency. This unique network also utilizes (2) separate 802.11a radios for the backhaul: one for ingress traffic (downlink) and one for egress traffic (uplink), effectively creating a “wireless full-duplex” backhaul connection every step of the way. The mesh topology forms a tree-like structure where each node has a dedicated link to another node eventually reaching the head-end location or termination point. At the same time, each node is fully aware of all its neighboring nodes and is ready to switch paths if there is a link failure (self-healing) or a more optimal path (self-tuning) that would provide the greatest throughput and lowest latency for wireless subscribers. In the diagram below, the head-end location will have one or more nodes, each with two or more backhaul radios, depending on the bandwidth requirements.

All the Strix nodes that fall under the same managing domain, with one or more subnets, are referred to as being members of the same “Cloud”. The concept of the Cloud will become more important in the following sections.



3.2.2 Overall Network Topology As part of the overall network topology, there are two basic sections: Layer 2 (Switching) and Layer 3 (Routing). Normally, if the core backhaul connection or the WAN interface between each subnet and the Core Switch/Router is reliable and has high bandwidth (e.g. 100Mbps Fiber Ring), then the overall network topology will look like the diagram below. It illustrates that there will be VLAN switches at the edge of each subnet bridging the traffic to the core. However, if the WAN interface has lower capacity or does not have reliable connections in the core backhaul (e.g. wireless or microwave backhaul links, DSL, T1-T3), then you need to provide the routing function at the edge of each subnet via an L3 switch.

3.3 Node Spacing and Density Considerations For a given deployment, node spacing and user density parameters should be considered in order to guarantee a certain level of per-user throughput and latency performance. The expected number of subscribers per node and the bandwidth requirements per subscriber



has a direct impact on the node density and total number of hops, number of egress locations and types of antennas used, among other things. The first step is to identify the variables that are going to be the driver for the deployment: Laptop reach to the user access radio (e.g. 802.11g), Public Safety CPE coverage (4.9 GHz), or the wireless mesh backhaul (802.11a). This is accomplished by identifying each of the user type link quality expectations for a given expected bandwidth. See table below for examples of the minimum link quality levels required for a given user type: User Type Min. Link Quality (dBm) Node to Node (11a backhaul) -75 Laptop (Outdoor, 11g) -80 CPE (Indoor signal, Residential, 11g) TBD CPE (Outdoor signal, Residential, 11g) -82 CPE (In Vehicle, Public Safety, 4.9 GHz) -80

Although the maximum number of associations allowed in a Strix radio is 128, there should not be more than 32 simultaneous subscribers on the same radio in one node, regardless of the bandwidth requirements. This parameter is configurable on a global or Cloud level basis. In addition, based on the type of applications and bandwidth service agreements, this number could be set even lower. The user density or the city’s demographics are also variables to consider for node density. If the user density in a particular area of the deployment will make the number of simultaneous connections exceed the maximum established, then this will be the driving factor in the node density instead of coverage and signal levels. The table below illustrates an example of the city demographics that could be taken into consideration.



3.4 Management Traffic Segmentation When designing a Strix wireless mesh network, designing the management component is one of the more important considerations. Strix management is handled primarily by the Strix Network Server (NS). As nodes boot up and mesh across the network, they are validated by the Network Server for a license. As new nodes join an existing network, the “Master” NS adds them to its inventory list within the Cloud level configuration and disseminates this global configuration file to those nodes (via FTP). Then the Network Server updates the rest of the network in real-time as to the new members of the Cloud. This communication and all other management communication between the mesh nodes (specifically every module within each node) and the “Master” NS is performed using IP multicast. Please refer to the Access/One User Guide for more information. Each Strix management subnet should have (2) Network Servers (one at each egress point), each with adequate licenses for the entire subnet. One of the Network Servers will act as the “master” while the other as a redundant or “standby” server. Both NS’s will also act as redundant servers for each other in the case of failure since the two servers automatically synchronize with each other. In small to medium deployments of up to 100 Strix nodes, a single IP management subnet network should be sufficient for all the nodes and Network Servers. However, in larger deployments of a 100 or more Strix nodes, common to municipal WiFi deployments, segmentation needs to be done to minimize the amount of management traffic to a given management subnet. It is recommended that no more than 75 - 100 Strix nodes exist on a single management segment or subnet. This is because every radio board within a node is considered a separate IP addressable element. Therefore, as with any L2 network (wired or wireless), it is not optimal to have too many elements within the same broadcast domain. For example, if the total size of the network is designed to have 350-400 Strix nodes, the management network will need to be segmented into 4 different management subnets each with less than 96 nodes and each with their own pair of Network Servers (model “NS-96”, the maximum number of licenses that a single server can provide). In addition to the (2) Network Servers recommended for each management subnet, a Cloud with multiple subnets is required to have one of those subnets designated as a Master Subnet. The remaining subnets will be referred to as “remote” subnets. Once a Master Subnet is selected, the Network Servers within that subnet will now be designated as “Static” Network Servers as seen by the remote subnets. Below is a diagram of this type of large network:



The Static Network Servers will communicate with each of the remote subnet’s Master Network Server using IP unicast. Therefore, in these large deployments, all Master Network Servers across the various management subnets will need to be able to route IP traffic to and from the static Network Server, via routers of course. Furthermore, the remote Master NS’s do not communicate with each other, only with the Static Network Servers in the master subnet. Of the many functions of the static Network Server, the more important functions are that it maintains the consistency of the Cloud level configuration across the various management subnets, and it acts as the primary management interface for the Strix network administrator or network operation center (NOC). It’s typically where all the network-wide configuration changes and network-wide monitoring are performed. It is strongly recommended that customers use an NTP (Network Time Protocol) server to synchronize Access/One Network to one clock. This will ensure that the system's internal Syslog time-stamping process is maintained correctly. Without an NTP server (no universal clock), each network server will use its own internal clock and stamp times accordingly. One last note regarding Network Servers is that any NS, whether it is an OWS or IWS module, may be used to manage the Strix Access/One network. The reason this is important to mention is that a standalone IWS with just a single IWS NS module may be co-located with the edge switch inside the building of a head-end location.



3.5 User Traffic Segmentation – VLANs As previously discussed, wireless client traffic can be segmented into their own virtual local area network (VLAN) using SSID to VLAN mappings. In a Strix wireless mesh network, client traffic traverses from node to node over a secure wireless connection until it reaches a wired head-end node. With SSID to VLAN mappings configured, each radio will tag its wireless client traffic with the appropriate VLAN ID and this tag information will traverse the entire mesh until it reaches or exits the wired head-end node’s Ethernet port. It is common under wireless hotspot applications to have multiple SSIDs that each serves a unique group of customers. In the municipal WiFi example, residential, public safety and fire, and voice over IP (VoIP) cell phones customers would each have a unique SSID mapped to a VLAN. In addition to this segmentation, it may also make sense to enable Class of Service (CoS/”Priority/One”) so that certain VLAN traffic has priority over other traffic. For instance, traffic from a public safety VLAN (e.g. voice traffic) would have higher priority over video or data traffic coming from other VLANs.

As mentioned previously, Strix management traffic is another important aspect that requires special attention. Since management frames are sent untagged as it exits the Ethernet interface of the wired head-end node, the Layer 3 network needs to know how to treat the untagged frames so that they are routed appropriately to any and all Network Servers and management stations. In larger deployments where multiple management subnets exist, the Layer 3 edge switches, where the wired head-end nodes are plugged into, need to be able to detect incoming untagged frames and assign them to a unique VLAN. This is commonly known as “switchport trunk native vlan” configuration supported on most L3 switches.



3.6 IP Addressing Considerations There are two basic IP addressing policies to consider: Dynamic Host Configuration Protocol (DHCP) and Static IP. There are many advantages to using dynamic host configuration protocol (DHCP) or Static IP addressing on a network. In addition to the ease of configuration and management of using DHCP compared to static IP addresses, in a Strix wireless network, DHCP adds another benefit. It allows for added robustness to the AP selection algorithm since the round trip delay is one of the many factors used to determine path selection for a node. Therefore, if the round trip algorithm fails against the designated gateway, the algorithm can be run against the DHCP server and if necessary the DNS servers as backup. This can be achieved with static settings as well, however it requires more settings to manually configure. Going a step further, configuring DHCP static reservations for each radio module is highly recommended for a properly designed Strix network. DHCP reservations provide the network with the added benefit of static IP addresses on a per host basis. In general, for a Strix wireless network, maintaining the same IP address on each of the radio modules is very important since it provides consistency, which is great for tracking and troubleshooting purposes. On the other hand, configuring static IP addresses has its benefits as well. Since the IP addresses of every module within a Cloud are stored within the Cloud configuration file of each node module on the network, management traffic would be affectively kept at a minimum during reboots or DHCP renewals (due to lease expirations). Furthermore, the best solution would actually be a combination of DHCP static reservations with static IP addresses. In other words, all modules will boot up with static IP addresses (this means less DHCP traffic in the event of a network-wide reboot) and in the event that any given module loses its configuration files or was “factory defaulted”, there is always the DHCP reservation to serve as a backup. Configuration Tips:

- Be sure to configure the subnet IP mask and the gateway correctly in the DHCP server (otherwise the mesh network will not form properly)

- Try to have an IP addressing scheme for modules within a node. For example, match the third octet of the IP address with the radio module position in the stack:

Stack Position IP Address Radio Board 1 (Bottom) 172.16.1.25 Radio Board 2 (Middle) 172.16.2.25 Radio Board 3 (Top) 172.16.3.25



3.7 Client Connect Privacy (CCP) Considerations When the Client Connect Privacy feature is enabled in the Strix mesh on a per-SSID basis, Wi-Fi users on that SSID are prevented from communicating with each other on the same module and throughout the mesh. Data from each Wi-Fi device is sent only to the Ethernet or backhaul ports, requiring a router or other access device for authentication before allowing the devices to exchange data. This feature effectively has the benefit of preventing “flooding” attacks since all broadcast traffic is directed to the wired head-end and dealt with by the Layer 3 device preventing broadcasts from flooding the entire wireless network and its subscribers. With CCP enabled across the mesh on a particular SSID, a given radio will encapsulate the traffic coming from the wireless subscriber within another temporary VLAN ID. This extra tagging is stripped once it reaches the Ethernet port of any node (e.g. a head-end location). When implementing this highly recommended feature for “public access” SSIDs, there is one thing to remember. If you have a head-end location with more than one OWS node as illustrated below, it is required to install a switch that offers port isolation on a per-VLAN basis. If you do not find a VLAN switch that supports this type of isolation, then you need to separate the NS from the OWS nodes (by installing an IWS node with a NS only) and to connect the OWS nodes and the IWS individually on dedicated ports in the switch. So for the scenario below, you need to enable port isolation on the ports where the OWS nodes are connected but NOT on the port where the IWS NS is connected. For further assistance, please contact your Strix representative.



4. Criteria for Selecting Locations This section is designed to provide guidelines on how to select or qualify locations to install Strix Systems Access/One wireless nodes in a city (generally in the US). It is designed for areas mainly with residential zones and some industrial areas. Although many tips in this document are valid for deployments in cities outside the US, the height and density of buildings in many European and Asian cities would make the procedure similar to the downtown areas in US cities. Additionally, the photocell devices that turn the light pole lamp on, based on daylight conditions, is generally available in the US but not in many other countries where several poles are controlled by a centralized switch (gang switched). In those cases, light poles will only have power from dusk till dawn. Consequently, alternative forms of constant power are required.

This document assumes the majority of Strix nodes are powered using the photocell device available on top of light poles. The procedure outlined is optimized to create the wireless mesh backbone, minimizing the node density and providing access to the major and secondary streets within residential areas. Further node locations may need to be qualified if additional coverage is required. For coverage inside subscriber residences or businesses, it is recommended to use a CPE such as the Strix Edge Wireless System (EWS).



4.1 Pre- Site Survey Design In general, this portion of the design can be broken down into three categories: information gathering, radio frequency (RF) environment analysis, and preliminary map designs. 4.1.1 Information Gathering A lot of information can be obtained directly from the city’s management. In some cases, one could obtain most of the city’s information straight from the Internet. Also, information such as street maps, topographical maps, and aerial photos can be used to analyze the physical environment. Geographical Information System (GIS) data and its tools are another great way to further analyze the environment. For information on GIS, visit the website: http://en.wikipedia.org/wiki/Gis

For mounting on light poles, which will make up a majority of your installation locations, a list of light pole locations that provide information on location, power, and other conditions would be extremely beneficial. Especially look for such information as how the light poles are powered (individually, gang-switched or shared power) and the city’s engineering documents on each pole type. This is to ensure the light pole structure can handle the additional wind and weight load of the Strix node and antennas. Another important part of information gathering is permits, rights of way, etc. Make sure to obtain a licensed contractor that can access the light pole with a cherry picker truck. Note: Some light poles might be located on facility poles carrying high voltage and other services. Not all contractors have licenses to access those poles.



4.1.2 RF Environment Analysis Note: The intent of this section is not to show you how to perform an RF analysis of your environment but rather to highlight the fact that this analysis is important to perform and to highlight the various considerations involved. Performing an RF scan of the environment is essential in setting the appropriate expectations. Due to the nature of Wi-Fi, which operates in unlicensed bands, it is expected that there will be some sources of interference that will be exhibited in certain locations more than others. For example, in residential areas where there are primarily single family home dwellings, there will be little interference on 802.11g and virtually no interference on 802.11a. In residential areas where there are primarily high occupancy dwellings or multi dwelling units (MDUs), one can expect more interference on 802.11g and still virtually no interference on 802.11a. In downtown or university settings, one can expect perhaps more interference on both frequency bands, with still a lot less interference on 802.11a. The main point to remember is to recognize all significant RF conditions. An RF signal in space is attenuated by obstacles that are within the Fresnel zone, atmospheric and other effects as a function of the distance from the initial transmission point. RF survey issues to keep in mind include but are not limited to:

- Spectrum analysis of the geographic area at the desired frequencies - Spectrum analysis at neighboring frequencies - Anticipated changes in local RF conditions (such tree growth, seasonal changes,

and urban development) An essential element in RF network planning is the analysis of spectrum usage and the signal strength of these various users. There are several tools that are very useful for performing such RF analysis and when it comes to analyzers, there are two basic types: protocol analyzers and spectrum analyzers. Protocol analyzers will provide information about other WiFi networks in the vicinity that can create contention. This part can be accomplished primarily with the internal tools provided by the Strix Access/One network. With spectrum analyzers, one can obtain good information not only about other WiFi interference but also about other RF sources that are in the same frequency bands in which the network will operate. Examples of such interference include those from microwave ovens, cordless phones, Bluetooth devices, in-home systems such as child monitors, cameras, etc…



The following are some of the available tools for RF spectrum analysis.

- Agilent E4403B - Anritsu MS2721A - Rohde & Schwarz FSH3 Spectrum Analyzer - Cognio Spectrum Expert (PCMCIA card) - Berkley Varitronics (‘BumbleBee’) - AirMagnet (PCMCIA Card)

4.1.3 Preliminary Map Designs Before diagramming network layouts, anticipate the correct amount of signal loss for your link budget calculations. Include such parameters as the antenna gain, transmit power and cable/connector losses to calculate the effective isotropic radiated power (EIRP) levels, receiver sensitivity of the Strix radios, propagation losses, etc. Use this information to determine the range of the system in your specific network deployment. Refer to the Strix OWS data sheets for detailed information on some of these parameters. Also, there are plenty of RF planning tools such as link budget calculators that are widely available on the Internet. For example, the following site has a comprehensive set of tools: http://home.deds.nl/~pa0hoo/helix_wifi/linkbudgetcalc/wlan_budgetcalc.html

Software and Web Mapping Tools A good way to plan or design the network and to keep track of all the node mounting locations is to use some type of mapping software with satellite imagery.

Also, the use of Google Maps (or other similar online mapping sites such as Map Quest, Yahoo! Maps, etc) is a great way to quickly develop preliminary or pre- site survey designs. These types of web map servers are useful because they provide an application programming interface (API) that enables users to associate attributes with interactive maps. This is in effect a GIS. However Google Maps is largely "point" oriented and



other than using different point markers, you have to click on the markers to get the metadata.

Primary Grid Cities with grid-like streets typically require fewer nodes than ones with non-linear streets due to the higher likelihood of obstruction. In dense, urban areas, a cell should be placed on each street in which coverage is required (intersections are often excellent choices). Once the area where required coverage is identified, it is recommended to divide the area into square sections (generally square miles), this helps control the density of nodes per unit area and helps in planning sections more effectively. Steps:

1. Identify all the major streets in the city, usually ones with two lanes in each direction.

2. Next, identify major intersections, (intersections between major streets) and secondary intersections (intersections between major and secondary streets).

3. Start placing markers on major intersections. Major intersections are usually separated one mile apart from each other but there may be cases where they are closer together (1/2 mile).

4. On a major street where two major intersections are one mile apart, you should plan to place about 4 to 5 nodes (400 yards apart), depending on the line-of-sight. When qualifying locations on the major streets, try to align the locations with the



secondary intersections. This will enhance the propagation of the mesh into the neighborhoods or the secondary grid.

Alternate Locations Method (“Zigzagging”) In order to avoid tree attenuation, try to identify locations on alternate sides of the street. If one node goes on the South side of the street, the next should go to the North. A similar approach should be used on streets where nodes are on the East and West of the street. Even if trees are lined up along the sidewalk, which will attenuate the signal along the same side of the street, it is likely that there will be line-of-sight (LOS) or near-LOS across the street in diagonal.

Secondary Grid Identify locations in residential or business areas inside the primary grid. Follow the same approach of alternate sides of the street also for the secondary grid. Depending on the coverage requirements, expect to provision approximately 25 locations per square mile.



In general, one could easily see that every square mile is going to require varying amounts of node locations, depending on terrain and coverage requirements. Example of an area that may require 25-30 nodes per square mile:

Example of an area that may require 20-25 nodes per square mile:



4.2 Site Survey Although a lot of planning and design can be accomplished from the desk, the physical site survey is still the critical component of the outdoor deployment. This set of procedures typically involves a team of field engineers in order to properly survey and identify the best location for a Strix OWS node. There are several factors to consider when conducting a site survey including such things as:

- Verifying the estimation of coverage area - Type and density of surrounding foliage - Availability and height of mounting locations - Visibility of candidate location to surrounding locations - Geographic conditions, including man made structures - Environmental conditions, including seasonal changes

While verifying the availability of locations, if you find that there isn’t an actual mounting location in the area that you planned to place a node, backup mounting locations such as light poles, rooftops or other structures with reliable power sources should be considered. This is where science starts to become an art since each of these alternatives has its own set of challenges.

A site survey being performed with a Tablet PC and a windshield attached GPS device



4.2.1 Qualifying Backhaul Locations Backhaul locations are where the nodes that are wired will be installed. These places provide access to data services via several media types such as Fiber, Ethernet, T1, T3 or other types of wireless backhaul infrastructure. The following are guidelines to consider when qualifying backhaul locations such as building rooftops (other possible locations include towers, water towers, silos, etc):

1. Make sure that the proposed location can “see” at least 5 to 10 light poles (or other buildings with nodes) in each direction

2. The building height should not be too high (more than 5 stories). Otherwise you will have to account for mechanical downtilt on the antennas

3. Check for an existing roof penetration that could be used 4. Ensure there is adequate and appropriate power and grounding for the node 5. DO NOT run extension cords on the roof. This is prohibited by most building

codes and is a fire and trip hazard. Use appropriate conduit 6. You will need at least 9 sq. feet of flat roof for non penetrating roof mount if the

nodes are mounted on a tripod 7. You will need conditioned, secure rack space available within 100 meters

(Ethernet cable run limit) of the rooftop location 8. Be sure to perform spectrum analysis from this location. Ensure the analyzer is

directly attached to the same antenna that will be used in the deployment.

n

s

p

P/N 210-1038-01 Copyright © 2007 Strix Systems, Inc. All rights reserved.

Example of a “roof mount” ode for a wired location. This configuration shows two 11g ector antennas and two 11a

antennas (one atch, one omni)

of 45


4.2.2 Pole Qualifying Techniques The following is a set of techniques proven to be an effective way to qualify light poles which will comprise approximately 80% of your node locations for a given citywide deployment. Only poles that are continuously powered and switched by a photocell will be selected. Basic Requirements

- A vehicle - A two person team

- A laptop (preferably a Tablet PC) with an external wireless card (internal wireless cards tend to be under-powered)

- A power inverter (with auto adapter) to power the laptop

- A software-based mapping tool such as Microsoft Street and Trips or a similar program that has the capability of attaching a GPS device and displaying the location of the vehicle

- The following example color and symbol schema can be used to mark up the

Streets and Trips map:

o Yellow circle – Location identified on the map as optimal desired location.

o Green circle – Location visited by the team and validated that there is at least one light pole to install nodes. Green locations are target locations for the installer.

o Red circle – Location visited by the team where there is no option to install a node but it is still a desirable location.

o Green flag – Location where a node has been installed.



- An additional handheld GPS device may be convenient at times when you need to walk around visiting special access areas to gather exact distances and antenna direction headings

- Masking tape (colored) to mark the selected poles so that the installers may find the locations quickly (Note: use a vinyl-based tape that can be easily removed in the future. DO NOT use painter’s tape or the like as it is brittle and won’t come off easily after hardening in the sun)

“Hitting the Road” There are several types of light poles (Arch, Stream, Modular, Traffic, Wood, etc) to choose from and many types of location decisions to be made. The following are some of the guidelines to consider:

1. Visit the locations that have been selected on the map as yellow locations

(optimal desired location). 2. Start from the locations closer to the wired backhaul site for the segment under

deployment and work your way out. General rule of thumb for inter-node spacing is up to 400 yards if you have line-of-sight and approximately 300 yards if you do not have LOS (e.g. light to medium foliage present).

3. Confirm that the visited intersection has at least one valid pole to install a node.

If possible select a secondary pole as a backup. This is important when the first selection is a facility pole, since it may not be a valid option, when the installer tries to install or power the node.

4. Photocell on head of lamp is a requirement. There should not be any dents, rust,

cracks, wood splitting, etc. visible on the pole. Note: There may be situations where not all of the photocells on the poles in an intersection control the power to the pole. Usually, one of the four poles controls the other three. In some cases it is easy to see the wiring between the poles and identify which one is the pole with the active photocell.

5. Mark the location with a green circle if it has at least one valid pole to mount.

6. Visit the next location in the primary grid (major streets and throughways) and try to follow the “zigzag” approach for pole selection. Repeat the same process for the main roads in the secondary grid.

Note: When pole qualifying, be sure to allow for tree growth and seasonal changes, particularly if the site survey is being performed during the winter months where most of the trees will be void of leaves.



Examples of Pole Selection Good pole selection:

Bad pole selection:

This wide metal portion of the pole will block the signal to the right for the lower antenna.



4.3 Antenna Selection Selecting the right antenna for a particular application is critical to a successful outdoor deployment. A wide variety of 802.11 antennas are commercially available through numerous vendors. In order to select the best antenna for your particular deployment, you need to first know what antenna types are available and what the characteristics are of each type. Please refer to the document, Strix Recommended Antennas, for further information. The following sections highlight the expected distances between two nodes and between a node and a client device, based on the type of antenna selected. When choosing an antenna, carefully consider the site requirements, as each antenna has different performance characteristics. 4.3.1 Unlicensed Spectrum and FCC Limitations The Unlicensed National Information Infrastructure bands, also known as the UNII bands, are part of the frequency spectrum utilized by radios operating as IEEE 802.11a compliant devices. The 5.725 – 5.825 MHz band is sometimes referred to as the UNII / ISM (Industrial, Scientific, and Medical) band since they share the same channels with the exception of Channel 165, which is an ISM channel. The chart below exhibits the number of non-overlapping channels currently available for use:



The following is a summary of the FCC regulations regarding outdoor point-to-point and point-to-multipoint EIRP limits (power at antenna and antenna gain). Note: The maximum EIRP allowed for any point-to-point link (2.4 GHz or 5 GHz) is 200 Watts.

• FCC limit for point-to-multipoint links (2.4 GHz or 5 GHz) = 4 Watts (36 dBm)

Example: 1 Watt (30 dBm) transmitter + 6 dBi antenna

• For point-to-point links (2.4 GHz), the limit is higher based on the following rule:

For every 1 dB you reduce the transmitter power (from 30) you can increase the antenna gain (of 6) by 3 dB.

• For point-to-point links (5.8 GHz aka UNII-3), the limit is based on the following rule (FCC Part 15.407):

“…devices operating in this band may employ transmitting antennas with directional gain up to 23 dBi without any corresponding reduction in the transmitter peak output power…For fixed, point-to-point U-NII transmitters that employ a directional antenna gain greater than 23 dBi, a 1 dB reduction in peak transmitter power… for each 1 dB of antenna gain in excess of 23 dBi would be required.”



4.3.2 Node-to-Client Spacing (802.11g) The table below highlights the expected link distances between a node (using a typical 9 dBi omnidirectional antenna) and a CPE device. Note: Range estimates are based on typical results and require line-of-sight (LOS), which means a given link will need a clear, unobstructed view of the antenna from the remote point. There are several factors that could affect the operating range and performance. Obstacles such as buildings, trees or foliage will at a minimum partially block the signal. Also, if the CPE device is indoors, factors such as building wall material and thickness will have an effect. These guidelines will work well for the majority of outdoor installations. However, due to the numerous factors affecting range and performance there is no guarantee that you will achieve these results for your specific deployment.

Antenna Configuration Distance to Client CC: 9dBi Omnidirectional CPE: Built-in PC 802.11g wireless (30mW) Up to 300 feet

CC: 9dBi Omnidirectional CPE: Indoor 802.11g (400mW) Omni Ant. Up to 1200 feet

CC: 9dBi Omnidirectional CPE: Mobile Node 802.11g (400mW) Omni Up to 1200 feet

CC: 9dBi Omnidirectional CPE: Outdoor 802.11g (400mW) Patch Ant. Up to 1500 feet

4.3.3 Node-to-Node Spacing (802.11a) The diagram and table below illustrate the approximate node-to-node spacing one would expect with Strix OWS nodes in a typical line-of-sight (LOS) or near LOS city environment with a small number of obstacles such as trees. In a majority of the cases, 10 dBi omnidirectional antennas on the nodes would suffice. However, if there are some obstacles in a near LOS environment, such as minor obstructions or tree foliage, a patch antenna would help considerably. Keep in mind that if you are deploying a network where the weakest client is a laptop internal wireless adapter (typically no greater than 50mW or 17dB), you should expect a



maximum node-to-client distance of around 200 yards or 600 feet (which is 400 yards or 1200 feet between nodes). This amounts to approximately 25-30 nodes required per square mile, depending on the environment.

Antenna Configuration Distance between Nodes 1 CC: 10dBi Omnidirectional NC: 10dBi Omni-Directional Up to 1200 feet

2 CC: 10dBi Omnidirectional NC: 12dBi Patch Up to 1500 feet

3 CC: 12dBi 120 Deg Sector NC: 12dBi Patch Up to 1800 feet

4 CC: 23dBi Directional NC: 23dBi Directional Up to Several Miles

Note: At first glance, if one wanted to use a 12 dBi omnidirectional antenna, one would notice that the combination of that antenna and the output power of an OWS radio (26 dBi) would exceed the FCC limit of 36 dBi for point-to-multipoint systems. However, keep in mind that this FCC limit is EIRP, which means you need to take into account the losses in the transmission line (e.g. cables, connectors, etc), which for some types of installations could easily add up to 2 dBi.



5. Pre-Staging Nodes Prior to deploying and installing a Strix node to its designated location, it’s recommended that nodes go through a pre-staging process. This process includes upgrading firmware on the radio modules, joining the nodes to the Cloud and management subnet, and proper tracking and documentation of the nodes. It’s recommended that the firmware version running on the radio modules is up to date and matching that of the entire network including the Network Servers. Upgrades can be accomplished network-wide through Manager/One or on an individual basis to each radio module. Both methods require an FTP server containing the appropriate software binary images. For an existing network of Strix nodes, by far the easiest and quickest method to perform a software upgrade is by using Manager/One. Please refer to the Access/One User Guide for more information. In a pre-staging environment where a Network Server is not readily available and you’re only upgrading a few nodes at a time, the manual option might prove to be faster and easier. This technique requires that the FTP configuration parameters get manually entered into each radio module through either a CLI telnet session or a web interface. The following commands are issued to each radio module over a CLI telnet session.

- ftransfer params set hostname <ftp server IP> - ftransfer params set username <username> - ftransfer params set password <password> - ftransfer params set path <path>

And to force a download of an image on that radio module, “ftransfer download image” is issued. All of the above CLI commands could be executed via a simple script to make the process even faster. Again, this type of firmware updating could be accomplished via the web interface of the individual module as well. Once a node is running a suitable firmware version, it’s recommended that before the node is physically installed it gets joined to the appropriate Cloud and management subnet through Manager/One. For smaller deployments this is not as important of a step since there’s likely to be only a single management network. But for bigger deployments which can have multiple management subnets, the ability to instruct which management subnet a node needs to join is crucial. When a node is included into a Cloud, a global configuration is uploaded into it. Not only will this provide the radio modules with the Cloud level configurations, but it will also dictate which other nodes it’s able to connect to. The other option is to have the node deployed with factory defaults which is not only less secure and can lead to the node being hacked into, but it can also be a lot more difficult getting the node joined to its designated Cloud and management subnet. Factory defaulted nodes are resilient and will likely mesh to any Strix network that’s within reach even those that you don’t want them to associate to. That’s why it’s highly recommended



for every type of Strix deployment that during the pre-staging phase a node is joined to the appropriate Cloud and management subnets. And finally, maintaining an accurate and updated database of any and all details related to each node’s installation is required. For example, the database should have the following entries:

• Node installation location, description of intersection and pictures if possible • Node serial numbers • Type of installation and mounting (street light, utility pole, rooftop, and etc) • Radio module serial numbers and MAC addresses (within each node) • Type of antennas being used and its installation orientation • Geographic information or GPS coordinates of the nodes (latitude, longitude, and

elevation) Having detailed information such as this for each deployed node is vital in troubleshooting problems that may arise later on.



6. Deployment Phase - Node and Antenna Installation This section discusses the guidelines for installing all OWS nodes at various types of mounting locations, including the requirements and strategies prior to deploying the nodes, antenna installation, etc. Also, the power and grounding requirements are generally covered. After reviewing this section, please refer to the document, OWS Field Installation Manual, for more information. 6.1 Requirements Prior to Deploying Nodes Prior to deploying nodes, it is mandatory to ensure that all of the following “wired side” items are completed and fully tested individually and at a system level (see test point below):

- All of the VLAN switches and routers are configured and available - All of the wired network or broadband connections are up and ready. This means

that there is connectivity to your network and that the bandwidth has been tested to validate performance expectations

- The DHCP server is up and running properly by testing first with a wired PC at the location of the head-end node

- Connectivity to the Network Server has been established at the head-end. The Network Server must be available in the wired location or at least in the first wired node

- The default gateway is “pingable” by the head-end node (responds to pings)



6.2 Node Deployment Strategy The main strategy when mounting the OWS nodes is to be sure to start with the head-end node first and move outward in a somewhat concentric fashion. The key is to ensure that the first ring or level of nodes have solid connections since this is where all of the backhaul traffic from the meshed nodes in the region will pass through. Also, this strategy is very important when deploying a large network (100+ nodes) that require segmentation or multiple subnets since it will ensure that the nodes, as they are powering up, will connect or mesh to the desired head-end or backhaul location and obtain the correct DHCP address. First, after deploying the head-end node(s) onto a rooftop, for example, including all antenna installation, it is highly recommended to employ a channel management scheme for all the radios. Either using the CLI or web interface, each radio should have “autochannel selection” disabled and pre-determined channels configured manually. For 802.11g, the three non-overlapping channels to choose from are 1, 6, and 11. For 802.11a, although all the channels are non-overlapping, channels should be selected two channels apart for optimal channel isolation. For example, if you select channel 136 for one of your backhaul ingress radios, the next one should be set at 153, and so forth.

For even greater optimization, the CLI feature, “set chanChange” should be enabled and configured. This feature allows you to take a specific action (trigger an alarm or allow a dynamic channel change) in the event that the radios within the same node occupy channels that fall within a threshold that you set (e.g. 0, 1, 2, 3 channels apart).



6.3 Node Mounting In order to mount the OWS nodes in various types of locations (light poles, rooftops, towers, sides of buildings underneath the eaves, other poles), the following equipment are some of the necessary items for a typical deployment:

- Screwdrivers (Flat and Philips) - Open-ended wrench set - Wire cutters, wire strippers - RJ-45 Crimping tools and connectors - Cat 5e cable (or better) rated for UV and outdoor install - Network cable tester - Work gloves, safety goggles, boots - Rope to lift parts to roof as needed - Soft-sided tool box or back pack to carry tools - Ladder, Man Lift or Bucket truck (for light pole mounting)

There are 3 types of Strix OWS node mounting kits:

- Wall mount - Vertical pole mount - Horizontal pole mount aka “Adjustable Mounting Bracket” (available for the

OWS 2400 series only).

6.3.1 Rooftops There are basically two options for mounting on rooftops:

1. Antennas Only – where the node is installed on the outside wall (under the eaves) or inside of a building. The advantage here is that the node will be protected with easy access from inside the building and it is less noticeable from the outside (more aesthetically pleasing). The disadvantage is that there are greater lengths of antenna cables, which translates into a certain amount of RF power loss (depending on the quality of the cables).



2. Node and Antennas on Roof – requires a tripod (non-penetrating roof mount) or parapet wall mount (using c-rail or unistrut brackets).

Antennas should have clearance from the parapet wall so it does not obstruct the signal. Make sure there is a mounting facility or build one. Antennas can be mounted on tripods or poles attached to the brackets as found in the picture. Care should be taken in routing cable (both power and antenna) to protect from weather and so as not to become easily damaged or a trip hazard. Also, if your backhaul location has a large surface area on the roof, especially with high parapet walls, where one or two centrally located nodes will not suffice, it is recommended to install a node at each of the four corners with two 90 Deg sector or panel antennas at each corner as seen below. Of course in this scenario, all of the Ethernet connections from each node would be bridged together.

“c-rails”



6.3.2 Towers There are several types of towers (traditional, water, cellular, silos) possible on which to install an OWS node. Towers offer good visibility from many places and are more common in rural deployments. In general there are two options for mounting nodes at these kinds of locations.

1. Mount the node on the tower near the antennas.

2. Mount the node at the bottom of the tower and run power and Ethernet cables to the antennas. The advantage is that it is less costly to deploy (at the time of installation and future maintenance visits) without having to climb or pay costly fees for a certified pole climber. The disadvantage is that there are more cable losses with runs of approximately 100-300 feet. However, this can be mitigated by paying a little extra for higher quality LMR cables that exhibit less loss.



In either case, the following items should be considered:

- Climbing could be tricky - Possible costly fees for certified pole climbers - With limited locations, potential long distances to subscribers - Need to bring your own power and Ethernet cables - Additional signal loss for the longer RF cables - Outer diameter considerations for mounting brackets or U-bolts

6.3.3 Light Poles Nodes mounted on light poles are accomplished through the use of a Strix Adjustable Mounting Bracket. It is used in situations where the mounting point is on the horizontal or angled arm (versus the vertical mast) of a light pole. Although this bracket can also be mounted on any pole, (vertical, horizontal or angled) and offers an adjustment covering a full 360 degrees, the standard mounting bracket that is included with all OWS models would suffice for the vertical mast. Please refer to the document, OWS Field Installation Supplement - Adjustable Mounting Bracket, for more detailed information.



6.4 Antenna Installation Once the OWS node has been installed, the next step is to attach the antennas. But before installing any antenna the following guidelines should be considered:

- Always ensure that antenna radiation patterns do not overlap - Only one antenna should be used on each antenna port (do not use an RF splitter,

except in special linear applications such as railways) - Unused antenna ports should be covered and unused radios should be software

disabled via CLI (set radio disable) - Install antenna lightning arrestors in areas that are prone to frequent lightning

storms - Make sure to weatherproof all your antenna connections and create “drip

loops” on each cable run - If using a patch antenna, be sure to properly angle the antenna toward the

intended direction

6.4.1 Antenna Isolation When installing sectorized antennas coming from radios that are broadcasting in the same frequency band (e.g. 5.7 GHz), it is very important to understand the need for physical antenna isolation, both vertical and horizontal. When you deploy more than one sector at the same physical location (e.g. a rooftop), noise caused by your sector antennas can affect each other’s performance. In general, the rule of thumb is to separate sector antennas at least 1 foot apart in the vertical and 3 to 6 feet in the horizontal. If possible, do both vertical AND horizontal separation.

Another way to help mitigate the effects of sector antenna interference is to procure antennas that are rated with a high “front-to-back ratio”. This parameter is the ratio between the energy in the main or front lobe of an antenna divided by the energy in the



back lobe of the antenna. Better antennas focus and radiate most of their energy from the front and very little of their energy “leaks” toward the back. The higher the front-to-back ratio (for example, +20 dB or +30 dB), the better the antenna and the less interference that will be experienced to and from signals in back of the antenna. Strix Systems recommends antennas with high front-to-back ratios.

6.5 Grounding and Powering Considerations All OWS nodes in your network should be properly grounded. When powering the nodes, make sure to properly wire the AC and DC connections to the outdoor rated, field attachable AC/DC power connector that is included with the unit. If you are mounting on a light pole, then the optional photo-cell adapter assembly may be used. Also, there is always the option of alternative energy sources such as solar power. This has proven to be a successful solution, especially in remote areas where power is not readily available or as a DC backup to AC power. Note: Strix OWS nodes have the ability to accept AC and DC power sources simultaneously where the unit will operate from AC as the primary and will immediately switch or fall back to DC upon failure with no interruption!

In addition to the Field Installation Manual, please refer to the OWS 2400 and OWS 3600 data sheets for more information on the latest specifications relating to cabling and grounding.



6.6 Checking Node Connectivity The final step in deploying the node, once all of the physical installations and connections have been made, is to check for node connectivity to the network. This is where an administrator at the network operation center (NOC), can verify that he/she can communicate with or “sees” the node in the Manager/One application. Also, before the installer moves on to the next node, the administrator also needs to verify the link quality, signal strength levels, and whether or not the node can see at least 2 or 3 other nodes. If the link quality isn’t as expected, the installer should double check all of the physical connections. If the link is still not satisfactory, then the installer should replace the omnidirectional antenna on the Network Connect or backhaul radio with a patch antenna. Once the antenna is angled properly in the general intended direction, the link quality should be improved considerably. Otherwise, another mounting location should be considered. Using Iperf: Iperf, which is a standard network performance tool, is a lightweight program commonly used in wired IP networks between any two points. Well now, Strix has embedded this program into the firmware (enabled through a CLI command) to aid the administrator in executing some quick pre-production tests on the mesh network. Iperf is a tool that measures maximum TCP bandwidth, allowing the tuning of various parameters and UDP characteristics as well. Iperf also reports delay jitter and datagram loss. For help in using this tool, please contact your Strix representative.

node2> iperf -s -u -i 1 ------------------------------------------------------------ Server listening on UDP port 5001 Receiving 1470 byte datagrams UDP buffer size: 60.0 KByte (default) ------------------------------------------------------------ [ 4] local <IP Addr node2> port 5001 connected with <IP Addr node1> port 9726 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 4] 0.0- 1.0 sec 1.3 MBytes 10.0 Mbits/sec 0.209 ms 1/ 894 (0.11%) [ 4] 1.0- 2.0 sec 1.3 MBytes 10.0 Mbits/sec 0.221 ms 0/ 892 (0%) [ 4] 2.0- 3.0 sec 1.3 MBytes 10.0 Mbits/sec 0.277 ms 0/ 892 (0%) [ 4] 3.0- 4.0 sec 1.3 MBytes 10.0 Mbits/sec 0.359 ms 0/ 893 (0%) [ 4] 4.0- 5.0 sec 1.3 MBytes 10.0 Mbits/sec 0.251 ms 0/ 892 (0%) [ 4] 5.0- 6.0 sec 1.3 MBytes 10.0 Mbits/sec 0.215 ms 0/ 892 (0%) [ 4] 6.0- 7.0 sec 1.3 MBytes 10.0 Mbits/sec 0.325 ms 0/ 892 (0%) [ 4] 7.0- 8.0 sec 1.3 MBytes 10.0 Mbits/sec 0.254 ms 0/ 892 (0%) [ 4] 8.0- 9.0 sec 1.3 MBytes 10.0 Mbits/sec 0.282 ms 0/ 892 (0%) [ 4] 0.0-10.0 sec 12.5 MBytes 10.0 Mbits/sec 0.243 ms 1/ 8922 (0.011%)



7. Starting and Configuring the Network This section further illustrates the methods of implementing the important recommendations discussed in previous sections. 7.1 Including Nodes in the Network

If the node does come up properly, then the node must be “included” into your “Cloud” or inventory. Please refer to the Access/One User Guide for more information.

7.2 Including Remote Networks or Subnets

The steps below outline the configuration needed to enable multiple subnets within a Cloud. The nodes on the remote subnets must be in a factory defaulted state.

1. Launch Manager/One on the main subnet’s Network Server and name the Cloud. Note: the Subnet with the Static Network Server(s) should be very limited in scope. It is recommended to have just the Network Server(s) on this subnet. IWS Network Servers can be used.

2. Go to Configure System Network Topology Static Network Servers and

input the IP addresses of the “grandmaster” and standby Network Servers on the main subnet. Select “Update” and “Apply the Configuration”. Note: This step simply writes the IP Address of the Static Network Server(s) to the Cloud configuration file that will be sent to all Remote Network Servers when they are



joined into the network. This is so that they can locate the Static Network Server from the various subnets.

3. Go to Commands Remote Network Server Include and enter the IP

addresses of the master Network Servers that are on each of the remote subnets. Note: no configuration on the remote network servers is required.

Start to join other nodes into the remote subnets using the Master Network Server on each remote subnet. The Remote Network Servers will provide reporting information to the Static Network Server. You will then see the following windows in Manager/One when accessing any of the master Network Servers. When you click in a Remote Subnet box, you will be forwarded to the master Network Server on that remote subnet.



7.3 Recommended Client Connect Settings The following are guidelines when configuring SSIDs for various types of users or subscribers. Management SSID: Feature Setting(s) SSID Untagged, Suppressed Applicable Wireless Mode Both (802.11a/g) Max Clients 2 Security Mode WPA-PSK/TKIP Client Connect Privacy Disabled SSID Shutdown Disabled Discovery Protocol (browser plug in) Enabled

Public Subscriber SSID: Feature Setting(s) SSID Tagged, Not suppressed Applicable Wireless Mode 802.11g Max Clients 32 or less depending on BW requirements Security Mode Open (authentication handled by gateway)Client Connect Privacy Enabled SSID Shutdown Enabled Discovery Protocol (browser plug in) Disabled

City SSID: Feature Setting(s) SSID Tagged, Suppressed Applicable Wireless Mode 802.11g or 802.11a or Both Max Clients 32 or less depending on BW requirements Security Mode WEP, WPA-PSK, or 802.1x Client Connect Privacy Disabled SSID Shutdown Enabled Discovery Protocol (browser plug in) Disabled



Appendix


Strix Outdoor Deployment Guide Rev A

Documents

Transcript of Strix Outdoor Deployment Guide Rev A