Managing IoT at the Edge: The Case for BLE BeaconsMichael Haus

Technical University of MunichAaron Yi Ding

Technical University of MunichJorg O�

Technical University of Munich

ABSTRACTManaging IoT devices in urban areas is becoming crucial be-cause the majority of people living in cities and the numberof deployed IoT devices are steadily increasing. In this paperwe present iCon�g, an edge-driven platform dedicated tomanage IoT devices in smart cities. �e goal is to addressthree major issues in current IoT management: registration,con�guration, and maintenance. �e core of iCon�g is itsprogrammable edge module, which can be deployed acrosssmartphones, wearables, and smart boards to con�gure andinteract with physically proximate IoT devices. �roughtestbed experiments and usability studies, we reveal the hard-ship and hidden pitfalls in managing IoT devices, especiallyfor low budget Bluetooth Low Energy (BLE) beacons. Oursystem evaluation shows that iCon�g can e�ectively addressthe aforementioned IoT management challenges by harness-ing the mobile and edge cooperation. To inspire communitycontributions, we further present concrete use cases to illus-trate how iCon�g can reduce operational cost and facilitatefuture edge-centric IoT research.

1 INTRODUCTION54% of the world’s population lives in urban areas, and by2050, it could be 66 % [1]. Moreover, the number of deployedInternet of �ings (IoT) devices is steadily increasing andprojected to reach approximately 50 billions in 2020 [2]. Man-aging urban areas and its applications is hence becomingimportant. Urban IoTs support the smart city concept [3]which integrates traditional and modern information andcommunication technology (ICT) for a uni�ed and simpleaccess to services for the city administration and the resi-dents [4, 5]. �e aim is an enhanced use of public resources,improving quality of services for citizens while reducingoperational costs of public administration [4]. �e smartcity environments are based on a multitude of devices, suchas smartphones, sensors, embedded systems, smart meters[3]. Each of these devices have their own purpose, only to-gether they are able to satisfy all service requirements ofsmart cities. For instance, IoT boards serve as local gateways,collecting sensor data, and provide backend connectivity,whereas standalone Bluetooth Low Energy (BLE) beacons arecheap and simple to a�ach to many objects serving mainlyfor indoor localization and proximity detection of devices.

In spite of a growing demand for IoT management, thereis still a lack of tools to seamlessly manage large scale IoT

WebserviceControl

Interface

Config StorageConfig

StorageBackend

Edge Module

IdentifyRegisterUpdateUpdate

...

IdentifyRegisterUpdateUpdate

...Action Queue

Sync

hron

izat

ion

Co

mm

un

icat

ion

Inte

rfac

e

Configuration

Smart GlassSmart WatchSmartphone

Smart GlassSmart WatchSmartphone

Smart GlassSmart WatchSmartphone

Smart Environment

BLE Beacons

iConfig

IoT Boards

Add-on Servicesfor BLE Beacons- Monitoring- Debugging- Localization

Figure 1: iCon�g in the context of smart environ-ments

deployments in which ad hoc management is becoming un-tenable. We need an up-to-date overview of all distributeddevices during di�erent phases of their life cycle, includinginstallation, registration, user customization, and device con-trol. Moreover, the IoT con�guration framework should bevendor independent and support a diverse range of devices[6]. We identi�ed three main challenges for IoT manage-ment. First, IoT devices are installed at various locations,which requires a uni�ed management process and is di�-cult to handle in large scale deployments. Second, there isno well-de�ned IoT management procedure that covers allnecessary operations corresponding to each phase of the lifecycle for IoT devices. �is causes management overhead andinformation fragmentation. �ird, manual e�orts needed tocon�gure those distributed IoT infrastructures are time con-suming and error prone, which further increase operationalcost [8].To tackle these challenges, we propose iCon�g, an edge-

