US20120257624A1 - Routing operations using sensor data - Google Patents

Abstract

In one embodiment, a method comprises an Internet Protocol (IP) router receiving sensor data from at least one of a second IP router or an attached host sensor node, the sensor data distinct from link data of a network link; the IP router generating sensor information based on storing the sensor data with metadata describing reception of the sensor data by the IP router in a routing information base; and the IP router executing a routing operation based on the sensor information stored in the routing information base.

Description

• This application is a continuation of commonly-assigned, copending U.S. application Ser. No. 11/938,970, filed Nov. 13, 2007.
TECHNICAL FIELD
• The present disclosure generally relates to using an Internet Protocol (IP) network for reception and transport of sensor data from sensor host nodes in a sensor network.
BACKGROUND
• Sensor networks enable sensor data from remote sensors to be transported within data packets to a destination controller, for example an executable application configured for monitoring the sensor data. The remote sensors (e.g., video cameras, weather sensors, etc.) can be implemented as sensor host nodes configured for forming a layer 2 wireless mesh network, configured for reaching the destination controller, based on relaying or “flooding” sensor data throughout the mesh network (i.e., “gossiping”). Centimeter-sized (or smaller) sensor host nodes, referred to as “sensor dust”, have limited battery life and therefore are limited in their ability in relaying data packets from other sensor host nodes throughout the wireless mesh network. Mobile routers also can be deployed to form the mesh network, enabling the sensor host nodes to be implemented for example as wireless IPv6 host nodes. Hence, the mobile routers forming the mesh network can serve as default gateways for the sensor host nodes, enabling transport of the data packets transmitted by the sensor host nodes and carrying the sensor data to the destination controller via the mesh network.
• The Internet Engineering Task Force (IETF) also has a working group, entitled “IPv6 over Low power Wireless Personal Area Networks” (“6loWPAN”), investigating IPv6 transport of sensor data from sensor host nodes in a sensor network implemented, for example, using a Personal Area Network (PAN) such as an IEEE 802.15.4 network.
BRIEF DESCRIPTION OF THE DRAWINGS
• Reference is made to the attached drawings, wherein elements having the same reference numeral designations represent like elements throughout and wherein:
• FIG. 1 illustrates an example system having IP-based knowledge routers configured for generating sensor information based on received sensor data, and generating sensor knowledge based on exchanging sensor information with other IP routers, according to an example embodiment.
• FIG. 2 illustrates an example IP knowledge router from the system ofFIG. 1, according to an example embodiment.
• FIG. 3 illustrates an example method by one of the IP knowledge routers ofFIGS. 1 and 2, according to an example embodiment.
• FIG. 4 illustrates an example of sensor data, received for example from an attached host sensor node or an IP router, according to an example embodiment.
• FIG. 5 illustrates example sensor information generated by the IP knowledge router ofFIG. 3 and inserted into a routing information base, according to an example embodiment.
• FIG. 6 illustrates example routing operations executed by the knowledge router ofFIG. 2 based on the sensor information stored in the routing information base, according to an example embodiment.
DESCRIPTION OF EXAMPLE EMBODIMENTSOverview
• In one embodiment, a method comprises an Internet Protocol (IP) router receiving sensor data from at least one of a second IP router or an attached host sensor node, the sensor data distinct from link data of a network link; the IP router generating sensor information based on storing the sensor data with metadata describing reception of the sensor data by the IP router in a routing information base; and the IP router executing a routing operation based on the sensor information stored in the routing information base.
• In another embodiment, an apparatus comprises an Internet Protocol (IP) network interface circuit, a memory circuit, and a routing circuit. The IP network interface is configured for receiving sensor data from at least one of an IP advertisement message from a second IP router or an attached host sensor node, the sensor data distinct from link data of a network link. The memory circuit is configured for storing a routing information base. The routing circuit is configured for generating sensor information based on storing, into the routing information base, the sensor data with metadata describing reception of the sensor data by the apparatus, the routing circuit configured for executing a routing operation based on the sensor information stored in the routing information base.
DETAILED DESCRIPTION
• Particular embodiments extend the capabilities of routers configured for relying on existing routing protocols for exchanging metrics that are used in order to compute routes through an autonomous system, for example a wide area network. Such routers can be configured to receive sensor data from a sensor network, store the sensor data within their respective routing information bases (e.g., routing tables), and execute routing operations based on the sensor data stored in the routing information base.
• Routing operations can be performed using the sensor data, stored in the routing information base, based on metadata that is generated by the router and that describes attributes of the received sensor data, including attributes describing reception of the sensor data (e.g., identifying the network node having transmitted the sensor data to the router, date and time of reception, identity and/or location of the router having received the sensor data, etc.). Additional attributes can be added to the metadata to more precisely describe the context of the received sensor data, for example an identifier of the source sensor network if multiple sensor networks are implemented, a Personal Area Network (PAN) identifier if one or more personal area networks are implemented for transport of the sensor data, etc.. Additional attributes that can be added to the metadata include different indexes that can be used by the router in sorting the sensor data stored in the routing information base. Applying information theory and information science, such attributes provide context and structure to the received sensor data, resulting in “sensor information”. Hence, the metadata that describes the context of the received sensor data, including reception of the sensor data by the router, also enables the context of the received sensor data to be structured according to prescribed criteria, such that the metadata applied to the corresponding sensor data can create “sensor information” that can be used for implementing routing operations, described below.
• An example routing operation that can be performed by a router includes distributing the sensor information (including the sensor data and the associated metadata, i.e., “information metadata”) among other routers according to existing routing protocols or according to a layer 4 distribution protocol. Hence, the distribution of sensor information among the routers based on database synchronization of the respective routing information bases (RIBs) enables the network implemented by the routers to serve as a distributed database for sensor applications that need to access the sensor information. Hence, a sensor application executed on a network node can obtain the sensor information from the nearest router of the network, as opposed to requiring a query from the sensor application to traverse the network in order to reach a specific gateway configured for collecting all of the sensor data within the sensor network.
• Another example routing operation that can be performed by a router includes executing constrained routing, where a constrained routing path to a destination is generated such that a first path for reaching the destination is chosen if relevant sensor information identifies a first attribute (e.g., low wind conditions), or a second path for reaching the destination is chosen if the relevant sensor information identifies a second attribute (e.g., high wind conditions). Hence, constrained routing paths can be generated and implemented based on the sensor information generated from the received sensor data. Such constrained routing paths can be used as the basis for establishing a multi-topology routing based on the sensor information.
• Distribution of routing information between routers according to a prescribed routing protocol providing synchronization of routing information (e.g., Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS)) enables each of the routers to generate a graph of the network topology, and perform route computation based on calculating path costs and the network topology in order to generate optimized paths. The prescribed routing protocol (e.g., OSPF, IS-IS) also can be used for distribution of the sensor information among other routers, based on forwarding the sensor data and associated information metadata as data that is opaque to the prescribed routing protocol; hence, the prescribed routing protocol can be used to provide synchronization of the sensor information. Further, each of the routers can be configured for accumulating the sensor information over time, enabling the routers to establish an evolution of the sensor data relative to a prescribed evolution domain (e.g., time or constrained lifetime, geographic distribution, network growth distribution). Hence, each of the routers can be configured for executing statistical or optimization operations relative to different evolution domains, resulting in each router capable of generating “knowledge metadata” that describes the evolution of the sensor information generated by the IP router (and received from other routers via database synchronization), resulting in the formation of “sensor knowledge” that uses the knowledge metadata to provide the interpretation of the relevant sensor information.
• FIG. 1 is a diagram illustrating anexample network10 having asensor network12 and aknowledge backbone network14 for supplyingsensor knowledge64 to asensor application60, according to an example embodiment. Thesensor network12 includes multiplehost sensor nodes16, implemented for example as IPv6host nodes configured for outputting sensor data via wired or wirelesssensor data links18. Thesensor network12 also can include data acquisition routers20 configured for receiving the sensor data from thesesensors16 via thesensor data links18. Thesensor data links18 can be implemented as wireless mobile ad hoc network (MANET) links, although other link layer protocols can be used for thesensor data links18, for example “6loWPAN” type networks implemented using a Personal Area Network (PAN) over an IEEE 802.15.4 network. Thesesensors16 and the associateddata links18 also can be implemented using proprietary link layer protocols, assuming the data acquisition routers20 include the appropriate link layer interface for receiving the sensor data via thesensor data links18.
• The data acquisition routers20 can be implemented as mobile ad hoc network (MANET) routers configured for receiving the sensor data via the appropriate link layer protocol utilized by thewireless data links18. The data acquisition routers20 also can be configured with multiple distinct link interfaces that enable the data acquisition routers20 to receive sensor data from different groups ofsensors16 and across respective link layer domains for example different wireless channels, different link layer protocols, different sensor services, etc. The data acquisition routers20 also can be configured for forwarding the received sensor data via IPv6 packets over IP-baseddata links22. Hence, the data acquisition routers20 can serve as the ingress edge to an IP network, and can inject the sensor data received via the wirelesssensor data links18 into the IP network viaIP data links22, without any modification to the received sensor data.
• Thesensor network12 also can include aggregatingrouters24 that can be configured for aggregating the received sensor data into aggregated sensor data, and outputting the aggregated sensor data into theknowledge backbone network14 via anIP data link26. The aggregatingrouters24 can implement a tree topology that enables the sensor data to be aggregated in order to minimize the number of IP data packets that need to be transmitted to theknowledge backbone network14.
• An example of aggregatingrouters24 utilizing a tree topology for aggregation of sensor data is described in commonly-assigned, copending U.S. patent application Ser. No. 11/862,845, filed Sep. 27, 2007, entitled “Aggregation and Propagation of Sensor Data Within Neighbor Discovery Messages in a Tree-Based Ad Hoc Network”, published Apr. 2, 2009 as U.S. Patent Publication No. 2009/0085769. In summary, this copending application Ser. No. 11/862,845 describes mobile routers that can establish a wireless ad hoc mobile network having a tree-based topology, and that can output neighbor advertisement messages toward the root (i.e., clusterhead) of the tree-based topology. The neighbor advertisement messages can specify aggregated network prefix reachability information, as described in commonly-assigned U.S. Patent Publication No. 2005/0265259, published Dec. 1, 2005, entitled “Arrangement for Providing Network Prefix Information from Attached Mobile Routers to a Clusterhead in a Tree-based Ad Hoc Mobile Network”. The neighbor advertisement messages also can specify aggregated sensor data based on an aggregation of received sensor data messages from attached sensor host nodes. If a given mobile router is an intermediate mobile router that serves as a default attachment router for at least one attached mobile router, the intermediate mobile router can generate its aggregated sensor data based on an aggregation of the received sensor data messages from attached sensor host nodes, plus received aggregated sensor data retrieved by the intermediate mobile router from a received neighbor advertisement message.
• Hence, the mobile routers described in this copending application Ser. No. 11/862,845 can propagate aggregated sensor data toward the clusterhead using neighbor advertisement messages that are relied upon for propagation of network reachability information within the tree-based ad hoc mobile network. Consequently, wireless network traffic can be dramatically reduced by multiple orders of magnitude based on implementing a tree-based wireless ad hoc mobile network: the tree-based wireless ad hoc mobile network enables each sensor host node to send its sensor data to a single attachment mobile router, eliminating the necessity of relaying data packets from sensor host nodes throughout a mesh network. Further, aggregation of sensor data by each mobile router can minimize data traffic for sensor data based on adding the aggregated sensor data within neighbor advertisement messages that are required for maintaining reachability within the tree-based wireless ad hoc mobile network, eliminating the necessity of continuous transport of data packets carrying sensor data from sensor host nodes throughout the tree-based wireless ad hoc mobile network.
• Consequently, the mobile routers described in this copending application Ser. No. 11/862,845 can be used to implement the aggregatingrouters24 ofFIG. 1. Hence, the aggregatingrouters24 can output an IP-based neighbor advertisement message30 that includes the aggregated sensor data as described in the above-identified copending application Ser. No. 11/862,845, where the “clusterhead” is replaced with thenearest knowledge router28 that receives the IP-based neighbor advertisement message30 via the correspondingIP data link26.
• Hence, ascalable sensor network12 can be implemented that utilizes data acquisition routers20 for receiving sensor data fromhost sensor nodes16 via various link layer protocols, and aggregatingrouters24 that aggregate the sensor data into aggregated sensor data that can be supplied to aknowledge router28 within theknowledge backbone network14 in a scalable manner. A smaller scale implementation of thesensor network12 also can be utilized, where aknowledge router28 also can be configured for directly receiving sensor data via anIPv6packet32 transmitted by asensor host node16′ attached to theknowledge router28 via anattachment link26′.
• Theknowledge backbone network14 includes multiple IP-basedknowledge routers28 that can be configured for receiving aggregated sensor data from the received neighbor advertisement message30 described in the above-identified copending application Ser. No. 11/862,845, and/or receiving sensor data from anIPv6 packet32 received from an attachedsensor host node16′. As described below, theknowledge routers28 can be configured to enable theknowledge backbone network14 to supply desiredsensor knowledge64 to asensor application60, based onsynchronization84 of stored sensor information among theknowledge routers64 according to a prescribed routing protocol (e.g., OSPF or IS-IS) or according to a layer 4 distribution protocol, and generating the sensor knowledge based on generating knowledge metadata describing evolution of the sensor information relative to a prescribed evolution domain. Hence, theknowledge backbone network14 can be considered an “area” according to OSPF protocol, alternatively theknowledge routers28 can be considered as Level 2 routers according to IS-IS protocol.
• As illustrated with respect toFIG. 4, the sensor data (illustrated as a sensor data element)34 that can be contained within the neighbor advertisement message30 or theIPv6data packet32 can include one or more data values36 representing “raw sensor data”, aggregated sensor data, or both. The term “sensor data” refers to data having originated from a physical sensor measuring a physical parameter, where the physical parameter is distinct from data link information that is required for establishment and maintenance of a data link. Hence, the term “sensor data” can refer to either “raw sensor data” generated by the physical sensor (e.g., a single temperature measurement value, a single air pressure measurement value, a single wind speed management value, a single humidity value, etc.), or an accumulation, aggregation, or statistical evaluation of raw sensor data. As illustrated inFIG. 4, the sensor data within thesensor data element34 can include anaggregation36 of values for multiple sensor types, including average, minimum, and maximum values each for atemperature aggregation36a,anair pressure aggregation36b,awind speed aggregation36c,ahumidity aggregation36, and an Air Quality Index (AQI) aggregation36e.Sensor data related to other physical dimensions also can be included in thesensor data element34, except that these physical dimensions must be distinct from existing data link parameters required for establishment and maintenance of a data link and otherwise utilized for existing routing protocols; hence, data link parameters such as the bit error rate, received signal strength indicator (RSSI), link speed (e.g., 10 Mbits/sec., 54 Mbit/sec, 100 Mbit/s) and network parameters for existing routing protocols (e.g., hop count, bandwidth utilization, etc.) are distinct fromsensor data34.
• Any one of theknowledge routers28 ofFIGS. 1 and 2 can be configured for receiving sensor data in the form of “raw data” or accumulated data (e.g., the sensor data element34) either from a received neighbor advertisement message30 from an aggregatingrouter24, or from a receivedIPv6data packet32 from an attachedsensor host node16′. If preferred, any one of theknowledge routers28 also can be configured for receiving sensor data from a data acquisition router20. As illustrated inFIG. 5, each of theknowledge routers28 also can be configured for generatingsensor information38 based on generatinginformation metadata40 describing reception of the correspondingsensor data34 by thecorresponding knowledge router28, and storing the sensor information38 (including thesensor data34 and the corresponding information metadata40) into its routing information base (RIB)42.
• FIG. 2 illustrates anexample knowledge router28 according to an example embodiment. Theknowledge router28 includes an IPnetwork interface circuit44, arouting circuit46, and amemory circuit48 configured for storing therouting information base42 ofFIG. 5, for example in the form of a link state database (LSDB) according to OSPF or IS-IS protocol. The IPnetwork interface circuit44 can include aningress port50 configured for receiving thesensor data34 via the IP messages30 and/or32 vialinks26 and/or26′. The IPnetwork interface circuit44 also can include apeer port52, and anegress port54. Thepeer port52 can be configured for communication among thepeer knowledge routers28 according to existing routing protocols that support synchronization of data stored in the respective routing information bases42, such as OSPF or IS-IS protocol. Theegress port54 can be configured for receivingmessages56,58 from asensor application60 executed by a network node that is reachable via a data connection62: it will be apparent that theconnection62 between the network node executing thesensor application60 can be implemented as a local link, or as a virtual link that enables the network node executing thesensor application60 to be reachable by a wide area network, or a multi-hop data connection that traverses one or more networks such as the wide area network (e.g., the Internet).
• Therouting circuit46 can be configured for generating thesensor information38, illustrated inFIG. 5, based on generating themetadata40 associated with the corresponding receivedsensor data34, and storing thesensor information38 into therouting information base42 as asensor information entry66, described in further detail below.
• Any of the disclosed circuits of the knowledge routers28 (including thenetwork interface circuit44, therouting circuit46, and thememory circuit48, and their associated components) can be implemented in multiple forms. Example implementations of the disclosed circuits include hardware logic that is implemented in a logic array such as a programmable logic array (PLA), a field programmable gate array (FPGA), or by mask programming of integrated circuits such as an application-specific integrated circuit (ASIC). Any of these circuits also can be implemented using a software-based executable resource that is executed by a corresponding internal processor circuit such as a microprocessor circuit (not shown), where execution of executable code stored in an internal memory circuit (e.g., within the memory circuit48) causes the processor circuit to store application state variables in processor memory, creating an executable application resource (e.g., an application instance) that performs the operations of the circuit as described herein. Hence, use of the term “circuit” in this specification refers to both a hardware-based circuit that includes logic for performing the described operations, or a software-based circuit that includes a reserved portion of processor memory for storage of application state data and application variables that are modified by execution of the executable code by a processor. Thememory circuit48 can be implemented, for example, using a non-volatile memory such as a programmable read only memory (PROM) or an EPROM, and/or a volatile memory such as a DRAM, etc..
• Further, any reference to “outputting a message” or “outputting a packet” can be implemented based on creating the message/packet in the form of a data structure and storing that data structure in a tangible memory medium in the disclosed apparatus (e.g., in a transmit buffer). Any reference to “outputting a message” or “outputting a packet” also can include electrically transmitting (e.g., via wired electric current or wireless electric field, as appropriate) the message/packet stored in the tangible memory medium to another network node via a communications medium (e.g., a wired or wireless link, as appropriate) (optical transmission also can be used, as appropriate). Similarly, any reference to “receiving a message” or “receiving a packet” can be implemented based on the disclosed apparatus detecting the electrical (or optical) transmission of the message/packet on the communications medium, and storing the detected transmission as a data structure in a tangible memory medium in the disclosed apparatus (e.g., in a receive buffer).
• Also note that thememory circuit48 can be implemented dynamically by therouting circuit46, for example based on memory address assignment and partitioning executed by therouting circuit46.
• FIG. 3 illustrates an example method by any one of theknowledge routers28, according to an example embodiment.FIG. 6 illustrates example routing operations that can be executed by therouting circuit46 of any one of theknowledge routers28, according to an example embodiment. The steps described inFIGS. 3 and 6 can be implemented as executable code stored on a computer readable medium (e.g., floppy disk, hard disk, ROM, EEPROM, nonvolatile RAM, CD-ROM, etc.) that are completed based on execution of the code by a processor; the steps described herein also can be implemented as executable logic that is encoded in one or more tangible media for execution (e.g., programmable logic arrays or devices, field programmable gate arrays, programmable array logic, application specific integrated circuits, etc.).
• As illustrated inFIG. 3, theingress port50 of aknowledge router28 can receive instep70 sensor data (e.g., raw sensor data and/or aggregated sensor data)34, for example from an attachedhost sensor node16′ or an aggregatingrouter24. Therouting circuit46 can generate in step72sensor information38 by generatinginformation metadata40 that describes the context of the receivedsensor data34. As illustrated inFIG. 5, theinformation metadata40 can includecontext information68 describing the reception of the sensor data (e.g., “SD1”)34 by thecorresponding knowledge router28. For example, thecontext information68 described by theinformation metadata40 can include: a time value (e.g., “T1”)68aindicating the time that the correspondingsensor data element34 was received by thecorresponding knowledge router28; an origin identifier (e.g., “S1”)68bthat identifies the network node (e.g., Aggregating Router “AR1”) having transmitted thesensor data34 to theknowledge router28; source information (e.g., “R1”)68cthat identifies theknowledge router28 having stored the corresponding receivedsensor data34 in its corresponding routing information base; and a lifetime information (e.g., “L1”)68didentifying a lifetime of the corresponding sensor data (“SD1”)34. Hence, thetime value68aidentifies the relative age of the sensor data (“SD1”)34, theorigin identifier68bidentifies the network node having transmitted the sensor data (“SD1”)34 into theknowledge backbone network14, thesource information68cidentifies the original or “source”knowledge router28 that sources the corresponding sensor data (“SD1”)34 into theknowledge backbone network14, and thelifetime information68didentifies the lifetime or life span of the corresponding sensor data (“SD1”)34.
• Hence, themetadata40 can specify attributes describing reception of the sensor data (“SD 1”)34 by theknowledge router28, enabling the context of thesensor data34 to be preserved as thesensor data34 is propagated throughdatabase synchronization84 toother knowledge routers28. As described previously, other attributes can be added to theinformation metadata40 that describe the context of the receivedsensor data34, for example an identifier of thesource sensor network12, a PAN identifier, an information service provider identifier (e.g., if sensor data is being provided by multiple service providers), or other relevant environmental or political information associated with reception of the sensor data34 (e.g., declaration of a tropical storm warning, hurricane watch, hurricane warning, flood watch, flood warning, a declared disaster area due to weather events, etc.).
• As illustrated inFIG. 3, therouting circuit46 adds instep74 the sensor information element38 (including the correspondingsensor data34 and the corresponding information metadata40) as asensor information entry66 into therouting information base42. As illustrated inFIG. 5, thesensor information entry66 can be implemented in various forms, based on indexing preferences that may be implemented by therouting circuit46. For example,FIG. 5 illustrates that therouting circuit46 can index the sensor information entries based on source information (e.g., R1, R1, R3, . . . )68cthat identifies thesource knowledge router28 having injected the correspondingsensor information element38 into theknowledge backbone network14.
• FIG. 5 also illustrates that thesensor information entries66 are part of therouting information base42 that also includes routing information such aslink state entries78 that are generated based on therouting circuit46 sending and receiving “hello packets” and link state advertisement (LSA) messages, for example according to OSPFv3 protocol. As described previously, the sensor data is distinct from the link data, including link state data stored in thelink state entries78. Therouting information base42 also can be configured for storing anetwork graph80 that is generated by therouting circuit46 and represents a graph (e.g., network topology) of theknowledge backbone network14. Therouting information base42 also can be configured for storing a routing table82 specifying routing paths having been generated by therouting circuit46 based on thenetwork graph80, thelink state entries70, and route optimization according to prescribed routing protocols and as described in further detail below.
• Hence, therouting information base42 can include all routing information that is used under existing routing protocols for establishing routes within theknowledge backbone network14 based on synchronization of thelink state entries78 and thesensor information entries66 among theknowledge routers28 according to a prescribed routing protocol.
• According to one example implementation, therouting information base42 can be implemented based on storing thelink state entries78 in a first link state database that is synchronized among theknowledge routers28 by a first OSPFv3 instance, and storing the sensor information entries66 (and theknowledge metadata entries96, as appropriate) in a data knowledge database (DKDB) distinct from the first link state database, where the DKDB can be synchronized among theknowledge routers28 by a second OSPFv3 instance distinct from the first OSPFv3 instance. Hence, in this example implementation therouting circuit46 can execute multiple OSPFv3 instances.
• As described in further detail below with respect toFIG. 6, therouting circuit46 can execute instep76 ofFIG. 3 various routing operations based on thesensor information38 stored in therouting information base42 in the form ofsensor information entries66.
• FIG. 6 illustratesexample routing operations76 that can be performed by therouting circuit46. As described previously, thesensor information entries66 in therouting information base42 can be considered as opaque data from the perspective of the prescribed routing protocols (e.g., OSPF for IS/IS) that executedatabase synchronization84. Hence, therouting circuits46 in each of theknowledge routers28 can executedatabase synchronization84 of their respectivelink state entries78 and theirsensor information entries66, for example in response to the addition of at least onesensor information entry66 instep74. Hence, thedatabase synchronization84 enables thesensor information entries66 containing thesensor information elements38 to be propagated and synchronized among all the routing information bases42 of therespective knowledge routers28 instep84 in the same manner that thelink state entries78 are synchronized among therouters28 according to existing routing protocols.
• Consequently, arouting circuit46 receiving in step86 a routing protocol message (e.g., a received link state advertisement (LSA) message or “hello message”) specifying sensor information in the form of asensor information element38 or asensor information entry66 can determine instep88 whether to save the receivedsensor information38 or66 based on thecorresponding lifetime value68d,or based on determining whether the sensor information specifies a source knowledge router from thesource information68cthat exceeds a prescribed scope (e.g., if the sensor information is from aknowledge router28 that exceeds a prescribed number of hops). If instep88 therouting circuit46 determines that the lifetime of thesensor information38 or66 has expired, or that the sensor information has exceeded its scope (based on exceeding the prescribed number of hops), therouting circuit46 can selectively discard the undesired sensor information.
• Assuming therouting circuit46 determines insteps86 and88 that the receivedsensor information38 or66 includes relevant information within its lifetime and within the relevant scope, therouting circuit46 can update instep90 itsrouting information base42 with a newsensor information entry66, and continue thedatabase synchronization84 based on outputting in step92 a link state advertisement message or “hello message” with its updatedsensor entries66 to a neighboring router, for example according to OSPFv3 protocol.
• Following any change in thelink state entries78 or thesensor information entries66 in itsrouting information base42, therouting circuit46 can update itsnetwork graph80 and routing tables82, and generate and/or update instep94knowledge metadata entries96, illustrated inFIG. 5. As described previously, “knowledge metadata” describes the evolution of thesensor information entries66 generated by the IP router and received from other routers viadatabase synchronization84. Each of theknowledge metadata entries96 describes a corresponding evolution of the storedsensor information entries66 as thesensor information entries66 are accumulated over time: the “evolution” can refer to changes detected in thesensor information entries66 relative to a prescribed evolution domain, where each “evolution domain” can identify at least one independent variable or dimension used to identify relevant changes in the sensor information. For example, the geographicdistribution knowledge metadata96acan represent an indexing of change in thesensor information entries66 relative to a change in geographic distribution or distance from a reference origin, where sensor information can be evaluated with respect to geography or topography, or movement relative to a reference origin (e.g., measuring changes in sensor information by a mobile network as it moves further from a reference origin); the lifetimedistribution knowledge metadata96bcan represent an indexing of change in thesensor information entries66 over time, for example comparing short-term or long-term changes in the sensor information; the directionaldistribution knowledge metadata96ccan represent an indexing of change relative to a sensor angle, for example in the case of radar-based sensor information or navigation-based sensor information requiring an orientation relative to a prescribed coordinate system; the network growthdistribution knowledge metadata96dcan represent evolution of the sensor information as the network grows, for example indexed by the number of aggregatingrouters24 in thesensor network12, or the number ofknowledge routers28 in theknowledge backbone network14. Other examples of knowledge metadata can include indexing information for generating metric paths or gradients, for example isometric paths or maximum gradient paths to identify maximum or minimum changes in the distribution of values, for example in the case of maximum temperature gradient paths for a given geographic area.
• Hence, the generation and storage by therouting circuit46 of theknowledge metadata entries96 enables therouting circuit46 to generate “sensor knowledge” based on generating theknowledge metadata entries96 instep94, and storing theknowledge metadata entries96 in therouting information base42.
• Consequently, the sensor knowledge represented by theknowledge metadata entries96 overlying thesensor information entries66 enables therouting circuit46 to generateintelligent database responses64 to thesensor application60 ofFIG. 1. For example, therouting circuit46 can output instep98 selectedsensor knowledge64 to thesensor application60 in response to detecting a prescribed event. In particular, in response to thecorresponding egress port54 receiving instep100 ofFIG. 6 a Publish/Subscribe rule58 from thesensor application60, therouting circuit46 can install instep102 the Publish/Subscribe rule58 to enable therouting circuit46 to determine (e.g., for each update of the sensor information entries66) instep104 whether thesensor information66 matches the Publish/Subscribe rule58 relative to a relevantknowledge metadata entry96. An example event detected instep104 can be detecting a new record high temperature when the Air Quality Index (AQI) is determined to be in an unhealthy range. Hence, therouting circuit46, in response to detecting instep104 the prescribed event that is defined by the Publish/Subscribe rule58 supplied by thesensor application60, can output instep104 the desiredsensor knowledge64 to thesensor application60.
• Therouting circuit46 also can be configured for utilizing theknowledge metadata96 and/or theinformation metadata40 in order to respond instep106 to queries from thesensor application60. As described previously, since all thesensor information entries66 are synchronized among the routing information bases42 of theknowledge routers28, theknowledge backbone network14 can serve as persistent storage of thesensor information38 in thesensor information entries66, enabling thesensor application60 to send aquery56 to thenearest knowledge router28.
• Therouting circuit46 can be configured for responding to queries to accommodate the relative complexity of thequery56. For example, thequery56 can be a retrieval request for sensor information38 (or entries66) satisfying prescribed metadata criteria (e.g., sensor information added after a specified time or date, or sensor information added by a specifiedorigin68borsource knowledge router68c). Additional database indexing can be applied to the storedsensor information38 either by the routing circuit46 (e.g., the knowledge metadata96) or by an external database system and stored within therouting information base42, enabling the persistent storage of therouting information base42 distributed among theknowledge routers28 to serve as a distributed database. Hence, thequery56 also can be an intelligent database query according to known database query protocols, enabling therouting circuit42 to respond to intelligent database queries. Other indexing schemes overlying thesensor information entries66 and/or theknowledge metadata entries96 can be built by external applications (e.g., database applications) and stored in therouting information base42 for use by therouting circuit46 in responding to database queries56.
• Therouting circuit46 also can respond to queries for example based on publication of a prescribed set of Application Programming Interfaces (APIs) executed by therouting circuit46. Hence, the APIs can be utilized by thesensor application60 in generating queries or procedure calls to the API interface published by theknowledge router28. Therouting circuit46 also can be configured for responding to Layer 4 distribution protocol queries. Consequently, the persistent stored sensor information, as well as the distributed database, enables the sensor information and/or distributed database to be presented as a front-end interface that can be shared between sensor applications and/or database applications, without the necessity of requesting the data from a database server.
• Hence, in response to theegress port54 receiving in step108 a query (e.g., an intelligent database query)56, therouting circuit46 can respond to thequery56 by searching instep110 itsrouting information base42 using theappropriate information metadata40 and/or knowledge metadata96 (and other indexes added to therouting information base42 by an external database application) in order to provide the desiredsensor information38 and/orsensor knowledge64.Example sensor knowledge64 can be identifying peak daily temperatures within the last week that exceeded a historical average temperature for the relevant month, with approximate locations of the peak temperatures identified by theattribute68cidentifying thesource knowledge router28.
• Another example routing operation that can be performed by therouting circuit46 includes executing constrained routing instep112. For example, therouting circuit46 can be configured for generating in step114 a first path (“P1”) for reaching a destination (e.g., sensor application60) if selected sensor information (e.g., “WIND”) is below a first threshold (e.g., 20 miles per hour (mph)) indicating a low wind condition, and a second path (“P2”) for reaching the destination if the selected sensor information (e.g., “WIND”) exceeds the first threshold (e.g., 20 mph) indicating a high wind condition. Therouting circuit46 can store instep116 the constrained paths “P1” and “P2” in its routing table82 for use in routing in step118 a received packet based on selecting one of the paths P1 or P2 based on whether the relevant sensor information identifies that the corresponding detected sensor metric is below the threshold of 20 mph, or exceeds the threshold of 20 mph. In this example, use of a constrained routing path based on wind can be particularly beneficial for paths that can utilize laser transceivers for establishing a fiber-less laser link (i.e., over the air): such a laser link, however, can be unreliable in windy conditions due to movement of the laser transceivers, or weather conditions that reduce the propagation capabilities of the laser link, for example rain, snow, or fog. Hence, the constrained paths can enable use of the laser link (e.g., “P1”) for high bandwidth transmissions during ideal weather conditions, reserving use of the alternate (lower throughput) path (e.g., “P2”) during adverse weather conditions that are detected and based on the sensor information stored in therouting information base42.
• As described previously, another example routing operation executed by therouting circuit46 can be deletion of a stalesensor information entry66 instep120 in response to detecting that the correspondinglifetime attribute68dhas expired. Deletion of thestale entry66 can be followed by updating theknowledge metadata96 instep94, or performing a database sync operation instep84, if preferred.
• According to the example embodiments, routers can store received sensor data and associated metadata describing reception of the sensor data by the IP router, and synchronize routing information bases to enable the network to serve as a distributed database for sensor applications. Advanced database query operations can be executed by the routers on behalf of sensor applications based on the routers having established sensor knowledge based on generating knowledge metadata describing the evolution of the sensor information. The sensor information also can be distributed using existing routing protocols, based on supplying the sensor information as opaque data relative to the routing protocols. Storage of the sensor data and the associated information metadata in the routing information base also enables the routing circuit to generate knowledge metadata that can be used either for responding to database queries, or generating constrained routes that optimize routing of data packets based on sensor data that is distinct from existing network layer and link layer parameters.
• While the example embodiments in the present disclosure have been described in connection with what is presently considered to be the best mode for carrying out the subject matter specified in the appended claims, it is to be understood that the example embodiments are only illustrative, and are not to restrict the subject matter specified in the appended claims.

