QoS Architecture | WIMAX

In general, the process of requesting and granting QoS in a network can be logically split in two separate layers: application and network layers. The application layer provides the end-user with a simplified and standardized view of the quality level that will be granted for a given service. This layer is not aware of the technicalities of service requirements (such as bandwidth, delay, or jitter) and it does not depend on the technology-dependent issues related to the actual networks that will be traversed (such as a fiber-optic, wireless, or xDSL). On the other hand, the network layer deals with a set of technical QoS parameters, which it maps on network-specific requirements that have to be fulfilled to provide the end-user with the negotiated quality level. Usually, in wired IP networks the mapping is performed at the network layer. However, such an approach is hardly suitable for wireless networks, where there are a number of factors that influence the resource allocation: (i) the availability of bandwidth is much more limited with respect to wired networks, (ii) there is high variability of the network capacity due, for instance, to environmental conditions, (iii) the link quality experienced by different terminals is location-dependent. Therefore, it is often necessary to implement QoS provisioning at the MAC layer, as in IEEE 802.16, so as to gain a better insight of the current technology-dependent network status and to react as soon as possible to changes that might negatively affect QoS.

In IEEE 802.16 the prominent QoS functions of network provisioning and admission control are logically located on the management plane. As already pointed out, the latter is outside the scope of the IEEE 802.16, which only covers the data/ control plane, as illustrated in Figure 1. Network provisioning refers to the process of approving a given type of service, by means of its network-layer set of QoS parameters that might be activated later. Network provisioning can be either static or dynamic. Specifically, it is said to be static if the full set of services that the BS supports is decided a priori. This model is intended for a service provider wishing to specify the full set of services that its subscribers can request, by means of manual or semiautomatic configuration of the BS's management information base (MIB). On the other hand, with dynamic network provisioning, each request to establish a new service is forwarded to an external policy server, which decides whether to approve or not. This model allows a higher degree of flexibility, in terms of the types of service that the provider is able to offer to its subscribers, but it requires a signaling protocol between the BS and the policy server, thus incurring additional communication overhead and increased complexity.

Figure 1: Quality-of-service model of the IEEE 802.16.

Unlike the network provisioning function, which only deals with services that might be activated later, and that are therefore said deferred, the admission control function is responsible for resource allocation. Thus, it will only accept a new service if (i) it is possible to provide the full set of QoS guarantees that it has requested, and (ii) the QoS level of all the services that have been already admitted would remain above the negotiated threshold. Quite clearly, admission control acts on a time scale smaller than that of network provisioning. This is motivated by the latter being much more complex than the former, as pointed out by a recent study  on an integrated end-to-end QoS reservation protocol in a heterogeneous environment, with IEEE 802.16 and IEEE 802.11e  devices. Tested results showed that the network provisioning latency of IEEE 802.16 equipments currently available in the market is in the order of several seconds, whereas the activation latency is in the order of milliseconds.

In IEEE 802.16, the set of network layer parameters that entirely defines the QoS of a unidirectional flow of packets resides into a service flow (SF) specification. Each SF can be in one of the following three states: provisioned, admitted, active. Provisioned SFs are not bound to any specific connection, because they are only intended to serve as an indication of what types of service are available at the BS. Then, when an application on the end-user side starts, the state of the provisioned SF will become admitted, thus booking resources that will be shortly needed to fulfill the application requirements. When the SF state becomes admitted, then it is also assigned a connection identifier (CID) that will be used to classify the SDUs among those belonging to different SFs. However, in this phase, resources are still not completely activated; for instance, the connection is not granted bandwidth yet. This last step is performed during the activation of the SF, which happens just before SDUs from the application starts flowing through the network.

Thus a two-phase model is employed, where resources are booked before the application is started. This is the model employed in traditional telephony applications. At any time it is possible to "put on hold" the application by moving back the state of the SF from active to admitted. When the application stops the SF is set to either provisioned or deleted; in any case, the one-to-one mapping between the service flow identifier (SFID) and the CID is lost, and the CID can be reassigned for other purposes. The SF transition diagram is illustrated in Figure 2.

Figure 2: Service flow transition diagram.

Figure 3 shows the blueprint of the functional entities for QoS support, which logically reside within the MAC CPS of the BS and SSs. Each DL connection has a packet queue (or queue, for short) at the BS (represented with solid lines). In accordance with the set of QoS parameters and the status of the queues, the BS DL scheduler selects from the DL queues, on a frame basis, the next SDUs to be transmitted to SSs. On the other hand, UL connection queues reside at SSs.

Figure 3: Medium Access Control architecture of the Base and Subscriber Stations. 

Bandwidth requests are used on the BS for estimating the residual backlog of UL connections. In fact, based on the amount of bandwidth requested (and granted) so far, the BS UL scheduler estimates the residual backlog at each UL connection (represented in Figure 3as a virtual queue, with dashed lines), and allocates future UL grants according to the respective set of QoS parameters and the (virtual) status of the queues. However, as already introduced, although bandwidth requests are per connection, the BS nevertheless grants UL capacity to each SS as a whole. Thus, when an SS receives an UL grant, it cannot deduce from the grant which of its connections it was intended for by the BS. Consequently, an SS scheduler must also be implemented within each SS MAC to redistribute the granted capacity to the SS's connections.