A Metric for DISH Networks:
Analysis, Implications, and Applications
Abstract
In wireless networks, node cooperation has been exploited as a data relaying mechanism for decades. However, the wireless channel allows for much richer interaction among nodes. In particular, Distributed Information SHaring (DISH) represents a new improvement to multichannel MAC protocol design by using a cooperative element at the control plane. In this approach, nodes exchange control information to make up for other nodes’ insufficient knowledge about the environment, and thereby aid in their decision making. To date, what is lacking is a theoretical understanding of DISH. In this paper, we view cooperation as a network resource and evaluate the availability of cooperation, . We first analyze in the context of a multichannel multihop wireless network, and then perform simulations which show that the analysis accurately characterizes as a function of underlying network parameters. Next, we investigate the correlation between and network metrics such as collision rate, packet delay, and throughput. We find a nearlinear relationship between and the metrics, which suggests that can be used as an appropriate performance indicator itself. Finally, we apply our analysis to solving a channel bandwidth allocation problem, where we derive optimal schemes and provide general guidelines on bandwidth allocation for DISH networks.
1 Introduction
Cooperative diversity is not a new concept in wireless communications. Key ideas and results in cooperative communications can be traced back to the 1970s to van der Meulen [1] and Cover & El Gamal [2], whose works have spurred numerous studies on this topic from an informationtheoretic perspective (e.g., [3, 4, 5, 6]) or a protocoldesign perspective (e.g., [7, 8, 9, 10]). To date, cooperation has been intensively studied in various contexts, as a data relaying mechanism where intermediate nodes help relay packets from a transmitter to a receiver. However, the wireless channel allows for much richer interaction among nodes. Consider another possibility, where nodes exchange control information to make up for other nodes’ insufficient knowledge about the environment, and thereby aid in their decision making. This represents a notion of controlplane cooperation, which augments the conventional understanding of cooperation at the data plane.
This paper specifically studies the distributed flavor of controlplane cooperation, which we call Distributed Information SHaring (DISH). It is a general approach and can be customized into specific mechanisms in different environments. For example in a multichannel network, due to insufficient knowledge about channel or node status, a node may select a conflicting channel to exchange data, or a transmitter may initiate communication to a receiver who is however on a different channel. In both cases (which are the variants of a multichannel coordination problem define later), DISH can be used such that neighboring nodes who possess relevant information share the information to help the particular node avoid the problem. Recently, a DISHbased multichannel MAC protocol was proposed in [11, 12], and simulations therein demonstrated significant performance gain over other noncooperative protocols.
However, to date, what is still lacking is a theoretical understanding of DISH. The benefit of DISH is that it can remove the need for multiple transceivers [13, 14, 15, 16, 17] and time synchronization [18, 19, 20, 21, 22, 23] in designing multichannel MAC protocols. This motivates us to understand DISH from a theoretical perspective. In this paper, we provide an analysis of DISH in terms of the availability of cooperation by viewing cooperation as a network resource. We define a metric in the context of a general multichannel network. It characterizes the availability of cooperation as the probability that a multichannel coordination problem is identified by any neighboring node (who thus becomes cooperative). We analyze this metric in multihop networks with randomly distributed nodes, and verify the analysis via simulations. It is shown that our analysis accurately characterizes the availability of cooperation as a function of underlying network parameters, and reveals what factors and how these factors affect cooperation. This serves as a guide in provisioning a DISH network toward its optimal performance.
We then carry out a detailed investigation of with three different contexts of DISH: noncooperative case, ideal DISH, and real DISH. The investigation shows that is a very meaningful performance indicator for DISH networks. Moreover, we apply our analysis to solving a practical channel bandwidth allocation problem, which yields insights different from noncooperative networks.
Throughput analysis for multihop networks is difficult (and still an open problem in general), and it gets even more complicated in a multichannel context with DISH. Our approach in this paper is to first look at and then correlate it with network performance. We found a simple relationship between and typical performance metrics.
The specific findings of this study are:

The availability of cooperation is high () in typical cases, which suggests that DISH is feasible to use in multichannel MAC protocols.

The performance degradation due to an increase in node density can be alleviated due to the simultaneously increased availability of cooperation.

The metric increases with packet size for a given bit arrival rate, but decreases with packet size for a given packet arrival rate.

Node density and traffic load have opposite effects on but node density is the dominating factor. This implies an improved scalability for DISH networks as increases with node density.

is strongly correlated to network performance and has a nearlinear relationship with metrics such as throughput and delay. This may significantly simplify performance analysis for cooperative networks, and suggests that be used as an appropriate performance indicator itself.

