mirror of
https://github.com/RIOT-OS/RIOT.git
synced 2024-12-29 04:50:03 +01:00
13036c1bc4
The module previously called net_ieee802154 is renamed to capture that it is about interacting the frames and headers, and moved "into" the new topic in the documentation tree. Exceptions for undocumented headers are updated.
89 lines
4.3 KiB
Plaintext
89 lines
4.3 KiB
Plaintext
/*
|
|
* Copyright (C) 2021 Christian Amsüss <chrysn@fsfe.org>
|
|
*
|
|
* This file is subject to the terms and conditions of the GNU Lesser
|
|
* General Public License v2.1. See the file LICENSE in the top level
|
|
* directory for more details.
|
|
*/
|
|
|
|
/**
|
|
* @defgroup net_ieee802154 IEEE 802.15.4
|
|
* @ingroup net
|
|
* @brief IEEE 802.15.4 components
|
|
*
|
|
* General introduction
|
|
* --------------------
|
|
*
|
|
* The IEEE 802.15.4 standard describes radio communication for low-rate local
|
|
* wireless networks, operating in different frequency bands, modulations and
|
|
* MACs; all of these have been extended over time in revisions of the
|
|
* standard. It also describes topologies and roles of devices (eg. a PAN
|
|
* coordinator that is a FFD (Full Function Device) and RFDs (Reduced Function
|
|
* Devices) and clusters that use different PAN IDs to keep their traffic
|
|
* apart), without prescribing how they are formed or managed.
|
|
*
|
|
* Common frequencies used are the 868 MHz band (one channel, in Europe), the
|
|
* 915 MHz band (10 channels, in America) and the 2.4GHz band (16 channels);
|
|
* several more are defined between 169MHz and 9GHz.
|
|
*
|
|
* The standard describes several MACs that govern when to send and to listen,
|
|
* as well as operation modes building on them;
|
|
* the choice of these involves the trade-offs between power consumption,
|
|
* complexity and latency, as it governs how much time devices can spend with
|
|
* their radios powered down. Some operation modes support channel hopping to avoid
|
|
* frequencies used by others. Common variations are:
|
|
*
|
|
* * nonbeacon-eanbled: devices send whenever they want; beacons are only sent
|
|
* when devices ask for them in order to join the network. Optionally,
|
|
* packets can be held until the device asks for them ("indirect
|
|
* transmission").
|
|
* * beacon-enabled: a coordinator sends beacons regularly, devices can send
|
|
* for some time after the beacon
|
|
* * TSCH: the network uses frequency and time slots strictly synchronized at the
|
|
* coordinator's beacons
|
|
* * DSME: the network uses either CSMA-CA or frequency and time slots,
|
|
* synchronized at the coordinator's beacon
|
|
*
|
|
* A comprehensive introduction to these is available in
|
|
* [Towards the Internet of Relevant Things: The IEEE 802.15.4e Standard](http://www.sigapp.org/sac/sac2016/T7-HandOut.pdf)
|
|
* presented Anastasi et al. at the ACM Symposium on Applied Computing 2016.
|
|
*
|
|
* Some MACs are established outside of the standard but either relevant for
|
|
* context or because they are used in RIOT:
|
|
*
|
|
* * contikiMAC: receivers listen in brief time slots and stay listening if
|
|
* they detect a carrier; senders send until they receive an acknowledgement.
|
|
* * "YOLO mode": receivers are always on; senders just send and hope for the
|
|
* best.
|
|
* * "submac": A mode between "YOLO" and nonbeacon-enabled mode, in which a
|
|
* consistent set of components common to many specified MACs (CSMA-CA,
|
|
* retransmissions, acknowledgements) is implemented.
|
|
*
|
|
* It is similar to nonbeacon mode, but lacks that mode's provisions for
|
|
* discovery (in which devices ask for beacons to be sent) and others.
|
|
*
|
|
* Due to the variation both in the 802.15.4 internal layer and the
|
|
* protocols used on top of it, applications always need to pick their
|
|
* components; that selection is often guided by standards or organizations
|
|
* that pick an interoperable set of components (higher-level protocol, MAC,
|
|
* band and others), like Thread (6LoWPAN, nonbeacon-enabled, 2.4GHz),
|
|
* WirelessHART (HART, TSCH, 2.4GHz) or 6TiSCH (6LoWPAN, TSCH).
|
|
*
|
|
* Availability in RIOT
|
|
* --------------------
|
|
*
|
|
* One way of using the 802.15.4 layer in RIOT is by @ref net_sixlowpan, which
|
|
* provides IPv6 connectivity atop of it. In these setups, the GNRC network
|
|
* stack is used, and details like band or short addresses are configured
|
|
* manually at build time (@ref CONFIG_IEEE802154_DEFAULT_PANID etc.) or at
|
|
* runtime (eg. through ``ifconfig``). Boards using a radio driver that is
|
|
* already ported to @ref net_ieee802154_submac are used in "submac" mode;
|
|
* all others use whatever their driver provides (varying from "YOLO" to some
|
|
* features of "submac").
|
|
*
|
|
* Alternatively, the @ref pkg_openwsn and @ref pkg_openthread modules provide
|
|
* standalone network stacks that conform to the 6TiSCH and Thread
|
|
* specifications, respectively.
|
|
*
|
|
*/
|