WO2013008026A2 - Framework for ubiquitous networking - Google Patents

Abstract

Embodiments disclosed herein relate to ubiquitous networking. Some embodiments relate to optimizing routing. Some embodiments relate to implementing security for the ubiquitous network. Some embodiments relate to providing a peer-to-peer functionality for the ubiquitous network. 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 (APIs), 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 20 0, which is hereby incorporated by reference in its entirety, describes a generic Cognitive Adaptive Module (CAM) that can be utilized in conjunction with different ubiquitous 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 modular, cognitive and adaptive according to the changing network state. The text of this proposal can presently be found at the following link: http://tools.ietf.org/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, cryptographic material of the device and of the certificate authority or of the manufacturer of the device and security keys; 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.

The certificate authority may be the manufacturer of the device. The digital certificate may not only be signed by the certificate authority but may also be issued and provided by the certificate authority/manufacturer.

The cryptographic material of the device and of the certificate authority or of the manufacturer of the device may be a public key of the device, and a public key of the certificate authority. The security keys may be peer-to-peer security keys. 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 and/or cryptographic information to access the MAC layer.

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. More generally, in an embodiment, each digital certificate of each node in the network may be 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/the device's manufacturer and including identifiers and cryptographic keys, such as 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, establishing a secure association between said device and one of the member devices comprises sharing unique pairwise cryptographic material encrypted using cryptographic keys included in the digital certificate of the device.

In one embodiment, the method further comprises using the unique pairwise cryptographic material to encrypt routing packets and data communications between said device and said one of the member devices as well as providing authentication and integrity of the aforesaid routing packets and data.

In one embodiment, peer-to-peer security functionality comprises secure peer-to-peer data caching and secure peer-to-peer signalling, by using the peer-to-peer cryptographic keys included in the digital certificate of each node.

In one embodiment, intrusion detection of malicious activity and malicious or selfish nodes' existence comprise energy efficient techniques with respect to the mobile devices' nature. In one embodiment, intrusion detection of malicious activity and malicious or selfish nodes' existence comprise multi-layer intrusion detection using different kind of techniques such as anomaly or signature based detection to increase the availability of network resources.

In one embodiment, intrusion detection of malicious activity and malicious or selfish nodes' existence comprise nodes to use the findings of such detection to cache previous and present information about their neighbour's behaviour. The nodes may further be configured to decide on future communication paths using this cached information, for example to avoid routing future communication paths through a recognised selfish node.

In one embodiment, intrusion prevention comprises nodes to use prevention

techniques to stop malicious activities and react efficiently in the presence of malicious or selfish nodes' to increase the availability of network resources.

An API for security user defined components and parts may further be provided. In one embodiment, authenticating 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 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 multipoint 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 a network interface identifier of said second one of the plurality of devices; and transmitting the generated key to said first one of the devices using said network interface identifier. The network interface identifier is an identifier of a network interface within the ubiquitous network that is useable for routing packets from source to destination and may be an 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 may also include an network interface identifier of said one of the plurality of devices; and means for transmitting the generated key to said one of the devices using said network interface identifier.

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 such as 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 may also includes an network interface identifier 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 Network interface identifier. 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 such as 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 network interface identifier 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 Network interface identifier.

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 such as 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 Network interface identifieres; and transmitting the keys to the nodes having the corresponding Network interface identifieres.

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; Figure 11 illustrates a process of creating redundant data in the network;

Figure 12 illustrates a process of compensating for the departure of a node from the network; Figure 13 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;

Figure 14 illustrates a further process of creating redundant data in the network.

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 impiementations. Finally, the fourth section relates to peer-to-peer implementations.

1. Overview

