The BS shall provide periodic unicast request opportunities. In order for this service to work correctly, the Request/Transmission Policy setting (see 11.4.8.12) shall be such that the SS is prohibited from using any contention request opportunities for that connection. The BS may issue unicast request opportunities as prescribed by this service even if a grant is pending. This results in the SS using only unicast request opportunities in order to obtain uplink transmission opportunities (the SS could still use unsolicited Data Grant Burst Types for uplink transmission as well). All other bits of the Request/Transmission Policy are irrelevant to the fundamental operation of this scheduling service and should be set according to network policy. The key service information elements are the Nominal Polling Interval, the Tolerated Poll Jitter, and the Request/Transmission Policy.

6.2.5.3 Non-Real-Time Polling Service

The Non-Real-Time Polling Service (nrtPS) is designed to support non real-time service flows that require variable size Data Grant Burst Types on a regular basis, such as high bandwidth FTP. The service offers unicast polls on a regular basis, which assures that the flow receives request opportunities even during network congestion. The BS typically polls nrtPS CIDs on an interval (periodic or non-periodic) on the order of one second or less.

The BS shall provide timely unicast request opportunities. In order for this service to work correctly, the Request/Transmission Policy setting (see 11.4.8.12) should be such that the SS is allowed to use contention request opportunities. This results in the SS using contention request opportunities as well as unicast request opportunities and unsolicited Data Grant Burst Types. All other bits of the Request/Transmission Policy are irrelevant to the fundamental operation of this scheduling service and should be set according to network policy. The key service elements are Nominal Polling Interval, Minimum Reserved Traffic Rate, Maximum Sustained Traffic Rate, Request/Transmission Policy, and Traffic Priority.

6.2.5.4 Best Effort service

The intent of the Best Effort (BE) service is to provide efficient service to best effort traffic. In order for this service to work correctly, the Request/Transmission Policy setting should be such that the SS is allowed to use contention request opportunities. This results in the SS using contention request opportunities as well as unicast request opportunities and unsolicited Data Grant Burst Types. All other bits of the Request/Transmission Policy are irrelevant to the fundamental operation of this scheduling service and should be set according to network policy. The key service elements are the Minimum Reserved Traffic Rate, the Maximum Sustained Traffic Rate, and the Traffic Priority.

6.2.6 Bandwidth allocation and request mechanisms

Note that at registration every SS is assigned three dedicated CIDs for the purpose of sending and receiving control messages. Three connections are used to allow differentiated levels of QoS to be applied to the different connections carrying MAC management traffic. Increasing (or decreasing) bandwidth requirements is necessary for all services except incompressible constant bit rate UGS connections. The needs of incompressible UGS connections do not change between connection establishment and termination. The requirements of compressible UGS connections, such as channelized T1, may increase or decrease depending on traffic. Demand Assigned Multiple Access (DAMA) services are given resources on a demand assignment basis, as the need arises.

When an SS needs to ask for bandwidth on a connection with BE scheduling service, it sends a message to the BS containing the immediate requirements of the DAMA connection. QoS for the connection was established at connection establishment and is looked up by the BS.

There are numerous methods by which the SS can get the bandwidth request message to the BS.

6.2.6.1 Requests

Requests refer to the mechanism that SSs use to indicate to the BS that they need uplink bandwidth allocation. A Request may come as a stand-alone Bandwidth Request Header or it may come as a PiggyBack Request (see 6.2.2).

Because the uplink burst profile can change dynamically, all requests for bandwidth shall be made in terms of the number of bytes needed to carry the MAC header and payload, but not the PHY overhead. The Bandwidth Request Message may be transmitted during any of the following intervals:

Request IE

Any Data Grant Burst Type IE

Bandwidth Requests may be incremental or aggregate. When the BS receives an incremental Bandwidth Request, it shall add 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 shall replace its perception of the bandwidth needs of the connection with the quantity of bandwidth requested. The Type field in the Bandwidth Request Header indicates whether the request is incremental or aggregate. Since Piggybacked Bandwidth Requests do not have a type field, Piggybacked Bandwidth Requests shall always be incremental. The self-correcting nature of the request/grant protocol requires that SSs shall periodically use aggregate Bandwidth Requests. The period may be a function of the QoS of a service and of the link quality. Due to the possibility of collisions, Bandwidth Requests transmitted in broadcast or multicast Request IEs should be aggregate requests.

Regarding the grant of the bandwidth requested, there are two modes of operation for SSs: Grant per Connection mode (GPC) and Grant per Subscriber Station mode (GPSS). In the first case, the BS grants bandwidth explicitly to each connection, whereas in the second case the bandwidth is granted to all the connections belonging to the SS. The latter case (GPSS) allows smaller uplink (UL) maps and allows more intelligent SSs to make last moment decisions and perhaps utilize the bandwidth differently than it was originally granted by the BS. This may be useful for real-time applications that require a faster response from the system.

Systems using the 10–66 GHz PHY specification in 8.2 shall use GPSS mode.

6.2.6.2 Grants per connection (GPC) mode

For an SS in GPC mode, the bandwidth requests are addressed explicitly to individual CIDs. Since it is non-deterministic which request is being honored, when the SS receives a shorter transmission opportunity than expected (i.e., scheduler decision, request message lost, etc.), no explicit reason is given. In all cases, based on the latest information received from the BS and the status of the request, the SS may decide to perform backoff and request again or to discard the MAC SDU.

A GPC SS may use Request IEs that are broadcast, directed at a multicast polling group it is a member of, or directed at a unicast CID that represents a service flow belonging to that SS. The burst profile associated with the Request IE shall be used, even if the BS is capable of receiving the SS with a more efficient burst profile. To take advantage of a more efficient burst profile, the SS should transmit in an interval defined by a Data Grant IE directed at a unicast CID that represents a service flow belonging to that SS. Because of this, unicast polling of a GPC SS would normally be done by allocating a Data Grant IE directed at a unicast CID that represents a service flow belonging to that SS. Also note that, in a Data Grant IE directed at a unicast CID that represents a service flow belonging to a GPC SS, the SS shall make bandwidth requests only for the indicated connection.

The procedure followed by SSs operating in GPC mode is shown in Figure 32.

Figure 32—SS GPC mode flow chart

6.2.6.3 Grants per subscriber station (GPSS) mode

For an SS operating in GPSS mode, the bandwidth requests are addressed to the individual connections while the bandwidth grant is addressed to the SS’s Basic CIDs and not explicitly to individual CIDs. Since it is nondeterministic which request is being honored, when the SS receives a shorter transmission opportunity than expected (i.e., scheduler decision, request message lost, etc.), no explicit reason is given. In all cases, based on the latest information received from the BS and the status of the request, the SS may decide to perform backoff and request again or to discard the SDU.