WO2020002388A1

WO2020002388A1 - Wlan client congestion detection and reporting

Info

Publication number: WO2020002388A1
Application number: PCT/EP2019/066925
Authority: WO
Inventors: Klaas Cornelis Jan WIJBRANS; John Price HARROD IV
Original assignee: Koninklijke Philips N.V.
Priority date: 2018-06-29
Filing date: 2019-06-26
Publication date: 2020-01-02
Also published as: EP3815419A1; CN112369066A

Abstract

A network congestion monitoring method (100) includes: using a WLAN radio (20) of a medical device (10) that is communicating over a WLAN channel according to a transmission scheme, monitoring network events indicative of WLAN network congestion on the WLAN channel; and at least one of: using the WLAN radio of the medical device, mitigating the congestion by adjusting the transmission scheme according to which the WLAN radio is communicating; and using the WLAN radio of the medical device, transmitting the network events indicative of congestion on the WLAN channel from the medical device to a WLAN network management system (32).

Description

WLAN CLIENT CONGESTION DETECTION AND REPORTING

FIELD

The following relates generally to the medical monitoring and therapy arts, wireless patient monitoring art, and related arts.

BACKGROUND

With wireless communications, such as wireless local area networks (WLANs) radio spectrum is a limited resource that should be used efficiently by the wireless devices utilizing the radio frequency (RF) medium. Inefficient use or insufficient radio spectrum is the root cause of many wireless technology issues. In the case of IEEE 802.11 wireless communication radio technologies, these inefficiencies can be caused by having a dense deployment of access points (APs) and clients. Suboptimal infrastructure deployments, such as allowing two APs that are close to one another to operate on the same channel is a typical cause of congestion. Other examples of situations where clients can have problems accessing the radio medium can include higher prioritized clients with higher Quality of Service (QoS) accessing the channel sooner, clients that send or receive large amounts of data consuming more channel bandwidth, clients using low data rates thus block the channel over a longer period, and a higher than usual noise floor due to interference by non-802.11 wireless devices, among others.

To resolve channel utilization issues, APs monitor the channel’s spectrum and react to detected issues by notifying the personnel responsible for maintaining the wireless infrastructure. The AP can also take affirmative action to resolve a detected issue, such as moving devices and traffic associated therewith to another channel with less congestion. One example of such a device is Cisco’s CleanAir technology (available from Cisco Systems, San Jose, CA, USA).

However, these solutions may not be able to identify all issues and may not be able to determine how the RF conditions are affecting the performance of a particular device. It is also possible that wireless devices with mission critical and/or life critical applications are installed in infrastructures that do not include a congestion detection/mitigation solution. In particular, medical devices transmitting patient vital sign data and/or patient alarms, or which receive control data for adjusting a medical therapy being provided to a patient, are examples of devices carrying out mission critical and/or life critical applications. When operating wireless devices that need appropriate QoS on customer owned wireless networks, the infrastructure may not be available to ensure the design-basis QoS levels. Different infrastructure vendors have different ways of measuring and indicating potential issues, making it difficult to support a designed QoS over the multitude of customers with differing infrastructures.

The following discloses new and improved systems and methods that address the above referenced issues, and others.

SUMMARY

In one disclosed aspect, a network congestion monitoring method includes: using a WLAN radio of a medical device that is communicating over a WLAN channel according to a transmission scheme, monitoring network events indicative of WLAN network congestion on the WLAN channel; and at least one of: using the WLAN radio of the medical device, mitigating the congestion by adjusting the transmission scheme according to which the WLAN radio is communicating; and using the WLAN radio of the medical device, transmitting the network events indicative of congestion on the WLAN channel from the medical device to a WLAN network management system.

In another disclosed aspect, a medical device includes a medical component including at least one of a vital sign sensor, a therapy delivery device, or a medical alarm that generates medical data including at least one of vital sign measurements, therapy delivery monitoring data, or a medical alarm indicator. A WLAN radio is secured with the medical component and configured to communicate medical data over a WLAN channel according to a transmission scheme. The WLAN radio includes at least one non-transitory storage medium and an electronic processor programmed by instructions stored on the at least one non- transitory storage medium to detect network events indicative of WLAN network congestion on the WLAN channel and to store at least one count of detected network events on the at least one non-transitory storage medium.

