netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vladimir Kondratiev <vkondra@mail.ru>
To: netdev@oss.sgi.com
Subject: TGe overview #3
Date: Mon, 2 Aug 2004 22:38:57 +0300	[thread overview]
Message-ID: <200408022239.04871.vkondra@mail.ru> (raw)

[-- Attachment #1: Type: text/plain, Size: 3068 bytes --]

Finally, let's review Traffic Streams.

There are 2 different concepts: logical layer (admission) and completely new 
media access mechanism HCCA (Hybrid Coordinator Channel Access).

Idea behind HCCA is similar to PCF (Point Coordinator Function) from old 
802.11 standard. Hybrid Coordinator (HC), which have to be AP, decides who 
will talk when.

Technically it is implemented as following:
All time divided into contention based (EDCA TXOP's) and contention free CAP 
(Controlled AccessPhase). When HC want to start CAP, it simply starts it 
after PIFS interval of idle media. PIFS is shorter then any interval between 
EDCA frame exchange sequences, thus HC will preempt any EDCA flow at his 
will. Then, HC can either transmit frames, or it may send Contention Free 
Poll (CFP) frame to some STA. This frame gives to the STA "polled" TXOP, in 
contrast with EDCA TXOP. CFP frame provides TXOP duration.

Now, admission control. For HCCA it is the only mechanism. But, admission 
control may be activated also for 2 high priority EDCA categories.

For EDCA it mean the following: one can't use these categories as it was 
described in EDCA, instead, TID should be obtained. For EDCA this mechanism 
used to control bandwidth allocation. But remember, EDCA is contention based 
policy, without any guarantee.

TID's 8-15 dedicates to TS (Traffic Streams). In order to obtain TID, STA 
should send request to AP. Corresponded frame called ADDTS, it contain 
traffic specification: requested bandwidth, delay, periodicity, frame size 
etc. AP may accept or decline this request. It may also come with counter 
proposal with different parameters.

TS may be up-stream, down-stream, or bi-direction

If TS accepted by AP, AP provides schedule information. This information 
consist of Service Interval (SI) - interval between successive Service 
Periods (SP), during which AP serves this TS, and Start Time.
Start time have the following meaning: STA may request exact timing in ADDTS 
request. In this case, it will be served at precise times StartTime+n*SI. 
This used for power save: STA may identify itself as power down, but wake up 
for its stream. Obvious usage is .11 phones.

Here, important QoS related part is:
AP admin decides upon admission control policy. For "legacy stations", that 
don't speak TS (stations implementing WME spec), it may provide only 2 low 
priority access categories. These STA will be severely impacted in 
performance.
STA have to know TGE in order to get real performance. And, STA need to know 
how to identify streams (RSVP like).

One additional feature: DLP (Direct Link Protocol). Unrelated to anything 
else. Idea is to let 2 stations to talk directly. Link establishment is 
through AP, but later they send frames directly, reducing media time 2x. This 
is important for applications like streaming of high definition TV, for which 
"usual" way when AP forward frames, is unacceptable.

P.S. I did not covered many other stuff which is not related directly to QoS.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

                 reply	other threads:[~2004-08-02 19:38 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=200408022239.04871.vkondra@mail.ru \
    --to=vkondra@mail.ru \
    --cc=netdev@oss.sgi.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).