GB2493133A

GB2493133A - Ubiquitous networking

Info

Publication number: GB2493133A
Application number: GB1111955.9A
Authority: GB
Inventors: Grant Paul Millar; Christos Politis; Tipu Arvind Ramrekha; Emmanouil Antonios Panaousis
Original assignee: KINGSTON UNIVERSITY HIGHER EDUCATION CORP
Current assignee: KINGSTON UNIVERSITY HIGHER EDUCATION CORP
Priority date: 2011-07-12
Filing date: 2011-07-12
Publication date: 2013-01-30
Also published as: WO2013008026A3; WO2013008026A2; GB2493133A8; GB201111955D0

Abstract

Numerous embodiments are disclosed relating to ubiquitous networking i.e. in a Mobile Ad Hoc Network (MANET). One embodiment relates to distribution of a signed certificate, e.g. DC602, from a certificate authority, CA, to all member devices 604, 606, 608, in the ubiquitous network, to facilitate authentication and establishment of secure connections. Some further embodiments relate to optimizing routing. One embodiment relates to optimising peer-to-peer functionality by identifying a nearest multi-point relay device and associating a joining device to the relay device by concatenating identifiers. A further embodiment relates to providing peer-to-peer functionality in a proactive routing protocol network, involving maintaining hash tables which include hash identifiers of data objects. A further embodiment relates to searching a peer-to-peer relay overlay in a network implementing a reactive routing protocol, involving receiving a search string and hashing it to generate a key used for look-up. A further embodiment relates to peer-to-peer functionality in a network of devices configured to implement proactive and reactive routing protocol. A further embodiment relates to routing in accordance with a plurality of routing protocols involving selecting a candidate route from a set of candidate routes based on a determined link metric and user quality requirements. Embodiments can be implemented by a module that comprises a core that acts as a 'controller' to direct routing efforts for ubiquitous networks. The core provides interfaces, in the form of Application Programming Interfaces (AP Is), to components that implement ubiquitous networking routing functionalities. The components, in turn, provide APIs to module parts that implement the actual logic used to perform these functions.

Description

FRAMEWORK FOR UBIQUITOUS NETWORKING

FIELD

The present invention generally relates to ubiquitous networking.

BACKGROUND

A ubiquitous network, such as a mobile ad hoc network (MANET), is a collection of nodes that are able to communicate autonomously without any central infrastructure.

Among the different routing protocols for ubiquitous networks such as MANETs, the MANET Working Group (WG) of the Internet Engineering Task Force (IETF) mainly favours the proactive and reactive approaches. However, a single approach is not always optimal for all environments.

Ramrekha, T., Panaousis, E., and Politis, C., "A Generic Cognitive Adaptive Module (CAM) for MANETs" draft-ramrehka-manet-cam-00.txt (work in progress), June 2010, which is hereby incorporated by reference in its entirety, describes a generic Cognitive Adaptive Module (CAM) that can be utilized in conjunction with different MANET routing protocols. The CAM is able to take advantage of the better features of the proposed proactive and reactive approaches while rendering these to be adaptive according to the changing network state. The text of this proposal can presently be found at the following link: http://tools.ietf,orq/html/draft-ramrekha-manet-cam-00.

SUMMARY

The embodiments disclosed herein relate to ubiquitous networking. Some embodiments relate to optimizing routing. Some embodiments relate to security and privacy. Some embodiments relate to a peer-to-peer overlay.

According to one embodiment, there is provided a method of implementing security for a ubiquitous network, the method comprising receiving, by a device intending to join the network, security information from a certificate authority, the security information including: a digital certificate that is signed by the certificate authority and that includes an identifier of the device and a public key of the device, and a public key of the certificate authority; and transmitting the signed digital certificate to member devices of the network via one or more hops, to thereby allow each of said member devices to authenticate the device and to establish secure associations with said device.

In one embodiment establishing a secure association between said device and one of the member devices comprises sharing a symmetric key encrypted using the public key of said device.

In one embodiment, the method further comprises using the symmetric key to encrypt data communications between said device and said one of the member devices.

In one embodiment, authenticating the device comprises verifying the digital signature using the public key of the certificate authority.

In one embodiment, the security information further includes a shared network key.

In one embodiment, the method further comprises including a thumbprint algorithm of said device in the digital certificate and hashing the digital certificate using said thumbprint algorithm.

In one embodiment, the signed digital certificate is distributed to substantially all of the member devices of the network.

According to one embodiment, there is provided a device for implementing security for a ubiquitous network, the device comprising means configured to receive security information from a certificate authority, the security information including: a digital certificate that is signed by the certificate authority and that includes an identifier of the device and a public key of the device, and a public key of the certificate authority; and means configured to transmit the signed digital certificate to member devices of the network via one or more hops, to thereby allow each of said member devices to authenticate the device and to establish secure associations with said device.

In one embodiment, the device further comprises means configured to receive digital certificates from other devices, the received digital certificates signed by the certificate authority and including identifiers and public keys of the corresponding devices; and means configured to store the received digital certificates.

In one embodiment, the device further comprises means configured to establish a security association with said other devices using the received digital certificates.

In one embodiment, authenticating comprises verifying the digital signature using the public key of the certificate authority.

In one embodiment, the device further comprises means configured to include a thumbprint algorithm of the device in the digital certificate, and to hash the digital certificate using the thumbprint algorithm.

According to one embodiment, there is provided a method of optimising peer-to-peer functionality in a ubiquitous network having a plurality of devices including multi-point relay devices and implementing a proactive routing protocol, the method comprising identifying a nearest multi-point relay device for a joining device; and associating said joining device to said nearest multi-point relay device by concatenating a first identifier of said nearest multi-point relay node with a second identifier of said joining device.

In one embodiment, the method further comprises identifying a new nearest multi-point relay device for the device; associating said device to said new nearest multi-point relay device by replacing said first identifier with a third identifier of said new nearest multi-point relay device.

According to one embodiment, there is provided a device for implementing peer-to- peer functionality in a ubiquitous network having a plurality of devices including multi-point relay devices, the device comprising means for implementing a proactive routing protocol; means for identifying a nearest multi-point relay device; and means for associating the device to said nearest multi-point relay device by concatenating a first identifier of said nearest multi-point relay node with a second identifier of said joining device.

In one embodiment, the device further comprises means for identifying a new nearest multi-point relay device for the device; means for associating the device to said new nearest multi-point relay device by replacing said first identifier with a third identifier of said new nearest multi-point relay device.

According to one embodiment, there is provided a method of providing peer-to-peer functionality in a ubiquitous network having a plurality of devices configured to implement a proactive routing protocol, the devices maintaining hash tables that include identifiers of data objects in the form of hashed metadata, the method comprising hashing metadata of a new data object that is to be added to a peer-to-peer overlay of the ubiquitous network by a first one of the devices, to thereby generate a key; matching the generated key to an identifier of a second one of the plurality of devices, the identifier stored in a routing layer table that also includes an IP address of said second one of the plurality of devices; and transmitting the generated key to said first one of the devices using said IP address.

According to one embodiment, there is provided a device for implementing peer-to-peer functionality in a ubiquitous network having a plurality of devices, the device comprising means configured to implement a proactive routing protocol; means configured to store a hash table that include identifiers of data objects in the form of hashed metadata; means configured to hash metadata of a new data object that is to be added to a peer-to-peer overlay of the ubiquitous network, to thereby generate a key; means configured to match the generated key to an identifier of one of the plurality of devices, the identifier stored in a routing layer table that also includes an IP address of said one of the plurality of devices; and means for transmitting the generated key to said one of the devices using said IP address.

According to one embodiment, there is provided a method of searching a peer-to-peer overlay of a ubiquitous network having a plurality of devices configured to implement a proactive routing protocol, the devices maintaining hash tables that include identifiers of data objects in the form of hashed metadata, the method comprising receiving a search string at a first one of the devices; hashing the search string with a hash function, to thereby generate a key; matching the generated key to an identifier of a second one of the plurality of devices, the identifier stored in a routing layer table that also includes an IP address of said second one of the plurality of devices; and transmitting a request for a data object corresponding to said search string to said second one of the devices using said IP address.

