Distributed admission control protocol for end-to-end QoS assurance in ad hoc wireless networks

Abstract

To reserve end-to-end bandwidth in quality of service (QoS) supported wireless ad hoc networks, local bandwidth requirement should be carefully determined by considering the number of contending nodes in an interference range. In this article, we propose a novel admission control protocol, called DACP (distributed admission control protocol), which is implemented over a reactive ad hoc routing protocol with minimal overhead. DACP computes the required bandwidth for end-to-end band-width provision at each node and estimates the available bandwidth at the medium access control layer. After that, DACP makes a decision for admitting a flow in a per-hop basis. Extensive simulations are carried out via the OPNET simulator. The simulation results demonstrate that DACP not only provides guaranteed end-to-end resource but also reduces the control overhead to provide QoS support, compared with the existing admission control schemes.

1 Introduction

Over the last few years, research on quality of service (QoS) provisioning in wireless ad hoc networks has increased significantly. These networks can be adopted in commercial environments in which there are multimedia systems that enable users to access multimedia data, such as IP television and voice over IP (VoIP). Moreover, these multimedia systems need better service quality than best-effort service. To this end, an admission control scheme including resource reservation in wireless ad hoc networks should be devised to support the end-to-end bandwidth demanded by wireless multimedia applications.

The existing works on QoS in wireless ad hoc networks explore QoS routing, QoS medium access control (MAC), power management, QoS provisioning model, and so on [1–4].

However, they are not appropriate solutions for providing users with QoS because of system complexity and implementation overhead. Instead, simple admission control with low complexity can be an alternative approach.

In this article, we propose a distributed admission control protocol (DACP). DACP is implemented over an ad hoc on-demand distance vector (AODV) routing protocol and uses a route request (RREQ) packet during the route discovery procedure for admission control. DACP utilizes Hello messages to calculate the number of contending nodes within the sender's interference range, which can significantly reduce the network overhead. In addition, DACP achieves more accurate estimation of available local bandwidth by exploiting the interaction between IEEE 802.11 MAC and AODV routing protocol. Also, in point of the complexity of the proposed algorithm for admission control, DACP only use RREQ message of AODV protocol. This means DACP can reduce the complexity for establishing QoS session and be sample admission control scheme with low complexity. To demonstrate the effectiveness of DACP, we conduct extensive simulations via the OPNET simulator [5]. Simulation results indicate that DACP can support accurate resource reservation for QoS provision and alleviate network saturation and achieve higher throughput and lower end-to-end delay with low signaling overhead and low complexity.

The remainder of the article is organized as follows. Section 2 summarizes the previous works on QoS in wireless ad hoc networks. In Section 3, the bandwidth requirement for the end-to-end bandwidth reservation is discussed, and an accurate estimation method for the local available bandwidth is proposed in Section 4. Section 5 describes the DACP, and Section 6 demonstrates the simulation results. Finally, Section 7 concludes this article.

2 Previous QoS works in wireless ad hoc networks

Several QoS provisioning schemes for resource reservation have been proposed in [1, 3, 4]. These mechanisms, for resource discovery and admission decisions, send probe packets on preselected routes. Each node predicts the achievable QoS based on available resources and admits the QoS session if the QoS requirement of end-to-end path delivered by the probe packet is sufficient. Then, these mechanisms using the probe packets have signaling overhead to provide QoS assurances. In [6], another alternative is to probe routes end-to-end and use the interval between packet arrivals to calculate the route capacity. Differentiated scheduling and medium access algorithms have been proposed in [7] to provide a prioritized service model to guarantee real-time traffic over best-effort traffic. These solutions still face the issue of reducing the overhead for QoS guarantee. In [8], the softMAC architecture is addressed. The softMAC scheme resides at layer 2.5 between the MAC layer and the network layer. It takes the autorate feature of 802.11 into account. Then, to establish link capacities, the experienced delay between transmitting back-to-back probe packets of various sizes is used. This scheme also has the signaling overhead of probe packet to provide QoS assurances. In [9], the authors highlight the necessity of local data control and admission control to guarantee QoS for real-time traffic under high traffic load conditions. Further, in this model, each node maps the measured traffic load condition into backoff parameters locally and dynamically. However, this model does not consider bandwidth reduction in multi-hop ad hoc environments. On the other hand, admission control schemes for wireless multi-hop environments have been also proposed in [10–15]. Contention-aware admission control protocol (CACP) [10] considers the contention among flows within a node's interference range and uses on-demand resource discovery-based scheme to provide QoS assurances. In CACP, three methods are proposed. First, an admission request packet is flooded to a distance of two hops to test the node's carrier sensing (CS) neighbors' residual capacities. Second, CACP uses a higher power to transmit an admission request packet to ensure it reaches all the nodes within the CS range with a single transmission. The third method employs passive resource discovery-based approach. These methods' overhead depends on the node density. In addition, while the admission request packet is transmitted, a high level of interference is produced at neighbor nodes. Furthermore, CACP is based on inaccurate estimation required bandwidth at each node along the established end-to-end route for making the admission decision. In [16], the perceptive admission control (PAC) protocol is introduced. This protocol operates on a similar to CACP. It uses passive monitoring to estimate the available bandwidth at the node and its neighbor node. However, PAC's monitoring threshold is set such that the average CS range is less than that used by CACP. PAC also has the problem about a high level of interference like CACP. Admission control and bandwidth reservation (ACBR) [17] is compatible with the existing AODV routing protocol. A shortcoming of ACBR is that it only tests the available capacity of the neighbor nodes of a route, and only considers intra-route contention in 1-hop node. In addition, it also uses inaccurate calculation of the required bandwidth at each node along the established end-to-end route, because it does not take the contenting nodes in the interference range into account. In other words, this scheme only considers the contention of nodes within a node's transmission range.

