Wireless Communications and Mobile Computing
Volume 2018 (2018), Article ID 2182614, 17 pages
https://doi.org/10.1155/2018/2182614

Research Article

Space Occupancy through BLE Dynamic Broadcasting

Miran Borić, Rebeca P. Díaz Redondo, and Ana Fernández Vilas

Information & Computing Lab., atlanTTic Research Center, School of Telecommunications Engineering, University of Vigo, 36210 Vigo, Spain

Correspondence should be addressed to Miran Borić; mboric@det.uvigo.es

Received 19 April 2018; Revised 23 July 2018; Accepted 17 September 2018; Published 18 October 2018

Academic Editor: Luca Foschini

Copyright © 2018 Miran Borić et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

Abstract.

Internet of Things (IoT) merges different technologies to provide the needed infrastructure for an adequate inter-device connection and data exchange, with Bluetooth Low Energy (BLE) being one of the latest acquisitions. The use of BLE beacons offers a straightforward approach to broadcast information to any device being in the coverage zone and able to process such signal. Instead of this static solution, in this paper, we face an alternative approach that, combining both Wi-Fi and BLE beacon technologies, is able to dynamically adapt the information being broadcast depending on the particular devices in the coverage area. Taking advantage of the beacon device communications, we propose to monitor the space occupancy throughout the study area (typically inside a building) by following the beacon device data exchange. This information would be later used to improve space analysis. As a proof of concept, we have conducted an experiment inside a faculty to check the potentiality of the proposal, obtaining promising results.

1. Introduction

Using smart environments nowadays in urban areas is mostly indoor [1], e.g., private homes, offices, and shopping centers. In the same manner, smart environment represents a heterogeneous field that combines different technologies [2]. Furthermore, the primary objective of smart environments and IoT is to make a connection between the virtual and the physical world. For this to be possible, different technologies have arisen and are actually combined to solve not only these but other problems in smart environments [3, 4]. One of these technologies is Bluetooth Low Energy (BLE). It incorporated itself into almost every human wearable, such as smartphones and smartwatches. [5]. Thanks to its low-power capability and minimum energy consumption [6, 7], BLE gives developers, researchers, and IT enthusiasts a perfect foundation to bring their IoT ideas to the real world.

However, one class of BLE, sometimes called a BT flavor, is the beacon technology, and lately, it found its place in many aspects of the IoT concept [8, 9]. Beacon devices are little hardware transmitters that are capable of broadcasting a specific preconfigured identifier to the nearby electronics. Such technology enables smartphones, tablets, and different wearables to perform a particular kind of action when near a beacon. Although it applies to a various type of scenarios, it is mostly used for indoor positioning [10, 11]. What is more, identifying occupied indoor spaces within some particular building is fundamental for many reasons such as better building optimization and management of emergency situation evacuation plan. With the rise of global Bluetooth beacon devices market and predictions that forecast its growth [12], many companies offer a different kind of products with beacon possibilities, all based on BLE beacon broadcast capability [13, 14]. Basic beacon devices often do not provide advanced features, and managing them can also present a challenge. Excellent centralized systems that can control all the beacons at the same time exist, but they are either too expensive or part of some bigger commercial solution [15]. Therefore, in many circumstances, we need to manually approach each beacon to ensure that it still works and transmits the signal, or even to make some configuration changes. Furthermore, most of the commercial beacon devices associate their beacon to one advertisement, and that is their most significant disadvantage. It also means that if we want to advertise different information in the broadcasting area, every beacon device needs to be associated with the specific beacon signal. What is more, having many beacon devices in a small sized area is not so convenient, and it makes network wireless congestion and loads even worse [16], keeping in mind that all the beacons are operating in the 2,4 GHz ISM band.

In this paper, we present a solution for monitoring space occupancy through dynamic BLE information broadcasting by extracting interaction statistics between the system and the users’ smart devices. The idea is to dynamically broadcast different information to different users and to potentially use that information for space occupancy. By “dynamic”, we mean that a beacon device can deliver different information to different profiles simultaneously. For space occupancy monitoring, we use feedback from the devices that are directly related to the user position while receiving the broadcast. First, this input gives us an indoor user position insight. Second, such output can also be used by building managers, to design the inside of the building the way that it will be used better and make its usage even more productive and functional. Optionally, user position could help us in profiling users. That said, by analyzing his position it is possible to define their profiles according to the areas that they have been using. Any message dissemination system may use this solution since it is easy to integrate it into existing infrastructures with minimum investment. In our previous research we have already developed the dynamic beacon solution where we were able to recognize different profiles according to different user interests [17, 18]. Now, we are using this dynamic system to provide statistics to building managers to give better insight into space occupancy. In this research, we will demonstrate the functionality and verify the proposed concept by using the BLE beacon dynamism as a base for analyzing space occupancy. By doing that we will analyze the results and provide space occupancy through localizing user position. Through dynamic message dissemination, we support indoor localization and compare the proposed method with solutions mentioned in the literature and show that the proposed approach is more flexible and offers more possibilities.

In our case, we have test it as an indoor solution for faculty information broadcasting to all faculty users, as well as a real-time space monitoring solution where we examine how users utilize building space through the indoor localization. We conducted the experiment, through which we are going to show the proposed system capabilities and from which we are going to extract all the analytics, in 29 days (from 15th of September until 13th of October 2017). The remainder of this paper is divided into several sections. Section 2 gives the related work and what motivates us to experiment in this area. Section 3 contains the background of beacons technology and how we use it to build the proposed system through the system explanation. Section 4 shows the pilot experiment and all the details regarding the conducted monitoring and system performance. Section 5 explains the space occupancy process, and in Sections 6 and 7 we discuss the optional system possibilities and conclude the paper along with the future work.

2. Related Work

