CN112369066A

CN112369066A - WLAN client congestion detection and reporting

Info

Publication number: CN112369066A
Application number: CN201980044023.3A
Authority: CN
Inventors: K·C·J·韦杰布兰斯; J·P·哈罗德四世
Original assignee: Koninklijke Philips NV
Current assignee: Koninklijke Philips NV
Priority date: 2018-06-29
Filing date: 2019-06-26
Publication date: 2021-02-12
Also published as: EP3815419A1; WO2020002388A1

Abstract

A network congestion monitoring method (100) comprising: monitoring, using a WLAN radio (20) of a medical device (10) communicating according to a transmission scheme on a WLAN channel, for a network event 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 communicates; and transmitting, using the WLAN radio of the medical device, the network event indicating congestion on the WLAN channel from the medical device to a WLAN network management system (32).

Description

WLAN client congestion detection and reporting

Technical Field

The following generally relates to the fields of medical monitoring and therapy, wireless patient monitoring, and related fields.

Background

In the case of wireless communications, such as Wireless Local Area Networks (WLANs), the radio spectrum is a limited resource that should be efficiently used by wireless devices that utilize the Radio Frequency (RF) medium. Inefficient use or inadequate radio spectrum is the root cause of many wireless technology problems. In the case of IEEE802.11 wireless communication radio technologies, these inefficiencies can arise from having a dense deployment of Access Points (APs) and clients. Suboptimal infrastructure deployment, such as allowing two APs close to each other to operate on the same channel, is a typical cause of congestion. Other examples of situations where a client can have problems accessing the radio medium can include a higher priority client with a higher quality of service (QoS) accessing the channel faster, a client sending or receiving large amounts of data consuming more channel bandwidth, a client using a low data rate and therefore blocking the channel for a longer period of time, and a noise floor above normal due to interference from non-802.11 wireless devices, among others.

To address the channel utilization problem, the AP monitors the spectrum of the channel and reacts to the detected problem by notifying personnel responsible for maintaining the wireless infrastructure. The AP can also take positive measures to address the detected problem, such as moving the device 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, Inc. of san Jose, Calif.).

However, these solutions do not identify all of the problems and do not determine how 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 an infrastructure that does not include congestion detection/mitigation solutions. In particular, medical devices that transmit patient vital sign data and/or patient alarms or receive control data for adjusting medical therapy being provided to a patient are examples of devices that perform mission critical and/or life critical applications.

When operating wireless devices that require appropriate QoS on customer-owned wireless networks, the infrastructure may not be available to ensure that the underlying QoS level is designed. Different infrastructure vendors have different ways to measure and indicate potential problems, making it difficult to support QoS designed for numerous customers with different infrastructures.

The following discloses new and improved systems and methods that solve the above-referenced problems and others.

Disclosure of Invention

In one disclosed aspect, a network congestion monitoring method includes: monitoring, using a WLAN radio of a medical device communicating according to a transmission scheme on a WLAN channel, for a network event indicating 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 communicates; and transmitting, using the WLAN radio of the medical device, the network event indicating 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 signs sensor, a therapy delivery device, or a medical alarm that generates medical data including at least one of vital signs measurements, therapy delivery monitoring data, or a medical alarm indication. A WLAN radio is fixed with the medical component and configured to transmit medical data according to a transmission scheme over a WLAN channel. The WLAN radio includes at least one non-transitory readable medium and an electronic processor programmed with instructions stored on the at least one non-transitory readable medium to detect a network event indicative of WLAN network congestion on the WLAN channel and store at least one count of the detected network events on the at least one non-transitory readable 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 comprises the following steps: monitoring for a network event indicating 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 communicates; and transmitting, using the WLAN radio of the medical device, the network event indicating 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 problems for medical devices and notify device users and maintainers of the wireless network infrastructure.

Another advantage resides in providing QoS information to determine wireless network congestion problems between medical devices.

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

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

A given embodiment may provide none, one, two, or all of the aforementioned advantages, and/or may provide other advantages that will become apparent to those skilled in the art upon reading and understanding the present disclosure.

Drawings

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

Fig. 1 illustrates an example embodiment of a medical device according to an aspect.

Fig. 2 is a flow chart of an exemplary method for the apparatus of fig. 1.

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

Detailed Description

