# Discrete Data Rate Adaptation for Wireless Body Area Networks
## 1 Introduction  
Nowadays, the quick spread and evolution of wireless body area networks (WBANs) can be seen in the healthcare industry [1, 2]. WBANs can monitor the health data of patients in real time at low cost. They can be considered as a special type of wireless sensor network (WSN) where the connected sensor devices (e.g., blood pressure sensor, temperature sensor, motion sensor, ECG, EEG, etc.) can be implanted under the skin, fixed on the body, or carried as portable devices. The sensor data are transferred to the WBAN coordinator (also called the sink) through wireless links. The sink transmits the collected sensor data from the WBAN for evaluation and further processing on a local terminal or a distant server. Limited computation power, power supply, and communication bandwidth make the data transfer challenging in wireless sensor networks. The data should arrive with a short delay and high reliability in eHealth services to provide real-time observation and urgent response in case of emergencies. Monitoring human physiological activities requires continuous data streaming and a stable level of quality of service (QoS) [3, 4]. However, wireless networks can be characterized by frequent packet loss and variable delays and capacities. For this reason, continuous adaptation of systems is required. In the case of a shortage of network resources, the quality of the data stream may be reduced. In this case, how to optimize the utility of the delivered data under the current resource constraints is a key question. Figure 1 presents an example of WBAN. The various sensor data in WBANs have different QoS requirements (e.g., delay, reliability, energy efficiency, bandwidth utilization, and throughput). The data streams require different data rates depending on the type of measured data [5]. For example, data generated by medical sensors typically have a lower rate than audio and video streams. The importance of the data streams may alsovary, and they can be prioritized accordingly [6], e.g., heart rate has a higher priority than temperature. Our model exploits the fact that the sensors can be configured from software to provide a data stream in a few variations with different qualities. This is typical in the case of multimedia streams, e.g., a video stream can be generated with various spatial resolutions, frame rates, and quantization parameters. Commercial biosensors can be also programmed for different sampling frequencies or accuracy levels [7; 8; 9]. For example, an ECG (electrocardiogram) or EMG (electromyography) sensor node may produce data with a base rate and the rate of each subsequent variation is doubled (e.g., 125, 250, 500, 1000,..., 8000 SPSs). Furthermore, the number of bits in a sample can also be configured, e.g., an EEG (electroencephalography) sensor can be configured to sample signals with an accuracy of 24 or 32 bits. The programmable sensors enable the dynamic adaptation of the sampling rate in response to the changes in the system including the network, the sensor state, the monitored phenomenon, or the requirements. Rate adaptation methods in the literature usually consider the data rate domain to be continuous. However, the sensors can generate data streams with a limited number of quality variants. Furthermore, the sensor transmitters can often send data with rates from a discrete set. For example, in IEEE 802.15.6-based WBANs, at most, eight different data rates can be defined in a frequency band [10]. For this reason, discrete rate adaptation models have high practical significance where the data rates are selected from a pre-determined, discrete set of rates coming from hardware and software constraints in WSNs [11; 12]. We aim to optimize the delivered data under the current resource constraints by selecting an appropriate variation of the transferred data. The sensor data of the best quality should be transferred if there are enough resources in the network. However, if this is not possible because of the lack of network and node resources (e.g., throughput, energy, etc.)