- Research Article
- Open Access

# Connectivity-Based Reliable Multicast MAC Protocol for IEEE 802.11 Wireless LANs

- Woo-Yong Choi
^{1}Email author

**2009**:968408

https://doi.org/10.1155/2009/968408

© Woo-Yong Choi. 2009

**Received:**19 May 2009**Accepted:**8 October 2009**Published:**23 November 2009

The Erratum to this article has been published in EURASIP Journal on Wireless Communications and Networking 2010 2010:439738

## Abstract

We propose the efficient reliable multicast MAC protocol based on the connectivity information among the recipients. Enhancing the BMMM (Batch Mode Multicast MAC) protocol, the reliable multicast MAC protocol significantly reduces the RAK (Request for ACK) frame transmissions in a reasonable computational time and enhances the MAC performance. By the analytical performance analysis, the throughputs of the BMMM protocol and our proposed MAC protocol are derived. Numerical examples show that our proposed MAC protocol increases the reliable multicast MAC performance for IEEE 802.11 wireless LANs.

## Keywords

- Data Frame
- Frame Transmission
- Connectivity Information
- Multicast Data
- Bandwidth Overhead

## 1. Introduction

In an infrastructure mode IEEE 802.11 wireless LAN, the STAs (Stations) should first transmit their data frames to the AP (Access Point) when they want to communicate with other STAs in the same wireless LAN or the nodes in an external network. The AP relays the data from the STAs and the external network through the distribution system. For this reason, we can consider the AP to be the only place where the multicast data transmission is actually performed.

The fundamental IEEE 802.11 MAC protocols, DCF (Distributed Coordination Function), and PCF (Point Coordination Function) provide the MAC layer error recovery service for the unicast best effort data. However, according to [1], the multicast data cannot be served with the MAC layer reliable transmission service. When a transmitter transmits a multicast data frame to multiple recipients, the transmitter expects no ACK frame from the recipients, and cannot check whether the data frame is received with no error or not. This unreliable multicast transmission service needs to be enhanced by an efficient reliable multicast MAC protocol.

In the approach in [2–4], the AP centrally coordinates the ACK or NACK frame transmissions of the recipients by transmitting the RAK (Request for ACK) or RNAK (Request for NACK) polling frames to the recipients. For example, according to the BMMM (Batch Mode Multicast MAC) protocol in [3], the AP coordinates the ACK frame transmissions by transmitting the separate RAK frames to the recipients. In the approach in [5], the AP reserves the wireless channel for the ACK frame transmissions of the recipients and coordinates the ACK frame transmissions of the recipients in a strictly sequential order. For the channel reservation for the ACK frame transmissions, it is assumed that the AP knows each ACK frame transmission time beforehand. However, this assumption cannot be realized generally because the STAs can choose their ACK transmission rates differently according to the wireless channel state. Other approaches in [2, 4, 6–8] not based on the AP's polling have also been proposed for the reliable multicast transmission.

Generally, the efficiency of the PCF protocol is better than that of the DCF protocol when many STAs including the AP are involved in the frame exchange sequences to transmit their data or ACK frames. The reliable multicast data transmission corresponds to the case where the AP transmits the multicast data frames, and usually many STAs transmit the ACK frames. Therefore, we need to develop the new efficient reliable multicast MAC protocol that is based on the PCF protocol for easing the implementation in the existing IEEE 802.11 wireless LANs. Furthermore minimizing the AP's polling frame transmissions and piggybacking the uplink data frames on the ACK frames of the recipients need to be realized in the new reliable multicast MAC protocol for the efficient use of the wireless bandwidth. The approaches in [2–5] based on the AP's polling can be implemented by modifying the PCF protocol; however, in the approach in [5] the assumption that the AP knows each ACK frame transmission time beforehand makes piggybacking the uplink data frames on the ACK frames difficult. Therefore, enhancing the approach in [2–4] so that the AP's polling frame transmissions are minimized is promising for the development of the new efficient reliable multicast MAC protocol.