According to one embodiment, there is provided a device for searching a peer-to-peer overlay of a ubiquitous network having a plurality of devices, the device comprising means configured to implement a proactive routing protocol; means configured to store a hash table that include identifiers of data objects in the form of hashed metadata; means configured to receive a search string; means configured to hash the search string with a hash function, to thereby generate a key; means configured to match the generated key to an identifier of one of the plurality of devices, the identifier stored in a routing layer table that also includes an IP address of said one of the plurality of devices; and means configured to transmit a request for a data object corresponding to said search string to said one of the plurality of devices using said lP address.

According to one embodiment, there is provided a method of searching a peer-to-peer overlay of a ubiquitous network having a plurality of devices configured to implement a reactive routing protocol, the devices maintaining identifiers of data objects in the form of hashed metadata, the method comprising receiving a search string at one of the devices; hashing the search string with a hash function, to generate a key; and transmitting the key in a lookup packet of the peer-to-peer overlay if a time limit is exceeded, and otherwise transmitting the key in a routing layer packet.

According to one embodiment, there is provided device for searching a peer-to-peer overlay of a ubiquitous network having a plurality of devices, the device comprising means configured to implement a reactive routing protocol; means configured to store identifiers of data objects in the form of hashed metadata; means configured to receive a search string; means configured to hash the search string with a hash function, to generate a key; means configured to transmit the key in a lookup packet of the peer-to-peer overlay if a time limit is exceeded, and otherwise transmit the key in a routing layer packet.

According to one embodiment, there is provided a method of providing peer-to-peer functionality in a ubiquitous network having a plurality of devices configured to implement a proactive routing protocol and a reactive routing protocol, the method comprising looking up node identifiers in the distributed hash table for each of the keys; matching the node identifiers to the corresponding IF addresses; and transmitting the keys to the nodes having the corresponding IP addresses.

According to one embodiment, there is provided a method for implementing routing in a ubiquitous network in accordance with a plurality of routing protocols, the method comprising obtaining a link metric based on a received control packet; determining a set of candidate routes the obtained link metric; determining a user quality requirement for a received data packet that is to be routed; and selecting one of the candidate routes based on the determination of the user quality requirement.

In one embodiment, the method further comprises determining a network state value indicative of the state of the network; comparing the obtained network state value to a corresponding threshold value; and altering the routing behaviour in accordance with the comparing.

According to one embodiment, there is provided a device for implementing routing in a ubiquitous network, the device comprising routing means configured to implement a plurality of routing protocols; and control means configured to control the routing means to provide routing functionality using at least one of the plurality of routing protocols by: obtaining a link metric based on a received control packet; determining a set of candidate routes the obtained link metric; determining a user quality requirement for a received data packet that is to be routed; selecting one of the candidate routes based on the determination of the user quality requirement.

In one embodiment, the device further comprises means configured to determine a network state value indicative of the state of the network; means configured to compare the obtained network state value to a corresponding threshold value; and means configured to alter the routing behaviour in accordance with the comparing.

Embodiments can be in the form of a hardware implementation, a software implementation, or a mixture of both. Thus any of the means', components' and parts' defined herein can be implemented as code modules in different combination in a computer. A computer program product could be involved in the implementation of an embodiment, either as a complete set of computer executable instructions capable of configuring, on its own, the performance of one or more of the embodiments, or as a set of instructions engaging pre-existing operable software components on a computer, to cause the configuration of the computer in the desired manner.

Whatever form the computer program product takes, it can be embodied in a computer readable storage medium, such as a magnetic or optical storage medium or a programmable electronics storage medium such as a solid state device, or as a computer readable signal, such as on a wireless communications channel, by which the computer program product can be introduced into a computer. The computer program product may be directly executable, or may require local processing, such as decoding, decompression, or compilation, before it is in an executable condition. All possible ways of achieving configuration of a general purpose device as an implementation of an envisaged embodiment should be considered by the reader.

BRIEF DESCRIPTION OF DRAWINGS

Further embodiments, features and advantages will become apparent to the reader of the following description of specific embodiments, provided by way of example only, with reference to the accompanying drawings, in which: Figure 1 schematically illustrates a module for enabling ubiquitous networking at a node in accordance with an embodiment described herein; Figure 2 illustrates a process of changing routing behaviour in accordance with an embodiment described herein Figure 3 illustrates a process of optimizing routing in accordance with an embodiment described herein Figure 4 schematically illustrates security components and parts for the module illustrated in Figure 1; Figure 5 illustrates a process of implementing security and privacy for a ubiquitous network using the security components and parts illustrated in Figure 4; Figure 6 schematically illustrates the distribution of cryptographic information when implementing network security and privacy in accordance with an embodiment described herein Figure 7 schematically illustrates a peer-to-peer component and parts for the module illustrated in Figure 1; Figure 8 illustrates a process of service discovery for proactive routing protocols in accordance with an embodiment described herein: Figure 9 illustrates a process of enabling searching in a peer-to-peer network overlaying a ubiquitous networking implementing proactive routing protocols in accordance with an embodiment described herein; Figure 10 illustrates a process of searching in a peer-to-peer network overlaying a ubiquitous networking implementing proactive routing protocols in accordance with an embodiment described herein; and Figure 11 illustrates a process of searching in a peer-to-peer network overlaying a ubiquitous networking implementing reactive routing protocols in accordance with an embodiment described herein.

The drawing in which an element first appears is typically indicated by the leftmost digit or digits in the corresponding reference number. In the drawings, like reference numbers may indicate identical or functionally similar elements.

DETAILED DESCRIPTION

In the detailed description of embodiments that follows, references to one embodiment", "an embodiment", "an example embodiment", etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

This detailed description is divided into sections. The first section provides an overview of a computer implemented module that provides a flexible framework to enable interoperable, adaptive and hybrid routing protocol implementation in ubiquitous networks. The second section describes the computer implemented module in more detail. The third section relates to the security and privacy implementations. Finally, the fourth section relates to peer-to-peer implementations.

1. Overview By way of overview, and with reference to Figure 1, a computer implemented module (or simply "module" in this description) according to an embodiment comprises a core 102 that acts as a controller' to direct routing efforts for ubiquitous networks, such as MANET5. The core 102 provides interfaces, in the form of Application Programming Interfaces (APIs), to components 108-122 that implement ubiquitous networking routing functionalities. The components 108-122, in turn, provide APIs to module parts 124- 138 that implement the actual logic used to perform these functions. In an embodiment, all data exchanges among the components 108-122 are enabled through the core 102. The core 102 also defines an interface for receiving packets from lower layers (PHY/MAC) and upper layers (Transport) as well as an interface for sending packets to those layers. To achieve this, the core 102 contains a sequence list' that dictates the flow and control of data as packets are received or in the case of periodical events.

The core 102 contains identifiers 104 of the various components 108-122 and their pads 124-138. In addition, parameter values 105 for routing variables, such as time periods for route discoveries (e.g. HELLO messages every three seconds), are defined in the core 102. These values affect the routing behaviour. Each routing variable is associated with a corresponding component and part. Also provided are cross-layer APIs 106. For example, one of the APIs interfaces with the Transport layer and another API interfaces with the PHYI'MAC layer. Furthermore, a Graphical User Interface (GUI) API provides graphical interfaces for user information and configuration.

In operation, and with reference to Figure 2, the module 100 monitors the neiwork to obtain one or more network state parameter values, for example from packets and other cross-layer information (step 5202). At step S204, the module compares the network state parameter values with defined thresholds, and, if the thresholds are exceeded (step 5206 "YES") the necessary adaptive action is initiated to change the routing behaviour accordingly (step 5208). It will be appreciated that an adaptive action may comprise a switch from one routing protocol to another, such as from a reactive routing protocol to a proactive routing protocol, or a behaviour change within a routing protocol.

Thus, different routing protocol approaches can be utilised according to changes in the network state A change, from one protocol to the other, is one of the possible actions as part of the adaptive actions taken by the module 100. However, the module 100 may be configured such that the adaptive and/or hybrid features can be suppressed, for example by altering the core 100 sequence list (containing the identifiers of those parts and components used to process packets and route data packets in the correct order) and actively using only the desired components and parts. Needless to say, the module 100 may be applied to different Operating Systems (OS) and promote interoperability among implementations that can be plugged into the module 100 in the form of a component and/or a part.

