Introducción

Las demandas de ancho de banda en los últimos años han aumentado notablemente debido a los nuevos servicios de video en alta definición y otras necesidades propias de las nuevas tecnologías. Las implementaciones de banda ancha ultra rápida son muy complejas técnicamente, y se están moviendo hacia tecnologías de acceso de próxima generación, lo cual implica el incremento de la infraestructura de fibra óptica cada vez más cerca del cliente (FTTH, Fiber to the Home) a fin de aumentar la velocidad en los servicios.(Council & Alliance, 2015) Además, la instalación de fibra óptica requiere una gran inversión de dinero para cubrir áreas geográficas significativas(Otelco, n.d.), por lo que muchas empresas deciden asociarse para compartir los costos de los tendidos, lo cual implica tener que definir cómo se gestionará el acceso. Esto llevó al desarrollo del concepto de FANS para estandarizar el uso de las redes por parte de diferentes empresas de forma flexible, y ofreciendo control de configuraciones, lo que permite la creación de nuevos productos y servicios de cara al cliente, que habilitan a competir en la capa activa.

El interés particular del foco en los dispositivos IoT radica en que los mismos corresponden a una de las tres categorías principales de aplicación de la tecnología 5G definidas por el ITU-R(ITU-R, 2015), llamada mMTC (Massive Machine type Communication) y orientada a la conexión de diferentes artefactos y dispositivos a Internet que se considera del orden de los miles de millones. Ejemplos de esto lo constituyen los electrodomésticos inteligentes, sistemas de alarma y cámaras, y drones para situaciones de desastres y emergencias. En cualquier caso, el análisis propuesto no incluye los posibles efectos del sincronismos y problemas tecnológicos de la tecnología en sí. Las otras 2 categorías de uso en 5G son eMMB (Enhanced Mobile Broadband) y URLLC (Ultra Reliable Low Latency Communication). Esta última corresponde al caso de uso más exigente

Asimismo, el interés específico en la tecnología 5G radica en que está orientada a aumentar capacidades y cantidad de dispositivos, penetración en las ciudades, y nuevos tipos de servicios, y serán desplegadas en parte sobre redes de fibra óptica, lo cual requerirá una integración técnicamente eficiente de ambas tecnologías. Los temas principales de los encuentros de Broadband Forum en 2020 se enfocaron en las tecnologías IoT y 5G, determinando que la industria de las telecomunicaciones a nivel global se encuentra avanzando hacia la resolución de varias de las cuestiones presentadas, que son los desafíos a ser resueltos por estas redes.

Las tecnologías y estándares que se consideran como base para este estudio corresponden al ecosistema de dispositivos y protocolos utilizados en redes de fibra óptica, y se detallan a continuación:

FANS (Fixed Access Network Sharing): propone que mediante una interconexión y un acuerdo de aprovisionamiento, operación y mantenimiento de clientes, se utilice la red de un proveedor que tiene cobertura sobre una ciudad específica, para ofrecer servicios de otro proveedor.(The Broadband Forum, 2017) Poniendo en consideración que una vez alcanzado este punto se podrá replicar este esquema en cualquier lugar que el InP (Infrastructure Provider) tenga red de acceso. La principal referencia sobre FANS la constituye el estándar TR-370 de BroadBand Forum, que busca automatizar y armonizar datos, control y gestión de interfases entre los proveedores de infraestructura (InPs) y operadores mayoristas, o Virtual Network Operators (VNOs). Esto puede ayudar a disminuir los costos operacionales de las empresas, a la vez que aumentan y mejoran los servicios para los clientes. Así, FANS permite particionar a nivel lógico y aislar recursos de red compartidos entre operadores, y trabaja con virtualización, donde las funciones de control son migradas desde equipamiento de red dedicado a software corriendo sobre hardware genérico, con FANS proveyendo Network as a Service (NaaS)(The Broadband Forum, n.d.). Dentro de los alcances y objetivos a cumplir en FANS, el principal es la inclusión de un nuevo VNO a la red de fibra existente. No obstante, hay varios puntos a tener en cuenta, ya que las integraciones en lo que respecta a provisión, operación y mantenimiento son un punto crucial en esta implementación. El objetivo de estas es que el VNO pueda continuar utilizando las diferentes plataformas que componen su red. En esta investigación se toman como referencia los tres diferentes modelos que presenta el estándar para interconexión de proveedores a la red de acceso: Q-inQ, VXLAN y MPLS.

