A ring-based multicast routing topology with QoS support in wireless mesh networks

Abstract

Wireless mesh networking (WMN) is an emerging technology for future broadband wireless access. The proliferation of the mobile computing devices that are equipped with cameras and ad hoc communication mode creates the possibility of exchanging real-time data between mobile users in wireless mesh networks. In this paper, we argue for a ring-based multicast routing topology with support from infrastructure nodes for group communications in WMNs. We study the performance of multicast communication over a ring routing topology when 802.11 with RTS/CTS scheme is used at the MAC layer to enable reliable multicast services in WMNs. We propose an algorithm to enhance the IP multicast routing on the ring topology. We show that when mesh routers on a ring topology support group communications by employing our proposed algorithms, a significant performance enhancement is realized. We analytically compute the end-to-end delay on a ring multicast routing topology. Our results show that the end-to-end delay is reduced about 33 %, and the capacity of multicast network (i.e., maximum group size that the ring can serve with QoS guarantees) is increased about 50 % as compared to conventional schemes. We also use our analytical results to develop heuristic algorithms for constructing an efficient ring-based multicast routing topology with QoS guarantees. The proposed algorithms take into account all possible traffic interference when constructing the multicast ring topology. Thus, the constructed ring topology provides QoS guarantees for the multicast traffic and minimizes the cost of group communications in WMNs.

Appendix

In this “Appendix”, we use the node colouring model proposed in Sect. 4 to derive bounds on performance metric of multicast streaming using star and tree routing topologies over a wireless mesh network. Our analysis is based on the model and list of assumptions described in Sects. 3 and 4.

Since streaming traffic is delay sensitive, it is important to evaluate the performance of multicast streaming in terms of metrics such as delay, throughput, and capacity in order to ensure that the multicast network topology constructed by the IP multicast routing protocol achieves the QoS guarantees. To evaluate the performance of multicast streaming in a wireless multi-hop network, one must have some knowledge of which links in the multicast routing topology interfere with one another, and to what extent. However, the problem of estimating the interference among links of a multi-hop wireless network is a challenging one [41–44]. It involves accurate modelling of radio signal propagation, which is difficult since many environment and hardware-specific factors must be considered. Moreover, empirically testing every group of links is not practical: a network with n nodes can have O(n ²) links, and even if we consider only pairwise interference, we may have to potentially test O(n ⁴) pairs [45]. Therefore, it is hard to accurately evaluate the performance of multicast streaming in a wireless multi-hop network. However, lower/upper bounds on performance metrics are always easier to compute and can be very useful in deciding whether or not the constructed routing topology can achieve the required QoS guarantees.

Interference between wireless links is determined by their relative locations on the physical network topology. In our modelling, however, interference between links is determined based only upon their logical positions on the routing topology. Thus, our modelling ignores interference that can occur between multicast traffic transmitted from nodes that are not direct neighbours on the routing topology. For illustration, let us consider the physical network topology depicted in Fig. 2(a). Since node c is a direct neighbour to node b (i.e., c is located in the coverage area of node b), traffic transmitted from node b to node d interferes with the traffic transmitted from node a to node c. However, since nodes c and b are not direct neighbours in the tree routing topology (Fig. 2b), we ignore the effect of their traffic interference. We understand that this assumption is restrictive. However, this assumption allows us to derive feasible bounds on performance metrics of star and tree routing topologies when MAC 802.11s MAC mulitcast layer with RTS/CTS is used.

The purpose of this approximate performance analysis of star and tree that we present in this “Appendix” is to motivate the ring routing topology, and show that routing topology is ideal from many-to-many communication in wireless mesh network, especially for large number of group members.

1.1 Star topology

We consider a multicast routing network that is connected in a shared star topology (Fig. 15a). We refer to IP multicast routers that connect group members to the network as cluster heads. We refer to the cluster head that connects all cluster heads together in the star topology as the root. We assume that the number of intermediate routers between a cluster head and the root is h. We note here that we carried out our performance analysis based on the star topology that is shown in Fig. 15(a). However, our analysis can be easily extended to any given star routing topology.

Fig. 15

Common multicast network topologies. a Star; b tree; c ring-based

Proposition

The end-to-end delay in a star IP multicast routing topology is

