From: Alexander Simon <an.alexsimon@googlemail.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH v3 3/3] mac80211: Add HT operation modes for IBSS
Date: Mon, 19 Sep 2011 17:46:27 +0200 [thread overview]
Message-ID: <36569806.Rgjanm0GiI@alex-1> (raw)
In-Reply-To: <1316437459.5995.29.camel@jlt3.sipsolutions.net>
Wow. I've been looking for anything regarding HT IBSS in the standard but I
must confess that I found nothing.
And, I must confess this is more work than I first expected.
Of course I agree to conforming to the standard.
9.13.3.1 and 11.5.1.1 should not be too difficult to implement and that sould
be done.
I need some help understanding 11.14.2 and 10.3.2.2.2. (11.1.3.4 seems to
explain them somewhat easier in words)
10.3.2.2.2 tells to adopt the HT Info IE or none if none found ("else null"),
which means to disable HT.
Then, 11.14.2 says I should use "the most common value" for the extension
channel, which implies that the HT Info could diverge. This contradicts the
previous statement...
Let's say we'd adopt the HT Info:
We may join the HT IBSS from a legacy station. Logically, we would disable HT
even if there are stations that have HT enabled.
We also could use the most common value, again joining from a legacy STA:
We must be constantly watching and saving IEs and calculate percentages for
them. Over which time window? In larger networks, this could mean several
beacons until this homogenization happened, especially in changing network
environments of mobile devices. When the network is using an HT Mode we aren't
capable of, should we drop HT or even leave the IBSS?
The problem just is that the TSFs are already the same - we have no chance to
tell which HT configuration is the oder one.
My first patch was going in that direction (no most-recent algorithm, just the
first HT Info received is adopted), which quite some work, had an
unpredictable behaviour, needed to change skbs on the fly, etc...
With all this text I'm just trying to say that it would be quite some work and
maybe the resulting code would still be ... problematic.
As broadcasting always happens in legacy mode, I see no problem having a
inhomogeneous HT configuration.
If we want homogenization (I'll just call it that way) I'd like to propose my
idea:
When joining, adopt the most common HT config out there. Save the number of
stations using that configuration, including itself (variable num_configs).
If no HT config found after scanning, create one, setting num_configs to 0.
When another configuration shows up, compare num_configs to the count of that
configuration (should be 1 as it is unlikely that more than one config will
show up within beacon_intervall of typically 100ms).
A station that created its own config will always adopt another one (as
num_configs == 0), but a station that has already changed won't (num_configs >
0).
Constantly update num_configs. Eg having 4 stations seeing each other should
result in all stations having num_configs = 4. One STA leaving -> num_config =
3 and so on.
This way we could limit the uncontrolled growth somewhat.
I'll apreciate any comments on this.
Thanks, Alex
next prev parent reply other threads:[~2011-09-19 15:46 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-17 22:14 [PATCH v3 1/3] nl80211: Parse channel type attribute in an ibss join request Alexander Simon
2011-09-17 22:14 ` [PATCH v3 2/3] mac80211: Add HT helper functions Alexander Simon
2011-09-19 12:55 ` Johannes Berg
2011-09-19 13:01 ` Alexander Simon
2011-09-17 22:14 ` [PATCH v3 3/3] mac80211: Add HT operation modes for IBSS Alexander Simon
2011-09-17 22:54 ` Alexander Simon
2011-09-19 13:04 ` Johannes Berg
2011-09-19 15:46 ` Alexander Simon [this message]
2011-09-20 12:21 ` Johannes Berg
2011-09-20 18:12 ` Luis R. Rodriguez
2011-09-20 18:21 ` Felix Fietkau
2011-09-20 18:38 ` Luis R. Rodriguez
2011-09-20 18:46 ` Felix Fietkau
2011-09-20 19:05 ` Luis R. Rodriguez
2011-09-20 19:31 ` Felix Fietkau
2011-09-20 20:18 ` Luis R. Rodriguez
2011-09-20 21:04 ` Felix Fietkau
2011-09-20 21:26 ` Luis R. Rodriguez
2011-09-20 21:52 ` Luis R. Rodriguez
2011-09-20 22:09 ` Felix Fietkau
2011-09-20 22:39 ` Luis R. Rodriguez
2011-09-20 21:52 ` Felix Fietkau
2011-09-20 22:37 ` Luis R. Rodriguez
2011-09-20 22:54 ` Felix Fietkau
2011-09-20 23:04 ` Luis R. Rodriguez
2011-09-20 18:55 ` Javier Cardona
2011-09-19 12:52 ` [PATCH v3 1/3] nl80211: Parse channel type attribute in an ibss join request Johannes Berg
2011-09-19 13:18 ` Alexander Simon
2011-09-19 13:32 ` Johannes Berg
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=36569806.Rgjanm0GiI@alex-1 \
--to=an.alexsimon@googlemail.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@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.