Patent Description:
The present disclosure relates to a monitoring system for determining the location of Bluetooth beacons using the relative positioning of one or more transceivers and the strength of received signal from said beacons at one or more said transceivers.

Document <CIT> discloses a system for tracking and monitoring activities of individual in e.g. hospitals, has a gateway for receiving wearable advertising device identifier, and forwarding the advertising device identifier using a wireless fidelity module to a remote server.

Document <CIT> describes a real-time location system (RTLS) which uses Bluetooth Low Energy (BLE) transmitting tags, bridges, and beacons. The fixed beacons broadcast BLE advertisements containing motion-status information about recent history of perceived motion in a room as determined from a motion sensor in the beacon. The bridges forward the beacon's received advertisements to a location engine, which records timestamps of motion events seen by each beacon in each room. The system utilizes a series of location-engine steps, to estimate the room-location of the tags based on a specific combination of RSSI analysis, and a comparison of tag-motion history to the perceived and recorded motion-status in a room as an alternative to room-level location of a tag than can be estimated by simple proximity or multi-lateration using radio signal strengths.

The disclosure includes a monitoring system for determining the location of Bluetooth beacons comprising a plurality of battery-powered Bluetooth beacons each arranged to wirelessly transmit periodically Bluetooth beacon messages, a plurality of battery-powered repeaters each arranged to receive and retransmit Bluetooth beacon messages as repeater messages, one or more line-powered gateways each arranged to wirelessly receive and retransmit said Bluetooth beacon or repeater messages as gateway messages, and a server arranged to receive said gateway messages to determine the location of said beacons.

It is disclosed a monitoring system for determining the location of Bluetooth beacons comprising:.

In an embodiment, each beacon is arranged to transmit a beacon message and subsequently enter a low-power state for a predetermined sleep period of time until the next transmission of a beacon message.

Monitoring system according to any of the previous claims wherein each beacon is arranged to not receive confirmation that the beacon message was received by a gateway and is also arranged to not detect if there was another beacon transmitting at the same time the beacon message was being transmitted.

In an embodiment, each of the plurality of repeaters is arranged to:.

In an embodiment, each of the plurality of repeaters is arranged to:
during the transmit state, transmit a predetermined number of wirelessly Bluetooth beacon messages, for each of the received beacon messages, comprising the beacon ID and the received signal strength of the received beacon message and also comprising the repeater identification, repeater ID, of the transmitting repeater.

In an embodiment, each of the plurality of repeaters is arranged to transmit said predetermined number of wirelessly Bluetooth beacon messages, for each of the received beacon messages, interpolated between different Bluetooth beacons.

In an embodiment, each of the one or more gateways is arranged to:
transmit a summary gateway message comprising the beacon ID, the received signal strength, and the repeater ID if applicable, of all the received beacon messages which have been received for a predetermined periodical duration of time, and also comprising the gateway identification, gateway ID, of the transmitting gateway.

In an embodiment, the transmitted Bluetooth beacon messages by the Bluetooth beacons and by the repeaters have the same packet structure.

In an embodiment, the transmitted Bluetooth beacon messages by the Bluetooth beacons and by the repeaters have the same packet structure such that each of the one or more gateways is arranged to receive and transmit said beacon messages from beacons and repeaters, independently of whether the beacon messages originate from beacons or from repeaters.

In an embodiment, said Bluetooth beacon messages transmitted by the Bluetooth beacons are Bluetooth Low Energy, BLE, Advertisements packets.

In an embodiment, said Bluetooth beacon messages received and transmitted by the repeater beacons are Bluetooth Low Energy, BLE, Advertisements packets.

In an embodiment, said Bluetooth beacon messages received by the one or more gateways are Bluetooth Low Energy, BLE, Advertisements packets.

In an embodiment, said Bluetooth beacon messages are connectionless communication packets.

In an embodiment, the server is further arranged to determine the location of a Bluetooth beacon, for the beacon ID of the Bluetooth beacon which location is to be determined, by:.

