Smartphone detection

Meshlium allows to detect iPhone and Android devices and in general any device which works with WiFi, BLE or Bluetooth interfaces.

Devices can be detected without the need of being connected to a specific Access Point, enabling the detection of any smartphone, laptop or hands-free car kit device which comes into the coverage area of Meshlium.

The idea is to be able to measure the amount of people and cars which are present in a certain point at a specific time, allowing the study of the evolution of the traffic congestion of pedestrians and vehicles.

Figure : Smartphone detection

Users have to do nothing to be detected, because the WiFi, Bluetooth and BLE radios integrated in their smartphones periodically send a "hello!" message telling about their presence. The information read from each user contains:

  • The MAC address of the wireless interface, which allows to identify it uniquely*.
  • The strength of the signal (RSSI), which gives an idea of the distance of the device from the scanning point**.
  • The vendor of the smartphone (Apple, Samsung, etc).
  • The WiFi Access Point where the user is connected (if any) and the Bluetooth/BLE friendly name. Users not connected to an AP will be showed as "free users".
  • The Class of Device (CoD) in case of Bluetooth/BLE which allows us to differentiate the type of device (smartphone, hands-free, laptop, LAN/network AP). With this parameter we can differentiate among pedestrians and vehicles.

(*) see section “MAC address randomization” for more information
(**) see section “Frequently Asked Questions (FAQ)” for more information

In addition to classic Bluetooth, Meshlium integrates a radio for Bluetooth Low Energy (BLE) since January 2020. Also known as Bluetooth 4.0, BLE is used for applications that do not need to exchange large amounts of data, and can therefore run on battery power for long time. It is primarily aimed at IoT devices in the health, fitness, beacons, security and home entertainment industries. More and more devices feature a BLE radio, like smart watches, blood pressure monitors, Fitbit-like devices, industrial monitoring sensors and geo-trackin devices.

The coverage areas may be modified by changing the power transmission of the radio interfaces allowing the creation of different scanning zones from a few meters (in order to study a specific point) to dozens of meters (to study the whole street or even the entire floor of a shopping mall).

Applications related to shopping and street activities:

  • Number of people passing daily in a street.
  • Average time of the stance of the people in a street.
  • Walking routes of people in shopping malls and average time in each area.
  • Simple device-aware games (reward people for returning to your shop).

The Vehicle Traffic Monitoring is also another important application as understanding the flow and congestion of vehicular traffic is essential for efficient road systems in cities. Smooth vehicle flows reduce journey times, reduce emissions and save energy. Similarly the efficient flow of pedestrians in an airport, stadium or shopping center saves time and can make the difference between a good and a bad visit. Monitoring traffic - whether road vehicles or people - is useful for operators of roads, attractions and transport hubs.

Figure : Vehicle Traffic Detection

Applications for Vehicle Traffic Detection:

  • Number of people passing daily in a street.
  • Average time of the stance of the people in a street.
  • Routes of people and average time in each area.

The monitoring system can also be used to calculate the average speed of the vehicles which transit over a roadway by taking the time mark at two different points.

Figure : Calculate the average speed

Devices detected

Detection includes any of the last models even those that implement low consumption techniques when using the radio interfaces:

  • iPhone (all models).
  • Android (all models).

MAC address randomization

It is possible to track devices, and therefore their users, using their media access control (MAC) address as a unique identifier. To fulfill with privacy regulations and public concerns, some vendors have taken the decision to randomize the MAC addresses that are used when the phone is not connected to a WiFi network.

This ensures that a client cannot easily be tracked when it moves between locations. WiFi clients may use a randomized MAC address to discover networks, but revert to their "factory" MAC address once they start the process to connect to a WiFi network.

Apple and Android added MAC address randomization to their devices starting from iOS 8 and Android 6 (if hardware supported). Depending on the vendor, Meshlium will detect the randomized MAC address when it is not connected to a WiFi network but always its "factory" MAC address when the device is connected to a WiFi access point (AP).

