Keywords

1 Introduction

Mobile sensing systems are a new type of flexible sensor networks that employ mobile devices such as an unmanned aerial vehicle (UAV), a robot, etc. [1–3]. As a direct transmission from mobile devices is limited, mobile devices require a platform network to extend the measurement area. Traditionally, sensor network systems use multi-hop communication to extend a network area [4–6]. Platform networks also employ multi-hop communication to cover a network area, and should operate on low power devices [7–9]. Therefore, requirements for platform networks for mobile sensing systems are flexible data collection and low power operation [10–12].

Since an important function in sensor networks is a long life operation with small capacity battery, almost all systems require an efficient data collection scheme with low power consumption. The schemes are generally classified into a media access layer approach [13, 14] and a routing layer approach [15, 16]. A media access layer approach typically employs a special frame format to realize a sleep operation for turning off all circuits on a device. A routing layer approach for sensor networks sometimes employs a tree-based route because a sink device is an only device for data collection. Traditional sensor networks assume a fixed and static devices for data collection. Therefore, a system requires various numbers of sensor devices to cover a whole sensing area.

Mobile sensor networks are extended sensor networks where some devices can move to a measurement location. According to a flexible mobility of sensor devices, a fewer number of devices can cover a whole measurement area comparing to a traditional sensor network [17, 18]. Some researchers have considered efficient data gathering scheme to realize efficient resource usages. On the contrary, an implementation of these schemes on real hardwares is difficult due to the limitation of a computational resource and overhead of an optimization for data collection.

This paper proposes a simple mobile sensor network system for practical wireless system on chips (SoC). The proposed system consists of an original media access control scheme and an original tree-based routing to reduce required hardware resource and to realize a low power operation. We have developed our original communication protocol on a SoC to show the feasibility of the proposed protocol on real devices. The evaluation results show that the proposed protocol can work on the real SoC hardware to realize a mobile sensor network system.

2 Mobile Sensing Platform

Figure 1 shows the overview of the mobile sensing platform. The platform consists of a sink device, relay devices, mobile sensor devices. The sink device is a fixed device in a sensor network, and collects measured information from mobile sensor devices. The relay devices are a fixed device, and construct a route to the sink device with a routing protocol. They also transfer measured information from mobile sensor devices to the sink device. The mobile sensor devices are a mobile device such as a robot, UAV, etc. They have a few sensors to measure environment or specific objects, and transfer measured information to a neighbor relay device.

Fig. 1
figure 1

Mobile sensing platform

Full size image

Typical sensor network systems construct a route from all sensor devices to a sink device. The constructed route is usually fixed because all devices do not move in a short period. On the contrary, mobile sensor devices frequently move in a sensing area in the mobile sensing platform. Therefore, the mobile sensing platform requires a new route management scheme for mobile sensor devices. In the proposed platform, relay devices construct a tree based route to a sink device because they are fixed in a sensing area. Mobile sensor devices have no route to a sink device and only ask a neighbor relay device to transfer its own measured information. The benefit of the proposed scheme is to reduce control messages for the routing management and to reduce power consumption for updating routing information.

2.1 Media Access Control

Sensor networks usually require low power operation because each sensor devices work by a battery power. Relay devices in the mobile sensing platform also require low power consumption due to the same reason. It is common knowledge that a deep sleep operation is the best method to reduce consumed power in a micro-processor chip. Therefore, media access control also considers a deep sleep period to turn off circuits on a micro-processor chip. Additionally, multi-hop networks usually suffer from interference from simultaneous wireless transmissions because neighbor relay devices may transmit a signal due to the hidden node problem. As a result, media access control should assign a specific period for neighbor relay devices to avoid interference among relay devices.

Fig. 2
figure 2

Frame structure

Full size image

