A Reliable and Efficient MAC Protocol for Underwater Acoustic Sensor Networks

3.1. Overview of RAS Protocol

The typical application we discuss is the ocean bottom surveillance application, in which all nodes generate the same amount of data and send them to the BS periodically with cycle T c . RAS's practicability is guaranteed by the applications features: (2) the maximum one-way propagation delay of UWASNs is very long, for example, 1000 ms, and thus the synchronization accuracy requirement is low; (3) the networks are sparsely (because of high-cost sensors) and statically deployed.

Before schedule calculation, RAS needs synchronization in the networks. Although there exist many synchronization methods [11, 12], for the sake of simplicity and low cost, RAS only requires coarse synchronization through the initial packet exchange or the information piggybacked in the received packets as The authers in [7, 8] do. Meanwhile, it can calculate the rough propagation delays between nodes by checking time stamps during the synchronization process [8].

With synchronization, the nodes can work and sleep periodically [13]. In Figure 1, the RAS cycle T c is divided into two portions. One portion is the sleeping period, the other is the working period T w which is divided into many time slots T s . One time slot is composed of T d , the time duration for transmitting data, and T g , the guard time for avoiding collisions introduced by imprecise synchronization and propagation time calculation. The actual value of T g is determined by the real deployment environment. If there is a data burst due to abnormal events, nodes can transmit them in the following sleeping period by notifying the related nodes in advance. In this way, data burst does not require the schedule update. In the following, we focus on analyzing the working schedule in one cycle.

OPEN IN VIEWER

Figure 1

RAS cycle.

It is practical to employ static routing, because the networks are static. In addition, the monitoring applications only require data transmissions from the sensor nodes to the BS. Then, the BS calculates the number of data to be transmitted and received at each node. Finally, the BS can calculate for all the sensor nodes the working schedule on when to send and receive data, and broadcast the schedule to all the sensor nodes to follow for a long time. The steps are shown in Algorithm 1.

Algorithm 1: RAS protocol at the BS (it runs at the initialization phase).

These processes cost little efforts, because they do not require frequent updates. Therefore, the major goal is how to make the working period of the whole network as short as possible so as to save the energy and improve the network efficiency, that is, how to design an efficient schedule for a cycle.

3.2. Scheduling Principles

The transceiver cannot receive when it is transmitting, and collision will occur at a node when it receives more than one packet [14]. (This corruption is called interference. Interference packets at a node are divided into two types: the first type is for packets that are not destined for the node but are within the node's communication range R R . The other type is for packets that are beyond the node's communication range but are within the interference range R I . Usually, the relation [15] between R R and R I is: 2 × R R ≤ R I ≤ 3 × R R .) In order to avoid collision, we define the following scheduling principles. (1)

A DR duration must not overlap any DT duration.

Since there is no data from the BS to sensor nodes, we can design a compact schedule by only allocating time for data from sensor nodes to the BS. Thus, the next principle is as follow: (5)

No DR from ith hop node to ( i + 1 )th hop node.

The goal of data transactions is to guarantee successful receptions, and we arrive at the last principle. (6)

A node considers DR duration as the scheduling basis rather than DT or IR duration.

With DR as the scheduling basis, we do not have to consider whether IR will overlap other IRs and DTs. In addition, we can increase the throughput and reduce delay by making nodes transmit or receive instead of idling whenever no DR is overlapped.

3.3. Scheduling of RAS Protocol

To accomplish the goal of an efficient schedule, RAS implements MAC level pipelining by interlacing multiple data transmissions in a schedule as long as no collision is triggered. During the interlacing process, RAS assigns the slots to nodes with heavier traffic first that is, nodes with heavier traffic are given higher priority in data transmission and reception, and thus other nodes can only transmit or receive in the time slots that are not taken up by the heavier-traffic nodes. In this way, the traffic load can be better balanced, and the efficiency can be improved as well.

We call the schedule length calculated with RAS as L 1 . In RAS, the scheduling element corresponds to one data transaction in which the data transmission and reception will last for several time slots. The scheduling element is composed of one DT duration, one DR duration, and several IR durations.

According to scheduling principle (6), we will schedule all the elements generated in a cycle equals by scheduling all the data receptions in a cycle. Let 𝕊 i = { m : node m is i hops from the BS , m ∈ 𝕊 } . Assuming a node's distance from the BS is proportional to its hop distance to the BS, the following is the priority scheduling steps of RAS algorithm.

