Análisis de latencia en modelos FANS para servicios IoT
Latency analysis in FANS model for IoT services
Presentación: 22/05/2021
Aprobación: 10/06/2021
Guido Priano
Facultad Regional Buenos Aires (FRBA), Universidad Tecnológica Nacional (UTN) - Argentina
gpriano@gmail.com
Federico Pacheco
Facultad Regional Buenos Aires (FRBA), Universidad Tecnológica Nacional (UTN) - Argentina
federico.pacheco@gmail.com
Resumen
El presente trabajo plantea la creación de un escenario real de operación de una red de fibra óptica conformada en base al estándar FANS (Fixed Access Network Sharing) de Broadband Forum, en la que se simule el manejo de un tráfico modelo correspondiente a dispositivos IoT. Para esto se propone la realización de distintas maquetas que representen el modo de funcionamiento de una arquitectura FANS manejando las condiciones de tráfico correspondientes, de forma que se puedan extraer conclusiones sobre la latencia, que es el parámetro de mayor importancia considerado por la industria en contextos de uso sobre redes 5G que se interconecten por medio de redes de fibra óptica. El objetivo del estudio es determinar si alguno de los modelos del estándar podría ofrecer ventajas ante escenarios de redes compuestas por dispositivos IoT que sean sensibles a la latencia.
Palabras clave: Latencia; FANS; GPON; IoT
Abstract
This work proposes the creation of a real operating scenario of a fiber optic network based on the FANS (Fixed Access Network Sharing) standard of Broadband Forum, in which the handling of a model traffic corresponding to IoT devices is simulated. For this, it is proposed to make different models that represent the operating mode of a FANS architecture managing the corresponding traffic conditions, so that conclusions can be drawn about latency, which is the most important parameter considered by the industry in contexts for use on 5G networks that are interconnected through fiber optic networks. The objective of the study is to determine if any of the models of the standard could offer advantages in scenarios of networks composed of IoT devices that are sensitive to latency.
Keywords: Latency; FANS; GPON; IoT
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 |
Trafico Continuo Latencia |
Trafico Rafaga Latencia |
Trafico Rafaga Latencia |
|
5 |
382 |
428 |
383 |
428 |
|
10 |
337 |
393 |
338 |
394 |
|
15 |
315 |
359 |
316 |
359 |
|
20 |
302 |
349 |
302 |
349 |
|
25 |
294 |
342 |
295 |
342 |
|
30 |
288 |
336 |
289 |
336 |
|
35 |
284 |
332 |
284 |
332 |
|
40 |
281 |
330 |
281 |
331 |
|
45 |
279 |
327 |
279 |
328 |
|
50 |
277 |
326 |
278 |
327 |
|
60 |
277 |
326 |
277 |
326 |
|
70 |
278 |
326 |
278 |
326 |
|
80 |
278 |
326 |
279 |
326 |
|
90 |
280 |
327 |
280 |
327 |
|
100 |
280 |
327 |
281 |
327 |
|
150 |
288 |
328 |
289 |
329 |
|
200 |
297 |
330 |
298 |
331 |
|
250 |
307 |
331 |
308 |
333 |
|
300 |
311 |
334 |
313 |
335 |
|
350 |
314 |
337 |
316 |
339 |
|
400 |
318 |
340 |
321 |
342 |
|
450 |
323 |
343 |
325 |
345 |
|
500 |
325 |
347 |
328 |
349 |
|
600 |
334 |
358 |
338 |
362 |
|
700 |
346 |
372 |
351 |
376 |
|
800 |
362 |
390 |
369 |
399 |
|
900 |
388 |
419 |
405 |
437 |
|
950 |
404 |
434 |
436 |
470 |
Tabla 1: Tráfico para QinQ
Figura 4: Trafico para Q-in-Q
Maqueta 2: VXLAN
|
Tasa (Mb) |
Trafico Continuo Latencia promedio (us) |
Trafico Continuo Latencia |
Trafico Rafaga Latencia |
Trafico Rafaga Latencia promedio (us) |
|
5 |
377 |
489 |
355 |
482 |
|
10 |
330 |
398 |
311 |
394 |
|
15 |
311 |
338 |
290 |
333 |
|
20 |
298 |
329 |
278 |
325 |
|
25 |
291 |
321 |
271 |
318 |
|
30 |
285 |
319 |
266 |
313 |
|
35 |
282 |
315 |
263 |
310 |
|
40 |
280 |
314 |
260 |
308 |
|
45 |
278 |
311 |
258 |
306 |
|
50 |
277 |
311 |
258 |
306 |
|
60 |
279 |
311 |
258 |
306 |
|
70 |
280 |
311 |
259 |
306 |
|
80 |
281 |
311 |
260 |
306 |
|
90 |
282 |
311 |
260 |
306 |
|
100 |
283 |
312 |
261 |
307 |
|
150 |
287 |
314 |
264 |
308 |
|
200 |
291 |
316 |
271 |
308 |
|
250 |
295 |
318 |
279 |
310 |
|
300 |
298 |
321 |
284 |
313 |
|
350 |
303 |
325 |
287 |
315 |
|
400 |
307 |
328 |
291 |
318 |
|
450 |
309 |
332 |
293 |
320 |
|
500 |
312 |
336 |
297 |
324 |
|
600 |
319 |
347 |
306 |
334 |
|
700 |
332 |
360 |
315 |
347 |
|
800 |
348 |
380 |
337 |
368 |
|
900 |
375 |
406 |
369 |
402 |
|
950 |
389 |
422 |
391 |
421 |
Tabla 2: Tráfico para VXLAN
Figura 5: Tráfico para VXLAN
Maqueta 3: MPLS
|
Tasa (Mb) |
Latencia |
Latencia |
Latencia |
Latencia |
|
5 |
368 |
401 |
368 |
401 |
|
10 |
325 |
398 |
325 |
398 |
|
15 |
301 |
363 |
302 |
363 |
|
20 |
287 |
350 |
287 |
351 |
|
25 |
279 |
343 |
279 |
344 |
|
30 |
273 |
337 |
274 |
338 |
|
35 |
269 |
333 |
271 |
334 |
|
40 |
267 |
331 |
268 |
332 |
|
45 |
264 |
327 |
264 |
328 |
|
50 |
262 |
326 |
263 |
326 |
|
60 |
261 |
325 |
262 |
325 |
|
70 |
262 |
325 |
263 |
326 |
|
80 |
265 |
325 |
266 |
326 |
|
90 |
266 |
326 |
267 |
327 |
|
100 |
265 |
326 |
266 |
326 |
|
150 |
273 |
327 |
274 |
329 |
|
200 |
277 |
328 |
278 |
330 |
|
250 |
279 |
330 |
281 |
332 |
|
300 |
282 |
333 |
284 |
335 |
|
350 |
285 |
336 |
288 |
338 |
|
400 |
288 |
339 |
291 |
342 |
|
450 |
291 |
343 |
294 |
345 |
|
500 |
295 |
346 |
298 |
350 |
|
600 |
304 |
359 |
309 |
363 |
|
700 |
321 |
373 |
328 |
379 |
|
800 |
350 |
396 |
362 |
404 |
|
900 |
387 |
426 |
390 |
447 |
|
950 |
405 |
445 |
410 |
484 |
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 |
VxLAN |
MPLS |
QinQ |
VxLAN |
MPLS |
|
5 |
382 |
377 |
368 |
428 |
489 |
401 |
|
10 |
337 |
330 |
325 |
393 |
398 |
398 |
|
15 |
315 |
311 |
301 |
359 |
338 |
363 |
|
20 |
302 |
298 |
287 |
349 |
329 |
350 |
|
25 |
294 |
291 |
279 |
342 |
321 |
343 |
|
30 |
288 |
285 |
273 |
336 |
319 |
337 |
|
35 |
284 |
282 |
269 |
332 |
315 |
333 |
|
40 |
281 |
280 |
267 |
330 |
314 |
331 |
|
45 |
279 |
278 |
264 |
327 |
311 |
327 |
|
50 |
277 |
277 |
262 |
326 |
311 |
326 |
|
60 |
277 |
279 |
261 |
326 |
311 |
325 |
|
70 |
278 |
280 |
262 |
326 |
311 |
325 |
|
80 |
278 |
281 |
265 |
326 |
311 |
325 |
|
90 |
280 |
282 |
266 |
327 |
311 |
326 |
|
100 |
280 |
283 |
265 |
327 |
312 |
326 |
|
150 |
288 |
287 |
273 |
328 |
314 |
327 |
|
200 |
297 |
291 |
277 |
330 |
316 |
328 |
|
250 |
307 |
295 |
279 |
331 |
318 |
330 |
|
300 |
311 |
298 |
282 |
334 |
321 |
333 |
|
350 |
314 |
303 |
285 |
337 |
325 |
336 |
|
400 |
318 |
307 |
288 |
340 |
328 |
339 |
|
450 |
323 |
309 |
291 |
343 |
332 |
343 |
|
500 |
325 |
312 |
295 |
347 |
336 |
346 |
|
600 |
334 |
319 |
304 |
358 |
347 |
359 |
|
700 |
346 |
332 |
321 |
372 |
360 |
373 |
|
800 |
362 |
348 |
350 |
390 |
380 |
396 |
|
900 |
388 |
375 |
387 |
419 |
406 |
426 |
|
950 |
404 |
389 |
405 |
434 |
422 |
445 |
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 |
VxLAN |
MPLS |
QinQ |
VxLAN |
MPLS |
|
5 |
383 |
355 |
368 |
428 |
482 |
401 |
|
10 |
338 |
311 |
325 |
394 |
394 |
398 |
|
15 |
316 |
290 |
302 |
359 |
333 |
363 |
|
20 |
302 |
278 |
287 |
349 |
325 |
351 |
|
25 |
295 |
271 |
279 |
342 |
318 |
344 |
|
30 |
289 |
266 |
274 |
336 |
313 |
338 |
|
35 |
284 |
263 |
271 |
332 |
310 |
334 |
|
40 |
281 |
260 |
268 |
331 |
308 |
332 |
|
45 |
279 |
258 |
264 |
328 |
306 |
328 |
|
50 |
278 |
258 |
263 |
327 |
306 |
326 |
|
60 |
277 |
258 |
262 |
326 |
306 |
325 |
|
70 |
278 |
259 |
263 |
326 |
306 |
326 |
|
80 |
279 |
260 |
266 |
326 |
306 |
326 |
|
90 |
280 |
260 |
267 |
327 |
306 |
327 |
|
100 |
281 |
261 |
266 |
327 |
307 |
326 |
|
150 |
289 |
264 |
274 |
329 |
308 |
329 |
|
200 |
298 |
271 |
278 |
331 |
308 |
330 |
|
250 |
308 |
279 |
281 |
333 |
310 |
332 |
|
300 |
313 |
284 |
284 |
335 |
313 |
335 |
|
350 |
316 |
287 |
288 |
339 |
315 |
338 |
|
400 |
321 |
291 |
291 |
342 |
318 |
342 |
|
450 |
325 |
293 |
294 |
345 |
320 |
345 |
|
500 |
328 |
297 |
298 |
349 |
324 |
350 |
|
600 |
338 |
306 |
309 |
362 |
334 |
363 |
|
700 |
351 |
315 |
328 |
376 |
347 |
379 |
|
800 |
369 |
337 |
362 |
399 |
368 |
404 |
|
900 |
405 |
369 |
390 |
437 |
402 |
447 |
|
950 |
436 |
391 |
410 |
470 |
421 |
484 |
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 |
VxLAN |
MPLS |
|
5 |
382.5 |
366 |
368 |
|
10 |
337.5 |
320.5 |
325 |
|
15 |
315.5 |
300.5 |
301.5 |
|
20 |
302 |
288 |
287 |
|
25 |
294.5 |
281 |
279 |
|
30 |
288.5 |
275.5 |
273.5 |
|
35 |
284 |
272.5 |
270 |
|
40 |
281 |
270 |
267.5 |
|
45 |
279 |
268 |
264 |
|
50 |
277.5 |
267.5 |
262.5 |
|
60 |
277 |
268.5 |
261.5 |
|
70 |
278 |
269.5 |
262.5 |
|
80 |
278.5 |
270.5 |
265.5 |
|
90 |
280 |
271 |
266.5 |
|
100 |
280.5 |
272 |
265.5 |
|
150 |
288.5 |
275.5 |
273.5 |
|
200 |
297.5 |
281 |
277.5 |
|
250 |
307.5 |
287 |
280 |
|
300 |
312 |
291 |
283 |
|
350 |
315 |
295 |
286.5 |
|
400 |
319.5 |
299 |
289.5 |
|
450 |
324 |
301 |
292.5 |
|
500 |
326.5 |
304.5 |
296.5 |
|
600 |
336 |
312.5 |
306.5 |
|
700 |
348.5 |
323.5 |
324.5 |
|
800 |
365.5 |
342.5 |
356 |
|
900 |
396.5 |
372 |
388.5 |
|
950 |
420 |
390 |
407.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:
|
Eficiencia |
Compatibilidad entre proveedores de equipamiento |
Configuración y operación |
Penetración en el mercado |
|
|
Q in Q |
Buena |
Simple |
Simple |
Alto |
|
VXLAN |
Muy Buena |
Compleja |
Complejo |
Bajo |
|
MPLS |
Excelente |
Simple |
Complejo |
Medio |
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.