Hello Patrick,

With all due respect I don't think anyone here doubts the Alvarion VL is not
simply a plain vanilla CSMA product.  However, unfortunately the end result
is the same when deployed in a RF hostile environment.

All the items you list below while impressive are of little use in RF
hostile environments.  Believe me I wish this wasn't the case as I'd love to
make use of some of the many nifty VL features.  Unfortunately until VL
makes the turn and offers the tools required in today's unlicensed fixed
wireless world it is best suited for bursty, best effort applications.

The VL can scream in the right environment, but unfortunately the days of
friendly RF and clean unlicensed airways are long gone in many markets and
disappearing quickly in the rural markets as well.  As unlicensed users we
require greater flexibility out of the products we purchase not less



-----Original Message-----
Behalf Of Patrick Leary
Sent: Tuesday, December 26, 2006 12:21 PM
To: WISPA General List
Subject: [WISPA] once again, several of the key...

...features that make VL NOT a basic CSMA/CA product.

- 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
maximum is 1023.

- 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.

- 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.

- 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%)

- 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.

- Configurable threshold for lost beacon watchdog

- 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)

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

WISPA Wireless List: wireless@wispa.org


Archives: http://lists.wispa.org/pipermail/wireless/

WISPA Wireless List: wireless@wispa.org


Archives: http://lists.wispa.org/pipermail/wireless/

Reply via email to