commit - bbf7183aa80898154c20767e6dc267ad1ed4dfc8
commit + 7db60ad5ea733e7e07d8f2d6bcafe25fa38f2064
blob - 86c333bcc82045a3e7136c7275c8de034c0334ec (mode 644)
blob + /dev/null
Binary files figures/bluetooth_audio_split.png and /dev/null differ
blob - 8e7f191aa55494192c00e2e5b18a5fb3d81cc731
blob + c6b8f762608d717cf0911c4100f079de8eeb49f4
--- src/abbreviations.tex
+++ src/abbreviations.tex
\acro{sdk}[SDK]{Software Development Kit}
\acro{rtos}[RTOS]{Real-Time Operating System}
\acro{raii}[RAII]{Resource Allocation Is Initialization}
- \acro{os}[OS]{Operating System}
\acro{bredr}[BR/EDR]{Bluetooth Basic Rate/Enhanced Data Rate}
\acro{sig}[SIG]{Special Interest Group}
\acro{l2cap}[L2CAP]{Logical Link Control and Adaptation Layer Protocol}
blob - e9e59212d7205e83f703761a02d29cf2902bd725
blob + c41cbcd61696a3b25f0aa073e4d6a46ce3bd4430
--- src/chapters/alternative_implementations.tex
+++ src/chapters/alternative_implementations.tex
official Bluetooth audio implementations. Classic audio is operated on
\ac{bredr}, while \ac{le} Audio is operated on \ac{ble}.
-\begin{figure}[htpb]
- \centerline{\includegraphics[scale=0.3]{bluetooth_audio_split.png}}
- \caption{Classic Audio and \ac{le} Audio are both Bluetooth audio
- implementations, with Classic Audio operating on \ac{bredr} and \ac{le}
- Audio operating on \ac{ble}\cite{bluetooth:le_audio:recent_enhancements}.}
- \label{fig:bluetooth_audio_split}
-\end{figure}
-
\section{Classic Audio}%
\label{sec:classic_audio}
blob - 2ac4feb35ce7abd93937ac032b535b523d3e18c3
blob + dc208a54979d82c2c7545aa0f48d71a3a8878b45
--- src/chapters/background/ble/layers.tex
+++ src/chapters/background/ble/layers.tex
\paragraph{\ac{att}} In the stack above \ac{l2cap} is the \acl{att}
which is \enquote{a protocol for discovering, reading, and writing
- attributes on a peer device.}\cite[p. 2169]{bluetooth:spec50} It's
-important for throughput because it is responsible for reading and
-writing, so it's crucial to also understand this layer.
+ attributes on a peer device.}\cite[p. 2169]{bluetooth:spec50} It is
+important for throughput because it is responsible for reading and writing data.
\paragraph{\ac{gatt}} Finally, above \ac{att} is the last of the
important layers this thesis will talk about, \acl{gatt}, which is
blob - ff399a95596ce0b3ed77d6f5f5c27b37538bd4a1
blob + c6dc207e59c46fa782377c27435d204210304486
--- src/chapters/background/hardware/esp32_c3.tex
+++ src/chapters/background/hardware/esp32_c3.tex
Previously it was planned that the hardware used would be a Raspberry Pi. The
Raspberry Pi 4 Model B has a quad-core \ac{soc} and, like the ESP32-C3, supports
-Bluetooth 5 Low Energy\cite{raspberrypi:rpi4bdata}. Ultimately, we decided that
+Bluetooth 5 Low Energy\cite{raspberrypi:rpi4bdata}. Ultimately, I decided that
less powerful hardware, in terms of CPU core count and speed, and RAM, in terms
of size, should be used to closer match the hardware specifications that would
be used in the production device. Doing this avoids developing for hardware that
-is too powerful and risking that the software ultimately would not be able to run
-on the production device.
+is too powerful and risking that the software ultimately would not be able to
+run on the production device.
Other than the hardware specification of the ESP32-C3, the software and tooling
that drives this hardware has to be taken into account, too. Espressif is
focused on developing microchips for use in \ac{iot}, meaning support for it
-should be present, at least partially. Section \ref{sec:rust} will further
-expand on this.
+should be present, at least partially. Section \ref{sec:rust} will elaborate on
+this further.
-Additionally, I chose this microcontroller because of previous work
-experience with it, which avoided getting to know new hardware and
-tooling around it. Through this the focus remained on prototyping,
-functionality, and testing rather than getting familiar with both the new device
-and software that might be running on it.
+Furthermore, I chose this microcontroller because of previous work experience
+with it, which avoided getting to know new hardware and tooling around it.
+Through this the focus remained on prototyping, functionality, and testing
+rather than getting familiar with both the new device and software that may be
+running on it.
blob - adad942a4b1e0ad1d9b8213c668fa8a1bae6faf1
blob + 25782d6133bbaeee49ed8e381ed1b529038d0dc9
--- src/chapters/background/hardware/nrf52840_dongle/hci.tex
+++ src/chapters/background/hardware/nrf52840_dongle/hci.tex
compiling the image has to be installed. The version used here is 3.2.0. For
this, the \enquote{Getting Started Guide} in the \citetitle{zephyr:zephyrdoc}
can be used which outlines the necessary steps in detail. This includes
-installing the dependencies \lstinline{CMake}, \lstinline{Python}, and
-\lstinline{Devictree compiler}, getting the Zephyr dependencies, installing
-their meta-tool \lstinline{West}, and installing the Zephyr \ac{sdk}.\\
-When this is done, the meta-tool \lstinline{west} that is provided by Zephyr can
-be used to build the sample application located in
+installing the dependencies, consisting of \lstinline{CMake},
+\lstinline{Python}, and \lstinline{Devictree compiler}, getting the Zephyr
+dependencies, installing their meta-tool \lstinline{West}, and installing the
+Zephyr \ac{sdk}.\\
+After this is done, the meta-tool \lstinline{west} that is provided by Zephyr
+can be used to build the sample application located in
\lstinline{samples/bluetooth/hci_usb/}.
The exact application along with its configuration used for this thesis can be
Assuming the dependencies for working with Zephyr described above have been
installed, this project supports building with \lstinline{make}.
-After building the project it can be flashed on one of the two nRF52840 Dongles
-and should now be accessible to the host computer when plugged in.
+After building the project it can be flashed onto one of the two nRF52840
+Dongles and should now be accessible to the host computer when plugged in.
blob - 84ad14ebf7837117d51949f2409b69294cabb01c
blob + e7731a6674ad8d49291f46d0dab8b973323bba4f
--- src/chapters/background/hardware.tex
+++ src/chapters/background/hardware.tex
In order to emulate the hardware requirements of the task as closely as
possible while enjoying some freedom during development, the hardware needs to
be evaluated beforehand. Simply using a computer with standard hardware inside
-will not suffice as the final hardware is much, much less powerful. The most
-important parts that need to be evaluated are \ac{ram} and \ac{cpu}.
+will not suffice as the final hardware is much less powerful. The most important
+parts that need to be evaluated are \ac{ram} and \ac{cpu}.
The capacity of \ac{ram} used on the hardware determines how much data can be
buffered, if any. Should it have insufficient capacity to store a meaningful
amount of data during transmission then a potentially inconsistent data stream
-cannot be handled by buffering data beforehand. On the other side, if the
-capacity of the \ac{ram} is enough to store the complete data, then the maximum
-bandwidth is a lot less important, as the data can be completely transferred to
-the device before usage, making the process of working with the data independent
-from the bandwidth. Ideally, a middle ground should be found that allows both
-buffering and streaming of data, while keeping costs for the product low.\\
+cannot be handled by buffering data beforehand. But, if the capacity of the
+\ac{ram} is enough to store the complete data, then the maximum bandwidth is a
+lot less important, as the data can be completely transferred to the device
+before usage, making the process of working with the data independent from the
+bandwidth. Ideally, a middle ground should be found that allows both buffering
+and streaming of data, while keeping the costs for the product low.\\
Similarly, the \ac{cpu} is responsible for processing the data. If the \ac{cpu}
-cannot keep up with processing of the data and too much data is sent, some data
-might be lost or needs to be sent again, hurting throughput in the process. It's
-important for the hardware in production to be able to think about both \ac{ram}
-and \ac{cpu} very carefully.
+cannot keep up with processing the data and too much of it is sent, some data
+might be lost or needs to be sent again, hurting throughput in the process.
Lastly, the chosen hardware needs to support at least Bluetooth version 5.0, as
-this is the version that supports the most important throughput improvements.
+this is the version that supports the most significant throughput improvements.
For the sake of research, I chose the ESP32-C3, the microcontroller that is used
-for receiving data and calculating the throughput. Furthermore, I chose the
+for receiving data and calculating the throughput. Additionally, I chose the
nRF52840 Dongle as a dongle for sending data as well as sniffing \ac{ble}
traffic for debugging purposes.
blob - f63cb836a6d5d6abe4283d9de5bafa8622f8ea11
blob + 6bdec6544988b452e94b49a4830a50e56614a89a
--- src/chapters/background/rust/reasons.tex
+++ src/chapters/background/rust/reasons.tex
\subsection{Reasons behind using Rust for this Thesis}%
\label{sub:reasons_behind_using_rust_for_this_thesis}
-Even though Rust is popular it still lacks major adoption in the industry,
-although the adoption of Rust has increased in the last years, most notably by
+Even though Rust is popular, it still lacks major adoption in the industry.
+However, the adoption of Rust has increased in the last years, most notably by
introducing Rust into the Linux kernel\cite{linux:rust_merge} and
Android\cite{android:introducing_rust}.\\
This shows that Rust is mature enough to be used in production.
Given these already successful uses of the Rust programming language, along with
the other projects mentioned above and the previous experience gained with the
-language, this makes a good opportunity to explore whether Rust is also ready
-for programming deeply embedded systems specifically.
+language, this makes for a good opportunity to explore whether Rust is ready for
+programming deeply embedded systems specifically.
Since the ESP32-C3 is the platform for development, this is what I evaluated.
Espressif, the company that is manufacturing the ESP32-C3, has started to
develop Rust bindings\cite{espidf:esp_idf_sys}, \enquote{Type-Safe Rust
-Wrappers}\cite{espidf:esp_idf_svc}, as well as \enquote{Rust APIs and
-abstractions}\cite{espidf:embedded_svc} for their esp-idf\cite{espidf:espidf}.
+ Wrappers}\cite{espidf:esp_idf_svc}, as well as \enquote{Rust APIs and
+ abstractions}\cite{espidf:embedded_svc} for their esp-idf\cite{espidf:espidf}.
The esp-idf is the \ac{iot} Development Framework developed by Espressif that
acts as a standard library for their microchips, supporting functionality to
support features such as Wi-Fi, Ethernet, HTTP client and server, MQTT,
\todo{how did i extend ble-esp32c3}
However, not only the ESP32-C3 needs to be evaluated. As Linux is used on the
-development machine there also needs to be a Rust library that interacts with
-the Linux Bluetooth protocol stack, BlueZ\cite{bluez:website}. A library that
-does this is called \enquote{BlueR}\cite{bluer:readme}. As with the esp-idf and
-the corresponding Rust libraries, BlueR is the official BlueZ library for Rust
+development machine there needs to be a Rust library that interacts with the
+Linux Bluetooth protocol stack, BlueZ\cite{bluez:website}. A library that does
+this is called \enquote{BlueR}\cite{bluer:readme}. As with the esp-idf and the
+corresponding Rust libraries, BlueR is the official BlueZ library for Rust
bindings, so this is what I used.
\todo{type safety, enum, match}
blob - 67a6521b804dcb08032b6bfbdd75e8f236b84a5b
blob + bc9168c3bfb1bdaa6ecc0b8b825e4696d2298d2f
--- src/chapters/background/rust/use_cases.tex
+++ src/chapters/background/rust/use_cases.tex
Because of Rust's memory safety and speed rivalling that of C and C++ it is a
perfect candidate for low-level software like browser engines\cite{rust:servo}
-and \acp{os}\cite{rust:redox}.\\
+and Operating Systems\cite{rust:redox}.\\
The natural flow of creating a \textit{safe} interface around unsafe operations
by leveraging the type system to ensure that calling a function in a given
context is, in fact, safe, makes designing a low-level system easier as the
programmer does not have to worry about the memory safety of interfaces to
lower-level code. Unsafe code is isolated and can be reasoned about easier than
-if it was not isolated and potentially the whole program needs to be inspected
-to reason about the memory safety of it.
+if it was not isolated. When this is the case, the whole program would
+potentially need to be inspected to reason about the memory safety of it.
These features also make Rust a good fit for the software developed for this
thesis, not only because there is unsafe code to be written which can be
blob - 18002d9d232f1bec0610da21e0a7f06992cf9ad5
blob + 51953c35840b313960e91300f55560a32fe97f86
--- src/chapters/background/rust.tex
+++ src/chapters/background/rust.tex
\end{figure}
This is, no doubt, at least partially the case because of the features that make
-Rust the language what it is. Because of this it is also worth investigating
-whether using Rust for a use case like this is viable, both in terms of
-developer productivity and hardware compatibility, which are both further
-reasons why this language was chosen.
+Rust into the language it is. Because of this, it is worth evaluating whether
+using Rust for a use case like this is viable, both in terms of developer
+productivity and hardware compatibility, which are both further reasons why this
+language was chosen here.
Linting, the process of automatically checking source code for common errors and
improvements, is well supported with Rust. Not only does the Rust compiler
itself have the ability to lint code, but there also exists an external program
for this called \enquote{Clippy}\cite{clippy:readme} which introduces many more.
Clippy is well integrated with Cargo, the standard package manager and build
-system for Rust, to run Clippy across all source files in a project. If correct
+system for Rust, to run it across all source files in a project. If correct
programs are desired it is recommended to use as many Clippy lints as apply for
-the application. Examples of lints that Clippy support are
+the application. An example of lints that Clippy supports are
\lstinline{unwrap_used}, which annotates any calls to \lstinline{unwrap} that
the user could, for example, instead replace with a call to \lstinline{expect},
which also takes a message that will be printed if the program aborts due to
-this, or \lstinline{unseparated_literal_suffix}, which makes sure that a suffix
-to declare a type on a constant is always separated with an underscore to
-guarantee that a certain coding style is adhered to. Lints that are important
-for the applications developed in this thesis can be
+this. Another example is \lstinline{unseparated_literal_suffix}, which makes
+sure that a suffix to declare a type on a constant is always separated with an
+underscore to guarantee that a certain coding style is adhered to. Lints that
+are important for the applications developed in this thesis can be
\begin{itemize}
\item \lstinline{as_conversions} to avoid conversions between data types with
blob - a25e1a9364dfa64a7af27ff51281d8a9b0e550de
blob + 420aa40215201f8b78fee9463e61d34fb33c202f
--- src/chapters/closing/conclusion.tex
+++ src/chapters/closing/conclusion.tex
While a unidirectional throughput of {\textasciitilde}1250 \ac{kbps} has been
measured in Chapter \ref{cha:improving_throughput_of_bluetooth_low_energy} with
-every optimization applied, there are other source that suggest a different
+every optimization applied, there are other source which suggest a different
maximum throughput is possible\cite{bluetooth:paper:throughput_iot}, although a
notably higher throughput of {\textasciitilde}1550 \ac{kbps} might mean that
testing was performed in \textit{both} directions, adding the two separate
themselves without the need for high quality equipment and professional
oversight.
-Rust as the choice for the development of software for this thesis is difficult
-to judge. Having high-level langauge features available in a use case that is
-close to the hardware is beneficial as it keeps the developer thinking about the
-project in terms of logic, not in terms of hardware restrictions while still
-making it \textit{possible} to think about the hardware. It is, at the same
-time, also difficult to develop in Rust as potentially important pieces of the
-software stack are missing that Rust can interact with. The case here is made
-for the Bluetooth interaction with the esp-idf, something that is implemented in
-C/C++ but does not yet have an interface developed in Rust. This is a
-\textit{crucial} part of the stack used, but it is not yet available to use in
-Rust without further time spent on developing it first.\\
+Rust as the choice for the development of the software for this thesis is
+difficult to judge. Having high-level langauge features available in a use case
+which is close to the hardware is beneficial as it keeps the developer thinking
+about the project in terms of logic, not in terms of hardware restrictions while
+still making it \textit{possible} to think about the hardware. It is, at the
+same time, also difficult to develop in Rust as potentially important pieces of
+the software stack are missing that Rust can interact with. The case here is
+made for the Bluetooth interaction with the esp-idf, something that is
+implemented in C/C++ but does not yet have an interface developed in Rust. This
+is a \textit{crucial} part of the stack used, but it is not yet available to use
+in Rust without further time spent on developing it first.\\
This does not mean Rust is inadequate for this type of development; it means that
some initiative has to be shown in order to get the ecosystem to a point where
Rust is a perfectly viable choice for developing software with, eventually
blob - 1afb3c5e87d612d5c900cd4596c88a180801303e
blob + 7072f9444b8eed19bdacfae58b2de30a34e53643
--- src/chapters/closing/further_topics.tex
+++ src/chapters/closing/further_topics.tex
Regarding the use of Rust there are still a lot of improvements to be made. Not
only does Espressif not yet support the use of Bluetooth in their esp-idf
interface for Rust, but there is also the hand-crafted library
-\enquote{ble-esp32c3} that is not suited for a general use-case in production
-and only serves the purpose of this thesis. With a library like this, as well as
-the interface for the esp-idf and their heavy use of the \lstinline{unsafe}
-keyword, there is also the possibility to use \enquote{Miri}, \enquote{An
- interpreter for Rust's mid-level intermediate
+\enquote{ble-esp32c3} which is not suited for a general use-case in production
+and only serves the development of the software in this thesis. With a library
+like this, as well as the interface for the esp-idf and their heavy use of the
+\lstinline{unsafe} keyword, there is also the possibility to use \enquote{Miri},
+\enquote{An interpreter for Rust's mid-level intermediate
representation,}\cite{rust:miri:readme} which can \enquote{detect certain
classes of undefined behavior}\cite{rust:miri:readme}.
blob - 9324fe15c0c6cfde8aded03d841042a2810d9611
blob + 139f1e7fa231a7751771f16f10fb8001b5cb1706
--- src/chapters/improving_throughput/att.tex
+++ src/chapters/improving_throughput/att.tex
\enquote{Exchange \ac{mtu} Response} \acp{pdu} which, in this case, are sent by
client and server respectively\cite[p. 2184]{bluetooth:spec50}.\\
To maximise the throughput both client and server send a value of 517 bytes to
-the other, the maximum value they support.
+each other, the maximum value they support.
As the packet can be a maximum of 517 bytes large, the payload can be 514 bytes
long when subtracting the size of the header for an \ac{att} Write Command. This
\begin{table}[ht]
\centering
\caption{Parameters and their values that result in a throughput of
- {\textasciitilde}250 \ac{kbps}. In comparison to the previous parameters,
+ {\textasciitilde}250 \ac{kbps}. In comparison to the previous parameters,
the \ac{att} \ac{mtu} was changed from 23 bytes to 517 bytes, and the
\lstinline{buffer_len} was changed from 20 bytes to 514 bytes. The previous
change for the \ac{dle} is reverted from 251 bytes to not used (27 bytes).}
\begin{tabularx}{.7\textwidth}{Y | Y}
- Parameter & Value \\
+ Parameter & Value \\
\hline
- \ac{le} \ac{phy} & 2M \\
+ \ac{att} Operation & Write Command \\
\hline
- \ac{dle} & \textit{not used (27 bytes)} \\
+ \ac{le} \ac{phy} & 2M \\
\hline
- \ac{att} Operation & Write Command \\
+ \ac{dle} & \textit{not used (27 bytes)} \\
\hline
- \ac{att} \ac{mtu} & \textit{517 bytes} \\
+ \ac{att} \ac{mtu} & \textit{517 bytes} \\
\hline
- \lstinline{buffer_len} & \textit{514 bytes} \\
+ \lstinline{buffer_len} & \textit{514 bytes} \\
\end{tabularx}
\label{table:parameters_mtu}
\end{table}
\begin{table}[ht]
\centering
\caption{Parameters and their values that result in a throughput of
- {\textasciitilde}900 \ac{kbps}. In comparison to the previous parameters,
+ {\textasciitilde}900 \ac{kbps}. In comparison to the previous parameters,
the \ac{dle} was changed from not used (27 bytes) to 251 bytes.}
\begin{tabularx}{.7\textwidth}{Y | Y}
Parameter & Value \\
\hline
+ \ac{att} Operation & Write Command \\
+ \hline
\ac{le} \ac{phy} & 2M \\
\hline
\ac{dle} & \textit{251 bytes} \\
\hline
- \ac{att} Operation & Write Command \\
- \hline
\ac{att} \ac{mtu} & 517 bytes \\
\hline
\lstinline{buffer_len} & 514 bytes \\
blob - 07b97e9c5850d7e8fb2e93bd35d29d8b2b8542e1
blob + 07e830340639d3f941bd874df0ac6b11f5b6bf32
--- src/chapters/improving_throughput/link_layer.tex
+++ src/chapters/improving_throughput/link_layer.tex
parameters for a connection which define the length of the payload in a Link
Layer packet\cite[p. 2651]{bluetooth:spec50}.\\
Parameters for \ac{dle} can be exchanged more than once for a given connection,
-so it's realistic for an application to increase the length of a Link Layer
+so it is realistic for an application to increase the length of a Link Layer
packet payload only for the time that it is needed, and decrease the parameters
again afterwards if a smaller Link Layer packet size is required. Maximizing the
payload length can have implications for the throughput if a connection is not
Channel Payload} field of the Link Layer \ac{pdu} seen in Figure
\ref{fig:link_layer_pdu}.\\
The \ac{mic} field of the Link Layer \ac{pdu} is not considered anywhere in this
-thesis because it is only used for encrypted Link Layer connections\cite[p.
- 2587]{bluetooth:spec50}.
+thesis because it is only used for encrypted Link Layer connections which are
+not used here\cite[p. 2587]{bluetooth:spec50}.
Having a larger Link Layer \ac{pdu} through \ac{dle} means that there is less
\ac{tifs} between packets of the master and slave when sending the same amount
-of data. Additionally, more payload that is being sent per Link Layer \ac{pdu}
-means that there is less overhead from headers per byte of payload sent.
+of data. Additionally, more payload is being sent per Link Layer \ac{pdu},
+meaning that there will be less overhead from headers per byte of payload sent.
\begin{figure}[htpb]
\centerline{\includegraphics[scale=0.2]{link_layer_and_l2cap_pdu.png}}
\begin{table}[ht]
\centering
\caption{Parameters and their values that result in a throughput of
- {\textasciitilde}190 \ac{kbps}. In comparison to the previous parameters,
+ {\textasciitilde}190 \ac{kbps}. In comparison to the previous parameters,
the \ac{dle} was changed from not used (27 bytes) to 251 bytes.}
\begin{tabularx}{.7\textwidth}{Y | Y}
Parameter & Value \\
\hline
+ \ac{att} Operation & Write Command \\
+ \hline
\ac{le} \ac{phy} & 2M \\
\hline
\ac{dle} & \textit{251 bytes} \\
\hline
- \ac{att} Operation & Write Command \\
- \hline
\ac{att} \ac{mtu} & 23 bytes \\
\hline
\lstinline{buffer_len} & 20 bytes \\
change in throughput the \ac{att} \ac{mtu} first has to be increased, which is
done in Section \ref{sec:att_mtu}.\\
This improvement is mentioned here to make sure that the throughput is increased
-starting with the bottom layer and going up in the stack layer by layer, but
-since there is no improvement in throughput to be measured with the use of
-\ac{dle} it will be measured again later after the \ac{att} \ac{mtu} has been
-increased as it then shows much much of a difference this improvement actually
-makes.
+starting with the bottom layer and going up in the stack layer by layer.
+However, since there is no improvement in throughput to be measured with the use
+of \ac{dle} it will be measured again later after the \ac{att} \ac{mtu} has been
+increased as it then shows the difference this improvement actually makes.
blob - 9fc81376ce6de49dea11e3377537465ac1fac327
blob + ac428f6e0fa0aafc90937f40c17dae1e75c99462
--- src/chapters/improving_throughput/packet_sizes.tex
+++ src/chapters/improving_throughput/packet_sizes.tex
\begin{table}[ht]
\centering
\caption{Parameters and their values that result in a throughput of
- {\textasciitilde}1250 \ac{kbps}. In comparison to the previous parameters,
+ {\textasciitilde}1250 \ac{kbps}. In comparison to the previous parameters,
the \lstinline{buffer_len} was changed from 514 bytes to 495 bytes.}
\begin{tabularx}{.7\textwidth}{Y | Y}
- Parameter & Value \\
+ Parameter & Value \\
\hline
- \ac{le} \ac{phy} & 2M \\
+ \ac{att} Operation & Write Command \\
\hline
- \ac{dle} & 251 bytes \\
+ \ac{le} \ac{phy} & 2M \\
\hline
- \ac{att} Operation & Write Command \\
+ \ac{dle} & 251 bytes \\
\hline
- \ac{att} \ac{mtu} & 517 bytes \\
+ \ac{att} \ac{mtu} & 517 bytes \\
\hline
\lstinline{buffer_len} & \textit{495 bytes} \\
\end{tabularx}
blob - 61001202e3dd780bfc7f55c526e14f30401d2205
blob + 618fe56004aa7101f00772a67556ab039ed13566
--- src/chapters/improving_throughput/physical_layer.tex
+++ src/chapters/improving_throughput/physical_layer.tex
bit}\cite[p. 169]{bluetooth:spec50}. Thus, 1 \ac{msym}/s is equal to 1 Mbit/s,
meaning the 1M \ac{phy} transmits 1 Mbit/s of raw data. This is the default for
\ac{ble} and the 1M \ac{phy} is the only \ac{phy} that is required by the
-standard.\\
+Bluetooth standard.\\
Besides 1M \ac{phy} there are also the 2M and Coded \acp{phy}. Like the name
implies, the 2M \ac{phy} transmits 2 \ac{msym}/s. The Coded \ac{phy} is
operating at 1 \ac{msym}/s like the 1M \ac{phy} but also supports error
this is the \ac{tifs}, \enquote{the time interval between two consecutive
packets}\cite[p. 2604]{bluetooth:spec50}. It is defined as 150 microseconds
and specifies the amount of time that a receiver of a packet needs to wait
-before sending another packet. Additionally, sending of packets must happen in
-alternation. While the amount of bytes sent in a second doubles with the 2M
-\ac{phy} the sender still has to wait for the receiver to send the response
+before sending another packet. Additionally, packets must be sent in an
+alternating manner. While the amount of bytes sent in a second doubles with the
+2M \ac{phy} the sender still has to wait for the receiver to send the response
packet.
With this improvement, the throughput measured improved from
\begin{table}[ht]
\centering
\caption{Parameters and their values that result in a throughput of
- {\textasciitilde}190 \ac{kbps}. In comparison to the previous parameters,
+ {\textasciitilde}190 \ac{kbps}. In comparison to the previous parameters,
the \ac{le} \ac{phy} was changed from 1M to 2M.}
\begin{tabularx}{.7\textwidth}{Y | Y}
Parameter & Value \\
\hline
+ \ac{att} Operation & Write Command \\
+ \hline
\ac{le} \ac{phy} & \textit{2M} \\
\hline
\ac{dle} & not used (27 bytes) \\
\hline
- \ac{att} Operation & Write Command \\
- \hline
\ac{att} \ac{mtu} & 23 bytes \\
\hline
\lstinline{buffer_len} & 20 bytes \\
blob - bc0c23eb5f1d2c909ff82c72316e88abfc886c8a
blob + dd6d095343d800f1781b0f750bec962f5d1a149d
--- src/chapters/improving_throughput/setup.tex
+++ src/chapters/improving_throughput/setup.tex
Since \ac{gatt} is used for transferring data between the Computer (client) and
the ESP32-C3 (server) there has to be a definition of services as well as their
characteristics. In \ac{gatt}, services define collections of characteristics
-(e.g. for different application profiles), and characteristics are attributes
-that can be manipulated and read from by a client given the correct
-permissions.\\
+(e.g. for different application profiles). Characteristics are attributes which
+can be manipulated and read from by a client given the correct permissions.\\
The services and characteristics are identified with a \ac{uuid} that is either
16-bit or 128-bit long\cite[p. 2232]{bluetooth:spec50}. All services and
characteristics defined here are \acp{uuid} with a length of 128-bit.
The terminology \enquote{client} and \enquote{server} is used for devices
-communication via \ac{att}. A server is the device that is serving services and
+communicating via \ac{att}. A server is the device that is serving services and
characteristics, while a client is a device that connects to and interacts with
the server and its services and characteristics.
\label{table:defined_characteristics}
\end{table}
-The idea with this service is that there exists a buffer
-(\lstinline{data_buffer}) which holds data and has a length of
-\lstinline{buffer_len}. When this buffer is written to by the client, the server
-will not respond with an acknowledgement or a notification and will just wait
-for the next write. The client just sends writes to this buffer as fast as it
-can with a length of \lstinline{buffer_len}.
+The idea with this service is that a buffer (\lstinline{data_buffer}) which
+holds data and has a length of \lstinline{buffer_len} exists. When this buffer
+is written to by the client, the server will not respond with an acknowledgement
+or a notification and will just wait for the next write. The client simply sends
+writes to this buffer as fast as it can with a length of \lstinline{buffer_len}.
When the client is writing data to the buffer the server will count the amount
of bytes written to it and save it. To calculate the effective throughput, the
signature for the callback method is \textit{required} to be the one shown, so
the lint is deactivated.
-\lstinline{ThroughputState} keeps track of the state and is a struct defined in
-Listing \ref{lst:throughput_state_definition}. It keeps track of the time passed
-since starting the benchmark, how much data was written in total and during the
-last second, what the next sequence number should be, and how many packets have
-been missed.
+\lstinline{ThroughputState} keeps track of state, including sequence number and
+bytes written, and is a struct defined in Listing
+\ref{lst:throughput_state_definition}. It keeps track of the time passed since
+starting the benchmark, how much data was written in total and during the last
+second, what the next sequence number should be, and how many packets have been
+missed.
\begin{lstfloat}
\begin{lstlisting}[
multiplication results in a number higher than the maximum value that the data
type represents it will instead just be the highest value of the data type
used.\\
-Other functions exist that achieve similar goals, namely \lstinline{checked_*},
+Other functions exist which achieve similar goals, namely \lstinline{checked_*},
\lstinline{overflowing_*}, and \lstinline{wrapping_*}, which calculate the
number if no overflow would occur, calculate the number and check if an overflow
would occur, and wrap the overflow back around the data type, respectively. This
Before improving the throughput, to see how much improvement could be made, a
base throughput needs to be established. The throughput of the profile mentioned
above was measured with {\textasciitilde}4 \ac{kbps}. The parameters set for
-this test can be seen in Table \ref{table:parameters_none}. The parameters are
-the \ac{le} \ac{phy}, \ac{dle}, \ac{att} operation, and the \ac{att} \ac{mtu}
-used. These parameters will be explained in Sections \ref{sec:phy},
-\ref{sec:dle}, \ref{sec:write_command}, and \ref{sec:att_mtu} respectively.
+this test can be seen in Table \ref{table:parameters_none}.\\
+The parameters are the \ac{att} operation, \ac{le} \ac{phy}, \ac{dle}, and the
+\ac{att} \ac{mtu} used. These parameters will be explained in Sections
+\ref{sec:write_command}, \ref{sec:phy}, \ref{sec:dle}, and \ref{sec:att_mtu}
+respectively.
\begin{table}[ht]
\centering
\begin{tabularx}{.7\textwidth}{Y | Y}
Parameter & Value \\
\hline
+ \ac{att} Operation & Write Request \\
+ \hline
\ac{le} \ac{phy} & 1M \\
\hline
\ac{dle} & not used (27 bytes) \\
\hline
- \ac{att} Operation & Write Request \\
- \hline
\ac{att} \ac{mtu} & 23 bytes \\
\hline
\lstinline{buffer_len} & 20 bytes \\
\end{table}
A buffer size of 20 bytes has been chosen because of how the \ac{att} \ac{mtu}
-is set. This is further explained in Section \ref{sec:att_mtu}.
+is set. This will be further explained in Section \ref{sec:att_mtu}.
The parameters in Table \ref{table:parameters_none} can also be observed when
sniffing the traffic between client and server, which is possible since \ac{ble}
-traffic by default is unencrypted, although encryption can optionally be
+traffic is, by default, unencrypted, although encryption can optionally be
enabled\cite[p. 567]{bluetooth:spec50}. Wireshark along with a Bluetooth sniffer
makes this trivial to see.
In addition to this, both controllers also exchange \lstinline{LL_FEATURE_REQ}
and \lstinline{LL_FEATURE_RSP} \acp{pdu}, indicating a master-initiated feature
-exchange procedure\cite[p. 2668]{bluetooth:spec50} which exchange the features
-that each controller supports\cite[p. 2654]{bluetooth:spec50}. Important
-features for this thesis are \enquote{\ac{le} \acl{dle}} and \enquote{\ac{le} 2M
- \ac{phy}}. The \lstinline{LL_FEATURE_REQ} sent by the master can be seen in
-Figure \ref{fig:feature_req_client_wireshark}.
+exchange procedure\cite[p. 2668]{bluetooth:spec50} that exchanges the features
+each controller supports\cite[p. 2654]{bluetooth:spec50}. Important features for
+this thesis are \enquote{\ac{le} \acl{dle}} and \enquote{\ac{le} 2M \ac{phy}}.
+The \lstinline{LL_FEATURE_REQ} sent by the master can be seen in Figure
+\ref{fig:feature_req_client_wireshark}.
\begin{figure}[htpb]
\centerline{\includegraphics[scale=0.8]{feature_req_client_wireshark.png}}
controller is able to do.
No exchange of the \ac{le} \ac{phy} between master and client is done here, so
-by default the 1M \ac{phy} is used. This exchange will be shown in
+by default the 1M \ac{phy} is used. This exchange will be shown in Section
\ref{sec:phy}.
Master and client exchange whether to enable \ac{dle} or not by exchanging
blob - f52bd0754f9764a0cb9d17012cd08173eced34c6
blob + f4249e3aaa07064ad67d2f428d153bf05bf12bd1
--- src/chapters/improving_throughput/write_command.tex
+++ src/chapters/improving_throughput/write_command.tex
When using the Write Request command, the client writes a characteristic on the
server and the server responds with a Write Response, indicating that this write
was successful\cite[p. 2201]{bluetooth:spec50}. This, of course, trades speed
-for correctness, something that an application that transmits audio might not
+for correctness, something that an application that transmits audio may not
always care about. Instead the Write Command is used which does not expect a
response from the server after being written to. It not only avoids the
bandwidth cost of the response but the client also does not have to wait for a
response before sending more information.\\
This is the first optimisation of the throughput as it is the most simple one.
-With this simple change of how a write is issued, a speed up from
+With this simple change of how a write is issued, an increase in speed from
{\textasciitilde}4 \ac{kbps} to {\textasciitilde}170 \ac{kbps} can be
observed. It goes without saying that this is quite the improvement, but this is
still not enough for the transmission of lossless audio, as the minimum
\begin{table}[ht]
\centering
\caption{Parameters and their values that result in a throughput of
- {\textasciitilde}170 \ac{kbps}. In comparison to the previous parameters,
+ {\textasciitilde}170 \ac{kbps}. In comparison to the previous parameters,
the \ac{att} Operation was changed from \enquote{Write Request} to
\enquote{Write Command}.}
\begin{tabularx}{.7\textwidth}{Y | Y}
Parameter & Value \\
\hline
+ \ac{att} Operation & \textit{Write Command} \\
+ \hline
\ac{le} \ac{phy} & 1M \\
\hline
\ac{dle} & not used (27 bytes) \\
\hline
- \ac{att} Operation & \textit{Write Command} \\
- \hline
\ac{att} \ac{mtu} & 23 bytes \\
\hline
\lstinline{buffer_len} & 20 bytes \\
blob - fdf94047554918c8bbdc1d44cffd8f2bdb0a0d75
blob + 1337a8e0b4231682982d00e116cd4fb5bf9c2fd7
--- src/chapters/improving_throughput.tex
+++ src/chapters/improving_throughput.tex
\label{cha:improving_throughput_of_bluetooth_low_energy}
In this chapter, after giving an overview of the tests and explaining the setup
-used,the different layers of Bluetooth will be tweaked mostly in order going
+used, the different layers of Bluetooth will be tweaked mostly in order going
from the lowest layer to the highest, with the exception of starting with
\ac{att} as this is the easiest parameter to change. After changing the \ac{att}
write mode in Section \ref{sec:write_command}, the Physical Layer will be
blob - e580f14548444aa0f50395da8e2743eb5127be98
blob + 8f09f9af29b8a397fa19f5a1d237c472c0b94391
--- src/chapters/introduction/goal.tex
+++ src/chapters/introduction/goal.tex
either a high throughput to send high quality audio directly, or a good, but
lossy, audio codec that does not require such a high throughput. Because no
information should be lost to achieve the most accurate audio for audiometry
-procedures, the former option is used. The goal for a throughput should thus be
-at {\textasciitilde}800 \ac{kbps}. Bluetooth Low Energy will be used as the
+procedures, the former option is used. The goal for the throughput should thus
+be at {\textasciitilde}800 \ac{kbps}. Bluetooth Low Energy will be used as the
technology to transmit data between smartphone and hearing aid as this is what
will be supported by the end product. As \ac{ble} operates at a default
-throughput between 4 \ac{kbps} and 20 \ac{kbps}, this will need to be tuned
-heavily.\\
+throughput between 4 \ac{kbps} and 20 \ac{kbps}, the parameters will need to be
+tuned heavily.\\
Tuning will be done at different levels of the \acl{ble} stack, improving the
-throughput at each level of the stack before improving the next one. At the end,
-all layers will be finetuned with consideration of other layers to avoid wasted
+throughput at each level of the stack before the next one. At the end, all
+layers will be finetuned with consideration of other layers to avoid wasted
throughput.
This thesis will explore how the hardware used was evaluated, what programming
possible to hardware that will be used in the final product, wrote programs
running on the devices to calculate the possible throughput, extended a library
that is used by these programs, and maximized the possible throughput of
-\acl{ble} by experimenting with and, in the end, choosing the right parameters.
+\acl{ble} by experimenting with and, in the end, choosing the ideal parameters.
Furthermore, I compare the given solution to possible alternatives and direct to
possible further work in this area.
blob - 409c5b07087b8982a260e27f4aae3c91fe688b78
blob + af8903a15c1b72c4c7212f317689d3887c0803f9
--- src/chapters/introduction/relevance_context.tex
+++ src/chapters/introduction/relevance_context.tex
loss in the world}\cite{audiometry:smartphone_self_assessment} it is important
for these people to have access to hearing aids. In order to tune hearing aids,
patients have to undergo special hearing tests, also known as
-\enquote{audiometry procedures}. These include measuring the hearing threshold
-level, and uncomfortable loudness level, among others, which are mostly executed
-by \enquote{professional audiologists with a professional audiometer in a
- sound-proof booth}\cite{audiometry:smartphone_self_assessment}. This is an
-inconvenience for the patient with the hearing assessments being both costly and
-requiring time.
+\enquote{audiometry procedures}. These include, among others, measuring the
+hearing threshold level, and uncomfortable loudness level, which are mostly
+executed by \enquote{professional audiologists with a professional audiometer in
+ a sound-proof booth}\cite{audiometry:smartphone_self_assessment}. This
+inconveniences the patient since the hearing tests are both costly and require a
+significant amount of time to conduct.
-To avoid this it is conceivable that these tests can be conducted by the patient
-in their own time, at no extra cost and with their smartphone connected to their
-hearing aid, both being items which a patient suffering from hearing loss are
-likely in possession of.\\
-These test should be conducted with the highest audio quality so that they are
-as accurate as possible. Tests will not be limited to the ones mentioned above,
-therefore it is likely that a high audio quality is also needed for recognizing
-speech patterns or similar.
+To avoid this it is feasible that these tests can be conducted by the patient
+during their own time, at no extra cost and with their smartphone connected to
+their hearing aid, both being items which a patient suffering from hearing loss
+is likely in possession of.\\
+These test should be conducted with the highest audio quality achievable so that
+they are as accurate as possible. Tests will not be limited to the ones
+mentioned above, therefore it is likely that a high audio quality is needed for
+recognizing speech patterns or similar tests.
These guidelines serve as constraints for the technology that will be used. The
selected technology to transmit data from smartphone to hearing aid will be
to transmit lossless audio codecs.
The focus of this bachelor thesis is not audiometry procedures or audio codecs
-but instead is how to achieve a required throughput with \ac{ble} for the
-previously explained use case, as improving throuhgput of \ac{ble} is
-independent of this does not require knowledge of these topics.
+but instead on how to achieve a required throughput with \ac{ble} for the
+previously explained use case, as improving throughput of \ac{ble} is
+independent from this and does not require any knowledge of these topics.
blob - b5d4f8221147abbb46d7f71fa22879d4d11b84fc
blob + a31260e43ba5e763bfd786d047af8297943440d4
--- src/chapters/likely_mistakes/att_notifications.tex
+++ src/chapters/likely_mistakes/att_notifications.tex
has to receive a packet from the server before sending another write, so if the
server does not send a reply it is either still busy or did not receive the
packet. The downside of this is that not sending a packet means, for the Link
-Layer, that the packet that was sent from client to server might not have been
+Layer, that the packet which was sent from client to server might not have been
received, so the packet is retransmitted. Depending on how high the load of the
-server is, this could result in packets sent unnecessarily. The upside, however,
-is that the application does not need to handle retransmission of packets since
-the Link Layer is already doing this. In fact, this is what can be seen during
-testing in Figure \ref{fig:retransmission_link_layer}, and this is also why when
-trying to see lost packets in the application layer, no lost packets can be
-observed.
+server is, this could result in packets being sent unnecessarily. The upside,
+however, is that the application does not need to handle retransmission of
+packets since the Link Layer is already doing this. In fact, this is what can be
+seen during testing in Figure \ref{fig:retransmission_link_layer}, and this is
+also why when trying to see lost packets in the application layer, no lost
+packets can be observed.
\begin{figure}[htpb]
\centerline{\includegraphics[scale=0.72]{retransmission_link_layer.png}}
blob - 1ad846b2efb226b90cad37c18db78942d47e4580
blob + ccc6a1f0cd0d66cc0921d0081f54ddbe89671de3
--- src/chapters/likely_mistakes/ble_link_layer_procedure_collision.tex
+++ src/chapters/likely_mistakes/ble_link_layer_procedure_collision.tex
\end{figure}
During testing this can easily be missed when not debugging the connection and
-not logging the rejection. Even when using Wireshark it's hard to see as it can
+not logging the rejection. Even when using Wireshark it is hard to see as it can
be drowned out by the \enquote{noise} of other packets being exchanged.
blob - 7afd5c631157361fe0db8b22acff1be82e0ab475
blob + 622a279ddec142375ecc05e2aa6d1cd66c04fce7
--- src/chapters/likely_mistakes/default_settings.tex
+++ src/chapters/likely_mistakes/default_settings.tex
\ac{dle} to the maximum of 251 bytes, but, as Figure
\ref{fig:length_req_slave_wireshark} shows, it turned out to be the ESP32-C3
setting this value instead. Meanwhile, the computer did not activate \ac{dle} at
-all, which turned out to be the case because of the nRF52840 Dongle not
-supporting \ac{dle} by default, making the ESP32-C3 (esp-idf) and the nRF52840
-Dongle (Zephyr) have completely opposite defaults.
+all, which turned out to be the case as the nRF52840 Dongle not supporting
+\ac{dle} by default, making the ESP32-C3 (esp-idf) and the nRF52840 Dongle
+(Zephyr) have opposing defaults.
Even though the esp-idf sets the default of a 251 byte \ac{dle} by default this
should not be assumed to be the default, so setting this explicitly is
