ANÁLISIS ARTICULO; CHALLENGES IN IOT NETWORKING VIA TCP/IP ARCHITECTURE

ANÁLISIS ARTICULO; CHALLENGES IN IOT NETWORKING VIA TCP/IP ARCHITECTURE

[pic 1]

OSCAR LUIS BALLESTA CHARRASQUIEL

UNIVERSIDAD DE CÓRDOBA

FACULTAD DE INGENIERÍA

DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y

TELECOMUNICACIONES

LORICA – CÓRDOBA

2020.

Capa de red

MUT (Unidad Máxima de Transferencia) pequeño

Problema:

El tamaño de la trama de la capa para IEEE 805.15.4-2006  (wireless personal area networks, WPAN) (WPAN de baja velocidad) es de 127 bytes. Las redes actuales que normalmente asumen un mínimo de 1500 bytes o mayor.

La especificación IPv6 usa un encabezado de longitud fija de 40 bytes, estos encabezados extensos provocan gatos generales en paquetes pequeños. Además, todas las redes compatibles con la especificación admiten un minino de 1280 bytes

Solución:

La compresión del encabezado, permitiendo la eliminación de campos no utilizados e información redundante  

Fragmentación de la capa de enlace, esta oculta el tamaño real de MUT de 805.15.4 y le da a la capa red la ilusión de que se está ejecutando sobre el estándar de enlace compatible capaz de admitir MUT de 1280 bytes

Subred multienlace

Problema:

El reenvío a través de múltiples enlaces dentro de la subred crea problemas con TTL/Hop limite de manejo. En las redes IP es común limitar el alcance de la comunicación a una sola subred configurando el TTL/Hop-Limit a 1 0 255 y verifique que el valor pertenece igual al recibirlo. Pero la subred multienlace romperá cualquier protocolo que siga lo anterior descrito porque provoca que los nodos realicen el reenvío del IP a través de múltiples enlaces. Por lo que es necesario disminuir el valor TTL/Hop-Limit.

La multidifusión no funciona en las subredes multienlace sin el soporte adecuado para multidifusión, que a menudo se encuentra deshabilitado. En consecuencia, los protocolos heredados que dependen de en alcance multi difusión, por ejemplo: ARP, DHCP, descubrimiento de vecino y muchos protocolos de enrutamiento. también se romperán en subredes multienlace.

Solución:

Se confía en los mecanismos de la capa dos para pegar múltiples enlaces en una sola red transparente, o partición la red en malla en multi ples sud redes con diferentes prefijos

Eficiencia multidifusión

Problema:

La mayoría de los protocolos MAC inalámbricos deshabilitan el en lace en la capa ACK para multi difusión, con secuencia, los paquetes perdidos ni son recuperados en la capa de en lace

Los destinatarios de multidifusión pueden experimentar una velocidad de trasmisión de datos diferente debido a la diferencia de múltiples protocolos MAC (por ejemplo: diferentes versiones de WIFI) y/o la adaptación de la velocidad de la capa de enlace por lo tanto el remitente debe transmitir a la velocidad de enlace más baja entre todos los receptores.

Los nodos de IoT pueden cambiar la suspensión de vez en cuando para conservar energía lo que hace perder algunos paquetes de multidifusión.

Cuando los nodos conectados a través de una red de mayas, un paquete de multidifusión necesita ser reenviado a través de múltiples saltos a lo largo de muchos caminos despertando inicialmente muchos nodos dormidos y sobrecargando recursos de red ya escasos.

Solución:

Cuando los nodos de IoT necesitan enviar notificaciones a múltiples destinatarios, en lugar de multidifusión del paquete, pueden almacenar temporalmente esos paquetes en algún poso con ubicación desconocida y esperar a que los destinatarios extraigan los paquetes sobre unidifusión a pedido.

Si se quieren realizar consultas a un grupo, en lugar de hacerlo a la red con difusión, pueden enviar las consultas algunos nodos designados que están preconfigurados para responder consultas mediante la recopilación de la información a prioridad. Estos nuevos reemplazan la multidifusión con la extracción de unidifusión bajo demanda, para sortear las dificultades en el soporte de multidifusión y también para acomodar nodos durmientes.

Un ejemplo de tal adaptación de protocolo es el IPv6 NeighOptimización de bor Discovery (ND) para 6LoWPAN s. Al adaptar Funcionalidades ND a 6LoWPAN, en lugar de tener los enrutadores anuncios de enrutador de multidifusión periódicamente (que o despierta los nodos durmientes o los extrañan nodos).

Otra extensión es mantener un registro de direcciones de host en los enrutadores, haciendo los enrutadores capaces de responder a la resolución de direcciones y solicitudes de detección de direcciones duplicadas en nombre de los hosts finales, de modo que los nodos de consulta simplemente envíen sus consultas a los enrutadores predeterminados a través de mensajes de unidifusión.

Este nuevo protocolo de reenvío de multidifusión ha sido adoptado por la especificación IP actual de ZigBee.

Enrutamiento de red en malla

Problema:

Un inconveniente en este modo La precaución es que, a medida que nuevos nodos se unen dinámicamente a la red, el proceso de asignación de direcciones puede tener que volver a realizarse para adaptarse a los cambios topológicos.

Solución:

Enrutamiento de la red de malla a través de el enfoque de ruta y ha desarrollado RPL (IPv6 Routing Protocolo para redes de baja potencia y con pérdidas) como la solución estándar actual.

Cuando dos los nodos dentro de un DODAG se comunican entre sí, sus los paquetes atraviesan hasta el nodo raíz o un ancestor, luego siga un enlace hacia abajo hasta el destino. o. Sin embargo, a diferencia de IEEE 802.15.5 que asigna dependientes de la topología Dirección L2, RPL no hace ninguna suposición sobre IP asignación de direcciones. Esto prohíbe efectivamente la entrada de enrutamiento agregación más allá de compartir prefijos comunes.

Capa de transporte

Problema:

Debido a las limitaciones de energía, los dispositivos pueden entrar en modo de reposo, por lo que no es factible mantener una conexión en vivo en aplicaciones de IoT.

La comunicación implica sólo una pequeña cantidad de datos, la sobrecarga de establecer una conexión es inaceptable.

Algunas aplicaciones (p. Ej., Activación de dispositivos) pueden tener requisito de baja latencia, que puede no tolerar el retraso causado por el protocolo de enlace de TCP. Cuando se trabaja con pérdida redes inalámbricas, la entrega y retransmisión en orden El mecanismo de TCP también puede causar un bloqueo del encabezado de línea, que introduce retrasos innecesarios. Además, la mayoría de los cables menos protocolos MAC también implementan la recuperación automática de solicitud de turba (ARQ), que puede perjudicar aún más el rendimiento mance de TCP si el retardo de retransmisión L2 es mayor que el TCP RTO.

...