Patent Application
20080170527
The present invention relates generally to wireless communications and more particularly to techniques for determining whether a particular Access Point (AP) is to be designated as an Infrastructure Access Point (IAP) or a Backhaul Mesh Access Point (BMAP).
Types of wireless networks include infrastructure-based wireless networks and ad hoc wireless networks.
Ad hoc networks are self-forming networks which can operate in the absence of any fixed infrastructure, and in some cases the ad hoc network is formed entirely of mobile nodes. An ad hoc network typically includes a number of geographically-distributed, potentially mobile units, sometimes referred to as “nodes,” which are wirelessly connected to each other by one or more links (e.g., radio frequency communication channels). The nodes can communicate with each other over a wireless media without the support of an infrastructure-based or wired network. Links or connections between these nodes can change dynamically in an arbitrary manner as existing nodes move within the ad hoc network, as new nodes join or enter the ad hoc network, or as existing nodes leave or exit the ad hoc network. Because the topology of an ad hoc network can change significantly techniques are needed which can allow the ad hoc network to dynamically adjust to these changes. Due to the lack of a central controller, many network-controlling functions can be distributed among the nodes such that the nodes can self-organize and reconfigure in response to topology changes.
One characteristic of the nodes is that each node can directly communicate over a short range with nodes which are a single “hop” away. Such nodes are sometimes referred to as “neighbor nodes.” When a node transmits packets to a destination node and the nodes are separated by more than one hop (e.g., the distance between two nodes exceeds the radio transmission range of the nodes, or a physical barrier is present between the nodes), the packets can be relayed via intermediate nodes (“multi-hopping”) until the packets reach the destination node. In such situations, each intermediate node routes the packets (e.g., data and control information) to the next node along the route, until the packets reach their final destination. For relaying packets to the next node, each node should maintain routing information collected through conversation with neighboring nodes. The routing information can also be periodically broadcast in the network to reflect the current network topology. Alternatively, to reduce the amount of information transmitted for maintaining accurate routing information, the network nodes may exchange routing information only when it is needed. One approach for routing information, known as Mesh Scalable Routing (MSR), is described in U.S. patent application 20040143842 entitled “System and method for achieving continuous connectivity to an access point or gateway in a wireless network following an on-demand routing protocol, and to perform smooth handoff of mobile terminals between fixed terminals in the network”, filed on Jan. 13, 2004, which is incorporated by reference herein in its entirety. The Mesh Scalable Routing (MSR) defines two types of Access Points (APs): a Mesh Access Point (MAP) and an Infrastructure Access Point (IAP). MAPs can have an infrastructure state and an ad-hoc state, whereas IAPs are statically defined.
The accompanying figures, which together with the detailed description below are incorporated in and form part of the specification, serve to further illustrate various embodiments and to explain various principles and advantages all in accordance with the present invention.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.
Before describing in detail embodiments that are in accordance with the present invention, it should be observed that the embodiments reside primarily in combinations of method steps and apparatus components related to determining whether a particular Access Point (AP) is to be designated as an Infrastructure Access Point (IAP) or a Backhaul Mesh Access Point (BMAP) based on the connectivity of the particular AP to a network. Accordingly, the apparatus components and method steps have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.
In this document, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms “comprises,” “comprising,” or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by “comprises . . . a” does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element.
It will be appreciated that embodiments of the invention described herein may be comprised of one or more conventional processors and unique stored program instructions that control the one or more processors to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions for determining whether a particular Access Point (AP) is to be designated as an Infrastructure Access Point (IAP) or a Backhaul Mesh Access Point (BMAP) based on the connectivity of the particular AP to a network as described herein. The non-processor circuits may include, but are not limited to, a radio receiver, a radio transmitter, signal drivers, clock circuits, power source circuits, and user input devices. As such, these functions may be interpreted as steps of a method for determining whether a particular Access Point (AP) is to be designated as an Infrastructure Access Point (IAP) or a Backhaul Mesh Access Point (BMAP) based on the connectivity of the particular AP to a network. Alternatively, some or all functions could be implemented by a state machine that has no stored program instructions, or in one or more application specific integrated circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic. Of course, a combination of the two approaches could be used. Thus, methods and means for these functions have been described herein. Further, it is expected that one of ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology, and economic considerations, when guided by the concepts and principles disclosed herein will be readily designed to allow generating such software instructions and programs and ICs with minimal experimentation.
The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments. All of the embodiments described in this Detailed Description are exemplary embodiments provided to enable persons skilled in the art to make or use the invention and not to limit the scope of the invention which is defined by the claims.
Overview
In a mesh network, a node's determination of whether it is an IAP or not (and therefore its operational behavior) is determined by the pre-configuration on the AP. However, if connectivity between the IAP and the customer's network fails (e.g., cut wire, router goes down, etc.), then there will be a loss of service to any nodes which are bound to the failed IAP. Moreover, there will be no layer 2 (L2) notification or state change due to the failure of this IAP.
Embodiments of the present invention provide techniques for determining whether a particular Access Point (AP) is to be designated as an Infrastructure Access Point (IAP) or a Backhaul Mesh Access Point (BMAP) based on the connectivity of the particular AP to a network, such as a Customer Enterprise Network (CEN), that includes at least one multicast heartbeat message (MCHBM) source. Although the embodiments described herein refer to determining the connectivity (or loss of connectivity) of a particular Access Point (AP) to a Customer Enterprise Network (CEN) based on a multicast heartbeat message (MCHBM) received from at least one multicast heartbeat message (MCHBM) source that is strategically placed or provided in the CEN, it will be appreciated that the same techniques can be applied in determining the connectivity (or loss of connectivity) of a particular Access Point (AP) to any network, wired backhaul, or wireless backhaul (e.g., a microwave backhaul), based on a multicast heartbeat message (MCHBM) received from at least one multicast heartbeat message (MCHBM) source that is strategically placed or provided in the network, wired backhaul, or wireless backhaul. Connectivity of the particular AP to the MCHBM source in the network requires at least one path along links and/or nodes between the particular AP and the MCHBM source. Loss of connectivity of the particular AP to the MCHBM source in the network generally occurs when at least some of the links and/or nodes between the particular AP and the MCHBM source fail (e.g., there could be a break in the link at the edge network, the WAN network, or even within the CEN, such as, a failure in the firewall of the CEN).
For example, in one embodiment, techniques are provided which can allow an Infrastructure Access Point (IAP) to change its device type to a Backhaul Mesh Access Point (BMAP) device type when the IAP determines that connectivity to a Customer Enterprise Network (CEN) is lost. An all-IAP multicast group is defined which comprises a plurality of member IAPs. The at least one multicast heartbeat message (MCHBM) source can multicast a multicast heartbeat message to the member IAPs of the all-IAP multicast group on a regular basis. Each of the member IAPs can then determine whether it is connected to the Customer Enterprise Network (CEN) based on whether it has received the multicast heartbeat messages.
In another embodiment, techniques are provided which can allow a Backhaul Mesh Access Point (BMAP) to change its device type to an Infrastructure Access Point (IAP) device type when the BMAP determines that connectivity to the Customer Enterprise Network (CEN) is established. The BMAP monitors a port associated with the Customer Enterprise Network (CEN) for multicast heartbeat messages originating from a MCHBM source, and determines whether the BMAP has received a number of multicast heartbeat messages from the MCHBM source within a time interval. The BMAP can determine that it has established connectivity to the Customer Enterprise Network (CEN) when a number of multicast heartbeat messages have been received within a time interval.
The customer enterprise network (CEN) comprises MCHBM source 115 of multicast heartbeat messages (MCHBMs). Although
As used herein, the term “wide area network (WAN)” refers to a computer network covering a broad geographical area. A well-known example of a WAN is the Internet. WANs are used to connect local area networks (LANs) together, so that users and computers in one location can communicate with users and computers in other locations. In this specific example, the MEWAN comprises a network 120 which includes a plurality of routers 122-128 and in one implementation the routers 122-128 can be implemented in the Internet. Each of the routers 122-128 is designed to support a multicast routing algorithm which allows the routers 122-128 to form a multicast tree to deliver multicast heartbeat messages to each IAP in the network.
The MEEN 140 comprises routers 130 A,B. Each of the routers 130 A, B include an Internet Group Management Protocol (IGMP) server (not shown), and support IGMP server functionality which allows the routers 130 A, B to periodically send an IGMP general query to the LAN segments attached to them. For example, each of the routers 130 A, B can have an IGMP server (not shown) which runs an IGMP server protocol to detect the multicast members attached to it (e.g., through a LAN or a point-to-point link). The IGMP is a communications protocol used to manage the membership of Internet Protocol (IP) multicast groups. IGMP is used by IP hosts and adjacent multicast routers to establish multicast group memberships. In one exemplary implementation, the IGMP query interval can be 15 seconds.
A member IAP 170 defines a wireless mesh domain 180, another member IAP 172 defines another wireless mesh domain 182, and a plurality of other member IAPs 174 each define their own corresponding wireless mesh domains (not shown).
The CEN 110 assigns a multicast IP address for the all-IAP multicast group (e.g., 224.0.2.0), and forms a multicast group for all IAPs in the network with an unused multicast address within a range (e.g., a range of 224.0.2.0 to 238.255.255.255).
The MCHBM source 115 transmits a multicast heartbeat message (MCHBM) on a regular basis to member IAPs 170, 172, 174 of the all-IAP multicast group. For example, the MCHBM source 115 can run a specialized multicast application that generates the MCHBM on a regular basis, and then sends the MCHBM to all member IAPs 170, 172, 174 of the all-IAP multicast group. The multicast heartbeat message (MCHBM) is represented in
The various member IAPs 170, 172, 174 each have IGMP client functionality so that the various member IAPs 170, 172, 174 can subscribe to or join an “all-IAP multicast group.” For example, the member IAPs 170, 172, 174 each run IGMP client protocol to send a IGMP membership report to their respective first-hop multicast routers to join the all IAP multicast group and respond a subsequent periodic IGMP query from their respective first-hop multicast routers.
Each of the member IAPs 170, 172, 174 of the all IAP multicast group can use the MCHBM to determine whether that particular member IAP is to be designated as an Infrastructure Access Point (IAP) or a Backhaul Mesh Access Point (BMAP) based on the connectivity of the particular member IAP to the MCHBM source 115 of the CEN 110. For example, each of the member IAPs 170, 172, 174 can include a multicast processing engine or application which allows them to receive a multi-cast heartbeat message (MCHBM) transmitted from the MCHBM source 115, and process the MCHBM to detect their respective connection status to the MCHBM source 115 of the CEN 110 as will be described below with reference to
Switching from IAP Mode to BMAP Mode
When the method 300 begins at step 310, the MCHBM source transmits a multicast heartbeat message (MCHBM) on a regular basis to member IAPs 270, 272 of the all-IAP multicast group. For example, the MCHBM source can run a specialized multicast application that generates the MCHBM on a regular basis, and then multicasts the MCHBM to all member IAPs 270, 272 of the all-IAP multicast group. In one implementation, the MCHBM can be sent periodically at a fixed “heartbeat interval” from each source in the CEN. Each member IAPs 270, 272 of the all-IAP multicast group can use the MCHBM to determine its connectivity to the MCHBM source 115 of the CEN 110, and whether that particular member IAP is to be designated as an Infrastructure Access Point (IAP) or a Backhaul Mesh Access Point (BMAP). It will be appreciated that while this exemplary implementation refers to a single source, in other implementations, there can be multiple sources in a CEN generating their own MCHBMs.
At step 320, each of the member IAPs 270, 272 of the all IAP multicast group can determine whether the particular member IAP has failed to receive a MCHBM (or a certain number of MCHBMs) within the last X seconds, where X is a time period or duration that is set depending on the specific implementation. For example, each of the member IAPs 270, 272 can include a multicast processing engine or application which allows them to receive a MCHBM transmitted from the source (or sources) 115, and process the MCHBM. There are numerous techniques which could be used to determine whether the particular member IAP has failed to receive the MCHBM within a certain time period. For example, the member IAPs 270, 272 of the all IAP multicast group can listen for a MCHBM to confirm that they are connected to the MCHBM source 115 of the CEN 110 (e.g., to confirm that the CEN is “alive”), and when a member IAP of the all IAP multicast group misses the MCHBMs from the MCHBM source for a certain duration (e.g., 60 seconds), that member IAP assumes that connectivity to the CEN 110 has been lost. One exemplary implementation of step 320 will be described below with reference to
If the particular member IAP determines that it has received the MCHBM within the time period, then the method 300 loops back to step 320 after a delay.
By contrast, if the particular member IAP determines that it has failed to receive the MCHBM within the time period, then at step 330, the particular member IAP determines that its connection to the CEN 110 has been lost, and at step 340, the particular member IAP changes its device type to a BMAP and enables BMAP functionality to start operating in BMAP mode.
Method 400 starts at step 422 where the particular member IAP monitors the CEN 110 network for a MCHBM from the MCHBM source 115 in the CEN 110. At step 423, the particular member IAP determines whether a “heartbeat” window has expired. For example, in one implementation, the heartbeat window can be set for a particular duration (e.g., 60 seconds), and a time-based counter (e.g., a counter which uses internal clocking source) continuously runs, and records the amount of time passed since the last reception of a MCHBM.
If the particular member IAP determines that the “heartbeat” window has not expired (e.g., the member IAP has received a MCHBM from the MCHBM source 115 within the window period), then the method 420 proceeds to step 424 where the particular member IAP filters the MCHBM, and at step 425 resets its missed heartbeat counter. Without step 424, the particular member IAP would propagate the multicast packet on each of its interfaces with membership. Neighboring wireless mesh devices listening to the multicast group will falsely perceive that they were directly connected to the WAN since they are receiving the MCHBM. This can result in the device converting to an IAP. This becomes particularly important for a BMAP that is looking for MCHBMs to determine when to convert back to an IAP. Without this filtering step 424, the network would cause the BMAP to determine that it has WAN connectivity. The method 400 then loops back to step 422.
If the particular member IAP determines that the “heartbeat” window has expired (e.g., the member IAP has not received a MCHBM from the MCHBM source 115 within the window period), then the method 420 proceeds to step 426 where the particular member IAP increments its missed heartbeat counter.
The method 420 proceeds to step 427 where the particular member IAP determine whether the number of missed MCHBMs exceeds a threshold number of MCHBMs (e.g., four MCHBMs). If the number of missed MCHBMs is less than or equal to the threshold number of MCHBMs, then the method 420 loops back to step 422 and the method 420 repeats. If the number of missed MCHBMs is greater than the threshold number of MCHBMs, then the method 420 proceeds to step 330 in
After detecting loss of MCHBM messages, IAP1270 begins operating as a BMAP 570, establishes a connection to the network via MAP2590 and IAP2572.
During the BMAP operation, the BMAP keeps its membership in the all-IAP multicast group, and continues to monitor a port associated with the CEN 110 to detect MCHBMs from the MCHBM source 115 of the CEN 110. While operating in BMAP mode, the BMAP continues to receive general IGMP queries that are flooded throughout the network. The BMAP will respond to any IGMP queries it receives by transmitting an IGMP report for the all-IAP group on the WAN port and optionally on the wireless side. In one embodiment, this allows the all-IAP multicast group to be extended in the wireless mesh. However, the IAP will prevent the MCHBMs from being propagated into the wireless mesh. In another embodiment, even though the IGMP report for the all-IAP multicast group is optionally transmitted on the wireless interface, a mesh core/Wireless Distribution System (WDS) module in the BMAP will not trigger generation of a layer 2 wireless mesh multicast tree for the all-IAP multicast group, thus the MCHBMs are prevented from being propagated into the wireless mesh.
As described below, the BMAP 570 switches back to an IAP when it detects MCHBM on its WAN port. The BMAP 570 will not receive MCHBMs on its wireless interface. Operations of the BMAP 570 within the network 500 when changing its device type from a BMAP to an Infrastructure Access Point (IAP) device type will now be described with reference to
Switching from BMAP Mode to IAP Mode
The method 600 starts at step 610, where the BMAP monitors a port associated with the CEN 110 for MCHBMs originating from the backhaul (i.e., MCHBM source(s) 115 of the CEN 110), and at step 620, the BMAP determines whether it has received a number of MCHBMs from the source(s) within a time interval. For example, in one implementation of step 620, the BMAP can use its multicast processing engine to receive and process MCHBMs transmitted from the MCHBM source 115 (or sources) to determine whether it hears a number (n) of MCHBMs during a time period of y seconds. There are numerous techniques which could be used to determine whether the BMAP has received the MCHBM within this time period. One exemplary implementation of step 620 will be described below with reference to
When the BMAP determines that it has not received the number of MCHBMs from the source(s) within the time interval, then after a delay, the method 600 loops back to step 610.
By contrast, when the BMAP determines that it has received the number of MCHBMs from the source(s) within the time interval, then the method 600 proceeds to step 630 where the BMAP determines that connectivity to at least one of the MCHBM source(s) 115 of the CEN 110 has been recovered. At step 640, the BMAP changes its device type to an IAP and reconfigures itself to begin operating in normal IAP mode. For instance, the BMAP will be advertising itself as an IAP.
Notably, the operation of the BMAP is different from that of a regular IAP. For example, when reconfigured as a “BMAP,” the BMAP stops advertising itself as an IAP, and starts to advertise itself as an MAP. Further, it establishes a route to an IAP if it can detect one or otherwise it enters “ad hoc” mode.
Method 720 starts at step 722 where the BMAP monitors the CEN 110 for a MCHBM from the MCHBM source 115 of the CEN 110 to determine whether a “heartbeat” window has expired. For example, the BMAP can determine whether the BMAP has received a number of MCHBMs (e.g., three MCHBMs) from the MCHBM source within a heartbeat window or heartbeat duration. In one exemplary implementation, the heartbeat window can be set for a certain duration (e.g., 60 seconds).
If the BMAP determines that the “heartbeat” window has expired (e.g., the BMAP has not received the number of MCHBMs from the MCHBM source 115 within the window period), then the method 720 proceeds to step 724 where the BMAP resets its “found” heartbeat counter, and then loops back to step 610 in
If the BMAP determines that the “heartbeat” window has not expired (e.g., the BMAP has received the number of MCHBMs from the MCHBM source 115 within the window period), then the method 720 proceeds to step 726 where the BMAP increments its found heartbeat counter. The method 720 then proceeds to step 728 where the BMAP determines whether the number of found MCHBMs exceeds a threshold number of MCHBMs (e.g., four MCHBMs).
If the number of found MCHBMs is less than or equal to the threshold number of MCHBMs, then the method 720 loops back to step 610 of
Notably, the operation of the IAP is different from that of a BMAP. For example, when reconfigured as an “IAP,” the IAP will start advertising itself as an IAP (i.e., it is connected to the MCHBM source 115 of the CEN 110), and resume the IAP functionality as a mesh gateway node.
In the foregoing specification, specific embodiments of the present invention have been described. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the present invention as set forth in the claims below.
Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of present invention. The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential features or elements of any or all the claims. The invention is defined solely by the appended claims including any amendments made during the pendency of this application and all equivalents of those claims as issued.
