¿Por qué RTS / CTS no resuelve completamente el problema del terminal oculto y el problema del terminal expuesto?

1

Estaba leyendo un poco en línea y libros de texto sobre el protocolo RTS / CTS para la transmisión inalámbrica. Aunque el libro de texto que leí decía que el terminal oculto (y el terminal expuesto) se resuelve mediante RTS / CTS, en línea vi que en realidad el protocolo RTS / CTS no resuelve completamente el problema. Pero solo reduce es.

El protocolo parece bastante limpio y para mí parece que el problema está resuelto. ¿Qué me estoy perdiendo aquí, por qué varias fuentes afirman que el problema no se resuelve?

¿Hay suposiciones difíciles debajo de todo el protocolo?

    
pregunta Kristof Tak

1 respuesta

5

En primer lugar, se debe tener en cuenta que los RTS / CTS a los que se hace referencia en la pregunta no tienen nada que ver con los cables de hardware, como los cables RTS / CTS que se utilizan con frecuencia para el protocolo de enlace UART. Dicho esto, este es un problema de comunicación de radio de bajo nivel y parece ser tan tópico aquí como lo serían las preguntas sobre cosas como XBee.

El problema del terminal "oculto / expuesto" se relaciona con el hecho de que es posible tener tres nodos, X, Y y Z, de manera que Y está lo suficientemente cerca de X para recibir datos cuando Z está en silencio, y Z está simultáneamente cerca suficiente para Y para interrumpir las comunicaciones de X, pero lo suficientemente lejos para que X no pueda detectarla.

En el caso general, Z no tendrá forma de saber cuándo alguien podría estar enviando información a Y, por lo que Z no tendrá forma de saber cuándo sus transmisiones atascarán las de otra persona. Si X está enviando un paquete pequeño a Y, es más barato para X simplemente enviarlo y estar preparado para retransmitir si se atasca, de lo que sería tratar de evitar dicho atasco. Sin embargo, si X está enviando un paquete más grande, es útil que X comience con un paquete pequeño que le diga a Y que espere uno más grande, y que Y responda con un paquete pequeño que indique que espera recibir el paquete más grande. Esto tiene algunos efectos útiles. El principal de ellos:

  1. Si Y no puede escuchar un paquete pequeño de X, no hay razón para que X envíe un paquete grande. El hecho de que X se abstenga de enviar un paquete grande ayuda a evitar saturar las ondas con datos inútiles que posiblemente bloquearían o colisionarían con otras transmisiones.

  2. Si Z escucha a Y dice que está esperando datos de X, entonces Z sabrá que debe evitar transmitir en ese canal en particular durante el tiempo que se espera que tenga lugar la transmisión.

El protocolo RTS / CTS no es una panacea. Puede hacer que las colisiones sean improbables en bloques de datos más grandes, pero no soluciona el problema de las colisiones con bloques de datos más pequeños [afortunadamente, las colisiones de bloques pequeños son generalmente menos costosas]. Además, incluso si tanto X como Y anuncian el hecho de que X enviará datos a Y, e incluso si Z está lo suficientemente cerca de X e Y para bloquear sus transmisiones, no hay garantía de que Z escuchará realmente el anuncio de X o Y. Por ejemplo, Z podría estar comunicándose con el nodo Q, que está fuera del rango de X e Y, y Q podría enviar datos a Z al mismo tiempo que X e Y están enviando sus anuncios. En ese caso, debido a que Z no habría escuchado a X e Y diciendo que esperaban hablar entre ellos, Z no tendría ninguna razón para suspender sus transmisiones en su nombre.

Fundamentalmente, la comunicación inalámbrica está plagada de una cierta asimetría: si A escucha algo de B, puede saber que B lo envió, pero si A no escucha nada que no implique que B no haya enviado nada. . Conceptualmente, debería ser posible para un receptor distinguir entre "silencio" y "ruido indescifrable", y darse cuenta de que si A obtiene silencio (en lugar de ruido), B no puede haber enviado nada, pero no conozco protocolos que aproveche tales distinciones.

    
respondido por el supercat

Lea otras preguntas en las etiquetas