In an embodiment, the server is further arranged to determine the location of a Bluetooth beacon by using one received Bluetooth beacon message with the beacon ID of the Bluetooth beacon which location is to be determined and having the highest received signal strength for a predetermined periodical duration of time.

In an embodiment, the server is further arranged to determine the location of a Bluetooth beacon by:.

In an embodiment, the repeaters are arranged to operate for a predetermined operation period of time and to enter a low-power state for a predetermined sleep period of time until the next operation period.

In an embodiment, all the beacons are arranged to use a lower transmission power than any of the repeaters.

In an alternative embodiment, all the beacons and all the repeaters are arranged to use the same transmission power.

In an embodiment, wherein the server is further arranged to determine the location of a beacon by calculating an intermediate location from two determined locations of said beacon or by trilateration of two or more determined locations of said beacon using the received signal strength for each determined location.

In an embodiment, the beacon messages further comprise a beacon-measured temperature and/or beacon battery status.

In an embodiment, the beacon messages transmitted by a repeater further comprise a repeater-measured temperature and/or repeater battery status.

In an embodiment, all the gateways and all the repeaters are arranged to use the same reception sensitivity.

In an embodiment, the received signal strength is the received signal strength indicator, RSSI.

In an embodiment, the gateways are line-powered by a main connection or a power-over-ethernet, PoE, connection.

It is also disclosed a method for implementing a monitoring system for determining the location of Bluetooth beacons, the method comprising the steps of:.

It is also disclosed a non-transitory storage media comprising computer program instructions for implementing a monitoring system for determining the location of Bluetooth beacons, the computer program instructions including instructions which, when executed by a processor, cause the processor to carry out the method of any of the disclosed embodiments.

The following figures provide preferred embodiments for illustrating the disclosure and should not be seen as limiting the scope of invention.

<FIG> shows a schematic representation of the general architecture of a beacon monitoring system. Starting from the left, beacons <NUM> periodically send messages to the air (wireless broadcast). These messages include the beacon's identity and may also include other information, such as: remaining battery, temperature, acceleration, etc. This communication is typically performed with a low-power and shorter-range communication standard, such as Bluetooth Low Energy. When these beacons are in the vicinity of a gateway <NUM>, their messages are received by the gateway. During the message reception, the gateway calculates the received signal strength indicator (RSSI) of the message. The gateways process these messages and send the relevant information to a central server <NUM>, through a Local Area Network (LAN) or the Internet <NUM>, using either a wired or wireless communication. This communication is normally performed with a more power-hungry and longer-range communication standard, such as Wi-Fi or Ethernet. Applications <NUM> may then use this data to give users information about the beacons.

Beacons spend most of their time "sleeping", they only "wake up" to send periodic messages to the air (broadcast). The period of these messages is normally predefined, and they do not know if other beacons are transmitting, or if the message is actually received. Messages are sent without prior establishment of connection. This "simplistic" behaviour enables them to operate several years with a small battery, enabling their application to asset/people tracking and mobile asset/people monitoring.

Since gateways need to continuously "hear" the messages from the beacons and send the relevant information over a more power-hungry communication standard, they are operated plugged to a power source, e.g. wall power socket or Power over Ethernet (PoE). This need for power connection usually limits the possible locations for the gateways and increases installation costs.

<FIG> shows a schematic representation of the architecture of the same beacon monitoring system when one of the gateways <NUM> is replaced by a battery-powered repeater <NUM>. Again, beacons <NUM> periodically broadcast messages. However, these messages may be received both by gateways and/or repeaters. When they are received by gateways, the relevant information is transmitted to the central server <NUM>, serving different applications (as described in <FIG>). When beacons' messages are received by a repeater, the repeater extracts the relevant information from the beacon, along with the signal strength of the received signal (RSSI), and "repeats" this information with the same protocol beacons use to send their messages. This way, gateways can receive messages from repeaters, using the same interface they use to receive messages from beacons.

Some possible applications of the repeater are described in <FIG> and <FIG>. In every example there is a floorplan representing four rooms and a corridor.

