Showing all posts tagged apple:

Designing Wireless Networks for Clinical Communications

Healthcare presents one of the most challenging wireless environments in today's networking world. The unique blend of critical network applications and expectation of high speed ubiquitous wireless access for everyone is challenge enough and then numerous devices are layered on top. Clinical communications are critical to providing a high quality of care and has become an especially challenging environment to plan for. This post is intended to offer some guidance in designing these networks.

The Emergence of the Smartphone as a Clinical Communications Tool

Smartphones are joining the healthcare scene at increasing rates, companies such as Voalte, Mobile Heartbeat, PatientSafe and Vocera are bringing new features and functionality to market and are transforming communications at the point of care. These devices are typically either Apple iPhones or the Motorola MC40, however plenty of other variations exist. Each of these phones have numerous differences in how they behave. This differences vary from when they roam to how they handle packet loss, etc.

Access Point Transmit Power

In preparing to design for a clinical communications network a desired endpoint should be known. In almost all cases, Smartphones tend to have lower transmit power than what most admins are used to. As a result, we are designing wireless networks with transmit power of 10-12dBm rather than 14-17dBm as many legacy networks were built. This reduction in access point transmit power drives up the number of access points required to cover a facility by 25-50% depending on construction.

Data Rates

Disable lower data rates to reduce network overhead and functional cell size.

Access Point Placement

Fast roaming is critical to the performance of Voice over WiFi and for Smartphones this typically means leveraging 802.11r and 802.11k. Understanding how these protocols work and their impact on roaming is essential for success of any network being designed to support clinical communications. As a wireless engineer tasked with this design, the goal is to create small, clearly delineated cells with enough overlap to facilitate the roaming behavior of these mobile devices. If designed poorly, 802.11k can be a detriment to device roaming. Some general guidelines to follow:

  • Access points should be mounted in patient rooms and out of hallways whenever possible
  • Leverage interior service rooms to cover longer hallways--clean storage, food prep, case management offices, etc.
  • If you must place an AP in a hallway
    • consider planning to use short cross unit hallways rather than the long hallways wherever possible
    • consider using alcoves to your advantage to reduce the spread of the RF signal
  • Leverage known RF obstructions to help create clean roaming conditions that favor 802.11k
  • Overlap may need to be as much as 20% due to roaming algorithms in the smartphones
  • Pay attention to the location of patient bathrooms, facilities where these rooms are in the front of the patient room (near hallway) offer far more challenges than those where it is in the back of the room
  • Stagger APs between floors such that they are not vertically stacked on each other

Voice SSID

Configure for a single band whenever possible - you'll find that some vendors are still only comfortable with 2.4GHz. From experience this can work, but is not without issues either. As a general rule, I recommend using AppRF to view the applications using the SSID and prioritize them properly. Smartphones are always talking via multiple apps on multiple ports and this should be accounted for.

All Apps Are Not Created Equal

Certain mobile communications apps are simply not ready for the demands of a healthcare environment. Take the time to understand exactly how these apps are being used, on multiple occasions I've seen perceived "dropped" calls as an app issue rather than anything to do with the wireless network itself.

Test, Test, Test

This is still a relatively new application for Voice over WiFi and it will require effort to get it right. Extensive testing is typically needed to get these deployments 100% dialed in. Tuning from AP placements to transmit power tweaks should be expected to some degree.

Google's Eddystone-Updating the Physical Web


Much ado has been made about the Apple iBeacon over the past couple of years with market analysts predicting a rise from $4B to $44B in iBeacon influenced sales. Outside of retail, some interesting use cases have cropped up and have been tested, however mainstream adoption for other verticals isn't there yet. Enter Apple's archrival Google with their Eddystone, an open-source, cross-platform low energy bluetooth (BLE) beacon. The open nature of the Google Eddystone and its ability to broadcast a URL offers some new and interesting use cases, especially since it no longer requires a mobile app. The requirement for a mobile app is the single largest hurdle to adoption of any beacon strategy as it requires end-users to opt in to using a company's solution in a major way. The upfront cost of a mobile app and often lack of understanding around mobile app strategy scares some companies away from attempting this and impedes the overall growth of the solution. Every conversation that I have had around iBeacon solutions to-date involves customer education around what is and is not possible and the level of effort required to make some things work.

