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