Multiple Access with Collision Avoidance for Wireless: Difference between revisions

Revision as of 14:22, 3 August 2022

Latest revision as of 14:20, 12 February 2025

(2 intermediate revisions by 2 users not shown)

Line 1:

{{Short description|Slotted medium access control protocol widely used in ad hoc networks}}

'''Multiple Access with Collision Avoidance for Wireless''' ('''MACAW''')<ref name="MACAW">{{cite journal|author=Vaduvur Bharghavan|title=MACAW: A Medium Access Protocol for Wireless LAN's|url=http://pdos.csail.mit.edu/decouto/papers/bharghavan94.pdf|version=In the Proc. ACM SIGCOMM Conference (SIGCOMM '94), August 1994, pages 212-225|date=1994-08-01|accessdate=2007-01-18|display-authors=etal}}</ref> is a slotted [[medium access control]] (MAC) protocol widely used in [[ad hoc network]]s.<ref name="SMAC_1">{{cite journal |author=Wei Ye|title=An Energy-Efficient MAC Protocol for Wireless Sensor Networks |url=http://www.isi.edu/~weiye/pub/smac_infocom.pdf|version=INFOCOM 2002|date=2002-06-01|accessdate=2006-11-26 |archiveurl = https://web.archive.org/web/20061104045110/http://www.isi.edu/~weiye/pub/smac_infocom.pdf |archivedate = 2006-11-04|display-authors=etal}}</ref> Furthermore, it is the foundation of many other [[Medium Access Control|MAC]] protocols used in [[wireless sensor networks]] (WSN).<ref name="SMAC_1"/> The [[IEEE 802.11 RTS/CTS]] mechanism is adopted from this protocol.<ref name="SMAC_2">{{cite journal |author=Wei Ye|title=Medium Access Control With Coordinated Adaptive Sleeping for Wireless Sensor Networks |url=http://www.isi.edu/~weiye/pub/smac_ton.pdf|version=IEEE/ACM Transactions on Networking, Vol. 12, No. 3, pp. 493-506, June 2004|date=2004-06-01|accessdate=2006-12-27 |archiveurl = https://web.archive.org/web/20061209195620/http://www.isi.edu/~weiye/pub/smac_ton.pdf |archivedate = 2006-12-09|display-authors=etal}}</ref><ref name=holger>{{cite book | last = Karl| first = Holger | author-link = Holger Karl | year = 2005| title =Protocols and Architectures for Wireless Sensor Networks | url = https://archive.org/details/protocolsarchite00karl| url-access = limited| publisher = Wiley | isbn = 0-470-09510-5 | page = [https://archive.org/details/protocolsarchite00karl/page/n144 117]}}</ref> It uses ''RTS-CTS-DS-DATA-ACK'' frame sequence for transferring data, sometimes preceded by an ''RTS-RRTS'' frame sequence, in view to provide solution to the [[hidden node problem]].<ref name="MACAW"/> Although protocols based on MACAW, such as [[S-MAC]], use [[carrier sense]] in addition to the RTS/CTS mechanism, MACAW does not make use of carrier sense.<ref name="MACAW"/>

== Principles of operation ==

[[ImageFile:MACAW protocol.JPGjpg|thumb|450px|An example to illustrate the principle of MACAW. It is assumed that only adjacent nodes are in transmission range of each other.]]

Assume that node A has data to transfer to node B. Node A initiates the process by sending a ''Request to Send'' frame (RTS) to node B. The destination node (node B) replies with a ''Clear To Send'' frame (CTS). After receiving CTS, node A sends data. After successful reception, node B replies with an acknowledgement frame (ACK). If node A has to send more than one data fragment, it has to wait a random time after each successful data transfer and compete with adjacent nodes for the medium using the RTS/CTS mechanism.<ref name="MACAW"/>

Line 22:

MACAW is a [[non-persistent]] [[slotted]] protocol, meaning that after the medium has been busy, for example after a CTS message, the station waits a random time after the start of a time slot before sending an RTS. This results in fair access to the medium. If for example nodes A, B and C have data fragments to send after a busy period, they will have the same chance to access the medium since they are in transmission range of each other.

=== RRTS ===
Source:<ref name="MACAW"/>===

Node D is unaware of the ongoing data transfer between node A and node B. Node D has data to send to node C, which is in the transmission range of node B. D initiates the process by sending an RTS frame to node C. Node C has already deferred its transmission until the completion of the current data transfer between node A and node B (to avoid [[co-channel interference]] at node B). Hence, even though it receives RTS from node D, it does not reply back with CTS. Node D assumes that its RTS was not successful because of collision and hence proceeds to ''back off'' (using an [[exponential backoff]] algorithm).