If you're comparing Simbase to a native carrier SIM and you've seen the term QCI in operator documentation, this article explains what it is, why it doesn't directly apply to Simbase the way it might for a Verizon or AT&T SIM, and what to expect from Simbase performance instead.
QCI (QoS Class Identifier) is a one-byte value used in LTE and 5G networks to mark a traffic flow's priority class. The carrier's network treats different QCIs differently. Voice traffic gets a high-priority class with low latency and packet loss guarantees, bulk data gets a best-effort class with no guarantees, and so on.
QCI values are assigned at the bearer level when a device sets up a data session, and they control:
Whether the flow is guaranteed bit-rate (GBR) or non-GBR
Packet delay budget (target latency)
Packet error loss rate (target reliability)
Scheduling priority within the carrier's network
For native SIMs from a single carrier, the carrier can offer plans with specific QCI assignments, typically as part of an enterprise SLA.
No. Simbase doesn't apply throttling, artificial prioritisation, or rate-limiting at the platform level. You get the same access to the radio network as any standard roaming SIM. That means the same 2G/3G/4G/5G bearer types where the network supports them, and no Simbase-imposed cap on throughput.
Simbase SIMs are standard roaming SIMs, not stripped-down "IoT-only" variants. They can initiate emergency calls and behave like any international SIM used by frequent travellers or global enterprises.
Simbase's coverage comes from roaming agreements with operators around the world. When your device attaches to a network in another country:
The visited carrier applies its own policies and overrides many values signalled by the home network.
Simbase, as the home operator, cannot enforce or expose QCI values per visited carrier. That's the visited carrier's network.
No roaming provider can publish a complete QCI table per network. Even the largest roaming aggregators don't have this data, because it varies per agreement and is rarely contractual.
Even when visible, QCI is a poor predictor of real-world performance for data-heavy applications. The network's actual congestion state matters more.
This isn't unique to Simbase. It's the nature of cellular roaming. If QCI guarantees matter to your application, the only way to get them is from a native local SIM with an operator agreement.
In some cases, a native SIM from a local carrier (Verizon, AT&T, Vodafone, and so on) will outperform a roaming SIM. Three reasons:
Local IP breakout. A native SIM's traffic exits the cellular network in the same region as the device. Latency from California to a California server is short. Simbase's traffic breaks out at globally distributed locations (Virginia, Dallas, Frankfurt and others), so a device in California talking to a California server may have its traffic routed via a US-east breakout, which adds latency.
SLA-based prioritisation. Native enterprise SIMs may have contractual QoS agreements that set them apart from consumer traffic on the same network.
Carrier-specific optimisations. Carriers often optimise paths between their local devices and their own infrastructure.
For most IoT use cases, here's the realistic profile:
| Characteristic | Simbase SIM | Native carrier SIM |
|---|---|---|
Latency | ~100–250 ms (remote IP breakout) | ~20–80 ms (local breakout) |
Bandwidth | Whatever the local network gives you, no Simbase throttle | Whatever the carrier provides; may include burst allowances |
QCI / QoS guarantees | Not exposed or contractual | Available from the carrier on enterprise plans |
Network access per country | Multiple carriers via roaming | One carrier (your home carrier) |
IP breakout location | Centralised regional gateways | Local |
Failover between operators | Built-in via Multi-IMSI / eUICC | Limited to one carrier |
Latency
Bandwidth
QCI / QoS guarantees
Network access per country
IP breakout location
Failover between operators
Simbase is the right answer when:
The device deploys in multiple countries, or moves between them
You need multi-operator failover within a country
Latency of 100–250 ms is acceptable for the application
You want consistent IP breakout for logging, security, or compliance
You don't depend on carrier-specific QCI/QoS SLAs
A native carrier SIM is more appropriate when:
The device is fixed in one country (and your carrier covers it well)
You need single-digit-millisecond to ~50 ms latency
You have contractual QoS / QCI guarantees as a hard requirement
The device is in a region where the carrier offers specific optimisations for your traffic class
If latency matters but multi-operator failover does too, two things help:
Use a regional breakout APN for Black/Red/Green profiles in the EU (simbase.eu) or US (simbase.us). See Set up the Simbase APN.
Move your server closer to the breakout location for the region where most of your fleet runs.
For Blue/Yellow/Purple/Cyan profiles, the underlying eUICC profiles are typically provisioned for the region where the device operates, so local breakout is achieved through profile selection rather than APN choice.
Probably not. By the time Simbase secured contractual QoS through every visited carrier, the agreements would be specific to a region or a customer, at which point a private APN is a better fit. Talk to sales if you have a use case.
Probably not Simbase. Variability typically comes from the visited cellular network, the radio conditions at the device, or the IP breakout location. Diagnostics can help isolate.
Yes. Emergency calls work on Simbase SIMs through standard roaming behaviour, subject to the visited network's emergency-call policies.
Set up the Simbase APN, regional breakouts to reduce latency
SIM Profiles, coverage and technology per profile
Multi-IMSI vs eUICC, failover technology


© 2026 Simbase Connect. All rights reserved.

