xref: /freebsd/share/man/man9/ieee80211_beacon.9 (revision 2e3507c25e42292b45a5482e116d278f5515d04d)
1.\"
2.\" Copyright (c) 2009 Sam Leffler, Errno Consulting
3.\" All rights reserved.
4.\"
5.\" Redistribution and use in source and binary forms, with or without
6.\" modification, are permitted provided that the following conditions
7.\" are met:
8.\" 1. Redistributions of source code must retain the above copyright
9.\"    notice, this list of conditions and the following disclaimer.
10.\" 2. Redistributions in binary form must reproduce the above copyright
11.\"    notice, this list of conditions and the following disclaimer in the
12.\"    documentation and/or other materials provided with the distribution.
13.\"
14.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
15.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
16.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
17.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
18.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
19.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
20.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
21.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
22.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
23.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
24.\" SUCH DAMAGE.
25.\"
26.Dd August 4, 2009
27.Dt IEEE80211_BEACON 9
28.Os
29.Sh NAME
30.Nm ieee80211_beacon
31.Nd 802.11 beacon support
32.Sh SYNOPSIS
33.In net80211/ieee80211_var.h
34.Pp
35.Ft "struct mbuf *"
36.Fo ieee80211_beacon_alloc
37.Fa "struct ieee80211_node *"
38.Fa "struct ieee80211_beacon_offsets *"
39.Fc
40.\"
41.Ft int
42.Fo ieee80211_beacon_update
43.Fa "struct ieee80211_node *"
44.Fa "struct ieee80211_beacon_offsets *"
45.Fa "struct mbuf *"
46.Fa "int mcast"
47.Fc
48.\"
49.Ft void
50.Fn ieee80211_beacon_notify "struct ieee80211vap *" "int what"
51.Sh DESCRIPTION
52The
53.Nm net80211
54software layer provides a support framework for drivers that includes
55a template-based mechanism for dynamic update of beacon frames transmit
56in hostap, adhoc, and mesh operating modes.
57Drivers should use
58.Fn ieee80211_beacon_alloc
59to create an initial beacon frame.
60The
61.Vt ieee80211_beacon_offsets
62structure holds information about the beacon contents that is used
63to optimize updates done with
64.Fn ieee80211_beacon_update .
65.Pp
66Update calls should only be done when something changes that
67affects the contents of the beacon frame.
68When this happens the
69.Dv iv_update_beacon
70method is invoked and a driver-supplied routine must do the right thing.
71For devices that involve the host to transmit each
72beacon frame this work may be as simple as marking a bit in the
73.Vt ieee80211_beacon_offsets
74structure:
75.Bd -literal
76static void
77ath_beacon_update(struct ieee80211vap *vap, int item)
78{
79        struct ieee80211_beacon_offsets *bo = &ATH_VAP(vap)->av_boff;
80	setbit(bo->bo_flags, item);
81}
82.Ed
83.Pp
84with the
85.Fn ieee80211_beacon_update
86call done before the next beacon is to be sent.
87.Pp
88Devices that off-load beacon generation may instead choose to use
89this callback to push updates immediately to the device.
90Exactly how that is accomplished is unspecified.
91One possibility is to update the beacon frame contents and extract
92the appropriate information element, but other scenarios are possible.
93.Sh MULTI-VAP BEACON SCHEDULING
94Drivers that support multiple vaps that can each beacon need to consider
95how to schedule beacon frames.
96There are two possibilities at the moment:
97.Em burst
98all beacons at TBTT or
99.Em stagger beacons
100over the beacon interval.
101Bursting beacon frames may result in aperiodic delivery that can affect
102power save operation of associated stations.
103Applying some jitter (e.g. by randomly ordering burst frames) may be
104sufficient to combat this and typically this is not an issue unless
105stations are using aggressive power save techniques
106such as U-APSD (sometimes employed by VoIP phones).
107Staggering frames requires more interrupts and device support that
108may not be available.
109Staggering beacon frames is usually superior to bursting frames, up to
110about eight vaps, at which point the overhead becomes significant and
111the channel becomes noticeably busy anyway.
112.Sh SEE ALSO
113.Xr ieee80211 9
114