Time-Stamp Poll Scheduling

We propose an adaptive time-stamp poll scheduling method, the method starts to poll a new QoS station at its service start time which is registered in the accepted TSPEC (see Fig. 2.9). The service start time of a TSPEC means the time this QoS traffic stream needs the HC to poll it for transferring QoS data frame. Sometimes the original HCCA or PCF methods will start to poll the stations before their service start time because it tends to poll all accepted QoS traffic streams in a single contention-free period (CAP). It usually wastes time because these streams may not be

ready to send frames. In order to avoid such time consumption, when a new traffic stream’s QoS request is accepted, the HC starts to poll those stations exactly at its service start time.

When a QoS traffic stream has been polled, the HC calculates the next time to poll this stream by adding the maximum service interval in the TSPEC of this stream. Unlike original HCCA method, it uses adaptive polling intervals to each traffic stream instead of the unitary service interval. We do not use very small intervals to poll stations, instead we use maximum service intervals of them, so as to avoid unnecessary polling. Our basic polling time calculation formula is as follows:

i i

stPollingTime =ServiceStartTime

1 , ....………... (3.1)

i i

st i

ndPollingTime = 1 PollingTime +MaximumServiceInterval

2 , ……….(3.2)

i i

th i

thPollingTime n PollingTime MaximumServiceInterval

n+1 = + , ……….(3.3)

where PollingTimei is the predetermined time in which the traffic stream i will be polled, and MaximumServiceIntervali is the maximum service interval specified in the TSPEC of the traffic stream i.

In general, every HC has a clock to provide current time. When one of the polling time of a traffic stream is encountered, the HC tries to poll this traffic stream to give the temporal ownership of the channel to this stream for transmission. However, in some special case that we would discuss later, the HC can not poll these stations at their expected polling time exactly but delay for a while. In such situation, the HC should endeavor to poll this postponed traffic stream as soon as possible because it has passed the exact polling time.

The method of polling stations and exchanging frames during TXOP duration in our adaptive time-stamp scheme is same as the one in the original 802.11e HCCA scheme. When the HC detects that the present time equals to one of expected polling time of those traffic streams, the HC first checks to see whether the channel is clear before transmitting. If the channel is busy, the HC should wait for the channel to become idle for PCF Interframe Space (PIFS). If the

channel has been idle for longer than PIFS, the HC sends CF-Poll for this assigned traffic stream to provide ownership and calculated TXOP duration. Both the HC and the station which had been polled would exchange frames with combining ACK, data or polling types at interval of SIFS.

If there is no data frame to transmit by this traffic stream before the end of TXOP duration, the HC sends the CF-End frame to all stations and comes back to the contention modes. And if there is one or more expected polling time occur among the current TXOP duration, the HC do not halt the current TXOP. The HC would poll these traffic streams just following the termination of the present TXOP duration by transferring Data+CF-ACK-CF-Poll frames or CF-Ack+CF-Poll frames like the method of HCCA.

In traditional round-robin poll scheduling of HCCA mechanism, it chooses the smallest service interval among all maximum service intervals of those accepted traffic streams as the interval in which the AP polls all stations as described in Section 2.2.2. However, it will cause extra polling when it uses a shorter service interval than that the station really needs.

Fig. 3.2 Illustration of traditional RR polling scheme

For example, there are three stations which need to be polled for QoS transmission in HCCA method, station 1 requests polling with a maximum interval of 20ms that equals to the duration it

generates the video or voice frames. Similarly, station 2 requests polling with a maximum interval of 30ms, station 3 requests polling with a maximum interval of 50ms and the beacon interval is 100ms. The hybrid coordinator (HC) will choose 20ms as the final service interval to start contention-free periods or controlled access phases (CAPs). During contention-free periods, all QoS-requested stations to be polled by the HC will be polled certainly in proper order. Figure 3.2 is an illustration for the previous example. After the beacon, it will start the contention-free period to poll three stations in turn, then after a service interval of 20ms, it starts the CAP to poll those stations one by one again, and it repeats every 20ms. This means that the HC polls all three stations every 20ms regardless of the true intervals in which those stations generate their video or voice frames actually. Therefore, station 2 generates QoS data frame in 30ms but is polled every 20ms and station 3 generates frames every 50ms; both of them will no doubt respond the QoS-Null frames after certain times of polling. It causes extra polling overheads and decreases the channel utilization.

Fig. 3.3 Illustration of adaptive time-stamp polling scheme

However, the previous problem will be overcome in our proposed adaptive time-stamp

scheme. For the same example, station 1 is polled at a maximum interval of 20ms, station 2 is polled at a maximum interval of 30ms, and station 3 is polled at a maximum interval of 50ms.

They start to be polled at their own service start time with different service intervals. Figure 3.3 is an illustration for the same example using our proposed scheme. It looks like no contention-free periods, but the HC polls all stations during CAPs in contention periods. Each CAP period contains one or more polled TXOPs in accordance with the actual needs. In this illustration, there are some polled TXOP delays for station 1 and 2, because the polled TXOP duration of station 3 extends to the polling time of station 1, and in turn the TXOP of station 1 extends to the polling time of station 2. As Figure 3.2 and Figure 3.3 demonstrated, our proposed polling method can avoid unnecessary polling and improve the channel utilization.