In this paper, which revises and extends [9] substantially, we propose the efficient reliable multicast MAC protocol based on the connectivity information among the recipients. Enhancing the BMMM protocol, the proposed reliable multicast MAC protocol improves the MAC performance by reducing significantly the RAK frame transmissions. By the analytical performance analysis, the throughputs of the BMMM protocol and our proposed MAC protocol are derived. Numerical examples show that our proposed MAC protocol increases the multicast MAC performance for IEEE 802.11 wireless LANs.

## 2. Reliable Multicast MAC Protocol

*S* represents the set of STAs that are served by the PCF protocol.
represents the set of *n* recipients of a multicast data frame. For reliable multicast MAC transmissions, the proposed MAC protocol replaces the PCF protocol during CFPs (Contention-Free Periods). We can refer to [10] for the method for the AP's collecting of the connectivity information among the STAs in *S* under the PCF control. Specifically, the AP can obtain the set, *S* _{
i
}, which is the set of STAs of which the transmission signals can be heard by STA *i* for each STA *i* in *S*.

If the AP finds a sequence, *Q* of *n* recipients in *U* sequentially connected, that is, each recipient except the first recipient can hear its previous recipient in the sequence, the AP can poll the sequence of *n* recipients simultaneously by transmitting a single RAK frame including the MAC addresses of the sequence of *n* recipients after the multicast data frame is transmitted. For this purpose, the format of the RAK frame should be changed to include the multiple recipient MAC addresses. In response to the RAK frame, the first recipient transmits its ACK frame, on which its uplink data frame can be piggybacked, an SIFS (Short Inter-Frame Space) period after the reception of the RAK frame. And, each recipient except the first recipient transmits its ACK frame, on which its uplink data frame can be piggybacked, automatically an SIFS period after the end of the ACK frame transmission of the previous recipient in the sequence. If the AP does not detect the ACK frame transmission signal from a recipient within an SIFS period following the transmission of the AP or the previous recipient in the sequence, for the error recovery the AP transmits another RAK frame to poll the next recipients in the sequence after a PIFS (PCF Inter-Frame Space) period from the end of the previous transmission. In this manner, the AP can collect the ACK frames from *n* recipients by a single RAK frame transmission when the AP receives the ACK frames from the recipients successfully. This procedure for collecting the ACK frames by transmitting the RAK frames to the recipients in the sequence, *Q*, will be called the *RAK polling procedure* for the sequence, *Q*.

During the RAK polling procedure, the AP can piggyback on the RAK frames the MAC addresses of the transmitters of the successfully received uplink data frames. For this purpose, the format of the RAK frame should be changed to include the MAC addresses of the transmitters of the uplink data frames that are successfully received by the AP. When the AP finds that it has not yet acknowledged the receptions of one or more uplink data frames at the end of all RAK polling procedures for the multicast data frame, it can transmit one group ACK frame an SIFS period after the end of the last RAK polling procedure. The group ACK frame is assumed to have the same format of the RAK frame, however, has no polling function.

When the AP does not receive the ACK frames from one or more recipients during the RAK polling procedure, the AP will retransmit the multicast data frame, and another RAK polling procedure for the recipients of the failed ACK frames needs to be performed.

The problem of finding the minimal number of sequences of recipients, each of which is sequentially connected, that compose the set of *n* recipients can be formulated as the asymmetric TSP (Traveling Salesman Problem), where the recipients are the cities and the distance *D* _{
i,j
} from recipient *i* to *j* is binary valued:

To solve the asymmetric TSP in a reasonable computational time, we can use the following dynamic binary search algorithm using the branch and bound technique.

### 2.1. Algorithm Dynamic Binary Search (Time Limit = 1 s)

Step 1.

If a solution with the cost less than or equal to 1 is found using the branch and bound technique based on the depth-first search method within Time Limit, the solution is the result of the algorithm and the algorithm is terminated. Otherwise, set Lower Bound to 1.

Step 2.

If no solution with the cost less than or equal to is found within Time Limit, an arbitrary valid solution is the result of the algorithm and the algorithm is terminated. Otherwise, set Upper Bound to .

Step 3.

Set Current Cost to (Upper Bound Lower Bound) /2 . If Current Cost equals to Lower Bound or Upper Bound, the most recently found solution is the result of the algorithm and the algorithm is terminated.

Step 4.