By way of overview, and with reference to Figure , a computer implemented module 100 (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 MANETs. The core 02 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 parts 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 PHY/MAC layer. Furthermore, a User Interface (Ui) API, such as a Graphical User Interface (GUI) API, provides user interfaces for user information and configuration. In operation, and with reference to Figure 2, the module 100 monitors the network to obtain one or more network state parameter values, for example from packets and other cross-layer information (step S202). At step S204, the module compares the network state parameter values with defined thresholds, and, if the thresholds are exceeded (step S206 "YES") the necessary adaptive action is initiated to change the routing behaviour accordingly (step S208). 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 1 2, an adaptive component 4, a Link Metric component 116, a routing component 1 18, a Packet and TLV component 20, 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, WiMAX, Zigbee, wireless IEEE standardised interfaces, Long Term Evolution (LTE), LTE-Advanced and Software Defined Radio (SDR) or Cognitive Radio interfaces.

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

The monitor component 1 10 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 1 14 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 1 14 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 1 12. 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 S308 YES), it is sent to the upper (OSI) layers (step S310). If the data packet is to be routed (step S308 NO), then the quality of experience requirements for the packet are determined (step S3 2). An optimal route is selected in step S3 2 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 S318). 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 S320).

The routing component 1 18 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 proximate nodes, such as 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 interface 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 such as Neighborhood Discovery Protocol (NHDP), a proactive routing part, defining routing logic such as OLSRv2, and a Reactive routing part, defining routing logic such as AODV and DY O. 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 TLVs (Type-Length-Value; an optional encoded segment of information that may be carried by packets such as in payload or routing packets; segments of information carried may be 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 wilt 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 ANETs 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 working memory.

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 or protocol packet such as 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 network interface identifier, such as a specific IP address, or generate broadcast packets for all network interface identifiers/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 (RJrans).

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 structures 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 (IT^*(R_trans)²}. The determined value represents the node density. Other node density functions are, of course, possible.

A rate of change of neighbour part keeps a list of "{destination, next hop}" neighbour tuple. It also keeps a Changejnterval timer that stores the time between calls when active. Each time it is called, it checks the value of the local Changejnterval 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 changejnterval. 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 "totai number of nodes reactive part". The "total number of nodes proactive part" 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 reactive routing packets such as 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)*Hop_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 100ms and jitter of 5ms. Consequently, it establishes the coefficients such as a (for delay), β (for jitter), χ (for bandwith), δ (for packet loss) and (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, jitter is b ms, bandwith c kbps, packet loss ETX value of d and critical energy value of e Joules:

a = {(A/a)/((A a)+(B/b)+(c C)+(D/d)+(e/E))},

P = {(B/b)/((A/a)+(B/b)+(c/C)+(D/d)+(e/E))},

% = {(c/C)/((A/a)+(B/b)+(c/C)+(D/d)+(e/E))},

δ = {(D/d)/((A/a)+(B/b)+(c/C)+(D/d)+(e/E))},

e ={(e/E)/((A/a)+(B/b)+(c/C)+(D/d)+(e/E))}, where |A|<|a|, |B|<[b|, |cj<|C|, |d|<|D|, |e|<|E|, and A ms is the maximum achievable delay, B ms maximum achievable jitter, C kbps the maximum achievable Bandwidth, D 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 Component. 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 monitor component. The Network size Thresold is exceeded if: previously Nodes_total > 10 and new value <=10 Or previously Nodes_total < 10 and new value >=10. The corresponding triggered "Adaptive Component. Part" is "Change Routing Behaviour Part".

A Node density Threshold is set to {6/(n*(R_trans)²)} as obtained from "Monitor Component. Total number of nodes" part. This trigger the change "NHDP (Neighbourhood Discovery Protocol with discovers 1-hop and 2-hop neighbours) 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 Hello_interval<(Route__Change/2) seconds and is approximated to (Route_Change/4) seconds. The value for "Route_Change" is obtained from "Monitor component. Rate of change of routes" part. The Hellojnterval value is defined in the "Routing Component. 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

QoS = (a * ED) + (p * EJ)+ (χ * EBX) + (6 * ETX) + (ε * NEN), where ED, EJ, EBX, ETX and NEN are the "Link Metric Component, parts" expression or algorithms. In one embodiment, α=0.5, β=0, χ=0, δ=0.5 and ε = 0. Thus, the QoS threshold is

QoSJhreshold = |QoS1-QoS2|/QoS1 =0.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 1 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 1 14 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 Component. parts". The part values to be changed are specificied. 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, the neighbourhood routing part, such as the NHDP 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 routing packets such as the HELLOJNTERVAL, HELLO JvllNJNTERVAL, REFRESHJNTERVAL and VAL1DITY_TI E message TLV. When required by the "Node density Threshold part" the value of REFRESHJNTERVAL is increased proportionally to the node density, ND. When called by "Route Stability Threshold part", the HELLOJNTERVAL 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 TCJntervals. In this case the implemented proactive protocol such as OLSRv2 and it is the default mode of operation, if the network size < network threshold size, e.g. 10 nodes 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 < 10 nodes, the DYMO part in "Routing component" is turned off.

2.4 Link Metric component and parts

The Link Metric Component 16 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 ELBW 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 ELJ values where each ELJ value is the variance in consecutive ELD values for that link.

An NEN value may be calculated by an NEN metric part. The NEN 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 NEN 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 HC 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 1 18 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.

A Routing Part implements the neighbourhood routing protocol such as NHDP protocol. NHDP 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 Packet TLV 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 a proactive routing protocol such as 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 PRs 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 (TC) 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 MPRs exist, the QoS values of the routes to 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 signals 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 TC messages are only forwarded by the MPR nodes of the TC 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 a reactive routing protocol such as the DYMO protocol. The Dynamic MANET On-demand (DYMO) routing part enables reactive, multihop unicast routing among participating DYMO nodes or routers. The DYMO part 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 routejimeout 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 ail 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 and data confidentiality, and end-to-end packet and data 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, a Peer-to-Peer security component and an intrusion detection/prevention component. 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 or any other security credentials 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 devices and network resources. In particular, it serves to allow only authorised users to gain access to the network resources or capability. The routing and data 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 routing and data security component will provide different cryptographic functionalities for the routing (signalling) or data packets. The component can also be used to provide non-repudiation. Furthermore, the P2P security component includes security functionalities such as encrypting data put into DHT (secure caching), encrypt P2P signalling messages (puts, gets, replication). Finally, an intrusion detection/prevention component is used to monitor packets of data traverse the network and identify malicious activities as well as deny malicious traffic or activities from invading the network. 3.2 Key management component and parts

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 (such as secure video, voice and/or data communications) between nodes. More specifically, and with reference to Figures 5 and 6, before a node 602 is admitted into a network, it has been installed with the following information about the key management component:

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 some cryptographic material (e.g. the public key, P2P cryptographic keys) of the node. This certificate is unique to each node. 3) Authentication information (e.g. public key, PKm) of the devices' manufacturer or the public key of the certificate authority, PK_CA, which is used to verify the authenticity of the digital certificates of future joining nodes or any other packets signed by the certificate authority. The node 602 may have communicated with a certification authority (CA) (step S502) in order for the key management component 408 to obtain this information.

In an embodiment, the DC includes: i) the identity code of the certificate, ii) the identification of the device's manufacturer or of the CA (certification-service provider), and iir) 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 "thumbprint", i.e. the hash itself, to ensure that the certificate has not been tampered with.