<FIG> depicts a scenario where the repeater can be used to increase the monitoring system's coverage. The figure shows three beacons being monitored <NUM>, <NUM>, <NUM>. All beacons are transmitting with the same transmission power. Initially, only a gateway <NUM> is installed. The approximate gateway coverage area is represented with a circle around it <NUM>. The coverage area represents the area where the gateway is able to receive beacon messages, based on the transmission power of the beacons and on the receive sensitivity of the gateway. With the initial coverage area, the system will only receive messages from beacon <NUM>.

To increase the total coverage area of the system, a repeater <NUM> is then added in a position where it is both able to receive messages from the remaining beacons (<NUM>, <NUM>) and send the repeated information to the gateway, using the same transmission power as the beacons. Since the transmission power of the repeater is equal to the transmission power of the beacons, the coverage area of the gateway is the same for both beacons and repeaters <NUM>, <NUM>. Considering that the gateway and the repeater have equal receive sensitivity, the coverage area of the repeater <NUM> for beacons is approximately the same size as the coverage area of the gateway <NUM>.

One of the interesting applications of beacon monitoring systems is the location estimation of assets and people (where the beacons are attached). By knowing the positions of the infrastructure elements (gateways and repeaters), location estimation is performed using the received signal strength indicator (RSSI) of the beacon's communications to the different gateways and repeaters. In general, the higher the RSSI of a communication, the closer the beacon is to the receiver. This applies best when there is direct line-of-sight (LOS) between beacon and receiver. Obstacles and reflections tend to deteriorate the correlation between RSSI and distance, making it harder to correctly estimate the distance between beacon and receiver. With the different RSSI values, the location of the beacon may be selected to be the same as the closest gateway/reader, or more complex algorithms can be applied (e.g. trilateration).

<FIG> depicts a scenario where the repeater can be used to increase the accuracy of the location estimation of a beacon. The target of the represented system is to assess the room location <NUM>, <NUM>, <NUM> of each beacon (e.g. beacons attached to assets for asset tracking). Initially, the system is already able to receive communications from all beacons <NUM>, <NUM>, <NUM> using two gateways <NUM>, <NUM>. Beacon <NUM> is only "heard" by gateway <NUM>. Moreover, since the beacon is close to the gateway, the received signal strength will probably be high, and the system would (correctly) assume with a high probability that beacon <NUM> is inside room <NUM>.

Due to installation limitations (e.g. no power source available), gateway <NUM> is placed on the corridor, covering both rooms <NUM> and <NUM>. Beacons <NUM> and <NUM> are "heard" by gateway <NUM>. The system will know that there is a high probability that these beacons are inside rooms <NUM> or <NUM> but will not be able to assess in which of them they are. A possible solution is to add battery-powered repeaters (<NUM>, <NUM>), one in each room. This way, repeater <NUM> will receive communications from beacon <NUM> with a high RSSI and will communicate this to gateway <NUM>. Using the combined information of the packets received directly from beacon <NUM>, and the beacon "repeated" packets received from <NUM>, the system will be able to correctly assess that beacon <NUM> is inside room <NUM>. The same principle applies to make the assessment that beacon <NUM> is inside room <NUM>.

Adding more gateways and repeaters with a high coverage zone will sometimes not solve the uncertainty of the beacons' location.

<FIG> shows a modification to the previous example. In this example, due to the high coverage zone of repeaters <NUM> and gateways <NUM>, beacons <NUM>, <NUM>, <NUM> will be "heard" by more than one repeater/gateway, making it hard to assess the correct room location. This is even more difficult, if obstacles and reflections are taken into account. One possible solution is to use the previously added repeaters together with a reduced transmission power on the beacons, while maintaining the high transmission power on the repeaters. This way, the system gateways will have two different sizes for the coverage zones: one larger area for the repeater coverage by the gateways <NUM>, and one smaller area for the beacon coverage by repeaters and gateways <NUM>, <NUM>. With this solution, the system will easily assess the correct location of the different beacons. This application brings another advantage: reducing the transmission power on the beacons will also lead to an increase in their battery lifetime.