Vehicle Traffic Monitoring

The reduction of the time between scanning intervals allows for increments in the vehicles detection rate.

  • Monitor in real time the number of vehicles passing for a certain point in highways and roads.
  • Detect average time of vehicle stance for traffic congestion prevention.
  • Monitor average speed of vehicles in highways and roads.
  • Provide travel times on alternate routes when congestion is detected.

Antennas

Besides the omnidirectional antennas provided by default with the Meshlium kit, it is possible to install 2 other types of antennas, the directional and the sector antennas.

The directional antennas extend the range of WiFi, Bluetooth and BLE scanning in the required direction in around 40º. Libelium provides a pack of 3 directional antennas ready to connect to Meshlium in the same sockets available for the omnidirectional WiFi, Bluetooth and BLE antennas. They are specially recommended for Vehicle Traffic Monitoring applications. The dimensions of the antenna are 17 x 17 x 3 cm and weights about 350 g. The antenna has a gain of 14 dBi and comes with the needed mounting system, 3 m cables and screw adapters.

Figure : Directional antenna for Meshlium Scanner

The sector antennas is a type of directional antenna categorized by its azimuth plane width. They are commonly available with 60º, 90º, and 120º. Sector antennas are usually deployed higher up. The height of the deployment helps to select the required antenna, as this impacts in the gain and range of the antenna. Libelium does not provide sector antennas, so the user can look for a compatible one. Remember that the use of any unofficial hardware -like sectorial antennas- voids the warranty of Libelium's products.

Directional antenna coverage

Sector antenna coverage

Frequently Asked Questions (FAQ)

Do the users need to have a specific app installed or interact somehow to be detected?

No, the scan is performed silently, Meshlium just detects the "beacon frames" originated by the WiFi, Bluetooth or BLE radios integrated in the devices. Users just need to have at least one of the wireless interfaces turned on.

How do we differentiate if the Bluetooth/BLE device detected is a car's hands-free or a smartphone?

In the scanning process each Bluetooth/BLE device gives its "Class of Device" (CoD) attribute which allows to identify the type of service it gives. We can differentiate easily the CoD's generated by the car's hands-free from the people's phone ones.

How do I control the inquiry area?

In the Bluetooth/BLE inquiry there are different power levels which go from -27 dBm to 9.8 dBm in order to set different coverage zones from 10 to 50 m. In WiFi, Bluetooth and BLE radios these zones can also be increased or decreased by using a different antenna for the module as it counts with a standard N-Male connector. The default antenna which comes with the scanning modules is an omnidirectional antenna with a gain of 5 dBi.

How do I calculate the distance of any of the devices detected?

In the inquiry process we receive the MAC address of the Bluetooth/BLE device along with the Received Signal Strength Indicator (RSSI) which gives us the quality of the transmission with each device. RSSI values usually go from -40 dBm (nearest nodes) to -90 dBm (farthest ones).

In the tests performed, Bluetooth devices at a distance of 10 m reported -50 dBm as average, while the ones placed at 50 m gave us an average of -75 dBm. However, The RSSI value does not have a direct proportion with the distance and the correlation could be difficult to obtain. There are unpredictable effects like obstacles in the RF path, reflections, refractions, fading, multipath transmission, etc. The RSSI may change slightly from 2 phones at the same distance or from one frame to another later in time depending on the environment. Therefore, detailed measures have to be taken in place for determining this relation.

What about privacy?

The anonymous nature of this technique is due to the use of MAC addresses as identifiers. MAC addresses are not associated with any specific user account or mobile phone number not even to any specific vehicle. Additionally, the "inquiry mode" (visibility) can be turned off so people have always chosen if their device will or will not be detectable.

