Efecto Nodo Oculto - Configurar RTS
Contents
Se denomina Nodo Oculto al efecto por el cual el receptor puede escuchar dos transmisores, pero estos no se pueden escuchar entre sí.
La historia es así
RTS = Request To Send, CTS = Clear to Send.
La transferencia de paquetes entre equipos inalámbricos arranca con esos 2 paquetes, un equipo envia un RTS y el otro equipo le contesta con CTS cuando lo disponga.
Una analogía seria los paquetes ICMP ECHO (o sea ping), una máquina "pregunta" con un ICMP ECHO REQUEST y el otro responde con un ICMP ECHO REPLY lo antes posible.
En este caso, el CTS (contesta al que manda el RTS de que "no hay moros en la costa" para transmitir el paquete) lo devolverá el equipo cuando "le convenga". Es decir, si esta manteniendo una transmisión con otro equipo, entonces no va a responder hasta que no termine.
Entonces, con esto en mente:
Cuando configuramos "RTS/CTS" en realidad solamente vamos a pedirle a ese equipo que mande RTS antes de transmitir datos.
El CTS no se configura, es una consecuencia natural, es algo automático.
Todos los equipos de hoy cumplen con la norma, si reciben un RTS ya saben q hacer.
En la práctica
Bueno, se deriva de esto que lo único que hay que hacer es configurar en los equipos clientes (o sea los diferentes puntos que tienen antenas direccionales apuntando a una omni de un nodo central) que tiren RTS antes de intentar hablar.
¿Por que NO se configura que el nodo central tire RTS? Porque no tiene sentido, si lo pensamos un poco, los equipos clientes nunca van a estar "ocupados" con otra transmisión que no sea con el nodo central.
Efecto Nodo Oculto
Supongamos el diagrama siguiente:
equipo cliente A <·······> nodo central B <·········> equipo cliente C
A tiene que mandar RTS ya que puede ser que justo B este hablando con C, y A no puede saberlo de otra manera (C en este caso es un nodo oculto para A)
Inversamente, C también debería pedir permiso para hablarle a B. (Si configuramos RTS en A y no en C, puede darse el caso problemático de que A no pueda hablar con B mientras habla C, ya que C nunca pide permiso y no le da oportunidad a B de tirarle un CTS a A.
Moraleja: al armar un sistema de RTS, es crucial implementarlo en -todos- los clientes. El que no lo implemente va a atropellar a todos los demás).
Si ponemos RTS en ambos A y C, entonces cada uno pide permiso y el que maneja los tiempos es B, respondiendo CTS alternadamente a A y luego a C, de nuevo a A, etc. como debe ser.
Ahora, si ponemos RTS en B, B le va a preguntar a A si le puede hablar, y A siempre va a responder que si, porque no hay otra posibilidad. Entonces generamos un overhead de trafico innecesario (los paquetes RTS y CTS son pequeños pero muchos).
Conclusión
Buscá en la configuración del equipo un parámetro que se llame "RTS Threshold", "RTS/CTS" o algo relacionado, te pide un numero entre 0 y 2346 (Ese numero es el tamaño máximo de paquete que va a transmitir sin pedir permiso). Si el paquete es mas grande que ese numero, entonces manda RTS y espera un CTS, y recién ahí manda el paquete.
2347 es equivalente a desactivarlo.
Menos de alrededor de 256 no tiene sentido, porque el paquete de datos es casi mas cortito que el pedido de permiso.
Entre esos números, podes ir probando, ejemplo 512, etc y viendo cual te da mejor resultado.
Ese tuneo final es 100% empírico y puntual de cada escenario.
Esto siempre es en equipos clientes, nunca vas a poner RTS en un equipo puesto en modo AP con una omni, por lo explicado al principio.
Si implementas con Linux embebido, lo configuras con "iwconfig wlan0 rts 512" por ejemplo, si la interfaz se llama wlan0 y le estas poniendo de parámetro 512.
Véase también
De lo expuesto en estas páginas se llega a la conclusion de que al final RTS/CTS no es tan efectivo y no soluciona todos los problemas para nada, pero se puede "zafar" un poco para una estructura de red bien simple, como un AP con una omni y 6 o 7 clientes con antenas direccionales, y -nada mas-. Si ya tenemos 2 aps haciendo WDS; o en redes ad-hoc, etc.. el RTS no sirve para nada, incluso empeora la situacion agregando overhead de paquetes. Ejemplo:
Como se puede observar, son escenarios de redes ad-hoc, en la que no hay un nodo central, sino que todos los ordenadores están en igualdad de condiciones.
idea GuidoIribarren, editado y publicado por YairAdi
