Subject: MAC ?

From: Ken Peirce <[email-masked]>
Date: Fri, 4 May 2001 16:10:46 -0700

Could someone please point me to the MAC protocol that underlies the various
ad hoc routing protocols? 

Thanks,
	Ken Peirce

---

From: Ya Xu <[email-masked]>
Date: Fri, 4 May 2001 18:32:24 -0700 (PDT)

Ken,

802.11 is the one which has been used for many ad hoc routing research.

-Ya

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 04 May 2001 22:13:59 -0700

Hello,

It's true enough that 802.11 has been used a lot.  But not exclusively,
and part of the point of our work anyway, and I think many others,
is to develop protocols that do not depend on layer-2 properties.

Regards,
Charlie P.

---

From: [email-masked]
Date: Mon, 07 May 2001 11:26:32 +0200

And we can generalize some properties of wireless layer-2 from the basic
properties of radio transmissions:
- one hop broadcast nature 
- unpredictability and unreliability
- bandwidth limitations 

Philippe

---

From: Matthias Gerlach <[email-masked]>
Date: Sat, 05 May 2001 09:30:48 +0100

> > ad hoc routing protocols?

Another one which is not that popular, is Hiperlan / 2 (the European 
counterpart
to IEEE 802.11a) .

regards
Matthias

---

From: Julien Cartigny <[email-masked]>
Date: Tue, 08 May 2001 09:49:06 +0200

That's an interesting point. What are the main differences between this
2 MAC protocols (IEEE 802.11a & Hiperlan / 2) when using them in ad hoc
  networks ? Does anyone have papers or references about this ???

---

From: Marc Pearlman <[email-masked]>
Date: Tue, 8 May 2001 10:28:19 -0400 (EDT)

I was under the impression that HiperLan/2 is solely a wireless
infrastructure network.  HiperLan/1, on the other hand, would support both
infrastructure and ad hoc deployment.

Do I have the right picture here?  Or am I just adding more confusion to
the mix?

Also, does anybody know when HiperLan products will hit the
market?  802.11's popularity is certainly due to the fact that it
has been commercially available for a few years.

- Marc

---

From: Matthias Gerlach <[email-masked]>
Date: Tue, 08 May 2001 21:50:36 +0100

> infrastructure and ad hoc deployment.

Marc,

Hiperlan/2 actually got an "Extension for Home Environment", which
descripes HL/2 devices in an ad-hoc network environment. In that case,
the HL/2
devices use the so-called direct mode (DM) to communicate, whereas in
the
infrastructure mode all traffic goes to, and comes fom, the central
controller (in
that case called access point).