Nowadays, several companies are in a constant development of their beacon type, of which the most popular ones are Google, Apple, and AltBeacon and are competing on a regular basis [19]. However, for our system implementation, we used the Apple version of the beacon which we found most suitable for our work. Several projects motivated our work regarding message dissemination scenarios and indoor localization experiments based on a similar technology. In the same manner, for better understanding, we divide our work into two parts: (i) message dissemination and (ii) indoor user positioning (localization).

2.1. Message Dissemination

The Bluetooth Content Distribution Stations on Public Transport project [20] done by Department of Electrical and Computer Engineering at the University of California, called Bluespot, is an example of such system. The goal of this mentioned system is to provide users an easy way of accessing interest-based information while using public transport (bus). The central part of the Bluespot system is a station placed on a bus vehicle in the public transit system. The station synchronizes data when in Wi-Fi range (central location, for example) and uses Bluetooth Low Energy Beacon technology to distribute all the content to currently boarded users. Even though the Bluespot system represents an order system, where users before accessing their interest data have to place the order and wait for their data, it is an excellent example of an interest-based message dissemination system where authors combine two different technologies (Wi-Fi and BLE beacons).

In [21] researchers made a proposal of interaction system between visitors and collection in museum hall by using BLE iBeacon technology. The system is designed for users to interact with museum items while taking a museum tour and uses a user proximity and retention time. That way a specific user can receive more personalized information regarding the subject in which he is interested. Another example of message dissemination system by using BLE beacon technology is a project done by VTT Technical Research Centre of Finland, Oulu [22]. In this work, researchers are linking physical objects with their semantic description and later broadcasting unique identifiers over BLE beacon technology. This way a specific user, while using a specially made application, is aware of its surrounding without a need for any previous interaction. The most significant motivator of the message dissemination part is a commercial Virtual BLE Beacon Cisco solution. It delivers a high-accuracy location using Cisco Beacon Point hardware and CMX Cloud Beacon Center management [23]. This product represents both BLE and Wi-Fi solution for supporting indoor customer experience and insight. Connected Mobile Experiences (CMX) is a mobility solution that uses location intelligence gathered from the Wi-Fi network to help organizations of all different industries monetize their network by engaging with their customers and optimizing business operations. Using the context-aware information to deliver personalized mobile services. Based on users location and by using the customers smart mobile devices the system can deliver different content. Ranging from informational updated, indoor maps, or any user relevant information this location data also increases the efficiency by understanding new versus repeated customers. However, besides being a powerful all-in-one mobile solution, its high cost is a clear disadvantage. Implementing this solution usually requires many Cisco proprietary devices and its engine, e.g., Cisco 3365 Mobility Services Engine.

2.2. Indoor User Localization

Indoor localization represents any system that gives a precise position of a specific object inside of a closed structure, such as an airport, subway, university, and hospital [24, 25]. It would be relieving if Global Positioning System (GPS) works indoor as it works outdoor, but its performance is questionable [26]. Few improvements have been made, and every research has something specific to offer. In [27] researchers are trying to learn users habits and their mobility pattern in public transport by using probe requests of users mobile device through the collected data in the wireless access point. Researchers also mentioned the possibility of sending pieces of information to passengers but it has not been implemented yet.

Researchers in [28] built a crowdsensing solution based on BLE beacons and Bluetooth bracelets. From this, researchers are trying to analyze user mobility patterns through crowd detection. However, for the solution to function properly, users need to carry Bluetooth bracelets around. Such approach is not a flexible idea since users are more likely to carry their smartphones than bracelets. Furthermore, researchers justify receiving the information or personalized messages through the system by connecting the bracelet to user’s smartphone, which complicates the whole process. In our case, this entire process is done directly by the smartphone, and no additional equipment is necessary whatsoever.

In [29] researchers found a right way to localize users indoor, as well as outdoor, by combining two technologies (RFID and GPS), where they switch between them depending on where the user is positioned. Regarding the indoor localization, they offer a solution where the user, when moving indoor, needs to tap a passive RFID tag to the reader whenever he or she entered a specific room or building area. The provided solution represents a good solution, but it asks for the manual involvement of a user every time he/she changes the location. In this manner, our solution works automatically and detects a specific user every time his location changes while building a user’s movement trajectory in a real-time. We need to note that user location gets more precise with increasing number of devices.

3. System Overview

We separate the system overview into three parts: The first part presents a brief overview of our previous work. The second part is the technical background of a beacon technology. The third part explains how we incorporate that technology into our system.

3.1. Previous Work

In our previous work [17, 18], we explained how to overcome the static content distribution in BLE by implementing a dynamic one. In other words, we proposed to use the iBeacon architecture to disseminate the information dynamically. Both users and their devices are assigned to a specific profile according to their interests. By using the Apple beacon format (iBeacon ID combination: UUID, major, and minor values), we uniquely identified profiles corresponding to different users or groups of users. Thus, this dynamic approach enabled a solution where each beacon device can advertise various topics. Differently said, we offered a customized BLE beacon broadcasting method where the user is first recognized (discovered), and according to that information, the corresponding information is broadcast to the recognized user. Better said, we separated users on different profiles. These profiles are recognized when they enter a beacon advertising area. After this step, an enhanced beacon device sends a corresponding beacon ID to a user device.

3.2. Beacon Technical Background

iBeacon, during the packet advertisement, notifies everyone around that it is present and can be identified by three numerical identifiers, which are Universal Unique Identifier (UUID), major number, and minor number. Combining these three numbers we can identify a specific information, and by advertising this combined identifier, it can trigger a particular action on a device that reads it. While UUID includes a 128-bit identifier that is utilized to uniquely classify one entity, major and minor numbers (16 bits) describe specific identification within some entity (see Table 1). That said, we can build and achieve more detailed granularity in the development process. In other words, UUID can identify one organization, while major and minor numbers identify specific items inside that organization. Additionally, beacon UUID number is not centrally managed and could be generated randomly in many different ways, for instance, online or on Mac operating system by using the command uuidgen. The output looks like this: 158E8ACF-8527-4AE3-B931-0B5A50C550A6.

