A wireless local area network or WLAN wirelessly links two or more devices and usually also links to the Internet. Users with WLAN-equipped devices such as smartphones, iPads, and wireless laptops are therefore free to move within the area of Wi-Fi coverage.
The quantification and qualification of the quality of service requirements for wireless medical devices as well as the provider WLAN market has been inconsistent. Until recently, there has been no valid ways of testing and validation of the quality of service requirements for WLAN enabled medical devices that will be deployed on a shared enterprise wireless network.
This article will describe some test tools, validation and verification test protocols, and deployment methodologies that can be used to ensure the safe and reliable design of WLAN enabled medical devices; but also their deployment in the provider space.
Specifically, a Veriwave solution is described. This is just one vendor amongst many possibilities (for varying budgets) for wireless testing in clinical engineering hospital departments, but may provide useful insight into common issues faced by healthcare facilities and staff in testing wireless medical devices.
Drivers of Change in 2012
Virtually all medical device manufacturers have some 802.11 connectivity (802.11g/a, more commonly known as Wi-Fi) embedded within their client devices. The “smart pump” initiative drove this in the past, but today it is all about getting that information in the electronic medical records (EMR). However, not all embedded 802.11x client radios or protocol stacks are the same, let alone how the actual antenna element is designed into the medical device.
Medical device companies have tended to think that a WLAN adapter for a medical device is just like a WLAN-enabled laptop, and that they can therefore use the same typical deployment model. However, this is not case. The majority of WLAN enabled medical devices do not have the same use model as a typical enterprise WLAN enabled laptop or wireless voice over Internet Protocol (VoIP) phone.
The majority of WLAN enabled medical devices do not have the same use model as a typical enterprise WLAN enabled laptop or wireless voice over Internet Protocol (VoIP) phone.
Taking this into account, many medical device companies that do deploy their WLAN enabled medical devices in a shared wired/wireless enterprise environment may not take into account the correct or right site design.
Testing Requirements for a WLAN Enabled Medical Device
Testing requirements can be essentially broken down into three main areas:
The measurement of file transfer times
The measurement of roaming performance
Security
This kind of testing is very useful when the WLAN enabled medical device is expected to be deployed in hospitals that have a common WLAN network for all devices.
It is important to note that the measurement of file transfer times and roaming performance does ensure the integrity of Wi-Fi transferred data.
A typical test setup supports testing with up to eight access points. Users can also create similar test setups with up to four or 12 APs.
The APs and the MDUT are placed in RF isolation chambers, fully isolating one device from the other. The APs are connected to a wireless LAN controller and the medical device server can be connected to the wired network behind the controller.
An RF management unit (RFMU) is a multi-port programmable attenuator. The RFMU lets the user control the attenuation on each port through the testing application software, facilitating the MDUT roams.
For example, by setting zero attenuation on port1 and maximum attenuation on all the other ports, the test system can ensure that the MDUT can only see and connect to AP1. The user can slowly increase the attention on port1 and decrease the attenuation on port2 to roam the DUT from AP1 to AP2 in a very controlled fashion.
The user can then increase/decrease the attenuation on the other ports to make the MDUT see the other APs at different signal strengths while the MDUT is roaming from AP1 and AP2. This setup will allow the user to created advanced test cases and different roam scenarios.
The user can also load a simple software application on the MDUT and conduct data plane tests to measure file transfer times, throughout, jitter, and packet loss. A chassis can be used to capture all the traffic flowing through the system when the roaming test is run, and compute the roaming delays.
The chassis can also be used to load the APs with background traffic and test how well the MDUT will perform when sharing the available bandwidth with several other wireless clients connected to the same AP. This kind of testing is very useful when the WLAN enabled medical device is expected to be deployed in hospitals that have a common WLAN network for all devices.
Measuring File Transfer Times
To run this test, the user has to load an agent on the MDUT and the WaveClient application can create an FTP traffic stream between a MDUT and the medical testing hardware. The user can choose the packet rate and the packet size of the traffic stream.
The user can also set traffic direction using the software to either have the MDUT transmit or receive traffic. Upon completion of the test run, the software would compute the through-put and file transfer time.
These tests can also be run by using all the different encryption mechanisms such as WPA and WPA2. The tests can be repeated at differing levels of RF attenuation (representing different distances from the AP) and with/without, WLAN/non-WLAN interference, as well as in-band and out-of-band interference.
Wireless Roaming Tests
Roaming tests are conducted using the RFMU. For a simple roaming test, all ports of the RFMU are set to the highest attenuation initially and then the attenuation on port1 is set to zero. This will allow the DUT to connect to AP1 and start sending the traffic to the medical device server through the wireless network.
As the test starts, attenuation on Port1 is slowly increased and attenuation on Port 2 is slowly decreased. At some point in this cycle, the MDUT roams from AP1 to AP2, establishes a connection with AP2, and starts forwarding traffic through AP2.
While executing this roam cycle, the testing hardware will capture all the traffic seen from the client on AP1 as well as AP2 (Figure 1). Using these capture files the testing client software will measure the roaming delay as the time difference between the last data frame transmitted from the MDUT to the server through AP1 and the first frame that was transmitted through AP2.
Once a single roam is executed, the test can continue to roam the client hundreds of times back and forth between AP1 and AP2 or across several APs. The user can create various attenuation patterns to mimic real-world roaming scenarios.
Once a single roam is executed, the test can continue to roam the client hundreds of times back and forth between AP1 and AP2 or across several APs.
The test solution fully automates both the data plane (throughput/file transfer times, and the control plane (roaming/range) testing.
This completely isolates the medical device being tested. The access points and the radio frequency (RF) environment is set up using a chamber and cabling, which creates a highly reproducible test environment.
Research and development (R&D) teams can run hundreds of repeatable roaming tests in a very small amount of time when compared to a typical manual approach.
This type of test application allows the R&D team to control the RF environment by creating real world scenarios where the medical device under test (MDUT) will only see two access points at a given time or several access points with different signal strengths at the same time, thus comprehensively testing the roam initiation/decision algorithms of the MDUT.
This enables testing of MDUT using all industry standard authentication/encryption mechanisms including WEP, WPA-PSK, WPA2-PSK, and WPA-EAP-TLS.
The test solution validates the ability to very easily measure data plane performance such as throughput, jitter, packet loss, and file transfer times at different distances from the access point (AP)—a device or software that allows a wireless device to connect to a wired LAN.
This verifies to baseline the performance of the MDUT with no other traffic on the network and then lets the user make the same measurement in the presence of an ecosystem of simulated clients/traffic streams connecting to the same AP and sharing the bandwidth.
The test solution allows the user to run the same tests in the presence of controlled interference from non WLAN interferers like microwave ovens, and Bluetooth devices. Both “in-band” and “out-of-band” interferers should be considered.
A final report plots the roaming delays measured for each roam and how the PHY data rates of the MDUT change over time as the DUT moved from one AP to another. For example, if the MDUT seems to rate scale its PHY rate all the way to 1 Mbps before roaming to the next best AP, this would indicate a very “sticky” client that prefers connectivity over data performance.
These kinds of MDUT behaviors can be identified using these measurements. The user can control via the various RFMU settings two major aspects:
1. Client Velocity
By changing the attenuation change step, change interval, and min/max attenuation values, the user can control the speed at which the client is moving.
2. AP Density (Deployment Environment)
Using this metric the user will have control of how many APs the MDUT can “see” at any given time and hence control the density of the APs in the deployment environment. The AP density can be controlled by changing the time offset at which each attenuator port would start its ramp-down/ramp-up cycle hence controlling the amount of overlap of the APs RF footprints as seen by the clients.
By adjusting these defined metrics, a schedule can be created that computes the attenuation settings for each of the attenuator ports at any given time. The AP density (roam environment) setting can mimic some of the real world deployment environments:
With variability in settings, the user will be able to start from one of several configurations and modify it to create any other kinds of environments the user can think of.
Low-Density Setting
A low density setting models a low density (e.g. hospital hallway) environment with APs deployed at regular intervals. The MDUT will be able to see only two APs at any given time. The attenuator ports are configured in such a way that the client will be able to see only two APs at a time.
Each attenuator port would go through one max-to-min and then one min-to-max cycle and they stay at the max attenuation. The first attenuation port will start its cycle at time zero and then second attenuator port will start its cycle at time at which the first attenuator port is at min attenuation.
One cycle would end when all the attenuator ports complete their respective max-to-min-to-max cycles by which time the client is expected to roam across all APs one after the other. In each cycle, the expected number of roams in this configuration is N-1 where N is the number of APs.
Medium-Density Setting
The medium density setting models a medium density (e.g. a patient room) environment in which the AP density is higher and MDUT will be able to see more than two APs at a time. Each attenuator port would go through one max-to-min-to-max cycle and then stay at the max attenuation.
The first attenuation port will start its cycle at time zero and the start times for the subsequent ports permit the client to see half of the APs available in the test at different power levels, whenever it is ready to roam.
This will provide the client with more than one AP option to roam to, and will allow the user to test the roaming algorithm of the client in a more real world scenario and check if the client roams to the best available AP. The expected number of roams for each cycle in this configuration is N/2 where N is the number of Aps.
High-Density Setting
The High Density setting models a high density AP environment (e.g. hospital conference room) in which the AP density is very high and MDUT will be able to see lots of APs at any given time. As the first attenuator port ramps down from max to min and the client connects to AP1 the other attenuator ports ramp down in such a way that the client will be able to see almost all the other APs but at different power levels.
This kind of environment will provide new challenges to the client in deciding the best AP to roam to and sometimes may result in the client ping-ponging between APs. The expected number of roams per cycle in this environment is 1 irrespective of the number of APs in the test.
With variability in settings, the user will be able to start from one of several configurations and modify it to create any other kinds of environments the user can think of. It is important that the client has more than one AP option to roam to. This will allow the user to test the roaming algorithm of the client in a more real world scenario and check if the client roams to the best available AP.
Testing in the Presence of an Ecosystem
After measuring the roaming performance of the MDUT under ideal conditions, the next step is to measure the roaming delays of the MDUT under real world conditions. The same test described above is repeated but this time with the testing Wi-Fi cards actively generating ecosystem traffic that creates the real world network load scenarios under which the MDUT is expected to be deployed.
Testing hardware can create hundreds of WLAN clients that can actively connect to the APs and send and/or receive traffic. The test report generated shows the roaming delay measurements of each roam, similar to the test results shown, but now with the effect of the rest of ecosystem using the network.
The report also shows the performance metrics of other clients and traffic flows generated by testing hardware and software. The aforementioned testing shows how to test WLAN enabled medical devices in a controlled environment that will dictate the data integrity of how that device will operate in a real world environment.
For deployment purposes, other testing methodologies are recommended such as WaveDeploy, a site assessment and readiness solution for Institute of Electrical and Electronics Engineers (IEEE) 802.11 a/b/g/n networks that provides insight into the behavior of live networks in minimal time and allows IT managers and solution providers to see what their users see and experience.