IV. Resource and service discovery through compatibility
4.2 Dissemination layer…
4.2.6 Dissemination algorithm
The node offering a service or updating its status, starts the action by creating a new message variable initially empty that will later contain the service description, or type of data that needs to be added or eliminated from the data table of other nodes in the network.
If there are more than one type in the message, the process will go through the first one and follow up with the next ones until finalizing the queue in the message. As explained in section 4.2.3, the number of jumps and node identifier pairs for a type of data are contained in the Information section of the data table, hence the algorithm access and obtains the necessary information from the relevant column and place it in an array for later comparison and use. If the node is notifying the network of an unavailability of a service, or the waiting time threshold is reached to establish communication with a node, the protocol proceeds to eliminate the relevant information linked to the unavailable service and uses the Carrier function to propagate the changes in the node’s table to the neighbor nodes until the number of jumps reaches one.
The same way, if a new service appears in the network, instead of the elimination process the protocol performs and add in the table content, with the updated information the carrier function can again propagate the changes to the nodes in the network to update the data tables and have access to the service.
32
The dissemination layer forms the base in which the search requests are handled as it is explained in section 4.3, the ontology in which the different data types are classified allows the search process to adjust the generic level of requests. Figure 4.2.6 shows the dissemination algorithm and the different variables acting in its functionalities.
Figure 8: Data type dissemination algorithm 4.2.7 Applications
Service discovery is fundamental for the development of the advanced level of the Internet of Things; automation, interoperability, coupling and others are some of the challenges for current systems. These algorithms will aid in the external components coupling, as well as to efficiently allow services and devices to announce its services to the network and make it available to other
DisseminationFunction():
D.information Obtain the set of hop/identifier pairs in data table (Hp, nID) if ( ContentEliminated (m, D)) then
(Hp, n)ObtainDistance (D.information) then
(Hp, n) Eliminate entrance (D.information, nID) if Hp > 1 then
agents in a standardized way, improving the efficiency and security of the system. The system can benefit from the resources in the network, creating a certain level of judgment to define different states, developing predictions of outcomes of different settings and advising on a better solution.
4.3 Compatibility match and search mechanism
The objective of this part of the protocol is to perform the necessary comparisons between data types, decide the level of compatibility of the descriptions of a search and the services available in a network and make use of the ontology classification to find the most suitable response for a specific search performed, allowing for a high level of expression in the search descriptions.
Besides the particular characteristics of the compatibility match and search mechanism, two factors that will be explained in the following subsections are fundamental for the efficient function of the mentioned mechanism.
4.3.1 Service and search descriptions
The functionalities of a particular service can be described in different ways, making reference to the characteristics of the same. The different services in the network should be accessible by other nodes in a remotely manner, including the information, functions and communication method of the same.
The present work makes use of the data type handled by the nodes to create and use the compatibility characteristics between a request and a result. There is a close relation between the type of data used as an input of a process and the type of data that results after the process is performed and finished, the same way, service and search descriptions aim to provide information about the type of data that a certain node can handle or is looking for, respectively.
Although a number of technologies providing services had been developed throughout the years (e.g., REST, Web Services, etc.), which solution is chosen for the proposed protocol remains irrelevant, since the mechanism assumes the existence of a technology to perform the comparison of data type of a service. The classification architecture can be compared to the concept of semantic web where services are described semantically using the concepts of the same with the advantage of being capable to be processed automatically and determine the relation between the concepts used in the descriptions of〔41〕. The same way, using the ontology classification, explained in more details in section 4.3.2, the relation in the description of a service includes the type of data handled allowing relation building capability.
34
In the previous sections a different set of variables was mentioned such as the node identifier that contains the single identifier of a node and is used in the dissemination process to provide the information of which node started the action, besides that, there are other variables that need to be included in the description for the mechanism to perform correctly and efficiently:
- Service identifier
Refers to the identifier of the node offering the service in the network and through which the other nodes in the network obtain the information about the query starting point. The service identifier is fundamental in the creation of a subset of identifiers that are used in different purposes such as the unique search identifier that is explained in more details in section 4.3.3 as well as the 𝐻𝐻𝑛𝑛𝑡𝑡𝐷𝐷𝑖𝑖for the propagation method as described in section 4.2.4.
- Action
As in any process, the type of data a node is able to handle does not provide an accurate description of the actions or functions the node can perform with the data received or produced. Hence, including the action narrative capable to be executed complements the service and search description characteristics.
- Data type
Classified through an ontology entirely diffused in all nodes that participate in the network, a service can define a value 𝑛𝑛 of data type that is later used in the compatibility match through best effort comparison. As described previously, a process is formed by the input data, the function performed and the result obtained after finalizing the process. The same way, services define two types of data 𝑛𝑛𝑛𝑛𝑛𝑛𝑒𝑒 and 𝑂𝑂𝑐𝑐𝑡𝑡𝑛𝑛𝑒𝑒 referring to input and output type of data 𝑛𝑛 respectively.
4.3.2 Ontology Classification
Refers to a list containing the different concepts that can be related to the types of data used in the description of services for the nodes in the network. The objective of creating such classification is to build the relation between the different specifications providing a high level of expression for search processes of services. As described in chapter 3, different solutions had taken advantage of creating service classification to be used by the different protocols.
Including the ontology features to the classification allows for a new approach that makes use of the advantage of the relations to enhance efficiency. Different levels of relations can be
35
created between the concepts using dedicated ontology languages such as OWL, although for the present work, only the relation between data type is applied, more advanced relations can be considered for a future improvement of the mechanism. The OWL Web Ontology Language Overview 〔 42 〕 presents all the functionalities, details and capabilities of the mentioned ontology language as well as the different levels of relations between the concepts included in the same.
Figure 9 shows a representation of an ontology containing different concepts, the relations between the concepts are shown by the circles in the figure, and these relations at the same time can be configured as one-to-many or many-to-one:
- Identical
When two sets present equal characteristics, hence is assumed they have the same type of data.
- Inclusion
When a certain type of data is more general than a second type. In the example figure, type A includes B which at the same time includes C, hence is safe to assume the information in A is more generic and includes the ones described in B and C.
- Unrelated
The types do not share any common information expressed by the ontology, as it would be the case of A and D in the figure.
Figure 9: Representation of relations between concepts in an ontology Ontology
A B C
D E
36
As mentioned in section 3.2.2, the present work assumes the nodes participating in the network have a predetermined knowledge about the ontology used for the classification. A proposed solution to overcome this limitation would be a dissemination phase of the ontology to joining nodes allowing them to operate through the protocol, but a deeper consideration of the challenges, such as the presence of multiple ontologies in the network and correct selection of suitable one for protocol compatibility, as well as the feasibility of this proposal, is necessary.
Placing this and other considerations as an individual research and development topics for future investigations.
4.3.3 Search process
The objective of this part of the protocol is to find a particular service that fulfills the requirements of a search request. The dissemination layer makes use of the data types classified in an ontology used by all the nodes in the network, the compatibility match and search mechanism takes advantage of the features of data type dissemination to perform the search of services in the ad hoc network, more details about data type dissemination can be found in section 4.2 of the current chapter.
To initiate the search function, a service description containing the characteristics of data type handled by the particular node is necessary as explained in section 4.3.1. When a node is interested in finding a service, a search request is created by the particular node containing the variables describing the service to be found in the network. The expression of the request search message is described by:
𝑅𝑅𝑆𝑆 = {𝑛𝑛𝑛𝑛𝑅𝑅, (𝑛𝑛𝑆𝑆1, 𝑛𝑛𝑆𝑆2, . . 𝑛𝑛𝑆𝑆𝑆𝑆)} (8) Where 𝑛𝑛𝑛𝑛𝑅𝑅 is the unique search identifier created using the node identifier 𝑛𝑛𝑛𝑛𝑛𝑛 of the node that created the search request, and a local counter handled by the node to differentiate different search requests created simultaneously by a particular node. The variable 𝑛𝑛𝑠𝑠𝑆𝑆 refers to the description of the particular requests to be fulfilled by a service in the network, a single or multiple descriptions can be contained in a single search request. Each description uses the input and output data type sets that describes the services and perform the compatibility match as described in section 4.3.1, along with a Time-to-live (𝑇𝑇𝑇𝑇𝐿𝐿) value to control the search request propagation area. The expressions describe the search identifier and service description respectively:
𝑛𝑛𝑛𝑛𝑅𝑅 = (𝑛𝑛𝑛𝑛𝑛𝑛, 𝑐𝑐𝐻𝐻𝑐𝑐𝑛𝑛𝑡𝑡) (9)
37
𝑛𝑛𝑠𝑠𝑆𝑆 = {(𝑛𝑛𝑛𝑛𝑛𝑛𝑆𝑆1, 𝑛𝑛𝑛𝑛𝑛𝑛𝑆𝑆2, . . 𝑛𝑛𝑛𝑛𝑛𝑛𝑆𝑆𝑘𝑘), �𝑂𝑂𝑐𝑐𝑡𝑡𝑛𝑛𝑆𝑆1, 𝑂𝑂𝑐𝑐𝑡𝑡𝑛𝑛𝑆𝑆2, . . 𝑂𝑂𝑐𝑐𝑡𝑡𝑛𝑛𝑆𝑆𝑘𝑘� , 𝑇𝑇𝑇𝑇𝐿𝐿𝑆𝑆} (10)
Where, 𝑂𝑂 → 𝑂𝑂𝑛𝑛𝑡𝑡𝐻𝐻𝑂𝑂𝐻𝐻𝑡𝑡𝐼𝐼 𝐻𝐻𝑛𝑛𝑎𝑎 𝑛𝑛𝑛𝑛𝑛𝑛𝑆𝑆𝑘𝑘 ∈ 𝑂𝑂, 𝑂𝑂𝑐𝑐𝑡𝑡𝑛𝑛𝑆𝑆𝑘𝑘 ∈ 𝑂𝑂, 0 ≤ 𝑘𝑘
The use of the ontology allows for a classification of the data table parameters and facilitates the comparison of the 𝑛𝑛𝑛𝑛𝑛𝑛𝑒𝑒𝐻𝐻𝑛𝑛𝑎𝑎 𝑂𝑂𝑐𝑐𝑡𝑡𝑛𝑛𝑒𝑒 values of the data table entries of the search request and the ones contained in the services of nodes participating in the compatibility match process.
Section 4.3.2 details the different relations between possible during the comparison, besides, figure 9 shows the hierarchy structure followed by the ontology and how different parameters can be contained into one another.
This characteristic allows the compatibility match process and search mechanism to perform in a general or specific manner:
- Specific search
The compatibility match is performed only if the condition specified in the description is matched exactly as described, subsets and similarities are not taken in consideration and will not be included in the search results.
- General search
The search is performed throughout the network with results containing subsets and results with similarities to the description used in the process. With a more relaxed search condition, the amount of results matching the criteria is higher, hence although a certain degree of freedom is allowed, there must still be a consideration during the process.
To improve the efficiency of the search process, a selective mechanism can be applied to function after the results are found, and uses different criteria to choose the most suitable service to complete the request, such as power consumption, speed, location, etc. The current work does not make use of such mechanism for the many considerations and challenges that imply, hence is proposed as a future improvement of the present work and future research topic for related investigations.
When a match is found in a certain node, the same has to answer with a response message directed to the node that initiated the search process. The message contains the description of the service that was found as a match for the request, as well as the node and service identifier of the node offering the service in the network.
38
The request response message is described by the expression:
𝑅𝑅𝑅𝑅 = {𝑛𝑛𝑛𝑛𝑆𝑆𝑒𝑒𝑆𝑆𝑆𝑆𝑒𝑒𝑑𝑑𝑒𝑒, (𝑛𝑛𝑆𝑆1, 𝑛𝑛𝑆𝑆2, . . 𝑛𝑛𝑆𝑆𝑘𝑘), 𝑛𝑛𝑛𝑛𝑛𝑛 } (11) Being 𝑛𝑛𝑛𝑛𝑆𝑆𝑒𝑒𝑆𝑆𝑆𝑆𝑒𝑒𝑑𝑑𝑒𝑒 the identifier of a particular service in the network, 𝑛𝑛𝑆𝑆𝑘𝑘 the set of service description satisfying the request and 𝑛𝑛𝑛𝑛𝑛𝑛the single node identifier of the node containing the service. The service description is formed by the set of input and output data type that fulfill the search requirements, expressed as:
𝑛𝑛𝑠𝑠𝑘𝑘 = {(𝑛𝑛𝑛𝑛𝑛𝑛𝑘𝑘1, 𝑛𝑛𝑛𝑛𝑛𝑛𝑘𝑘2, . . 𝑛𝑛𝑛𝑛𝑛𝑛𝑘𝑘𝑒𝑒), �𝑂𝑂𝑐𝑐𝑡𝑡𝑛𝑛𝑘𝑘1, 𝑂𝑂𝑐𝑐𝑡𝑡𝑛𝑛𝑘𝑘2, . . 𝑂𝑂𝑐𝑐𝑡𝑡𝑛𝑛𝑘𝑘𝑒𝑒�} (12) Where, 𝑂𝑂 → 𝑂𝑂𝑛𝑛𝑡𝑡𝐻𝐻𝑂𝑂𝐻𝐻𝑡𝑡𝐼𝐼 𝐻𝐻𝑛𝑛𝑎𝑎 𝑛𝑛𝑛𝑛𝑛𝑛𝑘𝑘𝑒𝑒 ∈ 𝑂𝑂, 𝑂𝑂𝑐𝑐𝑡𝑡𝑛𝑛𝑘𝑘𝑒𝑒 ∈ 𝑂𝑂, 0 ≤ 𝐻𝐻
The information contained in the request response message will be used by the route composition system to create to communication link between the node looking for a service and the one providing it, as it is explained in section 4.4.
4.3.4 Network change adaptability
The mobility of nodes in an ad hoc network represent a challenge for the compatibility match and search mechanisms since not only the movement of nodes causes the topology to change, but also the network is susceptible to nodes arriving and leaving the network at any instant.
To deal with the changes in the network, when nodes receive a search request, they create and add an active search list containing all the searches currently running in the network. The information contained in the list is used to notify new nodes joining the network using a dissemination of the relevant information as described in section 4.2.
On the other hand, when a node leaves the network, the information contained in that particular node should be eliminated from the list and data table of other nodes. The communication routes are directly affected, and a recovery mechanism has to take action to ensure the connectivity among nodes, more details are described in section 4.4 of the chapter.
The active searches in the list remain alive until a response is received from a node in the network or a cancellation request is sent by the node that initially started the search process. In case a node decides to apply modifications to its active search request description, the cancellation request can be used by specifying explicitly the descriptions to be eliminated from a search. Hence, the cancellation request contains the search identifier 𝑛𝑛𝑛𝑛𝑅𝑅 and the set of service
39
descriptions to be modified or complete cancel command 𝐻𝐻𝑎𝑎𝐻𝐻𝑗𝑗𝑡𝑡 as the second parameter in the expression respectively:
𝑅𝑅𝐶𝐶 = {𝑛𝑛𝑛𝑛𝑅𝑅, �𝑛𝑛𝑆𝑆1, 𝑛𝑛𝑆𝑆2, . . 𝑛𝑛𝑆𝑆𝑆𝑆�} (13)
𝑅𝑅𝐶𝐶 = {𝑛𝑛𝑛𝑛𝑅𝑅, 𝐻𝐻𝑎𝑎𝐻𝐻𝑗𝑗𝑡𝑡} (14)
The nodes in the network that receive the cancellation request perform a check on the current entries of their active search lists and perform the modifications or completed cancellation of the search, disseminating the request to the neighbor nodes until reaching the maximum number of hops for message spread. If a node that initiated a search requests is no longer available in the network, the neighbor nodes will be notified through the neighbor detection procedure explained in section 4.2.1 and cancel the active search from the list.
Figure 10 shows the adaptability to network change for a node joining the network and cancellation of an active search among nodes participating in the same.
A search request 𝑅𝑅𝑆𝑆=
{𝑛𝑛𝑛𝑛𝑅𝑅, (𝑛𝑛𝑠𝑠1, 𝑛𝑛𝑠𝑠2)} is sent from node A d d
The active search list in nodes B and F shows the entry propagated by node
A new node D joins the network, the active search list of node B contains the entry previously sent by node A, and hence the information is transmitted to D from node B.
40
Figure 10: Search mechanism adaptability to network change and cancellation request process 4.4 Route Composition
The dynamic nature of mobile ad hoc networks requires solutions capable of adapting to the constant changes and variations among nodes in the network. The route composition has the objective of constructing the communication link between the nodes initiating a search process and the different services that fulfill the requirements of such search description. As opposed to fixed topology networks, the routes descriptions and construction cannot be assumed to be part of nodes’ knowledge, hence, mechanisms that create the links and allows nodes to communicate with each other are an essential part of a service discovery algorithm.
Section 4.2 mentions the necessary features used in the dissemination process that allows to trigger the route composition function, the following sections present the details of the same and operation mechanism to create the connectivity links.
The active search list in D is updated and a response is produced from node D directed to A.
A cancellation request is given by node A containing the data to eliminate 𝑛𝑛𝑠𝑠1 from the active search lists.
The contents in the lists of all
participating nodes are updated to no longer contain a 𝑛𝑛𝑠𝑠1 description.
41
4.4.1 Connectivity bridge formation
To create the connections between two particular nodes, a couple of considerations have to be taken, the first one is the group of neighbor nodes that can transfer the message 𝐴𝐴𝑒𝑒𝑒𝑒𝑑𝑑𝑘𝑘𝑠𝑠 and the second one is the group of nodes that can be reached 𝐴𝐴𝑑𝑑𝑑𝑑𝑆𝑆𝑡𝑡𝑒𝑒𝑑𝑑. The group of neighbor nodes 𝐴𝐴𝑒𝑒𝑒𝑒𝑑𝑑𝑘𝑘𝑠𝑠 contains the node identifier information of the nodes participating during the message transferring.
In the dissemination layer explained in section 4.2 refers to the use of the data type tables containing the type of data handled by the node as well as the projection hops and node identifier of the service. The connectivity bridge formation works on the same principle of tables, each node in the network contains a Link Table (𝐿𝐿𝑇𝑇) used to record the known paths to different nodes that are relevant to others. The table relates the two groups mentioned previously as follow:
𝐿𝐿𝑇𝑇: 𝐴𝐴𝑑𝑑𝑑𝑑𝑆𝑆𝑡𝑡𝑒𝑒𝑑𝑑 → 𝐴𝐴𝑒𝑒𝑒𝑒𝑑𝑑𝑘𝑘𝑠𝑠 (15)
For a particular node 𝐼𝐼, the link table entry in its particular 𝐿𝐿𝑇𝑇𝑒𝑒 is called a bridge 𝐵𝐵. Multiple bridges can be contained in a single 𝐿𝐿𝑇𝑇𝑒𝑒. A bridge expression is described by:
𝐵𝐵𝑘𝑘= {𝑛𝑛𝑛𝑛𝐵𝐵, 𝑛𝑛𝑑𝑑𝑑𝑑𝑆𝑆𝑡𝑡𝑒𝑒𝑑𝑑, 𝑛𝑛𝑒𝑒𝑒𝑒𝑑𝑑𝑘𝑘} (16)
Where 𝑛𝑛𝑛𝑛𝐵𝐵, is the single identifier of a particular bridge, 𝑛𝑛𝑑𝑑𝑑𝑑𝑆𝑆𝑡𝑡𝑒𝑒𝑑𝑑 is the destination node reached through the bridge and 𝑛𝑛𝑒𝑒𝑒𝑒𝑑𝑑𝑘𝑘 is the intermediate node to transfer the message towards the final destination. When a request is initiated in a node, the set of carriers 𝐻𝐻𝑛𝑛𝑡𝑡𝐷𝐷𝑖𝑖 use the information contained in the link tables to transfer the message towards a particular node, as well as providing the information to create new entries if a response message is created from a node.
Figure 11 shows a graphical representation of the link tables of different nodes and the bridge created during message transfer.
42
Figure 11: Link table and bridge formation in mobile ad hoc configuration
State 1 shows the initial state before a message is transferred in the network, the link tables 𝐿𝐿𝑇𝑇 are show for each node in the network with the 𝑛𝑛𝑛𝑛𝐵𝐵, 𝑛𝑛𝑑𝑑𝑑𝑑𝑆𝑆𝑡𝑡𝑒𝑒𝑑𝑑, 𝑛𝑛𝑒𝑒𝑒𝑒𝑑𝑑𝑘𝑘 fields for each bridge entry.
State 2 shows a request initiated in node A and disseminated to the neighbor nodes B and F, the bridge entry is created in the link tables of the nodes receiving the message, the bridge
State 2 shows a request initiated in node A and disseminated to the neighbor nodes B and F, the bridge entry is created in the link tables of the nodes receiving the message, the bridge