3 Revisit: bandwidth requirement for end-to-end bandwidth reservation

3.1 The network model

We consider wireless ad hoc networks consisting of mobile devices, such as laptop and Smartphone. In the networks, each node communicates over a shared medium. Each node has a fixed radio range and exchanges messages only with nodes with this range. For medium access, the distributed coordination function (DCF) in IEEE 802.11 [3] is assumed, as the access method used in ad hoc mode. IEEE 802.11 MAC uses a fourway handshake scheme (RTS/CTS/Data/ACK exchange).

3.2 End-to-end QoS assurance

In the networks with the system for QoS support, applications of each node with end-to-end flows require specific end-to-end bandwidth from the network. To enable end-to-end bandwidth reservation, the required bandwidth of a flow at each node should be carefully determined. Specifically, the amount of the required bandwidth is affected the location of the node, i.e., source, intermediate, and destination nodes require different local bandwidth for end-to-end bandwidth reservation. Therefore, the required local bandwidth should be determined in a per-hop basis.

Existing schemes in [10, 11] estimate local bandwidth requirement based on the number of contenting nodes on the route in the interference or transmission ranges. However, they do not consider the relation between the end-to-end throughput and the hop number over the end-to-end route. Therefore, we revisit the required local bandwidth for end-to-end bandwidth reservation in this section.

Basically, in IEEE 802.11 ad hoc networks, a node cannot transmit and receive data simultaneously. In other words, to guarantee a packet transmission on a single-hop path, the same amount of bandwidth is needed at the sender and the receiver. If the same packet was transmitted over a multi-hop path in terms of an intra-flow, the bandwidth requirement is cumulative. And the accumulative bandwidth requirement is different according to whether or not the receiver transmits the same packet toward a destination node and the number of contention links in the interference range. The following subsection describes the analysis in detail.

3.3 Local bandwidth requirement on end-to-end route

From [18], the end-to-end throughput f(x) can be described depending on the hop number on the route, h, as

$$\begin{array}{cc}\hfill \mathsf{\text{Min\_Channel\_Bandwidth,}}\hfill & \hfill h=1,\hfill \\ \hfill f\left(x\right)=\hfill & \hfill \frac{\mathsf{\text{Min\_Channel\_Bandwidth}}}{2},\hfill & \hfill h=2,\hfill \\ \hfill \frac{\mathsf{\text{Min\_Channel\_Bandwidth}}}{3},\hfill & \hfill h=3,\hfill \\ \hfill \frac{\mathsf{\text{Min\_Channel\_Bandwidth}}}{4},\hfill & \hfill h\ge 4.\hfill \end{array}$$

(1)

Now consider a chain network in Figure 1, where there are six nodes consisting of the source N₁, the destination N₆, and four intermediate nodes N₂, N₃, N₄, and N₅. The source node N₁ wants to send packets with transmission rate of a flow, R, to the destination node. In such a case, N₂ and N₃ cannot transmit simultaneously because N₂ and N₃ are included in N₁'s transmission range and interference range. Thus, N₁ is not able to transmit at the same time when N₂ transmits a packet to N₃ or N₃ transmits a packet to N₄. If the hop number of the end-to-end route is more than 3, in order to transmit the same packet to the destination node successfully at the source node, the local bandwidth of 3R is required. Note that this value does not consider the overhead of the header, RTS, CTS, and ACK packets.