How do the Bluetooth/BLE, WiFi and 802.15.4/ZigBee radios coexist without causing interferences with each other? WiFi, XBee, Bluetooth/BLE work in the 2.4GHz frequency band (2.400-2.480 MHz), however, the Bluetooth and BLE radios integrated in Meshlium use an algorithm called Adaptive Frequency Hopping (AFH) which improves the common algorithm used by Bluetooth/BLE (FHSS) and enables the Bluetooth/BLE radio to dynamically identify channels already in use by XBee and WiFi devices and to avoid them.

Anyway, in the case of sending 802.15.4 frames from Waspmote or Plug & Sense! to a Meshlium Scanner equipped with XBee-PRO 802.15.4, it is recommended to perform re-tries in the sender application, just to minimize possible interferences and ensure a good percentage of received frames in Meshlium.

Figure : Bluetooth/BLE, WiFi and 802.15.4/ZigBee radios coexist

Under which conditions do you get a 95% detection rate of devices?

A set of conditions must be respected to keep the detection rate high.

The devices to be detected must be some meters away from the Scanner and must remain some seconds inside the coverage area to give time to the system to detect them.

The default setup of the WifiScan feature in Meshlium is 40 seconds of scanning span. This means Meshlium Scanner listens for 40 seconds and then stores the results of the scanning process. This parameter can be adjusted from "Real Time" to 90 seconds of scanning span.

If you select "Real Time" detection, Meshlium will continuously scan and store each register as soon as it is detected.

{warning.fa-dot} Important:

The "Real Time" option has their advantages and inconveniences. On the one hand, the precision in the detection time will significantly increase. On the other hand, memory and CPU usage will increase too. The user must check the CPU temperature does not get too high, especially in areas with hot weather.

Android and iOS devices have a special option to disable WiFi connection when the user locks the screen in order to save battery. All cases are studied here. This option changes with the iOS version, but will be present in the majority of iOS devices.

When a device is connected to a WiFi Access Point it is normally always detected, fetching its factory MAC, as it needs to send radio packets to allow communication.

The results not Android or iOS devices may vary depending on the type of system. Usually, APs are always detected, as they broadcast the SSID. Hidden SSID are detected too. The only APs that can be hard to detect are the APs that do not broadcast their presence. This APs can only be detected when there is traffic from connected devices.

Regarding other WiFi devices, the individual behaviour will define if they are detectable. As a general rule, every device that broadcasts beams or is connected generating traffic will be detected.

WiFi detection is summarized on this table:

WiFi OFF: never detected

Connected to AP Screen Detection MAC fetched Use cases
YES ON

YES

All scanning cycles

Factory MAC

100% cases

Office, work, malls, etc. any place where user connects to WiFi AP and using the phone
YES

OFF

or power saving

YES

Most scanning cycles

Factory MAC

100% cases

Office, work, malls, etc. any place where user connects to WiFi AP and NOT using the phone
NO ON

YES

All scaning cycles

Randomized MAC** People and cars on movement using the phone
NO OFF
or power saving

YES

Some scan cycles*

Randomized MAC** People and cars on movement NOT using the phone

(*) few minutes, depending on the model
(**) depending on the operating system and model

Bluetooth/BLE scanning, unlike WiFi scanning, is based on polling, and not in passive listening. This makes Bluetooth/BLE detection slower and gives the device the chance of avoiding detection (it just needs to ignore the polling request).

Nevertheless, Bluetooth/BLE scan is still useful in some applications, like car detection, as most of modern cars have a Bluetooth/BLE hands-free device, and these devices are most of the time listening for connections. Any smartphone can be configured to be visible (or not) by other Bluetooth/BLE devices. Putting this option as "NOT VISIBLE" will make the smartphone undetectable by any other Bluetooth/BLE device, which includes Meshlium Scanner. Note that some latest-technology hands-free devices implement the "not visible" mode too.

When the Bluetooth/BLE interface is set as visible, the phone will be listening for incoming queries. This way the device can be scanned. The visibility setup may be different in different devices. Some of them activate visibility for a limited time (usually 30 seconds), some others have a manual control to enable/disable the visibility.