Table 1: iBeacon format.

iBeacon Data 31B

iBeacon
Prefix
UUID
Major Number
Minor Number
Tx Power

9 Bytes
16 Bytes
2 Bytes
2 Bytes
1 Byte

The interesting part is the application, usually installed on a user’s phone, that reads an identifier and associates it with the action that starts after discovering the beacon. In this manner, an application function on a user phone is the primary product throughout the whole process, whether it is designed to show some information regarding advertised products in a beacon proximity or something else more complicated. Furthermore, BLE technology is a low-power technology and it has many advantages in that aspect over many other techniques in a mobile world [30]. For example, compared to WLAN, the gross bit rate is lower, around 1 Mbps, and the range depends on Bluetooth class (up to 200 m). This range is reduced indoor. It is also “lighter” and embedded in most smart devices [26]. Also, it does not require any infrastructure architecture whatsoever and lately most of the mobile vendors incorporate Bluetooth technology by default; no wonder that these were the main reasons why we chose BLE technology over some other technologies for the inside architecture. The reason for choosing BLE as a primary technology is because of its low-power consumption, comparing to Wi-Fi, for instance [31]. Furthermore, according to [32], users who have their Bluetooth active on the smartphones are on the rise. Previous research from 2015 reported that BLE ’on’ rates were approximately 40%, and in 2017 the rates increased significantly to over 60%. Also, Wi-Fi technology, before any data exchange, requires an established connection between two hosts, which is not convenient in our case. A similar situation is with Wi-Fi direct and classic Bluetooth [33]. However, we have to ask ourselves, what can we do to ensure that users with some specific application have Bluetooth active? A simple solution to this would be geofencing [34]. Such approach would allow the system facilitators to define the geofencing region and to notify the users to keep their Bluetooth active, once they enter or exit the region.

3.3. System Architecture

In this section, we explain the main components of the proposed system. We divide its infrastructure into two main parts, which are front-end infrastructure (Bluetooth Low Energy part) and back-end infrastructure (Wi-Fi part). Front-end infrastructure is responsible for user discovery, advertising, and space occupancy process. Back-end infrastructure connects all the beacon devices through the building Wi-Fi infrastructure to the iBeacon user profile database (see Figure 1). We have to mention that back-end infrastructure can be flexible and not strictly based on a Wi-Fi technology. In our case, we use a Wi-Fi technology which we find more convenient for our experiment. When speaking of possible wireless interference, having many beacon devices in a small sized area is not so convenient, and it makes network wireless congestion and loads even worse [16]. Keeping in mind that majority of the beacons operate in the 2,4 GHz ISM band, for the beacon devices to work accurately, precise positioning of the beacon device and the proper site survey of the building indoor need to be previously done.

Figure 1: System architecture.

Single user, in other words, a user’s device, is discovered when entering the beaconing area. This step does the Input BLE Module (BLE dongle installed on the Raspberry Pi) which continually scans for new MAC addresses over BLE protocol. Let us not forget that the beacon device originally cannot collect BLE signals since it is a one-way broadcasting technology. When the Raspberry device discovers a user, it learns a user’s device MAC address and saves it to the iBeacon database. In this case, we use two technologies in the whole process. First, a user is discovered through BLE protocol and sent to the database by using a Wi-Fi connection (see Figure 1 step 1-3). Later, when iBeacon database saves an input for a specific user, it associates the user with the beacon configuration advertisement (UUID, major, and minor combination) (see Figure 1 steps 4-6). After that, Wi-Fi transfers the configuration advertisement to a beacon device where the user was discovered (see Figure 1 steps 7,8). From that point, beacon device uses BLE protocol again to deliver configuration advertisement to the specific user (see Figure 1 step 9). This step also helps us with the space monitoring process because every beacon device has a static label inserted within its configuration, which uniquely identifies every beacon device in the system. According to that mark, iBeacon database knows in every moment where the user is located and at what time the user received the information. In our case, the label is nothing else than a device custom name that updates iBeacon database every time user gets recognized and gets a specific advert. This label is static and can be changed in the beacon device configuration. We have to mention that the label can only be changed by the device administrator and not by a user since it is configured on the secured beacon device. User’s device, in other words the app installed on a user’s device, reads the configuration advertisement and triggers a particular action. The action could be a simple notification message or something relevant to the user. Furthermore, iBeacon database saves all the user input records and updates them every time the user enters the area. It does this by keeping track of the user’s beacon entrance timestamps (see Figure 2). We have to add that we covered discovered device names and part of their MAC addresses for the sake of the user’s privacy (see Figure 2). Also, in Figure 2, all users belong to Profile ID Visitors, which in our case represents a global profile for all newcomers. According to this, we can apply a specifically predefined taxonomy to all known users where they can be recognized by the system every time they interact. However, in this paper, we do not discuss user taxonomy and how do we apply it. From the technical aspect, the beacon devices transmit periodically generated advertisements every 0,000410 microseconds on a different channel, starting with channel 37, then 38, and finishing with 39. This procedure presents one advertising cycle [35]. After that, the whole cycle starts again, where the delay between the cycles is around 1,2 second.

Figure 2: iBeacon database time stamps.

We have to mention that for the experiment we do not update the beacons but the configuration of the beacons, which is the main point in the proposal. Such mechanism contributes to moving from one configuration window to other configuration windows. Moreover, the proposed mechanism assures that the dissemination messages in a specific configuration window are treated in that window or discarded.

4. Pilot Experiment