GPON (Gigabit Passive Optical Networks) está basada en las normas ITU-T G.984(ITU-T, 2008). En dichas normas se explica las normativas para lo que incluye aprovisionamiento, protocolos, mantenimiento, instalaciones de fibra, privacidad y seguridad. Las redes GPON cuentan con un equipo concentrador de clientes llamado OLT (Optical Line Termination) del que se interconectarán los diferentes clientes a través de un terminal llamado ONT (Optical Network Terminal). Las OLT tienen por norma la capacidad de poder abastecer por puerto de fibra hasta 128 clientes. Para alcanzar esta ocupación cada pelo de fibra es dividido (split) con divisores ópticos (splitters) que se encargan de separar la señal y enviarla desde un puerto de entrada a múltiples puertos de salida.

Latencia: la latencia en un servicio está dada por el tiempo que tarda en llegar un mensaje de un punto a otro. Al enviar un mensaje del punto A al punto B hay que considerar múltiples factores que afectan en los tiempos de recepción de este en el destino. El procesamiento de los equipos es uno de los factores que más afecta a la latencia, pero también se deben contemplar factores como tiempos de transmisión por el medio, tamaño de los paquetes por fragmentación, y encolado.

MPLS (Multiprotocol Label Switching): es un mecanismo de transporte de datos estándar creado por la IETF y definido en el RFC 3031(IETF, 2001). Opera entre la capa de enlace de datos y la capa de red del modelo OSI, y fue diseñado para unificar el servicio de transporte de datos tanto para las redes basadas en circuitos como en paquetes. Puede utilizarse para transportar diferentes tipos de tráfico, incluyendo voz y e IP.

VXLAN (Virtual Extensible Local Area Network): es un protocolo destinado a la superposición de redes (Overlay Networks) que permite transportar tráfico de la capa de enlace de datos sobre la capa de red, específicamente tráfico Ethernet sobre redes IP utilizando encapsulamiento MAC-in-UDP. Fue concebido originalmente para proveer los mismos servicios que una red VLAN tradicional, pero aumentando la capacidad de extensibilidad y la flexibilidad limitadas de estas. Se encuentra estandarizado por el IETF en el RFC 7348(IETF, 2014), y está en estado Informativo.

Q-in-Q: formalizado como IEEE 802.1ad(IEEE, n.d.), es un estándar de redes Ethernet que se incorporó en 2011 al estándar IEEE 802.1Q de 1998. También se la conoce como puente de proveedores, o VLAN apiladas. La especificación 802.1Q original permite insertar un solo encabezado VLAN en una trama Ethernet, pero QinQ permite insertar múltiples etiquetas VLAN en una sola trama, lo que les permite implementar topologías de red tipo Metro Ethernet. Generalmente se habla de «etiqueta VLAN» para referirse al encabezado VLAN 802.1Q de forma simplificada. QinQ permite múltiples etiquetas VLAN en una trama Ethernet, que en conjunto constituyen una pila de etiquetas. Cuando se utiliza en el contexto de una trama Ethernet, una trama QinQ es una trama que tiene 2 encabezados VLAN 802.1Q (con doble etiqueta).

IoT (Internet of Things): las tecnologías de red respaldan IoT tienen que abordar los desafíos de cobertura (espacios interiores y exteriores) escalabilidad y diversidad (capacidad de satisfacer demandas crecientes y variables) y confiabilidad (superando el modelo del mejor esfuerzo). Otra cuestión importante corresponde a la seguridad, que junto con la autonomía son los principales desafíos de IoT. En cuanto a la conectividad, existen tecnologías de corto y de largo alcance.(Garcia et al., 2018) Otro análisis importante corresponde al entorno típico en el que se utilizan los dispositivos IoT(Sivanathan, 2020). Así, se definen los siguientes como los principales ámbitos de uso, y se analizan los tamaños típicos de las redes, el tipo de tráfico, y los desafíos principales: viviendas y edificios inteligentes, atención sanitaria inteligente, entornos inteligentes, ciudades inteligentes, energía inteligente, transporte y movilidad inteligentes, Manufactura y comercio minorista inteligente, y agricultura inteligente.

Desarrollo

En el contexto de este proyecto se toma como caso de estudio el de un proveedor de servicios de internet (ISP) con las siguientes premisas:

  • Cuenta con una red ya desplegada y entrega servicios GPON a través de su red de fibra óptica.
  • Es el dueño de la infraestructura de red y de los equipos de acceso.
  • Ofrecerá servicios a un operador virtual (VNO) que desplegará una red IoT.

