BLE proxy: Difference between revisions

From UNamur InfoSec
Jump to navigation Jump to search
No edit summary
 
Line 1: Line 1:
== Architecture ==
==Architecture==
 
[[File:ble_proxy_architecture_sc.png]]
 
There are 5 components: The web server, cache server, MQTT Broker, BLE Proxy Module on RPi, BLE Device (Node)
#The web server handler user request, and send back resonse with data.
#Cache server subscribe to BLE Proxy message by connecting to MQTT Broker, And store the message or data as cache, So that the web server can access those data anytime user request.
#MQTT Broker is a module that relay message between BLE Proxy and Cache server
#BLE Proxy module is used to communicate with BLE Device and send device's message from and to Cache server via MQTT Broker.
#BLE Device is end-device that equip with sensors to collection data and send those data to BLE proxy on RPi with Bluetooth Low Energy Protocol.


== Uplink ==
== Uplink ==


== Downlink ==
*Message flow:
#BLE Device broadcast their sensor data in GAP mode.
#BLE Module on Raspberry Pi scan advertise data, analysis the data, extract sensor value, and finally send those sensor data over MQTT broker.
#On the web server, we have a cache server that is connected to MQTT Broker on Raspberry Pi. When the BLE Module on RPi publish the message.
The cache server store those message inside their cache database.
#User can then make a request to the web server. The web server reads the sensor value from those cache database, and form the response based on those sensor value.
 
*Message structure from BLE Proxy module via MQTT:
topic:
payload: {
  "mac": "<mac-addr>",
  "sensors": [{"id": "<id>", "value":"<value>"}]
}
 
*Broadcast message from BLE device:
We use the first byte of data to indicate the id of the sensor, for example:
01 50 55
#The first byte 01 is the id of the sensor
#The rest 50 55 is the sensor 01's data value
More information about GAP data is available at this wiki: [https://doc.info.fundp.ac.be/mediawiki/index.php/GAP_Bluetooth_Low_Energy GAP] and [https://doc.info.fundp.ac.be/mediawiki/index.php/Custom_GAP_advertising_packet Custom GAP]
 
 
==Downlink==
 
*Message flow:
#User send downlink request to web server.
#Web server publish message request to cacher server.
#Cache server publish request to MQTT Broker.
#BLE Proxy receive downlink message through MQTT Broker subscription, Extract downlink mac address, connect to BLE Device, write downlink message.
#BLE Device once connected will handle the message wrote by the BLE Proxy module, And response to the message (For example: turn on LED).
*Message structure from user via HTTP:
url POST request: /api/devices/{id}/downlink
body: {
"sensors": [{
"id": "<sensor_id>"
"payload": "<value>"
}]
}
 
*Message structure from MQTT Broker for BLE proxy:
topic: ble/<mac>/down
payload: {
  "sensors": [{
    "id": "<id>",
"value": "<value>"
  }]
}
 
*Message structure form BLE proxy to BLE device:
Once BLE proxy connected to BLE device, BLE proxy will extract the message from MQTT, write message to BLE device via Nordic's UART Service RX characteristic.
The start of the message is sensor id, and the rest is value, if there are multiple sensors, The BLE proxy write them one by one.
For example: the write 01 to sensor id=5, message would be:
05 01

Latest revision as of 20:23, 20 December 2017

Architecture

Ble proxy architecture sc.png

There are 5 components: The web server, cache server, MQTT Broker, BLE Proxy Module on RPi, BLE Device (Node)

  1. The web server handler user request, and send back resonse with data.
  2. Cache server subscribe to BLE Proxy message by connecting to MQTT Broker, And store the message or data as cache, So that the web server can access those data anytime user request.
  3. MQTT Broker is a module that relay message between BLE Proxy and Cache server
  4. BLE Proxy module is used to communicate with BLE Device and send device's message from and to Cache server via MQTT Broker.
  5. BLE Device is end-device that equip with sensors to collection data and send those data to BLE proxy on RPi with Bluetooth Low Energy Protocol.

Uplink

  • Message flow:
  1. BLE Device broadcast their sensor data in GAP mode.
  2. BLE Module on Raspberry Pi scan advertise data, analysis the data, extract sensor value, and finally send those sensor data over MQTT broker.
  3. On the web server, we have a cache server that is connected to MQTT Broker on Raspberry Pi. When the BLE Module on RPi publish the message.

The cache server store those message inside their cache database.

  1. User can then make a request to the web server. The web server reads the sensor value from those cache database, and form the response based on those sensor value.
  • Message structure from BLE Proxy module via MQTT:
topic: 
payload: {
  "mac": "<mac-addr>",
  "sensors": [{"id": "<id>", "value":"<value>"}]
}
  • Broadcast message from BLE device:

We use the first byte of data to indicate the id of the sensor, for example:

01 50 55
  1. The first byte 01 is the id of the sensor
  2. The rest 50 55 is the sensor 01's data value

More information about GAP data is available at this wiki: GAP and Custom GAP


Downlink

  • Message flow:
  1. User send downlink request to web server.
  2. Web server publish message request to cacher server.
  3. Cache server publish request to MQTT Broker.
  4. BLE Proxy receive downlink message through MQTT Broker subscription, Extract downlink mac address, connect to BLE Device, write downlink message.
  5. BLE Device once connected will handle the message wrote by the BLE Proxy module, And response to the message (For example: turn on LED).
  • Message structure from user via HTTP:
url POST request: /api/devices/{id}/downlink
body: {
	"sensors": [{
		"id": "<sensor_id>"
		"payload": "<value>"
	}]
}
  • Message structure from MQTT Broker for BLE proxy:
topic: ble/<mac>/down
payload: {
 "sensors": [{
   "id": "<id>",

"value": "<value>"

 }]
}
  • Message structure form BLE proxy to BLE device:

Once BLE proxy connected to BLE device, BLE proxy will extract the message from MQTT, write message to BLE device via Nordic's UART Service RX characteristic. The start of the message is sensor id, and the rest is value, if there are multiple sensors, The BLE proxy write them one by one. For example: the write 01 to sensor id=5, message would be:

05 01