Multipath Admission Control Protocol Multimedia applications need the guarantee o f more than one QoS metric such as
5.1 Flow Aware Admission Control-Multipath with Multiple Constraints (FAAC-MM) protocol
Flow Aware Admission Control-Multipath with Multiple Constraints (FAAC-MM) [97] protocol assures the guaranteed throughput and bounded average end-to-end delay to application. The data session is admitted in the network if it accommodates without affecting the previously admitted sessions. The basic structure of the protocol has been presented before in chapter 3 and chapter 4. Here we will present the protocol extended structure and working o f the protocol.
5.1.1 User Requirements Specification
We have developed an application that generates the traffic and specifies the requirements of the traffic on the basis o f user requirements. The application agent generates Session Request (SReq) packet indentifying the requirements o f the data session. It includes the requested throughput, data session ID, data packet size (bytes), bounded average end-to-end delay and session state.
5.1.2 Optimal Route Finding
FAAC-MM protocol receives the user data session requirements in form o f SReq, which specifies the throughput and end-to-end delay requirements o f the data session. The protocol stores this information and checks its local capacity. The protocol generates Route Request (RtRq) and broadcast to one hop neighbours. The receiving node checks the destination of RtRq, if it is intended for that node then it sends the Route Reply else drop the RtRq. When the source node did not get the RtRp then it broadcasts the RtRq with TTL 16. We have selected 16 hops because it covers the whole simulation area. The RtRq spread through the network and reach the destination. The destination node sends back the Route Reply to the source node. The source node may receive multiple routes for each data session.
5.1.3 Session Admission Decision
The FAAC-MM protocol tests the available routes according to the needs or requirements of the data session. The application agent specifies the requirement of the data session in
session request packet. The protocol tests the routes for the requirements fulfilling in the following ways.
(i) First check the available capacity o f the route nodes against the required capacity forward by the session request. The route nodes check its local capacity using CITR (Channel Idle Time Ratio) mechanism and if the nodes can satisfy the requirements then it checks the two hop neighbour nodes capacity by transmitting admission request (AdRq) packet. The neighbouring nodes reply with admission denial (AD) packet if it cannot satisfy the session requirements.
(ii) The protocol finds the end-to-end delay o f the capacity tested route by transmitting a dummy packet (size of data packet) on the stated route. The Round Trip Time (RTT) of the dummy packet on the route helps FAAC-MM protocol to decide whether this route can satisfy the requirements o f the data session or not. If the route satisfies the capacity as well as end-to-end delay requirements of the data session, then the data session admits into the network.
(iii) The FAAC-MM protocol maintains multiple routes for each data session. The backup or secondary routes are tested for each session as well but with a slight different procedure. The protocol tests local capacity using CITR mechanism and neighbour’s capacity using low neighbours carrier sensing threshold value.
5.1.4 Local Route R epair
FAAC-MM protocol tries to locally repair the routes if it fails during the active session. The repairing node tries to find the alternate route to the destination and sends Route Error (RtEr) packet to the source. The repairing node tests the alternate route whether it can satisfy the requirements of the session or not. If the route satisfies the requirements then the repairing node informs the source with new available tested route.
5.1.5 Switching Mechanism
The switching mechanism is one of the important aspects o f FAAC-MM protocol. It actually avoids the route failure, avoids the collision and tries to uphold the guaranteed throughput and bounded end-to-end delay of the data session. The switching mechanism benefited the protocol to avoid the session pausing mechanism, which increases end-to-end delay and results in collision and route failure. Switching mechanism is implemented in the following three different scenarios.
Multi-Metrics QoS Provisioning with Multi-path Admission control Protocol 105
(i) The protocol switches the data session from primary to secondary route, when the primary route is not satisfying the requirements of the data session. The failure to satisfy the requirement can be due to node mobility or collision. When a route node of other data session moves into the interference range of the earlier stated data session’s route nodes, it affects the throughput o f the session and also increases PLR which in turn increases end-to-end delay.
(ii) The FAAC-MM protocol switches the data session from primary to secondary route when primary route fails either due to mobility or due to failure of excessive re transmission at the MAC layer. When a route nodes move out o f the transmission range o f the data sending node then failure detecting node informs the source node and the source node switches the data session from primary route to secondary route. Figure 5-1 and Figure 5-2 shows the data flow before and after the route failure by node mobility.
^ Primary route Secondary route
a.
Figure 5-1 Data route before route failure Figure 5-2 Data route after route failure
In Figure 5-2, when node ‘C’ moves out o f the transmission range of node ‘B’, then node ‘B’ informs the source node ‘S’ about route failure. The source node switches the data session from primary route to secondary.
(iii) The protocol also switches the data session from primary to secondary route when it finds that the secondary route offers higher throughput and shorter end-to-end delay than the primary. The protocol admits the data session when it finds a route from source to destination that satisfies the session requirements. As the protocol does not wait for secondary route discovery to initiate the data session, so when source node become aware that secondary route is offering higher throughput and less end-to-end delay then the primary route, then the protocol switches the data session from primary to secondary route. One thing must be noted in this scenario that the primary route is still satisfying the requirements o f the data session. It upholds the guaranteed throughput and bounded end to end delay. The Figure 5-3 and Figure 5-4 explains the scenario.
-> Prim ary ro u te ■> S econdary ro u te
^Q)~-K3>v
—► Primary ro u te Secondary ro u te KCFigure 5-3 Available primary route Figure 5-4 Secondary route offer better services
In Figure 5-3, the protocol finds the route between source node ‘A’ and destination node ‘D’. The source node initiates the data session and the available primary route is selected for data transmission. During the session duration, the protocol finds the secondary route as shown in Figure 5-3. The secondary route assures the provision o f guaranteed throughput and bounded end-to-end delay. It offers higher throughput and less end-to-end delay to the session than the primary route, and then the protocol switches the data session from primary route to secondary route as shown in Figure 5-4.