La paradoja del 5G: por qué tener cobertura completa no garantiza velocidad en el extranjero
Pocas situaciones durante un viaje resultan tan frustrantes como estar bajo los carteles de neón del cruce de Shibuya, recorrer la terminal de llegadas de Londres Heathrow o intentar pedir un Uber en Times Square con cinco barras completas de cobertura "5G" en la pantalla de tu móvil, solo para ver cómo el navegador se bloquea por tiempo de espera y las aplicaciones de mensajería se quedan cargando indefinidamente.
Esta discrepancia entre la intensidad visual de la señal y la velocidad real de transferencia se conoce en telecomunicaciones como la paradoja del 5G. Para comprender por qué ocurre, es necesario diferenciar lo que realmente mide la barra de estado de tu teléfono de cómo se transfieren los datos a través de las fronteras internacionales.
+-----------------------------------------------------------------------------+
| LO QUE TU TELÉFONO REALMENTE MIDE |
+-----------------------------------------------------------------------------+
| [Móvil] <===== Enlace de radiofrecuencia (Capa 1) =====> [Antena local]|
| * Mide: RSRP, RSSI, SINR (Barras de cobertura) |
| * Estado: 5/5 Barras (Excelente conexión RF) |
+-----------------------------------------------------------------------------+
|
| Red de transporte (Backhaul / Transit)
v
+-----------------------------------------------------------------------------+
| DÓNDE OCURRE REALMENTE EL CUELLO DE BOTELLA |
+-----------------------------------------------------------------------------+
| [Antena local] ---> [Nodo IPX] ---> [Pasarela de paquetes de origen] ---> Internet |
| * Capa 3: Enrutamiento IP y reenvío de paquetes |
| * Cuotas de ancho de banda, prioridad QCI y saturación |
+-----------------------------------------------------------------------------+Capa 1 (RF Física) vs. Capa 3 (Enrutamiento de paquetes)
Las cuatro o cinco barras que ves en tu dispositivo representan la conectividad de la Capa 1 (Red de acceso de radio física / RAN). Tu teléfono calcula este icono basándose en métricas de radiofrecuencia:
- RSRP (Reference Signal Received Power): La potencia de señal pura recibida desde la antena de telefonía cercana (gNodeB para 5G, eNodeB para LTE).
- RSSI (Received Signal Strength Indicator): La potencia total de banda ancha recibida, incluyendo ruido e interferencias.
- SINR (Signal-to-Interference-plus-Noise Ratio): La calidad del canal de radio.
Tener todas las barras simplemente significa que tu teléfono tiene un enlace de radio sin obstrucciones y de baja atenuación con la antena de la estación base local. No significa que la antena tenga capacidad de transporte (backhaul) ni que la red te haya asignado ancho de banda.
+--------------------------+-----------------------------------------------------------+
| Métrica / Capa | Qué controla |
+--------------------------+-----------------------------------------------------------+
| Capa 1 (RAN / RF) | Barras de señal, estabilidad de conexión con la antena. |
| Capa 2 (Enlace de datos) | Transmisión de tramas, prioridad de asignación de radio. |
| Capa 3 (Red / IP) | Velocidad real de datos, tránsito de paquetes IP y rutas. |
+--------------------------+-----------------------------------------------------------+Mientras tu móvil mantiene una comunicación impecable en Capa 1 con el operador local (como NTT Docomo en Japón o EE en el Reino Unido), tus paquetes de datos deben atravesar la Capa 3 (Enrutamiento de red). Si el sector de la antena local está congestionado con 20.000 usuarios locales, o si la línea de transporte que conecta la antena con el núcleo de la red está saturada, tus paquetes se colocarán al final de la cola de procesamiento.
El cuello de botella en el tránsito de roaming: IPX y enrutamiento doméstico (Home Routing)
Las eSIM de viaje internacionales introducen otra capa de complejidad: la arquitectura de roaming. Al conectarte con un perfil de viaje, tus datos no salen directamente al internet local, sino que suelen atravesar un circuito de roaming internacional:
- Acceso local: Tu teléfono se conecta mediante Capa 1 a la red de acceso de radio (RAN) del operador local del país anfitrión.
- Encapsulación IPX: El operador anfitrión encapsula tus paquetes y los reenvía a través de una red de tránsito IPX (IP eXchange) (operada por proveedores como Syniverse, BICS o Tata Communications).
- Núcleo de enrutamiento doméstico (S8HR): En configuraciones estándar con enrutamiento en origen ("Home-Routed"), el tráfico se redirige hasta el núcleo del operador móvil virtual (OMV) de origen (frecuentemente ubicado en Hong Kong, Polonia, Francia o Israel) antes de acceder a la red pública de internet.
- Ruta de retorno: Los datos solicitados deben recorrer toda esa ruta transcontinental a la inversa para llegar a tu dispositivo.
Si cualquier segmento a lo largo de esa cadena internacional con múltiples saltos sufre pérdida de paquetes, picos de latencia o limitaciones de ancho de banda, la velocidad efectiva cae a cero absoluto, incluso cuando el teléfono muestre con orgullo una conexión 5G al máximo.
Por qué importan los límites de velocidad inteligentes en zonas congestionadas
Cuando las redes experimentan picos de congestión o aplican políticas de uso justo, las eSIM de viaje habituales suelen reducir el ancho de banda del usuario a 128 kbps, o disminuyen la prioridad hasta el punto de que la pérdida de paquetes supera el 80%. A 128 kbps, las conexiones seguras modernas (apretones de manos TLS) fallan, inhabilitando por completo servicios esenciales como Google Maps, la confirmación de viajes en Uber o las pasarelas de pago digital.
Para solucionar esto, los proveedores de roaming optimizados como MollySIM emplean rutas directas y establecen una Política de Uso Justo (FUP) con un umbral mínimo considerablemente superior de 384 kbps. Al garantizar 384 kbps —el triple del estándar de la industria—, los paquetes de datos esenciales (como la carga de mapas vectoriales, la tokenización de Apple Pay y los mensajes de texto de WhatsApp) mantienen la fluidez necesaria para funcionar con fiabilidad, evitando los bloqueos totales de conectividad provocados por redes locales congestionadas.
Anatomía del QCI: cómo funciona realmente la despriorización de red
🌐 Global Travel High-Speed Travel eSIM & SIM Plans
Instant QR code activation, hotspot enabled, with guaranteed 384kbps fallback speed to keep Maps & Digital Wallets active.
Para entender por qué tu eSIM de viaje deja de responder mientras un residente local a tu lado reproduce vídeo 4K sin esfuerzo, hay que mirar más allá de las barras de cobertura y analizar la asignación de recursos de radio. Las redes móviles no tratan todos los paquetes de datos por igual. Los estándares del 3rd Generation Partnership Project (3GPP) regulan la clasificación del tráfico mediante los Identificadores de Clase de QoS (QCI) en 4G LTE y los 5G QoS Identifiers (5QI) en redes 5G Standalone.
Cuando tu teléfono se conecta a una antena local (un eNodeB en LTE o un gNodeB en 5G), la Función de Reglas de Política y Cobro (PCRF) del operador anfitrión le asigna un portador EPS con un nivel de prioridad numérico específico. Esta clasificación determina el orden exacto en el que los paquetes se transmiten por el espectro de radio físico.
La jerarquía QCI/5QI: la posición de los usuarios en roaming
Cada conexión celular se sitúa dentro de una jerarquía operativa que va desde canales de voz críticos hasta datos secundarios de bajo nivel. El tráfico de roaming entrante —donde se engloban prácticamente todas las eSIM de viaje comerciales— se ubica de forma casi universal en el escalón más bajo de esta estructura.
| Identificador QoS | Tipo de recurso | Nivel de prioridad | Límite de retardo de paquetes | Tasa objetivo de pérdida de paquetes | Descripción típica del servicio |
|---|---|---|---|---|---|
| QCI 1 | GBR (Garantizado) | 2 | 100 ms | $10^{-2}$ | Voz conversacional crítica (VoLTE / VoNR). |
| QCI 5 | No-GBR | 1 | 100 ms | $10^{-6}$ | Señalización de núcleo IMS (establecimiento de llamadas, enlaces de red). |
| QCI 6 | No-GBR | 6 | 300 ms | $10^{-6}$ | Datos de pospago prémium local (planes nativos de primer nivel). |
| QCI 7 | No-GBR | 7 | 100 ms | $10^{-3}$ | Datos de pospago local de gama media, juegos móviles y vídeo interactivo. |
| QCI 8 | No-GBR | 8 | 300 ms | $10^{-6}$ | Planes de prepago locales estándar y datos de OMV nacionales prémium. |
| QCI 9 | No-GBR | 9 | 300 ms | $10^{-6}$ | Usuarios en roaming internacional, eSIM de viaje estándar y datos masivos despriorizados. |
Asignación proporcional equitativa: cómo las antenas descartan tus paquetes
Las antenas de telefonía dividen las bandas de frecuencia disponibles en unidades microscópicas de tiempo y frecuencia denominadas Bloques de Recursos Físicos (PRB). El planificador interno de la torre ejecuta un algoritmo de equidad proporcional (Proportional Fair - PF) cientos de veces por segundo para distribuir estos PRB entre los dispositivos conectados.
Bajo una carga de red baja o moderada, el planificador atiende todas las solicitudes entrantes sin problemas. Sin embargo, en sectores con alta saturación —como la terminal de un aeropuerto internacional, una estación de tren en hora punta o un evento deportivo concurrido— la utilización de los PRB alcanza el 100%.
Al llegar a la saturación, el planificador cambia el equilibrio estándar por un triaje estricto de recursos:
- Asignación de búfer en cola: El planificador procesa primero las colas asignadas a QCI 6 y 7. Los dispositivos etiquetados con QCI 9 (como los perfiles eSIM de viaje) quedan relegados al final del búfer.
- Bufferbloat y latencia TCP: Al esperar más tiempo por un turno de transmisión, el tiempo de ida y vuelta (RTT) de los paquetes QCI 9 se dispara. Un ping normal de 40 ms puede escalar rápidamente por encima de los 1.500 ms.
- Descarte de cola (Tail Dropping): Si el búfer de entrada de la antena se llena por completo, el planificador aplica un descarte directo: elimina los paquetes de menor prioridad antes de que lleguen al enlace de radio.
- Espiral de retroceso TCP: Tu smartphone interpreta los paquetes descartados como un fallo de red y reduce automáticamente su ventana de transmisión TCP, desplomando la velocidad real casi a cero.
Cómo superar los cuellos de botella por despriorización en viaje
Dado que los operadores locales siempre priorizan a sus clientes directos de contrato por encima de los usuarios temporales en roaming durante momentos de saturación, quienes usan eSIM de viaje sufren a menudo una severa despriorización. Mientras que las eSIM convencionales agravan este escenario al sumar una asignación QCI 9 básica con límites estrictos de 128 kbps, las alternativas optimizadas mitigan el impacto reduciendo la sobrecarga de datos y elevando los mínimos de velocidad de tráfico.
Proveedores como MollySIM configuran su enrutamiento para minimizar la latencia entre operadores y garantizan una base de 384 kbps en su Política de Uso Justo, el triple del límite de 128 kbps habitual en el mercado de eSIM tradicionales. Mientras que una conexión despriorizada a 128 kbps no logra mantener los protocolos criptográficos básicos de seguridad, una base de 384 kbps ofrece la velocidad de paquetes suficiente para que navegadores como Google Maps, la solicitud de trayectos en Uber y los pagos autenticados mediante Apple Pay se ejecuten sin interrupciones por tiempo de espera.
La letra pequeña de los planes "Ilimitados": políticas de uso justo y límites de velocidad
El término "ilimitado" es el concepto comercial más desvirtuado en el sector del roaming internacional. Cuando los proveedores de eSIM de bajo coste anuncian datos ilimitados de alta velocidad, suelen incluir estrictas Políticas de Uso Justo (FUP) en los términos de servicio. En la práctica, casi ninguna eSIM de viaje comercial ofrece gigabytes ilimitados sin restricciones en redes móviles extranjeras debido a los elevados costes de tránsito mayorista que cobran los operadores de telecomunicaciones locales.
En su lugar, los usuarios se encuentran con techos de velocidad aplicados en cuanto superan ciertos umbrales diarios arbitrarios, habitualmente situados entre 500 MB y 2 GB.
La arquitectura de la limitación: PCRF y Session AMBR
A diferencia de la despriorización (que varía en tiempo real según la saturación de la antena local), el estrangulamiento o limitación deliberada de velocidad es un tope estricto aplicado por software directamente en el núcleo de la red.
- Contabilización del tráfico: Mientras navegas, el Sistema de Cobro en Línea (OCS) registra el consumo acumulado de bytes respecto a tu perfil contratado.
- Aplicación de políticas: En el instante en que alcanzas el límite diario, la Función de Reglas de Política y Cobro (PCRF) (o la Función de Control de Políticas - PCF en núcleos 5G SA) envía una orden de modificación de política a la pasarela de datos (PGW) o a la Función del Plano de Usuario (UPF).
- Restricción de ancho de banda: El núcleo de la red actualiza tu APN-AMBR (Access Point Name Aggregate Maximum Bit Rate). Esto reduce de inmediato la velocidad de bajada y subida a una mínima fracción de la capacidad real de la red, normalmente a 128 kbps o a unos insuficientes 64 kbps.
Por qué 128 kbps y 64 kbps bloquean la infraestructura web moderna
Los proveedores tradicionales de roaming justifican los límites de 128 kbps asegurando que son suficientes para "mensajería básica y navegación de emergencia". En la arquitectura web actual, esta afirmación es técnicamente errónea.
Las aplicaciones móviles actuales ya no transfieren texto plano ligero. Cada conexión requiere capas de cifrado y complejos entornos de ejecución:
- Fallos en la negociación TLS/SSL: Establecer una sesión segura exige intercambiar certificados criptográficos y claves públicas (a menudo entre 6 KB y 12 KB de datos en la negociación inicial). A través de un enlace de roaming internacional con alta latencia y limitado a 64 o 128 kbps, estas negociaciones tardan varios segundos. Los sistemas operativos móviles y las aplicaciones aplican tiempos de espera estrictos (generalmente de 5 a 10 segundos), lo que hace que la conexión segura aborte antes de transferir un solo byte de datos útiles.
- Retardos al renderizar mapas vectoriales: Plataformas como Google Maps y Apple Maps transmiten teselas vectoriales Mapbox (MVT) en lugar de imágenes estáticas comprimidas. Una conexión limitada a 128 kbps no puede descargar estos paquetes vectoriales a tiempo, dejando el mapa completamente en blanco durante la navegación urbana o en carretera.
- Sondeo de API y expiración de tokens: Las aplicaciones de transporte (Uber, Grab) y los pagos móviles (Apple Pay, Google Wallet) realizan consultas constantes a sus API para sincronizar la telemetría de ubicación e intercambiar criptogramas de autenticación. Con una conexión estrangulada, estas peticiones se descartan por tiempo de espera, arrojando constantes alertas de "Error de conexión de red".
Rendimiento real según los umbrales de limitación
| Tarea / Aplicación móvil | 64 kbps (Restricción severa) | 128 kbps (Límite eSIM tradicional) | 384 kbps (FUP optimizado MollySIM) |
|---|---|---|---|
| Mensajería de texto básica (WhatsApp, Signal) | Operativo (retraso leve) | Totalmente operativo | Totalmente operativo |
| Negociación segura TLS/SSL | ❌ Falla / Timeouts | ⚠️ Inestable (Alta tasa de fallos) | ✅ Totalmente fiable |
| Navegación y mapas vectoriales (Google Maps, Waze) | ❌ Bloqueo total | ❌ Fallos frecuentes de teselas | ✅ Carga fluida y actualización de rutas |
| Petición de transporte (Uber, Grab, Bolt) | ❌ Error de API por timeout | ⚠️ Inestable / Reservas canceladas | ✅ Totalmente operativo |
| Pagos móviles tokenizados (Apple/Google Pay) | ❌ Falla la validación de tokens | ⚠️ Fallos intermitentes | ✅ Autorización instantánea |
| Llamadas de voz VoIP (WhatsApp / FaceTime Audio) | ❌ Pérdida severa de paquetes / Voz robotizada | ⚠️ Pérdida de paquetes (15-25%) | ✅ Voz clara (Códec Opus estable) |
Recuperar la funcionalidad con límites de FUP realistas
La diferencia entre una conexión inútil y un respaldo funcional radica en diseñar límites de uso justos y técnicamente viables. Mientras que los planes "ilimitados" tradicionales dejan a los usuarios atrapados en velocidades inoperativas de 64 y 128 kbps, las soluciones más avanzadas configuran sus sistemas PCRF para mantener el flujo de datos esenciales incluso después de agotar los gigabytes de alta velocidad.
Al establecer un umbral mínimo de 384 kbps en su Política de Uso Justo, MollySIM ofrece el triple de velocidad que los límites estándar del mercado. Este umbral específico de 384 kbps garantiza que los certificados SSL/TLS se validen sin cortes, que los mapas de navegación carguen sin dejar cuadrículas vacías y que las pasarelas de pago seguro respondan al instante, asegurando que alcanzar el límite diario nunca te deje sin herramientas críticas durante tu viaje.
Comparativa técnica: limitación de velocidad vs. despriorización de red
Aunque ambos problemas se manifiestan como una notable lentitud en tu dispositivo, el estrangulamiento estricto (Hard Throttling) y la despriorización dinámica operan en capas arquitectónicas totalmente distintas de la red móvil.
El estrangulamiento estricto es un límite de ancho de banda determinista, fijado por software a nivel de PCRF (Función de Reglas de Política y Cobro) y UPF (Función del Plano de Usuario). Una vez consumida la cuota de alta velocidad contratada, tu velocidad máxima se restringe de forma tajante, con independencia de la capacidad que tenga la antena local en ese momento.
Por contra, la despriorización de red es dinámica, transitoria y depende de la asignación de recursos en la red de acceso de radio (RAN). Las eSIM en roaming suelen contar con identificadores de prioridad más bajos (QCI 8 o QCI 9) frente a los usuarios locales de contrato (QCI 6 o 7). Cuando una antena experimenta una alta concentración de tráfico, su planificador asigna los bloques de recursos de radio (RRB) a los clientes locales en primer lugar, poniendo en cola o descartando los paquetes de los perfiles de roaming despriorizados.
| Dimensión arquitectónica | Estrangulamiento estricto (Agotamiento FUP / Cuota) | Despriorización dinámica (Prioridad QCI) |
|---|---|---|
| Detonante principal | El consumo de datos alcanza el límite del plan | Congestión en la antena, alta densidad de usuarios, nivel QCI bajo |
| Punto de aplicación en la red | Núcleo de red (Control de políticas en PCRF / PGW / UPF) | Red de acceso de radio (Planificador eNodeB / gNodeB) |
| Comportamiento de velocidad | Límite máximo fijo (ej. 64 kbps, 128 kbps o 384 kbps) | Variable: oscila entre alta velocidad y cero absoluto |
| Impacto en latencia y RTT | RTT nominal, pero alta latencia en apps por acumulación de paquetes | Picos extremos de RTT (500 ms – 2.500 ms), bufferbloat |
| Tasa de pérdida de paquetes | Baja (los paquetes se retrasan, no se destruyen) | Alta (descartes continuos de paquetes en la interfaz de radio) |
| Método de resolución | Renovación del plan, recarga adicional o reinicio del ciclo diario | Cambiar de ubicación a una antena descongestionada o esperar a que baje el tráfico |
Pruebas de rendimiento en aplicaciones con redes restringidas
Para evaluar el impacto de estas limitaciones durante un viaje real, analizamos el rendimiento de aplicaciones esenciales en tres situaciones: Límite estándar de mercado (128 kbps), FUP optimizado de MollySIM (384 kbps) y Despriorización severa (Antena congestionada).
+---------------------------------------------------------------------------------------+
| COMPARATIVA DE RENDIMIENTO POR APLICACIÓN |
+----------------------+--------------------+--------------------+----------------------+
| Servicio / App | Límite a 128 kbps | Límite a 384 kbps | Despriorización dinámica |
+----------------------+--------------------+--------------------+----------------------+
| Mapas Google Vectors | Carga en 18–35 s | Carga fluida en 2–4s| Timeouts intermitentes |
| Llamada VoIP WhatsApp| Con cortes/Robótica| Nítida (Códec Opus)| Jitter severo/Robótica |
| Petición Uber / API | Timeout de auth | Solicitud rápida | Pérdida de conexión con conductor |
| Vídeo en 1080p | Error total (ABR) | Solo audio / 240p | Carga y paradas constantes |
+----------------------+--------------------+--------------------+----------------------+1. Navegación vectorial y rutas en Google Maps
- Con límite estricto a 128 kbps: Las capas de teselas vectoriales (formato Protobuf) no logran descargarse de forma simultánea. Al desplazarte por un nuevo barrio de la ciudad aparecen cuadrículas en blanco y el recálculo de rutas tarda entre 25 y 40 segundos por el bloqueo de las conexiones HTTP/2.
- Con límite estricto a 384 kbps: Dado que los datos vectoriales ocupan entre 20 y 50 KB por pantalla, la base de 384 kbps de MollySIM descarga la información en solo 1,5 a 3 segundos. Las conexiones TLS se mantienen activas, se omiten de forma limpia las imágenes por satélite pesadas y la navegación paso a paso se actualiza sin demoras apreciables.
- Con despriorización dinámica: Las peticiones de mapas sufren altas tasas de retransmisión a nivel de enlace de radio (RLC). Aunque haya suficiente velocidad nominal aparente, la elevada pérdida de paquetes colapsa la ventana TCP, dejando el mapa congelado a mitad de trayecto.
2. Llamadas de audio por WhatsApp y FaceTime (VoIP)
- Con límite estricto a 128 kbps: Las llamadas VoIP utilizan el códec de audio Opus, que se ajusta de 6 a 32 kbps. Aunque la velocidad teórica bastaría, las tareas de sincronización en segundo plano del teléfono saturan de inmediato el canal de 128 kbps, provocando bufferbloat y distorsionando la voz con sonido robotizado.
- Con límite estricto a 384 kbps: El margen adicional de ancho de banda aísla la llamada de la telemetría en segundo plano. El jitter se mantiene estable por debajo de 40 ms, permitiendo una conversación de voz bidireccional clara.
- Con despriorización dinámica: Al descartarse masivamente el tráfico UDP durante la saturación en la antena, el audio VoIP sufre silencios constantes y cortes continuos de llamada.
3. Servicios de transporte y geolocalización (Uber, Grab, Bolt)
- Con límite estricto a 128 kbps: Las aplicaciones de transporte dependen de conexiones WebSocket activas y llamadas REST API continuas para rastrear la ubicación del conductor, validar tarifas y procesar pagos. Con 128 kbps, las negociaciones criptográficas (TLS 1.3) superan con frecuencia el tiempo de espera del servidor (normalmente de 10 a 15 segundos), cancelando la solicitud del viaje.
- Con límite estricto a 384 kbps: El intercambio de tokens y la recepción de las coordenadas GPS del conductor se completan con fluidez, evitando fallos en la autorización del cobro o bloqueos en la interfaz.
- Con despriorización dinámica: La pérdida intermitente de paquetes interrumpe la sesión WebSocket, haciendo que el icono del vehículo dé saltos en la pantalla o se muestre inmóvil cuando el coche ya ha llegado a tu ubicación.
4. Streaming multimedia y redes sociales (Instagram, YouTube, TikTok)
- Con límites estrictos (128 kbps y 384 kbps): Los algoritmos de tasa de bits adaptable (ABR) detectan la velocidad limitada al instante. La reproducción a 1080p/4K es imposible; a 384 kbps se cargan vistas previas de baja resolución y texto en redes sociales, pero el contenido de vídeo requerirá almacenamiento en búfer constante.
- Con despriorización dinámica: Los reproductores intentan descargar fragmentos de vídeo en alta calidad durante pequeños picos de velocidad, para congelarse de golpe en cuanto la antena reasigna los recursos a los usuarios prioritarios.
La arquitectura de MollySIM: enrutamiento de alta prioridad y base funcional de 384 kbps
Evitar la degradación de la conexión requiere intervenir tanto en el enrutamiento central de la red como en la configuración de los perfiles de roaming mayoristas. La mayoría de revendedores de eSIM de bajo coste operan como simples intermediarios que revenden las rutas de datos más económicas del mercado. Este enfoque introduce una latencia notable y relega a los viajeros a perfiles QCI de la categoría más baja.
Por el contrario, MollySIM utiliza un modelo de infraestructura fundamentado en nodos de tránsito distribuidos en el borde, perfiles QoS de roaming optimizados y un suelo de ancho de banda garantizado diseñado para los protocolos de aplicaciones actuales.
+-------------------------------------------------------------------------+
| eSIM ECONÓMICA TRADICIONAL (Enrutamiento centralizado) |
| Usuario (Tokio) ---> Antena roaming ---> Túnel a Europa/HK ---> Internet|
| Latencia: 350ms+ | QCI bajo (Despriorizado) | Tras límite: 128kbps (Falla)|
+-------------------------------------------------------------------------+
+-------------------------------------------------------------------------+
| ARQUITECTURA MOLLYSIM (Salida local / Local Breakout) |
| Usuario (Tokio) ---> Antena roaming ---> Nodo PGW/UPF local ---> Internet|
| Latencia: <40ms | Alta prioridad QCI | Tras límite: 384kbps (Útil) |
+-------------------------------------------------------------------------+1. Pasarelas de salida local directa (LBO) vs. Enrutamiento doméstico de alta latencia
Cuando un usuario se conecta a una antena en el extranjero, la pasarela de datos (PGW) o la Función del Plano de Usuario (UPF) determinan por dónde sale ese tráfico hacia el internet público.
- El problema del enrutamiento centralizado tradicional: Los proveedores de bajo coste redirigen todo el tráfico internacional a una pasarela centralizada en su país de origen (habitualmente Hong Kong, Polonia o Israel), sin importar dónde esté el usuario. Un viajero en Tokio que consulta los horarios del tren local debe esperar a que sus paquetes viajen hasta Europa y regresen, sumando entre 300 ms y 450 ms de latencia base (RTT) antes de procesar cualquier respuesta.
- Salida local de MollySIM (Local Breakout - LBO): MollySIM cuenta con nodos de salida distribuidos estratégicamente en Norteamérica, Europa, Asia Oriental y Oceanía. Las consultas DNS y el tráfico de datos salen a través de nodos regionales próximos a la ubicación real del usuario. Esto reduce el RTT interno a valores de entre
🌐 Global Travel High-Speed Travel eSIM & SIM Plans
Instant QR code activation, hotspot enabled, with guaranteed 384kbps fallback speed to keep Maps & Digital Wallets active.