ANMIAN

REF. 

https://interrupt.memfault.com/blog/ble-throughput-primer#:~:text=For%20Bluetooth%204.0%2C%20the%20BLE,be%20encoded%20in%20each%20symbol

https://novelbits.io/bluetooth-5-speed-maximum-throughput/

Why is it impossible to achieve the theoretical speeds of BLE?

The data rates of 1 Mbps (LE 1M PHY), 2 Mbps (LE 2M PHY), 125 kbps and 500 kbps (both using the LE Coded PHY with S=8 and S=2, respectively) are the rates at which the radio transmits data, but this is not achievable for the application throughput due to the following reasons:

• Limit on the number of packets per connection interval
• Inter Frame Space (IFS) delay between packets (150 us)
• Empty packets required to be sent from a device even if no data is available for transmission
• Packet overhead – not all bytes in a packet are used for payload

In order to better understand these factors and understand what impacts application throughput, we have to take a deeper look at the packet format. The following figure shows what LE 1M PHY and 2M PHY data packets look like:

The part we’re interested in (and the one that really defines the application data) is the ATT Payload. As you can see from the figure, there are a number of overhead bytes that are used by each layer in Bluetooth Low Energy.

• In 4.0 and 4.1, the maximum ATT Payload is 20 bytes.
• In 4.2 and 5.0, a new feature called Data Length Extensions (DLE) allows the ATT Payload to hold up to 244 bytes of data.

Factors that impact/determine the data throughput

There are a few factors that impact the data throughput of a BLE application. The most common are:

• PHY being used (LE 1M vs. LE 2M vs. LE Coded (S=2 or S=8))
• Connection interval
• Maximum number of packets per connection interval
• ATT Maximum Transmission Unit (ATT MTU)
• Data Length Extension (DLE)
• Operation type: Write with response vs. write without response, Indications vs. Notifications
• Inter Frame Space (IFS): time gap between consequent packets (150 us)
• Transmission of empty packets
• Packet overhead – not all bytes, in a packet, are used for the application payload

Calculating your application data throughput

The big question is: how do we calculate our application throughput?

As we mentioned before, there are a few variables that impact the data throughput:

• Bluetooth version & PHY used
• DLE: Data Length Extensions – enabled or not
• ATT MTU value
• Connection interval
• Maximum number of packets per connection event
• Operation (writes with responses vs. writes without responses, and notification vs. indication)
• Inter Frame Space (IFS): 150 microseconds

The Link Layer (LL) Packet

All data during a BLE connection is sent via Link Layer (LL) packets. All higher level messages are packed within Data Payloads of LL Packets. Below is what a LL Packet sending data looks like (each tick mark represents 1 byte):

NOTE: The astute reader may note that Data Payload can be up to 251 bytes. This however is an optional feature known as “LE Data Packet Length Extension” which we will explore in more detail below

Maximum Link Layer Data Payload Throughput

With the three rules we mentioned about transmissions on the Bluetooth Radio in mind, let’s take a look at the procedure to transmit a maximally sized LL packet.

• Side A sends a maximum size LL data packet (27 bytes of data in a 41 byte payload) which takes 328μs (41 bytes * 8 bits / byte * 1Mbps) to transmit
• Side B receives the packet and waits T_IFS (150μs)
• Side B ACKs the LL packet it received in 80μs (0 bytes of data)
• Side A waits T_IFS before sending any more data

Here’s an example exchange of two packets of data in one Connection Event:

The time it takes to transmit one packet can be computed as:

328μs data packet + 150μs T_IFS + 80μs ACK + 150μs T_IFS = 708μs

During this time period, 27 bytes of actual data can be transmitted which takes 216μs.

This yields a raw data throughput of:

(216μs / 708μs) * 1Mbps = 305,084 bits/second = ~0.381 Mbps

The Link Layer (LL) Packet

All data during a BLE connection is sent via Link Layer (LL) packets. All higher level messages are packed within Data Payloads of LL Packets. Below is what a LL Packet sending data looks like (each tick mark represents 1 byte):

NOTE: The astute reader may note that Data Payload can be up to 251 bytes. This however is an optional feature known as “LE Data Packet Length Extension” which we will explore in more detail below

Maximum Link Layer Data Payload Throughput

With the three rules we mentioned about transmissions on the Bluetooth Radio in mind, let’s take a look at the procedure to transmit a maximally sized LL packet.

• Side A sends a maximum size LL data packet (27 bytes of data in a 41 byte payload) which takes 328μs (41 bytes * 8 bits / byte * 1Mbps) to transmit
• Side B receives the packet and waits T_IFS (150μs)
• Side B ACKs the LL packet it received in 80μs (0 bytes of data)
• Side A waits T_IFS before sending any more data