<FIG> shows an example of the most relevant contents of the packets sent from a beacon (<NUM>) to a repeater and the packets sent from a repeater <NUM> to a gateway. As previously mentioned, packets form beacons and repeaters are similar, so that the gateway is able to receive packets from both of them with the same interface. Both packets contain the transmitter's address / ID <NUM>, <NUM>, the packet type, beacon or repeater, that identifies whether the packet is sent from a beacon or from a repeater, and a payload. The payload of the beacon includes its battery <NUM> and temperature <NUM>. The payload of the repeater includes its own battery <NUM> and temperature <NUM> and the information from the beacon it is repeating <NUM>, <NUM>, <NUM>, <NUM>. Besides the battery and temperature of the beacon <NUM>, <NUM>, the repeater also sends the beacon's ID <NUM> and the calculated RSSI of the received beacon packet <NUM>. This is important for the asset/people location applications explained before.

Repeaters only use the shorter-range low-power communication standard, both to receive the communications from the beacons and to send their information to the gateways. Nevertheless, this is not enough to enable battery-powered operation during long periods of time (at least <NUM> year). Even if a repeater is receiving messages from a single beacon and simply repeating these messages, its energy will quickly drain out. This happens because the repeater does not go to sleep between transmissions, like the beacon does. Although transmission may require more power than reception, the total energy spent during reception is typically much higher than the total energy spent in transmission. As an example, with a battery of <NUM> Ah capacity, and considering a low Bluetooth receive (RX) average current consumption of <NUM> mA, the repeater would last less than <NUM> months (without considering the transmissions). On the other hand, a beacon sending a packet every second is typically able to last several years (more than <NUM>), using a battery of <NUM> Ah. Its average power consumption benefits from the sleeping periods between transmissions.

In situations where the characteristics of the system are not fast-changing, or where some degree of information delay is acceptable, it may be enough to perform time-sampling on the monitoring of the beacons. This applies to some temperature monitoring systems, asset/people location, etc. As an example, in an asset location system where assets spend most of their time stopped (e.g. <NUM> hour periods) and only make movements to change position during short periods (e.g. <NUM> minute movements), it is acceptable to only have information from time to time (e.g. from <NUM> to <NUM> minutes). In these scenarios, repeaters may operate only in some intervals (e.g. for <NUM> seconds), "sleeping" during the remaining time.

<FIG> shows the ideal flow of communication between beacons, repeater and gateway. This example considers that the beacons are only being "heard" by the repeater (they are not in the coverage zone of the gateway). Beacons <NUM>, <NUM>, <NUM>, <NUM> periodically send their messages. When the repeater <NUM> is "sleeping", messages are not received by the repeater, and so the gateway <NUM> does not get any information from the beacons. When the repeater is operating, it receives the beacons' messages and repeats them. Repeater is in the coverage zone of the gateway, so these repeated messages are received by the gateway. This information is then sent to the central server, enabling the desired asset/people monitoring.

The communication flow is in fact more complex. Even though beacons are in the coverage zone of a repeater, there are several factors that may interfere with the communication between beacons and repeater. As already stated, beacons typically do not implement any kind of medium access control, i.e., they simply transmit their packets, even if other communications are being performed on the same frequency at the same time. This may lead to interference, and this problem tends to grow with the number of beacons present in the system, but also with other devices operating in close frequency bands. As an example, Bluetooth Low Energy beacons operate on the license-free <NUM> band, which is very crowded (Bluetooth, Wi-Fi, ZigBee,. ), leading to potential interference problems.