Different Android and iOS versions have different behaviors about Bluetooth/BLE visibility. In most of the modern versions, Bluetooth/BLE visibility is disabled when the screen is locked (or even when the user exits the Bluetooth/BLE configuration menu). There is no way to detect an Android or iOS phone with the screen off, which makes it very difficult to scan Android or iOS devices in a real environment. On the other hand, there are more and more smartphones paired permantently with wearables devices, which makes them easily detectable.

There are a lot of types of Bluetooth/BLE devices. Most of slave Bluetooth/BLE devices are designed to wait for incoming connections. This makes highly possible to detect devices like hands-free car kits, headsets, HID, etc.

The scanning time is more important in Bluetooth/BLE as the devices need some time to reply to the queries.

Device name is not always obtained, as some devices take some time to reply to the name queries. Nevertheless, the device can be easily identified by its MAC address.

How can I calculate the total number of people from the number of detected devices?

It depends. Not all the people have a smartphone. Also, not all the people switch WiFi and/or Bluetooth/BLE radios on their smartphones and wearables. It all depends on so many economic, social and cultural factors. The percentage of people with WiFi or Bluetooth/BLE on depends on the scenario where they are too. For example, if a Meshlium Scanner is installed in a college campus which provides free WiFi service, many students will be detected because they will probably keep their smartphones, tablets or notebooks with WiFi on. The same would happen in a mall, airport or hotel with free WiFi.

Besides, consider that not all the people who could be detected will remain enough time inside of the coverage area of Meshlium Scanner.

Also, keep in mind that some people can carry several WiFi or Bluetooth/BLE devices. For example, a driver with smartphone in his pocket and a Bluetooth/BLE device in his car can be detected as 2 different users by Meshlium.

It all depends on a number of variables. The administrator of Meshlium Scanner can perform real tests in order to find the exact value of this factor in the specific scenario under study.

WiFi Scanner

Concepts

The additional 2nd WiFi radio integrated in Meshlium Scanner allows to scan WiFi devices in a range of action of up to 500 m (depending on the line of sight conditions). Meshlium Scanner can detect devices in the 2.4 GHz and 5 GHz frequency bands.

The idea is to search for WiFi devices in a defined interval which can be configured. Meshlium will get the MAC address, information about the detected Device. Regarding these devices, we can distinguish Access Points and Clients .In the case of each client, Meshlium gets which Access Point the device is connected to (if any). Also, the signal strength (RSSI) of the device along with a timestamp which identifies when the scan was performed, or when the device was detected ("Real Time" option). The timestamp is always stored in UTC to avoid inconsistencies (regardless of the time zone selected in Meshlium). It is important to set the correct time in the System before starting with the storage of the data. See the Time Synchronization in the System section.

As extra information, the System also identifies the Vendor of the WiFi devices using its MAC address and if the information is synchronized to the external database (Sync).

Example of information scanned:

B ID Sync Timestamp MAC Device RSSI Vendor
53483 0 2012-04-24 07:56:25 C4:2C:03:96:0E:4A (not detected) 69 Apple
53482 1 2012-04-24 09:11:26 D8:2A:7E:10:1E:63 libelium_wsn1 60 Nokia Corporation

Wifi scanner configuration menu is located in:

Tools -> Wifi Scan

In this section we can select the Scanning Time from a drop-down list. This time specifies how many seconds the scanner will spend searching. After each scanning process, the system performs a pause of one second before starting again.

The option "Real Time" behaves differently to the other options. Usually, data is stored with the timestamp of the scanning process, but with the "Real Time" option, the timestamp will be the exact time when the device is detected (with seconds precision).

The Scanning Time must be trimmed in order to avoid that a temperature of 70ºC is reached in the Meshlium's microprocessor. See chapter "Internal temperature sensor" to know how to monitor the microprocessor's temperature.

Figure : Configuring WiFi Scanner

