Novel Guidance CPS Based on the FatBeacon Protocol

Abstract

Throughout this work, the use of a new technology is proposed to give an innovative solution to the problem of indoor and outdoor positioning and a guidance system in areas where there is no coverage of Internet or global positioning systems. This novel solution is based on the Bluetooth protocol called FatBeacon, created by Google, which can be used in places such as subway stations located below ground, outdoor areas where even 2G coverage is unreachable or simply as an alternative to current technologies that may require an additional cost, such as the Internet in some countries. In particular, this work describes a new solution for supporting tourism called Smart Tourism for which an interactive and non-intrusive guidance application based on the FatBeacon protocol is presented. The developed application informs the users about the way to reach their destination without getting lost and can be used to obtain user data tracking anonymously. In this way, the cooperation between the different systems and components of the scheme creates a distributed ecosystem that is independent of an Internet connection. Since no FatBeacon implementations can be found yet, an experimental implementation was developed to test the proposal, and the obtained results are promising.

1. Introduction

In recent years, the world has changed in many ways. Firstly, technology has invaded people’s lives. Secondly, many people have changed their lifestyle habits to a healthier lifestyle. At the same time, in the last decade, tourism has become one of the largest economic activities worldwide. These mixed elements have led to the emergence of a new type of tourism, known as Smart Tourism (or Smart Destination), based on the intensive technology use in the tourist industry. Users connect to each other using their mobile devices (such as smartphones) so that they can look for information about what to do, when and how to do it and share information with other users. This concept is usually linked to Smart Cities, but nevertheless, Smart Tourism does not need a metropolitan environment to be deployed. As previously mentioned, nowadays, people want to live a healthier life, and these changes have been noticed not only in the way of eating, but also in the way of doing activities, moving from the classical sun and beach tourism to a more active and rural tourism. This is the main reason why the worldwide search terms rural tourism have surpassed its rival sun and beach (see Figure 1). At the same time, over the last decade, the use of mobile devices by users has escalated to such an extreme point that today, our lives without a smartphone are unthinkable. Similarly, the number of devices related to intelligent cities based on the Internet of Things (IoT) has increased drastically, surpassing 23.14 million devices today. Indeed, according to [1], in 2025, the number of IoT devices will reach 75.44 million around the world.

In recent years, many Points Of Interest (POIs), like historical monuments, museums, a statues, gardens, etc., have integrated electronic devices like, for example, Bluetooth-based ones, to offer information. Those devices, known as beacons, can be used to emit a web address Uniform Resource Locator (URL) using a Bluetooth Low Energy (BLE) signal.

This work takes advantage of the emergence of BLE technology to propose a solution to the existing problem in tourism, consisting of a lack of information about nearby interesting locations or activities in places with no Internet coverage. Compared to a standard system based on IoT content, this Cyber Physical System (CPS) deals with a more complex system that is dynamically composed from other systems and can be used to learn from the interactions that occur to create intelligent environments. Throughout this work, an application is presented to help tourist get oriented in rural areas (such as trails), although it can also be applied to indoors. This guidance system is based on Bluetooth technology using the new FatBeacon protocol without the need for an Internet connection. For this purpose, an application based on Android systems is presented that makes use of an algorithm that indicates to the user whether he or she is on a correct route within an area. This algorithm does not indicate the best route, but it focuses on ensuring that users do not get lost.

The present work is structured as follows: Section 2 presents the current state of the art comparing our work with previous related works. Section 3 briefly describes the main BLE-related technologies and explains how the FatBeacon protocol works. Section 4 shows a specific case study demonstrating the aim and scope of the work. Section 5 includes the algorithm and application designed for pathways, focusing on a particular case. Section 6 introduces a system that makes use of the FatBeacon protocol for gathering statistical data from users anonymously. Finally, Section 7 closes the paper with some conclusions and open problems.

2. State of the Art

