The Slow Start Phase

The slow start phase is the first stage of STELA and refers to the scenario where the wireless device wakes up regularly to listen to every beacon. It is adopted when the al- gorithm predicts that some data packets will be arriving within the next beacon interval in

Algorithm 1: Static STELA

Input: Threshold value Wthre

Initialize the sleeping window of the WNIC, Ws= 1;

Initialize the sleeping intervals counter Wl= 1;

for every beacon interval do

if Wl= 1then

wake up, listen to beacon; if buffered data is detected then

Retrieve data; Wl= 1; Ws= 1; else if Ws< Wthrethen Wl= Ws= 2*Ws; else Wl= Ws= Ws++; else Wl–;

order to reduce packet delays. This phase contributes in several aspects. On one hand, most protocols without considering any characteristics in terms of traffic burstiness turn off the transceiver radio immediately after finishing transmission. In this circumstance, packets that could arrive at the client within a short period of time will instead be stored in the ac- cess point’s buffer and will be transferred after the node wakes up next time. Unnecessary delay is therefore introduced. On the other hand, some other protocols, e.g. BSD [231], introduce a method of reducing the delay by not going to sleep at all after sending out a request, and waiting instead for some time before going to sleep. However, these protocols focus on delay reduction without saving any energy. This approach is practical in HTTP traffic only, and may waste energy for other types of traffic without reducing the delay (for example for CBR traffic, where the server constantly generates traffic with the same rate).

This phase is triggered by either of the two events: sending data request and receiving packets. Sending request refers to the mobile host sending a request to a remote server asking for data content. This initiates the delivery of content including texts, images, au- dio, video, etc. On one hand, it is highly likely that one or multiple pieces of content will

be generated by the server and transmitted to the requesting node via the network. Fur- thermore, any piece of data content that is longer than the Maximum Transmission Unit (MTU) will be chopped into a group of segments prior to the transfer of data. This is due to the packetized communication process in today’s communication systems. Therefore a request by the client normally determines a series of data packets to be transmitted in the reverse direction, which can be seen in Figure 4.10.

On the other hand, Round Trip Time (RTT) which is the time between a client sending a request and the server response being received over the network. This has been observed to be very short according to [231] due to the fast deployment of Content Distribution Net- works (CDNs), and increased bandwidth of the latest network infrastructure. For example, measurement results have shown that the round trip time from both east coast and west coast of the U.S. to some popular sites such as Google, Yahoo, CNN, etc. is less than 30 ms most of the time. Additionally there are many other applications where data transfer happens between a client and a local server, and RTT is only a few milliseconds.

In this context, the RTT is much shorter than the typical beaconing interval of the access point, i.e. 102.4 ms. Data segmentation and fast RTT together help support the assumption that a series of data packets arrive at the mobile host within one beacon interval, and therefore the wireless interface should be turned on at the beginning of each interval.

Receiving packets refers to the event that the mobile host receives a data packet from the server after sleeping for more than one beacon interval. According to the bursty nature of traffic, packets often arrive in the form of bursts which implies that a packet received by the client device will be followed by multiple packets within the same burst. Under this assumption, waking up at the time when the next beacon is generated leads to quick response to packet arrival and shorter packet delays.

The end of the slow start phase is signalled by the absence of incoming packets when the transceiver radio turns on and listens to the beacon. Based on the assumption of that packet arrive in bursts, the absence of packets indicates that the last packet of a traffic burst was received, and very likely there are no more packet incoming for the immediate a short

Figure 4.10 Packet flow between client and server

period of time. In these conditions, switching on the wireless radio interface for every beacon interval would be useless and wastes energy without any effective packet reception. Static STELA design suggests the power saving process should go to the next stage, i.e. exponential increase of the sleeping window.

The slow start phase helps increase the response time by predicting packet’s arrival based on network activity and at the same time does not waste energy spent on idle lis- tening. Furthermore, energy conservation is obtained through reducing the frequency of waking ups by switching to the exponential increase stage.