Subject: multiple channels

From: Dmitri Deshun Perkins <[email-masked]>
Date: Wed, 5 Dec 2001 13:27:03 -0500 (EST)

Hello,

I am working on QoS issues(at the network layer) in MANETs.
However, one of the key factors limiting the provision of QoS
in the ad hoc environment appears to be the MAC layer and the
use of a single channel for all communications.

Is there any work on using multiple channels? Are there specific
reasons why at least two channels (one for MAC-level control
packets and one for data packets) cannot be used? Would this be
beneficial in the multi-hop environment? in a mobile, multi-hop
environment?

I realize that this may be an engineering-type question, but the
use of multiple channels would certainly influence protocol design.

Please comment...

Thanks,
Dmitri

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 05 Dec 2001 13:18:21 -0800

Dmitri,

We have used multiple channels under IEEE 802.11b to instantiate multiple
MANETs that may overlap geographically yet remain seperate from an RF
perspective. What you suggest in terms of seperate channels for control
and data messages makes sense but implies the existence of a radio
technology that allows simultaenous monitoring of multiple channels.
But, using IEEE 802.11b (the de facto experimental MANET radio) would
require multiple interfaces since each interface can only actively
monitor a single RF channel at a time. (A time-division multiplexing
scheme could possibly be used on a single IEEE 802.11b interface, but
seems intuitively sub-optimal.)

Fred Templin
[email-masked]

---

From: Rex Buddenberg <[email-masked]>
Date: Thu, 6 Dec 2001 08:59:48 -0800

Fred,

If you reinterpret Dmitri's 'multiple channels' into multiple queues, 
then we have something more sensible.  Multiple queues avoids the 
multiple RF interfaces and all the bad things that that implies (self 
jamming, multiple hardware, etc).  It makes sense in RF networks to 
have at least two queues which are time division muxed into the same 
physical channel:
  - one for scheduled traffic.  MAC is controlled by a schedule that 
prevents >1 transmitter from sending at a time.  This maxes 
efficiency, and trades off interactivity to get it.
  - a second, random access, queue that is used to gain entry into the 
schedule.  Outsiders are, by protocol, only allowed to broadcast 
during this window so we have the silent host problem here ... but it 
self-attenuates since success in this queue means the host disappears 
from it and is moved into the first queue.

I see no reason why some QoS data can't be passed in the entry frame 
in the second queue (e.g. 'I need in the net and I have 1345 bytes of 
z precedence traffic').

-- 
b

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 06 Dec 2001 09:41:41 -0800

Rex,

You are right, and this is also something we have done. The Linux Traffic
Classifier (TC) and FreeBSD ALTQ mechanisms provide ready-made tools to enable
priority queuing mechanisms that can be used to enable a QoS service such as
that presented by the IETF 'diffserv' model. A reasonable configuration decision
might be to give control traffic priority such that it will still make progress
in the face of heavy data traffic.

Fred
[email-masked]