In another disclosed aspect, a non-transitory computer readable medium stores instructions executable by at least one electronic processor of a WLAN radio connected to a WLAN network to perform a network congestion monitoring method. The method includes: monitoring network events indicative of WLAN network congestion on the WLAN channel; using the WLAN radio of the medical device, mitigating the congestion by adjusting the transmission scheme according to which the WLAN radio is communicating; and using the WLAN radio of the medical device, transmitting the network events indicative of congestion on the WLAN channel from the medical device to a WLAN network management system.

One advantage resides in allowing an operator to independently identify wireless network congestion issues with medical devices and notify device users and maintainers of a wireless network infrastructure.

Another advantage resides in providing QoS information to determine wireless network congestion issues amongst medical devices.

Another advantage resides in detecting wireless network congestion issues to improve battery life of devices connected to a wireless network.

Another advantage resides in providing access to wireless networks for medical devices having a high priority of connectivity.

A given embodiment may provide none, one, two, more, or all of the foregoing advantages, and/or may provide other advantages as will become apparent to one of ordinary skill in the art upon reading and understanding the present disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

The disclosure may take form in various components and arrangements of components, and in various steps and arrangements of steps. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the disclosure.

FIGURE 1 illustrates an example embodiment of a medical device in accordance with one aspect.

FIGURE 2 is a flow chart showing an exemplary method of use for the device of FIGURE 1.

FIGURES 3-6 illustrate exemplary registers suitably employed in various embodiments as described herein.

DETAILED DESCRIPTION

As used herein, the terms“wireless network,”“wireless local area network (WLAN)”,“an IEEE 802.11 network” (and variants thereof) refer to a wireless network having compatibility to the IEEE 802.11 standard.

Current medical devices employ WLAN communication for transmitting mission-critical data, such as vital sign measurements, medical alarms, and so forth. These devices are commonly deployed on the WLAN infrastructure of an existing hospital network. However, the devices differ from most devices on that network in that the transmitted mission- critical data requires very high transmission link reliability. Additionally, some current WLAN enabled medical devices are battery operated, and to conserve power they transmit at discrete intervals and do not always have receivers on when the devices are not sending data.

The WLAN component of the hospital network typically includes traffic monitoring and may implement Quality of Service (QoS) protocols to prioritize important network connections. Yet, these measures are not designed to the stringent requirements of mission critical data links.

For mission- and life-critical devices, overall channel quality and congestion is relevant, but only provides a partial picture of connectivity as the specific congestion and interference encountered by these devices, of these affect the quality of service provided by these devices as well as their power consumption. For battery-operated devices that need real time mission critical communication of measurements, it is especially important to detect and remediate frequent network congestion encountered by the device in order to avoid fast draining of the battery. It would be advantageous to monitor communication quality on the wireless link while at the same time being efficient in battery usage: in particular, the device cannot afford to monitor the link continuously as doing so would heavily burden the battery, but at the same time must be efficient in when it has its wireless radio turned on and cannot afford to make excessive re-transmissions that again burden the battery. This is especially necessary for devices with Voice over Internet Protocol (VoIP) -like communication patterns. The most efficient usage of the spectrum and the battery for such devices is to communicate regularly using Unscheduled - Automatic Power Save Delivery (U-APSD). In U-APSD protocols, a device wakes up, tries to reserve the medium by first sending all its information in one burst and then immediately receives all pending information from the access point in the same QoS class in the same burst and then releases the medium. Congestion here can interfere with radio operation in two ways: (1) the congestion can interfere with getting access to the medium to start the burst; and (2) interference during the burst can cause corruption of transmission or reception thus requiring a later retry of the same transmission/reception attempt.

With respect to getting access to the medium, a special case is if there are many devices periodically communicating in such a manner that are accidentally synchronized to the same timeslot they will cause frequent congestion to one another. These can be the same devices (e.g., multiple patient monitors), or different devices (interference between patient monitors and VoIP phones). As devices all perform clock synchronization to the same WLAN beacon signal, this is likely.

