WO2017041631A1

WO2017041631A1 - Communication network, devices and methods for proximity based distributed caching of service information within said network

Info

Publication number: WO2017041631A1
Application number: PCT/CN2016/096704
Authority: WO
Inventors: Rahul Arvind JADHAV; Amit Kumar SHEORAN; Vijayachandran MARIAPPAN
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2015-09-10
Filing date: 2016-08-25
Publication date: 2017-03-16
Also published as: CN107736002B; CN107736002A

Abstract

Communication networks devices and methods for proximity based distributed caching of service information within said network are disclosed. The network comprises service endpoint device (1402), client devices (1404), resource directory devices (1406), and border router devices (1408), in communication with each other. The methods for proximity based distributed caching of service information comprises: identifying (1502) RDs in a network; identifying (1504) service endpoints or clients in the network and assigning (1506) preferred RD to every service endpoint or client; registration (1508) of service endpoints with the service information to the preferred RD, the RD then backups the information on the BR; client always does the service lookup (service lookup from the client) (1510) from its preferred RD, if that RD cannot locally fulfill the lookup then it queries the BR for information, and based on the lookup patterns the RD decides to cache the service information i.e., proximity-based caching (1512).

Description

COMMUNICATION NETWORK, DEVICESAND METHODSFORPROXIMITY BASED DISTRIBUTED CACHING OF SERVICE INFORMATION WITHIN SAID NETWORK

TECHNIAL FIELD

The present invention described herein, in general, relates to communication networks, and in particularly, to a communication network, devices and methods for proximity based distributed caching of service information.

BACKGROUND

Internet of Things (IoT) is a new paradigm in the world of communication, where general-purpose daily-use appliances, utility devices connect to the Internet to achieve seamless connectivity, ease of operation, improved power consumption, better utilization of resources, remote monitoring etc. As shown in figure 1, IoT network can be divided into three primary parts: Wireless Sensor Network (WSN) , Gateway and Cloud. WSN is the last mile network where the devices interconnect with each other to form a mesh network. All the devices eventually connect to a gateway in order to communicate with a cloud based server.

A Wireless sensor network (WSN) refers to a network of spatially distributed autonomous sensors to monitor physical or environmental conditions, such as temperature, sound, pressure and the like, and to co-operatively pass their data through the network to a main location. WSN is sometimes called as Low Power and Lossy Networks (LLNs) in the context of IoT because of the limited power and network resources within the nodes and the network. The scale of nodes connected to the network is usually high. For e.g. 350+nodes for home automation, 1000+nodes for building automation, several thousand nodes for Industrial automation and other use-cases.

Advent of Internet of Things is estimated to result in an unprecedented increase in scale of networked devices. New networking standards have been defined to support constrained scenarios especially targeted to keep the cost of the network module low. Networks are intended to work without any human intervention and it entails the need for participating nodes to identify, advertise, discover and communicate with other nodes of interest in the network. Such need for auto-configuration poses a serious challenge to wireless low power nodes designed with limited memory and processing capability. IP based protocols which are used to interconnect these nodes facilitate the addressing and connectivity issues but rely on application level protocols for configuration of services.

Nodes in the networks provide different kinds of service. For e.g. as shown in figure 2, one node has humidity sensor which provides humidity information to the network and the other device could be a water sprinkler node. In a completely autonomous mode, sprinkler needs to know the humidity level so as to turn on its water-sprinkling operation. Thus the sensor and the sprinkler need to interwork without any manual configuration. Service discovery is used by the nodes to identify and command other nodes of interest in the network.

Based on the previous example, in certain scenarios the criticality of the service information can be extremely high. For e.g. consider the case of a heat sensor and the water sprinkler. Thus it is of paramount importance to make service information available within the network without depending on a single node (to avoid single point of failure) and ensure that the information latency is less.

■ Service Discovery Terminology:

a) Service Endpoint (SEP) : Node which hosts the service and advertises it within the network

b) Client: Node which queries/looks-up for a service

c) Resource Directory: Node which hosts the service information on behalf of other nodes

Figure 3 shows an exemplary scenario of the service discovery terminology, wherein, a sprinkler is acting as the SEP whose service information is stored in the resource directory (RD) , and the wireless temperature and humidity sensor acts as a client seeking service in the RD.

The primary goal of any service discovery protocol is to enable nodes to query for other nodes supporting specific services. Service discovery constitutes of a) optional Directory Service (DS) Discovery (RD (Resource Directory) , DA (Directory Agent) are some synonyms to DS (Directory Service)) b) Service Advertisement c) Service Update/Delete and d) Service Lookup.

Conventionally, there are various techniques for operations of service discovery in a network, the techniques may include but not limited to a Centralized DS (C-DS) mode, a Directory-less (D-less) mode, and a Distributed DS (D-DS) mode. Figure 4 shows conventionally available C-DS mode in comparison with D-less mode in comparison with D-DS mode.

However, the available techniques for service discovery operations have below mentioned technical drawbacks/problems:

1. In centralized mode, there is Single Point of Failure (SPoF) . If the RD node or the link becomes unavailable then the service discovery operations fail.

2. Though there is no SPoF in distributed (Dir-less or Dir-Based) mode, multicast is used and hence the average power consumption is high. Also the lookup latency is very high.

3. The nodes hosting the RD’s in all the prior-art techniques are constrained i.e. have less RAM. Thus all RD’s may not be able to host “all” the service information.

4. Existing techniques are not memory-aware i.e. the entries which are received first are served/stored first. The RDs within the WSN have relatively less memory and cannot hold all the service information in the network.

5. In centralized mode, the RD is most likely hosted on border routers (BR) . Thus all the lookup/register information has to be handled by BR, causing traffic bottlenecks near BR.

6. Proximity of lookups is not considered for storing entries in distributed directory based RD.

In view of the above drawbacks and limitation in the prior-art and as discussed above, there exists a need to provide a new and efficient technique that solves the problem of distributing service entries to enable efficient service discovery operations within the network without deploying any multicast based communication.

SUMMARY

A major technical problem in the existing communication network which is to be solved by the present invention is directed towards how to distribute service entries/information hosted by a node in a network to enable efficient service discovery operations without deploying any multicast based communication？

This summary is provided to introduce concepts related to communication network, devices and methods for proximity based distributed caching of service information within said network, and are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.

Accordingly, in one implementation, the present invention provides a device hosting service information for distributing service information to at least one other device in a network. The device comprises a processor, and a memory coupled to the processor for executing a plurality of modules present in the memory. The plurality of modules comprises a storage module, a receiving module, a distribution module, and a transmitting module. The storage module is configured to host the service information, and store a list of the other devices available in the network. The receiving module is configured to receive at least one service request from the other device, wherein the service request seeks for the service information pre-stored in the storage module required by the other device, and a new service information and an IP address associated with a new device joining the network, wherein the new device is not present in the list the other devices. The distribution module is configured to distribute the service information hosted, in response to the service request, to the other device in the network, the IP address of the new device to the other devices in the network, and thereby store, in the list, in the storage module, the new service information received and the IP address associated with the new device. The transmitting module configured to transmit the service information pre-stored or the new service information received based on the service request from the other device.

In one implementation, a device hosting service information for caching service information received from at least one other device in a network is disclosed. The device comprises a processor, and a memory coupled to the processor for executing a plurality of modules present in the memory. The plurality of modules comprises a storage module, a receiving module, a caching module, and a transmitting module. The storage module is configured to host the service information pre-stored. The receiving module is configured to receive at least one service request from at least one client device, wherein the service request seeks for the service information pre-stored, required by the client device, in the storage module, at least one new service information, if the service information pre-stored, required by the client device, is not available in the storage module, from the other device. The caching module is configured to cache the new service information received from the other device using a caching mechanism, wherein the caching mechanism confirms if the new service information received not pre-stored in the storage module, and evacuate, if no space in the storage module for storage of the new service information received, at least one service information pre-stored in the storage module based on at least one counter, and store the new service information received in the storage module. The transmitting module configured to transmit the service information pre-stored or the new service information based on the service request from the client device.

In one implementation, the present invention provides a network for distributing and caching of service information in a network, the network comprises a plurality of devices selected from a first device, a second device, a third device, and a fourth device, interconnected with each other. The network comprises at least one first device configured to host the service information associated with the second device, the third device, and the fourth device, wherein the second device is configured to offer services in the network, and register these services offered to the third device, and the fourth device configured to request at least one service to the third device. The first device is configured to receive at least one service request from the third device, wherein the service request seeks for the service information, pre-stored in the first device, required by the fourth device, store a list of the second device, the third device, and the fourth device available in the network, receive a new service information and an IP address associated with a new device joining the network, wherein the new device is not present in the list, distribute the IP address of the new device to the third device, store the new service information received and the IP address associated with the new device in the list, and transmit the service information pre-stored or the new service information received based on the service request from the third device. The third device configured to receive, from the first device, the service information pre-stored or the new service information based on the service request from the third device, cache the new service information received from the first device using a caching mechanism, wherein the caching mechanism confirms if the new service information received from the first device is not pre-stored in the third device； and evacuate, if no space in the third device for storage of the new service information received, at least one service information pre-stored in the third device based on at least one counter； and store the new service information received in the third device, and thereby transmit the service information pre-stored or the new service information stored in the third device based on the service request from the fourth device.

