The Healthcare and Enterprise Wireless Experience

Smart Phones and the Challenges of Healthcare VoIP (Voice over IP)

Integra Systems, Inc., has had the opportunity to be associated with the WLAN space before Wi-Fi actually came to the market. That being said, we have learned a lot about mobile devices and the proper enterprise design by actual field design and deployment over eighteen years. Integra Systems was retained several years ago by a technology firm to design and deploy a WLAN VoIP solution in a very challenging environment. We just had to make it work. It worked in a flawless fashion.

So what are the challenges to the design of a WLAN voice over IP solution?
This is being described as the mobile device and WLAN radio. It has to be enterprise grade. What does this mean enterprise grade? Simply put the roaming algorithms have to be robust enough to maintain a secure connection back the WLAN controller while mobile. If not the call will drop.

The Design
Any WLAN design today should use predictive modeling based upon the actual construction materials of the building. For WLAN voice over IP, you need a signal strength of -65dBm and a co-channel interference of less than 2%.

The Gotchas
Smart phones were never designed to work in a highly mobile WLAN VoiP environment because of the inherent WLAN radio contained in the device. The primary use model is 3G/4G with the occasional connection to a hotspot. Integrators have attempted to try to resolve the client radio deficiencies by adding more WLAN access points. This only raises the noise floor and increases co-channel interface.

The Solution
Use a purpose built enterprise mobile solution that has WLAN client radio that supports fast roaming with the ability to handle all current security supplicants.
Design taking into account all the building materials with a criteria of -65dBm with a CCI of less than 2%

Smart Phones Voice SIP over Enterprise WLAN

As I have stated in previous blogs the use of a SIP client on a consumer based smart phone within the healthcare enterprise just will not work in a reliable fashion. First; smart phones were designed for the consumer “cool” experience and value advantage of connecting to the carrier for voice and data. With the premise...now data, and more data. How often do you actually see folks "talking anymore"? It was and is all about the smart phone user experience to drive the ARPU. (Average Revenue Per Unit) for the carrier. The carrier’s all currently control the “smart phone” and the connectivity to the tower. Dropping in a WLAN radio and BTLE (Bluetooth Low Energy) were important to include NFC (Near Field Communications) to increase valuation of the smart phone market and the user experience. The more stuff the better. In terms of the WLAN radio for the smart phone it has provided basic security and connectivity but in terms of enterprise roaming to ensure a persistent connection with enterprise grade security, this was not the goal. If it could connect to your home or a hotspot, that was good enough. From a business goal perspective, if this were to occur to work in a reliable fashion it would off load the ARPU of voice. Not a good business model perhaps for the carrier. Thus there is no incentive for smart phone manufacture's to improve the embedded WLAN radio side of things. So at the end of the day, the enterprise WLAN infrastructure vendors either through design or software will not be able to enable the limited resource WLAN smart phone device to operate in a bullet proof WLAN roaming fashion with the enterprise voice SIP WLAN. So for reliable healthcare voice connectivity, you need an enterprise client device that was designed for this. Trying to stick a round peg in a square hole will not cut it. In this case, it all about RF performance, which a lot of folks simply gloss over.

Download Voice_over_WLAN_v3-1

Download Mc40-brochure-en-us

Smart Phones and Voice over IP WLAN

Integra Systems, Inc. has engineered some of the toughest environments for voice over IP. Not only do you have to the right signal strength but also the correct CCI. In reality the clients algorithms also dictate the quality of the ability to maintain a call while roaming.

Voice over WLAN Roaming

At its most basic level, roaming in an enterprise IEEE 802.11 network occurs when an IEEE 802.11 client changes its access point (AP) association from one AP to another AP within the same WLAN.
Roaming is a client decision. The client is responsible for deciding it needs to roam, and then detecting, evaluating, and roaming to an alternative AP.

Roaming is a client decision. WLAN standards bodies (such as the IEEE) and industry bodies (such as the Wi-Fi Alliance) do not specify when a client should roam, or how the client determines to which alternative AP it should roam. Each vendor's roaming algorithms are proprietary and are not generally published.

