Directly modify Link Layer packet

RE: Directly modify Link Layer packet

LucosidE — Sun, 29 Mar 2020 23:41:36 GMT

Never mind, it works as expected, I realized in my switch statement I used NRF_LOG_DEBUG but my LOG_LEVEL was 3.

RE: Directly modify Link Layer packet

LucosidE — Sun, 29 Mar 2020 22:47:00 GMT

Thank Kenneth,

I am getting a little bit closer to the setup mentioned above. I think now I am having trouble understanding the SDK. I have a 52833DK trying to set up an L2CAP channel with 52840 Dongle which is running the peripheral blinky app. I am simply using the blinky app since I can try to set up an L2CAP channel after connection is established. I also have a 52840DK acting as a sniffer.

My code works as follows, the 52833 scans for device named "BLINKY" and connects to it. This part works.

When BLE_GAP_EVT_CONNECTED is triggered on the 52833 I call sd_ble_l2cap_ch_setup with same params as the OTS example. At this point I can see in wireshark that everything is as I expect.

No.	Time	Source	PHY	Protocol	Length	Delta time (µs end to start)	SN	NESN	More Data	Event counter	Info
834	20.674	c4:03:29:65:50:fe	LE 1M	LE LL	21	498				0	ADV_IND
835	20.675	c4:03:29:65:50:fe	LE 1M	LE LL	21	1050				0	ADV_IND
836	21.677	c4:03:29:65:50:fe	LE 1M	LE LL	21	1000658				0	ADV_IND
837	21.678	f7:51:61:6c:70:ca	LE 1M	LE LL	34	151				0	CONNECT_REQ
838	21.679	Master_0xb2a7e1bf	LE 1M	L2CAP	18	1253	0	0	False	0	LE Credit Based Connection Request (CID: 0040, Initial Credits: 0)
839	21.679	Slave_0xb2a7e1bf	LE 1M	LE LL	0	150	0	1	False	0	Empty PDU
840	21.707	Master_0xb2a7e1bf	LE 1M	LE LL	0	29545	1	1	False	1	Empty PDU
841	21.708	Slave_0xb2a7e1bf	LE 1M	L2CAP	18	151	1	0	False	1	LE Credit Based Connection Response (CID: 0000, Initial Credits: 0)
842	21.737	Master_0xb2a7e1bf	LE 1M	LE LL	0	29546	0	0	False	2	Empty PDU
843	21.738	Slave_0xb2a7e1bf	LE 1M	LE LL	0	150	0	1	False	2	Empty PDU
844	21.767	Master_0xb2a7e1bf	LE 1M	LE LL	0	29692	1	1	False	3	Empty PDU
845	21.768	Slave_0xb2a7e1bf	LE 1M	LE LL	0	150	1	0	False	3	Empty PDU

Since the 52840 Dongle is not set up for L2CAP it refuses the connection. In wireshark I can see LE Result: Connection Refused - No Resources Available (0x0004)

Frame 841: 44 bytes on wire (352 bits), 44 bytes captured (352 bits) on interface wireshark_extcap2808, id 0
Nordic BLE Sniffer
Bluetooth Low Energy Link Layer
Bluetooth L2CAP Protocol
    Length: 14
    CID: Low Energy L2CAP Signaling Channel (0x0005)
    Command: LE Credit Based Connection Response
        Command Code: LE Credit Based Connection Response (0x15)
        Command Identifier: 0x03
        Command Length: 10
        Destination CID: Null identifier (0x0000)
        MTU: 0
        MPS: 0
        Initial Credits: 0
        LE Result: Connection Refused - No Resources Available (0x0004)

I am currently registering a BLE observer as in all the examples I've seen.

    // Register a handler for BLE events.
    NRF_SDH_BLE_OBSERVER(m_ble_observer, APP_BLE_OBSERVER_PRIO, ble_evt_handler, NULL);

However on the 52833DK the p_ble_evt->header.evt_id is never BLE_L2CAP_EVT_CH_SETUP_REFUSED or BLE_L2CAP_EVT_CH_SDU_BUF_RELEASED in ble_event_handler. From https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v16.0.0%2Findex.html Variant 2 I am expecting to see those events after 52840 Dongle refuses the L2CAP setup. Is there a special handler needed to catch L2CAP events?

RE: Directly modify Link Layer packet

Kenneth — Thu, 26 Mar 2020 08:23:23 GMT

