JP4733489B2 - Detect and diagnose performance problems in wireless networks by collaborating with neighboring devices - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a system and a method for detecting and diagnosing a problem of performance in a radio communication network. <P>SOLUTION: A diagnosis program for diagnosing the problem in the network jointly is executed on a radio device, an adjacent device, and a radio access point. The adjacent device intercepts the diagnosis session between the device and the access point to determine the problem in the device, access point, and radio media. Data from an interception device are summarized and are transmitted to a network manager for succeeding action. The diagnosis program is described so that it includes a passive component for detecting the problem, and an active one for executing a diagnosis technique. <P>COPYRIGHT: (C)2007,JPO&amp;INPIT

Description

  The present invention relates generally to network operation, and more particularly to diagnosing performance problems in wireless networks.

  The convenience of wireless network connection has led to large-scale adoption of wireless networks (eg, IEEE 802.11 networks). Companies, universities, homes, and public places are deploying such networks at a surprising rate. However, a significant number of “pain points” remain for end users and network administrators. Users experience several problems such as occasional broken connections, poor performance, lack of coverage, and authentication failures. These problems arise due to a variety of reasons, such as poor access point placement, device misconfiguration, hardware and software errors, the nature of the wireless medium (eg, interference, propagation), and traffic congestion. Users are frequently dissatisfied with connectivity and performance issues, and network administrators are expected to diagnose these issues when managing company security and coverage. Administrator tasks are particularly difficult due to the unreliable nature of the wireless medium and the lack of intelligent diagnostic tools to determine the cause of these problems.

  An enterprise that has a large deployment of an IEEE 802.11 network may have thousands of access points (APs) that span many buildings. The problems associated with such networks result in end-user frustration and lost productivity for the company. Furthermore, resolving each end user's dissatisfaction results in additional support labor costs for the company's IT department. This cost can be in the tens of dollars and does not include costs due to end user productivity loss.

