Clasificación de fuentes de tráfico HTC y MTC

Clasificación de fuentes de tráfico HTC (Human Type Communication) y MTC (Machine Type Communication) Autor: Moamin Mhanna Director: Dr. Miguel Angel Rodríguez Hernández Fecha de comienzo: 01/02/2015 Lugar de trabajo: Laboratorio GIRBA, E.T.S.I. de Telecomunicaciones 1 Clasificación de fuentes de tráfico HTC y MTC Objetivos — El objetivo principal de este trabajo es realizar una clasificación y descripción de las principales propiedades de las distintas fuentes de tráfico que aparecen involucradas en los sistemas de comunicaciones actuales según los parámetros del tráfico generado y sus comportamientos, mediante búsqueda bibliografía. Teniendo en cuenta dos grandes categorías: fuentes HTC (Human Type Communications) comunicaciones humanohumano y fuentes MTC (Machine Type Communications) donde interviene una máquina para comunicaciones con requerimientos heterogéneos como alarmas, sensores, etc. Se pretende que este trabajo sea una guía para futuros investigadores, donde estas clasificaciones faciliten estudiar y gestionar en un entorno simulado el comportamiento de las fuentes de tráfico para identificar los mecanismos de diseño de la red para garantizar una calidad de servicio y el consumo en ancho de banda de una red. Metodología —  Revisión de artículos y libros ofrecidos de diferentes autores sobre las características y el comportamiento de diferentes tipos de fuentes de tráfico en diferentes redes.  Identifición de los parámetros de interés (tiempo entre llegadas, tamaño de paquete, tasa de datos, etc.) y de las distribuciones (lognormal, weibull, exponencial, etc.) que definen los patrones del comportamiento de las fuentes de tráfico  Agrupación cada tipo de fuente según los parámetros del tráfico generado y su comportamiento, en dos tipos de fuentes HTC y MTC. Desarrollos teóricos realizados — El desarrollo teórico realizado consiste en una clasificación de los distintos tipos de fuentes de tráfico, considerando en la clasificación los diferentes parámetros que caracterizan estas fuentes. Cada fuente según los parámetros del tráfico generado y su comportamiento en la red. Desarrollo de prototipos y trabajo de laboratorio — El trabajo consiste en clasificar las fuentes de tráfico a nivel teórico y no tiene trabajo de laboratorio. Resultados — El resultado principal del trabajo es una clasificación de las distintas fuentes de tráfico utilizados en entornos HTC y MTC. Como resultados hemos clasificado, las fuentes de voz, video y datos para HTC, donde las fuentes de datos contienen tres tipos de fuentes (www, FTP (File Transfer Protocol), online gaming). Mientras que otros cuatro tipos de fuentes de tráfico para MTC, que son, sensores de medición, juegos M2M, automóviles y rastreo de equipos. 2 Clasificación de fuentes de tráfico HTC y MTC Líneas futuras — En este trabajo hemos clasificados diferentes tipos de fuentes de tráfico según las investigaciones realizadas actualmente sobre estas fuentes y su comportamiento para las dos tipos (HTC y MTC), en las fuentes MTC existen diferentes tipos de fuentes de tráfico que no se han estudiado sus comportamiento hasta el momento. En el futuro se puede a realizar un trabajo que complete la investigación y clasificación de los diferentes tipos de fuentes de tráfico mediante la simulación de los modelos aquí presentados. Publicaciones — De momento no hay publicación. Abstract — The generated traffic by the new communications networks like NGN (Next Generation Network) is heterogeneous traffic, where those networks are considered as common infrastructure for different networks and services. The problem is that the different services have different characteristics and network requirements. Therefore the different types of traffic sources must be identified and characterized, to be able to introduce mechanisms of traffic management in the network, to ensure the required quality of service for each service. In this work we show a classification of several types of traffic sources which appear in the actual communications systems under two main groups, Human Type Communication (HTC) and Machine Type Communication (MTC). The traffic patterns distribution type, interarrival time, packet size, data rate and other parameters of traffic are considered in the classification. As a result, from our classification, voice, video and data sources are classified for HTC, while other four type of traffic sources for MTC, namely, measuring sensors, automotive, M2M games and team tracking. Autor: Moamin Mhanna email: [email protected] Director: Dr. Rodríguez Hernández Miguel Angel email: [email protected]s Fecha de entrega: 05-09-15 3 Clasificación de fuentes de tráfico HTC y MTC ÍNDICE I. INTRODUCCION............................................................................................................4 II. HUMAN TYPE COMMUNICATION (HTC).............................................................5 II.1. Fuentes de voz...........................................................................................................5 II.2. Fuentes de video......................................................................................................11 II.3. Fuentes de datos.......................................................................................................16 II.3.1. Fuentes de tráfico “www”.............................................................................16 II.3.2. Fuentes de tráfico file transfer (FTP) ...........................................................17 II.3.3. Online gaming...............................................................................................18 II.3.3.1. First Person Shooter………………………………………………18 II.3.3.2. Online Racing Simulations……………………………………….19 II.3.3.3. Massive Multiplayer Online Role-Playing Game…………….…..21 III. MACHINE TYPE COMMUNICATION (MTC)………………………………….22 III.1. M2M: Visión general...…...…………………………………………………….22 III.1.1. M2M: Estándares........………………………………………………….22 III.1.2. M2M: Arquitectura y componentes……………………………….........22 III.1.3. M2M: Aplicaciones......................………………………………………23 III.1.4. Requisitos de servicio...............................................................................24 III.2. Modelos de tráfico MTC......................................................................................25 III.2.1. Modelo 3GPP...........................................................................................25 III.2.2. Modelo de fuente CMMPP......................................................................26 III.2.2.1. MMPP Básicos..........................................................................27 III.2.2.2. Acoplamiento Múltiple MMPP. .................…………...….......27 III.3. Clasificaciones de fuentes de tráfico MTC............................................................29 III.3.1. Sensores de medición.................................................................................32 III.3.2. Automoción.......................................…………………………………….34 III.3.3. Juegos M2M. .........................................………………………………....35 III.3.4. Rastreo de equipos.............................................………………………....36 IV. CONCLUSIONES.......................................................................................................38 V. AGRADECIMIENTOS................................................................................................39 VI. BIBLIOGRAFÍA.........................................................................................................40 4 Clasificación de fuentes de tráfico HTC y MTC I. INTRODUCCION. Las redes de multiservicio como NGN (Next Generation Network), representan una infraestructura común para diferentes redes y servicios, servicios tradicionales incluidos voz, datos y multimedia, además de nuevas redes y servicios, como MTC que incluyen dispositivos de control y monitorización, como sensores, redes industriales. El tráfico heterogéneo generado por estas redes ha tenido y tendrá aún dificultades técnicas que superar ya que los distintos servicios que se ofrecen tienen diferentes características y requerimientos de red. Un caso especialmente importante es el tráfico generado por las fuentes MTC cuya dificultad para la caracterización de su comportamiento en redes de comunicaciones es especialmente alto. Por ello hay que identificar las diferentes fuentes de tráfico y caracterizarlas para poder introducir en la red mecanismos de gestión de tráfico que garanticen a cada servicio la calidad de servicio necesaria recogida en las recomendaciones internacionales, este es el propósito del trabajo, identificar y clasificar las diferentes tipos de fuentes de tráfico, cada fuente según su características y su comportamiento teniendo en cuenta dos grupos: fuentes HTC, comunicaciones humano-humano y fuentes MTC, comunicaciones entre máquinas donde no es necesaria la interacción humana como sensores, video vigilancia, dispositivos inteligentes, etc. En el presente trabajo, nos interesa centrar la atención en este aspecto debido a la gran importancia que se le está dando en la comunidad científica y en particular en la gestión de tráfico donde esto ayuda para planificar, diseñar, proyectar, dimensionar, desarrollar y supervisar redes de telecomunicaciones para ofrecer un servicio confiable a un coste menor. El documento consiste en dos partes grandes: el primer parte, sección II HTC en el que se categorizan tres diferentes fuentes con intervención húmana: fuentes de voz “Subsec. II.1”, fuentes de video “Subsec. II.2” y fuentes de datos “Subsec. II.3”. La subsección II.3 a su vez contiene tres tipos de fuentes de datos (www, FTP, online gaming). En todas las secciones y subsecciones se definen las características y los parámetros para cada tipo de fuente. La segunda parte, sección III MTC trata de las comunicaciones entre máquinas sin intervención humana. En la subsección III.1 se muestra una visión general breve sobre MTC (estándares, arquitectura y componentes, aplicaciones y requisitos de servicio), en la subsección III.2 se describen algunos modelos de tráfico utilizados para estudiar el comportamiento del tráfico MTC, y al final de la segunda parte “Subsec. III.3” se incluyen clasificaciones de cuatro tipos de fuentes de tráfico MTC según la aplicación, sensores de medición “Subsec. III.3.1”, automoción “Subsec. III.3.2”, juegos M2M “Subsec. III.3.3” y rastreo de equipos “Subsec. III.3.4”. En estas subsecciones se definen las características y los patrones para los flujos de tráfico generado por estas aplicaciones. Por último en la sección IV se incluyen las conclusiones. 5 Clasificación de fuentes de tráfico HTC y MTC II. HUMAN TYPE COMMUNICATION (HTC). II.1. Fuentes de voz. Voz sobre IP (VOIP) es el más comúnmente utilizado en los servicios de voz, generalmente transportada como un flujo digital codificado usando RTP (Real-time Protocol) sobre UDP. Los factores clave que van a determinar el impacto que van a tener los factores de calidad que afectan al nivel del servicio, como retardo o pérdidas, están relacionadas con el tipo de códec utilizado para codificar la señal y también en la implementación del sistema final. El modelo de la fuente más utilizado es la fuente ON/OFF, el tráfico de voz a nivel de fuente se caracteriza por un período activo ON (speech activity o talk spurt) y un período de inactividad OFF (silencio). La duración del periodo ON y el periodo OFF presentan la distribución exponencial de conformidad con ITU-T P.59 con duración 61,47% y 22.48% respectivamente. La transmisión de paquetes de voz se produce sólo por la duración de los períodos de ON y las fuentes de tráfico se apagan durante los períodos OFF de una llamada VoIP, estas características se suelen considerar en los mecanismos de transmisión para mejorar las transmisiones y la eficiencia (por ejemplo con la supresión de silencios). Los códecs más utilizados son los estándares G.71x y G.72x, como G.711 o el estándar de la ley A es un códec que usa una modulación por pulsos (PCM), donde la señal analógica es muestreada en intervalos regulares para producir la señal digital, su ancho de banda 64kbps, tiene como Retardo máximo 0.375ms. Códecs más avanzados como G.726 que usa diferencial adaptativa PCM (ADPCM) tiene la misma calidad que G.711 pero con menos ancho de banda. Otros códecs como G.729 y G.723.1 que utilizan técnicas más complicadas como ACELP (Algebraic Code Excited Linear Prediction), G.729 necesita menos ancho de banda que G.711, G.726 y G.723.1 (8kbps) pero con un retardo mayor (35ms), G.723.1 comprime mucho más la voz (5.3kbps) pero tiene un retardo mayor que G.729 (97.3ms) [1]. En las fuentes de voz el tamaño del paquete y el tiempo entre llegadas depende del códec utilizado para la encapsulación de voz. Existen muchos estudios para estimar el tiempo entre llegadas y estudiar el comportamiento del tráfico de voz en una red mediante análisis estáticos, estos estudios para modelar fuentes de tráfico se basan en dos aspectos, estudiar el comportamiento de la fuente y encontrar un modelo estadístico adecuado para describir este comportamiento. Uno de estos estudios que utiliza la distribución gamma para representar diferentes fuentes de tráfico y analizar el patrón de estas fuentes [2], la distribución gamma es adaptable al tráfico en las conexiones y podría cubrir muchos casos especiales de tráfico en las redes oportunistas donde el tráfico es auto-similar con factor de peakedness alto y long-tails. La distribución gamma es una distribución de probabilidad continua se describe mediante un parámetro de forma k y un parámetro de escala ϴ ambos números reales positivos, la función de densidad de probabilidad es: 6 Clasificación de fuentes de tráfico HTC y MTC Γ (k, ϴ) = 1 Γ(𝑘)ϴ𝑘 𝑥𝑘−1 𝑒−𝑥 𝑦 (1) Donde Γ (k) es la función gamma, y la función de distribución acumulada de distribución gamma es: F(x; k, ϴ) = ∫𝑓(𝑢; 𝑥 0𝑘 ,ϴ)du = 𝛾(𝑘,𝑥 ϴ) Γ(𝑘) (2) Donde 𝛾(𝑘, 𝑥 ϴ) es La función gamma incompleta inferior, los parámetros de la distribución gamma, media, varianza que indica cómo las variables aleatorias se distribuyen alrededor de su valor medio, MSD (mean standard deviation) definiendo el intervalo de confianza, skewness como una medida de la simetría de la distribución y la cúrtosis como una medida de la forma de la distribución y sobre todo de la peakedness. La Tabla 1 [2], indica las fórmulas de los parámetros de la distribución gamma. Tabla 1. Los parámetros de la distribución gamma. La Tabla 2 [2], indica los parámetros estadísticos de 3 tipos de códecs (GSM 06.10, G.711, G.729) y la distribución utilizada, los datos medidos mediante una llamada de duración 1 minuto, las medidas están realizadas en la capa de paquete, la capa de sesión y de aplicación se eliminan como capa exterior (outlier). Para cada códec los datos están analizados en tres fases, con capa exterior en la segunda fase, Las capas exteriores se eliminan de los datos medidos. Debido a los datos en muchos casos tienen una cúrtosis alta, las capas exteriores que son más grandes que 60 ms son descartadas, se aplica la regla de tres sigma para las capas exteriores [-3σ, 3σ] donde σ es MSD. Después eliminar las capas exteriores, los datos medidos se ajustan a una distribución gamma, en la tercera fase los datos están simulados mediante dos herramientas estadísticas, CB (Crystal Ball) y WM (Wolfram Mathematica). Parámetro Fórmula Media E[X] = kϴ E[ln X] = ψ(k) + ln(ϴ), donde ψ(k) es la función digamma Varianza Var[X] = kϴ2 Var[ln X] = ψ1(𝑘), donde ψ1(𝑘) es es la función trigamma Skewness 2√𝑘 ⁄ Cúrtosis 6𝑘 ⁄ 7 Clasificación de fuentes de tráfico HTC y MTC GSM códec Media (ms) Varianza (ms) MSD (ms) skewness Cúrtosis Tipo de distribución del tiempo entre llegadas Con outlier 12.6 15.675 125.2 68 _ Distribución exponencial, λ=0.8, donde λ es la es tasa o parámetro de escala inversa Sin outlier 10.16 55.26 7.434 0.457 -0.48 Sin outlier WM 10.16 82.17 9.065 1.673 7.194 Distribución gamma, localización =0, forma =0.55, escala =18.17 Sin outlier CB 9.16 93.14 9.651 2.003 9.011 Distribución gamma, localización =0, forma =0.49, escala =20.39 G.711 codec Media (ms) Varianza (ms) MSD (ms) skewness Cúrtosis Distribution type of interarrival time Con outlier 22.7 235.125 485 50 _ Distribución gamma, forma =0.2292, escala =99.11 Sin outlier 10.23 52.482 7.244 0.026 -1.041 Sin outlier WM 10.23 116.69 10.89 2.019 9.109 Distribución gamma, localización =0, forma =0.354, escala =28.5 Sin outlier CB 8.233 42.122 6.49 1.422 6.024 Distribución gamma, localización =-47.53, forma=64.41, escala =0.89 G.729 codec Media (ms) Varianza (ms) MSD (ms) skewness Cúrtosis Distribution type of interarrival time Con outlier 12.2 14.417 120 57 _ Distribución lognormal, localización =-2.63, µ=10.02, σ =8.61 Sin outlier 9.714 41.85 6.469 0.46 -0.610 Sin outlier WM 9.714 50.8 7.127 132.7 5.632 Distribución gamma, localización =0, forma =1.06, escala =8.98 Sin outlier CB 8.714 84.66 9.201 2.003 9.012 Distribución gamma, localización =-0.9, forma =2.18, escala =4.79 Tabla 2. Las características estadísticas de los codecs de VoIP. Para códec GSM el tamaño del paquete es 90 bytes y la tasa del usuario 55 Kbps. La Figura 1 [2], es la función de densidad de probabilidad del tiempo entre llegadas con la capa exterior, la distribución es exponencial, la figura muestra que la mayoría de los paquetes están generados durante la transmisión activa (active speech transmission). La Figura 2 [2], es la función de densidad de 8 Clasificación de fuentes de tráfico HTC y MTC probabilidad del tiempo entre llegadas sin la capa exterior la distribución es gamma, el parámetro de localización de la distribución gamma muestra la posición relativa de la gráfica en la abscisa. Figura1. pdf de tiempo entre llegadas para GSM códec, Figura 2. pdf de tiempo entre llegadas para con outlier, distribución exponencial. GSM códec, sin outlier, distribución gamma. Para códec G.711 el tamaño del paquete es 230 bytes y la tasa del usuario 75 Kbps. La Figura 3 [2], es la función de densidad de probabilidad del tiempo entre llegadas con la capa exterior, la distribución es gamma, la figura muestra que la mayoría de los paquetes están concentrados en un intervalos pequeños durante la fase ON de la fuente ON/OFF. La Figura 4 [2], es la función de densidad de probabilidad del tiempo entre llegadas sin la capa exterior la distribución es gamma. Figura 3. pdf de tiempo entre llegadas para G.711 códec, Figura 4. pdf de tiempo entre llegadas para G.711 con outlier, distribución gamma. códec, sin outlier, distribución gamma. Para códec G.729 el tamaño del paquete es entre 60 y 80 bytes y la tasa del usuario 48 Kbps. La Figura 5 [2], es la función de densidad de probabilidad del tiempo entre llegadas con la capa exterior, la distribución es log-normal, la mayoría de los tiempos entre llegadas son cortos y corresponden a la transmisión activa, los parámetros de la distribución lognormal son µ y σ, donde µ es la media y σ es la desviación estándar. La Figura 6 [2], es la función de densidad de probabilidad del tiempo entre llegadas sin la capa exterior la distribución es gamma. 15 Clasificación de fuentes de tráfico HTC y MTC Figura 10. Pdf de tiempo entre llegadas para H.263 códec, Figura 11. Pdf de tiempo entre llegadas para con outlier, distribución exponencial. H.263 códec, sin outlier, distribución gamma. Para códec H.263+ el tamaño de los paquetes concentrado alrededor de 230 bytes con sólo algunos paquetes con tamaño 700 bytes y la tasa de la fuente 364 Kbps. La Figura 12 [2], es la función de densidad de probabilidad del tiempo entre llegadas con la capa exterior, la distribución es exponencial. La Figura 13 [2], es la función de densidad de probabilidad del tiempo entre llegadas sin la capa exterior la distribución es gamma. Figura 12. Pdf de tiempo entre llegadas para H.263+ códec, Figura 13. Pdf de tiempo entre llegadas para con outlier, distribución exponencial. H.263+ códec, sin outlier, distribución gamma. La diferencia entre H.264 low end y H.264 high end es el sistema operativo utilizado en la prueba y la capa de aplicación que es extremo bajo o alto, H.264 códec genera ráfagas con tiempo entre llegadas más pequeño que H.263 y H.263+. Para H.264 low end el tamaño de los paquetes es 230 bytes y la tasa de la fuente 498 Kbps y para H.264 high end el tamaño de los paquetes es 230 bytes y la tasa de la fuente 406 Kbps. Las Figuras 14 y 15 [2], son las funciones de densidad de probabilidad del tiempo entre llegadas con la capa exterior y sin la capa exterior respectivamente para H.264 low end, la distribución es gamma. Las Figura 16 y 17 [2], son las funciones de densidad de probabilidad del tiempo entre llegadas con la capa exterior con distribución exponencial y sin la capa exterior con distribución gamma respectivamente para H.264 high end. La diferencia entre los pdfs “Fig. 14”, “Fig. 16” es debido a los algoritmos de encapsulación de paquete aplicados en los códecs. 16 Clasificación de fuentes de tráfico HTC y MTC Figura 14. Pdf de tiempo entre llegadas para H.264 low end Figura 15. Pdf de tiempo entre llegadas para H.264 códec con outlier, distribución gamma low end códec, sin outlier, distribución gamma. Figura 16. Pdf de tiempo entre llegadas para H.264 high end Figura 17. Pdf de tiempo entre llegadas para H.264 códec con outlier, distribución exponencial. high end códec, sin outlier, distribución gamma. II.3. Fuentes de datos. Las fuentes de datos varían más sus características en comparación con el tráfico de voz y de vídeo y esto las hace más difíciles de soportar en la red debido a la previsibilidad baja de tráfico. Existen muchos tipos de fuentes de datos, en este trabajo vamos a clasificar tres tipos de fuentes de tráfico de datos, fuentes de tráfico “www”, FTP (File Transfer Protocol) y online gaming. II.3.1. Fuentes de tráfico “www”. La World Wide Web es una aplicación cliente-servidor, La mayoría de los estudios han indicado que el tráfico de Internet es la mayor porción del tráfico global del Internet. El tráfico "www" es autosimilar con el parámetro de Hurst H en el rango 0.7 – 0.9 [10]. El tráfico web puede ser caracterizado como una fuente ON/OFF con el period ON es heavy-tailed, los períodos ON representan las transmisiones activas del fichero web o el tiempo que los usuarios gastan descargar un fichero. El período OFF corresponde al tiempo entre dos descargas y dividido en OFF activo e inactivo, OFF activo cuando un usuario está leyendo el navegador Web pero no existe transmisión de datos, mientras que el OFF inactivo el usuario no está utilizando el navegador Web. La Tabla 7 [11], indica las características estadísticas de tráfico “www”, donde xmim y ϴ son los parámetros de localización 17 Clasificación de fuentes de tráfico HTC y MTC y forma de la distribución de Pareto, α y β son los parámetros de escala forma de la distribución de Weibull. Modelo Distribución Parámetros ON Pareto xmin = 1000 bytes, ϴ = 1.06 OFF activo Weibull α = 1.46, β= 0.382 OFF inactivo Pareto xmin = 1 s, ϴ = 1.5 Tabla 7. Las características estadísticas de tráfico www. II.3.2. Fuentes de tráfico file transfer (FTP). El tráfico FTP es auto-similar con el parámetro de Hurst H en el rango 0.85 – 0.95 [10]. El mismo estudio lo que hemos visto en las fuentes de voz y video [2], también estudió las características estadísticas del tiempo inter llegadas para para la aplicación ftp utilizando la distribución gamma donde su función de densidad de probabilidad y la función de distribución acumulada en las ecuaciones (1) y (2) respectivamente. La Tabla 8 [2], indica las características estadísticas de tráfico FTP medidos mediante una descarga de fichero de tamaño 2 MB, el tamaño del paquete varía entre 80 y 1500 bytes, y la tasa de transmisión es 140 Kbps. Los factores principales que dan forma al proceso de descarga son la sesión TCP y el tamaño de la ventana del protocolo TCP. FTP Media (ms) Varianza (ms) MSD (ms) skewness Cúrtosis Tipo de distribución del tiempo entre llegadas Con outlier 17 48232 220 39 - Distribución gamma, localización =0, forma =0.128, escala =417.97 Sin outlier 11.32 189.2 13.75 1.126 0.833 Sin outlier WM 11.33 639.5 25.29 4.426 32.38 Distribución gamma, localización =0, forma =0.17, escala =66.16 Sin outlier CB 5. 325 10.05 3.17 0.875 4.099 Distribución gamma, localización =0, forma =0.13, escala =83.58 Tabla 8. Las características estadísticas de tráfico FTP. 18 Clasificación de fuentes de tráfico HTC y MTC Es el comportamiento del protocolo TCP en conexión congestionada que importa más que el tamaño del fichero. Las Figuras 18 y 19 [2], son las funciones de densidad de probabilidad del tiempo entre llegadas con la capa exterior y sin la capa exterior respectivamente con distribución gamma. Figura 18. Pdf de tiempo entre llegadas para una Figura 19. Pdf de tiempo entre llegadas para una conexión FTP, con outlier, distribución gamma. conexión FTP sin outlier, distribución gamma. II.3.3. Online gaming. Hay diferentes tipos de juegos en línea de tiempo real, los tipos de juego más comunes son: First Person Shooter (FPS), Online Racing Simulations (ORS) y Massive Multiplayer Online RolePlaying Game (MMORPG), son juegos interactivos de alta velocidad. Existen muchos juegos de estos estilos, como Open Arena (FPS), Dirt2 (ORS), World of Warcraft (MMORPG). A continuación vamos a ver las características del tráfico generado por las tres tipos de estos juegos. II.3.3.1. First Person Shooter. Un ejemplo para FPS es el juego Open Arena. El tráfico de esta aplicación se encapsula en paquetes UDP para la transmisión de red y la aplicación él mismo se encarga de las pérdidas del paquete y la reordenación. Las Figuras 20 y 21 [12], representan la tasa de paquete y la tasa de datos de un equipo de cliente en un juego con otros 10 jugadores. La tasa de paquete muestra altos picos de más de 0,8 en el PDF empírica en un valor discreto para uplink y downlink, en la dirección downlink la tasa de paquetes es 24 /s y en la dirección uplink es tres veces más alta con 91 /s. 19 Clasificación de fuentes de tráfico HTC y MTC Figura 20. Tasa de paquete, Open Arena (1 jugador). Figura 21. Tasa de datos, Open Arena (1 jugador). Cuando comparamos la figura de la tasa de paquetes con la figura de la tasa de datos, la PDF empírica para la tasa de datos no muestra un pico claro en la dirección downlink “Fig. 21”, de este hecho, el tamaño del paquete en la dirección downlink tiene una gran dispersión entre 50 y 500 bytes “Fig. 22” [12], en la dirección uplink la tasa de datos es constante y el tamaño de paquete casi constante “Fig 23” [12]. Figure 22. Tamaño de paquete vs tiempo entre Figure 23. Tamaño de paquete vs tiempo entre llegadas (downlink). llegadas (uplink). II.3.3.2. Online Racing Simulations. Dirt2 es uno de los juegos en línea representante del ORS, donde varios jugadores juegan entre ellos en un entorno virtual. Esta aplicación hace uso del servicio Xbox Live para la configuración de los juegos de multijugadores. Cada participante intercambia información con el resto de los jugadores en una sesión y uno de los jugadores actúa como un servidor (nodo), sin embargo esta configuración 20 Clasificación de fuentes de tráfico HTC y MTC se puede cambiar de forma dinámica, incluso dentro de una misma sesión. De esto concluimos que el tráfico en Dirt2 depende del número de jugadores activos, que participan en el juego de una manera lineal. La tasa de paquete muestra picos claros en las dos direcciones, 12 /s para downlink y 11 /s para uplink “Fig. 24” [12]. El tamaño constante de estos paquetes conduce a una tasa de datos que tiene picos similares, en este juego es el valor 600 Byte/s, con sólo una pequeña variación “Fig. 25” [12]. Figura 24. Tasa de paquete, Dirt2. Figura 25. Tasa de datos, Dirt2. Las Figuras 26 y 27 [12], muestran un tamaño de paquete constante centrado alrededor de 90 ms (tiempo entre llegadas) en las dos direcciones. Estos parámetros son medidos mediante analizar el flujo de tráfico de red entre dos nodos, el tráfico completo para todos los nodos contiene un flujo de tráfico adicional por participante, lo que resulta en un aumento multiplicativo en la tasa de paquete y la tasa de datos. Figure 26. Tamaño de paquete vs tiempo entre Figure 27. Tamaño de paquete vs tiempo entre llegadas (downlink). llegadas (uplink). 21 Clasificación de fuentes de tráfico HTC y MTC II.3.3.3. Massive Multiplayer Online Role-Playing game. MMORPG representa un caso extremo de aplicación de juegos en línea. Estas aplicaciones sólo se pueden jugar en línea y los servidores agregan miles de jugadores al mismo tiempo. Uno de este tipo de juego es World of Warcraft (WOW), este juego utiliza TCP como protocolo de transporte, utilizando push-flags para garantizar el tiempo de entrega de los paquetes [12]. La tasa de paquetes de WOW centrada alrededor de 5 /s en las dos direcciones “Fig. 28” [12], esta tasa en comparación con la tasa de paquetes del juego OA es significativamente más baja y esto debido a que los juegos MMORPG son aplicaciones de menos reacción y más estratégicos que requieren una tasa de actualización de información más pequeños. Figura 28. Tasa de paquete, WOW. Figura 29. Tasa de datos, WOW. La Figura 29 [12], representa una diferencia interesante de la tasa de datos entre las dos direcciones, mientras que la tasa de paquetes para las dos direcciones es similar “Fig. 28”, estos resultados se pueden verificar en “Fig. 30” y “Fig. 31” [12]. La Figura 30 muestra un componente fuerte para un tiempo entre llegadas de 200 ms en un gran intervalo de tamaño de paquete, y en la dirección uplink la mayoría de los paquetes tienen tiempo entre llegadas constante “Fig.31”. Estos parámetros son medidos para un único jugador. Figure 30. Tamaño de paquete vs tiempo entre Figure 31. Tamaño de paquete vs tiempo entre llegadas (downlink). llegadas (uplink). 22 Clasificación de fuentes de tráfico HTC y MTC III. MACHINE TYPE COMMUNICATION (MTC). III.1. M2M : Visión general. III.1.1. M2M: Estándares. La comunicación M2M (machine to machine) o MTC como se denomina en 3GPP, es una forma de comunicación de datos que involucra una o más entidades que no necesariamente requieren la interacción humana o intervención en el proceso de la comunicación. Este tipo de comunicación representa un punto importante en ICT (Information and Communications Technologies) mediante habilitando el futuro de IoT (Internet of Things), y se espera que experimenta un crecimiento significativo en el 2020 a 50 millones de dispositivos interconectados. Esto ha motivado a las organizaciones a ser más activas en el proceso de estandarización M2M como ETSI, 3GPP e IEEE. El ETSI, ha establecido Comité Técnico para M2M (TC M2M) para desarrollar estos estándares necesarios. Se enfoca en desarrollo de una arquitectura end-to-end con énfasis en la capa intermedia para los servicios (middleware), que involucra en direccionamiento, localización, calidad de servicio, gestión, interfaces y otras cuestiones, de forma que los servicios sean independientes de las tecnologías existentes en las redes de acceso. Además, se especifican varias capacidades de servicios que permiten ofrecer las funcionalidades requeridas por diferentes aplicaciones M2M [13] [14]. El 3GPP, por su parte mantiene y desarrolla las especificaciones y reportes técnicos para los sistemas de comunicaciones móviles, por este motivo se encarga de definir las características y requisitos para MTC, se definen 2 escenarios para MTC, dispositivos MTC comunicados con uno o más servidores MTC y dispositivos MTC comunicados con otros dispositivos MTC [15]. El IEEE, estandariza la interfaz de aire y las funciones relacionadas con el WLL (Wireless Local Loop), por medio de la especificación IEEE 802.16p, en la que se define un punto de agregación para dispositivos no compatibles con 802.16 y otros dispositivos M2M que son compatibles. Otros estándares como, IEEE 802.11 (Wi-Fi), IEEE 802.15.3 (Zigbee), IEEE 1451 (sensor networks) y IEEE 2030 (smart grid). El ITU, se encarga del área de redes de sensores inteligentes, como SUN (smart ubiquitous networks), USN, MOS (Machine oriented Communication) y IoT. III.1.2. M2M: Arquitectura y componentes. El ETSI, considera la red M2M como una estructura de 5 partes [16]: (1) Dispositivos, normalmente embebidos en un dispositivo inteligente y son capaces de responder a peticiones o enviar datos. (2) Gateway, actúa como una entrada a otra red, además de proveer interacción e interconexión entre los dispositivos. (3) Red de área M2M, proporciona conexión entre todos tipos de dispositivos 23 Clasificación de fuentes de tráfico HTC y MTC inteligentes (o sensores) y gateways. (4) Red de comunicación, permite conexiones entre gateways y aplicaciones. (5) Aplicaciones, transfieren datos a través de diversos servicios y son utilizadas por motores de procesos de negocio específicos. Es un agente de software analizan los datos, toman acciones y reportan resultados. Ejemplos de redes de área M2M incluyen principalmente las tecnologías de red de área personal (PAN), como IEEE 802.15, UWB (Ultra-WideBand), Zigbee y Bluetooth o redes locales, como PLC (power line communication), Wi-Fi, Femtocell. La Tabla 9 [17], indica las principales tecnologías para red de área M2M. Las redes de comunicación entre gateways M2M y las aplicaciones, se incluyen redes como xDSL, WiFi, satélite, GSM, GPRS, WiMAX y LTE. Estándar Área Tasa (Mbit/s) Energyconstrained aplicaciones SRD (Short Range Devices) Personal <0.02 No Wireless audio, RFID UWB Personal >100 No Video, files sharing ZigBee/6LoWPAN (IEEE 802.15.4) Personal <0.25 Yes Sensors, monitoring Bluetooth Personal 3.00 (V2.0) Yes Music sharing PLC Local >4.5 No Smart power grid M-BUS Local <0.0096 No Consumption meters Wi-Fi Local 108(802.11g+) No Water metering Femtocell Local >7.2 No Cellular phones Tabla 9. Tecnologías para la red de área M2M. III.1.3. M2M: Aplicaciones. El 3GPP [15], ha dividido las posibles aplicaciones MTC en 7 grandes áreas: 1Seguridad: Sistemas de vigilancia, Respaldo a líneas terrestres, Control de acceso físico y Seguridad coche/conductor. 2Rastreo y Seguimiento: Gestión de flotas, Gestión de órdenes, Pague mientras conduce, Rastreo de activos, Navegación, Información del tráfico, Peajes y Optimización del tráfico. 3Pagos: Puntos de Venta (PoS), Máquinas expendedoras y Maquinas de juegos. 4Salud: Monitorización de signos vitales, Apoyo a ancianos y discapacitados, Telemedicina y Diagnostico remoto. 5Control y Mantenimiento Remoto: Sensores, Iluminación, Bombas, Válvulas, Control de ascensores, Control de máquinas expendedoras y Diagnostico de vehículos. 6Medición: Energía, Gas, Agua, Calefacción, Control de redes eléctricas y Medición industrial. 7Dispositivos de Consumo: Marco de fotos digitales, Cámara digital y Libro electrónico (eBook). 24 Clasificación de fuentes de tráfico HTC y MTC III.1.4. Requisitos de servicio. Las aplicaciones MTC no todos tienen las mismas características. Esto implica que solo una optimización del sistema no es adecuado para todas las aplicaciones MTC. Por consiguiente, en 3GPP [15], se definieron unos requisitos de servicio específicos que se adaptan a situaciones particulares de las comunicaciones MTC. Las siguientes características MTC se han definido:  Movilidad reducida: aplica a dispositivos MTC que no se mueven, se mueven muy poco, o lo hacen en cierta localidad.  Tiempo controlado: útil para aplicaciones que permitan enviar/recibir información en un momento definido, la transmisión se realiza solo durante intervalos de tiempo determinados.  Tiempo tolerante: dispositivos MTC a los que se les prohíbe el acceso temporal a la red de acceso, y pueden retrasar la transferencia de sus datos.  Solo conmutación de paquetes (PS): dispositivos MTC que solo requieren servicios PS, en lugar de conmutación de circuitos (CS).  Poca transmisión de datos: solo enviar o recibir pequeñas cantidades de datos, utilizando la mínima señalización posible.  Móvil originado sólo (MO): no se permite la opción de finalizar en el móvil (MT) y se reducen los procesos de gestión de la movilidad.  Móvil Terminado Infrecuente (MT): aunque se esperan principalmente comunicaciones MO, la red deberá mantener información actualizada del estado de los dispositivos MTC.  Monitorización MTC: supervisar el comportamiento de un dispositivo MTC de acuerdo a sus características, cambio de SIM o localidad, robo.  Mensaje de alarma de prioridad (PAM): mensaje de alarma con preferencia sobre cualquier otra característica MTC en caso de robo o vandalismo.  Conexión segura: asegurar la conexión entre dispositivos MTC y servidores MTC.  Ubicación de disparo específico: corresponde al caso donde solo se activan dispositivos MTC en un área específica, basados en la información de su ubicación.  La red provee el destino para el enlace de subida: la red debe proveer una dirección IP de destino para el tráfico uplink, desde el dispositivo MTC.  Transmisión infrecuente: el periodo entre dos transmisiones consecutivas desde el dispositivo MTC, envío o recepción de datos, es muy grande.  Características MTC basadas en grupo: gestión optimizada de todos los dispositivos MTC que pertenecen a un mismo grupo MTC (políticas de control, direccionamiento IP y otras). 31 Clasificación de fuentes de tráfico HTC y MTC Figura 34. Estado básico de la Máquina M2M. En la mayoría de los diferentes tipos de dispositivos de sensores, el tráfico se puede describir con las mismas ecuaciones y parámetros comunes que deben ser conocidos o estimados para calcular la cantidad de datos [21]:  N: El número de dispositivos o sensores M2M.  Xframe: La sobrecarga máxima del Protocolo (Campos de dirección, campos de seguridad, checksums, etc).  Xpayload: La carga útil del Protocolo.  Fhearbeat: La frecuencia de transmisión de datos para sensores inactivos, cada cuanto ocurre heartbeat una vez /minute).  Ftrigger: La frecuencia de disparo, cada cuanto ocurre un disparo (Un interruptor de la luz puede ser varias veces al día y para una alarma de incendio esperemos que nunca).  Th: El tráfico de subida de Heartbeat (Mbytes/year), cantidad total de tráfico heartbeat que viene de un tipo de sensor cada año.  Tt: El tráfico de subida de disparo, cantidad de tráfico de subida generada por un disparo específico.  Fthreshold: La frecuencia de la transmisión de datos de sensores activos después de haber sido disparado.  Threshold: Distancia de los valores umbral del sensor.  ∂y ∂t ⁄: La tasa del entorno del sensor que cambia con respecto a lo que monitoriza El parámetros Fthreshold solo es aplicable en sensores tipo alarma, como estos tipos de sensores que monitorizan el entorno el que cambia con el tiempo. Por ejemplo, cuando un dispositivo de alerta de fuga de agua monitoriza la humedad, primero será en el modo sleep cuando la humedad está por debajo de cierto umbral. Cuando hay una fuga y el umbral de humedad es superior el dispositivo despertará y envía una alerta. Las siguientes ecuaciones son para calcular el tráfico heartbeat y disparo: 32 Clasificación de fuentes de tráfico HTC y MTC Ecuación 1: Para calcular el tráfico total de heartbeat (keep-alive) 𝐓heartbeat = N x 𝐅𝐡𝐞𝐚𝐫𝐛𝐞𝐚𝐭 ( 𝐗𝐟𝐫𝐚𝐦𝐞 + 𝐗𝐩𝐚𝐲𝐥𝐨𝐚𝐝 ) Ecuación 2: Calcular el tráfico total de disparo para sensores de tipo sin alarma 𝐓𝐁𝐮𝐫𝐬𝐭 = N x 𝐅𝐭𝐫𝐢𝐠𝐠𝐞𝐫 ( 𝐗𝐟𝐫𝐚𝐦𝐞 + 𝐗𝐩𝐚𝐲𝐥𝐨𝐚𝐝 ) Ecuación 3: Calcular el tráfico total de disparo para sensores de tipo alarma (7) 𝐓𝐁𝐮𝐫𝐬𝐭 = N x 𝐅𝐭𝐫𝐢𝐠𝐠𝐞𝐫 x 𝐅𝐭𝐡𝐫𝐞𝐬𝐡𝐨𝐥𝐝 ( 𝐗𝐟𝐫𝐚𝐦𝐞 + 𝐗𝐩𝐚𝐲𝐥𝐨𝐚𝐝 ) Ecuación 4: Calcular el valor 𝑓𝑡hreshold para la Ecuación 3 𝐅𝐭𝐡𝐫𝐞𝐬𝐡𝐨𝐥𝐝 = 𝛛𝐲 𝛛𝐭 ⁄ / Threshold III.3.1. Sensores de medición. Las características del tráfico o el impacto de la red de las aplicaciones de sensores de medición se pueden describir como [22]:  Sin movilidad para sensores estacionarios.  Baja tasa de transferencia de datos.  Comportamiento predecible (en general, los sensores de medición están configurados para informar datos periódicamente).  Tolerantes al retraso.  Efecto de sincronización (sensores están configurados para establecer la conectividad simultáneamente e informar datos). En los sensores de medición existen dos tipos de sensores, sensores de tipo no alarma (como medidor eléctrico, interruptores de luz, etc.) y sensores de tipo alarma (como los sensores de detección de humo o humedad y medidor de temperatura). En una investigación para estudiar las características del tráfico M2M para esto tipo de sensores, mediante un modelo de domótica los autores han calculado el tráfico heartbeat (keep-alive) y el tráfico trigger en una red de sensores WPAN [21]. La Tabla 12 [21], muestra la cantidad de datos que se producen en un año con respecto al tráfico de la red y el tráfico de aplicación específico (goodput). El tráfico de red se usa para mantener la red viva (keep-alive) al tener dispositivos que señalen periódicamente su estado actual. En IEE 802.15.4 esto se resuelve con los nodos que piden al coordinador si hay nuevos datos para ellos, enviando una trama MAC con 1 octeto de carga útil especificando un mensaje de solicitud de datos. El Xframe es la suma del MAC (39B) + NWK (28B) + APS (8) + ZCL (4B) = 79 Bytes (cabeceras ZigBee 64 bit). 33 Clasificación de fuentes de tráfico HTC y MTC Tipo Numero de nodos (promedio)(N) 𝐗𝐟𝐫𝐚𝐦𝐞 𝐗𝐩𝐚𝐲𝐥𝐨𝐚𝐝 𝐅𝐡𝐞𝐚𝐫𝐛𝐞𝐚𝐭 𝐓𝐡 (Mbytes/year) 2 salas 8 salas (Bytes) (Bytes) (Hz) Min Max Detector humedad 3 5 79 1 6 x 10−4 4 7 Detector humo 2 8 79 1 2 x 10−2 80 321 Centro de Sistema de seguridad 1 1 79 1 2 x 10−2 40 40 Interruptores de luz 20 40 79 1 6 x 10−4 27 53 Medidor eléctrico 1 1 79 1 6 x 10−4 1 1 Enchufes eléctricas 10 40 79 1 6 x 10−4 13 53 Temperatura 3 10 79 1 6 x 10−4 4 13 Total 40 105 170 489 Tabla 12. Tráfico Heartbeat basado en especificación ZigBee con 64 bit de dirección. Según esta tabla el detector de humo y el sistema de seguridad producen una gran cantidad de tráfico heartbeat a pesar del número de unidades en cada sistema es pequeño, comparando este tráfico con el gran número de interruptores de luz, se ve que la diferencia se debe a la frecuencia polling. La alta frecuencia de polling de los detectores de humo y sistemas de seguridad se debe a las alarmas de estos sistemas en tiempo crítico. Los demás sensores no son críticos y producen una considerable menos cantidad de tráfico de Heartbeat. Tipo Numero de nodos (promedio)(N) 𝐗𝐟𝐫𝐚𝐦𝐞 𝐗𝐩𝐚𝐲𝐥𝐨𝐚𝐝 𝐅𝐭𝐫𝐢𝐠𝐠𝐞𝐫 𝐅𝐭𝐡𝐫𝐞𝐬𝐡𝐨𝐥𝐝 𝐓𝐭 (Mbytes/year) 2 salas 8 salas (Bytes) (Bytes) veces por año (Hz) Min Max Detector humedad 3 5 79 2 2.5 x 10−2 1.7 x 10−2 10−7 2 x 10−7 Detector humo 2 8 79 4 1. 2 x 10−3 2 x 10−1 4 x 10−8 2 x 10−7 Veces por día Centro de Sistema de seguridad 1 1 55 100 144 7.77 7.77 Interruptores de luz 20 40 79 2 5 NA 2.82 5.64 Medidor eléctrico 1 1 79 100 144 NA 8.97 8.97 Enchufes eléctricas 10 40 79 4 3 NA 0.87 3.47 Temperatura 3 10 79 4 5 NA 0.43 1.44 Total 40 105 21 27 Tabla 13. Tráfico Trigger (Disparo) basado en especificación ZigBee con 64 bit de dirección. La Tabla 13 [21], indica una estimación de la cantidad de tráfico (event-driven) que se enviará fuera de la casa a través de la conexión WAN del gateway. Se muestra que el tráfico de disparo en los sensores de humo y humedad es mínimo, ya que es sólo cuando las alarmas dispararan y envían un mensaje de evento, pero esto no suele a pasar. Los sistemas de seguridad tienen la mayor parte 34 Clasificación de fuentes de tráfico HTC y MTC del tráfico. El medidor de electricidad y el sistema de seguridad tienen altas frecuencias de disparo y payloads, desde que las compañías operadoras que son responsables necesitan alta fiabilidad y seguridad. En los sensores tipo alarma el patrón de tráfico keep-alive se puede modelar utilizando modelo de tráfico ON/OFF con tiempo entre salidas constante para imitar la naturaleza periódica de los mensajes keep-alive. Mientras que el patrón de tráfico en ráfagas (event-driven) se puede modelar utilizando modelo de tráfico ACTIVE-OFF con distribución de Weibull con tasa λ y el parámetro de forma k [12]. III.3.2. Automoción. La Automoción se basa en dispositivos M2M equipados con sensores integrados en los coches y aplicaciones relacionados de red que proporcionan muchos servicios como autopiloto, rastreo y detener los vehículos robados, pay-as-you-drive (seguro de automóvil). Las características del tráfico o el impacto de la red de las aplicaciones de automoción se pueden describir como [22]:  Alta movilidad.  Alta tasa de transferencia de datos, en particular para aplicaciones comerciales. El servicio autopiloto incluye tanto la detección de colisión de vehículo y evitar la colisión y cómo se toman las acciones de urgencia en caso de un accidente. Se basa en dispositivos M2M equipados con sensores integrados en los coches y el entorno que rodea y se utiliza en los sistemas de conducción automática. Estos dispositivos M2M (automóviles, unidades de señal de tráfico, cámaras de autopista) envían información a un sistema BCAS (backend collision avoidance system). El sistema backend distribuye notificaciones a todos los vehículos en el entorno de la ubicación de la colisión, junto con la información necesaria para los controles correspondiente en los coches afectados. En todos los coches que reciben, los sistemas de conducción automática en base a la información recibida controlan el coche totalmente o parcialmente (frenos activados, cambió en la dirección, cinturones de los asientos apretados, etc.), si no hay un sistema de este tipo en un coche, el conductor se notifica [12]. Hay dos patrones principales de tráfico para el autopiloto el primero keep-alive, mensajes periódicos de baja tasa de datos (GPS, velocidad, tiempo) desde los dispositivos M2M al sistema backend (una vez por minuto, en el orden de 500B por mensaje). El segundo, ráfaga (event-driven), señales de emergencia de alta tasa de datos desde el backend a los dispositivos M2M incluyendo comandos de aviso y activación (cada ráfaga en el orden de 1-2kB). La Tabla 14 [12], indica el tráfico para los dos patrones. El 𝐗𝐟𝐫𝐚𝐦𝐞 es la suma de TCP / IPv4 (40 B), PDCP (2B), RLC-AM (4B) y MAC (4B) tamaño de la cabecera, y estimado como 49 bytes. 35 Clasificación de fuentes de tráfico HTC y MTC Tráfico N 𝐗𝐟𝐫𝐚𝐦𝐞 𝐗𝐩𝐚𝐲𝐥𝐨𝐚𝐝 𝐅𝐡𝐞𝐚𝐫𝐛𝐞𝐚𝐭 𝐅𝐭𝐫𝐢𝐠𝐠𝐞𝐫 𝐅𝐭𝐡𝐫𝐞𝐬𝐡𝐨𝐥𝐝 Keep-alive 100 48 500 B 1s NA NA Ráfaga 100 48 1-2 KB NA - - Tabla 14. Los parámetros de tráfico para autopiloto. El patrón de tráfico keep-alive se puede modelar utilizando modelo de tráfico ON/OFF con tiempo entre salidas constante para imitar la naturaleza periódica de los mensajes keep-alive. El segundo patrón de tráfico (event-driven) se puede modelar utilizando modelo de tráfico ACTIVEOFF con distribución exponencial y tasa media, como la transmisión de datos desde máquinas o sensores se produce cuando se activan y se convierten en activo. Figura 35. Modelo de referencia para el autopiloto. La Figura 35 [12], representa el diagrama de estado para los diferentes estados del autopiloto. Cuando todo es correcto, los coches y los sensores de carretera están enviando mensajes de actualización para detección de colisión. Cuando ocurre un accidente la detección de colisiones es transferida al estado evitación de colisiones y se produce el tráfico de ráfaga. III.3.3. Juegos M2M. Uno de muchos posibles juegos M2M es la carrera virtual de bicicletas reales. Los competidores intercambian información entre ellos, información de mediciones son tomadas por sensores (GPS, temperatura, humedad, velocidad, etc.), y son utilizados por la aplicación para calcular las posiciones equivalentes de los participantes y para mostrarles el estado correspondiente (por ejemplo, "usted está liderando por 10 m"). El número de competidores puede ser más que dos, y todos los competidores deben intercambiar información y las aplicaciones deben presentar para todos los participantes el estado de otros competidores. Para un gran número de competidores (100 o más), un servidor de aplicaciones correspondiente debe ser utilizado. Durante la carrera se les informan sobre el lugar y las distancias entre ellos [12]. 36 Clasificación de fuentes de tráfico HTC y MTC El patrón de tráfico para este juego es comparable a una transmisión periódica constante de baja tasa de datos entre los dispositivos M2M con períodos más cortos como el fin de la carrera está cada vez más cerca. Este patrón de tráfico también se puede modelar como un modelo de tráfico ON/OFF clásico con tiempo entre salidas monótona decreciente. La Tabla 15 [12], muestra el tráfico para el patrón keep-alive, los paquetes que contienen los datos del GPS y sensores son de tamaño 10-15 KB (Xpayload) y deben ser intercambiados aproximadamente cada 100 ms (Fhearbeat), lo que corresponde a una resolución de 1.4 m (la precisión del GPS). La aplicación debe conocer las posiciones de todos los competidores con respecto al fin de la carrera y cuando los competidores están cerca del final, los paquetes deben ser enviados cada 70 ms (Fhearbeat) que corresponde a una resolución de 1 m. Las tasas de datos normalmente no son superiores a 10 kb/s (solo 15 kb/s en la fase final de la competición). Tráfico N 𝐗𝐟𝐫𝐚𝐦𝐞 𝐗𝐩𝐚𝐲𝐥𝐨𝐚𝐝 𝐅𝐡𝐞𝐚𝐫𝐛𝐞𝐚𝐭 𝐅𝐭𝐫𝐢𝐠𝐠𝐞𝐫 𝐅𝐭𝐡𝐫𝐞𝐬𝐡𝐨𝐥𝐝 Keep-alive 2-100 79 10-15 KB 70-100ms NA NA Tabla 15. Los parámetros de tráfico para la carrera virtual de bicicletas. La Figura 36 [12], representa el diagrama de estado para los diferentes estados de la carrera virtual de bicicletas. Hay dos estados: Estado del competidor y sistema de juego virtual. Los competidores están enviando sus datos al servidor de aplicación y luego el servidor envía los datos procesados a los competidores. Figura 36. Modelo de referencia para la carrera virtual de bicicletas. III.3.4. Rastreo de equipos. Las aplicaciones TT (Team Tracking), se utilizan para monitorizar la posición de varios nodos en un dado entorno para conocimiento de la situación y planificación de la acción. Una aplicación típica del TT es la monitorización de bomberos o policías en un área dada durante una operación (por ejemplo, edificio). Es importante tener una imagen up-to-date de la situación, para permitir la reactividad y gestionar el equipo teniendo en cuenta las posiciones y los riesgos asociados. Una monitorización constante es obtenida por un sistema de localización y la conectividad entre los nodos 37 Clasificación de fuentes de tráfico HTC y MTC y el centro de control. Este tipo de aplicación es normalmente ejecutado en redes ad hoc de malla desplegada para necesidades específicas, por lo tanto, el centro de control puede estar cerca físicamente de uno de los nodos de la red o puede estar físicamente lejos. Si es lejos, un nodo de la red ofrece conectividad a una red troncal IP para llegar al centro de control [12]. Los sistemas TT se tratan con flujos datos separados: información de localización, fotos, texto o datos para los nodos, y cada flujo puede tener su jerarquía de prioridades en las restricciones de QoS. Por ejemplo, la información sobre los nodos (estado del nodo, nivel de batería, etc.) no tiene restricciones de entrega, pero necesita fiabilidad parcial. Por otro lado, las actualizaciones de posición no tienen restricciones de fiabilidad, en el sentido de que, dependiendo de la tasa de los mensajes y el tipo de escenario operativo, perder algunos paquetes puede ser posible. Tráfico N 𝐗𝐟𝐫𝐚𝐦𝐞 𝐗𝐩𝐚𝐲𝐥𝐨𝐚𝐝 𝐅𝐡𝐞𝐚𝐫𝐛𝐞𝐚𝐭 𝐅𝐭𝐫𝐢𝐠𝐠𝐞𝐫 𝐅𝐭𝐡𝐫𝐞𝐬𝐡𝐨𝐥𝐝 Keep-alive (GPS) <10 79 10B-1 KB 1-60 s NA NA Keep-alive (Email) <10 79 1-2 KB 600s NA NA Keep-alive (Foto) <10 79 300 KB 600s NA NA Tabla 16: Los parámetros de tráfico para el TT. Hay dos patrones principales de tráfico para el TT el primero keep-alive, mensajes periódicos de baja-mediana tasa de datos (GPS, foto, texto, tiempo) desde el equipo al centro de comando. El segundo, ráfaga (event-driven), señales de actividad de planificación de baja tasa de datos desde el centro de comando al equipo. La Tabla 16 [12], indica el tráfico keep-alive para tres patrones en paralelo. La Figura 37 [12], representa el diagrama de estado para los diferentes estados del TT. Figura 37. Modelo de referencia para TT. 38 Clasificación de fuentes de tráfico HTC y MTC IV. CONCLUSIONES. En este trabajo hemos clasificado dos categorías principal de fuentes de tráfico, la primera categoría es las fuentes HTC incluye fuentes de voz, fuentes de video y fuentes de datos. Las fuentes de voz generan tráfico a una tasa entre 5 y 64 Kbps, las características (tiempo entre llegadas, tamaño de paquete) de una fuente de voz o una fuente de video son totalmente diferentes dependiendo del códec utilizado, cada códec genera un patrón de tráfico diferente el mejor ajuste que describe esta patrón es la distribución gamma para diferentes codecs de voz y video (GSM 06.10, G.711, G.729, H.263, H.263+ y H.264), otro parámetro importante que define el comportamiento de una fuente de voz es la duración del período activo ON y el período de inactividad OFF donde el mejor distribución que describe el comportamiento de las dos periodos es la distribución lognormal. A diferencia de las fuentes de voz las fuentes de video tienen una tasa de generación más alta entre 30 Kbps y 10 Mbps dependiendo del códec y el movimiento. Otros parámetros caracterizan las fuentes de video, el número de cuadros (fps) o si se estudian a nivel de GOB el número de GOB (GOB/s). Las fuentes de datos tienen características diversas en comparación con el tráfico de voz y de vídeo dependiendo del tipo de fuente y esto las hace más difíciles de soportar en la red debido a la previsibilidad baja de tráfico, en las fuentes de tráfico FTP el comportamiento del protocolo TCP en conexión congestionada que importa más que el tamaño del fichero y el mejor ajuste que describe el patrón del tráfico generado por FTP es la distribución gamma. El tráfico de los juegos en línea depende principalmente del tipo de juego que se ejecuta el cliente, En el caso de los juegos FPS las fuentes de tráfico generan la tasa de paquete más alta de todos los juegos (91 paquete/s), para ORS 11 paquete/s y en el caso de MMORPG la tasa es baja (5 paquete/s). En general los modelos de tráfico MTC son de tráfico agregado como el modelo 3GPP, definen el tráfico MTC como un flujo de múltiples dispositivos, que requieren modelos de fuente pero cada modelo sea por cuenta del dispositivo, las problemas en los modelos de fuente son la cantidad de dispositivos que deben modelar en paralelo y la correlación tanto espacial como temporal entre los dispositivos, los Modelos de tráfico CMMPP solucionan estas problemas. La segunda categoría es las fuentes MTC, hemos clasificado cuatro tipos según la aplicación (sensores de medición, automoción, juegos M2M y rastreo de equipos), los paquetes transmitidos por estas aplicaciones consisten en los datos medidos más la sobrecarga del protocolo y generalmente son pequeños, el comportamiento de las redes de sensores es de aplicación específica y los parámetros más importantes que afectan a este comportamiento son la frecuencia de disparo, la sobrecarga del tráfico heartbeat y la sobrecarga del tráfico event-driven. El tráfico MTC tiene patrones de tráfico muy específicos, existen dos patrones principales que describen el comportamiento del tráfico generado por las cuatro aplicaciones, el primero es keep-alive o heartbeat mensajes 39 Clasificación de fuentes de tráfico HTC y MTC periódicos desde el nodo MTC hacia el servidor con un tamaño de datos constante y el segundo patrón de tráfico (event-driven) o en ráfagas desde el servidor hacia el nodo MTC con tasa de datos depende de la aplicación. V. AGRADECIMIENTOS. A mi director el Dr. Miguel Angel Rodríguez por haberme dado la oportunidad de realizar este trabajo, por su disponibilidad, su buen hacer, por confiar en mí y darme ánimos para llevar a término este trabajo, al profesor Angel Gómez quien me saco de dudas en momentos oportunos. A mi padre el Doctor Rabah Muhana y a mi madre Norhan Al nono. A mi hermano el Doctor Marwan Muhana porque es un punto de referencia esencial en mi vida y aunque esté lejos de mí siempre ha estado conmigo, en los momentos buenos y malos y siempre apoyándome. 40 Clasificación de fuentes de tráfico HTC y MTC VI. BIBLIOGRAFÍA [1] J. Evans and C. Filsfils, “Deploying IP and MPLS QoS for Multiservice Networks: Theory and Practice”, Morgan Kaufmann (2007). [2] R. Goleva, D. Atamian, S. Mirtchev and D. Dimitrova, “3G Network Traffic Sources Measurement and Analysis”, Transactions on Emerging Telecommunications Technologies, 25, (2014), 8, pp. 798‐ 814. DOI: 10.1002/ett.2703. [3] Brady, P.T., “A model for generating on-off speech patterns in two-way conversations”, Bell Syst. Tech. J., 1969, 48, pp. 2445–2472. [4] Pragtong, P., Ahmed, K.M., Erke and T.J., “Analysis and Modelling of voice over IP traffic in the real network”, IEICE Trans. Inf. Syst., 2006, E89-D, (12), pp. 2886–2896. [5] A.D. Shaikh, K.J Blow, M.A. Eberhard and S.A. Fowler, “Language independent on–off voice over IP source model with lognormal transitions”, IET Communications, 7 (2013), DOI: 10.1049/iet‐ com.2012.0686, 1449 ‐ 1455. [6] R. Hernández Cuenca, “Clasificación De Los Modelos De Fuentes De Video Sobre Internet”, Mater en Ingeniería Electrónica, Pontificia Universidad Javeriana. [7] O. Rose, and M. R. Frater, “A Comparison of Models for VBR Video Traffic Sources in B-ISDN”, Tech. rep., University of Wurzburg 1993. [8] H. Hassan, J.M GARCIA and O. BRUN, “Generic Modeling of Multimedia Traffic Sources”, Laboratory for Analysis and Architecture of Systems, France. [9] Krunz M. and Makowski M., “Modeling Video Traffic Using M/G/∞ Input Processes: A compromise between Markovian and LRD Models”, IEEE Journal of Selected Areas in Communications, pp.733-748, (1998). [10] Recommendation ITU-T Q.3925, “Traffic flow types for testing quality of service parameters on model networks”, 2012. [11] Gomes J. V. P., Inacio P. R. M., Lakic B., Freire M. M., da Silva H. J. A., and Monterio P. P., “ Source traffic analysis”, ACM Transactions on Multimedia Computing, Communications, and Applications, 2010. [12] FP7 lola project, "Achieving Low-Latency in Wireless Communications", Project Nº 248993, EURECOM and TuV, France. [13] ETSI TS 123 107 V12.0.0, “Quality of Service (QoS) concept and architecture”, septiembre.2014. [14] ETSI TS 123 207 V12.0.0, “End-to-end Quality of Service (QoS) concept and architecture”, September, 2014. [15] 3GPP TS 22.368 v11.2.0, “Service requirements for machine-type communications”, Jun.2011. [16] ETSI TS 102 690: "Functional architecture", v1.1.1, 2011. [17] M. Chen, J. Wan and Fang Li “Machine-to-Machine Communications: Architectures, Standards and Applications”, KSII Transactions on internet and information systems VOL. 6, NO. 2, February, 2012. [18] M. Lan, P. Svoboda, N. Nikaein, M. Rupp, “Traffic Models for Machine Type Communications”, Wireless Communication Systems (ISWCS 2013), Proceedings of the Tenth International Symposium on, 27-30 Aug. 2013, vol., no., pp.1,5. [19] 3GPP TR 37.868, “Study on RAN Improvements for Machine-type communications”, September, 2011. [20] T. P., S.N.K.Marwat, Y. Zaki and C. Gorg, “Influence of Future M2M Communication on the LTE System”, Wireless and Mobile Networking Conference. Dubai, United Arab Emirates, 23-25 April, 2013. [21] Orrevad, A., “M2M Traffic Characteristics (When machines participate in communication)”, Information and Communication Technology. Master of Science Thesis Stockholm, Sweden 2009. [22] D. Boswarthick, O. Elloumi and O. Hersent, “M2M communications: A systems Approach”, John Wiley & Sons Ltd, United Kingdom, 2012.