Sunday, March 15, 2015

WiFi Beacon

iBeacon specification has been around for some time now. While Estimote, and others have been focusing on the hardware itself and they are successful to some extent, we cannot see many software creating adopters of this technology.  The main problem is – what is the #1 use case of this technology? For me, it’s micro-location. You can get a notification based on your surroundings. You can argue why not use a GPS for that? Well, because GPS may not be available everywhere, especially in buildings. Nowadays we can encounter WiFi networks almost everywhere – in shops, schools, offices, even in public areas – so why to bother installing another iBeacon based infrastructure? WiFi access points (APs) can be used in the same fashion, iBeacons are used now, plus they can be used to connect you to the Internet. The only negative aspect of using WiFi for micro-location is that it’s possible to do it only on Android. But compared to Bluetooth LE, which is compulsory to use with iBeacons, and available since API 18 and only for those devices physically containing Bluetooth LE module, WiFi is present in Android API since its beginning. So if you think, that 76% of Android’s market share is covering your user base perfectly, and you don’t care for a dense infrastructure of beacons, you might be better of using WiFi beacons.
For example, you own a small chain of shops.  In each of those shops you have a WiFi AP, you can setup notifications based on presence of predefined APs in your application. WiFi range is often exceeding outside the physical premises, so you can notify users passing by your shop.  These notifications can be universal, or even shop specific – depending on the information broadcast by particular AP.

I propose to use following attributes for AP filtering:
MAC address
Service set identifier (SSID)
Channel – based on broadcasted frequency
Proximity – estimated proximity from the AP calculated from received signal strength. Proximity values can be: IMMEDIATE (distance from AP < 0.5 m), NEAR (distance from AP <= 4.0 m), FAR (distance from AP > 4.0 m)

While channel and proximity are fixedly set, MAC and SSID can be used also in the terms of sub-strings. MAC, having a format of XX:XX:XX:XX:XX:XX, can be used partially as a prefix for AP filtering. And SSID can offer even larger variety of possibilities. Having maximal length of 32 characters, it can be used to hold a lot of encoded information.

I have prepared a small demo app to demonstrate usage of this specification. This app uses prefix filtering on discovered APs. You can adjust the filtering in the settings section. But beware; inputs are not 100% fool proof, so pay attention to the values you are typing in. In the channels section enter channel numbers separated by comma.

Main activity displays all APs matching your search criteria, so you can use it for validation. Main activity is refreshed instantly, as fast as your device can perform WiFi scans.

After obtaining a set of newly discovered APs matching your filter criteria, you get a notification indicating how many APs that is. Notification scans are once in 10 seconds, but they may be faster, depending system WiFi scan broadcast. You can imagine here anything, from predefined text to dynamically obtained content for currently discovered AP or set of APs.

Purpose of this app is just to demonstrate filtering and notification capabilities, so don't expect any miracles from it. And please, give me some feedback! What do you think? Would you use WiFi beacons in your app? And if yes, what would you use it for?


  1. Hi Jonas, I have some questions about this topic:

    1) I would like to ask what do you think/know about power consumption of WiFi scan? In case of iBeacon, Bluetooth LE is used mainly because of low energy consumption. Is it possible to use scanning on background for hours without battery drain? Or will device last for few hours and die. I can't think of usage where user has application in foreground and is waiting for specific signal.

    2) How accurate can be proximity? Is it similar to ibeacon where some time it shows 5m another time 80m or can I assume something about this value? Is it usable in different situations than only knowing if I am near some ap?(have signal/don't have)

    3) What if I want to use more WiFi ap in one place. For example I have some places in big room and I want to know whether user is walking nearby some ap. Is it still usable? will the signal stay same or will it be lower and also proximity will not be accurate.

    Thank you for answering my questions.

    1. 1) Any radio being active on the device will cause battery drain, no matter how "low energy" its implementation is. In this case, WiFi scanning is done every 10 s in scan-only WiFi mode. For more info, see this blog post:

      2) Accuracy of measured proximity is very similar to the accuracy used in the iBeacon implementations, since it uses the same FSPL formula for calculating a distance. Also the displayed proximity regions are used in the same fashion.
      Usability other than determining my proximity to some AP is not very likely to appear. You would need more complex approach to get some sense of more precise location estimate.

      3) Sure, you can use it to determine user's proximity to AP, that's why it has 3 values of proximity. Calculated proximity depends on the clear line of sight to AP, therefore any obstructions in the way will cause calculation errors.

  2. Could I see the source code..