Basándonos en el esquema FANS, se utiliza un modelo mediante el cual la OLT será vinculada a dos diferentes proveedores de servicio de internet, contemplando que uno de ellos es considerado el dueño de la red y el otro es al cual se le arrendará la red para poder montar su red IoT. Nuestro modelo analizará el comportamiento de la red con respecto al proveedor de IoT en lo que respecta a servicios. Es importante tener en cuenta que en este análisis no se tendrán en cuenta las cuestiones externas a la red en caso de cursar tráfico inalámbrico por fuera de la red GPON, lo que abarca la sincronización de las antenas, las metodologías de modulación, alcances, o ancho de banda. De esta manera, el análisis estará enfocado a la prueba del servicio de cliente final, sin considerar las diferentes problemáticas intrínsecas del resto del sistema.

El estudio está enfocado en el análisis de la latencia de los diferentes modelos presentados en el Broadband Forum en los esquemas de FANS. Para el armado de los diferentes escenarios se diseñaron tres maquetas que corresponden a los esquemas que se presentan a continuación, para la simulación y análisis cada escenario (Q-in-Q, VXLAN, y MPLS). Se describen además de forma general los diferentes dispositivos que forman parte de cada maqueta, así como también su función básica y características.

Figura 1: Maqueta para modelo Q-in-Q

Figura 2: Maqueta para modelo VxLAN

Figura 3: Maqueta para modelo MPLS

Los tipos de dispositivos que se utilizan en estos esquemas se detallan a continuación. Vale destacar que las marcas y modelos de los equipos se omiten por cuestiones de confidencialidad. No obstante, la información se encuentra a disposición.

  • Generador de tráfico: encargados de simular un tipo de tráfico de Internet para las ONT 1 a 5, correspondiente a un tráfico de 100 Mbps bidireccionales. Para poder dar tráfico a las 5 ONT se utilizará la función generación de tráfico y monitoreo, y se producirán cinco (5) flujos de datos independientes con distinta IP de origen y de destino. De esta manera cada ONT podrá contar con su propio tráfico bidireccional independiente de los otros.
  • Switch Concentrador y Distribuidor de Servicios: se colocará un switch entre las ONT y el generador de tráfico de manera que se puedan dividir los múltiples flujos que salen del generador. Los generadores de tráfico tienen un solo puerto por donde salen los 5 flujos, por lo que el switch se coloca para realizar la división de dichos tráficos.
  • ONT 1 a 5: las ONT 1 a la 5 cumplirán la función de ONT para los servicios de Internet del proveedor de la infraestructura de red. El objetivo de este es simular clientes de internet por lo que se les inyectará tráfico de datos de 100Mbps.
  • ONT 6: La ONT 6 será la ONT del VNO que tiene los servicios a simular, en la misma se va a inyectar tráfico de distinto tipo y rampas con el objetivo de ver diferencias en lo que a la red de acceso respecta.
  • OLT: La OLT tendrá la capacidad de realizar la sincronización con las diferentes ONT y pasar el tráfico a través de ella. A sí mismo será la encargada de utilizar los diferentes protocolos planteados en el Broadband Forum. Dentro de las capacidades va a tener que soportar los protocolos Q-in-Q, VXLAN y MPLS.
  • Equipos Agregadores: Los equipos agregadores tienen como objetivo simular los equipos concentradores de acceso de cada VNO. Estos equipos tendrán la capacidad de recibir el tráfico de múltiples OLT y centralizarlo en un solo puerto para el núcleo (core) de la red.
  • Equipo Core: Los equipos de core simularán ser un equipo de borde en la red, en ese punto finalizará los protocolos Q-in-Q, VXLAN y MPLS para cada una de las maquetas. En el otro extremo será la vinculación con los generadores de tráfico para terminar los vínculos.

Los routers pueden clasificarse según su ubicación respecto al sistema total, y con ese criterio se cuenta con: routers de Borde de proveedor o PE (Provider Edge Router), routers de Proveedor o P (Provider Router) y routers de Borde del Cliente o CE (Customer Edge Router).

Simulación de tráfico

Debido a que los sistemas de telecomunicaciones están compuestos por muchos componentes diferentes que interactúan en complejas interrelaciones, su análisis requiere del modelado de cada componente o bien de las relaciones entre los mismos. La simulación es un enfoque que permite modelar sistemas estocásticos grandes y complejos con fines de pronóstico o medición del rendimiento, y es la técnica de modelado cuantitativo más comúnmente utilizada. La selección de la simulación como herramienta de modelado suele deberse a que es menos restrictiva, ya que otras técnicas de modelado pueden imponer restricciones matemáticas materiales al proceso y también requieren múltiples suposiciones intrínsecas(Barceló, 2010). En este estudio se simula solamente el tráfico, no así los dispositivos de red, ya que las maquetas se arman con equipos físicos reales. En los casos en que los estudios fueran completamente simulados, se realizaría el modelado del sistema como proceso estocástico dinámico.