In embodiments disclosed herein, network congestion monitoring is added into the medical device, in combination with one or the other or both of (1) congestion mitigation at the medical device; and/or (2) reporting of network congestion detected at the medical device to an on-premise management system (e.g., a Philips FocusPoint on-premises management system for Philips medical equipment; available from Koninklijke Philips N.V., Eindhoven, the Netherlands), possibly coupled with remedial action taken by the management system. This approach can be used in place of, and/or to augment, congestion mitigation strategies implemented at the APs, and provides numerous benefits. Congestion monitoring by the medical device ensures detection of congestion at levels that may be acceptable for the network overall, but which are unacceptable for the medical device which requires a higher QoS than most other devices on the network. Congestion monitoring by the medical device identifies congestion problems specifically affecting the medical device. Congestion monitoring by the medical device enables the medical device to take specific remedial actions (possibly in conjunction with an on-premises management system specifically providing support for mission- or life-critical devices) that are not readily implemented by the APs. The disclosed approaches enable mission- or life-critical medical devices to utilize existing general purpose WLAN networks with the requisite QoS required for such devices, without requiring expensive or impractical modifications to the general purpose WLAN network.

The congestion monitoring entails modifying the WLAN radio firmware and/or hardware of the medical device to include registers and/or data structures that store counts of one or more network events indicative of network congestion. For example, in some illustrative embodiments a medium-busy alert control register stores a count of times the Physical Carrier Sense fails a set number of consecutive times and does not receive a network allocation vector (NAV) from another wireless device. ANAV alert control register stores a count of the number of times the Virtual Carrier Sense fails a set number of consecutive times and receives a NAV from another wireless device. A failed transmissions register stores a count of the number of unacknowledged packets (i.e., packets sent with no ACK received). When such a count exceeds a designated threshold then a network congestion problem is detected.

In a variant embodiment, the congestion monitoring is performed for each Media Access Control (MAC) address, tracking the MAC addresses of the parties on which the medical device waits. This variant entails constructing a MAC table and storing the counts for each MAC address in the table. Congestion mitigation may be implemented at the medical device. In one illustrative approach, the first attempt at mitigation is to introduce a random offset in the transmission schedule of the medical device. If the encountered congestion is periodic, e.g. due to another device transmitting on the same schedule, then this may resolve the interference. If several attempts at different random offsets does not resolve the problem, then another aspect of the transmission scheme may be adjusted, for example halving the scheduled transmission interval to double the chances of successful transmission, or employing random hopping within the interval, or introducing redundancy into the transmission. Finally, if these measures all fail, the medical device may attempt to switch to a different access point (AP).

Congestion reporting may also be performed, e.g. transmitting network congestion data collected at the medical device to the Philips FocusPoint (or other) on-premises management system or to another centralized network congestion resolution system, such as a WLAN logging station. The central system may take various actions in response to reported congestion. For example, the network congestion problem can be presented to a user, e.g. at a logging station dashboard, and/or an email reporting on the congestion can be sent to an IT departmental email address. If the medical device has performed congestion mitigation, this information may also be reported.

With reference to FIGURE 1, an exemplary embodiment of a medical device 10 is shown. As shown in FIGURE 1, the medical device 10 includes a medical component 12 configured to generate medical data. For example, the medical component 12 can be one or more of a vital sign sensor 14 (e.g., an electrocardiogram (ECG) sensor, a photoplethysmography (PPG) sensor, an electroencephalology (EEG) sensor, a respiratory sensor, and so forth) configured to measure or generate a corresponding vital sign measurement; a therapy device 16 (e.g., a drug delivery device, an electrotherapy device, and so forth) configured to generate therapy delivery monitoring data; or a medical alarm device 18 configured to generate a medical alarm indicator.

