AIR-AP1832I-F-K9 Cisco Aironet 1832i WiFi 5 AP with Internal Antennas

AIR-AP1832I-F-K9 exact order identity

AIR-AP1832I-F-K9 is a Cisco Aironet 1832i indoor access point with integrated antennas. This exact PID combines regulatory-domain token F with a single controller-based K9 order. Cisco documents 802.11ac Wave 2, 3x3 MIMO with two spatial streams and a maximum 5-GHz PHY rate of 867 Mbps.

Integrated-antenna boundary

The 1832i antenna system is internal. No external antenna is selected by this access-point PID, so mounting location, orientation, ceiling construction and the post-install survey determine how the published platform is used.

Software and order boundary

Cisco identifies AIR-AP1832I-x-K9 as a dual-band, controller-based 802.11ac Wave 2 access point. Record the target controller and software release; Cisco lists AireOS 8.1.121.0 or later as the 1830 Series baseline.

F regulatory-domain evidence

Cisco treats the letter as a regulatory-domain identifier and requires approval for the country of use; it is not a country name. Keep the F-domain approval beside the RF survey and antenna record so a later antenna change triggers a regulatory review.

Make antenna-change control the focus for this F-domain order. Record the approved antenna PID, gain, cable and mounting plan with the country lookup, then require review whenever any RF component changes. The controller configuration and final installation photographs should refer to the same asset. A mechanically compatible replacement antenna is not automatically an approved regulatory substitute.

Power and interface boundary

The AP supports 802.3af, 802.3at, Enhanced PoE, a local power supply and Cisco power injectors. Cisco lists a 15.4 W draw and states that USB is disabled when 802.3af is used. Record the negotiated power and the single Gigabit Ethernet uplink state.

Lifecycle decision

Cisco ended sale of the Aironet 1830 Series on 1 May 2022, ended software maintenance on 1 May 2023 and lists 30 April 2027 as the last support date. Cisco identifies Catalyst 9115AX as the migration family; available inventory does not extend these dates.

Deployment evidence worksheet

Controller join evidence

Stage the access point on the controller release intended for production. Retain the controller model, software version, discovery path, authorization method and first successful CAPWAP join. Confirm that configuration download completes and that both radios reach an expected operational state. Remove any temporary staging authorization before handover. This evidence separates an orderable access point from a unit that has actually been proven compatible with the planned controller environment. For the 1832i, retain the controller or Mobility Express role, software release, regulatory token and first successful join.

Power-state acceptance

Measure power after the access point has joined its controller and the planned radios and services are active. Record switch model, port, negotiated power level, LLDP result and any reduced-capability warning. An idle boot result is not sufficient evidence for the deployed power budget. If an injector is proposed, verify its supported use and include its exact identity in the maintained bill of materials rather than treating it as an unspecified accessory. The 1832i draws up to 15.4 W and supports 802.3af or 802.3at; Cisco states that 802.3af disables the USB port.

Ethernet and cabling proof

Preserve the permanent-link test, patch-lead identities, switch port, negotiated Ethernet rate and error counters. Investigate pair faults, excessive length or rate fallback before wireless acceptance begins. A link light only proves connectivity at some rate; it does not demonstrate the intended uplink performance. Tie the cable result to the AP serial so a later throughput problem can be separated from radio, controller and wired-path causes. Record the single 10/100/1000 Ethernet uplink rate, cable test and switch-port counters before evaluating wireless performance.

Serial-level asset control

Capture chassis serial, base MAC address, carton reference, deployment site, controller assignment and asset owner. Reconcile the identifiers against the purchase line before activation. Multi-unit cartons require an entry for every physical access point; a carton SKU alone cannot show which unit was installed, held as a spare or returned. This record is also needed to trace support entitlement, replacement history and monitoring ownership. For a K910C line, reconcile every received serial against the authorized carton quantity because Cisco's lifecycle description does not state that quantity.

Controlled spare policy

If purchased as a spare, name the protected site population, compatible controller image, storage location, storage conditions and periodic power-on test. Confirm that regulatory token, antenna architecture and mounting parts match the population it protects. Set a final-use review date. A stored unit can become unsuitable while untouched because controller software, country approval, certificates or network architecture may change. A spare 1832i should be tested against the protected controller release, domain, mounting hardware and April 2027 support cutoff.

Capacity observation

Define the expected concurrent clients, application mix, airtime utilization and channel-width assumptions for this location. After commissioning, capture radio utilization, retry behavior and representative throughput during a meaningful load period. Compare the observation with the survey design and state any shortfall. A peak link rate from a data sheet is not a site capacity result and should not replace measured operating evidence. Capacity evidence should use measured airtime, retries, client mix and channel width rather than the published 867-Mbps 5-GHz PHY rate.

Fault-domain separation

Build the acceptance record so power, wired link, controller join, radio state, authentication and application reachability can be reviewed independently. Preserve timestamps and device identifiers across switch and controller logs. When a test fails, identify the failing boundary before replacing hardware. This avoids classifying a cable, policy or controller problem as an access-point defect and creates evidence that can be reused during support escalation. Use controller, switch and client timestamps to separate power, CAPWAP, RF and authentication faults before declaring hardware failure.

Operational log retention

Store the initial controller events, switch-port state, radio assignment, channel list and client test results with a consistent asset identifier. Define how long commissioning evidence is retained and who can retrieve it. A later firmware, controller or RF change should add a new dated observation rather than overwrite the original. The resulting history supports lifecycle decisions and distinguishes a new regression from the accepted baseline. Keep the first accepted join, power, wired, radio and client test results so later software or RF changes have a baseline.

Related Aironet 1832 order records

• AIRAP1832I-FK910C - compare software and procurement form.
• AIR-AP1832I-F-K9C - compare software and procurement form.
• AIRAP1832I-ZK910C - compare regulatory-domain evidence.

Official evidence: Cisco Aironet 1830 Series data sheet; Cisco Aironet 1830 lifecycle bulletin; Cisco Aironet 1830 support page; and Cisco wireless compliance tool.