We can also activate the anonymization of the MAC addresses. This option will store the MAC address encoded with an MD5 hash. The hash will be consistent in the same day, but will change from one day to another. This system allows to follow a particular user in the same day, but keeps the privacy of the user, not storing the real MAC of the device and not allowing to track a user more than one day.

From this section the user can start and stop the service from the button next to the status indicator.

Figure : WiFi Scanner was stopped

If the user manually stops the service, it will be automatically relaunched upon reboot. In order to completely disable service, the user have to click on the slider "Disable Service". This will stop the service and avoid it to run upon reboot. Setup cannot be changed when disabled, but already stored data is available to be shown.

To enable the service again, click on the slider "Enable Service".

Figure : Enable and Disable controls

It is possible to perform two different storage options with the data captured:

  • Local database: This is always used.
  • External database: The data is synchronized to an external database from the local database.

Figure : WiFi Scanner storing options

Local database

Meshlium has a MySQL data base up and running which is used to store locally the information captured. In the "Local Data Base" tab you can see the connection parameters.

  • Database: MeshliumDB
  • Table: wifiScan
  • IP: localhost
  • Port: 3306
  • User: root
  • Password: libelium2007

Figure : Local database for WiFi Scanner

At any time you can see the last "x" records stored, filtered by access points or clients. Just set how many and what kind of insertions you want to see and press the "Show data" button. The maximum number of data to display is 500.

The data from the database can be deleted pressing the button "Delete all data". Be careful, as this option deletes all the information of WiFi scans in the local database.

There is an option to program an automatic purge in the database every day, keeping the information in the database the days you specify. Furthermore, if you intend to configure the external database, you can choose if you want to delete only synchronized data or everything, taking care of the days established before.

External database

Meshlium can synchronize all the WiFi devices information stored in the local database to an external MySQL database managed by the user.

In this tab the user can:

  • Setup the parameters of the external database and check the connection.
  • Enable or disable the synchronization.
  • Select the number of fields sent per synchronization iteration.
  • Show last data inserted in the external database (up to 500 data).
  • Show the SQL script used to create the database and table needed for the synchronization.
  • Mark all data in the local database as synchronized so it will not be sent to the external database.

The steps to setup the synchronization are:

  • Before configuring anything, make sure you have a MySQL database working under your control. Make sure the database listens to connections in an external IP.
  • Press the "Show SQL script" button, copy the SQL code. You can modify user, password, database name and table, as long as you change the setup of the connection to match.

Figure : SQL script

  • Enter the connection settings and press "Save" button. You can check the connection now to ensure the settings are correct.
  • Enable the service with the checkbox and save.

The synchronization service runs every 60 seconds and synchronizes up to 100 data every loop. The service synchronizes first newer data, as it is more relevant for decision making. This could make data in external database to be out of order. As every data has a timestamp, this should not be a problem for using the data in any external application.

The "Real time" scanning option will increase the number of registers stored in the database. It is highly recommendable to change the "Synchronization limit" from the default value (100) to a higher number that allows the database to synchronize completely.

Bluetooth/BLE Scanner

Concepts

The Bluetooth and BLE radios integrated in Meshlium Scanner allow to scan Bluetooth and BLE devices in a range of action of up to 100 m depending on the line of sight conditions.

The idea is to search for Bluetooth/BLE devices in a defined interval which can be configured. Meshlium will get the MAC address, the Bluetooth ID and the RSSI of the devices along with a timestamp which identifies when the device is detected. The timestamp is always stored in UTC to avoid inconsistencies (regardless of the time zone selected in Meshlium). It is important to set the correct time in the System before starting with the storage of the data. See the Time Synchronization in the System section.

Other interesting parameters the system also detects are the Class of Device (CoD) which allows us to differentiate the type of device (smartphone, wearable, hands-free, laptop computer, LAN/network AP) and the Vendor of the Bluetooth/BLE devices using its MAC address.

With these parameters we can differentiate among pedestrians and vehicles.