Figure 1

The example of estimating the end-to-end throughput in a chain network.

In Figure 1, when N₃ wants to send the packet to N₄ through link 3, all the nodes in the networks should be deferred because they are included in N₃'s and N₄'s interference range. The existing work [10, 11, 17] analyzes this case in terms of the contending nodes that are all the nodes within CS range of the transmission path. Therefore, it is shown that 3R[10, 11] or 5R[17] is required at the intermediate node as the local bandwidth. However, both values are inaccurate. This is because links 1 and 5 are used simultaneously to transmit a packet of intra-flow at the point of link 3. Therefore, if intra-flow wants to be transmitted at N₃ using link 3, links 1 and 5 affect the transmission of intra-flow of N₃ simultaneously. In other works, if end-to-end hop number is more than 4, four contending links are affected at an intermediate node, such as N₂, N₃, and N₄. As a result, 4R is only required at N₂, N₃, and N₄. This result is based on the analysis in [18].

Figure 2 shows the bandwidth requirement at each hop according to the number of hops in an end-to-end route. In the case of an end-to-end route with 1-hop, when the source transmits a packet, the destination node receives simultaneously. Thus, both nodes need only R, as the required bandwidth requirement. In the 2-hop case, 2R is required at all the nodes, because all the nodes belong with the mutual interference range. In the 3-hop case, the source node and two intermediate nodes need 3R, and the destination node requires 2R since the destination node does not send the intra-flow. Figure 2d and e shows the case where there are more than 4-hops. In these cases, the source node, the intermediate nodes, the last intermediate node, and the destination node need 3R, 4R, 3R, and 2R, respectively. Here, the last intermediate node needs 3R. In this case, the deference of the transmission of the destination node is not considered because the destination node does not transmit a packet. In our protocol, based on the results above, when each node receives a RREQ packet, it can make the admission control decision.

Figure 2

The bandwidth requirement at each hop according to the hop number on a route.

4 Available local bandwidth estimation

In our work, we estimate the available local bandwidth at a node in terms of MAC throughput. In IEEE 802.11 networks, a packet generated by an application layer is handled through a reliable transmission service including a fourway handshake scheme in the MAC layer. Thus, we have to continuously observe the throughput achieved by the MAC layer. To get accurate available MAC throughput, two parameters, such as the available channel time and the average MAC forwarding delay, are used.

4.1 Available channel time (T_{ava_chann_time})

To estimate the available bandwidth, intuitively, each node has to determine how much free channel is available by listening to the channel every measurement time. Free channel time is available channel time of a node. It chooses the measurement time (T_{meas_time}) that is the same as the default broadcast interval of a Hello message in the AODV routing protocol.

Carrier sense can be used to determine both free channel time (T_{ava_chann_sub>time}) and busy channel time (T_{busy_time}). Available channel time (T_{ava_chann_time}) should be the remaining allocable bandwidth for a node during the measurement time as shown in Figure 3. The IEEE 802.11 MAC detects which channel is in a free state or busy state, by the following:

Figure 3

The example of determining the free and busy channel time during the measurement time.

• Busy state: the value of the network allocation vector (NAV) is set, receiver state is any other state except for idle, and the transmitter state is not idle.

• Free state: the value of the NAV is less than the current time, receiver state is idle, and transmitter state is idle.

4.2 Available local bandwidth

An available local bandwidth is determined with available channel time and average MAC forwarding delay during the measurement time in the forwarding queue of a node. The average MAC forwarding delay is defined as the average time from the time when a new arrival packet is in a forwarding queue of a node to the time when the node receives the MAC ACK of successful transmission of the packet. Thus, as shown in Figure 4, this value includes queuing time in a forwarding queue and the forwarding transmission delay of a link. In addition, MAC forwarding delay for the transmission of a packet is different in real network environments, because of retransmission due to the collision and variation of queuing delay according to network congestion. Thus, in our work, we use the average value of the forwarding time taken to complete transmission for a packet, including MAC access delay for accessing the channel and the time for retransmission. The MAC forwarding delay, T_{mac_forwarding_delay}, is shown as

Figure 4

The MAC forwarding delay.

$$T_{\mathsf{\text{mac\_forwarding\_delay}}}=T_{\mathsf{\text{ack}}}-T_{\mathsf{\text{enqueue}}}.$$

(2)

The weighted moving average is used to smooth the estimated MAC for warding delay of a forwarding queue. After the forwarding of each packet is completed, the value is updated as