BLE technology (also known as Bluetooth-Smart) is a type of technology created in 2011 by the Bluetooth Special Interest Group (SIG) [3] with the aim of creating innovative applications in the health, fitness, safety and home entertainment industry. Its use has been common in physical devices such as smart watches, bracelets and all types of everyday appliances. The main difference of the BLE protocol compared with the classical Bluetooth protocol is that BLE can be used to emit the same signal, considerably reducing the energy consumed for this purpose. The main advantage of using BLE over other wireless technologies is that it allows broadcasting content such as a web address. In addition, this type of device has low power consumption, which allows it to operate for months or even years without any interruption with a normal battery. Android and iPhone mobile devices with Bluetooth 4.0 or higher can be used to receive the BLE signal, for instance to display the web content pointed by a beacon. The main disadvantage of this technology is that it currently requires an Internet connection. This requirement in many cases is a problem due to the fact that although mobile networks are quite widespread, in many places, they are not available or the connection is so slow that it is practically unusable. BLE technology has gained so much importance that even the largest technology world-renowned companies have opted for it. More specifically, the two biggest companies that have contributed to its development are Google and Apple, proposing their models of Eddystone/AltBeacon/Physical [4] web and iBeacon [5], respectively. Until now, most projects developed by Google with this type of beacon have been based on the location of entities. For example, one of the projects Google proposes on the official Physical Web site is the location and identification of pets. It is also used by many stores to promote their products, offering special prices or discounts on items because advertising in Smart Cities [6] is one of the main objectives in the current use of BLE technology with beacons.

Thanks to the wide research and the protocol improvement, a variety of projects that use BLE can be found. The proposed use of this technology goes from the use of drones for the rescue of people [7] to systems for delivering assistance [8] and even to the management of energy consumption in an office [9]. However, the most usual application of this type of device is indoor location [10,11,12,13,14]. Besides, a project has been proposed to give a solution in underwater environments, providing an underwater location system [15] using beacons. Until now, all aforementioned applications and projects have made use of Bluetooth technology for POIs as a sensor dependent on other technologies, such as an Internet connection, to retrieve the information about the place, as shown in [16,17]. This is not the case of the proposal described in this work.

The current work presents a novel IoT application of the new protocol created by Google in 2016 known as FatBeacon. This protocol can be used to send web content in Hypertext Transfer Markup Language (HTML) format directly from the beacon to users’ smartphones, broadcasting the HTML content. This must not be confused with a web address URL. The broadcast includes the JavaScript (JS), Cascade Style Sheet (CSS), images or other HTML resources without needing an Internet connection. The main difference between the new protocol and the classical ones implemented in Bluetooth is that these can only broadcast in URL format, requiring an Internet connection to acquire the content. Because of that, the aim of this work is focused on giving a new kind of guidance system based on the new FatBeacon protocol as a solution in areas where there is no Internet coverage or where Internet connection is practically inaccessible. The idea is that, without needing a connection to obtain information from the environment, it is possible to deploy FatBeacons along areas or pathways that are highly frequented by tourists where it is possible that, due to poor road signs, there is a risk of getting lost.

Since the FatBeacon protocol is the only one that currently transmits data that are not URL-type, it is virtually impossible to find references regarding usage-oriented applications for information retrieval in POIs that do not require an Internet connection. However, the problem of location has been widely discussed using Bluetooth technologies like classical beacons.

There are several bibliographic references with a goal similar to that of the present work [11,18,19], consisting of the use of beacon BLE to locate people and objects inside buildings. There are also solutions proposed for POIs located outdoors, such as [20], where beacon devices are used in POIs that do require an Internet connection. Our proposal is based on the use of FatBeacons in rural areas or places without Internet access, like trails or underground areas, in order to offer a guidance system where it is difficult to find accurate and detailed information.

3. The FatBeacon Protocol

The new FatBeacon protocol should not be confused with the previous ones, even though they are based on the same BLE technology. The main difference, apart from the advantage of not requiring an Internet connection for content streaming, is that FatBeacon is capable of storing and delivering content with several types of data, different from a URL alone. This allows, apart from the cases presented in this paper, the implementation of more diverse projects, such as the creation of communications networks over large areas, which would facilitate communications in emergency situations.

