BLE embedded network architecture organization

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hello to all.

   

Please find attached the image that show architecture of the embedded system I'm working on.

   

As it can be seen there is one main embedded device (Hub) and a number of peripheral embedded devices. Number of mobile phones with installed application can communicate with the main embedded device, but there is no need to support simultaneously more than one connection with the mobile phones. Minimal setup will be one main device, two peripheral and one mobile phone. But user can add new peripheral device whenever he wants. I still don't know the maximum number of the devices, but lets say up to four peripheral devices.

   

Here are some observations that could help design the best architecture for this small BLE network that I want to design:

   
        
  • All embedded devices should spend as little power as possible 🙂
  •     
  • All embedded devices have CYBLE-022001-00 module on them.
  •     
  • Mobile App should connect only to the Hub. Application will be written for both iPhone and Android devices.
  •     
  • Only the Hub should be able to connect to the peripheral devices.
  •     
  • Peripheral devices have no need to speak to one another. All communication goes through Hub (this can be changed if better solution exists).
  •     
  • Only the user that bought the devices should be able to securely connect to the Hub (I guess some password mechanism).
  •     
  • Peripheral embedded devices have sensors and buttons. In case that someone presses the button they need to notify the Hub. Hub then can initiate communication with them or with another peripheral embedded device and return some values. Hub also has a button. If someone presses it, he needs to establish communication with some of the peripheral devices (maybe all of them). User can via mobile App request something from Hub. Hub in return may look for that info from one of the peripheral devices.
  •     
  • Hub must know that peripheral devices are alive and present. If they are not, he triggers the alarm sound. He should check that for about 10 times in a second.
  •    
   

Questions/Proposals:

   
        
  • Let's say mobile phone app plays BLE Central role.
  •     
  • Peripheral devices will sometimes be Broadcasters (when they say I'm here, I'm here..., Connect with me ASAP Connect with me ASAP...). I don't want to broadcast sensitive information into the air, that's way I would like to do it when connected with Hub. Does this make sense? And sometimes peripheral devices will be Peripherals (to enable Hub to connect to them).
  •     
  • Hub obviously sometimes needs to be Central (when he needs to establish a connection with the peripherals) and sometime needs to be Peripheral (when user via mobile phone application wants to connect to it).     
            
    • Mobile phone can connect to the Hub, only when Hub advertises. When he is connected to the peripheral device then user can't connect to it, right?
    •       
    • If the Hub is connected to the mobile phone app, can it then listen to peripherals who are broadcasting?
    •       
    • As I see it, if the mobile app is central, and Hub breaks the connection (if he can do it) in order to connect ot some alarming peripheral devices, later on Hub can no longer initiate the connection with the mobile app. Or he can maybe also advertise You can connect with me, You can connect with me... Or the mobile app could be programmed that whenever it sees the Hub, it will automatically connect to it.
    •      
  •     
  • What kind of mechanism to use to switch Hub from Central to Peripheral. Maybe App should play Peripheral BLE role? 
  •     
  • Could adding new peripherals into the system be made automatic, i.e. that Hub recognize new device and start communicate with it, without the user intervention i.e. so that user doesn't need to initiate some kind of pairing mechanism.
  •     
  • Can BLE whitelist concept be utilized here? I guess peripheral devices should whitelist the Hub and allow only him to connect to them. When do you put the device in the whitelist?
  •     
  • Hub is definitely the bottleneck here. How to setup him the best?
  •    
   

Obviously, I don't have experience with the design of wireless networks. Can any of you guys share their thoughts on this. I would appreciate that much. Be free to ask any question and make any suggestion.

   

Thanks,

   

Vojislav

0 Likes
1 Solution
Anonymous
Not applicable

Thoughts:

   

Since you are trying to minimize power consumption overall (I assume the peripherals and hub are all battery powered), you're best bet for saving power would be to setup the hub as a peripheral "advertising" device, with the peripherals attempting to connect to it when they have new information, or on a "timed basis" if you want them to check in periodically. This would reduce the advertising power from all peripherals, to just the hub device. You would then setup the mobile app to connect, read new data, then disconnect on a polling basis as well to allow the peripherals to update their data to the hub in "real-time". 

   

With this method, you could allow the hub to be the device that whitelists all of the peripherals, only allowing a new device to connect when it has been told to "add new peripheral" by the mobile app. (Otherwise, it would filter with the whitelist to only allow the vetted peripherals to connect). Also, it would allow the central device to only allow the mobile app it has been setup to connect with to get data from it.

   