Claims (21)

1. A method comprising:

a first Internet Protocol (IP) router receiving sensor data within an IP network from at least one of a second IP router or an attached host sensor node, the sensor data distinct from link data of a network link;

the first IP router generating sensor information based on storing the sensor data with metadata describing reception of the sensor data by the first IP router in a routing information base, the routing information base further storing routing information required for the first IP router to establish one or more routes to provide reachability to a destination within the IP network; and

the first IP router synchronizing the routing information base with the routing information base of at least one of the second IP router or a third IP router within the IP network according to an IP routing protocol to maintain reachability within the IP network, the synchronizing of the routing information base including synchronizing the sensor information stored in the routing information base.

2. The method ofclaim 1, further comprising generating a constrained routing path to the destination based on the sensor information and the routing information stored in the routing information base.

3. The method ofclaim 2, wherein the generating a constrained routing path includes:

generating a first path for reaching the destination if a first portion of the sensor information identifies a detected sensor metric is below a first threshold; and

generating a second path for reaching the destination if the first portion of the sensor information identifies the detected sensor metric exceeds the first threshold, the second path distinct from the first path;

the method further comprising selecting, by the first IP router, one of the first or second paths for routing a received data packet, based on determining whether the first portion of the sensor information identifies the detected sensor metric is below the first threshold or exceeds the first threshold.

