Presentation on theme: "802.15.4 - An introduction Jan Flora Department of Computer Science University of Copenhagen."— Presentation transcript:
802.15.4 - An introduction Jan Flora Department of Computer Science University of Copenhagen
Overview Introduction Device roles Topologies Communication and timing Beacon and non-beacon mode Superframes Indirect transmission The radio driver (PHY) Requirements Functionality Timing Filtering Acknowledgements MAC functionality Starting a PAN Scanning Association control PAN maintenance Beacon synchronization GTS control The PIB database
Overview - Cont’d Data transmission Direct transmission Indirect transmission GTS transmission
Introduction: Device roles Two device types: Reduced function device (RFD) Full function device (FFD) Three different roles: End device (RFD or FFD) Coordinator (FFD) PAN Coordinator (FFD) A coordinator must be able to act as both PAN coordinator and end device, even though it is neither :-) Coordinators can only exist in beacon enabled networks.
Introduction: Topologies Two main topology groups: Star network P2P network
Introduction: Topologies cont’d P2P cluster trees can be formed using coordinators as cluster heads
Introduction: Communication and timing 802.15.4 has two modes of operation: Non-beacon mode 802.15.4 makes use of CSMA-CA (carrier sense multiple access with collision avoidance) A clear channel assessment (CCA) is carried out before sending on the radio channel If the channel is NOT clear, we wait for a random period of time, before trying to retransmit Beacon mode Beacon mode introduces the superframe structure to divide time into different transmission periods (Beacon, CAP, CFP and inactive) During the CAP (Contention Access Period) communication is carried out like in non-beacon mode. CCA’s are aligned with the transmission/reception of the beacon.
Introduction: Communication and timing cont’d Beacon mode Beacon transmission takes place in the start of the CAP, but is carried out without using CSMA-CA. The CFP (Contention Free Period) is used for TDMA (Time Division Multiple Access) purposes. The CFP in divided into GTS’s (Guaranteed Time Slots). A GTS is used for communication between two predetermined devices. The inactive period can be used for sleeping or for communicating with other clusters (cluster heads in cluster trees). A coordinator would have a second superframes active part in the inactive period of its own superframe.
Introduction: Communication and timing cont’d Indirect transmission The end devices can not be expected to be in receive mode except for when expecting a response for a transmitted frame or the next beacon frame. Coordinators use indirect transmission when communicating with end devices. End devices must poll pending messages from the coordinators indirect transmission queue. Pending frames are indicated in the beacon frames sent out by the coordinator. Polling can be initiated automatically when a pending frame is indicated in the beacon, or by issuing the poll primitive (typically for non-beacon networks).
Radio Driver: Requirements Functionality: Transciever operations (TX, RX ED and CCA). Channel selection. Acknowledging frames. Frame filtering. Sleeping. Timing: Handle micro-precision start of transciever operations. Turn-around-time (eg. TX-RX) of 192 micro seconds must be enforced.
Radio Driver: Filtering Filtering is VERY time critical, since it must be carried out before any acknowledgement is sent. If a frame is rejected by the filter, it is automatically dropped by the radio driver. Ideally the filtering should be carried out by the radio chip (like in Chipcon CC2420). For Freescales MC13192 we do filtering in SW applying the filter word by word as the frame is received.
Radio Driver: Acknowledgements ACK’s are handled differently in beacon and non-beacon mode. In non-beacon mode an ACK must be transmitted 192 micro seconds after receiving the last byte of a valid frame demanding an ACK. In beacon mode, the ACK transmission is aligned with the TX/RX of the beacon (like the CCA).
MAC functionality: Starting a PAN When starting a PAN it is best practice to scan all available radio channels to find the channel with the lowest energy level (least traffic). The PAN is started issuing the start primitive. If beacon mode is requested, beacon transmission initiated. The role of the device changes from end device (default) to PAN coordinator. The start primitive can also be used to change the role of an end device to a coordinator. A coordinator will operate on the same radio channel and with the same PAN identifier as the PAN coordinator.
MAC functionality: Scanning Three scan types: Active scanning A frame is sent out on every specified channel, and responses are recorded. Passive scanning The receiver is enabled on each specified channel for a certain amount of time, and any “valid” traffic is recorded. Energy scanning The energy level is measured on any specified channel. The 802.15.4 standard dictates 4 scan variants: Active scanning for beacons Passive scanning for beacons Active scanning for orphan notifications Energy scanning
MAC functionality: Association control An end device must be associated to a PAN in order to communicate with its members. The association procedure is initiated through the associate primitive. The PAN coordinator responds with the decision on whether to allow the asociation of the end device. This decision process is not part of 802.15.4 Both PAN coordinator and end device can request disassociation. Both is initiated through the disassociate primitive.
MAC functionality: PAN maintenance Orphaned devices: An end device can lose track of its PAN coordinator (or coordinator). This could happen due to sleep. The end device can try to rediscover the coordinator by performing an active scan for orphan notifications (orphan scan). When rediscovering its coordinator, the end device can consider itself associated to the PAN and ready for operation. PAN conflicts: A PAN conflict arises when two PANs share the same PAN identifier. This can be detected by overhearing a beacon that originates from a PAN coordinator that is not the coordinator of the device but uses the same PAN identifier. A PAN conflict is resolved by notifying the PAN coordinator about the conflict. The PAN coordinator will inform the upper layer about the conflict. Conflict resolution is not part of 802.15.4.
MAC functionality: Beacon synchronization For an end device to operate on a beacon enabled PAN, the device must obey the superframe. All MAC control frames must be send in the CAP. In order to identify the CAP location, the device must track the coordinator beacon. Beacon synchronization is requested through the sync primitive. As long as the device is in sync with its coordinator, it can be expected to obey the superframe. A loss of synchronization is indicated through the sync-loss primitive.
MAC functionality: GTS control GTS’s are only available in beacon mode and can only be used for data transmission. GTS’s are assigned by the coordinator to requesting end devices. A GTS can be requested and deallocated through the GTS primitive. If a GTS is allocated following a GTS request, the availability of the GTS is indicated in the beacons.
MAC functionality: The PIB database Various MAC settings can be controlled through the PIB (PAN Information Database) database. The PIB database can be accessed from outside the 802.15.4 stack by using the get and set primitives.
Data transmission Data can be transmitted in three ways: Direct transmission Data is sent during the CAP. Indirect transmission This option is only available for coordinators. Data is placed on the indirect transmission queue. Data is sent during the CAP when polled. GTS transmission This option requires, that the sending device has an allocated GTS send slot with the receiving device. Data is send in the specified GTS slot during the CFP.
Your consent to our cookies if you continue to use this website.