El tráfico corresponde a la cantidad de datos que se mueven a través de una red en un momento dado. Los datos en redes informáticas se encapsulan principalmente en paquetes que proporcionan la carga. El tráfico de red es el componente principal para la medición, el control y la simulación de redes. El control de tráfico implica gestionar, priorizar, controlar o reducir el tráfico de red. La medición del tráfico implica medir la cantidad y el tipo de tráfico en una red en particular. La simulación de tráfico implica medir la eficiencia de una red, para lo cual se requiere un modelo de generación, que es un modelo estocástico de los flujos de tráfico o fuentes de datos.

A fin de realizar las pruebas necesarias, se propone la generación de un tipo de tráfico compatible con el encontrado estadísticamente en redes de dispositivos IoT. Para esto, se utilizaron varios estudios previos de caracterización de tráfico IoT, pudiendo obtenerse así distintos perfiles de tráfico que lo representan adecuadamente.(Batista et al., 2018; Finley & Vesselkov, 2019) En estudios publicados(Sivanathan et al., 2017) se logró recopilar y sintetizar los rastros de tráfico de un entorno de campus inteligente equipado con una diversidad de dispositivos de IoT que incluyen cámaras, luces, electrodomésticos y monitores de salud. A partir de esto, se analizó el tráfico para caracterizar atributos estadísticos como tasas de datos y ráfagas, ciclos de actividad y patrones de señalización, para más de 20 dispositivos IoT, y utilizando estos atributos se desarrolló un método de clasificación que puede distinguir el tráfico de IoT del tráfico que no es de IoT, así como también identificar dispositivos de IoT específicos con más del 95% de precisión. Los datos de captura de tráfico se han puesto a disposición pública.

Los parámetros analizados fueron: Sleep time (seg), Volumen activo (B), Promedio Tamaño del paquete (B), Tasa media (Bps), Tasa pico/media, Tiempo activo (seg), No. de servidores, No. de Protocolos, DNS request único, Intervalo de DNS (seg) e Intervalo NTP (seg). En este estudio, el tamaño de los logs diarios varía entre 61 MB y 2 GB, con un promedio de 365 MB. También en estudios previos se estimó que la cantidad de tráfico generado por un solo dispositivo M2M probablemente sea pequeña, pero el tráfico total generado por cientos o miles de dispositivos M2M sería sustancial(Elmangoush et al., 2015). De esta forma, se espera que una aplicación de monitorización remota de pacientes genere aproximadamente 0,35 MB por día y medidores inteligentes aproximadamente 0,07 MB por día. Para este análisis, consideraremos este estudio para tomar un patrón de tráfico, que se llevará al nivel de tráfico de una red de gran capacidad. Es decir, tomando un máximo teórico de 1 Gb/s, que permitiría transportar 86.400 Gb por día, lo que equivale al tráfico de más de 240 millones de dispositivos para el peor caso, correspondiente a un dispositivo que genera una gran cantidad de datos (0,35 MB diarios).

Para la realización de las pruebas se consideran los siguientes pasos:

  • Armado de la maqueta: Esto se realizó en los laboratorios de la empresa IPLAN Networks, la cual proveyó el equipamiento necesario para realizar el estudio.
  • Configuración de protocolos: Luego de conectada la maqueta, se realiza la configuración de los protocolos de red correspondientes según cada configuración esperada en función de los 3 modelos de FANS a ser analizados (QinQ, VxLAN, MPLS). Las configuraciones se encuentran a disposición.
  • Conexión de los generadores de tráfico: Se realiza la conexión de los generadores en los extremos de la red, a fin de verificar su funcionamiento en base a los protocolos configurados anteriormente.
  • Configuración de parámetros: Para cada prueba se realiza la configuración de los parámetros constantes, como ser el tipo de tráfico, el protocolo, el tamaño de paquete, y la tasa de transmisión.
  • Medición de latencia: Manteniendo constante el tipo de protocolo, se realiza la medición de la variable a analizar (latencia) para cada configuración de tipo de tráfico, tamaño de paquete (64 y 1024 bytes) y tasa de transmisión. Para el caso del tamaño de paquete, el valor de mayor interés es el de 64 bytes con protocolo UDP, dado que es el menor que puede testearse, y corresponde al tipo de tráfico que más se asemeja con el tráfico de IoT.
  • Trazado de curvas: Con la información obtenida se levantan las curvas correspondientes a la latencia promedio (en microsegundos) en función de la tasa de transmisión (en Mbps).

