No, no...stay up!  <grin>

Good to see Patrick decided to engage the pros and cons of the VL product!
Now maybe we can get some traction on offering up the improvements the VL
product sorely needs.  Surely Alvarion wants to improve the product right?

The pros Patrick lists are certainly impressive, but all the wizardry in the
world won't do you much good if the radio lacks fundamental RF abilities to
block or avoid noise.  Additionally many features Patrick lists below are
found in other products albeit called something else.

What can be improved?  That's what we're here offer suggestions to
IMPROVE a product, right?

(1)  Dual polarity AU and SU via software control

(2)  RSSI reading

(3)  Quicker reboots and fewer of them for basic changes ipconfig etc.

(4)  Adhere to standard 568A or 568B CAT5 color code

(5)  Add Rx threshold to enable radio to maintain higher modulations in
noisy environments

(6)  Increase size of weather seal opening to allow RJ45 connector to pass

I should mention many of these points have been long standing requests from
long time VL clients.  Patrick himself gave me a number of VL customers to
contact as references and these points were brought up by them as well as
me.  Even Keith Edmonds a tech who works for Alvarion agreed there should be
a RSSI reading (not just a SNR reading) and dual polarity would be

Additionally all of the references Patrick provided were not selling
committed rate business packages, but rather "up to" or best effort
packages.  This is important to note as the VL will auto-rate itself down to
a low modulation and slower speed in noisy environments.  This is not a good
feature if you are offering committed bandwidth packages and not best effort



-----Original Message-----
Behalf Of Matt Larsen - Lists
Sent: Sunday, September 24, 2006 1:05 AM
To: WISPA General List
Subject: Re: [WISPA] vendor specs

Geez Patrick, go to bed!!! Get some rest!!!!

Seriously, this is a great list. Definitely shows how the VL is a 
completely different animal than the other options out there.

Matt Larsen

