The BS decides transmissions in the uplink and the downlink. For uplink access, a grant is defined as the right for an SS to transmit during a certain duration. Requests for bandwidth must be made in terms of the number of bytes needed to carry the MAC header and payload, but not the PHY overhead. For an SS, bandwidth requests reference individual connections while each bandwidth grant is addressed to the SS's Basic CID, not to individual CIDs. It is then up to the SS to use the attributed bandwidth for any of its CIDs. Since it is nondeterministic which request is being honoured, when the SS receives a shorter transmission opportunity than expected due to a scheduler decision, the request message loss or some other possible reason, no explicit reason is given.
Grants are then given by the BS after receipt of a request from an SS. Two possible differentiations can be made for this request. These differentiations are now described.
A grant-request (by an SS) may be incremental or aggregate:
When the BS receives an incremental bandwidth request, it adds the quantity of bandwidth requested to its current perception of the bandwidth needs of the connection.
When the BS receives an aggregate bandwidth request, it replaces its perception of the bandwidth needs of the connection with the quantity of bandwidth requested.
The self-correcting nature of the request-grant protocol requires that the SSs should periodically use aggregate Bandwidth Requests. The standard states that this period may be a function of the QoS of a service and of the link quality, but do not give a precise value for it.
The grant-request may be sent in two possible MAC frame types that are described in the following subsection. Only the first one (the standalone bandwidth request) can be aggregate or incremental.
The two MAC frame types of the 802.16 standard, already defined in Section 8.2, can be used by an SS to request bandwidth allocation from the BS. Specifically, Section 8.2.3 details MAC headers and gives two types of request that are now described.
The standalone bandwidth request is transmitted in a dedicated MAC frame having a Header format without payload Type I, indicated by the first bit of the frame, the Header Type bit, being equal to 1. A Type field in the bandwidth request header indicates whether the request is incremental or aggregate (see Table 8.3). In the bandwidth request header, a 19-bit long bandwidth request field, the Bandwidth Request field, indicates the number of bytes of the uplink bandwidth requested by the SS for a given CID, also given in this header.
The standalone bandwidth request is included in the two main grant-request methods: unicast polling and contention-based polling.
For any uplink allocation, the SS may optionally decide to use the allocation for:
requests piggybacked in data.
The piggyback bandwidth request uses the grant management subheader which is transmitted in a generic MAC frame (then having a generic MAC header). This is indicated by the first bit of the frame, the Header Type bit, being equal to 0. This can avoid the SS transmitting a complete (bandwidth request MAC header) MPDU with the overhead of a MAC header only to request bandwidth. The grant management subheader, in a generic MAC frame, is used by the SS to transmit bandwidth management needs to the BS. The Type bit in the generic MAC frame header (see Table 8.2) indicates the possible presence of a grant management subheader.
The piggyback bandwidth request (grant management subheader) is a lightweight way to attach a request uplink bandwidth without having to create and transmit a complete MPDU with the overhead of MAC headers and CRCs. The grant management subheader is two bytes long. It is used by the SS to transmit bandwidth management needs to the BS in a generic MAC header frame in addition to other possible data transmitted in the same MAC frame. Depending on the class of QoS of the connection, three types of grant management subheader are defined and used:
Grant management subheader (see Figure 10.1). This is the case for QoS class = UGS. The UGS (Unsolicited Grant Services) is a QoS class designed to support real-time service flows, where the SS has a regular uplink access (for more details on the UGS class, see Chapter 11). For this class of QoS, the PM (Poll-Me) bit in the grant management subheader can be used by the SS to indicate to the BS that it needs to be polled in order to request bandwidth for non-UGS connections (see below).
Figure 10.1: Grant management subheader for the QoS class = UGS (Unsolicited Grant Services)
The grant management subheader contains only two useful bits, the SI (Slip Indicator), used by the SS to indicate a slip of uplink grants relative to the uplink queue depth, and the PM (Poll-Me) bit, used by the SS to request a bandwidth poll, probably for a needed additional uplink bandwidth with regard to the regular access this UGS SS has. The Slip Indicator bit use by the SS is the following: the BS may provide for long-term compensation for possible bad conditions, such as lost maps or clock rate mismatches, by issuing additional grants. The SI flag allows prevention of the provision of too much bandwidth by the BS. The SS sets this flag once it detects that the service flow has exceeded its transmit queue depth. Once the SS detects that the service flow transmit queue is back within limits, it clears the SI flag. No precise values for these limits are given in the standard.
Piggyback grant-request subheader (see Figure 10.2). This is the case for the QoS classes ≠ UGS. Since the piggybacked bandwidth request subheader does not have a Type field, it will always be incremental. The piggyback request field is the number of bytes of the uplink bandwidth requested by the SS. The bandwidth request is for the CID indicated in the MAC frame header (see Section 8.2).
Figure 10.2: Grant management subheader for the QoS class = UGS (Unsolicited Grant Services). The piggyback request field is the number of bytes of the uplink bandwidth requested by the SS
Extended piggyback request. This is defined by the 16e amendment along with and for the (newly defined) ertPS class. The number of bytes of the uplink bandwidth (piggyback) requested by the SS is on 11 bits (instead of 16). This request is incremental. In the case of the ertPS class, if the MSB (Frame Latency Indicator, or FLI) of the grant management subheader is 1, the BS changes its polling size into the size specified in the LSBs of this field (Frame Latency (FL) field).
The standard (16e) states that FL and FLI fields may be used to provide the BS with information on the synchronisation of the SS application that is generating periodic data for UGS/extended rtPS service flows. The SS may use these fields to detect whether latency experienced by this service flow at the SS exceeds a certain limit, e.g. a single frame duration. If the FL indicates inordinate latency, the BS may shift scheduled grants earlier for this service flow (taking into account the FL).
The standard states that capability of the piggyback request is optional. This probably includes the PM grant management subheader.