[email protected]

La problemática de TCP sobre arquitecturas 5G NSA

Introducción – SA vs. NSA

Como es sabido, a la hora de la implantación de la nueva generación de comunicaciones móviles 5G, se puede optar por dos categorías de arquitectura para la interconexión de su red de acceso radio (conocida como NR, New Radio) con el resto de elementos de la red.

  • En las arquitecturas SA (Stand-Alone), cada nodo de la red de acceso, denominados eNB en LTE y gNB en NR, tiene conexiones directas de plano de usuario y plano de control hacia su núcleo de red correspondiente, es decir, el Evolved Packet Core (EPC) o el New Generation Core (NGC) respectivamente.
  • En las arquitecturas NSA (Non Stand-Alone), por el contrario, sólo uno de los nodos (eNB o gNB) tiene conexiones de plano de control y plano de usuario hacia el núcleo de red; mientras que el otro es controlado por el primero a través de la interfaz X2-C, y tiene sólo una conexión de plano de usuario hacia el núcleo de red.

Las especificaciones del 3GPP recogen múltiples variantes de estas topologías, que son nombradas bajo la etiqueta de «opciones» de arquitectura:

  • SA – Option 2, Option 5
  • NSA – Option 3/3a/3x, Option 4/4a, Option 7/7a/7x

Siendo las diferencias entre ellas diversos matices en cuanto a la conectividad del UP y/o CP. Y, de cada una de los tipos, las dos más comúnmente adoptadas son NSA 3x y SA 2, cuyos esquemas (y flujos de información relativos a la conexión 5G) recogemos aquí:

¿Qué repercusiones tiene optar por una u otra arquitectura? Demasiadas como para detallarlas en un post, pero la más inmediata es también la más relevante: mientras que SA 2 supone el desarrollo y despliegue de un Core Network (CN) 5G, la opción NSA 3x permite despliegues iniciales de la tecnología 5G basándose en el CN pre-existente que ya de servicio a las redes 4G (y otros RATs “legacy”). Ha sido, por tanto, una topología que ha permitido dar paso a despliegues rápidos de la nueva generación de redes celulares aprovechando el ahorro de coste y operación que supone tener que actualizar sólo un parte de la red, el acceso radio.

Aunque hay que recordar en su debe que, como contrapartida, no todas las prestaciones nativas 5G van a ser posibles hasta que no se disponga de un núcleo propio optimizado para estos nuevos casos de uso, que son además los asociados con la previsible capacidad disruptiva de esta nueva tecnología. Este factor, no obstante, no ha detenido a la mayor parte de los operadores que han decidido desplegar New Radio para apostar por las soluciones Non Stand Alone sobre las que seguimos comentando.

La topología NSA 3x – El concepto de ‘split bearer’

El despliegue de las arquitecturas NSA requiere, como acabamos de comentar, de una red 4G subyacente, que a menudo es referida como “LTE overlay”. Esa necesidad se manifiesta en términos de conectividad en el concepto estándar de Dual Connectivity (DC) que deben soportar y gestionar a nivel protocolos radio tanto el gNB, como el eNB y el propio terminal.

Por parte del dispositivo, el soporte de Dual Connectivity (DC) se traduce esencialmente en la presencia de dos ramas radio de recepción (RX) separadas, aunque esta implementación ha ido variando en la evolución de los chipset hacia arquitecturas más simples (pero hablar de ello no es objeto de este post)

En el ámbito de la red de acceso radio para este escenario, el 5G gNB actuará como nodo secundario (SgNB, Secondary gNB), mientras el eNB asume el rol de master (MeNB, Master eNB) y, como tal, estará al cargo de la gestión del plano de control tanto en la comunicación con el núcleo de red como con el terminal (con algunos matices asociados al SRB3 que puede establecerse de manera opcional con el gNB). Ese control por parte de la red LTE, como comentábamos con anterioridad, se manifiesta también en el empleo del Core LTE (EPC), no siendo necesario un Core 5G en absoluto.

El siguiente esquema muestra esta topología, de forma gráfica.

El concepto de ‘split bearer’ que aparece en la figura es, de facto, inherente al funcionamiento en modo DC, de forma que:

  • El plano de control (CP) viajará siempre sobre la red 4G
  • El plano de usuario (UP), representado por las ‘data radio bearers’ hacia el móvil DC, podrán viajar vía 4G, o vía 5G (usando sus interfaces S1-U respectivos) en función de las capacidades del UE.
  • Una ‘data bearer’ de un móvil que soporte DC se mapeará hacia la red 5G pero puede ser eventualmente dividida y enviada parcialmente sobre las interfaces radio 5G y 4G (con los paquetes de datos siendo reenviados sobre una conexión X2 entre ambos nodos). En el esquema anterior, esto queda reflejado en el ‘PDCP splitting point

El esquema anterior nos mostraba el comportamiento genérico a muy alto nivel. Si queremos indagar en esta división de portadora con un poco más de detalle tendríamos que emplear este otro diagrama donde los flujos de datos se representan sobre la capa de protocolos NR y LTE. Se puede apreciar como la división se produce en la entidad NR PDCP, que es la que puede decidir seguir enviando datos a través del stack propio del gNB o derivar parte del tráfico hacia la entidad RLC del eNB asociado.

 