Here’s an example exchange of two packets of data in one Connection Event:

The time it takes to transmit one packet can be computed as:

328μs data packet + 150μs T_IFS + 80μs ACK + 150μs T_IFS = 708μs

During this time period, 27 bytes of actual data can be transmitted which takes 216μs.

This yields a raw data throughput of:

(216μs / 708μs) * 1Mbps = 305,084 bits/second = ~0.381 Mbps

Maximum throughput over GATT

The Attribute Protocol Handle Value Notification is the best way for a server to stream data to a client when using GATT. The Opcode Overhead for this operation is 2 bytes. That means there are 3 bytes of ATT packet overhead and 4 bytes of L2CAP overhead for each ATT payload. We can determine the max ATT throughput by taking the maximum raw Link Layer throughput and multiplying it by the efficiency of the ATT packet:

ATT Throughput = LL throughput * ((MTU Size - ATT Overhead) / (L2CAP overhead + MTU Size))

Tabulating this information for a couple common MTU sizes we get:

LE Data Packet Length Extension (BT v4.2)

As part of the 4.2 Bluetooth Core Specification revision, a new feature known as LE Data Packet Length Extension was added 4. This optional feature allows for a device to extend the length of the Data Payload in a Link Layer packet from 27 up to 251 bytes! This means that instead of sending 27 bytes of data in a 41 byte payload, 251 bytes of data can now be sent in a 265 byte payload. Furthermore, we can send a lot more data with fewer T_IFS gaps. Let’s take a look at what exchanging a maximally sized packet looks like:

We can calculate the raw data throughput and see that this modification yields greater than a 2x improvement on the maximum raw data throughput which can be achieved!

251 bytes / 2500μs = 100.4 kBytes/sec = ~0.803 Mbps

LE 2M PHY (BT v5.0)

As part of the 5.0 Bluetooth Core Specification revision, a new feature known as “LE 2M PHY”5 was added. As you may recall in the section above, we discussed how the BLE Radio is capable of transmitting 1 symbol per μs for a bitrate of 1Mbps. This revision to the Bluetooth Low Energy Physical Layer (PHY), allows for a symbol rate of 2Mbps. This means we can transmit each individual bit in half the time. However, the 150μs IFS is still needed between transmissions. Let’s take a look on how this impacts the throughput when sending packets that are using the data packet length extension feature:

We can calculate this throughput and see the modification yields almost a 4x improvement over the original maximal raw data speed that could be achived with BLE 4.0:

251 bytes / 1400μs = 179.3 kBytes/sec = ~1.434 Mbps

LE Coded PHY (BT v5.0)

The “LE Coded PHY” feature, also introduced in the 5.0 Spec 5 provides a way to extend the range of BLE at the cost of speed. The feature works by encoding a bit across multiple symbols on the radio. This makes the bits being transmitted more resilient to noise. There are two operation modes where either two symbols or eight symbols can be used to encode a single bit. This effectively reduces the radio bitrate to 500 kbps or 125kbps, respectively.

Determine the time it takes to send one data packet and the empty packet from the receiver.

The time during which one data packet can be sent will include the following:
Data_Packet_Time = Time to transmit empty packet + IFS + Time to transmit the actual data packet + IFS.

An empty packet transmission time can be calculated as follows:
Time to transmit empty packet = empty packet size / raw data rate

An empty packet will contain the following fields:
Preamble + Access Address + LL Header + CRC.
For 1M PHY, Preamble will be 1 byte, and so the total size of the empty packet = 1 + 4 + 2 + 3 bytes = 10 bytes = 80 bits.

(for 2M PHY, the size of an empty packet will be 88 bits since the Premable is 2 bytes instead of 1 byte).
Based on this, the time to transmit an empty 1M PHY packet will be:
Time to transmit empty packet = empty packet size / raw data rate = 80 bits/ 1 Megabits per second = 80 micro seconds

A data packet will contain all fields listed in the packet format diagram with the exception of the MIC field (encryption disabled).
Time to transmit data packet = data packet size / raw data rate

If we have DLE enabled and the ATT MTU is equal to the maximum bytes allowed in one packet: 247 bytes, then we can calculate the data packet size as:
Data packet size = 1 + 4 + 2 + 4 + 247 + 3 bytes = 265 bytes = 265*8 bits = 2088 bits
Time to transmit data  packet = 2088 bits / 1 Mbps = 2,088 micro seconds

Data_Packet_Time = Time to transmit empty packet + IFS + Time to transmit the actual data packet + IFS = 80 + 2*150 + 2088 = 2,468 microsecs