driven platform that takes care of all installed IoT devices.�e framework covers the entire device life cycle: registra-tion, con�guration management, monitoring, and debuggingof IoT devices. Moreover, our design aims to control the fullspectrum of IoT devices, from high end IoT boards to lowbudget BLE beacons. iCon�g enables automated edge devicemanagement and hence minimizes operational cost. Fig. 1shows iCon�g in the context of smart environments takingadvantage of programmable devices to run edge moduleson smart glasses or IoT boards. �is allows iCon�g to con-nect various IoT devices to its management backend, whichenforces a uni�ed con�guration procedure. As an example,we successfully tested iCon�g on Android smartphone and

smart glass [7]. In particular, the iCon�g edge modules arededicated for users interested in managing and interactingwith IoT environments.

�e design principles of iCon�g: 1) automatic con�gura-tion of IoT devices to avoid miscon�gurations which becomeone of the dominant causes of system failures [8], 2) easyto use frontend, 3) device orchestration via global view, and4) serving as a platform for developers and researchers toenable add-on services.

�e key contributions are summarized as follows:

• We analyzed and identi�ed key properties of IoTdevice management that must be a�ained to managelarge scale deployments in smart cities.• We designed and implemented iCon�g, an edge-driven platform dedicated for IoT device manage-ment. We demonstrate the e�cacy of iCon�g viaprototype implementations, which target at BLE bea-cons without backend connectivity.• Our usability study and testbed experiments further

uncover the hidden aspects in IoT management thatare important and deserve future research.

�e rest of the paper is structured as follows. Section 2de�nes requirements for IoT device management. Section 3introduces BLE beacons and Section 4 highlights di�erentuse cases of iCon�g. In Section 5 we present the system ar-chitecture, work�ow, and implementation details of iCon�g.�e evaluation in Section 6 consists of performance testsregarding memory usage and system scalability. In addition,we conducted a user study to show di�erences between man-ual and automatic device con�guration. Section 7 presentsrelated work and Section 8 provides a discussion about userinteractions with their surrounding devices. We concludeand outline future work in Section 9.

2 REQUIREMENTS FOR IOT DEVICEMANAGEMENT

A major challenge for IoT is the management and con�gu-ration of pervasive deployments, especially for IoT deviceswithout backend connectivity. We identi�ed three stages ofIoT device management.

�e �rst stage covers device deployment and registration,in which the device is identi�ed and initially con�guredwith default se�ings. A�erwards, the device is registered ata backend service combined with location information. �ismanual �rst step is done only once per device.

Second, automated con�guration of device parameters isthe fundamental service for IoT devicemanagement. �e con-�guration parameters depend on the speci�c device. �ereby,we classify IoT devices into two di�erent types: standaloneand connectivity devices. Standalone devices are only equippedwith limited short-range transmission techniques, such as

near �eld communication (NFC), ultra-wideband (UWB), Zig-Bee, and/or Bluetooth. �ese IoT devices (e.g., BLE beacons)have no backend link and require additional edge modulesfor device management. �e edge modules can run on plat-forms which support short-range communication and pro-vide a backend link. In contrast, connectivity devices (e.g.,smarthome gateways) have a connection to the backend ando�er easier device management.�ird and �nal stage of IoT device management refers

to the centralized backend service which receives deviceregistrations together with con�guration data. �is enablesmultiple add-on services: 1) monitoring of distributed IoTdevices via global view, including con�guration status orlocalization of broken devices for replacement, 2) debuggingof IoT devices via collected maintenance data, such as up-time or ba�ery voltage to identify malfunction devices, 3)so�ware and �rmware updates distributed via central back-end service which ensures up-to-date so�ware versions andimproves IoT security, and 4) parameter updates for a setof devices. �ereby, the device selection can be based ondi�erent criteria, such as close proximity among IoT devices.Our case study targets at BLE beacons, which represent

one of the most challenging classes of IoT devices due tomissing backend connectivity. Furthermore, the number ofdeployed beacons will be much higher than the number ofIoT boards. �us, it’s important to have a scalable frame-work which covers the de�ned requirements for IoT devicemanagement.

