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/

Reply via email to