In one implementation, the present invention provides a method for distributing and caching of service information in a network, the network comprises a plurality of devices selected from a first device, a second device, a third device, and a fourth device, interconnected with each other, wherein at least one first device configured to host the service information associated with the second device, the third device, and the fourth device, wherein the second device is configured to offer services in the network, and register these services offered to the third device and the fourth device configured to request at least one service to the third device. The method includes:

receiving, by the first device, at least one service request from the third device, wherein the service request seeks for the service information, pre-stored in the first device, required by the fourth device；

storing, by the first device, a list of the second device, the third device, and the fourth device available in the network；

receiving, by the first device, a new service information and an IP address associated with a new device joining the network, wherein the new device is not present in the list；

distributing, by the first device, the IP address of the new device to the third device；

storing, by the first device, the new service information received and the IP address associated with the new device in the list；

transmitting, by the first device, the service information pre-stored or the new service information received based on the service request from the third device；

receiving, by the third device, from the first device, the service information pre-stored or the new service information based on the service request from the third device；

caching, by the third device, the new service information received from the first device using a caching mechanism, wherein the caching mechanism:

confirming if the new service information received from the first device is not pre-stored in the third device；

evacuating, if no space in the third device for storage of the new service information received, at least one service information pre-stored in the third device based on at least one counter； and

storing the new service information received in the third device；

and

transmitting, by the third device, the service information pre-stored or the new service information stored in the third device based on the service request from the fourth device.

In one implementation, the present invention provides a method, performed by a device hosting service information, for distributing service information to at least one other device in a network The method includes:

hosting the service information；

storing a list of the other devices available in the network；

receiving at least one service request from the other device, wherein the service request seeks for the service information pre-stored in the storage module required by the other device；

receiving a new service information and an IP address associated with a new device joining the network, wherein the new device is not present in the list the other devices；

distributing the service information hosted, in response to the service request, to the other device in the network, and the new service information received and the IP address of the new device to the other devices in the network； and thereby storing, in the list, the new service information received and the IP address associated with the new device； and

transmitting the service information pre-stored or the new service information received based on the service request from the other device.

In one implementation, the present invention provides a method, performed by a device hosting service information, for caching service information received from at least one other device in a network. The method includes:

hosting the service information；

receiving at least one service request from at least one client device, wherein the service request seeks for the service information pre-stored, required by the client device, in the storage module, and at least one new service information, if the service information pre-stored, required by the client device, is not available in the storage module, from the other device；

caching the new service information received from the other device using a caching mechanism, wherein the caching mechanism comprises:

confirming if the new service information received not pre-stored；

and

evacuating, if no space in the storage module for storage of the new service information received, at least one service information pre-stored based on at least one counter； and

storing the new service information received； and

transmitting the service information pre-stored or the new service information based on the service request from the client device. In one implementation, the present invention provides a method for proximity based distributed caching of service information in constrained multi-hop networks. The method comprises:

identifying RDs in a communication network；

identifying service endpoints or clients in the communication network and assigning preferred RD to every service endpoint or client；

registration (Service Advertisement or Service Registration) of service endpoints with the service information to the preferred RD, the RD then backups the information on the BR. (For the purpose of simplicity and understanding, in this document, BR is assumed to be the centralized RD which can stores all service information, but it can as well be a different node in the network) ；

client always does the service lookup (service lookup from the client) from its preferred RD, if that RD cannot locally fulfill the lookup then it queries the BR for information.

based on the lookup patterns the RD decides to cache the service information i.e., proximity-based caching.

In case of failure of either any RD, the other RD may act as a replacement or the information may be fetched from the BR； in case of failure of the BR, the RD may replace the BR for providing the service information.

In one implementation, the present invention provides a method for proximity based distributed caching of service information in a network wherein a plurality of devices are interconnected with each other forming said network. The method comprises:

● identifying at least one resource directory device selected from said plurality of devices, and configured for hosting service information of at least one other device；

● identifying at least one service endpoint device and at least one client device selected from said plurality of devices；

● assigning at least one preferred resource directory device to said service endpoint device and to said client device, wherein said preferred resource directory device is selected from said resource directory device identified；

● registering, on said preferred resource directory device, at least one service information, provided by, and associated with said service endpoint device；

● distributing, by said preferred resource directory device, said service information in said network, wherein said service information is distributed to at least one border router device and/or said resource directory device；

● caching, based on at least one lookup pattern of said client device and by means of a proximity based mechanism, said service information and at least one new service information received, on said preferred resource directory device.

In one implementation, the present invention provides a method for distributed caching of service information in a network wherein a plurality of devices are interconnected with each other forming said network. The method comprises:

● identifying at least one resource directory device in said network hosting service information of at least one other device；

● identifying at least one service endpoint device and at least one client device selected from said plurality of devices in said network；

● registering, on said preferred resource directory device, at least one service information provided by said service endpoint device；

● back up, by said preferred resource directory device, said service information registered on at least one border router device in said network；

● querying at least one lookup query, using said client device, said preferred resource directory device seeking at least one response, wherein,

● if said response to said lookup query is not responded by said preferred resource directory device, said response is fetched from said border router device by said preferred resource directory device and responded to said client device；

● caching, by said preferred resource directory device, said service information registered and said response fetched from said border router device, wherein said response is at least one new service information pre-registered on said border router device.

In one implementation, the present invention provides a network for providing a proximity based distributed caching of service information in a plurality of nodes/devices on said network. The network comprises at least one service endpoint device selected from said plurality of devices and configured to offer services to said plurality of devices； at least one resource directory device selected from said plurality of devices and configured to store information of said service endpoint device offering services to said plurality of devices； and at least one client device selected from said plurality of devices and configured to seek (lookup) for services in said network.

The network to achieve proximity based distributed caching of service information, said service endpoint device registers to at least one preferred resource directory device, selected from said resource directory device based on an IPv6 routing protocol for low-power and lossy network (RPL) signaling, with information of services offered by said service endpoint device； said preferred resource directory device is configured to transmit said information registered to at least one border router device in which said information received is stored； said client device, when lookup for services offered, transmit a lookup query to at least one preferred resource directory device selected from said resource directory device based on an IPv6 routing protocol for low-power and lossy network (RPL) signaling； said preferred resource directory device on receipt of said lookup query is configured checks if queried information is present in said preferred resource directory device if available, said preferred resource directory device responds back with the queried information； if not available, said preferred resource directory device is configured to transmit said lookup query to said border router device, in response to which said border router device replies with queried information to said preferred resource directory device which is ultimately transmitted to said client device； and cache said queried information in said preferred resource directory device by using a proximity based caching mechanism.

In one implementation, a person skilled in the art may understand that, the identification of the resource directory device may be performed/found by the endpoints based on a willingness of any node to share/publish its services within the network. Further, it may be understood that, the client may also be an endpoint device based on, however, it may work as client device when it seeks service from other endpoint (s) in the network. Further, it may be also understood by the preferred resource directory device may be assigned by any of the resource directory, or a border gateway or router or any of the node in the network.

As compared to the prior-art techniques, the present invention provides a technique of distributing the service information to more than one node and thereby caching said service information in these node which avoids technical issues of SPoF and service request traffic bottlenecks near a specific node (border) . Further the present invention enable to use unicast communication to distribute service information without any change of memory requirement for the client or the SEP. Further the present invention enable to get/set service information in the event preferred RD fails or the BR fails. Further, the present invention assigns a preferred RD to every client and SEP. Furthermore, the present invention avoids multicast communication by either leveraging routing protocol signaling (example RPL) or any cast based communication.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS

The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit (s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to refer like features and components.

Figure 1 illustrates a typical IoT network of the prior-art.

Figure 2illustrates an example of service discovery, as per the prior-art technique.

Figure 3 illustrates a service discovery nodes terminology, as per the prior-art technique.

Figure 4 illustrates a C-DS mode in comparison with D-less mode in comparison with D-DS mode, as per the prior-art technique.

Figure 5 illustrates anIPv6 routing protocol for low-power and lossy network (RPL) signaling primitives used in networks, as per the prior-art technique.

Figure 6 illustrates a process of identifying RD in the network, in accordance with an embodiment of the present subject matter.

Figure 7 illustrates a flowchart for distribution of RD list when a new RD joins the network, in accordance with an embodiment of the present subject matter.

Figure 8 illustrates a process of identifying a preferred RD in the network, in accordance with an embodiment of the present subject matter.

Figure 9illustrates a process of service registration, in accordance with an embodiment of the present subject matter.

Figure 10illustrates a Service Registration call flow, in accordance with an embodiment of the present subject matter.

Figure 11 illustrates a process of handling service lookup, in accordance with an embodiment of the present subject matter.

Figure 12 illustrates a flowchart for proximity based caching handling, in accordance with an embodiment of the present subject matter.

Figure 13 illustrates a proximity based caching -a call flow, in accordance with an embodiment of the present subject matter.

Figure 14 illustrates a network for providing a proximity based distributed caching of service information in a plurality of nodes/devices on said network, in accordance with an embodiment of the present subject matter.

Figure 15 illustrates a method for distributed caching of service information in a network wherein a plurality of devices are interconnected with each other forming said network, in accordance with an embodiment of the present subject matter.

Figure 16 illustrates adevice hosting service information for distributing service information to at least one other device in a network, in accordance with an embodiment of the present subject matter.

Figure 17 illustrates a device hosting service information for caching service information received from at least one other device in a network, in accordance with an embodiment of the present subject matter.

Figure 18 illustrates a method for distributing and caching of service information in a network, the network comprises a plurality of devices selected from a first device, a second device, a third device, and a fourth device, interconnected with each other, in accordance with an embodiment of the present subject matter.

Figure 19 illustrates a method, performed by a device hosting service information, for distributing service information to at least one other device, in a network in accordance with an embodiment of the present subject matter.

Figure 20 illustrates a method, performed by a device hosting service information, for caching service information received from at least one other device in a network, in accordance with an embodiment of the present subject matter.

It is to be understood that the attached drawings are for purposes of illustrating the concepts of the invention and may not be to scale.

DETAILED DESCRIPTION OF THE PRESENT INVENTION

The following clearly describes the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Apparently, the described embodiments are merely a part rather than all of the embodiments of the present invention. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

The present invention can be implemented in numerous ways, including as a process, an apparatus, a system, a composition of matter, a computer readable medium such as a computer readable storage medium or a computer network wherein program instructions are sent over optical or electronic communication links. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention.

A detailed description of one or more embodiments of the present invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.

Communication networks devices and methods for providing for proximity based distributed caching of service information are disclosed.

While aspects are described for providing communication networks and method for providing for proximity based distributed caching of service information, the present invention may be implemented in any number of different computing systems, environments, and/or configurations, the embodiments are described in the context of the following exemplary systems, apparatus, and methods.

Accordingly, in one implementation, the present invention provides a method for proximity based distributed caching of service information in constrained multi-hop networks. The method comprises:

● identifying RDs in a communication network；

● identifying service endpoints or clients in the communication network and assigning preferred RD to every service endpoint or client；

● registration (Service Advertisement or Service Registration) of service endpoints with the service information to the preferred RD, the RD then backups the information on the BR. (For the purpose of simplicity and understanding, in this document, BR is assumed to be the centralized RD which can stores all service information, but it can as well be a different node in the network) ；

● client always does the service lookup (service lookup from the client) from its preferred RD, if that RD cannot locally fulfill the lookup then it queries the BR for information.

● based on the lookup patterns the RD decides to cache the service information i.e., proximity-based caching.

● In case of failure of either any RD, the other RD may act as a replacement or the information may be fetched from the BR； in case of failure of the BR, the RD may replace the BR for providing the service information.

Identifying the RDs in the network: The present invention is explained considering multiple RDs in the network, however, a person skilled in that art may understand that the present invention may be implemented in a network having single RS as well. As shown in figure 5, there is a centralized RD (BR+RD) which is capable of hosting all the service information and apart from that there could be multiple RDs distributed in the network with low memory and may be incapable of holding the complete service information. For the purpose of this document and to avoid complexity in understanding, the centralized RD may be considered as the BR and will be addressed as BR or centralized RD in the remaining document.

BR manages the list of RDs in the network and thus needs to identify all the RDs in the network. We leverage routing protocol signaling for this purpose. As part of routing protocol signaling, messages are sent within the network to identify best paths and to form a mesh network. For e.g. IPv6 routing protocol for low-power and lossy network (RPL) protocol involves sending a data access objects (DAO) message from every node to the BR to setup routing tables on the way.

In one implementation, the RPL signaling to understand how routing paths are established is explained below, figure 5 shows RPL signaling primitives used in networks. DIO is a broadcast message initiated by the border router.

Using DIO every node determines the parent node to use for sending traffic in upward direction. Every node then sends a DAO message in upward direction through the identified parent (identified using acyclic graph (DAG) Information Option (DIO) ) . DAO message passes through every intermediate node and sets up the routing table all the way till the BR.

For example, as shown in figure 5 the BR first broadcasts the DIO. DIO may be always originated by a BR and contains the IP address of the BR. Since it is a broadcasted message the DIO is received by RD3 and RD1 since they are in range to the BR. RD3 and RD1 in turn broadcast the DIO downwards. Thus the DIO forwarded from RD3 is received by CLI1 and SEP1. Note the SEP1 will receive DIO from RD1 as well as RD3. The routing metrics/constraints which are part of DIO message will be used by SEP1 to decide the best path to use. Thus using DIO, every node knows how to reach the BR by selecting the best parent node.

In the figure 5, SEP1 selects RD1 as its best parent and hence the path is shown as primary path versus the other dotted line to RD3 which is used designate a secondary parent/path. It may be understood by the person skilled in the art that, the identification of best parent is an inherent property of any ad hoc mesh routing protocol (such as RPL) . The best parent selection is done by using one or more metrics such as RSSI (Received Signal Strength Indicator) , LQI (Link quality Indicators) , ETX (Estimated Number of Transmissions) , Latency, number of hops and the like. These metrics are handshaked as part of DIO message explained in the present invention. A node may receive multiple DIOs from different peers and it uses the metric indicators present inside DIO to identify the best parent to select.

Thus the DIO signaling ensures upward path selection i.e. every node knows how to reach BR by sending the traffic to its best parent.

The problem of establishing the downward path i.e. given that BR receives an IP packet to be sent to SEP1 how it will know whether to send it to RD1 or RD3, is solved by every node sending a DAO in upward direction which establishes the routing tables. When the node selects the best parent, it then sends a DAO message containing its own IP address in the upward direction. Since the DIO has established the path towards the BR, the DAO message will follow that path in the upward direction going via every intermediate parent. Thus every intermediate parent will receive DAO and know how to reach a particular node and thus sets up the routing table.

Identifying RDs: The present invention leverages the RPL signaling to identify RDs in the network. As shown in figure 6, when the RD node initiates a DAO in the upward direction it may additionally sets an RD_FLAG in the DAO message specifying that the source node is an RD. Thus when the DAO reaches the BR, the BR knows that the originator of the DAO message is an RD node.

Distribution of RD list: As shown in figure 7, the BR on identifying a new RD has joined the network, it informs all the other RDs of the presence of this new RD in the network. Thus all the RDs are aware of the addresses of every other RD in the network. Thus, when the new RD joins the network for the first time, it queries the BR for the list of RDs in the network and thus receives the list.

In one implementation, as shown in figure 7, when the new RD joins the network, the BR receives the service information from the new RD joined. RD then checks in its list of RD’s stored for the presence of this new RD. If the new RD is found in the list, the service information provided by this new RD is stored/updated in the list. If the new RD is not found in the list then the new RD information i.e., the address is sent to all other RD’s in the network. Further, the BR adds the new RD in the list of RD’s present in the network. Then the service entry is stored in the SET.

Identifying a preferred RD by/for the Service Endpoint and/or Client: The present invention enables every service endpoint device or client device needs to identify a preferred RD. This identification may be achieved as a part of routing protocol signaling. As shown in figure 8, the endpoint or client sets an EP_FLAG or CLI_FLAG in the DAO to signal the intermediate parents that it is interested in identifying a closest RD. The DAO while traveling upward is received by every intermediate router node in the network. If the router node is an RD then it consumes the EP_FLAG or CLI_FLAG and signals the endpoint or client that it can act as a preferred RD for that node.

In the case where no RD is located in the path to the BR, the BR may decide on behalf of the client or service endpoint which RD to use as a preferred RD. BR then sends a PREF_RD message to the client or endpoint specifying the preferred RD address to use. BR can decide the preferred RD to use based on number of parameters such as the least utilized RD, or the closest RD (based on the routing metric) to the node.

Service Advertisement or Service Registration: As shown in figure 9, the SEP device always registers the service to the preferred RD where the information is cached. Preferred RD sends this information to the BR as a backup. Thus BR continues to retain all the information in one place.

As shown in figure 9, the service endpoint (SEP) sends service registration to its preferred RD, the preferred RD then sends the registration information to the BR.

In one implementation, the service entry information is stored in following format on intermediate RDs (such as RD1, RD3) :

Table 3: SET (SERVICE ENTRY TABLE) ON RD

In one implementation, the BR+RD may store additional information along with the service information such as the corresponding RD from which it is received and the Service response information sent from RD to SEP.

TABLE 3: SET (SERVICE ENTRY TABLE) ON BR

In one implementation, additionally the BR needs to store the RD table which contains list of all the RDs present in the network:

TABLE 4: RD TABLE ON BR

Figure 10 illustrates a service registration call flow as an exemplary embodiment of the present invention. In one implementation, the endpoint sends a service registration message to the RD. On receiving the service registration message, the RD caches service registration messagehaving service information associated with said endpoint locally and then updates the information to the border router (BR+RD) . The BR on receiving this message may perform two things: 1. follows the procedure when the new RD joins the network as explained in details of figure 7 above and/or, 2. caches the service information locally as well.

Service Lookup: The client may always perform a look-up to the preferred RD. As shown in figure 11, when RD receives a lookup request from the client device, the preferred RD checks whether the queried information is available locally. If it is available then the lookup request is responded by the RD directly. Otherwise the RD sends the lookup query to the BR which in turn responds with the information to the RD. The RD then sends the response back to the client. The RD decides whether to cache this information locally based on the proximity-based algorithm.

As shown in figure 13, in proximity based caching, the RD may always be the first point of contact for every lookup. RD handles the lookup query on behalf of the client. The RD may have the information locally with itself or it may not. In case the information is not available locally the RD fetches the information from BR and then hands it over to the client. Thus RD may receive new service information from BR and may have to cache it locally. The proximity-based caching algorithm decides whether to cache the information and it has to be cached which other information needs to be evicted in case there is no free space left in the RD.

To achieve this, RD keeps a lookup counter in context to every service information it has. Every time a lookup is done then the corresponding counter with respect to the information is incremented while all other counters are decremented. Thus when the RD receives any information it checks the counter which is least and substitutes the new information at that location. It may be noted that, only the counters which are less than or equal to zero are considered for this eviction process. However, the evacuation criteria may be revised/altered based on the requirement of the system.

In one implementation, figure 13 illustrates Proximity based caching -sample call flow as an exemplary embodiment of the present invention. The example shows the RD with initial table set to A, B information. The call flow shows how subsequent lookup queries impact the table and depicts the proximity based caching algorithm.

The call flow in figure 13 in step-by-step manner is explained below:

Step 1: Assume that the RD current SET contains two Service Entry values for A and B with lookup count set to 0 for both.

Step 3: Node N3 sends a Query for Service Information A. RD contains service information for A and responds back to N3 with the information.

Step 3: The lookup counts (CC) on the RD is updated. Since the query was received for A the lookup count is incremented for A and decremented for every other entry. Thus B’s lookup count becomes -1.

Step 4: Next RD receives query for B. Since RD holds the information for B, it responds back with the information.

Step 5: The lookup counts on the RD are updated. Since the query was received for B the lookup count for B is incremented and is decremented for every other entry.

Step 6: Again query for B is sent to the RD. RD responds directly since it contains B information.

Step 7: Since query is received for B, the lookup count for B is incremented and for other entries it is decremented. Thus the lookup count for A and B is set to -1 and 1 respectively.

Step 8: Now query for C is received on RD. And RD does not contain information for C.

Step 9: Since query for C could not be satisfied at RD, the RD forwards the request to BR. BR holds information for all the services.

Step 10: RD receives C information from BR and checks if it has any vacant space in SET. Since there is no vacant space in the SET, RD checks if there is any entry with negative lookup count value. It finds that Service Entry A has negative lookup count value and thus A information is evicted and C information is replaced in place of A.

Step 11: B’s lookup count is decremented by 1 since the query received was from C, and thus the new lookup count of C and B becomes 0, 0 respectively. C’s lookup count is initialized to 0 when it is first pushed in the SET.

It is to be noted that the eviction mechanism of the present invention as explained only runs on the entries that are added dynamically during lookups. The entries which were advertised during initial registration procedure are not considered for eviction.

Failure Handling: As compared to the existing techniques available in the prior-art, the present invention is different in a way that it addresses single point of failure. Based on the above explained procedures, it is always ensured that the preferred RD always holds the service information for an endpoint apart from the centralized BR/RD.

Consider following scenarios for failure handling:

● Preferred RD fails: In case of preferred RD failure, the client tries to lookup the information with the BR. Similarly, if the EP detects that its preferred RD is unavailable, it queries the BR to assign an alternative preferred RD. BR assigns an alternative RD using the procedure mentioned in above section (Identifying a preferred RD as explained above) .

● Border Router or the Centralized RD fails: This will impact the RDs where queries could not be handled locally. As mentioned above (Identifying the RDs) , the RDs always have the list of all the other RDs in the network and thus the query has to be forwarded to all the other RDs in case it cannot be handled locally.

In one implementation, as shown in figure 14, the present invention discloses a network for providing a proximity based distributed caching of service information in a plurality of nodes/devices on said network, in accordance with an embodiment of the present subject matter. The network comprises at least one service endpoint device (1402) , at least one client device (1404) , at least one resource directory device (1406) , and at least one border router device (1408) , in communication with each other.

The service endpoint device (1402) is selected from said plurality of devices and configured to offer services to said plurality of devices. The resource directory device (1406) is selected from the plurality of devices and configured to store information of said service endpoint device offering services to said plurality of devices. The client device (1404) selected from said plurality of devices and configured to seek (lookup) for services in said network.

The service endpoint device (1402) registers to at least one preferred resource directory device selected from said resource directory device (1406) based on an IPv6 routing protocol for low-power and lossy network (RPL) signaling, with information of services offered by said service endpoint device (1402) . The preferred resource directory device (1406) is configured to transmit said information registered to at least one border router device (1408) in which said information received is stored.

The client device (1404) , when lookup for services offered, transmit a lookup query to at least one preferred resource directory device selected from said resource directory device based on an IPv6 routing protocol for low-power and lossy network (RPL) signaling. The preferred resource directory device (1406) on receipt of said lookup query is configured checks if queried information is present in said preferred resource directory device. If the required information is available, said preferred resource directory device responds back with the queried information. If the required information is not available, said preferred resource directory device is configured to transmit said lookup query to said border router device (1408) , in response to which said border router device replies with queried information to said preferred resource directory device which is ultimately transmitted to said client device. The queried information is cached in said preferred resource directory device by using a proximity based caching mechanism.

Although the present invention is explained considering that the service endpoint device (1402) , the client device (1404) , the resource directory device (1406) , and the border router device (1408) , is implemented as nodes on a communication network, it may be understood that the service endpoint device (1403) , the client device (1404) , the resource directory device (1406) , and the border router device (1408) , may also be implemented in a variety of computing systems, such as a laptop computer, a desktop computer, a notebook, a workstation, a mainframe computer, a server, a network server, and the like. Examples of the service endpoint device (1402) , the client device (1404) , the resource directory device (1406) , and the border router device (1408) , may include, but are not limited to, any sensor node/device that may include a portable computer, a personal digital assistant, a handheld device, sensor node and a workstation. The service endpoint device (1402) , the client device (1404) , the resource directory device (1406) , and the border router device (1408) , are communicatively coupled with each other through a network (not shown) .

In one implementation, the network may be a wireless network, a wired network or a combination thereof. The network can be implemented as one of the different types of networks, such as intranet, local area network (LAN) , wide area network (WAN) , the internet, and the like. The network may either be a dedicated network or a shared network. The shared network represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP) , Transmission Control Protocol/Internet Protocol (TCP/IP) , Wireless Application Protocol (WAP) , and the like, to communicate with one another. Further the network may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, and the like.