Client Roaming Decision
IEEE 802.11 clients typically decide to roam when the connection to the current AP becomes degraded. Roaming necessarily has some impact on client traffic because a client scans other IEEE 802.11 channels for alternative APs, re-associates, and authenticates to the new AP. Prior to roaming, a client may take some actions to improve its current connection without necessitating a roam:
• Data retries—The IEEE 802.11 MAC specifies a reliable transport. Every unicast frame sent between a wireless client and an AP is acknowledged at the MAC layer. The IEEE 802.11 standard specifies the protocol used to retry the transmission of data frames for which an acknowledgment was not successfully received.
• Data rate shifting—IEEE 802.11a, IEEE 802.11b, and IEEE 802.11g each support a variety of possible data rates. The data rates supported for a given frequency band (such as 2.4GHz or 5GHZ) are configured on the WCS/WLC and are pushed down to the APs using that frequency band. Each AP in a given WLAN then advertises the supported data rates in its beacons. When a client or AP detects that a wireless connection is becoming degraded, it can change to a lower supported transmission rate (lower transmission rates generally provide superior transmission reliability).
Although the roaming algorithms differ for each vendor or driver version (and potentially for different device-types from a single vendor), there are some common situations that typically cause a roam to occur:
• Maximum data retry count is exceeded—Excessive numbers of data retries are a common roam trigger.
• Low received signal strength indicator (RSSI)—A client device can decide to roam when the receive signal strength drops below a threshold. This roam trigger does not require active client traffic in order to induce a roam.
• Low signal to noise ratio (SNR)—A client device can decide to roam when the difference between the receive signal strength and the noise floor drops below a threshold. This roam trigger does not require active client traffic in order to induce a roam.
• Proprietary load balancing schemes—Some wireless implementations have schemes where clients roam in order to more evenly balance client traffic across multiple APs. This is one case where the roam may be triggered by a decision in the WLAN infrastructure and communicated to the client via vendor-specific protocols.
• Scan threshold—The minimum RSSI that is allowed before the client should roam to a better AP. When the RSSI drops below the specified value, the client must be able to roam to a better AP within the specified transition time. This parameter also provides a power-save method to minimize the time that the client spends in active or passive scanning. For example, the client can scan slowly when the RSSI is above the threshold and scan more rapidly when below the threshold.
• Transition time—The maximum time allowed for the client to detect a suitable neighboring AP to roam to and to complete the roam, whenever the RSSI from the client's associated AP is below the scan threshold. The scan threshold and transition time parameters guarantee a minimum level of client roaming performance. Together with the highest expected client speed and roaming hysteresis, these parameters make it possible to design a WLAN network that supports roaming simply by ensuring a certain minimum overlap distance between APs.
• Minimum RSSI field—A value for the minimum RSSI required for the client to associate to an AP.
• Hysteresis—A value to indicate how much greater the signal strength of a neighboring AP must be in order for the client to roam to that AP. This parameter is intended to reduce the amount of roaming between APs if the client is physically located on or near the border between two APs.
Roaming Selection of a New AP
Channel Scanning
Wireless clients learn about available APs by scanning other IEEE 802.11 channels for available APs on the same WLAN/SSID. Scanning other IEEE 802.11 channels can be performed actively or passively as follows:
• Active scan—Active scanning occurs when the client changes its IEEE 802.11 radio to the channel being scanned, broadcasts a probe request, and then waits to hear any probe responses (or periodic beacons) from APs on that channel (with a matching SSID). The IEEE 802.11 standards do not specify how long the client should wait, but 10 ms is a representative period. The probe-request frames used in an active scan are one of two types:
– Directed probe—The client sends a probe request with a specific destination SSID; only APs with a matching SSID will reply with a probe response
– Broadcast probe—The client sends a broadcast SSID (actually a null SSID) in the probe request; all APs receiving the probe-request will respond, with a probe-response for each SSID they support.
• Passive scan—Passive scanning is performed by simply changing the clients IEEE 802.11 radio to the channel being scanned and waiting for a periodic beacon from any APs on that channel. By default, APs send beacons every 100 ms. Because it may take 100 ms to hear a periodic beacon broadcast, most clients prefer an active scan.
During a channel scan, the client is unable to transmit or receive client data traffic. There are a number of approaches clients take to minimize this impact to client data traffic:
• Background scanning—Clients may scan available channels before they need to roam. This allows them to build-up knowledge of the RF environment and available APs so they may roam faster if it becomes necessary. Impact to client traffic can be minimized by only scanning when the client is not actively transmitting data, or by periodically scanning only a single alternate channel at a time (scanning a single channel incurs minimal data loss)
• On-roam scanning—In contrast with background, on-roam scanning occurs after a roam has been determined necessary. Each vendor/device may implement its own algorithms to minimize the roam latency and the impact to data traffic. For example, some clients might only scan the non-overlapping channels.
Typical Scanning Behavior
Although most client roaming algorithms are proprietary, it is possible to generalize the typical behavior.
Typical wireless client roam behavior consists of the following activities:
• On-roam scanning—This ensures clients have the most up-to-date information at the time of the roam.
• Active scan—An active scan is preferred over a passive scan, due to lower latency when roaming.
There are some informational attributes that may be used to dynamically alter the roam algorithm:
• Client data type—For example, voice call in progress
• Background scan information—Obtained during routine periodic background scans
Ways in which attributes can be used to alter the scan algorithm include:
• Scan a subset of channels—For example, information from the background scan can be used to determine which channels are being used by APs in the vicinity.
• Terminate the scan early—For example, if a voice call is in progress, the first acceptable AP might be used instead of waiting to discover all APs on all channels.
• Change scan timers—For example, if a voice call is in progress, the time spent waiting for probe responses might be shortened during an active scan.

