1===============================
  2IEEE 802.15.4 Developer's Guide
  3===============================
  4
  5Introduction
  6============
  7The IEEE 802.15.4 working group focuses on standardization of the bottom
  8two layers: Medium Access Control (MAC) and Physical access (PHY). And there
  9are mainly two options available for upper layers:
 10
 11- ZigBee - proprietary protocol from the ZigBee Alliance
 12- 6LoWPAN - IPv6 networking over low rate personal area networks
 13
 14The goal of the Linux-wpan is to provide a complete implementation
 15of the IEEE 802.15.4 and 6LoWPAN protocols. IEEE 802.15.4 is a stack
 16of protocols for organizing Low-Rate Wireless Personal Area Networks.
 17
 18The stack is composed of three main parts:
 19
 20- IEEE 802.15.4 layer;  We have chosen to use plain Berkeley socket API,
 21  the generic Linux networking stack to transfer IEEE 802.15.4 data
 22  messages and a special protocol over netlink for configuration/management
 23- MAC - provides access to shared channel and reliable data delivery
 24- PHY - represents device drivers
 25
 26Socket API
 27==========
 28
 29::
 30
 31    int sd = socket(PF_IEEE802154, SOCK_DGRAM, 0);
 32
 33The address family, socket addresses etc. are defined in the
 34include/net/af_ieee802154.h header or in the special header
 35in the userspace package (see either https://linux-wpan.org/wpan-tools.html
 36or the git tree at https://github.com/linux-wpan/wpan-tools).
 37
 386LoWPAN Linux implementation
 39============================
 40
 41The IEEE 802.15.4 standard specifies an MTU of 127 bytes, yielding about 80
 42octets of actual MAC payload once security is turned on, on a wireless link
 43with a link throughput of 250 kbps or less.  The 6LoWPAN adaptation format
 44[RFC4944] was specified to carry IPv6 datagrams over such constrained links,
 45taking into account limited bandwidth, memory, or energy resources that are
 46expected in applications such as wireless Sensor Networks.  [RFC4944] defines
 47a Mesh Addressing header to support sub-IP forwarding, a Fragmentation header
 48to support the IPv6 minimum MTU requirement [RFC2460], and stateless header
 49compression for IPv6 datagrams (LOWPAN_HC1 and LOWPAN_HC2) to reduce the
 50relatively large IPv6 and UDP headers down to (in the best case) several bytes.
 51
 52In September 2011 the standard update was published - [RFC6282].
 53It deprecates HC1 and HC2 compression and defines IPHC encoding format which is
 54used in this Linux implementation.
 55
 56All the code related to 6lowpan you may find in files: net/6lowpan/*
 57and net/ieee802154/6lowpan/*
 58
 59To setup a 6LoWPAN interface you need:
 601. Add IEEE802.15.4 interface and set channel and PAN ID;
 612. Add 6lowpan interface by command like:
 62# ip link add link wpan0 name lowpan0 type lowpan
 633. Bring up 'lowpan0' interface
 64
 65Drivers
 66=======
 67
 68Like with WiFi, there are several types of devices implementing IEEE 802.15.4.
 691) 'HardMAC'. The MAC layer is implemented in the device itself, the device
 70exports a management (e.g. MLME) and data API.
 712) 'SoftMAC' or just radio. These types of devices are just radio transceivers
 72possibly with some kinds of acceleration like automatic CRC computation and
 73comparison, automagic ACK handling, address matching, etc.
 74
 75Those types of devices require different approach to be hooked into Linux kernel.
 76
 77HardMAC
 78-------
 79
 80See the header include/net/ieee802154_netdev.h. You have to implement Linux
 81net_device, with .type = ARPHRD_IEEE802154. Data is exchanged with socket family
 82code via plain sk_buffs. On skb reception skb->cb must contain additional
 83info as described in the struct ieee802154_mac_cb. During packet transmission
 84the skb->cb is used to provide additional data to device's header_ops->create
 85function. Be aware that this data can be overridden later (when socket code
 86submits skb to qdisc), so if you need something from that cb later, you should
 87store info in the skb->data on your own.
 88
 89To hook the MLME interface you have to populate the ml_priv field of your
 90net_device with a pointer to struct ieee802154_mlme_ops instance. The fields
 91assoc_req, assoc_resp, disassoc_req, start_req, and scan_req are optional.
 92All other fields are required.
 93
 94SoftMAC
 95-------
 96
 97The MAC is the middle layer in the IEEE 802.15.4 Linux stack. This moment it
 98provides interface for drivers registration and management of slave interfaces.
 99
100NOTE: Currently the only monitor device type is supported - it's IEEE 802.15.4
101stack interface for network sniffers (e.g. WireShark).
102
103This layer is going to be extended soon.
104
105See header include/net/mac802154.h and several drivers in
106drivers/net/ieee802154/.
107
108Fake drivers
109------------
110
111In addition there is a driver available which simulates a real device with
112SoftMAC (fakelb - IEEE 802.15.4 loopback driver) interface. This option
113provides a possibility to test and debug the stack without usage of real hardware.
114
115Device drivers API
116==================
117
118The include/net/mac802154.h defines following functions:
119
120.. c:function:: struct ieee802154_dev *ieee802154_alloc_device (size_t priv_size, struct ieee802154_ops *ops)
121
122Allocation of IEEE 802.15.4 compatible device.
123
124.. c:function:: void ieee802154_free_device(struct ieee802154_dev *dev)
125
126Freeing allocated device.
127
128.. c:function:: int ieee802154_register_device(struct ieee802154_dev *dev)
129
130Register PHY in the system.
131
132.. c:function:: void ieee802154_unregister_device(struct ieee802154_dev *dev)
133
134Freeing registered PHY.
135
136.. c:function:: void ieee802154_rx_irqsafe(struct ieee802154_hw *hw, struct sk_buff *skb, u8 lqi)
137
138Telling 802.15.4 module there is a new received frame in the skb with
139the RF Link Quality Indicator (LQI) from the hardware device.
140
141.. c:function:: void ieee802154_xmit_complete(struct ieee802154_hw *hw, struct sk_buff *skb, bool ifs_handling)
142
143Telling 802.15.4 module the frame in the skb is or going to be
144transmitted through the hardware device
145
146The device driver must implement the following callbacks in the IEEE 802.15.4
147operations structure at least::
148
149   struct ieee802154_ops {
150        ...
151        int     (*start)(struct ieee802154_hw *hw);
152        void    (*stop)(struct ieee802154_hw *hw);
153        ...
154        int     (*xmit_async)(struct ieee802154_hw *hw, struct sk_buff *skb);
155        int     (*ed)(struct ieee802154_hw *hw, u8 *level);
156        int     (*set_channel)(struct ieee802154_hw *hw, u8 page, u8 channel);
157        ...
158   };
159
160.. c:function:: int start(struct ieee802154_hw *hw)
161
162Handler that 802.15.4 module calls for the hardware device initialization.
163
164.. c:function:: void stop(struct ieee802154_hw *hw)
165
166Handler that 802.15.4 module calls for the hardware device cleanup.
167
168.. c:function:: int xmit_async(struct ieee802154_hw *hw, struct sk_buff *skb)
169
170Handler that 802.15.4 module calls for each frame in the skb going to be
171transmitted through the hardware device.
172
173.. c:function:: int ed(struct ieee802154_hw *hw, u8 *level)
174
175Handler that 802.15.4 module calls for Energy Detection from the hardware
176device.
177
178.. c:function:: int set_channel(struct ieee802154_hw *hw, u8 page, u8 channel)
179
180Set radio for listening on specific channel of the hardware device.
181
182Moreover IEEE 802.15.4 device operations structure should be filled.