To evaluate the performance of the proposed system, we conducted an experiment on the premises of the Faculty of Engineering and Telecommunications of Vigo in Spain. This building represents a complex environment, where we had to take care of the BLE coverage, which reduces if the signal encounters an obstacle (walls, doors, inventory, and so on.). Along the building area, several beacon advertisers were deployed and continuously served users while entering and exiting the building area (Figure 3). Single beacon device was based on a Raspberry Pi hardware device [36]. We choose Raspberry Pi device because it is Linux based [37] and also because other solutions lack customization abilities. Hardware part consists of few components. The main element is a Raspberry Pi 3, and it represents a beacon device, but the iBeacon database as well. Every beacon device has two pieces of Bluetooth CSR 4.0 USB dongles and one Wi-Fi USB dongle installed on its chassis. The reason why we chose to use two BLE dongles is to facilitate the process of discovery and advertising. Beacon device is scanning the beacon area on one BLE dongle while the other has a function of the advertising process. More specifically, the scanning BLE dongle has a customizable scanning time period. In our case we set the scanning time period of 5 seconds, and after that period the scanning period stops and all the user devices that are found in the beacon vicinity are compared against the iBeacon database. Later, the advertising BLE dongle is activated and disseminates a corresponding message to the recognized user devices. Later, after 2 seconds, which is also customizable, a scanning period is repeated. In the period when the scanning BLE dongle is activated, the advertising BLE dongle does no operate. That way, the scanning BLE dongle cannot collect any advertising BLE dongle packets. Such mechanism also helps to filter out the unnecessary network traffic. Wi-Fi dongle connects the beacon to the internal building infrastructure and that way communicates with the iBeacon database. For an iBeacon database, we use Raspberry Pi 3 model B with MySQL ver. 5.5. After positioning all beacon devices and making sure that we conceived a full coverage, we connected them all through the building Wi-Fi infrastructure. Also, every device is easily accessible through the Secure Shell (SSH) protocol, which connects all the devices to the iBeacon database and processes the discovered devices.

Figure 3: Field experiment map.

The following sections present data collection, system performance, and evaluation results. In data collection section we extract and analyze real-time data. System performance shows us how the system behaves during the experimental period and how it collects the data. For the evaluation process, we combine several system inputs and outputs, such as user location, time of user detection, and user location during the operations of discovery and advertisement. From this we get knowledge about user mobility pattern and how does it correlate with space occupancy. Regarding the building locations, we have eight monitoring locations, which are library, Main Hall, EMOffice, CPOffice, B004, AS07, AT213, and AT218 (see Figure 3). Some of these locations, as we already know, present user gathering points, such as Main Hall and library. Other places are used by faculty as classes, workshops, offices, and gathering points. For better understanding, we group these locations into areas, according to their use. From this, we have classrooms area (AT213, AT218), laboratories area (AS07), offices area (CPOffice, EMOffice), and common area (library, Main Hall, B004).

4.1. Data Collection and Basic Statistics

We evaluate the performance of the proposed system by collecting, extracting, and analyzing real-time data. We experimented in a period of 29 days straight, from 15/09/2017 to 13/10/2017, when the building was in its usual working routine process, from 8 AM to 9 PM (teachers working with students, students attending classes and exams and studying in the library). After collecting and extracting all the data from the iBeacon database the total number of inputs in the database was 25,660. This number also tells us that the interactions of all discovered users and the system were the same as the number of database inputs previously mentioned. By interaction, we mean discovery and advertisement process altogether. After we extracted the data from the iBeacon database, we found that the total number of discovered and served users during the experiment period was 121 (see Table 2). Interactions of detected users also present how they used the system during the period experiment. It is important to mention that no influence on users was done, regarding their smart devices and activating the BLE protocol, whatsoever. For the sake of user privacy, we had to change user’s MAC addresses for randomly generated names. This way it is also easier to explain the whole process. Table 2 presents discovered users and their interactions with the system. The interesting thing to notice is that one user (user Kimiko) had more interactions than all the other users in the whole monitoring period (13,654). Reason for such behavior is that this user interacted with the system during nonworking hours (from 9 PM to 8 AM). In that manner, we exclude this user from further analysis, and we analyze him separately in the following section.

Table 2: Discovered users in a period of 29 days.

Users
Interactions

1
Kimiko
13654

2
Leanna
1504

3
Evon
808

4
Chun
733

5
Donn
613

6
Ingeborg
570

7
Suzan
552

8
Stasia
549

9
Margarito
504

10
Tory
410

11
Randell
379

12
Renay
326

13
Maryanna
299

14
Roseanne
267

15
Jaymie
249

16
Delphine
243

17
Palmira
230

18
Fermin
217

19
Petronila
210

20
Elizabeth
187

21
Edwardo
176

22
Adelina
166

23
Nestor
150

24
Flora
149

25
Camelia
127

26
Kay
123

27
Khadijah
114

28
Ethel
105

29
Cheri
102

30
Tammara
100

31
Jarod
97

32
Jamie
95

33
Dwight
83

34
Avery
80

35
Mike
74

36
Les
73

37
Rocky
73

38
Horacio
70

39
Jeramy
62

40
Jason
59

41
Herschel
54

42
Denver
54

43
Seymour
52

44
Doug
51

45
Wesley
51

46
Jan
50

47
Milton
49

48
Teodoro
47

49
Stan
42

50
Myles
41

51
Shirley
36

52
Francisco
33

53
Ali
30

54
Phil
30

55
Rick
28

56
Barry
28

57
Andrea
27

58
Sheldon
26

59
Rusty
25

60
Hal
24

Will
23

61
Malcom
20

62
Dewitt
17

63
Tad
17

64
Terence
15

65
Jeff
13

66
Kim
13

67
Augustine
13

68
Jim
13

69
Leland
12

70
Jerold
12

71
Kirk
11

72
Nell
9

73
Lissa
8

74
Nora
7

75
Catheryn
7

76
Kristel
7

77
Lashay
4

78
Maynard
4

