## 3 The Location-Based Interactive Model
### Entities  
**Physical Wireless Sensor Networks:** A wireless sensor network consists of physical sensor nodes. Each sensor node is characterized by the following properties: ID, type \(i_{\tau}\), location \(L\), and the state.  
**Definition 1**.: _Each physical sensor node \(i\) associates with a type \(i_{\tau}\) that describes its sensor type, with \(i_{\tau}\in\tau=\{\tau_{1},\tau_{2},...,\tau_{N}\}\), where \(\tau\) is a set of N registered sensor types._  
**Definition 2**.: _After deployment, a physical sensor node registers its location with the cloud. Location \(L_{i}=\{x_{i},y_{i}\}\) of a sensor node \(i\) describes the latitude and longitude of the node._  
**Definition 3**.: _During the lifetime, a sensor node may be in an active state (denoted by 1) or inactive state (denoted by 0). The state of a node \(i\) is denoted by \(i_{\zeta}\)._  
By our definition, a physical sensor \(i\) is modeled as follows:  
\[i=(i_{ID},i_{\tau},i_{L},i_{\zeta}),i_{\tau}\in\tau,i_{\theta}\in\Theta.\]  
**Cloud:** A cloud \(c\) is characterized by the following properties: ID, resources, QoS, and price. A cloud \(c\) may provide sensing service for a set of \(\tau\) sensor types from \(\Theta\) WSN owners. Note that this paper does not consider selective model for clouds, so we do not cover properties of a cloud in detail. In the IoT-cloud, sensors are virtualized into virtual sensors. We model a function that maps a physical sensor or a set of physical sensors \(\zeta\) to a virtual sensor or a set of virtual sensors \(\gamma\) as follows:  
\[f_{phy->vir}(\zeta)=\gamma. \tag{1}\]  
In our previous design [3], virtual sensors are managed by the virtual sensor manager and mapped to physical sensors by the physical sensor manager. Note that with a huge storage capability, a cloud can also act as a sensor database to provide historical sensor data services upon the demand of applications. Such a historical sensor data service can be provided directly by the sensor cloud to applications and can be built simply as a web service application. In this work, we focus on the interactive model between WSNs and the cloud, and historical sensor data services are out of the scope of this paper.  
**Application:** Application \(\alpha\) is characterized by the following properties: ID, a set of sensor data of interest, the region of interest, and QoS requirements (i.e., delay, sensing interval).  
**Definition 4**.: _An IoT-cloud application \(\alpha\) may be interested in a set of sensor data types \(\alpha_{SI}\) for its operations. These data may be requested by mobile users based on the user's location. We later provide a function to map \(\alpha_{SI}\) of an application to \(\tau\) of a cloud._  
**Definition 5**.: _An application \(\alpha\) is deployed to work in a limited region, called a region of interest \(\alpha_{RI}=L_{1},L_{2},L_{3},L_{4}\). The region of interest consists of locations of four points that bound the region._  
**Definition 6**.: _Each application \(\alpha\) may have different QoS requirements \(\alpha_{QoS}\) for sensing data such as delay or sensing interval. Based on these requirements, an application may find an appropriate cloud service provider. Note that the price is normally proportional to the sensing data quality._  
As a result, an application \(\alpha\) is modeled as follows:  
\[\alpha=(\alpha_{ID},\alpha_{SI},\alpha_{RI},\alpha_{QoS}).\]  
**Mobile User:** A mobile user \(\mu\) is characterized by the following properties: ID (i.e., device ID), application IDs \(\mu_{AppIIDs}\), current location \(L_{\mu}^{current}\). Note that a mobile user may use one or multiple applications. A mobile user is modeled as follows:\[\mu=(\mu_{ID},\mu_{ApPIDs},\mu^{current}_{L}).\]  
We highlight that in one sensing area, there may be several mobile users who need the same sensing information.