B ID Timestamp MAC ID RSSI CoD Vendor
45400 2012-05-16 16:18:12 07:56:25 00:26:7e:5f:3c:18 myCar -72 Handsfree PARROT SA
78005 2012-04-20 12:59:27 09:11:26 D8:2A:7E:0E:C3:10 Tropic -82 Smartphone Nokia Corporation

Bluetooth/BLE scanner configuration menu is located in:

Tools -> Bluetooth Scan

In this section we can configure the Scanning Type which specifies the use of our Bluetooth/BLE Scanner:

  • Indoor type is recommended to scan static devices or devices with slow movement (offices, malls, etc). This option retrieves device names after about 15 seconds scanning.
  • Outdoor type focus on devices which stay a brief period of time in our Bluetooth/BLE action range (roads, highways,...). This option does not ask the device name and the scanning period is about 45 seconds.

In both types, the devices are registered in the database as soon as they are detected.

Figure : Configuring Bluetooth/BLE Scanner

We can also activate the anonymization of the MAC addresses. This option will store the MAC address encoded with an MD5 hash. The hash will be consistent in the same day, but will change from one day to another. This system allows to follow a particular user in the same day, but keeps the privacy of the user, not storing the real MAC of the device and not allowing to track a user more than one day.

From this section the user can start and stop the service from the button next to the status indicator.

Figure : Bluetooth/BLE Scanner was stopped

If the user manually stops the service, it will be automatically relaunched upon reboot. In order to completely disable service, the user have to click on the slider "Disable Service". This will stop the service and avoid it to run upon reboot. Setup cannot be changed when disabled, but already stored data is available to be shown.

To enable the service again, click on the slider "Enable Service".

Figure : Enable and Disable controls

Note: Last versions of Android and iOS devices may need the Bluetooth/BLE Setup Screen be activated to be detected.

We have two different storage options for the data captured:

  • Local database: This is always active.
  • External database: This synchronizes local database data to an external MySQL database.

Figure : Bluetooth/BLE Scanner storing options

Local database

Meshlium has a MySQL database up and running which is used to store locally the information captured. In the "Local Data Base" tab you can see the connection parameters.

  • Database: MeshliumDB
  • Table: bluetoothData
  • IP: localhost
  • Port: 3306
  • User: root
  • Password: libelium2007

Figure : Local database for Bluetooth/BLE Scanner

At any time you can see the last "x" records stored, filtered by access points or clients. Just set how many and what kind of insertions you want to see and press the "Show data" button. The maximum number of data to display is 500.

The data from the database can be deleted pressing the button "Delete all data". Be careful, as this option deletes all the information of Bluetooth/BLE scans in the local database.

There is an option to program an automatic purge in the database every day, keeping the information in the database the days you specify. Furthermore, if you intend to configure the external database, you can choose if you want to delete only synchronized data or everything, taking care of the days established before.

External database

Meshlium can synchronize all the Bluetooth/BLE devices information stored in the local database to an external MySQL database managed by the user.

Figure : External database tab

In this tab the user can:

  • Setup the parameters of the external database and check the connection.
  • Enable or disable the synchronization.
  • Select the number of fields sent per synchronization iteration.
  • Show last data inserted in the external database (up to 500 data).
  • Show the SQL script used to create the database and table needed for the synchronization.
  • Mark all data in the local database as synchronized so it will not be sent to the external database.

The steps to setup the synchronization are:

  • Before configuring anything, make sure you have a MySQL database working under your control. Make sure the database listens to connections in an external IP.
  • Press the "Show SQL script" button, copy the SQL code. You can modify user, password, database name and table, as long as you change the setup of the connection to match.

Figure : SQL script

  • Enter the connection settings and press "Save" button. You can check the connection now to ensure the settings are correct.
  • Enable the service with the checkbox and save.

The synchronization service runs every 60 seconds and synchronizes up to 100 data every loop. The service synchronizes first newer data, as it is more relevant for decision making. This could make data in external database to be out of order. As every data has a timestamp, this should not be a problem for using the data in any external application.