Los pasos anteriormente mencionados se repiten para cada maqueta, y luego de realizada la totalidad de las pruebas se procede a hacer el análisis. Las pruebas se realizaron sobre cada una de las maquetas, correspondientes a cada uno de los tres modelos propuestos por FANS (anteriormente descritos). Para cada uno de ellos se consideraron 2 tipos de tráfico:

  • Tráfico continuo: el tipo más simple de técnica para el envío de datos a través de una red, y se basa en mantener una determinada tasa de información constante durante un período de tiempo definido. Desde el punto de vista del receptor tiene la ventaja de que es completamente predecible, lo cual permite una mejor eficiencia en la reserva de recursos destinados a su procesamiento. Este tipo de tráfico puede encontrarse en dispositivos IoT que mantengan algún tipo de conexión continua tipo latido (hertbeat) para monitoreo constante de algún parámetro(Akanksha, 2020).
  • Tráfico en ráfaga: implica el envío de un conjunto de datos que ocupan un ancho de banda relativamente alto durante un período de tiempo corto. En escenarios reales la transmisión en ráfagas puede ocurrir de forma no intencional (natural) en base al comportamiento requerido por el tipo de tráfico, como puede ser el caso de una descarga de datos de Internet, donde se experimenta brevemente velocidades más altas en función del ancho de banda asignado o disponible. También puede ocurrir naturalmente en una red donde la transmisión se interrumpe a intervalos por problemas ajenos a la red misma. Por otro lado, las transmisiones en ráfaga pueden darse de forma intencional, como por ejemplo ante la necesidad de envío de mensajes comprimidos a una velocidad de señalización de datos muy alta en un tiempo muy corto con un fin específico. Así, se permite la comunicación entre equipos y redes que operan a velocidades de señalización diferentes. En la práctica este tipo de tráfico se usa para verificar el tamaño de ráfaga comprometido (CBS, Committed Burst Size) y el tamaño de ráfaga en exceso (EBS, Excess Burst Size). Este tipo de tráfico es el que más comúnmente se espera encontrar en dispositivos IoT(Sivanathan, 2020).

A continuación, se presentan las mediciones realizadas en cada maqueta.

Maqueta 1: QinQ

Tasa (Mb)Trafico Continuo Latencia
promedio (us)
Packet 64 bytes
Trafico Continuo Latencia
promedio (us)
Packet 1024 bytes
Trafico Rafaga Latencia
promedio (us)
Packet 64 bytes
Trafico Rafaga Latencia
promedio (us)
Packet 1024 bytes
5382428383428
10337393338394
15315359316359
20302349302349
25294342295342
30288336289336
35284332284332
40281330281331
45279327279328
50277326278327
60277326277326
70278326278326
80278326279326
90280327280327
100280327281327
150288328289329
200297330298331
250307331308333
300311334313335
350314337316339
400318340321342
450323343325345
500325347328349
600334358338362
700346372351376
800362390369399
900388419405437
950404434436470

Tabla 1: Tráfico para QinQ

Figura 4: Trafico para Q-in-Q

Maqueta 2: VXLAN

Tasa (Mb)Trafico Continuo Latencia promedio (us)
Packet 64 bytes
Trafico Continuo Latencia
promedio (us)
Packet 1024 bytes
Trafico Rafaga Latencia
promedio (us)
Packet 64 bytes
Trafico Rafaga Latencia promedio (us)
Packet 1024 bytes
5377489355482
10330398311394
15311338290333
20298329278325
25291321271318
30285319266313
35282315263310
40280314260308
45278311258306
50277311258306
60279311258306
70280311259306
80281311260306
90282311260306
100283312261307
150287314264308
200291316271308
250295318279310
300298321284313
350303325287315
400307328291318
450309332293320
500312336297324
600319347306334
700332360315347
800348380337368
900375406369402
950389422391421

Tabla 2: Tráfico para VXLAN

Figura 5: Tráfico para VXLAN

Maqueta 3: MPLS

Tasa (Mb)Latencia
promedio (us)
Packet 64 bytes
Latencia
promedio (us)
Packet 1024 bytes
Latencia
promedio (us)
Packet 64 bytes
Latencia
promedio (us)
Packet 1024 bytes
5368401368401
10325398325398
15301363302363
20287350287351
25279343279344
30273337274338
35269333271334
40267331268332
45264327264328
50262326263326
60261325262325
70262325263326
80265325266326
90266326267327
100265326266326
150273327274329
200277328278330
250279330281332
300282333284335
350285336288338
400288339291342
450291343294345
500295346298350
600304359309363
700321373328379
800350396362404
900387426390447
950405445410484

