From: Michael Renzmann <lartc@nospam.otaku42.de>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] QoS in wireless networks
Date: Mon, 03 May 2004 09:35:21 +0000 [thread overview]
Message-ID: <40961259.6070107@otaku42.de> (raw)
In-Reply-To: <4095E979.9080706@gbt.tfo.upm.es>
Hi.
Francisco Javier Simo Reigadas wrote:
>> IEEE 802.11 provides a fair channel access for all the nodes including
>> APs and clients. (I do not know about PCF mode implemented)
> It seems that it was abandoned because it didn't work as expected,
It's not abandoned, but it's an optional feature that mostly none AP has
implemented. And it's not a complete protocol afair, but only a
framework that leaves much room for the actual implementation.
> only private extensions like Karlnet's Turbocell can do that (polling
> from a central point)
While Karlnet's Turbocell implements central polling, it does not make
use of PCF. Instead, the stations work in DCF, and all traffic is
transmitted as broadcasts (thus getting rid of 802.11 ACKs which gives
some additional bandwidth). Downside: they loose the ability to have
automatic rate selection.
> and I am not interested in private extensions.
Maybe you'll also consider this as private extension, but you might be
interested in some "DCF-based polling protocol" implementations running
under Linux:
frottle: http://frottle.sourceforge.net/
WiCCP: http://patraswireless.net/software.html
pewit: http://savannah.nongnu.org/projects/pewit
While they all perform a similar goal (implementation of a polling
protocol on top of a normal ethernet link) they use different techniques
to achieve their goal. But they all are not depending on a special
device driver, so you can still choose your hardware freely.
And maybe also this link is of interest:
http://wsched.sourceforge.net/
"While the H-FSC qdisc can be used in a usual wireline environment (e.g.
replacing the standard CBQ scheduler), the purpose of the port to Linux
was to use it as a basis for the prototype implementation of a new form
of wireless link-sharing. The basic problem is that in a wireless
environment the amount of resources consumed in order to transmit X
bytes to a mobile destination depends on the quality of the link to this
station. The link-sharing model developed during the project allows the
integration of goodput and resource-consumption oriented criteria in
hierarchies for wireless link-sharing. Furthermore, the model can be
used with currently available hardware because it can be implemented
above the link layer. For detailed information take a look at the
documents listed in the Documentation section."
They have two interesting papers about their work online:
"Packet scheduling for bandwidth sharing and quality of service support
in wireless local area networks" and "A resource-based approach to MAC
layer independent hierarchical link-sharing in wireless local area
networks", explaining the ideas behind their scheduler.
Bye, Mike
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
next prev parent reply other threads:[~2004-05-03 9:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-03 6:40 [LARTC] QoS in wireless networks Francisco Javier Simo Reigadas
2004-05-03 7:57 ` Ferenc Kubinszky
2004-05-03 8:53 ` Francisco Javier Simo Reigadas
2004-05-03 9:35 ` Michael Renzmann [this message]
2004-05-13 4:48 ` Michael Renzmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40961259.6070107@otaku42.de \
--to=lartc@nospam.otaku42.de \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.