79
Ferdinand
4

80
Sherilyn
4

81
Sherrie
4

82
Kacy
3

83
Thurman
3

84
Marlo
3

85
Candance
3

86
Tressa
3

87
Nikki
3

88
Sabrina
3

89
Felisa
2

90

91
Venice
2

92
Marianna
2

93
Merri
2

94
Lorilee
2

95
Enoch
2

96
Gisela
2

97
Darcey
2

98
Felicitas
2

99
Hai
2

100
Michele
1

101
Olive
1

102
Ian
1

103
Cristie
1

104
Avril
1

105
Nichol
1

106
Marlana
1

107
Maureen
1

108
Royal
1

109
Yolanda
1

110
Marquita
1

111
Brock
1

112
Marvin
1

113
Estelle
1

114
Elanor
1

115
Sheena
1

116
Azalee
1

117
Creola
1

118
Glennis
1

119
Lamar
1

120
Nicol
1

121
Thais
1

Next, we examine the system usage from several points of view and divide it into days and hours. Such report tells us at what specific time the system was involved in a message dissemination process, as well as in a user discovery process. From Figure 4 we see that system had several usage peaks, especially on working days, which presents a typical working routine. Also, we can notice how in three cases (three range of dates) from 18th to 22nd of September, 2nd to 6th of October, and 9th to 13th of October interactions are increasing with the beginning of the week (Monday) and achieving their peak on Wednesday or Thursday. In the third case, we notice that we have 0 interactions on 12th of October (Thursday) since this was a nonworking day. In the fourth case (from 25th to 29th of September) interactions were decreasing, with Monday (25th of September) being the day with the most interactions.

Figure 4: System interactions per day.

Next, we analyzed the hour peak time of a system usage. According to Figure 5, we can tell that the system was mostly used from 9 AM to 1 PM. This peak time shows that the majority of students classes are in the morning hours. It also shows us at what time the building becomes a more crowded place. We see when the day goes down, in the same manner, the system usage slowly drops, until the next working day at around 8 AM. If we go even into a more further examination, we can extract the date/hour ratio and find out on what days, during the experimental period, users interacted mostly with the system on an hourly basis. Therefore, to get a more precise picture, we divided the user/system total interactions into two groups. The first group presents the interactions from 0 to 1000 total interactions (see Figure 6) and the second group gives the interactions from 1000 total interactions to more (Figure 7). We base these interactions on a sum of hourly periods through all monitored days. From the first group (see Figure 6) we know that the busiest hour was around 3 PM, especially on days such as September 19, October 2, and October 5, while from the second group (see Figure 7) the busiest hour was at around 11 AM almost every working day.

Figure 5: System usage per hour.

Figure 6: Date/hour ratio 0 to 1000 interactions.

Figure 7: Date/hour ratio 1000 interactions and more.

4.2. The Case of a Static User

As already mentioned in the previous section, user Kimiko interacted with the system 13,654 times, which is the most significant interaction during the experiment period of 29 days. We can notice that user was active through all 29 days, especially from 22nd of September until 26th of September and then again from 7th of October until 13th of October (see Figure 8). What is interesting to mention is that we noticed how user Kimiko is interacting with the system during night hours, what can be seen clearly from Figure 9. This info tells us that he leaves his device on the premises of the faculty.

Figure 8: User Kimiko interaction with the system.

Figure 9: User Kimiko: 1 hour time period.

Figure 10 shows the total count of user interaction with the system in all days combined per hour. This output tells us that he was continuously involved with the system, which proves our statement that the user was leaving his device (either computer, laptop, or some personal smart device) always active and in scanning mode.

Figure 10: User Kimiko: total count of user activity.

In the end, we see how user never changed his location and was consistently present in one area (see Table 3). This information is extracted from the iBeacon database as well, and it is explained later in the following section.

Table 3: User Kimiko location.

EM_OFFICE
Main Hall
Library
CPOffice
AS07
AT213
AT218
B004
TOTAL

Kimiko

13654

13654

5. Space Occupancy through User Positioning

To get a better insight into a space occupation and indoor activities, we have to go into the investigation that contains several components. First, we analyze a location/date ratio where we get a better knowledge of a daily user interaction per building area. Second, we proceed with location/hour ratio and the dependence of these two variables. Lastly, we combine users and their interactions through building locations and how they correspond to one another.

5.1. Location/Date Ratio

Going deeper into the investigation of how users interact with the system in different building areas, we realized that the common area was the most crowded area in the experimental period (see Figure 11).

Figure 11: Total interactions per area.

Further analysis shows that the users intend to interact with the system mostly at the Main Hall location (see Figure 12).

Figure 12: Total interactions per building area.

From this information, we see nothing unusual since building cafeteria is also part of Main Hall location, so it is not a surprise that this location was the most crowded place in the experimental period. Again, user/system interaction in this case (Main Hall) followed similar pattern of interactions with a slightly increased number of interactions between October 2 and October 6, compared to other days in the experimental period (see Figure 13). Figure 13 also presents the interactions of every location divided by days.

Figure 13: Daily interactions per building area.

5.2. Location/Hour Ratio

Regarding the location/hour ratio (see Figure 14) and how building locations are used in that aspect, we know, for example, that the users tend to occupy the location AT218 between 9 AM and 1 PM and location AT213 between 11 AM and 1 PM. Mentioned area (classrooms area) is a subject of regularly held classes at the faculty, and from user/system interactions we see how this area is being used and in what period. Figure 15 presents the area/hour ratio and how users interacted with the system.

Figure 14: Location/hour ratio.

Figure 15: Area/hour ratio.

5.3. User/Location Ratio