For comparison, in the case of 2M PHY, it would be:
Data_Packet_Time = Time to transmit empty packet + IFS + Time to transmit the actual data packet + IFS = 88/2 + 2*150 + (2 + 4 + 2 + 4 + 247 + 3)*8/2 = 1,392 microsecs

When DLE is enabled and the ATT MTU is set to less than 247, we end up with more overhead (since now data larger than the ATT MTU gets split up into more packets). For example, say we have the ATT MTU set to 158, then in order to transfer 244 bytes of application data, we will need two packets instead of one, causing the throughput to go down due to the increased byte overhead as well as the increased IFS between the packets. In another scenario, we could have DLE disabled (Payload size up to 27 bytes) and the ATT MTU greater than 27 bytes. Here, this will also result in more packets needed to be sent for the same amount of data, causing the throughput to go down.
Note: The same method for calculating the data and empty packet sizes that we used above can be used for the LE Coded PHY.

https://ieeexplore.ieee.org/iel7/9952188/9952355/09952802.pdf

Published in
2022 13th International Conference on Information and Communication Technology Convergence (ICTC)
Date of Conference
19-21 October 2022
Date Added to IEEE Xplore
25 November 2022
ISBN Information
ISSN Information
INSPEC Accession Number
22330032
DOI
10.1109/ICTC55196.2022.9952802
Publisher:
IEEE

9월2일 금
마지막 날이다. 아침부터 비가 와서 아무런 일정도 하지 못할 줄 알았는데 체크아웃 할 때에는 비가 전혀 오지 않았다. 한국에서 계속 연락이 와서 그냥 자리 깔고 일하고 싶은 생각도 있었다.

센토사 섬에서 루지로 일정을 시작하려고 했으나 루지 이후 비가 와서 펍에서 맥주나 마시는 것으로 일정이 마무리되었다. 호텔 주변으로 돌아와 간단히 쇼핑을 하고 호텔에 맡겨놓은 짐을 찾았다.

그러고는 공항으로 바로 갔는데 너무 일찍 도착하니 대한항공 부스가 없었다. 이륙하기 3시간 전부터 부스가 준비된다고 한다. 회사에 청구하기 귀찮아질 것 같아 그냥 기다릴까 생각하다가 모바일로 해버렸다. 같이 다니던 팀원들은 다른 비행기로 귀국해서 터미널이 달랐다. 일정 중간중간에 몇분씩 쪼개서 업무를 하니 제정신이 아닌 상태였다. 그냥 집에 돌아가고 싶은 생각이 간절했다. 하루종일 같이 다니면서 맞춰주는 것도 한두번이지 계속하니 너무 지치고, 더이상의 에너지가 남아있지 않은 기분이었다. 아마 한동안 해외 출장은 가기 싫을 것 같다. 단체라면 더더욱.

9월 1일 목
이번에야말로 아침에 바다수영을 했다. 아침인데도 햇살이 강해 피부가 따가웠다. 바다수영 후 수영장에 잠시 있다가 들어가려는데 아니타에게 걸려서 다시 바다로 갔다. 잠깐 놀려고 하는데 해파리가 돌아다녀 그냥 나왔다. 다시 아침을 먹고 각자 선택한 마지막 일정을 하러 갔다. 옵션이 3개가 있었는데 하나는 골프, 하나는 쇼핑, 마지막 옵션은 리조트에 잔류.

난 쇼핑을 선택했는데 팀원끼리 같이 다니자고 하는 바람에 잔류로 바꼈다. 그런데 알고보니 쇼핑이 그냥 쇼핑이 아니라 시티투어라고 한다. 악!!!
급하게 바꿀수 있는지 알아봐 달라고 하고 팀원은 버리고 체크아웃 후에 버스를 기다리는데 자리가 가득차서 탈 수 없다고 했다. 기다리던 4명이 모두 허망하게 돌아섰다. 지사장까지 나서서 도와주려 했지만 갑자기 버스를 늘릴수도 없으니 별수없이 돌아섰다. 두명은 체크아웃을 취소해달라고 하고 최소한의 샤워 공간을 마련한 뒤 수영장으로 갔다. 야외에 있어 상당히 피부가 타기 좋은 자리였다. 한참 수영을 하다보니 샤워하다 깜짝 놀랄만큼 타 있었다.
말레이시아에서 싱가폴로 돌아오는 길 역시 처음 싱가폴에 가는 것과 동일한 수준으로 각종 등록이 필요했다. 이날 저녁부터 계속 한국에서 일이 밀려왔는데 처리할 시간이 마땅치 않았다.