The Measuring Broadband America (MBA) Program’s mobile measurement effort is supported by the FCC Speed Test mobile application (FCC Speed Test app), which provides mobile broadband service performance testing of Android and iOS mobile devices. The MBA’s measurement infrastructure used for fixed-line broadband performance measurement is shared to support the mobile measurement program.
The FCC Speed Test app has two independent mobile applications, one for iOS devices and another for Android devices, due to the differences between iOS and Android operating systems, security features, and hardware. The iOS operating system, which supports Apple’s iPhone and iPad hardware devices, has security features that do not expose many of the radio parameters that the FCC Speed Test app relies on to verify the network environment. Additionally, the iOS operating system (unlike the Android operating system) allows only for tests to be performed manually in the foreground and does not allow for automated scheduled testing of the FCC Speed Test app. In contrast, the Android operating system allows automated tests and provides a consistent Application Programming Interface (API), which exposes many radio parameters for use by Android applications.
The mobile broadband performance measurement effort by the MBA mobile program rely both on the measurement client that initiates the test process and measurement servers that function as a test endpoint to the client’s measurements. The measurement client consists of a publicly available app, the FCC Speed Test app (App), which can be obtained at no cost without in-app ads and has been downloaded on hundreds of thousands of Android and iOS devices in locations across the nation. Measurement tests can be performed on any mobile broadband service provider’s network subscribed to by consumers running the App. Currently, the measurement servers (which are also used in the fixed-line broadband performance measurements) are hosted by StackPath and are located in 10 cities (with overall 13 locations, since some cities have multiple sites) across the United States near a point of interconnection between the broadband provider’s network and the network on which the measurement server resides.
This methodology focuses on the performance of the specific mobile broadband network under test. When a test sequence initiates, the App will check whether the form of connection is cellular or Wi-Fi. If the connection is over a mobile network, the App will further identify its connection technology type; i.e., 3G, 4G, or 5G. If the connection is over a Wi-Fi network, the App will test and report the performance of the Wi-Fi network connection through its connected Internet service.
Once the App selects a measurement server, the metrics are derived from traffic exchanged between a measurement client (the App) and the selected measurement server. The tests use the measurement server for which the latency between the measurement client and server is the lowest value (note that the selected server may not necessarily be the closest geographically from the measurement client location). As a result, the metrics measure performance along a specific path within each mobile broadband provider’s network, through the point of interconnection between the mobile broadband provider’s network, and the network on which the chosen measurement server resides.
Frequently Asked Questions
What is the Mobile Testing Architecture?
The mobile application to measure the network connection speeds is designed to be installed on a user's mobile device via the native app download site, e.g. Google Play for android devices or App Store for iOS devices. The application is free to download, but carrier charges may apply if the download is over a carrier’s mobile network. The application can be configured to run continuously in the background, periodically performing measurements for Android devices. However, this automated functionality is not available on iOS devices which allow for only manual testing.
How do I remove the application?
End users may uninstall the application at any time via their devices’ normal application uninstallation procedure.
How does the app determine the best measurement server?
When starting a measurement cycle, the application runs a brief latency test to measurement servers in the application's configuration. The nearest measurement server, determined by the lowest round-trip latency, is selected as the target for all subsequent measurements (download and upload throughputs, latency, packet loss, and jitter).
Will it disrupt my using my phone; e.g., generate cross-traffic?
Prior to each measurement, the Application checks the volunteer's mobile broadband use; e.g. cross-traffic within the mobile device). The app will measure cross-traffic, which will then be included in environmental data reported in the test results. This data reporting feature is limited to Android devices.
How does the app capture location, carrier, and network data?
The approximate location of the mobile device is determined by using the device’s own internal capabilities. These typically use a combination of nearby cell towers, nearby WiFi access points, and GPS, if available.
The network provider name and other network characteristics, such as bearer, signal strength data, etc. are recorded from APIs available from Android and iOS (if available). These metrics are recorded before and after every active measurement.
How does the app communicate data?
All communications between the software application and the Data Collection Service on the backend hosted infrastructure are initiated by the application and securely encrypted over SSL (Secure Sockets Layer). The software application communicates with the measurement servers over a variety of TCP and UDP ports. For Android, ICMP ping is used to determine the server with the lowest round-trip latency, where TCP ping is used for iOS.
How does the app know to configure and update tests?
For Android users, the app will frequently download, when opened, updates from a central server to its configuration to maintain the most current schedule of automated tests that it can execute. For iOS users, the app will update as long as automatic updates are enabled.
How does the app deal with my privacy?
What tests does the app run?
Active Performance Test Metrics - All active tests designed and developed for the program by the FCC's contractor (www.samknows.com), in collaboration with industry, academia, and other stakeholders, adhere to relevant RFCs and are publicly disclosed as part of the open methodology. All times are displayed in microseconds and all speeds in displayed in bits per second in the app’s user interfaces. The tests include:
UDP Latency, Packet Loss, and Jitter
This test sends up to 200 UDP (User Datagram Protocol) data packets traffic, running between a client and a test server. Each 160-byte UDP packet has an 8-byte sequence number and an 8-byte timestamp. If an acknowledgement is not received back within two seconds it is treated as lost. The number of UDP packets that are sent and the number received back within a five second time period are recorded, as well as the average round-trip time of the response. The averaged round-trip time is measured as latency. Jitter, measured in milliseconds, refers to the variation in latency. Jitter is calculated using the PDV (Packet Delay Variation) approach described in section 4.2 of RFC 5481.
Packet Loss refers to the ratio of the number of UDP packets either not acknowledged by the measurement server, or acknowledged as received after two seconds, to the number of total packets sent from the client.
Two separate tests are used to measure the download and upload speed of the given connection in bits per second by establishing multi-TCP connections to perform HTTP GET and HTTP POST requests to a target test node. Binary non-zero content, herein referred to as the payload, is hosted on a web server on the target test node. Each test cycle begins with a fixed 3-second warmup, followed by the download or upload speed test. Each speed test concludes either after 1,000 MB of payload is transferred or after a maximum elapsed time period of 5 seconds. The client will attempt to download as much of the payload as possible for the duration of the test.
How many threads do the tests execute?
Tests are executed using three concurrent connections. Each connection used in the test counts the numbers of bytes of the target payload, transferred between two points in time, and calculates the speed of each thread as the number of bits transferred over the number of seconds in the active test window. The speeds of the three threads are then summed to determine the total speed.
Factors such as TCP slow start are taken into account by transferring a portion of the target payload before the real testing begins. This “warmup” period will complete after a fixed duration of three seconds. Three individual connections are established, each on its own thread, and are confirmed as all having completed the warmup period before the five-second timing begins.
How often do tests run? What's the app test schedule?
The Android application will periodically download a predefined test schedule randomized to execute tests. This functionality is not available on iOS devices. For Android users, upon opening the app, the app tests will be scheduled to occur once per day (24 hrs.) by default. However, users can change the setting to be more frequent (once per 12 hrs., once every 6 hrs., once per hour, and once per 15 minutes). Data usage for these scheduled tests will vary depending on the connection type (3G/4G/5G), and may exceed the user configured app data limit in order to complete the last test sequence initiated prior to reaching the data cap.
How much data will the program use by default?
By default the app will limit the total monthly data traffic used for execution of scheduled tests to a maximum of 100 Megabytes (MB) of data. Volunteers can adjust the data cap to suit their preference.