MARCH: A MEDIUM ACCESS CONTROL PROTOCOL

FOR MULTIHOP WIRELESS AD HOC NETWORKS

C-K. Toh, Vasos Vassiliou, Guillermo Guichal, and C-H Shih
Mobile MultiMedia and HiSpeed Networking Laboratory
School of Electrical and Computer Engineering
Georgia Institute of Technology

Abstract

ditional control handshake before data transmission.

Based on who initiates the handshake, these MAC
protocols can be categorized as sender-initiated or
receiver-initiated protocols. Theoretically, the latter outperforms the former since less control overhead is required. However, fundamental assump
tions made in the receiver-initiated protocols are
vulnerable. In this paper, we present a new MAC
protocol called MARCH (Multiple Access with Reduced Handshake) that combines the advantages of
both sender- and receiver-initiated protocols. This
protocol reduces the number of handshakes required
to transmit a data packet through multihop ad
hoc networks so that it outperforms other senderinitiated protocols.
This paper is organized as follows. In Section 2
we address the operation of sender- and receiverinitiated protocols. In Section 3, we propose a new
method to reduce the number of handshakes and
apply it to MARCH. In Section 4, we compare the
performance of MARCH with MACA [5] via simulations. A conclusion is made in section 5.

The Multiple Access with Reduced Handshake ( M A R C H )

protocol utilizes the broadcast characteristics of an omnidirectional antenna t o reduce the number of control
messages required t o transmit a data packet an multihop ad hoc networkx In MARCH, the RTS-CTS handshake is used only by the first hop of a route t o forward
data packets while for the rest i t utilizes a new CTS-only
handshake. Since fewer control packets are transmitted,
the probability of packet collision is reduced and therefore channel throughput is increased. Simulation results
demonstrate that M A R C H outperforms M A C protocols
that employ only the RTS-CTS handshake.

INTRODUCTION

