Home > Wireless LAN > Bluetooth > Bluetooth Low Energy (BLE)

Bluetooth Low Energy (BLE)

Meraki access points with an integrated Bluetooth Low Energy radio have the ability to transmit BLE Beacons, as well as to scan and locate BLE devices. Client devices like smartphones “hear” the BLE Beacon emitted by a Meraki AP, and an app on the smartphone can respond to a recognized Beacon. BLE scanning allows the Meraki AP to listen for and locate all Bluetooth Low Energy devices. The BLE scanner can hear other Beacons, BLE asset tags, and devices like fitness monitors that communicate using BLE data protocols. The Bluetooth Location API allows third party applications to provide asset tracking and analytics using battery-based bluetooth tags or wearables like fitness monitors.

Bluetooth clients

Detected devices will also be displayed in the Wireless > Monitor > Bluetooth clients page. The list of BLE clients can be viewed for several different observation time periods (two hours, one day, one week), and displays several useful pieces of information such as the AP that observed the device and, when available, the manufacturer of the device. The dashboard allows tagging the Bluetooth devices to identify individual or groups of devices.

Figure 4: Bluetooth clients page

Email alerts

Additional details about each Bluetooth device can be seen on the client details page. The name of the Bluetooth client can also be edited for easier tracking. Email alerts can be enabled to trigger when the device becomes visible by the access point and when the device is no longer visible.

Figure 5: BLE client details

Enable Bluetooth Scanning

Using the physical placement of the access points from the Map & Floorplan on the Dashboard, the Meraki cloud estimates the location of the client. The geo-location coordinates (latitude, longitude) and X,Y location data accuracy can vary based on a number of factors and should be considered a best effort estimate. AP placement, environmental conditions, and client device orientation can influence X,Y estimation; experimentation can help improve the accuracy of results or determine a maximum acceptable uncertainty for data points.

 

To enable BLE devices to be located, enable the BLE scanning radio on the access points. BLE Scanning is enabled in the Wireless >  Bluetooth Settings > Scanning settings page by selecting "Scanning enabled" in the Scanning section, as shown in Figure 3 below:

Figure 3: Enabling BLE scanningBLE Scanning API

 

Bluetooth API Data Elements

Name
Format
Description
apMac string MAC address of the observing AP
apTags [string] JSON array of all tags applied to the AP in dashboard
apFloors [string] JSON array of all floorplan names on which this AP appears
clientMac string Device MAC
seenTime ISO 8601 date string Observation time in UTC; example: "1970-01-01T00:00:00Z"
seenEpoch integer Observation time in seconds since the UNIX epoch
rssi integer Device RSSI as seen by AP
location location Device geolocation; null if location could not be determined
lat decimal Device latitude in degrees N of the equator
lng decimal Device longitude in degrees E of the prime meridian
unc decimal Uncertainty in meters
x [decimal] JSON array of x offsets (in meters) from lower-left corner of each floorplan
y [decimal] JSON array of y offsets (in meteres) from lower-left corner of each floorplan

Enable the Scanning API with BLE Scanning, and the Location API will include both WiFi and Bluetooth devices seen by the access points in a single data feed. The event type BluetoothDevicesSeen is used to identify the observations from the Bluetooth radio. Below are the JSON formats used by the Location API for Bluetooth devices.

 

HTTP POST body format

{
   "version":"2.0",
   "secret":<string>,
   "type":"BluetoothDevicesSeen",
   "data":<event-specific data>
}

 

Bluetooth API Data Format

{
  "apMac": <string>,
  "apFloors": [<string>, ...],
  "apTags": [<string, ...],
  "observations": [
    {
      "location": {
        "lat": <decimal>,
        "lng": <decimal>,
        "unc": <decimal>,
        "x": [<decimal>, ...],
        "y": [<decimal>, ...]
      },
      "seenTime": <string>,
      "clientMac": <string>,
      "seenEpoch": <integer>,
      "rssi": <integer>,
    },...
  ]
}

Enable Scanning API 

The Location API is configured in the Meraki Dashboard on the Network Wide > General settings page in a few simple steps:

  1. Turn on the API by selecting Scanning API enabled in the dropdown box.

  2. Specify a post URL and the authentication secret (the secret is used by your HTTP server to validate that the JSON posts are coming from the Meraki cloud)
  3. Specify which Scanning API version your HTTP server is prepared to receive and process.
  4. Configure and host your HTTP server to receive JSON objects.
  5. Upon the first connection, the Meraki cloud will perform a single HTTP GET; the server must return the organization-specific validator string as a response, which will verify the organization's identity as the Cisco Meraki customer. The Meraki cloud will then begin performing JSON posts. 

 

 

 