In one implementation, the queried information received from said border router device, is not currently available/present in said preferred resource directory device.

In one implementation, said resource directory device is selected by the steps of:

● transmitting, by at least one device selected from said plurality of devices, at least one data access objects (DAO) message to said border router device, wherein:

● said DAO message includes at least one flag specifying said device is said resource directory device； or

● aid DAO message does not include at least one flag specifying said device is not said resource directory device；

● receiving, by said border router device, said DAO message transmitted, and thereby

● identifying, by said border router device if said flag present/enabled, said device is said resource directory device； and

● (optionally) sending, by said border router device, at least one directed acyclic graph (DAG) Information Option (DIO) message to said resource directory device identified.

In one implementation, the border router device is configured to maintain a list of said resource directory device, wherein said list is distributed to all said resource directory device present in said network.

In one implementation, when a new device joins said network and if said new device is configured to act as said resource directory device, said new device queries said list stored in said border router device； and thereby said border router device is configured to distribute said list to said new device in said network.

In one implementation, said service endpoint device and said client devices are selected by using a service discovery mechanism which: detects said service endpoint device from said plurality of device, wherein said service endpoint device is configured to offer services to said plurality of devices in said network； and detects said client device from said plurality of device, wherein said client device is configured to seek services and utilize said services from said service endpoint device detected in said network.