The medical device 10 also includes a WLAN radio 20 wirelessly connected to an access point (AP) of a WLAN network 22 of, for example, a medical facility. In some embodiments, more than one medical device 10" can be connected to the WLAN network 22 by the same and/or different APs. The WLAN radio 20 is secured with the medical component 12. As shown in FIGURE 1, the radio 20 and medical component 12 are secured together by way of a housing 22 that houses both the medical component 12 and the WLAN radio 20 so that the medical component 12 and the WLAN radio 20 are considered a unitary medical device. The WLAN radio 20 includes a transceiver antenna 23 configured to wirelessly send and receive data in accordance with a suitable WLAN protocol employed by the WLAN network 22, such as an IEEE 802.11 protocol, at least one electronic processor 24 (e.g., a microprocessor, a microcontroller, and the like), and at least one non-transitory storage medium 26. The non-transitory storage medium 26 may, for example, comprise a hard disk drive or other magnetic storage medium; a solid state drive (SSD), flash drive, electronically erasable read-only memory (EEROM) or other electronic memory; an optical disk or other optical storage; various combinations thereof; or so forth. In some embodiments the non-transitory storage medium storing the instructions is disposed in the WLAN radio 20, e.g. in the form of an internal hard drive, SSD, flash memory, and/or the like.

The WLAN radio 20 is configured to communicate the medical data from the medical component to a receiving device such as a nurses’ station, Electronic Medical Record (EMR) server, and/or so forth, over a WLAN channel of the WLAN network 22 according to a transmission scheme. (Additionally or alternatively, the communications may convey configuration/control signals or the like to the medical component 12). For example, the transmission scheme includes a transmission schedule (e.g. for sending transmission bursts), a set of data rates, and channel widths (examples: 20 MHz, 40 MHz, and 80 MHz, and so forth) to use, and a current AP to which the WLAN radio 20 is connected. The at least one electronic processor 24 of the WLAN radio 20 is operatively connected with the non-transitory storage medium 26 that stores instructions which are readable and executable by the at least one electronic processor 24 to perform disclosed operations including performing a network congestion monitoring method or process 100 to obtain images of a patient for neurosurgery guidance. For example, the at least one electronic processor 24 is programmed by instructions stored on the at least one non-transitory storage medium 26 to detect network events indicative of WLAN network congestion on the WLAN channel and to store at least one count of detected network events on the at least one non-transitory storage medium 26 (e.g., in registers 28a, 28b, 28c, 28d stored in the at least one non-transitory storage medium). The WLAN radio 20 is also in communication with a WLAN management system 32 to report detected congestion events.

With reference to FIGURE 2, an illustrative embodiment of the imaging method 100 is diagrammatically shown as a flowchart. The method 100 includes congestion detection operations performed at the medical device 10, and may also include congestion mitigation operations, and/or congestion reporting operations. At 102, using the WLAN radio 20 of the medical device 10 that is communicating over a WLAN channel according to a transmission scheme, monitoring is performed of network events indicative of WLAN network congestion on the WLAN channel. In this operation the IEEE 802.11 standard uses a carrier sense multiple access with collision avoidance (CSMA/CA) to access the RF medium. Statistics are collected from certain points in this process, and the statistics are compared with thresholds that can indicate issues with the RF environment that are related to congestion and interference. The thresholds may be monitored on a per-packet basis and/or a per packet-sequence basis.

In one example, the monitoring of network events indicative of WLAN network congestion on the WLAN channel includes storing, in a register 28a, a count of times a Virtual Carrier Sense of the WLAN radio 20 fails a number of consecutive times by virtue of receiving a Network Allocation Vector (NAV) from another wireless device 102 This monitoring operation example can be referred to as a NAV Waits threshold. In this operation, a count of the number of times the Virtual Carrier Sense fails a set number of consecutive times and receives a NAV from another wireless device is collected and stored in the register 28a. The number of these types of counts can be an indication of congestion due to excessive IEEE 802.11 traffic and/or larger numbers of devices using higher QoS levels than the device experiencing the congestion.

