lkml.org 
[lkml]   [2009]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Ответ : [PATCH 10/10] ieee802154: add at86rf230/rf231 spi driver
On Tue, Jun 02, 2009 at 10:36:49AM +0200, Marcel Holtmann wrote:
> > This gonna happen, as we are most probably going to implement 6lowpan
> > on top of our stack. 6lowpan is a way to encapsulate IPv6 frames into
> > IEEE 802.15.4 and has nothing in common with ZigBee. Moreover
> > ZigBee is a trademark with strict rules upon it's usage. Our lawyers are
> > currently investigating if it's possible to use this name in projects like
> > Linux kernel which are open-source, non-related to any project but
> > OTOH can be encapsulated in any commercial project.
> >
> > IEEE 802.15.4 is a term like IEEE 802.11. We do have mac80211,
> > we have had (until recently) ieee80211 dir, so why bother?
> >
> > For Bluetooth naming directories 'bluetooth' is logical, as 802.15.1
> > standard is a less known name, doesn't incorporate latest changes
> > from Bluetooth, etc.
>
> and so is IEEE 802.15.4 hence we propose using "zigbee" here. Using the
> mac80211 has historical reasons and 802.11 is a known name and even used
> on product marketing material. IEEE 802.15.4 is not. We are also using
> the term "wimax" and not its IEEE numbering.

That WILL add confusion. Because of the following:
1. IEEE 802.15.4 is layer under ZigBee. ZigBee is implemented on top of
IEEE 802.15.4, like UDP is implemented on top of IP.
2. There are hardware implementations of the following sorts:
a) Simple radio (IEEE 802.15.4 PHY).
b) IEEE 802.15.4 MAC
c) ZigBee, or other high level protocols (well, actually I don't know of
any others than ZigBee at this level, but that doesn't mean they don't
exist).

Using this stack we can implement both a) and b). With addition of
ZigBee layers, it might be possible to implement c), too. For things
like 6lowpan, only a) and b) are useful. If you call this all ZigBee,
it will add confusion and artifical limitation. Not to mention, not
true. And just for cosmetic measures. That will be a lot of trouble and
no practical gain from that.

References:
RFC-4919
RFC-4944

All the best,
S.



\
 
 \ /
  Last update: 2009-06-02 11:13    [W:0.074 / U:0.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site