Early 802.11a brought a 5 GHz wireless LAN option into a market familiar with 2.4 GHz 802.11b. Interoperability testing helped establish whether independently implemented products could communicate. To interpret a historical certification claim, identify the program date, tested modes and exact product configuration.
What the July 2002 record establishes
The WECA update included in the IEEE 802.11 July 2002 meeting minutes (PDF) reports that a second round of 802.11a interoperability testing had finished at the end of May. It anticipated another round in August, with a testbed and formal certification to follow. The record therefore places July in the program’s development period; it should not be read as proof that every contemporary a-mode product already held a completed certification.
The same update shows the emerging capabilities-label concept separating band and maximum data rate. Those fields answer which radio mode a product supports. Application throughput remains affected by protocol overhead, contention, signal conditions and the rest of the network.
Read compatibility in layers
- Radio mode: an a-only 5 GHz device and a b-only 2.4 GHz device need a shared supported mode to communicate directly. A dual-band access point can serve different clients through its supported radios.
- Configuration: firmware, driver, channel, security settings and regional variant form part of the tested pairing.
- Interoperability: association and data transfer with specified partner devices establish behavior within that test scope.
- Deployment: coverage, workload capacity and service recovery require evidence from the intended environment.
For current product research, use the Wi-Fi certification-record guide to match an exact variant to the features in its record. Treat a period certification as historical scope, especially when considering old security settings.
Use a bounded compatibility matrix
On a narrow screen, scroll the table sideways. Keyboard users can focus the table and use the arrow keys.
| Pairing and configuration | Observation to record | Interpretation |
|---|---|---|
| Client A and AP A; documented common mode | Association, address assignment and controlled data transfer | Baseline for the setup. |
| Client A and AP B; same supported mode | Repeated connection and bidirectional transfer | Cross-vendor behavior for this pairing. |
| Client B and AP A; documented driver version | Connection after reconnect or restart | Checks another client implementation and recovery. |
| Only one parameter changed | Before/after result and full configuration | Helps isolate a failure without changing several causes at once. |
Keep the endpoint, payload and measurement method constant. Save both successful and failed runs. A completed laboratory matrix can support a local compatibility decision; use the certification body’s own records for a claim about formal certification.
Handle historical hardware as historical hardware
For a collection or research demonstration, record labels, revision numbers, manuals and software provenance before powering or configuring equipment. Conduct legacy network experiments in an appropriately isolated laboratory with a test endpoint and no personal credentials. Modern internet services may depend on capabilities that the old client lacks, even when its radio link works.
If a pair fails, narrow the result: “these revisions failed under these settings” is more informative than declaring an entire standard incompatible. Distinguish the radio connection from address assignment and application access, then document the first failing stage. This preserves the value of the test for another researcher trying the same equipment.