Cellular, Wi-Fi or Phone Tether: Connectivity for a Voice LLM Device

Concept render

Raw 24 kHz mono PCM, assuming 16-bit samples, is 384 kbps. That is above the 375 kbit/s LTE-M downlink peak u-blox publishes, so LTE-M needs a compressed codec, while Cat 1bis lists up to 10 Mb/s down. Wi-Fi and BLE tether have no sourced battery figures, so measure battery, latency and coverage on your own board.

A voice LLM device has to move audio to a model and bring the reply back. The link you choose sets your data bill, your battery life and where the product works. This guide starts from the published numbers, does the bandwidth and data-cost arithmetic with inputs you can replace, and lists what to measure on your own board. It contains no Duobay price and no measured result.

Every vendor figure below was read on October 31, 2026. This is an engineering write-up of public documents. Rates, plans and prices change, so re-read the linked pages before you decide.

What do the four links offer on paper?

The table lists what the public sources say and marks the gaps. A gap means the vendor did not publish a figure in the pages we checked. Fill it in with a measurement.

The u-blox pages give two upload figures for LTE-M: 1 Mbit/s on the technology page and 1200 kb/s on the module summary. We show both. The module summary's power numbers belong to one module and do not apply to every LTE-M design.

Which link should you prototype first?

This section is engineering reasoning that follows from the sourced facts above. It is not a vendor claim and not a measured result. It branches on three questions about your product.

• Does the user have a network or a phone at the place of use? If the device is used only where the user has a Wi-Fi network they can join, prototype Wi-Fi first: it needs no SIM and no carrier plan. If the user carries a phone and will run your companion app, prototype the BLE tether. If neither can be assumed, the device needs its own cellular link. Test that settles it: Wi-Fi join and power, or BLE audio throughput with a phone.
• Is a SIM and a data plan acceptable? If not, the choice is Wi-Fi or BLE. If yes, compare LTE-M and Cat 1bis. Cat 1bis lists higher rates (up to 10 Mb/s down), LTE-M lists lower rates and PSM and eDRX. Neither has a power figure we could verify for your design, so the battery drain test decides between them. Test: battery drain per minute and carrier coverage.
• Is the device press-to-talk or always listening? A press-to-talk device can sleep between presses, which fits the PSM and eDRX modes the sources describe. An always-listening device keeps the link or the phone connection active, so test battery drain on that duty cycle for every link before you commit. Test: battery drain per minute, with the idle time included.

If more than one branch applies, prototype the link with the weakest assumption first, such as a phone always being nearby, and keep the cellular option as the fallback.

Does the audio fit in the link?

OpenAI's realtime guide says to send 24 kHz mono audio for PCM (OpenAI realtime guide, as of October 31, 2026). The guide as we read it does not state the sample width. We assume 16 bits per sample, which is our assumption and not a vendor statement.

R = sample_rate × bits_per_sample
  = 24,000 × 16
  = 384000 bits per second
  = 384 kbps

LTE-M published downlink peak = 375 kbit/s
384 kbps > 375 kbit/s   so raw PCM does not fit the downlink peak

The comparison is for the reply direction, where audio comes down from the model. The microphone direction sits under the 1 Mbit/s upload peak. Because LTE-M is half duplex, both directions share the radio, and the sources do not give a split. Cat 1bis lists up to 10 Mb/s down, which leaves wide headroom for the same stream. A compressed codec changes the picture for LTE-M. We did not find codec bit rates in the official pages we read, so take them from the codec specification you choose.

For a BLE tether, the PHY rates run from 125 kb/s (Coded S=8) to 2 Mb/s (LE 2M) (Bluetooth SIG, as of October 31, 2026). The slowest option is below the raw 384 kbps stream, and the fastest is well above it. These are radio rates. Throughput through a real phone is a test result.

Second check: your own codec rate

Replace the raw PCM figure with the rate R, in kbps, of the codec you choose, taken from its specification. Apply the same test to each link, once for the direction that carries the most audio. Add headroom you choose in advance for protocol overhead and poor signal.

