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.
|
Posts
No comments:
Post a Comment