$$ D_{Star} \ge 3 \times n \times T(h+1). $$

Proof

In a star topology, every cluster head delivers traffic generated by group members in its cluster to the root in order to get distributed to other clusters. We consider the following delays. Cluster heads can simultaneously receive traffic from their members. Due to interference between traffic, every cluster needs at least T time period to receive traffic from its members. Since the path from a cluster head to the root consists of h intermediate nodes, the time that a multicast packet spends on the path to reach the root is at least 3 × h × T, where the factor 3 accounts for number of colours (C = 3) that are used to label nodes on the path (h ≥ 2).

Due to interference between traffic, the root can receive traffic from one of its neighbouring nodes at a time. Thus, the root needs at least (n − 1)T time period to receive traffic from all neighbouring nodes. When the root receives all cluster heads traffic, it uses the multicast address at the IP layer to transmit (broadcast) the traffic to all neighbouring nodes during n × T time period. The relayed traffic then needs to traverse every path from the root to every cluster head. The time that is needed to deliver the traffic from the root to every cluster head is at least 3 × h × (n − 1) × T, where n − 1 accounts for the duplicate traffic that is eliminated at the IP relay nodes. Every cluster head (relays) broadcasts traffic using IP multicast address to all members in its cluster during (n − 1) × T time period. Hence, the summation of all above delays gives us a feasible lower bound on the end-to-end delay as follows.

$$ \begin{aligned} D_{Star_{LB}} &= T + 3 \times h \times T + (n-1) \times T + n \times T \\ &\quad+ 3 \times h \times (n-1) \times T + (n-1) \times T \\ &\approx 3 \times n \times T(h+1). \end{aligned} $$

□

To achieve the end-to-end QoS guarantees (η), D must not exceed η (i.e., D ≤ η). Moreover, the multicast routing topology must be able to support multicast traffic with rate of at least N × b, where N is the number of group members, and b is the rate at which multicast traffic is generated at each member (frame/s).

We can see that due to bandwidth constraint at the root and interference between traffic (traffic congestion at the root), the rate (in packet/s) at which the root can relay (forward) multicast traffic is limited. Referring to the D _Star computation, we can see that the maximum channel bandwidth that the root can use to relay the multicast traffic is

$$ \left(\frac{n \times T}{3 \times n \times T(h+1)}\right) \times B. $$

Hence, in order for the star topology to support the multicast traffic, we have

$$ \left(\frac{n \times T}{3 \times n \times T(h+1)}\right) \times B \ge N \times b. $$

We also know that b must exceed $\frac{1}{\eta}$ (i.e., $b \ge \frac{1}{\eta}$). Combining the above two constraints, a feasible upper bound on the number of group members that a star topology can support with QoS guarantees is

$$ N_{Star_{UB}} = \frac{B \times \eta}{3 \times (h+1)}. $$

This implies that for relaxed QoS (i.e., high η), higher channel bandwidth B, or less h, a star topology can support a larger number of group members and vice versa.

The power that every multicast packet consumes in the star topology to reach all group members can be computed as P _Star  = P _topology  × (h + n × h).

1.2 Tree topology

We consider a shared tree that is shown in Fig. 15(b). We refer to IP multicast routers that connect group members to the network as cluster heads. We assume that each cluster head is with d node degree on average (d is the number of tree branches generated from a cluster head, d = 3 in Fig. 15b). We further assume that the maximum number of cluster heads on a path between any leaf cluster head and tree root is h _max (h _max  = 2 in Fig. 15b). We assume that the average number of intermediate routers between adjacent cluster heads on the multicast routing topology is I. We note here that we carried out our performance analysis based on the tree topology that is shown in Fig. 15(b). However, our analysis can be easily extended to any given tree routing topology.

Proposition

The end-to-end delay of a tree IP multicast routing topology is

$$ D_{Tree} \ge 2 \times n \times T (h_{max}+1) (3 \times I+ 1). $$

Proof

