# A Node Placement Algorithm Utilizing Mobile Nodes in WSN and IoT Networks +
## 5 The Energy Node Placement Algorithm
### Sink Node  
In Dynamic MobileCC, the sink node was only responsible for assigning an idle mobile node (of those waiting near the sink) for each problem occurrence in the network. In our extended version, the sink node may choose either an idle mobile node that resides at the sink (_MList_) or one that is already placed in the network for a previous problem (_idleMList_), if one exists. Algorithm 6 describes the tasks of the sink node. ```
1:functionsend_mnode(\(new\_pos\))
2:if\(idleMList==empty\)then
3:choose \(m_{k}\in MList\)
4:send(\(New\)Position) to \(m_{k}\)
5:else
6:\(distnace_{m}\) = distance(sink_pos, new_pos)
7:\(distance_{i}\) = distance(\(closest1M\_pos\),new_pos)
8:if\(distance_{m}<distance_{i}\)then
9:choose \(m_{k}\in idleMList\)
10:else
11:\(m_{k}=closest1M\)
12:endif
13:send(\(New\)Position) to \(m_{k}\)
14:endif
15:endfunction
16:upon receive (\"problem_notification\") from \(n_{i}\)then
17:new_pos = DynamicMobileCCAlgorithm()
18:call send_mnode(new_pos)
19:upon receive (\"ShouldBeReplaced\") from \(m_{i}\)then
20:\(new\_pos=currentpositionofm_{i}\)
21:call send_mnode(current position of \(m\_i\))
22:upon receive (\"ComingBack\") from \(m_{i}\)then
23:if\(m_{i}\in idleMList\)then
24:remove\(m_{i}\) from idleMList
25:endif
26:\(flag_{m_{i}}=FALSE\)
27:\(current\_pos_{m_{i}}=init\_pos_{m_{i}}\)
28:upon receive (\"Becomeldle\") from \(m_{i}\)then
29:\(status_{m_{i}}=idle\)
30:add\(m_{i}\in idleMList\)
```  
**Algorithm 6** Algorithm for sink node  
The selection of which mobile node to send is made on the closest distance to the calculated position. Initially, the sink defines the closest idle mobile node (\(closest1M\)) based on its distance (\(distance_{i}\)). Then, \(distance_{i}\) is compared to the distance of a near sink mobile node (\(distance_{m}\)). The mobile node with the smallest distance is sent to the calculated position (see Algorithm 6, lines 1-15). Another task of the sink node is to replace an in-use mobile node in the case of an energy emergency. When a mobile node informs the sink about the need of replacement, the sink node assigns the position to a new idle mobile node by choosing the closest idle mobile node in the network (see Algorithm 6, lines 19-21). Additionally, the sink node needs to keep track of the current status of the in-used mobile nodes. In this respect, notification messages received by the mobile nodes must be processed by the sink node. When a mobile node is about to return to its initial position, the sink node is informed in order to change its availability (\(flag_{m_{i}}\)), its position, and, if necessary, remove it from the idle list (see Algorithm 6, lines 22-27). When a mobile node is not needed and becomes idle at its current position, the sink node is informed and changes the status of the mobile node, and it is added to the idle list (see Algorithm 6, lines 28-30). We proceed to a simple analysis of the sink node algorithm, depending on whether there is reuse or not. Specifically, when a new problem occurs in the network, the _computational delay_ (defined below) for the whole process is divided into two cases based on the scenario used, the no reuse scenario and the reuse scenario. _No Reuse Scenario (Figure 3a):_ The notification information is sent (link a) from node \"N\" to the sink \"S\" and then a _moving notification_ is sent (link b) from \"S\" to a near-sink mobile node \"MN\". \"MN\" moves (link c) to its new position \"X\". _Reuse Scenario (Figure 3b):_ The notification information is sent (link a) from node \"N\" to the sink \"S\" and then a _reuse notification_ is sent (link b) from \"S\" to an in-used mobile node \"MN\" in the network. \"MN\" moves (link c) from its current position in the network to its new position \"X\".