3 BLE BEACONS�e ba�ery powered BLE beacons are small-size wirelessdevices that transmit a short-range BLE signal to mobilecomputing devices (e.g., smartphones) [9]. Via BLE, users’devices are noti�ed of the beacon proximity by receiving sig-nals which contain contextual information, typically aboutindoor surroundings and its contents. �us, the receivingend is able to perform location aware actions, such as access-ing speci�c URLs for marketing purposes [9]. For example,the Los Angeles International Airport uses Bluetooth bea-cons to track and dispatch wheelchairs for passengers inneed of assistance [10]. In another scenario, universitiesuse beacons to help students navigate through the library,guiding them to resources, study spaces, and services in thelibrary [11].Our beacons [12] are capable to send three di�erent BLE

message formats and can be locked via a password. �eprimary beacon standards are Eddystone and iBeacon. Eddy-stone is a protocol speci�cation that de�nes a BLE messageformat for beacons [13]. It describes di�erent frame typesto transmit device identi�er, URL, or telemetry data con-taining ba�ery voltage, beacon temperature, count of adver-tised packets, and uptime. In contrast, the iBeacon standard

2

[14] transmits only a device identi�er. Besides that, the bea-con vendor added an own proprietary BLE message formatnamed sBeacon to transmit another �xed device identi�erimprinted on the beacon.

4 ICONFIG USE CASES�e ability of iCon�g to programmatically adjust device pa-rameters facilitates di�erent use cases. For example, we usediCon�g to set up an automated testbed for research projectsto adapt BLE parameters, such as transmission power orpacket advertisement rate. �e goal was to measure the in-terference between BLE and Wi-Fi because both wirelesstechnologies work on the same frequency of 2.4 GHz. More-over, iCon�g supports debugging and monitoring of BLEbeacons by collecting maintenance data, such as uptime andba�ery voltage of each device. �e long term bene�ts of iCon-�g come from add-on services based on the programmableinterface of iCon�g. In the context of a smart city manage-ment for dense, co-deployed IoT devices, the energy-awarecon�guration of devices is important. For instance, the devel-oper can use iCon�g to add a module to the iCon�g backendto turn o� devices at speci�c times.

5 ICONFIG DEVICE MANAGEMENT�e goal of iCon�g is to manage various IoT devices byutilizing programmable edge platforms. In our case study,we focus on the management of BLE beacons as low budgetIoT devices. �is section presents the system architecture ofiCon�g and the corresponding working �ow for IoT devicemanagement. In addition, we provide implementation detailsregarding so�ware libraries and BLE communication.

5.1 System Architecture and Key Features�e iCon�g system architecture, as illustrated in Fig. 1, con-sists of twomajor modules: mobile edge module and backendmodule. �e framework is able to identify, register, and up-date IoT devices (in our case BLE beacons). Supported byour speech recognition, a user wearing an iCon�g-enabledsmart glass can discover, register, and con�gure BLE beaconswhile walking around. �e edge module is intended to runon mobile devices (e.g., smart glasses, smartphones, tablets)and on static devices like IoT boards. �e backend module ofiCon�g runs at a centralized infrastructure, such as a localserver or in the cloud.

�e iCon�g edge module uses a central action queue for allbeacon operations to synchronize user actions (identify andregister) with automated updates of beacon se�ings. �ereby,user interactions are prioritized over automatic beacon up-dates. Each device action occurs via threads to immediatelystart the next action from the central operation queue. Dur-ing registration and update of BLE beacons, the edge module

Admin

BLE Discovery

Register

IdentifyCorrect?

Alert

Write

Start

Show Beacons

Result

Updates

Result

WriteResults

UseriConfig

BackendiConfig Edge

ModuleBLE Beacons

Registered BeaconsConfiguration Updates Updates

Result

Configuration Updates

Register

Config Synchronization

Figure 2: iCon�g work�ow

collects maintenance data which enables monitoring of bea-con health and detection of broken beacons. To update BLEbeacons, we aggregate received signal strength indication(RSSI) for each beacon and update beacons according todescending RSSI sum, which means nearest beacons �rst.Besides that, the iCon�g edge module works in two di�erentmodes: o�ine and online depending on connectivity to thebackend. In o�ine mode, beacon con�gurations are storedand loaded from local storage for later synchronization tothe backend.