Zhang et al., "On the Characteristics and Origins of Internet Flow Rates", Proceedings of ACM SIGCOMM, August 2002 Floyd et al., "Equation-Based Congestion Control for Unicast Applications", Proceedings of ACM SIGCOMM, August 2000 Allman et al., "Estimating Loss Rates with TCP", ACM Perf. Evaluation Review 31 (3), December 2003 W. Richard Stevens, "The Protocols (TCP / IP Illustrated, Vol. I)", Addison Wesley, 1994

  Failure diagnosis in an IEEE 802.11 infrastructure network has not received much attention from research groups as compared to other research fields with a relatively high degree of attention in wireless network connection. Some companies are trying to provide diagnostic tools, but these products lack some desirable features. For example, these products do not perform the comprehensive task of collecting and analyzing data to identify possible causes of problems. Furthermore, most products typically only collect data from the AP and ignore viewing the network from the client side. Some products that monitor the network from the client's point of view require hardware sensors, which can be costly to deploy and maintain. Also, current solutions typically do not provide any support for disconnected clients, even those that need the most help.

  The problems outlined above can be addressed, at least in part, by the systems and methods for detecting and diagnosing faults in a wireless network as described herein.

  The following presents a simplified summary of the disclosure in order to provide the reader with a basic understanding of some aspects of the disclosure. This summary is not an exhaustive or limiting summary of the disclosure. This summary is not intended to identify key and / or critical elements of the invention, to delineate the scope of the invention, or to limit the scope of the invention. Its sole purpose is to present some of the disclosed concepts in a simplified form as a prelude to the more detailed description that is presented later.

  In one embodiment, the systems and methods described herein can be utilized to analyze performance problems encountered in wireless LAN deployments. A flexible architecture for detecting and diagnosing faults in infrastructure wireless networks is also described. By applying instrumentation to wireless clients (and access points where possible) to monitor nearby wireless media and devices, this architecture enables proactive and reactive fault diagnosis. Both can be supported. This monitoring framework can be used to address some of the problems that plague wireless users.

  In one embodiment, a computer-readable medium is provided that includes computer-executable instructions that facilitate diagnosis of a communication problem that occurs at a first wireless computing device in a wireless network, the wireless network comprising: a first wireless computing device; A computer-executable instruction comprising a wireless access point is executed on a first wireless computing device to determine whether a communication problem exists in the wireless network and a request to assist in diagnosing the communication problem Broadcast to one or more neighboring wireless computing devices, responding to a snoop request sent by the wireless access point in a diagnostic session, and fewer neighboring wireless computing devices Since also one implement and receiving information about the diagnostic session.

  In another embodiment, a diagnostic system for diagnosing problems on a computer network that includes both a wireless portion between a first wireless computing device and a wireless access point and a wired portion between an access point and an infrastructure network And the diagnostic system comprises a client diagnostic program executed on the first wireless computing device and an access point diagnostic program executed on the wireless access point, the access point diagnostic program being a client diagnostic program To determine if a network connection problem occurred in the wired or wireless part of the network.

  In yet another embodiment, a computer-readable medium is provided that includes computer-executable instructions that facilitate diagnosing a communication problem that occurs at a first wireless computing device in a wireless network, the computer-executable instructions being a second wireless device. Executing on the computing device and receiving a request for diagnostic help from the first wireless computing device; between the wireless environment and the first wireless computing device and the one or more wireless access points; By monitoring the traffic flow, the steps of accumulating performance data and transmitting a summary of the accumulated performance data are performed.

  While the appended claims specifically define the features of the present invention, the invention and its advantages can best be understood by reading the following detailed description in conjunction with the accompanying drawings, in which:

  Although methods and systems for detecting and diagnosing wireless network performance problems are described with reference to particular embodiments, the methods and systems of the present invention are not so limited. Further, those skilled in the art will readily appreciate that the methods and systems described herein are exemplary only and that variations are possible without departing from the spirit and scope of the invention. After reviewing this description, it will be apparent to those skilled in the art that the above description is provided by way of example only, and not limitation. Numerous variations and other exemplary embodiments are within the scope of those skilled in the art and are contemplated within the scope of the present invention. In particular, many of the examples presented herein involve method operations or specific combinations of system elements, but such operations and elements are combined in other ways to achieve the same purpose. It should be understood that it is also possible. Operations, elements, and features discussed only in connection with one embodiment are not intended to be excluded from a similar role in other embodiments. Further, in the claims, ordering terms such as “first” and “second” are used to modify an element of a claim, but as such, by itself, Does not imply any priority, advantage, or order over another element, nor does it imply a chronological order in which the operations of the method are performed, elements of a claim with a name have the same name It is used to distinguish these multiple claim elements as merely a label to distinguish them from other elements (except for the use of ordering terms).

  Listed below are many of the problems faced by users and network administrators when using and maintaining enterprise wireless networks.

  Connectivity issues: End users are unhappy with inconsistent network connectivity or lack of network connectivity in certain areas of the building. Such “dead spots” or “RF holes” can occur due to weak RF signals, lack of signals, changes in environmental conditions, or obstacles. Automatic discovery of RF holes is important for radio administrators. The administrator then adjusts the power settings on nearby APs to reposition this problem by relocating APs within the problematic area or increasing AP congestion or to improve coverage. It can be solved by doing.

  Performance issues: This category includes all situations where the client perceives performance degradation, eg, low throughput or long latency. For example, slow traffic due to congestion, RF interference due to microwave ovens or cordless phones, multipath interference, large co-channel interference due to poor network planning or poorly configured client / AP, etc. There can be several reasons why performance problems exist. Performance problems may occur as a result of problems in the non-wireless part of the network, for example due to slow servers or proxies. Therefore, it is useful that the diagnostic tool can determine whether the problem is inside the wireless network or elsewhere. In addition, identification of the cause in the wireless part is important to allow network administrators to better provide the system for end users and improve experience.

  Network security: Large enterprises often use solutions such as IEEE 802.1x to protect corporate networks. However, the worst scenario for IT managers is that employees unknowingly compromise network security by connecting unauthorized APs to the corporate network's Ethernet tap. Is the time. This problem is commonly referred to as the “Rogue AP Problem”. Such unauthorized APs are one of the most common and serious flaws in wireless network security. Because of such APs, external users are allowed access to resources on the company network. These users can leak information or cause other damage. Furthermore, unauthorized APs can cause interference with other access points in the vicinity. Detection of unauthorized APs by manual processes in large networks is costly and time consuming. Therefore, it is important to detect such AP proactively.

  Authentication problems: According to IT support group logs, some dissatisfaction is related to the user not being able to authenticate themselves to the network. In wireless networks protected by technologies such as IEEE 802.1x, authentication failures are usually due to lost or revoked certificates. It is therefore important to detect such authentication problems and help the client boot with a valid certificate.

  The invention will be more fully understood when the following detailed description is read in conjunction with the accompanying drawings. In this description, like numbers refer to similar elements in the various embodiments of the invention.

  Aspects of the invention are illustrated as being implemented in a suitable computing environment. Although not required to do so, the invention is described in the general context of computer-executable instructions, such as procedures, being executed by a personal computer. Generally, procedures include program modules, routines, functions, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Further, those skilled in the art will appreciate that the present invention can be implemented using other computer system configurations including handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. You will understand. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote memory storage devices. The term computer system can be used to refer to a system consisting of computers, as can be seen in a distributed computing environment.

  FIG. 1 illustrates an example computing system environment 100 in which aspects of the invention may be implemented. The computing system environment 100 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the computing environment 100 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment 100. While at least one embodiment of the present invention includes each component shown in the exemplary operating environment 100, in another more typical embodiment of the present invention, some or all of the non-essential components, eg, network communications Does not include input / output devices other than those required.

  With reference to FIG. 1, an exemplary system for implementing the invention includes a general purpose computing device in the form of a computer 110. The components of computer 110 may include, but are not limited to, processing unit 120, system memory 130, and system bus 121 that couples various system components such as system memory to processing unit 120. The system bus 121 may be any of several types of bus structures such as a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example and not limitation, such architectures include ISA (Industry Standard Architecture) bus, MCA (Micro Channel Architecture) bus, EISA (Extended ISA) bus, VESA (National Video Electronics Standards Association) local bus, mezzanine bus Includes a PCI (Peripheral Device Interconnect) bus, also known as.

  Computer 110 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 110 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may include computer storage media and communication media. Computer storage media is volatile and non-volatile media, removable media and non-removable media implemented in any method or technique for storing information such as computer readable instructions, data structures, program modules, or other data including. Computer storage media can be RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, DVD (Digital Versatile Disc) or other optical disk storage, magnetic cassette, magnetic tape, magnetic disk storage or other Or any other medium that can be used to store desired information and that can be accessed by computer 110. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Any combination of the above should also be included within the scope of computer-readable media.

  The system memory 130 includes computer storage media in the form of volatile and / or nonvolatile memory such as ROM (Read Only Memory) 131 and RAM (Random Access Memory) 132. The BIOS (basic input / output system) 133 includes a basic routine that assists in transferring information between elements inside the computer 110 during startup, for example, and is normally stored in the ROM 131. RAM 132 typically contains data and / or program modules that are immediately accessible to and / or currently being operated on by processing unit 120. By way of example and not limitation, FIG. 1 shows an operating system 134, application programs 135, other program modules 136, and program data 137.

  The computer 110 may also include other removable / non-removable, volatile / nonvolatile computer storage media. By way of example only, FIG. 1 illustrates a hard disk drive 141 that reads from or writes to a fixed non-volatile magnetic medium, and a magnetic disk drive 151 that reads from or writes to a removable non-volatile magnetic disk 152. And an optical disk drive 155 that reads from or writes to a removable non-volatile optical disk 156, such as a CD ROM or other optical media. Other removable / non-removable, volatile / nonvolatile computer storage media that can be used in the exemplary operating environment include magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tapes, solid state RAM, Including but not limited to solid state ROM. Hard disk drive 141 is typically connected to system bus 121 by a fixed memory interface such as interface 140, and magnetic disk drive 151 and optical disk drive 155 are typically connected to system bus 121 by a removable memory interface such as interface 150. The

  The disk drive and associated computer readable media described above and illustrated in FIG. 1 allow for the storage of computer readable instructions, data structures, program modules, and other data for the computer 110. In FIG. 1, for example, the hard disk drive 141 is shown as storing an operating system 144, application programs 145, other program modules 146, and program data 147. Note that these components can either be the same as or different from operating system 134, application programs 135, other program modules 136, and program data 137. Operating system 144, application program 145, other program modules 146, and program data 147 are given different numbers here to indicate that they are at least different. A user may enter commands and information into the computer 110 through pointing devices 161, commonly referred to as a tablet or electronic digitizer, microphone, keyboard 162 and mouse, trackball or touch pad. Other input devices (not shown) may include joysticks, game pads, satellite dish antennas, scanners, and the like. These and other input devices are often connected to the processing unit 120 via a user input interface 160 coupled to the system bus, but other interfaces and buses such as parallel ports, game ports, USB (Universal Serial Bus), etc. It can also be connected by structure. A monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190. The monitor 191 can also be integrated with a touch screen panel or the like. It should be noted that the monitor and / or touch screen panel can be physically coupled to the housing in which the computing device 110 is incorporated, such as in a tablet-type personal computer. In addition, a computer such as computing device 110 may also include other peripheral output devices such as speaker 197 and printer 196 that may be connected via output peripheral interface 195 or the like.

  Computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as remote computer 180. The remote computer 180 may be a personal computer, server, router, network PC, peer device, or other common network node, and typically includes many or all of the elements described above in connection with the computer 110, although FIG. Only the memory storage device 181 is shown. The logical connections shown in FIG. 1 include a LAN (Local Area Network) 171 and a WAN (Wide Area Network) 173, but can also include other networks. Such network environments are commonplace in companies, enterprise-wide computer networks, intranets and the Internet.

  When used in a LAN network environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN network environment, the computer 110 typically includes a modem 172 or other means of establishing communications over a WAN 173, such as the Internet. The modem 172 can be internal or external and can be connected to the system bus 121 via the user input interface 160 or other suitable mechanism. In a networked environment, the program modules illustrated in connection with computer 110 or portions thereof may be stored in a remote memory storage device. By way of example and not limitation, FIG. 1 illustrates remote application program 185 as resident in memory device 181. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers can be used. Specifically, the computer 110 preferably includes a wireless network interface or wireless card that operates in accordance with the IEEE 802.11 protocol.

  In an embodiment of the present invention, the system consists of several components as shown in FIG. The client diagnosis (DC) 202 is software executed on the wireless client machine 204. AP diagnostics (DAP) 206 is performed on the access point 208. Server diagnostics (DS) 210 is executed on the back-end server 212 of the organization.

  In some embodiments of the invention, the client diagnostic module 202 monitors the RF environment and traffic flows from neighboring clients 214 and APs 216. While operating normally, the client's wireless card is not placed in promiscuous mode. The DC 202 performs local fault diagnosis using the collected data. Depending on the particular fault detection mechanism, this summary of data is transmitted to the DAP 206 or DS 210, preferably at regular intervals. In addition, the DC 202 is programmed to accept commands from the DAP 206 or DS 210 to perform on-demand data collection, for example, switch to promiscuous mode and analyze performance issues for nearby clients. When the wireless client 204 is disconnected, the DC 202 records a data log in the local database / file. This data can be analyzed by DAP 206 or DS 210 when network connectivity is restored in the future.

  AP diagnostics 206 accepts diagnostic messages from DC 202, merges these messages with its own measurement results, and sends a summary report to DS 210. Some embodiments of the present invention do not include an AP diagnosis 206. The DAP 206 reduces the work load on the DS 210. Some embodiments of the present invention include a mixture of legacy AP 220 and DAP 206. If the AP is a legacy AP 220 (eg, an AP that does not perform AP diagnostics), the AP monitoring function is performed by the DC 202, and the AP summarization function and investigation is performed by the DS 210.

  Server diagnostic 210 accepts data from DC 202 and DAP 206 and performs appropriate analysis to detect and diagnose various faults. The DS 210 also has access rights to the database 221 that stores the location of each AP 208. To balance the load, the network administrator can deploy multiple DSs 210 in the system, for example, by hashing each AP's MAC address to a particular DS 210. In some embodiments, server diagnostics 210 interacts with other network servers, such as RADIUS 230 and Kerberos 232 servers, to obtain client permissions and user information.

  The exemplary system described with reference to FIG. 2 supports both reactive and proactive monitoring. In proactive monitoring, the DC and DAP constantly monitor the system. If an abnormality is detected by DC, DAP, or DS, a warning is issued for the network administrator to investigate. The reactive monitoring mode is used when a support person wants to diagnose user dissatisfaction. The person in charge can issue an instruction from one of the DSs to collect and analyze data for diagnosing the problem to a specific DC.

  The exemplary system imposes little overhead on power management. Both proactive and reactive technologies described later consume very little bandwidth, CPU, or disk resources. As a result, these technologies have only a small impact on battery consumption. The exemplary system architecture shown in FIG. 2 supports several functions in embodiments of the present invention by using DC, DAP, and DS. Some of the supported features include disconnected client discovery, disconnected client assistance, performance issue isolation, and unrecognized access point detection.

  In some embodiments of the present invention, DAP 206 is a software change to AP 208 that allows for better scalability and AP performance analysis. Since it is not necessary to change the hardware, the obstacle when deploying this embodiment is relatively low.

  Client machine 204 and access point 208 preferably have the ability to control beacons and probes. In addition, client machine 204 preferably has the ability to initiate an infrastructure network independently (ie, become an AP) or to initiate an ad hoc (ie, computer-to-computer) network. This feature is supported by many wireless cards currently on the market. Some embodiments of the present invention take advantage of the presence of nearby clients or access points. Utilizing nearby clients or access points with software “sensors” may reduce deployment costs.

  The backend server 212 preferably uses a database to maintain the location of all access points in the network. Such a location database is preferably maintained by a network administrator.

  The exemplary system shown in FIG. 2 can accommodate the number of clients and APs in the system. The system includes two shared resources: DS and DAP. In order to prevent a single server diagnostic from becoming a potential bottleneck, additional DS are preferably added as the system load increases. In addition, some embodiments allow each individual DS to reduce the workload by sharing the diagnostic burden with DC and DAP. DS does not allow DCs and DAPs to diagnose problems, and analysis requires a global perspective and additional data (eg, signal strength information obtained from multiple DAPs may cause disconnected client discovery Used only if it may be needed for

  Similarly, since the DAP is a shared resource, having the DAP do extra work can probably detract from the performance of all clients associated with the DAP. To reduce the load on the DAP, some embodiments of the present invention utilize optimization techniques that allow the AP to perform an active scan no matter what client is associated with the AP. Rather, the associated client performs these operations as needed. The AP continues to carry out passive monitoring activities that have a negligible impact on the performance of the AP. If no clients are associated, the AP is idle and can perform such monitoring operations. This approach ensures that most of the physical area around the AP is monitored without compromising the performance of the AP.

  In one embodiment, the interaction between DC, DAP, and DS is protected using an EAP-TLS certificate issued by IEEE 802.1x. A recognized certificate authority (CA) issues certificates to the DC, DAP, and DS. These certificates are used to ensure that all communications between these entities are mutually authenticated. One embodiment includes known techniques for detecting malicious behavior by legitimate users.

  Turning attention to FIG. 3, a technique for detecting and diagnosing performance problems in an IEEE 802.11 wireless network will now be described in accordance with an embodiment of the present invention. There are three distinct phases performed by various combinations of client diagnostics 302, access point diagnostics 304, and server diagnostics 306: a problem detection phase 308, a problem isolation phase 310, and a problem diagnosis phase 312. The detection phase 308 is preferably performed by the client diagnostics 302, which comprises two light components: a proactive / passive monitoring component 314 and a reactive diagnostic component 316. The monitoring component 314 runs in the background at the client and informs the diagnostic component 316 when it detects a degraded performance connection. At this point, the diagnostic component 316 analyzes the connection and analyzes the delay, ie, the degree of delay in the wired and wireless parts, and for the wireless part, the delay in the client 318, the delay in the AP 320, and the medium 322 and A detailed report of the delay at 324 is output. The monitoring component 314 is preferably conservative in declaring that a network problem is occurring. This is because a false alert invokes diagnostic component 316. Because this component has low overhead, invoking this component has only a minor impact on the performance of client 318 and AP 320.

  In one embodiment, because TCP is the most widely used transport protocol in the Internet, performance issues are diagnosed for TCP connections. For TCP connections, passive diagnosis is performed by utilizing connection data and acknowledgment (ACK) packets. For other transport protocols, end-to-end loss rates and round-trip times are calculated using either active probes or performance reports (eg, RTCP reports).

  More specifically, moving to the detection phase 308, embodiments of the present invention recognize that network performance issues can appear in various forms, such as low throughput, high loss rate, and high delay. In some embodiments, throughput is not used as a reference value for detecting problems. This is because the throughput depends on the workload (ie the client application may not require high throughput) and certain parameters of the transport protocol (eg initial window size in TCP, sender And the window size on the receiving side). Instead, in embodiments of the present invention, packet loss rate and round trip time are used to detect performance problems.

  In order to estimate the round trip time (RTT) in a TCP connection, embodiments of the present invention check whether the client is the sender. If the client is the sender, the client is already tracking the RTT. When the client is a receiver, the client can apply a heuristic to estimate the round trip time (see, for example, Non-Patent Document 1).

  In order to estimate the loss rate, the client diagnosis 302 in the embodiment of the present invention uses a heuristic (see, for example, Non-Patent Document 2 and Non-Patent Document 3). Various loss rates are calculated for packets sent and received by client 318. For data packets transmitted by client 318, the loss rate is estimated as the ratio of retransmitted packets to transmitted packets in the last L RTTs. This estimation mechanism assumes that the TCP implementation uses Selective ACK (SACK) so that the loss rate is not unnecessarily overestimated. This is a reasonable assumption because some operating systems, such as Windows, Linux, and Solaris, currently support this option by default. This estimate may be higher than the actual loss rate if a timeout occurs in a TCP connection, but this inaccuracy is acceptable for two reasons. First, if a timeout occurs in a TCP connection, there is a problem with the TCP connection and it is worth making a diagnosis. Second, it only triggers the diagnostic component of the present invention which incurs a small overhead as a result of an error. Where more accurate analysis is required, the LAST technique proposed by Allman et al. Is preferably used.

  For data packets received by client 318, embodiments of the invention estimate the number of losses using the following approach. That is, if a packet is received whose starting sequence number is not the expected next sequence number, the missing segment is considered lost. The loss rate is estimated as the ratio of lost packets to the total number of packets expected in the last L RTTs. Note that the expected number of bytes is calculated as the largest observed sequence number during the last L RTTs minus the smallest number. The maximum segment size (MSS) is estimated using methods such as taught by Zhang et al., And the number of packets is estimated by dividing the number of bytes by the MSS.

  The monitoring component 314 triggers the diagnostic component 316 if the connection is very lossy or has a high delay. If the RTT of a particular packet is greater than a given threshold (eg 250 msec) or higher than some multiple of the current TCP RTT (eg 2 times), the connection is detected as experiencing high latency The In order not to call the diagnostic algorithm for a temporary high delay, the connection is only flagged if a packet greater than some variable D is experiencing a high delay. A connection is classified as lossy if its loss rate (for transmitted or received packets) is above a certain threshold L (eg 5%). Both D and L are rewritable parameters, each representing a compromise between the responsiveness of the detection component and the unnecessary invocation of the diagnostic component. That is, using a small value of D or L will immediately detect any change in delay / loss, but may also result in unnecessary calling of diagnostic components. In addition to slow response, another problem arises when using high values of D or L. That is, the TCP connection can be terminated before a sufficient number of samples are collected. Such a situation can occur in the case of a short web transfer. Embodiments of the present invention alleviate this problem by aggregating loss rate and delay information between the client 318 and the remote host 326 across the entire TCP connection.

  When a network performance problem is detected in problem detection phase 308, DC 302 in client 318 communicates with its associated DAP 304 in problem isolation phase 310 to delay and wireless part 324 in the wired part 322 of the path. Distinguish from the delay in. A method for separating wired performance issues and wireless performance issues used by embodiments of the present invention will be described with reference to FIG. When the DC notifies the DAP of the performance problem in step 402, the DAP then begins monitoring TCP data and ACK packets in step 404 for the client's connection. In step 406, the DAP determines whether the client is the sending side or the receiving side in the TCP connection. If the client is the sender, the DAP calculates the difference between the data packet from the client to the remote host and the reception time of the corresponding TCP ACK packet at step 408. This time difference is an estimate of the delay experienced in the wired network. In order to ensure that the round trip time estimate is reasonable, various heuristics utilized by TCP, such as Karn's algorithm, are also applied to such round trip measurements (eg, Non-Patent Document 4). At step 410, the DAP sends this estimate to the DC, and at step 412, the DC can subtract this estimate from the TCP round trip time to determine the radio part of the delay. If the client is a receiver, in one embodiment, a similar approach is used to calculate this analysis. That is, the DAP determines the radio delay at step 414 by monitoring the data packet from the remote host to the client and the corresponding ACK packet. Note that the amount of state maintained in the DAP is small because it corresponds to the number of TCP packets that were not responded. This amount can be further reduced by sampling.

  Returning to FIG. 3, wireless performance degradation occurs on the client 318 for several reasons, such as an AP 320 or client processor overload, a problem with the wireless medium 324, a driver or other kernel problem with the AP 320 or client 318, etc. obtain. Embodiments of the present invention quantify the impact of such problems by observing the impact that the problem has on packet delays in the wireless network path. These performance issues fall into three categories: packet delay at the client 318, packet delay at the AP 320, and packet delay at the wireless medium 324. The embodiment uses a collaborative scheme called Estimating Delay using Eavesdropping Neighbors (EDEN). EDEN uses the presence of other clients to quantify the delay experienced within each of the above categories. Since electromagnetic waves travel at the speed of light, it can be assumed that the RF propagation delay is small compared to the client or AP delay. When triggered by its problem detection component 314, the performance diagnostic component 316 of the client 318 initiates a broadcast of a packet requesting diagnostic help from a nearby client. All clients that hear (receive) such a packet switch to promiscuous mode (or “intercept” mode) and ask the DAP 304 to begin diagnosis. Security mechanisms such as those discussed in pending US patent application “USING A CONNECTED WIRELESS COMPUTER AS A CONDUIT FOR A DISCONNECTED WIRELESS COMPUTER” filed Jan. 31, 2005, under US Pat. Can be used to prevent Note that the use of multiple snoop clients with EDEN results in the following robustness: That is, multiple clients increase the likelihood that at least one client will hear the EDEN protocol request and response discussed later.

  EDEN proceeds in two phases which will now be described with reference to FIG. In the first phase, the DAP 502 with which the client 504 is associated estimates the delay at the client 504. In step 506, the DAP 502 sends a snoop request packet to the client 504 periodically (eg, every 2 seconds). When the client 504 receives the snoop request packet, it immediately responds with a snoop response message in step 508. The intercepting client 510 logs the snoop request time (intercepted) at step 512 and the first attempt by the client 504 to send the corresponding snoop response packet at step 514, i.e. Only the time of the response packet in which the retransmission bit is clear is recorded. If eavesdropping client 510 fails to obtain any of these packets, it ignores the timing value for that request / response pair. The difference between the recording times is the client delay, that is, the application and OS delay that occurs at the client after receiving the request packet. For robustness, the snoop request is preferably sent several times (eg 20 times). Client and AP delays are averaged over all these cases.

  In the second phase, a similar technique is used to measure the AP delay. That is, the client 504 transmits a snoop request packet in step 520, and the AP 502 transmits a response in step 522. Intercept client 510 logs the request and response times in steps 521 and 523. The client 504 also records, at step 524, the number of request packets for which the client 504 did not receive a response, eg, the request or response was lost, along with the round trip time to the AP for such snoop requests and responses.

  Client and AP delays may include delays due to contention occurring in the wireless medium. Empirical studies have shown that the delay due to such competition does not prevent EDEN from estimating the delay with reasonable accuracy.

  At the end of the protocol, preferably all intercepting clients 510 send the AP and client delay times to client diagnostics 504. The difference between the round trip time reported by the client and the sum of delays at the client and AP is close to the sum of delays encountered by the packets on the transmit and receive radio links. Client diagnostics 504 can then report the client / AP / medium classification to the network administrator. Client diagnostics 504 may also report the percentage of request packets that were not responded as an indicator of the network level loss rate over the wireless link.

  In an alternative embodiment of the present invention, the wireless access point detects network performance issues by performing the EDEN steps described above. In such embodiments, the wireless access point can monitor network traffic for lost packets and packet delays, and can also participate in a snoop protocol with the client or another access point. The access point notifies neighboring clients to intercept the protocol and receives the collected information to determine the nature of the problem.

  Turning attention to FIG. 6, details of one embodiment of the implementation are shown. The basic architecture consists of DC, DAP, and DS daemons running on the client, access point, and server, respectively. The system can be implemented on a Microsoft Windows® operating system, for example, with a standard commercially available 802.11b card. In DS, the daemon process accepts information from the DAP. The DS reads a list of valid APs from a file or database. The code structure in DC or DAP preferably comprises a user level daemon 602 and kernel level drivers 604 and 606. These parts are constructed such that code is added to the kernel drivers 604 and 606 only if the functionality cannot be achieved with the user level daemon 602 or if there are too many performance penalties.

  In the exemplary system, there are two kernel drivers, a miniport driver 604 and an intermediate driver (IM driver) 606, such as the Native WiFi driver in the Microsoft Windows® operating system. The miniport driver 604 communicates directly with the hardware and provides basic functions such as packet transmission / reception and channel setting. Driver 604 exposes sufficient interfaces so that functions such as association, authentication, etc. can be handled in IM driver 606. The IM driver 606 supports several interfaces (exposed by loading) that query various parameters such as the current channel, transmission level, power management mode, SSID, etc. In addition to allowing parameters to be set, this query also allows user-level code to request an active scan, associate it with a specific SSID, capture a packet, and so on. In general, this query provides considerable flexibility and control to user-level code.

  Although many operations already exist in IM driver 606, embodiments of the present invention use modifications to expose specific functionality and improve the performance of specific protocols. Miniport driver 604 is preferably minimally modified to expose certain types of packets to IM driver 606. In the IM driver 606, the following support is preferably added. Packet header and packet capture, RSSI (Received Signal Strength Indicator) value storage from received packets, AP information tracking, and kernel event support for protocol efficiency. These changes are discussed in further detail next.

  Packet header and packet capture: Embodiments of the present invention allow filters such as specific MAC addresses, packet types, packet subtypes (eg, management packets and beacon packets) to capture only specific packets or packet headers. Allows a filter based on etc. to be set.

  Storing RSSI values from received packets: Embodiments of the present invention obtain RSSI values for all received packets and track RSSI values from each neighboring device (indexed on MAC address) A table called NeighborInfo table is maintained. An exponentially weighted average is maintained with the new value given a certain weighting factor of, for example, 0.25.

  Tracking AP information: In the NeighborInfo table, some embodiments include the channel from which a packet was heard (received) from a particular MAC address, the SSID information (from the beacon), and whether the device is an AP. Or track if it is a station.

  Kernel event support for protocol efficiency: Preferably, events that are shared between the kernel and user-level code are added. The kernel triggers an “interesting” event when it occurs. This makes some of the protocols interrupt-driven rather than poll-based.

  In addition, several ioctls are preferably added to obtain and clear the information discussed above.

  In an embodiment of the present invention, the diagnostic daemon 602 runs on the device, collects information, and implements the various mechanisms discussed above. If the device is an AP, it communicates diagnostic information with the DS and DC. If the device is only a DC, it communicates with the AP associated with the device to convey diagnostic information. The diagnostic daemon on the DC obtains the current NeighborInfo table from the kernel 608 at regular intervals, eg every 30 seconds. Such information is sent to the DAP when a new node is found or when the existing data has changed significantly (eg, the client's RSSI value has changed more than a factor of 2). The DAP preferably also maintains a similar table indexed by MAC address. However, the DAP only sends information about the disconnected client and AP to the DS. Alternatively, the DS ceases getting updates for all clients in the system, reducing client scalability. The DAP periodically sends new or changed information about the AP to the DS (eg, 30 seconds). In addition, if the DAP has any pending information about the disconnected client D, the DAP immediately informs the DS so that the disconnected client can receive service when appropriate. All messages from DC to DAP and from DAP to DS are preferably sent as XML messages. A sample message format from the DC is shown below (time stamps are erased).

  As this sample message shows, the DC sends information about other connected clients, APs, and disconnected clients. For each such class of entity, the DC sends the machine's MAC address along with the RSSI, SSID, and a channel bitmap that indicates the channel on which the particular device was overheard.

  While a number of possible embodiments have been considered to which the principles of the invention may be applied, the embodiments described herein in connection with the drawings are intended to be illustrative only and limit the scope of the invention. It should be understood that it should not be taken. For example, those skilled in the art will appreciate that the illustrated embodiments can be modified in arrangement and detail without departing from the spirit of the invention. Although the invention has been described in terms of software modules or components, those skilled in the art will appreciate that hardware components can be equivalently replaced. Accordingly, the invention described herein contemplates that all such embodiments may be within the scope of the appended claims and their equivalents.

FIG. 2 is a simplified schematic diagram illustrating an exemplary architecture of a computing device used in accordance with an embodiment of the present invention. 1 illustrates an exemplary wireless network for detecting and diagnosing network performance problems in accordance with embodiments of the present invention. FIG. FIG. 2 illustrates an exemplary architecture for detecting and diagnosing network performance problems according to embodiments of the present invention. FIG. 5 is a flow diagram illustrating a method for calculating delay in a wireless network according to an embodiment of the present invention. FIG. 6 is a flow diagram illustrating a method for jointly diagnosing wireless network communication problems using neighboring wireless devices according to an embodiment of the present invention. FIG. 3 is a schematic diagram illustrating software components used for diagnosing wireless communication problems according to an embodiment of the present invention.

Explanation of symbols

202, 302 Client diagnosis 204 Wireless client machine 206, 304 Access point diagnosis 208, 320 Access point 210, 306 Server diagnosis 212 Backend server 220 Legacy access point 221 Database 230 RADIUS
232 Kerberos
314 Proactive / passive monitoring component 316 Reactive diagnostic component 318 Client 322, 324 Medium 326 Remote host

Claims (13)

A method for facilitating diagnosis of communication problems occurring in a first wireless device that is either a wireless computing device or a wireless access point in a wireless network, comprising:
Determining that there is a communication problem in the wireless network;
Broadcasting a request to assist in diagnosing the communication problem to one or more neighboring wireless devices, switching the neighboring wireless device that received the request to an intercept mode ;
Responding to a diagnostic session request sent by a second wireless device in a diagnostic session ;
Receiving information about the diagnostic session from an intercept client that is at least one of the neighboring wireless devices in the intercept mode ;
With
The reception time of the diagnostic session request sent by the second wireless device to the first wireless device and a corresponding diagnostic session sent by the first wireless device to the second wireless device A method, characterized in that the information received regarding the diagnostic session request facilitates diagnosis of a communication problem based on monitoring by the intercepting client with the reception time of the request . Computer-executable instructions for facilitating diagnosis of communication problems that occur at a first wireless device that is either a wireless computing device or a wireless access point in a wireless network, executed on the first wireless device A computer-readable storage medium comprising computer-executable instructions for causing the first wireless device to perform the method of claim 1 . Wherein the computer executable instructions, characterized in that it further comprises the step of performing the step of transmitting a diagnostic session request to the second wireless device to the first wireless device in the diagnostic session, according to claim 2 Computer readable storage medium. The computer-readable storage medium of claim 2 , wherein the information about the diagnostic session includes an estimate of one or more of a packet delay rate or a packet loss rate . The computer-readable storage medium of claim 2 , wherein the first wireless device is a wireless computing device and the second wireless device is a wireless access point . The computer-executable instructions use the information about the diagnostic session to determine how much communication problem the first wireless device, the second wireless device, or the first wireless device and the second The computer-readable storage of claim 2 , further comprising: causing the first wireless device to perform the step of determining if caused by one or more of the wireless media between the wireless devices. Medium. The computer-readable storage medium of claim 2 , wherein the computer-executable instructions further comprise causing the first wireless device to perform a step of reporting a result of the diagnostic session to a network administrator. . A method performed at a second wireless computing device to facilitate diagnosis of communication problems occurring at a first wireless computing device in a wireless network, the method comprising:
Receiving a request for diagnostic help from the first wireless device;
In response to the request for diagnostic help, switching to intercept mode to operate as an intercept client and receiving a diagnostic session request sent to the first wireless computing device by the wireless access point in a diagnostic session; and Accumulating performance data by monitoring a reception time of a corresponding diagnostic session request sent by the first wireless computing device to the wireless access point;
Transmitting information relating to the accumulated performance data to the first wireless computing device;
And wherein the information regarding the performance data facilitates diagnosing communication problems occurring at the first wireless computing device. 9. The method of claim 8, wherein computer-executable instructions that facilitate diagnosis of communication problems that occur at a first wireless computing device in a wireless network when executed on the second wireless computing device. A computer-readable storage medium comprising computer-executable instructions for causing the second wireless device to execute. The computer-executable instructions cause the second wireless computing device to perform a step of requesting a diagnostic access point program operating on the wireless access point to initiate a diagnostic protocol with the first wireless computing device. The computer-readable storage medium of claim 9 , further comprising steps . The computer-readable storage medium of claim 9 , wherein the step of accumulating performance data comprises estimating a communication delay by the first wireless computing device . The computer-readable storage medium of claim 11 , wherein the communication delay is estimated as an amount of time between receiving the diagnostic session request and a corresponding diagnostic session response . The computer-readable storage medium of claim 9, wherein the step of accumulating performance data comprises estimating a communication delay due to the wireless access point .

Images