In the star topology, all of the devices are children of a central Coordinator device and are within its direct radio communication range (Fig. 1). Each device is within two hops of another. The RFDs don’t communicate directly with each other, but instead send messages to the Coordinator, which then forwards them to the destination device.
The mesh topology consists of a lattice of interconnected devices, including both routers and end devices (Fig. 2). All FFDs within radio range of each other can communicate directly.
Outside of radio range, communication among devices is supported by passing data along the most effective links until the destination is reached. This is commonly referred to as “multi-hop” communication. In practice, routers are interspersed throughout the network and then connected to provide at least two paths to each device to avoid a single point of failure.
TOPOLOGY IMPACE ON MEMORY USAGE
The star topology is much easier to operate, and it can have a significant impact on reducing the memory footprint of network devices. Complexity and the amount of data required are two key drivers:
• Code size and complexity: The star topology is much simpler to implement at the network layer of the device protocol stack, and the routing algorithm is straightforward. Just send every message to the coordinator, and they will be sent on to their final destination. By contrast, the routing algorithm required to support a mesh network device is very complex. With complexity comes increased program memory size.
As an example, Microchip’s mesh routing subsystem within its ZigBee PRO stack requires about 4 kbytes more program memory than a similar, more streamlined mechanism employed in its MiWi protocol. Both use the IEEE 802.15.4 MAC protocol.
• NVM resource usage: The mesh topology requires routers and the Coordinator to maintain a routing table. This table is used to maintain the best paths to other devices in the network. In its simplest form, the MCU memory space required to maintain a routing table will grow proportionally with the network size.
Some wireless protocols, including ZigBee, require the preservation of important information across power failures and device resets. This includes the preservation of the routing table. Thus, to support the mesh topology and its related routing table, NVM storage is required. A typical application will require about 100 bytes of NVM for maintaining the routing table of a mesh network of up to 20 devices.
While some applications may require support for a mesh topology, a star topology is sufficient for many others. In such instances, the use of the star topology will yield a reward of lower memory usage. The primary benefits are in two areas: code space savings gained from a simplified routing mechanism, and RAM or NVM storage savings gained from not having to maintain a complex routing table.
Another topology-related technique for saving memory is to use what is commonly referred to as “tree routing.” Rather than maintain a complex routing table and perform computationally expensive link cost calculations, devices make simple routing decisions with tree routing. They either pass any given packet up the tree to its parent or down the tree to one of its descendants. In practice, this decision is based on the destination device’s address. Generally, tree routing requires about 60% less code space to implement than a full mesh routing algorithm.
APPLICATION FEATURE SET SELECTION
The second strategy for reducing the memory footprint is to streamline the feature set of each WSN device. To support this strategy, the device application must be designed in such a way that, for each deployment, only the required core feature set is actually included within the MCU’s memory space. Unused features are excluded, directly reducing the required memory footprint. The architecture of the device must be designed with this strategy in mind.
Using the free Microchip ZigBee protocol stack as an example, all major protocol-stack supported features, particularly those that may be optional for some deployments, are designed so they can be either included or excluded from a given device realization. This is accomplished by providing a feature selection tool and coupling its use with judicious use of compile-time options.
FEATURE SELECTION IMPACT ON MEMORY USAGE
The ZigBee protocol feature called “fragmentation” illustrates the effectiveness of this streamlining strategy. The IEEE 802.15.4 specification, which ZigBee is based on, limits each packet to 127 bytes. Applications that require larger payloads aren’t directly supported. To address this issue, the ZigBee Alliance introduced the fragmentation feature, whereby packets larger than 127 bytes of payload can be broken into smaller blocks. These blocks are sent and reassembled at the receiver.
While this is a useful feature, it may not be a necessary option, since most packets that are transmitted fall in the range of 20 to 40 bytes. This feature required about 1.5 kbytes to implement. More importantly, a large block of dynamic memory must be set aside to manage fragmented packets that were never sent.
To accommodate both users and nonusers of a particular feature set, the strategy is to offer a convenient way of including or excluding them from a particular WSN device. A configuration tool is used to select the desired feature set, and it, in turn, generates the desired configuration file. This file is used by the application at build time to create devices that only contain the selected feature set.
In a wireless sensor network, some common features that lend themselves to be either included or excluded from a particular deployment include security and encryption, where packets are instead sent in the clear. Tree routing replaces the more complex mesh routing. And, frequency agility—the ability to dynamically switch channels to avoid interference—is replaced with the simpler fixed-channel mode of operation.
For customers who are deploying a private WSN, where inoperability with other manufacturers’ devices is not a requirement, such a feature-selection approach can be a significant cost saver. When used effectively, the memory footprint of the WSN device can be lowered, which directly affects the final cost of the device.
Continue to page 3
Reprints