�e iCon�g backend stores all device data at a central stor-age. We ensure that only beacons are updated where BLEparameters are actually changed. Furthermore, the iCon�gbackend provides a control interface including status aboutdevice update, functionality (e.g., broken BLE beacon), de-vice health, and o�ers localization via indoor map and placeimage.

5.2 Work�ow�e main task of the user is to register IoT devices (in ourcase BLE beacons). �erefore, the user holds a smartphonerunning the iCon�g edge module and walks around to dis-cover nearby BLE beacons. At the application start, the edgemodule automatically received registered beacons via iCon-�g backend and shows only unregistered beacons, whenthey are discovered by the user. Fig. 2 presents the iCon�gwork�ow.

A�er discovering unregistered beacons, the user is ableto identify one beacon at a time. �e beacon shows a redlight as feedback for device identi�cation. When the beaconidenti�cation was successful, the user can register the bea-con to the iCon�g backend with additional information fordevice localization, such as nearest room number, pictureof device place. A�erwards, during registration, the edgemodule will automatically con�gure the BLE beacon witha default con�guration including password, iBeacon, andEddystone identi�er to ensure that the device is ready to use.Finally, the edge module will synchronize all con�guration

3

data to the backend. �e registration has to be done onlyonce per beacon.For advanced management, iCon�g backend provides a

control interface for the administrator, including a globalview about installed BLE beacons. �e administrator hastechnical knowledge and is responsible to manage the reg-istered BLE beacons. �erefore, the administrator is able toadapt multiple device con�gurations at once. �is is possibleby linking devices to groups and groups to con�gurations.

�e device update of a BLE beacon is independent of useractions and automatically triggered when two conditions aresatis�ed: 1) adapted BLE con�guration from administratorvia iCon�g backend available, and 2) beacon is currentlydiscovered by the user via iCon�g edge module. �e updateprocess runs in the background of the iCon�g edge mod-ule, only recognizable by blinking red lights as feedback ofsuccessful con�guration.

5.3 Implementation DetailsWe implemented two prototypes of the iCon�g edge modulefor di�erent device types: smartphone and smart glass. Wetake advantage of speech recognition to enable hands-freedevice con�guration. On the smartphone the speech recog-nition can be optionally activated, on the smart glass it isautomatically activated to allow a convenient usage of theiCon�g edge module.For beacon con�guration, the Eddystone standard pro-

vides a Bluetooth Ga� service for URL con�guration. An-other service allows the adaption of all Eddystone parame-ters. �is service was not available for our beacons and doesnot cover all BLE parameters. We hence used the communica-tion library provided by the beacon vendor [15], which usesa customized communication interface for beacon con�gura-tion. �e communication library works asynchronously viacallbacks to provide the result to set beacon parameters.�e iCon�g backend is implemented in Python and pro-

vides a REST API and a control interface via cherrypy. �ebeacon device data can be stored in any database. In ourcase, we use MongoDB to store device con�gurations, onedocument per beacon. Moreover, we use an URL shorteningservice to overcome the limit of 17 bytes for the EddystoneURL �eld. For system security, the password of each beaconis stored encrypted in MongoDB via AES encryption. In ad-dition, SSL secures the wireless network connection betweeniCon�g edge and backend module. �us, common a�ackssuch as man-in-the-middle or sni�ng are not possible.

6 EVALUATIONWe analyzed the system performance of iCon�g regardingmemory usage and con�guration scalability over multiplebeacons. Moreover, we breakdown the con�guration timefor one beacon to show the duration of each con�guration

part. Additionally, we conducted a user study to highlightdrawbacks by manually con�gure IoT devices.

6.1 System PerformanceRegarding the memory usage of iCon�g edge module, wemeasured a deployment on Android smartphone (OS 7.1.1)in o�ine and online mode during con�guration of ten BLEbeacons. In online mode, the edge module used 6.50 ±0.98MB similar to o�ine mode with a memory usage of6.47 ± 0.96MB. �ese results show that the memory foot-print of the iCon�g edge module is small enough to run onprogrammable IoT devices.�e next evaluation part of iCon�g refers to the beacon

