Research Article | Open Access
Rolando Menchaca-Mendez, Brayan Luna-Nuñez, Ricardo Menchaca-Mendez, Arturo Yee-Rendon, Rolando Quintero, Jesus Favela, "Opportunistic Mobile Sensing in the Fog", Wireless Communications and Mobile Computing, vol. 2018, Article ID 2796282, 18 pages, 2018. https://doi.org/10.1155/2018/2796282
Opportunistic Mobile Sensing in the Fog
The increasing adoption of mobile personal devices and Internet of Things devices is leveraging the emergence of a wide variety of opportunistic sensing applications. However, the designers of this type of applications face a set of technical challenges related to the limitations and heterogeneity of the hardware and software platforms and to the dynamics of the scenarios where they are deployed. In this paper, we introduce a Semantic-Centric Fog-based framework aimed at effectively and efficiently supporting this type of applications. The proposed framework is composed of local and distributed algorithms that support the establishment and coordination of sensing tasks in the Fog. First, it performs ontology-driven in-network processing to locate the most adequate devices to carry out a given sensing task and then, it establishes efficient multihop routes that are used to coordinate relevant devices and to transport the collected sensory data to Fog sinks. We present a set of theorems that prove that the proposed algorithms are correct and the results of a series of detailed simulation-based experiments in NS3 that characterize the performance of the proposed platform. The results show that the proposed framework outperforms traditional sensing platforms that are based on centralized services.
Fog computing is a distributed paradigm for transporting, storing, analyzing, and acting on data generated by a swarm of heterogeneous networked devices such as Internet of Things (IoT)  devices and personal mobile devices that are located at the network edge [2–5].
Fog computing provides Cloud-like services implemented close to where data is generated. The purpose is manifold: to provide stable resources to the swarm at the network edge: this way, edge devices do not have to rely solely on their limited resources; to improve scalability by offloading data traffic from the core network [5, 6]: in the Fog computing model, only selected or preprocessed data is transported through the core network to the Cloud ; to reduce response time: by analyzing and acting on time-sensitive data close to where it is generated, systems can eliminate a network round-trip time, reducing the response delay and jitter [7, 8]; to improve privacy by storing privacy-sensitive data at the local premises [3, 5, 7–9]; and to improve efficiency by distributing processing, storing, and communication functions anywhere between the Cloud and the swarm at the edge [7, 10].
The Fog computing paradigm provides an ideal platform for implementing sensing applications because it enables seamless integration between the unprecedented capabilities to monitor the physical world  of dedicated sensor networks, personal mobile, and IoT devices; and the scalable storage and high-performance computing capabilities for data analytics of the Cloud . In fact, despite the large diversity of Fog applications (e.g., smart grid, smart traffic, and smart buildings ), all of them include a sensing component involving IoT devices , mobile devices, and/or sensor networks. However, the vast majority of current sensing applications typically address a single scenario on a dedicated set of resources. While this approach provides performance guarantees and reliability, it prevents the explosion of possibilities that result from sharing data, hardware, and software services across applications .
In this paper, we present a platform for opportunistic sensing  in the Fog, where collections of heterogeneous networked devices (e.g., IoT devices, dedicated sensor networks, and personal mobile devices) can self-organize to collect relevant sensory data and to efficiently transport it to Fog sinks. The result is an adaptive platform that is able to opportunistically take advantage of the local sensing devices to support a wide diversity of sensing applications with optimized performance. Please note that opportunistic sensing and the Fog share a common fundamental research question, namely, how to distribute computational tasks over a dynamic set of heterogeneous resource-constrained wireless nodes .
Opportunistic sensing (OS) systems differ in important ways from traditional sensor networks, introducing new challenges but also opening new opportunities. While sensor networks are typically deployed as a well-known set of homogeneous devices, OS systems are usually composed of highly heterogeneous devices with diverse hardware characteristics . Moreover, OS systems are much more dynamic in the sense that completely new types of networked sensors can come into play at any time during the system operation, and OS platforms should be able to seamlessly integrate them into the sensing tasks. Therefore, identifying the right set of devices, those that can produce the desired sensory data with the proper context and at minimum network cost become one of the most important and complex problems for the complete realization of an opportunistic sensing platform [12, 14]. The context of a sensor may include its current battery’s energy level and its geographical location, but also, in the case of mobile devices such as smartphones, the set of applications running on the foreground, as well as instantaneous readings of their sensors that may indicate, for instance, whether a device is inside of a bag.
Another important difference between OS and traditional sensor networks is the degree in which human users are involved in the sensing tasks. In the opportunistic sensing paradigm, sensing applications can run in the background of mobile personal devices while opportunistically collecting data. In this type of scenarios, personal devices cannot be overloaded with continuous sensing tasks that may reduce the user experience by disrupting applications or depleting battery power because it may prevent users to participate in future sensing tasks . This has motivated the development of collaborative sensing strategies, where two or more mobile devices share the sensing, processing, or communication load to save resources .
In a nutshell, the main advantage of opportunistic sensing platforms is that they can harness the sensing and communication capabilities of the static sensor networks deployed in a given environment, but also of mobile and IoT devices that happen to also be located at the same environment. This is all to provide sensing services to applications running on local devices but also to large-scale applications running on the Cloud.
The proposed framework for opportunistic sensing is based on Semantic-Centric Sensing Foglets (sensing Foglets for short) which are dynamic collections of local heterogeneous networked devices such as smartphones, traditional sensor networks, IoT devices, and mobile and desktop computers. These devices organize themselves to collect and deliver relevant sensory information to a designated local Fog data sink. For a given sensing request, the proposed framework locates and identifies the set of local sensing devices that are most fit to perform the task. This selection is based on the computation of a semantic distance function between semantic labels describing the requested sensor and the sensors installed on the local devices, the instantaneous context of the sensing devices, and the communication cost.
The main contributions of this paper are as follows: an ontology-based semantic distance function, with an efficient implementation, that can be computed without accessing the whole ontology; a semantic-driven distributed algorithm that uses in-network processing to locate a set of sensing devices that are able to perform a given sensing task at minimum network cost. This way, sensing tasks can be opportunistically carried out by a combination of mobile devices, IoT artifacts, traditional sensor networks and Fog devices; and an effective and efficient distributed algorithm that instantiates sensing Foglets by establishing and maintaining multihop paths connecting the best sensing devices in the environment to Fog sinks and that implements collaborative sensing schedules where multiple devices can share the load of implementing a sensing task. These sensing schedules can reduce local network contention and congestion by balancing the network load. They can also be used to improve the quality of the sensory data by providing redundant sources of information.
The rest of this paper is organized as follows. In Section 2, we describe existing mobile sensing platforms, emphasizing the fact that most of these platforms are either based on centralized architectures where mobile nodes communicate directly to services on the Internet; or do not address the problem of finding the best set of sensing and communication nodes. In Section 3, we present the proposed opportunistic sensing architecture and formulate the problem of instantiating semantic-centric Foglets for sensing. In Section 4, we establish the correctness of the proposed algorithms. Section 5 presents the results of a series of detailed simulation-based experiments that show that the Semantic-Centric Sensing Foglets outperform traditional sensing platforms in terms of efficiency and effectiveness. Lastly, in Section 6 we present our concluding remarks and future research directions.
2. Mobile Sensing
Many sensing platforms have been proposed in recent years. Here we present a small, but representative sample of that body of work. Sensing platforms can be classified as either centralized or distributed depending on the way the mobile nodes interact among them. Representatives of centralized platforms are METIS , PRISM  Medusa , and InCense , while representatives of distributed platforms are COUPON  and the work by Ngai et-al .
METIS  is a sensing platform that offloads sensing tasks to sensors embedded in the environment with the goal of conserving energy. METIS assumes the presence of a centralized rendezvous point, which is used by smartphones to query the infrastructure about the available sensing resources and their capabilities. Offloading decisions are based on the estimated energy cost when sensing is performed on the phone and the prediction of the energy cost when sensing is performed by sensors in the environment. Unlike the proposed platform, METIS does not provide support to generate sensing schedules where multiple devices can be involved in a given sensing task. In , the authors present a human-based data-muling system where smartphones are used to collect data from sensor networks. Then, smartphones use a 3G cellular link or 802.11 to upload their collected data to a centralized server. EEMSS  and Jigsaw  are two sensing platforms that focus on energy efficiency through the optimized use of the smartphones’ sensors. These proposals, however, consider neither the problem of sensor selection nor collaboration among smartphones.
PRISM  is based on a client-server architecture where a PRISM server accepts sensing jobs from application servers; then, these jobs are deployed by pushing an application into smartphones that comply with a set of predicates. The PRISM runtime platform implements a software sandbox where the sensing application is executed. This sandbox also provides functionality for resource metering, for preventing applications to retain sensed data, and for allowing users to establish policies on the type of applications that they are willing to run on their phones. Once data is collected, it is transmitted back to the PRISM server through a wireless WAN link. AnonySense  also uses a client-server architecture where users of smartphones can volunteer to accept sensing tasks and send back anonymous reports. Tasks are accepted based on the acceptance condition defined by the task issuer and on the local policies of the phones. The main focus of AnonySense is to preserve privacy in opportunistic sensing environments. Medusa  provides a high-level language for developing crowd-sensing tasks which are specified as a sequence of steps that are executed by the Medusa runtime system, which is structured as a set of services that run on the Cloud and on the phones. These services are in charge of coordinating the execution of the sensing task between the smartphones and a cluster on the Cloud. InCense  is a general purpose mobile phone sensing platform for deploying sensing campaigns through a visual programming paradigm. The architecture of InCense is based on a centralized context-aware server that coordinates smartphones in order to improve the quality of the sensed data and reduce energy consumption. Neither PRISM, AnonySense, Medusa, nor InCense has support for direct peer-to-peer communication between smartphones. These four proposals are complementary to the one presented here in the sense that they tackle related but orthogonal aspects of mobile opportunistic sensing.
COUPON  is a cooperative sensing and data forwarding framework that incorporates a cooperative sensing scheme and two store-carry-and-forward forwarding schemes with data fusion. In COUPON, the area of interest is divided into grid cells whose size is defined by the application requirements. Time is also divided into time slots that are further divided into sampling periods. Cooperative sensing consists of nodes reporting to their neighbors their coverage tables that contain two-tuples consisting of grid cell identifiers and the time that the grid cell has been covered during a time period. Using this information, nodes may decide not to sense and transmit redundant information regarding a given cell in the current time period. The authors implicitly assume that nodes are homogeneous and capable of sensing the required variable with the appropriate resolution at any time. Lastly, in  the authors propose a context-aware sensing data dissemination framework where smartphones are either used as sensors or as data mules that opportunistically collect data from stationary sensors through short-range communications.
3. Semantic Fog for Opportunistic Sensing
Figure 1 depicts the proposed Cloud/Fog-based opportunistic sensing architecture that aims at integrating the storage and processing power of the Cloud with the sensing capabilities of any networked device that happens to be located in a region that is of interest for a sensing application. In the proposed architecture, sensing applications running either on a mobile device (e.g., a personal health-care application) or on the Cloud (e.g., a large-scale public-health sensing application) can issue sensing tasks to Fog environments requesting to monitor a given set of variables, during a specified period of time and in a region of interest. As a response to such request, the devices in the Fog environment will organize themselves to create a Foglet composed of interconnected devices that have the capabilities to fulfill the sensing task by delivering the requested data to a designated Fog data sink. This is at minimum network cost in terms of congestion and contention. Under this paradigm, the sensing Foglets are in charge of providing the sensing capabilities needed to implement personal, community, and large-scale sensing applications that run either on a mobile device or on the Cloud. It is important to mention that, even though our platform is specifically designed to instantiate Foglets for sensing, the same architecture can be used to provide other types of Fog services.
Figure 1 shows two examples of the way in which the proposed opportunistic sensing Fog environments operate. In the first example, Foglet A (composed of a smartphone and a personal computer) is instantiated as a response to a sensing task issued from the Cloud requesting to measure the noise level at the local environment. In the example, the smartphone is selected because it is equipped with an adequate sensor (e.g., a microphone), has the right context (e.g., it has enough energy in its battery, is not stored and is located in the region of interest), and is located just one-hop away from the designated Fog sink (the same personal computer that received the request). In the second example, Foglet B is instantiated as a response to a sensing task issued by an application running on a mobile device located in the local environment. This sensing task requests three devices with video cameras to record a video for a designated time period. The task of this example also designates a local Fog storage service as a sink so that the mobile device can move out of the environment without interrupting the data collection process.
For the sake of completeness, Figure 1 also shows two other Cloud services, which are relevant to opportunistic sensing platforms, namely, a storage service and a data analytics service.
In the following subsections, we present the system model and formally formulate the problem of instantiating an effective and efficient semantic-driven sensing Foglet.
3.1. System Model
We use a time varying graph to model the topology of a dynamic network composed of a time varying set of heterogeneous nodes (e.g., desktop computers, mobile and IoT devices, and sensor nodes) that at time are located in a given Fog environment. Nodes in the Fog environment interact with each other by means of wireless links that are modeled by edges . Two nodes are connected by a link at time , if and only if . Where is the transmission radio range, is a function that assigns to each node a position in the -plane at time and is the Euclidean distance between two points. In practice, individual nodes know their own instantaneous position only, usually through GPS or from other positioning services.
Since nodes are heterogeneous, they can be equipped with different types of sensors that provide them with a specific set of capabilities. Such sensors are described by means of a sensor ontology that contains concepts describing the different types of sensors and a set of unidirectional relations between concepts . For this work, we assume that the relations in , as well as the relations in the other ontologies, are is-a relations and that the ontologies are organized as hierarchies. Figure 2 presents a small portion of the sensor ontology that shows the branch that describes the acoustic sensors. In the figure, the relation (Microphone, Acoustic_sensor) indicates that a Microphone is a type of Acoustic_sensor, and, for instance, that a node equipped with a microphone is adequate to fulfill a request for an Acoustic_sensor.
The particular sensors of a given device (also referred as node) are specified by a function , where denotes the power set of the concepts in the ontology . This means that a node can have any subset (e.g., a Pressure_sensor and an Acoustic_sensor) of the sensor types described in the ontology . Please note that in practice, the information of function is distributed among the nodes in the environment, namely, that each node only knows the information regarding their local sensors.
Similarly, a function defines the individual instantaneous node context in terms of a 3-tuple where is the remaining node energy. For the case of personal devices, is the type of the application currently running on the foreground and indicates whether the device is stored (e.g., in a pocket or a bag). As in the case of the types of sensors, an application ontology is used to describe the different types of applications that can be executed by the devices. For instance, for a smartphone that at time is stored in a bag, has 50% of remaining battery charge and is not currently running an application on the foreground, we would have .
A sensing task is implemented by means of a set of sensing requests that are issued to the Fog by one or more devices. A sensing request issued by node at time is a 5-tuple of the form , where is the identifier of the request, is the requested type of sensor, is a 4-tuple that defines the restrictions that a node needs to fulfill in order to be considered a feasible data source, is the maximum number of devices that will generate data, and is the identifier of the Fog data sink. The restrictions include the geographic area of interest of the sensing request (a disk of radio with center at ), the maximum number of hops () that the request will be propagated, and a context predicate () that defines the required device context, which includes the acceptable remaining energy level , the type of application running on the foreground of the sensing device and whether the device can be stored. When , the requesting node will be in charge of coordinating a collaborative sensing schedule where the selected nodes will monitor the required variables at intervals defined by a sensing schedule.
3.2. Semantic Distance
A semantic distance function between two concepts of an ontology , denoted by , is a function that assigns a positive real value to any pair of concepts depending on how taxonomically close the two concepts are in the ontology  (here we have dropped the subindex of because we are not referring to a particular ontology). We use such a function to assess how appropriate is a given sensing hardware to fulfill a sensing request. In particular, if the value of the semantic distance between the requested type of sensor and the sensing hardware installed on the device is small, we say that the device is adequate to fulfill the sensing request. From the example of Figure 2, a node equipped with either a condenser_microphone or a carbon_microphone is adequate to fulfill a request for a Microphone because both concepts are more concrete instances of the more abstract concept Microphone.
The definition of semantic distance between two concepts can be extended in a number of ways to obtain a semantic distance between a concept and a set of concepts . In this work, we propose (1) that simply returns the smallest semantic distance between concept and any of the concepts . The idea is that a device is adequate to fulfill a request if the type of any of its hardware components is semantically close to the requested type of sensor. To exemplify this, assume that a node is equipped with the set of sensors Pressure_sensor, Acoustic_sensor, and that a request for a Pressure_sensor arrives to the Fog environment. Then, since Pressure_sensorPressure_sensor, Acoustic_sensor we can say that node is adequate to fulfill the request.
Precise specifications of the way in which the proposed semantic distance function is computed are presented in Sections 3.5 and 3.6. Section 3.5 presents the formulation of the semantic distance function when the ontology is codified as a graph, and Section 3.5 presents an equivalent formulation that uses prefix-based labels as parameters.
3.3. Problem Formulation
From the previous definitions, we can state the problem of instantiating a sensing Foglet as follows.
Definition 1. Given an environment composed of a time varying set of devices located at positions designated by function , a sensor ontology describing the different types of sensing hardware, an application ontology describing the different types of applications running on the devices, a function that describes the sensing hardware installed in the devices in , a node context function that describes the instantaneous context of each device, and a sensing request issued by node at time ; find a set of devices , such that the following conditions hold:(1)The selected sensing nodes are located inside of the region of interest: , is a point located inside of the circumference of radio with center at .(2)Nodes in have the required energy, are running an adequate type of application on the foreground (if any), and are not stored if it may interfere with the sensing process: , , .(3) there is a path of length in .(4) is as large as possible but .(5)Nodes in are those equipped with the most adequate sensing hardware, or more specifically, the nodes that minimize
where, as defined in Section 3.1, denotes the remaining energy in the battery of node at time , is the application that node is running on the foreground (if any) at time , and indicates if node is stored at time . Similarly, is a predicate that defines the required device context which includes the acceptable remaining energy level , the type of application running on the foreground, and whether the device can be stored or if the latter is irrelevant for the request .
This way, a solution to the problem of instantiating a sensing Foglet is a set of nodes currently in the environment, located in the area of interest (Condition 1), with the adequate context (Condition 2), equipped with the most suitable sensing hardware (Condition 5) and, a set of devices that connect the requesting node with all the nodes in through paths in of length less than (Condition 3). Other criteria can be used to compute the paths connecting with the nodes in , for instance, paths of Maximum-Minimum residual energy, paths composed of nodes not currently in use by their human users, or paths composed of nodes that have not recently participated in a sensing task.
Please note that the problem formulated at Definition 1 is a search problem where a subset of feasible nodes is selected to perform a sensing task. Feasibility is defined by Conditions 1–4, whereas Condition 5 establishes that the best devices to fulfill the request are those equipped with the most adequate sensors for the request, namely, those with the smallest semantic distance between the requested sensor and themselves.
3.4. Semantic-Driven Foglet Formation
The proposed semantic-driven distributed framework for the instantiation of sensing Foglets is composed of a distributed semantic-driven sensor selection algorithm, a sensor ontology, an application ontology, a semantic distance function that can be computed without accessing the whole ontology, a distributed protocol for implementing collaborative sensing plans, and an interest-driven [28, 29] routing algorithm.
During the first phase of the sensor selection algorithm, a Foglet Request () is disseminated across the Fog environment establishing a breadth-first search tree rooted at the requesting device. The request is disseminated only among devices located inside of the region of interest defined by the request and up to the maximum number of hops (). At the end of this phase, every node in the tree knows if it is a feasible device, namely, if it complies with the restrictions defined in the request.
During a second phase of the algorithm, starting at the leaves and up to the root, nodes inform their parents in the tree of the best feasible devices they have seen. A device is considered better than another device if the semantic distance between the requested type of sensor and any of the sensors in the device is smaller, or if the semantic distance is the same but the path connecting the root with the device is better in terms of hop length. This way, the node issuing the request receives only the information regarding the set of best feasible devices available in the Fog environment. With this information, the requesting node can determine if the selected devices are in fact adequate to implement an effective sensing Foglet.
Figures 3(a)–3(d) illustrate the previous idea. Figure 3(a) shows a Fog environment composed of a heterogeneous set of devices that are connected through wireless links. In the figure, a sensing task is received by a Fog server from the Cloud. As a response, the Fog server issues a series of Foglet requests that are disseminated inside the region of interest. If more than one device is selected to generate sensory data, the requesting node will coordinate the selected devices to implement a collaborative sensing plan where the selected devices and the nodes connecting them share the computing and communication load. For instance, the requesting node can compute and deliver sensing schedules to the set of selected devices so that they can turn off their radios or sensing hardware to preserve energy and bandwidth. Alternatively, the sink can also request sensory information from all the selected devices to improve the quality of the information through the redundant sources. Figures 3(b) and 3(d) show the BFS-trees established over the nodes located inside of a circular region of interest of radio .
Figure 3(c) illustrates the case where a sensing request is issued by an application running on a mobile device. The request in this example designates a Fog server as the data sink (Figure 3(d)) so that data can be collected even if the mobile device is turned off or if it moves out of the Fog environment. Once the best sensors have been identified, interest-driven routing [28, 29] is used to transport the sensory data to the designated sink (Figure 3(d)).
The following sections present detailed specifications of the proposed algorithms and protocols.
3.5. Asymmetric Semantic Distance
We propose an asymmetric semantic distance function defined over the concepts of an ontology that can be efficiently computed, even without the need of accessing the whole ontology. The objective of this semantic distance function is to serve as the key metric to identify the best available sensor to fulfill a sensing request and, for the case of personal devices, to determine if an adequate application is running on the foreground. Equation (3) shows the definition of the proposed where we can observe that given a pair of concepts , the function equals if the requested concept is an hypernymy (an ancestor) of concept . This is because is-a more specific instance of and hence, it can be used to fulfill the request. Otherwise, the value of is computed as the length of the path from to the first common ancestor of and in the ontology, which is denoted by . This semantic distance function is similar to the one proposed by Rada et-al  in the sense that both functions are based on the hop distance between concepts in the ontology. The proposed distance, however, is an asymmetric version aimed at evaluating to what extent an instance of concept can be used as an instance of concept .
3.6. Asymmetric Semantic Distance over Prefix-Based Labels
In order to make the computation of (3) more efficient, every concept in is mapped onto a prefix-based label that is derived from a finite alphabet . A prefix label for concept is a word in such that , where is the prefix label of the parent concept of in , is the concatenation operator, and is a suffix assigned to , which is different to the suffixes assigned to its sibling concepts. The root concept of is assigned to label that can be equal to any symbol . We use function to denote such a labeling. Please note that we can assign prefix labels to all the concepts in linear time by performing a level-order traversal of the ontology.
Now, we can reformulate (3) in terms of the prefix labels. We use to denote the length in symbols of label and to denote the label composed of the largest common prefix between and . The new formulation is shown in (4). Please note that (4) can be easily implemented using simple string operations.
As we have already mentioned, the main advantage of this formulation is that devices do not need to access the whole ontology in order to compute the semantic distance between concepts. They only need to perform simple string operations over the corresponding prefix-based labels. Moreover, devices can use (4) to correctly compute the semantic distance between the labels of their sensors and a label of a concept that was added to the ontology to accommodate a new type of sensor. This discussion also applies to the applications running on the devices.
Similar to the case of (1), we can define a semantic distance function between a prefix label and a set of prefix labels , where denotes the power set of prefix labels in the labeling . This is shown in (5).
Figure 4 shows a small ontology and its corresponding prefix-based labeling derived from the alphabet . From the figure we can see that because “0c” . Similarly, that because . Now, let us assume that the concepts located inside of the dashed box (, and ) were added to accommodate new types of sensors. We can see that a device equipped with a sensor of type can reply to a request for a sensor of type with a distance because it only needs the labels of the two concepts.
Please note that for any ontology with a tree topology, the length of the prefix-based label of any is in where is the height of the ontology tree. Therefore, the space needed to store a prefix-based label and the number of operations needed to compute Equation (4) are also in .
3.7. Semantic-Driven Sensor Selection Algorithm
As already mentioned, a sensing task is implemented by means of a set of sensing requests that are issued to the environment by one or more devices. A sensing request is a 5-tuple of the form , , where is the identifier of the request, is the requested sensor type codified as a prefix label, defines the restrictions that nodes need to fulfill in order to be considered feasible data sources, is the maximum number of devices that will generate sensory data, and is the identifier of the sink node.
As shown in Algorithm 1, when a node receives a sensing request from the upper layers, it creates a new element in the set of Foglets (, line ) that contains the fields and data structures that are used during the process of establishing and maintaining the sensing Foglet. All this information is soft state. An element of the Foglet set contains(i)a unique Foglet identifier (),(ii)the identifier of the root node of the tree (),(iii)the identifier of the sink (),(iv)the identifier of the parent of the current node in the tree (), which in the case of the node issuing the request is its own node identifier,(v)a monotonically increasing sequence number () that is further used to maintain the routes from nodes to the root node,(vi)the requested sensor type (),(vii)the maximum number of devices that will generate sensory data (),(viii)the set of restrictions (),(ix)a subset of one-hop neighbors that are known to be children of the current node in the tree (),(x)a subset of one-hop neighbors that are known not to be children of the current node in the tree (),(xi)the set of current one-hop neighbors (),(xii)a set containing the replies () received from the children nodes in the tree,(xiii)a flag that indicates if the node has already sent a Foglet Reply back to its parent () and,(xiv)a routing table () that contains pairs , which are used to route packets from the root to the selected nodes.
A reply is a 3-tuple that contains the identity of the node () that originally issued the reply, the semantic distance () between the requested sensor type and the sensors in the node, and the hop distance () from the root to that particular node.
Once the local state has been created, the root node transmits to its neighbors a Foglet Request which is an 8-tuple of the form , where is the Foglet identifier, is the identifier of the root node, is the root’s sequence number, is the hop distance that the has traversed so far, is the requested sensor type, is the set of restrictions, is the maximum number of devices that will be used to generate sensory data, and is the identifier of the sink. Note that the pair uniquely identifies the Foglet that will be instantiated in response to the sensing request. Upon reception of a from neighbor , node first checks if it is the first time it has received a request with the same pair (line ). If so, it creates a new element in the set of Foglets and checks whether or not it has to relay the message by verifying if it is inside the region of interest (by calling function , line ) and, if the has not reached the maximum number of hops (). If node has already received another Foglet Request with the same pair, it checks if it is a leaf of the tree by comparing its set of nonchild neighbors () against its one-hop neighborhood at the time it received the for the first time (line ).
Nodes know their one-hop neighborhood, denoted , by periodically exchanging hello packets that contain the identity of the nodes.
In order to ensure termination in the presence of packet loss due to either channel effects or topological changes, nodes start a timer (line ) after they have relayed a Foglet Request. The value of the timer is proportional to the difference between and the node’s hop distance to the root. When this timer expires, and if the node has not already done so, the node sends its Foglet Reply back to its parent. This way, in the worst case, the tree will be contracted from leaves to root in a time proportional to .
The contraction phase of the sensor selection algorithm starts when a either reaches its maximum number of hops or when it is received by a node located outside of the region of interest. In the first case, the node considers itself a leaf of the tree and sends a Foglet Reply message back to its parent containing its own reply (line of Algorithm 1). When the node does not fulfill the context restrictions defined in the Foglet Request (), it sets the value of the semantic distance to to indicate that it does not have a feasible sensor (line ). If the node is located outside of the region of interest (), it also sends a Foglet Reply containing a value of semantic distance equal to (line ). A node can also detect that it is a leaf if it receives from all of its current neighbors indicating other nodes as their parents (lines and ).
As shown in Algorithm 2, when a node receives a Foglet Reply from one of its children (node ), it stores the replies contained in the message in the data structure and adds ’s identifier to the data structure. Then, for each of the replies contained in the message reporting a semantic distance different to , creates an entry in the routing table () establishing that node can be used as a next-hop to reach the selected node through a shortest path (line ). If the receiving node has collected Foglet Replies from all of its children nodes that remain in its one-hop neighborhood, it selects the best received replies (line ) to create its own reply message that will be forwarded to either its parent in the tree or to upper layers if the current node is the root node. The node also includes its own information in the reply if it has a feasible sensor, namely, if (line ).