Methodology · Wi-Fi gateways and access points
TR-398: what a gateway delivers in a real home, measured in a shielded box with nothing else on the channel
Broadband Forum TR-398 is the test plan ISPs and vendors use to accept a Wi-Fi gateway, access point or mesh node. Five groups of tests: RF capability, baseline performance, coverage, multiple stations and long-term stability, each with a minimum for the device class. We run it on request on our Wi-Fi bench, with emulated stations up to Wi-Fi 6 behind programmable attenuators in a shielded enclosure; the full chamber set-up is agreed per project. Wi-Fi 7 is in progress on the bench and not reported yet.
- Every test with its own pass line, per band and per channel width, from sensitivity to a four-hour run
- Spatial consistency and AP coexistence are agreed per project, with the setup named in the report
- Pass thresholds from the TR-398 tables for the device class, your own figures on top where the tender names them
Range versus rate for one band and one channel width: throughput at every attenuation step against its own minimum; one step below the line fails the test
Where it fits
Acceptance of the Wi-Fi device, not of the Wi-Fi standard
RFC 2544 proves what the wired ports forward. TR-398 proves what a household gets from the radio: at range, with many clients, with an old laptop in the room, for hours
ISP gateway acceptance
The box that goes into ten thousand homes with the next firmware. The report says which test groups passed on which band, with the thresholds the tender named, before the rollout
Vendor bake-off
Two or three candidate gateways or access points measured the same way, in the same enclosure, with the same stations. One table, one winner per criterion
Firmware regression
A new driver, a new channel plan, a new mesh release. The baseline set rerun against the previous report shows what moved, before the field finds it
Test bed
Stations on one side, the wired network on the other, the device in a shielded box between them
TR-398 asks for a controlled RF path. Our bench feeds the stations through programmable attenuators and keeps the wired side at line rate, so the radio is the only variable
Station emulator
Emulated stations with their own radios, streams and channel widths, 802.11n, ac and ax up to Wi-Fi 6. Rate, PER, RSSI and retries per station every second; a legacy station added to the mix when the test calls for one
Device under test
Gateway, access point or mesh node in a shielded enclosure, configured as shipped, both bands on. Path loss of every cable and attenuator is calibrated with a reference station before the device goes in, and the offsets are in the report
Wired side
A traffic generator on the LAN or WAN port at 1 or 10 GbE, the other end of every flow. Throughput and loss per station, latency across the air link, on the same clock as the station emulator
What the bench does today
Wi-Fi 6 on 2.4 and 5 GHz. Wi-Fi 7 is in progress and is not reported until it is. A turntable for spatial consistency and the full chamber procedure are agreed per project; the report states which setup was used
Parameters
What is fixed before the run
TR-398 fixes the test setup and the pass thresholds per device class. The plan lists what we set on top, with the value we use when the tender is silent
| Parameter | Our default | Allowed | Why it matters |
|---|---|---|---|
| Device class | From the datasheet: band, streams, width | 2.4 GHz, 5 GHz, 2×2 to 4×4, 20 to 160 MHz | Every TR-398 threshold is a function of the class; a 2×2 gateway judged by a 4×4 line fails for the wrong reason |
| Channel and width | As shipped, auto off | Any channel of the regulatory domain | A device left on auto may change channel mid-run; the plan pins the channel and the report names it |
| Station types | 802.11ax 2×2, plus 802.11n for fairness | 802.11n, ac, ax; 1×1 to 4×4 | The stations decide what the device can show; a legacy station is the whole point of the airtime fairness test |
| Attenuation steps | 10 to 60 dB in 10 dB steps | Any list inside the attenuator range | Range versus rate is a curve, and the minimum applies at every point of it; finer steps show where the rate collapses |
| Traffic | UDP for rate, TCP on request | UDP, TCP; down, up, both | UDP shows the radio; TCP shows what a download gets after retries and window growth, usually lower |
| Station count | 32 for the multi-STA test | 1 to the bench limit | A home has twenty to forty clients; the sum rate and the per-station floor both have to hold |
| Long-term run | 4 h | 4 h or longer | Resets, memory leaks and thermal throttling show after hours at load, not in a 60 s trial |
| Pass thresholds | TR-398 table for the class | Table values, or stricter ones from the tender | Every test is pass or fail against its own line; one miss marks the group failed and the run goes on |
Thresholds follow the TR-398 tables for the device class. When the tender names a stricter figure, the tender wins; a looser one is reported next to the table value
Always in our runs
- Path loss calibrated before the DUT goes in
- Both bands, DUT configured as shipped
- Thresholds from the TR-398 table for the device class
- Per-station counters every second, both sides
- Wired side at line rate, never the bottleneck
- Console log and DUT logs for the whole run
Calibrated path loss, both bands, the device as shipped, thresholds from the table, counters per station from both sides, console and logs for the whole run
Agreed per device
- Baseline set only, or all five groups
- Turntable for spatial consistency
- Wi-Fi 6 features on: OFDMA and MU-MIMO
- Client mix with a legacy 802.11n station
- Long-term run: 4 h, or longer
- Second AP and its channel for coexistence
The set of groups, the turntable, Wi-Fi 6 features, the client mix, the length of the long run and the coexistence setup are fixed in the plan with you. Each one changes the bench days and what the report can claim
Inside the method
Five groups, from the radio to a four-hour run
TR-398 builds up: first the radio alone, then throughput, then range and angles, then many stations, then time and a neighbour on the channel
-
01RF capability
Receiver sensitivity and maximum connection
The station level is lowered step by step until the packet error rate crosses the limit; the level where it still holds is the sensitivity, per band and per rate. Maximum connection checks that the device accepts the number of stations the class requires and keeps them
Per band · PER at each level -
02Baseline
Maximum throughput, dual-band, bidirectional
One station at short range, down then up, then both at once, then both bands loaded together. Each figure against the table minimum for the band, the stream count and the channel width
Per band · UDP, 2 min per run -
03Baseline
Airtime fairness
Wi-Fi 6 stations at full rate, then a slow 802.11n or 802.11ac station joins at range. A fair device gives the slow client its share of time, not its share of frames; the fast stations must keep the rate the table names
5 GHz · legacy client in the mix -
04Coverage
Range versus rate, spatial consistency
Attenuation rises in steps and the rate at each step must stay above its line. On a turntable the device is turned through the angles and the rate must not fall below the limit in any direction; an antenna that favours one wall shows here
10 to 60 dB · turntable when agreed -
05Multiple STAs
Multiple stations, join and leave, MU-MIMO
Many stations at once, 32 by default, with a sum rate and a per-station floor to meet. Stations associate and disassociate in a loop while the others carry traffic; no station may be lost. Downlink MU-MIMO to several stations at once when the device claims it
32 STAs · both bands -
06Stability
Long-term stability, AP coexistence
Four hours at load with the rate sampled every second: no reset, no reassociation, no throttling beyond the tolerance. Then a second access point on the same channel with its own traffic; the device must keep the rate the table names for a shared channel
4 h · second AP on the channel
Procedure
From the plan to the signature
The baseline set fits in a bench day; coverage, stations and the long run take one or two more. The whole plan for one gateway is two to three bench days
-
00
Test plan
Device class, bands, channels, station types, the groups to run, the length of the long run and every threshold in one table, signed off before the device goes into the enclosure
-
01
Bed calibration
Path loss of every cable and attenuator measured with a reference station on both bands. The offsets go into the plan; the device goes in only after the bed is known
-
02
Baseline set
Sensitivity and maximum connection, then maximum throughput down, up and both ways, dual-band, airtime fairness. A failed test is reported the same day so the firmware can be changed before the rest runs
-
03
Coverage, stations, time
Range versus rate in steps, angles on the turntable when agreed, thirty-two stations, join-and-leave loops, MU-MIMO where claimed, then four hours at load and the coexistence run
-
04
Report and hand-over
Pass or fail per test and per band, with the rate at every step, the per-station series and the DUT logs attached. A failed test comes with the level, the station mix and the minute
One device, five groups: the baseline set first, then range, stations and time. Every test has its own line from the TR-398 table, and the run goes on after a miss
Pass rules we apply
- PER ≤ limit
At each sensitivity level of the table the packet error rate stays within the limit; the first level that breaks it ends the test for that rate
- ≥ table rate
Throughput at every step of every test meets the minimum for the device class, band and width; a stricter figure from the tender replaces the table
- Fair share
With a legacy station in the mix the Wi-Fi 6 stations keep the rate the table names; a device that lets the slow client own the air fails here
- 0 drops
No reset, no lost station and no rate outside the tolerance in the four-hour run; a single reassociation is logged and fails the group
Time budget
- Bed calibration2 hours, once per set of cables, attenuators and bands
- Baseline setOne bench day for both bands, including a rerun after a firmware change
- Coverage and stationsOne bench day; add half a day for the turntable
- Stability and report4 hours at load plus the coexistence run; report the next business day
Report
What you get at the end
A verdict per test and per band, and the series behind it. Enough to accept the firmware, pick the vendor, or send the developer to the exact level and station mix
Per test
- Sensitivity level per band and rate, with the PER at each step
- Throughput down, up and both ways, per band, against the table minimum
- Rate at every attenuation step and, with the turntable, at every angle
- Per-station rate and the sum in the multi-STA run, join-and-leave events
- Four-hour rate series with resets, reassociations and throttling marked
- Pass or fail against each threshold, table value or tender value
Context
- Device class, firmware, channel, width and security mode as tested
- Bed calibration: path loss offsets per cable and attenuator, per band
- Station emulator model, station types and the legacy client used
- Which TR-398 groups were run, which were left out and why
- Enclosure or chamber, turntable yes or no, second AP and its channel
- Timestamps of every run and the DUT log around every failure
Attached
- Rate per step and per station as CSV, for your own charts
- Four-hour time series, DUT console log and a PCAP around each failure
- Range and fairness graphs as PNG, ready for the acceptance document
From practice
The gateway that passed on speed and failed on manners
A Wi-Fi 6 gateway for an ISP fleet, 2×2 on 5 GHz. Maximum throughput passed on both bands with room to spare, range versus rate cleared every step. Then the multi-station run with one 802.11n laptop added at range: every Wi-Fi 6 station lost 62 % of its rate, well below the airtime fairness line.
The slow client was sending at a low rate and taking most of the air for it. Airtime fairness existed in the firmware and was off by default. One setting, one rerun: the Wi-Fi 6 stations came back to 94 % of their alone rate, the old laptop kept its share. The fleet shipped with the setting on.
TR-398 airtime fairness and multi-STA runs on a 2×2 Wi-Fi 6 gateway, 5 GHz, 80 MHz
Services
How we run TR-398 for you
On our Wi-Fi bench with your device shipped to the rack, the baseline set or all five groups. Same plan, same report
Gateway acceptance for an ISP
The groups the tender names, on the firmware that will ship, with the thresholds written into the contract. The report is the acceptance document
Order an acceptance runBake-off of candidate devices
Two or three devices through the same plan in the same enclosure, one table at the end and a winner per criterion the buyer set
Set up a bake-offFirmware regression
The baseline set rerun on each release against the previous report. What moved, by how much, on which band
Bring the next buildBench access for your team
Your engineers run the plan on our bench through CloudLAB, with our engineer on chat and the device in our enclosure
Open CloudLAB- Report in the TR-398 structure, group by group, band by band
- Station emulator and attenuators chosen for the device class, from more than one vendor
- Engineers who read the tender thresholds before the counters
Related pages
- SolutionWi-Fi testing: access points, gateways and mesh under load
- MethodologyRFC 2544: zero-loss benchmark for the wired ports of the same device
- IndexAll methodologies we run on the bench
- ServiceLoad and performance testing: limits and failover under load
- About usWhy TEST4NET: an independent lab and how it works
FAQ
Questions we get about TR-398
Is your lab a certified TR-398 test house?
No. We run the TR-398 procedure on our own Wi-Fi bench: emulated stations up to Wi-Fi 6, programmable attenuators, a shielded enclosure, and the rest of the chamber procedure agreed per project. The report states exactly which setup was used and which groups were run, so a buyer can see how close it sits to the full chamber procedure. For a certificate from an accredited house we help write the plan and read the result.
Do you test Wi-Fi 7 devices?
The bench supports stations up to Wi-Fi 6 today; Wi-Fi 7 is in progress and we do not report Wi-Fi 7 figures until it is. A Wi-Fi 7 gateway can be tested now on its 802.11ax modes, with the limitation written on the first page of the report.
How long does a full TR-398 run take?
Two to three bench days for one device: a day for the baseline set on both bands, a day for coverage and the multi-station tests, four hours or more for the long-term run plus coexistence. A bake-off of three devices takes about a week. The baseline set alone fits in a day.
Which devices does it apply to?
Residential gateways, ISP-supplied access points, mesh nodes and enterprise access points used in home offices. TR-398 was written for the device the operator hands to the subscriber; for an enterprise campus the same bench runs a client-mix plan without the TR-398 thresholds.
Can we test mesh or multi-AP systems?
Yes, on request and as a separate plan. The basic set tests one device in the enclosure. For a mesh we put the root and one or two satellites on calibrated paths and measure the rate at the far node, roaming between nodes and the backhaul share; the thresholds come from your requirements, not from the TR-398 table.
What happens when the device fails a test?
The run goes on and the test is marked failed with the level, the station mix and the minute. You change the firmware or the configuration, we rerun that test or the whole group, and the report shows both results side by side. Reruns on the same setup are bench time, not a new project.
Test plan and quote in 1 to 3 business days
Send the device model, the firmware and the groups the tender names. You get the plan with every threshold, the bench days and a quote for the run
Send the shortlist
You have the method. Now get the numbers.
Name the models and the KPIs that matter. An engineer replies within one business day with a test plan draft and a quote.
Prefer to chat? Message an engineer on WhatsApp
We use what you send only to answer you. See our Privacy Policy.