The signal emitted by a beacon can be of a spherical or omni-directional type. Besides, depending on the used protocol, beacons can emit a different type of content, although in most cases, it is a URL type (web address). In addition to transmitting a URL, beacons simultaneously emit other parameters packaged in the same Bluetooth signal, like the Transmission power (TX power), which usually has a fixed emission value, which determines the approximate emission range of each beacon and directly determines the battery consumption. Thus, the higher the TX level, the greater the strength of the signal and, consequently, the higher the consumption of battery power. The transmitting period or frequency is the time between two successive emissions. This value can also affect battery consumption because the higher the frequency, the higher the battery consumption. For example, a low frequency can be represented with 100 ms (corresponding to 10 emissions in one second), while a high frequency of 500 ms would imply that two emissions per second are made. The life-cycle of a beacon device depends mainly on those two values, TX power and frequency, so that the greater the requirements of the beacon, the sooner the battery will be depleted. On the one hand, beacon devices generally run on lithium batteries such as CR2032 (or button cells) because they have a large capacity for these low-power devices and can last for years. On the other hand, these devices could run on rechargeable energy using solar energy (with solar panels), which not only contributes to the use of renewable and clean energies, but also allows the implementation of unattended beacons in remote locations without the need to replace batteries from time to time. However, as shown in [14], these data can vary with respect to several factors such as emission power, algorithm optimization, antenna orientation, transmission power, beacon density per area, etc. Currently, we can find various types of beacon signals from different manufacturers supported by two different protocols.

• Apple iBeacon: This beacon is supported by one of the most popular protocols, the iBeacon [5] protocol created by Apple. This is an Indoor Positioning System (IPS) that works on iOS 7+ devices and Android systems in Versions 4.3 and higher (with Bluetooth >4.0). This technology allows the emission of push notifications to the mentioned devices whenever they are in a nearby radius. iBeacon devices mainly have four layers of information corresponding to:

  -

  Universally Unique Identifier (UUID): The UUID is the standard identification system that allows a unique number (or code) to be assigned to a device. It would be the equivalent of MAC addresses.

  -

  Major and Minor: Major and Minor are numerical type values that are assigned to iBeacons in order to identify them more accurately than using the UUID field alone. Minor and Major are integers between zero and 65,535.

  -

  Payload: The payload is the load that each beacon emits. In the case of iBeacon, it emits a URL address that is the one that will be used later to download the content of a POI using the Internet.

• Radius Network AltBeacon: This beacon is supported by the AltBeacon protocol created by Radius Networks, a company that tries to imitate the iBeacon protocol, but offering the code for free and increasing the number of bytes available for the user from 25–28 (compared to the 20–27 of iBeacon).
• Google Eddystone: This beacon is supported by the Eddystone protocol created by Google. Unlike the iBeacon protocol, Eddystone is open-source and is prepared for multiple types of data packets like Eddystone-UID, Eddystone-URL and Eddystone-TLM.
• Google FatBeacon: This protocol is supported by the FatBeacon protocol, which is still in an experimental phase, although there can already be found a few implementations [21,22] for various platforms such as Raspberry, Arduino and NodeJS servers. Unlike the protocols mentioned above, FatBeacon can be used to transmit data and have them displayed by a receiver on a mobile device without the need for an Internet connection. The device detection operation is the same as for the other protocols, except that in this case, HTML content stored in the beacon can be broadcast.

This work is based on the use of the FatBeacon protocol, which allows the transmission of a single data stream in atomic form, i.e., so that the output content cannot have different resources. When sending HTML content using the Hypertext Transfer Protocol (HTTP) 1.1 protocol [23] (see Figure 2), the different resources (HTML, CSS, JavaScript, images, etc.) are sent separately according to the protocol specifications and to the fact that it is common to have separate resources, not integrated in a single document.

The FatBeacon protocol transmits under the HTTP 1.1 protocol, so in order to be able to make a streaming transmission, the inclusion of all the necessary resources within the same sending string, containing all the content (images, CSS, etc.) in their respective locations, is necessary (see Figure 3). CSS and JavaScript content have been included within the HTML head tags of <head>... </head>. In the case of other resources such as images, a base change in the format has been chosen, resulting in that rather than transmitting the binary of the image as a resource, a string is emitted in base64 format using <img src=’data: image/format; base64,/9j/23J06S09(...)’/>.

In the following example, a diagram divided into two parts is shown (Figure 4a,b). This image shows the differences in which classical beacons operate normally and how the FatBeacon protocol makes the content broadcast, respectively.

The algorithm shown in Figure 4a corresponds, in [24] the following steps:

