Linux wireless networking development ()

Re: SoftMAC vs FullMAC

On Sun, Feb 04, 2007 at 12:22:15PM -0500, Jon Smirl wrote:
> Has it been considered to simply treat all wireless hardware as
> SoftMAC and to just ignore the FullMAC capabilities?

There are number of FullMAC designs that do not allow management
functionality to be moved to the host, so this consideration is not
going to go very far unless one were to drop support for all the FullMAC
designs that do not allow this..

> Dscape looks to have already started down this path with
> implementations for five vendors. Is the plan to do this for all
> vendors, including Intel and Atheros?

Atheros (well, assuming you don't mean the USB design here) does not
even use firmware, so it is not FullMAC card in any way.. There is
already work on supporting Intel ipw3945 with d80211. Other Intel
designs (ipw2100, ipw2200, ipw2915) are currently using more FullMAC
type design, but that depends on the firmware implementation.. I don't
know what the hardware would be capable of doing, but in theory, it
might be possible (for the vendor) to produce a firmware version that
could work soft MAC designs.

> My specific need is that I am working on an embedded design that
> really needs 802.11s, but 11s isn't available yet. I don't want to end
> up locked into a hardware vendor's FullMAC implementation with much
> more expensive hardware. Currently hardware can run 11s if there is a
> host implementation in software.

I hope you realize that 802.11s is in very early steps (the first draft
failed to get the needed approval rate in IEEE 802.11 working group) and

(Continue reading)

headers

Jon Smirl | 4 Feb 19:24

Re: SoftMAC vs FullMAC

On 2/4/07, Jouni Malinen <jkmaline@...> wrote:
> I hope you realize that 802.11s is in very early steps (the first draft
> failed to get the needed approval rate in IEEE 802.11 working group) and
> is subject to change.. Whether hardware can run 802.11s (the current
> draft or whatever may end up in the end) is quite open question from my
> view point.. 802.11 requires MAC changes and I'm sure there are hardware
> designs that do not work with the current 802.11s draft no matter what
> the host CPU is doing in the driver/802.11 stack.

What I've read is that there are no changes at the PHY layers for 11s.
If that is the case then any existing hardware should be able to run
11s if the interface allows properly formatted packets to be
transmitted and received. Of course I don't know exactly what is in
the 11s draft since it is secret.

A related issue is merging the Marvell support for the OLPC. Marvell
is doing a FullMAC 11s implementation which requires a coprocessor in
the wireless hardware. Merging a firmware 11s implementation before a
software 11s implementation exists will likely cause problems since
interfaces won't get designed correctly.

I'm concerned that's the vendor's goal is to require a new round of
hardware purchases to support 11s when it doesn't appear to be
necessary. OLPC needs the firmware implementation for power saving
reasons, not to implement the protocol.

--

-- 
Jon Smirl
jonsmirl@...
-

(Continue reading)

headers

Jouni Malinen | 4 Feb 19:47

Re: SoftMAC vs FullMAC

On Sun, Feb 04, 2007 at 01:24:03PM -0500, Jon Smirl wrote:

> What I've read is that there are no changes at the PHY layers for 11s.
> If that is the case then any existing hardware should be able to run
> 11s if the interface allows properly formatted packets to be
> transmitted and received. Of course I don't know exactly what is in
> the 11s draft since it is secret.

Hardware may be able to take care of most needed functionality, but
whether firmware is going to allow this is completely different
question.. Amongst other things, IEEE 802.11s/D1.0 is adding new fields
to the frame headers and that is likely to get into problems with number
of firmware implementations.

> A related issue is merging the Marvell support for the OLPC. Marvell
> is doing a FullMAC 11s implementation which requires a coprocessor in
> the wireless hardware. Merging a firmware 11s implementation before a
> software 11s implementation exists will likely cause problems since
> interfaces won't get designed correctly.

I would not call that 11s. It may be a snapshot of a proposal for
802.11s, but IEEE 802.11s is far from being complete, so better call
this Marvell implementation something else.

> I'm concerned that's the vendor's goal is to require a new round of
> hardware purchases to support 11s when it doesn't appear to be
> necessary. OLPC needs the firmware implementation for power saving
> reasons, not to implement the protocol.

Vendors are usually more interested in selling new hardware than adding

(Continue reading)