http://freaklabs.org/index.php/Articles/Zigbee/IEEE-802.15.4-in-the-Context-of-Zigbee-Part-2-MAC-Layer.html
When the economic news is too unbearably depressing to allow me to even write software, I turn to the few things that I know I can count on: my Groove Salad streaming MP3 radio station (legal, of course), a glass of wine, and the tutorial series on 802.15.4 and Zigbee that I have yet to finish.
When we left off last time, Jan was sleeping with Jim, the transsexual who goes by the name of….wait…no, we left off at the 802.15.4 PHY layer. Well, the PHY layer is pretty straightforward unless you're an RF IC engineer, so now we're going to get into the real meat of things…the MAC layer.
The MAC layer is where all the fun is in terms of a software protocol stack. Actually, the 802.15.4 MAC is fairly complicated and feature-packed, which is why I named this series "802.15.4 in the Context of Zigbee". As the title implies, I'm only going to cover enough of 802.15.4 to understand how it fits into a protocol like Zigbee. Luckily, Zigbee eschewed a good portion of 802.15.4 in the name of simplicity and getting a spec out quick, so you won't need to know a whole bunch about 802.15.4. Unfortunately, this has also become a weakness of Zigbee.
Beacon Modes
One of the most glaring omissions of the Zigbee spec is that it doesn't use the 802.15.4 MAC in beacon mode (except for tree-only routing implementations which are impractical as I'll explain in some later article).
The MAC layer defines two basic modes of operation: beacon mode and non-beacon mode. Beacon mode is timing dependent, where a beacon frame is sent out at some set interval defined by the implementation. The beacon defines the start of a superframe which is basically the interval between the beacons, and is used as a way for the devices on the network to synchronize with each other. The superframe is divided into two parts: the active part where data transfers occur, and the inactive part where the device can go to sleep. For very low power operation, you can define the ratio of the active time to the inactive time to be very low so that the device spends most of its time sleeping.
In non-beacon mode, there is no concept of a superframe and the beacons are only used to discover what networks exist within a channel. In other words, beacons are only used when a device is first turned on and it scans for networks to join. Non-beacon mode is completely asynchronous so the upper layer protocol needs to treat each node as completely independent. This has certain implications, especially to power consumption. One of the biggest complaints about Zigbee is that the routers are not allowed to sleep due to the asynchronous nature of non-beacon mode. Since the routers never know if an end device is sleeping or not, it needs to always be on to receive and buffer frames for its children. The children will poll the router periodically to see if there are any messages buffered for that device. The fact that the routers are always on means that certain types of applications are non-feasible for Zigbee, such as applications where the routers do not have access to a MAINS supply.
Media Access Control
The main purpose of the MAC layer is to provide access control to the shared channel and reliable data delivery. In layman's terms, that means that it controls the channel so that only one device is transmitting at a time and it also defines the handshaking acknowledgement when a frame is received successfully.
So let's get started with one of the main functions of the MAC. That is to provide access control to the wireless medium. To accomplish this, it uses a simple algorithm called CSMA/CA which stands for Carrier Sense Multiple Access/Collision Avoidance. It sounds complicated, but it's really rather simple:
Think of the street that you live on. When you pull your car out of your driveway in the morning, you need to implement CSMA/CA. As you inch your car out of the driveway, you're constantly checking your right and left rear sides to make sure no cars are coming. That's the carrier sense, where the street is the carrier. The fact that you're checking for a car other than yours coming down the street is the multiple access. You're making sure that no other cars are trying to access the road that you want to get on. If you see another car coming as you're trying to get on the road, you stop, possibly inch your car back up the driveway, and wait some unspecified amount of time for the car to pass. That's called collision avoidance. Yes, that's the genius algorithm that engineers devised for the 802.15.4 media access. It's actually slightly more complicated if you use beacon mode, however since we're only focusing on Zigbee, then we don't need to worry about that.
So now that we have the cheesy analogy out of the way, let's see how it really works. When you want to transmit a frame, the first thing you need to do is a CCA, or clear channel assessment. That means that you instruct the radio to check the receive channel and see if there is any data being transmitted, either to you or some other device on the channel that you're on. If it's clear, then you can transmit the frame. Voila!
If it's not, then you have to go into collision avoidance mode. If the channel is not clear, then you wait for a random amount of time and check the channel again. If it's still not clear, you do the same thing. To avoid ending up in an infinite loop, the implementor sets a maximum amount of CSMA backoffs that can be performed. If that amount is exceeded, then the transmit attempt is failed. This usually means you have a serious problem with the channel that you're on so your software better do something to handle it. This gets into frequency (channel) agility which we can discuss more about in the Zigbee section.
802.15.4 Device Types
There are two devices types defined by the 802.15.4 spec:
- Full Function Device (FFD):
- Full function devices are allowed to start a network and assume the role of coordinator. They are also able to allow other FFDs or reduced function devices (RFDs) to join them. For Zigbee, FFDs are known as Zigbee Routers and are the only devices that can forward frames. They must have sufficient RAM to buffer frames for the devices that are joined to it and hold all the tables including the routing and neighbor tables. These devices usually have large flash memory footprints as well since they handle the bulk of the logic in a Zigbee network.
- Reduced Function Device (RFD):
- These devices are only allowed to join FFDs and cannot have other devices join them. They cannot start a network or become a coordinator and are also not allowed to do any routing. In Zigbee, they are known as Zigbee End Devices (ZEDs). The advantage of a Zigbee End Device is that the code and RAM footprint are much smaller resulting in a lower cost device. They are also allowed to sleep so they can reduce their power consumption and survive for long periods of time on a battery.
802.15.4 MAC Topologies
802.15.4 defines two main topologies: point-to-point and star networks. A point-to-point topology is the simplest and isn't even a network. This is just a serial cable replacement where one device can transmit to another device. It's nothing too fancy so I won't spend too much time on it.
A star network is perhaps the simplest real networking topology supported by 802.15.4. It defines a central coordinator and multiple satellite devices that have joined to the coordinator. Unlike an actual star network where the data needs to pass through the center of the star before going to another satellite, an 802.15.4 star network can send data to any device within listening range. However the topology exists because the coordinator always needs to exist to start the network and the devices need to join the coordinator before they can start transmitting on the network.
The MAC layer also defines the services required for a peer-to-peer network where any device can transmit to any other device on the network. However if the receiving device is outside the listening range of the transmitting device, then the frame needs to be somehow forwarded until it reaches the destination. This forwarding mechanism is where the boundary lies between 802.15.4 and Zigbee, since Zigbee defines the mechanism and rules for forwarding frames across a network.
Incidentally, although Zigbee is touted as supporting a mesh network, the actual Zigbee network topology is called a clustered star network. The reason that it follows this topology is because the Zigbee End Devices (ZEDs) are not allowed to perform any routing. Hence the ZEDs are just satellites to their parents. In this type of topology, only the Zigbee Routers (ZRs) are allowed to route frames to each other. A true mesh network would allow routing from any device to any other device, which implies that all devices need to have routing capabilities.
802.15.4 Frame Formats
An generic 802.15.4 frame consists of the PHY header, MAC header, MAC data payload, and the frame checksum. There are four specific types of frames that are defined by the 802.15.4 specification and the frame type is defined in the Frame Control Field, located in the first two bytes of the MAC header. After the general frame format diagram, I'll cover each individual frame type.
- Beacon:
- The beacon frame is a special frame that is used to transmit network information and also synchronize devices on the network and can only be transmitted by full function devices. In Zigbee, the beacon is used to transmit network information and is only used for network discovery.
- Data:
- The data frame is the basic and most common frame. It's used to transmit data and can be sent as a unicast or broadcast frame. A unicast frame means that it will only go to the device specified in the destination address. A broadcast frame means that it will go out to all devices within listening range on the network.
- Command:
- Command frames are used for network management and control and have a command ID associated with them. The command ID will identify the type of command that is being requested and the command frame recipient will respond accordingly.
- Acknowledge:
- If a frame is received with its ack_request flag set, then that means that the frame requires an ACK to inform the transmitter that it was received properly. The receiver will then transmit an ACK frame which basically consists of the frame's unique identifier (DSN) and a frame ID that identifies it as an ACK.
Addressing
There are two types of addresses in 802.15.4:
- Extended address
- This is an 8-byte address that is used as a universal, unique identifier for the device and will differentiate it from all other devices in the world. It is similar to the MAC address of an Ethernet device. The IEEE 64 bit address is known as the extended unique identifier (EUI) and consists of the 24-bit organizationally unique identifier (OUI) a.k.a. company ID, and a 40-bit unique identifier assigned by the company that owns the OUI. The address range needs to be purchased from the IEEE.
- Short address
- This is a 2-byte address that is unique only on the network that the device has joined to. It is the main addressing method used in a Zigbee network to identify a device and also serves the purpose of determining the position of the device within the Zigbee tree routing hierarchy.
Indirect Data Transfers
Indirect transfers are used to send data to an RFD (Zigbee end device). Since it is not possible for a parent to know when a child RFD is sleeping, it cannot simply send a frame to it at any time. Hence it will buffer all frames destined to the child device. The child device will poll the parent at a set interval determined by the implementation and retrieve any pending frames for it.
In order to poll the parent, the child sends a special frame called the data request command frame to the parent. If the parent has data for the child, the parent will indicate it in the "frame pending" field of the ACK. That will let the child know that it should keep its receiver on for the incoming data frame. Otherwise, if the ACK indicates no frames, the child will turn off its transceiver and go back to sleep.
Network and Energy Scanning
802.15.4 defines a generic scan mechanism that allows the device to perform different types of scans. The ones most often used by Zigbee are the energy scan and the network scan. The network scan is used for Zigbee network discovery and the energy scan is used in conjunction with the network scan for Zigbee network formation.
An energy scan is a relatively simple operation where a device turns on its receiver and samples the energy level for a certain amount of time. The scan is performed on all channels that are allowed to the device, and the results of the energy scan will tell the device how much noise or interference exists on a channel. This will be useful for the device in determining an optimal channel to form a network on.
A network scan consists of a device broadcasting a beacon request command frame. This is a command frame with an ID of "beacon request" and it will be received by all devices on the network. If an FFD receives a beacon request command frame, it must respond with a beacon frame containing information about itself and the network. The scanning device will then collect all the beacons and compile a list of FFDs within listening range as well as the different networks that exist on that channel.
Association
Association is the process of a device joining to a parent node. Association is very dependent on the upper layer for many of the decisions on joining criteria, so in this sense, it's basically a service that is used by the upper layer, Zigbee in this case, to join devices to the network. That being said, let's take a closer look at the association sequence.
The association process occurs after a device finishes its network scan and chooses a suitable parent to join. The choice of a suitable parent is determined by the Zigbee stack. Once a parent is chosen, the device will issue an association request command frame to the potential parent. When the parent receives the request, it will determine if it has the capacity to add another device and is permitting other devices to join it. This is also determined by the Zigbee layer. The potential parent will then issue an association response command frame telling the device whether the join was successful or not. If it was successful, the response frame will also contain the short address that will be used to identify the node on the network. It might be kind of hard to follow so I tried to illustrate the data flow in the following sequence diagram.
You might notice that there's a slight complication where the association response is sent via indirect data transfer. This is because the parent can't send the response directly to the child in the case that the child is asleep so it uses an indirect transfer instead.
Well, I guess that covers the major areas that I wanted to hit for the MAC layer in this part. The next part will get into the data and management services descriptions and some of the minutiae of the MAC layer, and hopefully wrap things up so I can get started on the Zigbee portion.
http://freaklabs.org/index.php/Articles/Zigbee/IEEE-802.15.4-in-the-Context-of-Zigbee-Part-3-MAC-Layer.html
I'm back once again to excite you with the details of the IEEE 802.15.4 spec. Actually, it's not so boring if you know what you're looking for. But if you were like me, wading through the endless SDL diagrams and trying to make sense of the bizarre acronyms, then yeah, it's a real snoozer. This will be the last in the three-part 802.15.4 series and should be quick. It's just going to be a quick summary of the MAC layer service functions defined in the spec. As I mentioned before, this will only explain the service functions as it applies to Zigbee.
In this part, I'm going to be going over the 802.15.4 service interfaces, since the spec can make it rather cryptic; especially if you see something like MCPS-DATA.indication. Instead, I'm going to try and explain what the data and management services are, how they're used, and try my best to avoid the spec formality so that it's easier to get an implementation view of things.
If you look at the MAC layer block diagram in the 802.15.4 spec, you're going to see a lot of weird terms and acronyms. An example would be the entry ports to the layer. These ports are called "MCPS-SAP" and "MLME-SAP" respectively. Ugh. Technically, that stands for the "MAC Common Part Sublayer - Service Access Point" and the "MAC Layer Management Entity - Service Access Point". Unfortunately, I've never seen any use for those ports. When I designed the MAC layer of the FreakZ stack, I found it easier to call the functions directly. In other stacks that I've seen, they either call the functions directly or use function pointers that serve as the API for the layer. Going through a level of abstraction like ports would just add overhead and make a stack bigger.
Before I get too distracted, let me get into the real meat of this post. The MAC layer is actually divided into two functional partitions: Data handling and Device/Network management. The data handling portion can be thought of as the data path and the management portion can be thought of as the control path. The data path is pretty straightforward but should be optimized since it will be accessed the majority of the time. The management (control) path is not accessed very frequently, but can be complex and must be implemented. At least part of it anyways. With no further ado...
MAC Data Service
| Data Request |
This is for outgoing data frames and can be more appropriately called mac_tx. The Zigbee network layer will call this function once it has decided where a frame needs to go (based on its routing tables, etc). All of the required info will be provided such as the source and destination addresses, PAN ID, and the transmit options so this function basically just needs to format all that data into the relevant MAC header and slap it on to the front of the Zigbee network frame. Once the header is assembled, the final touch will be to add the frame length to the front of the frame (ie: the PHY header).
Once the frame is assembled, there are actually two ways to send it. If its going to another router or an end device whose receiver is always on, the frame will be sent directly via the radio. Otherwise, if the destination is a sleepy end device, the frame will need to be sent as an indirect transfer. The frame will go to the indirect queue until the destination device wakes up and polls the parent. Once the poll comes in, the frame will get sent to the destination.
|
| Data Confirm |
This is a separate function than the data request and usually runs asynchronously to it. Its purpose is to communicate the status of the transmitted data. If no response was received and the maximum number of transmission retries was exceeded, it will send a failure status. Otherwise, it will send a success status or some other code expressing any issues that occurred during transmission. |
| Data Indication |
This is for incoming data and can be more appropriately called mac_rx. Usually an indicator will be set in the Rx ISR that a frame came in and will trigger the call of this function. The MAC code will then start to process the inbound frame and send it up the stack. |
| Purge |
Not required for Zigbee. |
MAC Management Service
Association
|
The association function is used to join a node to a parent. Before a node is allowed to communicate on the network, it must go through the association process and join a parent that is in the network. Zigbee uses the association service in its NWK_JOIN service. |
| Disassociation |
This would normally be used to remove a node from its parent on the network. However Zigbee doesn't use this service and instead defines its own command frame called NWK_LEAVE which is sent as a data frame. |
| Beacon Notify |
This service is used to inform the Zigbee layer that a beacon has arrived and requires processing. Zigbee uses information in the beacon to communicate router/end device capacity and whether or not they are allowing joining. |
| MAC PIB Get/Set |
I have a hard time seeing how these should exist as services since they basically just manipulate a data structure that holds the MAC settings. In my implementation, I just manipulate the table directly via pointer. |
| GTS |
Used for reserving guaranteed timeslots in beacon mode. Not used by Zigbee. |
| Orphan Notification |
When a device loses its parent, it's considered an orphaned device. There are a couple ways that this can happen, but normally, it occurs through a failure on the parent or if the end device is mobile and it moves out of range. If a device is orphaned, then it will do an orphan scan by broadcasting an "orphan notification" command frame in the hopes of finding its parent. If the parent gets the notification, it will inform the device that it's still there and the orphan can rejoin that parent. |
| Reset |
Resets the MAC layer and sets all values to their defaults in the PIB. |
| Rx Enable |
Not used for Zigbee. Zigbee doesn't specify transceiver control except for routers which must always have their receivers on. End device power handling is dependent on stack architecture and requirements. Transceiver control is also usually implemented at the driver level. |
| Scan |
There are three types of scans that are used in Zigbee: energy scan, network (active) scan, and orphan scan. The energy scan is used during network formation to select a channel with low noise on it. The network scan is used during network formation and network discovery. During network formation, the channel is selected based on the noise level and the amount of other networks on the channel. For network discovery, the scan active scan is used to find other networks to join. The orphan scan, as mentioned above, is used for an orphaned device. It consists of broadcasting an orphan notification frame and waiting to see if the parent responds. |
| Comm Status Indication |
This is mostly used to inform the Zigbee network layer that an event occurred in the indirect transaction queue. Indirect transactions are transactions that are buffered and require the destination device to poll the parent to retrieve the frame. If a buffered frame is sent to its destination successfully, a comm status indication is sent with a success code. Otherwise, if a frame times out and is purged, then a comm status indication is also sent out with the relevant code. |
| Start |
This is used to start the MAC layer and initialize the device. It is also used to change certain settings in the MAC layer such as the superframe configuration. In Zigbee, it's just used to start the device and is normally called after a MAC reset. |
| Sync |
Not used in Zigbee unless on a beacon enabled network. |
| Sync Loss Indication |
Not used in Zigbee unless on a beacon enabled network. |
| Poll |
Used by the Zigbee nwk_sync request to poll the parent for any pending data buffered for the device. Calling the poll function will generate a data_request command frame and set off the indirect transaction sequence. |
That should wrap it up for this series on IEEE 802.15.4 in the Context of Zigbee. From here, I'll probably be starting up the next series which is a detailed look at the Zigbee layers and how it's implemented.