As used herein, the terms "wireless network," "Wireless Local Area Network (WLAN)," "IEEE 802.11 network" (and variations thereof) refer to a wireless network that has compatibility with the IEEE802.11 standard.

Current medical devices employ WLAN communication for transmitting mission critical data such as vital sign measurements, medical alarms, etc. These devices are typically deployed over the WLAN infrastructure of existing hospital networks. However, the devices differ from most devices on the network in that the mission-critical data transmitted requires a very high transmission link reliability. Furthermore, some current WLAN-enabled medical devices are battery-operated and, to conserve power, they transmit at discrete intervals and do not always have the receiver turned on when the device is not transmitting data.

The WLAN components of a hospital network typically include traffic monitoring and may implement quality of service (QoS) protocols to prioritize important network connections. However, these measurements are not designed to be the strict requirements of mission critical data links.

For mission and life critical devices, the overall channel quality and congestion are relevant, but only local pictures of connectivity are provided when the devices encounter certain congestion and interference, which affect the quality of service provided by the devices and their power consumption. For battery-operated devices that require real-time mission critical communication of measurements, it is especially important to detect and correct frequent network congestion encountered by the device in order to avoid rapid drain of the battery. It would be advantageous to monitor the quality of communications over a wireless link while being efficient in battery use: in particular, the device cannot provide a continuously monitored link, as doing so would burden the battery, but at the same time must be efficient when it turns on its wireless radio and not provide excessive retransmissions that again burden the battery. This is especially necessary for devices with a voice over internet protocol (VoIP) -like communication version. The most efficient use of spectrum and battery for such devices is to communicate regularly using unscheduled automatic power save delivery (U-APSD). In the U-APSD protocol, a device wakes up, attempts to re-serve the medium by first sending all its information in one burst and then immediately receiving all pending information in the same burst from an access point in the same QoS class, and then releases the medium. Here, congestion can interfere with radio operation in two ways: (1) congestion can interfere with accessing the medium to begin a burst; and (2) interference during the burst can cause corruption of transmission or reception, thus requiring subsequent reattempts of the same transmission/reception attempt.

With respect to accessing the medium, a special case is if there are many devices that communicate periodically in a manner that are accidentally synchronized to the same time slot, they will cause frequent congestion to each other. These can be the same device (e.g., multiple patient monitors) or different devices (interference between a patient monitor and a VoIP phone). This is possible because the devices all perform clock synchronization to the same WLAN beacon signal.

In embodiments disclosed herein, network congestion monitoring is added to the medical device in conjunction with one or another or both of: (1) congestion relief at the medical device; and/or (2) report network congestion detected at the medical device to a local deployment management system (e.g., Philips FocusPoint local deployment management system for Philips medical devices; available from Royal Philips, Inc. of Emendporm, Netherlands), possibly coupled with corrective action taken by the management system. The method can be used in place of and/or to enhance congestion mitigation strategies implemented at an AP and provide a number of benefits. Congestion monitoring by medical devices ensures detection of congestion at levels that are generally acceptable to the network, but unacceptable to medical devices requiring a higher QoS than most other devices on the network. Congestion problems that specifically affect medical devices are identified through congestion monitoring of the medical devices. Congestion monitoring by the medical device enables the medical device to acquire certain corrective actions that are not easily implemented by the AP (possibly providing support for mission or life critical devices in particular in conjunction with a field deployment management system). The disclosed method enables mission or life critical medical devices to utilize existing generic WLAN networks with the necessary QoS required by such devices without expensive or impractical modifications to the generic WLAN network.

Congestion monitoring requires 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 that indicate network congestion. For example, in some demonstrative embodiments, the medium-busy alert control register stores a count of a number of times physical carrier sensing fails a number of consecutive times and does not receive a Network Allocation Vector (NAV) from another wireless device. The NAV alert control register stores a count of the number of times the virtual carrier senses a continuous number of failures and receives a NAV from another wireless device. The failed transfer register stores a count of the number of unacknowledged packets (i.e., packets sent without ACKs received). When such a count exceeds a designed threshold, then a network congestion problem is detected.

In a variant embodiment, congestion monitoring is performed for each Media Access Control (MAC) address, tracking the MAC address of the counterpart that the medical device waits for. This variant requires building a MAC table and storing a count 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. This may be resolved if the congestion encountered is periodic, for example, because another device transmits on the same schedule. If several attempts at different random offsets do not solve the problem, another of the transmission schemes may be adjusted, for example, to halve the scheduled transmission interval to double the chance of successful transmission, or to take random hops within the interval, or to introduce redundancy into the transmission. Finally, if both of these measures fail, the medical device may attempt to switch to a different Access Point (AP).