pass if R + headroom < link rate in that direction

LTE-M downlink   375 kbit/s
LTE-M uplink     1 Mbit/s (technology page) or 1200 kb/s (module summary)
Cat 1bis         up to 10 Mb/s down
BLE LE 1M        1 Mb/s       LE 2M            2 Mb/s
BLE Coded S=2    500 kb/s     BLE Coded S=8    125 kb/s

All of these are peak or PHY rates. A pass here means the link is not ruled out. A fail rules it out for that codec. Because LTE-M is half duplex and BLE passes audio through a phone, a pass on paper still has to be confirmed with the throughput and battery tests below. Wi-Fi has no figure in our sources, so take its rate from your Wi-Fi chip datasheet and apply the same test.

How much does the data cost?

The model has two parts. One is carrier data, which applies to the cellular links. The other is the model API, which applies to every link.

Carrier data cost

MB per hour (one direction) = R_kbps × 3,600 ÷ 8 ÷ 1,000
data cost = MB × c       (c = price per MB, dollars)
monthly SIM cost = S × (number of SIMs)
one-time SIM cost = K × (number of SIMs)

Units: R in kbps, MB in megabytes, c in dollars per MB, S and K in dollars. Hologram's self-service plan lists $0.03 per MB, $1 per SIM per month and $3 per SIM card (Hologram pricing, as of October 31, 2026). That page does not mention LTE-M, so the $0.03 figure is a reference point for order of magnitude and carries no LTE-M label.

Worked example, recalculated. R = 384 kbps (raw PCM, 16-bit assumption). One direction: 384 × 3,600 ÷ 8 ÷ 1,000 = 172.8 MB per hour. At $0.03 per MB that is 172.8 × 0.03 = $5.18 per hour. With audio in both directions, the transfer doubles to 345.6 MB and the cost to $10.37 per hour. For an assumed 10 minutes of one-direction audio in a day, the transfer is 172.8 ÷ 6 = 28.8 MB, which costs $0.86. The 10 minutes is a placeholder for your own H. A compressed codec lowers all of these in proportion to its bit rate.

Model API cost

The same API price applies on every link. OpenAI lists these audio rates per million tokens (OpenAI pricing, as of October 31, 2026).

To turn these into a cost per minute you need audio tokens per second of speech. The pages we read do not give that rate, so we do not compute a per-minute API cost here. Read it from the usage fields of real responses on a prototype, then multiply: tokens per second × seconds × price per token. Keep the cloud cost separate from the link cost, because it does not change with the uplink.

Inputs, and which are yours to replace

A battery formula you can fill in

hours of active link ≈ B ÷ I        (B in mAh, I in mA)

Take B from your battery and I from your own measurement. For scale only, the SARA-R500E summary lists 195 mA connected at 23 dBm. If a modem drew that continuously, every 100 mAh of capacity would last 100 ÷ 195 = 0.51 hours. That is a ceiling for one operating point on one module and says nothing about a real session average (u-blox SARA-R500E summary, as of October 31, 2026).

Which pitfalls follow from the published facts?

These come from engineering reasoning about the numbers above. None describes an incident at a named company.

