On Mon, 2011-09-19 at 17:46 +0200, Alexander Simon wrote:
> 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.
:)
Yeah sometimes it looks small but then just seems to get more
complex ... I just had that with uAPSD too.
> 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 have no idea why you need 11.5.1.1 this way -- if you have ever
received probe response information from that peer it should be OK? But
we can stick to this too.
> 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)
I think that just means adopt the bandwidth.
> 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...
I don't see that in 11.14.2?
> 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.
I'm not sure -- the legacy station wouldn't be an HT station so those
rules wouldn't necessarily apply?
> 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.
I think the only way to get that would be to have two independently
created networks that merge by moving?
> 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.
That seems pretty complex too ...
I don't really know. As I said, I think I'd be happy with an
implementation that maybe doesn't fully implement everything as long as
it considers the trade-offs.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