The reason to schedule the BS's DR first is that the topmost goal is for the BS to receive all the data generated by all other nodes in a cycle. The reason to prioritize the inner tier nodes over the outer tier nodes is that the inner-tier nodes are affording much heavier traffic. It is unfair for them to share the same bandwidth with other light-traffic nodes. In addition, the packets forwarded by the inner tier nodes are forwarded more hops than those forwarded by the outer tier nodes. Colliding or dropping those packets would cost more efforts to retransmit. Finally, to alternate the receptions among the children provides load balancing of the nodes. If fairness is not considered for a parent's children, a few children might drop packets due to congestion, whereas other children's queues are far from full. Therefore, when we alternate the children's transmissions, we improve the fairness. The three steps are shown in Algorithm 2. How RAS works at the sensor nodes is shown in Algorithm 3.

Algorithm 2: CalcSchedule() function at the BS.

Algorithm 3: RAS protocol at the other nodes (it runs at each sensor node after the initialization).

3.4. Analysis of the RAS Scheduling Algorithm

The time used to calculate the schedule of RAS is less than 1 sec in our personal computer, because RAS is a heuristic method with complexity O(N) in which N is the node number.

Since the upper bound for the RAS schedule length ( L 1 ) can be infinitely long, we only discuss L 2 , the lower bound for the schedule length. Assuming each node generates P packets in a cycle, then the BS has to receive N × P packets in total from 1-hop nodes in a N-node network. To receive packets, it has to wait for at least the propagation time T p of one packet. Therefore, the shortest time for receiving all the N × P packets is N × P × T s + T p . We call this time L 2 as the lower bound, which cannot be achieved in large-scale networks due to interferences.

4.1. Overview of NACK-Retransmission Mechanism

In the scheduling of RAS, each node n knows n c , the number of packets that should be received from each of its child node c, and n 0 , the number of packets generated by itself. The total packets that should be sent to its parent are n 0 + ∑ c n c . In RRAS protocol, if in a cycle, a node does not receive the expected packets, it would keep the packet loss in mind and perform retransmission in the following retransmission period.

Retransmission period is part of an RRAS cycle as shown in Figure 2. RRAS cycle is designed from RAS cycle: the data transmission period of RAS is kept, while the sleeping period of RAS is divided into the retransmission period and a shorter sleeping period. In this way, the data lost in data transmission period T w can be retransmitted in retransmission period T r . Obviously, RRAS protocol keeps the nodes working for a longer period than RAS for the sake of reliable transmission. However, since the unavoidable packet loss might fail the applications, it is worthy of the extra time T r to keep all the nodes waiting for possible data retransmission requirement.

OPEN IN VIEWER

Figure 2

RRAS cycle.

The packet loss caused by the volatile wireless environment is random, thus we do not know which packets will be lost in the data transmission period T w , and we cannot schedule the retransmission as we schedule the periodical data transmission. As a result, we employ a NACK-retransmission mechanism, that is, the NACK packet asks for the lost packets, and the retransmission packets reply NACK with the required packets. The detailed explanation follows.

During retransmission period T r , the node n that has not received the expected packets would send a control packet (NACK) to its child node c whose packets to n are lost during transmission. The NACK contains the packet sequence numbers that n has received from c. On receiving the NACK, c would know which packets to retransmit. If node n failed to receive packets from multiple child nodes, it would send an NACK to the very child nodes one by one. If the retransmissions succeed, no more retry is needed. Otherwise, node n could initiate the corresponding retransmission by sending another NACK.

4.2. Retransmission Mechanism

The more times that node n retry the transmissions, the higher the reliability is. Although such retransmission is aimed at improving the data transmission reliability, it does not promise 100% success which would cost a lot of extra resources. Hence, in our case, we only focus on one-time retry rather on the frequently used three-time retry [13]. If we want to retry a second time, we can simply add another retransmission period to retransmit the data packets lost during the first retransmission period.

After receiving NACK, node c would retransmit the lost data packets in a batch or in a burst to node n. Since the control frame exchanges deteriorate the UWASN efficiency greatly, batch data transmission improves the retransmission throughput and delay performance by reducing the exchanges.

