Since in the spontaneous PN-F, the federation is formed in the absence of a fixed infrastructure; therefore we extend our proposal for PN cluster formation i.e. PNRP, for the initiation, formation and usage of spontaneous PN-Fs. The Personal Network Routing Protocol (PNRP) extension for PN-F is a variant of on-demand multi-hop routing protocol such as AODV and DSR, which adapts to the personal networking environments for communication among PNs. The PN-F creator decides the PN-F members and sends them, the PN-F profile. On the reception of PN-F profile, if the initially proposed members decide to be the part of PN-F, they exchange their PN-F participation profile with the PN-F creator.
Therefore, PN-F initiation becomes an intrinsic capability of PN-F formation owed by PNRP. Moreover, PN-F routing mechanisms assist to determine the routes towards the desired PN-F members and provide means to form and to use PN Federations.
PN-F Topology Discovery, Initiation and Formation
PN-F routing builds routes using a join request/reply query cycle. When a PN desires to create a PN-F with certain defined PN-F members, it creates a PN-F profile and sends to its FMs, piggybacked with a Join-Request (JR) message, leveraging the inter-cluster routes; thanks to PNRP's PN-cluster formation capability. As show in Figure 1, in order to create a PN-F with PN2, PN3 and PN4, the PN1 (i.e. PN-F creator) sends the JR message to its FMs. The Join-Request (JR) message contains two lists of PN-IDs such as "destination-list", which stores the potential PN-F participants and "destination-attained-list", which represents the PNs already attained by the JR message. As FMs receive the JR, they investigate whether the PN-ID of their neighbouring PN is mentioned in JR message destination-list. In case of positive response, the JR is forwarded to the FM of the neighbouring PN. In contrast, if the FM does not find the adjacent PN in the destination-list and the potential participant PNs are not accessible through other FMs of the same PN, a "Connectivity PN-F" can be formed with the
adjacent PN in order to relay the PN-F information towards the potential PN-F members.
On the reception of JR message, the neighbouring PN's FM first removes its PN-ID from JR's destination-list and then put it in the destination-attained-list. Moreover it also sets up backward pointers in PN-F routing table, towards the PN which sent the JR, as a next-hop to reach all the PNs mentioned in the destination-attained-list. PN1's FM (i.e. A) forwards the JR to PN2's FM (i.e. B), which sets the entries in its PN-F routing table that PN1 is reachable through its FM B.
The above presented mechanisms are repeated at each next PN until all the PNs mentioned in the JR destination-list are reached. Finally, on the reception of JR if the PN finds the JR's destination-list is empty, it will send a Joint-Request-Ack (JRA) message (by replacing the entries of destination-attained-list with destination-list) backwards to the PN which forwarded the JR message. As shown in Figure 1, the JRA is initiated by PN4, which receives the empty destination-list. The mechanisms of setting backward pointers to the PNs declared in destination-attained-list and moving the PN-IDs from destination-list to destination-attained-list at every next PN is also repeated for JRA message until it reaches the PN-F creator, who triggered the PN-F formation. The exchange of JR and JRA messages facilitate the establishment of PN-F routing tables at the Federation Managers of PNs, which are participating in the PN-F.
Data Forwarding and PN-F Use
During the integrated PN-F topology discovery process, the entire participant PNs learns the routes not only towards the PN-F creator but also towards each other. These routes are stored in the PN-F routing table and are leveraged to exchange, initially the PN-F profiles and then the PN-F participation profiles in order to form the PN-F. To this end, the data packets destined to any other PN are first forwarded to the FMs, which further routes the data with the help of PN-F routing table. The profiles are stored at the FMs (the entry points of PNs), which are used to enforce PN-F policies on the PN-F routing in order to ensure secure PN-F overlay concept.