Protocol flow between Meraki cloud and third-party server:

 

Privacy for Scanning API

Cisco Meraki's Location API, outlined above, exports raw MAC addresses to a specified third-party server. There are a number of privacy protection mechanisms that we have implemented, including:

 

No customer identity tie-in mechanisms

Cisco Meraki does not directly provide any way of tying MAC addresses to customer identity. These systems must be separately built and hosted by a customer, partner or service provider.

 

No customer contact mechanisms

Cisco Meraki does not provide any mechanism by which the location API data can be used to contact customers in any way. For real-time user engagement, Cisco Meraki customers must build and maintain their own platform for contacting customers.

 

Recommended best practices

Cisco Meraki recommends a number of best practices for users of its API, including:

  • Opt-in Cisco Meraki customers should make it explicitly clear at the time of identity tie-in (e.g., via a splash page or through a mobile app) that user-provided information may be linked to a device's MAC address for more extensive engagement.
  • On-premise notification As with the use of the built-in Location Analytics, notice should be prominently displayed in areas using of the Location API data.
  • Opt-out In addition to providing an opt-in policy, Cisco Meraki customers should make their own customers aware of Cisco Meraki's global opt-out policy (allowing an opt-out by MAC address) and provide an intuitive means of accessing Cisco Meraki's opt-out page. Cisco Meraki's global opt-out is available at https://account.meraki.com/optout.

Bluetooth Advertising

The Cisco Meraki MR30H, MR32, MR33, MR42, MR52, MR53, MR72, MR74 and MR84 WiFi access points have a built-in BLE iBeacon Advertising mode. You can enable the beacon right from the Cloud-hosted dashboard and configure the UUID, Major, and Minor. Meraki’s BLE enabled access points enable customers to begin developing practical applications for BLE devices. For example, you can use the BLE beacon advertising in a mobile app to trigger notifications or determine the position of the smartphone for wayfinding. These can be broadly categorized into ‘push’ applications, where the AP informs an aware device that it is in a certain location, or ‘pull’ applications, where the AP listens for beacons and uses this information to assist with asset tracking and control through the dashboard.

Configuring Beacons

Beacons are periodic signals emitted using Bluetooth Low Energy radio technology and conforming to a specific data packet format. The data packet looks like this:

Field

Preamble

Access Address

Header

MAC Address

Beacon prefix

UUID

Major

Minor

TX Power

CRC

Size

1B

4B

2B

6B

9B

16B

2B

2B

1B

3B

The Preamble, Access Address, Header, MAC Address, and CRC will be set as part of the BLE radio’s frame construction. The TX Power is a calibrated indicator of the RSSI of the transmitted measured at a 1m distance; this can be used for rough estimation of proximity to the device emitting the Beacons.

UUID, Major, and Minor are fields defined by the Beacon network administrator. Typically, an organization will define a unique identifier for their habitual usage: the UUID. All Beacons deployed throughout their locations would have the same UUID.

To differentiate Beacons at different offices or store locations, and Beacons within different areas of those locations, the Major and Minor fields are used. For example, a chain restaurant might decide that all restaurants within a city will share a Major, and each restaurant within that city will have a different Minor.

Meraki APs with an integrated Bluetooth Low Energy radio can emit Beacons with following technical specifications:

  • Beacon interval: 100 ms
  • Transmit power: 0 dBm

 

Beacon mode can be enabled under Wireless > Configure > Bluetooth by selecting "Advertising enabled" in the Advertising section, as show in Figure 1 below:

Figure 1: Enabling BLE Beacon advertising
 

Once advertising is enabled, the UUID, Major, and Minor fields of the Beacon frame can be set:

Figure 2: Setting the BLE Beacon UUID/Major/Minor

 

Saving these settings will activate the BLE Beacon on the Meraki AP’s integrated Bluetooth Low Energy radio.

You must to post a comment.
Last modified
09:46, 20 Jul 2017

Tags

Classifications

This page has no classifications.

Article ID

ID: 3461

Contact Support

Most questions can be answered by reviewing our documentation, but if you need more help, Cisco Meraki Support is ready to work with you.

Open a Case

Ask the Community

In the Meraki Community, you can find answers provided by fellow Meraki users and ask questions of your own.

Visit the Community