802.11 PCF

1
802.11 PCF
2
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 pckts 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 215, so STA
  set their NAVs accordingly. The CFP ends with an
  explicit end of CFP frame from the AP.
• No RTS/CTS in CFP

3
Learning is PCF is supported

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

4
Beacon Frame
5
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.

6
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

7
When does the CFP occur
Sets the TARGET beacon time. The AP only
broadcast a beacon when the channel is idle
8

• 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.

9
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 DTIMCount0 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.
• Im not sure why there are two counters.

10
(No Transcript)
11
(No Transcript)
12
Transmissions during CFP

• CFP is based on DCF, the AP gains control of the
  channel by waiting a PIFS ??(with DIFSgtPIFS)
  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
  transmits first.
• 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 APs
  beacon.

13
Transmissions during CFP

• Switch between the AP transmitting and the STAs
  transmitting.

14
Example of a CFP
All nodes update their NAV to 32000 us
beacon
DataCF-poll
DataCF-ACK from station1
DataCF-ACKCF-poll
DataCF-ACK from station1
DataCF-ACKCF-poll
SIFS
SIFS
SIFS
SIFS
SIFS
Trans error
DataCF-ACKCF-poll
DataCF-ACK from station1
DataCF-poll
SIFS
No ack
SIFS
No data sent, but data was received
DataCF-ACKCF-poll
ACK from STA
SIFS
SIFS
Station did not respond to the poll, so the AP
retakes control after PIFS
CF-ACKCF-poll
DataCF-poll
SIFS
PIFS gt SIFS
CF-ACKCF-end
End of CFP
All nodes update their NAV
PIFS
15
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 dataCF-poll)

16
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,
  DataCF-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, dataCF-ACK, CF-ACK, or
  nothing
• A non-pollable STA can never send data pkts
  during CF. But is 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 pkts destination is different
  from the CF-ACKs 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-ACKCF-Poll be the STA that
  is the intended recipient of the CF-ACK?)
• The AP can piggyback CF-ACK on various other
  combinations.

17
TIM

• TIM traffic indication map
• TIM is field in the beacon if the AP supports PCF
• The bitmap control
• First bit 0 and DTIM Count0 gt 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 8Offset X
  has a pkt in the APs 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 AID100, the offset is 12 (12896) and
  the 4th (?) 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

18
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.,
  XXXCF-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 DataCF-poll or
  DataCF-ACKCF-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 due to radio
  transmission error.

19
Polling list

• The AP need not poll able STAs 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
  multicastbroadcast 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 no 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 alower 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 be 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

20

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

21
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 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
• In CFP the AP will transmit the frame to a
  pollable STA in PS-mode
• If there is a STA in PS-mode, then the AP will
  buffer all multicast and broadcast frames until
  the CFP. So STAs in PS mode can 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

22
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

23
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 assoication
  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

24
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 I 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

25
Sensor net MACs

• These are similar to power save mode

26
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.

27
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 can each
  independent system a EDCAF (EDCA function)

28
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
• Wasnt there a 2006 mobicom paper on nearly the
  same approach?

29
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 backoff0, 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

30
(No Transcript)
31
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 (if 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

32
Time to First Slot Boundary

• AC access category, like a priority class
• AIFSNAC arbitration interframe space number
  for access category AC, lower means higher
  priority
• AP has AIFSNgt1
• QSTA has AIFSNgt2
• AIFSAC the time for class AC to wait after
  the medium become free
• AIFSAC AIFSNAC x SlotTime SIFS

If AIFSNAC2, then its the same as a non-QoS
STA. Otherwise, it is low priority than a non-QoS
enabled STA
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.
33
(No Transcript)
34
Time to First Slot Boundary

• Typical case
• Waiting time SIFS after last transmission
  should have finished AIFSNACSlotTime
  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 AIFSNACSlotTime
• For DSSS, RXTXTurnAroundTime is lt5us, 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
• Distance 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 AIFSNACSlotTime
  RXTXTurnAroundTime
• IF AIFSNAC2, 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 dont wait EIFS, then collision is ACKs
  might occur, and that would be quite bad in that
  the period of time wasted (the dataACK?IFS) is
  longer than the EIFS-DIFS.

35
Time to First Slot Boundary

• If another EDCAF was transmitting,
• then wait until after the ACK arrives SIFS
  AIFSNACSlotTime RXTXTurnAround
• Or wait until the ACK should have arrived SIFS
  AIFSNACSlotTime 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 AIFSNACSlotTime RXTXTurnAround
• In any other situation where the channel has
  become idle, then wait SIFS
  AIFSNACSlotTime RXTXTurnAround
• After the first SlotBoundary, wait a SlotTime
  before taking any action.

36
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 backoff0
• Some EDCAF with higher priority is going to start
  transmitting
• It seems like another reasonable option is to not
  backoff. Im not sure why backoff is so important
  here. After all, the collision did not occur and
  will never occur.

37
Multiple transmissions during a TXOP

• Once the medium is acquired, it is possible to
  transmit multiple frames from the same AC
• 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 or
• 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

38

• 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.
• CWAC is unchanged
• The final transmission by the TXOP holder
  initiated during the TXOP for that AC was
  successful.
• CWAC CWMinAC
• 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.
• CWAC
• 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.
• CWAC
• Note that CWAC, CWMinAC, and CWMaxAC 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)

39
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 QoSCF_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
40
Initiating CAP controlled

• The AP waits PIFS after the last transmission.
• The AP transmits a QOSCF-Poll
• The QoSCF-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
• QoSCF-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.

41
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?
• Some one buys your box and they cannot connect
  because they have some ancient laptop. They
  call/yell at tech support and maybe write a bad
  review.
• Your box squeezes a few 100 us out of each
  transmission
• Cisco APs use 1 and 2 as the BSS basic set
• nobody ever gets fired for buying cisco

42
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

43
Admission control and nearly QoS guarantees

• The AP may require admission control for some
  user priorities.
• 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 frmae includes the
  MediumTime
• the QSTA computes
• Admitted_time admitted_time
  AveragingPeriodmediumTime
• 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

44
802.11n

• MIMO, SIMO, MISO
• Higher throughput (HT)
• Up to 600 Mbps but only over short distances,
  like lt20 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

45
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

46
(No Transcript)