What is Different?
Designed to be cross-platform, Google's Eddystone supports the Nearby API and is available on GitHub under Apache 2.0 license.

The Infobubble
Anyone interested in creating awareness of who they are, what they are doing, or empowering a device to do the same in a given location now has the ability to advertise to passersby. This has many implications from brand awareness to interacting with a specific device. Most importantly this can happen on the smallest of scales, increasing the chance for adoption and interaction since there is no dependency on a mobile app. Check out the Physical Web Cookbook for many newer ideas.

Multiple Frame Types
Google Eddystone supports multiple frame types enabling users to interact in a variety of ways. These frames are designated in the Service Data field associated with the Service UUID by using the high order four bits of the first octet. Github provides all this information in much more depth.

Frame Type
High-Order 4 Bits
Low-Order 4 Bits
(Reserved for Future Use)
Byte Value
Unique Identifier (UID)
0000
0000
0x00
Uniform Resource Locator (URL)
0001
0000
0x10
Telemetry Data (TLM)
0002
0000
0x20


Universally Unique Identifier (UUID)
If this sounds familiar, it is because it is the same type of identifier that iBeacons use. Google implemented the same 128-bit value that enables applications and specific use cases using major and minor numbers. This form of interaction is tied to a specific app and as such is limited to users who have that specific app installed.

URLs
The implementation of URL broadcast is meant to address the issues in which users aren't so interested in installing an app and caters to a "one-time use" scenario. This powerful option can provide a user with information through a standard web browser, ensuring that all users have access to this data. Effectively this URL broadcast could replace every instance of a QR code with the added benefit of not actually having to take a picture of the QR code, this data can just be available over the air.

Ephemeral Identifiers (EIDs)
A secured identifier that only permits authorized access. A 10-byte namespace is used to ensure uniqueness across multiple Eddystone implementations. Security is achieved using a truncated hash of a fully qualified domain name (FQDN) or an elided version 4 UUID which involves removing some information from the UUID.

Telemetry Data
Diagnostic data enabling an organization to better manage their beacon infrastructure. This includes battery life and other critical info. It is important to know that this type of information must be paired with either EID or URL since it does not contain a beacon ID. Telemetry data may include battery voltage, beacon temperature, advertising PDU count, and uptime.

Eddystone Ecosystem

Nearby API

Proximity Beacon API
The Proximity Beacon API is a new interface enabling users to manage their beacons via the cloud and use a REST interface. This enables monitoring of the telemetry data previously mentioned as well as reconfiguration of the beacons.

BKON Eddystone
I opted for the BKON Eddystones to try, there are a few options out there, but I liked the approach and packaging that I saw on the BKON site and acquired them through Amazon (2 for $60). AAA batteries were included and already installed. Also included a screwdriver and 3M dual-sided sticky tape. One thing I am not a fan of is the lack of screw type mounts as seen on the Aruba beacons. I'm not convinced the 3M sticky tape will hold up as long as a battery will, especially for beacons in tougher climates--outdoors, fridge/freezer, high humidity, etc. That being said though, the overall packaging and included items are great!

PHY.Net
Setting up with PHY.net was painless, simple field with beacon ID (located on side of beacon), valid email address and contact info. BKON sends a validation email to confirm.



Browsing...and a surprise
As of right now a specific browser is needed to browse the Physical Web. The screenshot to the right is from BKON's own "BeaconPages" available for IOS. Alternatively, you can install "Physical Web" available on both IOS and Android. I found it interesting that this Physical Web app picked up my HP printer via Bluetooth and let me view the configuration page. Interestingly, the Bluetooth radio is configured as "off" on the HP printer. I could pull my MAC and IP addresses, subnet mask, gateway, DNS info and host names via the Physical Web browser. I would have to log in to the printer to change any settings, but I was still surprised at how much information was readily available. Perhaps the next blog post will be on security.....