As for the collision avoidance, in order not to degrade the efficiency, we do not use the maximum propagation delay to avoid collisions as [2, 6] do. In addition, carrier sense and RTS/CTS handshaking are efficient in a network where the propagation delay is negligible, but they are inefficient in UWASNs [16]. As a result, we adopt a simple ALOHA mechanism [5, 17]. According to [10], the propagation time is usually larger than the data duration time (100 ms) as long as the distance between the nodes is larger than 150 m. In this situation, even if the two nodes send packets to each other simultaneously, no collision happens. Furthermore, if node A and node B start to send a packet to C at the same time, as long as the difference between A–C distance and B–C distance is larger than 150 m, there will be no collision at node C. For these reasons, we employ simple ALOHA that is, a node could transmit a packet when it is not receiving or transmitting. Although this mechanism does not guarantee collision-free situations, it is more efficient. In case collision happens, further actions can be taken: retransmit the collided packets again or ignore it and accept the current reliability level. In our work, we study the effects of ALOHA through experiments and prove its influence on the efficiency and reliability.

We define the states of a node after the data transmission period as ( α , β ) . The α state is determined by the node itself, while the β state is determined by its parents

α = { Y , packets from its child nodes are lost, N , packets from it child nodes are not lost, β = { Y , packets to its parent nodes are lost, N , packets to its parent nodes are not lost.

(1)

A node might be in 4 situations: (N,N), (N,Y), (Y,N), and (Y,Y). If it it in state (N,N) with no packet loss, it is free from sending or receiving packets. If it is in state (N,Y), it does not know that its data transmissions to its parents are lost until it receives the NACKs from its parents. In this case, it will only retransmit the data packets designated in the NACKs.

If it is in state (Y,N), it knows that data transmissions from its child nodes are lost. It is also aware that since it fails to forward the lost packets to its parent nodes, its parent nodes will require them through NACK. It should first ask its child nodes for the lost packets by sending NACKs to them. Next, after collecting the lost packets from its child nodes, it should forward them to its parent nodes. Since it does not know the b e t a state, it does not know whether its parent nodes will ask for lost packets generated by its child nodes or packets generated by itself. As a result, even if it has finished collecting the lost packets from its child nodes, it still should wait to retransmit until receiving the NACKs from its parents.

The actions in state (Y,Y) is similar to those in state (Y,N). The only difference is that the node should send the lost packets from both its child nodes and from itself to its parent nodes. In summary, the retransmission will be triggered only after receiving the NACK requirements.

4.3. Retransmission Time

In addition, the length of T r and extra energy consumption E for reliable transmission is closely related to the packet loss rate R. The overall energy consumption is dominated by the transmit power E t , as compared to receive power E r and idle power E i [18, 19]. If R is low, then E is low. For example, if R is 0, that is, there is no packet loss during T w , then no retransmission is needed, and all the nodes are idling during T r with low extra power consumption. If the packet loss rate is very high during T w , then the retransmission period T r should be long enough to finish all retransmissions, and the extra power would be a lot. In other words, high packet loss means that the wireless environment is very severe, and retransmission is required no matter what kind of mechanisms are employed for data transmissions.

Given packet loss rate R, to ensure that the time duration is long enough for retransmitting the lost packets, the length of T r for a given network topology is calculated as follows.

To make sure that T r can accommodate all retransmission situations, we analyze the worst case. Consider the nodes in the longest route to the BS, from the leaf node a to the BS, and the maximum hop distance is H.

If a DATA transmission from node a to its parent b is lost, then all the nodes in the route need to retransmit the lost data to the BS. A node will retransmit only on receiving the NACK requirement, then a retransmission between a pair of nodes would take at most 2 * ( T p + T s ) , in which T p is the maximum propagation delay and T s is the time slot. The longest time taken for retransmitting the DATA to the BS is consequently

2 * H * ( T p + T s ) .

(2)

The ALOHA retransmission mechanism only restricts the order between the NACK and its corresponding retransmission that is, it allows parallel transmission among NACKs from different nodes. As a result, the time used is much less that is,

( T p + T s ) + H * ( T p + T s ) .

(3)

We then consider the case that more than one packet are lost in such a route. The worst situation is that all the packets are lost on the way from a to b. The batch DATA transmission mode reduces the NACK-retransmission handshake, and keeps the handshake round to be 1 among a node pair. Hence the longest time taken for retransmitting all the DATA to the BS is

( T p + T s ) + H * ( T p + L p * T s ) ,

(4)

L p = A p * R ,

(5)

Next, consider the case that more than one route, r o routes, experience data loss. The worst situation is that all the routes are H hops from the BS, and there is no overlap between any of the routes until they converge at the BS. In this situation, the batch DATA transmission mechanism cannot be applied to reduce the time. Then, we get the length of T r , that is, long enough for most retransmission situations as:

T r = r o * ( T p + T s ) + r o * H * ( T p + L p * T s ) .

(6)

5.1. Schedule Length

Since RRAS uses the schedule of RAS, this section is about RRAS and RAS schedule length. We calculate the lower bound schedule length L 2 and the RAS schedule length L 1 when the number of packets generated by each node in a cycle varies from 1 to 10. Figure 3 shows the value variations of L 2 / L 1 . The ratio of L 2 to L 1 for each network almost stabilizes at a constant value. Since L 2 = N × P × T s + T p , then L 2 also increases linearly with the network size N. This means that RAS is scalable in calculating the schedule no matter the traffic rate is low or high. Moreover, the ratio of small size networks is higher. The reason is that the hop distances of small-scale networks are 1-hop or 2-hop, and they suffer less from the interferences caused by neighboring nodes. When there are few interferences, the schedule length is reduced.

OPEN IN VIEWER

Figure 3

Schedule ratio.

Basically, the larger the guard time, the longer the schedule length. Longer guard time allows more imprecise synchronization while reduces the network efficiency. Figure 4 shows the relation between the guard time and the schedule length for ten 64-node networks. In accordance with our expectation, the schedule length increases linearly with the guard time ranging from 25% of the data duration time (80 ms) to 300% of the data duration time. Therefore, if we deploy a network with high clock drift, we should set the guard time to a longer value. Otherwise, we can use a smaller guard time.

OPEN IN VIEWER

Figure 4

Schedule length.

5.2. Throughput of RAS

Due to RAS's high scalability in schedule length demonstrated in the previous subsection, we use the schedule calculated for the case when only one packet is generated in a cycle since this subsection.

To compare RAS with UW-FLASHR [7], an existing MAC protocol designed for high channel utilization, we employ their throughput definition. Throughput is defined by measuring the total number of the intended data packets received by the BS by the total number of data packets generated by all the nodes in a period. Obviously, if the traffic generated at each node is so heavy that it exceeds the maximum capacity of the network, then the throughput would drop and even approaching to 0. Conversely, if the traffic is light, then it is likely that all the data generated will be received by the BS; therefore, the throughput is 1 when there is no traffic.

Although we simulated networks of different sizes, for the sake of conciseness, Figure 5 only compares the throughput of RAS and UW-FLASHR in 36-node networks and 64-node networks. As the traffic rate increases, the throughput of all the networks drops from 1. In addition, 36-node networks are able to afford a much heavier traffic rate than the 64-node networks, because networks with a larger size suffer higher total traffic. Moreover, we notice that the throughput for 36- and 64-node networks with UW-FLASHR dramatically drops from 1 when the traffic rate is not 0. This is because UW-FLASHR performs the slot requirement among the neighbors, and the hidden terminal problem leads to some slot establishment which might cause collisions. On the other hand, RAS performs scheduling based on all nodes' position information, thus no collision happens. Finally, for UW-FLASHR, the heaviest traffic rate these networks could afford is much less than that of RAS. This is because RAS generates a much compacter schedule than UW-FLASHR. RAS arranges the exact time needed by the transmission and reception of each node, while UW-FLASHR reserves the time slots for transmission randomly.

OPEN IN VIEWER

Figure 5

Throughput.

5.3. Average End-To-End Delay of RAS

The end-to-end delay is the period from the time a packet is generated by a node until the time it is received by the BS. Figure 6 shows that the average end-to-end delay increases when the traffic rate increases. Specifically, when the traffic rate is heavy enough to cause congestion in the networks, there are sudden jumps of delay as observed in the figure. By observing the sudden jumps in delay, we find that RAS networks can afford about 4 times higher traffic load than UW-FLASHR networks without collision. Because the scale of 36-node networks is smaller than 64-node networks, their end-to-end delay is also shorter. In addition, when heavily congested, the delay of RAS networks and UW-FLASHR networks stops increasing with traffic rate. The reason is that both RAS and UW-FLASHR are based on TDMA to reserve the channel rather than on CSMA/CA to compete the channel, thus the delay reaches an upper bound. However, the delay upper bound of RAS networks is higher than that of UW-FLASHR networks, this is due to the fact that: the priority scheduling makes the queue utilization of RAS networks higher than that of UW-FLASHR networks (this will be explained in the following subsection). In UW-FLASHR networks, the queue utilization is very low. Most packets from faraway nodes cannot arrive at the BS before being dropped by the heavy-loaded forwarding nodes. In other words, most of packets that arrive at the BS are generated by nearby nodes, thus the delay upper bound is lower. In contrast, this phenomenon is alleviated by the priority scheduling in RAS networks.

OPEN IN VIEWER

Figure 6

End-to-end delay.

5.4. Average Maximum Queue Length per Node of RAS

In this subsection, we demonstrate the advantage of RAS in fairness by showing that its queue utilization is fairer than that UW-FLASHR. The queue size of each node is set to 50 in the simulations. If a queue is filled with 50 packets, then further packet arrival will cause one packet to be dropped.

The sudden jump in the queue length is caused by congestion. For example, for the 64-node RAS network, after the traffic rate reaches 0.06 kpbs, the network starts to congest, and the congested packets are put into the queue. If the traffic rate continue to be 0.06 kpbs or higher, more packets will be enqueued until the queue is filled. Since our simulation runs a long time enough at each traffic rate, the queue is full almost all the time when the traffic rate is higher than 0.06 kpbs.

UW-FLASHR does not take the application direction into consideration, nor does it arrange longer time for nodes with heavier traffic. As a result, nodes with heavier traffic (i.e., nodes that are nearer to the BS) would easily accumulate a long queue of packets and suffer queue overflow very soon while nodes with lighter traffic maintain an empty queue. The queue utilization of the nodes in UW-FLASHR is unfair and low. Actually, nodes with heavier traffic experience a larger packet arrival rate, and they need more time to handle the packets. RAS gives higher priority to nodes with heavier traffic by allocating more data transmission time to them, thus their packet leaving rate is also higher. Likewise, nodes with lighter traffic are allotted less time. As a result, the queues of all the nodes are balanced, and the queue utilization is fairer.

Due to similar phenomenon of 36-node networks and 64-node networks, we mainly discuss the case for 64-node networks in Figure 7. When the traffic rate is between 0 kbps and 0.06 kbps, the queue length of RAS networks is shorter than that of UW-FLASHR networks. Due to RAS's capability of affording higher traffic rate, most of the nodes in RAS networks do not have to queue under those traffic rates. Whereas the nodes in UW-FLASHR networks are queueing more and more packets when traffic gets heavy. In addition, RAS networks undergo a jump in queue length when the traffic rate increases from 0.06 kbps to 0.07 kbps. This is because the queue utilization of RAS networks is fairer and higher than UW-FLASHR networks. At traffic rate 0.06 kbps, most of the nodes in RAS networks start to congest. If the traffic rate continues to be 0.06 kpbs or higher, as time goes by, more packets will be enqueued until the queues are full. Our simulation runs a long time enough at each traffic rate, the queue is full almost all the time when the traffic rate is higher than 0.06 kpbs. In contrast, in UW-FLASHR networks, the queues of the few nodes that are next to the BS are congested at a very low traffic rate, while the queues of faraway nodes are empty. Other nodes get congested gradually with the increasing traffic rate, thus the queue length does not surge.

OPEN IN VIEWER

Figure 7

Queue length.

Furthermore, because small-scale networks are less likely to suffer congestion, the queue length of 36-node RAS networks soars at about traffic rate 0.09 kbps rather than at 0.07 kbps. It stabilizes at around 27 rather than at 50 when the traffic rate is larger than 0.11 kbps. Eventually, it will stabilize at 50 when the traffic rate is very high. Nevertheless, 0.15 kbps is not a very high traffic rate for 36-node networks, thus only a majority of the nodes are congested while the others sustain empty queue. Still the queue length of RAS networks is much larger than that of UW-FLASHR networks when congestion happens in RAS networks, which again indicates that the queue utilization of RAS networks is fairer and higher.

In summary, greater maximum queue length allows fairer and higher utilization of the queue. Correspondingly, the delay upper bound of the RAS networks is higher than the UW-FLASHR networks because more faraway packets are capable of arriving at the BS with no overflow in queue.

5.5. Retransmission Time of RRAS

In this subsection and the following subsections, each node generates 1 packet for the BS periodically. Experiments are performed to determine the actual length of the retransmission period. Although we compare UW-FLASHR with RAS, we cannot compare it with RRAS, because it does not contain retransmission mechanism. According to (6), the theoretical length of the retransmission period is conservatively long, attempting to fit in all possible retransmission communications. Actually, the retransmission time can be much shorter. In Figure 8, RRAS(1) and RRAS(2) are the retransmission time when the retry time is 1 and 2 respectively. Theoretical RRAS(1) is the retransmission time calculated with (5) when the retry time is 1.

OPEN IN VIEWER

Figure 8

Retransmission time.

In Figure 8, with loss rate (loss is caused by the wireless environment) increasing from 0, the retransmission time of all the three cases increases from 0. RRAS(2) is about a double of RRAS(1), because it retransmits the lost packet one more time. When the loss rate is very low, say 0.04, RRAS(1) and RRAS(2) are equal, because the DATA packets that need retransmission are so few that they can be sent simultaneously. Theoretical RRAS(1) is the longest, because it is an overestimated value that attempts to accommodate all possible retransmission cases. As a result, to save the time spent on retransmission, we can adjust the retransmission time according to the simulation results and the loss rate in the deployment.

5.6. Working Time of RRAS and RAS

Working time is the total time that a node is turned on. During the working time, the node can be sending, receiving, or idling, but not sleeping. For RAS, the working time is the schedule time, and the sensor nodes sleep for the rest of the cycle time. For RRAS, the working time is the schedule length plus the retransmission time. For the traditional CSMA/CA used in TWSNs, the working time is the time used for transmitting all DATA packets to the BS without exceeding the required retry times. Besides RAS, RRAS(1), RRAS(2), and theoretical RRAS(1), Figure 9 also shows the working time of CSMA/CA(1) and CSMA/CA(10), with 1 and 10 as the retry limit, respectively.

OPEN IN VIEWER

Figure 9

Working time.

Because the traditional CSMA/CA employs RTS/CTS handshaking and does not design the collision avoidance mechanism suitable for UWASNs, many packets are collided and its efficiency is very low. The CSMA/CA has to retransmit the collided DATA packets, and it cannot successfully retransmit all the collided DATA packets to the BS when the retry time limit is 10, let alone when the retry time is 1. As a result, no matter what the loss rate is, the working time of CSMA/CA is a constant. In other words, the protocol for UWASNs should first settle down the negative effects caused by improper collision avoidance methods of the traditional CSMA/CA, and then recovers the packet loss caused by the volatile environment. Figure 9 also demonstrates that (1) the RAS work time is the lower bound of all because it does not retransmit, and, (2), except for CSMA/CA, the working time increases with the increase of retry time and loss rate.

5.7. Success Rate of RRAS and RAS

The success rate is defined as the DATA packets received by the BS divided by the total DATA packets for the BS. Because the RAS does not perform ACK or retransmission mechanism, its DATA success rate is reduced by the loss rate. RRAS can achieve a higher success rate. Figure 10 verifies that compared with RAS, RRAS attains a higher success rate, especially when the loss rate is high. In addition, success rate of RRAS(2) is higher than that of RRAS(1), because RRAS(2) retries one more time. However, according to Figure 8 and Figure 9, one more retransmission of RRAS(2) results longer retransmission and working time. Finally, as discussed previously, the efficiency of CSMA/CA is very low, including the success rate.

OPEN IN VIEWER

Figure 10

DATA transmission success rate.

5.8. Throughput of RRAS and RAS

According to [1], the throughput is defined as a function of the sensor node working time and the total DATA packets received by the BS:

throughput = total DATA packets received by the BS * T d working time .

(7)

In consistency with the poor success rate, the traditional CSMA/CA efficiency is also very low in Figure 11. As discussed in subsection retransmission time, the throughput of the traditional CSMA/CA is determined by its poor collision avoidance method rather than by the packet loss rate caused by the environment hence, it is flat. According to Figure 11, the throughput of RAS is the highest, but the throughput performance of RRAS is not greatly reduced, especially when the loss rate is not very high. Since the success rate of RRAS is much higher than RAS according to Figure 10, we can observe that RRAS obtains a good tradeoff between the reliability and the throughput.

OPEN IN VIEWER

Figure 11

Throughput.