5G RedCap en abril 2026: quiénes despliegan, qué cambia para las pruebas, y cómo validar un módulo en red comercial

Un PM de módulo IoT en una OEM industrial en Madrid en abril de 2026 sostiene un módulo Quectel RG255C-EU recién soldado al diseño de referencia de un sensor de catenaria, y le pregunta al integrador 5G: “GSA dice que 42 operadores están desplegando RedCap, pero mi módulo se queda acampado en LTE en el piloto de Sevilla. ¿RedCap está vivo de verdad en esta red o no?”.

Es una buena pregunta, y no se contesta mirando la barra de señal del Android de pruebas. Se contesta abriendo el SIB1 que envía la celda, leyendo el UECapabilityInformation que sube el módulo, y comparando lo que la red declara con lo que el módulo pide. Este artículo explica, con datos de campo de abril de 2026, qué redes despliegan RedCap de verdad, qué restringe Release 17, cómo trata la red a un UE RedCap de forma diferente, las cinco cosas que salen mal en producción, y un protocolo concreto de validación de 60 minutos para certificar tu módulo en una red comercial.

Fotografía RedCap en abril de 2026: 42 operadores, 27 países, despliegues comerciales reales

La foto la firma GSA en su “5G RedCap April 2026 Industry Update” (gsacom.com): 42 operadores activos en 27 países invirtiendo en RedCap, ya sea en planificación, ensayo o despliegue comercial. Tres mercados van por delante.

T-Mobile US es el primer operador del mundo con un dispositivo RedCap comercial, lanzado en octubre de 2024 con el TCL Linkport, y lleva año y medio iterando sobre su despliegue 5G SA nacional. Verizon y AT&T han seguido con RedCap sobre 5G SA en banda C. En Europa, los pilotos visibles están en Reino Unido, Finlandia y la República Checa. En Asia, Corea del Sur tiene un caso emblemático con la planta de Hyundai en Ulsan, la mayor instalación de fabricación de automóviles del mundo en un solo emplazamiento, donde Hyundai y Samsung están corriendo RedCap sobre IoT de planta de producción. India, Indonesia, Malasia, Tailandia y Turquía tienen pilotos activos. Oriente Medio aporta Baréin, Omán y Arabia Saudí.

El ecosistema de módulos sigue al ecosistema de redes. Quectel, Fibocom, Telit Cinterion, Smawave y MeiG ya tienen módulos comerciales sobre chipsets Qualcomm, MediaTek, ASR y Sequans. Es decir, el problema no es ya “¿existe RedCap?”, sino “¿la celda donde voy a desplegar mi flota lo trata correctamente?”.

Qué restringe realmente la 3GPP Release 17 RedCap (y qué no)

RedCap no es 5G recortado al azar: es un perfil de UE definido en 3GPP Release 17, especificado normativamente en TS 38.300 (arquitectura), TS 38.331 (RRC) y TS 38.306 (capabilities). Conviene tener claras las restricciones, porque condicionan cada decisión de diseño del producto.

El ancho de banda máximo de un UE RedCap es de 20 MHz en FR1 y 100 MHz en FR2, frente a 100 MHz / 400 MHz de un UE eMBB. Las antenas de recepción se reducen a 1 o 2, frente a 4 típicas en eMBB. El sobre de throughput práctico ronda los 150 Mbps en bajada y 50 Mbps en subida con configuración estándar, números coherentes con los reportes de prueba de Keysight, Rohde & Schwarz y VIAVI sobre emulación de dispositivos RedCap. El modo half-duplex FDD (HD-FDD) es opcional y abarata el front-end. No hay agregación de portadoras, no hay dual connectivity, y no hay MIMO 4x4.

Para casos donde 150 Mbps siguen siendo demasiado caros, 3GPP está cocinando eRedCap en Release 18, con un objetivo de 5 MHz de ancho de banda y un perfil pensado para IoT realmente de gama baja. Se espera que aterrice en módulos comerciales entre 2026 y 2027. Hay un análisis detallado en el artículo eRedCap: IoT 5G aún más económico (Release 18).

La conclusión práctica de la tabla es brutal: en FR1, un RedCap R17 y un LTE Cat-4 tienen techo similar de throughput. Lo que cambia es el plano de control 5G SA, la capacidad de soportar slicing, y la trayectoria evolutiva hacia Release 18. Si tu caso de uso es solo “20 Mbps estables con IMS opcional”, LTE Cat-4 sigue siendo defendible. Si necesitas slicing, URSP o trayectoria a 5G-Advanced, RedCap es la única opción razonable. Y para entender cómo gestionar la flota de IMEI de esos módulos en producción, conviene leer también IMEI en IoT y M2M: gestión de dispositivos a escala.

Cómo trata una red comercial a un UE RedCap de forma diferente (y por qué el test debe adaptarse)

Una red 5G SA “lista para RedCap” no es la misma red 5G SA “lista para smartphone”. El gNB tiene que señalizar varios elementos específicos en el RRC, y el AMF tiene que aceptar el perfil reducido en la capa NAS. Hay cinco puntos a verificar.