$${\bar{T}}_{\mathsf{\text{mac\_forwarding\_delay}}}=\alpha {\bar{T}}_{\mathsf{\text{mac\_forwarding\_delay}}}+\left(1-\alpha \right)T_{\mathsf{\text{mac\_forwarding\_delay}}},$$

(3)

where ${\bar{T}}_{\mathsf{\text{mac\_forwarding\_delay}}}$ is the average value to the previous packet, is the weighting factor (α < 1), whose optimum value has been computed to be 0.9, following a comprehensive simulation under traffic conditions, and T_{mac_forwarding_delay} is the forwarding delay achieved by the current packet. The MAC forwarding delay also includes the time consumed for the head-of-line packet to be transmitted to the physical layer. This means the overhead of the transmission in the contending area is included. In particular, the period for successful RTS/CTS exchange is included, if this exchange is used for packet transmission. Similarly, if the initial transmission of the packet is delayed due to one or more collisions generated by other nodes within the transmission range, multiple numbers of backoff periods, SIFS and DIFS may also be included. With the average MAC forwarding delay and available channel time, the expected number of packets, N, which can be transmitted during the next measurement period, can be estimated. Thus, N is determined, as

$$N=\frac{T_{\mathsf{\text{free\_channel\_time}}}}{{\bar{T}}_{\mathsf{\text{mac\_forwarding\_delay}}}},$$

(4)

where N is the expected number of packets that are able to be transmitted during the period of next measurement time. Using the value, the available local bandwidth can be predicted as

$$B_{\mathsf{\text{available}}}=\frac{N\times PL}{T_{\mathsf{\text{mea\_time}}}},$$

(5)

where PL is any MAC layer payload length transmitted in the current measurement time.

5 A new admission control based on AODV protocol

Basically, in our admission control, each node receiving the RREQ packet first determines which of the destination nodes of the RREQ packet is in its interference range, and then with the above result, it predicts its hop number on end-to-end route through hop number in the RREQ packet. Thus, our protocol performs admission control during the route discovery procedure. To predict an end-to-end hop number, our protocol needs the information of the first neighbor nodes and second neighbor nodes. To this end, we can utilize the Hello message specified in the AODV protocol. This overall procedure reduces the number of a RREQ packet during the route discovery for a QoS session. Moreover, since the number of routing packet can be reduced, the overall network performance can be improved.

In this section, AODV protocol-based distributed admission control (DAC) including resource reservation is elaborated. The reason to choose AODV as the platform for our QoS model is that AODV uses "Hello" messages for keeping track of its continued connectivity to its next active nodes. In our model, through the "Hello" message, each node makes up the information of its first neighbor nodes and its second neighbor nodes.

5.1 The connectivity tables

Each node construes the two connectivity tables that are the first neighbor table and the second neighbor table as shown in Figure 5. The reason to construe these tables is to check the contention node that generates the contention link that affects intra-flow with low network overhead. In our admission control policy, when a node makes the admission decision, one will obtain the number of contention links within its interference range through the connectivity tables. The existing mechanism, through the hello message, can directly obtain the first neighbor nodes' information. However, there is no way to get the information of second neighbor nodes directly. Here, second neighbor nodes mean the 2-hop neighbor nodes in the interference range. They can be contention nodes when transmitting intra-flow. In existing work [10], there are the schemes to get the second neighbor nodes' information. This is achieved by disseminating node information though high transmission power to reach the 2-hop neighbor nodes, and setting up a separate signaling channel to broadcast node information. However, these mechanisms not only consume much more power, and cause much more interference, but also require additional overhead of control message, in terms of bandwidth consumption. However, in our work, the hello message is used to provide the information of the second neighbor nodes. Through the hello message, each node keeps track of its continued connectivity to its next active nodes and broadcasts the hello message which includes the first neighbor table consisting of the information of its own first neighbor nodes as shown in Figure 5. Therefore, in proposed admission control scheme, each node construes the two connectivity tables, first neighbor table and second neighbor table, through the hello message as shown in Figure 5. Each node determines its second neighbor nodes through the hello message received from its first neighbor nodes. This is recorded in the second neighbor table at the node and is updated periodically. This approach to gather the second neighbor nodes' information, suffers from the problem that it cannot indicate all the nodes' information within the node's interference range, such as node J, illustrated in Figure 5. As mentioned above, node's interference and transmission ranges are different. The outside circle indicates node A's interference range, and the other dotted circles indicate each node's transmission range. Thus, although the hello message is used in the proposed scheme, node J does not fall into node A's second neighbor node. In other words, there is no way that node A will never know the existence of node J. However, this situation does not become a problem in the QoS support provided by our work. The reason for this is as follows. When node A makes the admission control decision, node J does not participate in a path which will be established for the intra-flow through node A. Therefore, it is unnecessary to take this problem into account at node A. Once a node receives a hello message from its neighbor nodes, it checks whether this hello message is an updated one by examining the timestamp in the message. In our work, a cache is made for this table.

