Adding Quality of Service Extensions to the Enhanced Associativity Based Routing Protocol for Mobile Ad Hoc Networks (MANET)

: This paper described how to discover routes that can satisfy QoS service requirements by using extensions to the Enhanced Associativity Bases Routing Protocol (EABR). These extensions were added to the messages used during route discovery. These extensions specify the service requirements, which must be met by nodes re-broadcasting a route request or returning a route reply for a destination. The performance analysis of EABR with QoS support showed that more overhead was incurred when the intermediate node discover that it cannot support the level of the QoS requested.


INTRODUCTION
QoS is characterized in [1] as a set of service requirements to be met by the network while transporting a packet stream from the source to the destination. The QoS is an agreement or a guarantee by the network to provide a set of measurable pre-specified service attributes to the user in terms of end-to-end network delay, delay variance (jitter), available bandwidth, probability of packet loss and so on. RFC 1633 suggests that with the provisioning of the QoS, the user must be able to get a service whose quality is sufficiently predictable that the application can operate in an acceptable way over the duration of time determined by the user [10] .
A lot of work has been done in supporting the QoS in the Internet, but unfortunately none of them can be directly used in MANETs because of the bandwidth constraints and dynamic network topology of MANETs [12] . To support QoS, the link state information such as delay, bandwidth, cost, loss rate, and error rate in the network should be available and manageable. However, getting and managing the link state information in MANETs is very difficult because the quality of a wireless link is apt to change with the surrounding circumstances. Furthermore, the resource limitations and the mobility of hosts make things more complicated and challenging with limited available resources in a dynamic environment.
In the literature, the research on the QoS support in MANETs includes QoS models, QoS resource reservation signaling, QoS routing, and QoS Medium Access Control (MAC). Because all of the research just discusses a certain aspect of QoS in MANETs, it is difficult for the readers to understand the relationships among the research. Without a whole picture, it is even impossible to understand and evaluate the importance of a particular method. In this paper, a comprehensive introduction to the current work on QoS support in MANETs is presented. In [2] Wu & Harms presented the relationships among the QoS research as follows.

QoS Challenges in MANETs:
Ad hoc networks differ radically from the conventional wired or cellular networks. The characteristics of these networks make the task of providing QoS guarantees in these networks extremely difficult. Some of these difficulties are well known and well pointed out in many papers including [2,3,4] . These challenges are discussed briefly below. In [5] Harpreet found some unique problems associated with the most popular routing algorithms for MANETs and also present some difficulties encountered while designing the model for providing QoS guarantees. The following are some QoS challenges in MANET 1. Unpredictable Network Topology 2. Scarce Radio Bandwidth 3. Limited Battery Power

Synchronization Effects
The QoS Models: Before going into the detail of the available models, lets define a set of metrics associated with QoS performance in networks that will be used throughout the rest of the thesis. 1. Bandwidth Bound: The minimum rate at which packets can be transmitted from the source to the destination throughout the length of duration of the flow. 2. End-to-end Network Delay Bound: The maximum amount of time a packet takes to reach from the source to the destination. This bound is essential for real-time applications such as voice conversations. 3. Delay Variance Bound: The maximum time difference between the arrival of two consecutive packets at the destination. This metric is crucial in defining the length of the buffer at the receiver for real-time applications. 4. Packet Delivery Ratio: The ratio of the number of packets reaching the destination to the number of packets sent by the source. This metric defines the threshold below, which the performance of certain applications starts to degrade.

TCP Good:
The number of bytes of a TCP connection reaching the destination per second (measured in kbps). This metric is an important indication of the amount of congestion in the network. 6. Several QoS schemes and models have been developed in general for the wired Internet and also for MANETs. Two well-known QoS models for the Internet are briefly described; the Integrated Services Model and the Differentiated Services model and describe why these models are not directly applicable to MANETs [11] .

Classification of the QoS Models for MANETs: The
Intserv and the Diffserv model are not directly suitable in the context of MANETs. This is because of the characteristics of MANETs such as mobility, broadcast nature of the medium and so on. Many QoS schemes for MANETs can be found in literature some are based on the modification of the conventional models. These schemes can be broadly classified into three categories: 1. QoS aware routing protocols 2. Link layer based schemes 3. Independent schemes

