SERVICES 37
This thesis also uses the term Information Sprinkler if the device runs only in sinkmode or in a combination of both.
The next two definitions introduce two core node components that are essential for our data dissemination protocol.
Definition 5 (Node Profile) A node profile is a data structure stored on an oppor- tunistic network node. Using the profile, a node specifies what information it is interested in and what information it wants to share with other nodes. For this purpose, the node profile splits into two sub-components, the so-called information lists(iLists):
• iHave-list (information have list):
The iHave-list holds all the information the node wants to contribute to other nodes. A single entry on the iHave-list is called information item.
• iWish-list (information wish list):
In the iWish-list, the node specifies what kind of information it is interested in. A single entry on the iWish-list is called information wish or wish.
Definition 6 (Neighborhood) A neighborhood is a node’s software component that keeps track of other active nodes in the vicinity, i.e., successfully discovered
nodes.
The process by which information items are distributed among nodes within an opportunistic network is called data dissemination. Rules about distribution are specified by a data sharing protocol that makes use of the node profile. The data sharing protocol is based on two steps: i) node discovery and ii) exchange of information lists. This is elaborated upon in Section 3.3.
3.2
Node Architecture, System Model and Proximity Based
Services
The definitions from the last section, together with the identified opportunistic network services from the last chapter, lead us to an architecture for opportunistic network nodes and a corresponding system model, which we will describe now.
3.2.1 The iClouds Architecture
In order to develop and investigate opportunistic network concepts, the iClouds project [Hei07] was set up at the Telecooperation Group (Computer Science De- partment, Darmstadt University of Technology). iClouds is an abbreviation for information clouds. Imagine a pedestrian walking around a city center and encoun- tering other pedestrians. Each person he passes could be a potential information
PA UN IF ID IM S ...
Message Exchange Node Discovery
Neighborhood User Interface & Application Logic
Node Profile
Information Distribution Service Identity Management Service Security Service
Presence Awareness Service User Notification Service Information Filtering Service
PA: UN: IF: ID: IM: S:
Figure 3.1: Node architecture
bearer. Thus, our user wanders through an imaginary cloud of information or in- formation cloud. This metaphor grasps the fundamental idea of collaboration in opportunistic networks. The effortless sharing of information by passing messages in a spontaneous manner.
The goal of the iClouds project was to investigate methods for sharing in- formation among a group of users, based on individual user contribution. The opportunistic network dissemination protocol is such a method.
As a part of iClouds, an architecture for opportunistic network nodes was developed, shown in Figure 3.1. The architecture reflects the common building blocks from Chapter 2 (see Section 2.4) and the definitions from the last section.
We distinguish between four different layers. The bottom layer handles simple communication issues, i.e., adjacent node discovery and one-hop message exchange between nodes in communication range. For example, the neighborhood data structure on the third layer makes use of the node discovery mechanism.
The common services are located on the second layer. Each service can use functionalities provided by other services or by the bottom communication layer. Note that the service layer is extensible for new services that might be needed by future applications.
The node profile and neighborhood data structure, being present in all oppor- tunistic network applications, resides on the third layer.
An application’s specific logic and user interface reside on the topmost layer. To fulfill its purpose, this layer has access to all layers below.
3.2.2 System Model
The opportunistic network nodes define our opportunistic network system model. An example of this model is depicted in Figure 3.2. The figure shows three Infor-
3.2 NODE ARCHITECTURE, SYSTEM MODEL AND PROXIMITY BASED SERVICES 39 Information sprinkler/sink Mobile node communication range connection link backbone link (optional)
Figure 3.2: System model for information dissemination
mation Sprinklers and the optional sprinkler backbone. A connection link between nodes is indicated by a black dashed line. It shows several mobile nodes with their communication ranges (dotted sphere). Note that in practice, the communication range of a node is not an ideal sphere, due to communication signal interferences with the surroundings. For example, in city settings, buildings will reduce commu- nication range, whereas in a park with direct line of sight, communication range will not be harmed (see Chapter 6.2).
3.2.3 Proximity Based Services using Information Sprinklers
As already stated in Chapter 2, with our opportunistic network system model, a simpler form of a Location Based Services is possible. We call it proximity based services. It exploits the physical proximity of a user to an Information Sprinkler. Since an Information Sprinkler is set up at a dedicated place, it can store its geographical location and provides an information service that is useful for that location. By passing an Information Sprinkler, a user’s device learns its current geographical location and is provided with information that might be useful to the user. For example, an Information Sprinkler located at the entrance of a shopping mall might disseminate the latest advertisements belonging to the various shops at the mall. The adPASS system (Section 6.1.1) uses an Information Sprinkler for this purpose.
Alice Bob O L L E H HELLO Add Bob to neighborhood Add Alice to neighborhood
(a) Alice and Bob dis- cover each other
Alice Bob Y L P E R _ G N I P PING periodically refresh neigborhood entry for Bob or remove entry, if a time-out occurs
(b) Check node liveliness
Figure 3.3: Node discovery and liveliness check