Figure 5

The example of the connectivity tables that are the first neighbor table and the second neighbor table.

5.2 A DAC and resource reservation algorithm

This subsection details admission control and resource reservation schemes. As mentioned previously, our QoS solution utilizes a cross-layer design. With the available local bandwidth and the connectivity table defined in the subsection above, the whole procedure is progressed when disseminating a RREQ packet and a RREP packet during the route discovery.

To initiate the route discovery, the application at a source node indicates, in the request message, the bandwidth requirement, B_req, that must be guaranteed, and then a source node disseminates a RREQ packet. At this time, the source node first checks whether there is a destination IP in the first neighbor table and the second neighbor table. Through this procedure, it can determine whether the end-to-end hop number is 1-hop, 2-hop, or more than 3-hop. The local bandwidth requirement of the source node is determined with the end-to-end hop number obtained by the above procedure. At an intermediate node and a destination node, the local bandwidth requirement is also determined with this procedure and the hop number achieved by the received RREQ packet.

Figure 6 shows the pseudo codes for admission control by handling a RREQ packet during the route discovery procedure at a source node. Here B_ava,s is the available local bandwidth of source node defined in Section 4 and Curren-tHopCount is the hop number achieved by the current RREQ packet. Further, FnTable is the first neighbor table, and SnTable is the second neighbor table in Section 5.1. In the case of a source node, CurrentHopCount is 0 and if there is a destination IP in FnTable, this means that the end-to-end hop number is 1. Thus, as described in Section 3.3, the local bandwidth required to admit the flow at the source is B_req at the source node. If there is a destination IP in SnTable, this means that the end-to-end hop number is 2. Therefore, the local bandwidth requirement is 2B_req. If there is no destination IP in FnTable and SnTable, this means that the predicted end-to-end hop number is more than 2. Thus, to make the admission control decision, 3B_req is required. In all the cases, if the bandwidth requirement described in Figure 6 is not met, a source node discards the RREQ packet.

Figure 6

Admission control in a source node.

If the node that receives a RREQ packet is an intermediate node, Curren-tHopCount is more than 0. This is the case of N₂, N₃, N₄, and N₅ in Figure 1. Figure 7 shows the admission control in an intermediate node. If there is a destination IP in FnTable, and CurrentHopCount is 1, this means that the end-to-end hop number is 2. Therefore, the required local bandwidth is 2B_req as the second node in Figure 2b. If there is a destination IP in FnTable, and CurrentHopCount is more than 1, this indicates an end-to-end route with more than 3-hop numbers as well as the node is the last intermediate node. Thus, 3B_req is required as the third node in Figure 2c. If there is a destination IP in SnTable, and CurrentHopCount is 1, this indicates a 3-hop route and the node means the first intermediate node. Therefore, the local bandwidth of 3B_req is needed as the second node in Figure 2c. Finally, if there is no destination IP in SnTable and FnTable, and CurrentHopCount is more than 1, this case indicates that end-to-end hop number is more than 4, and the node is not the last intermediate node. Therefore, to make the admission control decision at this node, 4B_req is required. In all the cases, if the bandwidth requirement described in Figure 7 is not meet, an intermediate node discards the received RREQ packet.

Figure 7

Admission control in an intermediate node.

Figure 8 shows admission control at a destination node. In this case, Curren-tHopCount is only used. As described in Figure 2, we consider two cases. One is the end-to-end route with 1-hop, and the other is the end-to-end route of more than 1-hop. The first case is that CurrentHopCount is 1, therefore, when the destination receives a RREQ packet with B_req, only B_req is required. However, in the other case, with the condition that is CurrentHopCount is more than 1, 2B_req is required. If the admission control succeeds by a destination node, this means that a soft end-to-end QoS session for B_req required by a source node is established. Therefore, the reservation message must be forwarded to all the nodes on the end-to-end route achieved by the RREQ packet. In our work, a RREP packet is used for the resource reservation.

Figure 8

Admission control in a destination node.

Figures 9, 10 and 11 show the pseudo codes of the resource reservation in each node.

Figure 9

Bandwidth reservation in a destination node.

Figure 10

Bandwidth reservation in an intermediate node.

Figure 11

Bandwidth reservation in a source node.

