802.11 PCF and Power Save Mode

Overview• Time is divided into contention period (CP) and contention free period

(CFP).

• During CP, transfers used DCF, i.e., Data-ACK, or RTS-CTS-Data-ACK, with exponential back-off etc.

• During CFP, the AP controls all transmissions. That is, the AP controls which STA transmits to the AP and which STA receives pkts from the AP.

• All STAs can receive packets during the CFP. But the ability to transmit during the CFP is optional. Also, APs do not necessarily support PCF.

• During CFP all durations are set of 2^15, so STA set their NAVs accordingly. The CFP ends with an explicit end of CFP frame from the AP.

• No RTS/CTS in CFP

Learning if PCF is supported

• The AP announces whether it supports PCF in the beacon, and in other management frames.

Beacon Frame

STA Announcing PCF Compatibility• A STA will announce to the AP in the association and reassociation frames

whether it is CF-pollable, i.e., whether it is capable of transmitting during the CFP.

– The AP periodically broadcasts beacons.– The STA uses these beacons to learn about APs.– The STA and the AP authenticate each other.– Then the STA associates with the AP.

• The STA sends association request management frame.

• The AP replies with an association response.

Overview of Topics

• Controlling when CFP occurs– CFP always starts after a beacon. In particular, after a beacon with a DTIM field.

We call these beacons DTIMs

• Transmissions during CFP• Controlling interference between nearby APs CFPs

When does the CFP occur

Sets the TARGET beacon time. The AP only broadcast a beacon when the channel is idle

• CFP Max Duration– Long enough to send and receive one full sized data frame.– Short enough to allow a data frame to be sent during the CP.

• How else can a STA become associated?

• The CFP may extend over several beacons. If the so, the CFP time remaining has how much time is remaining until the Max CFP duration has run out.

• If this beacon is the one that begins the CFP, then MaxDuration = DurRemaining.

• All STAs update their NAV according to the CFP DurRemaining.

DTIM

• Each beacon must contain a CF parameter set and a TIM• A beacon with a TIM is a special TIM if the DTIM count =0;• The number of beacons until the next beacon with the DTIMCount=0 is the

DTimCount (it decrements every beacon).• The number of beacons between beacons with DTIM count = 0 is the DTIM period.• Instead of always saying “beacons with DTIM count = 0,” we just say DTIM. That is a

DTIM is a beacon with DTIM Count = 0.• The CFP Count is the number of DTIMs until the next CFP.• The number of DTIMs between CFPs is the CFP period• If the CFP Count is zero, then a CFP is beginning.• If all beacons are DTIMs, then the period = 1.• I’m not sure why there are two counters.

Transmissions during CFP

