From: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
To: "Goldenshtein, Victor" <victorg@ti.com>
Cc: linux-wireless@vger.kernel.org, hostap@lists.shmoo.com,
kgiori@qca.qualcomm.com, mcgrof@frijolero.org,
zefir.kurtisi@neratec.com, adrian.chadd@gmail.com, j@w1.fi,
Johannes Berg <johannes@sipsolutions.net>,
Luciano Coelho <coelho@ti.com>, Assaf Azulay <assaf@ti.com>,
"Divinsky, Yonatan" <yoni.divinsky@ti.com>,
Igal Chernobelsky <igalc@ti.com>,
adrian@freebsd.org, nbd@nbd.name
Subject: Re: DFS implementation status update
Date: Tue, 10 Jan 2012 23:25:24 +0100 [thread overview]
Message-ID: <20120110222524.GF19790@pandem0nium> (raw)
In-Reply-To: <CAK80WHZZp=NxVigOZWgECF6Z1Apdzc3dPCXyYRn98QizALTh=g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2499 bytes --]
Hello Victor,
thank you for the update, it is nice to hear that you're working on this!
I have a few questions regarding your implementation and whether you have
some features on your list for possible future extensions, please see below.
If you don't have them on your list, I could work on some of them too, please
don't take this as if I'd expect that you need to do that. ;)
On Tue, Jan 10, 2012 at 10:22:44AM +0200, Goldenshtein, Victor wrote:
> Main DFS procedures
> ===================
>
> 1. Hostapd gets driver's DFS capabilities.
Do you plan to support IBSS/Ad-Hoc as well?
>
> 2. If 80211h is enabled in the hostapd.conf and the driver supports
> one of the above radar detection techniques, hostapd may use DFS
> channels.
I guess you're implementing the channel switch part for now, any plans
on the rest of 802.11h? (station measurement, TPC, etc).
>
> 3. Hostapd selects an operational channel (default from hostapd.conf),
> if selected channel is a DFS channel, hostapd sends
> start_radar_detection command to the device/driver which starts
> monitoring for radar interference while hostapd sets a timer for a CAC
> (Channel Availability Check) time, which is 60 seconds (DFS spec).
>
> 4. As CAC timer expires and no radar has been detected, hostapd may
> continue with the init flow, otherwise if interference is detected
> hostapd randomly selects another channel (later on this can be changed
> to ACS). If the new channel is also a DFS channel hostapd performs CAC
> once again, while the original channel is added to a "black list" for
> a period of ''No-Occupancy'' time (time that the channel can't be
> used/selected).
Do you plan to allow band selection or channel selection? For example,
it would be desirable to only select indoor channels or outdoor channels,
exclude weather channels (5600-5650 MHz) or only select a specific subband where
high tx power is allowed.
I'm also not sure if pre-selecting a start channel is conforming to
ETSI EN 301 893 V1.5.1 - as I'd interpret it (but I might be wrong), a
channel should always be randomly selected from the available channel list
(4.7.2.6 Uniform Spreading) - there is not test specified for this though (Annex A).
I'm also missing the channel switch announcement for associated clients in your
flow chart, but maybe you skipped this to keep it simple. It looks like a good approach,
I'm really looking forward to your patchset.
Cheers,
Simon
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2012-01-10 22:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-10 8:22 DFS implementation status update Goldenshtein, Victor
2012-01-10 15:56 ` Martin Schleier
2012-01-10 22:25 ` Simon Wunderlich [this message]
2012-01-11 8:50 ` Goldenshtein, Victor
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=20120110222524.GF19790@pandem0nium \
--to=simon.wunderlich@s2003.tu-chemnitz.de \
--cc=adrian.chadd@gmail.com \
--cc=adrian@freebsd.org \
--cc=assaf@ti.com \
--cc=coelho@ti.com \
--cc=hostap@lists.shmoo.com \
--cc=igalc@ti.com \
--cc=j@w1.fi \
--cc=johannes@sipsolutions.net \
--cc=kgiori@qca.qualcomm.com \
--cc=linux-wireless@vger.kernel.org \
--cc=mcgrof@frijolero.org \
--cc=nbd@nbd.name \
--cc=victorg@ti.com \
--cc=yoni.divinsky@ti.com \
--cc=zefir.kurtisi@neratec.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