My Concept for the Cisco Internet of Things Innovation Grand Challenge

Here is the concept I just submitted for the Cisco's IoT Challenge:

Deploy a network of fixed Bluetooth scanners throughout an urban area and/or transportation corridor to enable a region-wide alert/notification system for things: Bluetooth enabled devices that transmit a Bluetooth signal. Currently this includes: mobile phones, medical devices, consumer electronics, vehicles, smart watches, FitBits and other activity trackers, and a myriad of sensors and trackers.

This essentially addresses the last mile problem for things, using a well understood and widely adopted RF protocol (30 Billion Bluetooth devices estimated to be deployed by 2016). I have created a mobile app-based prototype of this system which supports both Bluetooth Classic and Bluetooth Low Energy (with data available at earthping.com) in which the scanning is crowdsourced (a mobile app rather than fixed scanners). Fixed scanners would be available through an API to enable subscribers to access the data. Only devices registered to be tracked (with Bluetooth Address) would be allowed, except for public safety use cases. 

Use cases for this would include:

• An Amber Alert add-on in which kids with a Bluetooth radio (they cost less that $20) or their abductors cars or mobile phones would be able to be tracked.
• Stolen cars (most will be Bluetooth enabled according to industry research) would be identified when passing by a scanner.
• Cities deploying this type of technology could license the data for market research as a revenue source (following appropriate guidelines for security and privacy).
• App developers and other commercial entities could license specific scanners (beacons) to implement iBeacon functionality in which an app (only those apps that users install on their phones and approve) would wake up in the proximity of a beacon.
• Public alert systems could leverage the beacon capability of the Bluetooth network to provide fine grain alerts based on proximity to an event.

Features that could be implemented with such a system are extensive and include any use case that might leverage alerts, triggers, geo-fencing, inventory, tracking and sensors. This type of system could save lives, provide revenue and also perhaps impact city-wide insurance premiums. The system could be deployed in increments such as a major transportation corridor, malls, or borders for specific requirements.

Bluetooth LE Captures from an item tracker

Item Tracker Bluetooth Device Captures

Below shows another advertising strategy. This shows an advertising sequence between an item tracker from Phone Halo and the Bluescan app running on an Android device with BD_ADDR of AC:22:0B:45:87:55. The second capture is between another tracking device (I got a second one of their devices via their Indiegogo campaign) and their proprietary app.

Device 1

This is the advertisement and scan request from the BlueScan app:

Advertisement

 systime=1402000803 freq=2402 addr=8e89bed6 delta_t=1287.768 ms  
 40 23 ac 91 89 1c f3 c7 04 09 74 6b 72 03 19 40 02 02 01 06 02 0a 04 03 03 3e 0f 09 ff 00 00 ac 91 89 1c f3 c7 40 22 c7   
 Advertising / AA 8e89bed6 / 35 bytes  
   Channel Index: 37  
   Type: ADV_IND  
   AdvA: c7:f3:1c:89:91:ac (random)  
   AdvData: 04 09 74 6b 72 03 19 40 02 02 01 06 02 0a 04 03 03 3e 0f 09 ff 00 00 ac 91 89 1c f3 c7  
     Type 09 (Complete Local Name)  
       tkr  
     Type 19  
       40 02  
     Type 01 (Flags)  
       00000110  
     Type 0a (Tx Power Level)  
       4 dBm  
     Type 03  
       3e 0f  
     Type ff  
       00 00 ac 91 89 1c f3 c7  
   
   Data: ac 91 89 1c f3 c7 04 09 74 6b 72 03 19 40 02 02 01 06 02 0a 04 03 03 3e 0f 09 ff 00 00 ac 91 89 1c f3 c7  
   CRC:  40 22 c7  

Scan Request

 systime=1402000803 freq=2402 addr=8e89bed6 delta_t=0.352 ms  
 83 0c 55 87 45 0b 22 ac ac 91 89 1c f3 c7 a7 21 48   
 Advertising / AA 8e89bed6 / 12 bytes  
   Channel Index: 37  
   Type: SCAN_REQ  
   ScanA: ac:22:0b:45:87:55 (public)  
   AdvA: c7:f3:1c:89:91:ac (random)  
   
   Data: 55 87 45 0b 22 ac ac 91 89 1c f3 c7  
   CRC:  a7 21 48  