4. The method ofclaim 1, further comprising providing at least a portion of the sensor information to a sensor application in response to one of the first IP router receiving a database query from the sensor application, or the first IP router detecting a prescribed event defined by a prescribed rule related to the sensor information.

5. The method ofclaim 4, further comprising receiving by the first IP router the prescribed rule related to the sensor information from the sensor application via the IP network.

6. (canceled)

7. The method ofclaim 1, wherein the synchronizing includes:

the first IP router receiving sensor information from the third IP router according to the IP routing protocol providing synchronization of the routing information base in the first IP router with a remote routing information base of the third IP router;

the first IP router generating sensor knowledge based on generating metadata describing evolution of the sensor information generated by the first IP router, and the received sensor information from the third IP router, relative to a prescribed evolution domain, and storing the metadata describing the evolution in the routing information base.

8. The method ofclaim 7, further comprises providing at least a portion of the sensor knowledge to a sensor application in response to one of the first IP router receiving a database query from the sensor application, or the first IP router detecting a prescribed event defined by a prescribed rule related to the sensor knowledge.

9. The method ofclaim 1, wherein the metadata includes at least one of source information identifying the first IP router having stored the received sensor data in the routing information base or lifetime information indicating a lifetime of an identified portion of the sensor data stored in the routing information base, the method further comprising:

selectively removing, by the first IP router, the identified portion of the sensor data from the routing information base in response to detecting an expiration of the corresponding lifetime;

receiving, by the first IP router, received sensor information from the third IP router according to the IP routing protocol providing synchronization of the routing information base with a remote routing information base of the third IP router, the received sensor information including first sensor information having been generated by the third IP router and second sensor information having been received by the third IP router from a fourth IP router according to the IP routing protocol; and

selectively discarding, by the first IP router, the second sensor information based on identifying from corresponding source information that the second sensor information originated from a source beyond a prescribed scope utilized by the first IP router.

10. The method ofclaim 1, wherein:

the receiving includes receiving from the second IP router an IP advertisement message that specifies at least a portion of the sensor data;

the routing information base is implemented as a link state database that stores the sensor information including the sensor data and metadata, the synchronizing including the first IP router sending a link state advertisement message, specifying at least a portion of the sensor information, to a third IP router according to a prescribed link state routing protocol.

11. An apparatus comprising:

an Internet Protocol (IP) network interface circuit configured for receiving sensor data within an IP network from at least one of an IP advertisement message from a first IP router or an attached host sensor node, the sensor data distinct from link data of a network link;

a memory circuit configured for storing a routing information base, the routing information base storing routing information required for the apparatus to establish one or more routes to provide reachability to a destination within the IP network; and