In another example, the monitoring of network events includes storing, in a register 28b, a count of times a Physical Carrier Sense of the WLAN radio 20 fails a number of consecutive times detect a free channel or a radio frequency (RF) medium is available. This monitoring operation example can be referred to as a Medium Busy threshold. The monitoring also includes storing, in the register 28b, a count of times the Physical Carrier Sense fails a set number of consecutive times and does not receive a NAV from another wireless device. The number of these types of counts can be an indication of non- WLAN traffic, interference or distance WLAN traffic that is being interpreted as noise. In some examples, the number of times a Physical Carrier Sense of the WLAN radio 20 fails is counted when an indication that that Virtual Carrier Sense has failed (i.e., the Virtual Carrier Sense receives the network allocation vector from another wireless device 10" connected to the WLAN radio).

In a further example, the monitoring of network events indicative of WLAN network congestion on the WLAN channel includes storing, in a register, a count of a number of unacknowledged packets transmitted by the WLAN radio 20, and the at least one electronic processor 24 of the WLAN radio is configured to detect congestion when the number of unacknowledged packets exceeds a threshold. A failed packet count is normally included in the radio target statistics, and hence there would typically be no additional register required to implement this congestion monitoring aspect. This monitoring operation example can be referred to as a Failed Transmissions threshold. In this operation, a count of the number of unacknowledged packets (i.e., packets sent with no ACK received) are collected and stored. When such a count exceeds a designated threshold then a network congestion problem is detected. These number of these types of counts can be an indication interference occurred either during the transmission of the packet, or during the reception of the ACK causing retransmits of the same packet.

It is to be understood that the congestion monitoring 102 may employ one, two, or more of these illustrative monitoring aspects. In any of these examples, congestion may not only be detected, but also tracked by MAC address. In some embodiments, the at least one electronic processor 24 of the WLAN radio 20 is programmed to construct a table of MAC addresses of devices on which the medical device 10. These counts for each MAC address can be stored in the constructed table, which itself can be stored in the at least one non-transitory storage medium 26.

At 104, in one example embodiment, the WLAN radio 20 of the medical device 10 is configured to mitigate the congestion detected by the monitoring 102 by adjusting the transmission scheme according to which the WLAN radio is communicating. In this operation, the desired transmission scheme is adapted based on the counts to get a better trade-off between QoS and battery usage. The congestion mitigation applies specific heuristics or approaches to attempt to improve QoS and battery usage. Some illustrative examples are provided below.

In some embodiments, the transmission scheme includes a transmissions schedule in which transmissions (or transmission bursts) are at periodic intervals. The transmission schedule may be adjusted in an effort to mitigate congestion. For example, the adjusting of the transmissions scheme includes introducing a random offset in the transmissions schedule of the medical device 10. This can mitigate congestion if the interfering transmissions from another device happen to be on the same schedule as those of the medical device 10. In another example, the adjusting of the transmission scheme includes reducing the period of the transmissions schedule of the medical device 10. This provides redundant transmissions in case some are not received due to the congestion. In this example, the adjusting would actually increase the congestion, as more data is being transmitted, but the effects of the congestion on the medical device 10 are mitigated by increased redundancy that, for example, transmits twice as often.

In a further example, the adjusting of the transmission scheme includes modifying the transmission scheme to employ random hopping. For example, the transmission interval can be shortened to ensure that in spite of the delay, real-time performance with the guaranteed latency is achieved. In yet another example, the transmission scheme includes the current AP with which the WLAN radio 20 is connected. In this example, the adjusting of the transmission scheme includes switching the medical device from the current AP to a different AP (not shown).

At 106, in another example embodiment, the WLAN radio 20 is configured to transmit the network events indicative of WLAN congestion on the WLAN channel from the medical device 10 to the WLAN network management system 32. In this embodiment, the transmitting includes transmitting a notification indicative of the WLAN network congestion. In another example, the WLAN radio 20 is configured to use filtering of the collected counts and perform operations including using a sliding window procedure and generate an alert only if the congestion is sustained for a certain period for time; or generating an alert when there is a strong correlation between the failed data transmissions and congestions. In addition, if the MAC addresses are retained of congestion-inducing devices, these can be sent to the monitoring station if a specific MAC address is dominant in the congestion in terms of occurrence frequency, or if a specific MAC address is dominant in the congestion in terms of keeping the spectrum occupied for a long duration. This could for example be devices having low rates (e.g., 802.1 lb devices at 1 Mbps still present on a 2.4GHz channel), or a devices claiming the link for a long period (for example to transmit very large A-MPDUs)

EXAMPLE

The congestion detection operation would optimally be performed by the at least one electronic processor 24 of the WLAN radio 20 where the alerts can be monitored and tracked on a per packet basis. The processor 24 would track the associated statistic for each threshold and store the number of times a threshold was crossed. The processor 24 could then collect the congestion-reporting statistics on a regular basis. The statistics would be reset for each packet transmission. A set of configuration registers would be used for enabling and specifying the threshold values. An example set of configuration registers are presented in FIGURES 3-6 and Tables 1-4. Specifically, FIGURE 3 diagrammatically illustrates an embodiment of the medium busy alert control register 28a, and Table 1 describes the contents of this register. FIGURE 4 diagrammatically illustrates an embodiment of the NAV alert control register 28b, and Table 2 describes the contents of this register. Another set of registers is then used in notifying the host processor 24 of the number of congestion alerts. An example set of status registers are presented in FIGURES 5 and 6 and Tables 3 and 4. FIGURE 5 presents an embodiment of a congestion statusl register 28c described in Table 3, and a congestion status2 register 28d described in Table 4. Note that after reading the congestion status 1 register 28c, its contents are reset to 0x0, and likewise after reading the congestion status2 register 28d, its contents are reset to 0x0. Table 1

Table 2

Table 3

Table 4

As previously noted, the failed packet count is normally included in the radio target statistics and there would likely be no additional registers required for implementing this monitoring aspect. The congestion mitigation operations can be implemented as part of the application. As the congestion-mitigation measures are constrained by the properties of the application level protocol, these are best implemented as part of the application software making use of appropriate APIs.

The congestion reporting operations could be implemented as either part of the wireless radio driver or an application. The congestion reporting operations also provides the API that is relevant for the congestion-mitigation module to be used.

If the MAC address refinement is added, the following additional information can also be reported: MAC address table with additional flags: Contains MAC address of offending devices, duration the link is occupied by the devices and number of times the link is occupied by this MAC address. Fixed table size, highest occurrences are retained. In addition, could contain flags indicating low speed, use of large A-MPDUs, or claiming of spectrum for long period using and RTS/CTS mechanism.

The disclosure has been described with reference to the preferred embodiments. Modifications and alterations may occur to others upon reading and understanding the preceding detailed description. It is intended that the disclosure be construed as including all such modifications and alterations insofar as they come within the scope of the appended claims or the equivalents thereof.

Claims

CLAIMS:

1. A network congestion monitoring method (100), comprising:

using a WLAN radio (20) of a medical device (10) that is communicating over a WLAN channel according to a transmission scheme, monitoring network events indicative of WLAN network congestion on the WLAN channel; and

at least one of:

using the WLAN radio of the medical device, mitigating the congestion by adjusting the transmission scheme according to which the WLAN radio is communicating; and

using the WLAN radio of the medical device, transmitting the network events indicative of congestion on the WLAN channel from the medical device to a WLAN network management system (32).

2. The method of claim 1, including, using the WLAN radio (20) of the medical device (10), mitigating the congestion by adjusting the transmission scheme according to which the WLAN radio is communicating.

3. The method of claim 2, wherein the transmission scheme includes a transmissions schedule in which transmissions are at periodic intervals and the adjusting of the transmission scheme includes:

introducing a random offset in the transmissions schedule of the medical device

(10).

4. The method of claim 2, wherein the transmission scheme includes a transmissions schedule in which transmissions are at periodic intervals and the adjusting of the transmission scheme includes:

reducing the period of the transmissions schedule of the medical device (10).

5. The method of claim 2, wherein the adjusting of the transmission scheme includes: modifying the transmission scheme to employ random hopping.

6. The method of claim 2, wherein the transmission scheme includes a current access point (AP) with which the WLAN radio (20) of the medical device (10) is connected and the adjusting of the transmission scheme includes:

switching the medical device from the current AP to a different AP.

7. The method of claim 1, including:

using the WLAN radio (20) of the medical device (10), transmitting the network events indicative of WLAN congestion on the WLAN channel from the medical device to the WLAN network management system (32).

8. The method of claim 7, wherein the transmitting includes:

transmitting a notification indicative of the WLAN network congestion.

9. The method of any one of claims 1-8, wherein the monitoring of network events includes storing, in a register (28), a count of times a Physical Carrier Sense of the WLAN radio (20) fails a number of consecutive times to detect that a radio frequency medium is available.

10. The method of any one of claims 1-8, wherein the monitoring network events indicative of WLAN network congestion on the WLAN channel includes storing, in a register (28), a count of times a Virtual Carrier Sense of the WLAN radio (20) fails a number of consecutive times by virtue of receiving a network allocation vector from another wireless device.

11. The method of any one of claims 1-8, wherein the monitoring network events indicative of WLAN network congestion on the WLAN channel includes storing, in a register (28), a count of a number of unacknowledged packets transmitted by the WLAN radio (20), and the method further includes:

detecting congestion when the number of unacknowledged packets exceeds a threshold.

12. The method of any one of claims 8-11, further including:

constructing a table of MAC addresses of devices on which the medical device

(10) waits; storing the counts for each MAC address in the constructed table.

13. A medical device (10), comprising:

a medical component (12) including at least one of a vital sign sensor (14), a therapy delivery device (16), or a medical alarm (18) that generates medical data including at least one of vital sign measurements, therapy delivery monitoring data, or a medical alarm indicator; and

a WLAN radio (20) secured with the medical component and configured to communicate medical data over a WLAN channel according to a transmission scheme, the WLAN radio including at least one non-transitory storage medium (26) and an electronic processor (24) programmed by instructions stored on the at least one non-transitory storage medium to detect network events indicative of WLAN network congestion on the WLAN channel and to store at least one count of detected network events on the at least one non-transitory storage medium.

14. The medical device of claim 13, further comprising:

a housing (22) which houses the medical component (12) and the WLAN radio (20) whereby the WLAN radio is secured with the medical component.

15. The medical device of either one of claims 13 and 14, wherein the WLAN radio (20) is further configured to:

mitigate the congestion by adjusting the transmission scheme according to which the WLAN radio is communicating.

16. The medical device of claim 15, wherein the WLAN radio (20) is configured to adjust the transmission scheme according to which the WLAN radio is communicating by at least one of:

introducing a random offset in a transmissions schedule of the medical device

(10);

reducing a period of the transmissions schedule of the medical device;

modifying a transmission scheme to employ random hopping; and switching the medical device from the current AP to a different AP.

17. The medical device of either one of claims 13 and 14, wherein the WLAN radio (20) is further configured to:

transmit the network events indicative of WLAN congestion on the WLAN channel and a notification indicative of the WLAN network congestion from the medical device to the WLAN network management system (32).

18. The medical device of any one of claims 13-17, wherein the WLAN radio (20) is further configured to:

monitor network events indicative of WLAN network congestion on the WLAN channel to which the WLAN radio is connected.

19. The medical device of claim 18, wherein the WLAN radio (20) is configured to monitor network events indicative of WLAN network congestion on the WLAN channel to which the WLAN radio is connected by one of:

(i) storing, in the register, a count of times a Virtual Carrier Sense of the WLAN radio fails a number of consecutive times by virtue of receiving a network allocation vector from another wireless device

storing, in a register (28), a count of times a Physical Carrier Sense of the WLAN radio (20) fails by detecting that a radio frequency medium is available when the Virtual Carrier Sense fails; and

(ii) storing, in a register (28), a count of a number of unacknowledged packets transmitted by the WLAN radio (20), and detecting congestion when the number of unacknowledged packets exceeds a threshold.

20. A non-transitory computer readable medium (26) storing instructions executable by at least one electronic processor (24) of a WLAN radio (20) connected to a WLAN network (22) to perform a network congestion monitoring method (100), the method comprising:

monitoring network events indicative of WLAN network congestion on the WLAN channel;

using the WLAN radio of the medical device, mitigating the congestion by adjusting the transmission scheme according to which the WLAN radio is communicating; and using the WLAN radio of the medical device, transmitting the network events indicative of congestion on the WLAN channel from the medical device to a WLAN network management system (32).