If no solution with the cost less than or equal to Current Cost is found within Time Limit, update Lower Bound: Lower Bound Current Cost. Otherwise, update Upper Bound: Upper Bound Current Cost. Go to Step 3.

In Steps 1 and 2, we, respectively, try to search the solutions with the costs less than or equal to 1 and
. If we cannot find a solution with the cost less than or equal to 1, we set Lower Bound to 1 because we need to search a solution with the cost greater than 1. If we can find a solution with the cost less than or equal to
, we set Upper Bound to
because we need to search a better solution. If we cannot find a solution with the cost less than or equal to
, only the solution with the cost of *n* may be possible. In this case, an arbitrary valid solution can be the result of the algorithm. In Steps 3 and 4, we try to search a solution with the cost of at most the largest integer less than or equal to the mean of Lower Bound and Upper Bound.
is the largest integer less than or equal to *x*. If no more search is possible, that is, Current Cost equals to Lower Bound or Upper Bound, the most recently found solution is the result of the algorithm.

Let us denote the derived sequences by
and
, where
, and
for
include one or more recipients. After the AP transmits the multicast data frame to *n* recipients, the AP initiates sequentially the RAK polling procedures for the sequences,
and
. If the AP does not receive the ACK frame from the last recipient in a sequence,
, for
, within a SIFS period following the transmission of the AP or the previous recipient in the sequence, the AP will initiate the next RAK polling procedure for the sequence,
, a PIFS period after the end of the previous transmission. When the AP does not receive the ACK frames from one or more recipients through the sequential RAK polling procedures, the AP will retransmit the multicast data frame. And, the AP newly constructs the minimal number of sequentially connected polling sequences of recipients that compose the set of the recipients of the failed ACK frames, and initiates sequentially the RAK polling procedures for the newly constructed sequences. In this manner, the RAK polling procedures are repeated until all ACK frames are received from the recipients.

## 3. Performance Analysis

For the analytical performance analysis for our reliable multicast MAC protocol, the following parameters are defined:

- (i)
*U*= : the set of recipients, - (ii)
*T*_{ M }: the average transmission time of the multicast data frame, - (iii)
: the basic RAK frame transmission time when only one recipient MAC address is included to poll a recipient and no MAC address is piggybacked to acknowledge the receptions of the uplink data frames,

- (iv)
: the basic ACK frame transmission time when no uplink data frame is piggybacked,

- (v)
*L*_{ D }: the average length of the user payload of the multicast data frame (bits), - (vi)
*L*_{ U }: the average length of the user payload of a piggybacked uplink data frame (bits), - (vii)
*p*: the probability that an error occurs during the handshake of the multicast data frame and the corresponding ACK frame, - (viii)
*q*: the probability that an ACK frame has a piggybacked uplink data frame, - (ix)
SIFS: Short Inter-Frame Space,

- (x)
PIFS: PCF Inter-Frame Space,

- (xi)
*R*: Data Transmission Rate (bps).

, and include the physical layer header transmission time.

If we denote by *X* _{
i
} the number of multicast data frame transmissions until the multicast data frame is successfully transmitted to recipient *i* for
, the probability distribution of *X* _{
i
} and the mean of *X* _{
i
} can be obtained as follows:

Since the number *Y* of multicast data transmissions until the multicast data frame is successfully transmitted to *n* recipients equals
, the probability distribution of *Y* can be obtained as

The mean of *Y* can be numerically calculated as

Let us denote by
the mean number of connected polling sequences for the initial transmission of the multicast data frame when no transmission error occurs.
denotes the mean number of recipient MAC addresses included in the RAK frames to poll the recipients, and
denotes the mean number of MAC addresses piggybacked on the RAK frames to acknowledge the receptions of the uplink data frames. We will denote by *r* the probability that the group ACK frame is transmitted at the end of all RAK polling procedures for the multicast data frame. Then, the mean amount of time *T* needed for the multicast data frame to be successfully transmitted to *n* recipients can be upper bounded as