con�guration. As illustrated in Fig. 3 (a), we breakdown thecon�guration time for one beacon over 20 rounds. �ereby,we measured a total con�guration time of 2.56 s shared oversix di�erent con�guration phases. �e connectivity andmaintenance phase takes almost half of the con�gurationtime (41 %). �e connectivity phase consists of connect anddisconnect time. It shows the largest time �uctuation due tointerference among BLE beacons. Regarding device con�gu-ration, to set the password takes most of the time (25 %). Tocon�gure Eddystone packets, including telemetry, URL, andidenti�er sum up to 21 % of the con�guration time. iBeaconand vendor speci�c sBeacon takes less time. Our results showthe worst case, in which all con�gurable �elds are adapted.Usually, the identi�ers for Eddystone and iBeacon are setonly once during device registration.For scalability testbed and to evaluate iCon�g in a dense

deployment we placed ten beacons in a circle with a diameterof 1m around the smartphone running iCon�g edge module.�ereby, we evaluated ten cases (from one to ten beacons)each over 20 rounds. All BLE parameters for transmissionpower (5 dBm - 80m) and advertisement rate (10Hz - 10times a second) were set to the maximum, which re�ectsthe worst case se�ing in terms of interference among BLEbeacons. Our evaluation yielded 18 unauthenticated connecterrors (meaning BLE con�guration is not possible) out of1100 connect a�empts, i.e., rate of 1.64 %. Fig. 3 (b) illustratesscalability results when con�guring ten BLE beacons againstten cases each over 20 rounds. �e con�guration time showsa linear increase over all beacons, on average an increase of2.2 s per beacon. In addition, we evaluated the success ratewhich describes whether con�guration parameters were cor-rectly set. A success rate of 100 % means that all parametersare correctly set to the prede�ned value. In our evaluation,the lowest success rate was 75% during the con�gurationof four beacons. In most cases, iCon�g achieved a successrate of 100 %. In our testbed with a dense deployment of BLEbeacons and high interference among devices, iCon�g is stillable to achieve a reasonable con�guration time per beaconwith high success rates.

4

Total

Password

Connectivity

Eddystone

MaintenanceiBeacon

sBeacon

0.06

0.12

0.25

0.50

1.00

2.00

4.00

Dura

tion

(s)

2.56

0.630.56

0.53 0.48

0.23

0.071 2 3 4 5 6 7 8 9 10

Num. Beacons

5

10

15

20

25

Dura

tion

(s)

2.75.3

7.510

12.4

15.116.5

16.417.8

22

Total config timeSuccess rate

0.2

0.4

0.6

0.8

1.0

Rate

(a) Breakdown of con�gurationtime for one beacon

(b) Con�guration time andsuccess rate from one to ten

beacons

Figure 3: iCon�g system evaluation

6.2 Usability StudyOur user study serves two purposes: 1) to reveal the gapbetween a manual and automatic con�guration system, and2) to test the application interface of the iCon�g edge mod-ule. In total, ten persons participated in the study, all PhDstudents or Postdocs with a strong background in computerscience. �e user study consisted of a questionnaire and thecon�guration of BLE beacons. �e participants manuallycon�gured three beacons with a prede�ned con�gurationusing the vendor application [16]. In the next step, the samebeacons were registered via iCon�g, in which the defaultcon�guration was automatically wri�en to each BLE beacon.For each beacon, we calculated the success rate by compar-ing prede�ned con�guration with actual beacon se�ings.�e con�guration time for the vendor app was taken man-ually. Fig. 4 (a) shows the con�guration time per beacon.�e manual con�guration took in average six times longerthan the iCon�g automatic con�guration, which re�ects atime saving of 83 %. �e results show a slight decrease ofcon�guration time when the user is more familiar with thecon�guration system. Fig. 4 (b) presents the success rate,how many parameters were correctly set at the beacon. Incase of manual con�guration, the lowest success rate overall beacons was 58 % and the median is around 92 %. In total,only 1/3 of all manual con�gurations were entirely correct.On the other hand, our iCon�g framework achieved for allBLE con�gurations the success rate of 100 %. In general, thisshows that the manual con�guration of BLE beacons is timeconsuming and error prone due to type errors by users. Fig. 4(c) presents the iCon�g edge module to register BLE beaconsand Fig. 4 (d) illustrates the iCon�g control interface whichis part of the backend module.In the following questionnaire, most participants rated

