Mark, ...also, in terms of your question about packet aggregation, BreezeACCESS VL employs very aggressive concatenation. That is why it delivers over 40,000 packets per second performance of small packets (such as 64k frames). The radio also allows setting the "Maximum Concatenated Frame Size," as well as disabling the concatenation feature. Frame sizes (in software version 4.0 and hardware rev. C or higher) can be aggregated 4032 bytes. As well, you can configure the max number of concatenated frames. Finally, the concatenation process is performed separately by the AU for each subscriber radio.
Patrick Leary AVP WISP Markets Alvarion, Inc. o: 650.314.2628 c: 760.580.0080 Vonage: 650.641.1243 [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Koskenmaki Sent: Tuesday, December 26, 2006 10:57 AM To: WISPA General List Subject: Re: [WISPA] once again, several of the key... Hopefully you understand all of those:) Part of Marlon's issue with the basic 802.11 system is talked about below, but of course, since it's there, the "tuneability" helps, but does not resolve the issue. I beleive Marlon's reference to CSMA / CA is two pronged. While it's true that recieved noise will block transmission, it also blocks reception of ACK packets, meaning a "double" whammy. During periods of high noise or repetitive noise, not only does the AP wait to transmit, it then fails to beleive that the transmission was accepted. After so many of thse failures, it then renegotiates the rate at which it's connected and tries again. While these are not the same process, they do link to each and occur in cascade-type failure. I have seen data on a nearly clear channel suddenly have a 200, 300 or more ms interruption while this "cascade" occurs... repettive noise, rate renegotiations and contention window increases, and ack failures from weak clients all cause all clients to have that momentary communication block. I believe there have been quite a number of interesting means of addressing this, as I recall some products from Trango don't "ack" packets, but instead allows the higher layer controls to ensure data integrity, while some versions seem to have a mechanism to request retransmits. There, of course, are polling type systems, and so on. Each has its perceived strengths and weaknesses. Overall, while what you post below is quite interesting, I doubt that most of us (including me) fully grasp what tuning each of these parameters does "in real life" and why you'd use them and under what circumstances. Thus, I really don't know what effect in real life all this ability to "muck with the works" will have. I have seen real world demonstrations of how differring equipment using the exact same hardware, but different settings for many of those settings performs dramatically different. But not understanding the full picture of what each does, I cannot "estimate" in my mind their worth, nor how much they alleviate the various issues that are part of the nature of 802.11 based systems. I also don't see any mention of packet aggregation or hardware compression, which would be wonderful things to have, and would improve the overall "life" and performance of the system. I believe what most of the respondents have at issue here is really the reliance upon 802.11, which is simply NOT anywhere near "great" when it comes to WISP use. Yes, it appears that you can raise the threshold for ignoring noise, and you can tune the system to better cope with varioius kind of situations - distance, colocated small cells, etc. And then the high inefficiency that 802.11 introduces with it's "ack" mechanism and the large amount of access point time spent doing nothing but passing time, waiting for ACK packets. Please understand, I am neither criticizing nor praising, it just appears to me that people are talking past each other, and that neither I nor at least some of the readers, really understand what real life value these things have. +++++++++++++++++++++++++++++++ neofast.net - fast internet for North East Oregon and South East Washington email me at mark at neofast dot net 541-969-8200 Direct commercial inquiries to purchasing at neofast dot net ----- Original Message ----- From: "Patrick Leary" <[EMAIL PROTECTED]> To: "WISPA General List" <wireless@wispa.org> Sent: Tuesday, December 26, 2006 10:20 AM 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 > [EMAIL PROTECTED] > > > > > > > > ************************************************************************ **** ******** > 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: wireless@wispa.org > > Subscribe/Unsubscribe: > http://lists.wispa.org/mailman/listinfo/wireless > > Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ ************************************************************************ ************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(190). ************************************************************************ ************ ************************************************************************ ************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(43). ************************************************************************ ************ ************************************************************************************ 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: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
