Quality of service (QCI) on Simbase SIMs

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.

What QCI is

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.

Does Simbase throttle or deprioritise traffic?

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.

Why QCI is not directly relevant in a roaming setup

Simbase's coverage comes from roaming agreements with operators around the world. When your device attaches to a network in another country:

  1. The visited carrier applies its own policies and overrides many values signalled by the home network.

  2. Simbase, as the home operator, cannot enforce or expose QCI values per visited carrier. That's the visited carrier's network.

  3. 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.

  4. 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.

Why a native carrier SIM may feel faster

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.

What to expect from Simbase performance

For most IoT use cases, here's the realistic profile:

Characteristic
  • Latency

  • Bandwidth

  • QCI / QoS guarantees

  • Network access per country

  • IP breakout location

  • Failover between operators

Compare uptime, not just latencyLower latency in some cases doesn't mean better overall. A native SIM gives you 50 ms latency until your one carrier has an outage. A Simbase SIM gives you 200 ms latency every day, including during the carrier outage.


When to choose Simbase vs native


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

Reducing latency on Simbase SIMs

If latency matters but multi-operator failover does too, two things help:

  1. 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.

  2. 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.

Common questions

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.