# A Survey on Mobility Support in Wireless Body Area Networks
## 3 Mobility Model and Communication Protocol
### Individual Mobility
#### 3.1.2 Protocols for General Mobility  
Most of the protocols to support general mobility operate in either layer 3 or layer 2. For the layer 3 approach, flooding is likely to be considered in WBANs due to simple operation and low computational overhead. In addition, typical ad hoc networks protocols can support mobility in proactive and reactive ways. However, communication between sensor and sink node is mostly bounded by a few hops where a node's mobility speed is lower than ad hoc networks; therefore, original ad hoc protocols intended to support a large number of hops at high speed need to be extended or newly developed to meet requirements of applications. Based on the above mentioned reason, modified flooding is desirable due to significant energy consumption. On the other hand, as a layer 2 approach, Time Division Multiple Access (TDMA) based Medium Access Control (MAC) protocols were proposed to meet real-time requirements and low overhead instead of high throughput where the amount of periodic reporting is overwhelming the event-driven in WBANs. In this section, we review the technical issue and present the recent advances in mobility support for WBAN. Usually, multiple copies of packets are broadcasted to all nodes to establish routes between sink and sensor nodes in typical flooding schemes. As a next step, a route with minimum end-to-end delay is selected as the main path. However, due to path loss caused by topology partitioning in WBAN, [PERSON] et al. proposed On-Body Store and Flood Routing (OBSFR) [17], which is based on the store and forward principle. To implement OBSFR, each packet carries a unique identifier which consists of a pair of (source ID, sequence number), and list of all node's ID along the path from source and corresponding node. When a node receives a packet, it checks whether this packet is already received or not. If this packet already arrived before, it is discarded. Otherwise, the packet is stored in the buffer. The stored packet will be rebroadcasted when a node encounters any new node that does not possess a list of node IDs. Upon being rebroadcasted, the packet is removed from the buffer to make additional empty space. Even though OBSFR was proposed to support mobility in WBAN, OBSFR can be applicable to any networks, given that flooding is not controlled by any specific parameter for WBAN. A similar approach to OBSFR was introduced in Probabilistic Routing with Postural Link Costs (PRPLC) [18]. The major distinct between OSBFR and PRPLC is the forwarding scheme. A packet stored in a node's buffer is forwarded to a node which has a higher probability to meet the sink node than the current node. With the help of a new forwarding scheme in PRPLC, higher resource utilization is observed than OBSFR because the packet is not forwarded to all nodes. Furthermore, end-to-end delay is also affected by reducing the number of intermediate hops. In order to evaluate the meeting probability for sink nodes, PRPLC introduced a new metric: Link Likelyhood Factor (LLF). After each node calculates LFF for sink nodes, a node uses a HELLO message to carry its LFF value to neighboring nodes. When a node is connected with a sink node directly, a packet at the buffer is delivered. Otherwise, it can be either delivered to the next node or kept in the current node. The former happens when a node meets any node with a higher LLF value while the latter occurs when no higher LLF value is found in neighboring nodes. Distance Vector Routing with Postural Link Costs (DVRPLC) [19] was proposed to reduce end-to-end delay by reducing waiting delay at the intermediate node. Even though DVRPLC is based on store and forward like OBSFR and PRPLC, there are slight differences in operation among them. DVRPLC uses a distance vector algorithm to compute accumulated cost of path toward the sink instead of a node's value. Path cost between a node and sink node is computed by taking all neighbor nodes' Link Cost Factor (LCF) value that is exchanged through a HELLO message.