Congestion reporting may also be performed, for example, to transmit network congestion collected at the medical device to a Philips focusspoint (or other) on-site deployment management system or another centralized network congestion solution, such as a WLAN record station. The central system may take various actions in response to the reported congestion. For example, network congestion issues can be presented to the user, e.g., at a dashboard of a recording station, and/or emails reporting congestion can be sent to IT department email addresses. This information may also be reported if the medical device has performed congestion relief.

Referring to FIG. 1, an exemplary embodiment of a medical device 10 is shown. As shown in fig. 1, the medical device 10 includes a medical component 12 configured to generate medical data. For example, the medical component 12 can be a vital signs sensor 14 (e.g., an Electrocardiogram (ECG) sensor, a photoplethysmography (PPG) sensor, an electroencephalogram (EEG) sensor, a respiration sensor, etc.) configured to measure or generate corresponding vital sign measurements; a therapy device 16 (e.g., a drug delivery device, an electrotherapy device, etc.) configured to generate therapy delivery monitoring data; or one or more of medical alert devices 18 configured to generate medical alert indications.

The medical device 10 further comprises a WLAN radio device 20 wirelessly connected to an Access Point (AP), e.g. a WLAN network 22 of the medical facility. In some embodiments, more than one medical device 10' can be connected to the WLAN network 22 through the same and/or different APs. The WLAN radio 20 is fixed with the medical component 12. As shown in fig. 1, the radio 20 and the medical component 12 are secured together by a housing 22 that houses both the medical component 12 and the WLAN radio 20, such 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 transmit and receive data according to a suitable WLAN protocol employed by a WLAN network 22, such as an IEEE802.11 protocol, at least one electronic processor 24 (e.g., a microprocessor, microcontroller, etc.), and at least one non-transitory readable medium 26. Non-transitory readable medium 26 may include, for example, a hard disk drive or other magnetic storage medium; a Solid State Drive (SSD), flash memory, Electrically Erasable Read Only Memory (EEROM), or other electronic memory; optical disks or other optical storage devices; various combinations thereof; and so on. In some embodiments, a non-transitory readable medium storing instructions is provided in the WLAN radio 20, for example in the form of an internal hard drive, SSD, flash memory, or the like.

The WLAN radio 20 is configured to transmit medical data from the medical component to a receiving device, such as a nurse station, an Electronic Medical Records (EMR) server, etc., according to a transmission scheme over a WLAN channel of the WLAN network 22. (additionally or alternatively, the communication may communicate configuration/control signals, etc. to the medical component 12). For example, the transmission scheme includes a transmission schedule (e.g., for transmitting transmission bursts), a set of data rates, and a used channel width (examples: 20MHz, 40MHz, 80MHz, etc.), 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 a non-transitory readable medium 26, the non-transitory readable medium 26 storing instructions readable and executable by the at least one electronic processor 24 to perform the disclosed operations, including performing the network congestion monitoring method or process 100 to obtain images of a patient for neurosurgical guidance. For example, the at least one electronic processor 24 is programmed by instructions stored on the at least one non-transitory readable medium 26 to detect a network event indicative of WLAN network congestion on the WLAN channel, and store at least one count of the detected network event on the at least one non-transitory readable medium 26 (e.g., in a

register

28a, 28b, 28c, 28d stored in the at least one non-transitory readable medium). The WLAN radio 20 also communicates with the WLAN management system 32 to report the detected congestion event.

Referring to fig. 2, an illustrative embodiment of an imaging method 100 is shown diagrammatically as a flow chart. 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, monitoring of network events indicative of WLAN network congestion on a WLAN channel is performed using the WLAN radio 20 of the medical device 10 communicating according to a transmission scheme over the WLAN channel. In this operation, the IEEE802.11 standard uses carrier-sense multiple access with collision avoidance (CSMA/CA) to access the RF medium. Statistics are collected from certain points in the process and compared to thresholds that can indicate problems with the RF environment related to congestion and interference. The threshold may be monitored on a per packet basis and/or a per packet sequence basis.