A multihop wireless ad hoc network consists of mobile hosts (MHs) equipped with radio devices to
cooperatively form a communication network. In
such a network, MHs may not be within transmission range of each other, but they can still build a
connection through other MHs. Since all MHs use
a common radio channel to communicate with one
another, it becomes necessary to have a medium access control (MAC) protocol to govern their access
to this shared media so that there is no conflict.
The carrier sense multiple access (CSMA) protocols
[1][3] have been used in a number of packet-radio
networks in the past. Although they are simple and
can achieve acceptable channel throughput under
certain situations, they suffer from the well-known
hidden terminal problem [2] in multihop wireless
ad hoc networks, which signifkantly degrades their
performance.
To overcome this problem, various MAC protocols [5][6][7][81[10] have been developed with an ad-

0-7803-6521-6/$10.00(C) 2000 IEEE

2
2.1

RELATED WORK
Sender-initiated MAC Protocols

In sender-initiated MAC protocols, Multiple Access

Collision Avoidance (MACA) [5] first uses a requestresponse dialogue to partially solve the hidden terminal problem in wireless networks. In MACA,
when a sending MH wants to transmit, it sends a
request-to-send (RTS) packet to the receiver, who
responses with a clear-to-send (CTS) packet if it
receives the RTS packet correctly. Thereafter, the
sending MH can transmit data. An improvement
of MACA is MACAW [6], which uses more hand-

512

shakes t o handle problems associated with control

packet collision. In addition, MACA has been further improved in Floor Acquisition Multiple Access
(FAMA) [7], which adds carrier sensing capability
in order to reduce the possibility of collisions.
Although these protocols outperform CSMA in
the presence of hidden terminals, their performance
is quite limited when the trafllic load is high. Under
high traffic load, these protocols have a high probability of control packet collision, incurring a lot of
retransmissions and lowering the channel throughput.

2.2

is that an MH has knowledge of data packet arrival

at its neighboring MHs from the overheard CTS
packets. It can then initiate an invitation for
the data to be relayed. In the following sections,
we &st present the concept of overhearing CTS
packets and then describe the proposed MARCH
protocol in detail by providing an example.

3.1

In sender-initiated MAC protocols, before an MH

can receive or transmit data, it must first perform
an RTS-CTS handshake with its upstream MH or
downstream MH. The handshake process used in
MACA is shown in Figure 1, illustrating how a
source, MHA, can send data to the destination, via
MHB, MHc, etc.

Receiver-initiated MAC Protocols

Receiver-initiated protocols attempt to reduce the

number of required control packets during the handshake. In these protocols, only one control packet,
issued by a receiver, is required in each handshake.
In the protocol known as MACA By Invitation
(MACA-BI) [8], the authors assumed that an MH
can ,predict the packet arrival time at its neighboring MHs. Based on the prediction, the MH can
send ready-to-receive (RTR) packets to invite its
neighboring MHs to transmit. MACA-BI is further improved in Receiver Initiated Multiple Access
(RIMA) [9], which employs a new packet arrival prediction method. The RIMA protocol assumes that
all MHs have the same packet arrival rate. When
an MH receives a data packet, it assumes that its
neighboring MH also receives a data packet. It then
sends an RTR packet to invite the neighboring MH
to transmit.
Since these protocols reduce control overhead,
they outperform sender-initiated protocols, especially when the traffic load is high. However, this
is only true if the data packet arrival at a sender
can be correctly predicted by its receiver, which is
hard to achieve in reality.

Figure 1: The RTS-CTS handshake in MACA.

From Figure 1, we observe that to forward a data
packet, MHB needs to transmit two control packets:
a CTSl packet destined to MHA and an RTS:! packet
to MHc. However, due to the broadcast characteristics of omnidirectional antennas, MHc will receive
both the CTSl and RTSz packets. This characteristic implies that the overheard CTSl packet can
also be used to convey the information of a data
packet arrival at MHB to MHc. Then, after the
data packet has been received by MHB, MHc can invite MHB to forward that data via the CTS2 packet,
and therefore the RTSz packet can be suppressed.
Figure 2 shows the new handshake process to forward a data packet through the route. As can be
seen from this figure, the RTS-CTS handshake is reduced to a single CTS (CTS-only) handshake after

THE MARCH PROTOCOL

The Multiple Access with Reduced Handshake

(MARCH) protocol improves communication
throughput in wireless multihop ad hoc networks
by reducing the amount of control overhead. Unlike
other receiver-initiated protocols, MARCH operates
without resorting to any traffic prediction. In fact,
our protocol exploits the broadcast characteristic of
omnidirectional antennas to reduce the number of
required handshakes. The novelty of our approach

0-7803-6521-6/$10.00(C) 2000 IEEE

The Overhearing Mechanism

the first hop, and the reduction in the control over-

head is a function of the route length. For an ad hoc

route of C hops, the number of handshakes needed
to send a data packet from the source to destina-

513

involved. During route discovery, packets are broadcast. When it comes to data communication, nodes
in the route use an underlying MAC protocol such
as MARCH.
To begin data transmission in Route 1, an RTS
packet (RTS1) packet is first sent from MHA to
MHB. If this packet is successfully received by
MHB, MHB will reply with a CTSl packet to grant
the data transmission, as illustrated previously in
Figure 2. Meanwhile, CTSl is also overheard by
MHc. According to the MAC address and RTID,
MHc knows that the packet is sent by its upstream
MHB in Route 1. A timer T,, is then invoked
at MHc. T ! is set to a value long enough for
MHB to receive and process the new data packet.
Upon timeout, if the channel is free, MHc sends a
CTS2 packet to MHB to acquire the data packet.
Similarly, MHD will overhear CTS2 sent by MHc
and will subsequently invite MHc to relay the data
packet via CTS3 once its T, timer expires.
In the above example, MHz, the downstream MH
of MHc in Route 2, will also overhear the CTS2
packet. To avoid MHz misinterpreting it and initiating an unnecessary CTS-only handshake, the
RTID method is applied.
In MARCH, the MAC layer has access to tables that maintain information on the routes the
node participates into, as well as its upstream and
downstream neighbors in those routes. This does
not mean that MARCH performs any Layer 2 routing. It just consults those tables to understand if
it should respond to a control message (RTS/CTS)
particular to a certain route. If a MH is going to initiate a CTS-only handshake in route i, it encloses
its RTID for that route in the CTS packet. Therefore, by checking the RTID in CTS?, only MHD will
react appropriately to the control packet, and may
''7 timer
initiate a CTS-only handshake after its
expires. It is important to note that MARCH does
not participate in routing, nor makes any decisions
about the data packets exchanged. The contents of
the data packets are passed on to the network layer
for processing and action as usual.

Figure 2: The proposed handshake mechanism in

MARCH protocol.
tion is 2L in MACA, L: in MACA-BI, and (L:+l)
in MARCH. Hence, if L is large, MARCH will have
very similar number of handshakes as in MACA-BI.

3.2

MARCH Illustration

To support the CTS overhearing mechanism in

MARCH, we include the following information in
an CTS/RTS packet: (a) the MAC addresses of the
sender and the receiver and (b) the route identification number (RTID) l . The function of RTID will
be explained later. We also assume that each MH
keeps sensing the channel and will not transmit until
the channel is free.

Figure 3: Two overlapping routes in an ad hoc mobile network.

The operation of our MARCH protocol can be illustrated with the following example. In Figure 3,
two routes intersect at a common MH. Route 1 consists of MHA, MHB, MHc, and MHD, and Route 2
includes MHy, MHc, and MHz. These routes can
be established through an appropriate routing protocol. For example, in Associativity Based Routing
(ABR) [ll]the desired route is discovered and activated by the creation of routing entries in the nodes

To evaluate the performance of the MARCH pro-

tocol, we performed several simulations using the

OPNET tool. We also compared the performance
(throughput, overhead and delay) of MARCH with

'The RTIDcan be the concatenation of the source and

destination IP addresses.

0-7803-6521-6/$10.00(C) 2000 IEEE

PERFORMANCE EVALUATION

514

MACA [5]. The network topology used in our

simulations is shown in Figure 4, where two preestablished five-hop routes intersect at one common
MH3. In both routes, neighboring MHs are separated by 10 m, and each MH is within the transmission range of its upstream and downstream MH2.
The channel is considered to be error free and its
capacity is 1 Mbps. The size of the data and control packets is 2048 bits and 128 bits, respectively.
The source MHs in each route, MH1 and MH6, generate data packets according to a Poisson process
with an arrival rate varying from 10 pkt/sec to 350
pkt/sec. The TX-RX/RX-TX turn-around time of
a radio transceiver is 25 psec and the length of a
time slot is 1 psec. Simulation results are shown in
Figures 5, 6, and 7.

Yt.

w-3G

"

- . .
Y

i:

...................................

Figure 6: Route Control Overhead.

FI

Figure 7: End-to-End Delay.

4.1

Figure 4: The network topology used in our simulation.

Figure 5 shows the average end-to-end throughput

related to the two routes used in our simulations.
Under high trafIic load, we observe that MARCH
achieves about 66 % improvement when compared
to MACA. This -is because the reduced handshake
mechanism leads to much less control packet collisions. In order to transmit a data packet in MACA
(Figure 4), MH2 must content with MH1 and MH3
for the channel. Moreover, RTS packets transmitted by MH2 may collide at MH3, with other packets
coming from MH7, MH4, or MHs. Thus, it is dificult for MH2 to forward data packets to MH3, which
results in the restriction of end-to-end throughput
of route 1. The same situation happens in route 2.
In MARCH, transmissions between MH2 and MH3
are initiated by MH3 so that the CTS packets from
MH3 may only collide with RTS packets from MH1.
Hence, the link throughput between MH2 and MH3
is improved and so is the end-to-end throughput.

Figure 5: End-to-End Throughput Performance.

'However, MH2 and MH4 cannot hear transmission from

MH7 and MHs, vice versa.

0-7803-6521-6/$10.00 (C) 2000 IEEE

End-to-End Throughput

515

4.2

Control Overhead

modes and their throughput-delay characteristics,

IEEE Trans. Communication, vol. COM-23, no. 12,
pp. 1400-1416,1975.

The above explanation can be further justified by

Figure 6, which shows the control overhead (i.e., the
average number of control packets required for one
data packet transmission) associated with each protocol. In MACA, when the traffic load is greater
than 50 pkt/sec, control packet collisions result in
a lot of retransmissions, and an increase in control
overhead. The MARCH protocol, however, has a
lower probability of control packet collision, therefore its control overhead is much less than MACA
at altraffic loads.

4.3

[2] F. A. Tobagi and L. Kleinrock, Packet switching in

radio channels: Part I1 - the hidden terminal problem in carrier sense multipleaccess modes and the
busy-tone solution, IEEE Trans. Communication,
vol. COM-23, no. 12, pp. 1417-1433,1975.
[3] R. L. Brewster and A. M. Glass, Throughput Analysis of Non-Persistent and Slotted Non-Persistent

CSMA/CA Protocols, 4th International Conference on Land Mobile Radio, pp. 231-6, 1987.
[4] A. Colvin, CSMA with collision avoidance, Computer Communication, vol. 6, no. 5 , pp 227-35,1983.

End-to-end Delay

[5] Phil Karn, MACA - A New Channel Access

Method for Packet Radio, 9th Computer Networking Conference, pp. 134140, ARRL/CRRL Amateur Radio, 1990.

Figure 7 shows the average end-to-end delay associated with transmitting a data packet through a
route. Under light traffic load, the delay in MARCH
is higher than MACA. This is because the reduced
handshake mechanism introduces an extra delay
close to the the packet inter-arrival time at each intermediate MH (e.g., MH2, MH3 and MH4 in route
1). However, as the traffic load increases beyond
50 pkt/sec, the delay in MACA grows significantly
when compared t o MARCH since control packet collisions cause a lot of queuing delay at MH2 and MH7.
Packet queing due to collisions does not happen in
MARCH until the traffic load is above 100 pkt/sec.

[6] Vaduvur Bharghavan, MACAW: A Media Access

Protocol for Wireless LAN, Proc. ACM SIGCOMM 94, pp. 212-225,1994.
[7] Chane L. Fullmer and J.J. Garcia-Luna-Aceves,
Floor Acquisition Multiple Access (FAMA) for
Packet-Radio Networks, Proc. ACM SIGCOMM
95, 1995.
[8] Fabrizio Talucci and Mario Gerla, MACA-BI
(MACA By Invitation): A Wireless MAC Protocol
for High Speed Ad Hoc Networking, Proc. IEEE
ICUPC 97,1997.
[9] J.J. Garcia-Luna-Aceves and Asimakis Tzamaloukas, Reversing the Collision-Avoidance
Handshake
in
Wireless
Networks,Proc.
ACM/IEEE Mobicom 99, Seattle, Washington,
1999.

CONCLUSION

In this paper, we introduce a single channel MAC

protocol for multihop ad hoc wireless networks
known as MARCH. MARCH improves throughput,
delay, and control overhead performance by reducing the number of handshakes. Our simulation results reveal that MARCH outperforms MACA in
several respects. MARCH is a protocol that exploits the fact that control messages are overheard
by neighbors, therefore it is more deterministic and
does not resort t o network prediction, unlike most
receiver-initiated protocols. Finally, the concepts in
MARCH can also be applied t o other multi-channel
MAC protocols to further improve their communication performance.

[IO] Wireless LAN medium access control (MAC) and

physical layer (PHY) specifications, 1997. Draft

Standard IEEE 802.11, P802.11/Dl: The editors of
IEEE 802.11.
[ll] C-K Toh, Associativity-Based Routing For Ad-Hoc

Mobile Networks,, Journal on Wireless Personal

Communications, vo1.4 no.2, March 1997.

References
[l]L. Kleinrock and F. A. Tobagi, Packet switching in
radio channels: Part I - carrier sense multiple-access

0-7803-6521-6/$10.00(C) 2000 IEEE

516