The main difference between HL/2 and IEEE 802.11 ad hoc networks is that
in
IEEE 802.11 all devices are the same, whereas (due to the TDMA scheme in
HL/2) there has to be a central controller scheduling the traffic in
HL/2.
The central controller is (dynamically) elected among the HL/2 ("CC
-capable")
devices.

All Hiperlan Standards are accessible free of charge at
www.etsi.org/bran/ .

hope that helps
Matthias

PS: I am currently writing on my study thesis looking at the different
architectures. If anybody is interested in architecture overviews of
those
standards, just send me an email.

PPS: The main differences in a nutshell: 
IEEE: 
- 5 different PHYs (DSSS, HR/DSSS (802.11b), FHSS, IR, OFDM (802.11a)) 
- CSMA/CA scheme distributed MAC (Distributed Coordination Function) 

HL/2: 
- 1 PHY: OFDM 
- TDMA / TDD scheme, centralized (see above) 
- QoS inherently supported.

---

From: "qi xue" <[email-masked]>
Date: Tue, 8 May 2001 22:37:45 -0400

Hi,

Can u point to me how can HL/2 support Qos "inherently" ?
And how do it support ad hoc networking by TDMA without some kinds of
channel sensing/co-ordination?
Thanks.

qi

---

From: [email-masked]
Date: Wed, 09 May 2001 13:52:15 +0200

Does it not imply that, in "direct mode" HL/2, it is impossible to build an
ad hoc network with more than two hops and the first hop *must* go through
the elected centralizer?  

HL/2 experts told me that HL/2 centralizers cannot interoperate on the same
frequency. Is it true? 

Philippe

---

From: Matthias Gerlach <[email-masked]>
Date: Thu, 10 May 2001 01:47:45 +0100

Qi,

in HL/2 all traffic in the cell (subnet) is scheduled by the central
controller (CC), i.e. the CC gets recource requests and grants recources from
resp. for the nodes (see also Jvrgs email). By inherently, I mean that this
centralised system makes it relatively easy to implement QoS, whereas more
efford has to be made for IEEE 802.11.
Actually HL/2 was designed with this issue in mind (see also
www.etsi.org/BRAN/ ) .

Cheers
Matthias

---

From: "qi xue" <[email-masked]>
Date: Wed, 9 May 2001 22:22:40 -0400

Hi, Matthias

It looks to me quite like bluetooth, in that it allow flexible "master"/cc
and claim to host various network: cellular, IP, and ATM.
And I think it will be painstaking when trying to support multihop ad hoc.

However, I can't find what's the range of it and it's interesting that it
claims that the communications range and data rate is variable and
co-relative.

For QoS I think the main approach is to use the worst case channel condition
to decide tranmision rate.
I do't think qos is quite simple in wireless. Maybe I am not full ubderstand
the standard.
However, it do not tell how to satisfy specific time delays.
And IEEE 802.11 also have optional centralized MAC(PCF) which use polling.

Qi

----- Original Message -----
From: "Matthias Gerlach" <[email-masked]>
To: "qi xue" <[email-masked]>
Cc: "manet" <[email-masked]>
Sent: Wednesday, May 09, 2001 8:47 PM
Subject: Re: MAC ?

> > > > infrastructure network.  HiperLan/1, on the other hand, would
support
> > both

---

From: Matthias Gerlach <[email-masked]>
Date: Thu, 10 May 2001 22:36:10 +0100

Hi Qi,
please find my comments below.

> And I think it will be painstaking when trying to support multihop ad hoc.

Indeed, I did not really think about it yet, you are right. But (there
is
always a but ;-) ) the data rates are higher in HL/2 (up to 54 Mbit/s)
and it
supports more stations in a cell (Bluetooth max. 8 in a piconet), i
reckon more
than 50 (that is a guess, I cannot prove it).
There is another difference
- in bluetooth, all slaves communicate directly with the master (data
transfer) , whereas that is not the case in HL/2, where the stations
communicate among each other, just scheduled by the CC.

> claims that the communications range and data rate is variable and

I had some troubles finding the range as well, but it is about 100 m in
buildings (according to I'X, a German magazine.(i'X 01/2001, they were
talking
about WLAN in general there). What do you mean by the last sentence ?

> And IEEE 802.11 also have optional centralized MAC(PCF) which use polling.

True. But the PCF is not used in IBSS mode (which I consider as the ad
hoc
mode). As to provide QoS in wireless lans, I think the unreliability of
the
wireless Medium makes the whole thing quite difficult, but I don't
really know
lots about that issue, I have to admit.

Hope that helps.

Cheers
Matthias

PS: your email address does not work. <[email-masked]>

---

From: "A. Bruce McDonald" <[email-masked]>
Date: Fri, 11 May 2001 15:02:00 -0400 (EDT)

Hi,

That sounds like a tall order. I think layer-2 properties obviously have
an impact on higher layers--the effects differ for different
(routing) protocols (for example). However, it is true enough that we
don't want the correctness or robustness of a routing protocol (or
whatever) to be tightly bound to some specific MAC layer property.

Perhaps what is needed in addition to 'optimized' MAC protocols for ad-hoc
networks is an abstract interface between the MAC and the upper
layers. Probably something with two sub-layers---MDL and MIL--the the MAC
depednednt sublayer and the MAC independent sublayer--yikes--this will
enable us to create MAC indepedent routing. Of course differnet MACs may
provide different services, for example priorities, power control etc.
This will get all those gross layer violators back under control.

Just a little tounge in cheek. Wasn't IMPEP intended to provided this type
of generalized interface so that MANET routing protocols would be less
depedent on specific MACs?  In the end it all comes down to economics,
philosophy and semantics...

Best Regards,
Bruce