The Network Layer Architecture 

Context in source publication

Context 1

... shown in Figure 2, the IST MAGNET project [9, 12] has proposed a PN architecture, which is composed of three abstraction levels; the connectivity, the network and the service abstraction levels [18]. The connectivity abstraction level consists of various wired and wireless link layer technologies, organized in radio domains, including infrastructure links. The link layer will allow two nodes implementing the same radio technology to communicate if they are within radio range. To allow any two nodes within a PN to communicate, a network abstraction level is needed. The network level divides the nodes into personal and foreign nodes , based on trust relationships. Trust relationship is a way nodes can gauge trustworthiness of other nodes with whom they interact. There can be different levels of trust relationships. Only nodes that are able to establish long term (permanent) trust are personal and can be part of a user's PN. personal nodes that are ‘nearby’ and have such a long term common trust relation form a ‘ cluster ’. Clusters can communicate with other clusters via infrastructure. The next section will further develop the architectural concepts of the network abstraction level. The highest level in this architecture is the service abstraction level, which incorporates two types of services; public and private services. Public services are offered to anyone whereas private services are restricted to the owner or trusted persons by means of access control and authentication. The network level has to be as independent as possible from the underlying connectivity level so that all current and future wireless communication technologies can be supported. In the Internet, IP was designed to meet this requirement and therefore IP is the underlying protocol for packet transfer also for PNs. In this architecture [9, 10, 16, 30], the home network of a person will likely a single cluster, the car network another, the PAN of personal nodes around the person (called Private PAN or P-PAN) a third and so on. The link layer technology used to form a cluster will limit the geographical spread and size of a cluster. All clusters work as local networks, therefore need their own independent networking solutions such as self- configuration, self-maintenance, addressing, routing, etc. The formation and maintenance of clusters is a purely local process and does not need any support from infrastructure. Clusters are dynamic in nature. Nodes are switched off and on as well as roam and might suddenly show up in a different cluster. Clusters can split for example, when a person leaves some devices behind and takes some with him similarly, clusters can merge when a person comes back home with his devices. Therefore, the solutions used in all the clusters, including the P- PAN, will be the same so that they can merge and split without extra effort. An important requirement for cluster formation is the capability to keep foreign nodes out of the clusters and only include personal nodes (see Figure 3). This is done by using a special authentication and authorization mechanism [17, 11]. The cluster formation approach we propose is opportunistic and tries to make the clusters as large as possible. The purpose here is to be able to use intra-cluster mechanisms to provide communication between personal nodes as often as possible, since it is likely to be more efficient than using infrastructure networks. Inter-cluster mechanisms involve infrastructure which is not always available and is, in many cases, poorer (in terms of performance, cost, etc.) than direct multi-hop intra-cluster communication. Clusters are defined from the connectivity and trust perspective. Therefore, if there is connectivity, a cluster can be very large with many hops between nodes. However, typically we expect clusters to have a small number of nodes and a limited geographical span, because of the way they will be deployed. To facilitate communication between remote clusters, each cluster will have a special node called gateway node that can support communication to the other clusters and also to the rest of the outside world. We briefly explain this entity below. Gateway (GW) node is a personal node within a cluster that enables connectivity to nodes outside the cluster. GW nodes have links to infrastructure. GW nodes have some special requirements such as address translation, set up and maintenance of tunnels, filtering of incoming traffic, etc. They should preferably be powerful devices since the tasks required by such a node might be quite heavy. The process of finding capable GW nodes with links to foreign nodes or the infrastructure is a joint task of the nodes in a cluster. It is part of the cluster formation process. The selection of GW nodes for a particular data session depends on several aspects not only decided by the cluster but also on the person owning the PN. There can be more than one GW node simultaneously active in a cluster. After a cluster has discovered which nodes provide connectivity to the infrastructure, it initiates the establishment of tunnels between these GW nodes and the GW nodes of remote clusters. GW nodes are responsible for setup of outgoing or incoming tunnels. A single GW node can also take the sole responsibility in a cluster. We shall not discuss the formation of the secure IP tunnels here. Security related protocols such us IPSec [15, 23] can be used here. More about the security issues are discussed in detail in [11]. When clusters want to communicate with remote clusters through their GW nodes, they first need to locate each other. Further, inter-cluster communication needs to be secure and maintained when clusters merge, split and their nodes roam or are activated/deactivated. This will be accommodated through dynamic tunnel establishment mechanisms. The aim of this is to both facilitate secure inter-cluster communication as well as solve the mobility problem. Each node will have an intra-PN IP address that stays the same as long as the node is part of the PN. Since nodes can roam freely and may shift to another cluster, there is no possibility for hierarchical organization of intra-PN addresses without introducing address changes. If address changes still need to occur within the PN, then the mobility problem is not entirely solved, which is one of the purposes of introducing a flat intra-PN addressing scheme. IV. S OLUTIONS FOR I NTER -C LUSTER C OMMUNICATION There are many solutions to enable inter-cluster communication which is an important task for enabling PNs. We present four different solutions for dynamic tunneling between clusters in the following subsections. This is the simplest and most straight forward solution, where the GW nodes of the clusters establish tunnels to a central server, the PN Agent. The PN agent is an infrastructure- based management entity that knows the location of all clusters in the PN. The PN agent has a fixed address and can be contacted from any Internet-connected infrastructure network. Each personal node knows the address of the PN agent of the PN it belongs to. This address can, for instance, be distributed during the personalization of the personal nodes. GW nodes, which are always personal nodes, therefore know the address of the PN agent. In this solution, the GW nodes set up tunnels to the PN agent. Hence, all inter-cluster traffic goes through the PN agent as shown in Figure 4. As soon as a GW node in a cluster detects an infrastructure network with connectivity to the PN agent, it may use it to establish a tunnel to it. As the cluster roams, different access networks may be chosen for the tunnel. As the GW nodes keep at least one tunnel connected to the PN agent at all times, inter-cluster communication will work and the mobility problem is handled. Further, since the tunnels are initiated by the GW nodes, it will work even if the GW nodes are using infrastructure connections with dynamic addressing and NAT, such as from WLAN ...