Nevertheless, this is not the only factor that may interfere with the quality of the communication. The characteristics of the protocol may also influence the success of the communications. As an example, to reduce the probability of frequency interference, Bluetooth Low Energy implements frequency hopping in its protocol, using a total of <NUM> channels (frequencies). Regarding the beacons, they send a specific type of packet, part of a group of packets known as advertising packets. If these packets were sent over all channels, it would be very difficult to ensure transmitter and receiver were tuned to the same frequency at the same time. However, if these messages were sent over a single "noisy" channel, there would be too much interference. To mitigate these problems, advertising packets are sent over three designated channels. Receivers cycle over these three designated channels to try to "hear" these advertising packets. Once again, receivers could stay tuned in one particular channel, instead of cycling through the three channels, but if this channel has some constant interference problem (e.g. Wi-Fi systems), the efficiency of the system would drastically reduce. Even though beacons sent their advertising messages on the three channels each time they broadcast, there is some probability that the receiver is not tuned to the correct channel at the exact time (e.g. switching between channels).

All these problems have a higher impact when repeater's switching between receiving and transmitting is considered. <FIG> depicts a scenario similar to the one depicted in <FIG>, but with detailed repeater's receiving <NUM> and transmitting <NUM> processes, together with some probability of interference or other problems that affect communications. Each time the repeater is able to receive a packet from a beacon <NUM>, <NUM>, <NUM>, <NUM>, it switches to transmitting mode, working as a beacon itself. Since the physical medium for communication is the same for transmitting and receiving, when the repeater is transmitting, it will not receive any communication from the beacons. Moreover, the packets that are being transmitted by the reader will also contribute to increase the total interference probability of the system. In this example, during the period the repeater was operating (not "sleeping"), the gateway was not able to receive any information for beacon <NUM>. The gateway may only receive information from beacon <NUM> on the next time repeater returns to operating mode, reducing the sampling rate of the system.

A possible solution is explained in <FIG>. In this case, repeater <NUM> operates with separate periods for receiving <NUM> and transmitting <NUM>. This way, packets sent by beacons <NUM>, <NUM>, <NUM>, <NUM> are not lost due to the repeater's switching between receiving and transmitting. This increases the probability of repeater "hearing" all the beacons in the surroundings. During the transmitting period, repeater broadcasts (as a beacon) the information from the different beacons that were "heard" during the receiving period. To reduce the "awaken" time and simultaneously increase the probability of successful information transmission, the repeater may broadcast multiple equal packets for each beacon with a shorter period than the period beacons are broadcasting (e.g. beacons may be broadcasting once per second, and repeater may broadcast with a period of <NUM>). This may be done sequentially (e.g. three packets repeating beacon <NUM>, then three packets repeating beacon <NUM>, etc.) or interleaved, as shown in the figure (e.g. one packet repeating <NUM>, one packet repeating <NUM>, etc., and repeat the whole process three times). The proposed interleaved method is particularly interesting in a very crowded frequency band, such as the <NUM> band. Communications from other devices may interfere with the packets sent by the repeater. In case these are burst communications, interference will occur during certain time windows. If all packets of the same beacon are sent consecutively, there is a higher probability a burst communication from other devices prevent gateways from receiving information from one or more of the beacons.

During the receiving period, the repeater may receive several packets from a beacon. These packets may have different RSSI, different temperature value, etc. During the transmitting period, repeater will transmit multiple equal packets for that beacon, so one single value should be reported. This is solved by applying a function to the received values, such as the maximum value, average, median, or other function that serves the application (this also solves the issue of possibly having more received packets than the number of packets that are going to be transmitted for a defined beacon).

To optimize even further the probability of success of the "awaken" time, packets sent from the repeater may contain information from multiple beacons. <FIG> shows the packets that are sent from the repeater, containing information from more than one beacon. The two top packets represent the packets sent from two beacons <NUM>, <NUM>. The payload of the repeater's packet includes its own information: repeater's battery <NUM> and temperature <NUM>, followed by the information of the different beacons: ID <NUM>,<NUM>, RSSI <NUM>, <NUM>, Battery <NUM>, <NUM> and temperature <NUM>, <NUM>. Although only two beacons are represented, this may be applied for multiple beacons. The limitation of the number will come from the maximum size of the packet, depending on the protocol being used.