The Challenges of Using a Smart Phone for WLAN Voice over IP in the Enterprise Space

Many folks today like to use their own smartphones in the business environment, hence BYOD as well as tablets. In the case of healthcare, the IT organization may decide to use a certain brand of a “smart phone” for the use in clinical applications. There are perhaps some important things to understand and look at.

First pretty much all “smart phones” are consumer devices that were primarily designed for the consumer in mind. The attractiveness is the display, touch screen, user interface etc. And yes it is a literally a computer with the the ability of making that 3G/4G call.

To build some more value and allow the consumer to not have to incur all that data cellular usage cost (like videos); the manufactures decided to put in a WiFi radio chipset. It could be 802.11a/g/n, this is not really the issue. The main issue to realize is that for the price point that they are selling this at; it is more than likely not a robust radio designed for enterprise application requirements…but to connect to a “hotspot” or your home network. And the real use of the radio would be for data…not voice. Oh yes, most folks would be sitting in their chair.

Wireless voice over IP in the enterprise is a challenging application to just make work right. A lot of variable exist. For instance, the actual WLAN network has to be designed with a signal strength of -65dBm and a co-channel interference of less then 2% (ideal). This includes everywhere where you “think you might make a call…like in an elevator going down between floors”.

Now to the device itself and what is needed after you add a client application for WLAN VoIP. More than the likely the clinician when using a WLAN enabled smart phone for voice is not “standing” under an access point, but will be walking up and down the hallway, inside rooms, etc. on a call taking care of patients. To actually make a WLAN voice over IP call the clinician first has to authenticate to the network via a variety of security schemas that may be different for each institution.

Now this is when it gets interesting. As the person is walking down the hallway on a call, the radio in the “smartphone” has to initiate a nice gradual and clean handoff to the next AP “without” disconnecting while keeping the same authenticated network connection. If the radio algorithms for roaming are not sufficient or if the antenna is not great…the connection will drop. WLAN data is more forgiving as if you lose a few packets…the connection slows downs. However with voice the call is pretty much dropped..

As a side most WLAN radios are power hungry hogs even though this has been improved over the years. So to save power most mobile devices have what they call PSP and CAM modes. PSP (Power Saving Polling), simply means that the phone is idle with the radio on and when the connection is made (like a call), the radio ramps up the power to ensure a reliable connection. This saves a lot of power…thus keeping somebody from having to change batteries or plug it in. In the CAM mode (Continuous Aware Mode), the radio is powered up at the highest power setting to maintain a reliable connection….all the time.

So what does this all mean? A smart phone for WLAN data and WLAN voice over IP needs to last an entire shift in a healthcare setting. The combination of the big display sucking power and perhaps the need to put the device in CAM mode, just means it will not.

Options include charging (during a shift)…not an option…or adding a “sled with a battery”. Now that cool smart phone is a cool brick.

Integra Systems, Inc. and Wireless Forensic Analysis

