JP5004999B2 - Hybrid mesh routing protocol - Google Patents

Description

  The present invention relates to a routing mechanism used for automatic topology learning and route selection. Specifically, the present invention relates to setting each path in a wireless local area mesh network based on a media access control address.

  A wireless local area mesh network, also called a wireless LAN-based ad hoc network, consists of two or more nodes that communicate directly or indirectly with each other, interconnected via wireless links. Yes. A wireless local area mesh network may be connected to the Internet or other network via a portal. In a wireless local area mesh network, a route from a source node to a destination node is discovered using an IP layer routing protocol. The IP layer ad hoc routing protocol is based on IP addresses. However, some devices, such as WLAN access points, forward data packets based on IEEE 802.11 Media Access Control (MAC) addresses and operate only at the link layer (Layer 2). . Also, data transfer in layer 2 is generally faster than data transfer in the IP layer (layer 3). This is because the data packet does not need to go to the IP layer.

  The AODV (Ad Hoc On-Demand Distance Vector) protocol is an ad hoc routing protocol that functions at the IP layer. The AODV protocol can support unicast and multicast route discovery. Route discovery is performed on demand. When a source wants to send a packet to a destination node, it doesn't have a valid route to the destination node, so if you need it, by broadcasting a route request message across the network, Discover the route to the destination. This message includes the IP addresses of the transmission source node and the transmission destination node together with other necessary information. The destination node or the node that has a valid route to the destination node responds to this request by sending a route response message to the source node. With these route request message and route response message, the routing table for the forward route and the reverse route is set in each of the intermediate nodes. Each set route expires and expires if it is not used within a predetermined route lifetime. On-demand routing (hereinafter referred to as on-demand routing) reduces the impact of invalid routes and the need to maintain unused routes due to network topology changes (eg, node movement or failure) The On-demand routing, however, delays route discovery because the source node needs to set a route before data transmission is possible. In addition, the transmission source node needs to buffer data during the route discovery period.

  DSDV (Destination-Sequenced Distance Vector) is a proactive routing protocol for wireless local area mesh networks. Each node in the network exchanges routing control messages, and the routing table in each node includes routing information for all destination nodes in the wireless local area mesh network. The data packet is transferred from the transmission source node to the transmission destination node by each intermediate node based on each routing table on the route. In order to maintain a valid route and to avoid routing loops due to link and node failures and network topology changes, each node not only periodically sends route update information, but also important As soon as new information is obtained, it is broadcast as update information. DSDV can transfer a packet using either a layer 2 MAC address or a layer 3 IP address, and there is no path discovery delay. On the other hand, since routing messages are broadcast throughout the network, the routing overhead is relatively high. In particular, when each node in the network moves very quickly and the network topology changes frequently, a significant portion of the network capacity is used to keep routing information up to date. Furthermore, some nodes may not forward data packets originating from other nodes due to processing limitations, battery limitations, or for other reasons. Each of the above protocols assumes that each node agrees to relay data packets to other nodes upon request and does not consider non-forwarding nodes.

  In a wireless local area mesh network, two or more nodes are interconnected via an IEEE 802.11 link. Each node has a unique IEEE 802.11 MAC (Media Access Control) address. When sending a data packet to a destination node, the source node needs to know the route from the source node to the destination node.

  Therefore, a routing mechanism that discovers and sets a route based on the destination MAC address is required. The problem addressed by the present invention is how a source node discovers and configures a route to a destination node based on the IEEE 802.11 MAC address of the destination in a wireless local area mesh network. .

  A wireless LAN (WLAN) mesh network is comprised of two or more nodes interconnected via IEEE 802.11 links. Each node follows the routing protocol used for automatic topology learning and route selection. The present invention provides a mechanism for finding a route based on an IEEE 802.11 MAC address. The present invention supports on-demand route discovery and proactive route setting simultaneously. The mechanism provided by the present invention can discover and set a path, satisfy quality of service (QoS) requirements for real-time multimedia applications, and maintain and manage the path. In addition, the mechanism also supports non-forwarding nodes.

  The method of the present invention is a method in which a node between a source node and a destination node selects a route in a wireless mesh network, and uses the media access control address to transmit the source node and the destination node. Set the route between. The method of the present invention also provides that the node joins the multicast group in the wireless mesh network by setting a path between the node and the multicast group using the media access control address. Select a route. In both of these methods, the set route can be set using on-demand routing or proactive routing. Here, the present invention will be described with respect to a wireless local area mesh network. However, the network in which each route is set is not limited to this wireless local area mesh network, and may be of any form. It may be a wireless mesh network. An access point having a proxy function may participate in this wireless mesh network. Note that each assigned station assigned to this access point is not a component of the wireless mesh network. Therefore, communication with each station is performed via the access point, but it is transparent to each assigned station. is there.