In Figure 9, when a destination node forwards a RREP packet to a source node, the algorithm for resource reservation is shown, where EteHopCount is the end-to-end hop number achieved by a RREQ packet, and BackHopCount is the hop number from a destination node. First of all, a destination node checks EteHopCount. If EteHopCount is 1, B_req is reserved for the QoS session. If EteHopCount is more than 2, 2B_req is reserved. Then, one forwards a RREP packet to the source node. Figure 10 shows the pseudo code for resource reservation at an intermediate node. In this case, one first checks which one is the last intermediate node through EteHopCount and BackHopCount, and then reserves bandwidth. If the node is the last intermediate (BackHopCount == 1) and EteHopCount is 2, it reserves 2B_req. If EteHopCount is more than 2, 3B_req is reserved. But, if this node is not the last intermediate, 3B_req or 4B_req is reserved according to EteHopCount. Figure 11 shows the pseudo code in a source node. According to EteHopCount, B_req, 2B_req, or 3B_req is reserved. After the source node reserves the local bandwidth, the QoS session of the end-to-end route is finally accepted. In spite of the admission control, an end-to-end route may still be broken from time to time due to various reasons, such as node mobility and topology changes when nodes die. In this case, we adopt the explicit ICMP QoS-LOST used by AODV-QoS [19] to inform the source nodes of all the unmaintainable sessions. Thus, the corresponding source nodes have to reinitiate session requests for new ones. The old broken routes will expire after the lifetime.

6 Simulation studies

To test the performance of our QoS solution, DACP, with comprehensive simulations, is evaluated and compared with the non-service model, which is the standard AODV routing protocol without admission control (the non-admission control model) [19] and existing service models with admission control, such as power scheme in CACP [10] and ACBR [17], in three scenarios; simple topology on chain environment, grid topology, and random topology on static environment. In the simulations, we use the IEEE 802.11 MAC protocol with a channel data rate of 2 Mb/s. Nodes have a 250 m radio transmission range and 550 m CS range. Simulations are conducted using the OPNET v11.5 simulator [5].

6.1 The performance on simple topology on chain environment

To prove the inaccurate calculation about the bandwidth requirement of each node in existing works, such as CACP and ACBR, first of all, we conduct simple simulations with a chain topology as shown in Figure 12. As mentioned in Section 3, in the case of admission control in CACP, when the route of flow 1 goes through nodes 1-6, the contending nodes of node 3 is nodes 1, 2, 4, and 5. Thus, CACP for admission control requires 5R as the local bandwidth requirement at node 3 to support the flow 1's transmission rate, R. Also, in ACBR, since the interference range of a node is not taken into account, 3R is required as the local bandwidth requirement of flow 1. However, in our work, 4R is required at node 3. In order to prove this, considering the overhead of the control message, we firstly analyze the data throughput on a single-hop link between nodes. Assuring that congestion does not occur, and the data packet is 1500-byte in size, the data throughput on the single-hop link are

Figure 12

Simulation topology used to observe the inaccurate calculation of existing works.

$$\begin{array}{c}\frac{\mathsf{\text{DATA}}}{\mathsf{\text{RTS}}+\mathsf{\text{CTS}}+\left(\mathsf{\text{DATA}}+\mathsf{\text{MAChdr}}+\mathsf{\text{IPhdr}}\right)+\mathsf{\text{ACK}}}\times \mathsf{\text{channel\_bandwidth}}\\ =\frac{1500}{44+38+\left(1500+52+20\right)+38}\times 2\\ =1.773\mathsf{\text{Mbps}}.\end{array}$$

(6)

Thus, if we consider the bandwidth used in control packets, such as RTS, CTS and ACK, and packet header, the weight factor is 1.128 per a packet. This means, if a 1500-byte packet transmits to the next hop, 1692-bytes are consumed as channel bandwidth. Thus, in the case of the route with more than 4-hop numbers, the maximum end-to-end throughput is achieved at 0.44 Mbps. The weight factor is different according to packet size. However, it does not consider the retransmission and time of AIFS and DIFS. Thus, the real weight factor is more than 1.128. Through the simulations with a 6-hop chain topology with different transmission rate, we determine the approximated real weight factor. The results of a 6-hop chain topology using 1500-byte data packets are shown in Table 1.

Table 1 Throughput achieved by a 6-hop chain topology with different sending rate