In one implementation, said preferred resource directory device by means of at least one routing protocol or any cast communication for networks, preferably an IPv6 routing protocol for low-power and lossy network (RPL) , are selected by:

● transmitting, by said service endpoint device or said client device, at least one data access objects (DAO) message to said border router device, wherein:

● said DAO message, if transmitted by said service endpoint device, includes at least one flag specifying said service endpoint device is seeking said preferred resource directory device which is closest to said service endpoint device； and/or

● said DAO message, if transmitted by said client device, includes at least one flag specifying said client device is seeking said preferred resource directory device which is closest to said client device；

● receiving, by said plurality of devices, said DAO message transmitted by said service endpoint device or said client device； and

● responding, by at least one device from said plurality of devices if said device is said resource directory device registered, by sending at least one message indicating said device as said preferred resource directory device to said service endpoint device or said client device seeking preferred resource directory device.

In one implementation, if no device respond to said DAO message transmitted by said service endpoint device or said client device, said DAO message is received by said border router device, subsequently said border router device is configured to allocate said preferred resource directory device to said service endpoint device or said client device seeking preferred resource directory device, and simultaneously send at least one message indicating said device as said preferred resource directory device to said service endpoint device or said client device, in which, said device as said preferred resource directory device is selected based on a least utilized resource directory device in said network, or closest resource directory device identified using routing metrics in said network.

In one implementation, said service endpoint device configured to transmit service information associated with services provided by said service endpoint device to said preferred resource directory device identified for said service endpoint device； said preferred resource directory device is configured to cache said service information received； subsequently transmit said service information to said border router device, and said border router device, is configured to register said service information.

In one implementation, said service information is registered in said preferred resource directory device in a service entry information format, and said service entry information comprises at least one host IP address information, at least one host port number, at least one service information selected from an endpoint (name or id) (Ep) , a resource type (Rt) , an interface (If) , and endpoint type (Et) , a domain (D) , a lifetime (Lt) , a context/messages (Con) , , a look up count and the like.

In one implementation, said resource directory device/preferred resource directory is configured to store a list of all resource directory devices present/available in said network, said list comprises at least a resource directory device information selected from host IP address and port number, and SE count.

In one implementation, said border router device is configured to register said service information in a service entry information format, said service entry information comprises at least one host IP address information, at least one host port number, at least one service information selected from an endpoint (name or id) (Ep) , a resource type (Rt) , an interface (If) , and endpoint type (Et) , a domain (D) , a lifetime (Lt) , a context/messages (Con) , , a look up count and the like, at least one resource directory device /preferred resource directory device information, or at least one service RSP information..

In one implementation, said client device is configured to query or lookup said preferred resource directory device to seek service information； said preferred resource directory device is configured to:

● respond, if service information queried found, to said query with said service information found； or

● transmit, if service information queried not found, said query or said lookup to said border router device in said network；

● receive new service information in response to said query or said lookup from said border router device； and thereby

● respond if new service information received from said border router device, to said query with said new service information.

In one implementation, said preferred resource directory device configured to:

● maintain a plurality of lookup counters associated with service information pre-stored；

● increment at least one lookup counter selected from said lookup counters when a lookup is done for service information pre-stored and associated with said lookup counter, and simultaneously decrement other counters associated with service information pre-stored and not looked-up；

● cache, based on said proximity based mechanism, said new service information received and simultaneously creating a space, if no space available, for storage of said new service information by empty said pre-allocated service information in said preferred resource directory device, wherein said pre-allocated service information is emptied based on said counter i.e., service information with least counter is emptied and replaced with said new service information.

In one implementation, said service information is maintained in said preferred resource directory device and in said border router device.

In one implementation, said plurality of devices are selected from sensor nodes, routers, gateways, border routers/gateways, servers, actuators, and the like.

In one implementation, said client device is at least one device or node in said network seeking services offered by said service endpoint device or nodes on said network.

In one implementation, said service endpoint device and said client device comprises similar preferred resource directory device or different preferred resource directory device in said network.

Figure 15 illustrates a method for proximity based distributed caching of service information in a network wherein a plurality of devices are interconnected with each other forming said network, in accordance with an embodiment of the present subject matter. The method may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types. The method may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, computer executable instructions may be located in both local and remote computer storage media, including memory storage devices.

The order in which the method is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method or alternate methods. Additionally, individual blocks may be deleted from the method without departing from the protection scope of the subject matter described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof. However, for ease of explanation, in the embodiments described below, the method may be considered to be implemented in the above described communication network.

At block 1502, at least one resource directory device (1406) is identified by selecting the same from said plurality of devices. The resource directory device (1406) is configured for hosting service information of at least one other device.

At block 1504, at least one service endpoint device (1402) and at least one client device (1404) are identified by selecting from said plurality of devices.

At block 1506, at least one preferred resource directory device is assigned to said service endpoint device and/or to the client device, wherein said preferred resource directory device is selected from said resource directory device (1406) identified.

At block 1508, at least one service information, provided by, and associated with said service endpoint device (1402) is registered on said preferred resource directory device.

At block 1510, said service information is distributed by said preferred resource directory device in said network, wherein said service information is distributed to at least one border router device (1408) and/or said resource directory device (1406) .

At block 1513, said service information and at least one new service information received is distributed on said preferred resource directory device based on at least one lookup pattern 1510 of said client device and by means of a proximity based mechanism. It may be understood by the person skilled in the art that the lookup pattern is the lookup query or service lookup from the client seeking/requesting service information from a resource directory or any other device hosting service in the network.

In one implementation, said service information is an information associated with services offered by said service endpoint device on said network.

In one implementation, identifying resource directory device from said plurality of devices, comprises identifying by means of any routing protocol or any cast communication for networks, preferably an IPv6 routing protocol for low-power and lossy network (RPL) , by:

● said DAO message does not include at least one flag specifying said device is not said resource directory device；

In one implementation, the method comprises maintaining, in said border router device, a list of said resource directory device present in said network； and distributing, by said border router device, said list of said resource directory device registered to all said resource directory device present in said network.

In one implementation, when a new device joins said network and if said new device is configured to act as said resource directory device, the method comprises querying said list of said resource directory device registered to the border router device and thereby distributing said list stored in said border router device to said new device in said network.

In one implementation, identifying, said service endpoint device and said client device, comprises:

● detecting, by using a service discovery mechanism, said service endpoint device from said plurality of device, wherein said service endpoint device is configured to offer services to said plurality of devices in said network；

● detecting, by using a service discovery mechanism, said client device from said plurality of device, wherein said client device is configured to seek services and utilize said services from said service endpoint device detected in said network； and

● said service endpoint device and said client device comprises similar preferred resource directory device or different preferred resource directory device in said network.

In one implementation, assigning said preferred resource directory device, comprises, assigning by means of any routing protocol or any cast communication for networks, preferably an IPv6 routing protocol for low-power and lossy network (RPL) , by:

In one implementation, if no device responds to said DAO message transmitted by said service endpoint device or said client device, said DAO message is received by said border router device, subsequently said border router device is configured for: allocating said preferred resource directory device to said service endpoint device or said client device seeking preferred resource directory device, and simultaneously sending at least one message indicating said device as said preferred resource directory device to said service endpoint device or said client device, in which, said device as said preferred resource directory device is selected based on a least utilized resource directory device in said network, or closest resource directory device identified using routing metrics in said network.

In one implementation, registering said service information provided by said service endpoint device, comprises:

● transmitting, by said service endpoint device, service information associated with services provided by said service endpoint device to said preferred resource directory device identified for said service endpoint device； and

● caching, in said preferred resource directory device, said service information received； subsequently transmitting said service information to said border router device； thereby

● storing, in said border router device, said service information.

In one implementation, the method comprises:

● querying or a lookup, by said client device, said preferred resource directory device for seeking service information；

● responding, by said preferred resource directory device and if service information queried found, to said query with said service information found； or

● transmitting, by said preferred resource directory device and if service information queried not found, said querying or said lookup to said border router device in said network；

● receiving, by said preferred resource directory device, new service information in response to said query or said lookup from said border router device； and thereby

● responding, by said preferred resource directory device and if new service information received from said border router device, to said query with said new service information.

In one implementation, caching, based on at least one lookup pattern/query of said client device and by means of a proximity based mechanism, said service information and said new service information received, on said preferred resource directory device, comprises:

● receiving, by said preferred resource directory device, said new service information in response to said query or said lookup from said border router device, wherein said new service information received from said border router device is received first time for said preferred resource directory device；

● caching, based on said proximity based mechanism, said new service information received and simultaneously creating a space, if no space is available, for storage of said new service information, by emptying pre-allocated service information in said preferred resource directory device.

In one implementation, emptying said pre-allocated service information in said preferred resource directory device, comprises:

● maintaining, in said preferred resource directory device, a plurality of lookup counters associated with service information pre-stored；