The last thing we analyze is the user/location ratio. The reason for that is to find out the user’s position and their movement through building areas. First, we separate recognized users by their location interaction. From Figure 16 we notice how the system discovered four users in all monitored locations (8 locations). Also, we notice how these four users interacted with the system mostly in the classrooms building area, locations AT213 and AT218 (see Table 4). Furthermore, seven users participated in the system interactions in 7 locations (see Figure 16), and we can see their specific interactions from Table 4 as well. We consider these users active (dynamic) users since they have changed their locations more often through all building areas in comparison to the others which interacted with the system but mostly from one location (see Table 5).

Table 4: Dynamic users example.

(a) 8 Locations

EM_OFFICE
Main Hall
Library
CPOffice
AS07
AT213
AT218
B004
TOTAL

Chun
1
173
52
19
122
178
181
7
733

Ingeborg
7
139
88
10
52
220
12
42
570

Fermin
1
2
12
3
15
4
99
81
217

Petronila
1
62
3
3
13
115
9
4
210

(b) 7 Locations

EM_OFFICE
Main Hall
Library
CPOffice
AS07
AT213
AT218
B004
TOTAL

Leanna

113
186
18
219
9
955
4
1504

Evon
1
4
244

349
14
8
188
808

Randell

120
51
3
12
106
64
23
379

Jarod

21
3
1
5
34
6
27
97

Horacio
11
37

4
1
1
1
15
70

Seymour
1
1
3
2
3

1
42
53

Myles

30
3
1
2
2
2
1
41

Table 5: Static users example.

EM_OFFICE
Main Hall
Library
CPOffice
AS07
AT213
AT218
B004
TOTAL

Margarito
485
1

17

503

Renay
325

1
326

Suzan
552

552

Figure 16: User/location ratio.

6. Discussion

As mentioned before, the system can extract the location of users in a real-time while interacting with them. When the specific user and the system interact, a piece of information is sent from the system to the user. That advert can represent information about user’s interest or some regular broadcast message regarding global notification (in our case, the student receives the info about his exam, changes in the faculty calendar, global faculty news, and so on). To read the sent message, user’s phone needs to have an installed application that recognizes a BLE iBeacon signal that represents a specific information relevant to the user (UUID and major and minor ID). During the message dissemination process, the system also recognizes the location where the user is currently positioned. In other words, the system recognizes when the user changes its location. Also, an important thing to mention is that the user discovery and the advertising process are customizable. In other words, every iBeacon device has its own beacon configuration which works uniquely for that iBeacon device. That said, the device configuration can be adjusted manually to accomplish the discovery and advertising process depending on the situation. For example, in a crowded area, an iBeacon device can be configured to process requests more often (every second or more). We have tested a single iBeacon device to process every two seconds and it behaved satisfying with some information droppings. In this mentioned process 10 user smart devices were simultaneously participating and iBeacon device recognized every user request. However, the iBeacon database failed to recognizes every user request sent from the iBeacon device. We think that such behavior has to do with the iBeacon database’s lack of hardware resources. As a reminder, our iBeacon database is based on Raspberry Pi device with the integrated basic Wi-Fi network card. In this work, a specific user gets identified once every minute, as we find this discovery/advertising time range more suitable for our experiment. This concept of modifying configuration may change over time and in response to changing circumstances. We have to mention that the system can be divided and it is scalable in that sense. Advertising part can function separately from the user indoor localization, but when used together, they constitute a useful tool for advertising data giving a better insight into a specific space usage (space occupancy).

From the technical aspect of view, as already mentioned, in the experiment period, the iBeacon database processed 25,660 interactions with all the devices. If we take a look at the single interaction between one of the beacon devices and a random user device, we notice that the observed device (beacon device) is advertising packets every 0,000410 microseconds on a different channel, starting with channel 37, then 38, and finishing with 39 and that presents one advertising cycle. This advertising cycle is the beacon device behavior once the user is detected and recognized in the iBeacon database. After that, the whole cycle starts again, where the delay between the cycles is around 1,2 second. We collected this data with the Wireshark [38] between single beacon device and one of the user devices. Since we used the Raspberry Pi architecture as a base for our dynamic system, the memory and the CPU usage for a single beacon device were low, at around 150 Megabytes for the memory and 30% for the CPU usage. We have to mention that this information depends on the hardware that is used for the system base architecture.

Optionally, our solution offers a user profile categorization by applying a predefined user interest taxonomy to the system, and thus using fewer devices it advertises different data to users found in beacon proximity. A single beacon device, in our solution, can interact with various user profiles and simultaneously advertise dynamic data to those profiles. That is to say, a single beacon device in our solution can operate in a mode where it associates with different advertisements and in the same moment can advertise multiple information to nearby smart devices. With this approach we also lower network wireless load and network infrastructure complexity by reducing the number of beacon devices needed. However, in our faculty case, we could differentiate the users according to their position and their movements. By doing this, we can automatically separate them to different profiles. Also, this information helps to develop a personalized notification system and reduces the need for predefined user profile categorization. It could also help us to explore the possibility of recognizing potential user profiles. As mentioned before, user profiles represents an optional part of the system, where we can predefine them according to a specific taxonomy. Whenever a predefined user appears in the building broadcasting area, it gets recognized by the system and corresponding information is sent to his smart device. New users, or newcomers, are identified as visitors and are a subject of a potential regular user (e.g., newcomers becoming students, professors, or faculty staff). In our previous work, users have to be predefined according to some taxonomy [17]. In this work, we try to recognize the users according to their position and how this position changes.

Supposing that we already know building locations where users interact and combining them with user interactions, we can assume their user profile. We have to mention that this does not mean that a specific user has to correspond to a particular profile, but it helps to narrow down a user segmentation to profiles. In our case, during almost one month and constant area monitoring, we assume that users presented in Table 4 are potential student or teacher profiles, according to their interactions with the system. All four users (8-location table) interacted mostly in two mentioned locations (AT213, AT218) which is the faculty classrooms area. Another example would be a static user that rarely changes its location. Here, we take the example of 3 users that are regularly seen in EM_Office location (see Table 5). Here we notice that users concentration was almost all of the time in one area. By that, we assume that these users are part of faculty staff, either teacher or administrative staff since we know that such user profile mostly uses this area. However, to be positively sure how specific user could correspond to a different profile, longer and more detailed analysis is needed.