Scan Response

 systime=1402000803 freq=2402 addr=8e89bed6 delta_t=0.263 ms  
 44 06 ac 91 89 1c f3 c7 1a 59 6e   
 Advertising / AA 8e89bed6 / 6 bytes  
   Channel Index: 37  
   Type: SCAN_RSP  
   AdvA: c7:f3:1c:89:91:ac (random)  
   ScanRspData:  
   
   Data: ac 91 89 1c f3 c7  
   CRC:  1a 59 6e  

Device 2:

This is another one of their devices in which the capture was between their device and their proprietary Android app. In this case, there is an advertisement and a connection request.

Advertisement

 systime=1402002717 freq=2402 addr=8e89bed6 delta_t=27.500 ms  
 40 15 ca b3 9b 87 c2 c7 02 01 05 07 09 69 6e 53 69 74 65 03 19 ff ff d8 85 00   
 Advertising / AA 8e89bed6 / 21 bytes  
   Channel Index: 37  
   Type: ADV_IND  
   AdvA: c7:c2:87:9b:b3:ca (random)  
   AdvData: 02 01 05 07 09 69 6e 53 69 74 65 03 19 ff ff  
     Type 01 (Flags)  
       00000101  
     Type 09 (Complete Local Name)  
       inSite  
     Type 19  
       ff ff  
   
   Data: ca b3 9b 87 c2 c7 02 01 05 07 09 69 6e 53 69 74 65 03 19 ff ff  
   CRC:  d8 85 00  

Connect Request

 systime=1402002717 freq=2402 addr=8e89bed6 delta_t=0.495 ms  
 85 22 55 87 45 0b 22 ac ca b3 9b 87 c2 c7 76 f6 7c c7 a4 66 90 02 12 00 27 00 00 00 d0 07 ff ff 7f 00 1c a5 23 dd c1   
 Advertising / AA 8e89bed6 / 34 bytes  
   Channel Index: 37  
   Type: CONNECT_REQ  
   InitA: ac:22:0b:45:87:55 (public)  
   AdvA: c7:c2:87:9b:b3:ca (random)  
   AA:  c77cf676  
   CRCInit: 0066a4  
   WinSize: 02 (2)  
   WinOffset: 0012 (18)  
   Interval: 0027 (39)  
   Latency: 0000 (0)  
   Timeout: 07d0 (2000)  
   ChM: ff ff 7f 00 1c  
   Hop: 5  
   SCA: 5, 31 ppm to 50 ppm  
   
   Data: 55 87 45 0b 22 ac ca b3 9b 87 c2 c7 76 f6 7c c7 a4 66 90 02 12 00 27 00 00 00 d0 07 ff ff 7f 00 1c a5  
   CRC:  23 dd c1  

Gimbal Bluetooth iBeacon Advertising

Gimbal iBeacons

Below are some packet captures from the Gimbal Proxmity Beacon Series 10. These are advertisements from two devices.

First 5 seconds

For the first five seconds the devices appear to broadcast their Bluetooth addresses. Notice the AdvA for each of the following two captures:

Device 1 (a4:d8:56:01:75:ce)

 size 16  
 systime=1401996656 freq=2402 addr=8e89bed6 delta_t=22295.843 ms  
 00 1b ce 75 01 56 d8 a4 02 01 06 11 07 ad 77 00 c6 a0 00 99 b2 e2 11 4c 24 00 4f 0c 96 24 40 b3   
 Advertising / AA 8e89bed6 / 27 bytes  
   Channel Index: 37  
   Type: ADV_IND  
   AdvA: a4:d8:56:01:75:ce (public)  
   AdvData: 02 01 06 11 07 ad 77 00 c6 a0 00 99 b2 e2 11 4c 24 00 4f 0c 96  
     Type 01 (Flags)  
       00000110  
     Type 07 (128-bit Service UUIDs)  
       960c4f00-244c-11e2-b299-00a0c60077ad  
   
   Data: ce 75 01 56 d8 a4 02 01 06 11 07 ad 77 00 c6 a0 00 99 b2 e2 11 4c 24 00 4f 0c 96  
   CRC:  24 40 b3  
   