Only one device can be connected to the hub at a time; Sad limitation of bluetooth from what I've seen 😞

   

Switching between central and peripheral can be setup in the firmware/software code to change based on internal state machines.

   

Although adding the new peripherals could be automatic, it would allow anyone with a device configured to look like a peripheral to add their device to the hub-network. This would allow anyone to create their own peripheral, have it become listed in the hub's list, and then be able to interact with whatever code you have running on the central hub.

   

With the peripheral devices set to initiate connections, they would be invisible to RF until they attempt connection with the central hub, at which point they would only connect to the address they are trying to connect  to.

   

Since you are effectively using the hub as a database to store then pass along data to the mobile app on command, having the hub be the "peripheral" side of the connection allows the mobile app to just update it's values from the hub on a timed basis.

   

With this method, you would need dynamic timing to keep track of how long it has been since the last peripheral device check-in, but that would just be some clever software writing 🙂

   

To sum up:

   

You could set the hub to peripheral/advertising, and all other devices to central to connect to it to update/read data;

   

You could switch the hub between central/peripheral to check the other peripherals and to allow the central(phone) to connect; (peripherals can request disconnect, but I'm not sure how it is handled hardware-wise).

   

Only one device can be connected to another device at a time.

   

Not sure if you can listen to advertisements while connected.

   

Central/Peripheral configuration can be changed with software code on the device.

   

Automatic peripheral adding would be up to you to setup a secure method, as it depends on what implementation you decide on, and how secure the peripheral needs to be.

   

Whitelist concept can be automatic for both scanning and connecting. Normally, you add the device into a whitelist when you have verified it's identity.

   

For the "best" method to setup the hub, it depends on what tradeoffs you want to make between power, connectivity, ease of use, security, etc. since most security will reduce power/connectivity, and most ease-of-use will reduce security, etc.

View solution in original post

0 Likes
1 Reply
Anonymous
Not applicable

Thoughts:

   

Since you are trying to minimize power consumption overall (I assume the peripherals and hub are all battery powered), you're best bet for saving power would be to setup the hub as a peripheral "advertising" device, with the peripherals attempting to connect to it when they have new information, or on a "timed basis" if you want them to check in periodically. This would reduce the advertising power from all peripherals, to just the hub device. You would then setup the mobile app to connect, read new data, then disconnect on a polling basis as well to allow the peripherals to update their data to the hub in "real-time". 

   

With this method, you could allow the hub to be the device that whitelists all of the peripherals, only allowing a new device to connect when it has been told to "add new peripheral" by the mobile app. (Otherwise, it would filter with the whitelist to only allow the vetted peripherals to connect). Also, it would allow the central device to only allow the mobile app it has been setup to connect with to get data from it.

   

Only one device can be connected to the hub at a time; Sad limitation of bluetooth from what I've seen 😞

   

Switching between central and peripheral can be setup in the firmware/software code to change based on internal state machines.

   

Although adding the new peripherals could be automatic, it would allow anyone with a device configured to look like a peripheral to add their device to the hub-network. This would allow anyone to create their own peripheral, have it become listed in the hub's list, and then be able to interact with whatever code you have running on the central hub.

   

With the peripheral devices set to initiate connections, they would be invisible to RF until they attempt connection with the central hub, at which point they would only connect to the address they are trying to connect  to.

   

Since you are effectively using the hub as a database to store then pass along data to the mobile app on command, having the hub be the "peripheral" side of the connection allows the mobile app to just update it's values from the hub on a timed basis.

   

With this method, you would need dynamic timing to keep track of how long it has been since the last peripheral device check-in, but that would just be some clever software writing 🙂

   

To sum up:

   

You could set the hub to peripheral/advertising, and all other devices to central to connect to it to update/read data;

   

You could switch the hub between central/peripheral to check the other peripherals and to allow the central(phone) to connect; (peripherals can request disconnect, but I'm not sure how it is handled hardware-wise).

   

Only one device can be connected to another device at a time.

   

Not sure if you can listen to advertisements while connected.

   

Central/Peripheral configuration can be changed with software code on the device.

   

Automatic peripheral adding would be up to you to setup a secure method, as it depends on what implementation you decide on, and how secure the peripheral needs to be.

   

Whitelist concept can be automatic for both scanning and connecting. Normally, you add the device into a whitelist when you have verified it's identity.

   

For the "best" method to setup the hub, it depends on what tradeoffs you want to make between power, connectivity, ease of use, security, etc. since most security will reduce power/connectivity, and most ease-of-use will reduce security, etc.

0 Likes