What is RMA and how is it used for Network Testing
WirelessMetrix
Product Description
Remote Monitoring App (RMA)
Application-Layer Test Controller for the LinkMaster Platform
February 2026 — For distribution to partners and customers
1. Overview
The
Remote Monitoring App (RMA) is an Android application developed by
WirelessMetrix as the application-layer test controller within the LinkMaster
platform. It works in conjunction with the Link Master Logger (LML) hardware
and the Link Master Analysis (LMA) PC software to provide a fully integrated,
time-synchronized view of network performance from the application layer down
to the physical radio layer.
RMA turns any compatible Android
device into a self-contained network test endpoint. Unlike traditional tethered
modem setups — where a laptop generates traffic and the phone merely routes it
— RMA executes all tests natively on the device. The UE is the IP endpoint.
This means the measurements reflect exactly what a real user on that device
would experience.
RMA
is not available on the Google Play Store. It is installed directly onto the
Android device by LML via an ADB push — ensuring that only calibrated,
WirelessMetrix-controlled builds are deployed in the field.
2. System Architecture
RMA
operates as one of two parallel data streams flowing into LML during a test
session. The diagram below illustrates how the components relate:
|
Android UE |
|
Link Master Logger (LML) |
|
Link Master Analysis (LMA / PC) |
|
|
|
|
|
|
|
RMA App (Application Layer Tests) |
↔ |
ADB Bridge (Port-specific, not LogCat) |
→ |
App-Layer KPIs Time-synced with RF |
|
|
|
|
|
|
|
RF Modem (RF / Protocol Stack) |
→ |
LML Chipset Decoding Modem diagnostics |
→ |
RF KPIs PDCP / RLC / MAC / PHY RSRP / SINR / MCS / RB |
Figure 1: LinkMaster system architecture
— dual data path from UE to LMA.
2.1 The Two Data Paths
Every
LinkMaster test session captures two simultaneous and independent streams of
information from the UE:
• RMA executes test
traffic natively on the Android device and reports application-layer metrics
(throughput, latency, packet loss, etc.) to LML via the Android Debug Bridge
(ADB). The ADB link uses a specific port assignment — it does not rely on
Android LogCat — providing a dedicated, low-latency channel for RMA telemetry.Application Layer (RMA path):
• LML's chipset decoding
interface streams physical and protocol layer data from the modem chipset to
LML over the USB connection. LML is chipset agnostic and supports Qualcomm
(QXDM/DIAG), LSI, and MediaTek (MTK) modems. This provides per-second visibility
into PDCP, RLC, MAC, and Physical layer KPIs including RSRP, SINR, MCS, MIMO
rank, and resource block utilization.Radio
/ Protocol Layer (Modem path):
2.2 Time Synchronization
LML
timestamps both streams to a common clock, aligning RMA application-layer
events (test start, test end, per-second throughput samples) with the
corresponding modem diagnostic frames. This time alignment is what makes
LinkMaster analytically powerful: engineers can look at any moment in time and
simultaneously see what the application was delivering and what the radio was
doing to produce it.
In LMA, this appears as a
unified timeline where application-layer throughput plots sit directly above —
and share the same time axis as — physical-layer metrics such as PDSCH
throughput, PUSCH throughput, RSRP, and SINR. Correlating application-layer degradation
with a specific radio event (e.g., a handover, a SINR drop, or a carrier
deactivation) is direct and unambiguous.
2.3 USB vs. Bluetooth
The
connection between the Android UE and the LML hardware is via USB. Bluetooth is
not used in the LinkMaster architecture. USB serves two critical roles
simultaneously:
• It carries the ADB channel
over which RMA communicates with LML (application-layer data).
• It carries the LML chipset
decoding channel over which modem diagnostics are streamed to LML (radio layer
data), supporting Qualcomm, LSI, and MTK chipsets.
Both data streams travel over
the same physical USB cable but are logically separated by their respective
protocol layers. Bluetooth cannot replicate this because it does not support
the DIAG interface required for modem diagnostics, and would introduce latency
and bandwidth constraints that would compromise time synchronization accuracy.
3. Installation and Deployment
3.1 ADB Push Installation
RMA
is not distributed through the Google Play Store. This is a deliberate design
choice: it ensures that only approved, version-controlled builds are deployed
in the field, and eliminates dependency on a consumer app distribution channel
that is subject to policy changes, review delays, and automatic updates that
could alter test behavior mid-program.
Installation is handled entirely
by LML. When an Android UE is connected to LML via USB and detected, LML
performs an ADB push to install the RMA APK directly onto the device. The
process requires:
1. USB debugging enabled on
the Android device.
2. ADB authorization granted
to the LML host on the first connection.
3. LML firmware that includes
the target RMA build.
Once installed, RMA runs as a
background service and is managed entirely by LML. The user does not interact
with RMA directly during normal test operations — all test configuration and
sequencing is controlled through the LML interface or LMA.
3.2 Compatible Devices
RMA
is designed for Android devices equipped with a supported RF modem chipset —
including Qualcomm, LSI, and MediaTek (MTK) — which provide the diagnostic
interface required for the modem data path. The combination of a Qualcomm-based
Android device, an LML hardware unit, and the LMA PC software constitutes a
complete LinkMaster test system.
Device compatibility is managed
through WirelessMetrix's device qualification program. Customers should confirm
device compatibility with WirelessMetrix before procurement to ensure full DIAG
interface support and optimal diagnostic log availability.
4. Application-Layer Test
Capabilities
RMA
supports a comprehensive suite of application-layer tests covering the major
traffic types encountered in modern cellular networks. The table below
summarizes the available test types, their supported protocols and modes, and
the key metrics produced:
|
Test Type |
Protocols / Modes |
Description |
Key Metrics |
|
HTTP Download / Upload |
Multi-stream |
Replicates Ookla Speedtest methodology |
Throughput, latency, stream count |
|
Ping |
ICMP, TCP, UDP, TWAMP |
Round-trip time measurement |
Min / avg / max RTT, jitter, loss |
|
HTTP Browser |
Kepler or public pages |
Web page load performance simulation |
Page load time, TTFB |
|
FTP / SFTP |
DL and UL |
File transfer using FTP or Secure FTP |
Transfer rate, connection time |
|
YouTube Video on Demand |
Adaptive streaming |
Streaming video quality and buffering behavior |
Play start time, buffer events, bitrate |
|
iPerf |
UDP / TCP, multi-stream, bi-directional |
Network performance benchmarking |
Throughput, loss, jitter (UDP) |
|
SMS |
MO and MT |
Text message transmission and receipt |
Delivery time, success rate |
|
Voice Call |
VoLTE / VoNR |
Automated dialing for voice quality testing |
Call setup time, drop rate, MOS correlation |
Table 1: RMA application-layer test
types, modes, and key metrics.
4.1 HTTP Download / Upload (Speed
Test)
The
HTTP DL/UL test replicates the methodology used by Ookla Speedtest: a
multi-stream HTTP transfer over a fixed time window. Multiple simultaneous TCP
connections are used to saturate the available bandwidth, mimicking the
behavior of a competitive benchmarking app. This is the most commonly used test
type for network acceptance testing and carrier benchmarking programs.
Key configuration parameters
include the number of parallel streams, test duration, and target server. LMA
captures application-layer throughput on a per-second basis, aligned with the
concurrent PDSCH (downlink) and PUSCH (uplink) physical-layer measurements.
4.2 Ping (ICMP / TCP / UDP / TWAMP)
RMA
supports multiple ping variants beyond standard ICMP, including TCP Echo and
UDP Echo for penetrating firewalls that block ICMP, and TWAMP (Two-Way Active
Measurement Protocol) for RFC-compliant latency measurement. This range of
options allows latency testing to be adapted to the specific network
environment and test objectives.
4.3 iPerf (UDP / TCP, Multi-Stream,
Bi-directional)
The
integrated iPerf client supports both TCP and UDP transfer modes with
configurable stream counts and bi-directional operation. iPerf testing is
widely used by carrier engineers for controlled throughput measurement and is
particularly valuable when testing against iPerf servers deployed within the
carrier's own network infrastructure.
4.4 Voice (VoLTE / VoNR)
RMA
can initiate automated voice calls to support VoLTE and VoNR testing workflows.
When paired with LMA's Layer 3 message decoding and IMS diagnostic logging,
this enables full voice quality assessment including call setup time, call drop
analysis, and correlation of voice degradation with radio layer events such as
handovers and SINR variations.
5. Runtime Display on the Android
Device
During
an active test session, RMA displays a lightweight status interface on the
Android device screen. This display is intentionally minimal — it is designed
to confirm that the test system is operating correctly, not to serve as a
primary data interface. All detailed analysis occurs in LMA on the PC.
The runtime display provides two
categories of information:
• The current Radio Access
Technology in use (e.g., LTE, NR NSA, NR SA), confirming that the device is
registered on the expected network and that dual connectivity is active where
applicable.RAT Status:
• Real-time throughput and
test state for the active test type (e.g., current DL speed, upload progress,
ping RTT). This allows the field technician to confirm that the test is running
normally without needing to look at the LML hardware or LMA PC.Application Layer Status:
Figure 2: RMA runtime display showing RAT
status and application-layer test status during an active session.
The display is designed to be
readable at arm's length and does not require the technician to interact with
the device during testing. Test sequencing, configuration, and logging are all
controlled remotely by LML.
6. RMA Test Configuration Interface
Prior
to test execution, RMA presents a configuration screen through which the active
test types, parameters, and sequencing can be reviewed. The screenshot below
shows the RMA test configuration as seen on the Android device, illustrating
the breadth of test types available and their individual parameter controls:
Figure 3: RMA test configuration screen
on Android — showing all available test types and their parameter settings.
Configuration of RMA test
parameters is managed through LML and LMA rather than through direct
interaction on the Android device. This ensures consistency across test
sessions and prevents unintentional modification of test parameters by field
personnel during data collection.
7. Native IP Endpoint Architecture
A
critical architectural distinction of RMA is that the Android UE is the IP
endpoint for all test traffic. This is fundamentally different from a tethered
modem configuration, and the difference has significant implications for
measurement accuracy and applicability.
7.1 Tethered Modem vs. Native
Endpoint
|
Attribute |
Tethered Modem |
RMA (Native Endpoint) |
|
IP endpoint location |
Laptop / test PC |
Android UE (the device under test) |
|
USB role |
Data path (traffic passes through USB to laptop) |
Diagnostics only (modem logs; traffic stays on device) |
|
What is measured |
Throughput at laptop NIC — after USB transport overhead |
Throughput at UE application layer — identical to end-user experience |
|
Validity for UE experience testing |
Indirect — USB introduces latency and throughput artifacts |
Direct — accurately reflects what a user on that device experiences |
|
Carrier acceptance testing |
Not typically accepted as UE-representative |
Accepted methodology for UE performance validation |
Table 2: Tethered modem architecture vs.
RMA native IP endpoint architecture.
7.2 Data Flow During a Test Session
The
data flow during an active RMA test session can be described as follows:
4. RMA initiates the
application-layer test (e.g., HTTP download) from within the Android
environment. All test traffic is generated and terminated on the device itself.
5. Test traffic travels over
the cellular air interface to/from the target server — exactly as it would for
a real user running the same application.
6. RMA reports per-second
application-layer metrics (throughput, latency, etc.) to LML via the ADB
channel over USB.
7. Simultaneously, the RF
modem streams chipset diagnostic log packets containing physical and protocol
layer diagnostics to LML over the same USB connection.
8. LML timestamps and stores
both streams. On session completion, the data is transferred to LMA on the PC
for post-processing, analysis, and report generation.
8. Integration with LMA Analysis
Software
The
full value of RMA is realized through its integration with the LMA
post-processing and analysis platform. Because LMA has access to both the
application-layer data from RMA and the physical/protocol layer data from the
RF modem — all on a common time axis — it can produce analyses that are not
possible with any single-layer tool.
8.1 Full Protocol Stack Visibility
LMA
organizes the captured data into a layered KPI structure that mirrors the 3GPP
protocol stack:
• RMA-reported throughput,
latency, and test-type-specific metrics.Application
Layer:
• Packet Data Convergence
Protocol throughput — the first protocol layer below the application,
reflecting the combined data flow in EN-DC (NSA) deployments.PDCP Layer:
• Where LTE and NR traffic
can first be viewed separately in NSA configurations.RLC / MAC Layers:
• Per-component-carrier
throughput (PDSCH/PUSCH), MCS, MIMO layers, RSRP, SINR, and resource block
utilization for each LTE and NR carrier.Physical
Layer (PHY):
This stack is traversed
top-to-bottom in LMA, allowing engineers to follow a user experience
observation ("the throughput dropped here") down through the layers
to the root cause at the radio level ("the primary NR carrier deactivated
due to SINR falling below the A3 event threshold").
8.2 NSA / EN-DC Support
RMA
and LMA are fully compatible with 5G Non-Standalone (NSA) EN-DC deployments
where the device simultaneously maintains an LTE anchor and one or more NR
secondary carriers. In this configuration, RMA reports combined
application-layer throughput (the sum of LTE and NR contributions as delivered
to the app), while LMA provides the tools to decompose that combined throughput
by protocol layer and by individual component carrier.
This makes the LinkMaster system
particularly well suited for AT&T, T-Mobile, and Verizon NSA 5G programs,
where the ability to isolate and report NR-specific performance — while also
demonstrating its contribution to the overall user experience — is a standard
deliverable.
8.3 Automated Report Generation
LMA
can generate structured test reports from RMA sessions automatically, combining
application-layer KPI summaries with RF performance tables and time-series
plots. Reports can be configured to include any combination of the available
KPI layers and can be exported in standard formats suitable for carrier
submission or customer delivery.
9. Typical Use Cases
DAS /
In-Building System Acceptance Testing
Post-installation walk testing
of Distributed Antenna Systems (DAS) or small cell deployments in venues such
as stadiums, hospitals, hotels, and office buildings. RMA HTTP DL/UL tests
confirm that the installed system delivers the contracted application-layer
throughput at all test locations, while LMA provides the physical-layer
evidence (RSRP, SINR, PDSCH) that demonstrates why performance is at the
measured level.
Carrier
Network Benchmarking
Scheduled or drive-test network
benchmarking comparing LTE and 5G NR performance across geographies, frequency
bands, or time periods. RMA's speed-test replication methodology produces
results that are directly comparable to consumer benchmarking tools (Ookla,
nPerf, etc.) while LMA provides the underlying RF evidence that consumer tools
cannot access.
5G NR
Deployment Validation
Validation of 5G NR NSA or SA
deployments during rollout or upgrade programs. The ability to isolate NR
throughput from LTE contributions at the protocol and physical layers — while
simultaneously capturing the combined application-layer user experience — is
essential for demonstrating NR value to carrier customers.
Voice
Quality and VoLTE / VoNR Testing
Automated voice call testing
with concurrent IMS and Layer 3 diagnostic logging. LMA correlates voice
quality degradation (call drops, poor MOS periods) with specific radio events,
enabling root cause analysis that goes beyond what is available from the voice
application layer alone.
Network
Troubleshooting and Root Cause Analysis
When a customer reports poor
performance at a specific location or time of day, a LinkMaster session with
RMA provides simultaneous application and radio evidence. The time-synchronized
stack allows engineers to determine whether the issue is at the RF layer (weak
signal, interference), the protocol layer (handover failures, bearer issues),
or a network core/server issue that appears only at the application layer.
10. Summary
RMA
is the application-layer engine of the LinkMaster platform. It transforms a
standard Android device into a native network test endpoint — executing real
application traffic on the UE itself, communicating results to LML via a
dedicated ADB channel, and delivering time-synchronized application-layer KPIs
that LMA aligns with the full 3GPP protocol stack from PDCP down to the
physical layer.
Key characteristics:
• Native IP endpoint —
traffic terminates on the UE, not on a connected laptop, for accurate
user-experience measurement.
• USB-only connectivity —
Bluetooth is not supported; USB carries both the ADB/RMA channel and the LML
chipset decoding channel simultaneously.
• ADB-based installation —
deployed by LML via ADB push, not from the Google Play Store.
• Eight test types — covering
HTTP throughput, ping, browser, FTP, iPerf, YouTube, SMS, and voice.
• Full protocol stack
integration — RMA application-layer output is time-aligned with PDCP, RLC, MAC,
and PHY KPIs in LMA.
• NSA / EN-DC ready —
supports LTE+NR dual connectivity deployments with per-layer and per-CC
decomposition in LMA.
For further information contact
WirelessMetrix at support@wireless-metrix.com
Related Articles
Wi-Fi Coverage Testing: Heat Maps vs. Point-Data Surveys
WirelessMetrix Support | Frequently Asked Questions Wi-Fi Coverage Testing: Heat Maps vs. Point-Data Surveys Category: Wi-Fi / WLAN Testing | Product: DASView Walk-Test Software Question Can WirelessMetrix provide heat map drawings showing wireless ...How to Set Up ADB and Install RMA
In this article, we will show you how to: Set up your Android Debug Bridge (ADB) Install the Remote Monitoring App (RMA) onto your phone Set Up ADB Go to the Settings area of your phone (this is done slightly differently on each type of phone, so if ...Error Message -- "Please update RMA ... "
If you see this error: The following steps will help you resolve this:Encapsulated Security Protocol (ESP) authentication key status
Question: a red ”N” appeared at the bottom right corner of LM showing ‘No key’. Could you please let me know the reason for this? Answer: Some networks will employ Encapsulated Security Protocol for the data packets that are used for voice call set ...Quickstart: LML
In this article, you'll learn how to get up and running with Link Master Logging (LML) in no time. We'll cover: Downloading the latest version of LML Launching LML and configuring your Port Settings Configuring your test using Plan Settings Using the ...