The identification of the device's manufacturer or 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/refresh date.

Module user information may include an identifier of the module user and module user cryptographic key information (e.g. the user's public key and public key algorithm, P2P cryptographic keys).

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 or has been equipped with a digital certificate DC₆₀₂ from the certificate authority CA or the device's manufacturer. Upon joining the network 600, the digital certificate is distributed across the network. The digital certificate includes the cryptographic information (e.g. 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 (such as video, voice and/or data) communication. 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 retrieve the required information. To this end, users that need to communicate with each other must securely and confidentially share cryptographic information (e.g. a symmetric 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 both his/her device as well as the wireless network (step S504) by using for instance biometrics, password phrases and secure MAC layer access mechanism. The authentication part is configured to allow only legitimate users to authenticate themselves and get access to the device. The authorisation part indicates what level of access an authenticated user must have to the secured network and data resources. The secure MAC layer access part allows users to access the required network resources.

The authentication part can use different kind of mechanisms or combination of them. For instance biometric authentication (e.g. IRIS), password phrases (e.g. PINs, combination of different buttons or gestures) can be used to implement such authentication. In addition to such a mechanism, the other legitimate nodes of the network can authenticate and validate the joining peer's digital certificate. Authorisation can be implemented to be performed by the software immediately after the login of the user and the recognition of his/her privileges within 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 their 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 use devices that have installed digital certificates signed by the manufacturer or CA and have a non-expired module license.

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 cryptographic information (e.g. pre-shared key) to authorize his device in the MAC layer. Also this material 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 cryptographic material (e.g. 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 (manufacturer) 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 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) Optionally obtains the public key of the joining user, 3) Checks the authenticity and integrity of the message sent by validating cryptographic material (e.g. digital signature) of the joining user

