Chirp Networks
A system of transmitting of data packets within a network is described. The network includes at least one device transmitting short communication messages and another device transmitting standard communication message. The network also includes an array of wireless network routers communicating in a tree-shaped logical structure with one router including a receiver for the short communication messages. The receiver accepts the short communication message in a round robin manner from client wherein each short communication message is received at a designated time period. A single buffered packet is formed from the combined short communication messages and sent using the tree-shaped network.
The instant application claims priority as a continuation of U.S. Utility Application 14/740,062, filed on Jun. 15, 2015, presently pending, whose contents are incorporated by reference. Application Ser. No. 14/740,062 claims priority as a non-provisional of U.S. Provisional Application Ser. No. 62/012,196, filed on Jun. 13, 2014, presently expired.
Application Ser. No. 14/740,062 is also a continuation in part of U.S. Utility Application Ser. No. 13/764,008, filed on Feb. 11, 2013, which is issued as U.S. Pat. No. 9,363,651 on Jun. 7, 2016, which in turn claimed priority as a continuation in part of U.S. Utility Application Ser. No. 13/627,883, filed on Sep. 26, 2012, and issued as U.S. Pat. No. 8,923,186 on Dec. 30, 2014, which in turn claimed priority as a non-provisional utility application of Provisional U.S. Patent Application Ser. No. 61/555,400 filed on Nov. 3, 2011, currently expired, and Provisional U.S. Patent Application Ser. No. 61/615,802, filed on Mar. 26, 2012, presently expired, and Provisional U.S. Patent Application Ser. No. 61/621,926, filed on Apr. 9, 2012, presently expired, the contents of which are hereby incorporated by reference.
Application Ser. No. 14/740,062 also claims priority as a continuation in part of U.S. patent application Ser. No. 13/571,294, filed on Aug. 9, 2012, issued as U.S. Pat. No. 9,172,738 on Oct. 27, 2015, which in turn claimed priority to U.S. patent application Ser. No. 12/696,947, filed on Jan. 29, 2010, which issued as U.S. Pat. No. 8,520,691 on Aug. 27, 2013, which in turn claimed priority as a non-provisional of U.S. Application Ser. No. 61/148,803, filed on Jan. 30, 2009, presently expired, the contents of each prior application is hereby incorporated by reference. Application Ser. No. 13/571,294 also claimed priority as a continuation in part of U.S. Utility Application No. 12/352,457, filed on Jan. 12, 2009, and issued as U.S. Pat. No. 8,477,762 on Jul. 2, 2013, the contents of each prior application is hereby incorporated by reference.
Application Ser. No. 14/740,062 also claims priority as a continuation in part of U.S. application Ser. No. 13/541,446 filed on Jul. 3, 2012, presently abandoned, the contents of which are hereby incorporated by reference.
Application Ser. No. 14/740,062 further claims priority as a continuation in part of U.S. Utility Application 14/523,778, filed on Oct. 24, 2014, issued as U.S. Pat. No. 9,730,100 on Aug. 8, 2017, which in turn claims priority to U.S. Utility Application No. 12/625,365, filed on Nov. 24, 2009, issued as U.S. Pat. No. 8,514,852 on Aug. 20, 2013, which in turn claimed priority to U.S. Application Ser. No. 61/117,502, filed on Nov. 24, 2008, presently expired, which are hereby incorporated by reference.
FIELD OF THE INVENTIONThis invention relates to the field of computer networks and machine communications and, more particularly to a network system and method for facilitating large scale messaging emanating from devices on the edge of the network. These edge devices include, for example, sensors and actuators that interface with the dynamics of the physical world and each other through terse messages. In some embodiments these terse messages are referred to as chirps. Small data propagators near the edge of the network optimize the data based on dynamic subscriber interests.
BACKGROUND OF THE INVENTIONIncreasing percentages of devices connected to the Internet or other global networks are not used by people in the familiar way that personal computers, tablets and smart phones are. Interconnected devices monitor the environment, structures, transportation systems, factories, farms, forests, utilities, soil and weather conditions, oceans and resources. Many of these sensors and actuators are networked into autonomous sets, with much of the information being exchanged machine-to-machine directly and without human involvement.
Machine-to-machine communications are typically brief and specialized. Most sensors and actuators will report or act upon small pieces of information. For purposes of the systems described in this application these terse messages are “chirps.” Burdening these devices with prior art standard network protocol stacks is inefficient, unnecessary and unduly increases their cost of ownership.
Machine-to-machine communications dominate in several applications, including the field referred to as the “Internet of Things.” As described in this application, the architecture optimized for the Internet of Things necessarily entails a widely distributed topology relying on simpler chirp protocols, especially at the edges of the network where the machine-to-machine communications predominate. Intermediate network elements perform information propagation, manage broadcasts, and provide protocol translation. Another class of devices house integrator functions providing higher-level analysis, for both near-edge analytics and broader-scope analysis. Small chirp data provides the necessary information for analytical systems.
The system as described in the application is described using certain analogies, such as the propagation of pollen, and interaction of social insects.
This application describes reasons why a different architecture is needed for the Internet of Things. The architectures described can coexist with existing incumbent networking protocols. In one embodiment, the architecture comprises integrator functions, propagator nodes, and end devices, and their interactions.
SUMMARY OF THE INVENTIONThis invention addresses multiple embodiments. The methods taught address a variety of current networking challenges, specifically for mobile, temporal, or isolated networks, as can occur when a collection of wireless nodes is moving. These networks are mission critical, often requiring multiple connectivity media. Approaches for such networks are described in
These diverse requirements are supported by a service delivery framework for network participants comprising mesh nodes (in one embodiment) wherein each mesh node supports wireless clients. The features implemented in the architecture include:
-
- Logical Radio Routers
FIGS. 1 through 8 depict one logical radio abstraction to support diverse client connectivity needs.FIGS. 9, 13, 14, 15, 25, 44, 45, 56 through 63 explain certain other embodiments.FIGS. 5, 6 depict the analogy to tree based wired switch stacks. The analogy to ports on the switches is made inFIGS. 9, 38 through 42 .FIGS. 13, 14 ,15, 16, 44, 45 depict mission critical embodiments. Home or office application are shown inFIGS. 22, 23, 56 through 63, 68, 69 . - Efficient Terse Messaging Transport
FIGS. 10, 11 12, 24, teach concatenation for latency bound transmissions of terse M2M messaging, an embodiment of particular importance to VOIP packets. - Modular Nodes based on U/D/S/A
FIGS. 17, 22, 23, 26, 38, 39 through 45, 63 are embodiments of modular frameworks supporting the logical radio abstractions of Uplink, Downlink, Scanner and Access Point. Failover and dynamic options from one uplink port to another is depicted inFIGS. 9, 21, 41, 42, 44, 45 . Dynamic reconfigurable ports and sharing of U,D,S,A functions are depicted inFIGS. 9, 41, 42, 44, 45 . - Isolated Network support:
FIGS. 27 through 29 teach methods for Distributed DHCP address generation needed in mobile, temporal or isolated networks. Other applications are depicted inFIGS. 26, 39, 44, 45 . Finally,FIG. 27 depicts the SIP registry for M2M messaging, e.g. VOIP. - Remote Management
FIGS. 18, 19 describe embodiments for remotely programming clients. Clients include mesh router applications, element 060FIG. 12 . Programming applications or rule based directives is taught inFIGS. 30, 31 . The NMS based application support framework is depicted inFIG. 52 . It extensively uses Local and Global Streams,FIGS. 48, 49 . Intra router communications is implemented using terse UDP-based “heartbeats,”FIG. 54 . It is open and customizable and used for other M2M messaging. Stream Readers are used to translate and communicate with native formats,FIGS. 50, 51, 52 . A published NMS API,FIG. 53 , enables custom and domain specific NMS development, seeFIG. 55 . - Application-Aware Mesh Control
FIGS. 12, 20, 43 depict facets of the Mesh Control Layer that manages mesh topology first introduced inFIG. 1 . The control layer is radio and protocol abstracted. It supports both IP and non-IP client devices and applications. - Chirp Device Registration and Discovery
FIGS. 64, 70 describe a topic-based addressing scheme that does not require IP based addressing schemes. Instead the nature of the device and its function, define its genus. Categories may be defined or created using the SIP/DHCP services depicted inFIGS. 27, 28 .FIGS. 56 through 63 depict embodiments for such low-cost chirp devices. Category based information, e.g. “small data” is available within the M2M network for autonomous pattern discovery and machine control, seeFIGS. 68, 69, 70 . - Latency Sensitive Messaging
FIGS. 56 through 63 depict embodiments of devices participating in a dynamic M2M publish subscribe exchange. Terse M2M messaging between devices includes latency sensitive traffic, seeFIGS. 25, 56, 68, 69 .FIG. 71 shows chirp packets enter the propagator from both local and remote publishers (elements 7110 and 7120 respectively). The latter is containerized as a bus-load for efficient transport, 7120. Inside the propagator, port forwarding tables define the locations of interested subscribers. The bus containers may be reconstituted, in alignment with the current dynamics of the pub-sub exchange. Further processing includes removing chirp packets that are duplication or are no longer desired (such as for those packets that arrived out of order or contain information that is no longer current). In one embodiment, heart beat packet duplicates are discarded at each mesh node. The reconstituted bus containers are then sent out to both local and remote subscribers 7140. As shown inFIG. 72 , the top level view of the entire M2M service delivery framework consists of simple terse messaging devices 7210. Further included in the embodiment are propagator and bridging Mesh Network elements 7220 which incorporate agents. The agents are implemented within the nodes 7225. Agents act on behalf of big data subscriber requirements 7230.
- Logical Radio Routers
In order to more fully describe embodiments of the present invention, reference is made to the accompanying drawings. These drawings are not to be considered limitations in the scope of the invention, but are merely illustrative.
As explained below, the embodiment includes a Packet classifier (labeled 010) that recognizes voice packets based on size and regularity of transmissions. A VOIP concatenation engine (labeled 020) “container-izes” small voice packets into a larger “container” packet for more efficient transportation. Real time extensions (labeled 030) to the Linux kernel enable the system to provide near real time performance for sending and receiving the latency sensitive VOIP container packets through the network—regardless of what the Operating System is doing at the time.
Application driven rules and Scripts are resident in device abstracted APPLICATION layer library 060, a supervisory control layer above three lower control layer modules: TCP/IP, MESHCONTROL 040 and SCAN 050. Direct Machine to Machine (M2M) communications are controlled by APPLICATION over the Software MAC layer. The Software MAC Layer is typically running at the Kernel level of the software platform, requiring LINUX KERNEL EXTENSION 030. These extensions enable low level, fast applications/algorithms, operating at close to port forwarding tables, operating at (Kernel level) Drivers for Ports 080. The APPLICATION layer is analogous to the Control Plane in the SDN paradigm. The control plane manages the buses,
The description above and below and the drawings of the present document focus on one or more currently embodiments of the present invention and also describe some exemplary optional features and/or alternative embodiments. The description and drawings are for the purpose of illustration and not limitation. Those of ordinary skill in the art would recognize variations, modifications, and alternatives. Such variations, modifications, and alternatives are also within the scope of the present invention. Section titles are terse and are for convenience only.
The following concepts are applied in the embodiments described below:
-
- 1. Logical Radio Routers
- 2. Efficient Terse Messaging Transport
- 3. Modular Nodes based on U/D/S/A
- 4. Isolated Network support
- 5. Remote Management
- 6. Application Aware Mesh Control
- 7. Chirp Device Registration and Discovery
- 8. Latency Sensitive Terse Messaging
This section applies those methods to transport “chirp” broadcasts akin to VoIP packets from “chirp” device networks to co-existent and incumbent IP based network devices and protocols.
Raison d'être for Chirp ProtocolsTraditional networking protocols/techniques, specifically IP-based protocols, originated from sender-oriented communications. They emulated legacy frameworks of human-human networks to support human-to-human correspondence. Thus the methods of routing postal mail resulted in email. Emails are sender oriented. Sender oriented communications are intended to be read by stated intended recipients only. It is not lightweight: it contains destination addresses and potential encryption so they are not tampered by hackers. They were historically point to point communications.
With all this overhead in place, on every packet basis, IP based routing protocols favor economies of scale in moving large packets, preferably with best effort only. When QoS is required (latency/jitter/assured delivery) IP protocols extract a premium. Small packets are also charged a premium because the “standard” minimum packet size was not designed with them in mind. Traveling inside the minimum size, they have to pay the same price in transmission time and bandwidth requirements as the “standard” minimum.
This adversely affects the delivery schedule of lightweight packets (e.g. VOIP,
In addition to favoring larger packet sizes, retries (as in birds chirping repetitively) are frowned upon. Resending large packets increases traffic and TCP/IP overhead costs are based on a low number of retries. Further, retries are discouraged because they may flood the network e.g. broadcast storms. Retries are the exception, not the de facto modus operandi. Hence various forms of “virus” checks on email, file transports etc. are used. Since small packets are treated as one large packet, any device that begins to “chirp” like birds who chirp blindly and repetitively are costly especially when these chirp-like packets are travelling solo,
In contrast with legacy networks, communications that uses retries and over provisioning/broadcast storms are common in nature. For instance, pollen distribution by plants is not sender oriented. Instead, as many messages are sent as possible, in all directions. Note that these storms (e.g. pollen, monsoons) are seasonal, their time to live functions are encoded in their design. Parameters for these information containers do not have to be explicitly stated in each packet header. Pollen has its time-to-live function genetically encoded in it. Beyond that time it is ineffective. No network flooding can occur, despite over provisioning. Broadcasts are managed at a distributed systems level through the mesh control layer,
Further, nature's “packets” are receiver oriented. Pollen is promiscuously propagated, witness the temporary broadcast storms called allergy season. It is the receiver that has the (genetically encoded) secret handshake to unlock the pollen packet data. Sender data need not be encrypted.
In nature, receiver oriented security enables pollen to be lightweight (terse) and carried far by even low power winds. Further, pollen is reasonably patient or latency indifferent. As long as winds appear within pollen season, spring will occur. Light weight chirps/pollen are thus secure and lower Total Cost of Ownership (TCO) based on their lightness and “patience.”
In the world of Internet of Things (IoT), there is a need to be able to support lightweight chirp-like data without unduly taxing either the incumbent IP based networking protocols or the “chirp” device. This network protocol would support economical and effective transport of small, terse, repetitive chirps. In many cases the chirps are latency indifferent. Further, they would allow varieties of subscriber driven (receiver oriented) temporary broadcast storms without adverse effects.
DNA based Genus ClassificationRouters/Propagators, need some pollen “genus” or category or description to enable the match making. What does this descriptor look like? Bird chirps serve as an analogy. Bird chirps are categorized, based on studying individual bird categories. We can identify the bird type from its chirp/tune/melody. Hence those subscribers interested in melodies from doves, can now receive those recordings, based on bird category. The categories will have to support different levels of granularity—some bird enthusiasts are only interested in doves near their homes. Hence the category field, should be sufficiently flexible in design, to support further drill down.
In both melody/tunes and DNA structures, there exist “marker” strands of information that provide a common pattern across members of the category. These markers occur at specific locations and are of specific patterns. Thus, some categories may be described as those that have a 8 bit marker, always in the 4th byte of the bit stream. Thus the classification could be 4.8.XX.XX, where XX are more levels of granularity that may be gleaned from knowing a specific pattern type and what it entails, in terms of how to further classify the public (no security but not necessarily universally decipherable) category field.
Subscription based granularity Finer granularity is simply a matter of loading the appropriate agents who can recognize and sort based on information unlocked by the marker templates. Markers may be used in both public and private sections,
Low Overhead Routing is now possible: a quick bit mask on incoming chirp packets,
-
- 4.8.255.22
- 4.8.255.22.243 . . .
In one embodiment, Public classifications provide at least 3 levels of addressing (e.g. 4.8.255) and potentially the complete DNA strand/signature, based on agent subscriptions. The number of sub genus categories (e.g. 3 for 4.8.255) needed to more tightly define the zone of publisher interest is diverse. It is based on subscriber interests and mesh topologies see
Finer granularity costs requests follow the same toll hop costs and driven by the same economics: some applications/agents will work with “cheaper” but still relevant data some “hops” away. Other traffic may be more latency/jitter sensitive see
Encapsulating Chirp Packets Chirp data transport involves traversing the IP network, in some embodiments, and are thus susceptible to snooping/hacking. But this is not your typical IP data packet since the data is based or Chirp/Pollen-ID and/or Flower/Agents-ID etc. These are not typical IP or MAC-ID type Sender/Receiver Address Frames,
-
- a) The IP Destination Address (if applicable), and can include other addressing information depending on the type of transmission involved—e.g. unicast, multi-cast or broadcast, 3520,
- b) Chirp-ID (in the Sender Address frame, SA, 3522),
- c) Agent-ID being sought (in the BSSID Element, 3524)
- d) Any other use of the IP frame formats, recognizable by an agent.
All options (and their variants) exist within the exemplary Action Frame format, suitable for transmission over standard WIFI networks.
In one embodiment,
Chirp routers know just enough to decode the DA, SA and BSSID data sections,
How does the Chirp aware router recognize a chirp packet masquerading as an IP packet? Multiple embodiments exist:
-
- SIP-like Registries In one embodiment, the router knows which interface transports Chirp packets. It has a complete list of 802.11 stations associated with this AP. As part of the tree topology, it also has a list of all stations downstream—via the downlinks,
FIGS. 4 through 8 . It may not have access to the routing tables up stream. However, it may use distributed SIP registries that contain both chirp device and agent ID locations. Some embodiment use dynamic SIP registries to continue to provide VOIP phone connectivity even within isolated clusters. The same principles may be used to define where agents/flowers are, or the reverse look up—where chirp devices are, of interest to a particular agent. - Local Port Identification Even without the aid of SIP-like registries, chirp routers are still cognizant of the special nature of the data packets being transmitted. Chirp routers are keeping track of which port interface was used to inject the IP packet into the mesh network. In the mesh nodes shown in
FIGS. 17, 23 , there are multiple interfaces generally provided—the uplink and down links of Backhauls (BH and FD) and the client Access Points (AP). If the chirp packet came in through on of the APs, then it is marked as a chirp, since the Chirp ID provided does not match an associated IP based client's IP address or MAC-ID in its routing table. - Exclusion Principle in one embodiment, the AP does not need to keep a list of chirp devices it services—it can surmise its identity based on the exclusion principle, namely, this device ID, if an IP based device, is not in its routing tables or those of it node neighbors. Chirp device port locations and identity do not have to be stored, if anonymity is desired. In one embodiment, the chirp will still be forwarded up and/or down through the up links and down links the mesh tree, marked as a chirp in search of the agent/tune/subscriber. The identity of both chirp and its interested agent/tune/flower is hidden and yet the pollen reaches the flower efficiently. Ability to provide this type of anonymity extends existing prior art IP based routing security.
- Incognito Pollen: Some pollen travel incognito. That is, they expect propagators to rebroadcast them, potentially in all directions, until an intended agent discovers them. In one embodiment, a “4.0” category pollen implies a marker at byte 4 but its length is not specified. Agents with bit mask filtering locate such semi-incognito pollen, they know what the marker is. Note the marker can be arbitrarily long or short. Short markers increase the occurrence of false positives with other marker types (e.g. 4 bit markers 1.0.1.1 sharing same 4 bits as 8 bit marker 1.0.1.1.0.0.1.1). Agents that have this level of information can also glean other data from the packet melody/strands, to filter them out.
- Port based Zone Control In another embodiment, a “0.0” category pollen does not specify either the location or size of the marker. This is completely incognito and the propagator must continue to rebroadcast the pollen both up and down the tree till it reaches either roots or leaves of the tree. Chirp devices have no access to the IP network except through the bridging propagators
FIG. 22 . As in nature's broadcast storms, an agent at the chirp interfaces is either present or the pollen dies. Not that the tree networks inFIG. 22 are all layer 2. Only routers and their routing applications (FIG. 12 ) can initiate a bridge from Chirp to IP. Hence IP spamming/flooding from a corrupted or malfunctioning chirp device is stopped at the router. - Audit Trails Enterprise Class messaging mandates full audit trails on the myriad forms of communication being supported with the network. Each mesh node keeps a time window log of all messages received from all ports 090,
FIG. 12 . Further, for security reasons, it needs to keep a log of all out going packets created by applications operating at both Kernel and Application levels of the Stack. In on embodiment, the mesh node routing tables treat applications as a special class of client devices, resident in their multi-tenant application deployment environment. The location of affected devices is known within the network tree. Heart beat based messages are sent to all “clean” nodes to avoid contact with “affected” nodes and a new “temporal Key” is issued. Akin to ant colonies, the nodes response to “danger” evolves over time as publish-subscribe demographics change within the hybrid social network of humans and their machines and their evolving machine Esperanto,FIG. 69, 70 . - Lineage Based Secret Maps. In some situations, a 0.0 pollen may wish to specify a direction and nothing else—e.g. up or down the tree. Thus, in one embodiment 0.0.1 pollen are upwards, while 0.0.2 pollen are downwards. Since each category has its own vocabulary and language, 0.0 chirp families may choose to use the next two bits to define direction (0.0.0.1, 0.0.1.0, 0.1.1.0 . . . ), as opposed to marker size. If the device is removed from the network and its expected topology, the navigation fails. The device is therefore “imprinted”, like migrating birds, with a navigation “Mother” pattern. This is relevant to imprinting devices in the field to become part of a network, for life. The directions encompass both the chirp network topology and it parent IP based network tree, in an hybrid mesh network comprising of both,
FIGS. 22, 39 et al. Alternate navigation routing maps are also provided in one embodiment, for dynamic failover in healthy networks,FIG. 55 . - Chording Channels An agent can convert the data flow to be IP based, with regular IP addresses. In one embodiment, private networks coexist and span both chirp and conventional transmissions using “pattern” hopping techniques known only to them and their agents on the network. Part of the data travels as IP Data frames while others via chirp protocols, analogous to musical chords or dual signatures needed on a check. Only agents know the (chorded) “tune” This further obfuscates the chirp data flow.
- SIP-like Registries In one embodiment, the router knows which interface transports Chirp packets. It has a complete list of 802.11 stations associated with this AP. As part of the tree topology, it also has a list of all stations downstream—via the downlinks,
In some embodiments, chirp data comprises IP based transport packets whose format is regular and legitimate IP-based packet. It supports all the Frame Control feature sets,
Conventional IP based devices may also use category patterns as part of their data classification schemes. IP based packet headers specify the sensor MAC_ID or serial number within the payload, in addition to the category classification for IP based applications using the pub-sub exchange. By the same token chirp devices, may, in their private payload or public category type, contain an IP address where they wish their pollen to be sent. At each junction of the mesh network, there is the potential to bridge between IP and non IP logical radio mesh networks,
Several embodiments refer to scheduling of VOIP, to enable chirp like broadcasts from chirp like device networks to be efficiently repackaged to travel on existent and incumbent prior art IP based Network devices and protocols.
Chirps do not have destination addresses. Like school children boarding a school bus, they must be directed to get on the “yellow” bus/wind. In one embodiment, at each bus stop along the way, they need to be told which next bus to board,
Random Intervals, In one embodiment, simple devices chirp intervals are random, thereby providing a “white noise” effect that smarter devices can adjust for, using automatic gain control and other methods.
Regular Intervals In one embodiment, buses leave at regular intervals to help schedule when a container of chirps arrives and leaves at each bus station. They are a part of the mesh network support infrastructure for chirp travel. Their frequency of arrival is driven by the polling frequency (e.g. 20 ms for VOIP phones). It will vary depending on the chirp device nature and urgency per methods taught previously,
Dynamic Intervals. Additionally, subscribers, in one embodiment, awaiting specific pollen delivery, may also request sooner or later delivery, thereby dynamically changing Quality of Service (QoS). Collaborative scheduling agents, in some embodiments, ensure global supply chain alignment of supply/demand using simple concepts like “avoid” and “cluster” to ensure appropriate use of bandwidth resources and prevent “stacking”
This is a departure from Prior Art, where sender oriented IP packets declare their Quality of Service (QoS) requirements a priori, and QoS requirements are blindly enforced along the network path at significant added cost. QoS is dynamically managed in a receiver oriented network.
Bus Logistics Hubs In one embodiment, using the bus stations as decision points breaks up routing decision to hops between logistics hubs. The current active subscriber demographics and demand may be reevaluated at these hub points. Re-routing may be needed. For example, in one embodiment, routing policies may be specified. One “policy” is in place that all GE refrigerators provide a daily health status short “chirp” “color” (e.g. red, orange, blue, purple) forwarded to GE appliance service centers/subscribers. There are four such appliance region centers e.g. North, South, East and West. Based on the chirp signature and device location, directives running in edge routers “know” which bus load this pollen/chirp has to be part of. There may be multiple subscribers so it also needs to track and route multiple concurrent buses to multiple subscriber locations. Further, at each bus stop, at each mesh node, the routers must “know” enough to “sort” pollen, at varied levels of granularity for most effective onward directions,
Departures from Prior Art The hierarchical tree architecture is similar to a post office hierarchy (county, city, country are the hub levels), but unlike the post office, the direction or “default” address does not convert the communication into explicit addresses and sender-oriented transmissions. This type of routing circumvents the static address schemes used in traditional mail and email routing. In these embodiments, the destination of the bus is dynamic and so is its routing path. This is analogous to not just changing bus routing (e.g. an accident) but also end destination (e.g. hospital) based on the current situation and nature of containerized load. If the load is no longer needed, it is discarded mid journey. Round tripping, caused by static destination addresses, is avoided. Further packets are cloned and pruned at each junction of the route, in alignment with pub-sub demands.
Collaborative CoexistenceChirp data transport to the cloud involves traversing the IP network. Collaborative Coexistence is key since some chirp packets have subscribers reachable only through the incumbent IP network, e.g. VOIP chirp-like packets for an overseas subscriber. These networks and protocols must also conform to the existing frameworks and mediation layers e.g.
Further, if chirp devices intend to operate in the same frequency spectrum as IP devices, then both dance partners need to share the dance floor without constantly stubbing each others toes (e.g. collision□causing interference□some causing retries□possibly network flooding). Coexistence requires chirp devices not habitually create collisions or accidents on the IP based highways, like bad drivers. Methods taught with legacy chirp like devices (VOIP) see
Scheduling Device Chirps In one embodiment the chirp transmission schedules feeds the inter-node chirp bus schedules. Collaborative Scheduling,
Ideally, Chirp transmissions should occur sufficiently frequently for the level of granularity requested by the subscribers (“Customers”) schedules.
Small blue/red shift directives are provided by the Access Point for chirp devices. The Access Point receiving the chirps, monitors them to determine the range of the transmission “task” start/end times and their blue/red regions. It can thus profile the task and its variants. The bus schedule for the subscribers are then examined to determine the optimal bus size and interval. This, in turn drives how often the chirps must be transmitted and at what time. Synchronization may be approximate, measured in terms of a non dimensional parameter e.g. the fraction of the current chirp interval. This ensures complicity since both parties understand what that means regardless of whether they represent the time in nanoseconds or primitive register counters, Thus listen capable chirp devices may be controlled to adapt to the subscriber interests.
Closing Local Control LoopsCompare pollen based routing to conventional IP addressing. IP addressing is destination based. After the IP packet reaches its destination, the payload is deciphered. The typical thin client machine control loop,
The Chirp Category classifications scheme enables usable small data to be both generated and consumer by and for the edge member devices. Data is processed closer to the source/cluster, where it has more impact in tight sensing-control-actuation loops
Topology Matters
In one embodiment, bus delivery schedules are driven by the round robin delay caused by servicing siblings, at each sub tree along a route. More siblings imply more latency and favor node/device migrations. Others may barter to get a bigger slice of the pie. Accordingly, network topology and routing is modified based on toll/hop costs.
In
Periodic Silent Intervals In
Stream Reader Circuits:
Stream readers can feed multiple stream viewers, 5040, sequential readers/agents, 5060 or a logging database 5080 community mailbox etc. A circuit of collaborating stream readers and subscribers emulate complex logistic supply chains, see
One embodiment of an open extensible Stream Reader Framework,
Discovery and Registration: Several embodiments expand on the DHCP approach with the isolated distributed SIP registry functionality as described in that invention. Terse and periodic VOIP chirps are routed by the local SIP server. Further, when the VOIP network joins an external network, SIP registry information is exchanged. The Chirp registries may thus also exchange chirp device classifications and protocol specifics. Other (restricted) registries may contain location of agents dispersed at local nodes based on bus scheduling requirements. This enables discovery using the same approaches for devices, agents and logistics hubs. A comprehensive framework for discovery and routing for both Chirp and IP devices are thus supported by the DHCP and SIP registry modules, specifically designed for mobile, temporal wireless mesh networks.
When a new device is registered on the network, its agent/app is “loaded”- . This agent/app then provides the subscriber-based chirp-to-chirp translations and chirp-to-IP translations and filtered “small” data. Based on the direction of the chirp, agents may also direct propagators to provide intermediate translations see
Learning through Correlations
The lower control loop vocabulary is limited to actuator commands 6915, (e.g. “ON”, “OFF”). The system has no way of knowing whether the lawn sprinkler is functional, without accessing information from the larger M2M community. When chirp data is time tagged, then causal analysis indicates that if the upstream water pressure is “good” and the down stream flow is “bad”, then the actuator is worn out and needs replacement, see 6835. A local integrator agent, 6837 may also, through access to the shared pub/sub stream, 6920, be directed to perform this check each time the valve is activated, thus reserving internet traffic for exception handling. Thus an intelligent valve actuator emerges, without additional hardware/sensors at the actuator. Dual control loops thus provide intelligence without adding to the cost of the device.
Classification Aided Discovery How does the local integrator or its big data supervisors “discover” water pressure correlations in
Network Management The resulting implementation within a network of wireless nodes is scalable with no loss of bandwidth over many hops. The resulting network logic is distributed with low level autonomy on routing, power and channel management. The network uses distributed intelligence in terms of applications and where they reside: the result is a network where both the network management and the applications within the network can be distributed. The embodiments serve as a new type of service delivery framework specifically to address more “smarts” at the edge where the simple devices are sending terse messages or chirps. The network is flexible in that it can be implemented with multi-purpose devices, with alternative embodiments relying on a router and other embodiments using a client device. The embodiments rely on mesh nodes or routers, with the benefit of the router versus Machine controller are that by relying on the router there is low latency communication and ability to prevent escalation. The embodiments also rely on the router as the application delivery platform. The result is that the SDN control plane extends to the edge of the network where the chirping devices broadcast. In one embodiment the heartbeat extension to include sensor feeds and the result is integration with the NMS.
In summary, a new type of device management system emerges where efficient M2M command and control is enabled at the edge and edge communities. Chirp category based packet identification provides the M2M version on nature's receiver based communication protocols. Timing pollen “winds” is explored in
Claims
1. A system of transmitting of data packets within a network comprising:
- at least one device transmitting at least one short communication message;
- at least one device transmitting at least one standard communication message;
- an array of wireless network routers communicating in a tree-shaped logical structure;
- at least one of said wireless network routers comprising a chirp receiver for the at least one short communication message; and
- at least one of said wireless network routers comprising a standard receiver for at least one standard-length communication message;
- wherein said chirp receiver accepts said short communication message in a round robin manner from client devices associated with said chirp receiver, wherein each short communication message is received at a designated time period; wherein said short communication messages are buffered until all messages are received from all clients and a single buffered packet is formed from the combined short communication messages; and
- wherein each wireless network router further comprises an uplink function connecting said wireless network router to another wireless network router in the tree or an external ip-based network; a downlink function connecting said wireless network router to other wireless network routers within said tree; and a scanning function wherein the uplink function and the downlink function connect the wireless network routers participating in the system in a tree-based virtual switch and wherein said buffered packet is sent using the three-shaped virtual switch.
2. The system of claim 1 wherein a path within said tree-based virtual switch can be calculated in linear time with respect to the number of wireless network routers participating in the tree.
3. The system of claim 1 wherein said buffered packet is transmitted within the tree to the designated target host connected to another wireless network router or the external ip-based network.
4. The system of claim 3 wherein a path through the tree of the buffered packet is calculated in linear time.
5. The system of claim 3 wherein the transmission of the buffered packet does not delay standard communication messages transmitted in the tree.
6. The system of claim 1 wherein said clients are dispersed throughout the tree-shaped network.
7. The system of claim 1 wherein said round robin clients can reserve more than one time slot to obtain additional resources from the wireless network router.
8. A system of transmitting of data packets within a network comprising:
- at least one device transmitting at least one short communication message having metadata attached to said communication message;
- an array of wireless network routers communicating in a tree-shaped logical structure; and
- at least one of said wireless network routers comprising a chirp receiver for the at least one short communication message;
- wherein said chirp receiver accepts said short communication message in a round robin manner from client devices associated with said chirp receiver, wherein each short communication message is received at a designated time period; wherein said short communication messages are buffered until all messages are received from all clients and at least one buffered packet is formed from the combined short communication messages;
- wherein each wireless network router further comprises an uplink function connecting said wireless network router to another wireless network router in the tree or an external ip-based network; a downlink function connecting said wireless network router to other wireless network routers within said tree; and a scanning function wherein the uplink function and the downlink function connect the wireless network routers participating in the system in a tree-based virtual switch;
- wherein said buffered packet is sent using the uplink function of said wireless network router through the three-shaped network.
9. The system of claim 8 wherein multiple buffered packets are formed from the short communication messages and wherein the metadata attached to each communication message determines which buffered packet the short communication message is attached to.
10. The system of claim 9 wherein a path for buffered packet is calculated based on the metadata and intended target of the each buffered packet.
11. The system of claim 10 wherein the path calculation for the routing of the packet within the tree is performed in linear time.
12. The system of claim 8 wherein some short communication messages are cloned to multiple buffered packets and are sent to multiple destinations.
13. The system of claim 12 wherein said buffered packets are cloned at multiple forks in the tree-shaped network.
14. The system of claim 8 wherein each router participating in the tree may disassemble the buffered packet and send different parts in different directions.
15. The system of claim 8 wherein said short message metadata includes a latency requirement.
16. The system of claim 8 wherein a latency requirement for each short message is calculated on basis of type of data contained in the short message metadata.
17. A system of transmitting of data packets within a network comprising:
- at least one device transmitting at least one short communication message having metadata attached to said communication message;
- an array of wireless network routers communicating in a tree-shaped logical structure;
- at least one of said wireless network routers comprising a chirp receiver for the at least one short communication message;
- wherein said chirp receiver accepts said short communication message from client devices associated with said chirp receiver, wherein each short communication message is received along with its metadata and wherein said short communication message is published to a local control loop; and
- wherein each wireless network router further comprises an uplink function connecting said wireless network router to another wireless network router in the tree or an external ip-based network; a downlink function connecting said wireless network router to other wireless network routers within said tree; and a scanning function wherein the uplink function and the downlink function connect the wireless network routers participating in the system in a tree-based virtual switch.
18. The system of claim 17 wherein each control loop assembles and processes short communication messages assigned to the particular control group.
19. The system of claim 17 wherein each control group further comprises a local integrator agent, wherein said agent performs a check of all short communication messages received by the local control loop.
20. The system of claim 17 wherein said short communication messages comprises status messages and command messages.
Type: Application
Filed: Oct 10, 2017
Publication Date: Feb 15, 2018
Inventor: Francis DACOSTA (Santa Clara, CA)
Application Number: 15/728,863