a routing circuit configured for generating sensor information based on storing, into the routing information base, the sensor data with metadata describing reception of the sensor data by the apparatus, the routing circuit configured for synchronizing the routing information base with the routing information base of at least one of the first IP router or a second IP router within the IP network according to an IP routing protocol to maintain reachability within the IP network, the synchronizing of the routing information base including synchronizing the sensor information stored in the routing information base.

12. The apparatus ofclaim 11, wherein the routing circuit is configured for generating a constrained routing path to the destination based on the sensor information and the routing information stored in the routing information base.

13. The apparatus ofclaim 12, wherein the routing circuit is configured for generating the constrained routing path based on:

generating a first path for reaching the destination if a first portion of the sensor information identifies a detected sensor metric is below a first threshold; and

generating a second path for reaching the destination if the first portion of the sensor information identifies the detected sensor metric exceeds the first threshold, the second path distinct from the first path;

the routing circuit further configured for selecting one of the first or second paths for routing a received data packet, based on determining whether the first portion of the sensor information identifies the detected sensor metric is below the first threshold or exceeds the first threshold.

14. The apparatus ofclaim 11, wherein the routing circuit is configured for providing at least a portion of the sensor information to a sensor application in response to one of the network interface circuit receiving a database query from the sensor application, or the routing circuit detecting a prescribed event defined by a prescribed rule related to the sensor information.

