MOBILE RICART-AGRAWALA ALGORITHM
5.1.
General Idea and Description of the Algorithm
For distributed mutual exclusion in MANETs, a hierarchical architecture is con- structed where nodes form clusters and each cluster is represented by a coordinator in the ring ”(Erciyes 2004, 2005)”. After constructing this architecture, we can execute the Mobile RA algorithm. The main idea is to form coordinators as interface of other nodes to the ring. The relation between the cluster coordinator and an ordinary node is similar to a central coordinator based mutual exclusion algorithm. The types of messages exchanged are Node Req, Coord Req, Coord Rep and Node Rel where a node first requests a critical section and upon the reply from the coordinator, it enters its critical section and then releases the critical section. The message types are described below:
• Node Req: Any node which wants to execute CS, sends a Node Req message to its coordinator. After sendind this message, node waits for Coord Rep message from
its coordinator to execute CS.
• Coord Req: After receiving Node Req message, Coordinator sends this message to
the next coordinator on the ring if all pending requests in its cluster have greater timestamps than this incoming request. Otherwise, it enqueues this message to the
wait queue. If a coordinator receives this message, it forwards it according to the
timestamp of this message. If the coordinator which is the originator of this message receives its own message, it sends a Coord Rep message if there no other waiting requests with timestamp lower than itself or a CS executing node at the same time.
• Coord Rep: A node which wants to execute CS, will execute CS after receving this
message from its coordinator
• Node Rel: After executing CS, node sends this message to its coordinator indicating
The coordinators can be either in IDLE, WAITRP or WAITND state as described below:
• IDLE : Coordinators in IDLE state only forwards the Coord Req messages to the
next coordinator on the ring. If a Node Req message is received, coordinator sends a Coord Req message to the next coordinator and makes a transition to WAITRP state.
• WAITRP: Coordinator in WAITRP state waits for its original Coord Req message. Coord Req messages of other coordinators are enqueued if the timestamp is greater.
After receiving its original Coord Req message, coordinator makes a transition to
WAITND state. Received Node Req messages are forwarded as Coord Req messages
to next coordinators.
• WAITND: Coordinator in WAITND state waits for Node Rel message from its
cluster member which executes CS. After receiving Node Rel, it makes a transition to
IDLE state, if there is no pending request from its cluster members in its wait queue.
Otherwise it makes a transition to WAITRP state. Received Node Req messages are forwarded as Coord Req messages to the next coordinators.
The finite state machine representation of the Mobile RA coordinator is shown in Fig. 5.1 ”(Erciyes 2004, 2005)”. Node_Req WAITND IDLE Coord_Req Coord_Req Coord_Req / / Coord_Rep / Node_Rep Node_Rel Coord_Rep WAITRP Node_Req Coord_Rep / Node_Rel/ Coord_Rep Node_Rel Coord_Rep / / Coord_Rep Node_Rel Coord_Rep / / Coord_Req Node_Req Coord_Req /
5.2.
An Example Operation
Fig. 5.2 shows an example scenario for the Mobile RA Algorithm. Node 6, node 4, node 16 makes request for critical section respectively at 3.75s, 3.85s, 3,90s. Execution Time of critical section is taken as 350ms. The following describes the events that occur :
1. Node 6, in cluster 19 makes a critical section request at 3.75s by sending Node Req
(6,19,3.75) message to node 19 which is the cluster coordinator. Node 19 receives the
message at 3.76s and changes its state to W AIT RP . Node 19 sends a Coord Req
(6,19,3.75) message to the next coordinator(node 14) on the ring. Node 14, which
is in IDLE state and has no pending requests in its cluster, receives the Coord Req
(6,19,3.75) message at 3.78s and forwards the message to the next coordinator(node
17) on the ring. The message traverses the ring and is received by node 19 which is in
W AIT RP state at 3,82s meaning all of the coordinators have confirmed that either
they have no pending requests or their pending requests all have higher timestamps. Node 19 sends a Coord Rep message to node 6 and changes its state to W AIT ND. Node 6 receives the Coord Rep message at 3.83s and enters the critical section. Step 1 is depicted in Fig. 5.2.(a).
2. Node 4, in cluster 18 makes a critical section request by sending a Node Req
(4,18,3.85) at 3.85s. Node 18 receives the Node Req (4,18,3.85) message at 3.86s
and sends a Coord Req (4,18,3.85) message to its next coordinator(node 19) on the ring. Node 19, which is in W AIT ND state, receives the message and enqueues the
Coord Req (4,18,3.85) at 3.87s. Node 16 makes a critical section request at 3.90s.
Node 18 which is in W AIT RP state receives the Coord Req (16,17,3.90) message and enqueues the message at 3.93s. Step 2 is depicted in Fig. 5.2.(b).
3. Node 6 exits from critical section at 4.18s and sends a Node Rel message to node 19. Node 19 which is in W AIT ND state receives the message at 4.19s and makes a transition to IDLE state. Node 19 dequeues and forwards Coord Req (4,18,3.85) message to the next coordinator(node 14). The Coord Req (4,18,3.85) message is forwarded by node 17 since its request has higher timestamp. Node 18 receives its original request at 4.25s and sends a Coord Rep message to node 4. Node 4 enters the critical section at 4.26s. Step 3 is depicted in Fig. 5.2.(c).
12 14 5 7 10 9 13 6 19 15 4 18 1 11 2 8 17 3 0 16 Node_Req(6,19,3.75) Coord_Req(6,19,3.75) Coord_Req(6,19,3.75) Coord_Req(6,19,3.75) Coord_Req(6,19,3.75) (a) 12 14 5 7 10 R18 Coord_Req(16,17,3.90) 9 13 6 19 15 4 18 1 11 2 8 17 3 0 16 Coord_Req(4,18,3.85) (b) Node_Req(16,17,3.90) Node_Req(4,18,3.85) R17 12 14 5 7 10 9 13 6 19 15 4 18 1 11 2 8 17 3 0 16 Node_Rel(6,19) Coord_Req(4,18,3.85) Coord_Req(4,18,3.85) Coord_Req(4,18,3.85) Coord_Rep (c) 12 14 5 7 10 9 13 6 19 15 4 18 1 11 2 8 17 3 0 16 Coord_Req(16,17,3.90) Coord_Req(16,17,3.90) Coord_Req(16,17,3.90) (d) Node_Rel Node_Rel Coord_Rep Coord_Rep
Figure 5.2. Operation of the Mobile RA Algorithm
4. Node 4 finishes to execute critical section at 4.61s. Node 18 receives the Node Rel message at 4.62s. Node 18 dequeues and forwards the Coord Req (16,17,3.90) message to its next coordinator(node 19) on the ring. Operation is continued as explained before. Node 17 receives Node Rel message from node 16 at 5.03s. The Step 4 is depicted in Fig. 5.2.(d).
If there are multiple requests within the same cluster, time stamps are checked similarly for local request. The order of execution in this example is nodes 4 → 6 → 16 in the order of the timestamps of the requests.
5.3.
Analysis
Since the sending and receiving ends of the Mobile RA algorithm are the same as of RA algorithm, the safety, liveness and fairness attributes are the same. The upper
and lower bounds for total message number, response time and synchronization delay are shown and proven in theorems and corollaries below. ”(Erciyes 2004, 2005)”. The comparison of Mobile RA and RA is shown in table 5.1.
Theorem 5.3..1. The total number of messages per critical section using the Mobile RA Algorithm is k+3d where k is an upper bound on the number of neighbor nodes in the ring including the cluster coordinators and d is an upper bound on the diameter of a cluster.
Proof. An ordinary node in a cluster requires three messages ( Node Req, Coord Rep and Node Rel) per critical section to communicate with the coordinator. Each of these messages would require maximum d transfers between a node and the coordinator. The full circulation of the coordinator request (Coord Req) requires k messages resulting in
k+3d messages in total.
Corollary 5.3..2.The Synchronization Delay(S) in the Mobile RA Algorithm varies from 2dT to (k + 2d - 1)T.
Proof. When the waiting and the executing nodes are in the same cluster, the required messages between the node leaving its critical section and the node entering are the
Node Rel from the leaving node and Coord Rep from the coordinator resulting in 2dT
message times for Smin. However, if the nodes are in different clusters, the Node Rel message has to reach the local coordinator in d steps, circulate the ring through k − 1 node to reach the originating cluster coordinator in the worst case and a Coord Rep message from the coordinator is sent to the waiting nodes in d steps resulting in Smax=(k-
1)T+2dt=(k+2d-1)T.
Corollary 5.3..3. In the Mobile RA Algorithm, the response times are Rlight=(k +
3d)T+E and Rheavy varies from w(2dT +E) to w((k +2d-1)T+E) where k is the number
of clusters and w is the number of pending requests.
Proof. According to Theorem 5.3..1, the total number of messages required to enter a critical section is k+3d. If there are no other requests, the response time for a node will be
Rlight=(k+3d)T +E including the execution time(E) of the critical section. If there are
w pending requests at the time of the request, the minimum value Rheavy min is w(2dT +
E). In the case of Smax described in Corollary 5.3..2, Rheavy max becomes w((k + 2d-1)T
Table 5.1. Comparison of Mobile RA and RA
Mobile RA RA
Total Message Count k+3d 2(N-1)
Response timelight (k+3d)T+E 2T+E
Response timeheavy w((k-1+2d)T+E) w(T+E)
Synchronization delay (k+2d-1)T NT
5.4.
Results
We implemented the distributed mutual exclusion algorithm with the ns2 simula- tor. A random load generator is implemented to generate high, medium and low loads for different number of nodes. Different size of flat surfaces are chosen for each simulation to create small, medium and large distances between nodes.
Very Small, Small and Medium surfaces vary between 310m × 310m to 400m × 400m, 410m × 410m to 500m × 500m, 515m × 515m to 650m × 650m respectively. Random movements are generated for each simulation. Low, medium and high mobility scenarios are generated and respective node speeds are limited between 1.0m/s to 5.0m/s, 5.0m/s to 10.0m/s, 10.0m/s to 20.0m/s. K parameter of merging clustering algorithm is changed to obtain different size of clusters. Response times and synchronization delays as measured with respect to load, mobility, distance and K are recorded. Execution of critical section is selected as 100ms.
Response time behaves as expected in low load scenarios as shown in Fig. 5.3. Synchronization delay values are smaller in medium load as shown in Fig. 5.4. The synchronization delay is 0 in low load scenarios since there will be no waiting requests in the queues. When the load is increased response time increases due to waiting time of requests in the queue. Also response time and synchronization delay increases due to collisions and routing delays caused by high network traffic as shown in Fig. 5.3 and Fig. 5.4. Response time and synchronization delay results in approximate values by mobility parameter due to rapid change of network topology as shown in Fig. 5.5 and Fig. 5.6.
Figure 5.3. Response Time against Load for Mobile RA
Figure 5.4. Synchronization Delay against Load for Mobile RA
Fig. 5.7 and Fig. 5.8 shows the effects of distance between nodes to response time and synchronization delay. K parameter is selected between 3 to 8 in a MANET with 60 node. In fixed number of nodes, as the cluster size increases, total number of clusters in network decreases. This also reduces the number of cluster leaders forming the ring and routing delay which causes decreasing the response time and synchronization delay as shown in Fig. 5.9 and Fig. 5.10.
Figure 5.5. Response Time against Mobility for Mobile RA
Figure 5.7. Response Time against Surface Area for Mobile RA
Figure 5.8. Synchronization Delay against Surface Area for Mobile RA
Consequently, our results conform with the analysis that response time values against low and medium loads increase linearly with a small gradient. Synchronization delay values against medium and high load also increase linearly. Response time against high load makes a sharp increase due to high network traffic. Response time and syn- chronization delay values are stable under different mobility and surface area conditions. Response time and synchronization delay values decrease linearly against the number of clusters in MANET.
Figure 5.9. Response Time against K for Mobile RA