7. Conclusions and Future Work

This paper proposes an innovative solution for advertising information and helping organizations to get a better insight of their space by using Bluetooth Low Energy beacons. Field experiment shows how system behaves in discovering users and advertising information to detected users. It also gives an insight of the space occupancy while users interact with the system. The results provide us a closer look into system performance. The developed system is flexible and can be incorporated easily into already built infrastructure, not ruining its scalability. Furthermore, the experiment helped us to find a pattern in the way of extracting users’ behavior from their movements in a particular environment through system monitoring. Our system offers a less expensive solution than the proprietary one mentioned before [15] which entails flexibility, and it is open source. Additionally, it can be easily configured on small devices such as Raspberry Pi. By discovering users and sending corresponding information, it can improve organizational, operational efficiency, understand user pattern, and send different data to identified users. The only condition for the solution to be functional is that users need active Bluetooth Low Energy (BLE) on their smart device. We have tested a single iBeacon device to process every two seconds, and it behaved satisfyingly with few information droppings. According to that, the User Profile ID database (UPIDDB) failed to recognize every user request sent from the iBeacon device. We think that such behavior has to do with the iBeacon database lack of hardware resources, and for better processing, it demands a dedicated server since in our case the UPIDDB was installed on the same Raspberry device as the iBeacon advertiser. Additionally, a single beacon device was able to recognize 10 user devices in the same time.

We plan to continue our work to improve our advertising system with space indoor monitoring, where extracting data of discovered users from beacon devices can help to be aware of environment behavior. That functionality, in our case, could easily help a faculty management to recognize possible valuable inputs for any further development and to adjust the organization strategy. Furthermore, data collection and analysis derived from extracting the data might provide different pattern recognition as a basis for data predictions and machine learning concept. Also, for the future work, we plan to do an extensive experiment based only on the performance of the system, analyze the output of the generated network traffic, and merge it into already published work where we predicted the impact of the BLE devices in the particular network environment [16]. Having said that, in our system implementation and experiment we have not yet included a detailed analysis of the system performance from the technical aspects, such as the practical throughput, factors that impact/determine data throughput, and application data throughput since this work is a proof of concept. This analysis demands detailed experimenting which includes good site survey, the positioning of the devices, number of the devices included in the experiment, and so on. In fact, we are using [39] as a guidance for future detailed analysis in more complex scenarios. For the future work we are also planning to connect the system with the outer social services such as Instagram and Facebook, in terms of extracting data and correlating user movements with the existing data produced by the proposed system [40].

Data Availability

The datasets generated and analyzed during the current study are available from the corresponding author on reasonable request.

Disclosure

Rebeca P. Díaz Redondo and Ana Fernández Vilas are principal corresponding authors.

Conflicts of Interest

The authors declare that they have no conflicts of interest.

Acknowledgments

This work is funded by the European Regional Development Fund (ERDF) and the Galician Regional Government under agreement for funding the Atlantic Research Center for Information and Communication Technologies (atlanTTic); the Spanish Ministry of Economy and Competitiveness under the National Science Program (TEC2014-54335-C4-3-R and TEC2017-84197-C4-2-R); and the European Commission under the Erasmus Mundus Green-Tech-WB project (Smart and Green technologies for innovative and sustainable societies in Western Balkans, 551984-EM-1-2014-1-ES-ERA MUNDUS-EMA21).

References

R. H. Dodier, G. P. Henze, D. K. Tiller, and X. Guo, “Building occupancy detection through sensor belief networks,” Energy and Buildings, vol. 38, no. 9, pp. 1033–1043, 2006.

A. Zanella, N. Bui, A. P. Castellani, L. Vangelista, and M. Zorzi, “Internet of things for smart cities,” IEEE Internet of Things Journal, vol. 1, no. 1, pp. 22–32, 2014.

H. Kopetz, “Internet of things,” in Real-Time Systems, pp. 307–323, Springer, New York, NY, USA, 2011.

Q.-P. Chi, H.-R. Yan, C. Zhang, Z.-B. Pang, and L. D. Xu, “A reconfigurable smart sensor interface for industrial WSN in IoT environment,” IEEE Transactions on Industrial Informatics, vol. 10, no. 2, pp. 1417–1425, 2014.

N. K. Gupta, “Inside Bluetooth low energy,” Artech house, 2016.

C. Gomez, J. Oller, and J. Paradells, “Overview and evaluation of bluetooth low energy: an emerging low-power wireless technology,” Sensors, vol. 12, no. 9, pp. 11734–11753, 2012.

S. Kamath and J. Lindh, “Measuring bluetooth low energy power consumption,” in Texas instruments application note AN092, Dallas, 2010.

Y. Zhuang, J. Yang, Y. Li, L. Qi, and N. El-Sheimy, “Smartphone-based indoor localization with bluetooth low energy beacons,” Sensors, vol. 16, no. 5, article 596, 2016.

R. Faragher and R. Harle, “Location fingerprinting with bluetooth low energy beacons,” IEEE Journal on Selected Areas in Communications, vol. 33, no. 11, pp. 2418–2428, 2015.