The first term, the second term, and the third, and fourth terms in (5), respectively, take into account the amount of time taken to transmit the multicast MAC frames, the ACK frames, and the RAK polling frames until the multicast data frame is successfully transmitted. is the total mean number of bits of the additional recipient MAC addresses included in the RAK frame and the MAC addresses piggybacked on the RAK frame to acknowledge the receptions of the uplink data frames. The fourth term is due to the fact that is the mean number of occurrences of the transmission errors, and the AP should wait for PIFS to transmit the next RAK polling frames when the transmission errors occur. The last term takes into account the amount of time taken to transmit the group ACK frame at the end of the RAK polling procedures. Generally, the number of connected polling sequences for the retransmission of the multicast data frame is smaller than that for the initial transmission of the multicast data frame. However, the third term was derived assuming that the number of connected polling sequences for each retransmission of the multicast data frame is . This leads to the Upper Bound as in (5).

Since
,
, and
, *T* can be further upper bounded as follows:

We can lower bound the multicast throughput *E* _{
D
}, which is defined as the mean number of total bits of multicast user payloads successfully transmitted to *n* recipients per unit time, as follows:

We can lower bound the uplink throughput *E* _{
U
}, which is defined as the mean number of total bits of uplink user payloads successfully transmitted to the AP per unit time, as follows:

where is the mean number of uplink data frames piggybacked on the ACK frames that are successfully transmitted to the AP.

For convenience of analytical performance analysis, we assumed that the connectivity information does not change over time. When the connectivity information changes, only the change of the connectivity information is actually delivered to the AP. For example, if five MAC addresses per second need to be delivered to report the change of the connectivity information among the STAs, only the data rate of 240 bps is required for this overhead.

*n*STAs are randomly located in the service areas. According to [11], the transmission ranges of all STAs are set to 400 m. Using the dynamic binary search algorithm implemented in a computer with 3.0 GHz CPU, we derived the connected RAK polling sequences for all generated wireless LANs. The estimated values of and the mean amount of time taken to derive the polling sequences are shown in Table 1.

Results of simulation experiment.

n |
N
| Mean Derivation Time ( s) |
---|---|---|

20 | 1.1 | 1.5 |

40 | 1 | 1 |

60 | 5.1 | 2.3 |

80 | 5 | 3.1 |

100 | 12.1 | 3.9 |

From Table 1, we can see that the proposed reliable multicast MAC protocol significantly reduces the RAK frame transmissions compared with the BMMM protocol where *n* RAK frame transmissions are needed to poll *n* recipients. The dynamic binary search algorithm is very efficient to get the solution on the average within about 4
s for each wireless LAN. Using (6), (7), (8), and the estimated value of
, we can obtain the lower bounds of the multicast and uplink throughputs.

Ignoring the contention phase and assuming that the uplink data frames can be piggybacked on the ACK frames for the fair comparison, (2), (3) and (4) hold, and (6) can be modified for the BMMM protocol as follows:

The second term of the preceding equation is due to the fact that the AP should wait for SIFS to transmit the next RAK polling frames when the AP can successfully receive the ACK frames from the recipients, and the third term is due to the fact that the AP should wait for PIFS to transmit the next RAK polling frames when the AP cannot receive the ACK frames from the recipients. In (9), we ignored the group ACK frame transmission at the end of the multicast data frame transmission procedure. Therefore, we can obtain the multicast throughput *F* _{
D
} and the uplink throughput *F* _{
U
} of the BMMM protocol as follows:

## 4. Numerical Examples

Values of parameters used for numerical examples.

Parameters | Values |
---|---|

| 20, 40, 60, 80, 100 |

| 36 s, 54 s |

| 36 s |

| 36 s |

| 88 bits, 1000 bits |

| 0.1%, 1%, 2%, 5% |

| 1 |

SIFS | 16 s |

PIFS | 25 s |

| 54,000,000 bps |

The values of *T* _{
M
},
,
, *L* _{
D
}, and *L* _{
U
} are obtained assuming that the multicast and uplink data frames have the VoIP (Voice over IP) user payloads of 88 bits with UDP/IP headers or the user payloads of 1000 bits with TCP/IP headers, and all frames can be transmitted with the peak rate 54 Mbps of IEEE 802.11a wireless LANs.

*q*to 1, that is, all ACK frames have the piggybacked uplink data frames, the uplink throughput results of the BMMM and our reliable multicast MAC protocols were, respectively, the same as the multicast throughput results of the BMMM and our reliable multicast MAC protocols.