15. The apparatus ofclaim 14, wherein:

the IP network interface circuit is configured for receiving the prescribed rule related to the sensor information from the sensor application via the IP network;

the routing circuit configured for implementing the prescribed rule for detection of the prescribed event relative to the sensor information.

16. (canceled)

17. The apparatus ofclaim 11, wherein the routing circuit is configured for:

receiving received sensor information from the second IP router according to the IP routing protocol providing synchronization of the routing information base with a remote routing information base of the second IP router; and

generating sensor knowledge based on generating metadata describing evolution of the sensor information generated by the routing circuit, and the received sensor information from the second IP router, relative to a prescribed evolution domain, the routing circuit configured for storing the metadata describing the evolution in the routing information base.

18. The apparatus ofclaim 17, wherein the routing circuit is configured for providing at least a portion of the sensor knowledge to a sensor application in response to one of the IP network interface circuit receiving a database query from the sensor application, or the routing circuit detecting a prescribed event defined by a prescribed rule related to the sensor knowledge.

19. The apparatus ofclaim 11, wherein the metadata includes at least one of source information identifying the apparatus having stored the received sensor data in the routing information base or lifetime information indicating a lifetime of an identified portion of the sensor data stored in the routing information base, wherein:

the routing circuit is configured for selectively removing the identified portion of the sensor data from the routing information base in response to detecting an expiration of the corresponding lifetime;

