Cisco Aironet 2702i AIR-CAP2702I-E-K9 プリント
製品コード
AIR-CAP2702I-E-K9
© 2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 20 of 25
Table 4.
Compatibility and Coexistence of 802.11a, 802.11n, and 802.11ac Devices
Receiver Role
Transmitter
Receiver
Receiver
802.11a
802.11n
802.11ac
Intended
recipient
recipient
802.11a
802.11n device drops down to 802.11a
PPDUs
PPDUs
802.11ac device drops
down to 802.11a PPDUs
down to 802.11a PPDUs
802.11n
802.11n device drops
down to 802.11n PPDUs
down to 802.11n PPDUs
802.11ac
Third-party
recipient
recipient
802.11a
For transmitted HT_MM PPDUs, the third
party waits for the packet length as indicated
in the legacy portion of the preamble, then an
extra EIFS (so no collisions)
HT_GF PPDUs, preamble should be
transmitted only if preceded by MAC
protection (for example, RTS/CTS or CTS-to-
self) sent using 802.11a format PPDUs (so no
collisions)
party waits for the packet length as indicated
in the legacy portion of the preamble, then an
extra EIFS (so no collisions)
HT_GF PPDUs, preamble should be
transmitted only if preceded by MAC
protection (for example, RTS/CTS or CTS-to-
self) sent using 802.11a format PPDUs (so no
collisions)
The third party waits for
the packet length indicated
in the legacy portion of the
preamble, then an extra
EIFS (so no collisions)
the packet length indicated
in the legacy portion of the
preamble, then an extra
EIFS (so no collisions)
802.11n
The third party waits for
the packet length indicated
in the legacy portion of the
preamble, then an extra
EIFS (so no collisions)
the packet length indicated
in the legacy portion of the
preamble, then an extra
EIFS (so no collisions)
802.11ac
Furthermore, the preamble of the 802.11ac formatted packet is identical to an 802.11a formatted packet, so the
CCA mechanism kicks in for third-party 802.11a and 802.11n devices. As soon as these third-party devices see the
802.11ac preamble, they know the duration of the packet and know not to transmit during that time. Also, since the
packet is typically followed by an Ack or Block Ack frame sent in an 802.11a frame, the third-party devices can
correctly receive the Ack or Block Ack and then can continue to try to transmit as usual. In the worst case, a
third-party device hears the 802.11ac frame but is out of range of the transmitter of the Ack or Block Ack. But even
here the third party must wait for an extended duration (called EIFS) to allow time for the Ack or Block Ack to be
transmitted without fear of collision.
Because of this preamble-level compatibility, there is no need for 802.11ac devices to precede their 802.11ac
transmissions by CTS-to-self or RTS/CTS. The kinds of inefficiencies associated with sending 802.11g packets in
the presence of 802.11b devices are completely avoided at 5 GHz.
4.2 When to Upgrade to 802.11ac?
IT administrators are in the fortunate position to be able to pick between two great technologies: (1) 802.11n with
A-MPDU, MIMO, beamforming, and speeds from 65 to 450 Mbps within 40 MHz, and (2) 802.11ac with A-MPDU,
MIMO, beamforming, and speeds from 290 to 1300 Mbps within 80 MHz.
802.11n is available today and is sufficient for many customer use cases.
802.11ac is the future of wireless LANs, but Wi-Fi-certified 802.11ac APs are not yet available. 802.11ac can
provide full HD video at range to multiple users, higher client density, greater QoS, and higher power savings from
getting on and off the network that much more quickly.
Most IT administrators deploy new APs at the same time as they fit out a building or retrofit a space. For these, we
recommend installing 802.11n APs today, because of the sheer value of 802.11n. Further, for investment
protection, it is most desirable to install modular APs that are readily field-upgradable to 802.11ac. As 802.11ac
APs become available, these users should start installing 802.11ac APs, since the incremental value of 802.11ac
exceeds any reasonable price differential.