Indoor Wi-Fi Location and Beacons: Better Together Part 2

Location-based services have been getting a lot of attention lately and people are increasingly curious about how Wi-Fi and beacons play together in the hot space that is indoor location technology. In my last blog I reviewed how beacons work and how to differentiate when to use Wi-Fi and beacons. There’ve been some great questions about beacon technology and how it complements Cisco’s location-based Connected Mobile Experiences (CMX) solution, so I want to follow up on these topics with everyone.

What types of beacons are there?

Generally, there are two different classes of beacons: transmit only and backhaul enabled.

Transmit only beacons are exactly as they sound – they simply transmit information to anyone that is capable of hearing (bluetooth enabled smartphones). They do not receive or pass any data or information upstream.

Apple’s iBeacon is the best example of this type of BLE beacon. You can think of them like the navigational beacons used by airplanes when on approach to major airports. The beacon doesn’t even know the plane is there, but the plane is aware of the beacon and knows where the beacon is allowing it to take the correct action. Same is true for smartphones and transmit only beacons like iBeacon – the intelligence is located in the mobile application which must recognize the beacon and take appropriate action.

Backhaul enabled beacons generally include a Wi-Fi chipset for either management or data capabilities. Some backhaul enabled beacons are USB enabled and take advantage of whatever connectivity exists within the PC they are connected. These beacons are much rarer than transmit-only beacons, but do exist and can be used to gather more information/data. However, given communication capability, they do provide an opportunity for superior beacon hardware management.

How does the client device connect to the beacon?

Per the discussion on the nature of beacons, for transmit only beacons, no connection is made. The phone simply hears the “beacon” and responds to it. For the backhaul enabled beacons, some type of bluetooth profile is used to form a connection. The nature of the connection and the profile used depend on what the beacon provider is doing.

When the client device connects, how does it receive instructions—does the information get pushed into web browser or does some mobile app have to be pre-installed?

So far, all of the BLE implementations require a mobile application in order to do anything.

What is the difference between the beacons and the navigation part of Cisco’s Connected Mobile Experiences (CMX) solution? Could they be used together?

The biggest difference between a beacon solution and a network or infrastructure solution is where the location intelligence resides. In most beacon solutions, and in particular iBeacon, all of the intelligence must reside in the mobile application. The mobile app is the component that reacts to the beacon and must know where the beacon is. In the case of Cisco CMX, the Wi-Fi network calculates the location of the device. That location information can then be used for analytics or relayed to the mobile application for positioning.

Per the original post, the two can definitely be used in combination. BLE beacons solutions can be used to provide proximity based interactions for experiences where you want to be highly certain that a user is very close (within a meter) of some location. Cisco CMX, on the other hand, can provide way finding and collect analytics on customer movements throughout a store. These solutions are absolutely complementary and many customers are looking to deploy both technologies to deliver on their customer engagement goals.