Patrick Leary wrote:
> I believe most if not all of the below are features not found among 
> Trango or Canopy. I list a few of the advanced features. A few of 
> these (probably some you have never heard of before or even thought 
> of) I show in detail. Maybe this post will also explain why the VL is 
> not simply an Atheros chipset in a case and why it is not simply some 
> basic CSMA/CA. This is just a small sampling. The manual, with lots of 
> tables, drawings, etc., is 277 pages of which most relate to things 
> that can be configured/optimized. (I can send the pdf to any who want 
> it.)
> . Chassis-based or stand alone AUs with multiple LEDs on the chassi 
> blade versions, including current consumption
> . Redundant power supplies with status LEDs, including over 
> temperature warning
> . GPS-sync module (for hoppers) also can be used for VL for their 
> alarm capabilities
> . 110vAC or -48vDC power options
> . Built-in Ethernet repeater in the chassis blades to support over 600 
> feet from network switch/router to ODUs
> . AUs with antenna options, including built-in 60, 90, or 120 degree 
> sectors plus options with external connector
> . OFDM (with FEQ) for NLOS ability to enable connection of more of the 
> potential subscriber population
> . Adaptive modulation with configurable minimum modulation
> . Up to 40Mbps net (ftp) per sector
> . Over 40,000pps with small packets
> . No loss in capacity with varying frame size (all other UL gear 
> capacity is dramatically reduced when passing small packets
> . FIPS 197 option. AES standard, no extra charge
> . Virtual LANs based on IEEE 802.1Q with standard QinQ built-in support
> . Layer-2 traffic prioritization based on IEEE 802.1p and layer-3 
> traffic prioritization based on either IP ToS Precedence (RFC791) or 
> DSCP (RFC2474). It also supports traffic prioritization based on UDP 
> and/or TCP port ranges. In addition, it may use the optional Wireless 
> Link Prioritization (WLP) feature to fully support delay sensitive 
> applications, enabling Multimedia Application Prioritization (MAP) for 
> high performance voice and video. (MAP can increase VoIP capacity by 
> as much as 500%)
> . Built-in surge suppression in both ODU and IDU
> . Full management of all components, from any point in the system.
> . Components can be managed using standard management tools through 
> SNMP agents that implement standard and proprietary MIBs for remote 
> setting of operational modes and parameters. Security features 
> incorporated in BreezeACCESS VL units restrict access for management 
> purposes to specific IP addresses and/or directions, that is, from the 
> Ethernet and/or wireless link.
> . True toll quality VoIP (MOS of 4.1 or better)
> . Upload new or updated configuration file to multiple (selectable) 
> units simultaneously, thus radically reducing the time spent on unit 
> configuration maintenance.
> . Back up/shadow flash, can support two different versions of firmware
> . 5MHz (4.9GHz version), 10MHz, or 20MHz channel options.
> . SUs autorecognize and configure channel size
> . SUs available with external connector or integrated 21dBi with 
> 10.5h/10.5v beamwidth
> . Multilevel password, multi-layer ESSIDs
> . Configuration of remote access direction (from Ethernet only, from 
> wireless link only or from both)
> . Configuration of IP addresses of authorized stations
> . Numerous LEDs detailing advanced status information, plus tri-color 
> 10-bar alignment LEDs that directly corresponds to SNR, including 
> amber for warning signal is too strong (SNR >50dB)
> . Pole mount or band strap mounting options, hardware included
> . Power supply included, with reset feature and integrated surge 
> suppression
> . Specialty Cat 5 connector
> . Industrial grade waterproof seal with O rings
> . Auto or configurable maximum cell distance
> . Automatic distance learning. Per SU Distance Learning mechanism 
> controlled by the AU enables each SU to adapt its Acknowledge timeout 
> to its actual distance from the AU, minimizing delays in the wireless 
> link
> . Low Priority Traffic Minimum Percent feature ensures a selectable 
> certain amount of the traffic is reserved to low priority packets to 
> prevent starvation of low priority traffic when there is a high demand 
> for high priority traffic.
> . MAC address deny and allow list
> . Able to configure size of concatenated frames (enables 
> customization/optimization based on expected applications)
> . Best AU and preferred AU options in the SUs. (Best AU explanation: 
> each of the AUs can be given a quality mark based on the level at 
> which it is received by the SU. The SU scans for a configured number 
> of cycles, gathering information from all the AUs with which it can 
> communicate. At the end of the scanning period, the SU reaches a Best 
> AU decision according to the information gathered. The AU with the 
> highest quality mark is selected as the Best AU, and the SU will 
> immediately try to associate with it. The quality mark given to each 
> AU depends on the level at which it is received by the SU. The Best AU 
> selection mechanism can be overridden by defining a specific AU as the 
> preferred AU.)
> . Broadcast rate limiting, selectable
> . Configurable threshold for lost beacon watchdog
> . Support of packet sizes to 1600 bytes, including VLAN(s) for single 
> or double-tagged packets
> . Advanced event log feature. The event log is an important debugging 
> tool and a flash memory sector is dedicated for storing it. Events are 
> classified according to their severity level: Message (lowest 
> severity), Warning, Error or Fatal (highest severity). The severity 
> level of events that should be saved in the Event Log is configurable. 
> Events from the configured severity and higher are saved and may be 
> displayed upon request. Log history can be displayed up to the full 
> number of current active events. In the log, an event is defined as 
> active as long as it has not been erased (a maximum of 1000 events may 
> be stored). The Event Log may be read using TFTP, with remote file 
> name <SNMP Read Community>.log (the default SNMP Read Community is 
> "public"). The Event Log may also be uploaded to a remote FTP server. 
> The Event Log Menu includes the following options: Event Log Policy, 
> Display Event Log, Erase Event Log, Event Load Upload
> . Multiple DHCP options: From Wireless Link Only, From Ethernet Only, 
> From Both Ethernet and Wireless Link
> . Intelligent ATPC (The algorithm is controlled by the AU that 
> calculates for each received frame the average SNR at which it 
> receives transmissions from the specific SU. The average calculation 
> takes into account the previous calculated average, thus reducing the 
> effect of short temporary changes in link conditions. The weight of 
> history (the previous value) in the formula used for calculating the 
> average SNR is determined Menus and Parameters Operation and 
> Administration by a configurable parameter. In addition, the higher 
> the time that has passed since the last calculation, the lower the 
> impact of history on the calculated average. If the average SNR is not 
> in the configured target range, the AU transmits to the SU a power-up 
> or a power-down message. The target is that each SU will be received 
> at an optimal level, or as high (or low) as possible if the optimal 
> range cannot be reached because of specific link conditions. Each time 
> that the SU tries to associate with the AU (following either a reset 
> or loss of synchronization), it will initiate transmissions using its 
> Transmit Power parameters. If after a certain time the SU does not 
> succeed to synchronize with the AU, it will start increasing the 
> transmit power level. In an AU the maximum supported transmit power is 
> typically used to provide maximum coverage. However, there may be a 
> need to decrease the transmitted power level in order to support 
> relatively small cells and to minimize the interference with the 
> operation of neighboring cells, or for compliance with local 
> regulatory requirements. In some cases the maximum transmit power of 
> the SU should be limited to ensure compliance with applicable 
> regulations or for other reasons.
> . And ATPC is highly configurable (only highly advanced operators 
> should do so), with parameters like: ATPC min. SNR level, ATPC Delta 
> from min. SNR level, Min. interval between ATPC messages, ATPC power 
> level change step (1-20dB with default of 5dB)
> . Advanced Transmit Control. The Tx Control option enables turning 
> Off/On the AU's transmitter, or having the AU Tx status controlled by 
> the status of the Ethernet port/link.
> . Cell Distance Mode feature: The higher the distance of an SU from 
> the AU that is serving it, the higher the time it takes for messages 
> sent by one of them to reach the other. To ensure appropriate services 
> to all SUs regardless of their distance from the AU while maintaining 
> a high overall performance level, two parameters should be adapted to 
> the distances of SUs from the serving AU: The time that a unit waits 
> for a response message before retransmission (ACK timeout) should take 
> into account the round trip propagation delay between the AU and the 
> SU (The one-way propagation delay at 5 GHz is 3.3 microseconds per 
> km/5 microseconds per mile.). The higher the distance from the AU of 
> the SU served by it, the higher the ACK timeout should be. The ACK 
> timeout in microseconds is: 20+Distance (km)*2*3.3 or 20+Distance 
> (miles)*2*5. To ensure fairness in the contention back-off algorithm 
> between SUs located at different distances from the AU, the size of 
> the time slot should also take into account the one-way propagation 
> delay. The size of the time slot of all units in the cell should be 
> proportional to the distance from the AU of the farthest SU served by 
> it. The Cell Distance Mode parameter in the AU defines the method of 
> computing distances. When set to Manual, the Maximum Cell Distance 
> parameter should be configured with the estimated distance of the 
> farthest SU served by the AU. When set to Automatic, the AU uses a 
> special algorithm to estimate its distance from each of the SUs it 
> serves, determine which SU is located the farthest and use the 
> estimated distance of the farthest SU as the maximum cell distance. 
> The value of the maximum cell distance parameter (either computed or 
> configured manually) is transmitted in the beacon messages to all SUs 
> served by the AU, and is used by all units to calculate the size of 
> the time slot, that must be the same for all units in the same sector. 
> When the Per SU Distance Learning option is enabled, the AU uses the 
> re-association message to send to each SU its estimated distance from 
> the AU. The per-SU distance is used to calculate the ACK timeout to be 
> used by the SU. When the Per SU Distance Learning option is disabled 
> (or if it cannot be used because the SU uses a previous SW version 
> that does not support this feature), the SU will use the maximum cell 
> distance to calculate the ACK timeout. The AU always uses the maximum 
> cell distance to calculate the ACK timeout. It should be noted that if 
> the size of the time slot used by all units is adapted to the distance 
> of the farthest unit, then no unit will have an advantage when 
> competing for services. However, this reduces the overall achievable 
> throughput of the cell. In certain situations, the operator may decide 
> to improve the overall throughput by reducing the slot size below the 
> value required for full fairness. This means that when there is 
> competition for bandwidth, the back-off algorithm will give an 
> advantage to SUs that are located closer to the AU. The Cell Distance 
> Parameters menu includes the following parameters: fairness factor, 
> per SU distance learning, show cell distance parameters.
> . Arbitration Inter-Frame Spacing feature
> . Max association feature
> . Wireless Link Trap Threshold feature: defines the threshold for the 
> wireless quality trap, indicating that the quality of the wireless 
> link has dropped below (on trap) or has increased above (off trap) the 
> specified threshold. The Wireless Link Trap Threshold is in percentage 
> of retransmissions, and the allowed range is from 1 to 100 (%). The 
> default is 30 (%).
> . Lost Beacons Transmission Watchdog Threshold feature: When it is 
> unable to send beacon frames for a predetermined period of time, such 
> as in the case of interferences, the AU resets itself. The Lost 
> Beacons Transmission Threshold parameter represents the number of 
> consecutive lost beacons after which the unit will reset itself. The 
> range for this parameter is 100 - 1000 or 0. When the parameter is set 
> to 0, this feature is disabled, i.e. internal refresh will never be 
> performed. The default value is 218.
> . Disassociate (AU only) feature: enables disassociating all SUs 
> associated with the AU or a selected SU. This feature is useful during 
> configuration changes, enabling to force the SU(s) to re-initiate the 
> association process, including the search for the best AU (or a 
> preferred AU) using the Best AU process, without performing a full 
> reset. The Disassociate submenu includes two options: Disassociate All 
> SUs, Disassociate SU By MAC Address: to disassociate a selected SU.
> . Configurable Minimum and Maximum Contention Windows (The 
> BreezeACCESS VL system uses a special mechanism based on detecting the 
> presence of a carrier signal and analyzing the information contained 
> in the transmissions of the AU to estimate the activity of other SUs 
> served by the AU.) The available values are 0, 7, 15, 31, 63, 127, 
> 255, 511 and 1023. A value of 0 means that the contention window 
> algorithm is not used and that the unit will attempt to access the 
> medium immediately after a time equal to DIFS. The default min. value 
> is 15. The default max. is 1023.
> . Advanced MIR/CIR (controlled by both the SU and AU) with special 
> configurable graceful degradation algorithm ensuring that the 
> degradation of performance for each individual SU is proportional to 
> its CIR.
> Patrick Leary
> AVP WISP Markets
> Alvarion, Inc.
> o: 650.314.2628
> c: 760.580.0080
> Vonage: 650.641.1243
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals & 
> computer viruses.

WISPA Wireless List:



WISPA Wireless List:



Reply via email to