By way of example, it is assumed that (i) SK_CA is the private key of the certificate authority and (ii) PK_CA 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 PK_CA 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 Routing and data security security

The routing and data security parts 416, 418 implement different types of cryptographic algorithms that a user might prefer to use to encrypt its routing packets and data. 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 routing and data security parts are routing and data authentication and integrity to validate the authenticity of the routing packets and data 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 routing and data 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.

Any who needs to make sure that only the destination of the communication channel 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 B, user A will use B's cryptographic information (e.g. public key to send a unique symmetric pair-wise key) to establish secure communications in the network layer. Such cryptographic information is well known to all the nodes due to the access control component 404, which distributes the digital certificates of the joining users.

The confidentiality part 416 implements different cryptographic functionalities which implement encryption of the routing packets or the data. It requires the end-to-end security association part which provides a pairwise cryptographic material (e.g. symmetric key) between any two nodes in the network.

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 could take 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 + key and confirming that it is the same with the one user has received.

3.5 P2P security component and parts

The secure caching part of the P2P security component uses cryptographic material that may be preinstalled by the manufacturer to encrypt data put into DHT. This material is included in the digital certificate of each node. The secure P2P signalling part encrypts the different P2P signalling messages to prevent malicious nodes from reading such messages and damage the conventional operation of the P2P component.

3.6 Intrusion detection/prevention component and parts

The energy efficient part of the intrusion detection/prevention component takes into account different parameters to preserve the battery lifetime of each device while at the same time ensuring that intrusion detection takes place in an efficient manner across the network. To this end, different kind of mechanisms can be used such as optimisation techniques (e.g. game theoretic, probabilistic) or sleeping/waking up pattern procedures based on the different network topologies and the security requirements.

The detection part can use different kind of intrusion detection techniques (e.g. signature based, anomaly based) to identify malicious or selfish activities or existence of malicious or selfish entities in the network. Each node can cache behaviour information about his previous, current and future neighbours and decides whether their communication must be interrupted or not depending on the different security criteria for different scenarios. The detection part considers all the different layers of the OSi model, thereby finally creating a multi-layer intrusion detection engine that provides a defence against attacks in the different layers.

The prevention part of the intrusion detection/prevention component can shut down malicious activities (e.g. zero-day attacks) before they harm the network communications or any data. This part can also adjust other security controls or apply patches to stop an attack or use any other means of preventing attacks against the network such as deleting malicious contents from some of the nodes.

3.7 Other security considerations

Other components and parts can of course be defined. For example, some embodiments include one or more of a keying material update and revocation part in the key management component, a biometric authentication part in the access control and authorisation component and an anonymity part in the confidentiality 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 cryptographic material (e.g. public key) list part defines the cryptographic 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 key (e.g. symmetric) between two 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 cryptographic (e.g. symmetric) material. 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. The mutable fields are considered as 0 when the signature of a message is calcuiated.The HMAC part defines one hash message authentication code TLV for including the HMAC value of a packet. 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 are a distributed database system that uses uniform hashing to stor and retrieve data. Distributed Hash Tables will be referred to as DHTs hereinafter, 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. A NodelD is any information that can be used to identify an entity in the network capable of storing and/or retrieving data from the database system. Each peer (that is each entity with an associated NodelD) "owns" a part of the identifier space and stores the (key, value) pairs for keys lying in its space. Additionally peers replicate their key, value pairs among their neighbours in order to provide redundancy. Therefore if the original peer leaves the network, the neighbours of said peer will then become responsible for the leaving peers key, value pairs. 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. TC and HELLO messages can be used to propagate routing information, such as IP and topology information, throughout the network.

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 principles 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.

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). MPRs are nodes that optimise the relaying of routing messages between nodes in a wireless network. MPRs may also have the role of maintaining a fully connected network using the minimal number of MPR nodes connected to each other. MPRs are intermediate nodes in the path between a source 201