In the embodiment shown in Figure 1, the components comprise a repositories component 108, a monitor component 110, a threshold component 112, an adaptive component 114, a Link Metric component 116, a routing component 118, a Packet and TLV component 120, and any user defined component(s) 122.

The module in a device can use various interfaces for communicating with other devices using the module, such interfaces include WiFi, Long Term Evolution (LTE) and Software Defined Radio (SDR) or Cognitive Radio interfaces.

A brief overview of these components and their parts will now be described.

The monitor component 110 defines the network parameters that will be monitored by its parts and provides the required APIs for these. The functions that are typically provided by the parts include the processing of packets and cross layer information in order to calculate the network parameter as specified by the monitor component 110.

The parts have to follow the API specification of the core. The monitor parts indicate the parameters that will be compared to their thresholds.

The threshold component 112 defines the thresholds that will be defined by its parts and provide the required APIs for these. The threshold component 112 also specifies the adaptive component 114 parts to be activated in case a threshold has been exceeded. The threshold parts 126 implement the logic for comparing the values of the thresholds with the monitored values. They indicate the adaptive part of the adaptive component 114 that has to be activated as a result of a threshold being exceeded.

The adaptive component 114 implements the actions to be taken when activated by the threshold component 112. It provides APIs to the parts 130. The adaptive parts 130 implement actions such as changing the parameters in the core 102 or components, or change active components in the core "sequential list" in order to change the behaviour of the routing process.

The Link Metric component 116 defines link metrics and APIs to Link Metric parts 132 that implement the link metric definition equation. The link metric parts 132 define equations that are used to calculate the link metrics for routing paths, e.g. to select a route with good reliability the equation for link metric to calculate least packet loss links is selected and used to sort the routing tables in the repositories path.

Figure 3 shows a process of using link metrics for optimising routing. At step S302, the module core receives a packet, which is identified (step S304) as a control packet or a data packet, for example. If the packet is identified as a data packet and is intended for the node (steps S306 DATA and 5308 YES), it is sent to the upper (031) layers (step 3310). If the data packet is to be routed (step 5308 NO), then the quality of experience requirements for the packet are determined (step 5312). An optimal route is selected in step 5312 in accordance with information obtained from control packets. More specifically, link metrics are obtained at step S316. Based on the link metrics a set of candidate routes are selected (step 3318). In step S313, one of the candidate routes is selected according to the user quality of experience requirements. The packet is then routed accordingly (step 5320).

The routing component 118 defines APIs to routing parts that are required to route packets from source to destination. Some of the functionalities of the parts that are implemented and interfaced through the routing component are described next. The neighborhood routing protocol part discovers one-hop and 2-hop neighbors. New standards require this as a compulsory component in module. Therefore, components should define the API for basic logics and parameters that are used to interlace with the parts where the Neighborhood Discovery Protocol (NHDP) is implemented. An API that is used to interface with parts implementing the proactive routing algorithm is also defined. Additionally, the reactive routing logic requires an API (required parameters) that are used to interface with parts implementing the reactive routing algorithm. The routing parts 134 comprise a Neighbourhood Discovery part, defining routing logic of Neighborhood Discovery Protocol (NHDP), a proactive routing part, defining routing logic of OLSRv2, and a Reactive routing part, defining routing logic of DYMO. It will be appreciated that other types of proactive or reactive components can be implemented.

The Packet and TLV component 120 specifies the formats of the MANET packets and TL.Vs (components for carrying extra information such as energy of device and security keys). The APIs will then provide an interface to parts to define these TLVs. TLV parts 136 implement the creation of TLVs in routing packets and filling them with values of Link Metric parts when routing packets are used in the network.

The user defined component(s) 122 specify the essential parameters and logics that are required for its parts. The parts will then implement the actual algorithms for the component to fulfill its routing functionality.

The skilled reader will appreciate that the disclosure is not limited to the particular arrangement defined in Figure 1. Furthermore, it will be apparent to the skilled reader how the module can be implemented as part of a node, which typically includes a processor operable to execute computer executable instructions, such as in the form of a computer program. The processor can be connected to a working memory, which may include components of Read Only Memory (ROM) and Random Access Memory (RAM) in order to achieve operability, by way of a bus. Also connected to the processor, either by way of the bus or directly, can be a mass storage unit, which encompasses one or more secondary storage devices such as a magnetic data recording device such as a disk drive, a solid state memory device such as a FLASH memory, or any other suitable device. A communications unit can be provided, and is designed to work as a facilitator in the deployment of adaptive routing protocols for MANETs including adaptive hybrid approaches. A user input unit and a user output unit provide facilities for a user to input data by user input action, and to output data to a user visually, such as by an LCD or LED display, or audibly. In this way, the user can control operation of the node. Application programs can be are typically instanced in 2. Detailed structure As mentioned, the core 102 defines structures essential for the operation of a ubiquitous networking routing protocol. It receives packets from the Data Link or Medium Access Control (MAC) lower layer, from upper Transport layer and from Overlay APIs. It sends packets to the Data Link or Medium Access Control (MAC) lower layer, and to upper Transport layer or to Overlays through APIs. Furthermore, it forwards packets, as appropriate and determined by the active routing algorithm without passing packets to the upper layers, i.e. acts as a router. The core 102 can also process a packet to check if it is well formed, and to check the packet type i.e. data, DYMO(-req, reply, -error), OLSRv2 (-TC), NHDP (HELLO). It also store and send packet information to the right module component, and receives data from the module components to generate unicast packets for a specific IP address or generate broadcast packets for all IP addresses in its subnet. It also stores Names and Identifiers for Components, Parts and variables in those Components and Parts. All components, parts and variables changeable by users have to be declared here in the module core. It also sends the packet information required to components as specified by the "sequence list". It also stores user input information in appropriate data structures, e.g. the transmission coverage distance of transmittor (R_trans).

2.1 Monitor component and parts The monitor component processes the information from the API to check that it is well formed, and to verify that the required part or parts to send the information to, sends the information through the APIs to the right parts, declares data strcutres to store results for the monitor parts that have been declared in the core, and store the results from parts in data structures. The parts 124 of the monitor component 110 are described below.

A number of neighbours part calculates the number of neighbours.

A node density part calculates the number of nodes in a given area around itself. It finds the number of 1-hop nodes. It then finds the number of 2-hop neighbours. In one embodiment, it then adds the number of 1-hop and 2-hop nodes and divides it by (fI*(R_trans)2). The determined value represents the node density. Other node density functions are, of course1 possible.

A rate of change of neighbour part keeps a list of "{destination, next hop}" neighbour tuple. It also keeps a Change_interval timer that stores the time between calls when active. Each time it is called, it checks the value of the local Change nterval timer, it retrieves the current list, and compares with the older stored list to check the tuples. It counts the changes in the corresponding tuples divided by the change_interval. This value, Route change" represents the rate of change of routes.

A total number of nodes part estimates the number of nodes in the network without using any packet overhead. This part can have several forms depending on the routing approach. In an embodiment, two parts are defined, namely a "total number of nodes proactive part" and a "total number of nodes reactive part". The "total number of nodes proactive pad" is used with protocols such as OLSR and OLSRv2. In such a part, the total number of nodes in the network is estimated by counting the number of rows in its global routing table in the "repositories component" that should store routes to all reachable nodes in the network. The "total number of nodes reactive part" estimation of number of nodes uses the node density "ND" value estimated by the "Node Density part". The core also passes the value of "Number of hops" (Hops) in the RREP packets received. It takes the average value of the last 3 Hops received to calculate Hop_av = (Hops/3). The estimated number of nodes in the network is then calculated as ((ND/2)*Ilop_av). The latter part is an instance where users would require their own part to be plugged in the core as each user might have their own estimation algorithms or expressions.

A traffic profile part, when activated by the "sequence list", stores the data traffic profile through the current node. It retrieves the type of traffic from packets as well as number of connections that are supported for that traffic type. It stores this information in an appropriate data structure in the Monitor component. This information is kept for a timeout period defined by the user. This part also determines the required QoS information required by the traffic type e.g. delay of looms and jitter of Sms.