In a tree topology, cluster heads can simultaneously receive multicast traffic from members in their clusters during at least T time period. Every cluster head needs to receive multicast traffic from every neighbouring cluster head on the tree. Due to interference between traffic, a cluster head can receive traffic from one adjacent node at a time. Since the path between neighbouring cluster heads consists of I routers (I ≥ 2), every cluster head needs at least ∑ ^d _i=1 3 × I × P _i  × T time period to receive multicast traffic from all neighbouring cluster heads, where the factor 3 accounts for the number of colours (C = 3) that are used to label routers on a path between neighbouring cluster heads, i refers to a neighbouring cluster head on a tree branch, and P _i is number of descendants of cluster head i, P _x  = 4 in Fig. 15(b).

When every cluster head receives multicast traffic from all of its adjacent cluster heads, cluster heads simultaneously transmit (broadcast) the received traffic using IP multicast address to all adjacent nodes on the tree topology and to members in their clusters during n × T time period. Every adjacent node on the tree eliminates duplicate packets and relays the traffic. Hence, the time that is required to deliver a multicast packet between two neighbouring cluster heads on the tree topology is at least

$$ T + \sum_{i=1}^{d} 3 \times I \times P_{i} \times T + n \times T \approx 3 \times I \times n \times T+ n \times T. $$

The end-to-end delay for a tree topology is the time that a multicast packet spends in the network to traverse a path on the tree topology between the two group members that are connected to the farthest leaf cluster heads from the root. Hence, a feasible lower bound on the end-to-end delay can be computed as

$$ \begin{aligned} D_{Tree_{LB}} &= (2 \times (h_{max}+1))(3 \times I \times n \times T+ n \times T) \\ &= 2 \times n \times T (h_{max}+1) (3 \times I+1). \end{aligned} $$

□

As we have discussed earlier, in order to achieve the end-to-end QoS guarantees (η), D must not exceed η (i.e., D ≤ η). Moreover, the multicast routing topology must be able to support multicast traffic with rate of at least N × b, where N is the number of group members, and b is the rate at which multicast traffic is generated at each member (packet/s).

We can see that due to the bandwidth constraint at cluster heads and interference between traffic (traffic congestion at cluster heads), the rate (in packet/s) at which any cluster head can relay (forward) multicast traffic is limited. Referring to D _Tree computation, the maximum channel bandwidth that the any cluster head can use to relay (forward) the multicast traffic is

$$ \left(\frac{n \times T}{3 \times I \times n \times T+ n \times T}\right) \times B. $$

Hence, in order for the tree topology to support the multicast traffic, we have

$$ \left(\frac{n \times T}{3 \times I \times n \times T+ n \times T}\right) \times B \ge N \times b. $$

We also know that $b \ge \frac{1}{\eta}$. Thus, a feasible upper bound on the number of group members that a tree topology can support with QoS guarantees is

$$ N_{Tree_{UB}} = \frac{B \times \eta}{3 \times I+1}. $$

We can see that the average power consumption in the network when using tree topology is P _Tree  = P _topology  × ((n − 1) × I + n).

1.3 Performance comparisons and discussion

We summarize the results of our analytical results derived for different multicast routing topologies over a static wireless multi-hop network (Table 5). We can see that our proposed scheme for the ring-based topology mitigates the end-to-end delay by a factor close to $\frac{2}{3}$ as compared with a conventional bidirectional ring (about 33 %). Furthermore, our proposed scheme increases the capacity of the ring-based multicast routing topology (i.e., maximum group size that the ring-based topology can support with QoS guarantees) by a factor of $\frac{3}{2}$ (50 %) (Table 5).

Table 5 Performance comparison of multicast streaming for different routing topologies

We also compare the lower bound end-to-end delays (for T = 1 unit of time) and the average power consumptions (for P _topology  = 1 unit of power) for all routing topologies, where we set I = 3, d = 4, h = n/2, and h _max  = 5 × h _avg , where h _avg  = log _d−1(n) (Fig. 16). We observe that for n ≤ 280, a ring-based topology with the proposed routing scheme outperforms all other topologies in terms of the end-to-end delay except the star topology. Although the star topology has the lowest delay, the power consumption in a star topology is the highest and capacity of a star topology is the lowest. Hence, star topology is not practical in a limited resources network such as static wireless multi-hop networks.

Fig. 16

End-to-end delay comparison

Interestingly, we can see that for a moderate multicast group size, a ring-based topology coupled with our proposed algorithm for IP multicast routing outperforms the tree topology in terms of both the end-to-end delay and capacity.