Tabla 3: Tráfico para MPLS

Figura 6: Tráfico para MPLS

Análisis

Tal como se ha visto, en el contexto de cada maqueta, es natural realizar la comparación de pruebas entre distintos tamaños de paquete. No obstante, dado el interés particular en paquetes de 64 bytes, puede realizarse una comparación tomando como constante el tamaño del paquete y el modo del tráfico, y trazando las curvas correspondientes a cada maqueta, tal como se muestra a continuación. Asimismo, es de interés también destacar las diferencias encontradas en los resultados entre los tamaños de paquete mínimos analizados (64 bytes) y los máximos (1024 bytes) de lo cual puede deducirse la importancia relativa de cada modelo de FANS con relación al tipo de tráfico esperado.

Tráfico Continuo

Tasa (Mb)QinQ
64 bytes
VxLAN
64 bytes
MPLS
64 bytes
QinQ
1024 bytes
VxLAN
1024 bytes
MPLS
1024 bytes
5382377368428489401
10337330325393398398
15315311301359338363
20302298287349329350
25294291279342321343
30288285273336319337
35284282269332315333
40281280267330314331
45279278264327311327
50277277262326311326
60277279261326311325
70278280262326311325
80278281265326311325
90280282266327311326
100280283265327312326
150288287273328314327
200297291277330316328
250307295279331318330
300311298282334321333
350314303285337325336
400318307288340328339
450323309291343332343
500325312295347336346
600334319304358347359
700346332321372360373
800362348350390380396
900388375387419406426
950404389405434422445

Tabla 4: Comparativa tráfico continuo para paquetes de 64 y 1024 bytes

Figura 7: Comparativa tráfico continuo para paquetes de 64 bytes

Figura 8: Comparativa tráfico continuo para paquetes de 1024 bytes

Tráfico en Ráfaga

Tasa (Mb)QinQ
64 bytes
VxLAN
64 bytes
MPLS
64 bytes
QinQ
1024 bytes
VxLAN
1024 bytes
MPLS
1024 bytes
5383355368428482401
10338311325394394398
15316290302359333363
20302278287349325351
25295271279342318344
30289266274336313338
35284263271332310334
40281260268331308332
45279258264328306328
50278258263327306326
60277258262326306325
70278259263326306326
80279260266326306326
90280260267327306327
100281261266327307326
150289264274329308329
200298271278331308330
250308279281333310332
300313284284335313335
350316287288339315338
400321291291342318342
450325293294345320345
500328297298349324350
600338306309362334363
700351315328376347379
800369337362399368404
900405369390437402447
950436391410470421484

Tabla 5: Comparativa tráfico en ráfaga para paquetes de 64 y 1024 bytes

Figura 9: Comparativa tráfico en ráfaga para paquetes de 64 bytes

Figura 10: Comparativa tráfico en ráfaga para paquetes de 1024 bytes

Continuando con el análisis de los parámetros de interés específico, podemos realizar la comparativa entre los promedios de los tipos de tráfico continuo y ráfaga, dado que es el que mejor representa un escenario real de tráfico de IoT, por su funcionamiento general. Se replica la tabla por comodidad para el análisis, y se grafican solo los promedios de dichos tipos de tráfico para cada maqueta.

Tasa (Mb)QinQ
64 bytes Promedio
VxLAN
64 bytes Promedio
MPLS
64 bytes Promedio
5382.5366368
10337.5320.5325
15315.5300.5301.5
20302288287
25294.5281279
30288.5275.5273.5
35284272.5270
40281270267.5
45279268264
50277.5267.5262.5
60277268.5261.5
70278269.5262.5
80278.5270.5265.5
90280271266.5
100280.5272265.5
150288.5275.5273.5
200297.5281277.5
250307.5287280
300312291283
350315295286.5
400319.5299289.5
450324301292.5
500326.5304.5296.5
600336312.5306.5
700348.5323.5324.5
800365.5342.5356
900396.5372388.5
950420390407.5

Tabla 6: Comparativas de latencias promedio para paquetes de 64 y 1024 bytes

Figura 11: Comparativas de latencias promedio para paquetes de 64 bytes

Si suponemos un caso real basado en estudios y trabajos de referencia en el que se requiera transportar datos correspondientes a 100 millones de dispositivos IoT que generen un tráfico diario de 0.35 Mb (peor caso en estudios) sobre una red de fibra óptica gran capacidad, se estarían utilizando aproximadamente 400 Mbps, que en el caso del modelo FANS menos eficiente, correspondería a un valor de latencia de 320 microsegundos.