One of the challenges of gateways working simultaneously with repeaters having operating and "sleeping" modes is depicted in <FIG>. In this scenario, room location estimation is being performed, having one gateway <NUM> placed inside room <NUM> and one repeater <NUM> placed inside room <NUM>. The system knows the positions of both gateway and repeater and uses the RSSI to assess the beacons' position relatively to these infrastructure elements. Repeater is inside the coverage zone of the gateway <NUM>, so it can send the messages from the nearby beacons to this gateway. Beacon <NUM> is stopped inside room <NUM>. It is both inside the coverage zone of the reader <NUM> and inside the coverage zone of the repeater <NUM>. During the period where the repeater is operating, gateway will receive both messages directly from the beacon and messages from the repeater with the beacon's information. Since the beacon is closer to the repeater, the messages from the repeater will have in principle a higher RSSI for that beacon, leading to the system's conclusion that beacon <NUM> is inside room <NUM>. However, during the "sleeping" period of the repeater, system will only get information from the direct messages of the beacon to the gateway. This will mislead the system into thinking that beacon <NUM> is inside room <NUM>. The system would only have the correct information during the operating periods of the repeater.

This is solved by applying the method described in <FIG>. As the messages from beacon <NUM> are received by gateway and repeater, two buffers are created for that beacon (left side of the image): one containing the packets (timestamp and RSSI) of beacon <NUM> received directly from the gateway, and one containing the packets (timestamp and RSSI) of beacon <NUM> received via repeater packets. Blank slots in the gateway column may represent packets that were not received (e.g. interference, etc). Blank slots in the reader column represent mainly the sleeping or scanning periods, where repeater is not sending packets.

Each time a new packet from beacon <NUM> is received (from a gateway or a repeater), a new position estimation is performed (right side of the image). In this example, repeater is operating from <NUM> to <NUM> minutes during a certain amount of time, and "sleeping" between operation periods. When the new packet is received by the gateway, the system will consider information up to <NUM> minutes in the past (to have information from all relevant repeaters). Since the packet is received at <NUM>:<NUM>:<NUM>, all the packets received between <NUM>:<NUM>:<NUM> and <NUM>:<NUM>:<NUM> are considered by system (from all gateways and all repeaters). The system applies a function (e.g. maximum, average, median,. ) to get a single RSSI value for each infrastructure element (repeaters and gateways). With these values and a position algorithm (closest gateway/repeater, trilateration, etc.), the system estimates the position of the beacon. In this case, using the closest gateway/repeater, beacon <NUM> would be assessed as being in the same room as the repeater (for room-level location). This approach has the best results for slow-changing scenarios, where it is expected that during most of <NUM> minutes intervals, the system does not drastically change.

<FIG> depicts a more complex scenario, where packets from beacon <NUM> are received through multiple gateways and repeaters, simulating a dense infrastructure. Gateways <NUM> and <NUM> receive packets from beacon <NUM> directly. Gateways also receive packets with beacon <NUM> information transmitted by repeaters <NUM> and <NUM>. Packets from repeater <NUM> are received by gateways <NUM> and <NUM>, while packets from repeater <NUM> are only received by gateway <NUM>. For each infrastructure element (gateway and repeater), there is one buffer that stores the received RSSI values.

Repeater <NUM> was operating during a certain period and then went to sleep, so packets from beacon <NUM> are only received during a small interval (around <NUM>:<NUM>:<NUM>). Same happens with repeater <NUM> later (around <NUM>:<NUM>:<NUM>). Note that RSSI values corresponding to the communication between beacon <NUM> and repeater <NUM> are store in the same buffer, regardless of whether they are received through gateway <NUM> or gateway <NUM>. In this case, gateway <NUM> received <NUM> packets during the repeater <NUM> operating period, while gateway <NUM> received only <NUM> (explained by interference, etc.) In practice, this poses no problem since these are redundant values. When a new packet from beacon <NUM> is received at <NUM>:<NUM>:<NUM> on gateway <NUM>, only packets received between <NUM>:<NUM>:<NUM> and <NUM>:<NUM>:<NUM> (<NUM> minutes) are considered. This way, both repeater <NUM> and repeater <NUM> operating periods are considered. As described in the previous example, the system estimates the position of the beacon (closest gateway/repeater, trilateration, etc.), considering all mentioned values.