the manual con�guration via the vendor app as di�cult. Onthe other hand, the automatic con�guration by iCon�g wereentirely rated as easy. �e con�guration process is fasterand device registration requires less manual input by theuser. Moreover, we asked the participants of the user study

1 2 3Beacon

1

2

4

8

16

Dura

tion

(min

.)

10.82 10.19 8.99

1.861.49 1.59

ManualAutomatic

(a) Con�g duration per beacon

1 2 3Beacon

0.2

0.4

0.6

0.8

1.0

Succ

ess r

ate

0.92 0.92 0.941 1 1

ManualAutomatic

(b) Con�g success rate per beacon (c) iCon�g edge module

(d) iCon�g control interface (reduced due to space limits)

Figure 4: Results of user study and screenshots ofiCon�g framework to administrate IoT devices

for useful features of the iCon�g backend. �e monitoringof beacon health and the localization of beacons achievedhighest consent.

7 RELATEDWORKA majority of the related work are dedicated to services tak-ing advantage of beacon deployments, while BLE beaconsthemselves are not considered. �e work in [17] presenteda system where an IoT hub is dynamically selected from achanging set of users’ devices. �e IoT hub is responsible forcon�guring a set of services running on proximate devices toensure an e�cient management of available resources. Har-ris et al. [18] used BLE-tagged products for inventory control.�eir work included a detailed analysis of BLE regarding sig-nal propagation, deployment, and protocol a�ributes. Inour case, iCon�g is dedicated for IoT device managementincluding BLE beacons.

5

Indoor localization and proximity detection are major usecases for BLE beacons. Faragher et al. [19] found that BLE po-sitioning systems provide a higher accuracy compared withWi-Fi �ngerprinting. �e authors of [20] proved the feasibil-ity of using BLE beacons for proximity detection in workingplaces. �e detailed analysis of BLE parameters, such as ad-vertising interval and transmission power shows the impactof these se�ings on the proximity detection mechanism. An-other use case is highlighted by Michalevsky et al. [21] usingcryptographic secret handshakes over BLE protocol. �eirproposal can enable private communication among nearbydevices without central servers, which addresses a crucialconcern for privacy in device-to-device (D2D) communica-tion [22].

8 USER INTERACTIONSA key observation from our user study and experiments isthat the interaction among users, their smart gadgets and sur-rounding IoT devices via the conventional screen-keyboardsetup is far from optimal. Especially for smart cities with amultitude of services empowered by IoT devices, the systeminteraction should be more natural and �uent. Even whenusers adopt iCon�g on smartphones, the keyboard inputis still hindering the user experience no ma�er how auto-mated iCon�g has made the entire con�guration process.�is is the main reason for our second prototype dedicatedfor wearables (e.g., smart glass). �e combination of speechrecognition and hands-free devices can enable a more in-tegrated interaction during user movement and limit thedistraction of user a�ention. iCon�g is hence endeavoredto enhance user experience and to streamline managementof large scale IoT deployments, especially for low budgetdevices such as BLE beacons without backend connectivity.

9 CONCLUSION AND FUTUREWORKWe designed and implemented iCon�g for IoT device man-agement in smart cities. �e goal is to streamline the man-agement of large scale IoT deployments, especially for lowbudget devices such as BLE beacons. We have evaluatediCon�g in two ways. In the usability study, we revealedthe hardship introduced by existing mechanisms. Our re-sults highlighted the time saving and higher success rates ofiCon�g owing to its automatic con�guration with minimaluser interaction. �e system evaluation of iCon�g furtherrevealed a small memory footprint of the mobile edge mod-ule, making it suitable for various smart devices. We alsoevaluated the robustness and scalability of iCon�g by con�g-uring multiple BLE beacons in a testbed. �e con�gurationtime scales linearly with high success rates. Moreover, wediscussed several use cases enabled by iCon�g, such as dy-namic adjustment of beacon parameters for IoT testbeds, ande�cient detection of broken devices. For future work, we