Based on the simulation results, when considering the retransmission and time of AIFS and DIFS, the maximum throughput is achieved at 0.4 Mbps. When compared with the maximum throughput of 0.44 Mbps achieved using the weight factor of 1.128, 0.04 Mbps is different. In other words, 0.04 Mbps is used in the retransmission period, AIFS and DIFS. Therefore, we choose the real weight factor as 1.1 × 1.128 = 1.24. In the case of the transmission rate, such as 0.5 and 0.45 Mbps, since the collision occurs easily in the saturation network, these cases achieve lower throughput than 0.4 Mbps. In order to consider non-collision of intra-flow in the network and the transmission for routing packets in the simulations shown in Figure 12, we select 0.35 Mbps as the transmission rate of flow 1. In this case, the transmission rate in the MAC layer is 0.35 × 1.24 = 0.4342 Mbps. Therefore, the bandwidth used by flow 1 at node 3 is 4 × 0.4342 Mbps = 1.74 Mbps. Thus, in theory, 0.26 Mbps as available channel bandwidth is allowed.

In the beginning of the simulation, node 1 sends data packets to node 6 at the sending rate of 0.35 Mbps. At the simulation time of 20 s, node 7 sends data packets to node 8 at a sending rate from 0.1 to 0.5 Mbps. We run the simulation for 200 s. Table 2 shows the performance of flow 1. In this simulation, the transmission rate of flow 2 (0.2 Mbps) increases, up to 0.2 × 1.24 = 0.25Mbps, as the transmission rate in the MAC layer. Thus, 0.25 Mbps, as the bandwidth of flow 2, is used at nodes 2, 3, and 4, which are in node 7's interference range. In other words, the available channel bandwidth is 1.75 Mbps at nodes 2, 3, and 4. As shown in the results of the simulation, when the sending node of flow 1 is lower than 0.2 Mbps, the end-to-end bandwidth of flow 1 is almost guaranteed. Thus, 5R of CACP is more value, and 3R of ACBR is low value than local bandwidth required to guarantee end-to-end bandwidth, R.

Table 2 The performance of flow 1 according to the sending rate of flow 2

Consequently, through these results, the inaccurate calculation of bandwidth requirement at an intermediate node in CACP and ACBR is investigated. In addition, we prove that calculation of the bandwidth requirement using the number of contending link in our work is correct. In our work, the weigh factor is considered in our scheme for estimating available local bandwidth that takes the MAC's overhead and retransmission into account is proposed.

6.2 The performance in grid topology-based ad hoc environments

In this scenario, multi-hop ad hoc environments are considered using grid topologies, where 30 static nodes are located in 1250m × 1000m square regions shown in Figure 13. There are five CBR flows which have different transmission rate and starting time. The packet size of all the flows is 1500-byte and through varying packet interval per packet, the transmission rate of each flow is controlled. The metrics used to measure the performance are the end-to-end service stability using the delivery ratio and the average end-to-end throughput. In addition, through calculating the number of RREQ packets, the overhead of a signaling packet is estimated. The simulation runs for 300 s. The simulation results are shown in Figures 14, 15, 16 and 17. The information of each flow in the simulation is shown in Table 3.

Figure 13

Grid topology used to evaluate the performance in multi-hop ad hoc environments.

Figure 14

The throughput of each flow in non-admission control.

Figure 15

The throughput of each flow in CACP.

Figure 16

The throughput of each flow in ACBR.

Figure 17

The throughput of each flow in DACP.

Table 3 The information of each flow in the grid topology shown in Figure 13

Results obtained on the simulation, shown in Figures 14, 15, 16 and 17, show that DACP obtains better QoS support in terms of end-to-end service stability and resource assurance. Here, an end-to-end service stability, S, provides the indication about the level of service violation with the total percentage of loss of admitted flows during the end-to-end QoS session. S is

$$S=\frac{{\sum }_{i=1}^x\frac{A_i-L_i}{A_i}\times 100}{x}.$$

(7)

Let A _i be the total sent packets of flow i, L _i be the total received packets of flow i, x be the number of admitted flows for the QoS session. When the percentage loss is less than 5%, the level of service violation is good but when percentage loss is between 5 and 10%, quality is medium. When percentage loss exceeds 15%, quality is poor. The results of the service stability and end-to-end throughput in these simulations are shown in Table 4 and Figures 14, 15, 16 and 17, respectively. There is an improvement in the performance of each flow admitted by DACP, compared with other model.

Table 4 The end-to-end service stability in the grid topology shown in Figure 13