Your calculation is not taking into account pre- and post processing is part of the BLE event. Also, I don't think you can rely on peer is always sending empty packets. The minimum 2.5ms is choisen because in BLE everything is in 1.25ms resolution (e.g. connection interval = n * 1.25ms), and when taking into account the pre- and post processing it just isn't enough time to also include any radio activity if the BLE event is shorter than 2.5ms period. Realistically if you need to support long packets, I expect you will need to set BLE event to 3.75ms, but that should still work with 12 device, since 3.75ms * 12 < 50ms.

Best regards,
Kenneth

RE: Directly modify Link Layer packet

LucosidE — Wed, 25 Mar 2020 16:29:09 GMT

Thank Kenneth, I was confusing data length with ATT MTU.

I will get a second 52840DK and go ahead try to test the throughput under different settings. As I am understanding so far to reduce overhead I can avoid GATT all together and establish an L2CAP channel for each device. Looking at the l2cap channel setup message sequence once a connection is established I can initiate a channel from one device to another. Then the packets sent and their length in octets will be as follows:

[Preamble 1][Access Address 4][Link Layer header 2][L2CAP header 4][DATA(Data Length - 4)][MIC 4][CRC 3]

Where I can put anything into DATA i want using sd_ble_l2cap_tx()

Looking at BLE spec the raw radio is 1MBPS but there is a mandatory 150us delay between packets (Antenna cooling to avoid frequency shift?). Each packet is acknowledged with 80bits.

So for a 27 Data Length we have a total of 41bytes or 328bits. The timing will be as follows.

Side A sends 328bits = 328us -> Wait 150us -> Side B Acknowledges 80bits (empty packet) = 80us -> Wait 150us. Total time to send 1 packet of 27 Data Length = (328+150+80+150)us or 0.708ms. Thus with event length of 7.5ms we can ideally send 10.59 packets. This is close to the 9LL packets you mention.

So if I set Data Length to maximum of 251bytes the packet would be 265bytes or 2120bits long. The timing would work as: Side A sends 2120bits = 2120us -> Wait 150us -> Side B Acknowledges 80bits (empty packet) = 80us -> Wait 150us. Which means I can have an event length of (2120+150+80+150)us or 2.5ms. Is this why event length is multiples of 2.5ms?

With this set up I would be sending 247 DATA bytes that I can fill up using sd_ble_l2cap_tx() in 2.5ms. So for say 12 devices I can set the event length to 2.5ms and connection interval to 50ms meaning each device will send 247 bytes of data 20 times a second leading to an ideal throughput of 4.9Kbytes. Switching to LE 2 PHY (as I understand it this is just 2 bits instead of 1 GFSK) I can get up to 9.6Kbytes.

Excited to try this, hopefully I can get my hands on another 52840DK soon.

RE: Directly modify Link Layer packet

Kenneth — Tue, 24 Mar 2020 08:59:20 GMT

Hi,

The event length specify the maximum time width of the "timeslot" the active link will allow to exchange data during an BLE event, the actual timing and number of packet that can fit into the "timeslot" follow the BLE spec and also depend on the length of packets, type of transfer and direction of packets. In specific the LL payload size have a dramatic impact on the throughput, since a 155byte ATT MTU payload will be split into multiple LL packets over the air if using the default size of 27bytes, actually 6 LL packets will be required to send 155bytes, at the same time the 7.5ms event length allow for 9 LL packets, so will be able to send 1.5 ATT MTU in each window:

155 / 0.0075 * 1.5 * 8 = 248 kbps.

Best regards,
Kenneth

RE: Directly modify Link Layer packet

LucosidE — Mon, 23 Mar 2020 15:26:23 GMT

Hi Kenneth, thanks a lot, I think I am getting closer to understanding the possible throughput for my case and BLE in general.

Looking at the throughput tables I think I can correctly calculate theoretical maximum for some of the table. Here is my thinking:

Connection interval is time between two data transfer events, event length is how long the data transfer event is. Minimal event length is 2.5ms during which 2 Link Layer packets get transferred.

This lines up with the throughput numbers you provided for some rows of the table, for example with a connection interval of 7.5ms

Protocol	ATT MTU size	Event length	Method	Maximum data throughput (LE 1M PHY)	Maximum data throughput (LE 2M PHY)
GATT SERVER	23	2.5ms	Send Notification	42.6kbps

To calculate the 42.6kbps we have 1000/7.5 =133.333 connections per second. Each connection has one event of 2.5ms. During each event 2 Link Layer packets are transferred. Each packet has 23-3 bytes payload.

So we will have 1000/7.5*2 packets transfered, since each packet has (23-3) bytes of payload we can calculate the throughput in bps as 1000/7.5*2*(23-3)*8 = 42.6kbps.

