\chapter{Quality of Service}
\label{chapter-qos}

In the previous chapter we discussed architectural problems and the server selection algorithm which provide the general framework for latency-sensitive applications. In this chapter, we take a look at data traffic between these applications in a mobile ad-hoc network and how it is effected by other data. We will provide ideas and methods to support the timely delivery of our data. We will focus on wireless LAN (IEEE~802.11a/b/g) as the communication protocol for our ad-hoc network since most mobile devices support  WLAN. However, the general discussion in this chapter can generally be applied to other radio communication systems as well. 

This chapter is structured as follows: We start by discussing the problem of the transmission of latency-sensitive data in wireless ad-hoc networks. We will also show why quality of service approaches from other domains such as wired networks cannot be applied directly in mobile environments. After that, we present 


% Define Qos: What is QoS? Why we need it?
\section{Problem statement}

% Problem RTS/CTS
When connected to a typical wired broadcast network such as Ethernet, computers can usually send data to and receive data from any other computer on the same network. Physical limits such as the maximum communication range of a signal is being dealt with early on at the design stage of the network to ensure near-perfect conditions. The same, however, is not true for radio networks where not every station can automatically send/receive data from any other station and where the maximum communication range plays a more important role. Due to this fact, additional problems such as hidden or exposed terminals can occur. In the hidden terminal problem, two stations ($A$ and $C$) try to send data to stations $B$ at the same time which causes a collision at the receiver (see Figure~\ref{fig-rts-cts}). Because $A$ and $C$ are to far apart to notice the other station's transmission the carrier cannot be detected and the collision not be avoided. Thus, hidden terminals can lead to an increased number of actual unnecessary collisions and retransmissions which diminishes the total available bandwidth. Although these problems can be found in infrastructure networks as well, hidden and exposed terminals are in particularly problems of multi-hop ad-hoc networks. Here, packets may have to travel over several hops which multiplies the problem and reduces the bandwidth available from one end to the other even further.

\begin{figure}
\begin{center}
	\TODO{Picture of hidden terminal problem}
\end{center}
\label{fig-rts-cts} 
\caption{The hidden terminal problem}
\end{figure}

Exposed terminals are another problem in radio networks where two stations detect each other's transmission and go one after another which is unnecessary if the two receivers are not able to receive the wrong transmission because they are far apart. Thus, in an exposed terminal situation the collision only occurs on the sender side which is of no consequence in radio networks. In IEEE~802.11-based WLANs, the RTS/CTS mechanism deals with the hidden terminal problem. Here, the sender and the receiver send a small management frame to notify all stations in their vicinities that a data communication is about to take place. Other nodes can then refrain from interfering for the duration of the transmission. More on hidden and exposed terminals and the RTS/CTS mechanism can be found in \TODO{ref:Schiller}. While it can be seen that the RTS/CTS mechanism helps with hidden terminals, the increased overhead is only beneficial for larger packets\TODO{ref}. 
% TODO: Related work on RTS/CTS for latency critical applications, large/small packets
\myglossar{RTS}{Request-to-send, a IEEE~802.11 management frame which helps to lessen the hidden terminal problem}
\myglossar{CTS}{Clear-to-send, a IEEE~802.11 management frame which helps to lessen the hidden terminal problem}

% Problem Datenrate
Another problem which is unique to mobile networks are that data rates on a link can change over time. Wired links often work at a fixed data rate which is defined by the technology used for that link, e.g. 100\,MBit/s in case of IEEE~802.3u Fast Ethernet. But because the wireless medium is so volatile and error-prone, wireless communication protocols use several different data rates which can be employed to benefit the most according to the specific charateristics and the history of every wireless link. 

\begin{figure}
\begin{center}
\begin{tabular}{|r||l|l|l|}
\hline
802.11 data rate & Link layer overhead & Data packet & Total\\ \hline \hline
1\,MBit/s \\ \hline
6\,MBit/s \\ \hline
11\,MBit/s \\ \hline
12\,MBit/s \\ \hline
36\,MBit/s \\ \hline
54\,MBit/s \\ \hline
\end{tabular}
\end{center}
\caption{Single hop end-to end round-trip times with 802.11b/g}
\end{figure}


% Problem Fairness of DCF
Finally, fairness is an issue in wireless networks when multiple stations
are competing for the channel. With Wireless LAN, the distributed
coordination function (DCF)\myglossar{DCF}{Distributed Coordination
Function (see IEEE~802.11 (WLAN))}

we take a look at how fair the channel is divided among all participating nodes.


% TODO:
% Define latency in WLANs. What are the variables that influence the round
% trip time?
%  * Sending 1st packet (request)
%    - STATIC: Wait DIFS
%    - VARIABLE: Contention period
%    - VARIABLE: Send packet at specific data rate
%    - STATIC: Wait SIFS
%    - VARIABLE: Send ACK
%  * OPTIONAL: Retransmission (possibly with packets from other stations
%              being transmitted first)
%  * Sending 2nd packet (response)
%    - STATIC: Wait DIFS
%    - VARIABLE: Contention period
%    - VARIABLE: Send packet at specific data rate
%    - STATIC: Wait SIFS
%    - (VARIABLE: Send ACK)



% Question: Why can't we take the methods from wired networks
% Answer:
% - The medium is different (not everyone hears everyone else)
% - The network changes more often than wired networks either because device move or the environment around them changes which affects communication between nodes.


% * RTS/CTS
% * Unterschiedliche Datenraten -> unterschiedliche Latenzzeiten
%    - Datenratenanpassung
% * Fairness in WLANs
% * the more devices - the lesser bandwidth is available for each device. 


% Solutions: * RTS/CTS deals with hidden terminals at the cost of power and bandwidth utilization. RTS/CTS is only useful for large packets (because overhead is small) - find reference for that. Our preliminary tests shows a data-rate dependant hidden terminal problem. It may be good to show the classical Reception/Detection/Interference picture here (where does it come from?)

% Solution 2: QoS can be dealt with in different ways
% * Data link layer: 
%   - RTS/CTS threshold
%   - 802.11e (TODO: Look at related work, how does it improve latencies,
%                    jitter, packet loss for game traffic)
%   - Rate adaptation algorithm
% * Network layer: 
%   - Routing protocol (*AODV*, DSR, DSDV, ...)
%   - Priority Queuing
%   - Rate control
%   - Early drop (?)


\section{Related work}
Explain why QoS in mobile ad-hoc networks is different from QoS in fixed networks / the Internet.

Similar problems:
\begin{itemize}
\item Not all devices belong to the same administrative domain
\item Medium access layers often do not support quality of service (Ethernet IEEE 802.3 CSMA/CD vs. WLAN IEEE 802.11 CSMA/CA)
\end{itemize}

Different problems:
\begin{itemize}
\item Network conditions may change often:
\begin{itemize}
	\item Interference from outside
	\item Movement of nodes (sender/receiver or forwarding node)
\end{itemize}
\item Limited signal range inside the medium. Limited Hidden/exposed terminal problem
\item Wired networks can be designed, MANETs cannot
\end{itemize}

There is no such thing as guaranteed QoS in a MANET. However, we can assign medium access times differently to different applications and/or devices thus improving something...

Define the problem of small packets in WLAN networks. (What happens in case of large downloads, small packets vs. large packets). This can be a good position to write some formulars :-)

\section{Overview}


Improving quality of service in mobile ad-hoc networks can be done at various levels:

\begin{itemize}
\item[Regulatory] Use a dedicated frequency band exclusively reserved for an application / device / network
\end{itemize}

% TODO: Look at related work on how to categorize these methods {DiffServ, IntServ}

In the following sections, we will discuss how qos can be improved through this various methods.

\TODO{Results from Dirks work}

\TODO{Results from Philipps work}

\TODO{Results from Franks work?}

\section{Summary}


% Misc from chapter 2


An example of a service marking model is IPv4 TOS as defined in
   [RFC1349].  In this example each packet is marked with a request for
   a "type of service", which may include "minimize delay", "maximize
   throughput", "maximize reliability", or "minimize cost". 


The characteristics of a network can, as well as the requirements of
an application, be defined by a set of Quality of Service (QoS)
parameters. \myglossar{QoS}{Quality of Service}

\TODO{Find QoS network parameters from related work}

Communication types: individual vs. bulk, async vs. sync., distributed vs. local


\begin{itemize}
	\item Latency -- End-to-end delay of a packet
	\item Throughput -- 
	\item Packet loss -- Proportion of the number of received packets in
	relation to the number of send packets
\end{itemize}


* Explain the network characteristics we will define here.
  - latency or delay
  - jitter or variation of delay
  - Bandwidth / throughput
  - packet loss ratio (explain packet loss distribution, probably later with the manet chapter)
  - packet error ratio
  - Synchronisation (between different streams)
  - 
  
\TODO{Look at DiffServ/InterServ, QoS in MANETs}
