After determining that inter-container communication was indeed feasible, the next step was the design of the system architecture. This section gives a high-level overview of the different components (architectural entities), processes, and novel sensor communication solutions.
Component and connection overview
In Fig. 10, a high-level overview of the general architecture is shown. The main components of the system are depicted in part a of Fig. 10. The tracking device (brown oval) is a lightweight battery-powered device that will be mounted on a container and will become an unbreakable part of that container. In addition, it is connected via a secured wired link to a door sensor (light brown circle) capable of monitoring opening and closing of container doors. The tracking device is equipped with a cellular radio for direct connectivity with the central ICT system, a GPS for obtaining the containers location, and a IEEE-802.15.4 radio for short-range, low-power communication. The latter enables to create an ad hoc network with neighboring tracking devices and with sensors inside the container (blue circle) that monitor the status of the cargo.
Beside the tracking device, there are also two types of special devices: (1) an optional MoCo router (light blue trapeze), installed on key infrastructure for container handling such as cranes, boats, and lorries, and (2) a MoCo reader (light blue trapeze with brown oval inside) integrated in the handhelds (e.g., smartphone) of container operators. Both devices serve a special role. The MoCo router is mains-powered and can be used as gateway for tracking devices. It enables to collect tracking reports and monitoring data in an energy efficient manner (i.e., by avoiding the usage of the cellular radio). The MoCo reader is used by container operators to interface with the tracking device. For instance, when a container is loaded and sealed, a container operator can activate the door sensor, and conversely, when a container is unloaded, an operator can disable the door sensor.
The tracking device will periodically report status information (position, battery status, etc.) to the Cloud, will inform about critical events (e.g., opening of doors after sealing), and, optionally, will send data collected by sensors attached to the cargo consisting of sensitive and high-value products (e.g., temperature, toxic gasses). Listing 1 illustrates the content of periodical reports, comprising 42 bytes in total. It contains the tracking device ID, the container ID, a sequence number, GPS location information, a timestamp, the status of the door sensor (i.e., contact), a msgID, and the state of the tracking device. The state contains the mode of the tracking device (i.e., STP, SVE, or REST) and a substate (i.e., transmitting or not transmitting). The defined states will be explained in detail in Section 4.1.
Part b of Fig. 10 illustrates the different communication types. The sensors attached to the cargo will communicate with the tracking device over IEEE-802.15.4. This is intra-container communication. In order for a tracking device to transmit its status to the central ICT system, several possibilities exist. The device can directly send the data by turning on and using its UMTS/GPRS radio or can forward it over IEEE-802.15.4 to a nearby router, thereby saving energy. This is called extra-container communication. Alternatively, in order to save battery, the tracking device can also transmit the information to neighboring tracking devices, sharing UMTS/GPRS connectivity. This is called inter-container communication. Using these different communication capabilities, the architecture is capable of delivering all information required by customers.
One of the key features for saving energy and reducing (communication) cost that has been incorporated in the architecture is the ability to reduce UMTS/GPRS usage by making use of IEEE-802.15.4 communication (in between tracking devices and with a fixed router). The cost aspect is straightforward. For the energy consumption, the underlying motivation is that UMTS/GPRS communication is much more energy-consuming than IEEE-802.15.4. Each reduction in UMTS/GPRS usage contributes significantly to the energy reduction and lifetime of the tracking device. This will be shown in Section 5. Of course, achieving this reduction will depend on the presence of neighboring devices or routers, which will become more significant with an increasing uptake of the solution.
Process overview
The container monitoring process, illustrated in part a of Fig. 11, was defined taking into account the typical stages found in the logistic transportation chain. This allowed to optimize the communication strategy as much as possible.
When a container is stored empty, its tracking 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, neighboring containers will all transmit around the same time and communication between containers can be more easily optimized: a single tracking device can turn on its UMTS/GPRS radio and share it with other devices. This status is called REST mode.
When the container is stuffed, its doors are sealed and an operator triggers the tracking device to go in Secured Transport Mode (STP mode). This trigger can be sent using a mobile reader or the Cloud. From now on, the tracking device will send 2-hourly (configurable) 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). This mode is initiated when the tracking device receives a trigger from a fixed router, installed on the loading quay, or from the Cloud (when the device connects to the Cloud). After receiving the trigger, the tracking device can go to energy-saving mode, where the IEEE-802.15.4 radio is disabled, an internal clock is scheduled, and no status updates are sent until the device wakes up again. This mode can be used when the container is loaded in a vessel. An energy-efficient backup mechanism ensures that the tracking device will eventually wake up in case something goes wrong.
The different modes can meet the identified monitoring requirements, while at the same time taking care of the energy consumption: most energy is consumed when the container is sealed, less energy is consumed when the container is empty, and least energy can be consumed when the container is on a vessel and cannot be accessed until arrival of the vessel. Also note that at all times, when no UMTS/GPRS or GPS communication is required, the respective modules are turned off.
Communication overview
Based on this general architecture, we have derived a number of scenarios for which communication solutions have been designed, as illustrated in part b of Fig. 11.
The transition between the different modes (REST, STP, and SVE) is depicted at the top of part b in Fig. 11. When a container is sealed for transport, it must go from REST to STP mode. This is done by an operator that sends a trigger using a MoCo reader (type 5). Optionally, in STP mode, intra-container monitoring can take place (type 4, dark red). The sensors inside containers, attached to the cargo, either buffer the (delta) values until the tracking device requests the sensor data (just before report transmission) or transmit the sensed data immediately when a critical threshold was exceeded (type 3). When a container is put on a vessel, the device goes to SVE mode after receiving a trigger from a MoCo router (type 6). This results in the device sleeping (type 3, light red) until it is woken up, triggering it to go back to STP mode.
As mentioned, devices report X-hourly in REST and STP mode according to a specified UTC time. Therefore, we can either have a group of devices not transmitting data (type 1, dark green) or a group of devices transmitting data (type 2, light green). When in type 2, there is first a transmission setup period where devices get the opportunity to select a traffic device as gateway, collect the reports at this gateway, and, eventually, forward the collected reports to the cloud. This is illustrated at the bottom of part b in Fig. 11.
Making a distinction between a non-transmitting period and a transmitting period enables us to take additional energy-saving precautions in the non-transmitting period. Further, for all communication with the outside world, a communication hierarchy has been identified, specifying that IEEE-802.15.4 technology must be preferred over UMTS/GPRS technology and, when using UMTS/GPRS technology, this must be done in such a way to reduce roaming cost and energy consumption.
Tailored sensor communication solutions
Based on the previous specifications, a communication architecture and communication protocols have been designed for the tracking device (and router/reader). The architecture and protocols aim to implement the specs in an energy-efficient way. To this end, several novel and innovative features have been incorporated in the architecture, mostly related to the inter-container communication over the IEEE 802.15.4 radio. We will only highlight the most important components.
In Fig. 12, this high-level communication architecture of the MoCo device is presented. It consists of several building blocks dealing with the MoCo process logic, UMTS, and 8021.5.4 communication and all required networking functionality. The components are implemented on a board running an TinyOS. This board has a 802.15.4 radio interface on top of which a hardware abstraction layer is provided in order to make use of the underlying hardware functionality. Similarly, a UMTS/GPRS module and corresponding API provide direct connectivity to the outside world. In the following paragraphs, the different building blocks, together with their role in the system, will be briefly explained and some specific innovative features will be emphasized.
The Device Process Logic component is the heart of the application running on the embedded device. It implements and executes all process logic such as the mode changes of the tracking device, the behavior within a specific mode, and changes in status. As such, this component will interact with many other modules. All specific information such as report intervals, duty cycles, and timing values are captured in a device profile. This profile can be updated, upon which other components can be informed and reconfigured.
Just above the HAL and IEEE-802.15.4 radio, we have PluralisMAC [15]. From a MAC layer point of view (IEEE 802.15.4 MAC), the specifications reveal that in the non-transmitting period (REST or STP mode), the radio should sleep as much as possible, while remaining capable of receiving triggers or sending a critical event. In the transmitting period (REST or STP mode), data packets should be sent as efficiently and reliably as possible. In SVE mode, it should be disabled completely. Thisn results in completely different requirements on the IEEE-802.15.4 MAC layer and thus requires different MAC strategies and scheduling. Current MAC designs are monolithic, and PluralisMAC provides an innovative solution. It supports different MAC strategies on a single device through reuse and intelligent combination of primitives (e.g., data, ACK, BEACON, RST) into maclets. For example, low-power listening, beacon MAC, and always off are supported, which are tailored to the non-transmitting period, transmitting period, and SVE mode respectively.
At the routing/networking layer, we have the Dispatcher, Gateway Selector and Gateway Setup, and Forwarding components. The role of the Dispatcher is simple. It delivers incoming packets from the MAC layer to the appropriate module. In the other direction, it handles outgoing packets that need to be transmitted over the IEEE 802.15.4 radio interface. The Gateway Selector is an important component that implements the gateway selection protocol. Through this component, it is possible to select a gateway between neighboring tracking devices. Figure 13 illustrates the gateway selection algorithm by means of a simplified flowchart. The novel low-overhead algorithm allows selecting the best (= device with most remaining energy) gateway in a 1-hop neighborhood based on a gateway willingness metric. Apart from the achieved reduction in energy consumption through UMTS/GPRS sharing, the protocol strives to achieve fairness in energy consumption. Basically, it constitutes of two stages: (1) check if another node is announcing itself as a gateway, and (2) if no other nodes are announcing, start announcing yourself as a gateway. The mechanism works in such a way that the node with the highest energy starts announcing first. If the clock drift is acceptable, the energy consumed during this procedure is minimal. In the first stage, only periodical checks for medium activity (LPL) are required and, optionally, periodically send beacons to other nodes in the second stage. The gateway selection is limited to the 1-hop neighborhood in order to make the algorithm robust. We preferred using an algorithm that is simple instead of an algorithm that searches the most optimal gateway. Searching such an optimal gateway would consume a lot of energy, and introducing multihop communication would make the algorithm more complex and would introduce more link errors.
Once a gateway has been selected, the Gateway Setup and Forwarding component in the involved MoCo devices will establish a correct routing path to the selected gateway (which is either a router or another tracking device). When a device use another device (or router) as gateway, the selected gateway will receive the reports from that devices. As said, the Dispatcher delivers incoming packets to the appropriate module. For example, incoming triggers from a reader of router are delivered to the Trigger Handler component. This component will process the trigger (packet processing, acknowledging) and will then inform the Device Process Logic about the type of trigger that needs to be executed. It is also possible that data from intra-container sensors is received. This data is delivered to the Sensor Data Collection component, which stores it until the next transmission moment where the data can be delivered to the Cloud. When a device use another device (or router) as gateway, the selected gateway will receive the reports from that devices. These reports are delivered to the Report Handler, which stores them until the next transmission moment where the data can be delivered to the Cloud by the Cloud Middleware component. This component is responsible for the preparation of all data that needs to be transmitted to the Cloud over the UMTS/GPRS interface of that device. This data not only includes its own report but can also include collected sensor data or reports from neighboring devices that have selected this device as their gateway.
The architecture also contains several I/O modules that provide interfaces to mostly external hardware components such as the GPS module, GSM/UMTS module, door sensor, and battery. The nodes are synchronized in two ways: (a) directly when retrieving the GPS location and (b) indirectly via the 802.15.4 inter-container network (in this case, the GPS time of the 802.15.4 gateway is added in the acknowledgement of the reports send through the gateway). The gateway selection algorithm use guard times that take into account the clock drift on the node.