# Modem-to-Modem Links Over LTE: A Military Range Use Case

> How a U.S. military training range moved legacy modem-to-modem control links onto LTE with DataRemote 90X2 units and modem relay, with no equipment changes.

- Published: October 2, 2026
- Author: Timor Brik
- Topics: Use Cases, POTS Replacement, Cellular
- Primary entity: solution:modem-telemetry-connectivity
- Related entities: family:pots-in-a-box, platform:ara, product:90x2, solution:pots-line-replacement, endpoint:dial-up-modem, topic:legacy-analog-line-migration, definition:machine-to-machine-communication
**Direct Answer:**
A legacy modem-to-modem link can run over LTE without replacing the modems, but not by treating it as a phone call. At a U.S. military training range, a control center talked to remote equipment over dial-up modems on two-wire telephone lines. DataRemote put a [90X2](https://dataremote.com/pots-in-a-box/90x2) at each end of the link. Each modem trained against its own local unit, and DataRemote's modem relay service carried the decoded data over LTE. The site went from no data at all in the first test session to operators seeing the equipment respond to commands in two to three seconds, with every byte arriving intact and in order.

## Key Takeaways

- **A modem call is not a voice call.** Modems need a steady, timing-stable signal. Jitter and packet loss that a listener would never notice cause bit errors and retrains on a modem link.
- **Modem relay changes where the modem connects.** Each site modem trains against a nearby 90X2 over a short wired connection instead of across the whole network path, and only data crosses the cellular network.
- **Nothing changed at the site.** The control system, the modems, and the application software stayed exactly as they were at both ends.
- **The results were measured, not assumed.** Byte-for-byte data integrity, delay through the relay 17 times lower than the starting point, correct negotiation at the relay's top rate, and command-to-response times of two to three seconds.
- **Expect a mode step-down.** Modems newer than the relay's native modes fall back to a compatible one. What matters is whether that mode sits inside the range the application was designed for.

## The deployment at a glance

The customer and partner are intentionally not named.

| Detail | Deployment |
|---|---|
| **Customer** | A U.S. military training range |
| **Partner** | The site's managed-services provider |
| **Endpoint** | Legacy dial-up modems on two-wire telephone lines, linking a control center to remote equipment |
| **Products** | DataRemote [90X2](https://dataremote.com/pots-in-a-box/90x2) POTS IN A BOX® (one at each end), DataRemote modem relay service |
| **Transport** | LTE cellular, replacing the copper telephone path |
| **Constraint** | Existing equipment and software kept exactly as they were at both ends |

## The challenge: a timing-sensitive control link that had to move off copper

The site's control center talks to its remote equipment over legacy dial-up modems on ordinary two-wire telephone lines. This is a classic [machine-to-machine (M2M)](https://dataremote.com/newsroom/definitions/machine-to-machine-communication) arrangement. The equipment at each end expects a modem that answers, trains, and then passes a steady stream of status and control data, and the control application depends on the timing of that stream.

The site needed those same links to run over a modern cellular connection, with the existing equipment and software kept exactly as they are at both ends. Many organizations with legacy control systems face the same problem. Carriers are moving voice service off legacy copper and time-division multiplexing (TDM) networks onto IP and wireless technology, as the FCC describes in its [guidance for government officials on modernizing telecommunications networks](https://www.fcc.gov/modernizing-telecommunications-networks-what-government-officials-need-know). Purpose-built control equipment, though, rarely runs on the carrier's schedule. It can be embedded in larger systems or costly to requalify, so keeping it in service is often the requirement rather than a preference.

Moving a modem link onto a packet network is not the same as moving a phone call. That difference is the whole story of this deployment.

## Why a modem link breaks where a phone call survives

A voice call over IP is forgiving. If a packet arrives late or not at all, the phone conceals the gap and the listener hears, at worst, a brief glitch. Speech codecs are designed around what a human ear tolerates.

A modem has no such tolerance. Before any data moves, the two modems run a training sequence. They measure the line, agree on a modulation and a rate, and lock onto each other's timing. After that, every symbol on the line carries bits. On a packet path, three things go wrong:

- **Jitter becomes bit errors.** Packets that arrive at uneven intervals distort the timing the modems locked onto. A listener would never notice the difference, but a demodulator reads it as corrupted data.
- **Packet loss becomes a missing piece of the signal.** Concealment that smooths over a gap in speech inserts audio that was never sent, and the receiving modem decodes it as wrong bits.
- **Errors trigger retrains.** When the error rate climbs, modems stop and retrain, or drop the call. During a retrain, no data moves. A control application that expects a steady stream simply stops getting one.

This is why a modem link that looks connected can still fail the application. The modems may answer and even train, but the data stream underneath is unreliable. Our guide to [fax, POS, and ATM lines in a POTS replacement](https://dataremote.com/blog/fax-pos-atm-analog-endpoints-pots-replacement) covers the same failure pattern for other modem-based endpoints.

## Three ways to carry modem traffic over a packet network

| Approach | How it works | Where the modems train | Trade-off |
|---|---|---|---|
| **Pass-through (voice-band data)** | Modem tones are digitized as audio and sent across the network | Against each other, across the entire packet path | Simplest, but every bit of network jitter and loss lands on the modem signal |
| **Modem relay** | A local gateway terminates the modem, decodes the data, and sends the bytes to a far-end gateway that regenerates the modem signal | Against their local gateway, over a short wired connection | Robust to network impairment, but the modems use a mode the relay supports |
| **Replace the modems** | Swap the modems and often the host software for native IP equipment | Not applicable | Removes the modem problem by removing the modems, but changes the system you were trying to preserve |

For this site, replacing the modems was ruled out by the core requirement that nothing change at either end. That left a choice between pass-through and relay. The first test session showed which one the link needed.

## The solution: a 90X2 at each end and modem relay over LTE

The first test session showed how unforgiving these links are. The control center could not get data through to its remote equipment at all.

The deployed architecture puts a [DataRemote 90X2](https://dataremote.com/pots-in-a-box/90x2) at each end of the link:

1. **The site's modem trains against its local unit** over a short wired connection to one of the 90X2's analog [FXS](https://dataremote.com/newsroom/definitions/fxs) ports. It does not train across the whole network path. That short connection is quiet and timing-stable, which is exactly what a modem needs.
2. **The 90X2 decodes the modem data** and exchanges it with DataRemote's modem relay service over LTE.
3. **At the far end, the second 90X2 regenerates the modem signal** for the remote equipment's modem, which also trains only against its local unit.

The result is that cellular network impairment no longer reaches the modem signal directly. What crosses the LTE network is data, not audio that has to be reconstructed tone by tone.

### Why the modems stepped down to a compatible mode

The site's modems implement a newer standard than the relay negotiates natively. During training they did what modems are designed to do: fall back to a compatible mode. The same thing happens on a noisy copper line.

The question that matters is not whether the modems run at their maximum rate. It is whether the negotiated mode fits what the application needs. Here, the compatible mode sits inside the operating range the control system was designed for, and the link negotiated correctly at the top rate the relay supports. For a control link carrying timing-sensitive status and control data, a stable connection at a supported rate is worth more than a faster one that keeps retraining.

## The results

Each result below was measured on the site's own link.

| Measure | Result | Why it matters |
|---|---|---|
| **Working link** | From no data in the first session to operators issuing commands and seeing the equipment respond in two to three seconds, as reported by the site on the latest session | The test that counts is the application working, not the modems connecting |
| **Data integrity** | On calls, every byte that left the relay matched the byte that entered it, in order | A control link can't tolerate silent corruption or reordering |
| **Delay** | Delay through the relay on a clean call measured 17 times lower than what the site started with | Lower transit delay keeps command-and-response timing inside what the application expects |
| **Rate** | The link negotiated correctly at the top rate the relay supports | Confirms the step-down landed on the best mode available, not a degraded one |
| **Site impact** | The control system, the modems, and the application software are the ones the site already had | No requalification of the equipment at either end |

## What this deployment teaches about migrating modem links

The site's path from a failed first session to a working link carries lessons for any organization with modem-to-modem circuits still on copper:

- **Inventory both ends.** A modem-to-modem link has two endpoints and both have to move together. Record the modem make and standard, the host system, and the line at each end.
- **Learn the application's tolerance before you test.** How long does the control software wait for a response? How does it behave when a frame is late? This sets the pass/fail bar, and it is usually stricter than whether the modem connects.
- **Don't treat a voice test as a modem test.** A clear phone call on the new path says nothing about whether modem data will survive it.
- **Expect, and plan for, a mode step-down.** Confirm the negotiated mode falls inside the range the control system was designed for, rather than assuming the modems will run at their nameplate rate.
- **Measure integrity and delay, not just connection.** Compare bytes in to bytes out, check ordering, and measure delay through the path.
- **Have operators run real commands.** The site's acceptance test was operators issuing commands and watching the equipment respond. That is the result the mission depends on.
- **Plan for power.** The same FCC guidance notes that traditional copper landline service typically works during power outages, while modern alternatives usually need backup power. The 90X2 includes an internal battery rated for up to 48 hours of standby.

Remote telemetry links on [cell and radio towers](https://dataremote.com/blog/revolutionizing-communications-for-cell-and-radio-tower-connectivity-with-dataremotes-pots-in-a-box) raise many of the same questions. For the wider planning process, including line inventory and choosing among replacement options, see our [complete guide to POTS line replacement](https://dataremote.com/blog/complete-guide-to-pots-line-replacement-2026).

**Plan your modem migration:**
If you have modem-to-modem circuits still on copper, start with a two-ended inventory: the modem, the host, and the response time each application expects. Share it with DataRemote and we'll help you scope a test plan for the cellular path before anything is cut over. [Talk to a DataRemote engineer](https://dataremote.com/contact).

## How DataRemote helps

DataRemote's [POTS line replacement](https://dataremote.com/solutions/pots-line-replacement) approach keeps existing analog equipment in service while the transport underneath moves to cellular. For this deployment, that meant:

- **The 90X2 at each end of the link**, an LTE POTS IN A BOX® appliance with eight analog FXS ports, dual SIM slots, and coverage across mainstream North American LTE bands. The 90X2 supports fax and legacy analog modem (M2M / SCADA) use cases.
- **DataRemote's modem relay service**, which carries decoded modem data between the two units over LTE so the modems only ever train locally.
- **Remote management through [Ara](https://dataremote.com/ara)**, DataRemote's device management platform, for provisioning, line-status monitoring, and alerts across deployed units.

Every modem link is different. The make and standard of the modems, the host application's timing, and the coverage at each site all affect the outcome, so each link should be tested on its own before cutover.

## Frequently asked questions

**Can a dial-up modem work over an LTE cellular connection?**

Yes, when the path is built for modem data rather than voice. Passing modem tones over an ordinary voice path tends to fail because jitter and packet loss turn into bit errors and retrains. At the military training range described here, each modem trained against a local DataRemote 90X2 over a short wired connection, and DataRemote's modem relay service carried the decoded data over LTE, so the existing modems and control software kept working unchanged.

**What is modem relay, and how is it different from sending modem tones over VoIP?**

Sending modem tones over VoIP (often called voiceband data or pass-through) digitizes the audio and hopes it survives the network intact, so the two modems must train against each other across the whole packet path. Modem relay terminates the modem session at a local gateway, decodes the data, and carries the bytes across the network to a gateway at the far end, which regenerates a clean modem signal. The modems only ever train across a short, quiet local connection.

**Why would a modem connect at a lower speed after moving to cellular?**

A relay negotiates a defined set of modem modes. If the site's modems use a newer standard than the relay supports natively, they fall back to a compatible mode during training, just as they would on a poor copper line. At this site the modems stepped down to a mode inside the operating range the control system was originally designed for, and the link negotiated correctly at the top rate the relay supports.

**Did the site have to replace its modems or control software?**

No. The control system, the modems, and the application software are the ones the site already had. The change was limited to placing a 90X2 at each end of the link and moving the transport from a copper line to LTE.

**How should you test a modem link before cutting it over to cellular?**

Test the application, not just the connection. Confirm the modems train and hold the expected mode, verify that every byte arrives intact and in order, measure end-to-end delay against what the application tolerates, and have operators issue real commands and confirm the remote equipment responds in an acceptable time. A modem that connects but retrains or drops data under load has not passed.

---

Canonical page: https://dataremote.com/blog/modem-to-modem-over-lte-military-range-use-case
Organization: DataRemote, Inc. — POTS line replacement, cellular failover, and fixed wireless access solutions. https://dataremote.com