QOS for Enhanced Associativity Based Routing:
Using the extensions in this paper, EABR will enable mobile nodes in MANET to specify, as part of a BQ, Quality of Service requirements that a route to a destination must satisfy. In particular, the BQ MAY include a QoS Object extension, which specifies bandwidth and/or delay parameters. In order to enable measurements to be accumulated for end-to-end delay, EABR also provides an Accumulated Value extension. The work of this paper was based on the ideas of the authors of AODV as presented in [6] . Any QoS parameters that have to be measured and accumulated at each hop along the way can be stored along with the associated BQ message. Every BQ QoS extension also carries with it a "session-ID" value, which is used to identify the specific QoS flow that will be established according to the parameters of the BQ. The session-ID has to be stored along with the route table information associated with the particular flow that might be created because of the extended BQ. The routing table record will include in addition to the other attributes the session-ID, which uniquely identifies every flow. The routing table contents are detailed in Table 1.
If, after establishment of a QoS route, any node along the path finds out that the requested QoS parameters can no longer be maintained, that node MUST transmit a QOS_LOST message back to the source node, which had originally requested the now un-maintainable level of QoS. This typically requires additional information to be stored in each perdestination route table entry. The QOS_LOST message identifies the broken flow by including the session-ID value associated with the flow.
For the QoS parameters that are affected by cumulative measures at each intermediate node of a routing path, an extension is defined to enable a running total to be maintained for that measure as the BQ is propagated. Each intermediate node that elects to forward a BQ MUST adjust the accumulated value in the extension so that an accurate determination must be made. This approach is better than modifying the values in the QoS object directly, because it enables the original request to be authenticated whenever that is required. An intermediate node that can satisfy a BQ with QoS parameters specified typically SHOULD always rebroadcast the RREQ, even if it has a route to the destination. This contrasts with the situation with unconstrained BQ messages, because without any need for QoS an intermediate node is allowed to reply to the source node if it has a route to the destination. Unfortunately, the intermediate node is not likely to have current enough information about whether the remaining nodes along the path to the destination can also satisfy the requested QoS. Effectively, according to this specification, every QoS path to the destination will be ultimately approved by the destination itself along with every intermediate node along the path from the source to the destination. When the destination issues the REPLY message, it MUST also copy over the QoS extension into the REPLY message. Each intermediate node forwarding the REPLY message back to the originator of the BQ message also MUST copy over the QoS extension.
In the future, if a specification is made enabling an intermediate node to have reliable information about the remaining nodes along the path, then the node could issue an REPLY, along with an unjustified REPLY unicast towards the destination.
The unjustified REPLY would then enable the remaining nodes to make the proper resource reservations that would be needed to satisfy the QoS route discovery request. The EABR QoS Object Format: QoS information will be encoded into a standard format. The standard format allows both complete flexibility for specification of arbitrary values for various QoS requirements, and also allows very compact representation, especially for the well-known requirements of common applications such as voice over IP (VoIP). In this section, the standard object format is presented. This object format is used as the main part of the QoS Object Extension. RSV: Sent as 0, value unused and undefined on reception QoS Profile Type: If nonzero, an index for a list of QoS parameter field definitions and default values for those fields. If zero, the fields are as listed below in this section, and there are no default values. A : If this bit is set, the Authentication Data field is present following the bit vectors indicating the nondefault values. N : If QoS Profile Type is zero, this bit MUST be zero. Otherwise, if the QoS Profile Type is nonzero, when the `N' bit is set, the 16 bits following the "session-ID" field are present and part of the "Non-Default Values" bit vector Session-ID : 16-bit value identifying the flow which could be set up as a result of the extended route discovery operation controlled by this BQ message. Non-Default Values Bit Vector: a bit vector with one bit for each field parameter field defined for the particular QoS Profile Type number. Authentication Data: When present, supplies authentication data so that nodes receiving the BQ can check whether or not the data in the QoS object is the same as specified by the source node. QoS Parameter Fields: defined in accordance with the QoS Profile Type. If the profile type is 0, then the fields are as defined below in this section. For QoS Profile Type zero, the following parameter fields are defined, and MUST appear in this order as indicated by the corresponding bit in the "Non-Default Values Bit Vector": Capacity Requirement: 32-bit number, measured in bits/second Maximum Permissible Delay: 16-bit number, measured in milliseconds Maximum Permissible Jitter: 16-bit number, measured in milliseconds Traffic Class: According to Differentiated Services Code Points Some fields that might occur for profile type not equal 0 Peak data rate, Maximum permissible BER. The EABR QoS Extensions: Several extensions are needed in the routing table structure and the BQ and REPLY messages for supporting QoS routing. The extensions needed for the routing table are first described. The extensions defined in the section after that conform to the format defined for extensions to BQ and REPLY messages as specified in [7] and [8] and analyzed in [9] . The EABR Routing The Accumulated Value Extension MUST be appended to a BQ by a node re-broadcasting a request for a QoS route whenever it is needed to measure the accumulated value of the parameter of the type given in the Value Type field; the accumulation occurs at each node starting from the originating node. This allows each next intermediate node, or the destination, to determine whether the path can still meet the required parameter specification within the QoS Object data.

QoS Object Authentication Extension: The QoS
Object Authentication Extension may be used so that nodes receiving QoS route discovery message may verify that the source node in fact originated the QoS request. This extension does not verify the contents of any extension other than the QoS Object extension, because other extensions may have variable fields that are modified in transit. Link Capacity, Delay, Jitter and QOS LOST Message specification: A capacity (bandwidth) specification in a QoS object does not require the inclusion of any Accumulated Value extension in the BQ. Any node that has sufficient unreserved link capacity to forward data, or in the case of the destination to supply data, does not modify any contents of the BQ for the purpose of fulfilling a bandwidth specification in the QoS object.
In order to fulfill such a specification, a node has to take into account neighborhood traffic conditions. If recent history indicates that neighboring transmissions will likely interfere with the node's ability to carry out the indicated bandwidth specification, then the node SHOULD NOT rebroadcast the BQ. Exact mechanisms for estimating neighborhood traffic levels are away from the scope of this paper. Additional signaling and protocols may be defined in the future in order to obtain a higher probability of collecting the necessary neighborhood bandwidth utilization information.
If the QoS object in the BQ specifies a delay parameter, then any node forwarding the request MUST ensure that an Accumulated Delay extension is present in the BQ before forwarding the message. A node that agrees to satisfy delay constraints has to measure the average time it is currently requiring to forward a data packet, including processing time, average queuing delays and propagation delays. Call this average time the FORWARDING_DELAY. Before forwarding the BQ, an intermediate node MUST compare the current value of its FORWARDING_DELAY to the current value of the difference between the Maximum Delay value in the QoS object extension, and the value in the Accumulated Delay Extension. If the remaining delay is less, the node MUST discard the BQ and not retransmit it. Otherwise, the node subtracts FORWARDING_DELAY from the value in the Accumulated Value extension and continues processing the BQ.
A node forwarding a BQ also records the Source ID in the BQ message in the list of source nodes requesting delay guarantees in the corresponding destination's route table entry. These source nodes are to be notified with a QOS_LOST message in case there is a significant change in FORWARDING_DELAY at this node.
If the QoS object in the BQ specifies a jitter parameter, then any node forwarding the request MUST ensure that an Accumulated Jitter extension is present in the BQ before forwarding the message. Before forwarding the BQ, an intermediate node MUST compare its recently computed typical jitter value (call it NODE_JITTER) to the current value of the difference between the Maximum Jitter value in the QoS object extension, and the value in the Accumulated Jitter Extension. If the remaining allowable jitter is less, the node MUST discard the BQ and not process it any further. Otherwise, the node subtracts NODE_JITTER from the value in the Accumulated Jitter extension and continues processing the BQ.
A node forwarding a RREP with the QoS extension also records the Source IP address in RREP message in the list of source nodes requesting jitter guarantees in the corresponding destination's route table entry. These source nodes are to be notified with an ICMP QOS_LOST message in case there is a change in NODE_JITTER at this node.
The QOS_LOST message is generated when an intermediate node experiences a significant change in its ability to live up to the QoS guarantees it has made as part of generating a REPLY during the QoS Route Discovery process.
The QOS_LOST message is forwarded to all sources potentially affected by the change in the QoS parameter. These are sources to which a REPLY with a QoS extension has been forwarded in the past.

RESULTS AND DISCUSSION
Performance Analysis of the EABR with QOS Support: The analysis of the EABR with QOS support depends also on two the two factors described in the previous papers [89] , namely Operation complexity (OC): which can be defined as the number of steps required to perform a protocol operation. The second factor is the Communication complexity (CC) which can be defined as the number of messages exchanged in performing a protocol operation.
The performance analysis of the EABR with QOS support is the same as EABR except for more computation on the intermediate nodes to comply with the QOS requirements and the size of the control messages will be varying. But the total number of operations performed and total number of messages exchange will remain the same in terms of Operation and communication complexities analysis.
There is only one additional case that in which the QOS-Route will be invoked, specifically when any intermediate node fails to provide the required QOS, in this case the source will be notified by a QOS-LOST message sent by that node and a new QOS-Route discovery will be initiated by the Source Node.
Beside that the following variables are defined in Table 2 to be used when referring to time and communication complexities.
On the other hand broadcasted query message will traverse the whole network diameter in searching for the destination, so it needs to perform steps equal to the network diameter D. While the reply message will traverse the diameter of all the nodes forming the route from the destination node to the source node (Z). Thus the initial route discovery phase will require performing of D+Z steps. This is summarized in Table 3.

CONCLUSION
Conventional routing algorithms aim at finding a route to the destination with minimum number of hops without considering factors such as congestion along the links and bandwidth availability along a path. Attempts have been made at devising routing algorithms that take QoS factors into account and find a path from the source to the destination that can satisfy the requirements This paper described how to discover routes that can satisfy QoS service requirements by using extensions to the Enhanced Associativity Bases Routing Protocol routing protocol. These extensions are added to the messages used during route discovery. These extensions specify the service requirements, which must be met by nodes re-broadcasting a route request or returning a route reply for a destination.
The performance analysis of EABR with QoS support showed that more overhead is incurred when the intermediate node discover that it cannot support the level of the QoS requested.