The present invention relates generally to wireless networks and in particular to a layer 2 method for testing links in a wireless network.
In recent years, a type of mobile communications network known as an “ad-hoc” network has been developed. In this type of network, each mobile node is capable of operating as a base station or router for the other mobile nodes, thus eliminating the need for a fixed infrastructure of base stations. As can be appreciated by one skilled in the art, network nodes transmit and receive data packet communications in a multiplexed format, such as time-division multiple access (TDMA) format, code-division multiple access (CDMA) format, or frequency-division multiple access (FDMA) format.
More sophisticated ad-hoc networks are also being developed which, in addition to enabling mobile nodes to communicate with each other as in a conventional ad-hoc network, further enable the mobile nodes to access a fixed network and thus communicate with other mobile nodes, such as those on the public switched telephone network (PSTN), and on other networks such as the Internet.
In a wireless network, links between nodes are typically tested by passing data between those nodes. In some adhoc wireless networks, such as a mesh network, the data may not go directly (1 hop) to the destination. In such networks, for example, routing algorithms choose the best path. It would be beneficial to thus ignore the path chosen by routing.
Some systems use feedback from transmission attempts to characterize the quality of the link to the destination node. This typically occurs during network deployment and when analyzing an already deployed network.
A common way to test connectivity is to generate traffic using an application that uses layer 3 protocols, such as ‘ping’ or ‘iperf’. Ping tests whether another node is reachable by sending an Internet Control Message Protocol (ICMP) request message. An ICMP echo reply is expected to be returned if the node is reachable. Iperf is a tool to measure maximum Transmission Control Protocol (TCP) bandwidth, allowing the tuning of various parameters and User Datagram Protocol (UDP) characteristics. Iperf reports bandwidth, delay jitter, datagram loss. These methods are inadequate to test a link between nodes in some adhoc networks such as a mesh network because they are ignorant of the path taken to get from the source to the destination. For example, take a mesh network comprised of 3 nodes: A, B, and C. The desire is to test the link between nodes A and C, but the routing algorithms create a route from A to C through node B. There is no way for an application like ping to ignore the route and force A to communicate directly with C.
The accompanying figures, where like reference numerals refer to identical or functionally similar elements throughout the separate views and 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 a method for testing links in a wireless 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, top and bottom, 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 of a method for testing links in a wireless network 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 to perform a method for testing links in a wireless 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 capable of generating such software instructions and programs and ICs with minimal experimentation.
A method and apparatus for testing links in a wireless adhoc network is described herein. The present invention includes a protocol for allowing devices to send test data packets between links using layer 2 Media Access Controls (MAC) addresses. A specialized “Layer 2 Ping” packet is used allowing the protocol to bypass the normal network routing tables, if needed, to send packets directly to a node.
As can be appreciated by one skilled in the art, the nodes 102, 106 and 107 are capable of communicating with each other directly, or via one or more other nodes 102, 106 or 107 operating as a router or routers for packets being sent between nodes.
As illustrated, the node 200 includes an antenna 205, a transceiver (or modem) 210, a controller 215, and a user interface 225. The antenna 205 intercepts transmitted signals from one or more nodes 102, 106, 107 within the adhoc wireless network 100 and transmits signals to the one or more nodes 102, 106, 107 within the adhoc wireless network 100.
The antenna 205 is coupled to the transceiver 210, which employs conventional demodulation techniques for receiving and transmitting communication signals, such as packetized signals, to and from the node 200 under the control of the controller 215. The packetized data signals can include, for example, voice, data or multimedia information, and packetized control signals, including node update information. When the transceiver 210 receives a command from the controller 215, the transceiver 210 sends a signal via the antenna 205 to one or more devices within the ad-hoc wireless communications network 100. In an alternative embodiment (not shown), the node 200 includes a receive antenna and a receiver for receiving signals from the ad-hoc wireless communications network 100 and a transmit antenna and a transmitter for transmitting signals to the ad-hoc wireless communications network 100. It will be appreciated by one of ordinary skill in the art that other similar electronic block diagrams of the same or alternate type can be utilized for the node 200.
Coupled to the transceiver 210, is the controller 215 utilizing conventional signal-processing techniques for processing received messages. It will be appreciated by one of ordinary skill in the art that additional processors can be utilized as required to handle the processing requirements of the controller 215.
In accordance with the present invention, the controller 215 includes a link test manager 230 for managing the testing of links in which the node 200 is connected within the adhoc wireless communication network 100. It will be appreciated by those of ordinary skill in the art that the link test manager 230 can be hard coded or programmed into the node 200 during manufacturing, can be programmed over-the-air upon customer subscription, or can be a downloadable application. It will be appreciated that other programming methods can be utilized for programming the link test manager 230 into the node 200. It will be further appreciated by one of ordinary skill in the art that the link test manager 230 can be hardware circuitry within the node 200. In accordance with the present invention, the link test manager 230 can be contained within the controller 215 as illustrated, or alternatively can be an individual block operatively coupled to the controller 215 (not shown).
To perform the necessary functions of the node 200, the controller 215 is coupled to the memory 220, which preferably includes a random access memory (RAM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), and flash memory. The memory 220, in accordance with the present invention, includes storage locations for the storage of link test preferences 235, link test parameters, 240, and the like.
The link test preferences 235, for example, can include run link test in response to a message received from the adhoc wireless network 100, run link test in response to a user input to the user interface 225, or run link test in response to a pre-programmed event or condition (time, location, and the like).
The link test parameters 240, for example, can include directionality (bidirectional or omnidirectional), destination preferences, transmission interval, payload size (data load) maximums, and routes that should be ignored.
It will be appreciated by those of ordinary skill in the art that the memory 220 can be integrated within the node 200, or alternatively, can be at least partially contained within an external memory such as a memory storage device. The memory storage device, for example, can be a subscriber identification module (SIM) card. A SIM card is an electronic device typically including a microprocessor unit and a memory suitable for encapsulating within a small flexible plastic card. The SIM card additionally includes some form of interface for communicating with the node 200.
Preferably, the user interface 225 is coupled to the controller 215. The user interface 225 can include a keypad such as one or more buttons used to generate a button press or a series of button presses. The user interface 225 can also include a voice response system or other similar method of receiving a manual input initiated by the device user. The controller 215, in response to receiving a user input via the user interface 225 performs commands as required. It will be appreciated by those of ordinary skill in the art that the user interface 225 can be utilized to perform various functions and make various operational choices for functioning of the node 200. For example, the user interface 225 can be used to provide inputs to the link test manager 230 for performing a layer 2 link test in accordance with the present invention.
Specifically, in accordance with the present invention, a message can be sent between node D (320) and node A (305) which allows the two devices to send test data packets between links using layer 2 MAC addresses. An API is defined which includes the destination MAC, the size of the test packet, whether the test packet should be routed or sent directly, the frequency of packet generation, whether the destination should reply to the test packet, a time interval to generate test packets, and a method to stop the generation of test packets before the time interval has expired.
As illustrated in
When a link test is required/desired in Step 405, the operation continues with Step 410 in which the link test manager 230 of the node 200 obtains the destination MAC associated with the required link test. In one embodiment, a destination MAC associated with each link in which the node 200 is currently operating can be stored in the memory 220 (i.e. within the link test parameters 240) of the node 200 for use in Step 410 as needed. In another embodiment, a user input to the user interface 225 of the node 200 provides the destination MAC. In another embodiment, the node 200 receives a message including the destination MAC. The destination MAC, for example, can be included in the message indicating a link test requirement from another node in the network 100 or in a separate message. The destination MAC, for example can be the destination MAC of node A 305 to node D 320 for a link test of link 340 of
Next, in Step 415, the node 200 obtains the test packet size for the required link test. In one embodiment, the test packet size associated with each link in which the node 200 is currently operating can be stored in the memory 220 (i.e. within the link test parameters 240) of the node 200 for use in Step 415 as needed. In another embodiment, a user input to the user interface 225 of the node 200 provides the test packet size. In another embodiment, the node 200 receives a message including the test packet size. The test packet size, for example, can be included in the message indicating a link test requirement from another node in the network 100 or in a separate message.
Next, in Step 420, the process determines whether the test packet should be routed or sent directly. When the test packet is to be sent directly in Step 420, the operation continues to Step 425 in which the test packet is prepared to send directly. To illustrate, in the network 300 of
After Steps 425 and 430, the operation continues with Step 435 in which the node 200 obtains the packet generation frequency. In one embodiment, the packet generation frequency associated with each link in which the node 200 is currently operating can be stored in the memory 220 (i.e. within the link test parameters 240) of the node 200 for use in Step 410 as needed. In another embodiment, a user input to the user interface 225 of the node 200 provides the packet generation frequency. In another embodiment, the node 200 receives a message including the packet generation frequency. The packet generation frequency, for example, can be included in the message indicating a link test requirement from another node in the network 100 or in a separate message.
Next, in Step 440, the node 200 obtains the time interval to generate test packets for the link test. In one embodiment, the time interval associated with each link in which the node 200 is currently operating can be stored in the memory 220 (i.e. within the link test parameters 240) of the node 200 for use in Step 410 as needed. In another embodiment, a user input to the user interface 225 of the node 200 provides the time interval. In another embodiment, the node 200 receives a message including the time interval. The time interval, for example, can be included in the message indicating a link test requirement from another node in the network 100 or in a separate message.
Next, in Step 445, the node 200 determines whether or not the destination node should reply to the test packet. In one embodiment, the reply requirement associated with each link in which the node 200 is currently operating can be stored in the memory 220 (i.e. within the link test parameters 240) of the node 200 for use in Step 410 as needed. In another embodiment, a user input to the user interface 225 of the node 200 provides the reply requirement. In another embodiment, the node 200 receives a message including the reply requirement. The reply requirement, for example, can be included in the message indicating a link test requirement from another node in the network 100 or in a separate message. When a reply is required by the destination in Step 445, the operation continues to Step 450 in which a parameter is set to indicate a requested reply from the destination. When no reply is required in Step 445 and after Step 450, the operation continues to Step 455 in which the link test is performed using all the parameters previously described herein. Optionally, each test packet can be tagged as a request test packet for the link test. The operation then cycles back to the standby mode Step 400 and periodically to Step 405 to determine if another link test is required/desired.
As illustrated in
When a reply is requested or required in Step 505, the operation continues with Step 510 in which the receiving node obtains the destination MAC associated with the required link test. In one embodiment, the test packet received includes the destination MAC. The destination MAC, for example can be the destination MAC of node A 305 for replying to a test packet received from node D 320 in association with a link test of link 340 of
Next, in Step 515, the receiving node obtains the test packet size for the required link test. In one embodiment, the receiving node receives the test packet size within or along with the test packet. In another embodiment, the test packet size associated with each link in which the receiving node is currently operating can be stored in the memory (i.e. within the link test parameters) of the receiving node for use in Step 515 as needed. In another embodiment, a user input to the user interface 225 of the receiving node provides the test packet size.
Next, in Step 520, the process determines whether the reply should be routed or sent directly. When the reply is to be sent directly in Step 520, the operation continues to Step 525 in which the reply is prepared to send directly. To illustrate, in the network 300 of
After Steps 525 and 530, the operation continues with Step 535 in which the reply is sent using all the parameters previously described herein. Optionally, each reply can be tagged as a reply test packet for the link test.
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.