Device 2 (a4:d8:56:01:a5:cc)

 size 16  
 systime=1401997031 freq=2402 addr=8e89bed6 delta_t=100.627 ms  
 00 1b cc a5 01 56 d8 a4 02 01 06 11 07 ad 77 00 c6 a0 00 99 b2 e2 11 4c 24 00 4f 0c 96 3b 3e 4b   
 Advertising / AA 8e89bed6 / 27 bytes  
   Channel Index: 37  
   Type: ADV_IND  
   AdvA: a4:d8:56:01:a5:cc (public)  
   AdvData: 02 01 06 11 07 ad 77 00 c6 a0 00 99 b2 e2 11 4c 24 00 4f 0c 96  
     Type 01 (Flags)  
       00000110  
     Type 07 (128-bit Service UUIDs)  
       960c4f00-244c-11e2-b299-00a0c60077ad  
   
   Data: cc a5 01 56 d8 a4 02 01 06 11 07 ad 77 00 c6 a0 00 99 b2 e2 11 4c 24 00 4f 0c 96  
   CRC:  3b 3e 4b  

The BlueScan Android app shows these as:

• Vendor: Qualcomm Labs Inc.
• Desc: FyxBoot

Then after 5 seconds...

Each device starts the following broadcasts.

Device 1 (a4:d8:56:01:75:ce)

 systime=1401999056 freq=2402 addr=8e89bed6 delta_t=417.941 ms  
 42 25 48 36 14 0f c5 10 11 07 ad 77 00 c6 a0 00 99 b2 e2 11 4c 24 93 4a 0c 96 0c ff 8c 00 4e 12 7d 0c 5c 42 59 c1 a2 3a 5f 15   
 Advertising / AA 8e89bed6 / 37 bytes  
   Channel Index: 37  
   Type: ADV_NONCONN_IND  
   Data: 48 36 14 0f c5 10 11 07 ad 77 00 c6 a0 00 99 b2 e2 11 4c 24 93 4a 0c 96 0c ff 8c 00 4e 12 7d 0c 5c 42 59 c1 a2  
   CRC:  3a 5f 15  

Device 2 (a4:d8:56:01:a5:cc)

 systime=1401999005 freq=2402 addr=8e89bed6 delta_t=650.694 ms  
 42 25 d5 1c c9 d5 5c 39 11 07 ad 77 00 c6 a0 00 99 b2 e2 11 4c 24 97 4b 0c 96 0c ff 8c 00 d1 82 94 2c 57 52 4a 6f bc 5a 62 06   
 Advertising / AA 8e89bed6 / 37 bytes  
   Channel Index: 37  
   Type: ADV_NONCONN_IND  
   Data: d5 1c c9 d5 5c 39 11 07 ad 77 00 c6 a0 00 99 b2 e2 11 4c 24 97 4b 0c 96 0c ff 8c 00 d1 82 94 2c 57 52 4a 6f bc  
   CRC:  5a 62 06  