In one example, the monitoring of the network event indicating WLAN network congestion on the WLAN channel comprises storing in the register 28a count of the number of consecutive failures perceived by means of the virtual carrier of the WLAN radio 20 receiving a Network Allocation Vector (NAV) from the other wireless device 10'. This monitoring operational paradigm can be referred to as a NAV wait threshold. In this operation, a count of the number of times the virtual carrier senses a continuous number of failures and receives a NAV from another wireless device is collected and stored in the register 28 a. The number of these types of counts can be indicative of congestion due to excessive IEEE802.11 traffic and/or a greater number of devices using a higher QoS level than devices experiencing congestion.

In another example, the monitoring of the network event includes storing in register 28b a count of the number of times the physical carrier sense of the WLAN radio 20 fails to detect a free channel or available Radio Frequency (RF) medium a number of consecutive times. This monitoring operational paradigm can be referred to as a medium busy threshold. Monitoring also includes storing in register 28b a count of the number of times the physical carrier sense failed a number of consecutive times and did 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 interpreted as noise. In some examples, the number of physical carrier sense identifications of the WLAN radio 20 is counted when the indication that virtual carrier sense has failed (i.e., the virtual carrier sense receives a network allocation vector from another wireless device 10' connected to the WLAN radio).

In yet another example, the monitoring of the network event indicating WLAN network congestion on the WLAN channel includes storing a count of the number of unacknowledged packets transmitted by the WLAN radio 20 in a register, 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. The failed packet count is typically included in the radio target statistics and therefore there is typically no additional register needed to implement this congestion monitoring aspect. This monitoring operational paradigm can be referred to as a failed transmission threshold. In this operation, a count of the number of unacknowledged packets (i.e., packets sent without receiving an ACK) is collected and stored. When such a count exceeds a designed threshold, then a network congestion problem is detected. These numbers of these types of counts can be indicative of interference occurring during transmission of a packet or during reception of an ACK that causes retransmission of the same packet.

It should be appreciated 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 build a table of MAC addresses of devices on the medical device 10. These counts for each MAC address can be stored in a constructed table, which itself can be stored in at least one non-transitory readable medium 26.

At 104, in one example embodiment, the WLAN radio 20 of the medical device 10 is configured to alleviate the congestion detected by the monitoring 102 by adjusting the transmission scheme according to which the WLAN radio communicates. In this operation, the desired transmission scheme is debugged based on the count to get a better tradeoff between QoS and battery usage. Congestion reduction applies specific heuristics or methods to try to improve QoS and battery usage. Some illustrative examples are provided below.

In some embodiments, the transmission scheme includes that the transmission (or transmission bursts) are scheduled for transmission at periodic intervals. To alleviate congestion, the transmission schedule may be adjusted. For example, the adjustment of the transmission scheme includes introducing a random offset in the transmission schedule of the medical device 10. This can alleviate congestion if interfering transmissions from another device happen to be on those same schedules of the medical device 10. In another example, the adjustment of the transmission scheme comprises reducing the period of the transmission schedule of the medical device 10. This provides redundant transmission in case some are not received due to congestion. In this example, the adjustment will actually increase congestion as more data is being transmitted, but the impact of congestion on the medical device 10 is mitigated due to increased redundancy, e.g., twice as often as transmission.

In yet another example, the adjustment of the transmission scheme includes modifying the transmission scheme to employ random hopping. For example, the transmission interval can be shortened to ensure that real-time performance with guaranteed delay is achieved despite the delay.

In yet another example, the transmission scheme includes the current AP to which the WLAN radio 20 is connected. In this example, the adjustment of the transmission scheme includes switching the medical device from an AP to a different AP (not shown).

At 106, in another example embodiment, the WLAN radio 20 is configured to transmit a network event from the medical device 10 to the WLAN network management system 32 indicating WLAN congestion on a WLAN channel. In this embodiment, transmitting includes transmitting a notification indicating that the WLAN network is congested. 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 generating an alert only if congestion is sustained for a certain long time; or when there is a strong association between the failed data transmission and the congestion, generating an alert. Furthermore, these can be sent to the monitoring station if the MAC address of the device inducing the congestion is reserved, if a particular MAC address is dominant in the frequency of occurrence in the congestion, or if a particular MAC address is dominant in the spectrum that remains occupied for a long time in the congestion. This may be, for example, a device with a low rate (e.g., 802.11b devices still exist on a 2.4GHz channel at 1 Mbps) or a device requesting a long link (e.g., to transmit a very large a-MPDU).

Example

The congestion detection operation will be optimally performed by the at least one electronic processor 24 of the WLAN radio 20, where alarms can be monitored and tracked on a per packet basis. Processor 24 will track the associated statistics for each threshold and store the number of times the threshold was crossed. Processor 24 may then collect congestion report statistics on a regular basis. The statistics will be reset for each packet transmission. A set of configuration registers will be used to implement and specify the threshold. Example sets of configuration registers are presented in fig. 3-6 and tables 1-4. In particular, fig. 3 diagrammatically illustrates an embodiment of the media busy alert control register 28a, and table 1 describes the contents of this register. Fig. 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 alarms. An example set of status registers is presented in fig. 5 and 6 and tables 3 and 4. Fig. 5 presents an embodiment of the congestion status 1 register 28c described in table 3 and the congestion status 2 register 28d described in table 4. Note that after reading congestion state 1 register 28c, its contents are reset to 0x0, and likewise, after reading congestion state 2 register 28d, its contents are reset to 0x 0.

TABLE 1

TABLE 2

TABLE 3

TABLE 4

As mentioned earlier, the failed packet count is typically included in the radio target statistics and there may not be an additional register needed to implement this monitoring aspect. The congestion relief operation can be implemented as part of an application. Since congestion mitigation measures are limited by the nature of the application level protocol, these are preferably implemented as part of the application software utilizing the appropriate APIs.

The congestion reporting operation may be implemented as part of a wireless radio driver or application. The congestion reporting operation also provides an API associated with the congestion mitigation module to be used.

If MAC address improvement is added, the following additional information can also be reported: MAC address table with additional flags: including the MAC address of the attacking device, the duration of time the link was occupied by the device, and the number of times the link was occupied by that MAC address. With the table size fixed, the highest incidence is retained. Further, flags may be included that indicate the use of low speed, large a-MPDUs, or the request for spectrum and RTS/CTS mechanism for long time use.

The disclosure has been described with reference to the preferred embodiments. Modifications and alterations will 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

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

monitoring, using a WLAN radio (20) of a medical device (10) communicating according to a transmission scheme on a WLAN channel, for a network event 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 communicates; and

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

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

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

introducing a random offset in the transmission schedule of the medical device (10).

4. The method of claim 2, wherein the transmission scheme comprises a transmission schedule in which transmissions are made at periodic intervals, and the adjustment to the transmission scheme comprises:

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

5. The method of claim 2, wherein the adjustment to the transmission scheme comprises:

the transmission scheme is modified 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, comprising:

transmitting, using the WLAN radio (20) of the medical device (10), the network event indicating 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 comprises:

transmitting a notification indicating that the WLAN network is congested.

9. The method of any of claims 1-8, wherein the monitoring of network events includes storing in a register (28) a number of times that physical carrier sensing of the WLAN radio (20) fails to detect the availability of a radio frequency medium a number of consecutive times.

10. The method of any one of claims 1-8, wherein the monitoring for a network event indicating WLAN network congestion on the WLAN channel comprises storing in a register (28) a count of a number of consecutive failures perceived by a virtual carrier of the WLAN radio (20) receiving a network allocation vector from another wireless device.

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

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

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

building a table of MAC addresses of devices on which the medical device (10) is waiting;

storing the count for each MAC address in a constructed table.

13. A medical device (10) comprising:

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

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

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

a housing (22) that houses the medical component (12) and the WLAN radio (20), wherein the WLAN radio is fixed 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:

alleviating the congestion by adjusting the transmission scheme according to which the WLAN radio communicates.

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 communicates by at least one of:

introducing a random offset in a transmission schedule of the medical device (10);

reducing the period of the transmission schedule of the medical device;

modifying the transmission scheme to employ random hopping; and

switching the medical device from a 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:

transmitting the network event 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:

monitoring for a network event indicating 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 for 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 a number of consecutive failures of sensing by means of a virtual carrier of the WLAN radio receiving a network allocation vector from another wireless device,

storing in a register (28) a count of a number of physical carrier sensing failures of the WLAN radio (20) when the virtual carrier sensing fails by detecting that a radio frequency medium is available; 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) having instructions stored thereon that are 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 for a network event indicating WLAN network congestion on the WLAN channel;