• The beacon transmits the information with the URL by a spherical signal. Smartphones in the range receive this signal and read the emitted URL.
• The mobile phone, using an Internet connection, does a query to the Domain Name System (DNS) root server, which has the domain .dot, and then to the .org Top-Level Domain (TLD).
• The TLD asks for information about Wikipedia [25] , which will return an Internet Protocol (IP) address corresponding to the Wikipedia server. Then, the DNS server of the wikipedia.org domain makes the query to the IP for en.wikipedia.org to finally return the IP where the server path or Fully Qualified Domain Name (FQDN) is located.
• The IP is returned to the smartphone. Then, it makes the content request to the server in order to download the content
• The antenna on which the mobile phone was connected to the Internet returns the content to the mobile phone.
• The content is returned and displayed on the smartphone’s screen.

As can be seen, if one of the previous steps fails for some reason, the service will not work properly, and no information will be displayed on the smartphone.

The use of the FatBeacon protocol considerably simplifies the process because there is only one step (see Figure 4b), consisting of FatBeacon broadcasting the HTML content, and this is displayed on the mobile phone.

Below some test results can be seen to compare the efficiency of the FatBeacon protocol with that of others. Similarly, a comparison has been made between times for different connection types, package sizes and distances to determine the degree of correlation between tests and results. Since there is currently no device that implements the FatBeacon protocol natively, we have built it by an empirical data collection methodology. The way to obtain the data for BLE 4 has been by performing tests in a controlled environment using mobile devices such as a transmitter and a receiver. For this purpose, a Samsung Galaxy S7 mobile phone (model SM-G930F) has been used in the experiments as a transmitter and a Xiaomi Mi5s (model 3/64) as a data receiver. Both mobile phones have a Bluetooth version that allows the simulation of this new FatBeacon protocol. To simulate the data, the official Google Physical Web application [26] has been modified, making the necessary changes to carry out the experiments. The changes made to the original application have been as follows:

