How to improve throughput in a 3-node relay system

Hi,
I’m currently working on a setup with three nodes:

  • Node A: collects data

  • Node B: acts as a relay, forwarding data

  • Node C: processes the data and then sends the result back to Node B

The basic communication flow (A → B → C, and C → B) is already working correctly.

Now I am testing the throughput of the whole system, but I only get around 40 kbps.

Is there any recommended way to improve the throughput in this kind of multi-hop relay system? For example, parameters I should tune, or other techniques that could help boost the data rate?

Thanks in advance for any suggestions!

Parents
  • Hi,

    Since the proper setup depends on technology, please share what wireless technology you are using for the network, and describe the setup.

    If for instance you use normal Bluetooth LE connections, then the best approach would be to have the relay (B) be central, and the other nodes (A and C) be peripherals. The reason for this is that with Bluetooth LE, the timing follows the clock of the central. If you have devices communicating with different centrals, or both as central and peripheral, then there will be packet collisions or event overlaps between the different connections. If there is only one central, then events will be scheduled without overlap if possible. Further, if you use long connection events, then you might see lower throughput due to packet loss (long connection events are aborted on the first packet loss of the event.) Similarly, if the connection interval is large, there will be fewer packets sent and therefore lower throughput. 40 kbps is extremely low for BLE, though, so if you are using BLE, please share the setup (which devices have which roles) and connection parameters.

    Regards,
    Terje

  • Hi,

    Here is more detailed information:

    Wireless tech: Bluetooth Low Energy using Nordic UART Service (NUS).

    Roles / topology (3 nodes):

    • Node A = Peripheral

    • Node B = both Central & Peripheral (relay: A to B as Central, B to C as Peripheral)

    • Node C = Central (processes data received from B, then sends result back to B)

    Link roles explicitly:

    • Link #1 (A→B): A=Peripheral, B=Central

    • Link #2 (B and C): B=Peripheral, C=Central

    Connection parameters (both links):

    • Connection interval: 400 ms (interval_min = interval_max = 320 * 1.25 ms)

    • Supervision timeout: 4 s (400)

    • PHY: 2M requested on both links (bt_conn_le_phy_update to 2M)

    • MTU: I call GATT MTU exchange on connect. (No custom max MTU set beyond Zephyr defaults.)

    Would restructuring to one central only (B as the sole central, with A and C both as peripherals) help scheduling and throughput as you suggested?

Reply
  • Hi,

    Here is more detailed information:

    Wireless tech: Bluetooth Low Energy using Nordic UART Service (NUS).

    Roles / topology (3 nodes):

    • Node A = Peripheral

    • Node B = both Central & Peripheral (relay: A to B as Central, B to C as Peripheral)

    • Node C = Central (processes data received from B, then sends result back to B)

    Link roles explicitly:

    • Link #1 (A→B): A=Peripheral, B=Central

    • Link #2 (B and C): B=Peripheral, C=Central

    Connection parameters (both links):

    • Connection interval: 400 ms (interval_min = interval_max = 320 * 1.25 ms)

    • Supervision timeout: 4 s (400)

    • PHY: 2M requested on both links (bt_conn_le_phy_update to 2M)

    • MTU: I call GATT MTU exchange on connect. (No custom max MTU set beyond Zephyr defaults.)

    Would restructuring to one central only (B as the sole central, with A and C both as peripherals) help scheduling and throughput as you suggested?

Children
  • Hi,

    The relatively high connection interval of 400 ms might be the reason why you get low throughput. Even if you have set long event length (you did not tell what configuration you have for that), then if any packet is lost during one connection event, the connection event ends and no further packets are sent. Therefore, a shorter connection interval (which also may give shorter event lengths) will often provide better reliability.

    Restructuring to one central only could also help, yes, but I recommend trying shorter connection intervals first.

    Regards,
    Terje

Related