Over the past year, Integra Systems, Inc., has provided forensic analysis of a system re-design for the Department of Defense on a very unique wireless VoiP deployment. We helped a major IDN on the East Coast to resolve a 150 square mile EMS deployment. Our expertise provided guidance and subject matter expertise regarding WMTS dropout with an IDN for a West Coast Hospital. Finally we drove what had to happen to enable a wireless medical prototype to be developed for moving a company from angel to venture funding. As on a chessboard we bring all the wireless pieces together in winning way.

Integra Systems Design of Specialized Wireless Solution

Integra Systems is working with www.plantronics.com for a custom designed wireless solution for a classified government facility. Just like for NASA, this design will be used within a suited environment with high backgound noise, but also adapted for wireless voice over IP. It will be the first of it's kind in the world.

Download MS_Series_Brochure

Wireless Integration and Design BSL- 4 for NIAID for the National Institute of Health

Integra Systems, Inc. is working with www.tcg.com to provide the SME for a very unique wirless voice over IP design. We are honored to be able to work with NIH to make this happen.
http://www.hemisphere-eng.com/showcase/high-containment/niaid-national-institute-of-health-integrated-research-facility-fort-detrick/

Vocera Use Model in RF Challenging Healthcare Environments

It has come to my attention this week that a major IDN seems to be having difficulty having a great experience with Vocera badges on Cisco infrastructure. www.vocera.com

 

While certainly I believe Cisco knows their stuff; the fact is that healthcare is a very, very challenging multi-path environment.  You add to the user model of the Vocera badge/or device often worn around the chest, then you have a perfect environment for the 2.4GHz signal to be attenuated by the water in the person’s body. Not unlink a telemetry transmitter.  You add then the small micro-strip antenna, it may work well in an open environment, but challenges remain for the demanding environment of healthcare. Perhap’s Ruckus offers some real technical advantages to make this application work better. www.ruckuswireless.com

BeamFlex consists of a smart, compact antenna array with multiple elements, which can be combined in real time to form unique antenna patterns. The advanced BeamFlex system software continually learns the environment with all its hostilities and interference sources, including disruptive RF conditions, numerous communicating devices, network performance issues, and application flows. Then, it selects the optimum antenna pattern for each communicating device in real time, while actively avoiding interference and minimizing noise to nearby networks and devices.

Beamflex provides

• Over 3X increase in performance and range
• 8X expanded coverage
• Stabilized wireless network performance, for picture-perfect video streaming and crystal-clear voice communications
• Maximized power efficiency
• Interference mitigation

Unlike omni-directional antennas that radiate signals in all directions, BeamFlex directs transmit energy towards the best path to the receiving device. And unlike fixed-positioned directional antennas, BeamFlex dynamically configures its "beam" on a per-station, per-packet basis, to achieve omni-directional coverage.

 

The Apple I-Phone and Voalte

It is interesting to see how the I-Phone has changed our mobility use model. Now the move being a voice over IP device and looking to help change the nursing care process.  The key issue here is www.voalte.com is engaging clinicians on their user experience, even the change of user interface.  A lot of voice over IP handsets were produced for many vertical markets but not specific to healthcare.  So at the end of the day they have tiny screens that just may be hard to read. Voalte can adapt each user's device to their way of using the device.  For instance if you desire to have large fonts, you can, smaller yes. This will help clinician's probably be more productive as either they respond to internal calls and or text messages. 

 

Wireless Network Security and Voice Over IP

Yesterday I had a long conversation with www.tpchealthcare.com about a whole wide range of topics surrounding wireless voice over IP and security. It seems that there are wide ranging discussions about this in the enterprise, primarily for performance reasons.  However the baseline is planning for the implementation, design, and overall an enterprise model such as AirDefense should be implemented across the entire healthcare enterprise ecosystem.  Attached are Cisco's guidelines for voice over IP deployments, a case study from Meru Networks, and an architecture review of AirDefense. You will note also that AirDefense is FIPS approved. Yes, this is Cisco 7920 phone, but in a nifty holster that probably is ideal for healthcare.  Since the 7920 is not IP54 rated, this definitely would help not having the phone potentially be damaged if dropped on a hard OR floor.

 

Download net_implementation_white_paper0900aecd804f1a46.pdf

Download SS6-0206_StJohnsHospital.pdf

Download airdefensewirelesssecuritysolutionsforhealthcare.pdf