Primero, el UECapabilityInformation que sube el módulo debe contener el flag redcap-r17. Sin ese flag, la red asume eMBB y le exigirá al UE recursos que no puede soportar. El detalle de cómo se construye el árbol de capabilities está en la guía UE Capabilities, MR-DC y combos CA en NR.

Segundo, la celda puede señalizar un RedCapInitialBWP dedicado en SIB1, según TS 38.331. Si ese BWP no está, el UE RedCap intentará el BWP inicial común, lo que en algunos vendor implementations provoca un fallback prematuro a LTE.

Tercero, la celda puede prohibir explícitamente RedCap en SIB1 con el campo cellBarred-redcap-r17. Esto es muy común en redes donde RedCap está habilitado a nivel de operador pero solo en un subconjunto de celdas: el resto sigue marcando “barred” para el perfil. Si tu módulo se queda en LTE en el piloto de Sevilla, este campo es la primera sospecha.

Cuarto, la configuración PRACH puede ser específica para RedCap. La celda puede asignar una raíz Zadoff-Chu y un formato distintos al perfil eMBB.

Quinto, la movilidad. Intra-RAT NR-NR funciona normalmente si la celda destino también declara soporte RedCap. El inter-RAT a LTE (fallback) es un caso que hay que validar en campo, porque algunas configuraciones de red empujan al UE RedCap a LTE en cuanto detectan baja calidad, y otras lo mantienen en NR aunque el SINR sea pobre.

Para capturar esa secuencia en un Android Qualcomm de prueba, el flujo concreto está documentado en la guía del decoder de HiCellTek.

Las 5 cosas que salen mal con un módulo RedCap en red comercial (y cómo identificarlas en Layer 3)

Después de un par de campañas de validación reales, los modos de fallo se repiten. Si los tienes presentes, ahorras horas de debugging.

El caso A es el más frecuente en pilotos europeos: el operador dice que RedCap está activo en la región, pero solo lo activa en celdas concretas. El módulo, al ver cellBarred-redcap-r17 a true, escoge una celda LTE sin reportar nada al usuario.

El caso B es un problema de firmware del módulo más que de red. Algunos firmwares antiguos no anuncian redcap-r17 aunque el chipset lo soporta. Un upgrade resuelve, y la trazabilidad se ve directamente en el UECapabilityInformation.

El caso C suele ser falso positivo: el integrador compara con un Galaxy S24 y se sorprende. Es el comportamiento normal: 150 Mbps DL, 50 Mbps UL, sobre 20 MHz, con 1 o 2 RX. No es una anomalía, es el perfil.

El caso D es más sutil. La movilidad RedCap exige que la celda destino también declare soporte. Si la red ha activado RedCap solo en un subconjunto de celdas, los handovers entre vecinas con y sin soporte producen caídas a LTE.

El caso E impacta el negocio. RedCap promete ahorro energético si el operador configura DRX largo, eDRX o incluso Power Saving Mode (PSM) cuando esté disponible. Si el RRCReconfiguration no trae DRX largo, tu producto consumirá como un smartphone. Es revisable y muchas veces el operador lo corrige a petición.

Un protocolo de validación de campo para módulo RedCap en 60 minutos

El objetivo es simple: salir de la sesión sabiendo si la celda comercial trata realmente a tu módulo como RedCap, o si lo está degradando. El kit mínimo: un módulo RedCap (por ejemplo Quectel RG255C-EU), un Android Qualcomm de control con DiagClient SDK, y una hora de campo.

El paso 1 confirma que la red acepta el módulo: si llega Registration Accept con 5G-GUTI, atado a un slice URSP coherente, el plano de control está limpio. El paso 2 es el más diagnóstico: hay que ver el UECapabilityInformation decodificado y leer literal el campo redcap-r17 a true. Si está ausente, el resto del test no tiene sentido. Los pasos 3 y 4 son funcionales. El paso 5 es el que más pesa en el modelo de negocio del cliente final, y exige varios minutos de captura porque los ciclos DRX largos pueden ser de 1.28 s o más. El paso 6 captura los fallos esporádicos que solo aparecen en serie.

El reporte que se entrega al cliente es directo:

Esa tabla, con su columna de evidencia, es lo que cierra una conversación con el operador. No es una opinión: es el contenido de SIB1 y RRCReconfiguration capturado en campo.

En resumen

5G RedCap en abril de 2026 es real, no es marketing: 42 operadores en 27 países lo están desplegando, T-Mobile US lleva año y medio en comercial, y el ecosistema de módulos sobre Qualcomm, MediaTek, ASR y Sequans está maduro. Pero la diferencia entre “el operador soporta RedCap” y “esta celda trata a tu módulo como RedCap” se ve en SIB1, en UECapabilityInformation y en RRCReconfiguration, no en la barra de señal del Android. Un protocolo de 60 minutos con un módulo RedCap, un Android Qualcomm de control y una visión Layer 3 limpia basta para certificar el comportamiento de campo. Cuando veas un módulo RedCap acampado en LTE en una zona supuestamente cubierta, no asumas: abre el SIB1.

¿Cuántas celdas con RedCap habilitado declara realmente tu operador en SIB1 hoy?