is concave and not monotonic with respect to the ratio between control channel bandwidth and data channel bandwidth; there exists one and only one maximum for each given set of parameters.

The optimal bandwidth ratio between the control and a data channel increases with node density but decreases with traffic load. This tells us that, for example, in a sparser network with heavier traffic, the control channel should be allocated less bandwidth for larger .

In most cases (the number of channels is not too small), to boost the availability of cooperation, the control channel should be allocated more bandwidth than each data channel, rather than using smaller frequency band for a control channel or the usual equal bandwidth partition as suggested by many other studies.
Part of this work was presented in [24]. We review related work in Section 2, give the system model in Section 3 and then the analysis in Section 4. The analysis is verified in Section 5 where we also provide an detailed investigation of in different contexts of DISH. Then we present an application of our analysis in Section 6. Finally, Section 7 gives concluding remarks.
2 Related Work
Multichannel MAC protocols for ad hoc networks can be categorized into multiradio schemes and singleradio schemes. In the first category [13, 14, 15, 16, 17], each node dedicates a radio to monitoring channel usage when the other radio(s) are engaged in communication. In the second category, the mainstream approach is using time synchronization to (i) require nodes to negotiate channels in common time slots [18, 19, 20] or (ii) hop among channels according to wellknown or predictable sequences [21, 22, 23]. The first category sacrifices costefficiency due to the extra hardware requirement, and the second category underperforms in scalability due to the complexity of time synchronization.
There are three other studies most related to this work. One is CAMMAC [11, 12] which is the first DISHbased protocol. This multichannel MAC protocol uses a single transceiver but does not require time synchronization. In the protocol, a transmitter and a receiver perform a handshake on the control channel to reserve a free data channel. If they choose a busy channel or the receiver is not on the control channel (and hence deaf to the transmitter), neighboring nodes who recognize this (via overhearing) may send cooperative messages to inform the transmitter and/or the receiver. Our later evaluation of real DISH will be based on an adapted version of CAMMAC.
The second work, CoopMAC [10], is also a cooperative MAC protocol but the cooperation refers to data relaying as in many other protocols such as [7, 8, 9]. This protocol replaces a single lowrate transmission with two highrate transmissions by using a relay node, in order to achieve higher throughput. The paper provides a protocol analysis which involves computing the probability that a relay node is available. This probability seems to be similar to but they are actually very different. The probability defined in [10] is a spatial metric because it is completely determined by the (static) node placement, i.e., a relay is deemed available if there is a node in the intersection of the radio footprints of the source and the destination. This can be easily calculated via simple geometric analysis (as the paper assumes uniformly distributed nodes). On the other hand, is a metric involving spatial, temporal, and frequency factors: besides node locations, nodes’ communication activities (which vary with time), and the channels that nodes are tuned to (while [10] assumes a single channel), all will affect . Furthermore, the problem context of the analysis in [10] is a wireless LAN whereas our context is a multihop network. Finally, [10] deals with dataplane cooperation whereas our work deals with controlplane cooperation.
The last work is by Han et al. [25] who considered a multichannel MAC protocol that adopts ALOHA on the control channel to reserve data channels. Queueing theory was applied to calculate the throughput of the protocol. However, there are some noteworthy limitations. First, the scenario under consideration is singlehop. Second, it is assumed that each node can communicate on the control channel and a data channel simultaneously. This implicitly requires two transceivers per node and consequently leads to collisionfree data channels. Third, a unique virtual queue was assumed to store the packets arriving at all nodes for the purpose of centralized transmission scheduling, and the precise status of this queue was assumed to be known to the entire network. This assumption is impractical and makes the calculated throughput actually an upper bound. Fourth, the access to the control channel uses the ALOHA mechanism while CSMA/CA is widely adopted in practice.
3 System Model
We consider a static and connected ad hoc network in which each node is equipped with a single halfduplex transceiver that can dynamically switch between a set of orthogonal frequency channels but can only use one at a time. One channel is designated as the control channel and the others as data channels. Nodes are placed in a plane area according to a twodimensional Poisson point process.
We consider a class of multichannel MAC protocols with their common framework described below. A transmitterreceiver pair uses an McRTS/McCTS handshake on the control channel to set up communication (like 802.11 RTS/CTS) for their subsequent DATA/ACK handshake on a data channel. To elaborate, a transmitter sends an McRTS on the control channel using CSMA/CA, i.e., it sends McRTS after sensing the control channel to be idle for a random period (addressed below) of time. The intended receiver, after successfully receiving McRTS, will send an McCTS and then switch to a data channel (the McRTS informs the receiver of the chosen data channel). After successfully receiving the McCTS, the transmitter will also switch to its chosen data channel, and otherwise it will back off on the control channel for a random period (addressed below) of time. Hence it is possible that only the receiver switches to the data channel. After switching to a data channel, the transmitter will send a DATA and the receiver will respond with a ACK upon successful reception. Then both of them switch back to the control channel.
In the above we have mentioned two random periods. They are assumed to be designed such that idle intervals on the control channel are well randomized. Specifically, when a node is on the control channel, it sends control messages (an aggregated stream of McRTS and McCTS) according to a Poisson process with an unknown average rate (will be determined in Section 4). The validity of this assumption will be verified via simulations.
Note that we use McRTS, McCTS, DATA and ACK to refer to different packets (frames) without assuming specific frame formats. Since, logically, they must make a protocol functional, we assume that McRTS carries channel usage information (e.g., “who will use which channel for how long”) and, for simplicity, McCTS is the same as McRTS.
We assume that, after switching to a data channel, a node will stay on that channel for a period of , where is the duration of a successful data channel handshake.^{1}^{1}1This is also valid for a failed data channel handshake. See appendix for the elaboration. We ignore channel switching delay as it will not fundamentally change our results if it is negligible compared to (the delay is [23] while is more than for a 1.5KB data packet on a 2Mb/s channel). We also ignore SIFS and propagation delay for the same reason, provided that they are smaller than the transmission time of a control message.
We assume a uniform traffic pattern — all nodes have the equal data packet arrival rate, and for each data packet to send, a node chooses a receiver equally likely among its neighbors. We also assume a stable network — all data packets can be delivered to destinations within finite delay. In addition, packet reception fails if and only if packets collide with each other (i.e., no capture effect), transmission and interference ranges are equal, and neighboring nodes do not start sending control messages simultaneously (there is no time synchronization).
We do not assume a specific channel selection strategy; how a node selects data channels will affect how often conflicting channels are selected, but will not affect . This is because, intuitively, we only care about the availability of cooperation () when a multichannel coordination problem (a precise definition is given in Def. 1), which includes channel conflicting problem, has been created.
We do not assume a concrete DISH mechanism, i.e., nodes do not physically react upon a multichannel coordination problem, because analyzing the availability of cooperation does not require the use of this resource. In fact, assuming one of the (numerous possible) DISH mechanisms will lose generality. Nevertheless, we will show in Section 5 that, when an ideal or a real DISH mechanism is used, the results do not fundamentally change. This could be an overall effect from contradicting factors which will be explained therein.
We assume that the following parameters are known:

: node density. In a multihop network, it is the average number of nodes per where is the transmission range. In a singlehop network, it is the total number of nodes.

: the average data packet arrival rate at each node, including retransmissions.

: the duration of a data channel handshake.

: the transmission time of a control message. .
4 Analysis
4.1 Problem Formulation and Analysis Outline
We first formally define , which depends on two concepts called the MCC problem and the cooperative node.
Definition 1 (MCC Problem)
A multichannel coordination (MCC) problem is either a channel conflict problem or a deaf terminal problem. A channel conflict problem is created when a node, say , selects a channel to use (transmit or receive packets) but the channel is already in use by a neighboring node, say . A deaf terminal problem is created when a node, say , initiates communication to another node, say , that is however on a different channel. In either case, we say that an MCC problem is created by and .
In a protocol that transmits DATA without requiring ACK, a channel conflict problem does not necessarily indicate an impending data collision. We do not consider such a protocol.
Definition 2 (Cooperative Node)
A node that identifies an MCC problem created by two other nodes, say and , is called a cooperative node with respect to and .
Fig. 1 gives a visualization of the above two concepts in our system model.
Probabilities 
the probability that at least one cooperative node with respect to and exists  
the probability that node is a cooperative node with respect to and  
the probability that a node is on the control channel at an arbitrary point in time  
the probability that a control channel handshake (initiated by an McRTS) is successful  
the probability that an arbitrary node successfully overhears a control message  
Events 
node is on the control channel at time  
node successfully overhears node ’s control message, given that sends the message  
node is silent (not transmitting) on the control channel during interval  
node does not introduce interference to the control channel during interval , i.e., it is on a data channel or is silent on the control channel  
node , which is on a data channel at , switches to the control channel in  
Others 
is the set of node ’s neighbors, , (’s but not ’s neighbors)  
,  
the time when node starts to send a control message  
the average rates of a node sending control messages, McRTS, and McCTS, respectively, when it is on the control channel. Clearly, 
Definition 3 ()
is the probability for two arbitrary nodes that create an MCC problem to obtain cooperation, i.e., there is at least one cooperative node with respect to these two nodes.
Note that if there are multiple cooperative nodes and they are allowed by a DISH mechanism to send cooperative messages concurrently, a collision can result at node . However, this collision still indicates an MCC problem and thus cooperation is still obtained. CAMMAC[11, 12] also implements this.
We distinguish the receiving of control messages. A transmitter receiving McCTS from its intended receiver is referred to as intentional receiving, and the other cases of receiving are referred to as overhearing, i.e., any node receiving McRTS (hence an intended receiver may also be a cooperative node) or any node other than the intended transmitter receiving McCTS.
Our notation is listed in Table I. Overall, we will determine by following the order of .
Consider first. Fig. 1 illustrates that node is cooperative if and only if it successfully overhears ’s and ’s control messages successively. Hence ,
(1) 
Consider . For to successfully overhear ’s control message which is being sent during interval , must be silent on the control channel and not be interfered, i.e.,
(2) 
4.2 Solving (4.1)
Proposition 1
If node is overhearing a control message from node during , then the probability that a node does not interfere with is given by
where
Thus (4.1) can be reduced to (see Appendix)
(3) 
The above contains two unknown variables, and , and the following solves for them.
For , consider a sufficiently long period . On the one hand, the number of arrival data packets at each node is . On the other hand, each node spends a total time of on data channels, a factor of which is used for sending arrival data packets. Since the network is stable (incoming traffic is equal to outgoing traffic), we establish a balanced equation:
To determine , noticing that a node switches to data channels either as a transmitter (with an average rate of ) or as a receiver (with an average rate of ), we have . Substituting this into the above yields
(4) 
For (and ), we need a proposition and two lemmas.
Proposition 2
If node (transmitter) is intentionally receiving McCTS from node (receiver) during , then the probability that a node does not interfere with is given by
where
Lemma 1
For a Poisson random variable with mean value , and ,
Proof:
Lemma 2
For three random distributed nodes , and ,