For each beacon in the system, there will be a table similar to the one depicted in <FIG>, containing data from all the infrastructure (gateways and repeaters) that is currently receiving packets from that beacon.

Since beacon packets are received by both gateways and repeaters, the system may operate with or without the usage of repeaters. However, the scenarios depicted above show the advantage of adding repeaters to increase the range/accuracy of the system. As already stated, these repeaters are autonomous, which make their installation simpler and less expensive. For scenarios where there is a combination of real-time (e.g. people tracking) and non-real-time (e.g. asset tracking) applications, the installation of the system may be done in such a way that gateways cover most of the area where real-time is needed, and repeaters cover the area where non-real-time is enough. For this purpose, tags used for real-time tracking will use a shorter time window to evaluate position and may only consider direct communication with the gateways. Tags used for non-real-time tracking (e.g. <NUM> to <NUM> minutes) will operate with a larger time window to evaluate position, making the position estimation more accurate by taking into account the communication with all available infrastructure (gateways and repeaters).

Since repeaters are always placed in fixed locations, it is expected that the quality of the communication with the gateways remains constant. Namely, the RSSI between each repeater and gateway should be stable over time. Unexpected changes during short or long periods of time help identify changes in the environment, such as RF interference, or malfunction of specific repeaters and gateways. This way, the usage of repeaters enables better monitoring of the system's health.

The disclosure includes aspects that are advantageous over the prior art, in particular: (<NUM>) the repeater operates by alternating between cycles of reception and transmission followed by a sleep period, and (<NUM>) the infrastructure comprises constantly operation parts (i.e., the gateways) and parts operating periodically (i.e., the repeaters).

Flow diagrams of particular embodiments of the presently disclosed methods are depicted in figures. The flow diagrams illustrate the functional information one of ordinary skill in the art requires to perform said methods required in accordance with the present disclosure.

It will be appreciated by those of ordinary skill in the art that unless otherwise indicated herein, the particular sequence of steps described is illustrative only and can be varied without departing from the disclosure. Thus, unless otherwise stated the steps described are so unordered meaning that, when possible, the steps can be performed in any convenient or desirable order.

It is to be appreciated that certain embodiments of the disclosure as described herein may be incorporated as code (e.g., a software algorithm or program) residing in firmware and/or on computer useable medium having control logic for enabling execution on a computer system having a computer processor, such as any of the servers described herein. Such a computer system typically includes memory storage configured to provide output from execution of the code which configures a processor in accordance with the execution. The code can be arranged as firmware or software, and can be organized as a set of modules, including the various modules and algorithms described herein, such as discrete code modules, function calls, procedure calls or objects in an object-oriented programming environment. If implemented using modules, the code can comprise a single module or a plurality of modules that operate in cooperation with one another to configure the machine in which it is executed to perform the associated functions, as described herein.

Claim 1:
Monitoring system for determining the location of Bluetooth beacons comprising:
a plurality of battery-powered Bluetooth beacons, each arranged to:
wirelessly transmit periodically Bluetooth beacon messages comprising a beacon identification, beacon ID, of each said transmitting beacon;
a plurality of battery-powered repeaters, each arranged to:
wirelessly receive the beacon messages transmitted by the Bluetooth beacons; measure the received signal strength of each received beacon message; and
wirelessly transmit Bluetooth beacon messages comprising the beacon ID and the received signal strength of the received beacon messages and also comprising a repeater identification, repeater ID, of the transmitting repeater;
one or more line-powered gateways, each arranged to:
wirelessly receive said beacon messages from beacons and repeaters;
measure the received signal strength of each received beacon message; and
transmit one or more gateway messages comprising the beacon ID, the received signal strength, and the repeater ID if applicable, of the received beacon messages, and a gateway identification, gateway ID, of the transmitting gateway;
a server arranged to:
receive said gateway messages; and
determine the location of each of said plurality of beacons from the received gateway messages using a database of predetermined locations for said one or more gateways and of predetermined locations for said plurality of repeaters.