Hierarchical mobile ad-hoc network and methods for performing reactive routing therein
Abstract
This record has no abstract on file.
Term
Term ended
Expired 28 April 2023, 3.4 years ago.
- Priority
- Filed
- Granted
- Expired
- Today
12 claims: 5 independent, 7 dependent
- 1複数のノードと該複数のノードと接続する複数の無線リンクとを有するモバイル・アドホック・ネットワークにおいてデータを送信する方法であって、 上記複数のノードをノードのクラスターにクループ化し、 クラスター毎にクラスター・リーダー・ノードを指定し、 送り元クラスターの送り元ノードから送り元クラスターのクラスター・リーダー・ノードへとクラスターレベル・ルート要求を送信し、 上記クラスター・リーダー・ノード間で指定された通信リンクを決定し、上記指定された通信リンクを介して、送り元クラスターのクラスター・リーダー・ノードから残されたクラスター・リーダーへクラスター・リーダー・ノード要求を送信し、上記クラスター・リーダー・ノード・ルート要求の配信ルートに沿って送り先クラスターのクラスター・リーダー・ノードから送り元クラスターのクラスター・リーダー・ノードへとクラスター・リーダー・ノード・ルート返信を送り返すことによって、 上記送り元クラスターと上記クラスターレベル・ルート要求に応じた送り先ノードを有し、複数の上記クラスター・リーダー・ノードを使用する送り先クラスターとの間のクラスターレベル・ルートを決定し、 送り元ノードからクラスターレベル・ルートを使用する送り先ノードへとデータを転送する方法。
- 2請求項1記載の方法であって、 グループ化することは、ノードからクラスターの対応するクラスター・リーダー・ノードへのホップ数に基づいてノードをクラスターへグループ化することを有する方法。
- 3請求項1記載の方法であって、 グループ化することは、クラスター内の少なくとも1つのノードへの経路に関連付けられるパス・メトリックに基づいてノードをクラスターへとグループ化することを有する方法。
- 4請求項3記載の方法であって、 パス・メトリックは、遅延、帯域幅、及び利用可能性のうち少なくとも1つを有する方法。
- 5請求項1記載の方法であって、 グループ化することは、クラスターからのホップ数内での該クラスターからのノード数に基づいてノードをクラスターへとグループ化することを有する方法。
- 6請求項1記載の方法であって、 クラスター毎にクラスター・リーダー・ノードを指定することは、リンク可能性、移動性、及び利用可能性のうち少なくとも1つを有する方法。
- 7請求項1記載の方法であって、 少なくとも送り元クラスター・リーダー・ノードと送り先クラスター・リーダー・ノードとを有する複数のクラスター・リーダー・ノードをリーダー・ノード・クラスターへグループ化し、該リーダー・ノード・クラスター内において、送り元クラスターのクラスター・リーダー・ノードから送り先クラスターのクラスター・リーダー・ノードへの高いレベルのルートを決定する複数のクラスター・リーダー・ノードをグループ化することを更に有し、 上記クラスターレベル・ルートは、上記高いレベルのルートに沿って対応するクラスター・リーダー・ノードを持つクラスターを少なくとも有する方法。
- 8請求項 7 記載の方法であって、 各クラスター・リーダー・ノードは、隣接するクラスター・リーダー・ノードのアドレスを格納し、クラスター・リーダー・ノード・ルート要求を送信することは、各クラスター・リーダー・ノードからその隣接するクラスター・リーダー・ノードへと該クラスター・リーダー・ノード・ルート要求を送信することを有する方法。
- 9請求項1記載の方法であって、 転送することは、 (a)クラスターレベル・ルートに沿って次のクラスター内のクラスター目標ノードを指定し、 (b)データが現在位置しているノードからクラスター目標ノードへとノードレベル・ルートを決定し、 (c)ノードレベル・ルートを介して、データが現在位置しているノードからクラスター目標ノードへとデータを転送し、 (d)データが送り先クラスターに対する送り先クラスター目標ノードに到達するまで、ステップ(a)から(c)を繰り返し、 (e)送り先クラスター目標ノードから送り先ノードへのノードレベル・ルートを決定し、 (f)ステップ(e)にて確立されたノードレベル・ルートを介して、送り先クラスター目標ノードから送り先ノードへデータを転送することを有する方法。
- 10各クラスターは指定されたクラスター・リーダー・ノードを持っていて、ノードのクラスターへクループ化された複数のノードと、 上記複数のノードに接続する複数の無線リンクと 、 上記クラスター・リーダー・ノードと接続する指定された通信リンクと を有し、 上記複数のノードは、 送り元クラスターの送り元ノードから該送り元ノードのクラスター・リーダー・ノードへとクラスターレベル・ルート要求を送信することによって、それらの間でデータ転送し、 上記指定された通信リンクを介して、上記送り元クラスターの上記クラスター・リーダー・ノードから残されたクラスター・リーダーへとクラスター・リーダー・ノード・ルート要求を送信し、また、該クラスター・リーダー・ノード・ルート要求を配信ルートに沿って、上記送り元クラスターの上記クラスター・リーダー・ノードから上記送り元クラスターの上記クラスター・リーダー・ノードへとクラスター・リーダー・ノード・ルート返信を送り返すことによって、 上記送り元クラスターと、上記クラスターレベル・ルート要求に応じた送り元ノードを有し、複数の上記クラスター・リーダー・ノードを使用する送り先クラスターとの間でクラスターレベル・ルートを決定し、 クラスターレベル・ルートを用いて、上記送り元ノードから上記送り先ノードへとデータを転送することを有するモバイル・アドホック・ネットワーク。
- 11請求項 10 記載のモバイル・アドホック・ネットワークであって、 各クラスター・リーダー・ノードは、隣接するクラスター・リーダー・ノードのアドレスを格納し、 クラスター・リーダー・ノード・ルート要求が各クラスター・リーダー・ノードからその隣接するクラスター・リーダー・ノードへとクラスター・リーダー・ノード・ルート要求を送信することによって送信されるモバイル・アドホック・ネットワーク。
- 12請求項 11 記載のモバイル・アドホック・ネットワークであって、 各クラスター・リーダー・ノードは、その隣接するクラスター・リーダー・ノードへ周期的に問い合わせをして、該クラスター・リーダー・ノードの現在のアドレスを維持するモバイル・アドホック・ネットワーク。
Independent claims12
105 paragraphs, as filed
The present invention relates to the field of communication networks, in particular to mobile ad hoc wireless networks and methods thereof.
Wireless networks have undergone growing development over the last decade. One of the most restfully developed areas is mobile ad hoc networks. Physically, mobile ad hoc networks have the potential of many locally distributed mobile nodes that share a common wireless channel. Compared to other types of networks such as cellular networks and satellite networks, the most striking feature of mobile ad hoc networks is the lack of any well-established structural foundation. Networks are made up of mobile nodes only and are created "in the air" for nodes to transfer and receive from other nodes. The network is independent of any particular node and dynamically coordinates when some nodes join or others say apart.
These unique features require a routing protocol to define the data flow within an ad hoc network that can adapt to frequent topology changes. Two basic categories of ad hoc routing have emerged in recent years, primarily reactive or "on-demand" protocols, and proactive or table-driven protocols. The reactive protocol is requested to the destination in response to the route request. Examples of reactive protocols include ad hoc on-demand distance vector (AODV) routing, dynamic source routing (DSR), and temporary order routing algorithm (TORA).
Proactive routing protocols, on the other hand, seek to keep up-to-date, consistent information from each node in the network to other nodes. Such protocols generally require each node to hold one or more tables for storing routing information, by spreading updates throughout the network to maintain a consistent view of the network. Responds to changes in the network topology. Examples of such proactive routing protocols are the Destination Sequence Distance Vector (DSDV) routing and Radio Routing Protocol (WRP) disclosed in Perkins U.S. Pat. Nos. 5,412,654. , And includes Cluster Head Gateway Switch Routing (CGSR). A hybrid protocol that uses both proactive and reactive approaches based on distance from the source node is the Zone Routing Protocol (ZRP) disclosed in Haas U.S. Pat. Nos. 6,304,556. ..
One challenge to advancing ad hoc network development is to extend such networks to accommodate a large number of nodes. In one prior art, Optimal Spine Routing (OSR) disclosed by Das et al. In "Routing in Ad-Hoc Networks using Minimum Connected Dominating Sets", IEEE Int. Conf. On Commun. (ICC '97), 1997. Attempts have been made to utilize "spine" routing, such as the method. In this approach, the spine or "virtual backbone" is defined so that each network node has only one hop from the spine node. The overall topology (link state) is maintained at each spine node, and the link state routing algorithm is run at each spine node to generate the current route to each destination.
Other related techniques are cluster spines disclosed by Das et al. In "Routing in Ad-Hoc Networks using a Spine", IEEE Int. Conf. On Computer Commun. And Networks (IC3N '97), 1997. It is routing. This technique seeks to extend the adaptability of spine routing to larger network sizes by grouping the nodes in the cluster and by adding a second layer level to the OSR approach. Another method is known as Partial Knowledge Spines Routing (PSR) disclosed by Sivakumar et al. In "The Clade Vertebrata: Spines and Routing in Ad-Hoc Networks", IEEE Symposium On Computer and Commun., 1998. ing.
One common feature of each of the prior art cluster / spine methods described above is that they each rely on proactive routing. One potential drawback of proactive routing is that it generally requires a significant amount of routing overhead to always maintain the best route to all destinations. This problem is especially acute when adapted to ad hoc networks with a very large number of nodes.
<p> In view of the background art described above, the present invention provides a method for transmitting data in an ad hoc network that is particularly well suited for networks with a relatively large number of nodes and has root error recovery. The purpose is to do.</p><p> The above and other purposes, features, and effects according to the present invention are provided by a method of transmitting data in a mobile ad hoc network having a plurality of nodes and a plurality of wireless links connecting the plurality of nodes. The method may be to group the plurality of nodes into a cluster of nodes and specify a cluster leader node for each cluster. In addition, cluster-level route requests may be sent from the source node of the source cluster to the cluster leader node of the source cluster. The method may also determine a cluster-level route between a source cluster and a destination cluster that has a destination node in response to the cluster-level route request and uses multiple cluster leader nodes. .. In addition, data may be transferred from the source node to the destination node using the cluster level route.<u style="single">The method is to determine the cluster level route, the specified communication link may be determined between the cluster leader nodes. In addition, the cluster leader node request is sent over the specified communication link from the cluster leader node of the source cluster to the remaining cluster leader, and the cluster leader node root reply. May be sent back from the cluster leader node of the destination cluster to the cluster leader node of the source cluster along the delivery route of the cluster leader node route request.</u></p><p> In particular, nodes may be grouped into clusters based on the number of hops from the node to the corresponding cluster leader node of the cluster. That is, for example, a node may be associated with a cluster such that the cluster leader has the minimum number of hops. In addition, grouping may be grouped into a cluster based on the path metric associated with the route to at least one node in the cluster, with the path metric being delay, bandwidth, and available. It may have at least one of the sexes. Nodes may also be grouped into clusters based on the number of nodes from the cluster within the number of hops from the cluster. That is, the nodes may be grouped, for example, into a cluster with the maximum number of nodes within a certain number of hops.</p><p> The cluster leader node for each cluster may be specified based on the number of nodes within a predetermined number of hops. That is, for example, the node having the most nodes within a certain number of hops may be designated as the cluster leader node. Further, for example, cluster leader nodes may be specified based on node metrics such as linkability, mobility, and / or availability.</p><p> In addition, the method may also include grouping multiple cluster leader nodes with at least a source cluster leader node and a destination cluster leader node into a leader node cluster. .. Leader node clusters are at a higher level from the cluster leader node of the source cluster within the leader node cluster, which is in turn used to determine the cluster level route, to the cluster leader node of the destination cluster. It may favorably provide convenient criteria for determining the route. That is, a cluster-level route may have at least a cluster with corresponding cluster leader nodes along the higher-level route. In particular, high-level routes may be determined using, for example, dynamic source routing (DSR) or ad hoc on-demand distance vector (AODV) routing.</p><p> In particular, at least one of the specified communication links may include nodes that are not cluster leader nodes. That is, one or more designated communication links may include intermediate nodes that are not cluster target nodes and are connected to cluster target nodes. In addition, each cluster leader node stores the address of the adjacent cluster leader node, and each cluster leader node sends a cluster leader node root request. A cluster leader node root request may be sent from a node to its adjacent cluster leader node. In addition, the adjacent cluster leader node may be periodically inquired to maintain the current address.</p><p> In addition, the delivery route may have a minimum number of cluster leader nodes between the cluster leader nodes of the source and destination clusters. That is, a cluster-level route request may be received by the cluster leader node via one or more routes, but the delivery route may be one that has a minimum number of "hops" by route. good. Other path metrics such as delay, linkability, and availability may help determine the best route.</p><p> In addition, transferring data can (a) specify a cluster target node in the next cluster along the cluster-level route, and (b) node-level from the node where the data is currently located to the cluster target node. Determine the route, (c) transfer the data from the node where the data is currently located to the cluster target node via the node-level route, and (d) the data reaches the destination cluster target node for the destination cluster. Repeat steps (a) to (c) until (e) determine the node-level route from the destination cluster target node to the destination node, and (f) determine the node-level route established in step (e). It may have to transfer data from the destination cluster target node to the destination node via. In addition, steps (b) and (e) may be performed using, for example, DSR or AODV. In addition, data does not necessarily have to be forwarded through at least one of the cluster leader nodes along the cluster-level route, thus allowing excessive traffic on at least one cluster leader node. Promote mitigation.</p><p> Mobile ad hoc networks are also provided in accordance with the present invention, where each cluster has a designated cluster leader node and connects to multiple nodes grouped into a cluster of nodes and to the multiple nodes described above. It may have a plurality of wireless links.<u style="single">To determine the cluster-level route, the specified communication link may be determined between the cluster leader nodes.</u>The plurality of nodes described above are cluster-level routes from the source node of the source cluster to the cluster leader node of the source node.<u style="single">To</u>Data may be sent between them by sending requests. In addition, cluster-level routes<u style="single">A cluster leader node root request is sent from the cluster leader node of the source cluster to the remaining cluster leader over the specified communication link, and the cluster leader node root request is also sent. By sending back a cluster leader node route reply from the cluster leader node of the source cluster to the cluster leader node of the source cluster along the delivery route.</u>It may be determined between a source cluster and a destination cluster that has a source node that responds to the cluster-level route request and uses a plurality of the cluster leader nodes. Data may be transferred from the source node to the destination node using a cluster-level route.</p>
The present invention will be described in detail below with reference to the accompanying drawings showing the best examples. However, the present invention can be embodied in several different forms and should not be construed to be confined to the examples presented herein. Rather, these examples are provided to complete through this disclosure and to fully convey the scope of the invention to those skilled in the art. Throughout, the symbols refer to the elements, and the main and numerous major notations are used to indicate similar elements in selective embodiments.
First referring to FIG. 1, the mobile ad hoc network 10 according to the present invention exemplifies having a plurality of nodes 11 connected by a wireless communication link 13. Node 11 is a wireless communication device capable of communicating within a wireless ad hoc network, such as a computer equipped with a wireless modem, personal data assist (PDAs), etc., as will be understood by those skilled in the art. Any suitable type of. Of course, it will be understood that it is certain that node 11 may be optionally connected to the fixed communication structure infrastructure if desired.
According to the present invention, the nodes 11 are preferably grouped into clusters 12, which are exemplified in FIG. 1 by circles surrounding each group of nodes. The grouping of nodes 11 into cluster 12 is described in more detail below. For each of the clusters 12, one of those nodes 11 is designated as each of the cluster leader nodes 21-33. The processing and functions for designating the cluster leader nodes 21 to 33 are further described below. For clarity, here, when cluster 12 is described individually, a particular cluster is referenced by its corresponding cluster leader node reference number. For example, the cluster leader node 21 is in cluster 21 and so on.
The method for transmitting data in the ad hoc network according to the present invention will be described with reference to the flow charts of FIGS. 4 to 6. The method is initiated by grouping node 11 into cluster 12 at block 41 (block 40). Various techniques may be used to group the nodes 11 in the cluster 12. In general, preferably, the decision to cluster and the choice of cluster leader are based on generalized metrics with parameters selected to meet specific network requirements, as understood by those skilled in the art. Is based.
As an example, cluster 12 may be selected for nodes 11 to join based on the cluster relevance metric. This metric may be calculated for each potential cluster 12 associated with node 11 or may be based on how well the node is "suitable" for that cluster. The cluster relevance metric can also be as simple as the hop count metric, where the hop count is calculated for the route to the cluster leader node. In this simple case, the node will be associated with the closest cluster leader node in the hop count.
Other metrics are, for example, k<sub>N</sub>Path metric to all cluster members in a hop, k<sub>N</sub>Different measurements such as the number of cluster members in a hop, the path metric to the cluster leader, and / or the cluster leader metric may be considered. There are several ways in which these measurement methods can be combined to create an integrated metric for cluster relevance. As an example, a metric for a node to associate with a cluster leader node m
<maths num="1"><img file="JP4087380B2_D0001.tif" /></maths>The weighted sum to calculate
<maths num="2"><img file="JP4087380B2_D0002.tif" /></maths>Is calculated as. Where n<sub>m</sub>Is in cluster m<sub>N</sub>The number of nodes in the hop neighborhood
<maths num="3"><img file="JP4087380B2_D0003.tif" /></maths>Is the path metric to the i-th node in its neighborhood,
<maths num="4"><img file="JP4087380B2_D0004.tif" /></maths>Is the path metric to the cluster leader node m,
<maths num="5"><img file="JP4087380B2_D0005.tif" /></maths>Is the cluster leader metric, and a, b, and c are parameters tailored to the network requirements. Of course, other suitable techniques may be used as understood by those skilled in the art.
The above parameters allow a compromise in the relevance between the selection of cluster leader nodes 21-33 with the smallest path metric to as many nodes 11 in the cluster as possible. Node 11 is the smallest cluster relevance metric as a leader for joining
<maths num="6"><img file="JP4087380B2_D0006.tif" /></maths>Select the cluster leader nodes 21-33 that have. In addition, the hop count limit is the limit L for the number of nodes per cluster.<sub>CL</sub>Like the cluster leader node hop K<sub>C</sub>It may be established to require a new cluster that should be within.
The path metric used in the above calculation may be any other suitable method as understood by those skilled in the art, but as a node or link metric, for example, hop count, delay, availability. May include one or more components such as, node durability, and / or link durability. The path metric may also be calculated as a weighted sum of link and node metric components along the path.
If the cluster relevance metric is not within certain limits, node 11 chooses to become the cluster leader node and form a new cluster 12 at block 42. At this time, in the selection of the cluster leader, the K<sub>N</sub>May conflict near hops. Other metrics, cluster leader metrics, may be used for this purpose. In general, the cluster leader metric is that node 11 is its K.<sub>N</sub>It is based on how well the cluster leader node's tasks are performed near the hop.
More specifically, cluster leader metrics take one of several forms. K<sub>N</sub>It can be as simple as the number of nodes achievable in the hop neighborhood. However, additional components to the metric are described in one application. A cluster leader is preferably "durable" from the point of view of its operation as a cluster leader, i.e., rather than intermittently choosing between power-up and sleep mode. Intermittent operation of cluster leader nodes is likely to cause destructive behavior in hierarchical topologies, as will be appreciated by those skilled in the art.
Therefore, node 11 claiming to be the cluster leader is, for example, K.<sub>N</sub>The number of nodes achievable within the hop neighborhood, the path metric to these nodes, the path metric to adjacent cluster nodes 21-33, the total linkability of the center points, the node durability, and the relative nodes. Cluster leader metric with one or more components such as mobility
<maths num="7"><img file="JP4087380B2_D0007.tif" /></maths>To calculate. Of course, other metric components understood by those skilled in the art may be used. For a given network application, the cluster leader metric will apply to the cluster relevance metric as understood by those skilled in the art in a manner equivalent to the example in equation (1) above. Formed as an appropriate combination of these components required for.
As further described below, each cluster leader node 21-33 periodically makes a cluster leader node announcement (CLNANN) (eg, n).<sub>CL</sub>Broadcast (with hop transmission restrictions). This message transmission limit is such that all cluster members can be reached, as well as the cluster leader nodes of all adjacent clusters. This message notifies the node as a cluster leader node and contains the cluster leader metric for that node. In addition, as will be appreciated by those skilled in the art, alternatives may be included to allow accumulation of path metrics for any route transmitted.
Several forms of path metrics are possible, and as will be appreciated by those skilled in the art, path metrics can be as one or more components or resend CLNANN messages to vector metrics. It can be accumulated as a vector of each node to which the contribution is added. Path metrics and cluster leader metrics allow nodes to calculate cluster relevance metrics. The procedure for joining or working with a cluster and the procedure for selecting a cluster leader node are described separately here for clarity, but in fact, in some embodiments they are one. It is understood that they may be closely related as implemented in a compound method.
The details of the cluster relevance and the operation of selecting the cluster leader node will be described with reference to FIG. 10, which schematically illustrates the scenario for selecting a new cluster leader node. Clusters 101 and 102 each have a designated cluster leader node 101 and 102. For clarity of illustration and description, the same reference code used for a particular cluster leader node is used to specify each cluster. Using the example illustrated in Figure 10, periodic message-linked behavior details, node power-up selection and cluster relevance, cluster leader node selection, link failure, node failure, and new The link addition will be described.
Two types of periodic messages are used for periodic messages. Cluster leader nodes 101 and 102 issue periodic CLNANN messages, as briefly described above. This message signals the existence of the node as a cluster leader node. N so that messages reach all nodes 11 in adjacent clusters, especially in adjacent cluster leader nodes.<sub>CL</sub>It is transmitted to the hop. This message has a cluster leader metric and a node alternative that rebroadcasts the message to accumulate path metrics for the cluster leader node-to-node route along each route crossed. ing.
The cluster leader metric may also be used to notify other nodes in the cluster of this metric. If you compete for leadership based on this metric, you can help determine other nodes that will be better cluster leaders. Each ordinary node 11 broadcasts a HELLO message transmitted to the kN hop to reach all nodes in the node's kN hop neighborhood. This allows all nodes in the kN hop neighborhood to collect path metric information to all the nodes in those neighborhoods. The path metrics obtained in this way can be used to form both cluster leaders and cluster relevance metrics.
For node power-ups and cluster relevance, powering up node 11 performs the following steps: Node 11 "listens" for periodic CLNANN messages from the cluster leader node in concatenating clusters to identify potential clusters that may join. In addition, k to collect path metric information<sub>N</sub>From node 11 in the hop neighborhood its k<sub>N</sub>Attempts to listen to periodic HELLO messages to all nodes in the hop neighborhood. In addition, the periodic HELLO message is its k<sub>N</sub>Broadcast to all nodes in the hop neighborhood. Cluster relevance metric
<maths num="8"><img file="JP4087380B2_D0008.tif" /></maths>Is formed for each adjacent cluster leader m, and the cluster leader node m is the smallest cluster relevance metric as a joining cluster.
<maths num="9"><img file="JP4087380B2_D0009.tif" /></maths>Is selected by.
metric
<maths num="10"><img file="JP4087380B2_D0010.tif" /></maths>Is the threshold T to specify that the nodes being considered are close enough to the cluster to which they are joined.<sub>j</sub>The following is preferable. If this threshold is met, the cluster join message CLJOIN is sent to the cluster leader node m. Cluster is limited by the number of nodes per cluster L<sub>CL</sub>If less than or equal to, the cluster leader node accepts the node w in the cluster and sends a reception message CLACCEPT to that node. If the cluster leader node cannot accept other members, it sends a deny message CLREJECT to the node. In addition, if a node is rejected, it selects the next best cluster leader node as its backup and repeats the process to join the cluster.
Following the above process, node 11 will soon become a member of cluster 12 as usual after powering up. In some cases, at the start of such a network, for example, it is not possible to find acceptable cluster leader nodes 21-33 to complete the association. In this case, node 11 may decide to insist on becoming a cluster leader node.
If the decision is made to insist that regular node 103 become the cluster leader node, the following steps are initiated. Node 103 has a special type of CLNANN that notifies bids to become a cluster leader node, containing the cluster leader metric calculated by the node.<sub>N</sub>Broadcast to all nearby nodes 11. For reliability, k<sub>N</sub>Each neighboring node 11 preferably responds to the CLNANN message. As will be appreciated by those skilled in the art, for example, a follow-up CLNANN message will be sent via unicast to any node 11 that does not respond.
Node 11, which is positively responding to the CLNANN message, replies with a CLNANN message indicating consent that node 103 can become the cluster leader node. This is either not in a position to be the cluster leader node itself, or a cluster leader metric larger than that received in the original CLNANN message. Node 11, which responds negatively to the CLNANN message, has a better cluster leader metric than that received in the original CLNANN message and signals that it will create a better cluster leader. In the event of a cluster leader draw, the role of cluster leadership may be, for example, using other tie-breaking finals, but may be won by the node with the lowest node ID.
If the response of all CLNANN messages is positive or controversial and node 103 wins the role of cluster leader node, it is assumed that node is the role of cluster leader node. To reach all nodes 11 in adjacent cluster 12 and adjacent cluster leader nodes n<sub>CL</sub>Initiates a periodic broadcast of regular CLNANN messages spread to hops. The other node 11 starts determining whether or not to join this new cluster. If the other node succeeds in showing consent for the node's role, node 103 determines whether to join the cluster of this new cluster leader node.
A brief description of link / node failure and route recovery has now been made appropriately for the cluster ring and cluster leader node designation schemes, which are described in detail below. More specifically, if node 11 loses a link to a neighboring node, some action is taken. That is, it tests the route to the cluster leader node to determine if it can stay within the same cluster. If the node-level route to the cluster leader node cannot be found, it may be associated with another cluster leader node. On the other hand, if it determines that node 11 still has a route to the cluster leader node, it re-evaluates the cluster relevance metric for this cluster leader node and the cluster leader node for adjacent clusters. To do.
The cluster relevance metric is the other threshold T above.<sub>L</sub>That is,
<maths num="11"><img file="JP4087380B2_D0011.tif" /></maths>If it increases to the value of, then preferably, as mentioned above, it may be possible to leave the cluster alone and find adjacent clusters that meet the criteria for the cluster relevance metrics to join. You may also find that node 11 has a better cluster relevance metric than the adjacent cluster leader node. If its current relevance is due to the cluster leader node m and its best adjacency is the star leader node node k, then the cluster relevance metric is better with the threshold at which node k is identified. Nodes may be associated with adjacent clusters if they have. That is, if
<maths num="12"><img file="JP4087380B2_D0012.tif" /></maths>If so, switch from cluster m to cluster k. In various cases, it may be found that the node should try to form a new cluster and make a claim to cluster leadership using the procedure described above, as will be understood by those skilled in the art. Absent.
For node failure, either the normal node or cluster leader nodes 21-33 fail or stop. Failures of regular nodes (ie, nodes other than cluster leader nodes 21-33) are potentially identical to some link failures, as detected by neighboring nodes. Each of these nodes responds to this failure as if it were a link failure and proceeds according to the above procedure. This failure is detected by neighboring nodes due to link loss and by other nodes in the cluster due to loss of periodic CLNANN message broadcasts. Nodes in the same cluster, for example, select adjacent cluster leaders with whom they can work together if the cluster relevance metrics are in good condition using the above procedure. It may also be claimed that one or more nodes will be cluster leader nodes 21 to 23 using the cluster leader selection procedure described above.
In addition to the phase dynamics caused by the above nodes and link failures, link additions may also cause topology changes. Link and node failures tend to move node 11 further topologically. Conversely, link addition tends to bring nodes 11 closer to each other in phase. Traffic mechanics has a similar effect. This has the effect of eventually causing the nodes in one cluster to have better cluster relevance metrics with adjacent clusters. As will be appreciated by those skilled in the art, node 11 can use a similar procedure as defined above to determine whether its cluster relevance should be switched. If the current relevance of a node is due to the cluster leader node m and its best adjacent cluster leader node is node k, the cluster relevance metric will be better with the threshold at which node k is identified. Nodes may be associated with their adjacent clusters if they have. In other words
<maths num="13"><img file="JP4087380B2_D0013.tif" /></maths>If so, switch from cluster m to cluster k.
Moreover, the two cluster leader nodes may be so close to each other that it would be desirable to remove one of the cluster leader nodes. The path between the two cluster leader nodes has a specific threshold Δ<sub>p</sub>If less than or equal to, and one of them can support the total number of cluster members for both clusters, then the best cluster leader node is determined and the other node is that cluster leader node. You just have to abandon the role of. When cluster leader nodes move closer to each other, normal nodes may use cluster relevance metrics to move naturally, as they are the best choice for regular nodes as cluster leader nodes. .. Therefore, the decision as to which of the two nodes should be the remaining cluster leader node is based on the number of cluster members for each node and its cluster leader metric. After one of the nodes relinquishes the role of cluster leader node, the regular node associated with it is associated with the remaining node of either the cluster leader node or any of its other adjacent cluster leader nodes. Choose that.
If a particular source node 14 in the source cluster (cluster 21 in the example illustrated in Figure 1) needs to send data to the destination node 15 in the destination cluster (here, cluster 32), the source At block 43, the node advantageously sends a cluster-level route request (CLRR) to its corresponding cluster leader node (here node 21). At block 44, the source cluster 21 begins the process of determining the cluster-level route between the source cluster 21 and the destination cluster 32, which corresponds to the cluster-level route. That is, cluster-level routes are established in a reactive manner, contrary to the proactive techniques used for traditional spine / cluster routing.
A cluster-level route is a specific sequence of cluster 12 within a route from a source cluster to a destination cluster. With particular reference to Figure 5, the determination of cluster-level routes will be described in more detail. This process is initiated in block 51 by determining (or establishing) the communication link 16 specified between cluster leader nodes 21 and 33 (block 50). The designated communication link 16 is illustrated by the dotted line in FIG. 1 and can be conceptually thought of as a "virtual" link between cluster leader nodes 21-33. Each designated communication link includes a single hop or multihop connecting cluster leader nodes 21 to 33 in the adjacent cluster 12. That is, each of the specified links may contain one or more intermediate nodes that are not cluster leader nodes 21-33, or such intermediate nodes do not exist between the nodes. Is also good.
The decision of the specified Link 16 is a cluster leader node for the specified cluster, which is clustered via a restricted broadcast to notify all adjacent clusters by the cluster leader node. Includes sending a leader node announcement (CLNANN) message. Here, a "connecting cluster" is two clusters 12 such that at least one node 11 in one of the clusters is directly connected to at least one node in the other cluster.
Once cluster leader nodes 21-33 learn that other cluster leader nodes are in adjacent clusters, the specified communication between the cluster leader nodes (that is, the cluster leader nodes). Get the node-level route from link 16). These two cluster leader nodes maintain the specified communication link 16 between them and the metrics associated with them. As will be appreciated by those skilled in the art, this metric has the number of hops on the specified communication link 16 and quality of service (QoS) parameters such as bandwidth, availability, and so on. Such a metric may preferably be used for other designated links 16 as well.
Each cluster leader node stores all the addresses of its adjacent cluster leader nodes and maintains a designated communication link 16 to each of its adjacent cluster leader nodes. Once the specified communication link is established, if the cluster-level route requested by source node 14 is not a route to one of the clusters adjacent to the source cluster, then source cluster leader node 21 Start the cluster level route discovery process.
Processing is at block 22, from cluster leader node 22 to 31 remaining over the designated communication link 16 and from cluster leader node 21 of the source cluster to cluster leader node root request. Started by sending (CLNRR). Further, in particular, a cluster leader node root request is sent from the source cluster leader node 21 to each of the adjacent cluster leader nodes, cluster nodes 23 and 25 in the example illustrated in FIG. It is done by being done. Cluster leader nodes 23 and 25, in turn, adjacent to the cluster leader node root request until the cluster leader node root request is received by all of the cluster leader nodes 21-33. Transfer to each cluster leader node.
It will be appreciated by those skilled in the art that the above techniques provide significant savings in overhead traffic because broadcasts are not used overall. That is, only a subset of radio lines 13 are required for broadcasting. Further ring search can be used to extend this process because it is limited to overhead transfers that require communication. In addition, a cluster leader node route request can be targeted to discover a route to one cluster, a list of clusters, or all clusters. The cluster leader node request may also include accumulated metrics that can indicate the desirability of each cluster-level route discovered. As an example, the accumulated metric is the accumulation of link metrics for the specified communication link 16 between cluster leader nodes 21-33 along the route to the targeted destination cluster 32. Is also good.
If the cluster leader node route request is received by the destination cluster leader node 12 in block 53, the destination cluster leader node replies with the destination cluster leader node route reply (CLRREP). .. This cluster leader node route reply is used by the destination cluster leader node 32 to send back to the source cluster leader node 21 to the cluster level route. This message is sent over the delivery route to which the cluster leader node route request traveled, that is, the specified communication link 16 connecting the source cluster leader node 21 and the destination cluster leader node 32. Will be sent back.
As further described below, the information in the cluster leader node route may have a series of clusters on the distribution route, and may be modified in other ways. Also, a path metric for a particular delivery route (or a component that can be combined to form a path metric) may be returned. Of course, the destination cluster leader node 12 is the same cluster from one or more of its adjacent cluster leader nodes (ie, cluster leader nodes 26, 31, and 33 in the example illustrated in Figure 1). -It is possible to receive leader node route requests. In such a case, the source cluster leader node 32 may also return a cluster leader node route reply for each delivery route associated with each of these adjacent cluster leader nodes.
Once the source cluster leader node 21 collects all of the cluster leader node route replies corresponding to the given cluster leader node route request, at block 54, as a cluster level route. Use the path metric for each delivery route to select the best route among the delivery routes. Of course, in some embodiments, the source node 15 chooses the best delivery route from those available routes and determines the cluster-level route, so that the cluster leader node follows the best route. -Simply send back the route reply.
In either event, once the best route is selected, it is stored in the routing cache or table. As an example, the path metric used to select a cluster-level route is one whose delivery route contains the smallest number of cluster leader nodes (that is, the smallest number of clusters 12). ). Of course, other metrics can be used, such as the specific QoS metrics mentioned above. One specially valid method for selecting routes with QoS parameters is transferred to the Transferor and is incorporated in its entirety by reference, Agent Case No. GCSD-1201 filed April 29, 2002. It is disclosed by US Patent Application No. 10 / 134,715 of a concurrent application entitled "Methods and Systems for Determining Quality of Service (QoS) Routing for Mobile Ad Hoc Networks" in (51264). Once the source cluster leader node 21 determines the best cluster-level route, it is forwarded at block 57 to the source node 14 requesting in the cluster-level route reply (CLRREP).
At block 55, each of cluster leader nodes 21-33 queries its adjacent cluster leader node to hold its current address and terminates the method exemplary (block 56). This allows the process of forwarding cluster-level node root requests to be advantageous and efficient because the adjacent cluster leader node is not determined by each new request. This query step is exemplified as the final step (block 55) in the cluster-level route discovery process illustrated in Figure 5, while this step is between adjacent cluster leader nodes 21-33. It may be executed at any time after the designated communication link 16 is established, or it may be executed at desired intervals.
Once the cluster-level route is established, at block 45, data is transferred from the source node 14 to the destination node 15 using the cluster-level route, ending the method illustrated in FIG. (Block 46). Schematic diagram of ad hoc network 10 illustrated in FIG. 2 and a flow diagram of FIG. 6 in which the designated communication link 16 has been removed to clarify the process of transferring data using a cluster-level route. It will be explained with reference to. This example assumes that the cluster-level route selected by source node 14 contains clusters 21 (source), 25, 24, 29, 26, and 32 (destination).
This process begins at block 61 by specifying the target node 17 in the next cluster along the cluster-level route to which the data will be sent (block 60). According to the present invention, it is not necessary to use a cluster target node for data transfer, while the cluster target node serves as a gateway to each cluster along the cluster level route, as described further below. It provides good points for, thereby facilitating the establishment of node-level routes between them.
In particular, the source node 14 selects the cluster target node 17a in the next adjacent cluster along the cluster level route (here, cluster 25). This is done, for example, by broadcasting an adjacent cluster target node discovery packet with an extended ring search to identify a potential cluster target node. This broadcast is restricted in favor of the next adjacent cluster (here, cluster 25). That is, broadcasts are somewhat restricted to reduce excess traffic on ad hoc networks 10.
Adjacent cluster target node discovery that allows any node in adjacent cluster 25 to allow source node 14 to seed the identities of potential cluster target nodes according to metrics and routes to potential cluster target nodes Send back the response packet. The algorithm selects the best adjacent cluster target node in the adjacent cluster 25 based on all of the adjacent cluster target node discovery responses received and based on the metrics contained in those responses. used. Here again, the path metric used may include the minimum number of hops, QoS parameters, etc., as described above for cluster-level route selection.
The adjacent cluster target node 25 is preferably a node that is as close as possible to the source cluster 27 and has high capacity. Similarly, the cluster leader node of an adjacent cluster serves as the cluster target node, which is especially useful if the cluster leader node has high link potential.
Various techniques are possible to establish a cluster target node. For example, the proactive approach is adapted by using the above procedure for each node 11 in each cluster 12 to specify a cluster target node for each cluster adjacent to its own cluster. Adjacent cluster target node "hello" messages may be used to maintain node-level routes to such cluster target nodes. This message is periodically forwarded to each adjacent cluster target node to confirm that the route is also available. The cluster target node replies with a similar packet type to indicate that the route is still valid. If the route fails, the node that sent the hello message to the adjacent cluster target node will start searching for other adjacent cluster target nodes as the failure is detected by this process, as described further below.
Other techniques that do not require hello messages from adjacent cluster target nodes discover adjacent cluster target nodes only on a reactive basis when requested. Moreover, these adjacent cluster target nodes are maintained only as long as they are used. Here again, this results in less network traffic and is an advantage of some applications, as will be appreciated by those skilled in the art. In each case, each node is individually selected for its adjacent cluster target node so that each cluster uses only one cluster target node and through a single cluster target node. Reduce the concentration of transit traffic that may be triggered. Of course, as will be appreciated by those skilled in the art, one cluster target node may be used in some embodiments if desired.
Once the next cluster target node is determined (node 17a in the example illustrated in FIG. 2), block by click 62, the node-level route to the next cluster target node is determined. This is done, for example, by sending a node-level route request to the next cluster target node 17a using a basic routing protocol such as DSR or AODV. Specific examples of the present invention using these two protocols are presented below.
In general, node-level route requests find routes for other nodes in the same cluster, or for cluster target nodes in adjacent clusters with restricted broadcasts (or by extending ring search). Used to do. The destination node 15 is in the same cluster as the source node 14. In this case, only node-level routes are used, just as cluster-level routes are used only to reach destination nodes outside the source node cluster. In this case, as a basic routing protocol, it will be further described below in connection with the discussion of DSR.
Once a node-level route is established along the cluster-level route to the next cluster target node, the data is in block 63, via the node-level route, from the source node 14 to the next cluster. Transferred to target node 17a. Here again, this data transfer is managed by the underlying underlying routing protocol used. In general, data is forwarded according to mission data packets or headers that contain information suitable for node-level forwarding, cluster-level routes, or both. The use of mission-critical data packets is described below in certain cases where DSR and AODV are used as the underlying routing protocol.
The above steps exemplified in blocks 61-63 are performed in block 64 along each next cluster target node 17b along the cluster level route and the corresponding node level route until the data is transferred to the destination target node 17e. , 17c, 17d, 17e are repeated to determine. Once the data reaches the destination cluster target node 17e, a node-level route from the destination cluster target node to the destination node 15 is determined (block 65), and as described above, between these node-level routes. The data is transferred (block 66), and at block 67 the method ends. Again, these steps are performed according to a basic routing protocol such as DSR or AODV.
As can be seen in Figure 2, various node-level routes along the cluster-level routes may or may not include cluster leader nodes. In some embodiments, it is particularly advantageous to define node-level routes so that they do not include cluster leader nodes wherever possible, which is the excess traffic on the cluster leader nodes. Promote mitigation. The node-level route discovery process involves using a metric for each potential route that indicates whether the route has a cluster leader node, for example, the node requesting the route is understood by those skilled in the art. You may use this metric in the selection process so that it is done.
The case where DSR is used as a basic routing protocol will be described with reference to FIG. The underlying DSR protocol has message types such as route request and route reply used to perform the steps described with reference to blocks 61 and 62 of FIG. 6 reproduced in FIG. The route discovery process for node-level routes according to the present invention is very similar to the route discovery process of the conventional DSR method. That is, a controlled broadcast search searches only within the current cluster, rather than the entire network 10, or finds a route to a cluster target node (or cluster leader node) within an adjacent cluster. Because. Standard DSR packet types provide fields for metric types and metric values, as will be appreciated by those skilled in the art, as briefly described above, if it is desired to use a route selection criterion other than the minimum hop count. It may be modified to be prepared.
On the other hand, the cluster-level route discovery process according to the invention is somewhat different from the conventional DSR method. That is, this process involves a limited overall search. This is due to the existence of the specified communication link 16 (corresponding node-level source route) between all adjacent cluster leader nodes 21-33. In other words, the route discovery packet traverses only the designated communication link 16 rather than all the links 13 in the network 10, as described above. A cluster leader node route request forwarded from a cluster leader node preferably contains a node-level source route to the next cluster leader node to which the message is being forwarded. Again, it is transferred in this way to the cluster leader nodes in all adjacent clusters.
As mentioned above, data transfer according to the underlying protocol usually involves the data being generated in some form or header of the mission data packet. When using DSR according to the invention, at the start of block 70', the mission data packet (block 71') generated by source node 14 is preferably the address of the destination node, the address of the next cluster target node 17a, And cluster level routes. As will be appreciated by those skilled in the art, the following cluster goals and cluster-level routing fields may be defined as optional packet types for application to the present invention.
This data is forwarded at block 63 based on mission data packets along the node-level route to the next cluster target node 17a. The next cluster target node 17a'repeats the steps illustrated in blocks 61 and 62 (FIG. 6), thus updating the mission data packet. More specifically, mission data packets are updated on each cluster target node 17a, 17b, 17c, 17d along the cluster level route to include a new cluster target node and a new node-level route to it. The node.
This process continues until the destination cluster target node 17e is reached (block 64'). The destination cluster node 17e determines that the data has reached the destination cluster 32 by the cluster-level route in the mission data packet. Then, the node-level route to the destination node 15 is determined (block 65'). The mission data packet is updated to include a null value for the cluster-level route and the next cluster target note because the route to the destination node 15 is an inter-cluster route. The data is transferred to the destination node 15 in block 66'as described above.
As described above, the source node 14 and the destination node 15 are located in the same cluster in some cases. In this case, the source node 14 simply sets the address and cluster level route of the cluster target node in the mission data packet to be equal to the predetermined values. For example, this may be a null value for the destination cluster target node 17e as described above. Traditional DSR routing procedures are therefore used to transfer data.
Again, the source node 14 does not need to request a cluster-level route if the destination node 15 is already known to be in the same cluster. This is the case when the data is sent there and the record is stored in the memory or cache of the source node 14.
At that time, the various routing information determined in the above step is stored in one or more caches in block 73'to be advantageously used for subsequent routing operations. End processing (block 74'). As a result, if such routing information times out or is discarded, it may be used again without completing all or part of the cluster / node level discovery process.
As an example, the following types of cache are held: The cluster-level route cache caches cluster-level routes to the destination cluster where the route is currently held. This cache is maintained, for example, every 33 to 33 cluster leader nodes and is indexed by the destination cluster to provide known cluster-level source routes on demand.
Another cache caches node-level routes to any node in the same cluster or adjacent clusters (such as cluster target node 17) where routes are currently held. Including. This cache is maintained for each individual node 11, indexed by the destination node address, and provides each node 11 with a known node-level source route when it is available.
Also, the hierarchical route cache held at each node 11 caches the hierarchical route to any destination node for which the route is currently held. This cache is also indexed by the destination node address, and the cache is the cluster-level source route to the destination cluster and the cluster target node (in the example example) in the first cluster on the source route. , Returns a hierarchical route containing the node-level source route to node 17a).
Another type of cache that proves useful is a table that is indexed by the destination node address, which returns the address of the cluster to which the node is currently a member, in addition to the adjacent cluster target node cache. -Includes cache. This cache is indexed by the adjacent cluster address and returns the adjacent cluster node address for that cluster.
Given the dynamic nature of ad hoc networks, different types of addresses are used for individual nodes and clusters. Various other changes are required for the given underlying protocol, depending on the particular type of addressing used for the particular application. For example, if a fixed address is used, the protocol may be included to deliver the current cluster membership as a node change cluster, as understood by those skilled in the art. If no such protocol is used, cluster membership can be determined, for example, by a reactive method using CLNRR route discovery processing. On the other hand, if the address is dynamically assigned where the node is located, based on a particular cluster, hierarchical level (further defined below), etc., then dynamic, as will be understood by those skilled in the art. The name server may be installed at will to allow the source node to determine the current address for the fixed node name.
Another embodiment in which AODV is used as the underlying routing protocol will be described with reference to the flow diagram of FIG. According to the AODV protocol, node-level routes are established using route requests and route replies, as in the case of DSR described above. Also, the method by which the node-level route and the corresponding cluster-level route are determined is somewhat different from the method in DSR.
Also in particular, starting at block 81 of FIG. 8, cluster leader node route requests are transmitted over the designated communication link 16 using conventional AODV known to those of skill in the art. Generally, according to the AODV protocol, when a route request is sent, each node 11 stores the address of the previous node along the route. The route request is received from the previous node and forwarded to the next node. In this method, if the route reply is finally sent back along this route, the address stored in each node 11 provides the position of the next hop along the return route. Further, each node stores the address of the node that forwarded the route reply to the next node so that the route reply is forwarded from the node 11 along the return route to the next node. Thus, these addresses provide the position of the next hop along the route when the data is forwarded along the route.
According to the present invention, the above-mentioned processing determines the cluster-level route in blocks 81 to 82 by using the above-referenced cluster leader node route request and cluster leader node route reply. Start at the cluster level to do. In addition, this process also uses node-level route requests and node-level route replies as described above to determine node-level routes along cluster-level routes in blocks 83-84. Is implemented at the node level. Here again, the cluster target node may be used as described above as needed, and the cluster target node may be determined as described above by the standard mechanism of AODV, as understood by those skilled in the art.
At block 85, mission data packets are generated at the beginning of each node-level route (ie, by either source node 14 or cluster target node 17), and data is defined based on mission data packets. Transferred along various node-level routes. According to the AODV protocol, hops for node-level routes are already stored on various nodes 11 on the route, so mission data packets typically only request the address of the destination node 15.
Since the mission data packet does not have the location of the next cluster along the cluster-level route, each cluster target node 17 queries the corresponding cluster leader node for the next cluster address. Therefore, the cluster leader node determines the next cluster target node based on the next cluster address. Of course, as understood by those skilled in the art, other techniques are used in optional data packets defined to be included in mission data packets so that there is no need to query the cluster leader node. May be done.
Data is transferred at block 86 along various node-level routes until it reaches the destination cluster target node 17e. At block 87, the node-level route to the destination node 15 is again defined using standard AODV technology and the data transferred to it, thus ending the process (block 88).
Various tables are used to store essential routing information in order to implement AODV in accordance with the present invention. In particular, the cluster-level route table indexed by the destination cluster address sends back the next adjacent cluster on the route to the destination cluster where the route is held. In addition, the node-level route table, which is indexed again by the destination node address, is on the route to a node in a similar cluster where the route is held (such as cluster target node 17) or in an adjacent cluster. Send back the address of the next node 11 in. Also, the cluster cache indexed by the destination node address sends back the address of the cluster to which the destination node is currently a member. The adjacent cluster target node cache, indexed by the adjacent cluster address, sends back the adjacent cluster target node address for the adjacent cluster. In addition, the hierarchical route table indexed by the destination node address sends back the address of the next node on the route to any destination node in the entire network where the route is held. Similarly, the data held in the table may be stored each time new cluster-level or node-level information is generated. Therefore, this information will be available for future routes and avoid discovery requests and reply messages, thus facilitating traffic mitigation. Of course, this information may be discarded after a period of time, for example, to reduce storage space for outdated information.
Due to the dynamic nature of wireless mobile ad hoc networks, a common problem that must be addressed is the problem of route failure due to disconnection in the logged-off node 11 of network 10 and wireless communication link 16. Basic routing protocols usually have a mechanism for dealing with route recognition and recovery. Route recovery in the context of the present invention will be further described with respect to the flow diagram of FIG. 9, with particular emphasis on route recovery using the DSR and AODV protocols. For the purposes of Figure 9, assume that cluster-level and node-level route destination processing (Figures 5 and 6) has previously been performed.
Therefore, if a cluster-level route failure occurs between adjacent clusters according to the cluster-level route in block 91, starting at block 90, the cluster-level and node-level route discovery process is performed as described above. A cluster-level root error message to start again is sent to source node 14 (block 92). The format taken by this particular route request depends on the underlying routing protocol used.
For example, if the underlying protocol used is AODV, then each cluster leader node will have each "downstream" cluster along the cluster-level route to the destination cluster leader node 32. -It is evoked to store the address of the leader node. Therefore, in block 93, the cluster-level route is no longer valid so that the cluster-level route error message returns to the "upstream" cluster-level route to the cluster-level route. Therefore, each cluster leader node that receives the error message removes the next hop address from its corresponding cache.
When DSR is used as the underlying protocol, a cluster-level root error message, along with the cluster leader node in all adjacent clusters, discovers the loss of connectivity from the cluster leader node to that cluster. Broadcast to all other nodes in. This broadcast reaches all nodes selected as adjacent cluster target nodes 17 by nodes in other clusters, as well as all other nodes in the cluster. The cluster target node 17, which receives the packet to forward through a cluster that is no longer adjacent, sends a cluster-level route error message to the original sender of the data packet informing it that the route has failed at the cluster level. Forward. Cluster-level root error messages broadcast to cluster leader nodes in all adjacent clusters are also broadcast to all cluster leader nodes in network 10 as needed. It notifies you that the cluster-level route is out of date. This gives all of the cluster leader nodes a new round of route discovery queries to receive new cluster-level route requests, rather than simply replying to the information previously stored in the corresponding cache. Encourage them to start.
On the other hand, in block 94, if a node-level route failure occurs between adjacent nodes within the node-level route, in block 95 a new node-level route is determined according to the underlying protocol used. Therefore, the process ends (block 96). Also, in particular, the basic procedures established for basic routing protocols that use route error messages for node-level routes used to destination node 15 or adjacent cluster target nodes 17 by those skilled in the art. Accumulate notifications of appropriate nodes for routing failures, as understood.
The method described above of the present invention may also be effectively extended to any number of hierarchical levels, as illustrated in FIG. In FIG. 3, the exemplary ad hoc network 10 illustrated in FIGS. 1 and 2 is extended to four levels of hierarchy. The first level of the hierarchy is the network level (ie, node 11) from the previous example. The second level is made up of hierarchies that include cluster 12.
Level 17 of the hierarchy consists of virtual nodes and virtual links. Each virtual node at the third level represents the entire cluster 12 at the second level. Closely connected third-level 17 virtual nodes are grouped into third-level clusters, and one of these virtual nodes is selected as the third-level virtual cluster leader node. The physical node selected as the third level 17 virtual cluster leader node is the actual cluster from the second level cluster running the cluster leader node for both the second and third level clusters. -May be a leader node.
The third level 17 virtual link, shaded in Figure 10, is a multi-hop virtual link between cluster leader nodes in an adjacent cluster, shown in second level. Virtual links between third level 17 cluster leader nodes are established, as shown by way of illustration. As will be appreciated by those skilled in the art, this hierarchical organizing process can be continued for any number of levels.
A fourth level 18 cluster, in which each third level 17 cluster becomes a virtual node at the fourth level, is also illustrated exemplary in Figure 3. The virtual link shown at the fourth level 18 is the cluster leader node virtual link at the third level 17. The physical node selected as the fourth level 18 cluster leader node is the actual from the third level 17 cluster that performs the cluster leader node function for the second, third, and fourth level clusters. It is a cluster leader node. As will be appreciated by those skilled in the art, the wider the network, the more hierarchical organizations can extend to even clusters.
Multiple of the above messages may increase processing at any number of hierarchical levels. For example, the message type for cluster leader node root requests is different for each hierarchical cluster level. This message is broadcast to all destination cluster leader nodes, but includes only unicasts to virtual links that connect to adjacent cluster leader nodes, cluster leader nodes at the appropriate hierarchical level. Sent to a virtual link that connects to everything. Moreover, cluster leader node root reply messages, such as cluster leader node root requests, also have different types at each hierarchical cluster level, as will be understood by those skilled in the art.
In addition, cluster-level route requests may have different types for each hierarchical cluster level. Also, in particular, at a particular level, messages are sent to ALN for that level. In addition, in response to a cluster-level route reply, the source node provides a cluster-level route to the destination (a specific hierarchical level of the request) by sending a short distance to its cluster leader node. Can be obtained.
As can be seen in Figure 3, the fourth level 18 favors convenient criteria for determining high-level routes from the cluster leader node 21 of the source cluster to the cluster leader node 32 of the destination cluster. It has one cluster to provide. Also in particular, since this one cluster contains source and destination leader node clusters 21 and 32, high level routes are determined between them using the various steps outlined above. .. The higher level routes are, in turn, used to determine the cluster level routes for the second level. That is, a cluster-level route includes at least clusters with corresponding cluster leader nodes along the higher-level routes, in this case cluster leader nodes 21, 24 and 32.
<figref num="1">It is the schematic of the ad hoc network which concerns on this invention.</figref><figref num="2">It is a schematic diagram of the ad hoc network of FIG. 1 illustrating a node level route along a cluster level route.</figref><figref num="3">It is a schematic diagram of the ad hoc network of FIG. 1 exemplifying a plurality of hierarchical levels.</figref><figref num="4">It is a flow diagram which illustrates the method for transmitting data in the ad hoc network which concerns on this invention.</figref><figref num="5">It is a flow diagram which illustrates the cluster level route discovery process of FIG. 5 in more detail.</figref><figref num="6">It is a flow diagram which illustrates the node level route discovery processing and data transfer of FIG. 5 in more detail.</figref><figref num="7">FIG. 5 is a flow diagram illustrating another embodiment of the method of FIG. 5 using dynamic source routing (DSR).</figref><figref num="8">FIG. 5 is a flow diagram illustrating still another embodiment of the present invention using an ad hoc on-demand vector (AODV).</figref><figref num="9">It is a flow diagram which illustrates the method for root error recovery which concerns on this invention.</figref><figref num="10">FIG. 5 is a schematic diagram illustrating grouping of destination clusters and cluster leader nodes according to the present invention.</figref>
Every citation, both ways
| Document | Relation | Office |
|---|---|---|
| JP11098137A | Cites | Japan |
| WO01043317A1 | Cites | World Intellectual Property Organization (WIPO) |
| JP2002044003A | Cites | Japan |
| JP2000341323A | Cites | Japan |
| JP2001127797A | Cites | Japan |
39 members in 9 offices
Priority claims9
| Document | Office | Kind | Date |
|---|---|---|---|
| 10134559 | United States of America | – | |
| 13455902 | United States of America | A | |
| 13455902 | United States of America | A | |
| 0313142 | United States of America | W | |
| 0313142 | United States of America | W | |
| 2002134559 | – | – | – |
| 2003013142 | – | – | – |
| US20020134559 | – | – | – |
| WO2003US13142 | – | – | – |
Members39
| Document | Office | Kind | |
|---|---|---|---|
| US2003202468A1 | United States of America | A1 | |
| US2003202476A1 | United States of America | A1 | |
| US2003204623A1 | United States of America | A1 | |
| CA2484490A1 | Canada | A1 | |
| CA2493953A1 | Canada | A1 | |
| WO03093926A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO03094027A1 | World Intellectual Property Organization (WIPO) | A1 | |
| AU2003234265A1 | Australia | A1 | |
| AU2003234265A8 | Australia | A8 | |
| AU2003234266A1 | Australia | A1 | |
| EP1376939A2 | European Patent Office (EPO) | A2 | |
| AU2003204643A1 | Australia | A1 | |
| CN1474614A | China | A | |
| WO03093926A3 | World Intellectual Property Organization (WIPO) | A3 | |
| JP2004056787A | Japan | A | |
| EP1499990A1 | European Patent Office (EPO) | A1 | |
| EP1500229A2 | European Patent Office (EPO) | A2 | |
| CN1650284A | China | A | |
| CN1650573A | China | A | |
| EP1499990A4 | European Patent Office (EPO) | A4 | |
| JP2005524311A | Japan | A | |
| JP2005524317A | Japan | A | |
| US6954435B2 | United States of America | B2 | |
| CN1224281C | China | C | |
| JP3755881B2 | Japan | B2 | |
| EP1500229A4 | European Patent Office (EPO) | A4 | |
| EP1376939A3 | European Patent Office (EPO) | A3 | |
| EP1768332A2 | European Patent Office (EPO) | A2 | |
| EP1768332A3 | European Patent Office (EPO) | A3 | |
| CN1326068C | China | C | |
| US7281057B2 | United States of America | B2 | |
| JP4025774B2 | Japan | B2 | |
| JP4087380B2This record | Japan | B2 | |
| EP1500229B1 | European Patent Office (EPO) | B1 | |
| AT398366T | Austria | T | |
| DE60321563D1 | Germany | D1 | |
| US7764617B2 | United States of America | B2 | |
| EP1768332B1 | European Patent Office (EPO) | B1 | |
| EP1376939B1 | European Patent Office (EPO) | B1 |
8 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Cancellation because of no payment of annual feesLAPS | LAPS | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 |
Numbers
- Publication
- 4087380
- Publication, DOCDB
- 4087380
- Publication, EPODOC
- JP4087380B
- Application
- 2004502180
- Application, DOCDB
- 2004502180
- Application, EPODOC
- JP20040502180
Titles2
- Japanese
- 階層的なモバイル・アドホック・ネットワーク及びそのネットワークにおけるリアクティブ・ルーティングを実行するための方法
- English
- Hierarchical mobile ad hoc networks and methods for performing reactive routing on those networks
Classification
- CPC, 12
- H04L45/04
- H04L45/26
- H04L45/30
- H04L45/302
- H04L45/46
- H04W40/02
- H04W40/246
- H04W40/26
- H04W40/28
- H04W40/32
- H04W84/18
- H04L45/00
- IPC, 10
- H04L12 28
- H04B7 26
- H04Q7 38
- H04L12 56
- H04W40 02
- H04W40 24
- H04W40 26
- H04W40 28
- H04W40 32
- H04W84 18