Consequently, it establishes the coefficients cx. (for delay), 3 (for jitter), x (for bandwith), S (for packet loss) and c(energy). These fractional coefficients sum up to 1 and are calculated through a normalisation process as below if QoS requirements for delay is a ms, jifter is b ms, bandwith c kbps, packet loss ETX value of d and critical energy value of e Joules: a = {(Na)/((A/a)+(B/b)+(c/C)+(D/d)+(eIE))}, = {(BIb)I((A/a)1-(BIb)+(c/C)+(D/d)+(eIE))}, = {(cJC)f((A/a)+(BIb)+(c/C)+(DJd)+(eIE))}, 6 {(Ofd)fA/a)+(8fb)+(c/C)+(O/d)+(eIEfl}, c {(eIE)/UA/a)+(BIb)+(cIC)+(D/d)+(eIEfl}, where lANaI, IBICIbI, IciciCi, IdiciDi, lelciEl, and A ms is the maximum achievable delay, B ms maximum achievable jitter, C kbps the maximum achievable Bandwidth, 0 the maximum achievable packet loss QoS guarantees as specified by the user and E the maximum energy of the node.

2.2 Threshold component and parts The threshold component is essential for the Monitor and Adaptive components functionalities. The Threshold component parts define the threshold values for the Monitor parts. These values of the Thresholds and adaptive parts that have to be triggered (in case the thresholds are breached) are stored using appropriate data structures in the component. The Threshold parts are defined by the users mostly based on their desired values. For this instance, we will provide Threshold parts or values for the aforedefined Monitor parts and the corresponding "Adaptive Comporient.Parts" that have to be activated. These parts are activated by the Core when new monitored parameter values are calculated by the Monitor component.

A Network Threshold part estimates the network threshold to activate a local proactive or reactive behaviour. In one embodiment, the value of network threshold is set as 10 nodes for total number of nodes in the network (Nodes_total) as obtained from -The Network size Thresold is exceeded if: previously Nodes_total> 10 and new value <=10 Or previously Nodes_total c 10 and new value >10. The corresponding triggered "Adaptive ComponentPart" is "Change Routing Behaviour Part".

A Node density Threshold is set to {6/(fl*(R_trans)2)} as obtained from "Monitor Component. Total number of nodes" part. This trigger the change "NHDP behaviour" and "Proactive behaviour" parts from the "Adaptive Component".

A route stability threshold part (i.e. mobility threshold) specifies the acceptable number of changes in route per unit time. It encompasses changes in routes due to mobility of nodes, changes in Link quality, and battery drainage of nodes. The Route Stability Threshold is set as HeIlo_intervalc(Route_Change/2) seconds and is approximated to (Route_Changel4) seconds. The value for "Route_Change" is obtained from "Monitor component. Rate of change of routes" part. The Hello_interval value is defined in the "Routing Comporient.NHDP" part.

A QoS Threshold part defines the threshold values for the "Link Metric Component" combined with the expression or algorithm from the "Monitor Component.Traffic profile" parts, as set by the user. Therefore the user has to specify values for these Link Metrics based on the defined expression for QoS. Here, the part defines the threshold linearly as Q0S(a* ED)+(13*EJ)+(x*EBX)+(o* ETX)+(cNEN), where ED, EJ, EBX, ETX and NEN are the "Link Metric Component. parts" expression or algorithms. In one embodiment, ceO.5, 13=0, =O, 5=0.5 and c = 0. Thus, the QoS threshold is QoS_threshold = lQoS1QoS2I/QoS10.20 where QoSx is the QoS for route x from a specific source to destination pair and QoS1 is the QoS value of current route I being used to send data. Each user should be able to implement their own threshold value.

User defined threshold parts users to use the Monitor component values to compare with user-defined threshold parameters. The values of thresholds are usually determined using experimental or research based evaluations of Ad hoc networks.

2.3 Adaptive component and parts The Adaptive Component 114 is used for defining the actions that are required as a result of a threshold being breached. Therefore, the component maintains a configurable list of actions to be carried out when called by the "Threshold Cornponent.parts". The part values to be changed are speciflcied. This Component sends the required information to the right parts using the correct API. The variable values form individual parts are defined and stored in the component for visibility purposes. These are then linked to the parts by the component.

A change in routing behaviour part is used to choose specific routing parts in the "Routing Component". By default, based on IETF recommendations, the NHDF part is active. NHDP acts as a neighbourhood discovery protocol to discover and maintain node neighbours at all time, Although, this is active certain variables inside the NHDP can be changed to adjust its behaviour. However, the proactive behaviour and reactive behaviour of the protocol can be modified or switched off as required.

An NHDP behaviour part specifies the changes to be made to the NHDP protocol. It specifies new values for the HELLO_INTERVAL, HELLO_MIN_INTERVAL, REFRESH_INTERVAL and VALIDITY_TIME message TLV. When required by the "Node density Threshold part' the value of REFRESH_INTERVAL is increased proportionally to the node density, ND. When called by "Route Stability Threshold part", the HELLO_INTERVAL is decreased to the value of (Route_Change/4) seconds.

A proactive behaviour part can be turned off as required. This part also specifies changes that are made to proactive protocol variables such as the TC_lritervals. In this case the implemented proactive protocol is OLSRv2 and it is the default mode of operation. If the network size <10 and the "Network Threshold part" identifies that the threshold has been exceeded, the OLSRv2 part in "Routing component" is turned off.

A Reactive behaviour Part can be turned off as required. This part also specifies changes that are made to reactive protocol variables such as the Route_Timeout value. In one embodiment, the implemented reactive protocol is DYMO. For example, if the network size >10 and the "Network Threshold part" identifies that the threshold has been exceeded i.e. network size is now C 10 nodes, the DYMO part in "Routing component" is turned off.

2.4 Link Metric component and parts The Link Metric Component 116 defines the link metrics that are considered for the evaluation of route qualities. The route quality is determined by summing the QoS of the route as specified in the "QoS Threshold part" of the threshold component. In addition, the defined QoS_Threshold is used as the criteria to determine whether a new route has to be chosen if available. The parts specify how the metrics are estimated.

The relevant values of the link metrics estimated at each node are piggybacked into routing control packets such as HELLO packets and RREQ packets by using TLVs as specified in the "Packet/TLV component".

An ETX metric part is the estimated number of transmissions required to successfully send a packet over a link. ETX is defined as the sum of the ELTX values of links that form a given path.

It is assumed that the clocks in all the participating nodes are synchronized. The ELD value can then be calculated by the ED metric part using a timestamp message TLV that is written by each sender. The receiver node on the end of the link then has to use the current clock value. The difference between the two clock values gives the ELD value. Since delay is an additive metric, the ED value of a path is equal to the sum of all ELD values of links within that path.

An ELBVV value may be calculated by the EBW metric part using the ELD value of a link as estimated above. ELBW = Received Packet size/Link ELD. Since bandwidth of a path is constrained by the minimum ELBW along the path, the EBW value is equal to the minimum ELBW value.

An EJ value may be calculated by an EBW metric part EJ metric part. The value is additive in nature. It is the sum of ELI.) values where each EU value is the variance in consecutive ELD values for that link.

S An NEW value may be calculated by an NEN metric part. The NEW value can be included by each node in a TLV when it sends control packet messages to neighbor nodes. If the energy level of a route is required, the sum of NEW can be sent in node TLVs that are incremented at each node along that route.

An Hop Count (HC) value may be calculated by a Hop Count (HC) metric part. The HO value can be obtained from the message header <msg-hop-count> field defined in the MANET packet format.

2.5 Routing Component and parts The Routing Component 118 enables the actual routing algorithms that are used for routing packets, i.e. make the actual packet dissemination and route selection process.

In one embodiment, the default mode of routing is set to proactive mode. The route determination criteria is determined by the Threshold Component. QoS Threshold part.

