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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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).
Further analysis shows that the users intend to interact with the system mostly at the Main Hall location (see Figure 12).
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.
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.
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).
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).