Figure 14 shows the throughput of each flow in AODV-based networks without admission control. As expected, all the flows become active, and the channel becomes congested. Thus, the service stability, S, of all the flows looks like significant instability. Figure 15 shows the throughput of each flow achieved by the admission control in CACP. In the result, flow 2 is not admitted during the simulation time. The end-to-end service of flow 3 is also unstable. For the simulation time from 200 s to ending time, QoS session for flow 3 is disconnected. This is because the available local bandwidth will decrease at the intermediate nodes, since the network becomes overloaded. Figure 16 shows the throughput of each flow obtained by ACBR. In the result, at the beginning simulation time, all the flows are admitted by admission control. However, traffic of flow 2 is dropped from 200 s. Also, after transmitting flows 2 and 3, the service quality of flows 1, 4, and 5 becomes unstable. This is because flows 2 and 3 are admitted even if the local bandwidth is not sufficient. This indicates the inaccurate calculation of the required local bandwidth at each node.

Figure 17 shows the throughput of each flow achieved by the admission control of DACP. In the results, there are four admitted flows like the case of CACP. This is because both models, such as CACP and DACP, are similar to the required local bandwidth every node. Thus, the number of admitted flows is similar. Further, the service quality of the admitted flows is more stable than other models during the simulation time. Table 4 shows the results of the end-to-end service stability. As shown in results, we obtain good quality (S_total = 2.5%), when using DACP. However, when using CACP and ACBR, medium quality is obtained and when using non-admission control, low quality (S_total = 28%) is obtained. By comparison, CACP gives better stable service (S_total = 7%) than ACBR (S_total = 10%). This is because of the fact that flow 3 is admitted by ACBR despite the insufficient local resources. On the other hand, DACP obtains better service quality than CACP. This is because DACP can reduce the number of routing traffic, as such RREQ packets, more than CACP. This is shown in Table 5. Through these results, it is clear that the proposed model is able to reduce the number of unnecessary routing packets during route discovery by making admission control decisions at every node in the network. Thus, DACP can use more resources in the network than other models to transmit data packets. In addition, in point of complexity of DACP, the number of a signaling packet, such as RREQ packets, is considered as the argument of the overhead generated to providing admission control. During performing admission control, the number of signaling packet generated in DACP is reduced significantly as shown in Table 5. Therefore, DACP can see that the complexity is lower than other models.

Table 5 The overhead of a signaling packet in the grid topology shown in Figure 13

6.3 The performance in static multi-hop ad hoc environments

In order to evaluate more realistic performance of DACP, the simulations run in multi-hop ad hoc environments, where 50 static nodes are located randomly in 2000m × 2000m square regions. In the simulations, there are three CBR flows with throughput bounds of 150 kbps, three CBR flows with throughput bounds of 100 kbps and three CBR flows with throughput bounds of 50kbps. All the packets are 1500-bytes in size. The source-destination pair is randomly chosen. We randomly choose five different scenarios and run the simulations for 300s. In the simulations, the metrics used in measuring the protocol's performance are the throughput utility, the number of admitted flows, the aggregated throughput of all the flows, and the overhead of routing traffic. Here, the throughput utility is min (1, T_active/T_upper). T_upper is the upper bound throughput (bandwidth requirement), and T_active is the measured throughput. The averaged simulation results are shown in Figures 18, 19 and 20. As the results shown under grid topology, in these simulations, the DACP model also shows better QoS support than others in terms of service quality and guaranteed end-to-end throughput. Figures 18 and 19 show the throughput utility and the number of admitted flow per bandwidth requirement of flow, respectively. In these simulations, the non-admission control model remains unsatisfactory, and all the flows are admitted, while CACP, ACBR, and DACP achieve high throughput utility. In simulation for CACP, 6-flows are admitted, while in the cases of ACBR and DACP, 8-flows are admitted. In addition, as shown in Figure 20, DACP achieves higher aggregated throughput than other models. Also, DACP has less overhead than other models in terms of routing traffic, as shown in Table 6. These results are because of the reduced routing traffic in the overall network and the accurate local bandwidth requirement at every node.

Figure 18

Average throughput utilities in the static random topology.

Figure 19

The number of admitted flows in the static random topology.

Figure 20

Aggregated throughput of all the admitted flows in the static random topology.

Table 6 The overhead of signaling packets in the static random topology

7 Conclusion

In this article, we propose a novel admission control scheme, called the DACP, which is designed for guaranteeing end-to-end bandwidth in wireless ad hoc networks. We first exploit the problem of the bandwidth requirement for end-to-end bandwidth assurance. DACP makes admission control decisions only using RREQ messages during route discovery, and thus it can reduce routing traffic overhead significantly. In addition, an accurate estimation scheme for available resources of each node in the MAC is introduced. Simulation results demonstrate that DACP can significantly improve end-to-end QoS in terms of end-to-end throughput and service quality.