An WHOP Routing Pan implements the NHOP protocol. NI-lOP for MANETs uses a local exchange of HELLO messages so that each router can determine the presence of, and connectivity to (here, in terms of QoS from the threshold component.QoS Threshold part"), its 1-hop and symmetric 2-hop neighbors. Messages are defined and sent in packets specified in the PacketITLV component 120. NHDP provides continued tracking of neighborhood changes, link bidirectionality, and local topological information up to two hops. The NHDP Routing part is turned on or off, as required, by the routing component, in order to implement the NHDP protocol.

An OLSRv2 Part implements the OLSRv2 protocol. OLSRv2 is a proactive protocol exchanging topology information with other nodes in the network regularly. It is an optimized link state routing protocol with the use of MultiPoint Relays (MPRs). Each node selects as MPRs a set of its neighbor routers that connects it to all of its symmetrically connected 2-hop neighbor routers. MPRs are then used to achieve both broadcast flooding reduction and topology reduction. Flooding reduction is achieved by Topology Control (IC) packets being forwarded by nodes that first receive the traffic have selected it as an MPR (its "MPR selectors'). This mechanism is "MPR flooding'.

A router selects MPRs from among its one hop neighbors connected by "symmetric", i.e., bidirectional links. If two competing MFRs exist, the QoS values of the routes to S the 2-hop neighbours are used as the tie-breaker.

OLSRv2 uses NHDP to determine 1-hop, 2-hop and MPR sets. The objective of this implementation of OLSRv2 is for the node to provide routes based on the QoS value to all destinations in the network. A node signars its MPR selection by extending NHDP HELLO messages to include a MPR Address Block TLV(s) as shown in "Packet/TVL component. OLSRv2 part'. A node reports its willingness to be an MPR in HELLO messages, by adding MPR_WILLING Message TLV. OLSRv2 then uses the NHDP table informations to periodically generate a Toplogy Control (TC) Message that periodically inform nodes throughout the network about these links. These IC messages are only forwarded by the MPR nodes of the IC message source.

A Routing Set is used to determine and record routes to all possible routable addresses advertised by OLSRv2. The Routing Set can be used for packet routing, by using its contents to update IP's routing tables.

A DYMO Part implements the DYMO protocol. The Dynamic MANET On-demand (DYMO) routing pad enables reactive, multihop unicast routing among participating DYMO nodes or routers. The DYMO pad is turned on when required by the Routing component.

The basic operations of the DYMO protocol are route discovery and route maintenance. During route discovery, the originator's DYMO router initiates dissemination of a Route Request (RREQ) throughout the network to find a route to the target's DYMO router. During this hop-by-hop dissemination process, each intermediate DYMO node records a route to the originator. When the target's DYMO router receives the RREQs it extracts the TLVs for Link Metrics and calculates the QoS of the first 3 routes for which RREQs are received. It then responds with a Route Reply (RREP) sent hop-by-hop towards the originator. Each intermediate DYMO node that receives the RREP creates a route to the target, and then the RREP is unicast hop-byhop towards the originator. When the originator's DYMO node receives the RREP, routes have then been established between the originating DYMO router and the target DYMO router in both directions. The NHDP part is used to facilitate the forwarding of packets through to 2-hop neighbours towards the destination. In the case of DYMO, the only reactive part of NHDP is used whereby only changes in the neighbourhood are notified using the HELLO messages. The NHDP process is stopped after route_timeout period. Every time a data packet is forwarded along this path, the route_timeout period is reset.

Route maintenance consists of two operations. In order to preserve routes in use, DYMO routers extend route lifetimes upon successfully forwarding a packet. In order to react to changes in the network topology, DYMO routers monitor routes over which traffic is flowing using NHDP. When the source's DYMO node receives a HELLO due to changes, it deletes the route. If this source's DYMO node later receives a packet for forwarding to the same destination, it will need to perform route discovery again for that destination.

2.6 Repositories Component and parts The Repositories Component defines all the tables and similar structures required to store routing information or lists of interfaces that are utilised for routing. It provides the API necessary to implement tables required by the other components to carry out routing. In one embodiment, there is provided a routing table for NHDP, a routing table for proactive component, and a routing table for reactive part. In addition, the parts for these tables will slightly differ across operating systems.

The Packet and TLV Component 120 specifies the packet format to be used. For example the NHDP, OLSRv2 and DYMO parts respectively specify the HELLO messages, TC messages and DYMO (respective) protocol messages.

2.7 Power Control Component and parts A Power Control Component 121 allow a device to change Physical or MAC layer features such as the transmission power of the utilised device based on information stored by the module. Such information include the remaining energy in the device or a route, the Signal to Noise Ratio (SNR) and Signal to Interference and Noise Ratio (SINR). The Parts 137 of this component define specific logics to carry out such functionalities. This component will use communication interfaces such as the Physical/MAC interface that is defined in the module core.

User defined components 122 implement specific functionality not described above, and two such components will now be described.

3. Security 3,1 Overview Compromised or malicious nodes can lead to a loss of network integrity. Embodiments described herein can be implemented by module 100 in the form of components and parts that provide functionality associated with, but not limited to, network access control, user authorization, user and data authentication and privacy, cryptographic key management, end-to-end packet confidentiality, and end-to-end packet integrity.

However, it will be understood that the described functionality is applicable in general to other devices.

With reference to Figure 4, in one embodiment, the security components implemented by module 100 comprise a key management component 402, access control component 404, and a network layer security component 404. One skilled in the art will appreciate, however, that the same or similar functionality can be provided using more or less components. As before, each of the components 402, 404, 406 defines the APIs and logics that are used for a particular security function, while the corresponding parts implement the actual logics that are used to carry out these functions, The components 402, 404, 406 are connected via the core APIs, and activated according to the aforementioned sequence list" in the core 102 in order to carry out the desired processing. Each security component 402, 404, 406 defines and assigns appropriate values for parts that logically belong to that component.

By way of overview, the key management component 402 implements the mechanisms by which cryptographic keys or password phrases are distributed to nodes in the network and can define how they are further updated and/or deleted. The access control component 404 implements the mechanisms that provide the ability to control access to network resources. In particular, it serves to allow only authorised users to gain access to the network resources or capability. The network layer security component 406 implements the mechanisms that ensure that information content (both control and data traffic) is never interpreted by non-intended receivers and validates the authenticity and integrity of the routing or data packets. Thus, the network layer security component will provide different cryptographic functionalities for the routing (signaling) or data packets. The component can also be used to provide non-repudiation.

3.2 Key management component and Darts In more detail, the parts of the key management component 402 comprise a keying material creation and distribution part 408 and an end-to-end security association part 410, These provide the information that the access control component 404 and the network layer security component 406 use to enable authorised and secure end-to-end communications between nodes. More specifically, and with reference to Figures 5 and 6, before a node 602 is admitted into a network, it communicates with a certification authority (CA) (step S502) in order for the key management component 408 to obtain the following information: 1) A security, pre-shared key, such as, but not limited to, a Wi-Fi Protected Access II (WPA-2) key, to enable the node to access the network. This acts as a first filter of security in the MAC layer. This credential comes with an expiration date defined by the certificate authority -Link layer security; 2) A Digital Certificate (DC), which binds the identifier ID of the node with the public key of the node. This certificate is unique to each node.

3) The public key of the certificate authority, PKCA, which is used to verify the 3D authenticity of the digital certificates of future joining nodes or any other packets signed by the certificate authority.

In an embodiment, the DC includes: i) the identity code of the certificate, ii) the identification of the CA (certification-service provider), and iii) node information.

For example, the identity code of the certificate can comprise: a serial number of the module 100, used to uniquely identify the certificate, a module thumbprint algorithm, used to hash the digital certificate, and a module humbprint" i.e. the hash itself, to ensure that the certificate has not been tampered with.

The identification of the CA may include information identifying the issuer, i.e. the entity that verified the information and issued the certificate, and validity information, such as the date the digital certificate is valid from and the expiration date of the digital certificate.

Module user information may include an identifier of the module user and module user public key information, such as the user's public key and public key algorithm.

The certification authority need not be a third party node, but could be part of the software configured to implement a node according to the described embodiments.

As shown in Figure 6, node 602 obtains a digital certificate DC602 from the certificate authority CA. Upon joining the network 600, the digital certificate is distributed across the network. The digital certificate includes the public key of the intended entrant, to allow member nodes, such as node 608 to establish a secure association.

To enable secure end-to-end communication between nodes of a network, the end-to-end security association parts 410 of the source and destination nodes need to establish shared security attributes between them to support secure communication in the network layer. In that case intermediate nodes, which forward packets within a multi-hop environment, cannot intercept the payload of the packets. Only the destination of a packet is able to decrypt it and retrieve the required information. To this end, users that need to communicate with each other must securely and confidentially share a key, in other words must set up a security association (SA). This SA can be achieved using other pre-distributed keying material provided by the keying material creation and distribution part. For example any user can use the public key (included in its digital certificate) of a designated recipient/destination to provide the latter with a shared symmetric key (i.e. AES-128). Hence only the owner of a private key can decrypt the packets, which provide the symmetric keys guarantying end-to-end security between source and destination. The selection of the symmetric cryptography for ciphering routing or data packets is based on the fact it is much more efficient in terms of complexity and energy consumption compared to the asymmetric cryptography. These are important considerations for mobile wireless devices.

