3.3.1
Connectivity abstraction level
As mentioned earlier, we do not consider the connectivity abstraction level in this thesis. Nevertheless, an accurate abstraction of this level is still needed in order to correctly design the higher abstraction levels and to understand the connections and interactions with the lower levels. This level is composed of devices with Radio Interfaces connected to each other via different Radio Domains corresponding to given radio technologies. Figure 3.2 shows an example of devices with Radio Interfaces participating in several separate Radio Domains.
Problems addressed at this level concern link layers, medium access con- trol (MAC), the physical link, and their interrelationships. Solutions for this abstraction level can rely on existing technologies, such as WLAN [82] and Bluetooth [84], but also future technologies, such as IEEE 802.15.3 [85] and the new air-interfaces developed in IST MAGNET and MAGNET Beyond
3.3. THE THREE ABSTRACTION LEVELS 39
Figure 3.2: Nodes with Radio Interfaces communicating through Radio Do- mains
[201][202]. Since, it is virtually impossible to adopt one single radio technol- ogy for PNs, we believe that many different kinds of radio technologies will be utilized. Some are suitable for short range high speed communication, while others are more suitable for access to the Interconnecting Structures. Furthermore, radio technologies will continue to evolve. Since older Nodes may use older technologies, it is important to enable gradual shifting from older technologies to newer ones.
At the same time, these different radio technologies may be so different that they will not be able to interoperate with each other at the connec- tivity abstraction level in any meaningful way (e.g., IEEE 802.15.1 [84] and 802.15.3 [85]). Therefore, we need devices with multiple radios and a net- work abstraction level that can glue all these technologically different radio technologies, both current and future, together.
3.3.2
Network abstraction level
Concepts, such as Clusters and PNs are defined at the network abstraction level. Given a single user, there are two types of Nodes at the network level: Personal Nodes and Foreign Nodes. Personal Nodes are Nodes that belong to the user, while all other Nodes are Foreign Nodes. The PN is the collection of all that user’s Personal Nodes, both remote Nodes and the Nodes, which are in the close vicinity of the user. Active Personal Nodes are grouped into Clusters depending on their possibility to communicate with each other without external assistance. A user is likely to have several active Clusters, such as for instance: a home Cluster, an office Cluster, a car Cluster, etc. The Cluster directly around the user is also called the P-PAN and can consist of carried and wearable Personal Nodes. In other words, the PN is an extension
Figure 3.3: PN Network Level View
of the P-PAN and may contain several active Clusters, both remote and in the vicinity of the user. See, for instance, Figure 3.3.
The network level architecture separates the communication among Per- sonal Nodes of the same PN from the communication to, from, and among other Nodes and devices. To make this happen, each Node must know which PN it belongs to and must be able to tell if another neighboring Node is a Personal Node or not (i.e., belongs to the same PN). The process of in- troducing a Node into a PN is called personalization and is a prerequisite to any Cluster and PN formation mechanisms. Personalization should only take place once when a new Node is acquired for the first time by the user. A Node then “permanently” remains a Personal Node until the user decides otherwise. Which Nodes the user chooses to personalize is obviously up to the user, but it could include Nodes he/she owns or otherwise possesses for an extended period of time.
All personalized Nodes become Personal Nodes to that user and each Personal Node establishes mutual Trust Relationships with all the other Per- sonal Nodes. The personalization mechanism is responsible of establishing all the necessary Trust Relationships among all the Personal Nodes. Auto- matic mechanisms are needed to efficiently implement the personalization of new Nodes. The Trust Relationships must be maintained in an accurate, secure, easy to use, and efficient way so that two Personal Nodes always will be able to communicate securely. Before a Node changes owner, is discarded, or when a personalized Node is compromised, the personalization should be
3.3. THE THREE ABSTRACTION LEVELS 41
invalidated by the user. All Trust Relationships with a compromised or ex- cluded Node must be removed immediately. Section 3.4 further discusses the personalization procedures.
The next step is to enable the Nodes to distinguish Personal Nodes from Foreign Nodes among its neighbors. This is the first step of the Cluster for- mation and should be fast and light-weight as well as secure against currently known attacks (such as replay and man-in-the-middle attacks) and denial-of- service (DoS) attacks. When some Personal Nodes find each other, they can start to exchange routing information and other kinds of information and thereby form a Cluster consisting of only Personal Nodes. Foreign Nodes are kept out of these mechanisms to protect the organization of the Cluster. Section 3.5 discusses Cluster organization further.
Not all the Personal Nodes will be able to communicate with each other in this way due to the characteristics and limitations of the radio technologies available to Cluster Nodes. Instead, a PN will consist of several Clusters at various remote locations. The only way to connect the different Clusters is to use Interconnecting Structures (such as the Internet). To this end, tunnels between the Clusters will be established and maintained. In Section 3.6, we cover more about these inter-Cluster tunnels and other PN organization aspects.
Though a lot of communication will take place within the PN among a user’s Personal Nodes, it is also important that communication can take place between PNs and with non-PN devices. This we call foreign communication; this topic is covered in Section 3.7.
3.3.3
Application and service abstraction level
On top of the network abstraction level, we find the application and service abstraction level. This level consists of applications running on the Nodes that offer Services to each other as well as using these Services. Whether the Node where a Service is running is a Personal Node or not also influences this abstraction level since it sits on top of the network level. We make a distinction between Personal Services and Foreign Services depending on whether the Service is offered by a Personal Node or a Foreign Node.
Further, a Service can be Public or Private. Private Services are offered and used only by Personal Nodes in the PN sense. This implies that these Services can only be used by the person him/herself within the PN. It is important to realize that the protection offered by the fact that a Node is a Personal Node is not always satisfactory as the actual user of that Personal Node still is unknown to the Service. Some very sensitive Private Services may therefore require extra security such as authentication of the real end- user, for instance, by using passwords or biometrics.
On the other hand, Public Services are offered by the service owner to anyone that the owner wants to share the Services with. Public Service can
Figure 3.4: Service Discovery in a PN
be offered by someone’s PN as well as by commercial providers. Many Public Services do not require any Trust Relationship, while others may still require establishment of an ephemeral Trust Relationship between the Service Node and the Client Node. In some cases, service usage may be charged.
To further improve the usability of a PN, a service discovery and man- agement framework is defined that can support the applications and enable auto-configuration and adaptation. Figure 3.4 shows how this PN service framework works. Each Cluster has a Service Management Node (SMN), which is elected among the Cluster Nodes and works as a repository where all Services are registered. Clients in the Cluster that wish to use a partic- ular Service can query this repository. To also facilitate usage of Services across Clusters, the SMNs in the different Clusters communicate with each other and share Service information. The SMNs can also advertise the Public Services of the PN to surrounding Foreign Nodes as well as register Foreign Public Services in case a Client on a Personal Node wishes to use a Foreign Service. In addition to service discovery, the SMNs may also control the ongoing service sessions to better manage the service provisioning. However, service discovery and management are beyond the scope of this thesis. For further information, see [134][65][66][139].
Another important functionality at this level is naming and name reso- lution. The use of names is crucial in order to build a user-friendly PN; a requirement identified in Section 2.1.4. Basically anything that needs to be seen by the user should have its own name, such as Nodes, PNs, Services, and perhaps even Clusters. The naming scheme must provide a flexible naming resolution to the PN and at the same time be compatible with the naming schemes used in the current infrastructure, e.g., the Domain Name System