• Raw PCM does not fit the LTE-M downlink. Raw 24 kHz mono audio at an assumed 16 bits per sample is 384 kbps. The published LTE-M downlink peak is 375 kbit/s. A reply stream at 384 kbps cannot fit under that peak even before protocol overhead and poor signal, so the reply audio needs compression or a faster link.
• Half duplex shares one lane. u-blox describes LTE-M as half duplex. A device that sends microphone audio while it receives the model reply has to share airtime between the two directions. That is engineering reasoning from the published mode, and the effect on your product has to be measured.
• VoLTE is the operator's switch. The u-blox page says voice over LTE is available "if enabled by MNOs." A design that needs a circuit-style voice call over LTE-M depends on a carrier decision. Streaming audio as data to the model API does not need VoLTE, but ask your carrier which of the two you are buying.
• Power saving modes and live conversation pull in opposite directions. PSM and eDRX exist to let the modem sleep. The sources give no wake-up time for them. Treat the saving as a fit for a device that wakes on a button press and waits for the user, and measure whether an always-listening design can use them at all.
• A bit rate on a spec page is a ceiling. The same u-blox technology page says up to 1 Mbit/s up, and the SARA-R500E summary says 1200 kb/s up. Both are peaks under their own conditions. Plan from the throughput you measure in the field.
• BLE PHY rate is a radio number. The 1 and 2 Mb/s figures describe the PHY. Throughput through a phone depends on the phone, its operating system, the connection interval and your protocol. The Bluetooth page does not give application throughput, so measure it.
• A BLE tether adds a software dependency. The device needs a phone nearby with your companion app running. Background limits, pairing state and app updates become part of the voice path. We list this as a design consideration with no sourced incident behind it.
• The WebSocket path hands playback to you. OpenAI recommends WebRTC for browser playback. With WebSocket, the client handles playback and truncation. On a device that means your firmware owns the audio buffer and the interruption logic, whichever uplink you choose.
• An unlabeled price is not an LTE-M price. The $0.03 per MB figure comes from a plan page that does not mention LTE-M. Use it to size the order of magnitude and replace it with a quote for the technology you pick.

What should you measure on your own board?

The public sources do not give battery, latency, phone throughput or coverage for your product. We have not measured these for you, and no result appears here. Run these on your own hardware.

Set each pass line from your product promise before you run the test, and record the reason. A threshold chosen after you see the data tends to land just under the data.

Sample-size rule (engineering reasoning, not a vendor figure). Run a short pilot on each link and each site and compute the standard deviation s of the measure. Decide the error e you can accept on the mean. Then sessions per link and per site n ≈ (z × s ÷ e)², where z is the normal-table value for your chosen confidence level. A link and site with noisy results needs more sessions. Fix n before the main run.

What should you ask before you commit?

Take this list to your team and to any supplier who proposes an uplink.

• What audio bit rate do we send and receive, and which codec produces it?
• Does the reply stream fit under the published downlink peak of the module we picked, with the margin we chose in advance?
• Do we need VoLTE, or do we send audio as data to the model API? Has the carrier confirmed what it enables?
• Which carrier plan applies, what does it charge per MB and per SIM, and is that price for the technology we use?
• Is the device meant to listen all the time or wake on a press, and does the choice allow PSM or eDRX?
• If we use a BLE tether, who builds and maintains the companion app, and how does voice behave when the app is closed?
• Which side owns audio playback and interruption, the firmware or a browser or app?
• What is the measured battery drain per minute on each link, and on whose test rig?
• What happens to the user when the link drops mid-sentence?
• Which numbers in our model came from a vendor page, and which are still our own assumptions?

If you want a connectivity option compared for your own device, tell us about your device. You can also see how we approach audio and voice hardware development.

Sources

All pages accessed October 31, 2026. Rates and prices change, so re-read them before you decide.

• u-blox, LTE-M technology page: https://www.u-blox.com/en/technologies/lte-cat-m (accessed 2026-10-31)
• u-blox, LTE Cat 1bis article: https://www.u-blox.com/en/blogs/insights/lte-cat-1bis (accessed 2026-10-31)
• u-blox, SARA-R500E product summary: https://content.u-blox.com/sites/default/files/documents/SARA-R500E_ProductSummary_UBX-22018075.pdf (accessed 2026-10-31)
• Bluetooth SIG, technology overview: https://www.bluetooth.com/learn-about-bluetooth/tech-overview/ (accessed 2026-10-31)
• OpenAI, Realtime conversations guide: https://developers.openai.com/api/docs/guides/realtime-conversations (accessed 2026-10-31)
• OpenAI, API pricing: https://developers.openai.com/api/docs/pricing (accessed 2026-10-31)
• Hologram, pricing: https://hologram.io/pricing/ (accessed 2026-10-31)