Dynamic Data Aggregation

Although CIP can reduce unnecessary RTS transmissions, the bottleneck problem is still subsistent if the control process has to be done before each data transmission. The problem becomes more serious as the number of data channels, data rate, or node’s density increases

[3]. It is because that the requests for contention and coordination in the control channel become more intensive under these circumstances. In order to completely break through this limitation, one effective way is to transmit multiple data packets using only one control process [10]. It has three advantages in this way. First, both the physical collisions and the logical blocking by NAVCTRL can be mitigated, because multiple data transmission could be sent after one control process. Second, the time of inter-frame spaces and the backoff will become relatively small due to a long packet’s train. Furthermore, the reception of multiple data packets can be replied using only one ACK packet.

However, a new problem arises: How many packets should be aggregated in one transmission? If the number is too small, the effect by the above advantages will not be significant. Because a node uses its data interface for a short packet’s train, it may still spend the most of time to contend or wait for the access to the control channel. Thus, lead to a lower utilization of its data interface. On the contrary, if the number is too large, it may incur large idle time on its control interface due to too long packet’s train. Consequently the performance could be deteriorated by the increased retransmission cost and the unfairness problem from the longer packet’s train. On the other hand, for a given node, the loading of the control channel in its surrounding area is not always uniform, which would be varied due to some factors such as flow loading, node’s density, and routing path. For example, in Fig. 3-3, it is easier for u to coordinate with v, since v has only two neighbors, but it is much harder if u wants to coordinate with w, where other four nodes are surrounded and all of them compete to create a link with w.

Fig. 3.3 Non-uniform loading in the control channel of node u.

Our main idea is to dynamically adjust the number of data packets to be aggregated for each link based on the idle time of both the control and data interfaces. The primary goal is to balance the utilization of the two interfaces such the average throughput can be maximized.

Consider a node u and a destination v ∈ Nu. The number of packets, that will be aggregated from u to v, is denoted as Ku,v and initiated as 1 at the beginning. Note that each transmission consists of least one data packet and K_u,v can not be over the queue size. Hence, the range of K_u,_v is bound within 1 and |Qv|.

After node u chooses node v as the targeted destination, u would start to initialize a control process. Recall that the control initiation time may be postponed by some reasons (described in 3.2.1). Assuming that node u has been waiting to transmit data packets to v for a period, and it is preparing to restart the control process with v, as shown in Fig. 3.4. At this time point, if node u observes that its data interface has experienced a certain amount of time in idle status, denoted as data_idle_time(u, v) since the start of the current transmission, it will enlarge its K_u,v such that

K_u,_v = min{|Q_v|, K_u,_v + data_idle_time(u, v) / (T_DATA+ T_SIFS)}.

The reason is that the data interface’s idle time during this period is resulted from the recent contention in the control channel of either u or v. It means that the longer data_idle_time(u, v) is, the more serious the control bottleneck problem is. In order to avoid overly sending control messages and to arise the utilization of u’s data interface, the length of the packet’s train has to be expended in proportion to the experienced idle time.

Fig. 3.4 Data interface idle time (simplified).

On the contrary, as shown in Fig. 3.5, if node u observes that its control interface was in idle status for a period of time during the current data transmission, denoted as ctrl_idle_time(u, v), in order to increase the control channel’s utilization and avoid possible cost from retransmission and unfairness problem, it has to shrink back its K_u,v in proportion to the ctrl_idle_time(u, v). That is, node u adjusts

Ku,v = max{1, Ku,v - ctrl_idle_time(u, v) / (TDATA+ TSIFS)}, at the end of the current transmission to v.

Fig. 3.5 Control interface idle time (simplified).

Now, we formally define the two variables of data_idle_time(u, v) and ctrl_idle_time(u, v).

For a transmission from u to v (refer to the illustration in Fig. 3.6), we denote data_tx_time^*(u, v) and data_tx_time(u, v) as respectively the earliest and the actual time when node u can start transmitting data packets to v. That is,

data_tx_time^*(u, v) = ctrl_ini_time^*(u, v) + Tsctrl + TSIFS;

where Tsctrl = TDIFS + TBF + TRTS + τ ^{+ T}SIFS +TCTS + τ, and ctrl_ini_time^*(u, v) is the first control initiation time predicted for the current transmission by CIP component without any postponement. By definitions, u’s data interface need not be active before data_tx_time^*(u, v) and it must be under used after data_tx_time(u, v). In other words, at any time Tcurr(u), the data interface of u is in idle status only if Tcurr(u) ∈ [data_tx_time^*(u, v), data_tx_time(u, v)).

However, the gap between data_tx_time^*(u, v) and data_tx_time(u, v) is not only caused by the contention in the control channel, but also results from the change of link_rel_time(u, v), i.e.

Tcurr(u) < link_rel_time(u, v). It means that the statuses of data channels of u or v is not available. When the later case happens (see the example of the period between t₁ to t₂ in Fig.

3.6a), there is no free data channel to be used for data transmission even if the control channel is free. For the reason, the data interface’s idle time should ignore this case. Accordingly, we have the following definition:

At any time T_curr(u), the data interface of a node u is idle if and only if i) data_tx_time*(u, v) ≤ Tcurr(u)< data_tx_time(u, v);

ii) link_rel_time(u, v) < T_curr(u).

Similarly, referring to Fig. 3.6b, the control interface’s idle time is defined as follows:

At any time T_curr(u), the control interface of a node u is idle if and only if i) data_tx_time(u, v) + TRES < Tcurr(u) < data_tx_time(u, v) + NAVDATA; ii) ch_rel_time(u, 0) < T_curr(u)

iii) There is no physical carrier on the control channel of u.

(a)

(b)

Fig. 3.6 (a) Data interface idle time; (b) Control interface idle time.