Key management component 402 may include an API for user defined parts (not shown) that will allow users to extend the key management components by developing functionalities such as keying material update and revocation.

3.3 Access Control The access control parts 412, 414 initially enable the user to access the wireless network (step S504) by using a MAC layer access mechanism. Thereafter the authentication and validation of a joining peers digital certificate takes place by the legitimate users in the network. Upon completion of such process the user is authorised to start communicating with the other peers as well as forwarding packets within the multi-hop environment. Another important functionality of these parts is the periodic user authentication during a discovery phase where users need to validate the authenticity of theft neighbours at certain time intervals.

Access control is a fundamental security service for wireless decentralized networks. It is needed to ascertain membership eligibility and to bootstrap other important security services, such as secure routing. Access control is often related to identification and admission and the main issue regarding this, is that the parties must be authorized to gain access to the network resources. The access control component communicate with the MAC layer through the core. The access control component restricts access to network resources for legitimate users who 1) have previously contacted the certificate authority to retrieve a unique and valid digital certificate, which is signed by the certificate authority; and 2) have a non-expired module license indicated by the validity

field in the digital certificate.

Each user has cached the information given by the key management component 402 and when the user decides to join the network, the MAC layer access part 412 uses the pre-shared key to authorize his device in the MAC layer. Also this key will be using to encrypt any packets in the link layer during the participation of the user in the network.

Although a user might know the pre-shared key value, the authentication and authorisation part 414 needs to guarantee to the other users that his digital certificate has been signed, by the certificate authority and it has not yet been expired. To this end, each joining user broadcasts his digital certificate to the other users (one-hop S neighbors) in the network, as shown in Figure 6. In embodiments, this is propagated to n-hop neighbors reaching the edge of the network. In this manner, each other user: 1) Checks the validity of the digital certificate; 2) Obtains the public key of the joining user.

3) Checks the authenticity and integrity of the message sent by validating the digital signature of the joining user It is assumed that (i) SK4 is the private key of the certificate authority and (U) PKCA is the public key of the certificate authority. Each joining module user has been given a digital certificate signed by the certificate authority using the SKca (at step S502), The PKCA is given to authorized module users by the key management component as part of the third piece of information. Thus, existing module users check for the validity and the authenticity of the digital certificate of the joining peer by verifying the digital signature in the digital certificate. Users that advertise digital certificates that their digital signatures cannot be verified are treated as malicious and are denied from access to any network resources such as routing and packet forwarding. Apart from the digital signature of the certification authority the joining user needs to sign the digital certificate using the module thumbprint" algorithm to guarantee its authenticity and integrity. Any receiver of this packet can use the public key of the joining user, which has been retrieved through the digital certificate of the latter, to validate its signature.

As before, embodiments permit defining an API for user defined access control parts that will allow users to use different ways of access the network in a secure way as well as authorize themselves to be granted with network resources by the other users.

3.4 Network layer security The network layer security parts 416, 418 implement different types of cryptographic algorithms that a user might prefer to use to encrypt its packets. These parts are operating based on the key management implementation since any different cryptographic algorithms require their own types of keys. Other functionalities provided by the network layer security parts are routing and data authentication and integrity to validate the authenticity of the packets as well as to confirm that there is no alteration of the original data. Non-repudiation is additionally provided to ensure that a user cannot falsely deny its previous actions and cannot alter or falsely report commitments from other users.

The network layer security parts 416, 418 implement different cryptographic algorithms for different security purposes within the network. The confidentiality part 416 provides end-to-end secure communications. For purposes of explanation, three different types of users are defined regarding their security permissions as follows: 1) Userl = users that act as intermediate nodes by forwarding packets to a destination e validity of the digital certificate; 2) User2 = users, which are either the source or destination of a packet; and 3) User3 = external users that have succeeded to by pass the access control mechanism and they can overhear the traffic1 which is sent among users.

Any user2 who needs to make sure that only the destination of the communication channel (which is user2 type too) will be able to read the routing or data payload must encrypt his packets. The encryption is accomplished by using the security associations established by the end-to-end security association part of the key management component. According to this, the first time a user A wants to communicate with a user 8, user A will use B's public key to send a unique symmetric pair-wise key to establish 3D secure communications in the network layer. The public key of any node is well known to all the users due to the authentication and authorization part 414 of the access control component 404, which distributes the digital certificates of the joining users.

The confidentiality part 416 implements different functionalities such asymmetric ciphering using any asymmetric algorithm such as Digital Signature Algorithm (DSA), ElGamal, elliptic curve cryptography, NTRUEncrypt or RSA (Rivest, Shamir and Adlernan). Another functionality of the confidentiality part is the symmetric ciphering which implements encryption of the data or routing packets. It requires the end-to-end security association part which provides a pairwise symmetric key between any two nodes in the network. In a user2-user2 communication the established pairwise symmetric key can be used as follows: each user2 adds an HMAC to each packet by hashing the payload of the packet along with the symmetric key; each user2 encrypts each routing or data packet using the symmetric key that he/she has established with the other end (destination) of the communication. The symmetric ciphering functionalities can implement any symmetric algorithm such as Advanced Encryption Standard (AES), Blowfish, Data Encryption Standard (DES), IDEA, RC4, Tiny Encryption Algorithm.

The authentication and integrity part 418 refers to routing and data and it is used to ensure that the received packets are indeed sent by the claimed originator and they are not altered. This takes place by using an HMAC (keyed-hash message authentication) method in an end-to-end way. The HMAC involves any chosen cryptographic hash function along with the key, which has been established by the end-to-end security association part. In that manner the receiver of a packet can validate the authenticity of the data since form all the other users only the original source has the unique pair-wise key. In addition, each user that receives a packet can validate its integrity by finding the HMAC of the payload + (symmetric key) and confirming that it is the same with the one user has received.

Other components and parts can of course be defined. For example1 some embodiments include one or more of a keying material update and revocation part in the key management component, a biometric authentication pad in the access control and authorisation component, a privacy part in the confidentiality component, and a wireless intrusion detection component Again, embodiments permit defining an API for user defined network layer security parts that will allow users to communicate in a secure end-to-end way by developing for instance more different ways of applying confidentiality such as different ciphering algorithms. Furthermore secrecy and privacy functionalities will increase the security of the network for instance through anonymity (i.e. identity anonymity and location privacy). Last but not least, different authentication and integrity methods might be introduced in the future.

The interaction between the security components and their respective parts, and the previously-defined components and their respective parts, will now be described.

In embodiments, the repositories component 208 defines the routing table fields that are required by each essential tables that are implemented in the module table parts.

Thus, it may include a digital certificate list part, a public key list part, and a security association list part.

The digital certificate list part defines the list of digital certificates for all the authorized module users. These are obtained by the functionalities of the access control component when a user joins the network for first time. The number of fields for this list is equivalent to the number of users that their digital certificate has been successfully propagated across the network.

The public key list part defines the public keys of the joining peers retrieved from its digital certificate. This list is used in the end-to-end security association part for the establishment of the unique pair-wise symmetric key between two user-2 type users.

The number of fields for this list is equivalent to the number of users that their digital certificate has been successfully propagated across the network.

The security association list part defines the security associations established in the end-to-end security association part of the key management component. Thus for each end-to-end communication channel between two user, each node stores a certain pairwise symmetric key.

The Packet and TLV component 220 may include a digital signature part and an HMAC part. The digital signature part defines one message digital signature TLV for including the cryptographic signature of a packet. When we calculate signatures we never use mutable fields since these change in every hop. The mutable fields are considered as 0 when the signature of a message is calculated.

The HMAC part defines one hash message authentication code TLV for including the HMAC value of a packet. When we calculate HMAC values we never use mutable fields since these change in every hop. The mutable fields are considered as 0 when the HMAC of a packet is calculated.