En otras palabras, una ‘split bearer’ en una arquitectura NSA 3x será una data bearer establecida entre dos puntos extremos, la S-GW del Core LTE y el propio terminal móvil. Pero en la capa PDCP los datos van a ser divididos en dos flujos hacia las capas inferiores, uno de los cuales viajará sobre la interfaz radio 5G, mientras el otro lo hace sobre la interfaz radio 4G. Finalmente, será la entidad PDCP en el extremo contrario la que se encargará del reordenamiento de los paquetes recibidos por ambas conexiones radio.

Y aquí es donde pueden aparecer los problemas.

La interacción con TCP

A priori, sería lógico pensar que la posibilidad que NSA ofrece gracias al concepto de ‘split bearer’ nos va a garantizar obtener mejores cifras de throughput de usuario. Al fin y al cabo, estamos usando más recursos radio (sobre dos tecnologías superpuestas)… Y sólo por la mera acumulación de esos recursos, ya deberíamos poder transmitir mayores flujos de datos… ¿o no?

Quizá sea el momento de hacer un inciso, llegados a este punto, y comentar las diferencias (aunque sea muy someramente) entre flujos de datos UDP vs. TCP.

Si lo que estamos buscando es la realización de unas pruebas de estrés de la red, podemos asegurarnos de saturar completamente ambas interfaces radio (funcionando en modo ‘split bearer’) mediante la simple acumulación de flujos UDP con destino en un terminal concreto. Este tipo de pruebas se realiza típicamente con un móvil capacitado para la captura de diversos niveles de señalización en el que estaríamos registrando el comportamiento de la red.

¿Por qué lo hacemos de este modo? Porque básicamente lo que nos interesaría de esas pruebas es, sencillamente, ver que la acumulación de flujos nos permite acercarnos a los máximos teóricos que deberíamos alcanzar. El que para ello estemos malgastando paquetes UDP (que puede que nunca se envíen), no nos es crucial. Al fin y al cabo, son nuestros flujos UDP propios, y no hay ninguna aplicación o servicio esperando la confirmación de la entrega de esos datos.

Pero la mayoría de las aplicaciones de usuario (http, email, whatsapp, …)  no funcionan sobre UDP, sino sobre TCP… Y cuando nos adentramos en el mundo del comportamiento TCP, las cosas funcionan de forma radicalmente distinta…

Usaremos el esquema de la derecha para ilustrarlo.

El punto de partida es la existencia de un flujo de datos TCP que llega al gNB desde el S-GW asociado a cualquier tipo de aplicación basada en ese protocolo (como decíamos, prácticamente todas las empleadas por los usuarios finales)

Asumamos también que, por la razón que fuere (algoritmos de control de flujo, simple saturación de la interfaz radio 5G), la entidad NR PDCP en el gNB decide que es necesario desviar parte del flujo de datos vía la ‘split bearer’ hacia el eNB asociado.

Aquí van a poder ocurrir ahora dos cosas:

  • La primera, que la interfaz X2 no sea una conexión “ideal”. De hecho, es posible que no sea ni tan siquiera una conexión directa, sino que tenga que viajar de nuevo hacia el backhaul i/v para que algún switch la re-enrute.
  • El eNB puede que tenga que gestionar también, por su parte, tráfico legítimo 4G, por lo que su scheduler no sólo tendrá en cuenta nuestro flujo de datos, sino también el de aquellos otros usuarios concurrentes.

En resumen, tenemos dos fuentes de posibles retrasos para esos paquetes que la entidad NR PDCP decidió derivar hacia el eNB. Por tanto, esos paquetes llegarán al móvil con retrasos distintos a los que experimentan los paquetes que no son derivados y tendremos, en consecuencia, paquetes desordenados (® OoO, out-of-order) en el destino.

Este es, de hecho, uno de los problemas más graves a los que puede enfrentarse TCP que, como sabemos y a diferencia de UDP, requiere de la entrega de los distintos paquetes tanto correctamente como en orden. Como decía, es un problema grave porque los algoritmos de gestión del flujo TCP interpretan estos paquetes OoO como punto de partida para reducir los flujos TCP (se entiende que la causa del desorden puede ser la congestión en algún punto de la red entre el servidor/S-GW y el móvil). Y, en consecuencia, el servidor (el emisor de datos) reacciona reduciendo el throughput ofrecido al usuario…

Pero es que la situación puede incluso ser peor… Si la diferencia de retrasos es suficientemente grande, podría ocurrir que la entidad UE PDCP de esos paquetes por perdidos superados ciertos temporizadores. TCP entonces los asumirá como perdidos también, solicitando retransmisiones que ralentizan aún más todo el proceso, con la consiguiente reducción de throughput.

En resumen, la experiencia obtenida ya en los primeros despliegues de redes 5G NSA muestran que el throughput de usuario, cuando se emplean flujos TCP, puede deteriorarse por el uso de ‘split bearer’ hasta el punto de que llegue a ser en casos extremos incluso peor que cuando se utiliza la red 5G (o 4G) de forma aislada.

Y es que usando un viejo refrán… a veces “las apariencias engañan”.

Cerrar
Este sitio web utiliza cookies para mejorar su experiencia de usuario. Al continuar, entendemos que las acepta. Ver Política de Cookies