.

.

.
Now we can prove (see Appendix)
(5) 
Now we solve (together with ). From the perspective of a transmitter, the average number of successful control channel handshakes that it initiates per second is . Since each successful control channel handshake leads to transmitting one data packet, we have
From the perspective of a receiver, it sends an McCTS when it successfully receives (overhears) an McRTS addressed to it, ^{2}^{2}2In a more sophisticated protocol model, a receiver may not respond even if it receives McRTS due to, e.g., disagreeing with the transmitter’s channel selection. This behavior is modeled by ideal DISH and real DISH, which will be shown in Section 5 that it does not fundamentally change the results. and hence . Then combining these with yields
(6) 
where and are given in (4.2).
4.3 Solving (4.1) and Target Metric
Based on the proof of (3), it can be derived that
(7) 
Note that , because is not an arbitrary time for due to the effect form . The reason is that implies , and thus for to happen, must stay continuously on the control channel during (otherwise, a switching will lead to staying on the data channel for , but since ’s data communication is still ongoing at , and hence can never happen).
It can be proven that (see Appendix)
(8) 
where
Let be the average of over all , i.e., is the probability that an arbitrary node in is cooperative with respect to and , Using Lemma 2(b),
(10) 
By the definition of in Table I,
(11) 
where the events corresponding to , i.e., nodes not being cooperative with respect to and , are regarded as independent of each other, as an approximation.
Thus is determined by averaging over all pairs that are possible to create MCC problems. It can be proved [26] that these pairs are neighboring pairs satisfying ( denoting the degree of a node )

, , but not , or

