Showing posts with label qos support. Show all posts
Showing posts with label qos support. Show all posts

Thursday, September 9, 2010

QoS Support in the 802.16 MESH Mode

In stark contrast to the PMP mode, the QoS in MESH mode is provisioned on a packet-by-packet basis. Thus, the per-connection QoS provisioning using the DSx messages as introduced previously is not applicable. This design decision helps to reduce the complexity of implementing the MESH mode considerably. However, the MESH mode even with this simplification is quite complex.
Add a note hereThe CID in the MESH mode is shown in Figure 1. The mesh CID is used to differentiate the forwarding service a PDU should get at each individual node. As can be seen from Figure 1 it is possible to assign a priority to each MAC PDU. Based on the priority the transmission scheduler at a node can decide if a particular PDU should be transmitted before another. The field reliability specifies the number of retransmissions for the particular MAC PDU (if needed). The drop precedence specifies the dropping likelihood for a PDU during congestion. Messages with a higher drop precedence are more likely to be dropped. In effect, QoS specification for the MESH mode is limited to specifying the priority of a MAC PDU, the reliability, and its drop precedence. Given the same reliability and drop precedence and MAC PDU type (see Figure 1), the MAC will attempt to provide a lower delay to PDUs with higher priority. This QoS mechanism, however, does not allow the node to estimate the optimal bandwidth requirement for transmissions on a particular link. This is because (just based on the previous interpretation as presented in the 802.16 standard), the node is not able to identify the expected arrival characteristics of the traffic and classify it into the different categories as traffic requiring UGS, rtPS, nrtPS, or BE service.


Figure 1: MESH connection identifier (CID).
Add a note here
Add a note hereTo summarize, QoS mechanisms in the MESH mode are not consistent with those provided for the PMP mode. In addition, the per-packet QoS specification for the MESH mode does not allow a node to optimally estimate the amount of bandwidth required for transmission on a link, as no information about the data scheduling service required for the traffic is included explicitly in the QoS specification in the mesh CID.
Add a note hereWe next give an overview of the existing bandwidth request and grant mechanisms specified for the MESH mode of 802.16. This is followed by a description of our proposed QoS architecture, which enables efficient bandwidth management in the MESH mode and allows support of the data scheduling services consistent with those outlined for the PMP mode.

Sunday, September 5, 2010

QoS Support in the 802.16 PMP Mode

The 802.16 MAC is connection-oriented. QoS is provisioned in the PMP mode on a per-connection basis. All data, either from the SS to the BS or vice versa is transmitted within the context of a connection, identified by the connection identifier (CID) specified in the MAC protocol data unit (PDU). The CID is a 16-bit value that identifies a connection to equivalent peers in the MAC at both the BSs as well as the SSs. It also provides a mapping to a service flow identifier (SFID). The SFID defines the QoS parameters which are associated with a given connection (CID). The SFID is a 32-bit value and is one of the core concepts of the MAC protocol. It provides a mapping to the QoS parameters for a particular data entity.
Figure 1 shows the core objects involved in the QoS architecture as specified in the standard for the PMP mode. As is seen from Figure 1 , each MAC PDU is transmitted using a particular CID, which is in turn associated with a single service flow identified by a SFID. Thus, many PDUs may be transmitted within the context of the same service flow but a single MAC PDU is associated with exactly one service flow. Figure 1 also shows that there are different sets of QoS parameters associated with a given service flow. These are the "ProvisionedQoSParamSet," "AdmittedQoSParamSet," and "ActiveQoSParamSet." The provisioned parameter set is a set of parameters provisioned using means outside the scope of the 802.16 standard, such as with the help of a network management system. The admitted parameter set is a set of QoS parameters for which resources (bandwidth, memory, and so on) are being reserved by the BS (SS). The active parameter set is the set of QoS parameters defining the service actually being provided to the active flow. For example, the BS transmits uplink and downlink maps specifying bandwidth allocation for the service flow's active parameter set. Only an active service flow is allowed to transmit packets. To enable the dynamic setup and configuration of service flows, the standard specifies a set of MAC management messages, the so-called dynamic service messages (DSx messages). These are the dynamic service addition (DSA), dynamic service change (DSC), and the dynamic service deletion (DSD) messages. The various QoS parameters associated with a service flow are negotiated using these messages.


Add a note here
Figure 9.2: Quality-of-service (QoS) object model for IEEE 802.16-2004 point-to-multipoint mode.
Add a note hereTypical service parameters associated with a service flow are traffic priority, minimum reserved rate, tolerated jitter, maximum sustained rate, maximum traffic burst, maximum latency, and scheduling service. The BS may optionally create a service class as shown in Figure 1 . A service class is a name given to a particular set of QoS parameters, and can be considered as a macro for specifying a set of QoS parameters typically used. The value for the scheduling service parameter in the QoS parameter set specifies the data scheduling service associated with a service flow. The 802.16 standard currently defines the following data scheduling services: Unsolicited Grant Service (UGS), Real-Time Polling Service (rtPS), Non-Real-Time Polling Service (nrtPS), and Best Effort (BE). The UGS is meant to support real-time data streams consisting of fixed-size data packets issued periodically. The rtPS is meant to support data streams having variable-sized data packets issued at periodic intervals. The nrtPS is designed to support delay-tolerant streams of variable-sized data packets for which a minimum data rate is expected. The BE traffic is serviced on a space-available basis. For service flow associated with the scheduling service UGS, the BS allocates a static amount of bandwidth to the SS in every frame. The amount of bandwidth granted by the BS for this type of scheduling service depends on the maximum sustained traffic rate of the service flow. For rtPS service flows, the BS offers real-time, periodic, unicast request opportunities meeting the flow's requirements and allowing the SS to request a grant of the desired size. For nrtPS the BS, similar to the case of a rtPS service flow, offers periodic request opportunities. However, these request opportunities are not real-time, and the SS can also use contention-based request opportunities in addition to the unicast request opportunities for a nrtPS service flow as well as the unsolicited data grant types. For a BE service flow no periodic polling opportunities are granted. The SS uses contention request opportunities, unicast request opportunities, and unsolicited data grant burst types. 
Add a note hereTo summarize, the PMP mode provides the BS with efficient means to manage the bandwidth optimally and at the same time satisfy the requirements of the individual admitted service flows.

Related Posts with Thumbnails