AIR-AP1832I-A-K9 Cisco Aironet 1832i 802.11 a/b/g/n/ac Access Point

AIR-AP1832I-A-K9 exact order identity

AIR-AP1832I-A-K9 is a Cisco Aironet 1832i indoor access point with integrated antennas. This exact PID combines regulatory-domain token A 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.

A 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. Retain the destination-country result, the exact A-domain PID and the controller country setting in one approval record.

Use receiving as the A-domain control point: photograph the carton PID, reconcile it with the purchase order and attach the Cisco lookup before the serial is released. At commissioning, compare the controller country setting with that same record. A return replacement must repeat both checks because matching enclosure and antenna form do not establish matching regulatory identity.

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

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.

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.

Authentication path test

Commission representative clients through association, authentication, address assignment, DNS and application reachability. Preserve the identity policy used, test client type, result and relevant controller logs. An access point that joins its controller has not yet demonstrated the user path. Repeat the test after any controller, certificate or authentication-service change and retain failures separately from RF or switch-port evidence. Test association, authentication, DHCP, DNS and application reachability after the AP reaches its final controller or Mobility Express role.

Roaming acceptance

Define the neighboring access points and client types used for roaming validation. Record handoff behavior, interruption observed, authentication result and controller events along the intended movement path. Compare the outcome with the site's design target rather than declaring success from static association. Where this unit replaces an older AP, test both entry and exit from its cell so a local improvement does not hide a boundary problem. Roaming acceptance should identify neighboring cells, client type and controller events rather than treating static association as proof.

Interference baseline

Preserve the pre-install and post-install noise, neighboring-radio and channel-occupancy observations for the selected location. Record any controller-driven channel change during acceptance. If the regulatory profile limits the channel choices, state how that constraint affected reuse and mitigation. This baseline gives future troubleshooting a reference point and prevents an unrelated interference change from being attributed to the hardware order. Preserve the live controller country and enabled-channel state beside the exact domain token and deployment approval.

Replacement dependency map

Map this unit to controller, licenses, authentication services, switch power, cable, bracket, antenna design and monitoring objects. For an end-of-sale platform, state which dependencies can be reused by the planned Catalyst migration and which require change. A nominal access-point replacement can fail when the surrounding platform was never inventoried. Keep the map with the asset rather than only in a one-time project file. Cisco names Catalyst 9115AX as the migration family; map controller, power, mounting and coverage changes before replacement.

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.

Handover completeness

The handover package should include exact order identity, destination approval, serial record, controller evidence, switch port, mounting or antenna record, user-path tests and named operational owners. Review the package with the receiving team and list unresolved exceptions. A unit is not operationally accepted when important evidence remains only in installer notes, email attachments or an unowned temporary dashboard. Handover should contain exact PID, serials, quantity evidence, compliance lookup, software role, mounting record and lifecycle owner.

Related Aironet 1832 order records

• AIRAP1832I-AK910C - compare software and procurement form.
• AIR-AP1832I-A-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.