FOTA FOR THE NODE/ADVERTISER

[Rachita Reddy]

Here is a clearer, professional version you can use for the Nordic support ticket:

Subject: Query Regarding Multiple Node OTA Updates Through a Gateway Using BLE SMP

Hi Nordic Team,

I am currently working on OTA firmware updates for our BLE cattle nodes. The architecture is as follows:

• The node acts as a BLE advertiser/scanner device and does not have direct access to the cloud/server.

• The gateway acts as the BLE scanner and also communicates with the cloud/server.

• When an OTA update is triggered, the gateway receives the node firmware from the server/cloud.

• The gateway downloads and stores the firmware in its external flash memory.

• The gateway then switches its BLE architecture to connectable mode and sends an OTA trigger to the specific node.

• The node connects to the gateway using BLE.

• The gateway transfers the firmware to the node using BLE SMP/MCUmgr.

• The node then performs the firmware update.

Currently, we are able to perform this OTA flow for a single node.

My question is:

Can the gateway perform OTA updates for multiple nodes simultaneously or in parallel using BLE SMP/MCUmgr?

For example, if the gateway has firmware updates for 5–10 nodes, can it establish BLE connections with multiple nodes and transfer the firmware to all of them concurrently?

If simultaneous OTA is supported, I would also like to understand:

1. Is it possible to maintain multiple BLE connections from the gateway while performing SMP transfers?

2. Are there any limitations on the maximum number of concurrent SMP connections?

3. Does the Nordic BLE stack/SoftDevice Controller support multiple concurrent SMP sessions for this use case?

4. What would be the recommended architecture for handling multiple node OTA updates through a single gateway?

5. Are there any limitations related to BLE connection intervals, memory/RAM, MTU, throughput, or SMP buffering when performing multiple OTA transfers?

6. Would you recommend performing the OTA updates truly in parallel, or scheduling the nodes sequentially through the gateway?

Our main requirement is to update multiple BLE nodes from a single gateway without requiring each node to have direct cloud connectivity.

Please let us know if this architecture is supported and whether there are any Nordic-recommended examples or reference implementations for this use case.

Thanks,
Rachita
Firmware Engineer
Vanix Technologies

[Vidar Berg]

Hello,

I don't know how you've implemented the SMP client role, but it is technically possible to perform DFU on multiple targets in parallel. However, first I would consider what the real benefit would be of doing this. In addition to the increase complexity, the total time to update all nodes may actually increase, since more concurrent connections leave less on-air time per link and cause more scheduling conflicts.

Also in case it is relevant, we just updated this sample on the main branch to support DFU (single connection only):

https://nrfconnectdocs.nordicsemi.com/ncs/latest/nrf/samples/bluetooth/central_smp_client/README.html

Best regards,

Vidar

[Rachita Reddy]

ARE YOU TELLING IT IS NOT ADVISBLE TO DO THE OTA LIKE THIS ? AND IF YOU NEED ANY SOURCE CODE HOW I  HAVE IMPLEMNTED I CAN SHARE THAT TO  

[Vidar Berg]

I'm suggesting that it may be better to update one node at a time which you are doing already instead of requiring multiple nodes to be updated at the same time. It is perfectly fine to use SMP to transfer FW updates from your gateway to your nodes, this is also what the sample I linked earlier demonstrates.

[Rachita Reddy]

HEY WE  CAN HAVE A MEETING ONE ON ONE PROPER I HAVE SO MANY QUESTIONS WITH RESPECT TO THIS 

[Vidar Berg]

Could you help clarify the actual requirements and challenges? From your original post, I understand that you can update one node at a time, but you'd like to know whether it's possible to update multiple nodes concurrently. Is that correct? If so, could you tell me a bit more about why the updates need to be done concurrently?

[Gaurav Kapoor]

Vidar we have taken it up locally , lets close this here