This section presents the medium access part of our protocol by integrating the channel assignment part in the previous section. The channel model is as follows. The overall bandwidth is divided into one control channel and n data channels D1, D2, . . . , Dn. Each channel, including control and data ones, is of the same bandwidth. The purpose of data channels is to transmit data packets and acknowledgements. Control channel serves in many important management purposes: (i) to synchronize the use of data channels among hosts, (ii) to broadcast beacons periodically, and (iii) to search for routes. Note that beacons can help mobile hosts to discover which hosts are currently neighbors. Hosts can always communicate with others through the control channel, but they can only communicate with each other through data a channel if they switch to the same one. Route discovery and routing functions are beyond the scope of this paper and will not be elaborated, but can be supported by the control channel.
In our protocol, the channel assignment should be done in advanced. We think that the organization, e.g. city governments or corporations, should take the responsibility
of channel allocation if it wants to use GRID in its district such that the best perfor-mance can be got. It is something like that FCC regulates the use of radio spectrum to satisfy the communications needs without interference.
Each mobile host is equipped with two half-duplex transceivers:
• control transceiver: This transceiver will operate on the control channel to ex-change control packets with other mobile hosts and to obtain rights to access data channels.
• data transceiver: This transceiver will dynamically operate on one of the data channels, according to our channel assignment, to transmit data packets and acknowledgements.
Each mobile host X maintains the following data structure.
• CUL[ ]: This is called the channel usage list. Each list entry CUL[i] keeps records of how and when a host neighboring to X uses a channel. CUL[i] has three fields:
– CUL[i].host: a neighbor host of X.
– CUL[i].ch: a data channel used by CUL[i].host.
– CUL[i].rel time: when channel CUL[i].ch will be released by CUL[i].host.
Note that this CUL is distributedly maintained by each mobile host and thus may not contain the precise information.
The main idea of our protocol is as follows. For a mobile host A to communicate with host B, A will send a RTS (request-to-send) to B. This RTS will also carry the channel number that A intends to use in its subsequent transmission. Then B will match this request with its in CUL[ ] and, if granted, reply a CTS (clear-to-send) to A. All these will happen on the control channel. Similar to the IEEE 802.11 [1], the purpose of the RTS/CTS dialogue is to warn the neighborhood of A and B not to interfere their subsequent transmission, except that a host is still allowed to use the channels different from that indicated in the RTS and CTS packets. Finally, transmission of a data packet will occur on the data channel.
Table 2: Meanings of variables and constants used in our protocol.
TSIF S length of short inter-frame spacing TDIF S length of distributed inter-frame spacing
TRT S time to transmit a RTS TCT S time to transmit a CTS Tcurr the current clock of a mobile host TACK time to transmit an ACK
NAVRT S network allocation vector on receiving a RTS NAVCT S network allocation vector on receiving a CTS
Ld length of a data packet
Lc length of a control packet (RTS/CTS) Bd bandwidth of a data channel Bc bandwidth of a control channel
τ maximal propagation delay
The complete protocol is shown below. Table 2 lists the variables/constants used in our presentaiton.
1. On a mobile host A having a data packet to send to host B, it first checks whether the following two conditions are true:
a) B is not equal to any CUL[i].host such that
CUL[i].rel time > Tcurr+ (TDIF S+ TRT S+ TSIF S + TCT S).
If so, this means B will still be busy (in using data channel CUL[i].ch) after a successful exchange of RTS and CTS packets.
b) Suppose A determines that its current data channel is DA. Then for each i = 1..n,
(DA= CUL[i].ch) =⇒ (CUL[i].rel time ≤ Tcurr+(TDIF S+TRT S+TSIF S+TCT S)).
If so, this means A’s data channel is either not currently being used by any of its neighbors, or currently being occupied by some neighbor(s) but will be released after a successful exchange of RTS and CTS packets. (Fig. 6 shows how the above timing is calculated.)
DA
NAVRTS0 NAVRTS1 Time
B = Backoff D = DIFS
S = SIFS
Tcurr Trel_time
Figure 6: Timing to determine whether a channel will be free after a successful exchange of RTS and CTS packets.
If the above two conditions are true, proceed to step 2; otherwise, A must wait at step 1 until these conditions become true.
2. Then A can send a RT S(DA, Ld) to B, where Ld is the length of the yet-to-be-sent data packet. Also, following the IEEE 802.11 style, A can send this RTS only if there is no carrier on the control channel in a TDIF S plus a random backoff time period. Otherwise, it has to go back to step 1.
3. On a host B receiving the RT S(DA, Ld) from A, it has to check whether the following condition is true for each i = 1..n:
(DA= CUL[i].ch) =⇒ (CUL[i].rel time ≤ Tcurr+ (TSIF S + TCT S)).
If so, DA is either not currently being used by any of its neighbors, or currently being used by some neighbor(s) but will be released after a successful transmission of a CTS packet. Then B replies a CT S(DA, NAVCT S) to A, where
NAVCT S = Ld/Bd+ TACK + 2τ.
Then B tunes its data transceiver to DA. Otherwise, B replies a CT S(Test) to A, where Test is the estimated time that B’s data channel DA will change minus the time for an exchange of a CTS packet:
Test = max{∀i CUL[i].ch = DA, CUL[i].rel time} − Tcurr− TSIF S − TCT S. 4. On an irrelevant host C = B receiving A’s RT S(DA, Ld), it has to inhibit itself
from using the control channel for a period
NAVRT S0 = TSIF S + TCT S+ τ.
This is to avoid C from interrupting the RTS → CTS dialogue between A and B. Then, C senses channel DA for a period of τ to determine whether this communication is success or not. If so, it appends an entry CUL[k] to its CUL such that:
CUL[k].host = A CUL[k].ch = DA
CUL[k].rel time = Tcurr+ NAVRT S1
where
NAVRT S1 = Tcurr+ Ld/Bd+ TACK+ τ.
5. Host A, after sending its RTS, will wait for B’s CTS with a timeout period of TSIF S+ TCT S+ 2τ . If no CTS is received, A will retry until the maximum number of retries is reached.
6. On host A receiving B’s CT S(DA, NAVCT S), it performs the following steps:
a) Append an entry CUL[k] to its CUL such that CUL[k].host = B
CUL[k].ch = DA
CUL[k].rel time = Tcurr+ NAVCT S
b) Send its DATA packet to B on the data channel DA.
On the other hand, if A receives B’s CT S(Test), it has to wait for a time period Test and go back to step 1.
7. On an irrelevant host C = A receiving B’s CT S(DA, NAVCT S), C updates its CUL. This is the same as step 6a) except that
CUL[k].rel time = Tcurr+ NAVCT S+ τ.
On the other hand, if C receives B’s CT S(Test), it ignores this packet.
Figure 7: An example that the control channel is fully loaded and the data channel D4
is not utilized.
8. On B completely receiving A’s data packet, B replies an ACK on DA.
To summarize, our protocol relies on the control channel to negotiate the transmis-sions among hosts using the same data channel. Also, note that although our protocol will send timing information in packets, these are only relative time intervals. No absolute time is sent. So there is no need of clock synchronization in our protocol.