However I must be missing something since this does not work for other rows of the table when we have event length larger than 2.5ms. For example:

GATT Client	23	7.5 ms	Receive Notification	192.0 kbps	256.0 kbps

GATT Client

7.5 ms

Receive Notification

192.0 kbps

256.0 kbps

I was thinking now since event length is 7.5 instead of 2.5 we will send 3 times as many Link Layer packets however

1000/7.5*2*(23-3)*8*3 = 128.0kbps and not 192.

Also as I understand BLE is 1MBPS using LE 1M PHY, at 1MBPS each bit takes a microsecond. so 2500 bits can be send in a 2.5ms interval. For ATT MTU size of 158 as in the table does this mean only 1 Link Layer packet is sent every 2.5ms since the number of bits in two packets 158*2*8 is just a little larger than 2500? How is the row with 158 ATT_MTU computed?

GATT Server	158	7.5 ms	Send Notification	248.0 kbps	330.6 kbps

GATT Server

158

7.5 ms

Send Notification

248.0 kbps

330.6 kbps

Following last table it seems that for 12 devices at a connection interval of 40ms, event length of 2.5, and ATT_MTU 158 assuming only 1 Link Layer packet gets sent per event I can get a theoretical throughput of 1000/40*(158-3) = 3875 bytes per second. Since the events would not overlap.

RE: Directly modify Link Layer packet

Kenneth — Mon, 23 Mar 2020 11:49:05 GMT

You can find various throughput numbers here depending on configuration:
https://infocenter.nordicsemi.com/topic/sds_s140/SDS/s1xx/ble_data_throughput/ble_data_throughput.html

As you can see you may get slightly higher throughput (e.g. 771.1 kbps -> 803 kbps). However, whether it is worth the additional development time to get it right (firmware and application), and the drawback of likely not being compatible with many phone vendors I will let be up for discussion.

If you need multiple links please check out:
https://infocenter.nordicsemi.com/topic/sds_s140/SDS/s1xx/multilink_scheduling/suggested_intervals_windows_s132.html

Best regards,
Kenneth

RE: Directly modify Link Layer packet

Dmitry — Sun, 22 Mar 2020 22:35:37 GMT

Hi,

there is an object transfer service example that uses L2CAP channels. I don't have any experience with them, sorry.

You missed another thing: minimal event length for BLE is 2.5ms, thus you cannot have 50 events for 12 different devices per second, you're limited with 400 events/sec. Samples will be grouped by two packets in a connection interval, so it's better to send 128 bytes at once. I don't think you can win anything with L2CAP channels.

RE: Directly modify Link Layer packet

LucosidE — Sun, 22 Mar 2020 18:53:03 GMT

Hi Dmitry, thanks for your quick response, the L2CAP information is very helpful

After reading more about L2CAP it seems that basic L2CAP frames will allow for the smallest overhead while still supporting connection to a BLE device. Carefully setting up the L2CAP MTU will avoid data fragmentation.

For example lets say I have a data packet of 32 bytes. I can set up Link Layer payload to be 36 octets

//From att_mtu_throughput example
err_code = nrf_ble_gatt_data_length_set(&m_gatt, BLE_CONN_HANDLE_INVALID, 36

then use basic L2CAP which will have a 4 octet header (Length = 32, Channel ID = 0x0001 - 0x007F) and my 32 bytes of data.

ESB seems very close to what I need, unfortunately it only supports up to 8 devices. I am looking for up to 12.

My end goal is to have multiple devices that sample 32 bytes of data at 100Hz to stream that data to a single central device. I though I could set the connection interval to 10ms and directly set up the Link Layer MTU to be 32 bytes and just put the data in. However it seems there is no direct access to the Link Layer packet. So as I understand it L2CAP will give me the smallest overhead. For example I can set the connection interval to 20ms, set the Link Layer MTU to be 68 bytes then set up L2CAP on each device with Length 64 and different channel IDs. Finally on each device I put together 2 32 byte data samples and they get sent. Is my thinking correct that this will maximize throughput from multiple devices to a single one?

Is there an L2CAP example using the sdk? I only found ones using GATT.

Thanks a ton

RE: Directly modify Link Layer packet

Dmitry — Sun, 22 Mar 2020 10:17:07 GMT

Hi,

BLE 4.2 and upper allows you to enlarge your payload up to 247 bytes, allowing throughput close to theoretical maximum. Also you can use custom upper-layer protocol instead of GATT with L2CAP connection-oriented channels. Another way is to use some protocol with lower overhead, for example esb.