reating & Administering Wireless Networks
`
`reles
`tworks
`
`e Definitive Guide
`
`Matthew S. Gast
`SCT Exhibit 2024
`IPR2025-01183
`
`
`
`
`
`
`
`
`
`SECOND EDITION
`
`802.11° Wireless Networks: The
`Definitive Guide
`
`Matthew Gast
`
`OREILLY®
`
`Beijing + Cambridge + Farnham - Koln - Sebastopol - Tokyo
`
`SCT Exhibit 2024
`[PR2025-01183
`
`
`
`
`
`
`
`
`
`802.11° Wireless Networks: The Definitive Guide, Second Edition
`by Matthew Gast
`
`Copyright © 2005 Mathhew Gast. All rights reserved.
`Printed in the United States of America.
`
`Published by O'Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.
`
`O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions
`are also available for most titles (http:/fmy.safaribooksonline.com). For more information, contact our
`corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com.
`
`Editor: Mike Loukides Cover Designer: Karen Montgomery
`Production Editor: Colleen Toporek Interior Designer: David Futato
`: lHlustrator: Robert Romano
`
`April 2002: First Edition.
`April 2005: Second Edition.
`
`Revision History for the Second Edition:
`2008-10-20 Sixth release
`2010-04-12 Seventh release
`2010-08-30 Eighth release
`2011-02-18 Ninth release
`2013-04-05 Tenth release
`
`See hetp:toreilly.com/catalog/errata.csp?isbn=9780596100520 for release details,
`
`Nutshell Handbook, the Nutshell Handbook logo, and the O'Reilly logo are registered trademarks of
`O’Reilly Media, Inc. 802.11% Wireless Networks: The Definitive Guide, Second Edition, the image of a
`horseshoe bat, and related trade dress are trademarks of O’Reilly Media, Inc.
`
`802.11® and all 802.11-based trademarks and logos are trademarks or registered rrademarks of IEEE,
`Inc. in the United States and other countries. O’Reilly Media, Inc. is independent of IEEE.
`
`Many of the designations used by manufacturers and sellers to distinguish their prodticts are claimed as
`trademarks. Where those designations appear in this book, and O'Reilly Media, Inc., was aware of a
`trademark claim, the designations have been printed in caps or initial caps.
`
`While every precaution has been taken in the preparation of this book, the publisher and authors assume
`no responsibility for errors or omissions, or for damages resulting from the use of the information con-
`tained herein.
`
`ISBN: 978-0-596-10052-0
`LSy
`1365094995
`
`SCT Exhibit 2024
`IPR2025-01183
`
`
`
`
`
`
`
`
`
`MAC header
`bytes ’ 2 6
`T
`
`T T
`
`T T T T T T T T T
`Frame BSSID Transmitter Address
`
`Control
`I
`
`) ! ) L i
`
`bits 2 2 4 T — 1 1 1
`
`H T T T T =
`Protocol | Type =control| Subtype =PS - Poll FromDS | More | Retry | Pwr | More [Protected
`frag Mgmt | Data | frame
`
`ol 1,0 0ol 0|0 0 | 0
`
`0
`
`i
`
`Figure 4-19. PS-Poll frame
`
`Association ID (AID)
`Instead of a Duration field, the PS-Poll frame uses the third and fourth bytes in the
`MAC header for the association ID. This is a numeric value assigned by the access
`point to identify the association. Including this ID in the frame allows the access
`point to find any frames buffered for the now-awakened mobile station.
`
`Address 1: BSSID
`This field contains the BSSID of the BSS created by the access point that the sender
`is currently associated with.
`
`Address 2: Transmitter Address
`This is the address of the sender of the PS-Poll frame.
`
`The PS-Poll frame does not include duration information to update the NAV. However,
`all stations receiving a PS-Poll frame update the NAV by the short interframe space plus
`the amount of time required to transmit an ACK. The automatic NAV update allows
`the access point to transmit an ACK with a small probability of collision with a mobile
`station.
`
`Association ID (AID)
`
`In the PS-Poll frame, the Duration/ID field is an association ID rather than a value used
`by the virtual carrier-sensing function. When mobile stations associate with an access
`point, the access point assigns a value called the Association ID (AID) from the range
`1-2,007. The AID is used for a variety of purposes that appear throughout this book.
`
`Management Frames
`
`Management is a large component of the 802.11 specification. Several different types
`of management frames are used to provide services that are simple on a wired network.
`Establishing the identity of a network station is easy on a wired network because net-
`work connections require dragging wires from a central location to the new worksta-
`tion. In many cases, patch panels in the wiring closet are used to speed up installation,
`
`84 | Chapter4: 802.11Framing in Detail
`
`SCT Exhibit 2024
`IPR2025-01183
`
`
`
`
`
`
`
`
`
`2
`
`2
`
`MAC header
`
`Information
`
`elements and
`
`Al
`
`fixed fields
`0-2,312
`
`4
`T
`
`T
`
`Frame
`Control
`i
`
`T
`Duration
`
`Seg-
`o
`1
`
`Frame
`Body
`
`F(S
`
`H
`
`Figure 4-20. Generic management frame
`
`but the essential point remains: new network connections can be authenticated by a
`personal visit when the new connection is brought up.
`
`Wireless networks must create management features to provide similar functionality.
`802.11 breaks the procedure up into three components. Mobile stations in search of
`connectivity must first locate a compatible wireless network to use for access. With
`wired networks, this step typically involves finding the appropriate data jack on the
`wall. Next, the network must authenticate mobile stations to establish that the au-
`thenticated identity is allowed to connect to the network. The wired-network equiva-
`lentis provided by the network itself. If signals cannot leave the wire, obtaining physical
`access is at least something of an authentication process. Finally, mobile stations must
`associate with an access point to gain access to the wired backbone, a step equivalent
`to plugging the cable into a wired network.
`
`The Structure of Management Frames
`
`802.11 management frames share the structure shown in Figure 4-20. The MAC header
`is the same in all management frames; it does not depend on the frame subtype. Man-
`agement frames use information elements, little chunks of data with a numerical label,
`to communicate information to other systems.
`
`Address fields
`
`As with all other frames, the first address field is used for the frame’s destination ad-
`dress. Some management frames are used to maintain properties within a single BSS.
`To limit the effect of broadcast and multicast management frames, stations are required
`to inspect the BSSID after receiving a management frame, though not all implementa-
`tions perform BSSID filtering. Only broadcast and multicast frames from the BSSID
`that a station is currently associated with are passed to MAC management layers. The
`one exception to this rule is Beacon frames, which are used to announce the existence
`of an 802.11 network.
`
`BSSIDs are assigned in the familiar manner. Access points use the MAC address of the
`wireless network interface as the BSSID. Mobile stations adopt the BSSID of the access
`point they are currently associated with. Stations in an IBSS use the randomly generated
`BSSID from the BSS creation. One exception to the rule: frames sent by the mobile
`
`Management Frames | 85
`
`SCT Exhibit 2024
`[PR2025-01183
`
`
`
`
`
`
`
`
`
`station seeking a specific network may use the BSSID of the network they are seeking,
`or they may use the broadcast BSSID to find all networks in the vicinity.
`
`Duration calculations
`
`Management frames use the Duration field in the same manner that other frames do:
`
`1. Any frames transmitted in the contention-free period set the duration to 32,768.
`
`7. Frames transmitted during the contention-based access periods using only the DCF
`use the Duration field to block access to the medium to allow any atomic frame
`exchanges to complete.
`
`A 1f the frame is a broadcast or multicast (the destination address is a group
`address), the duration is 0. Broadcast and multicast frames are not acknowl-
`edged, so the NAV is not needed to block access to the medium.
`
`. If a nonfinal fragment is part of a multiframe exchange, the duration is set to
`the number of microseconds taken up by three SIFS intervals plus the next
`fragment and its acknowledgment.
`
`. Final fragments use a duration that is the time required for one acknowledg-
`ment plus one SIFS.
`
`Frame body
`
`Management frames are quite flexible. Most of the data contained in the frame body
`uses fixed-length fields called fixed fields and variable-length fields called information
`elements. Information elements are blobs of data of varying size. Each data blob is
`ragged with a type number and a size, and it is understood that an information element
`of a certain type has its data field interpreted in a certain way. New information elements
`can be defined by newer revisions to the 802.11 specification; implementations that
`predate the revisions can ignore newer elements. Old implementations depend on
`backward-compatible hardware and frequently can’t join networks based on the newer
`standards. Fortunately, new options usually can be easily turned off for compatibility.
`
`This section presents the fixed fields and information elements as building blocks and
`shows how the building blocks are assembled into management frames. 802.11 man-
`dates the order in which information elements appear, but not all elements are manda-
`tory. This book shows all the frame building blocks in the specified order, and the
`discussion of each subtype notes which elements are rare and which are mutually ex-
`clusive.
`
`Fixed-Length Management Frame Components
`
`10 fixed-length fields may appear in management frames. Fixed-length fields are often
`referred to simply as fields to distinguish them from the variable-length information
`elements. Fields do not have a header to distinguish them from other parts of the frame
`
`86 | Chapter4: 802.11Framingin Detail
`
`SCT Exhibit 2024
`IPR2025-01183
`
`
`
`
`
`
`
`
`
`T T T T T T T T T T T T T T
`
`o 1 2 3 4 s & 7 8 9 w0 N o B W B
`
`Authentication algorithm number
`Least significant <& » Most significant
`
`Figure 4-21. Authentication Algorithm Number field
`
`bits
`T B T T R T T T T T T T T T T
`0 1 2 3 4 5 6 7 8 9 10 n 12 13 14 15
`Authentication transaction sequence number
`Least significant & P Most significant
`
`Figure 4-22. Authentication Transaction Sequence Number field
`
`body. Because they have a fixed length and appear in a known order, fields can be
`delimited without using a field header.
`
`Authentication Algorithm Number
`
`Two bytes are used for the Authentication Algorithm Number field, which are shown
`in Figure 4-21. This field identifies the type of authentication used in the initial 802.11-
`level authentication process before association occurs. 802.1X authentication occurs
`after association, and is not assigned an algorithm number. (The authentication process
`is discussed more thoroughly in Chapter 8.) The values permitted for this field are
`shown in Table 4-3. Only two values are currently defined. Other values are reserved
`for future standardization work.
`
`Table 4-3. Values of the Authentication Algorithm Number field
`
`Value Meaning
`0 Open System authentication (typically used with 802.1X authentication)
`1 Shared Key authentication (deprecated by 802.11i)
`
`2-65,535 Reserved
`
`Authentication Transaction Sequence Number
`
`Authentication is a multistep process that consists of a challenge from the access point
`and a response from the mobile station attempting to associate. The Authentication
`Transaction Sequence Number, shown in Figure 4-22, is a two-byte field used to track
`progress through the authentication exchange. It takes values from 1 to 65,535; it is
`never set to 0. Use of this field is discussed in Chapter 8.
`
`Management Frames | 87
`
`SCT Exhibit 2024
`[PR2025-01183
`
`
`
`
`
`
`
`
`
`T T T T 1 T
`
`T T
`7 8 9 10 1 12 13
`
`Beacon interval
`Least significant & P Most significant
`
`Figure 4-23. Beacon Interval field
`
`bits 0 1 2 3 4 5 6 7 g§ 9 10 11 12 13 14 15
`Short Channel ‘ Short I < ‘
`
`Bss | 1BSS |, 55 | P piay L preamble | o POC f Tagity | Reserved | stot | Reserved D555 Reserved
`Pollable | request (802.11b) (802.11h) (802178 time OFDM
`
`1 | 1
`
`Figure 4-24. Capability Information field
`Beacon interval
`
`Beacon transmissions announce the existence of an 802.11 network at regular intervals.
`Beacon frames carry information about the BSS parameters and the frames buffered by
`access points, so mobile stations must listen to Beacons. The Beacon Interval, shown
`in Figure 4-23, is a 16-bit field set to the number of time units between Beacon trans-
`missions. One time unit, which is often abbreviated TU, is 1,024 microseconds (ms),
`which is about 1 millisecond.3 Time units may also be called kilo-microseconds in
`various documentation (Kms or kms). It is common for the Beacon interval to be set
`to 100 time units, which corresponds to an interval between Beacon transmissions of
`approximately 100 milliseconds or 0.1 seconds.
`
`Capability Information
`The 16-bit Capability Information field (Figure 4-24) is used in Beacon transmissions
`
`to advertise the network’s capabilities. Capability Information is also used in Probe
`Request and Probe Response frames. In this field, each bit is used as a flag to advertise
`a particular function of the network. Stations use the capability advertisement to de-
`termine whether they can support all the features in the BSS. Stations that do not im-
`plement all the features in the capability advertisement are not allowed to join.
`
`ESS/IBSS
`These two bits are mutually exclusive. Access points set the ESS field to 1 and the
`IBSS field to O to indicate that the access point is part of an infrastructure network.
`Stations in an IBSS set the ESS field to 0 and the IBSS field to 1.
`
`3. Kilo-microseconds are an odd blend of the powers-of-2 used in computing for the kilo, and the more
`common 1/1,000 for micro. Presumably, the International Bureau of Weights and Measures would protest
`the mangling of the traditional form of the prefixes.
`
`88 | Chapter4: 802.11Framing in Detail
`
`SCT Exhibit 2024
`IPR2025-01183
`
`
`
`
`
`
`
`
`
`MAC header
`[
`
`byres‘ 2 2 6 6 2 1 Variable 4
`T T T T T T T T T 1 T T T T T T T T i T T
`frame {Duration DA SA BSSID Seq- Frame S
`Control ctl Body
`L R R B o L L - - bl
`bytes 82— 27" Variable 7 2 8 4 Variable
`T T T H o1 T 1 1 1 T T ¢ 1 1 17 T T T
`Timestamp Beacon [Capability| SSID FH 0§ CF 18SS TIM
`Interval{ Info ParametesSet Pa"g':f""' ParameterSet |Parameter Set
`b b L L F RS TS B I S | i SN T U S S H I3 1
`‘ Mandatory | Optional >
`Variable 3 6 8 4 3 Variable Variable
`L T 1 1 1 1 T ¢ U 17 1 171 1T L
`Country Power Channel Quiet TPC ERP Extended Robust
`Info Contest Switch Report rates Security network
`) F I A T S | S T S R S S l‘ 1
`| Optional (continued) /
`
`Figure 4-51. Beacon frame
`Types of Management Frames
`
`The fixed fields and information elements are used in the body of management frames
`to convey information. Several types of management frames exist and are used for
`various link-layer maintenance functions.
`
`Beacon
`
`Beacon frames announce the existence of a network and are an important part of many
`network maintenance tasks. They are transmitted at regular intervals to allow mobile
`stations to find and identify a network, as well as match parameters for joining the
`network. In an infrastructure network, the access point is responsible for transmitting
`Beacon frames. The area in which Beacon frames appear defines the basic service area.
`All communication in an infrastructure network is done through an access point, so
`stations on the network must be close enough to hear the Beacons.
`
`Figure 4-51 shows most the fields that can be used in a Beacon frame in the order in
`which they appear. Not all of the elements are present in all Beacons. Optional fields
`are present only when there is a reason for them to be used. The FH and DS Parameter
`Sets are used only when the underlying physical layer is based on frequency hopping
`or direct-sequence techniques. Only one physical layer can be in use at any point, so
`the FH and DS Parameter Sets are mutually exclusive.
`
`The CF Parameter Set is used only in frames generated by access points that support
`the PCF, which is optional. The TIM element is used only in Beacons generated by
`access points, because only access points perform frame buffering. If the Country-spe-
`cific frequency hopping extensions were to be present, they would follow the Country
`information element. Frequency hopping networks are much less common now,
`
`Management Frames | 109
`
`SCT Exhibit 2024
`[PR2025-01183
`
`
`
`
`
`
`
`
`
`[————-———————— MAC header Frame hody
`bytes 1 2 2 6 6 2 | Variable Variable } 4
`T
`
`T T TTTTTY TTTTT Extended
`Frame [Duration DA SA Seq- | SSID Supported Supported £CS
`Control a Rates Rates <
`
`|
`
`1 F Y T 1
`
`Figure 4-52. Probe Request frame
`
`though, so I omit the frequency hopping extensions for simplicity. Likewise, the IBSS
`DEFS element occur between the Quiet and TPC Report elements, were it to appear.
`
`Probe Request
`
`Mobile stations use Probe Request frames to scan an area for existing 802.11 networks.
`The format of the Probe Request frame is shown in Figure 4-52. All fields are mandatory.
`
`A Probe Request frame contains two fields: the SSID and the rates supported by the
`mobile station. Stations that receive Probe Requests use the information to determine
`whether the mobile station can join the network. To make a happy union, the mobile
`station must support all the data rates required by the network and must want to join
`the network identified by the SSID. This may be set to the SSID of a specific network
`or set to join any compatible network. Drivers that allow cards to join any network use
`the broadcast SSID in Probe Requests.
`
`Probe Response
`
`If a Probe Request encounters a network with compatible parameters, the network
`sends a Probe Response frame. The station that sent the last Beacon is responsible for
`responding to incoming probes. In infrastructure networks, this station is the access
`point. In an IBSS, responsibility for Beacon transmission is distributed. After a station
`
`transmits a Beacon, it assumes responsibility for sending Probe Response frames for
`the next Beacon interval. The format of the Probe Response frame is shown in Fig-
`ure 4-53. Some of the fields in the frame are mutually exclusive; the same rules apply
`to Probe Response frames as to Beacon frames.
`
`The Probe Response frame carries all the parameters in a Beacon frame, which enables
`mobile stations to match parameters and join the network. Probe Response frames can
`safely leave out the TIM element because stations sending probes are not yet associated
`and thus would not need to know which associations have buffered frames waiting at
`the access point.
`
`IBSS announcement traffic indication map (ATIM)
`
`IBSSs have no access points and therefore cannot rely on access points for buffering.
`When a station in an IBSS has buffered frames for a receiver in low-power mode, it
`sends an ATIM frame during the delivery period to notify the recipient it has buffered
`data. See Figure 4-54.
`
`110 | Chapter4: 802.11 Framing in Detail
`SCT Exhibit 2024
`IPR2025-01183
`
`
`
`
`
`
`
`
`
`Roaming is sometimes given yet another meaning, referring to the process of moving
`a network session from one network (say, an 802.11 wireless LAN) to another disparate
`network (say, a 3G mobile telephone network). The IEEE has started another working
`group to define roaming operations to move network sessions and state between dif-
`ferent types of IEEE 802 networks.
`
`Power Conservation
`
`The major advantage of wireless networks is that network access does not require nodes
`to be in any particular location. To take full advantage of mobility, nothing can con-
`strain the location of a node, including the availability of electrical power. Mobility
`therefore implies that most mobile devices can run on batteries. But battery power is a
`scarce resource; batteries can run only so long before they need to be recharged. Re-
`quiring mobile users to return frequently to commercial power is inconvenient, to say
`the least. Many wireless applications require long battery life without sacrificing net-
`work connectivity.
`
`As with any other network interface, powering down the transceiver can lead to great
`power savings in wireless networks. When the transceiver is off, it is said to be sleep-
`ing, dozing, or in powersaving mode (PS). When the transceiver is on, it is said to be
`awake, active, or simply on. Power conservation in 802.11 is achieved by minimizing
`the time spent in the latter stage and maximizing the time in the former. 802.11 ac-
`complishes this without sacrificing connectivity.
`
`Power Management in Infrastructure Networks
`
`Power management can achieve the greatest savings in infrastructure networks. All
`traffic for mobile stations must go through access points, so they are an ideal location
`to buffer traffic. Most traffic can be buffered. The standard forbids buffering frames
`that require in-order delivery and have Order bit set because buffer implementations
`could possibly re-order frames. There is no need to work on a distributed buffer system
`that must be implemented on every station; the bulk of the work is left to the access
`point. By definition, access points are aware of the location of mobile stations, and a
`mobile station can communicate its power management state to its access point. Fur-
`thermore, access points must remain active at all times; it is assumed that they have
`access to continuous power. Combining these two facts allows access points to play a
`key role in power management on infrastructure networks.
`
`Access points have two power management-related tasks. First, because an access point
`knows the power management state of every station that has associated with it, it can
`determine whether a frame should be delivered to the wireless network because the
`station is active or buffered because the station is asleep. But buffering frames alone
`does not enable mobile stations to pick up the data waiting for them. An access point’s
`second task is to announce periodically which stations have frames waiting for them.
`
`Power Conservation | 193
`
`SCT Exhibit 2024
`IPR2025-01183
`
`
`
`
`
`
`
`
`
`The periodic announcement of buffer status also helps to contribute to the power sav-
`ings in infrastructure networks. Powering up a receiver to listen to the buffer status
`requires far less power than periodically transmitting polling frames. Stations only need
`to power up the transmitter to transmit polling frames after being informed that there
`is a reason to expend the energy.
`
`Power management is designed around the needs of the battery-powered mobile sta-
`tions. Mobile stations can sleep for extended periods to avoid using the wireless net-
`work interface. Part of the association request is the Listen Interval parameter, the
`number of Beacon periods for which the mobile station may choose to sleep. Longer
`listen intervals require more buffer space on the access point; therefore, the Listen
`Interval is one of the key parameters used in estimating the resources required to sup-
`port an association. The Listen Interval is a contract with the access point. In agreeing
`to buffer any frames while the mobile station is sleeping, the access point agrees to wait
`for at least the listen interval before discarding frames. If a mobile station fails to check
`for waiting frames after each listen interval, they may be discarded without notification.
`
`Unicast frame buffering and delivery using the Traffic Indication Map (TIM)
`
`When frames are buffered, the destination node’s Association ID (AID) provides the
`logical link between the frame and its destination. Each AID is logically connected to
`frames buffered for the mobile station that is assigned that AID. Multicast and broad-
`cast frames are buffered and linked to an AID of zero. Delivery of buffered multicast
`and broadcast frames is treated in the next section.
`
`Buffering is only half the battle. If stations never pick up their buffered frames, saving
`the frames is a rather pointless exercise. To inform stations that frames are buffered,
`access points periodically assemble a traffic indication map (TIM) and transmit it in
`Beacon frames. The TIM is a virtual bitmap composed of 2,008 bits; offsets are used
`so that the access point needs to transmit only a small portion of the virtual bitmap.
`This conserves network capacity when only a few stations have buffered data. Each bit
`in the TIM corresponds to a particular AID; setting the bit indicates that the access
`point has buffered unicast frames for the station with the AID corresponding to the bit
`position.
`
`Mobile stations must wake up and enter the active mode to listen for Beacon frames to
`receive the TIM. By examining the TIM, a station can determine if the access point has
`buffered traffic on its behalf. To retrieve buffered frames, mobile stations use PS-Poll
`Control frames. When multiple stations have buffered frames, all stations with buffered
`data must use the random backoff algorithm before transmitting the PS-Poll.
`
`Each PS-Poll frame is used to retrieve one buffered frame. That frame must be positively
`acknowledged before it is removed from the buffer. Positive acknowledgment is re-
`quired to keep a second, retried PS-Poll from acting as an implicit acknowledgment.
`Figure 8-12 illustrates the process.
`
`194 | Chapter8: Management Operations
`
`SCT Exhibit 2024
`[PR2025-01183
`
`
`
`
`
`
`
`
`rime (9 ps-Poll’
`
`ALK
`
`AP
`
`PSPl
`
`ACK
`PS-Poll
`e
`
`ALK
`
`1f multiple frames are buffered for a mobile station, then the More Data bit in the Frame
`Control field is set to 1. Mobile stations can then issue additional PS-Poll requests to
`the access point until the More Data bit is set to 0, though no time constraintis imposed
`by the standard.
`
`Figure 8-12. PS-Poll frame retrieval
`
`After transmitting the PS-Poll, a mobile station must remain awake until either the
`polling transaction has concluded or the bit corresponding to its AID is no longer set
`‘1 the TIM. The reason for the first case is obvious: the mobile station has successfully
`polled the access point; part of that transaction was a notification that the mobile sta-
`tion will be returning to a sleeping mode. The second case allows the mobile station to
`return to a power Conservation mode if the access point discards the buffered frame.
`Once all the traffic buffered for a station s delivered or discarded, the station can resume
`sleeping.
`
`The buffering and delivery process is illustrated in Figure 8-13, which shows the me-
`dium as it appears to an access point and two associated powersaving stations. The
`hash marks on the timeline represent the beacon interval. Every beacon interval, the
`access point transmits a Beacon frame with a TIM information element. (This figure is
`somewhat simplified. A special kind of TIM is used to deliver multicast traffic; it will
`be described in the next section.) Station 1 has a listen interval of 2, so it must wake up
`to receive every other TIM, while station 2 has a listen interval of 3, so it wakes up to
`process every third TIM. The lines above the station base lines indicate the ramp-up
`process of the receiver to listen for the TIM.
`
`At the first beacon interval, there are frames buffered for station 1. No frames are buf-
`
`fered for station 2, though, so it can immediately return to sleep. At the second beacon
`interval, the TIM indicates that there are buffered frames for stations 1 and 2, although
`
`Powet Conservation | 195
`
`SCT Exhibit 2024
`IPR2025-01183
`
`
`
`
`
`
`
`
`
`Beacon
`
`i interval ' 1 [ | '
`
`TIM: Framefor1 TIM: Framesfor TIM: Framefor2 TIM: Framesfor TIM: No frames TIM: No frames
`1and2
`
`[©) Time
`
`| ’
`
`Station 1 | - >
`1
`@ Time
`
`Station 2 —& }
`
`& fime
`
`Figure 8-13. Buffered frame retrieval process
`
`only station 1 woke up to listen to the TIM. Station 1 issues a PS-Poll and receives the
`frame in response. At the conclusion of the exchange, station 1 returns to sleep. Both
`stations are asleep during the third beacon. At the fourth beacon, both wake up to listen
`to the TIM, which indicates that there are frames buffered for both.
`
`Both station 1 and station 2 prepare to transmit PS-Poll frames after the expiration of
`a contention window countdown, as described in Chapter 3. Station 1 wins because
`its random delay was shorter. Station 1 issues a PS-Poll and receives its buffered frame
`in response. During the transmission, station 2 defers. If, at the end of that frame
`transmission, a third station, which is not illustrated, seizes the medium for transmis-
`sion, station 2 must continue to stay awake until the next TIM. If the access point has
`run out of buffer space and has discarded the buffered frame for station 2, the TIM at
`the fifth beacon indicates that no frames are buffered, and station 2 can finally return
`to a low-power mode.
`
`Stations may switch from a power conservation mode to active mode at any time. It is
`common for laptop computers to operate with full power to all peripherals when con-
`nected to AC power and conserve power only when using the battery. If a mobile station
`switches to the active mode from a sleeping mode, frames can be transmitted without
`waiting for a PS-Poll. PS-Poll frames indicate that a powersaving mobile station has
`temporarily switched to an active mode and is ready to receive a buffered frame. By
`definition, active stations have transceivers operating continuously. After a switch to
`active mode, the access point can assume that the receiver is operational, even without
`receiving explicit notification to that effect.
`
`Access points must retain frames long enough for mobile stations to pick them up, but
`buffer memory is a finite resource. 802.11 mandates that access points use an aging
`function to determine when buffered frames are old enough to be discarded. The stan-
`dard leaves a great deal to the discretion of the developer because it specifies only one
`
`196 | Chapter8: Management Operations
`
`SCT Exhibit 2024
`[PR2025-01183
`
`
`
`
`
`
`
`
`
`constraint. Mobile stations depend on access points to buffer traffic for at least the
`listen interval specified with the association, and the standard forbids the aging function
`from discarding frames before the listen interval has elapsed. Beyond that, however,
`there is a great deal of latitude for vendors to develop different buffer management
`routines.
`
`Delivering multicast and broadcast frames: the Delivery TIM (DTIM)
`
`Frames with a group address cannot be delivered using a polling algorithm because
`they are, by definition, addressed to a group. Therefore, 802.11 incorporates a mech-
`anism for buffering and delivering broadcast and multicast frames. Buffering is identical
`to the unicast case, except that frames are buffered whenever any station associated
`with the access point is sleeping. Buffered broadcast and multicast frames are saved
`using AID 0. Access points indicate whether any broadcast or multicast frames are
`buffered by setting the first bit in the TIM; this bit corresponds to AID 0.
`
`Each BSS has a parameter called the DTIM Period. TIMs are transmitted with every
`Beacon. At a fixed number of Beacon intervals, a special type of TIM, a Delivery Traffic
`Indication Map (DTIM), is sent. The TIM element in Beacon frames contains a counter
`that counts down to the next DTIM; this counter is zero in a DTIM frame. Buffered
`broadcast and multicast traffic is transmitted after a DTIM Beacon. Multiple buffered
`frames are transmitted in sequence; the More Data bit in the Frame Control field in-
`dicates that more frames must be transmitted. Normal channel acquisition rules apply
`to the transmission of buffered frames. The access point may choose to defer the pro-
`cessing of incoming PS-Poll frames until the frames in the broadcast and multicast
`transmission buffers have been transmitted.
`
`Figure 8-14 shows an access point and one associated station. The DTIM interval of
`the access point is set to 3, so every third TIM is a DTIM. Station 1 is operating in a
`sleep mode with a listen interval of 3. It will wake up on every third beacon to receive
`buffered broadcast and multicast frames. After a DTIM frame is transmitted, the buf-
`fered broadcast and multicast frames are transmitted, followed by any PS-Poll ex-
`changes with associated stations. At the second beacon interval, only broadcast and
`multicast frames are present in the buffer, and they are transmitted to the BSS. At the
`fifth beacon interval, a frame has also been buffered for station 1. It can monitor the
`map in the DTIM and send a PS-Poll after the transmission of buffered broadcast and
`multicast frames has concluded.
`
`To receive broadcast and multicast frames, a mobile station must be awake for DTIM
`transmissions. Nothing in the specification, however, keeps powersaving stations in
`infrastructure networks from waking up to listen to DTIM frames. Some products that
`implement powersaving modes will attempt to align their awakenings with DTIM
`transmissions. If the system administrator determines that battery life is more impor-
`tant than receiving broadcast and mult