the IP network interface circuit is configured for receiving received sensor information from the second IP router according to the IP routing protocol providing synchronization of the routing information base with a remote routing information base of the second IP router, the received sensor information including first sensor information having been generated by the second IP router and second sensor information having been received by the second IP router from a third IP router according to the IP routing protocol;

the routing circuit is configured for selectively discarding the second sensor information based on identifying from corresponding source information that the second sensor information originated from a source beyond a prescribed scope utilized by the apparatus.

20. The apparatus ofclaim 11, wherein the routing information base is implemented as a link state database that stores the sensor information including the sensor data and metadata, the routing circuit configured for synchronizing the routing information base based on sending a link state advertisement message, specifying at least a portion of the sensor information, to the second IP router according to a prescribed link state routing protocol.

21. An apparatus comprising:

an Internet Protocol (IP) network interface circuit configured for receiving sensor data within an IP network from at least one of an IP advertisement message from a first IP router or an attached host sensor node, the sensor data distinct from link data of a network link;

a memory circuit configured for storing a routing information base, the routing information base storing routing information required for the apparatus to establish one or more routes to provide reachability to a destination within the IP network; and

means for generating sensor information based on adding, into the routing information base, the sensor data with metadata describing reception of the sensor data by the apparatus, the means for generating configured for synchronizing the routing information base with the routing information base of at least one of the first IP router or a second IP router within the IP network according to an IP routing protocol to maintain reachability within the IP network, the synchronizing of the routing information base including synchronizing the sensor information stored in the routing information base.

Images