## 3 The FatBeacon Protocol
* 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:  
1. The beacon transmits the information with the URL by a spherical signal. Smartphones in the range receive this signal and read the emitted URL. 2. 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). 3. 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  
Figure 3: HTTP 1.1 using one message. Figure 2: HTTP 1.1 protocol. 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. 4. The IP is returned to the smartphone. Then, it makes the content request to the server in order to download the content
5. The antenna on which the mobile phone was connected to the Internet returns the content to the mobile phone. 6. 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 3(b)), 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.