2009-06-08 12:18:50 +00:00
|
|
|
|
|
|
|
Linux IEEE 802.15.4 implementation
|
|
|
|
|
|
|
|
|
|
|
|
Introduction
|
|
|
|
============
|
2016-11-28 17:22:33 +00:00
|
|
|
The IEEE 802.15.4 working group focuses on standardization of the bottom
|
|
|
|
two layers: Medium Access Control (MAC) and Physical access (PHY). And there
|
2012-05-15 20:50:31 +00:00
|
|
|
are mainly two options available for upper layers:
|
2015-09-03 14:31:34 +00:00
|
|
|
- ZigBee - proprietary protocol from the ZigBee Alliance
|
|
|
|
- 6LoWPAN - IPv6 networking over low rate personal area networks
|
2009-06-08 12:18:50 +00:00
|
|
|
|
2016-11-28 17:22:33 +00:00
|
|
|
The goal of the Linux-wpan is to provide a complete implementation
|
2015-09-03 14:31:34 +00:00
|
|
|
of the IEEE 802.15.4 and 6LoWPAN protocols. IEEE 802.15.4 is a stack
|
2009-06-08 12:18:50 +00:00
|
|
|
of protocols for organizing Low-Rate Wireless Personal Area Networks.
|
|
|
|
|
2012-05-15 20:50:31 +00:00
|
|
|
The stack is composed of three main parts:
|
|
|
|
- IEEE 802.15.4 layer; We have chosen to use plain Berkeley socket API,
|
2016-11-28 17:22:33 +00:00
|
|
|
the generic Linux networking stack to transfer IEEE 802.15.4 data
|
|
|
|
messages and a special protocol over netlink for configuration/management
|
2012-05-15 20:50:31 +00:00
|
|
|
- MAC - provides access to shared channel and reliable data delivery
|
|
|
|
- PHY - represents device drivers
|
2009-06-08 12:18:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
Socket API
|
|
|
|
==========
|
|
|
|
|
|
|
|
int sd = socket(PF_IEEE802154, SOCK_DGRAM, 0);
|
|
|
|
.....
|
|
|
|
|
|
|
|
The address family, socket addresses etc. are defined in the
|
2009-08-07 02:58:39 +00:00
|
|
|
include/net/af_ieee802154.h header or in the special header
|
2015-05-25 12:38:29 +00:00
|
|
|
in the userspace package (see either http://wpan.cakelab.org/ or the
|
|
|
|
git tree at https://github.com/linux-wpan/wpan-tools).
|
2009-06-08 12:18:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
Kernel side
|
|
|
|
=============
|
|
|
|
|
|
|
|
Like with WiFi, there are several types of devices implementing IEEE 802.15.4.
|
|
|
|
1) 'HardMAC'. The MAC layer is implemented in the device itself, the device
|
2016-11-28 17:22:33 +00:00
|
|
|
exports a management (e.g. MLME) and data API.
|
2009-06-08 12:18:50 +00:00
|
|
|
2) 'SoftMAC' or just radio. These types of devices are just radio transceivers
|
|
|
|
possibly with some kinds of acceleration like automatic CRC computation and
|
|
|
|
comparation, automagic ACK handling, address matching, etc.
|
|
|
|
|
|
|
|
Those types of devices require different approach to be hooked into Linux kernel.
|
|
|
|
|
|
|
|
|
|
|
|
HardMAC
|
|
|
|
=======
|
|
|
|
|
2009-08-07 02:58:39 +00:00
|
|
|
See the header include/net/ieee802154_netdev.h. You have to implement Linux
|
2009-06-08 12:18:50 +00:00
|
|
|
net_device, with .type = ARPHRD_IEEE802154. Data is exchanged with socket family
|
2009-08-19 14:53:39 +00:00
|
|
|
code via plain sk_buffs. On skb reception skb->cb must contain additional
|
|
|
|
info as described in the struct ieee802154_mac_cb. During packet transmission
|
|
|
|
the skb->cb is used to provide additional data to device's header_ops->create
|
2013-10-30 07:46:15 +00:00
|
|
|
function. Be aware that this data can be overridden later (when socket code
|
2009-08-19 14:53:39 +00:00
|
|
|
submits skb to qdisc), so if you need something from that cb later, you should
|
|
|
|
store info in the skb->data on your own.
|
2009-06-08 12:18:50 +00:00
|
|
|
|
|
|
|
To hook the MLME interface you have to populate the ml_priv field of your
|
2013-04-04 06:32:35 +00:00
|
|
|
net_device with a pointer to struct ieee802154_mlme_ops instance. The fields
|
|
|
|
assoc_req, assoc_resp, disassoc_req, start_req, and scan_req are optional.
|
|
|
|
All other fields are required.
|
2009-06-08 12:18:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
SoftMAC
|
|
|
|
=======
|
|
|
|
|
2012-05-15 20:50:31 +00:00
|
|
|
The MAC is the middle layer in the IEEE 802.15.4 Linux stack. This moment it
|
|
|
|
provides interface for drivers registration and management of slave interfaces.
|
|
|
|
|
|
|
|
NOTE: Currently the only monitor device type is supported - it's IEEE 802.15.4
|
|
|
|
stack interface for network sniffers (e.g. WireShark).
|
|
|
|
|
|
|
|
This layer is going to be extended soon.
|
2009-06-08 12:18:50 +00:00
|
|
|
|
2015-05-25 12:38:29 +00:00
|
|
|
See header include/net/mac802154.h and several drivers in
|
|
|
|
drivers/net/ieee802154/.
|
2009-08-19 14:53:39 +00:00
|
|
|
|
2012-05-15 20:50:31 +00:00
|
|
|
|
|
|
|
Device drivers API
|
|
|
|
==================
|
|
|
|
|
|
|
|
The include/net/mac802154.h defines following functions:
|
|
|
|
- struct ieee802154_dev *ieee802154_alloc_device
|
|
|
|
(size_t priv_size, struct ieee802154_ops *ops):
|
|
|
|
allocation of IEEE 802.15.4 compatible device
|
|
|
|
|
|
|
|
- void ieee802154_free_device(struct ieee802154_dev *dev):
|
|
|
|
freeing allocated device
|
|
|
|
|
|
|
|
- int ieee802154_register_device(struct ieee802154_dev *dev):
|
|
|
|
register PHY in the system
|
|
|
|
|
|
|
|
- void ieee802154_unregister_device(struct ieee802154_dev *dev):
|
|
|
|
freeing registered PHY
|
|
|
|
|
|
|
|
Moreover IEEE 802.15.4 device operations structure should be filled.
|
|
|
|
|
|
|
|
Fake drivers
|
|
|
|
============
|
|
|
|
|
2015-05-25 12:38:29 +00:00
|
|
|
In addition there is a driver available which simulates a real device with
|
|
|
|
SoftMAC (fakelb - IEEE 802.15.4 loopback driver) interface. This option
|
2016-11-28 17:22:33 +00:00
|
|
|
provides a possibility to test and debug the stack without usage of real hardware.
|
2012-05-15 20:50:31 +00:00
|
|
|
|
2015-05-25 12:38:29 +00:00
|
|
|
See sources in drivers/net/ieee802154 folder for more details.
|
2012-05-15 20:50:31 +00:00
|
|
|
|
|
|
|
|
2011-11-10 07:41:11 +00:00
|
|
|
6LoWPAN Linux implementation
|
|
|
|
============================
|
|
|
|
|
2015-05-25 12:38:29 +00:00
|
|
|
The IEEE 802.15.4 standard specifies an MTU of 127 bytes, yielding about 80
|
2011-11-10 07:41:11 +00:00
|
|
|
octets of actual MAC payload once security is turned on, on a wireless link
|
|
|
|
with a link throughput of 250 kbps or less. The 6LoWPAN adaptation format
|
|
|
|
[RFC4944] was specified to carry IPv6 datagrams over such constrained links,
|
|
|
|
taking into account limited bandwidth, memory, or energy resources that are
|
|
|
|
expected in applications such as wireless Sensor Networks. [RFC4944] defines
|
|
|
|
a Mesh Addressing header to support sub-IP forwarding, a Fragmentation header
|
|
|
|
to support the IPv6 minimum MTU requirement [RFC2460], and stateless header
|
|
|
|
compression for IPv6 datagrams (LOWPAN_HC1 and LOWPAN_HC2) to reduce the
|
|
|
|
relatively large IPv6 and UDP headers down to (in the best case) several bytes.
|
|
|
|
|
2016-11-28 17:22:33 +00:00
|
|
|
In September 2011 the standard update was published - [RFC6282].
|
2011-11-10 07:41:11 +00:00
|
|
|
It deprecates HC1 and HC2 compression and defines IPHC encoding format which is
|
|
|
|
used in this Linux implementation.
|
|
|
|
|
2015-05-25 12:38:29 +00:00
|
|
|
All the code related to 6lowpan you may find in files: net/6lowpan/*
|
|
|
|
and net/ieee802154/6lowpan/*
|
2011-11-10 07:41:11 +00:00
|
|
|
|
2016-11-28 17:22:33 +00:00
|
|
|
To setup a 6LoWPAN interface you need:
|
|
|
|
1. Add IEEE802.15.4 interface and set channel and PAN ID;
|
2011-11-10 07:41:11 +00:00
|
|
|
2. Add 6lowpan interface by command like:
|
|
|
|
# ip link add link wpan0 name lowpan0 type lowpan
|
2016-11-28 17:22:33 +00:00
|
|
|
3. Bring up 'lowpan0' interface
|