35

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 S802), 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 (Expected Transmission Count, a measure of the quality of a path between two nodes in a wireless packet data network), for example, if a link has less packet loss/lower 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 IP addresses, in other words, the NodelDs and IP addresses are associated with Layer 3 in the OSI 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 S904, 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 IP addresses (step S906). 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 S1002, a search (text) string such as "ftlel", 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 DHT.) 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 S1008):

GET 9D3A099C8EE→ 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. In order to provide redundancy in the network data stored in the peers must be replicated to ensure that if a peer leaves the network, data is not forever lost with that node. Figure 1 illustrates a process of create such redundancy. In step 1202 a node selects a subset of nodes from the network (for example geographically close nodes, nodes with a similar ID) and, in step 1204, exchange key, value pairs so that both nodes have a mirror of each other's data. Figure 12 illustrates a process in which the thus created redundancy is used. If it is detected, in step S1210, that a node leaves the network (for example realised through periodical pinging), one of the subset of nodes which has a mirror of the leaving nodes data is selected, in step S1212, to then take responsibility for said key, value pairs.

4.2 Reactive

In one embodiment, a re-active unstructured p2p search protocol is provided. Reactive routing protocols, 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 13, a search process begins at step S1102, a search (text) string, for example "filel", is received at a first node. The object that is being searched for, filel , 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 S 1 10, the hash of the data object, 9D3A099C8EE, 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 (S1 06 NO) that has started with the most recent receipt of a packet from the second node. If the time period has expired (S1 106 YES), the message is sent using a p2p lookup packet (step S1108) that includes the IP address of the second node:

GET 9D3A099C8EE→ (broadcast address). wherein the GET process retrieves data from the peer-to-peer network. 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 9D3A099C8EE : Content of data object.

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

In order to provide redundancy of the data, a replication scheme is used. To this end a neighbour discovery message can be piggybacked on to the routing messages. As with the other messages previously mentioned in the re-active approach, a timer will be enabled; if the timer expires a neighbourhood discovery packet will be broadcast (S1220 of Figure 14) in a finite hop radius. When a node receives a neighbourhood discovery packet they will reply directly to the source. The source then creates a neighbourhood table or adds the reply to an existing neighbourhood table (S1222 of Figure 14) and selects (S1224 of Figure 14) a set of nodes within the neighbourhood with which to replicate data. A message will then be sent periodically so said nodes (S1226 of Figure 14) to check if they are still active in the network, !f a node leaves then another node with the replicated data will then take responsibility for the key, value pairs. 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 DHT by the node requesting to store that object, by issuing a PUT process (storing data in the peer-to-peer network):

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 lookup 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 with the replication algorithm corresponding to those previously mentioned for either proactive or reactive p2p networks. 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 will 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

2013/008026 40 CLAIMS:

1. 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.

2. A method according to claim 1 , 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.

3. A device for implementing peer-to-peer functionality in a ubiquitous network having a plurality of devices including multi-point relay devices, the device operative to implementing a proactive routing protocol, to identify a nearest multi-point relay device and to associate the device to said nearest muiti-point relay device by concatenating a first identifier of said nearest multi-point relay node with a second identifier of said joining device.

4. A device according to claim 3, further configured to:

identifying a new nearest multi-point relay device for the device;

associate 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.

5. 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 identifier of a network interface within a ubiquitous network useable for routing packets from source to destination 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.

6. A device for implementing peer-to-peer functionality in a ubiquitous network having a plurality of devices, the device comprising:

a routing component configured to implement a proactive routing protocol; memory configured to store a hash table that include identifiers of data objects in the form of hashed metadata;