• CFP is based on DCF, the AP gains control of the channel by waiting a PIFS (with DIFS>PIFS) after the channel is idle (recall that STAs begin to transmit or begin to decrement their back-off timer DIFS after the channel become idle. – Note that this approach of using variable sized waiting times is a general

tool.• It can be used to support QoS – higher priority transmissions wait a shorter

amount of time.• It can be used to support channel selection – the transmitter that is best

suited to transmit uses a small time. Or the time is set according to the channel quality

• CFP always begin after a DTIM beacon (more on this later). The period and max duration of the CFP is listed in the APs beacons and association response.

• STAs associated with the AP learn when the CFP should begin and automatically set their NAV to Max CFP duration when the CFP is expected to begin (the DTIM beacon does not need to be received)

• If an STA receives a DTIM beacon from another AP (one that it is not associated with), the STA will set its NAV according to the CFPDurationRemaining field that is in the AP’s beacon.

Transmissions during CFP

• Switch between the AP transmitting and the STAs transmitting.

Example of a CFP

beacon Data+CF-poll

SIFS SIFS

Data+CF-ACK from station1 Data+CF-ACK+CF-poll

SIFS SIFS

Data+CF-ACK from station1 Data+CF-ACK+CF-poll

SIFS

Data+CF-ACK+CF-poll

SIFS SIFS

Data+CF-ACK from station1 Data+CF-poll

No ack

Data+CF-ACK+CF-poll

SIFS SIFS

ACK from STA

CF-ACK+CF-poll

SIFS PIFS > SIFS

Data+CF-poll

CF-ACK+CF-end

PIFS All nodes update their NAV

Trans error

No data sent, but data was received

Station did not respond to the poll, so the AP retakes control after PIFS

End of CFP

All nodes update their NAV to 32000 us

frame types relevant to PCF

• Data + CF-ACK (sent by AP or STA)• Data + CF-poll (only sent by AP)• Data + CF-ACK + CF-Poll (only sent by AP)• Null (a data frame with no data)• CF-ACK (sent by STA and AP?)• CF-Poll (sent by AP)• CF-end (sent by AP)• CF-End + CF-ACK (by AP)• ACK (sent by non-pollable STA after receiving data)• Data (sent by AP or STA)

– E.g., Sent by AP to non-pollable STA– E.g., sent by STA that had received a CF-Poll (not data+CF-poll)

CFP details• CFP always starts after a DTIM beacon• CFP starts with the AP transmitting after the DTIM beacon, at which point all nearby STAs should have set

their NAV to CFPMaxDuration• The first transmission must be either a CF-Poll, Data+CF-poll, or CF-End• Data pkts

– can be from the AP to a STA that is not being polled (because it is not the next on the list to be polled or because it is not pollable)

– Can be sent by pollable STAs to any STA when proceeded by a XXX + CF-poll from the AP to STA.• Where XXX can be data, data+CF-ACK, CF-ACK, or nothing

– A non-pollable STA can never send data pkts during CF. But it may receive data pkts.• ACKs

– A non-pollable STA uses ACKs after successfully receiving a data pkt.• If the channel does not become busy within EIFS, the AP regains control of the channel by sending the next pkt.

– A pollable STA uses• ACKs after successfully receiving a data pkt from the AP (or another STA?)• Data + CF-ACK after successfully receiving a data + CF-poll• ACKs after successfully receiving a management frame from the AP

– The AP always uses CF-ACKs.• The AP can piggyback the CF-ACK in a data pkt where the data pkt’s destination is different from the CF-ACK’s destination. In

this case, the CF-ACK is for the data pkt transmission that finished within the last SIFS• The AP can also piggyback an CF-ACK on a CF-poll. This is used when AP does not have any data for the STA that is being

polled. Note that the destination of this frame is the STA being polled. The destination is not necessarily the desired recipient of the CF-ACK. (When might the destination of the CF-ACK+CF-Poll be the STA that is the intended recipient of the CF-ACK?)

• The AP can piggyback CF-ACK on various other combinations.• Drawback of PCF: if the AP-STA channels are not all the same, then there is a possibility that the some STAs can support high

data rate and some cannot. Thus, the data+CF-ACK might have to be transmitted at a a low data rate to ensure that the CF-ACK is correctly received. Some performance improvement is possible by carefully selecting the order of polling STAs (but order is define by STA ID, which is given during association)

• Nonpollable STAs must decode Data + CF-ACK, but ignore the CF-ACK• Why are regular ACKs not used by the AP?

TIM

• TIM = traffic indication map– TIM is field in the beacon if the AP supports PCF– The bitmap control

• First bit = 0 and DTIM Count=0 => there are multicast and/or broadcast frames in the queue.

• Other 7 bits are an offset fo the partial virtual bitmap

– The partial virtual bitmap • is 2008 bits long

• Has a 1 in bit X if STA with AID = 8*Offset + X has a pkt in the AP’s queue (organized in bytes)

– The offset is used so that the virtual bitmap can be shorter (e.g., if there is a queued frame from STA with AID=100, the offset is 12 (12*8=96) and the 4 th (?) bit is one, and the vitrual bitmap has only one byte)

• The TIM included in each beacon so a STA in power save mode can easily detect if it should stay awake and get the frame. More in the power save mode discussion

Polling during CFP

• STAs can only transmit data one SIFS after being polled and can only transmit one frame– Pollable and nonpollable STAs can transmit ACKs as required, but they cannot reset the NAV (as is done

during DCF)

• If the pollable STA transmits a frame in response to a CF-poll but does not receive an ACK (i.e., XXX+CF-ACK), then it cannot retransmit until it is polled again or until the CP.

• A STA can set the MoreData bit is set– The more data bit is in the MAC header. The STA can only set it when responding to a CF-poll request.– (The AP will set MoreData bit to 1 if it has more data for the destination that is in power save mode)– (the AP will set the More Data to 1 in the headers of multicast or broadcasts that be transmitted when the

CFP begins.

• A STA should respond to a poll within SIFS. If not, the AP will regain control PIFS after the CF-poll was sent.

• If a STA has no data to respond with but the CF-poll had data (i.e., Data+CF-poll or Data+CF-ACK+CF-poll), then the STA responds with CF-ACK, with no data

• If the STA is polled without data (i.e., CF-poll or CF-ACK + CF-poll), then it should sent a null frame (no data). This ensures that the AP does not think that that STA missed the pkt because of radio transmission error.

Polling list

• The AP need not poll all STAs; e.g., the CFP can be used for AP to STA (downlink) only.• If the AP does poll, it should maintain a polling list.• At least one STA should be polled during each CFP

– It is not clear what happens if this is not the case– It is not clear if this requirement is feasible since all multicast and broadcast pkts are sent before polling and

there could be more multicast+broadcast than the MaxCFPDuration allows.• The AP should poll the STAs in ascending order of AID

– Note: when an STA becomes associated with the AP, it gets an AID, which is a 2 B value. This AID identifies the STA within the poll

– It is not clear what action the STA should do if this is not the case. Since the STA to be polled is explicit in the CF-poll frame, the STAs will always know whether they are being polled.

– There are reasons to not follow the ascending order. • E.g., if the channels support different rates, the CF-ACK to one STA should be piggybacked on a frame to an STA with a

same or slower channel.– Note, 802.16 orders STA in order of descending data rate, which can change during each frame. Here a frame contains many

data chunks to many different destinations.

– If there is not enough time to poll all STAs before the MaxCFPDuration runs out, then the next STA to be polled is polled first during the next CFP.

– If all queued CF frames have been delivered, then the AP may poll an STA multiple times. It may also transmit management frames to any STA. In this sense, nonpollable STAs have a lower priority than pollable STAs. So there is no reason for an STA to ever say that it is not pollable, it should announce that it is pollable but should never respond to a polled.

• Also, who is going to stop the AP from transmitting to a nonpollable STA before a pollable STA?

• The STAs to be polled are listed in the DTIM

• The AP can transmit a management frame. But there does not exists a CF-management, CF-management+cf-poll, etc.

Power save mode

• A STA tells the AP that it is in PS mode in the MAC header. • The STA can switch between PS mode and non-POS mode after informing the AP• When in PS mode, the STA listens/receives periodically for beacons (the period is a

user parameter)• The AP will buffer frames destined to the STA.

– The TIM is included in every beacon and indicates whether a frame is buffered for the STA.

– In DCF or the CP of PCF: The STA can retrieve the frame by transmitting a PS-poll• The AP either transmits the frame, or• ACKs the PS-poll and transmits the frame later• If there are more frames buffered, the AP sets the more bit. The STA can get this frame with another

PS-poll

– In CFP: the AP will transmit the frame to a pollable STA in PS-mode• If the STA does not respond, the pkt is buffered until the max num tries is reached

– If there is a STA in PS-mode, then the AP will buffer all multicast and broadcast frames until a DTIM is transmitted. So STAs in PS mode may awake up at the CFP and receive these frames.

• The indication that multicast/broadcasts frames are buffered is the first bit of the “offset” field of the TIM

• STAs are not required to wake up for DTIMs• There can be many TIMs between DTIMS

Transfer to STAs in PS – no PCF

• Extreme low power STA wakes up rarely– The AP must buffer frames for a long time

– Multicast/b-cast are buffered until the DTIM even if not using PCF

Pic shows DTIM every 3 TIMS. It could be more or less often.If less often, more delay, lower power.

STAs listen for beacon. And PS-poll if TIM says a pkt is ready.

More PS

• When a STA wakes up during PS, it does not transmit until it receives a frame. This way it can correctly set its NAV

• More data– The AP sets the TIM– The STA transmits a ps-poll– The AP transmits the frame with the more data set– This way the STA can stay awake and retrieve the next frame.– The AP will not send the next data until the first one has been ACKed

• The AP will not buffer frames indefinitely, but must buffer them longer then the STAs “listen interval” which is specified in the association frame during association.

• When a STA exits PS mode, the AP transmits all buffered frames

• In DCF (or CP), if more than one TIM bit is set, the STA transmits a ps-poll after waiting a random time between 0 and CWMin

PS with PCF

• Pollable STA:• The STA must be awake when the DTIM begins• If the TIM indicates no buffered frame, the STA must stay awake for the multicast and

b-cast frames– The existence of a m-cast/bcast frame in the buffer is indicated in the TIM

• If a frame is buffered for the STA, the STA must stay awake until the data has been received and the more data bit is not set.

– If the more data bit is set, then the AP may transmit more data during the current CFP.– After the more data is cleared, the STA may sleep and the AP is not allowed to transmit until

the next CFP• Of course, the bit may be set in the TIM and the STA could retrieve the data during the CP.

• Since the AP is expected to transmit pkts in ascending order of AID, there is a risk that changing the order will result in the premature sleeping of a STA

PS mode in 802.11 ad hoc networks

• In infrastructure mode, the AP transmits beacons.• In ad hoc, all nodes transmit beacons

– When a beacon is to be transmitted, all nodes select a random time between 0 and 2xCWmin

– If a beacon is received before timer expires, then the timer is stopped and no beacon is transmitted

– Multiple beacons might be transmitted, but not all nodes transmit beacons

• After the beacon is transmitted, any node can transmit an ATIM during the ATIM window. ATIM broadcasts are random with time between 0 and aCWmin

• ATIMs are have a destination. If the destination is unicast, the ATIM is ACKed• ACKed ATIMs and ATIMs for broad/multicast destinations are transmitted after the

ATIM windows and after the normal CSMA channel access• Asleep or awake

– If a node transmits a beacon or a ATIM, it msut be awake until the end of the next ATIM window– If a node receives a ATIM, it must stay awake until the end of the next ATIM– Otherwise, the node may sleep– Clearly, the main benefit is if the traffic rate is low. But, if the beacon rate is high…

• Nodes can’t enter PS if the ATIM windows == 0• How can a node determine if another node is in PS mode? The standard does not

say

• APSD (automatic power save delivery)– Not a standard, but widely supported

– When a STA transmits a

Sensor net MACs

• These are similar to power save mode

802.11e – 802.11 with QoS

• 8 user priorities– 2 background– 2 best effort (only slightly more best than the other)– 4 video– The types are not required to be followed. E.g., a sys admin could give the CTO highest priority for her file transfers

• CWmin and CWmax are set differently for each priority• Instead of DIFS, each priority has its own initial waiting time• Each priority has its own max number of long/short retries.

– Why?– So best effort file transfer can be more persistent and have fewer dropped pkts– VoIP needs to get the pkts delivered soon. So late pkts are of no use. They might as well be dropped.– Actually, a better approach is to use a timer instead to a retry counter.

• Each pkt in 802.11e has a timer associated with it• If the time from when the frame first enters the MAC exceeds the MaxTime, then the frame is discarded

– However, there can also be excess queuinh in the network layer. So a better approach is that each frame get a time when it enters the MAC. This time can reflect the time already spend in the network layer queue

• Different approach (not 802.11e)• If the pkt is too old, then drop it• If the pkt is getting old, then it gets higher priority

– The lifetime of the pkt is specified when it enters the network.– Also, the starting location is recorded.– At each hop, the velocity of the pkt is measured and the QoS is adjusted acorrding to whether this velocity is enough for the pkt to meet its

desired time

• The QAP (and AP that supports 802.11e) sets the CWmin, CWmax, and initial waiting periods• There are individual queues for each user priority. Transmission attempts from these queues could collide.

– Such collision occur internal to the STA.– Backoff results– But the retransmit bit is not set

• Along with PC or PCF, 802.11e supports HCF– HCF = hybrid coordinating function (what this is a hybrid of is not clear)

• Each user priority is call AC = access category

Internal queues and sender

• A QSTA has several internal queues and senders. Each queue functions independent of the others. So they may collide (internally) and they also compete for bandwidth.

• Each queue functions independently. We call each independent system a EDCAF (EDCA function)

802.11e - HCF

• QSTA – an STA with the ability to get QoS• QSTAs transmit during TXOPs (transmit opportunities)• TXOPs must be acquired

– Controlling how TXOPs are acquired is how QoS is controlled• Higher priority flows should be able to acquire a TXOP more easily than a lower

priority.

– They can be acquired by completing during CP• Referred to as EDCA (enhanced distributed channel access)

– Or during CP or CFP from the AP• Polled TXOP

• Not that this is different from diffserv – In diffserv high priority traffic will always be served before low priority- not so in

802.11e– In diffserv performance guarantees can be given – not so in 802.11e.

• Hard performance guarantees are very expensive since the benefits of statistical multiplexing cannot be exploited.

– Some types of guarantees can be given in 802.11e by using admission control so some STA cannot join the BSS

• Wasn’t there a 2006 mobicom paper on nearly the same approach?

Obtaining EDCA TXOP

• EDCA TXOP – acquiring a TXOP during with contention• Basic idea (like DCF)

– Backoff is decremented at the end of a slot where the channel is idle has been idle for a short time (in DCF this short time = DIFS) and the channel is idle during the slot

– Once the backoff=0, then transmission is possible

• New things in HCF– Each STA has internal queues, each with a different priority

• The queues can compete and cause internal backoff

– The initial waiting time depends on the STA, priority, and is adjustable (with restrictions)

• recall the basic technique of using small waiting times to give priority

• The slot times are the same

Setting slot times etc.

• Everything happens at slot boundaries. Specifically, for each EDCAF, one of the following can occur– Nothing (if there is no pending transmission for this EDCAF)– Initiate a transmission– Decrement backoff timer (it should be called backoff counter…)– Invoke backoff due to internal collision

• Recall that there are multiple internal queues and hence they can collide. But this collisions occurs without an actual wireless collisions

• In DCF collisions and backoff also occur, but they only occur after a transmissions, so backoff only occurs after a failed transmission. Thus in DCF, at slot boundaries the following are possible

– Do nothing– Decrement backoff timer– Start transmitting

Time to First Slot Boundary• AC – access category, like a priority class• AIFSN[AC] – ‘arbitration interframe space number’ for access category AC, lower means higher priority

– AP has AIFSN>=1– QSTA has AIFSN>=2

• AIFS[AC] – the time for class AC to wait after the medium become “free”– AIFS[AC] = AIFSN[AC] x SlotTime + SIFS

“free” – there is no need to wait for the channel to actually be idle. Instead, read to duration from the MAC header and start waiting after the channel should be free. So SIFS after the channel is idle is really SIFS after the channel should be idle. But we do require the channel to be idle after the SIFS.

If AIFSN[AC]=2, then it’s the same as a non-QoS STA. Otherwise, it is low priority than a non-QoS enabled STA

Time to First Slot Boundary (skip)

• Typical case:– Waiting time = SIFS after last transmission should have finished + AIFSN[AC]*SlotTime –

RXTXTurnAroundTime– After waiting, and the channel is idle and the backoff is zero, then start to transmit. But it takes

RXTXTurnAroundTime to go from receiving (checking if the channel is idle) to transmitting. So the transmission occurs at

• SIFS + AIFSN[AC]*SlotTime• For DSSS, RXTXTurnAroundTime is <5us, but it depends on the transceiver. Today, with chipsets currently available, it

seems to be roughly ½ us. Of course, the shorted the RXTXTurnArroundTime, the better

• Far from previous Sender– When waiting for the channel to become idle, the current transmission is received and ideally it is decoded.

If so, then the PLCP is heard so the above applied.– But if the packet is not properly heard, then we must be careful to not transmit when the ACK is being

received by the previous receiver. So, we wait EIFS– EIFS = DIFS + time to transmit an ACK

• Time to transmit an ACK include an SIFS and PLCP times. With ACK transmitted at 1 Mbps

– For a QSTA, if a packet is received in error, then wait time before the first slot boundary is• EIFS – DIFS + AIFSN[AC]*SlotTime – RXTXTurnAroundTime• IF AIFSN[AC]=2, then the ECDA could begin to transmit after waiting EIFS

– Suppose that the data pkt is received correctly, but the ACK is not. Then might there be a hidden node collision with the ACK?

• No, if the data pkt is received correctly, then the waiting time does not begin until the time specified in the MAC header has passed. This time includes the ACK transmission time.

• If only the ACK is heard, then the waiting time is set to zero, and hence only a SIFS is waited.• If only an ACK is heard, but the ACK is received in error. Then the node waits EIFS, which is too long!

– But what else can you do?– If you don’t wait EIFS, then collision is ACKs might occur, and that would be quite bad in that the period of time wasted (the

data+ACK+?IFS) is longer than the EIFS-DIFS.

Time to First Slot Boundary

• If another EDCAF was transmitting, – then wait until after the ACK arrives + SIFS + AIFSN[AC]*SlotTime –

RXTXTurnAround– Or wait until the ACK should have arrived + SIFS + AIFSN[AC]*SlotTime –

RXTXTurnAround

• If the last transmission did not require an ACK (which can only be determined if the pkt is decoded), then wait, after the data transmission + SIFS + AIFSN[AC]*SlotTime – RXTXTurnAround

• In any other situation where the channel has become idle, then wait + SIFS + AIFSN[AC]*SlotTime – RXTXTurnAround

• After the first SlotBoundary, wait a SlotTime before taking any action.

At a idle slot boundary

• A EDCAF may transmit if– If the channel is idle at the slot boundary– If a frame is pending– If the backoff = 0– If all higher priority EDCAF do not meet the above 3 conditions

• i.e., no higher priority EDCAF is ready to transmit.

• A EDCAF may decrement its backoff if it is nonzero• The EDCAF much backoff its backoff if

– There is a pkt pending– Its backoff=0– Some EDCAF with higher priority is going to start transmitting

• It seems like another reasonable option is to not backoff. I’m not sure why backoff is so important here. After all, the collision did not occur and will never occur.

Multiple transmissions during a TXOP

• Once the medium is acquired, it is possible to transmit multiple frames from the same AC (queue)

• The transmissions cannot last longer than the maximum duration that was specified in the beacon

• The fact that the QSTA will transmit another frame is in the duration/ID field of the header. This time will include– the time to transmit the next frame

• so ACKs are between transmissions

– the burst of frames including the ACK times.• Note that this burst has back-to-back pkts without ACKs between.

• If a transmission during a TXOP fails, recovery can be attempted before the TXOP ends (if there is time left)– If the TXOP ends before a failed transmission is recovered from, then

the EDCAF must backoff. Otherwise, it can continue.

• There is a TXOP limit that controls the maximum duration of a multiframe TXOP. Surprisingly, there is one limit for all EDCAs

• The backoff procedure shall be invoked for an EDCAF when any of the following events occurs:

– A frame with that AC is requested to be transmitted, the medium is busy as indicated by either physical or virtual CS, and the backoff timer has a value of zero for that AC.

• CW[AC] is unchanged– The final transmission by the TXOP holder initiated during the TXOP for that AC

was successful.• CW[AC] = CWMin[AC]

– The transmission of a frame of that AC fails, indicated by a failure to receive a CTS in response to an RTS, a failure to receive an ACK frame that was expected in response to a unicast MPDU, or a failure to receive a BlockAck or ACK frame in response to a BlockAckReq frame.

• CW[AC]++– The transmission attempt collides internally with another EDCAF of an AC that

has higher priority, that is, two or more EDCAFs in the same QSTA are granted a TXOP at the same time.

• CW[AC]++

• Note that CW[AC], CWMin[AC], and CWMax[AC] are one for each AC• Retry counters are incremented when an internal collision occurs (so the pkt

might be dropped without ever trying to transmit)

HCCA - HCF controlled channel access

• Kind of like PCF, but:• The HC (controller) issues TXOPs, which allow multiple

pkt transmissions– The duration of the TXOP is in the QoS+CF_Poll– (A TXOP that is acquired directly by the QSTA has a duration

set by the QSTA)

• TXOP can be issued during CFP or during CP

CAP = controller access period – HCCA supplied TXOPs or PCF

Initiating CAP – controlled

• The AP waits PIFS after the last transmission.• The AP transmits a QOS+CF-Poll

– The QoS+CF-poll specifies with traffic stream or AC the poll is for– This could be done during CFP, but it can also be done during CP– This allows more flexibility than PCF, which has the problem that is

must wait for a DTIM to start. And thus leads to longer delays than HCCA

– QoS+CF-Poll is sent at a BSS-basic rate so all STAs can decode it

• The QSTA can continue to transmit frames until its allocated duration ends. – These frames must be spaced by SIFS

• If the channel is idle for longer the PIFS, it is assumed that the QSTA has completed it transfers.

• The AP can regain control of the channel after waiting PIFS after the QSTA has finished.

ACKs• ACKs are expensive

– Small packets, provide only a binary indications, but yet require SIFS, preamble, PLCP headers, and MAC control data

• CTS and ACK rate– CTS and ACKs are sent at the highest rate in the BSS Basic Rate set that is no

faster than the frame before it, i.e., the CTS rate must be no more than the RTS rate and the ACK rate must be no more than the data rate

– The BSS bacis rate is a set of rate that are listed in the beacon (?) that specify the bit-rates that any STA must support in order to join.

• E.g., a 802.11b/g AP might have 1, 2, 5.5, and 11 as the BSS Bacis rate set. This way 802.11b STA can join

• The AP might only list 1 and 2 as the BSS basic set. Then even very old 802.11b STAs can join.

• What is a good set?

Block ACK

• Block ACK allows ACK to be aggregated into a single pkt• Two types

– Immediate• blockACK sent as soon as requested

– Delayed• blockACK frame sent at the next opportunity with the highest priority• Note that the blockACK is larger than a regular ACK

• During a TXOP, the sender requests a block transmission and the receiver agrees

– The request includes the number of pkts and the response may decrease this number if not enough buffer space is available

• Each frame in the block is separated by a SIFS• Before the block, an RTS/CTS should be used to silence neighbors

– Otherwise, the duration in the data pkts is set to the block size ot TXOP size

• NoACK – it is posisble to mark frame to not need an ACK at all– If the channel is good, then why not save the time– If the frame is very delay sensitive

Admission control and nearly QoS guarantees

• The AP may require admission control for some user priorities.– Usually admission control is used to stop new flows/connections. Stopping STA from joining is different

• In order to gain admission, the QSTA request admissions and specifies– Nominal frame size– Mean data rate– Minumum PHY rate– Inactivity interval– Surplus bandwidth allowance

• The QAP can allow or reject the admission request• If admitted, the admission frame includes the MediumTime • the QSTA computes

– Admitted_time = admitted_time – AveragingPeriod*mediumTime• At every averaging period, the QSTA computes

– Used_time = max(0,used_time – admitted_time)• The amount of the allocated time used.

• After a successful transmission– Used_time = used_time + TimeToTransmitFrame

• The time used up in transmissions

• If the used time reaches the admitted time, then the QSTA cannot transmit any more until the next averaging period

– However, the QSTA could transmit on a lower priority if that low priority does no require admission control• The QAP will issue QoS+CF-Poll to the QSTAs with flows with priority. • The QAP knows how much bandwidth is available, and thus admission control can be used to no

allow flows to start

Automatic power-save delivery (APSD)

• A STA can transmit a frame or a NULL frame to poll the AP. This can occur at any time, not just after a TIM

802.11n

• MIMO, SIMO, MISO– Higher throughput (HT)– Up to 600 Mbps – but only over short distances, like <20 feet

• E.g., 150Mbps up to 15 feet

• 100 Mbps up to 50 feet

• 2x2 up to 4x4 antennas• Use 10, 20, or 40MHz

– 40MHz uses two 802.11b channels• Some care is required to above collisions

• LDPC coding

HT

• Aggregation of multiple frames– Like 802.11e (it includes and expands 802.11e)– Subheader– RIFS (reduced interframe space)– ZiFS (zero interframe space)

• HT burst– Frames in burst can be sent to different destinations– Use ZIFS between frames if at the same power level– Use RIFS if the frames are at different powers