Por qué las comunicaciones inalámbricas deben intentar evitar el uso del protocolo IP
Esta pregunta es difícil de responder porque es una combinación de muchos factores. Debido a limitaciones de espacio, intentaremos ser lo más concisos posible.
El protocolo IP es un protocolo para la transmisión continua de paquetes de datos de formato fijo. Está diseñado para redes cableadas. Las redes cableadas se caracterizan por una calidad de canal estable y velocidades de transmisión de datos muy altas, que son adecuadas para transmitir grandes cantidades. cantidades de datos. La Figura 1 muestra el formato de un paquete IP e indica la longitud (en bytes) de cada campo dentro del paquete.
Como puedes ver, un paquete IP contiene un encabezado fijo de al menos 20 bytes, que se utiliza para el control y direccionamiento del protocolo IP. Esta parte del contenido no es útil para la transmisión real de datos del usuario, por lo que la longitud en bytes del encabezado del paquete de datos representa el costo de transmitir una cierta cantidad de datos válidos, también llamado sobrecarga. Los datos de usuario válidos en el paquete de datos, excepto el encabezado, se denominan carga útil. Los gastos generales se calculan de la siguiente manera:
Gastos generales = 1 - Longitud de la carga útil/Longitud total del paquete
Este es un valor porcentual. Obviamente, cuanto menor sea el valor general, mayor será la eficiencia de la comunicación.
Sin embargo, no puedes comunicarte directamente usando el protocolo IP, debes usar el protocolo TCP, que tiene un encabezado de 20 bytes, por lo que un paquete TCP/IP completo contiene 20 20 = 40 bytes de encabezado.
La longitud de esta cabecera no es importante para el protocolo TCP/IP. Debido a que la longitud máxima de un paquete TCP/IP puede alcanzar los 64.000 bytes, en comparación con un paquete tan grande, la sobrecarga = 0,06, que es casi insignificante, y se puede decir que la eficiencia de la comunicación es bastante alta.
Pero el entorno inalámbrico es completamente diferente. La característica de los canales inalámbricos es que la calidad del canal es muy inestable. Las señales de radiofrecuencia se atenuarán y reflejarán, lo que provocará una alta probabilidad de errores en la transmisión. Esto significa que la longitud de los paquetes de datos inalámbricos no puede ser demasiado larga; de lo contrario, una vez que se produce un error, el costo de la retransmisión será muy alto y es fácil bloquear todo el canal de transmisión. Por ejemplo, si sólo un bit de 64.000 bytes es erróneo, se deben retransmitir los 64.000 bytes. Esto es terrible. Por este motivo, los protocolos de comunicación inalámbrica suelen adoptar la forma de paquetes de datos cortos. El tamaño del paquete de datos corto se determina en función de diferentes frecuencias de radio, métodos de modulación y codificación, velocidades de símbolos, requisitos del entorno de uso, etc. **** Misma decisión. Por ejemplo, el estándar IEEE 802.15.1 (Bluetooth) especifica una longitud de paquete de 251 bytes, IEEE 802.15.4 (Zigbee) especifica una longitud de paquete de solo 127 bytes y la longitud del paquete LoRa es un máximo de 234 bytes.
La Figura 2 muestra la estructura de paquetes del protocolo Zigbee 802.15.4
Según los cálculos, la sobrecarga de los paquetes Zigbee es aproximadamente 1- 102/133 = 23,3.
La Figura 3 muestra la estructura del paquete de datos Bluetooth 802.15.1
La sobrecarga del paquete de datos Bluetooth se puede calcular como = 1 - 246/265 = 7,1
Si transmitimos paquetes TCP/IP a través de los estándares 802.15.1 y 802.15.4, la sobrecarga de transmisión por paquete es aproximadamente 1 - 102/133 = 23,3.
Transmisión de IP sobre IEEE 802.15.1: Gastos generales = 1 - 206/266 = 22,5
Transmisión de IP sobre IEEE 802.15.4: Gastos generales = 1 - 62/133 = 53,3 p>
Dado que cada paquete cuesta tanto, estos números son difíciles de aceptar. ¿Qué significan estos números? Por ejemplo, si China Telecom le vende 10 millones de banda ancha, pero en realidad solo puede usar 4 millones, pero China Telecom le cobra 10 millones, entonces me temo que se quejará.
¿No hay forma de mejorarlo? La respuesta es 6LowPAN. Algunos entusiastas inteligentes del protocolo IP han encontrado una manera de optimizar el protocolo IP: comprimir el encabezado del paquete de datos. Si el encabezado del paquete de datos de 40 bytes pudiera comprimirse a una longitud muy corta, ¿no mejoraría la eficiencia? En el estándar 6LowPAN, 20 bytes se pueden comprimir a 2 bytes en el mejor de los casos. De esta manera, el problema de los gastos generales es menos grave. La Figura 4 muestra la estructura del paquete 6LowPAN.
Entonces, ¿es esta la solución perfecta que necesitamos?
Las cosas no son tan sencillas. 6LowPAN todavía tiene sus limitaciones.
1. La compresión solo se puede realizar dentro de la misma red localizada inalámbrica conectada físicamente (como la misma red Bluetooth o la misma red LoRa) y está limitada a un salto. Este método será inútil si desea enviar datos a un dispositivo que no está en la misma red, como un dispositivo en una red Bluetooth que envía datos a un dispositivo LoRa.
2. El protocolo IPv6 requiere una longitud mínima de paquete de 1280 bytes, lo que obviamente es imposible de lograr en una red inalámbrica. Por lo tanto, al transmitir la pila de protocolos 6LowPAN en una red inalámbrica, es necesario segmentarla y llenarla artificialmente para adaptarse a los requisitos de la red IP. Esto es fácil de lograr en una red que utiliza la misma tecnología inalámbrica, pero en un entorno de red que contiene múltiples tecnologías inalámbricas, esto se vuelve muy complicado y genera muchos gastos generales adicionales.
Por lo tanto, 6LowPAN e IPv6 aún tienen un largo camino por recorrer para solucionar estos problemas y popularizar IPv6 en las redes de comunicación inalámbrica.