FIG. 3 is a diagram illustrating an example in which a route request (RREQ) message is flooded and a reverse route is set in a wireless local area mesh network. It is a figure which shows the example in which a route response (RREP) message is unicast and a forward route is set in a wireless local area mesh network. FIG. 3 is a diagram illustrating an example in which a route announcement (RANN) message is flooded and a route to a sender of a RANN message is set proactively (in advance) in a wireless local area mesh network. In a wireless local area mesh network, it is a figure which shows the example which a transmission source node transmits a gratuitous RREP message and sets the reverse path | route to the said transmission source node. FIG. 4 is a diagram illustrating a method in which an arbitrary node sets each route proactively and processes each routing control message in accordance with the principles of the present invention. FIG. 2 illustrates a wireless local area mesh access point with multiple assigned stations. FIG. 2 is a schematic diagram illustrating a wireless local area mesh access point according to the present invention. FIG. 5 illustrates an example in which a new node requests to join a multicast group by flooding a mesh network with a route request (RREQ) message. FIG. 6 is a diagram illustrating an example in which a route response (RREP) message is returned to a sender of a route request (RREQ) message by different multicast tree component nodes. FIG. 6 is a diagram illustrating an example in which a route request (RREQ) message originator transmits a route activation message. FIG. 6 shows an example where a new node is added to a multicast group. FIG. 6 illustrates how a multicast leaf node leaves a multicast group. It is a figure which illustrates the multicast tree after cutting. FIG. 3 illustrates a multicast tree with a broken link. It is a figure which shows the example which the downstream node is trying the detour of a broken link. FIG. 6 illustrates an example in which a downstream node receives a route response (RREP) message from a multicast tree component node with a requirement. It is a figure which shows the example which a downstream node activates a new link. It is a figure which illustrates the new multicast tree which detoured the disconnection link.

  The present invention can be fully understood from the accompanying drawings and the following detailed description.

  The present invention provides a layer 2 routing function in which each packet is transmitted and forwarded from a source node to a destination node based on these IEEE 802.11 MAC addresses. The present invention simultaneously supports on-demand routing and proactive routing. Some nodes only transmit data or only receive data, and do not transfer data transmitted from other nodes due to processing limitations, battery limitations, or other reasons. The present invention can also cope with these non-forwarding nodes. The routing mechanism of the present invention can be used for client / server application configurations / topologies, peer-to-peer application configurations / topologies, and hybrid application configurations / topologies.

  Hybrid mesh on demand routing is based on route request messages and route response messages and is similar to the IP layer routing protocol AODV. In the case of hybrid mesh on-demand routing in layer 2, when a source node wants to send a packet to a destination node, it checks its routing table for the route. If there is a valid route, the transmission source node transmits the packet to the next hop specified in its routing table for the transmission destination node. If there is no valid route, the source node initiates route discovery by broadcasting a route request (RREQ) message. Unlike AODV, the RREQ message includes the source (originator) IEEE 802.11 MAC address (not the IP address), its sequence number and optional layer 3 information and the destination node MAC address ( Not the IP address), the final confirmed sequence number for that destination node, and optional layer 3 information. Further, the RREQ message includes a message ID, a route metric, a time-to-live (TTL), and a route lifetime. The node increments its sequence number just before initiating a route request.

  By broadcasting an RREQ message or other mesh routing control message, eg, a RANN message described below, the IEEE 802.11 broadcast MAC address can be used as the destination address of the transmission mesh routing control message. Another method is to assign a dedicated IEEE 802.11 multicast MAC address and flood the mesh routing control message (mesh routing control group address). All mesh nodes are specified by this address. Each mesh node receives each message addressed to this mesh routing control group address. Non-mesh nodes may not receive each message addressed to this mesh routing control group address.

  FIG. 1 shows a wireless local area mesh network, where node 105 is a source node and node 110 is a destination node. All the other nodes 115 are potential intermediate nodes, that is, nodes that can be intermediate nodes, and when they actually become intermediate nodes, messages between the source node 105 and the destination node 110, A packet or data is passed. A set of intermediate nodes 115 that transfer individual unit content from the source node to the destination node is determined based on the selected path. In FIG. 1, the transmission source node 105 and the transmission destination node 110 are shaded so as to be distinguished from the potential intermediate node 115. In another case, the current source node and destination node (in FIG. 1) can be intermediate nodes, and other nodes can be source nodes and destination nodes. In FIG. 1, the source node 105 floods a route request (RREQ) message into the wireless local area mesh network. A reverse path is set based on the RREQ message.

  When each node receives the RREQ message, each node checks the sender (source) address and the message ID to determine whether or not the RREQ message has been viewed before. If this is the first RREQ message, the node updates its metric field by adding the link cost between itself and the node that sent the received RREQ message, and its routing table In, a reverse route to the caller is set. A sequence in which the node is a destination node, or the node holds a valid route that has not expired to the destination node, and the sequence number for the destination node is indicated in the RREQ message If it is equal to or greater than the number, the node responds by unicasting a route response (RREP) message back to the originator. Otherwise, the node propagates the RREQ message with a new metric. If the received RREQ message is not the first time, the node updates the metric field for the caller by adding the link cost between itself and the node that sent the received RREQ message. The node updates the reverse path if the new metric is smaller than the metric recorded in its routing table. Otherwise, the node discards the RREQ message. If the node satisfies the above requirements, it returns an RREP message to the sender. If the above requirement is not met, the node propagates the RREQ message with a new reverse path metric. This reverse path is used to send a RREP message back to the originator of the RREQ message to set up a forward path, and is also used for two-way communication between the source node and the destination node.

  The RREP message is sent back to the originator of the RREQ message by unicast to set the forward path. The RREP message includes a sender (source) MAC address, a destination MAC address, optional destination layer 3 information, a sequence number for the destination, a metric, an expiration date (TTL), and a route lifetime. It is. When the destination node responds, it uses the maximum value of its current sequence number and the destination sequence number in the RREQ message. The initial value of the metric is zero. The destination node also sets the route lifetime. When the intermediate node responds, it uses its own record of the destination node's sequence number, the metric, and the path lifetime calculated based on the entries in the routing table.

  FIG. 2 shows a wireless local area mesh network, where node 205 is a source node and node 210 is a destination node. A set of intermediate nodes 220 for the source node 205 and destination node 210 is determined. Node 215 is no longer an intermediate node on the path between source node 205 and destination node 210. A forward path is set by unicasting the RREP message from the transmission destination node 210 to the transmission source node 205.

  The RREP message is unicast via a reverse route set when a route request is broadcast. When the intermediate node receives the RREP message, it updates the metric by adding the link cost between itself and the node that sent the received RREP message. The intermediate node sets up a forward path in its routing table and forwards the RREP message to the originator of the RREQ message. If a node receives more than one RREP message, it forwards the first RREP message. The node updates the routing table only if the new RREP message contains a larger destination sequence number or the same destination sequence number with a better metric, Transfer the new RREP message. Otherwise, the node discards the new RREP message. FIGS. 1 and 2 show that the RREQ message is flooded to the mesh network, and the RREP message is unicast to set the forward path. The caller can start sending data or packets as soon as the first RREP message is received, and can then update his routing information when a better route is found.

  A node may have multiple IEEE 802.11 wireless interfaces. The node (hereinafter referred to as “multi-interface node”) has a unique node identifier, that is, a node IEEE 802.11 MAC address, and each interface also has its own IEEE 802.11 MAC address. The node's MAC address is used for RREQ messages, RREP messages, and other routing control messages described below. When a multi-interface node broadcasts an RREQ message, it may broadcast the RREQ message to all its interfaces. When the multi-interface node responds to the RREQ message by unicasting the RREP message, the multi-interface node sends the RREP message to the interface that has received the RREQ message.

  The routing table includes an entry for the destination node. Each entry includes a destination MAC address, optional layer 3 information (supported layer 3 protocol and address, eg, destination node IP address), destination sequence number, next hop MAC address, next hop , An upstream node using the route and a list of interfaces, a status flag and a routing flag (for example, valid or invalid), a metric to a destination node, and a route lifetime. The path lifetime is updated each time it is used. Each route becomes invalid if it is not used within that route lifetime. This invalid route is deleted when its deletion timer exceeds a predetermined time. The caller can start sending data as soon as the first RREP message is received, and then update his routing information when a better route is found. When the intermediate node receives the data packet, it checks its routing table based on the destination MAC address. If there is a valid entry for this destination, the intermediate node forwards the packet to the next hop specified in this routing entry. This process continues until the packet arrives at the destination node.

  In on-demand routing, only the currently used route is maintained. This reduces the routing overhead. However, since it is necessary to set a route before the transmission source node transmits data, an extra delay occurs. Also, during the route discovery period, the source node must buffer the data. Proactive routing can be used to reduce this route discovery delay. Furthermore, if a large number of nodes communicate with a particular node, effective control traffic may be required as each of those nodes individually discovers a route to that particular node. For example, a number of nodes in a mesh network access the Internet or other network through one or more portal nodes that connect the mesh network to the Internet or other network. Portal nodes preferably proactively (pre-) announce routes to themselves within the mesh network. The present invention integrates on-demand route discovery with proactive route announcements. The nodes can be explicitly configured by the network administrator, but are implicitly set to perform proactive routing within the mesh network according to some policy. For example, one policy stipulates that all mesh portal nodes make proactive route announcements. In FIG. 3A, node 310 advertises itself by periodically broadcasting a voluntary route announcement (RANN) message, which causes other nodes 315 in the mesh network to the originator 310 of the RANN message. It becomes possible to know the route. In other words, a node that transmits this RANN message can proactively (preliminarily) set a route to the node by flooding the wireless local area mesh network with a spontaneous RANN message. When a multi-interface node broadcasts a RANN message, it may broadcast the RANN message through all its interfaces. The RANN message includes the sender node's IEEE 802.11 MAC address (not an IP address), a destination sequence number, and optional layer 3 information. Furthermore, the RANN message includes a route metric, an expiration date, and a route lifetime. Unlike the RREQ message, the destination address in the RANN message is used to proactively set the route to the RANN message originator in the mesh network, and thus becomes the MAC address of the RANN message originator. .

  When the node 315 receives the RANN message, the node 315 updates the metric field for the originator of the RANN message by adding the link cost between the node that has transmitted the RANN message and itself. If the node does not have a valid route to this destination node (ie, the RANN message originator 310) in its routing table, the route to this destination node in its routing table Create The node broadcasts a RANN message with a new metric to neighboring nodes via its own interface or interfaces. When the node has a valid route to this destination node, it contains a higher destination sequence number in the RANN message, or the same destination sequence number with a better metric Only if that node updates its routing table and broadcasts the RANN message with a new metric to neighboring nodes. Otherwise, the node discards the RANN message. In this way, each route to the RANN message originator is set in the mesh network.

  In FIG. 3B, when the transmission source node 305 wants to send a data packet to the transmission destination node 310, the transmission source node 305 is already in the order to the transmission destination node obtained from the route announcement of the transmission destination node 310. You may have a route. In this case, the transmission source node 305 can immediately transmit the packet. However, there is a possibility that there is no reverse path from the transmission destination node 310 to the transmission source node 305. When two-way communication is required, the source node 305 is unicast to the destination node 310 via the intermediate nodes 320 along the forward path set by the destination node 310 RANTON message, and is gratuitous. : Sent voluntarily (although not requested) RREP message can be sent. The reverse path to the transmission source node 305 is set by this RREP message.

  Some nodes need to join a wireless local area mesh network only as a source node or destination node, i.e. as a node that does not forward traffic from other nodes. A node can be configured as a non-forwarding node by an administrator or set as a non-forwarding node based on a specific policy. For example, one such policy is that when a node's battery energy is below a threshold, the node becomes a non-forwarding node. A non-forwarding mesh node sends an RREQ message when it wants to send a packet. A non-forwarding mesh node responds to the received RREQ message only if it is the destination node in the received RREQ message. A non-forwarding mesh node does not respond to its received RREQ message if it is not the destination node in the received RREQ message. The non-forwarding mesh node receives the RANN message and knows the route to the originator of the RANN message. Further, the non-forwarding mesh node can proactively (in advance) set a route to which the non-forwarding mesh node is a transmission destination by sending a RANN message. However, non-forwarding mesh nodes do not forward any routing control messages including RREQ messages, RREP messages, and RANN messages to neighboring nodes. Therefore, there is no path that uses a non-forwarding mesh node as an intermediate node.

  If the link is broken, a route error (RERR) message is sent to the affected source node on the active route. The upstream node of the broken link, that is, the node near the transmission source sends a new RERR message. Before sending the RERR message, the node records the damaged path as invalid in its routing table, sets the damaged path metric to infinite, and is unreachable due to this link failure. Increment the destination sequence number of the destination. The RERR message contains a list of all destinations that are unreachable due to this link failure and their incremented sequence numbers. The node broadcasts this RERR message to one or more of its upstream neighbors. The multi-interface node sends a RERR message through each interface, and each path uses this failed link. When the adjacent node receives the RERR message from the downstream node, the adjacent node checks whether it is a route to each transmission destination on the list and holds a route using this downstream adjacent node. If such a route is held, the neighboring node records those routes as invalid and sets the metric for those routes to infinity. The neighbor node then propagates the RERR message to its upstream node. When the source node receives the RERR message, it starts route discovery again. When each node receives a data packet with a destination MAC address that is active, i.e. does not hold a valid path, it creates a RERR message for the source node and sends it to its upstream neighbor.

  Each node periodically sends a beacon (HELLO message) to an adjacent node, thereby managing local connectivity. When each node receives a beacon from an adjacent node, it updates the route lifetime corresponding to that adjacent node in its routing table. When a node cannot receive a beacon from an adjacent node during a predetermined hello lifetime (Hello_Life), the link to the adjacent node is released (disconnected), and routing information for the adjacent node in the routing table of the node Is updated.

  FIG. 4 illustrates a method in which an arbitrary node sets each path on demand and proactively and processes each routing control message in accordance with the principles of the present invention. In step 402, the node determines whether proactive route discovery is necessary. This information can be explicitly configured by the network administrator, as described above, but can be obtained implicitly by a specific policy. If proactive route discovery is required, at step 404, a RANN message is sent periodically. If proactive path discovery is not required, the node returns to the idle state. In step 410, when the node receives the data packet from the upper layer application, the node checks whether or not it has a forward path to the destination node (step 412). If the node does not have a forward route, it initiates on-demand route discovery by sending an RREQ message (step 414). The node waits for a corresponding RREP message. When the node receives the RREP message (step 416), it sets up a forward path (step 422) and starts data transmission (step 428). If the RREQ message is lost, the source node may be able to retransmit the RREQ message up to a predetermined number of times (step 418). If no RREP message is received even after the RREQ message has been retransmitted the maximum number of times, the source node notifies the application that the destination node cannot be reached via an error message (step 420). When the transmission source node holds the forward path, the transmission source node checks whether or not the transmission source node holds the reverse path for bidirectional communication (step 424). When the forward route is set by the RANNN advertisement of the transmission destination node, there is a possibility that there is no reverse route. In the case of unidirectional communication or bidirectional communication in which a reverse path is available, the transmission source node immediately transmits data (step 428). In the case of bidirectional communication without a reverse path, the transmission source node sends a gratuitous RREP message for setting the reverse path (step 426). The sending node can send data as soon as it sends the gratuitous RREP message (step 428).

  When any node in the mesh network receives the RANN message at step 440, the node sets up, sets or refreshes the route to the originator of the RANN message (step 442). If the node is a non-forwarding node (step 444), the RANN message is not forwarded (step 448). If the node is a forwarding node, the RANNN message is forwarded (step 446). In step 450, when any node receives the RREQ message, the node sets up, creates, or refreshes the reverse path (step 452). The node determines whether it is a non-forwarding node (step 454). The non-forwarding node responds to the RREQ message by unicasting the RREP message back to the originator of the RREQ message only when it is the destination node specified in the RREQ message (step 460) (step 462). ). If the non-forwarding node is not the destination node, the non-forwarding node discards the RREQ message without forwarding it (step 464). For the forwarding node, if it is the destination node, or if it has a valid route to the destination node (step 456), by returning the RREP message to the originator of the RREQ message by unicast, Respond (step 462). Otherwise, the RREQ message is propagated (step 458). In step 470, when any node receives the RREP message, the path is set up, created, or refreshed (step 472). If the node is a non-forwarding node or a destination node for this RREP message (step 474), the RREP message is not forwarded (step 478). Otherwise, the RREP message is transferred (step 475). In step 480, if any node detects a link failure or receives a RERR message, the damaged path is deactivated (step 482). When the node is a transmission source node (step 484), a new route is found or detected (step 490). Otherwise, if the node is not a non-forwarding node (step 486), the RERR message is forwarded (step 488). If the node is a non-forwarding node, the RERR message is not forwarded (step 492).

  In WLAN, a plurality of stations may be assigned to one access point (AP). In FIG. 5, node 505 is an AP and participates in wireless local area mesh network 525. However, each station 510 is not a part of a wireless local area mesh network 525. Each station 510 forms an infrastructure-based network or sub-network with the AP 505. The mesh AP 505 functions as a proxy for each station 510 and routing is transparent to the non-mesh station 510. The mesh AP 505 discovers a route to the transmission destination when transferring the data packet transmitted by the allocation station 510. The mesh AP 505 also responds to the RREQ message for each of its assigned stations, that is, responds by unicasting the RREP message to the originator of the RREQ message. The mesh AP 505 announces its route to each of its assigned stations 510 by broadcasting a RANN message. A single RANN message can be used to announce multiple destination addresses, their respective sequence numbers, optional Layer 3 information, time to live (TTL), metrics, and path lifetimes. Each of the plurality of transmission destination addresses corresponds to each assigned station.

  FIG. 6 is a block diagram illustrating details of a mesh access point (AP) 600 with a proxy function (corresponding to the node 505 or AP 505 in FIG. 5). The mesh AP 600 with a proxy function includes two logical interfaces. One of the logical interfaces, the transmission / reception (TX / RX) interface module 645 for the allocation station, communicates with each allocation station, and the transmission / reception (TX / RX) interface module 655 for the mesh network, which is the other logical interface. Communicates with the mesh network. These two logical interfaces may be implemented with two physical IEEE 802.11 radio interfaces operating on different channels (each physical interface corresponds to a different logical interface), or one physical IEEE 802. 11 wireless interfaces may be implemented. The station assignment control module 650 performs station assignment control. A mesh routing module 605 is responsible for routing data within the mesh network. The mesh routing module 605 includes a mesh route discovery unit 610 that sends a route request to find a route to a destination node in the wireless local area mesh network (performs on-demand routing). It is. Also included is a mesh path announcement unit 615 that sends a RANN message (with proactive routing) in the mesh network. The routing message processing unit 620 processes the received routing control message and responds to or forwards it. The route management unit 625 manages the route and generates a route error message when a link failure is detected. Further, the mesh routing module 605 manages the routing table 630 in its own cache. The data processing unit 635 transmits, receives, or forwards data packets based on the routing table. The mesh routing module 605 is connected to the mesh network via the mesh network transmission / reception interface module 655. Station proxy 640 provides a bridge between each assigned station and the mesh network. Station proxy 640 communicates assigned station information from station assignment control module 650 to routing module 605. The station proxy 640 interacts with the routing module 605 to perform a routing function and a data transfer function for the assigned station (for example, when transferring a data packet transmitted by the assigned station, Find the route, respond to the RREQ message for the assigned station, and announce the route to the assigned station by sending a RANN message to the mesh network).

  The present invention supports both multicast routing and unicast routing. A separate multicast routing table is managed by each node. Multicast on-demand route discovery is based on route request messages and route response messages, and is similar to the unicast on-demand route discovery described above and similar to the IP layer routing protocol AODV. . Each node can dynamically join or leave the multicast group at any time. Each multicast group includes a multicast group leader. The group leader manages the multicast group sequence number. When a multicast group leader failure is detected, a new group leader is created so that the center point is not out of order.

  When any node wants to join a multicast group, it broadcasts an RREQ message to all mesh nodes. This RREQ message includes the sender's MAC address, current sequence number, optional layer 3 information (layer 3 protocol and address, eg, information that supports an IP address), destination MAC address (ie, to join) Multicast group address), last confirmed sequence number of the group, message ID, metric, expiration parameter, and participation flag. Any member of the multicast tree may respond to the RREQ message, but only the component node of the multicast tree may respond to this. Non-component nodes (nodes that are not members of a multicast tree) do not respond to RREQ messages, but create a reverse path to the caller. The non-component node then forwards the RREQ message to the adjacent node. This will be described in detail below. The caller waits to receive a response during the discovery period. If there is no response, the caller increments the message ID by 1 and retransmits or rebroadcasts the RREQ message. The caller continues this process until a response is received or until the retry period expires. If no response is received even after the maximum number of retries, the caller may become the multicast group leader for the new multicast group.

  When any node receives a request to join a multicast group from another node (a node not in the group), it updates the metric field and is inactive for the caller in its multicast routing table Add an (inactive) entry. Each entry in the multicast routing table has a flag indicating whether the link is active or inactive. For multicast groups, no data packets are forwarded or transmitted on inactive links. The node also creates a reverse route entry for the caller in its unicast routing table according to the unicast route setting rule.

  The multicast tree includes the multicast group component nodes and forwarding nodes for the multicast group. This forwarding node is a node that is a component of the multicast tree but is not a component of the multicast group. A forwarding node functions as a “path” or “conduit” for data, packets, or content received by the forwarding node. The forwarding node does not use and does not affect the data, packets, or content received by the forwarding node. Any component node of the multicast tree may respond to an RREQ message for joining a multicast group if its recorded sequence number is equal to or greater than the sequence number in the RREQ message. The multicast group leader always responds to the RREQ message to join the multicast group. The node responding to the RREQ message to join the multicast group sets up a unicast reverse path to the caller in its routing table according to the unicast routing rules. The response node sets up a route for the caller in the multicast routing table. This route is flagged as inactive. Next, the response node returns the RREP message to the sender of the RREQ message by unicast. When a node on the reverse path receives this RREP message, it updates the metric and sets up the forward path in its multicast routing table. Routes set up in the multicast routing table are flagged as inactive. The node then forwards this RREP message to the next hop.

  Each node in the multicast tree has a multicast routing table. The multicast routing table has an entry for each multicast group. The entries in the multicast routing table include: multicast group MAC address, next hop MAC address, interface to next hop, multicast group sequence number, metric to multicast group leader, flags (active / inactive) Flag and routing flag), and path lifetime parameters. This route lifetime parameter is updated each time the route is used. Each route becomes invalid if it is not used within the defined route lifetime.

  The originator of the RREQ message to join a multicast group may receive multiple RREP messages from different component nodes of the multicast tree. Each response represents a potential route to the multicast group. The caller tracks each received response and waits for the end of the route discovery period. Next, the caller selects the route with the highest multicast group sequence number and the best metric to the multicast group. At the end of the route discovery period, the caller activates the selected route by setting the join flag to join the next hop and unicasting a multicast activation (MACT) message. The caller sets the active / inactive flag to active for the selected route in his multicast routing table. When each hop on the route receives the MACT message, if it is not the originator of the RREP message, it activates the route in its own multicast routing table and forwards the received MACT message to the next hop. . This process continues until the originator of the RREP message receives the MACT message. An arbitrary node may simultaneously become a component node of two multicast groups or two multicast trees.

  7A-7D show how a new node “N” joins a multicast group. Each shaded node is a multicast group component node and a multicast tree component node. Each node displayed in white is a node that is not a component of the multicast tree or a node that is not a component of the multicast group. Node “N” is a new node that wants to join the multicast group. Each node indicated by “F” is a forwarding node. In FIG. 7A, node “N” is a new node that wants to join the multicast group. Node “N” floods the RREQ message into the mesh network in an attempt to join the multicast group. The RREQ message passes through a node that is not a component of the multicast tree until it reaches a node that is a component of the multicast tree. FIG. 7B shows an example in which the RREP message is sent back to a new node that wants to join the multicast group. The RREP message is sent back to the originator of the RREQ message along the reverse path by different multicast tree component nodes. FIG. 7C shows an example in which the originator of the RREQ message sends a route activation message (MACT). The originator of the RREQ message sets the join flag to activate the route to the multicast group and unicasts the MACT message. FIG. 7D illustrates a state where a new node has been added to the multicast group. One node that was not a member of the multicast group or was not a member of the multicast tree has been added as a forwarding node and is therefore a member of the multicast tree.

  When a node that is a member of a multicast group wants to leave the group, that is, wants to leave, the node unicasts the MACT message with the prune flag set to “cut” to the next hop, Delete an entry for a multicast group in its own multicast routing table. When the next node on the route receives the MACT message in which the prune flag is set to “cut”, the next node deletes the routing information about the node that has transmitted the MACT message to itself. A node that has received a MACT message with the prune flag set to “cut” is not a member of the multicast group, and is associated with the deletion of a node that wants to give up membership in the multicast group. When it becomes a leaf node, it cuts (deletes) itself from the multicast tree. The leaf node cuts (deletes) itself from the multicast tree by unicasting the MACT message with the prune flag set to “cut” to the next hop. On the other hand, if the node receiving the MACT message with the prune flag set to “cut” is a component of the multicast group, that is, if it is not a leaf node, it does not cut itself (does not delete).

  8A and 8B illustrate how node “A” relinquishes its membership to the multicast tree and multicast group. Each node displayed by shading is a component of a multicast group and a component of a multicast tree. Each node displayed in white is a node that is not a component of the multicast group or a node that is not a component of the multicast tree. Each node indicated by “F” is a forwarding node. FIG. 8A illustrates how a multicast leaf node leaves a multicast group, i.e. leaves. Node “A” unicasts the MACT message with the prune flag set to “cut” in order to relinquish ownership of the multicast group and multicast tree. FIG. 8B shows the multicast tree after cutting. After node “A” relinquishes its membership in the multicast group and multicast tree, node “B”, which was the forwarding node, becomes a leaf node and cuts itself out of the multicast tree.

  The node on the multicast tree needs to receive a transmission signal from each of the adjacent nodes every hello period. This transmission signal includes a multicast data packet, an RREQ message, a hello message, a beacon message, or a group hello (GRPH) message. The GRPH message is periodically transmitted by the group leader along the multicast tree. If any node cannot receive a transmission signal from an adjacent node on the multicast tree during the hello lifetime (Hello_Life), the link to the adjacent node is released (disconnected). When a link breaks, the node downstream of the break (ie, a node further away from the multicast group leader) tries to repair the broken link. In practice, it tries to bypass the broken link and create another path to return to the multicast tree. A downstream node that is responsible for repairing the broken link or bypassing the broken link by discovering another route sends an RREQ message to join the multicast group. This RREQ message includes an extension field indicating an metric from the group leader of the transmission node. The node responding to this RREQ message must be a multicast tree component with a sufficiently new sequence number (a sequence number greater than or equal to the multicast group sequence number in the RREQ message) and multicast The metric to the group leader needs to be better than the metric shown in the RREQ message. At the end of the route discovery period, the node that originated the RREQ message trying to bypass the disconnected link selects a route, unicasts the MACT message with the join flag set to join, to the next hop, Activate the newly discovered route. If the multicast tree cannot be repaired by rejoining the multicast tree via any branch, the downstream node that is responsible for bypassing the broken link is responsible for the new multicast tree. Become a new multicast group leader.

  9A-9E illustrate bypassing broken or broken links in the multicast tree. FIG. 9A illustrates a multicast tree with a broken link. In this example, the link between the node “A” and the node “B” is disconnected. FIG. 9B shows an example in which the downstream node (node “A”) attempts to bypass the disconnected link by sending an RREQ message requesting participation in the multicast group. FIG. 9C shows an example where the downstream node (node “A”) receives a RREP message from a multicast tree component node with the necessary conditions. FIG. 9D shows an example in which the downstream node (node “A”) activates a new link by a MACT message in which the participation flag is set to participate. FIG. 9E shows an example in which the multicast tree is repaired by bypassing the disconnected link. As described above, the broken link is not actually repaired, but is bypassed by using a mechanism for finding an available route (route discovery mechanism).

  In the present invention, like unicast, proactive routing is supported to reduce path discovery delay. The present invention integrates on-demand route discovery with proactive route announcements. In the case of multicast, a node can be explicitly configured by the network administrator, but if the node is a multicast group leader, it is implicit to perform proactive routing within the mesh network according to some policy. Is set to A configured group leader advertises a multicast group by periodically broadcasting voluntary route announcement (RANN) messages so that other nodes in the mesh network can route to the multicast group. To be able to know. The RANN message includes an IEEE 802.11 MAC address (not an IP address) of the multicast group, a group sequence number, and optional layer 3 information. Furthermore, the RANN message includes a route metric, an expiration date, and a route lifetime.

  For example, multimedia applications and video applications need to support quality of service (QoS) in WLAN mesh networks. In order to support QoS, QoS requirements, such as maximum delay requirement and minimum bandwidth requirement for data, can be included in the option field of the extended RREQ message. In order to respond to or forward an RREQ message with QoS extension requirements, the node must meet QoS constraints. If the QoS constraints cannot be met, the node discards the RREQ message with this QoS extension requirement. After a QoS path is set up, if any node on the path detects that it no longer meets the required QoS parameters, it sends a RERR message to the originator of the RREQ message. This RERR message may include currently measured QoS parameters, eg, available bandwidth parameters and delay parameters for the link. The originator of the RREQ message may decide to continue using this route with lower QoS, or to find another route. For example, the RERR message indicates that the current bandwidth available on the link is less than the bandwidth requested by the caller. The caller may reduce the source rate to match the currently available bandwidth, or find a new route with the originally requested bandwidth.

  The present invention can be implemented in various forms of hardware, software, firmware, special purpose processors, or combinations thereof, for example, within a mobile terminal, access point, or cellular network. The present invention is implemented as a combination of hardware and software as a recommended example. Furthermore, the software is implemented as an application program embodied on a program storage device as a recommended example. This application program may be uploaded to and executed on a machine having any appropriate architecture. The machine, as a recommended example, is implemented on a computer platform with hardware such as one or more central processing units (CPUs), random access memory (RAM) and input / output (I / O) interfaces. The The computer platform also includes an operating system and microinstruction code. The various processes and functions described above may be part of the microinstruction code, part of the application program, or a combination thereof and are performed via the operating system. Various other peripheral devices such as an additional data storage device and a printing device may be connected to the computer platform.

  In addition, since some of the system components and the method steps shown in the accompanying drawings are preferably implemented by software, the actual components between the system components (or processing steps) are mutually The connection may vary according to the manner in which the present invention is programmed. Those skilled in the art can implement the above and similar embodiments or configurations of the present invention from the matters disclosed herein.

