IEEE 802.16e-2005 divides all possible data services into five classes: Unsolicited Grant Service (UGS), Real-Time Polling Service (rtPS), Extended Real-Time polling Service (ErtPS), Non-Real-Time Polling Service (nrtPS), and Best Effort (BE). Each service is associated with a set of quality of services (QoS) parameters that quantify aspects of its characteristics: (a) maximum sustained rate, (b) minimum reserved rate, (c) maximum latency tolerance, (d) jitter tolerance, and (e) traffic priority.
The aforementioned parameters are the basic inputs for the service scheduler placed in the BS, whose design and implementation are left to the manufacturers, which is aimed at fulfilling service-specific QoS requirements.
Within IEEE 802.16, in particular, the scheduler task is to define both uplink and downlink resource allocation maps (UL-MAP and DL-MAP) on the basis of the users' needs. With reference to BE services, an insight on the bandwidth request mechanism is provided in the following subsections and a fair and efficient scheduling strategy is proposed.
1. BE Resource Requests
In order to support BE services (FTP, web browsing, and so on), a resource request mechanism is needed to make the scheduler aware of MSs bandwidth requirements in both directions.
As for the DL direction, however, it is immediate to understand that the scheduler has a perfect knowledge of MSs needs, because they coincide with the amount of data waiting to be transmitted in the respective BS transmission queues.
As far as the UL is concerned, on the contrary, a request mechanism is introduced by the standard, which allows MSs to make use of (a) contention request opportunities, (b) unicast request opportunities, and (c) unsolicited data grant burst types. In the first case a bandwidth request is transmitted during the appropriately shared UL allocation, whereas in the other two cases each MS is given a reserved UL resource to convey its request.
All requests for bandwidth are made in terms of number of bytes needed to carry MAC PDUs.
Once an MS is given the UL resource, further bandwidth requests may come as a piggyback request, thus avoiding to resort again to one of the three bandwidth request mechanisms introduced before (a, b, and c).
Bandwidth requests may be incremental or aggregate; in the former case the BS adds the amount of bandwidth requested to its current perception of the bandwidth needs of the connection, whereas in the latter case it replaces its perception of the bandwidth needs of the connection with the amount of bandwidth requested. The type field in the bandwidth request header indicates whether the request is incremental or aggregate. Because piggyback bandwidth requests do not have a type field, piggyback bandwidth requests shall always be incremental.
The mechanism of piggyback incremental requests can be conveniently exploited to reduce the time wastage due to the complete bandwidth request mechanism: it is reasonable to operate in such a way that the first time an MS performs a bandwidth request (adopting one of the three previously introduced procedures), it notifies the BS the dimension of the entire amount of data waiting in its transmission queue. This way the BS has an exact knowledge of each MS need and can update it (decreasing) each time PHY-level resources are assigned to that connections and the related transmissions are correctly acknowledged.
Possible further data incoming in the MS queue while transmissions are still ongoing (i.e., before the MS queue gets empty) can be notified to the BS scheduler through the incremental piggyback bandwidth requests, which will determine a variation of the perception of MS bandwidth needs.
2. BE Scheduling
In this section we still focus on BE data services and we show how to provide, at the same time, a fair and efficient resource sharing, carefully considering IEEE 802.16e-2005 specific characteristics.
As far as the fairness issue is concerned, here we considered a round robin (RR) scheduling policy among all BE services. Although this choice seems the most suited to this kind of service, it has to be pointed out that its implementation, as well as the implementation of any other scheduling policy, requires some preliminary consideration on the nature of IEEE 802.16e-2005 radio resource (the OFDMA-Slot).
Because the different modes that can be adopted by users convey, in a single OFDMA-Slot, different amounts of data, it follows that, to provide a really fair scheduling among BE users, a different amount of slots has to be allocated to each of them.
To meet as much as possible the aforedescribed fairness requirement, hence avoiding that users with huge amount of data to be transmitted gather the most of resources, it is convenient to define an elementary resource unit, hereafter called Virtual Resource Unit (VRU), consisting in a fixed amount of data bytes, which is the basic element assigned by the scheduler in each RR cycle to BE users needing resources.
To better understand the scheduler behavior, let us focus our attention, for instance, on the DL subframe: the scheduler task is, in this case, to define the DL-MAP, assigning PHY-level resources to the different BS → MS links requiring DL resources.
As long as there is room (in terms of available slots) in the subframe and there are pending data that can be allocated in it, the scheduler moves from an user to the next, performing the following actions: (i) it assigns a VRU to the user, adding it to its Virtual Resource Budget (VRB); then, (ii) it virtually generates the biggest PDU that can be allocated, and (iii) correspondingly makes a slot booking; this means that although the scheduler does not effectively allocate the PDU at this time, that amount of slots is definitively reserved to that user; at the next round a bigger PDU or more PDUs may be allocated following the increased VRB, thus increasing the amount of booked slots. Please note that the scheduler would not do any slot reservation until VRB is not enough to allocate a PDU containing a single ARQ block. When the RR cycle ends (i.e., no more room or no more data to be allocated), the PDUs are effectively generated and the coding-mapping processes described in Section 8.2.3 can take place.
The separation between the virtual and physical allocations guarantees a flexible management: as an example, doubling the VRB (during the second round) may allow, for instance, to generate a PDU that includes two ARQ blocks and this could be preferred than generating and transmitting two separate PDUs with a single ARQ block each.
At the end of the allocation procedure users' VRBs are not reset, to allow stations with larger ARQ blocks to gain the same long-term priority as the others. Furthermore, VRB will be increased at most up to the amount of pending data.
The same procedure is performed also for the definition of the UL-MAP, which is carried out on the basis of UL resource request made by users.
To preserve fairness at most, in the next subframe of the same kind (UL or DL) the cyclic scheduling procedure will start from the user that follows, in the cyclic order, the last user served in the current frame.
No comments:
Post a Comment