As can be seen in Figures 1 and 2, as the transmission error probability increases, the throughputs of the BMMM protocol and our reliable multicast MAC protocol decrease. The throughputs with the user payloads of 1000 bits are about 9 times as those with the user payloads of 88 bits. This is because the relative bandwidth overhead due to the RAK and ACK frame transmissions increases as the user payload size decreases. From Figures 1 and 2, we can see the significant performance improvement by our reliable multicast MAC protocol. Compared with the BMMM protocol, our reliable multicast MAC protocol increases the throughput by about 60% and 27% with the user payloads of 88 bits and 1000 bits, respectively.

## 5. Conclusions

For a bandwidth-efficient reliable multicast MAC protocol, it is important to reduce the bandwidth overhead due to the transmissions of the control packets. We proposed the new reliable multicast MAC protocol reducing the bandwidth overhead by reducing the RAK frame transmissions and piggybacking the uplink data frames on the ACK frames. Our reliable multicast MAC protocol was shown to be useful especially when applications with relatively short data packets are served in IEEE 802.11 wireless LANs.

## Notes

## Declarations

### Acknowledgments

The author would like to thank the anonymous reviewers for the valuable comments, which are very helpful to improve the paper. The author also would like to thank Dr. Sayandev Mukherjee for coordinating the review process. This study was supported by research funds from Dong-A University.

## Authors’ Affiliations

## References

- IEEE :
*IEEE Wireless LAN Edition*. IEEE Press, New York, NY, USA; 2003.Google Scholar - Choi S, Choi K: Reliable multicast for wireless LAN. In
*Resource, Mobility, and Security Management in Wireless Networks and Mobile Communications*. Edited by: Zhang Y, Hu H, Fujise M. CRC Press, Boca Raton, Fla, USA; 2006.Google Scholar - Sun M-T, Huang L, Wang S, Arora A, Lai T-H: Reliable MAC layer multicast in IEEE 802.11 wireless networks.
*Wireless Communications and Mobile Computing*2003, 3(4):439-453. 10.1002/wcm.129View ArticleGoogle Scholar - Bao C-W, Liao W: Performance analysis of reliable MAC-layer multicast for IEEE 802.11 wireless LANs.
*Proceedings of the IEEE International Conference on Communications (ICC '05), May 2005, Seoul, South Korea*2: 1378-1382.Google Scholar - Gossain H, Nandiraju N, Anand K, Agrawal DP: Supporting MAC layer multicast in IEEE 802.11 based MANETs: issues and solutions.
*Proceedings of the IEEE Conference on Local Computer Networks (LCN '04), November 2004, Tampa, Fla, USA*172-179.Google Scholar - Tang K, Gerla M: MAC reliable broadcast in ad hoc networks.
*Proceedings of the IEEE Military Communications Conference (MILCOM '01), October 2001, McLean, Va, USA*1008-1013.Google Scholar - Kuri J, Kasera SK: Reliable multicast in multi-access wireless LANs.
*Wireless Networks*2001, 7(4):359-369. 10.1023/A:1016631911947View ArticleMATHGoogle Scholar - Peng J: A new ARQ scheme for reliable broadcasting in wireless LANs.
*IEEE Communications Letters*2008, 12(2):146-148.View ArticleGoogle Scholar - Choi W-Y: Efficient reliable multicast MAC protocol for IEEE 802.11 wireless LANs.
*Proceedings of the 9th International Conference on Advanced Communication Technology (ICACT '07), Feburary 2007, Phoenix Park, South Korea*1: 174-177.View ArticleGoogle Scholar - Choi W-Y: Hybrid polling method for direct link communication for IEEE 802.11 wireless LANs.
*EURASIP Journal on Wireless Communications and Networking*2008, 2008:-10.Google Scholar - Xu K, Gerla M, Bae S: How effective is the IEEE 802.11 RTS/CTS handshake in ad hoc networks?
*Proceedings of the IEEE Global Telecommunications Conference (GLOBECOM '02), November 2002, Taipei, Taiwan*1: 72-76.Google Scholar

## Copyright

This article is published under license to BioMed Central Ltd. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.