A Metric for DISH Networks:
Analysis, Implications, and Applications
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 multi-channel 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 multi-channel multi-hop 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 near-linear 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.
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  and Cover & El Gamal , whose works have spurred numerous studies on this topic from an information-theoretic perspective (e.g., [3, 4, 5, 6]) or a protocol-design 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 control-plane cooperation, which augments the conventional understanding of cooperation at the data plane.
This paper specifically studies the distributed flavor of control-plane 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 multi-channel 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 multi-channel 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 DISH-based multi-channel MAC protocol was proposed in [11, 12], and simulations therein demonstrated significant performance gain over other non-cooperative 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 multi-channel 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 multi-channel network. It characterizes the availability of cooperation as the probability that a multi-channel coordination problem is identified by any neighboring node (who thus becomes cooperative). We analyze this metric in multi-hop 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: non-cooperative 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 non-cooperative networks.
Throughput analysis for multi-hop networks is difficult (and still an open problem in general), and it gets even more complicated in a multi-channel 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 multi-channel 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 near-linear 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 . 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
Multi-channel MAC protocols for ad hoc networks can be categorized into multi-radio schemes and single-radio 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 well-known or predictable sequences [21, 22, 23]. The first category sacrifices cost-efficiency 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 CAM-MAC [11, 12] which is the first DISH-based protocol. This multi-channel 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 CAM-MAC.
The second work, CoopMAC , 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 low-rate transmission with two high-rate 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  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  assumes a single channel), all will affect . Furthermore, the problem context of the analysis in  is a wireless LAN whereas our context is a multi-hop network. Finally,  deals with data-plane cooperation whereas our work deals with control-plane cooperation.
The last work is by Han et al.  who considered a multi-channel 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 single-hop. 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 collision-free 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 half-duplex 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 two-dimensional Poisson point process.
We consider a class of multi-channel MAC protocols with their common framework described below. A transmitter-receiver 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.111This 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  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 multi-channel 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 multi-channel 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 multi-hop network, it is the average number of nodes per where is the transmission range. In a single-hop 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.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 multi-channel 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.
|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|
|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|
|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. CAM-MAC[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 ,
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.,
4.2 Solving (4.1)
If node is overhearing a control message from node during , then the probability that a node does not interfere with is given by
Thus (4.1) can be reduced to (see Appendix)
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
For (and ), we need a proposition and two lemmas.
If node (transmitter) is intentionally receiving McCTS from node (receiver) during , then the probability that a node does not interfere with is given by
For a Poisson random variable with mean value , and ,
For three random distributed nodes , and ,
Now we can prove (see Appendix)
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, 222In 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
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
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)
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),
By the definition of in Table I,
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  that these pairs are neighboring pairs satisfying ( denoting the degree of a node )
, , but not , or
, but and are not on the same three-cycle (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) which is much larger than 2. Therefore, taking expectation of (11) over all neighboring pairs using Lemma 1 and Lemma 2-(c),
This completes the analysis.
4.4 Special Case: Single-Hop Networks
where is the number of all possible cooperative nodes with respect to and , leading to . 333This 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 ,
and is given below, by reducing (8) with ,
5 Investigating with DISH
We verify the analysis in both single-hop and multi-hop 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 Non-Cooperative Case
This is a multi-channel MAC protocol based on the protocol framework described in Section 3. Key part of its pseudo-code 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 non-cooperative 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 CAM-MAC 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 CAM-MAC 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 multi-hop 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 Non-Cooperative 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 single-hop scenarios, and less than 10% in almost all multi-hop 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 multi-channel MAC protocols. (Finding 1)
Specifically, Fig. (a)a and Fig. (c)c consistently show that, in both single-hop and multi-hop 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 single-hop and multi-hop 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 single-hop 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 single-hop, and in multi-hop 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 non-DISH 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 multi-hop networks, as the single-hop 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 1-3, 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 re-select 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 multi-hop 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 near-linear 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 near-linear 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 non-DISH networks.
The explanation to this linear or near-linear relationship should involve intricate network dynamics. We speculate that the rationale might be that (i) MCC problems are an essential performance bottleneck to multi-channel 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 thought-provoking results.
5.4 Investigation with Real DISH
For the same reason as mentioned for ideal DISH, we present the results for multi-hop 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 1-4 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 near-linear 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 counter-intuitively 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 multi-channel 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 have444We 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
Then we rewrite as
Next, for a given and protocol-specified 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 non-cooperative multi-channel 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 control-plane 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., non-cooperative 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).
b.1 Proof of Proposition 1
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
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
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.
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)
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
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