Claims (10)

A method in which a node between a source node and a destination node in a wireless mesh network selects a route,
A step of setting the path between the transmission source node and the transmission destination node, wherein the path set between the transmission source node and the transmission destination node is a hybrid mesh-on-demand is set based on the type routing and a proactive mesh routing, comprising the steps,
The hybrid mesh-on-demand routing is
Receiving a request message by the node;
A first determination step of determining by the node whether the request message is an initial request message from the source node;
In response to the first determining step, updating a metric in the request message and setting a reverse path to the source node in the routing table of the node;
By the node, a) whether or not the node is the destination node, and b) the node holds a valid unexpired route to the destination node in the routing table. A second determination step of determining one of whether or not,
In response to said second determining step, the transmission to return a response message in unicast to the source node, and wherein the updated metrics to propagate the request message, executes a first executing one of Steps,
In response to the first determining step, comparing the metric in the routing table with the updated metric;
Responsive to the comparing step, updating the reverse path;
Performed in response to said second determination step, it returns a path response message to the source node in unicast and propagate the request message using the updated reverse path, one of and a second execution step of, only including,
Hybrid mesh on demand routing and proactive mesh routing are:
Further comprising supporting non-forwarding mesh nodes participating in the wireless mesh network only as source nodes or destination nodes;
The method, wherein the non-forwarding mesh node does not forward received routing control messages to neighboring nodes . If the non-transfer mesh node needs to transmit data packets, the non-transfer mesh node sends a route request message, the method according to claim 1. Wherein when the non-transfer mesh node is the destination node only, the non-transfer mesh node responds to the route request message, the method according to claim 1. If the non-transfer mesh node is not said destination node, wherein the non-transfer mesh node does not respond to the route request message, the method according to claim 1. The method of claim 1 , wherein the non-forwarding mesh node receives the route announcement message to know the route to the originator of the route announcement message. A device in which a node between a source node and a destination node in a wireless mesh network selects a route,
Means for setting the route between the source node and the destination node, wherein the route set between the source node and the destination node is a hybrid mesh-on-demand is set based on the type routing and a proactive mesh routing includes said means,
The hybrid mesh-on-demand routing is
Means for receiving a request message by said node;
First determination means for determining, by the node, whether the request message is an initial request message from the source node;
Means for updating a metric in the request message and setting a reverse path to the source node in the routing table of the node in response to the operation of the first determining means ;
By the node, a) whether or not the node is the destination node, and b) the node holds a valid unexpired route to the destination node in the routing table. Second determination means for determining one of whether or not,
In response to the operation of the second judging means, first performing said that returns a response message in unicast to the source node, and wherein the updated metrics to propagate the request message, one of the Execution means,
Means for comparing the metric in the routing table with the updated metric in response to the operation of the first determining means ;
Means for updating the reverse path in response to the operation of the means for comparing;
In response to the operation of the second judging means, it returns a path response message to the source node in unicast and propagate the request message using the updated reverse path, one of and second execution means for executing, only including,
Hybrid mesh on demand routing and proactive mesh routing are:
Further comprising means for supporting non-forwarding mesh nodes participating in the wireless mesh network only as source nodes or destination nodes;
The apparatus, wherein the non-forwarding mesh node does not forward the received routing control message to an adjacent node . 7. The apparatus of claim 6 , wherein the non-forwarding mesh node sends a route request message when the non-forwarding mesh node requires transmission of a data packet. 7. The apparatus of claim 6 , wherein the non-forwarding mesh node responds to a route request message only if the non-forwarding mesh node is the destination node. The apparatus of claim 6 , wherein the non-forwarding mesh node does not respond to a route request message if the non-forwarding mesh node is not the destination node. 7. The apparatus of claim 6 , wherein the non-forwarding mesh node receives the route announcement message to know the route to the originator of the route announcement message.

Images