- Open Access
PluralisMAC: a generic multi-MAC framework for heterogeneous, multiservice wireless networks, applied to smart containers
© De Mil et al; licensee Springer. 2012
- Received: 15 September 2011
- Accepted: 10 May 2012
- Published: 10 May 2012
Developing energy-efficient MAC protocols for lightweight wireless systems has been a challenging task for decades because of the specific requirements of various applications and the varying environments in which wireless systems are deployed. Many MAC protocols for wireless networks have been proposed, often custom-made for a specific application. It is clear that one MAC does not fit all the requirements. So, how should a MAC layer deal with an application that has several modes (each with different requirements) or with the deployment of another application during the lifetime of the system? Especially in a mobile wireless system, like Smart Monitoring of Containers, we cannot know in advance the application state (empty container versus stuffed container). Dynamic switching between different energy-efficient MAC strategies is needed. Our architecture, called PluralisMAC, contains a generic multi-MAC framework and a generic neighbour monitoring and filtering framework. To validate the real-world feasibility of our architecture, we have implemented it in TinyOS and have done experiments on the TMote Sky nodes in the w-iLab.t testbed. Experimental results show that dynamic switching between MAC strategies is possible with minimal receive chain overhead, while meeting the various application requirements (reliability and low-energy consumption).
- wireless networks
- neighbour management
- dynamic switching
- smart container monitoring
Developing energy-efficient MAC protocols for lightweight wireless systems has been a challenging task for decades because of the specific requirements of various applications and the varying environments in which wireless systems are deployed. Many MAC protocols for wireless networks have been proposed, often custom-made for a specific application. However, we have noticed two evolutions in wireless (sensor) networks. First, there is a shift from simple monitoring applications towards multiple applications (or an application with several modes) in the same network. Second, there is a shift from homogeneous devices towards heterogeneous devices (e.g. mobile battery-powered devices with limited processing power and a minimum required lifetime of 2 years, fixed mains-powered devices with many communication interfaces, or battery-powered portable devices which are easy to recharge on a daily or weekly basis). So, how should a MAC layer deal with an application that has several modes (each with different requirements) or with the deployment of another application during the lifetime of the system?
This is exactly the problem we have encountered during the design and implementation of a solution of a smart container monitoring system. The architecture is a complex system of mobile and lightweight devices with stringent energy consumption requirements and varying requirements for the MAC layer because of the peculiarities of the monitoring application.
To the best of the authors' knowledge, we have not found a MAC protocol that can meet all these requirements. Although hybrid MAC protocols exist, these are not sufficient in mobile systems, like the smart container monitoring system. This smart container use case, which will be described in Section 2, has inspired us to create a multi-MAC framework and a neighbour management framework (NMF). These frameworks are generic, so they can be deployed in a broader context and deal with other use cases (e.g. building automation, smart cities, etc.) as well that have conflicting requirements that cannot be addressed by monolithic or inflexible solutions.
Instead of designing one monolithic MAC protocol, we will switch between MAC strategies (the so-called maclets) based on the application state and requirements. In Section 3, we will show why one MAC does not fit for all our requirements. Section 4 gives an overview of the PluralisMAC design goals and our architecture is described in Section 5. We will offer common functionalities of a MAC protocol in shared primitives. This way, maclets do not have to implement these themselves. We have implemented this in TinyOS and have done experiments on the w-iLab.t testbed (Section 6). The results of our experiments are presented in Section 7. In Section 8, an overview of related work is given. Lastly, we conclude by a summary in Section 9.
One of the major tasks of supply chain management is to follow goods, stored in containers, from origin to final destination. A huge number of containers are stored in container port terminals, empty or loaded, or on freight ships and tracking their location could increase business efficiency. During the transport of goods, it is important to have an accurate view on the condition of goods (in particular for goods with a limited lifetime, such as food, or goods which needs to be stored at controlled conditions) and on the trajectory.
Smart container monitoring is therefore required. This means that the containers will be equipped with a device that will periodically generate data that need to be sent to a central ICT system in the cloud. However, in order to be accepted by the sector, such a smart container monitoring system must take into account several requirements.
Lightweight system with a low investment cost.
Easy to install the system on a container thereby lowering installation costs and avoiding the need for skilled labour.
Extended battery lifetime: GPRS/UMTS communication is highly energy consuming. Therefore, by realizing energy-efficient communication amongst the monitoring devices instead of sending their information separately, information from several devices could be collected and sent in bulk over a single GPRS/UMTS interface. This avoids many separated GPRS/UMTS connections and thus high energy consumption for each device.
Increased connectivity for all containers: A 3D stacked container environment is a hostile environment for wireless communication: the containers provide physical, visual and radio shielding. By letting devices communicate with and via each other (multi-hop), containers that are placed at the centre of a big block may still be able to reach the outside world through all the other metal containers without a costly and more powerful transmitter. Our real-life tests indicate that one container can communicate with an adjacent container and the container adjacent to that container (in both directions).
Ultra-low battery consumption to reduce battery replacements and increase the lifetime of the device: By applying intelligent sleep schemes and communication strategies according to the application requirements, energy consumption can strongly be reduced.
Allowing a gradual roll-out: Communication between containers can be useful as indicated above. However, such a solution should also be usable even when deployed only in a limited number of containers.
Additional devices to increase efficiency: next to the devices mounted on the container, additional devices mounted on fixed infrastructure or on the carrier or portable devices are required that are able to interact with the container devices in order to improve communication, reduce energy consumption and enhance process efficiency.
Within the MoCo project , in which the authors participate, a smart container system architecture is being developed and implemented. This includes a small, cheap, lightweight monitoring device that will make intelligent use of different wireless technologies (UMTS/GPRS and IEEE 802.15.4 sensor technology) in order to enable optimized and energy-efficient container monitoring. The goal is to realize a cheap generic and energy-efficient connectivity solution including IEEE 802.15.4 sensor technology for communication between 3D stacked containers and making use of tailored and highly energy-efficient protocols.
In the following sections, we will first identify the importance of container monitoring by briefly describing related work. Next, we will highlight the most important aspects and characteristics of our architecture and identify the challenges for the design of an efficient MAC layer for the IEEE 802.15.4 radio.
2.1. Related work on container monitoring
Most of the systems that are used today for monitoring containers use RFID tags to monitor the goods inside the container or to monitor the container itself. The range of these RFID tags is very limited and it is not possible to access this information over a longer distance. Only recently, researchers have started to use wireless sensor networks for monitoring containers. In , an architecture of low-power wireless sensor networks for container tracking and monitoring applications is described. They have proposed three devices: (1) internal monitors (sensor nodes), (2) container monitor (has a WSN interface, GSM and GPS) and (3) Prime Monitor (infrastructure node). IBM's Secure Trade Line  proposes a safe and secure solution for monitoring containers. For wide range communication, GSM/GPRS or satellites are used; ZigBee provides short-range communication inside the container. Each container needs to be equipped with a device that either has a GSM or satellite receiver, making the device cost expensive. Networking between the containers is not considered (in , it is stated that in IBM's solution, a meshed Bluetooth network can be established if one or more containers do not have a working satellite uplink). The Monitoring and Security of Containers (MASC) system  introduces a similar container monitoring system that collects data from sensors inside the container. These sensors are wired connected to an outside antenna that directly reports to a base station. No mesh networking between the containers is used. The communication between the container and the remote server is push-based (because the MASC units are battery powered). The EPC Sensor Network  introduces a combined global standard infrastructure for WSNs and RFID systems based on the EPCglobal Architectural Framework  to support data sharing between partners. The EPC Sensor Network tries to add WSN support to the initial goals of the framework. However, it is not fully specified how this should be done.
All of these solutions above do not fully investigate the communication issues, but mainly focus on providing services. The communication part is handled by standardized components, i.e. ZigBee or Bluetooth, and mostly focuses on direct communication between a container and an external network. We believe that not all the containers can contact the external network using their own WAN interface because of the hostile environment for wireless communication they operate in.
Recently, some research group started to investigate communication between containers. In , multi-hop routing is proposed in order to cope with communication problems caused by multipath propagation. The Intelligent Container project by University of Bremen uses a combination of RFID and sensors within one container . Communication between the containers is executed using different mobile networks, such as WLAN, GPRS or UMTS, depending on availability. The goal is to monitor quality changes that could occur during transport. In [9, 10], a hierarchical architecture is proposed: (1) an internal container network for communication using a combination of RFID tags and sensor motes; (2) an external network between containers that uses more powerful gateways, using an IEEE 802.11 interface or a GPRS modem. In this architecture, each container needs to be equipped with such a gateway. This research group is also the first one who has conducted a real-life experiment in a 3 × 3 stacked container configuration. They also found that energy consumption is critical for the success of such a wireless system.
Currently, mainly WLAN is used for this purpose. However, this solution is not power efficient. By using a wireless sensor network (e.g. IEEE 802.15.4 based) and designing protocols tailored to the specific characteristics of the container environment and applications, a longer lifetime and lower costs can be achieved. This is exactly the goal of the MoCo project and its architecture that is being implemented.
Finally, also the following two patents are worth mentioning. In , a method for tracking containers using a low-rate wireless personal area network is proposed. The devices will transmit the GPS-recorded, environmental parameter data and sensory reading data to a control station of the cargo vessel through a local area network on the cargo vessel. In our architecture, we do not use a local area network on the cargo vessel. In , a method for optimizing power consumption of container tracking devices through mesh networks is proposed. Tracking devices form a mesh network to the edge server installed on the vessel. Again, in our architecture, no infrastructure is required on the vessel.
2.2. MoCo smart container system architecture
Container communication types and their goals and challenges
Communication between MoCo device and optional cargo sensors in the container
Reliable, energy efficient, self-organizing, secure
Communication between 3D stacked containers + between container and a portable MoCo reader
Reliable, energy efficient, self-organizing, secure
Communication between the inter-container network and the external world using gateway functionality (+ between container and MoCo Router, using the PAN)
Optimal (best gateway), reliable, energy efficient, self-organizing, secure and evoking a minimum on roaming costs
2.3. The process
In this section, we will briefly summarize the container monitoring process as determined in the MoCo project. When a container is stored empty, its MoCo Device will daily report about its position and battery level according to a fixed Universal Time Coordinated (UTC) time (e.g. 12:00 UTC time). This way, neighbouring containers will all transmit around the same time and communication can be more easily optimized. This status is called REST mode. When the container is stuffed, its doors are closed and a MoCo Reader will send a trigger, putting the MoCo Device in Secured Transport Mode (STP mode). From now on, the MoCo Device will send 2-hourly status updates and reports of optional sensors attached to the cargo, again according to UTC time. In addition, it will immediately report about any critical event that occurs. Finally, there is an optional mode called Secured Vessel Mode (SVE mode). By sending a trigger from a MoCo Router to a MoCo Device upon loading the container in the vessel, the MoCo Device can go to energy-saving mode, where the 802.15.4 radio is disabled, an internal clock is scheduled and no status updates are sent until the device wakes up again.
2.4. Analysis of the process from a MAC layer point of view
From the above description, it is clear that to realize this use case, we have to deal with a complex system of lightweight and mobile devices with stringent energy requirements and varying requirements for the MAC layer. From a research point of view, this imposes many challenges to the design of an efficient MAC protocol for the 802.15.4 radio. In the remainder of this article, we will identify the problems in designing an efficient MAC protocol for this use case and present a generic approach that fulfils our needs and that can also be deployed in a broader context.
The smart container monitoring process described in Section 2 has revealed the need for a generic and flexible MAC layer that can deal with these changing requirements over time. It is quite clear that a single MAC protocol cannot fulfil all the requirements imposed by our use case. For example, in , real-life performance evaluation of WSN protocol combinations has shown that, depending on the traffic pattern and the packet interval, a given combination of MAC and routing is better under certain circumstances and can outperform another combination. The fact that so many MAC protocols  exist is also a clear indication that one MAC does not fit for all kinds of applications, network conditions or hardware profiles.
Bachir et al.  give an excellent overview of the MAC essentials: a contention-based protocol, like CSMA, does not rely on a central entity and is robust to node mobility, which makes it intuitively a good candidate for networks with mobility and dynamicity, but suffers from degraded performance when the traffic load increases. In contrast, TDMA schemes have some shortcomings resulting from their dependency on network topology and strict time synchronization. This would require large overheads in the smart container use case. Unsurprisingly, there exist some protocols like Arisha  where the sink assigns slots to all the nodes or PEDAMACS  where the sink gathers information during the setup phase and calculates a global scheduling. In the latter, the traffic pattern is always convergecast. In our use case, we have identified other traffic patterns, so once again: one MAC does not fit all our goals.
The presented use case clearly needs a novel approach for designing a MAC. Often a MAC protocol is designed specifically for one application. From our use case, we are strengthened in our belief that it is time to move away from a dependence on classic monolithic MAC protocols. Therefore, we have designed PluralisMAC. This is a generic multi-MAC framework for heterogeneous, multiservice wireless networks. Our container monitoring use case has inspired the design of this framework, but we want to emphasize that it should be clear that it can be used in a much broader context where mobile and lightweight devices are involved. PluralisMAC has the following design goals:
Provide extensible MAC primitives: Most MAC protocols share a common set of singular MAC primitives (e.g. DATA, ACK, BEACON, RTS, CTS, preamble, etc.) used for transmitting data and control frames. These primitives have to be provided by the framework in order to improve reusability, to reduce the memory footprint and to reduce the chances of bugs. Composed primitives (e.g. RTS-CTS-DATA-ACK, preamble-DATA, etc.) are a combination of singular MAC primitives. This way MAC protocols can be more easily designed, since they do not have to implement the primitives themselves. Of course, the set of MAC primitives has to be extensible in order to be future proof.
Support dynamic switching of MAC strategies: We have expressed the need for multiple MAC strategies (even on one node) previously. PluralisMAC must work well with many WSN deployments under dynamic contexts. PluralisMAC should allow fast development and dynamic addition (plug-in) of MAC solutions for (future) use cases and new environments. Therefore, we have introduced a new concept, maclets. A maclet is the short name for a MAC strategy. A maclet can choose MAC primitives and PHY settings (e.g. the sleep scheme, transmit power, etc.). Our framework allows that the application expresses certain requirements (e.g. maximum hop-by-hop latency of the messages) for which PluralisMAC will activate the maclet that provides these application requirements.
Provide generic neighbour monitoring and neighbour filtering: Neighbour management is a crucial task of many MAC protocols in order to increase efficiency and reliability. Neighbourhood control can be used to filter a good subset of neighbours based on network conditions (e.g. Link Quality Indicator or Received Signal Strength Indication--RSSI), neighbour information (e.g. remaining energy, network ID, etc.), topology constraints and/or application requirements. Often the same information is retrieved and processed. Providing generic neighbour monitoring and filtering at an architectural level can improve reusability. Moreover, because the same information is only processed once we can even reduce processing delay.
Backward compatible and future proof: It is important that existing MAC implementations can communicate with the maclets, and that it will be easy to implement future MAC protocols. For example, the IEEE 802.15.4-2006 is backward compatible to the 2003 revision. Each revision typically adds new functionalities or primitives. Note that over-the-air programming is out of scope of this article. Protocols for reprogramming wireless nodes via the PAN interface are discussed in [18–20]. In our use case, firmware upgrades of MoCo Devices and MoCo Routers can be done via the WAN connection.
Provide a research platform for MAC designers: By providing a set of shared primitives and a generic neighbour framework, different MAC designs can be compared with each other. This will yield a fairer comparison of MAC protocols because the same implementation of primitives for a specific implementation of the radio driver is used.
5.1. Multi-MAC framework
5.1.1. Primitives executor
The primitives executor contains the implementation of the various MAC primitives (e.g. data frames, control frames, etc.) and offers also the supported PHY primitives of the HAL (e.g. turn off the radio, wake up, set transmit power, set channel, etc.). Since each MAC protocol uses (some of) these primitives anyway, it makes sense to implement them once instead of multiple times. This way, each primitive implementation will be less prone to errors.
Singular MAC primitives
Unicast or broadcast
Ack request, clear channel assessment, retries, channel, transmit power
Channel, transmit power
Channel, transmit power
RTS (request to send)
Unicast or broadcast
Channel, transmit power
CTS (clear to send)
Unicasts or broadcast
Channel, transmit power
The primitives executor also uses the interface offered by the HAL. This includes turning on/off the radio and setting the channel, the transmit power, back off intervals for CCA and the node identifier.
By providing the primitives, the implementation of a MAC design is simplified and therefore we call it maclets (by analogy with "applet"). In a maclet, a MAC designer chooses the primitives that have to be used on a per-packet basis (if the primitive they want is not available, it is possible to implement it in the primitives executor). Either a static design is implemented or a dynamic design that can be influenced by the application state (e.g. maximum required hop-by-hop latency), or other context information (e.g. type of power source). A maclet must add metadata to the packet, so that the primitives executor knows what to do. The maclet still determines when to start the execution of a primitive.
A maclet can be created that will try (we say try, because it is hard to guarantee Quality of Service in a wireless system) to ensure for example a maximum hop-by-hop latency (e.g. 1000 ms). This could be asynchronous or synchronous. The latter is possible if the MAC designer implements a time synchronization protocol. It is possible to set timestamps in outgoing packets when the transmission has already started, and to set timestamps for incoming packets. These timestamps are added to the metadata.
Each maclet could do neighbour discovery, or a shared neighbour discovery maclet can be created. Typically, neighbour discovery is done during the start-up phase of a network, or if the number of available neighbours drops below a certain threshold. Maintaining up-to-date neighbour information can be done during the execution of any maclet, and is handled by the NMF.
Since one MAC protocol does not fit all requirements, it is possible to offer multiple maclets. Each maclet knows for what kind of applications (e.g. low latency, high reliability, etc.), network conditions (e.g. a dense network) and hardware profiles (e.g. battery powered, energy harvester, etc.) it offers the most optimal medium access solution. First, the maclets will send a registration message containing this information. Next, the best maclet to process a given packet from a higher layer will be selected. This can be based on context information (if available) or a fixed schedule can be chosen. Each maclet can be started, paused, restarted or stopped. When a maclet is paused or stopped, it must cancel any ongoing transmission and the MAC designer can choose to put the radio in sleep mode or receive mode. Since most sensor nodes have only one radio, only one maclet can be activated at the time. If more radios are present, it is possible to assign a maclet to each radio (this will require a simple extension of the multi-maclet selector).
Metadata that can be filled in by the PluralisMAC modules and the radio driver
The identifier of the module that requested a free entry in the queue
The identifier of the module that is busy processing the entry
The identifier of the next module that must process this entry
A handle that is used if more than one queue is present in the stack (e.g. IDRA queue) so that we can match entries
Length of the payload. Must be updated if a MAC header is added
If set to FALSE, a default transmit power will be used. Otherwise "TransmitPower" will be used
The transmit power for sending packets
If set to FALSE, a default channel will be used. Otherwise, "Channel" will be used
The channel on which the packet has to be sent
If set to FALSE, CCA is not used. Otherwise, CCAmode and backoffInformation is used for the clear channel assessment
The CCA mode (cfr. IEEE 802.15.4 standard)
Contains initial backoff and congestion backoff
The timestamp set when a packet is received
The timings for the sleep/wakeup schedule
Received Signal Strength Indicator
Link Quality Indicator
If set to FALSE, the crc was not correct
The identifier of the maclet that must process this packet
The chosen primitive that needs to be executed for this packet
The next hop address determined by the routing/forwarding layer
5.2. Neighbour management framework
5.2.1. Neighbour controller
Neighbour controller interface
FilterResult_t processPacket(uint16_t neighbourAddress, uint8_t ownerID, uint8_t length, void*packet)
Mac address of the neighbour
Owner of the packet. This can be a MAC protocol or a higher layer module. A protocol has to add collectors, aggregators and filters for its specific ownerID in order to process packets
Length of the packet pointer
Pointer to the packet or a part of the packet. Because a packet is only processed by specific owners, the packet formatting is always known in advance
Returns the result of the filters executed for the ownerID. If no filters are executed, the result will be SUCCESS
5.2.2. Neighbour repository
The Neighbour Repository is designed so that we can have multiple access levels for neighbours. The different access levels define the modules that can view, change and remove neighbour information. The access levels are organized in a hierarchical manner so that every access level exactly has one predecessor and one successor. With the use of access levels we can create different views on the neighbour repository. This feature makes it possible to shield certain neighbours from higher layers. This can be useful when considering the case where a MAC protocol has an always on neighbour discovery period and routing beacons are aggregated with MAC beacons. This could yield to a situation where a routing protocol chooses a neighbour as next hop for a certain destination but the MAC protocol does not create a communication scheme with this neighbour, for instance a TDMA protocol does not assign a slot for this neighbour. When we are able to shield those neighbours from the higher layers, a MAC protocol can still collect information without influencing the behaviour of higher layer modules.
Currently, we have three different access levels: Monitored, Enabled and Activated. A neighbour is always added in the monitored state by the Neighbour Controller. If a neighbour passes the neighbour filter checks, the Neighbour Controller changes its state to enabled. Note that a filter can also enable a neighbour by default (this will be the common case for most MAC protocols). A MAC protocol activates a neighbour when it has negotiated a communication strategy (e.g. assigned a slot for it in the previous example).
5.2.3. Neighbour monitor
The Neighbour Monitor is in essence an empty shell filled up with functions from now on referred to as collectors and aggregators. The collectors and aggregators are provided by the different protocols of the system, identified by a protocol owner id. The Neighbour Monitor only executes collectors and aggregators for a specific owner id when it processes packets. Collectors retrieve directly accessible parameters from packets or packet metadata like RSSI, timestamps or address information and store it in the neighbour repository. Aggregators combine information retrieved by the collectors in to an aggregated parameter like average RSSI or 'running average over n packets' RSSI and also add it to the neighbour repository.
Although only the collectors and aggregators for a specific owner are executed, they can however use the information stored in the neighbour repository by other collectors and aggregators. Special care has to be taken regarding the execution order of the collectors and aggregators. In the RX- (TX-) chain, a protocol can only use information collected or aggregated by lower (higher) layer modules. This information is available for the developer at design time.
5.2.4. Neighbour filter engine
The Neighbour Filter Engine executes filter rules provided by the protocols of our system. Again only filter rules for a specific owner id are executed. The filter owner (designer) is responsible for combining the different filter rules and aggregating the different results into one single return value. If the return value of the filter engine equals to success then the neighbour is activated and the packet is processed further. Otherwise the packet is dropped. This behaviour can easily be adapted however.
Link level duplicate detection is a good example for a filter provided by a MAC protocol. First of all, the MAC protocol designer provides a collector that retrieves the packet id and stores it in the neighbour repository. Secondly, an aggregator adds the previous to last packet id to the neighbour repository. Finally, a filter can check on those two packet ids to determine if the current packet is a duplicate of the previously received packet (of course more packet ids can be stored with another aggregator if one wants to make another duplicate detection filter). In another example, collectors are used for storing RSSI and a packet counter, and an aggregator is used to determine the average RSSI in order to build an RSSI threshold filter.
One of the major goals of PluralisMAC is the ability to evaluate different MAC protocols in realistic use cases and realistic conditions. Our use case presented in Section 2, for which we build a proof-of-concept, is a perfect candidate. In this section, we will give a brief explanation of the different tools we have used to test PluralisMAC and to build our prototype system.
6.1. w-iLab.t testbed
Central management server: The server is responsible for managing experiments and logging test data received during experiments from the DUT into a MySQL database. The server provides a web interface for creating and executing experiments. The web interface can also be used to control certain features of the EE.
EE: The EE can disconnect the USB power from the DUT, and power it with its own regulating voltage source. This enables the EE to emulate the real behaviour of a battery depleting. The current used by the DUT can then be measured with a sample frequency of 10 kHz. Using this approach, we can easily determine the exact power consumption during an experiment. The EE has some General Purpose digital Input/Output pins connected to the DUT. This allows for real-life, real-time digital sensor/actuator emulation. We use it in our prototype system to emulate a reliable clock source for the MoCo Device. The EE is synchronized with the central management server using NTP. In a real-life scenario, a MoCo Device would be equipped with a reliable clock on their UMTS or GPS chip.
iNode: We use the iNode to run a java program that emulates the UMTS connection with the cloud. The java program communicates with the mote over USB using the TinyOS SerialForwarder.
DUT: The Tmote Sky executes the MoCo Device software.
Beside MAC protocols, we also needed an application and other network protocols. For these, we make use of the IDRA framework . IDRA is a network architecture and application platform very suitable for developing L3 protocols and higher layers. IDRA is developed for TinyOS 2.x and written in nesC. It provides generic building blocks like queue management, packet decoding or aggregation on a system level for network protocols and applications. PluralisMAC is designed to work independent of the IDRA framework but for test purposes we have made an integrated solution and provided wrapper layers between PluralisMAC and IDRA. We reused the IDRA version of the Collection Tree Protocol. We also added a simple gateway discovery protocol and an application. As gateway discovery was not the focus of this article we have chosen a fixed device acting as gateway. Other devices will listen for announcements from this device. The application manages the timers for the different stages in the MoCo process, i.e. transmitting and not transmitting. It generates traffic to the gateway and notifies the MAC and network protocols of the application state and requirement changes through the context information module. The application on the gateway forwards the received application data over USB to the java application on the iNode.
It is possible to implement a stable MAC protocol in PluralisMAC.
PluralisMAC can work in an energy efficient manner.
The delay introduced by our system is acceptable.
PluralisMAC is capable of switching MAC protocols.
With this evaluation we do not want to prove that the implemented MAC protocol is the ideal protocol for our use case. In fact the version of LPL that we have implemented in PluralisMAC is a very simple one. No preamble sampling is used and the on duration could be shorter. Moreover, we do not send short preambles but repeat the packet for the length of the LPL sleep interval.
7.1. Proof-of-concept scenario
Based on the use case description in Section 2 we have selected a proof-of-concept scenario that we will use to validate our framework. We consider a network with an increasing number of MoCo Devices. One of these MoCo Devices will announce itself as the gateway (or sink, the used gateway selection algorithm is out of scope) every 2 h. This timing is set according to a UTC time base, which can be obtained via the WAN interface the first time the device is installed. Each MoCo Device knows that data collection is done around UTC 0:00, 2:00, 4:00, etc., in STP mode, and once a day (UTC 0:00) in REST mode. For our proof-of-concept scenario, we focus on the STP mode. We have divided the 2-h timeslot in three periods: first, a long period where the application tolerates a hop-by-hop latency of 30 s (ultra-low duty cycle phase), second, a short (8 s) period in which the MoCo Devices wait for sink announcements (always-on setup phase), and finally a data collection phase of 52 s, in which the application tolerates a hop-by-hop latency of 1 s. This will repeat every 2 h in STP mode. In the ultra-low duty cycle phase, a MoCo Device could need to send a critical event. In reality, this will occur very rarely, because first the MoCo Device will try sending the critical event using its own WAN interface. Only if that fails, then the MoCo Device will ask a neighbouring node to send the critical event using its WAN interface.
During the setup phase, the selected sink will send sink notifications. We take into account a guard time of 1 s (which is five times more than needed according to our calculations) at the start of this phase to compensate the clock drift during 2 h. All the devices can adjust their clock either during the connection with the cloud or because they receive sink notifications with accurate timestamps. After this period, the neighbours either heard the sink notifications, so they know the gateway, or they did not hear a sink notification and will try to use their own WAN interface. In the former case, the MoCo Device will send its monitored data (five packets) to the sink in the data collection period. In the latter case, the node can switch to the ultra-low duty cycle period already.
7.2. Experiment setup
We used five nodes in our experiment: one fixed MoCo Router acting as sink device and four regular MoCo Devices. We chose this specific setup because the main focus is on validating the framework and not on testing protocols. By limiting the number of nodes we could examine the test data more carefully.
During an experiment we gradually increase the number of nodes, going from one regular node and one fixed sink to four regular devices. This way we can measure the influence of increasing density on the workload. This is also the reason why we choose to use a fixed sink device.
Proof of concept time periods and their counterparts in our experiments on the testbed
Ultra-low duty cycle
In the beginning of each report interval, nodes are synchronized by the EE with an interrupt on one of the GPIO pins. This emulates the behaviour of a stable oscillator that would be integrated on the MoCo Device. The synchronization is not perfect but even a good oscillator cannot provide a perfect synchronization on its own. We measured a variance of ± 500 ms. This can be due to several reasons. Note that the trigger for the interrupt generator originates from the w-iLab.t web interface and has to be processed by the central management server, send over ethernet to the iNode and from the iNode to the EE over USB where the request is processed again.
7.3. Process description
Minimum average RSSI threshold: this information is gathered by the NMF. By using the NMF, we automatically include RSSI information from duplicate packets received from this neighbour.
Minimum number of hops to the sink.
After 8 s every node should have found a sink device and starts the data collection period. In the data collection period, an LPL sleep interval of 1 s is maintained. This information is automatically deducted from the application requirements and stored in the context information module. Using the context information module makes it possible to reuse our MAC protocol for other applications with different requirements. During this period, the regular devices send six packets to the sink device. Because we use LPL, we actually keep repeating the same packet for the duration of the LPL sleep interval or until the packet is acknowledged. The regular nodes have 52 s to transmit their data.
After the data collection period, the transmitting state is finished and the nodes fall back to an ultra-low power state. In this state, we maintain an LPL sleep interval of 30 s. This value is mainly deducted from the use case where the main goal is to save energy. We still need to maintain a duty cycle because we have to be able to receive triggers from MoCo Routers or MoCo Readers. For test purposes, we let a random node send one packet to the sink in this period.
7.4.1. Delay measurements
Delay measurements of PluralisMAC
Measured delay (ms)
Unicast transmit processing delay in ultra-low duty cycle period
Unicast receive processing delay
Unicast transmit processing delay in data collection period
Broadcast transmit processing delay in always-on setup period
Broadcast receive processing delay in always-on setup period
Processing delay NMF
Reliability measurements of PluralisMAC
Packets lost per stage
Unicast reliability in ultra-low duty cycle period
Unicast reliability in data collection period for two nodes
Unicast reliability in data collection period for greater than two nodes
Broadcast reliability in always-on setup period
7.4.3. Energy consumption
Average current consumption (mA) for the three periods
Two nodes in network (stage 1)
Five nodes in network (stage 4)
Ultra-low duty cycle
We have proposed a framework that extracts common functionality from MAC protocols (e.g. primitives and neighbour management). This enables reusability and reduces MAC development effort. The λMAC framework  and MultiMAC  are good examples of how MAC protocol development can be simplified by providing generic interfaces for common functionalities, hereby reducing MAC protocols to their essential task, namely performing power control (time management) and deciding when to send.
Several modules are available in λMAC. We will compare them with PluralisMAC modules: (1) The packet layer (responsible for the actual sending/receiving of a packet, radio state changes and CCA) is the radio driver in our architecture. (2) The network time layer (responsible for storage and generation of time-synchronization information) has no counterpart in our architecture. Setting timestamps on received packets or adding timestamps in outgoing packets is done in the radio driver (because this is best done below the MAC layer) and the maclets could implement a time-synchronization protocol. We agree that it should be a general service to the entire application stack. A PluralisMAC time management framework is left for future work, because in our use case we obtain time-synchronization information through the WAN interface. (3) The λMAC module (responsible for time management) has no counterpart in our architecture because we do not require allocating time blocks for transmissions. A PluralisMAC maclet designer has the freedom to design his/her MAC protocol with the primitives we offer (or add their own primitives). If the designer knows that, for example, it can send a reply 200 ms after it has received a message received from an energy-harvested node (because the energy-harvested node needs to harvest some "new" energy to turn the radio in receive mode), there is no limitation in PluralisMAC to initiate another primitive that lasts less than 200 ms. (4) The (de-)multiplexer is like our wrapper and multi-mac selector. (5) Transmission layer (contains the unicast, broadcast and other application-level primitives) is like our primitives, except for the fact that we do not require to request time blocks. Furthermore, we have separated singular MAC primitives and composed MAC primitives.
Multi-MAC, an extension of SoftMAC and MetaMAC, is an adaptive MAC framework (or mediating layer on top of MAC protocols) for cognitive radios that automatically selects between multiple MAC protocols. It does not offer common primitives, but reconfigures and/or selects a MAC layer.
Generic neighbour management has already been addressed in literature. The studies of Langendoen et al.  and Polastre et al.  clearly show the problems that can arise when protocols do not share neighbourhood information. If the selection of a good neighbour differs in the MAC protocol and in the routing protocol (T-Mac and MintRoute ), then this will lead to unexpected behaviour like high packet loss or increasing delays. Polastre et al.  propose the use of a general neighbour table. This is similar to what we do with the neighbour repository but they do not provide the possibility to add generic functions (collectors and aggregators) to collect neighbour information. Neighbours are added to the neighbour table by asking all the network protocols. How to resolving conflicts is not addressed however. We believe that with our filter engine we have a more generic and flexible approach.
Fonseca et al.  proposed a generic 4-bit link estimation that combines information from the physical, MAC and network layer into a 4-bit value. Again this is a good example of the necessity for some sort of generic neighbourhood management but they limit their work to link estimation and provide no flexibility for future extensions. The Link Estimation Exchange Protocol (LEEP)  is another example of generic link layer estimation included in TinyOS. LEEP is an example of an active neighbourhood control protocol because it exchanges bidirectional link information among neighbouring nodes. This feature is not included in the proposed NMF but could be easily integrated when providing the appropriate collectors and aggregators. Active neighbour management will be included in future work.
In this article, we have described the smart container monitoring use case which made clear that multiple MAC strategies were needed to achieve a low-power system able to handle wireless communication with heterogeneous devices. We have presented our generic multi-MAC framework and NMF. We have implemented our architecture in TinyOS and have done experiments on the w-iLab.t testbed. We have shown that our framework works, and it does not introduce a significant overhead (e.g. 4 ms in the receive chain for both the NMF and the multi-MAC framework). We will start to implement more (complex) reference maclets, composed primitives and neighbour filters in the near future and hope that our framework will be used by many MAC designers to implement and test their design on real hardware.
The authors would like to thank IBBT for their advanced testing infrastructure (w-iLab.t), numerous discussions with our colleagues, and Vincent Sercu for his container artwork. This study was partly funded through the IBBT MoCo project.
- IBBT MoCo[http://www.ibbt.be/en/projects/overview-projects/p/detail/moco-2]
- Mahlknecht S, Madani S: On architecture of low power wireless sensor networks for container tracking and monitoring applications, industrial informatics. 5th IEEE International Conference, 2007 2007, 1: 353-358. doi:10.1109/INDIN.2007.4384782Google Scholar
- Schaefer S: Secure trade lane: a sensor network solution for more predictable and more secure container shipments. In Companion To the 21st ACM SIGPLAN Symposium on Object-Oriented Programming Systems, Languages, and Applications OOPSLA '06, Portland, Oregon, USA. ACM, New York; 2006:839-845. doi:10.1145/1176617.1176732View ArticleGoogle Scholar
- Lauf JO, Gollmann D: Monitoring and security of container transports. Proceedings of New Technologies, Mobility and Security (NTMS), Paris 2007. ISBN: 978-1-4020-6270-4 [http://www.sva.tu-harburg.de/joomla/index.php/research/masc]Google Scholar
- Sung J, Lopez TS, Kim D: The EPC sensor network for RFID and WSN integration infrastructure. In Proceedings of the Fifth IEEE international Conference on Pervasive Computing and Communications Workshops (PERCOMW). IEEE Computer Society, Washington, DC; 2007:618-621. doi:10.1109/PERCOMW.2007.113Google Scholar
- CSO EPC Global[http://www.epcglobalinc.org/standards]
- Rogoz D, O'Reilly F, Delaney K: Multi-hopping and ad hoc networking for tracking systems. WiSen, 2nd Workshop on Wireless Sensor Networks Research, Ireland 2007. doi:10.1007/978-0-387-46264-6_18Google Scholar
- Jedermann R, Behrens C, Laur R, Lang W: Intelligent containers and sensor networks, approaches to apply autonomous cooperation on systems with limited resources. In Understanding Autonomous Cooperation & Control in Logistics - The Impact on Management, Information and Communication and Material Flow. Edited by: Hülsmann M, Windt K. Springer, Berlin; 2007:365-392. doi:10.1.1.165.1519Google Scholar
- Kim SJ, Deng G, Gupta SKS, Murphy-Hoye M: Intelligent networked containers for enhancing global supply chain security and enabling new commercial value. 3rd International Conference on Communication Systems Software and Middleware and Workshops (COMSWARE 2008) 2008, 662-669. doi:10.1109/COMSWA.2008.4554493Google Scholar
- Kim SJ, Deng G, Gupta SKS, Murphy-Hoye M: Enhancing cargo container security during transportation: a mesh networking based approach, technologies for homeland security. 2008 IEEE Conference on 2008, 90-95. doi:10.1109/THS.2008.4534429Google Scholar
- Binding C, Dolivo FB, Hermann RJ, Husemann D, Schade A: US Patent 7,541,913. 2009.Google Scholar
- Mermet J, Pucci B: US Patent Application 0149028. 2010.Google Scholar
- Vanhie-Van Gerwen J, De Poorter E, Latre B, Moerman I, Demeester P: Real-life performance of protocol combinations for wireless sensor networks. International Conference on, 2010 IEEE International Conference on Sensor Networks, Ubiquitous, and Trustworthy Computing 2010, 189-196. doi:10.1109/SUTC.2010.49Google Scholar
- Langendoen K: The MAC Aphabet Soup served in Wireless Sensor Networks.[http://www.st.ewi.tudelft.nl/~koen/MACsoup]
- Bachir A, Dohler M, Watteyne T, Leung KK: MAC essentials for wireless sensor networks. IEEE Communication Surveys Tutorials 2010, 12(2):222-248. doi:10.1109/SURV.2010.020510.00058View ArticleGoogle Scholar
- Arisha K, Youssef M, Younis M: Energy-aware TDMA-based MAC for sensor networks. In Proceedings of IEEE IMPACCT. New York City, NY; 2002. doi:10.1007/0-306-47720-3_2Google Scholar
- Coleri-Ergen S, Varaiya P: PEDAMACS: power efficient and delay aware medium access protocol for sensor networks. IEEE Trans Mob Comput 2006, 5(7):920-930. doi:10.1109/TMC.2006.100View ArticleGoogle Scholar
- Hagedorn A, Starobinski D, Trachtenberg A: Rateless deluge: over-the-air programming of wireless sensor networks using random linear codes. Proceedings of the 7th Int Conf On Information Processing in Sensor Networks (IPSN) 2008. doi:10.1109/IPSN.2008.9Google Scholar
- Dawson-Haggerty S: NWprog.[http://openwsn.berkeley.edu/browser/tinyos-2.x/tos/lib/net/blip/doc/README-NWPROG?rev=620]
- Hughes D, Thoelen K, Horré W, Matthys N, Del Cid J, Michiels S, Huygens C, Joosen W: Building wireless sensor applications using LooCI. Int J Mob Comput Multim Commun 2010, 2(4):38-64.Google Scholar
- OpenWSN: Implementing the Internet of Things[http://openwsn.berkeley.edu]
- w-iLab.t Office (Wireless Lab)[http://ilabt.ibbt.be]
- E De Poorter, E Troubleyn, I Moerman, P Demeester, IDRA: a flexible system architecture for next-generation wireless sensor networks, Wirel Netw, Springer, 7(6): pp. 1423–1440 (August 2011). doi:10.1007/s11276-011-0356-5View ArticleGoogle Scholar
- Parker T, Halkes G, Bezemer M, Langendoen K: The lambda-MAC framework: redefining MAC protocols for wireless sensor networks. In Wirel Netw. Volume 16. Springer; 2010:2013-2029. doi:10.1007/s11276-010-0241-7Google Scholar
- Doerr C, Neufeld M, Fifield J, Weingart T, Sicker D, Grunwald D: MultiMAC--an adaptive MAC framework for dynamic radio networking. IEEE DYSPAN 2005, 548-555. doi:10.1109/DYSPAN.2005.1542668Google Scholar
- Langendoen K, Baggio A, Visser O: Murphy loves potatoes: experiences from a pilot sensor network deployment in precision agriculture. IEEE Parallel and Distributed Processing Symposium 2006. doi:10.1109/IPDPS.2006.1639412Google Scholar
- Polastre J, Hui J, Levis P, Zhao J, Culler D, Shenker S, Stoica I: Unifying link abstraction for wireless sensor networks. In 3rd ACM Conf on Embedded Networked Sensor Systems. San Diego, CA; 2005. doi:10.1145/1098918.1098928Google Scholar
- Fonseca R, Gnawali O, Jamieson K, Levis P: Four bit wireless link estimation. Proceedings of the 6th Workshop on Hot Topics in Networks (HotNets VI) 2007. doi:10.1.1.74.2030Google Scholar
- Gnawali O: TinyOS Extension Protocol 124, The Link Estimation Exchange Protocol (LEEP).[http://www.tinyos.net/tinyos-2.x/doc/txt/tep124.txt]
This article is published under license to BioMed Central Ltd. This is an Open Access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.