F. Palumbo, P. Barsocchi, S. Chessa, and J. C. Augusto, “A stigmergic approach to indoor localization using Bluetooth Low Energy beacons,” in Proceedings of the 12th IEEE International Conference on Advanced Video and Signal Based Surveillance (AVSS '15), pp. 1–6, Karlsruhe, Germany, August 2015.

S. Kajioka, T. Mori, T. Uchiya, I. Takumi, and H. Matsuo, “Experiment of indoor position presumption based on RSSI of Bluetooth le beacon,” in Proceedings of the IEEE 3rd Global Conference on Consumer Electronics, GCCE 2014, pp. 337–339, Tokyo, Japan, October 2014.

R. ABI, “ibeacon/ble beacon shipments to break 60 million by 2019,” Tech. Rep, 2015, https://www.abiresearch.com/press/ibeaconble-beacon-shipments-to-break-60-million-by/.

Estimote, http://estimote.com/.

Kontakt.io Blog, http://kontakt.io/blog/.

“Cisco Mobility Express - Cisco Mobility Express Solution,” http://www.cisco.com/c/en/us/solutions/enterprise-networks/mobility-express/mobility-solution.html.

M. Borić, A. F. Vilas, and R. P. Redondo, “BLE broadcasting impact in a real network environment,” in Proceedings of the the Second International Conference, pp. 1–6, Cambridge, United Kingdom, March 2017.

M. Boric, A. F. Vilas, and R. P. D. Redondo, “Analysing the Potential of BLE to Support Dynamic Broadcasting Scenarios,” https://arxiv.org/abs/1803.02309.

M. Boric, R. P. Redondo, and A. F. Vilas, “Dynamic Content Distribution over BLE iBeacon Technology: Implementation Challenges,” in Proceedings of the 5th International Conference on Control, Decision and Information Technologies (CoDIT '18), pp. 910–915, Thessaloniki, April 2018.

Google Eddystone vs. Apple iBeacon: Big Clash Between Tiny Bluetooth Beacons, 2017.

J. LeBrun and C. Chuah, “Bluetooth content distribution stations on public transit,” in Proceedings of the the 1st international workshop on Decentralized resource sharing in mobile computing and networking, pp. 63–65, Los Angeles, California, July 2006.

Z. He, B. Cui, W. Zhou, and S. Yokoi, “A proposal of interaction system between visitor and collection in museum hall by ibeacon,” in Proceedings of the 10th International Conference on in Computer Science & Education (ICCSE, '15 ), pp. 427–430, 2015.

J. Takalo-Mattila, J. Kiljander, and J.-P. Soininen, “Advertising semantically described physical items with Bluetooth Low Energy beacons,” in Proceedings of the 2013 2nd Mediterranean Conference on Embedded Computing, MECO 2013, pp. 211–214, Montenegro, June 2013.

Virtual bluetooth low energy (ble) beacon solution, 2017.

J. Yang, Z. Wang, and X. Zhang, “An iBeacon-based indoor positioning systems for hospitals,” International Journal of Smart Home, vol. 9, no. 7, pp. 161–168, 2015.

C. Yang and H.-R. Shao, “WiFi-based indoor positioning,” IEEE Communications Magazine, vol. 53, no. 3, pp. 150–157, 2015.

V. Otsason, A. Varshavsky, A. LaMarca, and E. de Lara, “Accurate GSM indoor localization,” in UbiComp 2005: Ubiquitous Computing, pp. 141–158, Springer, Berlin, Germany, 2005.

N. Baeta, A. Fernandes, and J. Ferreira, “Mining users mobility at public transportation,” Inteligencia Artificial, vol. 20, no. 59, pp. 32–41, 2017.

C. Chang, L. Szu-Chuang, and H. Yennun, “Crowdsensing traces visualization in bluetooth beacon-based sensor network using wearable device,” in Proceedings of the SIGGRAPH ASIA '16 Posters, pp. 1-2, Macau, December 2016.

D. Zhang, F. Xia, Z. Yang, L. Yao, and W. Zhao, “Localization Technologies for Indoor Human Tracking,” in Proceedings of the 5th International Conference on Future Information Technology, pp. 1–6, Busan, Korea (South), May 2010.

A. Carroll and G. Heiser, An analysis of power consumption in a smartphone, 2010.

G. D. Putra, A. R. Pratama, A. Lazovik, and M. Aiello, “Comparison of energy consumption in Wi-Fi and bluetooth communication in a Smart Building,” in Proceedings of the 7th IEEE Annual Computing and Communication Workshop and Conference, CCWC 2017, pp. 1–6, USA, January 2017.

J. Coombs, More straight goods on location: Bluetooth and location permission opt-in rates, June 2017, https://goo.gl/6mzdiW/.

S. Trifunovic, B. Distl, D. Schatzmann, and F. Legendre, “WiFi-Opp: Ad-hoc-less Opportunistic Networking,” in Proceedings of the the 6th ACM workshopon Challenged Networks, pp. 37–42, Las Vegas, Nevada, USA, September 2011.

J. P. Munson and V. K. Gupta, “Location-based notification as a general-purpose service,” in Proceedings of the the 2nd international workshop, pp. 40–44, Atlanta, Georgia, USA, September 2002.

K. Cho, W. Park, M. Hong et al., “Analysis of Latency Performance of Bluetooth Low Energy (BLE) Networks,” Sensors, vol. 15, no. 1, pp. 59–78, 2015.

R. Pi, “Raspberry pi,” Raspberry Pi, vol. 1, p. 1, 2013.

M. Shacklette, “Linux operating system,” in Handbook of Computer Networks: LANs, MANs, WANs, the Internet, and Global, Cellular, and Wireless Networks, vol. 2, pp. 78–90, 1995.

G. Combs et al., Wireshark-network protocol analyzer, vol. 5, 2008.

M. Afaneh, Bluetooth 5 BLE: Achieving maximum throughput and speed, 2017, https://www.novelbits.io/bluetooth-5-speed-maximum-throughput/.

D. R. Domínguez, R. P. Díaz Redondo, A. F. Vilas, and M. B. Khalifa, “Sensing the city with Instagram: Clustering geolocated data for outlier detection,” Expert Systems with Applications, vol. 78, pp. 319–333, 2017.