The ADV_NONCONN_IND advertisement is an undirected broadcast that is not connectable, nor is it scanable (i.e. it won't respond to a SCAN_REQ in response to an advertisement).

Analyzing Bluetooth Advertising with Ubertooth

Bluetooth Active Scanning Example

in my last post, Understanding Bluetooth Advertising Packets, I reviewed and consolidated some key elements of advertising packet format and data structure from the Bluetooth Core 4.1 Specification. In this post, I'll review some packets, a relate the specific fields to the spec.

The following packet sequence is between a Fitbit Flex (advertiser) and Bluescan (scanner), on channel 37, using and Ubertooth Bluetooth packet sniffer per this command:

 ubertooth-btle -f  

The three packets below show a complete active scan cycle. The advertiser (Fitbit) send out a ADV_IND advertisement, and the BlueScan Android app responds with a SCAN_REQ packet requesting additional data and the Fitbit responds with a SCAN_RESP.

Fitbit advertisement (ADV_IND):

Below is the first packet captured with Ubertooth:

 systime=1401827476 freq=2402 addr=8e89bed6 delta_t=673.874 ms   
  40 21 eb 12 e6 2d bb f5 02 01 06 11 06 ba 56 89 a6 fa bf a2 bd 01 46 7d 6e ca 36 ab ad 05 16 0a 18 07 04 69 6e 34    
  Advertising / AA 8e89bed6 / 33 bytes   
   Channel Index: 37   
   Type: ADV_IND   
   AdvA: f5:bb:2d:e6:12:eb (random)   
   AdvData: 02 01 06 11 06 ba 56 89 a6 fa bf a2 bd 01 46 7d 6e ca 36 ab ad 05 16 0a 18 07 04   
    Type 01 (Flags)   
     00000110   
    Type 06 (128-bit Service UUIDs, more available)   
     adab36ca-6e7d-4601-bda2-bffaa68956ba   
    Type 16 (Service Data)   
     UUID: 180a, Additional: 07 04   
   Data: eb 12 e6 2d bb f5 02 01 06 11 06 ba 56 89 a6 fa bf a2 bd 01 46 7d 6e ca 36 ab ad 05 16 0a 18 07 04   
   CRC: 69 6e 34   

Some items of note:

1. The Access Address (AA) is 0x8e89bed6 (this number is used to manage Link Layer connections and is a random number, other this this, for non advertising packets).
2. It's on channel 37, which is one of three dedicated advertising channels (37, 38 & 39) of the 40 channels in the Bluetooth spectrum.
3. The packet's PDU type is ADV_IND, which indicates a connectable undirected advertising event with the following properties:
• connectable: a scanner can initiate a connection upon seeing this event.
• scannable: a scanner can issue a scan request up seeing one of these
• undirected: this is broadcast, no Bluetooth address is specified
• payload: can contain user data in payload, whereas a directed packet cannot.
4. AdvA is f5:bb:2d:e6:12:eb, which is the device address of the advertiser. This is a random address, based on...
5. The Type '01' is a flag in the TxAddr field indicating that the AdvA address is random.
6. Type '06' is a GAP profile indicating 'Incomplete List of 128-bit Service Class UUID' defined here, with a UUID provided: adab36ca-6e7d-4601-bda2-bffaa68956ba.
7. Type '16' is also a GAP service type (here) as 'Service Data'. Additional information on this type is defined in the Core Specification Supplement, Part A, section 1.11. For this packet the value is 0x180a which is the UUID for device information.

BlueScan response (SCAN_REQ):

In response the the previous packet, BlueScan responded with this message.

 systime=1401827476 freq=2402 addr=8e89bed6 delta_t=0.336 ms  
 83 0c 55 87 45 0b 22 ac eb 12 e6 2d bb f5 cc 1c fd   
 Advertising / AA 8e89bed6 / 12 bytes  
   Channel Index: 37  
   Type: SCAN_REQ  
   ScanA: ac:22:0b:45:87:55 (public)  
   AdvA: f5:bb:2d:e6:12:eb (random)  
   Data: 55 87 45 0b 22 ac eb 12 e6 2d bb f5  
   CRC:  cc 1c fd  

Some items to note:

1. This packet again uses the advertising channel (37) and Access Address (0x8e89bed6).
2. Scan type is SCAN_REQ.
3. ScanA is the BT_ADDR (Bluetooth Address) of the scanner (BlueScan Android App) and AdvA is the same random IP of the advertiser.

Fitbit response (SCAN_RSP):

Finally, the Fitbit responds with this:

 systime=1401827476 freq=2402 addr=8e89bed6 delta_t=0.326 ms  
 44 0f eb 12 e6 2d bb f5 05 09 46 6c 65 78 02 0a fa b6 c4 52   
 Advertising / AA 8e89bed6 / 15 bytes  
   Channel Index: 37  
   Type: SCAN_RSP  
   AdvA: f5:bb:2d:e6:12:eb (random)  
   ScanRspData: 05 09 46 6c 65 78 02 0a fa  
     Type 09 (Complete Local Name)  
       Flex  
     Type 0a (Tx Power Level)  
       -6 dBm  
   Data: eb 12 e6 2d bb f5 05 09 46 6c 65 78 02 0a fa  
   CRC:  b6 c4 52  

Note:

• Type '0a'  and '09' flags are assigned numbers designated by the Bluetooth SIG Generic Access Profile, indicating what the Ubertooth output shows: 'Complete Local Name' and 'Tx Power Level' respectively.

Analyzing Gimbal Advertisements

Next, I'll have a look at Gimbals iBeacon advertisements. These use random address as a privacy mechanism, so it's worth having a look at those.

Understanding Bluetooth Advertising Packets

Bluetooth Advertising

UPDATE (Dec. 7, 2014): I am interested in understanding how my Bluetooth scanning Android app, Bluescan could be used to help with your Bluetooth efforts. Please email me at j2abro@gmail.com if you have any feedback or ideas on how I can improve that app in ways that would be useful for you.

This post looks at Bluetooth Low Energy (BLE) advertising packet format and then shows some sample packets captured using an Ubertooth Bluetooth packet sniffer. First we'll look at the packet format and then look at some packets. In a future post I'll compare the captured packets to the format shown here.

Bluetooth Link Layer Packet Format

Packets in BLE are defined in the Link Layer. There is only one packet format for BLE as shown below.

BLE Packet Structure

Attributes

A packet can be 80 to 376 bits in length, and has the following components.

• Preamble: used for internal protocol management. Advertising packets have 10101010b as the preamble.

• Access Address: This is always 0x8E89BED6 (10001110100010011011111011010110b)for advertising packets.

• PDU: There are two PDU formats, one for advertising packets and one for data packets.

• CRC: 3 byte value calculated over PDU.

Bluetooth LE Advertising Channel PDU

There are only two PDU formats in BLE, one for data packets and one for advertising - shown below. Here is the GitHub Gist for the blockdiag diagram. The type of packet is determined by the channel on which the packet is transmitted. Advertising channels are 37, 38, and 39.

Advertising Channel PDU

Attributes

• PDU Type: See more info below.
• RFU: Reserved for future use
• TxAdd, RxAdd: These are defined for each individual advertising channel, but their purpose is not clear to me.
• Length: Payload length in bytes. Valid range is 6 to 37 bytes.

PDU Types

These are the PDU types; the first four are advertising channel types:

• ADV_IND (0000): Connectable undirected advertising, has the following payload:
• AdvA (6 bytes): Advertisers public or random device address. TxAdd indicates if the address is public or random.
• TxAdd = 0 advertiser address is public
• TxAdd = 1 advertiser address is random address
• AdvData (0-31 bytes): Optional advertising data from advertiser
• ADV_DIRECT_IND (0001): Connectable directed advertising. Directed advertising is used when a device needs to quickly connect to another device. An initiating device immediately sends a connection request upon receiving this. This PDU has the following payload.
• AdvA (6 bytes): Advertisers address. TxAdd indicates if the address is public or random.
• TxAdd = 0 advertiser address is public
• TxAdd = 1 advertiser address is random address
• InitA (6 bytes): Initiator address. RxAdd in PDU indicates the address type:
• RxAdd = 0 initiator address is public
• RxAdd = 1 initiator address is random address
• ADV_NONCONN_IND (0010): Non connectable undirected advertising. Used by devices that want to broadcast and don't want to be connected to or scannable. This is the only option for a device that is only a transmitter.
• AdvA (6 bytes): Advertisers public or random device address. TxAdd indicates if the address is public or random.
• TxAdd = 0 advertiser address is public
• TxAdd = 1 advertiser address is random address
• AdvData (0-31 bytes): Optional advertising data from advertiser
• ADV_SCAN_IDN (0110): (formerly called ADV_DISCOVER_IND) Scannable undirected advertising.
• AdvA (6 bytes): Advertisers public or random device address. TxAdd indicates if the address is public or random.
• TxAdd = 0 advertiser address is public
• TxAdd = 1 advertiser address is random address
• AdvData (0-31 bytes): Optional advertising data from advertiser

While not specifically an advertising PDU type, active scanning will involve the following additional types:

• SCAN_REQ (0011): Upon receiving and advertising packet and active scanner will issue this scan request packet, with the following payload.
• ScanA (6 bytes): Scanner address.TxAdd indicates if the address is public or random.
• TxAdd = 0 advertiser address is public
• TxAdd = 1 advertiser address is random address
• AdvA (6 bytes): Device to which this PDU is addressed. RxAdd in PDU indicates the address type:
• RxAdd = 0 initiator address is public
• RxAdd = 1 initiator address is random address
• SCAN_RSP (0100): Upon receiving a scan request (SCAN_REQ) packet and advertiser can respond with this.
• AdvA (6 bytes): Advertiser address.TxAdd indicates if the address is public or random.
• TxAdd = 0 advertiser address is public
• TxAdd = 1 advertiser address is random address
• ScanResponseData (0-31 bytes): Optional advertising data from advertiser
• Length: Length of response data
• CONNECT_REQ (0101): Connection request

Sample packets

Now lets look at some packet captures.

Using Ubertooth to capture Bluetooth packets, I was finally able to really visualize what was happening in my BlueScan Android scanner.  Below shows a dump from Ubertooth using the device connected to a Mac laptop as with the -f option to follow a connection:

 ubertooth-btle -f  

To capture data from another channel, the -A flag is used. On my installation, I had to take the Ubertooth out of  the USB slot for this to have an affect. Then this worked.

 ubertooth-btle -f -A 39

The following packet sequence is between a Fitbit Flex (advertiser) and Bluescan (scanner), on channel 37.

Fitbit advertisement (ADV_IND):

 systime=1401827476 freq=2402 addr=8e89bed6 delta_t=673.874 ms  
 40 21 eb 12 e6 2d bb f5 02 01 06 11 06 ba 56 89 a6 fa bf a2 bd 01 46 7d 6e ca 36 ab ad 05 16 0a 18 07 04 69 6e 34   
 Advertising / AA 8e89bed6 / 33 bytes  
   Channel Index: 37  
   Type: ADV_IND  
   AdvA: f5:bb:2d:e6:12:eb (random)  
   AdvData: 02 01 06 11 06 ba 56 89 a6 fa bf a2 bd 01 46 7d 6e ca 36 ab ad 05 16 0a 18 07 04  
     Type 01 (Flags)  
       00000110  
     Type 06 (128-bit Service UUIDs, more available)  
       adab36ca-6e7d-4601-bda2-bffaa68956ba  
     Type 16 (Service Data)  
       UUID: 180a, Additional: 07 04  
   Data: eb 12 e6 2d bb f5 02 01 06 11 06 ba 56 89 a6 fa bf a2 bd 01 46 7d 6e ca 36 ab ad 05 16 0a 18 07 04  
   CRC:  69 6e 34  

In this captures, we are listening on Channel 37 which is the default.

BlueScan response (SCAN_REQ):

 systime=1401827476 freq=2402 addr=8e89bed6 delta_t=0.336 ms  
 83 0c 55 87 45 0b 22 ac eb 12 e6 2d bb f5 cc 1c fd   
 Advertising / AA 8e89bed6 / 12 bytes  
   Channel Index: 37  
   Type: SCAN_REQ  
   ScanA: ac:22:0b:45:87:55 (public)  
   AdvA: f5:bb:2d:e6:12:eb (random)  
   Data: 55 87 45 0b 22 ac eb 12 e6 2d bb f5  
   CRC:  cc 1c fd  

Fitbit response (SCAN_RSP):

 systime=1401827476 freq=2402 addr=8e89bed6 delta_t=0.326 ms  
 44 0f eb 12 e6 2d bb f5 05 09 46 6c 65 78 02 0a fa b6 c4 52   
 Advertising / AA 8e89bed6 / 15 bytes  
   Channel Index: 37  
   Type: SCAN_RSP  
   AdvA: f5:bb:2d:e6:12:eb (random)  
   ScanRspData: 05 09 46 6c 65 78 02 0a fa  
     Type 09 (Complete Local Name)  
       Flex  
     Type 0a (Tx Power Level)  
       -6 dBm  
   Data: eb 12 e6 2d bb f5 05 09 46 6c 65 78 02 0a fa  
   CRC:  b6 c4 52  

For more info, I suggest to Core spec:

Bluetooth Specification Version 4.1, [Volume 6] Link Layer Specification.
(Page 2,506 of the specification, is a start)

Analyzing Packets

Next, we'll analyze some packets and compare them to the documented format.

UPDATE (Dec. 7, 2014): I am interested in understanding how my Bluetooth scanning Android app, Bluescan could be used to help with your Bluetooth efforts. Please email me at j2abro@gmail.com if you have any feedback or ideas on how I can improve that app in ways that would be useful for you.