# A Mobility-Aware Adaptive Duty Cycling Mechanism for Tracking Objects during Tunnel Excavation
## 2 Background and Related Work
### Adaptive Duty Cycling Based on Mobility  
There are many duty cycling schemes considering the mobility of sensor nodes and adjusting their schedule or hands-off request timing adaptively as the speed of the mobility nodes. The mobility-aware MAC protocol for sensor networks (MS-MAC) [17] was proposed to support the mobility of sensor nodes. In MS-MAC, stationary nodes work like S-MAC and mobile nodes work like IEEE802.11 [18]. Each node periodically broadcasts its schedule in a SYNC message to maintain synchronization and measures the RSSI of its neighbors. If there is a change of RSSI from a neighbor, it means that the neighbor or the node is moving and the speed can be estimated. This mobility information is included in the SYNC message and neighbors that receive the message increase the frequency of the synchronization period to maintain connection with the moving node. Mobility adaptive collision free MAC for mobile sensor networks (MMAC) [19] was based on time division scheduling and designed to be suitable for both high and low mobility environments. At the beginning of each frame, all the nodes predict their position in the next frame and send this estimated location information to their cluster head. The cluster heads that never go to sleep collect the estimated location information of all member nodes and broadcast collected information to their member nodes. Each member node suggests its frame duration based on the collected location information and sends its decision to the cluster head. The cluster head adjusts according to member node requests as shown in Figure 2.  
Mobile Cluster MAC (MCMAC) [20] was proposed to optimize for mobile nodes that travel in a cluster (i.e., without inter-cluster mobility). MCMAC classifies sensor nodes into static and mobile clusters. Because the slot assignment method is different for static and mobile clusters, the active period is divided into Static Active Slots (SAS) and Mobile Cluster Slots (MCS). The SAS follows scheduling based communication and the MCS follows contention based communication. All nodes can receive a message during SAS and MCS, but a node in a static cluster sends a message only during the SAS, and a node in a mobile cluster sends a message only during the MCS. Light-weight Mobility-Aware MAC (MA-MAC) [21] for wireless sensor networks was also proposed. MA-MAC extends X-MAC (a contention based scheme) and provides short preambles. MA-MAC detects mobility by using the RSSI of ACK packets and attempts to seamlessly handover communication to achieve better performance. A node can be found in one of five states: Sleep, Receive, Send, Discover, and Handover. In the initial step, a node stays in Sleep state. The node wakes up at any time if it has data to send and enters the Send state. To receive data, the node periodically wakes up and changes its state to Receive. If the node detects a discovery request, it enters a Discovery state and searches for an intermediate neighbor before breaking the link. If the node receives a discovery reply, it enters Handover state. If the handover attempt is successful, the node shifts to Send state, or otherwise, goes back to sleep. A handover process is shown in Figure 3. When a sender recognizes the mobility of _Receiver 1_ by estimating the RSSI of incoming ACK, the sender broadcasts data with a discovery request. _Receiver 2_ and _Receiver 3_ wake up to participate in discovering a new intermediate node that takes over _Receiver 1_. If _Sender 1_ receives a discovery reply from _Receiver 2_ or _Receiver 3_, _Sender 1_ updates its routing configuration and sends the data for R1 to the intermediate node. A new low duty cycle, energy efficient, mobility based protocol was introduced (Boarder Node MAC or BN-MAC) [22]. The hybrid approach of BN-MAC uses both conten  
Figure 3: Mobility support in MA-MAC (redrawn from [21]). Figure 2: Location estimation and dynamic frame time in MMAC (redrawn from [19]). communication.