, but and are not on the same threecycle (triangle).
This condition is satisfied by all neighboring pairs in a connected random network, because the connectivity requires a sufficiently high node degree ( where is the total number of nodes[27]) which is much larger than 2. Therefore, taking expectation of (11) over all neighboring pairs using Lemma 1 and Lemma 2(c),
(12) 
This completes the analysis.
4.4 Special Case: SingleHop Networks
Now that all nodes are in the communication range of each other, we have according to Prop. 1 and 2, which leads to according to (4.2), and according to (9). Hence (11) reduces to
where is the number of all possible cooperative nodes with respect to and , leading to . ^{3}^{3}3This means all nodes excluding , , and , where is the node that is currently communicating with (on a data channel), and is the node that was communicating with (on a data channel) when was setting up communication with (hence and missed ’s control message). None of these four nodes can be a cooperative node. So, as the average of ,
(13) 
where is given below, by solving equations (4), (4.2) and (6),
and is given below, by reducing (8) with ,
5 Investigating with DISH
We verify the analysis in both singlehop and multihop networks and identify key findings therein. We also investigate the correlation between and network performance.
5.1 Protocol Design and Simulation Setup
5.1.1 NonCooperative Case
This is a multichannel MAC protocol based on the protocol framework described in Section 3. Key part of its pseudocode is listed below, where is the control channel status (FREE/BUSY) detected by the node running the protocol, is the node’s state (IDLE/TX/RX, etc.), is the node’s current queue length, and they are initialized as FREE, IDLE and 0, respectively. The frame format of McRTS and McCTS is shown in Fig. 2, where we can see that they carry channel usage information. A node that overhears McRTS or McCTS will cache the information in a channel usage table shown in Fig. 3, where Until is converted from Duration by adding the node’s own clock.
As is based on the system model, this protocol does not use a concrete DISH mechanism, i.e., cooperation is treated as a resource while not actually utilized.
5.1.2 Ideal DISH
This protocol is by adding an ideal cooperating mechanism to the noncooperative case. Each time when an MCC problem is created by nodes and and if at least one cooperative node is available, the node that is on the control channel, i.e., node , will be informed without any message actually sent, and then back off to avoid the MCC problem.
5.1.3 Real DISH
In this protocol, cooperative nodes actually send cooperative messages to inform the transmitter or receiver of an MCC problem so that it will back off. We design a real DISH protocol by adapting CAMMAC[11] and show the control channel handshake in Fig. 4. A transmitter and a receiver first perform a PRA/PRB exchange like the 802.11 RTS/CTS to negotiate a data channel, and then perform a CFA/CFB exchange to confirm (to their respective neighbors) the channel selection. A cooperative node sends an INV packet when identifying an MCC problem through PRA or PRB.
We change CAMMAC such that , where denotes packet size.
5.1.4 Simulation Setup
There are six channels of data rate 1Mb/s each (the number of channels does not affect results as long as the network is kept stable). Data packets arrive at each node as a Poisson process. The uniform traffic pattern as in the model is used. Traffic load (pkt/s), node density (1/), and packet size (byte) will vary in simulations. In multihop networks, the network area is 1500m1500m and the transmission range is 250m. Each simulation is terminated when a total of 100,000 data packets are sent over the network, and each set of results is averaged over 15 randomly generated networks.
5.2 Investigation with NonCooperative Case
5.2.1 Verification of Analysis
The obtained via analysis and simulations are compared in Fig. 5. We see a close match between them, with a deviation of less than 5% in almost all singlehop scenarios, and less than 10% in almost all multihop scenarios. Particularly, the availability of cooperation is observed to be at a high level ( in most cases), which suggests that a large percentage of MCC problems would be avoided by exploiting DISH, and DISH is feasible to use in multichannel MAC protocols. (Finding 1)
Specifically, Fig. (a)a and Fig. (c)c consistently show that, in both singlehop and multihop networks, monotonically decreases as increases. The reasons are two folds. First, as traffic grows, each node spends more time on data channels for data transmission and reception, which reduces and hence the chance of overhearing control messages (), resulting in lower . Second, as the control channel is the rendezvous to set up all communications, larger traffic intensifies the contention and introduces more interference to the control channel, which is hostile to messages overhearing and thus also reduces .
Fig. (b)b and Fig. (d)d show that monotonically increases as increases, and is concave. The increase of is because MCC problems are more likely to have cooperative nodes under a larger node population, while the deceleration of the increase is because more nodes also generate more interference to the control channel.
An important message conveyed by this observation is that, although a larger node density creates more MCC problems (e.g., more channel conflicts as data channels are more likely to be busy), it also boosts the availability of cooperation which avoids more MCC problems. This implies that the performance degradation can be mitigated. (Finding 2)
In both singlehop and multihop networks, a larger packet size corresponds to a lower . However, note that this is observed under the same packet arrival rate (pkt/s), which means actually a larger bit arrival rate for a larger , and can be explained by the previous scenarios of versus . Now if we consider the same bit arrival rate, by examining the two analysis curves in Fig. (c)c where we compare with respect to the same product, e.g., () versus (), and () versus (), then we will see that a larger corresponds to a higher , which is contrary to the observation under the same packet arrival rate. The explanation is that, for a given bit arrival rate, increasing reduces the number of packets and hence fewer control channel handshakes are required, thereby alleviating control channel interference. (Finding 3)
5.2.2 Dominating Impact Factor
The above results indicate that node density and traffic load affect the availability of cooperation in opposite ways. This section aims to find which one dominates over the other. In Fig. 6, we plot the relationship of versus and , given and based on the analytical result for singlehop networks. We multiplicatively increase and with the same factor (two), and find that, when increasing () from (5,5) to (10,10), keeps increasing from 0.865 to 0.999, and when increasing () from (10,5) to (20,10), keeps increasing from 0.724 to 0.943. Consistent results were also observed in other scenarios, i.e., in singlehop, and in multihop networks.
This investigation shows that is the dominating factor over that determines the variation of . This implies that DISH networks should have better scalability than nonDISH networks, since increases when both traffic load and node density scale up. (Finding 4)
5.3 Investigation with Ideal DISH
For ideal DISH, we only present results in multihop networks, as the singlehop simulation results were similar and the discussion in this section applies to both sets of results.
5.3.1 Verification of Analysis
The results of comparison are shown in Fig. 8, where with ideal DISH well matches of analysis. This confirms Findings 13, and we speculate the reasons to be as follows. With ideal DISH, a transmitter will be informed of a deaf terminal problem at times and thus back off for a fairly long time, which leads to fewer McRTS being sent. On the other hand, a node will also be informed of a channel conflict problem at times and thus reselect channel and retry shortly, which leads to more control messages being sent. Empirically, channel conflict problems occur more often, and hence there will be an overall increase of control messages being sent. This escalates interference and thus would lower down . However, nodes will switch to data channels less frequently because cooperation suppresses a number of conflicting data channel usages. This makes nodes stay longer on the control channel and would elevate . Consequently, does not significantly change.
As Finding 4 is obtained via analysis which, as shown in Fig. 8, matches the simulations with ideal DISH, it is automatically confirmed.
5.3.2 Correlation between and Performance
We investigate how correlates to network performance — specifically, data channel collision rate , packet delay , and aggregate throughput . We consider both stable networks and saturated networks under multihop scenarios.
In stable networks, we measure () and when without and with cooperation (ideal DISH), respectively. Then we compute and to compare to with ideal DISH. The first set of results, by varying traffic load , is shown in Fig. (a)a. We observe that the two ascending and convex curves of and approximately reflect the descending and concave curve of , which hints at a linear or nearlinear relationship between and these two performance ratios. That is, , where and are two constants. The second set of results, by varying node density , is shown in Fig. (b)b. On the one hand, and decreases as increases, which is contrary to Fig. (a)a. This confirms our earlier observations: is amicable whereas is hostile to (the smaller and , the better performance cooperation offers). On the other hand, the correlation between and the performance ratios is found again: as increases on a concave curve, it is reflected by and which decrease on two convex curves.
In saturated networks, we vary node density and measure aggregate throughput without and with cooperation (ideal DISH), as and , respectively. Then we compute (note that this definition is inverse to and , in order for ) to compare to with ideal DISH. The results are summarized in Fig. 8. We see that (i) grows with , which conforms to Finding 2, and particularly, (ii) the declining and convex curve of reflects the rising and concave curve of , which is consistent with the observation in stable networks. In addition, the here is lower than the in stable networks. This is explained by our earlier result that higher traffic load suppresses .
In summary, the experiments in stable networks and saturated networks both demonstrate a strong correlation (linear or nearlinear mapping) between and network performance ratio in terms of typical performance metrics. This may significantly simplify performance analysis for cooperative networks via bridging the nonlinear gap between network parameters and , and also suggests that be used as an appropriate performance indicator itself. (Finding 5)
Note that this does not imply that the delay, the channel collision rate, and the throughput are linear with respect to each other, because the above stated relationship is for the performance ratios between DISH and nonDISH networks.
The explanation to this linear or nearlinear relationship should involve intricate network dynamics. We speculate that the rationale might be that (i) MCC problems are an essential performance bottleneck to multichannel MAC performance, and (ii) is equivalent to the ratio of MCC problems that can be avoided by DISH. In any case, we reckon that this observation may spur further studies and lead to more thoughtprovoking results.
5.4 Investigation with Real DISH
For the same reason as mentioned for ideal DISH, we present the results for multihop networks only.
5.4.1 Verification of Analysis
As shown in Fig. 9, the simulation and analytical results still match, with deviation less than 15%. This is explained by two underlying factors. On the one hand, since real DISH actually sends cooperative messages, the control channel will have more interference which tends to diminish . On the other hand, these cooperative messages inform transmitters or receivers of conflicting channel selections, which leads to a reduced number of channel switchings. Hence nodes will stay longer on the control channel and hence tends to be elevated. Consequently, is kept close to the analytical result. Findings 14 are thus confirmed.
5.4.2 Correlation between and Performance
We examine this issue using scatter plots which provide another point of view besides the direct representation in Section 5.3. These plots are given in Fig. 10, where it is more apparent to see the nearlinear relationship between and (respectively). This confirms Finding 5.
An observation is that, while and (the ratio of delay and throughput, respectively) in real DISH are slightly larger than those in ideal DISH, (the ratio of data channel collision) is slightly smaller. Note that, by definition, the smaller these ratios are, the better the corresponding performance is (i.e., shorter delay, fewer collisions, and higher throughput, respectively). To explain this difference, first notice that the larger and is simply because real DISH has to afford overhead for cooperation (physically send cooperative messages) while ideal DISH does not need to. Second, the smaller , which counterintuitively conveys fewer data channel collisions than ideal DISH, relates to two factors: (i) the transmissions of cooperative messages in real DISH lowers down the efficiency of cooperation than in ideal DISH, as explained before, and hence each use of a data channel in real DISH is slightly more likely to encounter collision, (ii) the cooperative messages suppress nearby nodes from initiating handshakes (via CSMA) and also interfere ongoing control channel handshakes, leading to fewer accomplished control channel handshakes per second, and hence fewer data channel usages than ideal DISH. The latter factor, according to the simulation results, outweigh the former factor, thereby explains the smaller . In fact, these two factors also contribute to the longer delay and lower throughput in real DISH than in ideal DISH.
6 Channel Bandwidth Allocation
Our investigation shows that is a meaningful performance indicator for DISH networks and captures several other critical performance metrics. In this section, we leverage as an instrument and apply our analysis to solving an important issue in multichannel operation, channel bandwidth allocation.
6.1 Problem Formulation
For a given amount of total channel bandwidth , define a bandwidth allocation scheme , where is the number of data channels and , in which is the bandwidth of the control channel and is the bandwidth of a data channel. The objective is to obtain the optimal scheme which achieves the maximum for a given . We remark that:

An implicit assumption of the problem formulation is that bandwidth is equally partitioned among all data channels.

In the formulation, is designated as an input parameter instead of a variable subject to optimization. This is because of the following: (i) in practice, the main consideration on choosing is system capacity (the number of users a system can accommodate), (ii) if, otherwise, is a variable subject to optimization, the formulation will be equivalent to and its solution will be a single “universally optimal” which generally does not fit into practical situations.

There exists another bandwidth allocation problem, where data channel bandwidth is fixed and only control channel bandwidth can be adjusted (or vice versa). We do not investigate this problem because (i) from a practical perspective, radio frequency band is a regulated or highly limited resource and cannot be arbitrarily claimed, and (ii) even if the band can be arbitrarily claimed, then the solution becomes obvious — will monotonically increase as or grows, as a consequence of using more resource.
6.2 Solutions and Discussion
Denoting the size of a control packet and a data packet by and , respectively, we have^{4}^{4}4We assume that ACK packet size is negligible compared to data packet size. Or alternatively, one can simply define as the sum size of data and ACK packets.
Combined with , we have
(14) 
Then we rewrite as
(15) 
Next, for a given and protocolspecified and , compute and using (14) and (15) for different combinations of and . Then substitute each pair of and into the equations derived in Section 4 and calculate . By this means, we will obtain a matrix of which corresponds to different combinations of and . Finally, comparing for each in order to find the maximum will obtain the optimal solution for a given .
Using this method, we can demonstrate results given a set of parameters. Fig. 11 is such a plot given the following parameters: bytes, bytes (cf. Fig. 2, plus PHY preamble and header), Mb/s, , . We can see that is concave and not monotonic with respect to , and it reaches the maximum at a certain on each curve corresponding to a specific . There are two counteractive factors attributing to this. First, as increases, the control channel is allocated more bandwidth, so the time needed for transmitting a control packet, and hence the vulnerable period of receiving a control packet, is being reduced. As such, the probability of successful overhearing will increase and hence tends to be higher. Second, as is fixed, increasing control channel bandwidth has to squeeze data channels simultaneously, which prolongs data packet transmission time and hence is to the effect of enlarging data packet size . According to Section 5, a larger leads to a lower . (Finding 6)
In particular, we obtain , , , , , . This conveys the following message: when the number of channels is small, the control channel should be allocated less bandwidth than a data channel (i.e., ), whereas when there are more channels, the control channel should be allocated more bandwidth than a data channel (i.e., ). The rationale is that, as the number of channels increases, it becomes easier for a node to secure a data channel for data transmission, and thus fewer nodes will be waiting for free data channels on the control channel. This reduces the chances of having cooperative nodes. In order to counteract this effect, the control channel should be allocated more bandwidth (than equal partition) to increase the probability of successful overhearing (by shortening the vulnerable periods of receiving control packets).
Then we investigate the relationship between (the optimal bandwidth allocation ratio) and . In each set of computation, we use (14), (15) and the equation array derived in Section 4, compute the optimal ratio by search in each series of (, ) for each . Also, a larger range of (1..25) and a smaller step size (one) are used. We perform multiple sets of computation with different and corresponding to different network scenarios.
Fig. 12 presents these results. The first observation is that monotonically increases with . This is consistent with the previous series of (, , … ). The second observation is that increases with (Fig. (a)a) but decreases with (Fig. (b)b). This tells us that, to achieve a high availability of cooperation in a sparse network with heavy traffic, the control channel should be allocated much smaller bandwidth than in a dense network with light traffic. (Finding 7)
Fig. 12 also shows that in most cases. This means that, for a DISH network to achieve larger , it generally prefers larger bandwidth for the control channel than for each data channel. This is contrary to the prior approach of using a smaller frequency band for control ([30, 31]) or dividing total bandwidth equally among all channels (numerous studies) in noncooperative multichannel networks. (Finding 8)
7 Discussion and Conclusion
Distributed Information SHaring (DISH) represents another dimension of exploiting cooperative diversity, in addition to data relaying, as a distributed flavor of controlplane cooperation. This paper gives the first theoretical treatment of this notion by addressing the availability of cooperation via a metric . Through analysis and investigation of the metric under three contexts, i.e., noncooperative case, ideal DISH, and real DISH, our study demonstrates that is a useful performance indicator for DISH networks and bears significant implications. We also apply our results to solving a practical bandwidth allocation problem.
Our study yields eight findings as listed in Section 1, which serve for different purposes. Findings 1 and 2 back up the feasibility and benefit of DISH. Findings 3 and 4 give hints on improving system performance by adjusting packet size, node density and traffic load. Finding 5 demonstrates the significance of the metric . Findings 7 and 8 suggest ways of performance improvement from a system design perspective.
In the case of mobile ad hoc networks, a node cannot become a cooperative node with respect to nodes and who create an MCC problem, if fails to decode at least one control message from and due to its mobility. However, in most cases when the mobility level is not high, node will still remain in the intersection region of and during the period and are sending their control messages, and thus is still able to cooperate. Also, another effect can compensate for the missing of cooperative nodes: a node, although not in the intersection range of and , first hears ’s control message and then moves into ’s range and hears ’s control message. In this case, it can also identify the MCC problem and become a cooperative node.
This work attempts to encourage an insightful understanding of DISH, and based on our findings, it demonstrates that is a useful metric capable of characterizing the performance of DISH networks, and also bears significant implications. We contend that DISH, as a new cooperative approach, is practical enough to be a part of future cooperative communication networks.
Appendix A Remark on data channel sojourn time
In our system model specified in Section 3, we assume that, after switching to a data channel, a node will stay on that channel for , the duration of a successful data channel handshake. This is also valid for a failed data channel handshake. To elaborate, let and be the period of staying on a data channel for a transmitter and a receiver, respectively, and let , and be the transmission time of a (DATA or ACK), the timeout interval for receiving a , and the interval for detecting collision, respectively. Hence clearly, . For a failed data channel handshake, there are three possible cases: (i) DATA is collided, in which case and , (ii) ACK is collided, in which case and , or (iii) only the receiver switches to the data channel (McCTS fails to reach the transmitter), in which case . In all above cases, , because , and (collision detection is typically by checking CRC at the footer of a packet).
Appendix B
b.1 Proof of Proposition 1
Lemma 3
If node is on a data channel at , then the probability that does not introduce interference to the control channel during , where , is given by
Proof:
By the total probability theorem,
Let be the time when node switches to the control channel (see Fig. 13). It is uniformly distributed in because the time when started its data channel handshake is unknown, and hence
(16) 
Since control channel traffic is Poisson with rate ,
where is uniformly distributed in by the same argument leading to (16). Hence
and then by substitution the lemma is proven. \qed
The proof of Prop. 1 is as below.
Proof:
In the case of , no matter is on the control channel at , or is on a data channel at but switches to the control channel before , it will sense a busy control channel (due to CSMA) and thus keep silent.
b.2 Derivation of (3)
Proof:
Based on the proof for the case in Prop. 1, it is easy to show that . Hence
Treating events (node is silent on the control channel) and (node does not interfere the control channel) being independent of each other, as an approximation, we have
b.3 Proof of Proposition 2
Proof:
The case of follows the same line as the proof for Prop. 1. In the case of , the only difference from Prop. 1 is that now we are implicitly given the fact that was transmitting McRTS during . This excludes ’s any neighbor interfering in . Therefore ’s vulnerable period is instead of as compared to Prop. 1. So