• Modify the BluetoothSite.java adding the following variables private long start_time = 0; and private long end_time = 0;.
• In the connect function, start_time = System.nanoTime(); was added
• In the close method end_time = System.nanotime(); and double difference = (end_time − start_time)/1e6; were added at the end of the function (with a System.out.println(difference) to check the result.

The files with the transmitted HTML content were stored on the mobile device in order to make the different broadcasts depending on the size (see

Table 1. Download speeds in Mbps for different protocols and sizes. * Based on the BLE5 specifications; ** based on the Generation Partnership Project (3GPP) specifications, without considering the Transmission Control Protocol (TCP) connection delay.

Packet Size	BLE4	BLE5 *	2G **	3G **
10 kB	5.21	1.30	5	0
20 kB	8.82	2.20	11	0
40 kB	7.43	1.85	23	0
100 kB	15.18	3.79	58	2
200 kB	28.14	7.03	107	4

). With these files, having the mobile device connected to a laptop, it is possible to observe the different transmission times and measures from one terminal to another from the terminal. The other bit rates (BLE5 [27], 2G and 3G [28]) were extracted from the specifications of each type of connection, considering if the bit-rate is 1 Mbps = 0.125 MB/s. The resulting download times, taken for each kind of connection and size, are shown in Table 1.

The connection times of BLE4 have been extracted from

Table 2. Transfer times (in seconds) at 1 m.

No. of Test	10 kB	20 kB	40 kB	100 kB	200 kB
1	4.0498	6.1178	4.3513	12.5816	15.8346
2	4.4163	7.5264	7.2030	12.7050	23.4155
3	5.2194	8.8279	7.4392	15.1869	28.1433
4	6.8424	12.0863	8.6729	18.4735	33.7344
5	7.3336	14.4279	10.35.77	74.8106	87.9002
Median	5.5219	8.8279	7.7492	15.1869	28.1433

, obtained in the same way as the previous experiments, maintaining the distances between transmitters and receivers to 1 m. Five measurements were made for each web-page weight. Afterwards, in order to obtain more stable data, the best and worst data for each measurement were discarded, leaving an average of the remaining values as a reference value.

Regarding the results shown in Table 2, the found correlation index (0.9468) between speed and load size is directly related to a strong relationship between those parameters. In order to determine whether the transfer time depends on the distance, another empirical test was performed in the same testing laboratory. This time, a static page size of approximately 40 kB and a variable distance were used. The experiment was carried out for each test in a straight line to avoid obstacles or other factors, such as wind, solar rays or other types of radiation such as WiFi signals, which impede the emission of the signal in the correct way. The results are displayed on

Table 3. Transfer times (in seconds) for 40 kB.

No. of Test	1 m	5 m	10 m	15 m
1 best result	4.351	4.237	6.283	7.769
2	7.203	4.539	6.668	8.001
3	7.439	6.718	7.117	8.075
4	8.673	7.614	8.668	10.235
5 worst result	10.358	10.246	30.187	10.784
Median (discarding the best and the worst result)	7.439	6.718	7.117	8.075

.

In the case shown in Table 3, the computed correlation index (0.6851) corresponding to the distance between the mobile phones and the transfer rate indicates that there is a relationship between them. Note that both the emission frequency and the emission power also depend on a strong correlation between each one of those variables and the emission angle. The work [29] includes an extensive comparison between WiFi and Bluetooth protocols indoors and outdoors, concluding that the RSSI can vary, depending on the emission angle (from 0º to 90º, where 0º is the best result for broadcast content).

4. Use Case

Mobile networks are nowadays almost vital in the daily life of most people. This type of network is deployed by establishing telephone antennas located at strategic points to cover a maximized area. Currently, connection bands are divided into 2G, 3G and 4G, and in the near future, 5G connections are expected to be deployed in some areas. Usually, the range of coverage of data networks is inversely proportional to their speed. For example, the 2G connection has a low speed, compared to the other connections, but it has a wider coverage.

Most users who have an Internet connection on their mobile phones use them to obtain information about places, restaurants, social networks, etc. However, in hiking tourism, most information, such as weather, track status, local flora and fauna and recommendations on activities related to trekking, is not available in many cases.

As an example of the application of the proposal, we now consider the case of a region on La Palma Island (see Figure 5a) in the Spanish region of Santa Cruz de Tenerife, where many outdoor activities are offered for hikers [30] in different varieties of trails approved and enabled for their use. Some of them are even enabled for people with reduced mobility.

Trails on La Palma (see Figure 5b) represent 7.23% of the island surface and are classified as follows:

• Green: These are local trails, of less than 10 km, approved and verified by the issuing authority.
• Yellow: These are short distance trails, with a length between 10 and 50 km, but generally with quite a few slopes.
• Red: These trails are long-haul, over 50 km, so they are designed for several hours or even days.

Figure 6 shows three images representing the different coverages (from 2G to 4G) in separate layers. Although 2G technology has a greater range, it has a worse coverage because there are not as many 2G antennas as 3G or 4G, for example. As shown in Figure 6, there are some areas where there is no coverage at all.

Figure 7 shows an overlap of the trail layer over the 2G + 3G + 4G map.

According to Figure 7, approximately 11.52% of the island has no access to an Internet connection of any type (white areas in the image). Working with this composition and using a technique based on the difference between layers of the image so that if there is a point in the layer A that is present in the layer B, that point is painted with a certain color, as seen in Figure 8, it is possible to graphically visualize which trails have network coverage, and which trails do not have it. In the case shown in Figure 8, we can see the red color indicating the number of trails (0.54% of the image surface) that have no coverage. This means that 85.036% of the trails have network coverage, while 14.937% of the trails do not have any coverage. The FatBeacon protocol is proposed here to solve the problem that hiking tourism faces in this latter case.

5. Offline Trail Positioning System

The improvement of the tourist experience in places where no Internet connection is available is a very important way to increase the interest in those places. The proposal presented in this paper describes an IoT system whose main objective is to improve the quality of rural tourism. As previously mentioned, this kind of tourism has increased greatly during the last few years. For a hiking tourist, to know when he/she is going in the correct way on a trail that could have many different routes or paths is crucial both for his/her safety and to have a good experience on the trail. Traditionally, hiking tourist can find different signals that indicate the trail difficulty level and the different directions, placed in logs and vertical signs (see Figure 9). These types of signs are often deteriorated due to climatic conditions or vandalism (see Figure 10). To solve the orientation problem on this kind of trail where there is no Internet connection, a proposal based on FatBeacons is herein described.

As a starting hypothesis, this paper assumes that rural areas are modeled as a graph where several zones (corresponding to POIs) are represented by vertices connected by edges (corresponding to roads or sidewalks). The main goal of the algorithm presented in this paper is to prevent users from getting lost. The use of a graph-based approach is due to the fact that often, tourists prefer to visit several points near an area and not to go directly from Point A to Point B. Each user has to choose a final destination point when starting the path, i.e., when the previous points are all null. Then, the user can move along the different trails until he/she finds the exit (or destination point). If he/she finds a destination point different from the selected one, the algorithm will indicate that the user is on the wrong path. The main advantage of this algorithm is that it reduces the probability of getting lost by preventing the user from going through wrong points. The developed application has two different parts: a web-view showing the information about the POI associated with the found FatBeacon and a positioning system. Both modules interact with each other and together work as an individual system.

The positioning system is based on the use of JavaScript Object Notation (JSON) information stored in each FatBeacon. This information is transmitted by the FatBeacon, together with the HTML content of the POI information. Then, these data are processed by the developed application to divide all data into two parts: the HTML content that is rendered by the web-view and the JSON data that are used to show useful information about the route to the user. For the correct operation of the system, every FatBeacon stores a list of FatBeacons that should have been previously found or that correspond to destinations that will be found later. These destinations depend on the current FatBeacon and the immediately previous one. The use of the previous FatBeacon is only useful to distinguish whether a tourist is going in a direction or the opposite on trials that could be crossed in both directions. To know the original destination of the tourist, when the application detects the first FatBeacon, the tourist is questioned about which is his/her destination among the possible ones. The response to this question is stored in the application to compare with the next FatBeacons in order to know whether the tourist is on her/his route or not. Every time a FatBeacon is detected, the application automatically checks whether his/her destination is between the possible destinations of the found FatBeacon or not. When the tourist destination is not among the possible ones, a sound message is sent to the application indicating to the user that he/she is on the wrong track. Otherwise, when the tourist destination is among the possible ones, a sound message is sent informing that he/she is on the correct track. An example of the system performance and the databases stored in different FatBeacons can be seen in Figure 11a.

In Figure 11a, different points corresponding to POIs can be seen. These POIs are highlighted with different letters to simplify the example. When the user starts hiking and detects the first FatBeacon, highlighted with the letter A in the image of Figure 11a, the application asks the hiker to select one of the possible destinations for this trail. Then, the application stores the last FatBeacon found, in this case A, and the final destination of the user, in this case H (see Figure 11b). The hiker continues the trail route, discovering different FatBeacons, like B, C and D, and the application informs the hiker about whether he/she is on the right track after discovering each one of the FatBeacons (see Figure 12).

If the user goes on the wrong track and finds for example the FatBeacon in the POI denoted by E, the application alerts the hiker that he/she is following the wrong way. In that case, the application discards this FatBeacon and does not store it in the database. Later, the user again finds the FatBeacon of the POI denoted by D, and the application informs that he/she is on the correct track. Now, the user finds the FatBeacons F and G, and the application informs that he/she is on the right track. Once the hiker finds the FatBeacon of the POI denoted by H, the application informs that he/she has reached his/her destination. This simple example shows the performance of the developed offline trail positioning system, whose decision algorithm can be seen in Algorithm 5.

Algorithm 1: Pseudo-code of the automatic position algorithm.

Boolean isInRightWay (String current, previous, chosenDestination){ if (current == chosenDestination) { inform("You are in your destination"); return true; } else { String[] destinations = extractBBDD(previous); for (destination in destinations) { if (destination == chosenDestination) { inform("Right Way"); return true; } } inform("Wrong Way"); return false; } }

The above fragment of the position algorithm shows how the developed system works to inform users about the trails. Some functions, like extractBBDD(String previous), are used to process the information received from the FatBeacon and to extract the useful data. Besides, the function inform(String message) sends the user a notification and a voice message through the application. Some screenshots of the developed application can be seen in Figure 13.

6. Alternative Tracking System

A common use of many systems integrated with beacons is for indoor location and user tracking [31]. Although those systems do not offer an exact location, they are widely used to indicate whether a user has been close to the area where the beacon is or not. By having direct connectivity to the Internet, these systems are able to record the time and approximate location of each user in real time. In this section, an alternative system is described to provide a solution for the case of areas without coverage, which takes advantage of the FatBeacon protocol implemented in systems where the emitted information can be altered (such as Raspberries). Using FatBeacon devices, the system can be used to indirectly send data to users, through a secure and anonymous communication protocol. In this way, the information shared by the users can be used to provide anonymous statistical data that allow creating users’ tracking maps, among other possibilities. The main advantage, apart from the generation of statistical data, is that passive monitoring of the different users in the area without coverage is possible.

To illustrate the idea, we use a basic example (see Figure 14) of a path that is very popular with tourists. The image shows the same scenario in three different stages ($t_0$, $t_1$ and $t_2$) with n POIs or beacons ($p_0$, $p_1$, ⋯, $p_n$). The section between $p_1$ and $p_{n-1}$ has no Internet coverage, so an Internet connection only exists in the $p_0$ and $p_n$ nodes. In the image, two different users $u_1$ and $u_2$ are distinguished. Before starting the trail, the user $u_1$ generates a random identifier for the application. The right side of the image shows how the information is stored and exchanged by both users. In the image we see that:

• At $t_0$, the user $u_1$ starts the tour and moves through the area without coverage throughout time. During the trip, the application that $u_1$ has on his/her mobile phone sends information and has a conversation with FatBeacons sharing the current tracking. At the same time, each FatBeacon stores user information anonymously (including the ID) generated by $u_1$ and the time that has passed. The beacon also stores the points previously visited by $u_1$.
• At $t_1$, the user $u_1$ comes across the user $u_2$, which has been near $p_1$ for a few hours. During these hours, the user $u_2$ sends to the same beacon the updated tracking information (adding the new registration hours). While $u_2$ continues doing various activities at that spot, $u_1$ continues on his/her way, but before that, the information that both have generated and that is stored in the beacon $p_1$ is shared by both. Now, $u_1$ has his/her own information and the information updated by $u_2$ until that time. Likewise, $u_2$ will have his/her own information and data generated from $u_1$. This exchange of information is automatic, such that it is not necessary to have previous contact or permission from the other user.
• At $t_2$, the user $u_1$ reaches the end of the trail where she/he has an Internet connection. Automatically, the $u_1$ tracking data from the beginning of the trail to the end are sent to an information server. Similarly, $u_2$ data from the beginning until he/she came across $u_1$ is also sent.

In an extended example, we consider a map of the real path (see Figure 15) shown in Figure 11. A starting point for user Alice ($u_1$) and a different starting point for Bob ($u_2$) have been set over the map. The areas marked with the red squares are areas where there is no Internet connection or network coverage. Besides, there are four FatBeacons along the trail. Alice follows the route through $P_1$, $P_2$ and $P_3$ beacons, while Bob follows the route $P_0$, $P_2$ and $P_3$. As in the previous example, in the middle of the trail, Alice comes across Bob. Then, they automatically exchange their information at that moment. While Bob waits at $P_2$, Alice goes to $P_3$ with the information obtained from FatBeacons along the trail. The stored information uses a JSON format to take advantage of the ease of use and computation with mobile devices and FatBeacons simulated by IoT devices like Raspberries or Arduinos. As users go through the different $P_x$, the beacon corresponding to that position changes its emission with the new updated information.

The information stored by each beacon is as follows for each user:

• Unique User Identifier (UUID)
• Previous route (to simplify the data in the table, they have been inserted in the format [X, Y], where X is the time (row) and Y represents the user (A or B)
• Current time $t_x$.

Additionally, the table contains some “$+P{X}_{t=Y}$” cases. This, like the second bullet point in the previous list, represents that the information shown in the cell is added to the information point X in $t=Y$.

All the exchanged information can be found in

Table 4. Exchanged information.

Time (t)	User ${\mathit{u}}_1$	User ${\mathit{u}}_2$	P0	P1	P2	P3	Server
0	-	User 2 = $u_2$← randomUid	-	-	-	-	-
1	-	$u_2$ { { P0, { $t_1$ }} }	{ $u_2$, {Ø}, {{ $t_1$ }} }	-		-	-
2	User 1 = $u_1$← randomUid	$u_2$ { { P0, { $t_1$ }} { P2, { $t_2$ }} }	{ $u_2$, {Ø} {{ $t_1$ }} }	-	{ $u_2$, { [1, $u_2$], $t_2$ } }	-	-
3	$u_1$ { { P1, { $t_3$ }} }	$u_2$ { { P0, { $t_1$ }} { P2, { $t_2$, $t_3$ }} }	{ $u_2$, {Ø} {{ $t_1$ }} }	{ $u_1$, {Ø} {{ $t_3$ }} }	{ $u_2$, { [2, $u_2$ ], $t_3$ } }	-	-
4	$u_1$ { { P1, { $t_3$ }}, { P2, { $t_4$ }} } + $P{2}_{t=4}$	$u_2$ { { P0, { $t_1$ }}, { P2, { $t_2$, $t_3$, $t_4$ }} } + $P{2}_{t=4}$	{ $u_2$, {Ø} {{ $t_1$ }} }	{ $u_1$, {Ø} {{ $t_3$ }} }	{ $u_2$, { [3, $u_2$ ], $t_4$ } } { $u_1$, { [3, $u_1$], $t_4$ }, }	-	-
5	$u_1$ { { P1, { $t_3$ }}, { P2, { $t_4$ }}, { P3, { $t_5$ }} } + $P{2}_{t=4}$	$u_2$ { { P0, { $t_1$ }}, { P2, { $t_2$, $t_3$, $t_4$, $t_5$ }} } + $P{2}_{t=4}$	{ $u_2$, {Ø} {{ $t_1$ }} }	{ $u_1$, {Ø} {{ $t_3$ }} }	{ $u_2$, { [4, $u_2$], $t_5$ } } { $u_1$, { [3, $u_2$], $t_4$ } }	{ $u_1$, { [ 4, $u_1$ ], $t_5$ } }	$u_1$ { { P1, { $t_3$ }}, { P2, { $t_4$ }}, { P3, { $t_5$ }} } + $P{2}_{t=4}$
6	User 1 = Ø	$u_2$ { { P0, { $t_1$ }}, { P2, { $t_2$, $t_3$, $t_4$, $t_5$ }} { P3, { $t_6$ }} }	{ $u_2$, {Ø} {{ $t_1$ }} }	{$u_1$, {Ø} {{ $t_3$ }} }	{ $u_2$, { [4, $u_2$], $t_5$ } } { $u_1$, { [3, $u_2$], $t_4$ } }	{ $u_1$, { [4, $u_1$], $t_5$ } } { $u_2$, { [5, $u_2$], $t_6$ } }	$u_1$ { { P1, { $t_3$ }}, { P2, { $t_4$ }}, { P3, { $t_5$ }} } $u_2$ { { P0, { $t_1$ }}, { P2, { $t_2$, $t_3$, $t_4$ } + {$t_5$}} { P3, {$t_6$}} }
7	-	User 2 = Ø	{ $u_2$, {Ø} {{ $t_1$ }} }	{ $u_1$, {Ø} {{ $t_3$ }} }	{ $u_2$, { [4, $u_2$], $t_5$ } } { $u_1$, { [3, $u_2$], $t_4$ } }	{ $u_1$, { [4, $u_1$], $t_5$ } } { $u_2$, { [5, $u_2$], $t_6$ } }	$u_1$ { { P1, { $t_3$ }}, { P2, { $t_4$ }}, { P3, { $t_5$ }} } $u_2$ { { P0, { $t_1$ }}, { P2, { $t_2$, $t_3$, $t_4$ } + {$t_5$}} { P3, {$t_6$}} }

. At the end of the process, the server has obtained all the data so that despite B being in an area without Internet coverage, thanks to the data collected by A, User B can be tracked passively.

7. Conclusions

In this paper, a novel solution has been defined for the location and guidance problem in environments where there is no Internet connection. The FatBeacon protocol created by Google, which allows the transmission of HTML content without the need for an Internet connection, is the main tool used for the development. The proposal can be used to provide hiking tourists with the necessary information to offer a guidance system that prevents them from getting lost along their tracks. Besides, a study has been made of the experimental technology used and other well-known BLE protocols, such as Eddystone, iBeacon or AltBeacon. In addition, some empirical data related to the efficiency of the new FatBeacon protocol have been obtained for different factors, such as distances, web page sizes, etc., and those data have been applied to compare the used protocol with other BLE protocols such as BLE5. Finally, a specific use case of a real scenario of application has been presented to analyze different parameters. The main conclusions of the experiments presented in this paper are the advantages of the new protocol compared to its predecessors, in terms of versatility, low consumption and low cost of deployment. As part of future work, we would like to do the implementation of the proposal in real devices, because the FatBeacon protocol is still in an experimental phase.