plan to enhance the mobile edge module. An immediate stepis to port the current Android implementation to Linux envi-ronment, which can be deployed on multiple programmableIoT boards. �is will ensure a more reliable and faster updateprocess by using iCon�g platform to unify the managementof edge and IoT devices. Besides that, another extension is toimprove synchronization redundancy when several iCon�gedge modules are in o�ine mode and ready to update BLEbeacons with latest device se�ings.

REFERENCES[1] h�ps://esa.un.org/unpd/wup/publications/�les/wup2014-highlights.

Pdf (visited on 05/29/2017)[2] h�ps://www.statista.com/statistics/471264/iot-number-of-

connected-devices-worldwide/ (visited on 05/29/2017)[3] Scha�ers et al. Smart Cities and the Future Internet: Towards Coop-

eration Frameworks for Open Innovation. In Future Internet. LectureNotes in Computer Science, Vol. 6656. Springer. 2011. 431–446.

[4] Zanella et al. Internet of�ings for Smart Cities. IEEE Internet of �ingsJournal 1, 1 (2014), 22–32.

[5] Zdraveski et al. ISO-Standardized Smart City Platform Architectureand Dashboard. IEEE Pervasive Computing 16, 2 (2017), 35—43.

[6] Dalipi et al. EC-IoT: An Easy Con�guration Framework for Con-strained IoT Devices. In Proceedings of the IEEE 3rd WF-IoT. 2016.

[7] h�p://madgaze.com/x5/ (visited on 05/29/2017)[8] Xu et al. Systems Approaches to Tackling Con�guration Errors. ACM

Computing Surveys 47, 4 (2015), 1–41.[9] Wang et al. Managing Large Scale, Ultra-Dense Beacon Deployments

in Smart Campuses. In Proceedings of IEEE INFOCOM WKSHPS 2015.[10] h�p://www.airport-world.com/news/general-news/5976-lax-uses-

bluetooth-beacon-technology-to-improve-wheelchair-operations.html (visited on 05/29/2017)

[11] h�p://www.edtechmagazine.com/higher/article/2017/02/bluetooth-beacons-could-improve-student-experience-higher-ed-campuses(visited on 05/29/2017)

[12] h�p://bluvision.com/wp-content/uploads/2016/12/Specs-iBEEK1.6.pdf (visited on 05/29/2017)

[13] h�ps://github.com/google/eddystone (visited on 05/29/2017)[14] h�ps://developer.apple.com/ibeacon/ (visited on 05/29/2017)[15] h�p://developer.bluvision.com/developer/beeks-beacons-sdk/ (visited

on 05/29/2017)[16] h�ps://play.google.com/store/apps/details?id=com.bluvision.

beaconmaker (visited on 05/29/2017)[17] Varshavskiy et al. MiHub: Wearable Management for IoT. In Proceed-

ings of the WearSys. 2016. 1–6.[18] Harris et al. Smart LaBLEs: Proximity, Autocon�guration, and a Con-

stant Supply of Gatorade(TM). In Proceedings of the 1st IEEE/ACM SEC.2016. 142–154.

[19] Faragher et al. Location Fingerprinting With Bluetooth Low EnergyBeacons. IEEE Journal on Selected Areas in Communications 33, 11(2015), 2418–2428.

[20] Montanari et al. A Study of Bluetooth Low Energy Performance forHuman Proximity Detection in the Workplace. In Proceedings of theIEEE PerCom. 2017. 1–10.

[21] Michalevsky et al. MASHaBLE: Mobile Applications of Secret Hand-shakes over Bluetooth LE. In Proceedings of the 22nd MobiCom. 2016.

[22] Haus et al. Security and Privacy in Device-to-Device (D2D) Commu-nication: A Review. IEEE Communications Surveys & Tutorials 20, 2(2017).

6