|Publication number||US7251222 B2|
|Application number||US 10/022,935|
|Publication date||Jul 31, 2007|
|Filing date||Dec 18, 2001|
|Priority date||May 15, 2001|
|Also published as||US20030007461, WO2002093802A1|
|Publication number||022935, 10022935, US 7251222 B2, US 7251222B2, US-B2-7251222, US7251222 B2, US7251222B2|
|Inventors||Priscilla Chen, Masahiro Maeda, Edgar H. Callaway, Jr., Monique Bourgeois, Yan Huang, Jiang Huang, Qicai Shi|
|Original Assignee||Motorola, Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (57), Non-Patent Citations (7), Referenced by (36), Classifications (23), Legal Events (4)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application claims the benefit of U.S. provisional application No. 60/291,140, “Procedures for Merging the Mediation Device Protocol with a Network Layer Protocol”, filed May 15, 2001.
This application is related to pending application Ser. No. 09/803,259 filed Mar. 9, 2001 for “A Protocol for a Self-Organizing Network Using a Logical Spanning Tree” and to co-pending application Ser. No. 09/803,322, filed Mar. 9, 2001 for “A Multiple Access Protocol and Structure for Communication Devices in an Asynchronous Network”. These applications are hereby incorporated by reference.
This invention relates to the field of wireless communications networks, such as wireless personal area networks (WPANs), and specifically to procedures for allowing networks operating under the mediation device protocol to be merged and used with networks operating under a network layer protocol.
Many applications for wireless communication networks, such as wireless sensors, industrial control and monitoring, intelligent agriculture, asset and inventory tracking, and security, would benefit from a communication protocol that produced an ad-hoc, self-organizing network (i.e. one with a random topology in which the network organization and maintenance occurred without human intervention) that enables each node in the network to be inexpensive and to have low power consumption in all possible connection states. The Cluster Tree Protocol is a protocol for the logical link and network layers for a wireless ad-hoc network designed to meet the above requirements. The Cluster Tree Protocol is described in “Cluster Tree Protocol (ver.0.53)”, by Masahiro Meada, April, 2001, which is hereby incorporated by reference
The protocol uses link-state packets to form either a single cluster network, or a potentially larger cluster tree network. The network is basically self-organizing and supports network redundancy to attain a degree of fault tolerance and self repair. Nodes within the network select a cluster head and form a cluster according to the self-organized manner. In the cluster formation process the cluster head assigns a unique node identifier (ID) to each member node. Self-developed clusters connect to each other using a Designated Device, that is a special node with a high computing ability and large memory space. In many applications the Designated Device is also the gateway between the network and the Internet. The Designated Device assigns a unique cluster ID to each cluster.
Low power consumption is achieved, in part, by each network device having a low duty cycle. For example, a device may be active for only 0.1% of each cycle. However, for asynchronous systems, a low duty cycle makes it difficult for devices to synchronize with one another. For instance, if device A tries to contact device B, there is a high probability that device B is inactive or ‘sleeping’. The problem is compounded by the use of low cost crystal oscillators and on-chip Micro Electro-Mechanical System (MEMS) resonators for timing. The poor frequency performance of these devices increases the need for regular re-synchronization. The Mediation Device Protocol was introduced to enable low duty cycle devices to communicate with each other without requiring a high accuracy synchronization reference, thus overcoming the issue of poor frequency stability. The Mediation Device Protocol is described in detail in “Mediation Device Operation”, Qicai Shi, Ed Callaway, Document IEEE 802.15-01/1880r0, which is hereby incorporated by reference. A mediation device has a relatively long receive period, during which it can record messages in the network. The recorded messages are then played-back to other devices in the network. Hence, the mediation device acts as an “answering machine”.
In order to obtain the benefits of both the Mediation Device Protocol and network layer protocols such as the Cluster Tree Protocol, the protocols must be merged. Consequently, there is an unmet need for a process for merging and using the Mediation Device Protocol with a network layer protocol.
The features of the invention believed to be novel are set forth with particularity in the appended claims. The invention itself however, both as to organization and method of operation, together with objects and advantages thereof, may be best understood by reference to the following detailed description of the invention, which describes certain exemplary embodiments of the invention, taken in conjunction with the accompanying drawings in which:
This present invention relates to a process for merging and using the Mediation Device Protocol with a network layer protocol. The Cluster Tree Protocol is used as an example for a network layer protocol, but it will be apparent to those of ordinary skill in the art how the Mediation Device Protocol may be merged and used with other network layer protocols, since equivalent steps can be used between any network layer protocol and the Mediation Device Protocol. The Mediation Device Protocol is described in detail in “Mediation Device Operation”, Qicai Shi, Ed Callaway, Document IEEE 802.15-01/1880r0. A Cluster Tree Protocol is described in “Cluster Tree Protocol (ver.0.53)”, Masahiro Meada, April, 2001.
Under the protocol of the present invention, each device joining a network will enter into two stages: the Set-Up Stage and the Normal Operational Stage. During the Set-Up Stage, the device will discover whom its neighbors are, build a neighborhood list, obtain a Logical ID, and pick a parent. After the Set-Up Stage is complete, the device enters the Normal Operational Stage where it will send/receive control and data messages, invite and help new nodes to join the network, recover from broken links or topology changes, and other normal network operations.
5.1. Set-Up Stage
Every node enters a network in the Set-Up Stage. The timing diagram for this stage is shown in
5.1.1. Discovering Neighbors
A second cluster is denoted with CID 21 and has node 3 as its cluster head, with the logical ID 21,3.
Table 1 shows Node 2's initial neighborhood list. Note that the first neighboring node that the new node hears will be the first node listed on the neighborhood list.
An initial neighborhood list of Node 2 in FIG. 1.
Next Rx/Tx Time
. . .
. . .
. . .
Since the messages heard from neighbors may be “Hello”, control, or normal data packages, the Depth and Load parameters of some neighbors may not be available at this time. However, this is not a problem since only the Logical ID (or a MAC address) of the neighbors and their next Rx/Tx time are necessary at this step.
5.1.2. Confirm Symmetric Links with Neighbors
Referring again to
In U.S. patent application Ser. No. 09/803,259, “A Protocol for a Self-Organizing Network Using a Logical Spanning Tree Backbone”, filed Mar. 9, 2001, the “Connection Request” message is referred to as an “X” message and the “Connection Response” message is referred to as a “Y” message.
For the new node, after the “CON REQ” period, it will enter a second Rx period 113 listening for all the “CON RES” responses (114 and 134) from its neighbors. The new node will also update all the parameters in its neighborhood list. Any neighbors who did not send in a “CON RES” at the end of this period will be deleted from the neighborhood list. This will eliminate any nodes with asymmetric links from the neighborhood table. Table 2 shows the new node's neighborhood list after this period.
TABLE 2 A complete neighborhood list of a new node after Set-up Step. Load Logical ID Next Rx/Tx Time Depth Parameter 0, 0 431 0 9 0, 7 456 1 1 . . . . . . . . . . . . 21, 3 678 1 6
5.1.3. Obtain Logical IDs and Pick a Parent
After the neighborhood table is updated, the new node will try to obtain a Logical ID and pick a parent for itself. The procedure for this is highly dependent on the network layer protocol, as well as which MD mode (Dedicated MD or Distributed MD for example) the system is using.
18.104.22.168. Distributed MD with Cluster Tree Protocol
For this implementation, the new node can simply pick the first node from the neighborhood list as its parent (this is the first node that it hears and has symmetric links with). It then asks this parent to send a “Logical ID Request” to the Cluster Head. The “Logical ID Request” is referred to as a “NID REQ” in the Cluster Tree Protocol. The Cluster Head then sends a “Logical ID Response” to the parent. The parent node then relays this message to the new node. The new node now has a Logical ID and a parent, and the parent node knows that it has been picked as the new node's parent.
22.214.171.124. Dedicated MD with Cluster Tree Protocol
Since Dedicated MD is used in this implementation, there can be nodes within the new node's range that are not in the dedicated MD's range.
For this implementation, the new node needs to identify the Dedicated MD. This can be done in the initial step (107 in
The new node can then pick a parent from the “normal neighborhood list” and ask that parent to request a Logical ID from the Cluster Head, the same way as in the Distributed MD case.
Table 3 shows the “normal neighborhood list” of node 2 and Table 4 shows its “Non-sync neighbor list”, from the topology of
Normal neighborhood list of Node 2 in FIG. 3.
Next Rx/Tx Time
TABLE 4 “Non-sync neighbor list” of Node 2 in FIG. 3. Load Logical ID Next Rx/Tx Time Depth Parameter 21, 7 798 2 12 21, 3 678 1 11 . . . . . . . . . . . . 21, 11 678 2 6
126.96.36.199. Distributed MD with Extended NW Protocol
In this implementation, the new node picks the node with the least depth in its “normal neighborhood list” and use it as the parent. If there is a tie in the least depth, the node with the least load will be picked as the parent. The Logical ID, if used, is obtained from the “CON RES” messages as described in section 5.1.2.
188.8.131.52. Dedicated MD with Extended NW Protocol
The “normal neighborhood list” and the “Non-sync neighbor list” need to be made the same way as in section 184.108.40.206. The parent node should be picked from the “normal neighborhood list”. The procedure for picking the parent and obtaining the Logical ID is the same as in section 220.127.116.11.
5.1.4. Broadcast New Status
After picking a parent and/or obtaining a Logical ID, the new node needs to inform all of its neighbors its new status. These include new Logical ID, depth, load parameter, and/or parent's ID (needed in Extended NW Protocol without Logical Address option). Again, how this step can be implemented depends on which MD mode and which network layer protocol is used.
18.104.22.168. Distributed MD with Cluster Tree Protocol
In the Cluster Tree Protocol, the time between the processes described in sections 5.1.2 and 5.1.3 above can be long if the number of hops between the new node and the Cluster Head is large. Therefore, it is inefficient for the neighbors to stay in Rx mode and wait for the new node to broadcast its Logical ID.
22.214.171.124. Dedicated MD with Cluster Tree Protocol
In the Dedicated MD case, the procedure is almost the same as the Distributed MD case except the following:
In the “1st Hello” message, the Logical ID of the Dedicated MD in its area also needs to be added, in additional to the new node's Logical ID. The neighbors having the same MD as the new node, can add the new node to their “normal neighborhood lists”. Otherwise, the new node is added to their “Non-synchronized neighborhood lists”.
126.96.36.199. Distributed MD with Extended NW Protocol
In the Extended NW Protocol, the time between step 5.1.2 and step 5.1.3 is short due to the distributed nature in finding a parent and getting a Logical ID. The neighbors can just wait in Rx mode until the new node broadcasts a “1st Hello”. In U.S. patent application Ser. No. 09/803,259, “A Protocol for a Self-Organizing Network Using a Logical Spanning Tree Backbone”, filed Mar. 9, 2001, the “1st Hello” message is referred to as a “BroadcastZ” message. The timing diagram for this implementation is shown in
188.8.131.52. Dedicated MD with Extended NW Protocol
The only difference between this case and that described above in 184.108.40.206 is the following:
In the “1st Hello” message, the Logical ID of the Dedicated MD in its area also needs to be added, in additional to the new node's Logical ID. The neighbors, having the same MD as the new node, can add the new node to their “normal neighborhood lists”. Otherwise, the new node is added to their “Non-sync neighborhood lists”.
The new node and its neighbors will go to the Normal Operational Stage after completion of process described in section 5.1.4 above.
5.1.5. Summary of Set-Up Stage
A flow chart summarizing the set-up stage is shown in
At block 506, the symmetric links are confirmed. To confirm the links, the new node sends out an alarm message, informing any MD in its transmission range to suspend transmission for the next period. The new node follows this alarm message with a transmit period in which it will send a “Connection Request” (CON REQ) message to its neighbors during each of their corresponding Rx time. After receiving the “Connection Request” message from the new node, the neighbors will send a “Connection Response” (CON RES) message in their next transmit periods, thus confirming that a symmetric link is in place. In this “Connection Response” message, the neighboring nodes will send in their Logical ID, Next Rx/Tx time, Depth, and Load Parameter to the new node, allowing the neighborhood list to be updated.
After the neighborhood table is updated, at block 508, the new node will try to obtain a Logical ID and pick a parent. The procedure for this is highly dependent on the network layer protocol, as well as which MD mode (Dedicated MD or Distributed MD for example) the system is using. Various embodiments of the procedure are described above.
After picking a parent and/or obtaining a Logical ID, the new node needs to inform all of its neighbors its new status. The new status is broadcast at block 510. The status includes new Logical ID, depth, load parameter, and/or parent's ID (needed in Extended NW Protocol without Logical Address option). Again, the implementation of this step depends on the MD mode and the network layer protocol being used, and is described in more detail above.
The set-up stage is now complete and the set-up process terminates at block 512.
5.2. Normal Operational Stage
5.2.1. Updating Neighborhood Lists
The neighborhood list in each node needs to be updated periodically. During this period, a node needs to listen to all its neighbors, get their ID and Rx/Tx timing, and updates its neighborhood list. In its next Tx time, a node can also send out a “Hello” or “W” message to all its neighbors individually.
This routine is exactly the same as a MD operation. When a node is a MD, it will receive for a period of time. During this period, it will receive “Query” messages from its neighbors. These “Query” messages can be used as “W” or “Hello” messages and are used to update the MD's neighborhood list. During the next period, the MD is required to answer all these “Query” messages. The MD can use these reply messages as its own “Hello” messages to send to all of its neighbors.
220.127.116.11. Distributed MD
In the Distributed MD case, since the operation of updating a neighborhood list and being a MD is almost identical, every node will be a MD during the time when it needs to update its neighborhood list. In other words, the updating period for a node's neighborhood table is the same as the node's periodic MD period.
18.104.22.168. Dedicated MD
In the Dedicated MD case, all the nodes that are Dedicated MDs can update their neighborhood table at anytime. For the nodes that are not Dedicated MDs, each one has a “normal neighborhood list” and a “Non-sync neighborhood list”.
22.214.171.124.1. “Normal Neighborhood List”
The “normal neighborhood list” needs to be updated periodically. This can be done with the help of the Dedicated MD. When a member node needs to update its “normal neighborhood list”, it sends a “Req. Sync All” message to the Dedicated MD. The Dedicated MD then asks all nodes to synchronize with the member node for the next period. The member node can then broadcast a “Hello” message in its next Tx period. All nodes within both the member node's range and the Dedicated MD's range can hear this message, and update their neighborhood table accordingly. For the nodes that are in the Dedicated MD's range, but not in the member node's range (such as nodes 5, 8, 9, 10 in
If location information is available, a more efficient scheme can be used. If the Dedicated MD knows the location of all nodes in its range, then a member node only needs to send a “Hello” message to the Dedicated MD. The Dedicated MD can forward this “Hello” message to only the nodes that are within the member node's communication range. This saves the all the nodes from having to synchronize with the member node and listen for its “Hello” message in its next Tx period.
126.96.36.199.2. “Non-sync Neighborhood List”
For updating the “Non-sync neighborhood list”, the nodes need to switch to a temporary MD mode and check the status of all nodes in its “Non-sync neighborhood list”. Another option is to combine the Distributed and Dedicated MD scheme described below.
188.8.131.52. Combine Distributed with Dedicated MD
In the Dedicated MD case, if the location of the Dedicated MDs are not planned carefully ahead of time, there can be nodes in the network that are not covered by any Dedicated MDs, such as node B (CID=21, Node 5) and node A(CID=21, Node 11) in
The frequency in which the “Non-sync neighborhood list” needs to be updated depends on the network delay requirement and how often the network topology changes (how often nodes are added/deleted or move in/out of the network). This frequency requirement in turn will dictate how often nodes turn into MDs in the Distributed MD case, and how often the nodes turn into temporary MDs in the Dedicated MD case or the “combine Distributed with Dedicated MD” case.
5.2.2. Transmitting Normal Messages
If a node wants to talk to a neighbor, it will send a “Req. Sync” message to the MD, the MD will send an “Ack” back to the requester and relay the message to the corresponding node. This process is described in detail in “Mediation Device Operation”, Qicai Shi, Ed Callaway, Document IEEE 802.15-01/1880r0.
5.2.3. Summary of Normal Operation Stage
A flow chart summarizing the normal operation of a network node is shown in
At decision block 608, a check is made to determine if it is time to update the neighborhood list again. This check may be made explicitly by polling a timer or counter, or the check may be implicit, in which case the update is made in response to a timer event. When it is time to update the neighborhood list again, as depicted by the positive branch from decision block 608, flow returns to block 604. If it is not time to update the neighborhood list, as depicted by the negative branch from decision block 608, flow continues to decision block 610. If operation is not to be ended, as depicted by the negative branch from decision block 610, flow returns to block 606. If operation is to be ended, as depicted by the positive branch from decision block 610, normal operation ends at block 612.
5.3. Effect of MD's Rotation on the Network Layer
5.2.4. Dedicated MD Case
In the Dedicated MD case, the rotation of MD nodes is not random. Only the nodes that are Dedicated MDs turn into MD mode periodically. Normal nodes do not need to turn into MD mode periodically. Because of this, the “Non-sync neighborhood list” of normal nodes are not necessary updated periodically. Therefore the inactive links between the normal nodes and their “Non-sync neighborhood list” may not be reliable. To use these inactive links also requires one of the nodes becoming a temporary MD, thus using more energy than normal active links (links between a normal node and its “normal neighborhood list”). It is therefore advantageous to use only the active links in the network layer to route information. In this case, the inactive links are not used, and therefore do not need to be updated. However, this is only useful if these active links do not change often. If the Dedicated MDs rotate often, causing these active links to change often as well, the control traffic for updating the active links becomes large. This makes using active links only in the network layer inefficient.
5.2.4. Distributed MD Case
When the MDs rotate often, such as in the Distributed MD case, not keeping track of active and inactive links can be a more efficient solution. The active and inactive links should be treated as equal in the network layer to route information. In this case, a node needs to turn into MDs periodically to update the status of all its neighbors. In addition, a node should also turn into MD mode to deliver messages when its buffer overflows or when messages have been in its buffer for longer than a threshold period.
5.2.4. Unknown MD Type
When it is not known whether a network is using Dedicated MD or Distributed MD or when there is a combination of Distributed and Dedicated MDs in the network, the network layer needs to identify which nodes are Dedicated MDs and which are Distributed MDs and to adjust its use of active and inactive links accordingly.
In one embodiment of the invention, a check is made of the amount of time a “Non-sync neighbor” switches to a “normal neighbor”. If a node jumps between “Non-sync neighbor” and “normal neighbor” many times, then this indicates that the MDs are in the Distributed MD case and this “frequently jumping neighbor” should be in the “normal neighborhood list”. If a node stays as a “Non-sync neighbor” consistently, then this can indicate that the MDs are in Dedicated MD case. The inactive link with this neighbor should not be used in normal network operations. This solution requires every node to be in temporary MD mode periodically and exchange neighborhood list with the MD. This needs to be done in the beginning until the node finds out which MDs are Dedicated and which are not.
In a further embodiment of the invention, Dedicated MDs are provided with a special Logical ID, thereby enabling the normal nodes to identify them easily.
While this invention is susceptible of embodiment in many different forms, there is shown in the drawings and will herein be described in detail specific embodiments, with the understanding that the present disclosure is to be considered as an example of the principles of the invention and not intended to limit the invention to the specific embodiments shown and described. In the description below, like reference numerals are used to describe the same, similar or corresponding parts in the several views of the drawings.
Those of ordinary skill in the art will recognize that the present invention has been described in terms of exemplary embodiments based upon merging a Mediation Device Protocol with a Cluster Tree Protocol. However, the invention should not be so limited, since the present invention could be use to merge a Mediation Device Protocol with other network layer protocols.
While the invention has been described in conjunction with specific embodiments, it is evident that many alternatives, modifications, permutations and variations will become apparent to those of ordinary skill in the art in light of the foregoing description. Accordingly, it is intended that the present invention embrace all such alternatives, modifications and variations as fall within the scope of the appended claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US4313036||Feb 19, 1980||Jan 26, 1982||Rolm Corporation||Distributed CBX system employing packet network|
|US5079767||Aug 25, 1989||Jan 7, 1992||Digital Equipment Corporation||Method of multicast message distribution|
|US5128938||Mar 6, 1991||Jul 7, 1992||Motorola, Inc.||Energy saving protocol for a communication system|
|US5241542||Aug 23, 1991||Aug 31, 1993||International Business Machines Corporation||Battery efficient operation of scheduled access protocol|
|US5278831||Jul 7, 1992||Jan 11, 1994||U.S. Philips Corporation||Information transmission system|
|US5371734||Jan 29, 1993||Dec 6, 1994||Digital Ocean, Inc.||Medium access control protocol for wireless network|
|US5418835||Oct 26, 1992||May 23, 1995||Motorola Inc.||Method of delivering paging messages using voice mail|
|US5533100||Jul 29, 1994||Jul 2, 1996||At&T Corp.||Communications system call complete arrangement|
|US5590396||Apr 20, 1994||Dec 31, 1996||Ericsson Inc.||Method and apparatus for a deep-sleep mode in a digital cellular communication system|
|US5740366||Feb 28, 1995||Apr 14, 1998||Norand Corporation||Communication network having a plurality of bridging nodes which transmit a beacon to terminal nodes in power saving state that it has messages awaiting delivery|
|US5778052||Feb 23, 1996||Jul 7, 1998||At&T Corp.||Method and system for storing messages for later forwarding|
|US5797094||Jun 26, 1997||Aug 18, 1998||Telefonaktiebolaget L M Ericsson (Publ)||Method and apparatus for supporting the delivery of short message service messages to sleeping mobile stations in a cellular communications system|
|US5845204||Aug 11, 1995||Dec 1, 1998||Rockwell International Corporation||Method and apparatus for controlling the wakeup logic of a radio receiver in sleep mode|
|US5850592||Jan 11, 1996||Dec 15, 1998||Gte Internetworking Incorporated||Method for self-organizing mobile wireless station network|
|US5940771||Oct 19, 1995||Aug 17, 1999||Norand Corporation||Network supporting roaming, sleeping terminals|
|US5943397||Feb 10, 1997||Aug 24, 1999||At&T||Network assisted callback system|
|US5991287||Dec 30, 1996||Nov 23, 1999||Lucent Technologies, Inc.||System and method for providing seamless handover in a wireless computer network|
|US6044069||Oct 29, 1997||Mar 28, 2000||Conexant Systems, Inc.||Power management system for a mobile station|
|US6047200||Dec 30, 1998||Apr 4, 2000||At&T Wireless Services||Remote wireless unit having reduced power operating mode|
|US6055561 *||Sep 30, 1997||Apr 25, 2000||International Business Machines Corporation||Mapping of routing traffic to switching networks|
|US6058289||Sep 26, 1995||May 2, 2000||Pacific Communication Sciences, Inc.||Method and apparatus for low power mobile unit for cellular communications system|
|US6134599||Apr 18, 1998||Oct 17, 2000||Sun Microsystems, Inc.||System and method for organizing devices in a network into a tree using suitability values|
|US6138019||Dec 11, 1996||Oct 24, 2000||Cisco Systems, Inc.||Cellular system hand-off protocol|
|US6192230||Sep 27, 1993||Feb 20, 2001||Lucent Technologies, Inc.||Wireless data communication system having power saving function|
|US6205122||Apr 2, 1999||Mar 20, 2001||Mercury Interactive Corporation||Automatic network topology analysis|
|US6208623||Apr 13, 1998||Mar 27, 2001||3Com Corporation||Method of combining PNNI and E-IISP in an asynchronous transfer mode network|
|US6259772||Feb 26, 1998||Jul 10, 2001||British Telecommunications Plc||Message delivery system with special features|
|US6269404 *||Jan 5, 1999||Jul 31, 2001||3Com Corporation||Virtual network architecture for connectionless LAN backbone|
|US6285892||Nov 24, 1998||Sep 4, 2001||Philips Electronics North America Corp.||Data transmission system for reducing terminal power consumption in a wireless network|
|US6304556||Aug 24, 1998||Oct 16, 2001||Cornell Research Foundation, Inc.||Routing and mobility management protocols for ad-hoc networks|
|US6351522||Jun 7, 1996||Feb 26, 2002||Nokia Telecommunications Oy||Method for providing a delivery confirmation of message deliveries made in a telephone network|
|US6353596 *||Apr 12, 1996||Mar 5, 2002||Lucent Technologies Inc.||System and method for multipoint-to-multipoint multicasting|
|US6356538||Mar 30, 1998||Mar 12, 2002||Oki Telecom, Inc.||Partial sleep system for power savings in CDMA wireless telephone devices|
|US6370146||Jun 29, 1998||Apr 9, 2002||Lucent Technologies Inc.||Method and apparatus for non-disruptive addition of a new node to an inter-nodal network|
|US6377987||Apr 30, 1999||Apr 23, 2002||Cisco Technology, Inc.||Mechanism for determining actual physical topology of network based on gathered configuration information representing true neighboring devices|
|US6385174||Nov 6, 2000||May 7, 2002||Itt Manufacturing Enterprises, Inc.||Method and apparatus for transmission of node link status messages throughout a network with reduced communication protocol overhead traffic|
|US6385201||Apr 29, 1998||May 7, 2002||Nec Corporation||Topology aggregation using parameter obtained by internodal negotiation|
|US6418299||Sep 9, 1998||Jul 9, 2002||Bbn Corporation||Self-organizing mobile wireless station network|
|US6456599||Feb 7, 2000||Sep 24, 2002||Verizon Corporate Services Group Inc.||Distribution of potential neighbor information through an ad hoc network|
|US6457048||Mar 7, 2001||Sep 24, 2002||Sun Microsystems, Inc.||System for representing device topology in a computer network operable independent of network management software|
|US6473408 *||May 19, 1999||Oct 29, 2002||3Com Corporation||Building a hierarchy in an asynchronous transfer mode PNNI network utilizing proxy SVCC-based RCC entities|
|US6493759||Jul 24, 2000||Dec 10, 2002||Bbnt Solutions Llc||Cluster head resignation to improve routing in mobile communication systems|
|US6636499||Dec 2, 1999||Oct 21, 2003||Cisco Technology, Inc.||Apparatus and method for cluster network device discovery|
|US6694361||Jun 30, 2000||Feb 17, 2004||Intel Corporation||Assigning multiple LIDs to ports in a cluster|
|US6791949||Apr 28, 2000||Sep 14, 2004||Raytheon Company||Network protocol for wireless ad hoc networks|
|US6816460||Mar 14, 2000||Nov 9, 2004||Lucent Technologies Inc.||Location based routing for mobile ad-hoc networks|
|US6829222||Apr 24, 2001||Dec 7, 2004||Board Of Regents The University Of Texas System||Clusterhead selection in wireless ad hoc networks|
|US6836463||Oct 15, 1999||Dec 28, 2004||Nokia Corporation||System for communicating labeled routing trees to establish preferred paths and source routes with local identifiers in wireless computer networks|
|US6845091||Dec 1, 2000||Jan 18, 2005||Sri International||Mobile ad hoc extensions for the internet|
|US6876643||Aug 8, 2000||Apr 5, 2005||International Business Machines Corporation||Clustering in wireless ad hoc networks|
|US6889254 *||Mar 30, 1999||May 3, 2005||International Business Machines Corporation||Scalable merge technique for information retrieval across a distributed network|
|US6973053||Sep 12, 2000||Dec 6, 2005||Bbnt Solutions Llc||Using direct cluster member to cluster member links to improve performance in mobile communication systems|
|US6982960 *||Mar 9, 2001||Jan 3, 2006||Motorola, Inc.||Protocol for self-organizing network using a logical spanning tree backbone|
|US20020018488||Feb 1, 2001||Feb 14, 2002||Kazuhiro Ohnuma||Transmission equipment having interface conversion function|
|US20020031131 *||Feb 1, 2001||Mar 14, 2002||Yechiam Yemini||Method and apparatus for the exchange of data between a dynamically addressed network and a foreign network|
|US20020163889 *||Feb 1, 2001||Nov 7, 2002||Yechiam Yemini||Method and apparatus for providing services on a dynamically addressed network|
|US20020169846||Mar 27, 2002||Nov 14, 2002||Chen Priscilla L.||Method and apparatus for a communication network with nodes capable of selective cluster head operation|
|1||Boukerche, A., A Simulation Based Study of On-Demand Routing Protocols for Ad hoc Wireless Networks, Simulation Symposium, 2001, Proceedings, 34<SUP>th </SUP>Annual, Apr. 22-26, 2001, pp. 95-92.|
|2||Chatterjee, M., An On-Demand Weighted Clustering Algorithm (WCA) for Ad hoc Networks, Global Telecommunications Conference, 2000, GLOBECOM '00, IEEE vol. 3, Nov. 27-Dec. 1, 2000, pp. 1697-1701.|
|3||Gerla, M., Multicluster, Mobile, Multimedia Radio Network, Wireless Networks 1 (1995) pp. 255-265.|
|4||Jiandong, L., An Adaptive Cluster Algorithm for a Self-Organizing Communication Network, Global Telecommunications Conference, 1988, Nov. 28-Dec. 1, 1988, Conference Record, GLOBECOM '88, IEEE, vol. 3, pp. 1653-1656.|
|5||Lee, W.C., Topology Agregation for Hierarchical Routing in ATM Netowrks, Computer Communication Review, vol. 25, No. 2, Apr. 1995, pp. 82-92, ACM Press.|
|6||Lin, H., A Clustering Technique for Large Multihop Mobile Wireless Networks, Vehicular Technology Conference proceedings, 2000 IEEE 51<SUP>st</SUP>, vol. 2., pp. 1545-1549.|
|7||Yong-Xi, F., A Clustering Algorithm Applied to the Network Management on Mobile Ad hoc Network, Info-tech and Info-net, 2001, Proceedings, ICii 2001, vol. 2, pp. 626-631.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7392053 *||Apr 8, 2003||Jun 24, 2008||Intel Corporation||Method and apparatus for selective listening in a dynamically configured wireless network|
|US7477612 *||Jan 27, 2003||Jan 13, 2009||Broadcom Corporation||Topology discovery process and mechanism for a network of managed devices|
|US7542459||Apr 26, 2002||Jun 2, 2009||Intel Corporation||Ad hoc network having a back-bone determined at least in part on a metric and method therefore|
|US7650405 *||Sep 29, 2005||Jan 19, 2010||Rockwell Automation Technologies, Inc.||Tracking and tracing across process boundaries in an industrial automation environment|
|US7672737||Mar 2, 2010||Rockwell Automation Technologies, Inc.||Hierarchically structured data model for utilization in industrial automation environments|
|US7676281||Mar 9, 2010||Rockwell Automation Technologies, Inc.||Distributed database in an industrial automation environment|
|US7809683||Sep 29, 2005||Oct 5, 2010||Rockwell Automation Technologies, Inc.||Library that includes modifiable industrial automation objects|
|US7899027 *||Aug 26, 2005||Mar 1, 2011||Cisco Technology, Inc.||Automatic route configuration in hierarchical wireless mesh networks|
|US7984039 *||Jul 14, 2005||Jul 19, 2011||International Business Machines Corporation||Merging of results in distributed information retrieval|
|US8185112 *||Nov 8, 2007||May 22, 2012||Motorola Mobility, Inc.||Cellular wireless communication device and method for managing the receipt of a handover command|
|US8307112||Jul 30, 2004||Nov 6, 2012||Cloudsoft Corporation Limited||Mediated information flow|
|US8437280 *||Mar 24, 2008||May 7, 2013||Tr Technologies Inc.||Distributed synchronous batch reconfiguration of a network|
|US8484401||Apr 15, 2010||Jul 9, 2013||Rockwell Automation Technologies, Inc.||Systems and methods for conducting communications among components of multidomain industrial automation system|
|US8499061 *||Feb 16, 2005||Jul 30, 2013||Thomson Licensing||Method for inserting a new device in a community of devices|
|US8645514 *||May 8, 2006||Feb 4, 2014||Xerox Corporation||Method and system for collaborative self-organization of devices|
|US8655995 *||Jan 13, 2009||Feb 18, 2014||Whirlpool Corporation||Home network commissioning|
|US8799800||Sep 29, 2005||Aug 5, 2014||Rockwell Automation Technologies, Inc.||Automatic user interface generation|
|US8812729||Apr 26, 2012||Aug 19, 2014||Cloudsoft Corporation Limited||Self-managed distributed mediation networks|
|US8984533||Apr 15, 2010||Mar 17, 2015||Rockwell Automation Technologies, Inc.||Systems and methods for conducting communications among components of multidomain industrial automation system|
|US9100247||Apr 10, 2013||Aug 4, 2015||Tr Technologies Inc.||Distributed synchronous batch reconfiguration of a network|
|US20050044268 *||Jul 30, 2004||Feb 24, 2005||Enigmatec Corporation||Self-managed mediated information flow|
|US20050060380 *||Jul 30, 2004||Mar 17, 2005||Enigmatec Corporation||Mediated information flow|
|US20060215582 *||Aug 26, 2005||Sep 28, 2006||Cisco Technology, Inc.||Automatic route configuration in hierarchical wireless mesh networks|
|US20060259154 *||Sep 30, 2005||Nov 16, 2006||Rockwell Automation Technologies, Inc.||Hierarchically structured data model for utilization in industrial automation environments|
|US20060259160 *||Sep 29, 2005||Nov 16, 2006||Rockwell Automation Technologies, Inc.||Distributed database in an industrial automation environment|
|US20070016574 *||Jul 14, 2005||Jan 18, 2007||International Business Machines Corporation||Merging of results in distributed information retrieval|
|US20070064721 *||Oct 19, 2006||Mar 22, 2007||Nokia Inc.||System and method for transmission scheduling using network membership information and neighborhood information|
|US20070198673 *||Feb 16, 2005||Aug 23, 2007||Olivier Heen||Method for inserting a new device in a community of devices|
|US20070260716 *||May 8, 2006||Nov 8, 2007||Shanmuga-Nathan Gnanasambandam||Method and system for collaborative self-organization of devices|
|US20080160989 *||Nov 8, 2007||Jul 3, 2008||Motorola, Inc.||Cellular wireless communiction device and method for managing the receipt of a handover command|
|US20080232274 *||Mar 24, 2008||Sep 25, 2008||Telecommunications Research Laboratories||Distributed synchronous batch reconfiguration of a network|
|US20090154420 *||Jun 24, 2008||Jun 18, 2009||Samsung Electronics Co., Ltd.||Method of and apparatus for managing neighbor node having similar characteristic to that of active node and computer-readable recording medium having recorded thereon program for executing the method|
|US20100180019 *||Jul 15, 2010||Whirlpool Corporation||Home network commissioning|
|WO2006124513A2 *||May 11, 2006||Nov 23, 2006||Rockwell Automation Tech Inc||Tracking and tracing across process boundaries in an industrial automation environment|
|WO2006124513A3 *||May 11, 2006||Apr 16, 2009||Rockwell Automation Tech Inc||Tracking and tracing across process boundaries in an industrial automation environment|
|WO2013049113A1 *||Sep 26, 2012||Apr 4, 2013||Schneider Electric USA, Inc.||Automated device discovery on a network|
|U.S. Classification||370/256, 370/432, 709/252, 709/220, 370/469, 370/408|
|International Classification||H04L12/28, H04L12/56, H04J3/06, G06F15/16, H04J3/16, H04L29/12|
|Cooperative Classification||H04L29/12254, H04L45/02, H04L61/2038, H04L45/026, H04J3/0638, H04L45/26|
|European Classification||H04L61/20B, H04L45/02, H04L45/02D, H04L45/26, H04L29/12A3B|
|Dec 18, 2001||AS||Assignment|
Owner name: MOTOROLA, INC., ILLINOIS
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:CHEN, PRISCILLA;MAEDA, MASAHIRO;CALLAWAY, EDGAR H. JR;AND OTHERS;REEL/FRAME:012396/0778;SIGNING DATES FROM 20011211 TO 20011212
|Dec 28, 2010||FPAY||Fee payment|
Year of fee payment: 4
|Apr 6, 2011||AS||Assignment|
Owner name: MOTOROLA SOLUTIONS, INC., ILLINOIS
Free format text: CHANGE OF NAME;ASSIGNOR:MOTOROLA, INC;REEL/FRAME:026081/0001
Effective date: 20110104
|Dec 29, 2014||FPAY||Fee payment|
Year of fee payment: 8