Canopy's C/I of 3dB is only the 10mbps at signals much stronger than sensitivity. At low signal it's always been higher than 3dB, and the 20mbps Canopy requires higher C/I under all circumstances.
OFDM provides a range of signalling speeds, from BPSK (same C/I as the 10mbps Canopy) through large constellation QAMs (with correspondingly higher C/Is). OFDM will work in as little signal as 10mbps Canopy, and can operate with less signal than 20mbps Canopy. And as you already expressed, with 17-25 dB or more, it runs much faster. But you also neglect that with OFDM's multiple subchannels, it can tolerate partial band interference whereas the DSSS system would just stop cold. Aside from the above, I perceive you seem to appreciate the value of time framed systems. I sometimes get wrong "who is advocating what" in email threads, so I appologize in advance if I've got this wrong. I'm a great fan of time framed systems myself. >It would be interesting to see how a bare OFDM TDD system >would have performed? I think you'll get your wish. Isn't this what WiMAX is? Rich ----- Original Message ----- From: Tom DeReggi To: WISPA General List Sent: Thursday, December 28, 2006 4:56 PM Subject: Re: [WISPA] Alvarion Comnet Radios have arrived Marlon, You get an A+ on your definitions of terms I used. I don't challenge those definitions. However, I challenge the relevance of just about all your responses to my comments. I recognize I may not have been super clear, but I was assuming the reader would apply their knowledge of the definitions, to infer the relevance of comments made. To be more clear.... OFDM is plagued by a larger SNR to operate adequately, compared to DSSS. DSSS has been able to operate with minimum SNRs anywhere from 3db (canopy) to 8db (trango). Actually that comment is not exactly true, Canopy's C/I is 3db (not minimum SNR required). OFDM gear typically wants to see a minimum of 17db SNR, and performs optimally with > 25db SNR. I'm not aware that Wifi gear has worse C/I specs than non-Wifi gear, based on it being Wifi (csma/ca). Wifi or TDD has nothing to do with Noise, Wifi & TDD has to do with timing of transmissions. My point was that if you can't get over the noise, when using modulations less able to get over the noise, you can help solve the problem by transmitting when the noise is not occuring. Contant time based transmission has little benefit, if it occurs during a noisy time where that noise will kill the signal and results in packet loss. I'd rather have increased latency, and try again, to prevent packet loss. >> I've always been a fan of TDD, especially when combined with DSSS to be >> able to survive the noise, with better SNRs Meant... DSSS gets over noise better than OFDM, and I like TDD gear when the gear can survive the noise floor, and DSSS gear is more likely to survive the noise floor, and well matched with TDD. If using OFDM, requiring larger SNR, harder to accomplish in high noise environements, a non-TDD based scheduling MAC such as CSMA/CA can improve overall end to end performance and reduce packet loss. A lost packet, end to end across a session, takes up WAY more bandwdith and has a penalty of WAY more LAtency, than hiding the packet loss from the session, and re-transmitting the loss at the specific link that the packet loss occured. The point I am making is that so many people judge performance by Link performance, which means nothing in terms of the performance that the end user experiences end to end. End USer Performance is about preventing and minimizing packet loss. A perfect exmaple was a link that I had to rebuild today. I tried to pull off a ofdm 900 Mhz link. I have a registered noise floor of -85, and an average signal of -55, but I had to pull out the link, because end to end, the best I could accomplish was 5-10% packet loss. The reason is that sporatic paging noise peaked loud enough to interfere with my signal (although not seen with cheap limited wifi built-in noise detection). I was able to do a radio to radio throughout test of almost 10 mbps. But thats not what the end user saw, trying to type in his remote office application. More like 30 seconds to see his characters show up on the screen after he typed them. But web browsing appeared OK. This particular case it demonstrates the harm of packet loss, allthough limited in relevance as it was a OFDM CSMA/CA link. Trango 900 DSSS w/ nosie compression built-in and ARQ, would have likely solved the problem. But thats because of DSSS's noise resilience, Trango compression (noise filtering) and ARQ, not because of its TDD spec. It would be interesting to see how a bare OFDM TDD system would have performed? I can test it, because one doesn't exist, atleast not that I own. But I bet it would perform pretty poorly. I believe the CSMA/CA was the saving grace that allowed the link to be tolerable at all (web browsing), with the random packet loss. Tom DeReggi RapidDSL & Wireless, Inc IntAirNet- Fixed Wireless Broadband ----- Original Message ----- From: "Marlon K. Schafer (509) 982-2181" <[EMAIL PROTECTED]> To: "WISPA General List" <wireless@wispa.org> Sent: Tuesday, December 26, 2006 4:57 PM Subject: Re: [WISPA] Alvarion Comnet Radios have arrived > oh oh. This one's gonna be fun. I'll warn ya now Tom, this is nothing > personal..... > > Marlon > (509) 982-2181 Equipment sales > (408) 907-6910 (Vonage) Consulting services > 42846865 (icq) And I run my own wisp! > [EMAIL PROTECTED] > www.odessaoffice.com/wireless > www.odessaoffice.com/marlon/cam > > > > ----- Original Message ----- > From: "Tom DeReggi" <[EMAIL PROTECTED]> > To: "WISPA General List" <wireless@wispa.org> > Sent: Tuesday, December 26, 2006 12:53 PM > Subject: Re: [WISPA] Alvarion Comnet Radios have arrived > > >> marlon, >> >> I have to disagree, and state the opposite. >> I've always been a fan of TDD, especially when combined with DSSS to be >> able to survive the noise, with better SNRs. > > OK, there's a problem here. Lets make sure we're talking the same > acronyms and such. > > TDD = Time Division Duplex. In our case, this part really doesn't mean > much of anything. > DSSS = Direct Sequence Spread Spectrum, > SNR = Signal to Noise Ratio. This is the one that you fine tune on a CB > radio to get the his to go away. > > For these and many more kindly take advantage of work I did years ago: > http://www.odessaoffice.com/wireless/definitions.htm > >> The problem occurs when DSSS is not enough to get above the noise. > > This is a problem when using DSSS, FHSS, OFDM, FM or any other modulation > scheme we're using today. > >> When the noise is other OFDM > > OFDM is NOT DSSS or FHSS. It's Orthogonal Frequency Division > Multiplexing. "I totally don't know what that is but I want it!" roflol > >> or Wifi contention gear, > > WiFi is an interoperability standard based on IEEE standards. Today WiFi > can be either DSSS or OFDM, I'm not aware of any WiFi FHSS product. > 802.11b is DSS, 802.11a and g are OFDM. > >> possibly louder than your own signal, using CSMA/CA actually performs >> much better in the severe interference environments. > > Define better. No, I'm not trying to pull a Clinton here. If you want to > compare DSS to FHSS then, yes in certain types of noisy conditions, DSS > can overcome the noise by spreading it's data packets over a larger area. > It's able to rebuild damaged data packets or to just ignore some times of > noise that would cause an FHSS signal to back off and retransmit on a > different freqency, causing a rise in latency and a drop in speed. > > A DSSS signal spreads the data over (in the WiFi example you site) 22 MHz > of spectrum. An FHSS signal spreads that same data over 1 MHz, but it > hops around interference. > > I remember seeing a couple of graphs years ago. They showed an ever > increasing noise level and it's impact on DSSS and FHSS. The DSSS stayed > at or near full speed longer than the FHSS but once the noise got too high > it totally dropped off line. > > The FHSS system, on the other hand, showed the noise as an overall > slowdown but kept on going long after that DSSS system rolled over and wet > on it's self. I'm hearing mixed results about OFDM. Some say it works > better yet in interference, some say it dies much sooner. I really don't > know. It would be nice to see someone run all three systems in a lab so > we could see the same tests. In fact it would be fun to see that same > test with several proprietary systems too. If only I had more time and > money! That's exactly the kind of tinkering that I live for! > >>The reason is TDD is guaranteed to transmit during the noisy period, some >>percentage of time. > > Nope. Not true at all. Been there, done that. I have more than one > T-shirt. It TOTALLY depends on the type of noise and it's levels in > relation to your carrier to interference ratios (also known as SNR). > > If you have narrow band interference DSSS can (and OFDM should) work > around it. It'll be able to recreate the missing data bits and deliver a > good data packet. Or, if the noise is far enough off of the center > frequency (the middle part of the 22 MHz wide channel) it'll likely just > completely ignore the noise. Lets say, for example that you are running a > WiFi based system and your customers radio is hitting your AP in the B > mode with a -65 signal. WiFi radios need around a 15 dB c/i radio. So as > long as your noise level was below -80 this system should work pretty > well. If the noise hit -75 though I'd expect to see some service > degredation. > > Canopy requires a roughly 3dB c/i ratio. It would still be working at > a -69 dB noise floor. Hit -65 with the noise, and neither of them will > work. > >> With CSMA/CA the radio waits for FREE time, or at minimum retransmits >> until it gets FREE spectrum. This can increase latency significantly, but >> it does reduce packet loss, which is more important. > > Remember, CSMA/CA is WiFi!!!! That's the backoff mechanism that makes it > so easy to co-locate so many systems in a confined area like an office or > appartment complex. > > The problem one runs into is that when there is a noise floor above your > c/i there is NEVER free air to transmit in. > >> >> TDD w/ ARQ, > > Now we're talking apples and oranges. TDD is still Time Division > Duplexing (vs. an FDD Frequency Division Duplexing) mechanism. ARQ is an > advanced means of correcting errors that already took place during > transmission. The error could have been caused by any number of things > including interference. But ARQ (as I understand it) is NOT a way to > prevent errors, rather it's a way to recover from them, hopefully without > the need for a retransmission. > >> can be even better, provided one has a high end radio, that can be >> engineered for both ARQ and optimal link quality. But not all ARQ radio >> can be optimized for best RSSI. I'd take 8 db of higher RSSI, than ARQ, >> because their is no need for ARQ, if you are adequately above the noise. > > Agreed. > >> >> Alvarion's strength is it empowers an operator to engineer a more durable >> link, based on antenna quality and flexibility. >> >> >> >> Tom DeReggi >> RapidDSL & Wireless, Inc >> IntAirNet- Fixed Wireless Broadband >> >> >> ----- Original Message ----- >> From: "Marlon K. Schafer (509) 982-2181" <[EMAIL PROTECTED]> >> To: "WISPA General List" <wireless@wispa.org> >> Sent: Tuesday, December 26, 2006 12:46 PM >> Subject: Re: [WISPA] Alvarion Comnet Radios have arrived >> >> >>> Got it. Thanks. >>> >>> I guess my "beef" comes from being a wifi based wisp. I find it too >>> difficult to reject interference with a csma based product. Anything >>> with a "wait for clear air, then transmit" MAC is GREAT for collocation. >>> But sucks when there are products around that don't follow that >>> mechanism. That's (my personal belief) why Canopy went with it's GPS >>> sync. It doesn't care who's already out there, when it's time to >>> transmit it does. Trango does that to, just without sync'ing the AP's. >>> >>> My REAL world experience so far is that csmak (or csma/ca, or whatever >>> collision avoidance scheme you want to use) is GREAT where there aren't >>> many other systems within ear shot of the radios. However, when there >>> are other devices in the area, especially those that don't have a >>> collision avoidance mechanism, the csma radio will pay a heavy price in >>> performance. >>> >>> Having used both csma and polling products, I'm not putting in any wifi >>> type products at 5 gig. All of our next gen products will be polling as >>> long as we can keep things that way. >>> >>> These days, I'm learning to sacrifice raw performance for reliability >>> and uptime. There's a balance, sure, but getting that last 10 to 20% >>> out of a product is less important to me than having a product that can >>> survive some of the games that my less scrupulous competitors play. >>> >>> However, with EITHER technology choice, it's critical to design a >>> network that can, and does, physically (antenna choice and ap locations) >>> isolates your system as well as you possibly can. That seems to be the >>> type of trick that just can't be taught. Your network designer either >>> gets it or he doesn't. Heck, I've even done consulting gigs where I >>> looked a guy right in the eye and gave them several choices for site >>> locations. Only to have them pick something completely different, and >>> sometimes unworkable. >>> >>> 80 to 90% of people's problems with wireless are self inflicted. >>> Either outright or in a lack of forethought manner. >>> >>> Here's an idea for you Patrick. Make this product work both ways. Give >>> it the option to be either csma or some fancy new version of token ring. >>> Then we could optimize performance for any environment that we find >>> ourselves in. >>> >>> Oh yeah, I remember the big hubbub about GPS in the BreezeACCESS II >>> line. Why was it important for collocation then but not now? >>> >>> Hope you guys all had a great Christmas! >>> Marlon >>> (509) 982-2181 Equipment sales >>> (408) 907-6910 (Vonage) Consulting services >>> 42846865 (icq) And I run my own wisp! >>> [EMAIL PROTECTED] >>> www.odessaoffice.com/wireless >>> www.odessaoffice.com/marlon/cam >>> >>> >>> >>> ----- Original Message ----- >>> From: "Patrick Leary" <[EMAIL PROTECTED]> >>> To: "WISPA General List" <wireless@wispa.org> >>> Sent: Tuesday, December 26, 2006 9:26 AM >>> Subject: RE: [WISPA] Alvarion Comnet Radios have arrived >>> >>> >>> I'd never call you a neophyte, Marlon. A jolly elf maybe, neophyte >>> never... >>> >>> CSMA/CA. But the MAC has been substantially altered, especially with 4.0 >>> and the WLP (wireless link prioritization) feature where all stations >>> can be made to wait while those stations with spooled up voice can >>> release their packets regardless of where they are in the cell. Also, in >>> VL an operator can adjust numerous values of the CSMA/CA, such as >>> contention window duration, contention levels, etc. It is more >>> sophisticated than your basic polling and more efficient. >>> >>> 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 Marlon K. Schafer (509) 982-2181 >>> Sent: Tuesday, December 26, 2006 9:13 AM >>> To: WISPA General List >>> Subject: Re: [WISPA] Alvarion Comnet Radios have arrived >>> >>> Got that part. I still didn't see in there anywhere, in plain English >>> that >>> a neophyte like me can understand, is this a polling or csmak product? >>> Marlon >>> (509) 982-2181 Equipment sales >>> (408) 907-6910 (Vonage) Consulting services >>> 42846865 (icq) And I run my own wisp! >>> [EMAIL PROTECTED] >>> www.odessaoffice.com/wireless >>> www.odessaoffice.com/marlon/cam >>> >>> >>> >>> ----- Original Message ----- >>> From: "Patrick Leary" <[EMAIL PROTECTED]> >>> To: "WISPA General List" <wireless@wispa.org> >>> Sent: Friday, December 22, 2006 1:54 PM >>> Subject: RE: [WISPA] Alvarion Comnet Radios have arrived >>> >>> >>> Marlon, I'll answer this with a re-post of a September post that >>> explains, in part, why VL is not just regular CSMA: >>> >>> <<trim>> >>> >>> -- >>> 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(42). >>> ************************************************************************ >>> ************ >>> >>> >>> >>> >>> >>> >>> >>> >>> ************************************************************************************ >>> 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/ >> >> -- >> 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/ -- 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/