Conclusiones

Luego de analizar los resultados de las pruebas sobre cada una de las maquetas tomando distintos tipos de tráfico y diferentes tamaños de paquete, podemos comprobar tal como es de esperarse por la teoría que, a menor tamaño de paquete, la latencia toma valores menores. Esto se repite para todas las maquetas y para todos los modos de tráfico de entrada. Otra cuestión que se logra comprobar de las que puede esperarse en base al análisis teórico es que a medida que aumenta el tamaño del paquete, menores son las diferencias en la latencia entre esquemas. Esto es debido al tamaño relativo entre el dato y el encabezado, que en paquetes menores afecta de forma más pronunciada.

En cuanto a las diferencias entre maquetas, se realizó un análisis de las conclusiones basándonos en diferentes puntos importantes para la implementación de un esquema FANS: la eficiencia observada en los resultados de las maquetas, la compatibilidad de los equipos para los diferentes protocolos, la dificultad en la configuración y operación, y la penetración de cada tecnología en el mercado actual. El resumen de estas conclusiones puede verse en la tabla a continuación:

EficienciaCompatibilidad entre proveedores de equipamientoConfiguración y operaciónPenetración en el mercado
Q in QBuenaSimpleSimpleAlto
VXLANMuy BuenaComplejaComplejoBajo
MPLSExcelenteSimpleComplejoMedio

Tabla 7: Resumen de conclusiones para cada maqueta

En cuanto a la eficiencia de las maquetas podemos decir que no se vio un delta de latencia significativo en las diferentes topologías, sin embargo, en el análisis de tráfico de 64 bytes (el más adecuado para esquemas IoT) podemos ver que el esquema de MPLS es el que mejor respuesta tiene. Esto se debe a que se utilizan menos equipos en la maqueta generando una menor latencia. El de VXLAN, más allá de lo esperado, tuvo una respuesta muy buena en términos de latencia. Por último, el esquema de Q-in-Q es el que peor respuesta dio sin ser este un delta lo suficientemente grande.

En términos de la compatibilidad entre proveedores para el uso de protocolo podemos decir que Q-in-Q y MPLS representan una complejidad sencilla de compatibilidad debido a que la utilización de VLAN en Q-in-Q y de MPLS y BGP en la maqueta de MPLS son protocolos altamente implementados en el mercado y la compatibilidad ya está dada. En cambio, y de la experiencia de la realización de las maquetas, podemos marcar que el esquema de VXLAN representa un desafío en lo que respecta a compatibilidad entre proveedores.

En relación a la configuración y operación de las diferentes topologías, podemos decir que el esquema de Q-in-Q es el más simple entre los diferentes VNO, solo tendrán que coordinar entre ellos que número de VLAN será la que se utilice como frontera. En cambio, en la configuración de VXLAN se tendrá que coordinar la forma de implementar la solución, VTEP a utilizar, forma de configuración (capa 2 o capa 3) siendo mucho más complejo. La configuración de MPLS de igual manera representará una complejidad grande entre ambos proveedores, se deberá coordinar la publicación de las diferentes redes, las direcciones IP de los diferentes vínculos de MPLS, lo cual generará a futuro problemas en altas de servicios y en la operación de los vínculos.

Por último, según la penetración en el mercado de las diferentes configuraciones, para poder un esquema de FANS se debe tener una coordinación entre proveedores en la manera en la que se configurarán los equipos. Cabe mencionar que los proveedores en la actualidad tienen base instalada con tipos de configuraciones específicas, por lo cual cambiarlas para la implementación de una solución requeriría cambios significativos en su red. Esto obedece además a la forma en el que mercado se fue desarrollando históricamente, y a cómo los distintos estándares fueron apareciendo en escena. Hoy en día, por su simplicidad en términos de configuración el esquema más adoptado en el mercado es el de Q-in-Q, seguido por el esquema de MPLS en algunos casos (la OLT en este caso se encuentra en capa 3). Sin embargo, el esquema de VXLAN más allá de encontrarse en el estándar no es un esquema muy utilizado por los proveedores de servicios de internet siendo esto un problema importante para implementar una topología de FANS.