● incrementing at least one lookup counter selected from said lookup counters when a lookup is done for service information pre-stored and associated with said lookup counter, and simultaneously decrementing other counters associated with service information pre-stored and not looked-up；

● caching, based on said proximity based mechanism, said new service information received and simultaneously creating a space, if no space available, for storage of said new service information by emptying pre-allocated service information in said preferred resource directory device, wherein emptying pre-allocated service information is based on said counter i.e., service information with least counter is emptied and replaced with said new service information.

In one implementation, in case of a new RD is to added in the network or removed from the network, the present invention automatically takes care of any new RD addition to the network or removal of existing RD. There is no change in the above explained mechanism for RD addition/removal.

In one implementation, the method for distributed caching of service information in a network wherein a plurality of devices are interconnected with each other forming said network. The method comprises:

● identifying (1502) at least one resource directory device (1406) in said network hosting service information of at least one other device；

● identifying (1504) at least one service endpoint device (1402) and at least one client device (1404) selected from said plurality of devices in said network；

● assigning (1506) at least one preferred resource directory device to said service endpoint device (1402) and/or to said client device (1404) , wherein said preferred resource directory device is selected from said resource directory device (1406) identified；

● registering (1508) , on said preferred resource directory device, at least one service information provided by said service endpoint device (1402) ；

● back up, by said preferred resource directory device, said service information registered on at least one border router device (1408) in said network；

● querying at least one lookup query (1510) , using said client device, said preferred resource directory device seeking at least one response, wherein,

● if said response to said lookup query is not responded by said preferred resource directory device, said response is fetched from said border router device (1408) by said preferred resource directory device and responded to said client device (1404) ；

● caching (1512) , by said preferred resource directory device, said service information registered and said response fetched from said border router device (1408) , wherein said response is at least one new service information pre-registered on said border router device (1408) .

Figure 16 illustrates a device (1408) hosting service information for distributing service information to at least one other device in a network, in accordance with an embodiment of the present subject matter. In one implementation, the present invention provides a device (1408) hosting service information for distributing service information to at least one other device (1406) in a network. The device (1408) comprises a processor (1602) , and a memory (1606) coupled to the processor (1602) for executing a plurality of modules present in the memory (1606) . The plurality of modules comprises a storage module (1608) , a receiving module (1610) , a distribution module (1612) , and a transmitting module (1614) .

The storage module may be configured to host the service information, and store a list of the other devices available in the network. The receiving module may be configured to receive at least one service request from the other device, wherein the service request seeks for the service information pre-stored in the storage module required by the other device, and a new service information and an IP address associated with a new device joining the network, wherein the new device is not present in the list the other devices. The distribution module may be configured to distribute the service information hosted, in response to the service request, to the other device in the network, the IP address of the new device to the other devices in the network, and thereby store, in the list, in the storage module, the new service information received and the IP address associated with the new device. The transmitting module may be configured to transmit the service information pre-stored or the new service information received based on the service request from the other device.

Figure 17 illustrates a device (1406) hosting service information for caching service information received from at least one other device (1408) in a network, in accordance with an embodiment of the present subject matter. In one implementation, a device (1406) hosting service information for caching service information received from at least one other device (1408) in a network is disclosed. The device (1406) comprises a processor (1702) , and a memory (1706) coupled to the processor (1702) for executing a plurality of modules present in the memory (1706) . The plurality of modules comprises a storage module (1708) , a receiving module (1710) , a caching module (1712) , and a transmitting module (1714) .

The storage module may be configured to host the service information pre-stored. The receiving module may be configured to receive at least one service request from at least one client device, wherein the service request seeks for the service information pre-stored, required by the client device, in the storage module, at least one new service information, if the service information pre-stored, required by the client device, is not available in the storage module, from the other device. The caching module may be configured to cache the new service information received from the other device using a caching mechanism, wherein the caching mechanism confirms if the new service information received not pre-stored in the storage module, and evacuate, if no space in the storage module for storage of the new service information received, at least one service information pre-stored in the storage module based on at least one counter, and store the new service information received in the storage module. The transmitting module may be configured to transmit the service information pre-stored or the new service information based on the service request from the client device.

Although the present subject matter is explained considering that the present invention is implemented as the device (1408, 1406, 1402, 1404) , it may be understood that the device (1408, 1406, 1402, 1404) may also be implemented in a variety of computing systems, such as a laptop computer, a desktop computer, a notebook, a workstation, a mainframe computer, a server, a network server, and the like. It will be understood that the device (1408, 1406, 1402, 1404) may be accessed by multiple users through one or more user devices (not shown) or application residing in those device (not shown) . Examples of the device (1408, 1406, 1402, 1404) may include, but are not limited to, a portable computer, a personal may be communicatively coupled to other devices through a network (not shown) .

In one implementation, the device (1408, 1406, 1402, 1404) may include at least one processor, an interface (1604, 1704) , and a memory. The at least one processor may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the at least one processor is configured to fetch and execute computer-readable instructions stored in the memory.

The interface may include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like. The interface may allow the device (1408, 1406, 1402, 1404) to interact with a user directly or through the client devices. Further, the interface) may enable the device (1408, 1406, 1402, 1404) to communicate with other computing devices, such as web servers and external data servers (not shown) . The interface can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. The interface may include one or more ports for connecting a number of devices to one another or to another server.

The memory may include any computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM) , and/or non-volatile memory, such as read only memory (ROM) , erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. The memory may include plurality of modules. The modules include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement particular abstract data types. In one implementation, the modules may include a receiving module, a user interaction profiler module, a user profile matcher module, and a recommendation module. The other modules may include programs or coded instructions that supplement applications and functions of the device (1408, 1406, 1402, 1404) .

In one implementation, the present invention provides a network for distributing and caching of service information in a network, the network comprises a plurality of devices selected from a first device (1408) , a second device (1402) , a third device (1406) , and a fourth device (1404) , interconnected with each other. The network comprises at least one first device configured to host the service information associated with the second device, the third device, and the fourth device, wherein the second device is configured to offer services in the network, and register these services offered to the third device, and the fourth device configured to request at least one service to the third device. The first device is configured to receive at least one service request from the third device, wherein the service request seeks for the service information, pre-stored in the first device, required by the fourth device, store a list of the second device, the third device, and the fourth device available in the network, receive a new service information and an IP address associated with a new device joining the network, wherein the new device is not present in the list, distribute the IP address of the new device to the third device, store the new service information received and the IP address associated with the new device in the list, and transmit the service information pre-stored or the new service information received based on the service request from the third device. The third device configured to receive, from the first device, the service information pre-stored or the new service information based on the service request from the third device, cache the new service information received from the first device using a caching mechanism, wherein the caching mechanism confirms if the new service information received from the first device is not pre-stored in the third device； and evacuate, if no space in the third device for storage of the new service information received, at least one service information pre-stored in the third device based on at least one counter； and store the new service information received in the third device, and thereby transmit the service information pre-stored or the new service information stored in the third device based on the service request from the fourth device.

Figure 18 illustrates a method fordistributing and caching of service information in a network, the network comprises a plurality of devices selected from a first device, a second device, a third device, and a fourth device, interconnected with each other, in accordance with an embodiment of the present subject matter. In one implementation, the present invention provides a method for distributing and caching of service information in a network, the network comprises a plurality of devices selected from a first device, a second device, a third device, and a fourth device, interconnected with each other, wherein at least one first device configured to host the service information associated with the second device, the third device, and the fourth device, wherein the second device is configured to offer services in the network, and register these services offered to the third device and the fourth device configured to request at least one service to the third device.

At step 1802, the first device receives at least one service request from the third device, wherein the service request seeks for the service information, pre-stored in the first device, required by the fourth device.

At step 1804, the first device stores a list of the second device, the third device, and the fourth device available in the network.

At step 1806, first device receives a new service information and an IP address associated with a new device joining the network, wherein the new device is not present in the list.

At step 1808, the first device distributes the IP address of the new device to the third device.

At step 1810, the first device stores the new service information received and the IP address associated with the new device in the list.

At step 1812, the first device transmits the service information pre-stored or the new service information received based on the service request from the third device.

At step 1814, by the third device receives from the first device, the service information pre-stored or the new service information based on the service request from the third device.

At step 1816, the third device caches the new service information received from the first device using a caching mechanism, wherein the caching mechanism, at step 1818, confirms if the new service information received from the first device is not pre-stored in the third device, and at step 1820, evacuates at least one service information pre-stored in the third device based on at least one counterif no space in the third device for storage of the new service information received.

At step 1822, the third device stores the service information pre-stored or the new service information stored in the third device based on the service request from the fourth device.

At step 1824, the third devicetransmit the service information pre-stored or the new service information stored in the third device (1406) based on the service request from the fourth device (1404) .

Figure 19 illustrates a method, performed by a device hosting service information, for distributing service information to at least one other device, in a network in accordance with an embodiment of the present subject matter. In one implementation, the present invention provides a method, performed by a device hosting service information, for distributing service information to at least one other device in a network.

At step 1902, the service information is hosted by the device 1408.

At step 1904, a list of the other devices (1406) available in the network is stored.

At step 1906, at least one service request from the other device (1406) is received, wherein the service request seeks for the service information pre-stored in the storage module required by the other device (1406) .

At step 1908, a new service information and an IP address associated with a new device joining the network is received, wherein the new device is not present in the list the other devices.

At step 1910, the service information hosted is distributed, in response to the service request, to the other device (1406) in the network.

At step 1912, the new service information received and the IP address of the new device to the other devices (1406) in the network is distributed.

At step 1914, the new service information received and the IP address associated with the new device is stored in the list.

At step 1916, the service information pre-stored or the new service information received is transmitted based on the service request from the other device (1406) .

Figure 20 illustrates a method, performed by a device hosting service information, for caching service information received from at least one other device in a network, in accordance with an embodiment of the present subject matter. In one implementation, the present invention provides a method, performed by a device hosting service information, for caching service information received from at least one other device in a network.

At step 2002, the service information is hosted.

At step 2004, at least one service request from at least one client device is received, wherein the service request seeks for the service information pre-stored, required by the client device, in the storage module, and at least one new service information, if the service information pre-stored, required by the client device, is not available in the storage module, from the other device.

At step 2006, the new service information received from the other device is cached using a caching mechanism, wherein the caching mechanism, at step 2008the device confirms if the new service information received not pre-stored； and at step 2012 the device evacuates, if no space in the storage module for storage of the new service information received, at least one service information pre-stored based on at least one counter.

At step 2014, the new service information received is stored in the device.

At step 2016, the service information pre-stored or the new service information is transmitted based on the service request from the client device.

In one implementation, it may be understood by the person skilled in the art that, the preferred resource directory where the information is shared by the SEP or the lookup request made by the client may be same i.e., shared by SEP and client or may be different i.e., distributed in network.

In one implementation, it may be understood that, the centralized RD may be located in BR or anywhere else in the WSN or outside it.

In one implementation, it may be understood by the person skilled in that art that, though the present invention may explained using CoRE-RD based service discovery, but the present invention may be equally applicable for any other service discovery protocols such as DNS-SD, or m-DNS/DNS-SD.

In one implementation, it may be understood by the person skilled in the art that, though the present invention may explained using RPL as routing protocol, but any other routing protocol available in the prior-art such as but not limited to any cast communication for networks, may be also used in the present invention.

In one implementation, it may be understood by the person skilled in the art that, to identify preferred RD, the endpoint or client may use some other heuristic such as number of hops or any other metric to identify the nearest or best RD to use or any of the existing techniques.

In one implementation, it may be understood by the person skilled in the art that, any cast addressing scheme may be used in place of routing protocol based signaling to isolate service discovery signaling from routing signaling. Alternatively, any cast addressing could be used to identifying RDs and endpoints and clients in the network.

In one implementation, it may be understood by the person skilled in the art that, a part of the communication such as identifying the preferred RD by the endpoints or clients may be based on multicast communication or any other communication available in the art, if the cost of multicast or other communication is not high.

In one implementation, it may be understood by the person skilled in the art that, the present invention may be implemented as a Border Router or the Gateway with integrated centralized RD capable of service information distribution in the WSN/LLN.

In one implementation, it may be understood by the person skilled in the art that, the present invention may be implemented as an IoT node with built-in RD functionality.

In one implementation, as the present invention may be implemented in a wireless sensor network, the present invention may also be used for providing services such as:

1. Home Automation

2. Building Automation

3. Industrial Automation

4. Smart City

5. Street Lighting

6. Smart Agriculture

In one implementation, the present invention may be implemented in automation scenarios. In case of automation scenarios where the connectivity to Border Router or Gateway is transient or is not always guaranteed, the idea allows a way to achieve service discovery operations in an optimized way.

An example product scenario is “Google Nest” : Google provides a Home Automation solution called Google Nest which works with a border router or gateway. It also assumes that the border router or gateway may not always be functioning in which case the services should still operate seamlessly. Our invention will be of value in such scenarios where connectivity is transient and any single node cannot be fully depended on.

The beneficial effects and advantages of the invention as compared to the existing techniques is a given below:

TABLE 5: COMPARISON OF PRESENT INVENTION WITH EXISTING TECHNIQUES

Apart from what is explained above, the present invention also include the below mentioned advantages:

1. The present invention avoids single point of failure.

2. The present invention enables to achieve reduced latency as compared to any other existing solutions.

3. The present invention reduces power consumption in overall network since the service discovery traffic is distributed in the network.

4. The present invention reduces traffic congestion in upstream network. The service discovery traffic is distributed within the network.

5. The present invention avoids multicast communication and thus improves registration/lookup performance.

6. The present invention enable to achieve efficient utilization of available resources such as memory.

7. The present invention handle uneven memory availability on RD’s. Preferred RD is decided based on factors including memory.

A person of ordinary skill in the art may be aware that in combination with the examples described in the embodiments disclosed in this specification, units and algorithm steps may be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether the functions are performed by hardware or software depends on the particular applications and design constraint conditions of the technical solution. A person skilled in the art may use different methods to implement the described functions for each particular application, but it should not be considered that the implementation goes beyond the scope of the present invention.

It may be clearly understood by a person skilled in the art that for the purpose of convenient and brief description, for a detailed working process of the foregoing system, apparatus, and unit, reference may be made to a corresponding process in the foregoing method embodiments, and details are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus, and method may be implemented in other manners. For example, the described apparatus embodiment is merely exemplary. For example, the unit division is merely logical function division and may be other division in actual implementation. For example, a plurality of units or components may be combined or integrated into another system, or some features may be ignored or not performed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections may be implemented through some interfaces. The indirect couplings or communication connections between the apparatuses or units may be implemented in electronic, mechanical, or other forms.

When the functions are implemented in a form of a software functional unit and sold or used as an independent product, the functions may be stored in a computer-readable storage medium. Based on such an understanding, the technical solutions of the present invention essentially, or the part contributing to the prior art, or a part of the technical solutions may be implemented in a form of a software product. The computer software product is stored in a storage medium, and includes several instructions for instructing a computer device (which may be a personal computer, a server, or a network device) to perform all or a part of the steps of the methods described in the embodiment of the present invention. The foregoing storage medium includes: any medium that can store program code, such as a USB flash drive, a removable hard disk, a read-only memory (Read-Only Memory, ROM) , a random access memory (Random Access Memory, RAM) , a magnetic disk, or an optical disc.

Although implementations for communication network devices and methods for proximity based distributed caching of service information within said network have been described in language specific to structural features and/or methods, it is to be understood that the appended claims are not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as examples of implementations ofthe communication network and method for proximity based distributed caching of service information within said network.

Claims

A device (1408) hosting service information for distributing service information to at least one other device (1406) in a network, the device (1408) comprising:

a processor (1602) ；

a memory (1606) coupled to the processor (1602) for executing a plurality of modules present in the memory (1606) , the plurality of modules comprising:

a storage module (1608) configured to host the service information, and store a list of the other devices (1406) available in the network；

a receiving module (1610) configured to receive:

at least one service request from the other device (1406) , wherein the service request seeks for the service information pre-stored in the storage module and required by the other device (1406) ；

a new service information and an IP address associated with a new device joining the network, wherein the new device is not present in the list the other devices；

a distribution module (1612) configured to distribute:

the service information hosted, in response to the service request, to the other device (1406) in the network；

the IP address of the new device to the other devices (1406) in the network； and thereby

store, in the list, in the storage module, the new service information received and the IP address associated with the new device； and

a transmitting module (1614) configured to transmit the service information pre-stored or the new service information received based on the service request from the other device (1406) .
The device (1408) as claimed in claim 1, wherein the receiving module receive the service request, the new service information and the IP address, and the transmitting module transmit the service information, preferably using at least one routing protocol or any cast communication for networks signaling.
The device (1408) as claimed in claim 1, wherein the service information stored in the storage module is in the form of a service entry information, said service entry information comprises at least one host IP address information, at least one host port number, at least one service information selected from an endpoint (name or id) (Ep) , a resource type (Rt) , an interface (If) , and endpoint type (Et) , a domain (D) , a lifetime (Lt) , a context/messages (Con) , , a look up count, at least one resource directory device /preferred resource directory device information, or at least one service RSP information.
The device (1408) as claimed in claim 1, is selected from sensor nodes, routers, gateways, border routers/gateways, servers, or actuators.
The device (1408) as claimed in claim 1, wherein said list of the other devices (1406) available in the network is obtained preferably using at least one routing protocol or any cast communication for networks signaling, wherein:

the other devices (1406) are configured to transmit at least one data access objects (DAO) message to the other devices (1406) available in the network, said DAO message includes at least one flag, and if the flag is present, the other devices (1406) is included in the list, thereby at least one directed acyclic graph (DAG) Information Option (DIO) message is transmitted to the other devices (1406) .
The device (1408) as claimed in claim 1, wherein the list is stored in the form of a table storing comprises at least a resource directory device information selected from host IP address and port number, and SE count.
A device (1406) hosting service information for caching service information received from at least one other device (1408) in a network, the device comprising:

a processor (1702) ；

a memory (1706) coupled to the processor for executing a plurality of modules present in the memory (1706) , the plurality of modules comprising:

a storage module (1708) configured to host the service information pre-stored；

a receiving module (1710) configured to receive:

at least one service request from at least one client device (1404) , wherein the service request seeks for the service information pre-stored, required by the client device (1404) , in the storage module；

at least one new service information, if the service information pre-stored, required by the client device (1404) , is not available in the storage module, from the other device (1408) ；

a caching module (1712) configured to cache the new service information received from the other device (1408) using a caching mechanism, wherein the caching mechanism comprises:

confirm if the new service information received not pre-stored in the storage module, and

evacuate, if no space in the storage module for storage of the new service information received, at least one service information pre-stored in the storage module based on at least one counter； and

store the new service information received in the storage module； and

a transmitting module (1714) configured to transmit the service information pre-stored or the new service information based on the service request from the client device (1404) .
The device (1406) as claimed in claim 7, wherein the receiving module receive the service request, the new service information and the IP address, and the transmitting module transmit the service information, preferably using at least one routing protocol or any cast communication for networks signaling.
The device (1406) as claimed in claim 7, is selected from sensor nodes, routers, gateways, border routers/gateways, servers, or actuators.
The device (1406) as claimed in claim 7, wherein the service information stored in the storage module is in the form of a service entry information, and said service entry information comprises at least one host IP address information, at least one host port number, at least one service information selected from an endpoint (name or id) (Ep) , a resource type (Rt) , an interface (If) , and endpoint type (Et) , a domain (D) , a lifetime (Lt) , a context/messages (Con) , a look up count.
A network for distributing and caching of service information in a network, the network comprises a plurality of devices selected from a first device (1408) , a second device (1402) , a third device (1406) , and a fourth device (1404) , interconnected with each other, the network comprising:

at least one first device (1408) configured to host the service information associated with the second device (1402) , the third device (1406) , and the fourth device (1404) , wherein the second device (1402) is configured to offer services in the network, and register these services offered to the third device (1406) , and the fourth device (1404) configured to request at least one service to the third device (1406) , wherein the network CHARACTERIZED IN THAT comprising:

the first device (1408) configured to:

receive at least one service request from the third device (1406) , wherein the service request seeks for the service information, pre-stored in the first device, required by the fourth device；

store a list of the second device (1402) , the third device (1406) , and the fourth device (1404) available in the network；

receive a new service information and an IP address associated with a new device joining the network, wherein the new device is not present in the list；

distribute the IP address of the new device to the third device (1406) ；

store the new service information received and the IP address associated with the new device in the list； and

transmit the service information pre-stored or the new service information received based on the service request from the third device (1406) ；

the third device (1406) configured to:

receive, from the first device (1408) , the service information pre-stored or the new service information based on the service request from the third device (1406) ；

cache the new service information received from the first device (1408) using a caching mechanism, wherein the caching mechanism:

confirm if the new service information received from the first device (1408) is not pre-stored in the third device (1406) ； and

evacuate, if no space in the third device for storage of the new service information received, at least one service information pre-stored in the third device (1406) based on at least one counter； and

store the new service information received in the third device (1406) ； and

transmit the service information pre-stored or the new service information stored in the third device (1406) based on the service request from the fourth device (1404) .
A method for distributing and caching of service information in a network, the network comprises a plurality of devices selected from a first device (1408) , a second device (1402) , a third device (1406) , and a fourth device (1404) , interconnected with each other, wherein at least one first device (1408) configured to host the service information associated with the second device (1402) , the third device (1406) , and the fourth device (1404) , wherein the second device (1402) is configured to offer services in the network, and register these services offered to the third device (1406) , and the fourth device (1404) configured to request at least one service to the third device (1406) , wherein the method CHARACTERIZED IN THAT comprising:

receiving (1802) , by the first device (1408) , at least one service request from the third device (1406) , wherein the service request seeks for the service information, pre-stored in the first device, required by the fourth device；

storing (1804) , by the first device (1408) , a list of the second device (1402) , the third device (1406) , and the fourth device (1404) available in the network；

receiving (1806) , by the first device (1408) , a new service information and an IP address associated with a new device joining the network, wherein the new device is not present in the list；

distributing (1808) , by the first device (1408) , the IP address of the new device to the third device (1406) ；

storing (1810) , by the first device (1408) , the new service information received and the IP address associated with the new device in the list；

transmitting (1812) , by the first device (1408) , the service information pre-stored or the new service information received based on the service request from the third device (1406) ；

receiving (1814) , by the third device (1406) , from the first device (1408) , the service information pre-stored or the new service information based on the service request from the third device (1406) ；

caching (1816) , by the third device (1406) , the new service information received from the first device (1408) using a caching mechanism, wherein the caching mechanism:

confirming (1818) if the new service information received from the first device (1408) is not pre-stored in the third device (1406) ； and

evacuating (1820) , if no space in the third device for storage of the new service information received, at least one service information pre-stored in the third device (1406) based on at least one counter； and

storing (1822) the new service information received in the third device (1406) ； and

transmitting (1824) , by the third device (1406) , the service information pre-stored or the new service information stored in the third device (1406) based on the service request from the fourth device (1404) .
A method, performed by a device (1408) hosting service information, for distributing service information to at least one other device (1406) in a network, the method comprising:

hosting (1902) the service information；

storing (1904) a list of the other devices (1406) available in the network；

receiving (1906) at least one service request from the other device (1406) , wherein the service request seeks for the service information pre-stored, as required by the other device (1406) ；

receiving (1908) a new service information and an IP address associated with a new device joining the network, wherein the new device is not present in the list the other devices；

distributing (1910, 1912) :

the service information hosted, in response to the service request, to the other device (1406) in the network；

the new service information received and the IP address of the new device to the other devices (1406) in the network； and thereby

storing (1914) , in the list, the new service information received and the IP address associated with the new device； and

transmitting (1916) the service information pre-stored or the new service information received based on the service request from the other device (1406) .
The method as claimed in claim 13, comprises receiving the service request, the new service information and the IP address, and transmitting the service information, preferably using at least one routing protocol or any cast communication for networks signaling.
The method as claimed in claim 13, wherein the service information stored is in the form of a service entry information, said service entry information comprises at least one host IP address information, at least one host port number, at least one service information selected from an endpoint (name or id) (Ep) , a resource type (Rt) , an interface (If) , and endpoint type (Et) , a domain (D) , a lifetime (Lt) , a context/messages (Con) , a look up count, at least one resource directory device /preferred resource directory device information, or at least one service RSP information.
The method as claimed min claim 13, wherein said list of the other devices (1406) available in the network is obtained preferably using at least one routing protocol or any cast communication for networks signaling, by the steps of:

transmitting, by the other devices (1406) , at least one data access objects (DAO) message to the other devices (1406) available in the network, said DAO message includes at least one flag；

including, if the flag is present, the other devices (1406) in the list； and

transmitting, by device (1408) , at least one directed acyclic graph (DAG) Information Option (DIO) message to the other devices (1406) .
The method as claimed min claim 13, comprises storing the list in the form of a table storing, the table contains at least a resource directory device information selected from host IP address and port number, and SE count.
A method, performed by a device (1406) hosting service information, for caching service information received from at least one other device (1408) in a network, the method comprising:

hosting (2002) the service information；

receiving (2004, 2006) :

at least one service request from at least one client device (1404) , wherein the service request seeks for the service information pre-stored, as required by the client device (1404) ；

at least one new service information, if the service information pre-stored, required by the client device (1404) is not available, from the other device (1408) ；

caching (2008) the new service information received from the other device (1408) using a caching mechanism, wherein the caching mechanism comprises:

confirming (2010) if the new service information received not pre-stored； and

evacuating (2012) , if no space for storage of the new service information received, at least one service information pre-stored based on at least one counter； and

storing (2014) the new service information received； and

transmitting (2016) the service information pre-stored or the new service information based on the service request from the client device (1404) .
The method as claimed in claim 18, comprises receiving the service request, the new service information and the IP address, and transmitting the service information, preferably using at least one routing protocol or any cast communication for networks signaling.
The method as claimed in claim 18, comprises storing the service information in the form of a service entry information, said service entry information includes at least one host IP address information, at least one host port number, at least one service information selected from an endpoint (name or id) (Ep) , a resource type (Rt) , an interface (If) , and endpoint type (Et) , a domain (D), a lifetime (Lt) , a context/messages (Con) , a look up count.