Figure 2 shows the proposed frame structure. The frame structure consists of some slots for specific purposes: time synchronization, route management, sensing data collection, and data forwarding. The proposed frame structure indicates a specific communication period depending on the purposes or hop count from the sink device. Therefore, relay devices can easily sleep according to the frame structure. Additionally, neighbor devices with a different hop count transmit a signal in a different period to avoid interference. The following is the detail of each slot.

  • Time synchronization slot

    Time synchronization scheme is a key function to maintain timing among a sensor network to realize a sleep operation for reducing consumed power. Typical quartz on a microcomputer board is not sufficiently accurate to maintain high-precision time for a frame synchronization. The proposed scheme employs a time synchronization scheme between nearby devices. Each device has two time information: absolute time and relative time in a frame. The absolute time starts when a device boots up. The relative time repeats in a frame period. An upstream device calculates relative time in a frame by checking a current time in the time synchronization slot. It transmits a time synchronization message to downstream devices. The time synchronization message includes relative time. Therefore, the downstream devices can regulate the relative time according to the relative time in the time synchronization message.

  • Route management slots

    Relay devices are almost fixed device in the proposed system. Therefore, routes from each relay device to a sink device are almost static. The proposed scheme assigns a special period for a route management to decrease power consumption. As a result, each relay device can sleep during the route management slots when it has an available route. The route management slots consist of three slots: a route request slot, a route reply slot, and a route construction slot. The route request slot is a special period to request a new route to neighbor devices. The route reply slot is a special period to inform an available route information to the requested device. The route construction slot is a period to construct a route between an upstream device and the requested device in a three-way handshake procedure.

  • Sensing data collection slot

    Mobile sensor devices move in a sensing area. Therefore, reconstructing of a route to the sink device is a considerable overhead. The proposed frame assigns a unique time slot for collecting sensing data. All relay devices listen the channel during the sensing data collection slot to receive a data message from neighbor mobile sensor devices. The received data messages are forward to the sink device.

  • Data forwarding slots

    Sensor network systems typically employ a large number of relay devices. Therefore, transmission range of each relay device is typically overlapped. As consequence, signal interference among neighbor relay devices may deteriorate communication performance. The proposed frame assigns data transmission slot and acknowledgement slot in the data forwarding slots, and divides each slot to subslots for each hop count from the sink device. As a result, relay devices, where their hop count is different, transmit a data message in different timing.

2.2 Routing Control

A routing control is an important function to realize a multi-hop network. Practical sensor networks require low-power operation for hardware devices to realize a long lifetime. Therefore, almost all hardware devices support a deep sleep mode that realizes a quite low-power operation. Additionally, they have a limited size of memory space to decrease power consumption. As a result, typical hardware devices require a simple routing control mechanism to implement a routing protocol.

The proposed routing protocol realizes a tree based route from relay devices to a sink device because all relay devices forward a data message to the sink device. Each relay device can construct a route to its own upstream device by exchanging routing control messages. Each routing control message is presented as follows.

2.3 Routing Control Messages

The proposed routing protocol uses five types of routing control messages: route request message, route reply message, route construction request message, route construction reply message, and route construction acknowledgement message.

  • Route request

    Route request(RREQ) control messages are to find a device with a route to a sink device. Downstream devices without a route broadcast a RREQ message to neighbor upstream devices. The message includes a source address of a device.

  • Route reply

    Route reply(RREP) control messages are to inform an available route to a sink device to a downstream device that requests a route. Upstream devices with an available route can transmit a RREP message to a requested downstream device. The message includes a destination address, a source address, and a hop count to a sink device. The requested downstream device can select a shortest route by evaluating the hop count in a RREP message.

  • Route construction request

    Route construction request(RCREQ) messages are to request a route construction to an upper device. A downstream device selects an adequate upstream device based on a hop count, and transmits a RCREQ message to the selected upstream device. The upstream device that receives the RCREQ message starts a route construction process. The message includes a destination address and a source address.

  • Route construction reply

    Route construction reply(RCREP) control messages are to inform the start of the route construction process to the downstream device. The upstream device transmits a RCREP message to the requested downstream device. The message includes a destination address and a source address.

  • Route construction acknowledgement

    Route construction acknowledgement(RCACK) control messages are to complete the route construction process to the upstream device. The downstream device transmits a RCACK message to the own upstream device. The message includes a destination address and a source address.

2.4 Routing Procedures

Figure 3 shows the route construction procedures for one-hop devices in the proposed protocol. The figure assumes that a sensor network consists of a sink device and five relay devices.

In a route request slot, relay devices without an available route try to find a route to the sink device. In Fig. 3i, relay device R2 and R3 transmit a RREQ message to neighbor devices. In this situation, the sink device is an only device with an available route.

Fig. 3
figure 3

Route construction procedures. i Route request slot ii Route reply slot iii Route construction slot

Full size image
Fig. 4
figure 4

Routing procedures for each hop count. i Ist frame ii 2nd frame

Full size image
Fig. 5
figure 5

Data transmission procedures. i Mobile sensors ii Relay at 2 Hop device iii Acknowledgment for 2 Hop devices iv Relay at 2 hop devices v Acknowledgment for 1 hop devices

Full size image

In a route reply slot, a device with an available route to the sink device reply a route reply message to the requested devices. In Fig. 3ii, the sink device replies a RREP message to relay device R2 and R3. The RREP message contains the address of R2 or R3 as a destination address, the address of the sink device as a source address, and 0 as a hop count to a sink device.

In a route construction slot, a device that finds an available route constructs a route to the sink device. In Fig. 3iii, relay device R2 and R3 transmit a RCREQ message to the sink device. The sink device replies a RCREP message to relay device R2 and R3. Finally, relay device R2 and R3 reply a RCACK message to the sink device. The proposed protocol can build the routes from relay device R2 and R3 to the sink device through the three-way handshake procedure.

