Subject: A Note on Broadcast Control Packets

From: Chip Elliott <[email-masked]>
Date: Mon, 01 Dec 1997 09:14:26 -0500

Zygmunt wrote:

  First let me state that I believe that one of the salient advantages 
  that the wireless communication environment offers is the *broadcasting* 
  feature. By taking advantage of this feature (such is the case in ZRP's 
  eavesdropping) does simplify the algorithms and *saves bandwidth*.

This is very true, but let me introduce a wrinkle. Imagine for a moment
that you are using a radio that can -- on a per-packet basis -- switch
frequencies and/or spreading codes. (NTDR in fact does have such a
fancy radio, and I think the GloMo radio will be equally fancy.)

This is a very desirable feature, in some ways, as it lets two radios
in close proximity transmit "in parallel" without the transmissions
interfering with one another. Hence it can increase the overall system
throughput.

However, unless a given radio can simultaneous receive on multiple
channels, it also makes for a serious drawback: there is no longer a
single channel that all radios will be listening to, and hence the
completion rate for broadcasts will be noticeably less than 100%.

In other words, a radio may not hear a broadcast control message
because it is busy transmitting or receiving on another channel.

In our own NTDR work, this has definitely influenced the protocol
design...

-- Chip

---

From: John Zavgren <[email-masked]>
Date: Mon, 01 Dec 1997 09:55:46 -0500

Amen. And if I may add my two bits...

 The use of broadcast channels as a means of efficiently disseminating information among a community of radio nodes is seductive. One transmission can send the same packet to many nodes. 

This is good. However, broadcast transmissions are inherently unreliable, and consequently one will often need some form of acknowledgement and retransmission. When one accounts for this "hidden" overhead, it is often the case that a "barrage" of reliable point to point transmissions is more efficient than a single broadcast.

At 09:14 AM 12/1/97 -0500, Chip Elliott wrote:

-----------

<color><param>ffff,0000,0000</param><bigger><bigger><bigger>John
Zavgren</bigger></bigger></bigger><smaller> 

</smaller></color>617-873-2280

-----------

Expert advice is a great comfort, even when it's wrong.

          Ellen Currie

---

From: Zygmunt Haas <[email-masked]>
Date: Mon, 1 Dec 1997 09:33:37 -0400 (AST)

Hi Chip,

There are a number of ways that you can address this problem. 
One is to have more than one transceivers - for example, two half duplex
transceivers. This is not such an "outrageous" proposal, as the cost of
hardware goes down and transceivers can be today miniaturized to a couple
of chips. Also, only one of the transceivers need to be transmit/receive.
The other can be receice only. We have had a paper describing a MAC scheme
based on two transceivers in the last MILCOM:
 
Z.J. Haas, ``On the Performance of a Medium Access Control Scheme for the
Reconfigurable Wireless Networks,'' IEEE MILCOM'97, Monterey, CA, 
November 2-5, 1997

There is another approach that comes to mind, but we are right now working
on it so I would better not describe it yet.

In any event, I would agree that any routing protocol cannot *exclusively*
depend on the broadcasting feature. In particular, ZRP will also work when
packets are unicasted between nodes, rather than broadcasted. The
flood termination may need to rely on one of the other termination algorithms, 
though.

Zygmunt.
==--==-=- 
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
Prof. Zygmunt J. Haas             tel: +1-607-255-3454
Wireless Networks Laboratory
323 Frank Rhodes Hall             fax: +1-607-255-9072
School of Electrical Engineering  
Cornell University                e-mail: [email-masked]
Ithaca, N.Y. 14853                
U.S.A                             http://www.ee.cornell.edu/~haas/wnl.html
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-

---

From: Zygmunt Haas <[email-masked]>
Date: Mon, 1 Dec 1997 10:39:23 -0400 (AST)

Hi John,

Yes, broadcasting may be unreliable. But there are many situations in which
reliable broadcasting in not required. Especially in route-discovery protocols
that rely on flooding. A node can receive a flood from multiple sources.
If some of them are lost, this does not represent a major problem. 

I would NOT rely on broadcasting to send actual information. But a lot of 
control traffic can efficiently use broadcasting.

Zygmunt.
=-==-=--=  

On Mon, 1 Dec 1997, John Zavgren wrote:

>  The use of broadcast channels as a means of efficiently disseminating information among a 
> community of radio nodes is seductive. One transmission can send the same packet to many nodes. 
> 
> This is good. However, broadcast transmissions are inherently unreliable, and consequently one 
> will often need some form of acknowledgement and retransmission. When one
> accounts for this "hidden" overhead, it is often the case that a "barrage" of reliable point 
> to point transmissions is more efficient than a single broadcast.
>