Asimismo, y como última conclusión, se puede comprobar que el uso de las diferentes topologías de FANS en el contexto de redes 5G (sin considerar los posibles efectos del sincronismo y la tecnología en sí) es adecuado en todos los casos, siempre y cuando se haya realizado un correcto dimensionamiento según la necesidad. En el caso de MMC, el uso es adecuado si se mantiene la red en el orden de las decenas de millones de dispositivos. En el caso de eMMB, el uso es adecuado considerando las necesidades específicas y bien dimensionadas. Finalmente, en el caso de URLLC, dado que se obtienen en todos los casos valores de latencia menores a 1 ms, puede considerarse a priori adecuadas para su uso, aunque se requieren análisis más específicos para determinarlo. Esto permite verificar que en el futuro las tecnologías de FANS se utilicen como base para el transporte de datos de redes 5G en todos sus usos.

Agradecimientos

Este trabajo fue posible gracias al apoyo brindado por la empresa IPLAN Networks, quien proveyó los equipos e instrumentos de laboratorio que permitieron realizar las maquetas aquí presentadas.

REFERENCIAS

Akanksha, E. (2020). Framework for propagating stress control message using heartbeat based IoT remote monitoring analytics. International Journal of Electrical and Computer Engineering, 10(5), 4615–4622. https://doi.org/10.11591/ijece.v10i5.pp4615-4622

Barceló, J. (2010). Models, traffic models, simulation, and traffic simulation. In International Series in Operations Research and Management Science (Vol. 145). https://doi.org/10.1007/978-1-4419-6142-6_1

Batista, E., Andrade, L., Dias, R., Andrade, A., Figueiredo, G., & Prazeres, C. (2018). Characterization and modeling of IoT data traffic in the fog of things paradigm. NCA 2018 – 2018 IEEE 17th International Symposium on Network Computing and Applications. https://doi.org/10.1109/NCA.2018.8548340

Council, F., & Alliance, G. (2015). FTTH Council Global Alliance – FCGA FTTH Council – Definition of Terms. February, 1–8.

Elmangoush, A., Corici, A. A., Steinke, R., Corici, M., & Magedanz, T. (2015). A framework for handling heterogeneous M2M traffic. Procedia Computer Science, 63. https://doi.org/10.1016/j.procs.2015.08.319

Finley, B., & Vesselkov, A. (2019). Cellular iot traffic characterization and evolution. IEEE 5th World Forum on Internet of Things, WF-IoT 2019 – Conference Proceedings. https://doi.org/10.1109/WF-IoT.2019.8767323

Garcia, L., Jiménez, J. M., Taha, M., & Lloret, J. (2018). Wireless Technologies for IoT in Smart Cities. Network Protocols and Algorithms, 10(1), 23. https://doi.org/10.5296/npa.v10i1.12798

IEEE. (n.d.). IEEE 802.1ad-2005. https://standards.ieee.org/standard/802_1Q-2011.html

IETF. (2001). RFC 3031 – Multiprotocol Label Switching Architecture.

IETF. (2014). RFC 7348 – Virtual eXtensible Local Area Network (VXLAN). https://doi.org/10.17487/rfc7348

ITU-R. (2015). IMT Vision – Framework and overall objectives of the future development of IMT for 2020 and beyond. Itu-R M.2083-0, 0, https://www.itu.int/dms_pubrec/itu-r/rec/m/R-REC-M.

ITU-T. (2008). G.984.1. 1(2008).

Otelco. (n.d.). Lightwave Fiber Infrastructure. Where, when, why, and how. https://www.otelco.com/fiber-infrastructure/

Sivanathan, A. (2020). IoT behavioral monitoring via network traffic analysis. ArXiv, September.

Sivanathan, A., Sherratt, D., Gharakheili, H. H., Radford, A., Wijenayake, C., Vishwanath, A., & Sivaraman, V. (2017). Characterizing and classifying IoT traffic in smart cities and campuses. 2017 IEEE Conference on Computer Communications Workshops, INFOCOM WKSHPS 2017, 559–564. https://doi.org/10.1109/INFCOMW.2017.8116438

The Broadband Forum. (n.d.). MR-453 – Fixed Access Network Sharing (FANS).

The Broadband Forum. (2017). TR-370 Fixed Access Network Sharing – Architecture and Nodal Requirements. November, 1–78.

Autores:

ISSN 1666-6933

DOI:https://doi.org/10.33414/rtyc.41.34-56.2021

Federico Pacheco
federico.pacheco@gmail.com
Facultad Regional Buenos Aires (FRBA), Universidad Tecnológica Nacional (UTN) – Argentina

Guido Priano
gpriano@gmail.com
Facultad Regional Buenos Aires (FRBA), Universidad Tecnológica Nacional (UTN) – Argentina

A %d blogueros les gusta esto: