Idea development

The problem we mention first chapter can be solved in many different direction. The straightforward idea is to reduce the collision rate, and in fact, there are many studies focus on this issue which is nearly complete. However, we think otherwise. The primal goal of previous studies which focus on reducing the collision rate may not focus on power saving.

For them, the power saving is only a side effect. On the contrary, for us, the power saving is the only thing we care about, and we may trade something for the effect of saving power.

Hence, the direction of the proposed algorithm is not follows these pioneers and we go our way.

The main idea of the proposed algorithm is that try to give right responses to unwanted situation which means collision and idle listen. As we say in chapter 1.4, the idea of making use of acknowledgement comes into our mind. And we not only try to get the information about condition of traffic load, but also try to info SS by having an acknowledgement of the state of the bandwidth request.

2.1.1 The acknowledgement

While maintaining backward compatibility, we try to find suitable signal in standard which contain three types of PSC. Obviously, the type I and II PSC are design for the connection which has been setup, and the purpose of them is to reduce the long term consumption of power. The bandwidth request mechanism, however, is not a long term procedure. In fact, the total life time of a bandwidth request is approximately equal to T16 length multiplied by the maximum backoff stage, and is about hundreds of microsecond. In such case the type III PSC

11

is more suitable for management, because the controllable duration of the sleep interval. With the characteristic of sleep signal of type III PSC, we find the possibility of constructing a scheduling procedure, because the effect of it is to make the connection enter sleep mode for a while and go back to active mode after the period. Hence, we design the proposed algorithm with three acknowledgements which are bandwidth grant, sleep signal of type III PSC (called scheduling signal afterwards) and null response. They stand for successful bandwidth request with successful bandwidth allocation, successful bandwidth and waiting for bandwidth grant and collision in turn.

2.1.2 The scheduling window

After deciding the acknowledgement, the next question is that how we scheduling a bandwidth request and how long is the scheduling window? To decide the scheduling window, we have to know that the longer scheduling window the more improvement of power saving efficiency. Because we can let the requesting connection stays in sleep mode longer, and provide more flexibility in scheduling. However, we cannot extend the scheduling at will, because the limitation of hardware device and also, as we mentioned before, the life time of bandwidth request. Hence, while maintaining backward compatibility, we decide the scheduling window to be the maximum value of T16 timer which may differ from frame to frame. In such setting, we can guarantee that all receiving bandwidth requests are in the scope of the scheduling before they expired.

2.1.3 The scheduling principle

The first procedure of scheduling is obviously fulfilling the current frame with available bandwidth request which is in the scheduling queue with the order predefined. By doing so, we can maximum the throughput as we can. From the observation of bandwidth request mechanism, we find that the best case of a bandwidth request is to active transceiver two frames which are the frame sending bandwidth request and the frame receiving grant in the view of power saving. With the knowledge of this, we should produce the “two frames” case

12

as possible as we can. That is to saving more bandwidth as possible as we can in the coming frame. To say extremely, not to schedule any bandwidth request in the next frame will come to the most number of “two frame” case. However, the bandwidth request must be scheduled in one particular frame or it may do idle listen. If we schedule them to the frame next to next frame, then they will reduce the number of “two frames” case in the frame next to next frame.

To make a good balance of every frame, a water filling scheduling mechanism may be the best way to do. That is we find the frame which has lowest scheduled traffic load in the scheduling window, and schedule the highest priority bandwidth request in the scheduling queue to the frame. As we repeat this procedure, finally we will have the condition that all frames in the scheduling window have nearly the same scheduling traffic load which is the best case of “two frame” case in long term statistic.

2.1.4 The optional bandwidth reservation

As we reading [7], an idea which comes to our mind is that why don’t we reserve some bandwidth in the coming frame to achieve more “two frame” case? That is if we know the traffic load in some future frame, and we reserve the amount of bandwidth in the frame. By doing so, the expecting coming bandwidth request will be the “two frame” case in the bandwidth-reserved frame. However, expecting arrival traffic is not an easy task, and the wrong reservation will lead to bandwidth waste which is the most intolerable mistake in scheduling procedure. With these reasons, we leave the expectation part as an external function and make the function of bandwidth reservation an optional function in the proposed algorithm. If we have a precise expecting function, then we may use this function to improve better performance, otherwise we just leave the expectation as zero traffic load to disable the expecting function.

13