Most fleet hardware programs run into the same problem – the connectivity stack is treated as an afterthought, selected late in the design cycle when changing it is expensive. By that point, the cellular module is locked in, the eSIM architecture is undefined, and the deployment covers markets where the chosen carrier doesn't perform well.

In this article:

• Choosing the right radio technology
• Module selection criteria
• Certification requirements
• eSIM architecture for fleet deployments
• Lifecycle and operational management
• Frequently asked questions
• Key takeaways

Choosing the right radio technology for fleet devices

Fleet telematics devices are mobile, always-on, and often deployed across multiple regions. That combination immediately narrows your technology options.

NB-IoT is not appropriate for moving vehicles. The technology doesn't support cell tower handover, which means a device traveling at speed will experience repeated disconnections and reconnection cycles – draining battery and creating gaps in data. As covered in detail in the NB-IoT vs LTE-M comparison, NB-IoT is designed for stationary sensors, not fleet hardware.

LTE-M is the baseline for mobile fleet devices. It supports full in-vehicle handover, SMS (important for remote management and eSIM profile operations), and delivers enough throughput for GPS pings, telemetry, and OTA firmware updates. For most tracking and telematics devices, LTE-M hits the right balance of power efficiency and capability. For data-heavy applications – dashcam footage, driver behaviour video, consistent uplink bandwidth – a CAT 1 bis module (single-antenna, up to 10 Mbps DL / 5 Mbps UL) is more appropriate.

One rule applies across all of these: always select a module with a fallback radio. A device that can only connect via LTE-M in a country where LTE-M coverage is sparse becomes a liability in production. Fallback to 4G or 2G preserves data continuity when primary networks are unavailable – and given the pace of network changes globally, that fallback will eventually be used.

Module selection criteria beyond radio technology

Choosing a chipset vendor – Quectel, Telit, u-blox, SIMCom – is only part of the decision. Several other factors determine whether a module will actually perform in production:

• Band support: Does the module support the frequency bands used by your target carriers in each deployment market? Missing bands create real coverage gaps that no software fix can address after the hardware is in the field.
• eSIM compatibility: Does the module support remote SIM provisioning via AT commands – profile download, enable, disable, and delete operations? Not all modules implement the full SGP.22 command set, and this creates operational problems later.
• BIP support: Bearer Independent Protocol is required for certain SIM management operations. Missing BIP support limits what your connectivity management platform can do remotely.
• Antenna integration: Fleet devices installed in metal vehicle cabins often suffer from poor antenna placement. Validate signal performance in realistic enclosure conditions before finalising industrial design.
• Module lifecycle: Cellular module vendors regularly discontinue SKUs. For devices expected to operate for 5–10 years, module longevity matters as much as the spec sheet.

In our experience, hardware compatibility issues are far easier to resolve in the evaluation phase than after units are in the field. We flag these mismatches even when it creates friction in the sales conversation – because discovering a band gap or missing BIP support at scale is a significantly worse outcome.

Certification requirements for North America

For OEMs targeting the US and Canadian markets, certification is non-negotiable – and more layered than most hardware teams anticipate. There are three distinct levels, and failing to plan for all three can delay launch by months.

The certification process for North America works as follows:

• FCC (US) / IC (Canada): Government-level certification covering RF emissions and spectrum use. This is the mandatory foundation for any device sold in North America and typically the first step in the process.
• PTCRB: Industry-level certification required by AT&T, T-Mobile, Rogers, Telus, and Bell Mobility. It covers OTA performance, radio conformance, SIM/eSIM functionality, and protocol compliance. Verizon is a notable exception – they operate their own independent program.
• Carrier-specific certification: Larger carriers layer additional requirements on top of PTCRB. AT&T requires TIS/TRP testing plus its own in-house certification. Verizon runs separate network-operation testing. Sprint conducts its own TIS/TRP compliance process.

The practical implication: plan your certification path at the start of hardware design, not at the end. An OEM that discovers a certification gap after manufacturing has started faces delays that cost months and meaningful revenue. Carrier requirements also change – verify current requirements directly with each target carrier rather than relying on documentation that may be outdated.

One shortcut worth knowing is modular certification. If your chosen cellular module already holds FCC/PTCRB certification, the end-device testing burden is significantly reduced. This is a legitimate strategy for compressing time-to-market, but verify that the certification covers your specific band configuration and intended use case before relying on it.

eSIM architecture for fleet deployments

The automotive eSIM management market is valued at USD 1.3 billion in 2025 and growing at nearly 16% annually – driven largely by telematics fleets and EVs. The reason is straightforward: eSIM is the only practical answer to the multi-market, long-lifecycle problem that fleet OEMs face. A vehicle or telematics device deployed today may operate for 10–15 years across multiple countries, on networks that don't yet exist, under regulatory conditions that will change. Physical SIM cards cannot accommodate that reality.

The two relevant eSIM standards differ meaningfully in what they solve:

• SGP.22 (M2M): The established standard for machine-to-machine eSIM provisioning. Uses SM-DP+ for profile hosting and SM-SR for profile state management. Mature and widely supported by module vendors – the appropriate choice for most current fleet deployments.
• SGP.32 (IoT eSIM): The newer standard, published by GSMA in 2024, designed specifically for headless IoT devices. It eliminates the SM-SR vendor lock-in that plagued SGP.22 deployments, introduces the eIM (eSIM IoT Remote Manager) for profile management, and supports multiple transport protocols including CoAP/UDP/DTLS for network-constrained devices. Critically, it removes the SMS dependency for profile downloads – directly relevant for devices deployed in markets with limited SMS support.

