<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD Journal Publishing DTD v2.3 20070202//EN" "journalpublishing.dtd">
<article xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink" xml:lang="en" article-type="research-article">
<front>
<journal-meta>
<journal-id journal-id-type="nlm-ta">Sensors</journal-id>
<journal-title>Sensors</journal-title>
<issn pub-type="epub">1424-8220</issn>
<publisher>
<publisher-name>Molecular Diversity Preservation International (MDPI)</publisher-name></publisher></journal-meta>
<article-meta>
<article-id pub-id-type="doi">10.3390/s90100327</article-id>
<article-id pub-id-type="publisher-id">sensors-09-00327</article-id>
<article-categories>
<subj-group>
<subject>Article</subject></subj-group></article-categories>
<title-group>
<article-title>An Effective Mobile Sensor Control Method for Sparse Sensor Networks</article-title></title-group>
<contrib-group>
<contrib contrib-type="author">
<name><surname>Treeprapin</surname><given-names>Kriengsak</given-names></name><xref ref-type="corresp" rid="c1-sensors-09-00327"><sup>*</sup></xref></contrib>
<contrib contrib-type="author">
<name><surname>Kanzaki</surname><given-names>Akimitsu</given-names></name></contrib>
<contrib contrib-type="author">
<name><surname>Hara</surname><given-names>Takahiro</given-names></name></contrib>
<contrib contrib-type="author">
<name><surname>Nishio</surname><given-names>Shojiro</given-names></name></contrib>
<aff id="af1-sensors-09-00327">Dept. of Multimedia Eng., Grad. Sch. of Information Science and Technology, Osaka Univ. 1-5 Yamadaoka, Suita, Osaka 565-0871, Japan; E-Mails: <email>kanzaki@ist.osaka-u.ac.jp</email>; <email>hara@ist.osaka-u.ac.jp</email>; <email>nishio@ist.osaka-u.ac.jp</email></aff></contrib-group>
<author-notes>
<corresp id="c1-sensors-09-00327">
<label>*</label>Author to whom correspondence should be addressed; E-Mail: <email>kriengsak.treeprapin@ist.osaka-u.ac.jp</email>; Tel.: +81-6-6879-4513; Fax: +81-6-6879-4514</corresp></author-notes>
<pub-date pub-type="collection">
<year>2009</year></pub-date>
<pub-date pub-type="epub">
<day>8</day>
<month>1</month>
<year>2009</year></pub-date>
<volume>9</volume>
<issue>1</issue>
<fpage>327</fpage>
<lpage>354</lpage>
<history>
<date date-type="received">
<day>19</day>
<month>9</month>
<year>2008</year></date>
<date date-type="rev-recd">
<day>25</day>
<month>11</month>
<year>2008</year></date>
<date date-type="accepted">
<day>13</day>
<month>12</month>
<year>2008</year></date></history>
<permissions>
<copyright-statement>© 2009 by the authors; licensee Molecular Diversity Preservation International, Basel, Switzerland.</copyright-statement>
<copyright-year>2009</copyright-year>
<license>
<p>This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution license (http://creativecommons.org/licenses/by/3.0/).</p></license></permissions>
<abstract>
<p>In this paper, we propose an effective mobile sensor control method, named DATFM (Data Acquisition and Transmission with Fixed and Mobile node) for sparse sensor networks. DATFM uses two types of sensor nodes, <italic>fixed node</italic> and <italic>mobile node</italic>. The data acquired by nodes are accumulated on a fixed node before being transferred to the sink node. In addition, DATFM transfers the accumulated data efficiently by constructing a communication route of multiple mobile nodes between fixed nodes. We also conduct simulation experiments to evaluate the performance of DATFM.</p></abstract>
<kwd-group>
<kwd>Mobile sensor</kwd>
<kwd>sparse area</kwd>
<kwd>route construction</kwd></kwd-group></article-meta></front>
<body>
<sec sec-type="intro">
<label>1.</label>
<title>Introduction</title>
<p>Recent advances in wireless communication technologies have led to an increasing interest in <italic>ad hoc</italic> networks that are constructed of only wireless terminals that play the role of a router. Especially, sensor networks have emerged as an important application of <italic>ad hoc</italic> networks. Due to the ability to construct a large-scale sensing system by cooperative behaviors of multiple sensor nodes, sensor networks are expected to be applied to many applications such as environmental monitoring, investigation of ecological system and building management.</p>
<p>In these areas there are some applications where it is difficult to deploy a large number of sensor nodes such as disaster sites, planetary exploration, polluted areas and underwater [<xref ref-type="bibr" rid="b1-sensors-09-00327">1</xref>-<xref ref-type="bibr" rid="b3-sensors-09-00327">3</xref>]. In such environments, the deployment of sensor nodes becomes too sparse to achieve sufficient sensing and data transfer. For example, in a planetary or underwater exploration, a large number (e.g. hundreds or thousands) of nodes cannot be deployed because of space and cost constrains. Moreover, in a polluted plant, the sensing area is too large to deploy a sufficient number of nodes. Although some studies assume applications where a large number of nodes are deployed from the air (e.g. from airplanes or helicopters), such a deployment becomes impossible in a building or under the heap of ruins. Furthermore, long range radio waves cannot improve the connectivity in these applications, since it is affected by the ambient surrounding such as obstacles and landscape.</p>
<p>On the other hand, with the development of robotics technologies in recent years, there have been many studies on sensor nodes with a moving facility (<italic>mobile sensors</italic>). Mobile sensors are well suited for a sparse network since a large area can be monitored with a small number of sensor nodes. In this paper, we call sensor networks which fully or partially include mobile sensors as <italic>mobile sensor networks</italic>.</p>
<p>Although many data transfer methods which utilize mobile sensors have been proposed [<xref ref-type="bibr" rid="b4-sensors-09-00327">4</xref>-<xref ref-type="bibr" rid="b6-sensors-09-00327">6</xref>], these methods assume an environment where the density of nodes is high. Thus, these methods cannot work well in a sparse network we assume in this paper. On the other hand, in [<xref ref-type="bibr" rid="b7-sensors-09-00327">7</xref>-<xref ref-type="bibr" rid="b9-sensors-09-00327">9</xref>], the authors proposed a data transfer method with mobile sensors that can transfer data even in a sparse network. However, since data transfer is performed mainly by the movement of mobile sensors, the performance of sensing and data gathering becomes significantly low especially in a sparse network.</p>
<p>In order to reduce the movement of mobile sensors, it is effective to construct a communication route for transmitting data to the sink node by using multiple mobile sensors. However, in a sparse network, it is difficult to construct a communication route due to the low connectivity of mobile sensors. Therefore, an effective mobile sensor control method is necessary to construct a communication route in a sparse network.</p>
<p>In this paper, we propose DATFM (Data Acquisition and Transmission with Fixed and Mobile node), which is an effective mobile sensor control method for sparse sensor networks to improve the efficiency of sensing and data transfer. In order to achieve effective control of mobile sensors, DATFM uses two types of sensor nodes, <italic>fixed node</italic> and <italic>mobile node</italic>. A fixed node has two roles, temporarily accumulating data acquired by nodes and constructing a communication route between fixed nodes for transmitting the accumulated data. By using the fixed nodes, DATFM can effectively control the behaviors of mobile nodes, and thus, effective sensing and data transfer can be achieved even in a sparse network.</p>
<p>The reminder of this paper is organized as follows. In Section 2, we briefly introduce the system model assumed in this paper and the conventional data transfer methods. In Section 3, we explain our proposed method. The results of simulation experiments are presented in Section 4. Finally, we conclude this paper in Section 5.</p></sec>
<sec>
<label>2.</label>
<title>System model and related work</title>
<p>In this section, we introduce the system model assumed in this paper and the conventional studies on data transfer in sparse sensor networks.</p>
<sec>
<label>2.1.</label>
<title>System model</title>
<p>In this paper, we assume an application which monitors a vast area with a small number of nodes. For example, in an investigation of the ocean floor or the planetary, detection of the mineral vein or undiscovered resources in an unexplored area, and observation of the toxic gas in a disaster site, a vast area should be monitored by a small number of nodes. To monitor the whole area with a small number of nodes, mobile sensors are introduced into the network. In addition, we assume that each sensor acquires data whose sizes are relatively large such as pictures or movies.</p></sec>
<sec>
<label>2.2.</label>
<title>Related work</title>
<p>Until now, many data transfer methods in mobile sensor networks have been proposed [<xref ref-type="bibr" rid="b4-sensors-09-00327">4</xref>-<xref ref-type="bibr" rid="b12-sensors-09-00327">12</xref>]. In [<xref ref-type="bibr" rid="b4-sensors-09-00327">4</xref>, <xref ref-type="bibr" rid="b6-sensors-09-00327">6</xref>], a simple and efficient data transfer method named DFT-MSN (Delay/Fault Tolerant Mobile Sensor Network) has been proposed. In DFT-MSN, mobile sensors are classified into two types of nodes, mobile sensor nodes and high-end sink nodes. The high-end sink nodes are deployed at strategic locations where mobile sensor nodes visit with high probability. In addition, they may directly connect to the sink node all the time by changing their transmission power if necessary. Each mobile sensor node acquires data and sends it to a nearby high-end sink node by flooding with a probability in order to prevent duplication of transmitted data. After that, the high-end sink node transmits the received data to the sink node. This method assumes that each high-end sink node has to connect to the sink node all the time. As mentioned in Section 1, this assumption cannot be applied to the applications assumed in this paper.</p>
<p>In [<xref ref-type="bibr" rid="b5-sensors-09-00327">5</xref>], the authors have proposed an algorithm which governs the behaviors of nodes in order to minimize the total energy consumption for moving and communication. In this algorithm, all nodes have an associated clock cycling and each node determines with a probability whether it acquires data or transmits data acquired by other nodes in every cycle. In the latter case, the node moves to construct a communication route between the sink node and a node that determines to transmit data. By doing so, this algorithm can construct the communication route to the sink node and transfer the acquired data by autonomous behaviors of nodes. However, this algorithm may not work in a sparse network because it becomes difficult to construct a communication route due to the low connectivity of nodes.</p>
<p>In [<xref ref-type="bibr" rid="b10-sensors-09-00327">10</xref>], the authors assumed an environment in which mobile sensors randomly move around in an area without any control and proposed a method to determine a mobile sensor for transferring data to the sink node. In this method, each mobile sensor periodically sends information on its location to nearby sensors. Using this information, each mobile sensor predicts the locations of other sensors in the future and determines a mobile sensor to send the data. However, since mobile sensors have to periodically exchange information on their locations, this method may not work in a sparse network due to the low connectivity between mobile sensors.</p>
<p>In [<xref ref-type="bibr" rid="b11-sensors-09-00327">11</xref>], the authors proposed a clustering algorithm which divides an area into several zones and clusters mobile sensors based on the divided zones. In this method, each mobile sensor periodically sends information on the frequency that it traverses the borders between zones. The mobile sensor with the smallest frequency among all sensors in a zone is elected as the cluster head. The cluster head in each cluster acts as a router in the network and transmits the data acquired in the corresponding cluster to the cluster head in an adjacent zone to which the multi-hop communication route is the most stable. This algorithm also has to periodically exchange information in order to elect the cluster heads. In addition, the data is transferred to the sink node via multi-hop communication routes between cluster heads. Thus, this algorithm may not work in a sparse network.</p>
<p>In [<xref ref-type="bibr" rid="b12-sensors-09-00327">12</xref>], a data gathering method considering a sparse network has been proposed. This method utilizes a broadcasting system to control the movement of mobile sensors. Specifically, the information on the locations of mobile sensors connected with the sink node by single or multi-hop communication route is broadcasted to all mobile sensors. By using this broadcasted information, each mobile sensor can adjust the moving destination in order to decrease the moving distance to connect with the sink node or a mobile sensor which has already connected with the sink node. Hereby, data gathering from all mobile sensors can be achieved with small moving costs. However, since this method needs a broadcasting system, it is difficult to be applied to environments we assume. For example, in a building or underwater, it is generally difficult for mobile sensors to surely receive broadcasted information.</p>
<p>In [<xref ref-type="bibr" rid="b7-sensors-09-00327">7</xref>, <xref ref-type="bibr" rid="b8-sensors-09-00327">8</xref>], RAMOS (Routing Assisted by Moving Objects) has been proposed as a data transfer method with mobile sensors. RAMOS defines several modes (classified into three categories listed below) for each sensor. Each sensor autonomously controls its behavior by changing its mode according to the existence of data.</p>
<sec>
<title>Category 1: Fixed</title>
<p>A sensor does a sensing operation without moving. If a neighboring sensor which is within the communication range locates closer to the sink node, the sensor transmits the data to the neighboring sensor.</p></sec>
<sec>
<title>Category 2: Moving</title>
<p>A sensor does a sensing operation and transfers the data by moving to the sink node.</p></sec>
<sec>
<title>Category 3: Transmitting</title>
<p>A sensor moves around the area to find other sensors that hold data. When it connects to such a sensor, it receives and transfers the data by moving to the sink node.</p>
<p>In RAMOS, each sensor transfers acquired data to the sink node by changing its mode autonomously. However, since each sensor has to move to the sink node to transfer acquired data in most cases, moving cost much increases. Moreover, in a sparse network, since each sensor has few opportunities to connect to other sensors, the efficiency of sensing and data transfer becomes low.</p>
<p>In [<xref ref-type="bibr" rid="b9-sensors-09-00327">9</xref>], the authors have proposed a sensing method using uncoordinated mobile nodes (UM nodes). In this method, each UM node acquires data until the amount of the acquired data reaches the memory capacity. Moreover, each UM node exchanges information on the acquired data with a connected UM node and deletes the data which were acquired by the connected node at the same location and time. By doing so, duplicated sensing (sensing a location by multiple nodes) can be suppressed and more data can be accumulated in the memory space of a UM node. In addition, this method proposes two mobility models of UM nodes, the multi-homed random way point model and the controlled mobile nodes model. In multi-homed random way point model, each UM node randomly chooses the destination and moves there. After reached the destination, it stochastically determines whether it returns to the sink node or it moves to a new destination. However, since each UM node selects the destination randomly from the whole area, the moving distance to the destination tends to increase. Thus, the efficiency of sensing decreases especially in a wide area. On the other hand, in the controlled mobile node model, the moving path of each UM node is determined in advance and each node does a sensing operation while moving its path. Furthermore, by setting moving paths of UM nodes to reduce unnecessary movement, the efficiency of sensing can be further improved. However, it is necessary to calculate the moving paths of all UM nodes in advance. Thus, the computational cost becomes very large. Moreover, this model cannot handle dynamic changes of conditions such as the existence of obstacles. Thus, moving paths cannot be determined in an unknown or highly dynamic area (e.g. planetary or underwater).</p></sec></sec></sec>
<sec sec-type="methods">
<label>3.</label>
<title>DATFM (Data Acquisition and Transmission with Fixed and Mobile node)</title>
<p>In this section, we explain our proposed mobile sensor control method, DATFM.</p>
<sec>
<label>3.1.</label>
<title>Assumptions</title>
<p>In this paper, we assume a sensor network in a wide area which is constructed by a small number of mobile sensors. The data acquired by sensor nodes are transferred to the sink node located at a corner of the area similar to the assumption in many conventional works such as target detecting, tracking and environment monitoring [<xref ref-type="bibr" rid="b9-sensors-09-00327">9</xref>, <xref ref-type="bibr" rid="b13-sensors-09-00327">13</xref>-<xref ref-type="bibr" rid="b14-sensors-09-00327">14</xref>]. Each node has a unique identifier in the network. In addition, we assume that all nodes have the same sensor and radio devices. Thus, the sensing and wireless communication ranges are same among all nodes.</p>
<p>Following the conventional works [<xref ref-type="bibr" rid="b4-sensors-09-00327">4</xref>-<xref ref-type="bibr" rid="b12-sensors-09-00327">12</xref>], we assume that there are no obstacles in the area. There are two types of sensor nodes, <italic>fixed node</italic> and <italic>mobile node</italic> (the sink node is classified as a fixed node). Each node acquires its present location by using GPS or other location detection methods [<xref ref-type="bibr" rid="b14-sensors-09-00327">14</xref>-<xref ref-type="bibr" rid="b16-sensors-09-00327">16</xref>]. Moreover, all nodes know the locations of all fixed nodes. This assumption is valid in applications where the locations of fixed nodes are strategically decided before deploying them.</p>
<sec>
<label>3.1.1.</label>
<title>Fixed node</title>
<p>A fixed node does not move. It has larger memory capacity, compared with a mobile node, and accumulates data acquired by itself and from other nodes. In addition, it controls nearby mobile nodes to construct a communication route when transmitting the accumulated data toward the sink node. Furthermore, it holds information on nearby mobile nodes that directly connected to it (entered the wireless communication range) for a certain period; the information includes the identifier of each mobile node, the time when the node connected to it, the fixed node that the node goes to next, and the next destination (sensing point or location of the next fixed node to go) of the node. <xref ref-type="table" rid="t1-sensors-09-00327">Table 1</xref> shows an example of the information held by a fixed node. Each fixed node sets the validity period for each record in the information (each row in <xref ref-type="table" rid="t1-sensors-09-00327">Table 1</xref>), and removes it when the validity period expires. Here, the validity period for mobile node <italic>i</italic> is calculated by the following equation:
<disp-formula id="FD1">
<label>(1)</label>
<mml:math id="mm1" display="block">
<mml:semantics id="sm1">
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="bold-italic">VP</mml:mtext>
<mml:mtext mathvariant="italic">i</mml:mtext></mml:msub>
<mml:mo>=</mml:mo>
<mml:mfrac>
<mml:mrow>
<mml:msqrt>
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="bold-italic">S</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="italic">area</mml:mtext></mml:mrow></mml:msub></mml:mrow></mml:msqrt></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi>υ</mml:mi>
<mml:mtext mathvariant="italic">m</mml:mtext></mml:msub></mml:mrow></mml:mfrac>
<mml:mo>.</mml:mo></mml:mrow></mml:semantics></mml:math></disp-formula></p>
<p>In the above equation, <bold><italic>S</italic></bold><italic><sub>area</sub></italic> and <bold><italic>υ</italic></bold><italic><sub>m</sub></italic> respectively denote the area size and the velocity of mobile nodes in the sensing mode (described in the next subsection). By using this information, each fixed node predicts where each mobile node exists.</p></sec>
<sec>
<label>3.1.2.</label>
<title>Mobile node</title>
<p>A mobile node moves around the area. In addition, it has the following three modes:</p>
<sec>
<title>Sensing mode (<italic>SM</italic>)</title>
<p>A node sets a destination randomly within the area and moves there. After reaching the destination, it does a sensing operation and decides its new destination.</p></sec>
<sec>
<title>Collecting mode (<italic>CM</italic>)</title>
<p>When a node in <italic>SM</italic> receives a <italic>route request packet</italic> (<italic>RReq</italic>) from a fixed node, it changes its mode into collecting mode (<italic>CM</italic>). In <italic>CM</italic>, a node moves faster than that in <italic>SM</italic> in order to collect other mobile nodes to construct a communication route.</p></sec>
<sec>
<title>Transmission mode (<italic>TM</italic>)</title>
<p>When a node in <italic>SM</italic> receives a <italic>route construction request packet</italic> (<italic>RCReq</italic>) from a fixed node or a mobile node in <italic>CM</italic>, it changes its mode into transmission mode (<italic>TM</italic>). In <italic>TM</italic>, a node constructs a route and transfers the data.</p>
<p><xref ref-type="fig" rid="f1-sensors-09-00327">Figure 1</xref> shows the mode transition of a mobile node.</p></sec></sec></sec>
<sec>
<label>3.2.</label>
<title>Moving strategy of mobile nodes</title>
<p>DATFM divides the area into several regions based on a Voronoi diagram in which fixed nodes are the site points. Here, the Voronoi diagram of a set of point partitions the area into convex polygons that consist of the vertical bisectors of the points. Every point in a polygon is closer to the site point in the corresponding polygon than to any other site points. In DATFM, each site point (a fixed node) has charge of the corresponding region. In other words, each fixed node has a role for collecting data acquired in the region the fixed node exists. We call the region for each fixed node as its <italic>territory</italic>. <xref ref-type="fig" rid="f2-sensors-09-00327">Figure 2</xref> shows an example of Voronoi diagram and divided territories</p>
<p>A mobile node basically sets its mode as <italic>SM</italic> and moves to the selected destination by the following steps:
<list list-type="order">
<list-item>
<p>It moves to connect to the nearest fixed node (i.e. the fixed node in the current territory) and transmits its acquired data.</p></list-item>
<list-item>
<p>It calculates the distances between its destination and all fixed nodes in the adjacent territories and moves to the fixed node that is the nearest to its destination. In addition, it sends information on its identifier, its next fixed node to move, and its destination to the connecting fixed node before moving to the next fixed node. <xref ref-type="fig" rid="f3-sensors-09-00327">Figure 3</xref> shows an example to choose the next fixed node to move. After transmitting its acquired data to fixed node <bold><italic>A</italic></bold>, the mobile node <bold><italic>a</italic></bold> calculates the distances between its destination and fixed nodes <bold><italic>B, C</italic></bold>, and <bold><italic>D</italic></bold>, which are in territories adjacent to <bold><italic>A</italic></bold>'s territory. After that, it chooses fixed node <bold><italic>C</italic></bold> that is the nearest to the destination and moves there. These procedures are repeated until the mobile node connects to the fixed node that has charge of the territory which contains the destination.</p></list-item>
<list-item>
<p>It moves to its destination and does a sensing operation.</p></list-item></list></p>
<p>This moving strategy enables each fixed node to have many opportunities to connect to mobile nodes. Moreover, each fixed node can predict the locations of the recently connected mobile nodes by using the information shown in <xref ref-type="table" rid="t1-sensors-09-00327">Table 1</xref>. Therefore, this strategy makes it easy for fixed nodes to collect mobile nodes in the data transmission phase described in the next subsection.</p></sec>
<sec>
<label>3.3.</label>
<title>Data Transmission</title>
<p>A fixed node starts to transmit the accumulated data when the amount of the accumulated data in its memory exceeds the predetermined threshold. In what follows, we explain the procedures for transferring the accumulated data to the sink node.</p>
<sec>
<label>3.3.1.</label>
<title>Selection of the next fixed node</title>
<p>The fixed node that starts data transmission (the source node) selects a next fixed node to transmit the data (the destination node) by using the Delaunay triangulation. The Delaunay triangulation can be performed by connecting the site points in the Voronoi diagram whose polygons share a common edge.</p>
<p>The source node creates Delaunay triangles which include itself, and selects another fixed node that is a vertex of a Delaunay triangle and is the nearest to the sink node. This node is set as the destination node. When the sink node is a vertex of the created Delaunay triangles, the source node selects the sink node as the destination. <xref ref-type="fig" rid="f4-sensors-09-00327">Figure 4</xref> shows an example of selecting the destination node. Fixed node <bold><italic>A</italic></bold> selects the destination node from fixed nodes <bold><italic>B, C</italic></bold> and <bold><italic>D</italic></bold>. In this figure, since fixed node <bold><italic>C</italic></bold> is the nearest to the sink node, it becomes the destination node. On the other hand, when fixed node <bold><italic>D</italic></bold> starts data transmission, it selects the sink node as the destination node since the sink node is a vertex of the created Delaunay triangles.</p></sec>
<sec>
<label>3.3.2.</label>
<title>Request for collecting mobile nodes</title>
<p>The source node firstly checks whether a communication route to the destination node exists. If it does, the source node transmits the data to the destination node via the communication route. Otherwise, the source node sends <italic>RReq</italic> to a mobile node that firstly connects to it. If multiple mobile nodes already connect to the source node, the source node randomly selects one of them and sends <italic>RReq</italic> to it. The mobile node that receives the <italic>RReq</italic> changes its mode into <italic>CM</italic>. Here, a <italic>RReq</italic> includes the identifiers of the source and destination nodes, the <italic>required number of mobile nodes</italic> <bold><italic>N</italic></bold><italic><sub>req</sub></italic>, and the <italic>time limit</italic> <bold><italic>T</italic></bold><sub>lim</sub> for collecting mobile nodes. <bold><italic>N</italic></bold><italic><sub>req</sub></italic> is the number of mobile nodes which is required to construct the communication route, and is calculated by the following equation:
<disp-formula id="FD2">
<label>(2)</label>
<mml:math id="mm2" display="block">
<mml:semantics id="sm2">
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="bold-italic">N</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="italic">req</mml:mtext></mml:mrow></mml:msub>
<mml:mo>=</mml:mo>
<mml:mrow>
<mml:mo>⌊</mml:mo>
<mml:mrow>
<mml:mfrac>
<mml:mrow>
<mml:mrow>
<mml:mo>|</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi mathvariant="bold">L</mml:mi>
<mml:mrow>
<mml:mtext mathvariant="italic">src</mml:mtext></mml:mrow></mml:msub>
<mml:mo>−</mml:mo>
<mml:msub>
<mml:mi mathvariant="bold-italic">L</mml:mi>
<mml:mrow>
<mml:mtext mathvariant="italic">dst</mml:mtext></mml:mrow></mml:msub></mml:mrow>
<mml:mo>|</mml:mo></mml:mrow></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="bold-italic">R</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="italic">com</mml:mtext></mml:mrow></mml:msub></mml:mrow></mml:mfrac></mml:mrow>
<mml:mo>⌋</mml:mo></mml:mrow>
<mml:mo>.</mml:mo></mml:mrow></mml:semantics></mml:math></disp-formula></p>
<p><bold><italic>L</italic></bold><italic><sub>src</sub></italic> and <bold><italic>L</italic></bold><italic><sub>dst</sub></italic> are the locations of the source and destination nodes. <bold><italic>R</italic></bold><italic><sub>com</sub></italic> is the wireless communication range. <bold><italic>T</italic></bold><sub>lim</sub> is the time that terminates collecting mobile nodes. The detail of the time limit is described in Subsection 3.3.4. <xref ref-type="fig" rid="f5-sensors-09-00327">Figure 5(a)</xref> shows an example of <italic>RReq</italic> sent from the source node <bold><italic>A</italic></bold>.</p>
<p>The mobile node in <italic>CM</italic> travels around the nearby fixed nodes to collect the other mobile nodes. First, the mobile node in <italic>CM</italic> moves to the destination node. When the mobile node connects with a fixed node, it does the following procedures:
<list list-type="order">
<list-item>
<p>It calculates the number of mobile nodes which are performing a sensing operation in the territory of the connected fixed node. This can be done by checking the ‘next destination’ record in the information held by the fixed node. Specifically, when the ‘next destination’ is in the territory of the fixed node, the corresponding mobile node is performing the sensing operation in the territory.</p></list-item>
<list-item>
<p>It decreases <bold><italic>N</italic></bold><italic><sub>req</sub></italic> in the <italic>RReq</italic> by that calculated number of nodes. This is because the mobile nodes performing a sensing operation in a territory will connect to the fixed node in the territory after the sensing operation. As described later, those mobile nodes will receive <italic>RCReq</italic> from the fixed node, and move to the source node to help data transmission.</p></list-item>
<list-item>
<p>It sends the updated <italic>RReq</italic> to the fixed node.</p></list-item>
<list-item>
<p>It chooses the next fixed node to go. Specifically, it checks the ‘next fixed node’ record in the information held by the fixed node, and chooses one to which the largest number of mobile nodes have gone, and which it has not visited yet.</p></list-item></list></p>
<p>Here, the mobile node in <italic>CM</italic> goes back to the source node when at least one of the following conditions is satisfied:</p>
<list list-type="bullet">
<list-item>
<p>The next fixed node to go cannot be found.</p></list-item>
<list-item>
<p><bold><italic>N</italic></bold><italic><sub>req</sub></italic> in <italic>RReq</italic> becomes zero.</p></list-item>
<list-item>
<p>The time limit has come.</p></list-item></list>
<p><xref ref-type="fig" rid="f5-sensors-09-00327">Figure 5(b)</xref> shows an example of behaviors of a mobile node in <italic>CM</italic> connected to fixed node <bold><italic>C</italic></bold>. It calculates the number of mobile nodes which are performing a sensing operation in the territory of fixed node <bold><italic>C</italic></bold>. In this figure, the mobile node in <italic>CM</italic> knows that mobile nodes <bold><italic>c</italic></bold> and <bold><italic>k</italic></bold> are performing a sensing operation since their next fixed node is <bold><italic>C</italic></bold>. Thus, the mobile node in <italic>CM</italic> decreases <bold><italic>N</italic></bold><italic><sub>req</sub></italic> in the <italic>RReq</italic> by two and sends the updated <italic>RReq</italic> to fixed node <bold><italic>C</italic></bold>. After that, it checks the ‘next fixed node’ record in the information held by fixed node <bold><italic>C</italic></bold>, and chooses fixed node <bold><italic>D</italic></bold> as the next destination to go since the largest number of nearby mobile nodes (i.e., <bold><italic>e</italic></bold> and <bold><italic>l</italic></bold>) have gone.</p>
<p>After returning to the source node, the mobile node in <italic>CM</italic> changes its mode. If the required number of mobile nodes has not been collected, the node in <italic>CM</italic> changes its mode into <italic>TM</italic>. Otherwise, if <bold><italic>N</italic></bold><italic><sub>req</sub></italic> mobile nodes have been collected and the communication route have been constructed, it changes back to <italic>SM</italic> and returns to a sensing operation.</p>
<p>When the mobile node in <italic>CM</italic> connects to other mobile nodes while moving, it sends a <italic>RCReq</italic> to the connected nodes. Here, a <italic>RCReq</italic> includes the identifiers of the source and destination nodes. When the mobile node that receives the <italic>RCReq</italic> is in <italic>SM</italic>, it moves to the source node and changes its mode into <italic>TM</italic>. After that, the mobile node in <italic>CM</italic> decreases the <bold><italic>N</italic></bold><italic><sub>req</sub></italic> in the <italic>RReq</italic> by one. For example in <xref ref-type="fig" rid="f5-sensors-09-00327">Figure 5(c)</xref>, when a mobile node in <italic>CM</italic> connects with mobile node <bold><italic>f</italic></bold>, it sends a <italic>RCReq</italic> to <bold><italic>f</italic></bold> and decreases <bold><italic>N</italic></bold><italic><sub>req</sub></italic>. On the other hand, when a mobile node in <italic>SM</italic> connects to the source node or a fixed node which received the <italic>RReq</italic> from a mobile node in <italic>CM</italic>, the source node or the fixed node sends a <italic>RCReq</italic> to the connected mobile node. The mobile node that receives the <italic>RCReq</italic> changes its mode into <italic>TM</italic> and moves to the source node. Here, a fixed node which received the <italic>RReq</italic> from the mobile node in <italic>CM</italic> continues to send <italic>RCReq</italic>s until the time limit comes.</p></sec>
<sec>
<label>3.3.3</label>
<title>Data transmission using the collected node</title>
<p>The source node starts data transmission when it firstly connects to a mobile node in <italic>TM</italic>. First, the source node calculates the location, (<bold><italic>x</italic></bold><italic><sub>k</sub></italic>, <bold><italic>y</italic></bold><italic><sub>k</sub></italic>), of each collected mobile node <bold><italic>m</italic></bold><italic><sub>k</sub></italic> by the following equations:
<disp-formula id="FD3">
<label>(3)</label>
<mml:math id="mm3" display="block">
<mml:semantics id="sm3">
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="bold-italic">x</mml:mtext>
<mml:mtext mathvariant="italic">k</mml:mtext></mml:msub>
<mml:mo>=</mml:mo>
<mml:msub>
<mml:mtext mathvariant="bold-italic">x</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="italic">src</mml:mtext></mml:mrow></mml:msub>
<mml:mo>+</mml:mo>
<mml:mfrac>
<mml:mtext mathvariant="bold-italic">k</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="bold-italic">n</mml:mtext>
<mml:mo>+</mml:mo>
<mml:mn mathvariant="bold">1</mml:mn></mml:mrow></mml:mfrac>
<mml:mo>⋅</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mtext mathvariant="bold-italic">x</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="italic">dst</mml:mtext></mml:mrow></mml:msub>
<mml:mo>−</mml:mo>
<mml:msub>
<mml:mtext mathvariant="bold-italic">x</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="italic">src</mml:mtext></mml:mrow></mml:msub>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>.</mml:mo></mml:mrow></mml:semantics></mml:math></disp-formula>
<disp-formula id="FD4">
<label>(4)</label>
<mml:math id="mm4" display="block">
<mml:semantics id="sm4">
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="bold-italic">y</mml:mtext>
<mml:mtext mathvariant="italic">k</mml:mtext></mml:msub>
<mml:mo>=</mml:mo>
<mml:msub>
<mml:mtext mathvariant="bold-italic">y</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="italic">src</mml:mtext></mml:mrow></mml:msub>
<mml:mo>+</mml:mo>
<mml:mfrac>
<mml:mtext mathvariant="bold-italic">k</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="bold-italic">n</mml:mtext>
<mml:mo>+</mml:mo>
<mml:mn mathvariant="bold">1</mml:mn></mml:mrow></mml:mfrac>
<mml:mo>⋅</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mtext mathvariant="bold-italic">y</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="italic">dst</mml:mtext></mml:mrow></mml:msub>
<mml:mo>−</mml:mo>
<mml:msub>
<mml:mtext mathvariant="bold-italic">y</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="italic">src</mml:mtext></mml:mrow></mml:msub>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>.</mml:mo></mml:mrow></mml:semantics></mml:math></disp-formula></p>
<p>Here, <bold><italic>n</italic></bold> is the number of collected mobile nodes and each of the collected mobile nodes is assigned an identifier (<bold><italic>m</italic><sub>1</sub>, <italic>m</italic><sub>2</sub>, …, <italic>m</italic></bold><italic><sub>n</sub></italic>). (<bold><italic>x</italic></bold><italic><sub>k</sub></italic>, <bold><italic>y</italic></bold><italic><sub>k</sub></italic>) and (<bold><italic>x</italic></bold><italic><sub>dst</sub></italic>, <bold><italic>y</italic></bold><italic><sub>dst</sub></italic>) are the locations of the source and destination nodes. Then, the source node sends information on the calculated locations to the collected mobile nodes. The collected mobile nodes move to their locations. <xref ref-type="fig" rid="f6-sensors-09-00327">Figure 6</xref> shows an example of calculating the locations of mobile nodes when two mobile nodes are collected.</p>
<p>Here, if the sufficient number of mobile nodes are collected, the communication route between the source and destination nodes is constructed. Otherwise, if the number of collected mobile nodes is smaller than the required number <bold><italic>N</italic></bold><italic><sub>req</sub></italic>, the source node transmits the data by using <italic>train transmission</italic>.</p>
<p>In train transmission, data are transferred by cooperative movement and communication among the collected mobile nodes. Specifically, the collected mobile nodes firstly form a line segment by the above mentioned process. After that, the collected nodes repeat the following procedures:
<list list-type="order">
<list-item>
<p>The source node transmits a part of the accumulated data so that the amount of the transmitted data equals to the sum of memory spaces of the collected nodes.</p></list-item>
<list-item>
<p>The collected nodes move toward the destination node with keeping same distances between adjacent nodes, and stop when the node at the other end of the line segment connects to the destination node.</p></list-item>
<list-item>
<p>The collected nodes transmit all the data to the destination node through the line segment (communication route), and then, move back toward the source node.</p></list-item></list></p>
<p><xref ref-type="fig" rid="f7-sensors-09-00327">Figure 7</xref> shows an example of train transmission with two mobile nodes.</p>
<p>Moreover, when another mobile node in <italic>TM</italic> connects to the source node after started the train transmission, the source node adds the connected mobile node to the ‘train’. Specifically, the source node increments the identifiers of mobile nodes (i.e. <bold><italic>m</italic></bold><italic><sub>k</sub></italic> <bold>→ <italic>m</italic></bold><italic><sub>k</sub></italic><bold><sub>+1</sub></bold>) in the current train and assigns identifier <bold><italic>m</italic><sub>1</sub></bold> to the newly connected node. Then, the source node recalculates the location of each mobile node and sends information on the recalculated locations to all the collected mobile nodes. The mobile nodes which received the information move to their new locations and restart the train transmission. <xref ref-type="fig" rid="f8-sensors-09-00327">Figure 8</xref> shows an example when another mobile node connects the source node. In this figure, the newly connected node is assigned identifier <bold><italic>m</italic><sub>1</sub></bold> and added to the train.</p>
<p>Here, when the number of the collected nodes reaches <bold><italic>N</italic></bold><italic><sub>req</sub></italic>, the completed communication route is constructed. In that case, the source node stops the train transmission and start transmitting the data via the constructed route. Moreover, the source node sends a <italic>route release packet</italic> (<italic>RRel</italic>) to nodes in <italic>TM</italic> which newly connects after constructed the complete communication route. The mobile nodes that received the <italic>RRel</italic> change their mode into <italic>SM</italic> and restart moving to their destinations.</p>
<p>After transmitting all the accumulated data, the source node sends a <italic>RRel</italic> to each mobile node in <italic>TM</italic>. A <italic>RRel</italic> includes the information on the next fixed node to go. Each mobile node that receives the <italic>RRel</italic> changes its mode into <italic>SM</italic> and moves to the destination specified in the <italic>RRel</italic>. Here, the source node sets the next fixed node for the half of mobile nodes in <italic>TM</italic> which are far from itself as the destination node of the data transmission. This helps the destination node to collect mobile nodes for the next data transmission since the amount of data in its memory space may exceed the threshold. On the other hand, for each of the other mobile nodes, the source node sets the next fixed node as itself. <xref ref-type="fig" rid="f9-sensors-09-00327">Figure 9</xref> shows an example when the source node <bold><italic>A</italic></bold> has transmitted all the accumulated data to the destination node <bold><italic>C</italic></bold>. The source node <bold><italic>A</italic></bold> sends <italic>RRel</italic>s including <bold><italic>C</italic></bold> as the next fixed node to mobile nodes <bold><italic>m</italic><sub>3</sub></bold> and <bold><italic>m</italic><sub>4</sub></bold>. It also sends <italic>RRel</italic>s including itself as the next fixed node to mobile nodes <bold><italic>m</italic><sub>1</sub></bold> and <bold><italic>m</italic><sub>2</sub></bold>. After that, mobile nodes <bold><italic>m</italic><sub>1</sub></bold> and <bold><italic>m</italic><sub>2</sub></bold> restart to move to the destination after connected to fixed node <bold><italic>A</italic></bold>.</p></sec>
<sec>
<label>3.3.4.</label>
<title>Decision of the time limit</title>
<p>In DATFM, the source node sets the time limit and notifies it to the mobile node in <italic>CM</italic> and other nearby fixed nodes. As described in Subsection 3.3.2, this value is used for terminating collecting mobile nodes for the corresponding data transmission. Here, in order to set the appropriate time limit, we use the estimated time elapsed to collect the required number of mobile nodes.</p>
<p>In order to calculate the time limit, we assume that the following parameters are given:
<list list-type="simple">
<list-item>
<p><bold>L</bold><italic><sub>i</sub></italic>: the location of fixed node <bold><italic>i</italic></bold>.</p></list-item>
<list-item>
<p><bold>T</bold><italic><sub>i</sub></italic>: the territory of fixed node <bold><italic>i</italic></bold>.</p></list-item>
<list-item>
<p><bold>d</bold><italic><sub>i</sub></italic>: the location of the destination (sensing point) of a mobile node in T<italic><sub>i</sub></italic> (i.e. <bold>d</bold><italic><sub>i</sub></italic> ∈ <bold>T</bold><italic><sub>i</sub></italic>).</p></list-item>
<list-item>
<p><bold><italic>S</italic></bold><italic><sub>area</sub></italic>: the size of the whole area (i.e. 
<inline-formula>
<mml:math id="mm5">
<mml:semantics id="sm5">
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="bold-italic">S</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="italic">area</mml:mtext></mml:mrow></mml:msub>
<mml:mo>=</mml:mo>
<mml:munder>
<mml:mtext>∑</mml:mtext>
<mml:mtext mathvariant="italic">i</mml:mtext></mml:munder>
<mml:mrow>
<mml:mrow>
<mml:mo>|</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi mathvariant="bold">T</mml:mi>
<mml:mtext mathvariant="italic">i</mml:mtext></mml:msub></mml:mrow>
<mml:mo>|</mml:mo></mml:mrow></mml:mrow></mml:mrow></mml:semantics></mml:math></inline-formula>).</p></list-item>
<list-item>
<p><bold><italic>υ</italic></bold><italic><sub>m</sub></italic>: the velocity of mobile nodes in <italic>SM</italic>.</p></list-item>
<list-item>
<p><bold><italic>T</italic></bold><italic><sub>acq</sub></italic>: the time for a sensing operation at a destination (sensing point).</p></list-item>
<list-item>
<p><bold><italic>S</italic></bold><italic><sub>F</sub></italic>: the set of fixed nodes in the whole area.</p></list-item>
<list-item>
<p><bold><italic>N</italic></bold><italic><sub>mov</sub></italic>: the number of mobile nodes in the whole area.</p></list-item>
<list-item>
<p><bold><italic>N</italic></bold><italic><sub>reqi</sub></italic>: the required number of mobile nodes to construct the completed communication route from fixed node <bold><italic>i</italic></bold>.</p></list-item></list></p>
<p>Let us denote <bold><italic>T</italic></bold><italic><sub>esti</sub></italic> as the estimated time in which the required number of mobile nodes connect to fixed node <bold><italic>i</italic></bold>. Then, the time limit of fixed node <bold><italic>i</italic></bold> (<bold><italic>T</italic><sub>lim</sub></bold><italic><sub>i</sub></italic>) is calculated by the following equation:
<disp-formula id="FD5">
<label>(5)</label>
<mml:math id="mm6" display="block">
<mml:semantics id="sm6">
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="bold-italic">T</mml:mtext>
<mml:mrow>
<mml:msub>
<mml:mtext>lim</mml:mtext>
<mml:mtext mathvariant="italic">i</mml:mtext></mml:msub></mml:mrow></mml:msub>
<mml:mo>=</mml:mo>
<mml:msub>
<mml:mtext mathvariant="bold-italic">T</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="italic">current</mml:mtext></mml:mrow></mml:msub>
<mml:mo>+</mml:mo>
<mml:msub>
<mml:mtext mathvariant="bold-italic">T</mml:mtext>
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="italic">est</mml:mtext>
<mml:mtext mathvariant="italic">i</mml:mtext></mml:msub></mml:mrow></mml:msub>
<mml:mo>.</mml:mo></mml:mrow></mml:semantics></mml:math></disp-formula></p>
<p>Here, <bold><italic>T</italic></bold><italic><sub>current</sub></italic> is the current time. In what follows, we describe how to calculate <bold><italic>T</italic></bold><italic><sub>esti</sub></italic>.</p>
<p>First, let us denote <bold><italic>T</italic></bold><italic><sub>avei</sub></italic> as the average interval for fixed node <bold><italic>i</italic></bold> that mobile nodes connect to <bold><italic>i</italic></bold>. By using this value, we can derive the following equation:
<disp-formula id="FD6">
<label>(6)</label>
<mml:math id="mm7" display="block">
<mml:semantics id="sm7">
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="bold-italic">T</mml:mtext>
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="italic">est</mml:mtext>
<mml:mtext mathvariant="italic">i</mml:mtext></mml:msub></mml:mrow></mml:msub>
<mml:mo>=</mml:mo>
<mml:msub>
<mml:mtext mathvariant="bold-italic">N</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="italic">req</mml:mtext></mml:mrow></mml:msub>
<mml:mo>⋅</mml:mo>
<mml:msub>
<mml:mtext mathvariant="bold-italic">T</mml:mtext>
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="italic">ave</mml:mtext>
<mml:mtext mathvariant="italic">i</mml:mtext></mml:msub></mml:mrow></mml:msub>
<mml:mo>.</mml:mo></mml:mrow></mml:semantics></mml:math></disp-formula></p>
<p>In order to calculate <bold><italic>T</italic></bold><italic><sub>avei</sub></italic>, we define <italic>sensing cycle</italic> of a mobile node engaged in a sensing operation in <bold><italic>T</italic></bold><italic><sub>i</sub></italic>. The <italic>sensing cycle</italic> is defined as the sequence of a sensing operation in which the mobile node departs from the fixed node in the region including the previous sensing point, moves to the sensing point, performs the sensing operation, and moves to fixed node <bold><italic>i</italic></bold>. We also define the <italic>average sensing cycle time</italic> <bold><italic>T</italic></bold><italic><sub>cycle</sub></italic> as the average time elapsed for a sensing cycle of a mobile node that performs a sensing operation. Here, since the moving path to the fixed node which has charge of the destination (described in Subsection 3.2) can be roughly approximated as the straight line, we assume that mobile nodes go straight to the fixed node (do not go through fixed nodes in the neighboring territories) in order to simplify the calculation. Actually, the effect of the difference of moving to the analysis is small.</p>
<p>As an example, we assume a mobile node in <xref ref-type="fig" rid="f10-sensors-09-00327">Figure 10</xref> which departs from fixed node <bold><italic>F</italic></bold> and performs a sensing operation in <bold><italic>T</italic></bold><italic><sub>B</sub></italic>. First, since the distance between fixed nodes <bold><italic>F</italic></bold> and <bold><italic>B</italic></bold> is |<bold>L</bold><italic><sub>F</sub></italic> − <bold>L</bold><italic><sub>B</sub></italic>|, the time elapsed for moving to fixed node <bold><italic>B</italic></bold> (<bold><italic>T</italic></bold><italic><sub>movB</sub></italic>) becomes |<bold>L</bold><italic><sub>F</sub></italic> − <bold>L</bold><italic><sub>B</sub></italic>|/<bold><italic>υ</italic></bold><italic><sub>m</sub></italic>. Next, the time elapsed for moving from fixed node <bold><italic>B</italic></bold> to the destination (sensing point) is |<bold>L</bold><italic><sub>B</sub></italic> − <bold>d</bold><italic><sub>B</sub></italic>|/<bold><italic>υ</italic></bold><italic><sub>m</sub></italic>. Finally, after the sensing operation at a destination (elapsed time is <bold><italic>T</italic></bold><italic><sub>acq</sub></italic>), the time elapsed for moving back to fixed node <bold><italic>B</italic></bold> becomes |<bold>d</bold><italic><sub>B</sub></italic> − <bold>L</bold><italic><sub>B</sub></italic>|/<bold><italic>υ</italic></bold><italic><sub>m</sub></italic>. Thus, the total time elapsed of the sensing cycle becomes:
<disp-formula id="FD7">
<label>(7)</label>
<mml:math id="mm8" display="block">
<mml:semantics id="sm8">
<mml:mrow>
<mml:mfrac>
<mml:mrow>
<mml:mrow>
<mml:mo>|</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi mathvariant="bold">L</mml:mi>
<mml:mtext mathvariant="italic">F</mml:mtext></mml:msub>
<mml:mo>−</mml:mo>
<mml:msub>
<mml:mi mathvariant="bold">L</mml:mi>
<mml:mtext mathvariant="italic">B</mml:mtext></mml:msub></mml:mrow>
<mml:mo>|</mml:mo></mml:mrow></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi>υ</mml:mi>
<mml:mtext mathvariant="italic">m</mml:mtext></mml:msub></mml:mrow></mml:mfrac>
<mml:mo>+</mml:mo>
<mml:mfrac>
<mml:mrow>
<mml:mrow>
<mml:mo>|</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi mathvariant="bold">L</mml:mi>
<mml:mtext mathvariant="italic">B</mml:mtext></mml:msub>
<mml:mo>−</mml:mo>
<mml:msub>
<mml:mi mathvariant="bold">d</mml:mi>
<mml:mtext mathvariant="italic">B</mml:mtext></mml:msub></mml:mrow>
<mml:mo>|</mml:mo></mml:mrow></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi>υ</mml:mi>
<mml:mtext mathvariant="italic">m</mml:mtext></mml:msub></mml:mrow></mml:mfrac>
<mml:mo>+</mml:mo>
<mml:msub>
<mml:mtext mathvariant="bold-italic">T</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="italic">acq</mml:mtext></mml:mrow></mml:msub>
<mml:mo>+</mml:mo>
<mml:mfrac>
<mml:mrow>
<mml:mrow>
<mml:mo>|</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi mathvariant="bold">d</mml:mi>
<mml:mtext mathvariant="italic">B</mml:mtext></mml:msub>
<mml:mo>−</mml:mo>
<mml:msub>
<mml:mi>L</mml:mi>
<mml:mtext mathvariant="italic">B</mml:mtext></mml:msub></mml:mrow>
<mml:mo>|</mml:mo></mml:mrow></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi>υ</mml:mi>
<mml:mtext mathvariant="italic">m</mml:mtext></mml:msub></mml:mrow></mml:mfrac>
<mml:mo>=</mml:mo>
<mml:mfrac>
<mml:mrow>
<mml:mrow>
<mml:mo>|</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi mathvariant="bold">L</mml:mi>
<mml:mtext mathvariant="italic">F</mml:mtext></mml:msub>
<mml:mo>−</mml:mo>
<mml:msub>
<mml:mi mathvariant="bold">L</mml:mi>
<mml:mtext mathvariant="italic">B</mml:mtext></mml:msub></mml:mrow>
<mml:mo>|</mml:mo></mml:mrow></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi>υ</mml:mi>
<mml:mtext mathvariant="italic">m</mml:mtext></mml:msub></mml:mrow></mml:mfrac>
<mml:mo>+</mml:mo>
<mml:msub>
<mml:mtext mathvariant="bold-italic">T</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="italic">acq</mml:mtext></mml:mrow></mml:msub>
<mml:mo>+</mml:mo>
<mml:mn>2</mml:mn>
<mml:mo>⋅</mml:mo>
<mml:mfrac>
<mml:mrow>
<mml:mrow>
<mml:mo>|</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi mathvariant="bold">d</mml:mi>
<mml:mtext mathvariant="italic">B</mml:mtext></mml:msub>
<mml:mo>−</mml:mo>
<mml:msub>
<mml:mi mathvariant="bold">L</mml:mi>
<mml:mtext mathvariant="italic">B</mml:mtext></mml:msub></mml:mrow>
<mml:mo>|</mml:mo></mml:mrow></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi>υ</mml:mi>
<mml:mtext mathvariant="italic">m</mml:mtext></mml:msub></mml:mrow></mml:mfrac></mml:mrow></mml:semantics></mml:math></disp-formula></p>
<p>Here, since each mobile node randomly chooses the destination in the whole area, the average elapsed time for moving between fixed node <bold><italic>B</italic></bold> and the destination <bold>d</bold><italic><sub>B</sub></italic> becomes the average of the moving time form <bold>L</bold><italic><sub>B</sub></italic> to any location in <bold>T</bold><italic><sub>B</sub></italic>. Due to the same reason, the probability that a mobile node departs from fixed node <bold><italic>F</italic></bold> depends on the ratio of the size of <bold>T</bold><italic><sub>F</sub></italic> (|<bold>T</bold><italic><sub>F</sub></italic><bold><italic>|</italic></bold>) to the size of the whole area (<bold><italic>S</italic></bold><italic><sub>area</sub></italic>). Thus, the average time which a mobile node departs from any fixed node (other than <bold><italic>B</italic></bold>) and moves to fixed node <bold><italic>B</italic></bold> becomes:
<disp-formula id="FD8">
<label>(8)</label>
<mml:math id="mm9" display="block">
<mml:semantics id="sm9">
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="bold-italic">T</mml:mtext>
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="italic">mov</mml:mtext>
<mml:mtext mathvariant="italic">B</mml:mtext></mml:msub></mml:mrow></mml:msub>
<mml:mo>=</mml:mo>
<mml:munder>
<mml:mo>∑</mml:mo>
<mml:mrow>
<mml:mtext mathvariant="italic">j</mml:mtext>
<mml:mo>∈</mml:mo>
<mml:msub>
<mml:mtext mathvariant="bold">S</mml:mtext>
<mml:mtext mathvariant="italic">F</mml:mtext></mml:msub>
<mml:mo>,</mml:mo>
<mml:mtext mathvariant="italic">j</mml:mtext>
<mml:mo>≠</mml:mo>
<mml:mtext mathvariant="italic">B</mml:mtext></mml:mrow></mml:munder>
<mml:mrow>
<mml:mfrac>
<mml:mrow>
<mml:mrow>
<mml:mo>|</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi mathvariant="bold">T</mml:mi>
<mml:mtext mathvariant="italic">j</mml:mtext></mml:msub></mml:mrow>
<mml:mo>|</mml:mo></mml:mrow></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi mathvariant="bold-italic">S</mml:mi>
<mml:mrow>
<mml:mtext mathvariant="italic">area</mml:mtext></mml:mrow></mml:msub></mml:mrow></mml:mfrac>
<mml:mo>⋅</mml:mo>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:mfrac>
<mml:mrow>
<mml:mrow>
<mml:mo>|</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi mathvariant="bold">L</mml:mi>
<mml:mtext mathvariant="italic">j</mml:mtext></mml:msub>
<mml:mo>−</mml:mo>
<mml:msub>
<mml:mi mathvariant="bold">L</mml:mi>
<mml:mtext mathvariant="italic">B</mml:mtext></mml:msub></mml:mrow>
<mml:mo>|</mml:mo></mml:mrow></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi>υ</mml:mi>
<mml:mtext mathvariant="italic">m</mml:mtext></mml:msub></mml:mrow></mml:mfrac></mml:mrow>
<mml:mo>)</mml:mo></mml:mrow></mml:mrow>
<mml:mo>.</mml:mo></mml:mrow></mml:semantics></mml:math></disp-formula></p>
<p>Therefore, the <italic>average sensing cycle time</italic> in <bold>T</bold><italic><sub>i</sub></italic> (<bold><italic>T</italic></bold><italic><sub>cyclei</sub></italic>) is derived by the following equation:
<disp-formula id="FD9">
<label>(9)</label>
<mml:math id="mm10" display="block">
<mml:semantics id="sm10">
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="bold-italic">T</mml:mtext>
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="italic">cycle</mml:mtext>
<mml:mtext mathvariant="italic">i</mml:mtext></mml:msub></mml:mrow></mml:msub>
<mml:mo>=</mml:mo>
<mml:munder>
<mml:mo>∑</mml:mo>
<mml:mrow>
<mml:mtext mathvariant="italic">j</mml:mtext>
<mml:mo>∈</mml:mo>
<mml:msub>
<mml:mtext>S</mml:mtext>
<mml:mtext mathvariant="italic">F</mml:mtext></mml:msub>
<mml:mo>,</mml:mo>
<mml:mtext mathvariant="italic">j</mml:mtext>
<mml:mo>≠</mml:mo>
<mml:mtext mathvariant="italic">i</mml:mtext></mml:mrow></mml:munder>
<mml:mrow>
<mml:mfrac>
<mml:mrow>
<mml:mrow>
<mml:mo>|</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="bold">T</mml:mtext>
<mml:mtext mathvariant="italic">j</mml:mtext></mml:msub></mml:mrow>
<mml:mo>|</mml:mo></mml:mrow></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi mathvariant="bold-italic">S</mml:mi>
<mml:mrow>
<mml:mtext mathvariant="italic">area</mml:mtext></mml:mrow></mml:msub></mml:mrow></mml:mfrac>
<mml:mo>⋅</mml:mo>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:mfrac>
<mml:mrow>
<mml:mrow>
<mml:mo>|</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi mathvariant="bold">L</mml:mi>
<mml:mtext mathvariant="italic">i</mml:mtext></mml:msub>
<mml:mo>−</mml:mo>
<mml:msub>
<mml:mi mathvariant="bold">L</mml:mi>
<mml:mtext mathvariant="italic">j</mml:mtext></mml:msub></mml:mrow>
<mml:mo>|</mml:mo></mml:mrow></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi>υ</mml:mi>
<mml:mtext mathvariant="italic">m</mml:mtext></mml:msub></mml:mrow></mml:mfrac></mml:mrow>
<mml:mo>)</mml:mo></mml:mrow>
<mml:mo>+</mml:mo>
<mml:msub>
<mml:mi mathvariant="bold-italic">T</mml:mi>
<mml:mrow>
<mml:mtext mathvariant="italic">acq</mml:mtext></mml:mrow></mml:msub>
<mml:mo>+</mml:mo>
<mml:mn>2</mml:mn>
<mml:mo>⋅</mml:mo>
<mml:mfrac>
<mml:mrow>
<mml:mtext mathvariant="bold-italic">ave</mml:mtext>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:mrow>
<mml:mo>|</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi mathvariant="bold">d</mml:mi>
<mml:mtext mathvariant="italic">i</mml:mtext></mml:msub>
<mml:mo>−</mml:mo>
<mml:msub>
<mml:mi mathvariant="bold">L</mml:mi>
<mml:mtext mathvariant="italic">i</mml:mtext></mml:msub></mml:mrow>
<mml:mo>|</mml:mo></mml:mrow></mml:mrow>
<mml:mo>)</mml:mo></mml:mrow></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi>υ</mml:mi>
<mml:mtext mathvariant="italic">m</mml:mtext></mml:msub></mml:mrow></mml:mfrac></mml:mrow>
<mml:mo>.</mml:mo></mml:mrow></mml:semantics></mml:math></disp-formula></p>
<p>Since a mobile node chooses its destination randomly from the whole area, the probability that a mobile node chooses the destination in <bold>T</bold><italic><sub>i</sub></italic> becomes the ratio of the size of <bold>T</bold><italic><sub>i</sub></italic> (|<bold>T</bold><italic><sub>i</sub></italic>|) to the size of the whole area (<bold><italic>S</italic></bold><italic><sub>area</sub></italic>). Thus, the average sensing cycle time in the whole area (<bold><italic>T</italic></bold><italic><sub>cycle</sub></italic>) is derived by the average of the <bold><italic>T</italic></bold><italic><sub>cyclei</sub></italic> for all <bold><italic>i</italic></bold>s.</p>
<disp-formula id="FD10">
<label>(10)</label>
<mml:math id="mm11" display="block">
<mml:semantics id="sm11">
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="bold-italic">T</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="italic">cycle</mml:mtext></mml:mrow></mml:msub>
<mml:mo>=</mml:mo>
<mml:munder>
<mml:mo>∑</mml:mo>
<mml:mrow>
<mml:mtext mathvariant="italic">j</mml:mtext>
<mml:mo>∈</mml:mo>
<mml:msub>
<mml:mtext>S</mml:mtext>
<mml:mtext>F</mml:mtext></mml:msub></mml:mrow></mml:munder>
<mml:mrow>
<mml:mfrac>
<mml:mrow>
<mml:mrow>
<mml:mo>|</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="bold">T</mml:mtext>
<mml:mtext mathvariant="italic">i</mml:mtext></mml:msub></mml:mrow>
<mml:mo>|</mml:mo></mml:mrow></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi mathvariant="bold-italic">S</mml:mi>
<mml:mrow>
<mml:mtext mathvariant="italic">area</mml:mtext></mml:mrow></mml:msub></mml:mrow></mml:mfrac>
<mml:mo>⋅</mml:mo>
<mml:msub>
<mml:mi mathvariant="bold-italic">T</mml:mi>
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="italic">cycle</mml:mtext>
<mml:mtext mathvariant="italic">i</mml:mtext></mml:msub></mml:mrow></mml:msub></mml:mrow>
<mml:mo>.</mml:mo></mml:mrow></mml:semantics></mml:math></disp-formula>
<p>Since the mobile node connects to the fixed node after the sensing operation, all mobile nodes connect to a fixed node in the period of <bold><italic>T</italic></bold><italic><sub>cycle</sub></italic>. Furthermore, since the number of mobile nodes which choose the destination in <bold>T</bold><italic><sub>i</sub></italic> is <bold><italic>N</italic></bold><italic><sub>mov</sub></italic> · |<bold>T</bold><italic><sub>i</sub></italic>|/<bold><italic>S</italic></bold><italic><sub>area</sub></italic>, we can estimate that <bold><italic>N</italic></bold><italic><sub>mov</sub></italic> · |<bold>T</bold><italic><sub>i</sub></italic>|/<bold><italic>S</italic></bold><italic><sub>area</sub></italic> mobile nodes connect to fixed node <bold><italic>i</italic></bold> in the period of <bold><italic>T</italic></bold><italic><sub>cycle</sub></italic>. Thus, the average time in which a mobile node connects to fixed node <bold><italic>i</italic></bold> (<bold><italic>T</italic></bold><italic><sub>avei</sub></italic>) is calculated by the following equation:
<disp-formula id="FD11">
<label>(11)</label>
<mml:math id="mm12" display="block">
<mml:semantics id="sm12">
<mml:mrow>
<mml:mtable columnalign="left">
<mml:mtr columnalign="left">
<mml:mtd columnalign="left">
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="bold-italic">T</mml:mtext>
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="italic">ave</mml:mtext>
<mml:mtext mathvariant="italic">i</mml:mtext></mml:msub></mml:mrow></mml:msub></mml:mrow></mml:mtd>
<mml:mtd columnalign="left">
<mml:mrow>
<mml:mo>=</mml:mo>
<mml:mfrac>
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="bold-italic">T</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="italic">cycle</mml:mtext></mml:mrow></mml:msub></mml:mrow>
<mml:mrow>
<mml:mfrac>
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="bold-italic">N</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="italic">mov</mml:mtext></mml:mrow></mml:msub>
<mml:mo>⋅</mml:mo>
<mml:mrow>
<mml:mo>|</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="bold">T</mml:mtext>
<mml:mtext mathvariant="italic">i</mml:mtext></mml:msub></mml:mrow>
<mml:mo>|</mml:mo></mml:mrow></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="bold-italic">S</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="italic">area</mml:mtext></mml:mrow></mml:msub></mml:mrow></mml:mfrac></mml:mrow></mml:mfrac></mml:mrow></mml:mtd></mml:mtr>
<mml:mtr columnalign="left">
<mml:mtd columnalign="left"/>
<mml:mtd columnalign="left">
<mml:mrow>
<mml:mo>=</mml:mo>
<mml:mfrac>
<mml:mrow>
<mml:msub>
<mml:mi mathvariant="bold-italic">T</mml:mi>
<mml:mrow>
<mml:mtext mathvariant="italic">cycle</mml:mtext></mml:mrow></mml:msub>
<mml:mo>⋅</mml:mo>
<mml:msub>
<mml:mtext mathvariant="bold-italic">S</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="italic">area</mml:mtext></mml:mrow></mml:msub></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="bold-italic">N</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="italic">mov</mml:mtext></mml:mrow></mml:msub>
<mml:mo>⋅</mml:mo>
<mml:mrow>
<mml:mo>|</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi mathvariant="bold">T</mml:mi>
<mml:mtext mathvariant="italic">i</mml:mtext></mml:msub></mml:mrow>
<mml:mo>|</mml:mo></mml:mrow></mml:mrow></mml:mfrac>
<mml:mo>.</mml:mo></mml:mrow></mml:mtd></mml:mtr></mml:mtable></mml:mrow></mml:semantics></mml:math></disp-formula></p>
<p>Based on the above discussion, the time limit (<bold><italic>T</italic><sub>lim</sub></bold><italic><sub>i</sub></italic>) can be calculated by the following equation:
<disp-formula id="FD12">
<label>(12)</label>
<mml:math id="mm13" display="block">
<mml:semantics id="sm13">
<mml:mrow>
<mml:mtable columnalign="left">
<mml:mtr columnalign="left">
<mml:mtd columnalign="left">
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="bold-italic">T</mml:mtext>
<mml:mrow>
<mml:msub>
<mml:mtext>lim</mml:mtext>
<mml:mtext mathvariant="italic">i</mml:mtext></mml:msub></mml:mrow></mml:msub></mml:mrow></mml:mtd>
<mml:mtd columnalign="left">
<mml:mrow>
<mml:mo>=</mml:mo>
<mml:msub>
<mml:mtext mathvariant="bold-italic">T</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="italic">current</mml:mtext></mml:mrow></mml:msub>
<mml:mo>+</mml:mo>
<mml:msub>
<mml:mtext mathvariant="bold-italic">T</mml:mtext>
<mml:mrow>
<mml:mi>e</mml:mi>
<mml:mi>s</mml:mi>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mtext mathvariant="italic">i</mml:mtext></mml:msub></mml:mrow></mml:msub></mml:mrow></mml:mtd></mml:mtr>
<mml:mtr columnalign="left">
<mml:mtd columnalign="left"/>
<mml:mtd columnalign="left">
<mml:mrow>
<mml:mo>=</mml:mo>
<mml:msub>
<mml:mtext mathvariant="bold-italic">T</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="italic">current</mml:mtext></mml:mrow></mml:msub>
<mml:mo>+</mml:mo>
<mml:msub>
<mml:mtext mathvariant="bold-italic">N</mml:mtext>
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="italic">req</mml:mtext>
<mml:mtext mathvariant="italic">i</mml:mtext></mml:msub></mml:mrow></mml:msub>
<mml:mo>⋅</mml:mo>
<mml:msub>
<mml:mtext mathvariant="bold-italic">T</mml:mtext>
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="italic">ave</mml:mtext>
<mml:mtext mathvariant="italic">i</mml:mtext></mml:msub></mml:mrow></mml:msub></mml:mrow></mml:mtd></mml:mtr>
<mml:mtr columnalign="left">
<mml:mtd columnalign="left"/>
<mml:mtd columnalign="left">
<mml:mrow>
<mml:mo>=</mml:mo>
<mml:msub>
<mml:mi mathvariant="bold-italic">T</mml:mi>
<mml:mrow>
<mml:mi mathvariant="italic">current</mml:mi></mml:mrow></mml:msub>
<mml:mo>+</mml:mo>
<mml:msub>
<mml:mtext mathvariant="bold-italic">N</mml:mtext>
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="italic">req</mml:mtext>
<mml:mtext mathvariant="italic">i</mml:mtext></mml:msub></mml:mrow></mml:msub>
<mml:mo>⋅</mml:mo>
<mml:mfrac>
<mml:mrow>
<mml:msub>
<mml:mi mathvariant="bold-italic">T</mml:mi>
<mml:mrow>
<mml:mtext mathvariant="italic">cycle</mml:mtext></mml:mrow></mml:msub>
<mml:mo>⋅</mml:mo>
<mml:msub>
<mml:mtext mathvariant="bold-italic">S</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="italic">area</mml:mtext></mml:mrow></mml:msub></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="bold-italic">N</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="italic">mov</mml:mtext></mml:mrow></mml:msub>
<mml:mo>⋅</mml:mo>
<mml:mrow>
<mml:mo>|</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi mathvariant="bold">T</mml:mi>
<mml:mi>i</mml:mi></mml:msub></mml:mrow>
<mml:mo>|</mml:mo></mml:mrow></mml:mrow></mml:mfrac>
<mml:mo>.</mml:mo></mml:mrow></mml:mtd></mml:mtr></mml:mtable></mml:mrow></mml:semantics></mml:math></disp-formula></p></sec></sec>
<sec sec-type="discussion">
<label>3.4.</label>
<title>Discussions</title>
<p>DATFM can acquire and transfer data efficiently due to the following features:</p>
<list list-type="bullet">
<list-item>
<p>The source node can collect mobile nodes easily since each mobile node travels around the fixed nodes as described in Subsection 3.2.</p></list-item>
<list-item>
<p>Since each mobile node transmits the acquired data to the nearest fixed node, it can store new data more frequently.</p></list-item>
<list-item>
<p>Since the accumulated data are transmitted by using multiple mobile nodes, the data can reach to the sink node easily even in a wide area.</p></list-item>
<list-item>
<p>By applying train transmission, the source node can transmit the accumulated data even when the distance between the source and destination nodes is long.</p></list-item></list>
<p>Here, as described in Subsection 3.1, DATFM assumes a flat environment where no obstacles exist. However, even when obstacles exist in the area, DATFM can work by letting each fixed node hold the information on obstacles in its territory and adjacent territories. By doing so, the source node of a data transmission process can determine an appropriate communication route considering the obstacles.</p>
<p>In DATFM, fixed nodes have larger memory spaces than mobile nodes. If mobile nodes have same memory spaces as those of fixed nodes, fixed nodes have to start a data transmission process every time they receive data from a single mobile node. In this case, mobile nodes have to move to transfer the data towards the sink node every time they send the acquired data to a fixed node. This may cause the deterioration of the performance of sensing in DATFM. Therefore, we set the size of memory spaces of mobile nodes smaller than those of fixed nodes in order to balance the efficiencies of data transfer and sensing.</p>
<p>As described in Subsection 3.3.3, the source node sends a <italic>RReq</italic> with <bold><italic>N</italic></bold><italic><sub>req</sub></italic>, which is the number of mobile nodes required to construct a communication route. Here, when a mobile node is performing a sensing operation in the territory of the source node, it will certainly connect to the source node. Also, the source node knows such nodes since all mobile nodes in the territory certainly connect to the fixed node which has charge of the destination before starting a sensing operation. Thus, the source node can decrease <bold><italic>N</italic></bold><italic><sub>req</sub></italic> considering mobile nodes which are performing sensing operation in its territory. However, DATFM does not decrease <bold><italic>N</italic></bold><italic><sub>req</sub></italic> in order to certainly construct a communication route even in a case that node failures occur.</p>
<p>In addition, the source node sends a <italic>RReq</italic> only to the mobile node which firstly connects after starting the data transmission process. Then, the source node starts a train transmission when the second mobile node connects. Here, if the source node sends <italic>RReq</italic>s to multiple mobile nodes it might be able to collect <bold><italic>N</italic></bold><italic><sub>req</sub></italic> mobile nodes in a shorter time. However, the source node does not do so because it becomes difficult to correctly manage <bold><italic>N</italic></bold><italic><sub>req</sub></italic>. For example, when another mobile node (node <bold><italic>b</italic></bold>) connects to the source node after the source node has sent a <italic>RReq</italic> to a mobile node (node <bold><italic>a</italic></bold>), the source node cannot set the appropriate <bold><italic>N</italic></bold><italic><sub>req</sub></italic> for node <bold><italic>b</italic></bold> since it cannot know the number of mobile nodes collected by node <bold><italic>a</italic></bold>. Moreover, the main task of a mobile node in <italic>CM</italic> is to request the nearly fixed nodes to collect other mobile nodes. This is because a single mobile node has a little chance to connect to another mobile node in a sparse network. Even if the source node sends <italic>RReq</italic>s to multiple mobile nodes, the effect will be little. Therefore, DATFM starts the train transmission when the second mobile node connects to the source node in order to improve the efficiency of data transmission.</p></sec></sec>
<sec>
<label>4.</label>
<title>Performance evaluation</title>
<p>In this section, we show results of simulation experiments regarding performance evaluation of DATFM. In the simulation experiments, we compare the performances of DATFM, UM with random way point model [<xref ref-type="bibr" rid="b9-sensors-09-00327">9</xref>], and RAMOS [<xref ref-type="bibr" rid="b7-sensors-09-00327">7</xref>,<xref ref-type="bibr" rid="b8-sensors-09-00327">8</xref>].</p>
<sec>
<label>4.1.</label>
<title>Simulation environment</title>
<p>In the simulation experiments, we assume a vast agricultural farm in which each sensor acquires pictures or movies of the crops. Sensor nodes are deployed in a 1,000[m]×1,000[m] flatland. Each sensor node performs a sensing operation with the rate of 100 [<bold><italic>bit/sec</italic>·<italic>m</italic><sup>2</sup></bold>] and <bold><italic>T</italic></bold><italic><sub>acq</sub></italic> is 30 [sec]. The wireless communication range of all nodes and the channel bandwidth are <bold><italic>R</italic></bold><italic><sub>com</sub></italic> [m] and 2 [Mbps], respectively.</p>
<p>In DATFM, there are 10 fixed nodes and 40 mobile nodes. Each mobile node moves with velocity of <bold><italic>υ</italic></bold><italic><sub>m</sub></italic> [m/s] in <italic>SM</italic> and <bold>2<italic>υ</italic></bold><italic><sub>m</sub></italic> [m/s] in <italic>TM</italic> and <italic>CM</italic>. Each fixed and mobile node has a memory space whose size is 2,000 [Mbit] and 10 [Mbit], respectively. Each fixed node starts data transmission when the amount of the accumulated data exceeds 800 [Mbit]. Each mobile node performs a sensing operation every time it arrives the destination. Each fixed node performs a sensing operation every 1,500 [sec]. The rate and the duration of a sensing operation by a fixed node are also 100 [<bold><italic>bit/sec</italic>·<italic>m</italic><sup>2</sup></bold>] and 30 [sec].</p>
<p>In RAMOS, there are 10 nodes in category1 (fixed), (40 - 10) nodes in category2 (moving), and 10 nodes in category3 (transmitting). This parameter setting is to make the total number of nodes in category2 and category3 in RAMOS equal to 40 and to guarantee all nodes in category1 can transfer data to the sink node by using nodes in category3. Nodes in category1 have a memory space of 1,000 [Mbit]. Nodes in category2 and category3 have a memory space of 10 [Mbit]. Nodes in category2 and category3 move with the velocity of <bold><italic>υ</italic></bold><italic><sub>m</sub></italic> [m/s] when sensing and gathering data, and <bold>2<italic>υ</italic></bold><italic><sub>m</sub></italic> [m/s] when transmitting data to the sink node. The nodes in category1 perform a sensing operation every 1,500 [sec] in the same way as fixed nodes in DATFM.</p>
<p>In UM, there are (40 + 10) UM nodes. Each UM node has a memory space of 10 [Mbit]. Each node moves with velocity of <bold><italic>υ</italic></bold><italic><sub>m</sub></italic> [m/s] when sensing, and <bold>2<italic>υ</italic></bold><italic><sub>m</sub></italic> [m/s] when transferring data. Each UM node starts transferring data to the sink node when the amount of the accumulated data exceeds 10 [Mbit] (i.e. each node transfers data after a sensing operation).</p>
<p>We set parameters <bold><italic>R</italic></bold><italic><sub>com</sub></italic> and <bold><italic>υ</italic></bold><italic><sub>m</sub></italic> as shown in <xref ref-type="table" rid="t2-sensors-09-00327">Table 2</xref>. In the experiments, we change one of the parameters and set others as default values in order to verify the effect of each parameter. In this environment, we evaluate the following four criteria during 60,000 [sec]:</p>
<list list-type="bullet">
<list-item>
<p>Throughput</p>
<p>The amount of data that arrive at the sink node per 1[sec].</p></list-item>
<list-item>
<p>Average moving distance</p>
<p>The average of moving distances of all mobile nodes (i.e. all mobile nodes in DATFM, all nodes except those in category1 in RAMOS, and all nodes in UM) during the simulation period.</p></list-item>
<list-item>
<p>Average delay</p>
<p>The average of the elapsed time after data are acquired until the data arrive at the sink node.</p></list-item>
<list-item>
<p>Control traffic</p>
<p>The number of packets to control sensor nodes during the simulation period. Specifically, in DATFM, the total number of <italic>RReq</italic>s, <italic>RCReq</italic>s, and <italic>RRel</italic>s sent by nodes becomes the control traffic. On the other hand, the control traffic in RAMOS is the total number of packets sent from nodes in</p></list-item></list></sec>
<sec>
<label>4.2.</label>
<title>Effects of the velocity of node</title>
<p><xref ref-type="fig" rid="f11-sensors-09-00327">Figures 11</xref>, <xref ref-type="fig" rid="f12-sensors-09-00327">12</xref>, <xref ref-type="fig" rid="f13-sensors-09-00327">13</xref> and <xref ref-type="fig" rid="f15-sensors-09-00327">15</xref> show the simulation results changing parameter <bold><italic>υ</italic></bold><italic><sub>m</sub></italic>. The horizontal axis on all graphs indicates the velocity of sensor nodes <bold><italic>υ</italic></bold><italic><sub>m</sub></italic>. The vertical axis indicates throughput in <xref ref-type="fig" rid="f11-sensors-09-00327">Figure 11</xref>, average moving distance in <xref ref-type="fig" rid="f12-sensors-09-00327">Figure 12</xref>, average delay in <xref ref-type="fig" rid="f13-sensors-09-00327">Figure 13</xref>, and control traffic in <xref ref-type="fig" rid="f15-sensors-09-00327">Figure 15</xref>.</p>
<sec>
<label>4.2.1.</label>
<title>Throughput</title>
<p><xref ref-type="fig" rid="f11-sensors-09-00327">Figure 11</xref> shows that the throughput in DATFM is always larger than those in RAMOS and UM. This is because DATFM can acquire and transfer data more efficiently than RAMOS and UM. As <bold><italic>υ</italic></bold><italic><sub>m</sub></italic> increases, the difference in throughput between DATFM and RAMOS gets larger. Mobile nodes in DATFM transfer the acquired data to a nearby fixed node while mobile nodes in RAMOS transfer data to the sink node every time they acquired data. Therefore, mobile nodes in DATFM can return to perform sensing operation more quickly than those in RAMOS especially when the mobile nodes move with higher speed.</p>
<p>On the other hand, the difference in throughput between DATFM and UM gets smaller as <bold><italic>υ</italic></bold><italic><sub>m</sub></italic> increases. This is because the number of mobile nodes in DATFM (40) is smaller than that in UM (40 + 10). Thus, UM is more affected by the velocity of nodes than DATFM.</p></sec>
<sec>
<label>4.2.2.</label>
<title>Average moving distance</title>
<p><xref ref-type="fig" rid="f12-sensors-09-00327">Figure 12</xref> shows that the moving distances in all methods increase as <bold><italic>υ</italic></bold><italic><sub>m</sub></italic> gets larger, which is an obvious result. In addition, the moving distance in DATFM is smaller than those in RAMOS and UM. This is because sensor nodes in RAMOS and UM move to the sink node every time they acquire data. On the other hand, since DATFM accumulates the acquired data on a fixed node before transmitting them to the sink node, the mobile node that acquires the data does not need to move to the sink node.</p>
<p>Furthermore, the difference in the moving distance between three methods increases as <bold><italic>υ</italic></bold><italic><sub>m</sub></italic> gets larger. This is because the mobile nodes in all methods can perform much sensing operations as <bold><italic>υ</italic></bold><italic><sub>m</sub></italic> gets larger, and thus, the numbers of movements between the sensing point of each sensor nodes and the sink node in RAMOS and UM become larger.</p></sec>
<sec>
<label>4.2.3.</label>
<title>Average delay</title>
<p><xref ref-type="fig" rid="f13-sensors-09-00327">Figure 13</xref> shows that the delay for transmitting data in DATFM is always larger than those in RAMOS and UM. This is because DATFM needs much time for accumulating data on fixed nodes. On the other hand, the average delays in the other methods do not change even when the number of mobile nodes increases. This is because the mobile nodes in these methods transfer data without accumulating data. As <bold><italic>υ</italic></bold><italic><sub>m</sub></italic> increases, average delays of all methods decrease. This is obvious since each sensor node can transfer data faster.</p>
<p><xref ref-type="fig" rid="f14-sensors-09-00327">Figure 14</xref> shows the details of delay in DATFM. In this figure, the delivery time is the time period after a mobile node acquires data until it connects to a fixed node. The accumulated time is the time period during which the data are stored at a fixed node. The transmission time is the time elapsed for transmitting the accumulated data to the destination node after the amount of data accumulated on a fixed node exceeds the threshold. From this result, the delay consists mostly of accumulated time. The accumulated time can be suppressed by controlling the threshold at each fixed node. However, since a small threshold causes highly frequent data transmissions, the efficiency of sensing may become low.</p>
<p>Thus, the threshold should be appropriately set according to the system parameters and requirements When <bold><italic>υ</italic></bold><italic><sub>m</sub></italic> is very small, the accumulated time becomes much larger because, mobile nodes spend much time to transfer the acquired data to the fixed node. This makes the rate of data accumulation low. Moreover, the delivery time decreases when <bold><italic>υ</italic></bold><italic><sub>m</sub></italic> increases, which is an obvious result.</p></sec>
<sec>
<label>4.2.4.</label>
<title>Control traffic</title>
<p><xref ref-type="fig" rid="f15-sensors-09-00327">Figure 15</xref> shows that the control traffic in DATFM is smaller than that in RAMOS. This is due to the difference of frequency of data transmissions between DATFM and RAMOS. Specifically, the control traffic in RAMOS occurs every time nodes in category3 connect to those in category2 which hold data. On the other hand, the control traffic in DATFM occurs only when a fixed node starts constructing a communication route.</p></sec></sec>
<sec>
<label>4.3.</label>
<title>Effects of the communication range</title>
<p><xref ref-type="fig" rid="f16-sensors-09-00327">Figures 16</xref>, <xref ref-type="fig" rid="f17-sensors-09-00327">17</xref>, <xref ref-type="fig" rid="f18-sensors-09-00327">18</xref> and <xref ref-type="fig" rid="f20-sensors-09-00327">20</xref> show the simulation results changing parameter <bold><italic>R</italic></bold><italic><sub>com</sub></italic>. The horizontal axis on all graphs indicates the communication range of sensor nodes (<bold><italic>R</italic></bold><italic><sub>com</sub></italic>). The vertical axis indicates throughput in <xref ref-type="fig" rid="f16-sensors-09-00327">Figure 16</xref>, average moving distance in <xref ref-type="fig" rid="f17-sensors-09-00327">Figure 17</xref>, average delay in <xref ref-type="fig" rid="f18-sensors-09-00327">Figure 18</xref>, and control traffic in <xref ref-type="fig" rid="f20-sensors-09-00327">Figure 20</xref>.</p>
<sec>
<label>4.3.1.</label>
<title>Throughput</title>
<p><xref ref-type="fig" rid="f16-sensors-09-00327">Figure 16</xref> shows that the throughputs in all methods get larger as <bold><italic>R</italic></bold><italic><sub>com</sub></italic> increases. This is obvious because the large communication range makes the connectivity high. The difference in throughput between DATFM and RAMOS becomes larger as <bold><italic>R</italic></bold><italic><sub>com</sub></italic> increases. In DATFM, the required number of mobile nodes to construct a communication route decreases. This makes it easy for mobile nodes to return to a sensing operation. On the other hand, the throughput in UM is nearly identical to that in DATFM. This may be due to the following two reasons: a) the number of mobile nodes in DATFM (40) is smaller than that in UM (40+10), and b) the mobile nodes in DATFM can perform sensing operations more frequently than those in UM since they do not move to the sink node to transfer data every time. These are the advantages of UM and DATFM, respectively. In the parameter setting in this subsection, these advantages are balanced out.</p></sec>
<sec>
<label>4.3.2.</label>
<title>Average moving distance</title>
<p><xref ref-type="fig" rid="f17-sensors-09-00327">Figure 17</xref> shows that the moving distances in RAMOS and UM are larger than that in DATFM. This is due to the same reasons as that in <xref ref-type="fig" rid="f12-sensors-09-00327">Figures 12</xref>. In addition, as <bold><italic>R</italic></bold><italic><sub>com</sub></italic> gets larger, the average moving distance in DATFM decreases. This is because the required moving distances between the source and destination nodes in DATFM decrease. Moreover, the increase of the communication range makes the moving distance required for the train transmission smaller.</p>
<p>The moving distance in RAMOS increases as the communication range gets longer until a certain value (about 36[sec]). This is because nodes in category3 have more opportunities to connect to nodes in other categories due to the increase of the communication range. On the other hand, as the communication range gets much larger, the moving distance decreases. This is because the moving distance of nodes in category3 required to transfers the data decreases.</p>
<p>The moving distance in UM decreases as the communication range gets larger. This is obvious because the UM nodes can transfer the acquired data with the shorter distance when the communication range is large.</p></sec>
<sec>
<label>4.3.3.</label>
<title>Average delay</title>
<p><xref ref-type="fig" rid="f18-sensors-09-00327">Figure 18</xref> shows that the delay in DATFM is always larger than those in RAMOS and UM. This is due to the same reasons as that in <xref ref-type="fig" rid="f13-sensors-09-00327">Figures 13</xref>.</p>
<p><xref ref-type="fig" rid="f19-sensors-09-00327">Figure 19</xref> shows the details of delay in DATFM. This result shows that the accumulated time much increases as <bold><italic>R</italic></bold><italic><sub>com</sub></italic> gets smaller. This is because of the increase of the required number of mobile nodes to achieve a data transmission between fixed nodes. When the required number of nodes increases, many mobile nodes tend to keep transferring data between fixed nodes. Therefore, the number of nodes which perform a sensing operation becomes smaller, and thus, the rate of data accumulation on a fixed node becomes low.</p></sec>
<sec>
<label>4.3.4.</label>
<title>Control traffic</title>
<p><xref ref-type="fig" rid="f20-sensors-09-00327">Figure 20</xref> shows that the control traffic in DATFM is smaller than that in RAMOS. This is due to the same reasons as that in <xref ref-type="fig" rid="f15-sensors-09-00327">Figures 15</xref>. In addition, the control traffic in DATFM increases as <bold><italic>R</italic></bold><italic><sub>com</sub></italic> get larger. This is because, the larger the communication range is, the faster the fixed nodes accumulate data. Thus, the frequency of data transmissions becomes high. This can be seen from the small accumulated time in <xref ref-type="fig" rid="f19-sensors-09-00327">Figure 19</xref>.</p>
<p>On the other hand, the control traffic in RAMOS increases as <bold><italic>R</italic></bold><italic><sub>com</sub></italic> gets larger. This is because sensor nodes in category3 have more opportunities to connect to nodes in other categories.</p>
<p>Here, the communication range greatly affects the energy consumed by communication. Thus, in addition to the above criteria, we measure the energy consumed in data transmission processes in DATFM when changing the nodes' communication range. The result is shown in <xref ref-type="fig" rid="f21-sensors-09-00327">Figure 21</xref>.</p></sec>
<sec>
<label>4.3.5.</label>
<title>Energy consumption</title>
<p>As described in the beginning of this subsection, the communication range affects the energy consumed by communication. In addition, the communication range also affects the energy consumed by movement since the moving distance changes according to the communication range as shown in <xref ref-type="fig" rid="f17-sensors-09-00327">Figure 17</xref>. To analyze the effects of communication range to the total energy consumption, we measure the energies consumed by each of communication and movement in data transmission process in DATFM.</p>
<p>In this experiment, we assume that the energy consumed by movement is 1 [J/m], and those consumed by data sending <bold><italic>P</italic></bold><italic><sub>s</sub></italic>(<bold><italic>k, R</italic></bold><italic><sub>com</sub></italic>) and receiving <bold><italic>P</italic></bold><italic><sub>r</sub></italic>(<bold><italic>k</italic></bold>) are represented by the following equations [<xref ref-type="bibr" rid="b17-sensors-09-00327">17</xref>]:
<disp-formula id="FD13">
<label>(13)</label>
<mml:math id="mm14" display="block">
<mml:semantics id="sm14">
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="bold-italic">P</mml:mtext>
<mml:mtext mathvariant="italic">s</mml:mtext></mml:msub>
<mml:mo stretchy="false">(</mml:mo>
<mml:mtext mathvariant="bold-italic">k</mml:mtext>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mtext mathvariant="bold-italic">R</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="italic">com</mml:mtext></mml:mrow></mml:msub>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>=</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:mtext mathvariant="bold-italic">k</mml:mtext>
<mml:mo>⋅</mml:mo>
<mml:mn mathvariant="bold">50</mml:mn>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>+</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:mn mathvariant="bold">0.1</mml:mn>
<mml:mo>⋅</mml:mo>
<mml:mtext mathvariant="bold-italic">k</mml:mtext>
<mml:mo>⋅</mml:mo>
<mml:msub>
<mml:mtext mathvariant="bold-italic">R</mml:mtext>
<mml:mrow>
<mml:mtext mathvariant="italic">com</mml:mtext></mml:mrow></mml:msub>
<mml:mn mathvariant="bold">2</mml:mn>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>.</mml:mo></mml:mrow></mml:semantics></mml:math></disp-formula>
<disp-formula id="FD14">
<label>(14)</label>
<mml:math id="mm15" display="block">
<mml:semantics id="sm15">
<mml:mrow>
<mml:msub>
<mml:mtext mathvariant="bold-italic">P</mml:mtext>
<mml:mi>r</mml:mi></mml:msub>
<mml:mo stretchy="false">(</mml:mo>
<mml:mtext mathvariant="bold-italic">k</mml:mtext>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>=</mml:mo>
<mml:mtext mathvariant="bold-italic">k</mml:mtext>
<mml:mo>⋅</mml:mo>
<mml:mn mathvariant="bold">50</mml:mn>
<mml:mo>.</mml:mo></mml:mrow></mml:semantics></mml:math></disp-formula></p>
<p>Here, <bold><italic>k</italic></bold> [bit] is the size of the transmitted/received data.</p>
<p><xref ref-type="fig" rid="f21-sensors-09-00327">Figure 21</xref> shows the simulation result when changing parameter <bold><italic>R</italic></bold><italic><sub>com</sub></italic>. From this figure, energy consumed by communication increases as the communication range gets larger. In addition, energy consumed by movement also increases as the communication range gets larger. This is because the decrease of the number of mobile nodes to construct the communication route due to the increase of the communication range makes the number of mobile nodes in <italic>SM</italic> larger. In such a case, more data will be accumulated to fixed nodes in a short time, and the frequency of data transmission processes (including train transmission) increases.</p>
<p>Here, this figure also shows that movement of nodes consumes much more energy than communication. This indicates that movement is dominant in power consumption in our assumed environment. As shown in <xref ref-type="fig" rid="f17-sensors-09-00327">Figure 17</xref>, since the average moving distance in DATFM is always smaller than conventional methods, we can confirm that DATFM reduces the total power consumption.</p></sec></sec>
<sec sec-type="conclusions">
<label>4.4.</label>
<title>Summary</title>
<p>From the above results, we can see that DATFM can transfer data with smaller moving distance compared with UM and RAMOS. This means that mobile nodes in UM and RAMOS must move for longer distance in order to transfer the acquired data to the sink node. In mobile sensor networks, the energy consumed by movement is much larger than those by communication and computation [<xref ref-type="bibr" rid="b17-sensors-09-00327">17</xref>, <xref ref-type="bibr" rid="b18-sensors-09-00327">18</xref>]. Therefore, we can see that DATFM achieves both high throughput and energy-efficiency compared with UM and RAMOS.</p>
<p>Moreover, from the results in Subsection 4.3, we can see that the performance of DATFM is affected by the density of nodes in the network. Here, the density also changes when the number of nodes changes. Although the results are not shown in this paper, we have confirmed by some experiments that the number of nodes has the same effect as the communication range.</p></sec></sec>
<sec sec-type="conclusions">
<label>5.</label>
<title>Conclusions</title>
<p>In this paper, we have proposed an effective mobile sensor control method named DATFM for sparse sensor networks. DATFM uses two types of sensor nodes, fixed node and mobile node, and accumulates the acquired data on a fixed node before transferring them to the sink node. In addition, DATFM transmits the accumulated data efficiently by constructing a communication route of mobile nodes between fixed nodes. We have also conducted simulation experiments to evaluate the performance of DATFM. From the results of the experiments, DATFM can acquires and transfers data with smaller moving distance. These results show that DATFM improves the efficiency of sensing and data transmission compared with the conventional methods.</p>
<p>Since each fixed node in DATFM accumulates data generated in its vicinity, the performance of sensing depends on the deployment of fixed nodes. In addition, since the distances between fixed nodes affect the number of required mobile nodes to construct a communication route, the performance of data transfer also depends on the deployment of fixed nodes. Thus, as part of our future work, we plan to discuss the effects of the locations of fixed nodes in order to improve the performance of data transfer.</p>
<p>On the other hand, since mobile nodes cannot sense their target locations when they are transferring the data accumulated by a fixed node, the amount of acquired data tends to decrease in a particular region where data transmissions frequently occur. Such a skew of data acquisition is not desirable in some applications such as planetary explosion and detecting dangerous regions. Thus, we plan to investigate the effects of data transfers in order to achieve the uniform sensing in the whole area while keeping high effectiveness of the data acquisition and transmission.</p>
<p>In DATFM, data transmission is treated as more important than sensing. For example, a mobile node in <italic>SM</italic> which receives a <italic>RCReq</italic> changes its mode into <italic>TM</italic> even when it is performing a sensing operation at its sensing point. However, in some environments, the performance may improve by treating sensing as more important than data transmission. For example, when communication range is large, the required number of mobile nodes for a data transmission process decreases. In such a case, total throughput may be improved when some mobile nodes in <italic>SM</italic> continue sensing operations even when they receive <italic>RCReq</italic>s. Thus, we plan to analyze the effects of the system parameters to the performance, and extend our method to change the behaviors of nodes according to the environment.</p>
<p>Furthermore, in order to adapt to a harsh environment, we also plan to extend our method to handle node failures. Moreover, we plan to examine the effects of difference in memory spaces between mobile and fixed nodes. Finally, we plan to implement our proposed method on real sensor nodes and verify its effectiveness on a practical platform.</p></sec></body>
<back>
<ack>
<p>This research was supported by Scientific Research on Priority Areas (18049050) and Grant-in-Aid for Scientific Research (A)(17200006) of the Ministry of Education, Culture, Sports, Science andTechnology, Japan, and by International Communications Foundation.</p></ack>
<ref-list>
<title>References and Notes</title>
<ref id="b1-sensors-09-00327"><label>1.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Cui</surname><given-names>J.-H.</given-names></name><name><surname>Kong</surname><given-names>J.</given-names></name><name><surname>Gerla</surname><given-names>M.</given-names></name><name><surname>Zhou</surname><given-names>S.</given-names></name></person-group><article-title>The challenges of building mobile underwater wireless networks for aquatic applications</article-title><source>IEEE Netw</source><year>2006</year><volume>20</volume><fpage>12</fpage><lpage>18</lpage></citation></ref>
<ref id="b2-sensors-09-00327"><label>2.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Roy</surname><given-names>S.</given-names></name><name><surname>Arabshahi</surname><given-names>P.</given-names></name><name><surname>Rouseff</surname><given-names>D.</given-names></name><name><surname>Fox</surname><given-names>W.L.J.</given-names></name></person-group><article-title>Wide area ocean networks: architecture and system design considerations</article-title><source>Underwater Networks</source><publisher-name>ACM</publisher-name><year>2006</year><fpage>25</fpage><lpage>32</lpage></citation></ref>
<ref id="b3-sensors-09-00327"><label>3.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Akyildiz</surname><given-names>I.F.</given-names></name><name><surname>Pompili</surname><given-names>D.</given-names></name><name><surname>Melodia</surname><given-names>T.</given-names></name></person-group><article-title>Underwater acoustic sensor networks: research challenges</article-title><source>Ad Hoc Netw.</source><year>2005</year><volume>3</volume><fpage>257</fpage><lpage>279</lpage><pub-id pub-id-type="doi">10.1016/j.adhoc.2005.01.004</pub-id></citation></ref>
<ref id="b4-sensors-09-00327"><label>4.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Lin</surname><given-names>F.</given-names></name><name><surname>Wang</surname><given-names>Y.</given-names></name><name><surname>Wu</surname><given-names>H.</given-names></name></person-group><article-title>Testbed implementation of delay/fault-tolerant mobile sensor network (dft-msn)</article-title><source>PerCom Workshops</source><publisher-name>IEEE Computer Society</publisher-name><year>2006</year><fpage>321</fpage><lpage>327</lpage></citation></ref>
<ref id="b5-sensors-09-00327"><label>5.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Rao</surname><given-names>R.N.</given-names></name><name><surname>Kesidis</surname><given-names>G.</given-names></name></person-group><article-title>Purposeful mobility for relaying and surveillance in mobile ad hoc sensor networks</article-title><source>IEEE Trans. Mobile Comput.</source><year>2004</year><volume>3</volume><issue>3</issue><fpage>225</fpage><lpage>232</lpage><pub-id pub-id-type="doi">10.1109/TMC.2004.26</pub-id></citation></ref>
<ref id="b6-sensors-09-00327"><label>6.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Wang</surname><given-names>Y.</given-names></name><name><surname>Wu</surname><given-names>H.</given-names></name></person-group><article-title>Delay/fault-tolerant mobile sensor network (dft-msn): A new paradigm for pervasive information gathering</article-title><source>IEEE Trans. Mobile Comput.</source><year>2007</year><volume>6</volume><issue>9</issue><fpage>1021</fpage><lpage>1034</lpage><pub-id pub-id-type="doi">10.1109/TMC.2007.1006</pub-id></citation></ref>
<ref id="b7-sensors-09-00327"><label>7.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Suzuki</surname><given-names>R.</given-names></name><name><surname>Makimura</surname><given-names>K.</given-names></name><name><surname>Saito</surname><given-names>H.</given-names></name><name><surname>Tobe</surname><given-names>Y.</given-names></name></person-group><article-title>Prototype of a sensor network with moving nodes</article-title><source>INSS</source><month>June</month><year>2004</year></citation></ref>
<ref id="b8-sensors-09-00327"><label>8.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Tobe</surname><given-names>Y.</given-names></name><name><surname>Suzuki</surname><given-names>T.</given-names></name></person-group><article-title>WISER: cooperative sensing using mobile robots</article-title><source>ICPADS 2005</source><year>2005</year><fpage>388</fpage><lpage>392</lpage></citation></ref>
<ref id="b9-sensors-09-00327"><label>9.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Wang</surname><given-names>K.-C.</given-names></name><name><surname>Ramanathan</surname><given-names>P.</given-names></name></person-group><article-title>Collaborative sensing using sensors of uncoordinated mobility</article-title><source>DCOSS, Lecture Notes in Computer Science</source><publisher-name>Springer</publisher-name><year>2005</year><volume>3560</volume><fpage>293</fpage><lpage>306</lpage></citation></ref>
<ref id="b10-sensors-09-00327"><label>10.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Son</surname><given-names>D.</given-names></name><name><surname>Helmy</surname><given-names>A.</given-names></name><name><surname>Krishmacharl</surname><given-names>B.</given-names></name></person-group><article-title>The effect of mobility-induced location errors on geographic routing in mobile ad hoc and sensor networks:analysis and improvement using mobility prediction</article-title><source>IEEE Trans. Mobile Comput.</source><year>2004</year><volume>3</volume><issue>3</issue><fpage>233</fpage><lpage>245</lpage><pub-id pub-id-type="doi">10.1109/TMC.2004.28</pub-id></citation></ref>
<ref id="b11-sensors-09-00327"><label>11.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Arboleda C</surname><given-names>L.M.</given-names></name><name><surname>Nasser</surname><given-names>N.</given-names></name></person-group><article-title>Cluster-based routing protocol for mobile sensor networks</article-title><conf-name>International Conference on Quality of Service in Heterogeneous Wired/Wireless Networks</conf-name><conf-date>August 2006</conf-date></citation></ref>
<ref id="b12-sensors-09-00327"><label>12.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Shinjo</surname><given-names>T.</given-names></name><name><surname>Ogawa</surname><given-names>T.</given-names></name><name><surname>Kitajima</surname><given-names>S.</given-names></name><name><surname>Hara</surname><given-names>T.</given-names></name><name><surname>Nishio</surname><given-names>S.</given-names></name></person-group><article-title>Mobile sensor control methods for reducing power consumption in sparse sensor network</article-title><source>SeNTIE</source><year>2008</year><fpage>133</fpage><lpage>140</lpage></citation></ref>
<ref id="b13-sensors-09-00327"><label>13.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Lin</surname><given-names>C.-Y.</given-names></name><name><surname>Tseng</surname><given-names>Y.-C.</given-names></name></person-group><article-title>Structures for in-network moving object tracking in wireless sensor networks</article-title><source>BROADNETS</source><publisher-name>IEEE Computer Society</publisher-name><year>2004</year><fpage>718</fpage><lpage>727</lpage></citation></ref>
<ref id="b14-sensors-09-00327"><label>14.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Pompili</surname><given-names>D.</given-names></name><name><surname>Melodia</surname><given-names>T.</given-names></name><name><surname>Akyildiz</surname><given-names>I.F.</given-names></name></person-group><article-title>Routing algorithms for delay-insensitive and delay-sensitive applications in underwater sensor networks</article-title><source>MOBICOM</source><publisher-name>ACM</publisher-name><year>2006</year><fpage>298</fpage><lpage>309</lpage></citation></ref>
<ref id="b15-sensors-09-00327"><label>15.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Bahl</surname><given-names>P.</given-names></name><name><surname>Padmanabhan</surname><given-names>V.N.</given-names></name></person-group><article-title>Radar: An in-building rf-based user location and tracking system</article-title><source>INFOCOM</source><year>2000</year><fpage>775</fpage><lpage>784</lpage></citation></ref>
<ref id="b16-sensors-09-00327"><label>16.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Hu</surname><given-names>L.</given-names></name><name><surname>Evans</surname><given-names>D.</given-names></name></person-group><article-title>Localization for mobile sensor networks</article-title><source>MOBICOM</source><publisher-name>ACM</publisher-name><year>2004</year><fpage>45</fpage><lpage>57</lpage></citation></ref>
<ref id="b17-sensors-09-00327"><label>17.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Goldenberd</surname><given-names>D.K.</given-names></name><name><surname>Lin</surname><given-names>J.</given-names></name><name><surname>Morse</surname><given-names>A.S.</given-names></name><name><surname>Rosen</surname><given-names>B.E.</given-names></name><name><surname>Yang</surname><given-names>Y.R.</given-names></name></person-group><article-title>Towards mobility as a network control primitive</article-title><source>MOBIHOC</source><publisher-name>ACM</publisher-name><year>2004</year><fpage>163</fpage><lpage>174</lpage></citation></ref>
<ref id="b18-sensors-09-00327"><label>18.</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Rahimi</surname><given-names>M.H.</given-names></name><name><surname>Shah</surname><given-names>H.</given-names></name><name><surname>Sukhatme</surname><given-names>G.S.</given-names></name><name><surname>Heidemann</surname><given-names>J.S.</given-names></name><name><surname>Estrin</surname><given-names>D.</given-names></name></person-group><article-title>Studying the feasibility of energy harvesting in a mobile sensor network</article-title><source>ICRA</source><publisher-name>IEEE</publisher-name><year>2003</year><fpage>19</fpage><lpage>24</lpage></citation></ref></ref-list>
<sec sec-type="display-objects">
<title>Figures and Tables</title>
<fig id="f1-sensors-09-00327" position="float">
<label>Figure 1.</label>
<caption>
<p>Mode transition of a mobile node.</p></caption>
<graphic xlink:href="sensors-09-00327f1.gif"/></fig>
<fig id="f2-sensors-09-00327" position="float">
<label>Figure 2.</label>
<caption>
<p>Dividing the area.</p></caption>
<graphic xlink:href="sensors-09-00327f2.gif"/></fig>
<fig id="f3-sensors-09-00327" position="float">
<label>Figure 3.</label>
<caption>
<p>Moving route of a mobile node.</p></caption>
<graphic xlink:href="sensors-09-00327f3.gif"/></fig>
<fig id="f4-sensors-09-00327" position="float">
<label>Figure 4.</label>
<caption>
<p>Selection of the next fixed node.</p></caption>
<graphic xlink:href="sensors-09-00327f4.gif"/></fig>
<fig id="f5-sensors-09-00327" position="float">
<label>Figure 5.</label>
<graphic xlink:href="sensors-09-00327f5a.gif"/>
<graphic xlink:href="sensors-09-00327f5b.gif"/></fig>
<fig id="f6-sensors-09-00327" position="float">
<label>Figure 6.</label>
<caption>
<p>Construction of a train.</p></caption>
<graphic xlink:href="sensors-09-00327f6.gif"/></fig>
<fig id="f7-sensors-09-00327" position="float">
<label>Figure 7.</label>
<caption>
<p>Train transmission.</p></caption>
<graphic xlink:href="sensors-09-00327f7.gif"/></fig>
<fig id="f8-sensors-09-00327" position="float">
<label>Figure 8.</label>
<caption>
<p>Reconstruction of a train.</p></caption>
<graphic xlink:href="sensors-09-00327f8.gif"/></fig>
<fig id="f9-sensors-09-00327" position="float">
<label>Figure 9.</label>
<caption>
<p>Release a communication route.</p></caption>
<graphic xlink:href="sensors-09-00327f9.gif"/></fig>
<fig id="f10-sensors-09-00327" position="float">
<label>Figure 10.</label>
<caption>
<p>The operations in a sensing cycle.</p></caption>
<graphic xlink:href="sensors-09-00327f10.gif"/></fig>
<fig id="f11-sensors-09-00327" position="float">
<label>Figure 11.</label>
<caption>
<p>Velocity and throughput.</p></caption>
<graphic xlink:href="sensors-09-00327f11.gif"/></fig>
<fig id="f12-sensors-09-00327" position="float">
<label>Figure 12.</label>
<caption>
<p>Velocity and average moving distance.</p></caption>
<graphic xlink:href="sensors-09-00327f12.gif"/></fig>
<fig id="f13-sensors-09-00327" position="float">
<label>Figure 13.</label>
<caption>
<p>Velocity and average delay.</p></caption>
<graphic xlink:href="sensors-09-00327f13.gif"/></fig>
<fig id="f14-sensors-09-00327" position="float">
<label>Figure 14.</label>
<caption>
<p>Velocity and details of delay in DATFM.</p></caption>
<graphic xlink:href="sensors-09-00327f14.gif"/></fig>
<fig id="f15-sensors-09-00327" position="float">
<label>Figure 15.</label>
<caption>
<p>Velocity and control traffic.</p></caption>
<graphic xlink:href="sensors-09-00327f15.gif"/></fig>
<fig id="f16-sensors-09-00327" position="float">
<label>Figure 16.</label>
<caption>
<p>Communication range and throughput.</p></caption>
<graphic xlink:href="sensors-09-00327f16.gif"/></fig>
<fig id="f17-sensors-09-00327" position="float">
<label>Figure 17.</label>
<caption>
<p>Communication range and average moving distance.</p></caption>
<graphic xlink:href="sensors-09-00327f17.gif"/></fig>
<fig id="f18-sensors-09-00327" position="float">
<label>Figure 18.</label>
<caption>
<p>Communication range and average delay.</p></caption>
<graphic xlink:href="sensors-09-00327f18.gif"/></fig>
<fig id="f19-sensors-09-00327" position="float">
<label>Figure 19.</label>
<caption>
<p>Communication range and details of delay in DATFM.</p></caption>
<graphic xlink:href="sensors-09-00327f19.gif"/></fig>
<fig id="f20-sensors-09-00327" position="float">
<label>Figure 20.</label>
<caption>
<p>Communication range and control traffic.</p></caption>
<graphic xlink:href="sensors-09-00327f20.gif"/></fig>
<fig id="f21-sensors-09-00327" position="float">
<label>Figure 21.</label>
<caption>
<p>Communication range and the energy consumption in DATFM.</p></caption>
<graphic xlink:href="sensors-09-00327f21.gif"/></fig>
<table-wrap id="t1-sensors-09-00327" position="float">
<label>Table 1.</label>
<caption>
<p>Information of mobile nodes held by a fixed node.</p></caption>
<table frame="box" rules="cols">
<thead>
<tr>
<th align="center" valign="top"><bold>Node ID</bold></th>
<th align="center" valign="top"><bold>Connected time</bold></th>
<th align="center" valign="top"><bold>Next fixed node</bold></th>
<th align="center" valign="top"><bold>Destination</bold></th></tr>
<tr>
<th align="center" valign="top" colspan="4">
<hr/></th></tr></thead>
<tbody>
<tr>
<td align="center" valign="top">a</td>
<td align="center" valign="top">1,232</td>
<td align="center" valign="top"><italic>E</italic></td>
<td align="center" valign="top">(832,324)</td></tr>
<tr>
<td align="center" valign="top">c</td>
<td align="center" valign="top">1,266</td>
<td align="center" valign="top"><italic>F</italic></td>
<td align="center" valign="top">(542,255)</td></tr>
<tr>
<td align="center" valign="top">f</td>
<td align="center" valign="top">1,335</td>
<td align="center" valign="top"><italic>E</italic></td>
<td align="center" valign="top">(832,324)</td></tr>
<tr>
<td align="center" valign="top">i</td>
<td align="center" valign="top">1,552</td>
<td align="center" valign="top"><italic>C</italic></td>
<td align="center" valign="top">(754,743)</td></tr>
<tr>
<td align="center" valign="top">o</td>
<td align="center" valign="top">1,632</td>
<td align="center" valign="top"><italic>C</italic></td>
<td align="center" valign="top">(754,743)</td></tr></tbody></table></table-wrap>
<table-wrap id="t2-sensors-09-00327" position="float">
<label>Table 2.</label>
<caption>
<p>Parameters in the experiments.</p></caption>
<table frame="box" rules="cols">
<thead>
<tr>
<th align="center" valign="middle"><bold>Parameter</bold></th>
<th align="center" valign="middle"><bold>Value (Default)</bold></th></tr>
<tr>
<th align="center" valign="middle" colspan="2">
<hr/></th></tr></thead>
<tbody>
<tr>
<td align="center" valign="middle"><bold><italic>R</italic></bold><italic><sub>com</sub></italic></td>
<td align="center" valign="middle"><bold>10 ∼ 50</bold> (50)</td></tr>
<tr>
<td align="center" valign="middle"><bold><italic>υ</italic></bold><italic><sub>m</sub></italic></td>
<td align="center" valign="middle"><bold>1.0 ∼ 5.0</bold> (5.0)</td></tr></tbody></table></table-wrap></sec></back></article>