Figure 4 shows the routing procedures for each hop count. The proposed protocol constructs a route hop by hop to reduce a required memory space for routing information. Therefore, the protocol can construct a route for one hop during one frame period. In Fig. 4i, all relay devices transmit a RREQ message to neighbor devices. Therefore, the RREQ message from relay device R2 reaches the sink device, relay device R4 and R5, and the RREQ message from relay device R3 reaches the sink device and relay device R6. Since relay devices R4, R5 and R6 do not have an available route, the sink device replies a RREP message to device R2 and R3. Finally, relay devices R2 and R3 can construct a route during the 1st frame period.

In the second frame period, relay devices R4, R5 and R6 transmit a RREQ message because they do not have any available route. The RREQ messages from relay device R4 and R5 reach relay device R2, and the RREQ message from relay device R6 reaches relay device R3. As a result, relay device R2 replies a RREP message to relay device R4 and R5, and relay device R3 replies a RREP message to relay device R6. Finally, the tree based route from the sink device has been constructed through two frame periods. The proposed protocol constructs a route for one hope during one frame period. As a consequence, it requires a long period to construct a full route from a sink device to all relay devices. On the contrary, it requires relay devices to store neighbor device information to construct a route. Therefore, small size of memory is sufficient to implement the proposed protocol.

2.5 Data Transmission

The proposed protocol classified data and acknowledgement slots to subslots. Subslots are allocated for relay devices according to a hop count from a sink device. Therefore, neighbor relay devices with a different hop count use another subslots to avoid collisions.

Figure 5 shows the example operation of data relaying. The mobile sensor transmits a data message including measured information to neighbor relay devices in the sensing data collection slot. Therefore, all relay devices should listen the wireless channel to receive a data message. In the example, relay device R5 receives a data message from the mobile sensor. Since relay device R5 is a two hop count device, it relays the data message in the subslot for two hop count. Relay device R2 receives a data message from relay device R5 because it knows relay device R5 is the downstream device. It also replies the acknowledgement message to relay device R5 in the acknowledgement subslot for two hop counts. Then, it relays the data message in the data subslot for one hop count. The sink device receives a data message from relay device R2 and replies the acknowledgement message to relay device R2.

Table 1 Specifications of TWE-Lite and Xbee
Full size table

3 Experimental Results

We have implemented the proposed protocol on a system-on-chip (SoC) for radio communication. Table 1 shows the specification of the SoC and Xbee which is a well known wireless module. Xbee typically requires a master micro-computer board such as Arduino. Therefore, additional power is required to work with Xbee in practical implementations. The SoC has a RISC based microcomputer and IEEE 802.15.4 based wireless module. Figure 6 shows the flowchart for the message processing. Table 2 shows the detail parameters for the proposed frame structure. The developer software provides a timer event mechanism and a trigger function for receiving a message. Therefore, the developed software implements the slot based operation with the timer event mechanism to realize a sleep operation. Additionally, it also classified the original messages by using the trigger function for receiving a message.

Fig. 6
figure 6

Flowchart for message processing

Full size image
Table 2 Frame format parameters
Full size table
Fig. 7
figure 7

Device location in experiment

Full size image

We assumed the device location in Fig. 7. We have set up a small sensor network system due to a limitation of an experimental space. The dot lines mean the constructed routes in the experiment. The mobile sensor device moves on the solid line, and transmits data messages to neighbor relay devices. It transmits 122 data messages during the moving of the mobile sensor device. The sink device receives 223 data messages from the network. In the proposed system, a mobile sensor device does not construct a route to a network. Therefore, some relay device receives a same data message from a mobile sensor device. As a result, duplicate data messages may reach a sink device. In the experiment, the sink device can receive 104 unique data messages from the mobile sensor device. Therefore, the arrival rate of each data message is 85 [%] because the developed software does not perform a retransmission for a lost message to evaluate the communication performance. Through the experiment, we can find that the proposed mechanism can implement on typical SoC modules for IEEE 802.15.4 communication. Therefore, the proposed mechanism is a one of a feasible protocol for resource-constrained devices.

4 Conclusion

This paper has developed a new mobile sensing platform employing a tree based sensor network. The mobile sensing platform consists of mobile sensor devices, relay devices, and a sink device. Relay devices can construct a tree based route to the sink device, and can forward data message from mobile sensor devices. We have developed a special software for wireless module System on Chip (SoC) for IEEE 802.15.4. The evaluation results show that our protocol can synchronize timing among relay devices, and can create a tree based route to a sink device. Additionally, they can find that mobile sensor devices inform measured data to a sink device through relay devices.