periodic_adv_conn & BLE MESH

[joey]

HI

I am using the nRF54L15. Is it possible to integrate BLE Mesh functionality into the periodic_adv_conn example? This would allow the device to both receive data reported from a periodic_sync_connnode and route data with other periodic_adv_connnodes for data relaying and uploading.

Thanks!

[Hung Bui]

Hi CRM, 
I don't see a problem having mesh and PaWR running at the same time. We do have example doing normal BLE and mesh (ble_peripheral_lbs_coex). I think you should be able to base on that sample add change normal BLE to PaWR. 
The question here is what you want to do with the mesh network ? Do you need both PaWR and Mesh ? 
If you already have Mesh network, you can broadcast message into the network similar way how PaWR advertiser doing it. 
And vice versa, if they are all in the same range of the advertiser, you can transmit data via PaWR without the need or a mesh network.  

[joey]

I have a large number of tags distributed across different areas. Each tag sends one piece of data every hour, and each piece of data is approximately 60 bytes at the application layer.

I want to use PAwR combined with MESH nodes as routers, where PAwR receives and manages the data from the tags, and then forwards this data to a more distant PC end through MESH networking. Therefore, I need nodes that operate in this mode. For this kind of model, which is more suitable: PAwR + Bluetooth Mesh or PAwR + Zigbee?

[joey]

Hung Bui said:

Please give the exact number of byte to be transmitted from PAwR advertiser to PC and the interval so that we can calculate the throughput.

1. The transmission from the PAWR advertiser to the PC is primarily concentrated at the top of each hour (00:00, 01:00, ..., 11:00) in a cyclical pattern. This is because PAWR scanners report data to the PAWR advertiser at these fixed hourly intervals. The PAWR advertiser caches the received data and then, at the application layer, packages and forwards 70-byte data packets to the PC-side node every 300ms until all cached data is cleared. Outside of these hourly reporting windows, there might be occasional retransmissions from a small number of scanners that failed to report successfully during their scheduled hourly slots.

   Hung Bui said:

   I assume with distance 50-100m they are in light of sight with no obstruction, correct ? 

2. There are some indoor columns present, but overall the environment is predominantly open and unobstructed.

• Hung Bui said:

  You can use the broadcast from the PAwR to send confirmation. Or you can also establish a connection to each and every scanner to send/receive data (Connection 2.0 with PAwR). It's also possible to do so with normal BLE connection, if the communication is only once in an hour, I don't see a problem establish a connection to transfer little amount of data and then disconnect again. 

I'm currently using S8 coding which provides relatively slow data rates. If I establish a connection to send reply messages, would this interfere with the timing slots and also increase power consumption? Instead of establishing connections or using broadcast transmissions, is it feasible for the advertiser to directly reply to the scanner within the same time slot when the scanner is reporting its data?

[Hung Bui]

Hi, 

joey said:

The transmission from the PAWR advertiser to the PC is primarily concentrated at the top of each hour (00:00, 01:00, ..., 11:00) in a cyclical pattern. This is because PAWR scanners report data to the PAWR advertiser at these fixed hourly intervals. The PAWR advertiser caches the received data and then, at the application layer, packages and forwards 70-byte data packets to the PC-side node every 300ms until all cached data is cleared. Outside of these hourly reporting windows, there might be occasional retransmissions from a small number of scanners that failed to report successfully during their scheduled hourly slots.

Please correct me if I'm wrong, so it's 70bytes/scanner/hour, correct ? How many scanner each PAwR advertiser handles  ?

joey said:

I'm currently using S8 coding which provides relatively slow data rates. If I establish a connection to send reply messages, would this interfere with the timing slots and also increase power consumption? Instead of establishing connections or using broadcast transmissions, is it feasible for the advertiser to directly reply to the scanner within the same time slot when the scanner is reporting its data?

No as far as I know the advertiser will have to use the next periodic advertising packet to send the confirmation back. 
Note that the connection v2 can be established when the PAwR advertiser continue to do periodic advertising (it's part of the PAwR specification). If you choose a connection interval matches with the subevent interval there will be less chance of scheduling conflict. With the rate of transmitting once per hour , I don't see a problem). 

[joey]

Hung Bui said:

Please correct me if I'm wrong, so it's 70bytes/scanner/hour, correct ? How many scanner each PAwR advertiser handles  ?

That's essentially correct. However, the 70 bytes refer to the data generated at the application layer, not the data after Bluetooth protocol encapsulation. Upon receiving and parsing out these 70 bytes, the advertiser forwards them directly without any processing. Each advertiser has approximately 500 nodes

Hung Bui said:

No as far as I know the advertiser will have to use the next periodic advertising packet to send the confirmation back. 
Note that the connection v2 can be established when the PAwR advertiser continue to do periodic advertising (it's part of the PAwR specification). If you choose a connection interval matches with the subevent interval there will be less chance of scheduling conflict. With the rate of transmitting once per hour , I don't see a problem). 

So, is it feasible to establish a connection as long as the response slot is set with an appropriate interval?​

[Hung Bui]

Hi, 

joey said:

So, is it feasible to establish a connection as long as the response slot is set with an appropriate interval

Yes, in that case it will not disturb the periodic advertising activity. I made a blog here a while ago, this could be useful for you: 
Periodic Advertising with Responses (PAwR): A practical guide
Connection v2 is touched briefly at section 3.3 

[joey]

joey said:

That's essentially correct. However, the 70 bytes refer to the data generated at the application layer, not the data after Bluetooth protocol encapsulation. Upon receiving and parsing out these 70 bytes, the advertiser forwards them directly without any processing. Each advertiser has approximately 500 nodes

Regarding the BLE+Zigbee solution, what are the evaluation conclusions?

Hung Bui said:

Yes, in that case it will not disturb the periodic advertising activity. I made a blog here a while ago, this could be useful for you: 
Periodic Advertising with Responses (PAwR): A practical guide
Connection v2 is touched briefly at section 3.3 

Thanks, I'll try it.​

[Hung Bui]

Hi, 

joey said:

Regarding the BLE+Zigbee solution, what are the evaluation conclusions?

Could you explain what you meant ? It's at production level as far as I know. Most of our Matter samples have BLE + Thread (802.15.4) support. 

[joey]

Hung Bui said:

Please give the exact number of byte to be transmitted from PAwR advertiser to PC and the interval so that we can calculate the throughput.

you mentioned earlier that you need my data reporting status to assess whether the Zigbee throughput is suitable for this type of application

[Hung Bui]

Hi, 
Yes but your throughput is really low as far as I understand. 
You are talking about 70 bytes * 500 nodes / hours = 9.7 bytes/s It should be fine with both Bluetooth mesh and Zigbee. 

[joey]

Thanks, According to your calculations, what is the maximum throughput limit for Zigbee or BLE Mesh?

[Hung Bui]

Hi, 
The generic numbers (it depends a lot on how many nodes in the network, how large the data packet is) for Zigbee is 20kbps-120kbps. When for Bluetooth mesh it much lower, at around 3-4kbps with one hop.