4. Peer-to-Peer Functionality In MANETs, Peer-to-Peer (P2P) systems form an overlay network. However, P2P networks operate at the application layer while MANETs operate at the network layer or data link layer. Although routing functionality is present in both layers, application layer routing finds a peer containing the desired information within the P2P overlay network, while network layer or data link layer routing is used to discover the physical route to any given node. In other words, the overlay network and its routing algorithm often don't take the physical topology into account. This may lead to unnecessarily long routes.

Distributed Hash Tables (DHTs) provide key-based overlay routing -each node is associated with a NodelD and each data object is assigned a unique key, obtained by using a hashing function. Each peer "owns" a part of the identifier space and stores the (key, value) pairs for keys lying in its space. All of the (key, value) pairs form the DHT. In conventional DHTs, search queries are forwarded to neighbours with NodelDs that are "closer" to the key in the identifier space, with the definition of distance and the details of routing depending on the specific structured algorithm being used.

Embodiments provide peer-to-peer functionality for pro-active and re-active routing.

The solutions can be seamlessly combined if the routing protocol is switched. This is achieved by abstracting the DHT functions (of the pro-active solution) to the routing layer (of the re-active solution) and piggybacking IDs on control messages, e.g. TC/HELLO.

Figure 7 schematically shows a peer-to-peer component 702 for use in the aforementioned module 100. As shown, the peer-to-peer component 702 interfaces to the core 102. The parts of the peer-to-peer component 702 comprise a reactive routing part 704, a proactive routing part 706, and a user defined part 708. The user defined part 708 may include security functionality, for example encrypting data put into DHT.

In accordance with the principies set out above, the reactive and proactive routing parts 706, 708 define the logic for implementing peer-to-peer searching for the respective protocols, as described below. A P2P API 710 provides an interface for sending and receiving packets. Other components and parts can of course be defined. For example, some embodiments include security for the P2P signalling messages as well as secure caching of the DHT (or P2P, whatever you call it) data.

4.1 Proactive Figures 8 to 10 show process flows for implementing peer-to-peer functionality for proactive routing protocols.

In an embodiment, Multi-Point Relay (MPR) nodes are selected, for example using the MANET routing protocol OLSR(v2). These are intermediate nodes in the path between a source and a destination. Conventionally, to implement this, each node in the network periodically broadcasts the information describing which neighbors have selected it as a multipoint relay. Upon receipt of this "MPR Selectors" information, each node calculates or updates the route to each known destination. So principally, the route is a sequence of hops through the multipoint relays from source to the destination. However, in an embodiment, each node already knows the 1-hop and 2-hop neighbours, along with routes to any other node in the network, by means of the NHDP protocol. With reference to Figure 8, when a node joins the overlay network (step 5802), it first identifies the closest MPR node (step 804) (whose ID is known from the MANET routing table), and prefixes this to its own ID (step S806). This creates proximity both spatially and also in the application layer, so that broadcast beacons are not required. It also reduces replication of data and network overhead. Rather, it is based on the known information in the routing table. Further, if the node moves closer to another MPR node, it can tell using the ETX metric, for example, if a link has less packet lossflower delay. This means that there is no need to send broadcast beacons from the MPR nodes.

Nodes maintain a routing table that includes their neighbours' NodelDs and lP addresses. In other words, the NodelDs and lP addresses are associated with Layer 3 in the 051 model. With reference to Figure 9, when making a data object available (i.e. for sharing), the node hashes the metadata (e.g. file name) of the data object to generate a key (step S902). At step 8904, the key is matched to the ID of the closest node using the routing table (closest in the sense of having the same or similar IDs). In one embodiment, the routing table is extended to include the IP addresses of nodes, so that the key can be sent there directly using the corresponding IF addresses (step 8906). Nodes receiving the key store the key and data in their DHTs (step S910).

A proactive p2p search process will now be described with reference to Figure 10. At step 81002, a search (text) string such as "filet', is received at a first node via a GUI for example. (The object that is being searched for is stored a second node.) The search string is then hashed (step S1004) to produce the hash value 9D3A099C8EE, for example. (It is assumed that the data has already been input into the 01-IT.) The identifier (i.e. key) of the node in the network storing the data is a text value, for example "9E22AE27F39". Thus, at step S1006, a lookup in the DHT is performed by the first node, to find a node that is closest to the key (closest in the sense of matching hash), for example a node with matching ID 9E22AE27F39. The corresponding IP address of that node (e.g. 192.168.0.44) is known to the first node. In step S1008 a GET request is then sent to the second node (step 51008): GET 9D3AO99CSEE -. 192.168.0.44.

In response, a reply is received: 192.168,0.44 -. GETREP 9D3A099C8EE: Content of data object.

The pro-active DHT algorithm thus uses the neighbourhood information in the MANET routing table, and expands this to include node IDs and IP addresses.

4.1 Reactive In one embodiment, a re-active unstructured p2p search protocol is provided. Re-active routing protocois, such as DYMO and AODV, broadcast control packets, such as RREQ (route request) packets, in order to find routes to nodes. Such RREQ packets are "lightweight" and do not create much overhead. Here, the search strings are piggybacked' onto these routing layer packets. The node also generates a p2p lookup packet when no RREQs occur within a certain time period. This algorithm requires very little overhead compared to conventional approaches.

In more detail, and with reference to Figure ii, a search process begins at step Si 102, a search (text) string, for example "filel", is received at a first node. The object that is being searched for, filei, is stored at second node having the IP address "192.168.0.44", for example. At step S1104, the search string, i.e. meta-data (object ID/key), is hashed to produce a hash value, for example text value "9D3A099C8EE".

At step 51110, the hash of the data object, GD3AO99C8EE, is sent in a routing layer packet (i.e. "piggybacked" or inserted into RREQ), if such a message is sent by the node within a given time period (S1106 NO), and otherwise sent using a p2p lookup packet (step SilOS): GET 9D3A099C8EE -. (broadcast address).

The time limit may be set by a user, or could be predefined. In response, a reply is received from the second node: 192.168.0.44 -. GETREP 9D3AO99CSEE Content of data object.

Here, "content of data object" is the data that is being searched for, such as text data.

4.2 Switching between protocols The two above algorithms can then be combined to operate in accordance with which routing protocol is being used, hence creating a general solution suitable for deployment on any ubiquitous network.

The identifiers of data objects (i.e. the keys for the data) in the reactive p2p search protocol are hashes of the metadata of the data object. This is to make the transition from pro-active DHT to unstructured p2p search easier, as will be described later.

In particular, nodes can use the same object ID/keys to initiate searches on both protocols, so that nothing needs to be changed in terms of moving objects after switching from the proactive protocol to the reactive protocol.

When switching from reactive to proactive, each object ID would have to be PUT into the DI-IT by the node requesting to store that object, by issuing a PUT: PUT 9D3A099C8EE: Content of data object.

The hash of the string, i.e. meta-data (object ID/key) is, for example, 9D3A099C8EE.

Its value is text data.

Then a lockup in the extended routing table is performed, to find a node closest to this key, for example a node with the ID 9E22AE27F39 and IP address of IP 192.168.0.44.

Then, a PUT key/value pair is sent to that node: PUT 9D3A099C8EE: Some text -192.168.0.44 The node at 192.168.0.44 would then store that text information, which would later be replicated by its neighbours for redundancy. As noted above, the use of MPR nodes creates proximity both spatially and also in the application layer, so that broadcast beacons are not required.

Although embodiments have been described with reference to specific proactive and reactive protocols, it will be apparent to one of ordinary skill in the art that the disclosure is applicable to other routing protocols.

It wiJi be appreciated that a MANET may include one or more relatively immobile nodes, and may include such nodes as will allow connection to a wider area network, such as the Internet.

While certain embodiments have been described, these embodiments have been presented by way of example only, and are not intended to limit the scope of the inventions. Indeed, the novel methods and systems described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions and changes in the form of the methods and systems described herein may be made without departing from the spirit of the inventions. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope and sprit of the inventions.

Claims