a hashing arrangement 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;

a matching configuration 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 network interface identifier of said one of the plurality of devices; and a transmitter for transmitting the generated key to said one of the devices using said network interface identifier.

7. 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 network interface identifier 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 network interface identifier.

8. A device for searching a peer-to-peer overlay of a ubiquitous network having a plurality of devices, the device comprising: a routing component configured to implement a proactive routing protocol; a memory configured to store a hash table that include identifiers of data objects in the form of hashed metadata;

an input configured to receive a search string;

a hashing arrangement configured to hash the search string with a hash function, to thereby generate a key;

a matching configuration 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 network interface identifier of said one of the plurality of devices; and a transmitter for transmit a request for a data object corresponding to said search string to said one of the plurality of devices using said network interface identifier.

9. 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 or in a routing layer packet.

10. A method according to claim 9, wherein said key is transmitted in the lookup packet of the peer-to-peer overlay if a time limit is exceeded, and otherwise in the routing layer packet.

11. A device for searching a peer-to-peer overlay of a ubiquitous network having a plurality of devices, the device comprising:

a routing component configured to implement a reactive routing protocol; a memory configured to store identifiers of data objects in the form of hashed metadata;

an input configured to receive a search string;

a hashing arrangement configured to hash the search string with a hash function, to generate a key; a transmitter configured to transmit the key in a lookup packet of the peer-to- peer overlay or in a routing layer packet.

12. A device according to claim 11 , wherein said transmitter is configured to transmit the key in the lookup packet of the peer-to-peer overlay if a time limit is exceeded, and otherwise in the routing layer packet.

13. 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 IP addresses; and transmitting the keys to the nodes having the corresponding IP addresses.

14. 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.

15 A method according to claim 14, 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.

16. A device for implementing routing in a ubiquitous network, the device comprising:

a routing configuration configured to implement a plurality of routing protocols; and

a controller configured to control the routing configuration 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.

17. A device according to claim 16, further comprising:

a network state evaluator configured to determine a network state value indicative of the state of the network; and

a comparator configured to compare the obtained network state value to a corresponding threshold value;

wherein the routing configuration is configured to alter the routing behaviour in accordance with the comparing.

18. 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, cryptographic material of the device and of the certificate authority or of the manufacturer of the device and security keys; 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.

19. A method according to claim 18, 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.

20. A method according to claim 19, further comprising using the symmetric key to encrypt data communications between said device and said one of the member devices.

21. A method according to any one of claims 18 to 20, wherein authenticating the device comprises verifying the digital signature using the public key of the certificate authority.

22. A method according to any one of claims 18 to 2 , wherein the security information further includes a shared network key.

23. A method according to any one of claims 18 to 22, further comprising including a thumbprint algorithm of said device in the digital certificate and hashing the digital certificate using said thumbprint algorithm.

24. A method according to any one of claims 18 to 23, wherein the signed digital certificate is distributed to substantially ail of the member devices of the network.

25. A device for implementing security for a ubiquitous network, the device comprising:

a receiver for receiving 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

a transmitter for 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.

26. A device according to claim 25, further comprising:

a receiver for receiving 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

a memory for storing the received digital certificates.

27. A device according to claim 25 or claim 26, the device further configured to establish a security association with said other devices using the received digital certificates.

28. A device according to claim 27, wherein authenticating comprises verifying the digital signature using the public key of the certificate authority.

29. A device according to any one of claims 25 to 28, wherein the security information further includes a shared network key.

30. A device according to any one of claims 25 to 29, further configured to include a thumbprint algorithm of the device in the digital certificate, and to hash the digital certificate using the thumbprint algorithm.

31. 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 1 , 2, 5, 7, 9, 13, 14, 15 or 18 to 24.

32. A computer program product comprising computer executable instructions to cause a computer to become configured as the device of any one of claims , 3, 4, 6, 8, 11 , 16,17 or 25 to 30.

33. A computer program product in accordance with claim 31 or claim 32 comprising a computer readable storage medium.

34. A computer program product in accordance with claim 31 or claim 32 comprising a computer receivable signal.