If you're designing a device for production in the next 12–18 months, evaluate SGP.32-capable hardware now. Avoid connectivity architectures that tie your profile management to a single SM-SR vendor – that lock-in defeats the purpose of eSIM entirely.

Multi-network access deserves specific attention here. It's not just a coverage story – it's a redundancy story. A fleet device with access to multiple networks in the same market can switch away from a congested or degraded carrier without any physical intervention. Markets like Brazil add urgency: permanent roaming restrictions can force non-compliant devices offline entirely, making local carrier profiles a compliance requirement rather than an optimisation. 1oT's IoT eSIM and M2M eSIM infrastructure is built on SGP.32-compliant eIM architecture with multi-operator flexibility across 190+ countries – designed precisely for these fleet deployment realities.

Lifecycle and operational management

Hardware selection is only the starting point. A cellular module chosen today needs to function – with updated carrier profiles, compliant software, and reliable connectivity – through network sunsets, regulatory changes, and operational scaling that may span a decade.

The most common connectivity failures in fleet telematics deployments aren't hardware failures. They're configuration failures: wrong APN settings, single-carrier SIM dependencies, legacy radio technologies that stop working after a 3G sunset. These are preventable, but only if the operational stack gives you remote visibility and control before problems compound in the field.

A production-grade fleet connectivity stack needs:

• Session-level telemetry: Know when a device loses a data session, not just when it goes offline. The difference matters for diagnosis – and for APN troubleshooting in particular, where a device can register on a network but fail to establish a data session due to misconfiguration.
• Non-steered SIMs: Steered SIMs force devices onto a preferred network regardless of signal quality. Non-steered SIMs connect to the strongest permitted network – the correct default for any mobile fleet device.
• Remote profile management: The ability to push a new carrier profile OTA without physically retrieving a device. For a fleet of 10,000 vehicles, physical SIM replacement is not a viable operational model.
• Lifecycle state management: Test state with limited data during manufacturing, transitioning automatically to operational plans post-deployment – tied to device state rather than manual intervention.
• IMEI pairing and anti-theft controls: Lock SIMs to specific device IMEIs during production to prevent misuse if hardware is stolen or substituted.

1oT's fleet management connectivity and connectivity management platform support all of these – including split invoicing between OEM and end customer, and permission-limited operator user access for managing SIM states within a customer's account. These aren't features that most OEMs ask for upfront. They're features that become urgent the moment a fleet scales past a few thousand devices.

Frequently asked questions

Should I use LTE-M or NB-IoT for a GPS tracking device installed in a moving vehicle?

Use LTE-M, without exception. NB-IoT doesn't support cell handover, which means a device in a moving vehicle will repeatedly lose and re-establish network connections as it passes cell boundaries. This creates data gaps, increases power consumption from reconnection attempts, and introduces problems for eSIM profile management since NB-IoT doesn't guarantee SMS support. LTE-M handles mobility correctly and supports the full eSIM provisioning workflow.

What's the difference between SGP.22 and SGP.32, and which should my next device use?

SGP.22 (M2M eSIM) is the mature standard, widely supported by existing module vendors and eSIM platforms. SGP.32 (IoT eSIM) is the newer standard designed for headless devices – it removes the SM-SR lock-in issue, eliminates SMS dependency for profile downloads, and introduces the eIM component for more flexible profile orchestration. For devices being designed today with a planned 5+ year lifecycle, start evaluating SGP.32-capable hardware now. For near-term production timelines, SGP.22 remains the practical choice.

Do I need carrier-specific certification if my module already has PTCRB?

PTCRB satisfies the base requirements of most major carriers – AT&T, T-Mobile, Rogers, Telus, Bell Mobility – but it doesn't cover everything. AT&T still requires its own in-house certification on top of PTCRB. Verizon doesn't use PTCRB at all and runs a completely separate program. Always verify current requirements directly with each target carrier before finalising your certification plan.

Key takeaways

• LTE-M is the correct baseline for mobile fleet devices – NB-IoT lacks cell handover and is unsuitable for vehicles. Always include a 4G fallback radio in your module selection.
• CAT 1 bis is the right choice for data-heavy fleet applications such as dashcam, video AI, and high-frequency telemetry where LTE-M throughput is insufficient.
• Certification is a multi-layer process – FCC/IC, PTCRB, and carrier-specific requirements are all separate and must be planned early in the hardware design cycle. Modular certification can compress timelines significantly.
• eSIM is a lifecycle decision, not just a connectivity one – SGP.32 eliminates SM-SR vendor lock-in and is the architecture to plan toward. Local carrier profiles are essential for roaming-restricted markets.
• Operational tooling determines real-world reliability – non-steered SIMs, session-level telemetry, and remote profile management are what separate a well-run fleet from one you're managing blind.

Ready to evaluate connectivity for your next fleet device program? Talk to the 1oT team about fleet connectivity – module compatibility, eSIM architecture, and what a production-phase support model actually looks like before you commit.

‍