<claim-text>CLAIMS: 1. A method of implementing security for a ubiquitous network, the method comprising: receiving1 by a device intending to join the network, security information from a certificate authority, the security information including: a digital certificate that is signed by the certificate authority and that includes an identifier of the device and a public key of the device, and a public key of the certificate authority: and transmitting the signed digital certificate to member devices of the network via one or more hops, to thereby allow each of said member devices to authenticate the device and to establish secure associations with said device.</claim-text> <claim-text>2. A method according to claim 1, wherein establishing a secure association between said device and one of the member devices comprises sharing a symmetric key encrypted using the public key of said device.</claim-text> <claim-text>3. A method according to ciaim 2, further comprising using the symmetric key to encrypt data communications between said device and said one of the member devices.</claim-text> <claim-text>4. A method according to any one of the preceding claims, wherein authenticating the device comprises verifying the digital signature using the public key of the certificate authority.</claim-text> <claim-text>5. A method according to any one of the preceding claims, wherein the security information further includes a shared network key.</claim-text> <claim-text>6. A method according to any one of the preceding claims, further comprising including a thumbprint algorithm of said device in the digital certificate and hashing the digital certificate using said thumbprint algorithm.</claim-text> <claim-text>7. A method according to any one of the preceding claims, wherein the signed digital certificate is distributed to substantially all of the member devices of the network.</claim-text> <claim-text>8. A device for implementing security for a ubiquitous network, the device comprising: means configured to receive security information from a certificate authority, the security information including: a digital certificate that is signed by the certificate authority and that includes an identifier of the device and a public key of the device, and a public key of the certificate authority; and means configured to transmit the signed digital certificate to member devices of the network via one or more hops, to thereby allow each of said member devices to authenticate the device and to establish secure associations with said device.</claim-text> <claim-text>9. A device according to claim 8, further comprising: means configured to receive digital certificates from other devices, the received digital certificates signed by the certificate authority and including identifiers and public keys of the corresponding devices; and means configured to store the received digital certificates.</claim-text> <claim-text>10. A device according to claim 8 or claim 9, further comprising: means configured to establish a security association with said other devices using the received digital certificates.</claim-text> <claim-text>11. A device according to claim 10, wherein authenticating comprises verifying the digital signature using the public key of the certificate authority.</claim-text> <claim-text>12. A device according to any one of claims 8 to 11, wherein the security information further includes a shared network key.</claim-text> <claim-text>13 A device according to any one of claims 8 to 12! further comprising means configured to include a thumbprint algorithm of the device in the digital certificate, and to hash the digital certificate using the thumbprint algorithm.</claim-text> <claim-text>14. A method of optimising peer-to-peer functionality in a ubiquitous network having a plurality of devices including multi-point relay devices and implementing a proactive routing protocol, the method comprising: identifying a nearest multi-point relay device for a joining device; and associating said joining device to said nearest multi-point relay device by concatenating a first identifier of said nearest multi-point relay node with a second identifier of said joining device.</claim-text> <claim-text>15. A method according to claim 15, further comprising: identifying a new nearest multi-point relay device for the device; associating said device to said new nearest multi-point relay device by replacing said first identifier with a third identifier of said new nearest multi-point relay device.</claim-text> <claim-text>16. A device for implementing peer-to-peer functionality in a ubiquitous network having a plurality of devices including multi-point relay devices, the device comprising: means for implementing a proactive routing protocol; means for identifying a nearest multi-point relay device; and means for associating the device to said nearest multi-point relay device by concatenating a first identifier of said nearest multi-point relay node with a second identifier of said joining device.</claim-text> <claim-text>17. A device according to claim 16, further comprising: means for identifying a new nearest multi-point relay device for the device; means for associating the device to said new nearest multi-point relay device by replacing said first identifier with a third identifier of said new nearest multi-point relay device.</claim-text> <claim-text>18. A method of providing peer-to-peer functionality in a ubiquitous network having a plurality of devices configured to implement a proactive routing protocol, the devices maintaining hash tables that include identifiers of data objects in the form of hashed metadata, the method comprising: hashing metadata of a new data object that is to be added to a peer-to-peer overlay of the ubiquitous network by a first one of the devices, to thereby generate a key; matching the generated key to an identifier of a second one of the plurality of devices, the identifier stored in a routing layer table that also includes an IP address of said second one of the plurality of devices; and transmitting the generated key to said first one of the devices using said IP address, 19. A device for implementing peer-to-peer functionality in a ubiquitous network having a plurality of devices, the device comprising: means configured to implement a proactive routing protocol; means configured to store a hash table that include identifiers of data objects in the form of hashed metadata; means configured to hash metadata of a new data object that is to be added to a peer-to-peer overlay of the ubiquitous network, to thereby generate a key; means configured to match the generated key to an identifier of one of the plurality of devices, the identifier stored in a routing layer table that also includes an IP address of said one of the plurality of devices; and transmitting the generated key to said one of the devices using said IF address.20-A method of searching a peer-to-peer overlay of a ubiquitous network having a plurality of devices configured to implement a proactive routing protocol, the devices maintaining hash tables that include identifiers of data objects in the form of hashed metadata, the method comprising: receiving a search string at a first one of the devices; hashing the search string with a hash function, to thereby generate a key; matching the generated key to an identifier of a second one of the plurality of devices, the identifier stored in a routing layer table that also includes an IF address of said second one of the plurality of devices; and transmitting a request for a data object corresponding to said search string to said second one of the devices using said IP address.21. A device for searching a peer-to-peer overlay of a ubiquitous network having a plurality of devices, the device comprising: means configured to implement a proactive routing protocol; means configured to store a hash table that include identifiers of data objects in the form of hashed metadata; means configured to receive a search string; means configured to hash the search string with a hash function, to thereby generate a key; means configured to match the generated key to an identifier of one of the plurality of devices, the identifier stored in a routing layer table that also includes an IF address of said one of the plurality of devices; and means configured to transmit a request for a data abject corresponding to said search string to said one of the plurality of devices using said IP address.22. A method of searching a peer-to-peer overlay of a ubiquitous network having a plurality of devices configured to implement a reactive routing protocol, the devices maintaining identifiers of data objects in the form of hashed metaclata, the method comprising: receiving a search string at one of the devices; hashing the search string with a hash function, to generate a key; and transmitting the key in a lookup packet of the peer-to-peer overlay if a time limit is exceeded, and otherwise transmitting the key in a routing layer packet.23. A device for searching a peer-to-peer overlay of a ubiquitous network having a plurality of devices, the device comprising: means configured to implement a reactive routing protocol; means configured to store identifiers of data objects in the form of hashed metadata; means configured to receive a search string; means configured to hash the search string with a hash function, to generate a key; means configured to transmit the key in a lookup packet of the peer-to-peer overlay if a time limit is exceeded, and otherwise transmit the key in a routing layer packet.24. A method of providing peer-to-peer functionality in a ubiquitous network having a plurality of devices configured to implement a proactive routing protocol and a reactive routing protocol, the method comprising: looking up node identifiers in the distributed hash table for each of the keys; matching the node identifiers to the corresponding P addresses; and transmitting the keys to the nodes having the corresponding IP addresses.25. A method for implementing routing in a ubiquitous network in accordance with a plurality of routing protocols, the method comprising: obtaining a link metric based on a received control packet; determining a set of candidate routes the obtained link metric; determining a user quality requirement for a received data packet that is to be routed; and selecting one of the candidate routes based on the determination of the user quality requirement.26 A method according to claim 25, further comprising: determining a network state value indicative of the state of the network; comparing the obtained network state value to a corresponding threshold value; and altering the routing behaviour in accordance with the comparing.27. A device for implementing routing in a ubiquitous network, the device comprising: routing means configured to implement a plurality of routing protocols; and control means configured to control the routing means to provide routing functionality using at least one of the plurality of routing protocols by: obtaining a link metric based on a received control packet; determining a set of candidate routes the obtained link metric; determining a user quality requirement for a received data packet that is to be routed; selecting one of the candidate routes based on the determination of the user quality requirement.28 A device according to claim 27, further comprising: means configured to determine a network state value indicative of the state of the network; means configured to compare the obtained network state value to a corresponding threshold value; and means configured to alter the routing behaviour in accordance with the comparing.29. A computer program product comprising computer executable instructions to cause a computer to become configured to perform a method in accordance with any one of claims ito 7, 14, 15, 18, 20, 22, 24, 25 or 26.30. A computer program product comprising computer executable instructions to cause a computer to become configured as the device of any one of claims 8 to 13, 16, 17, 19, 21, 23,27 or 26.31. A computer program product in accordance with claim 29 or claim 30 comprising a computer readable storage medium.32. A computer program product in accordance with claim 29 or claim 30 comprising a computer receivable signal.</claim-text>