2010-01-08 22 views
15

Pregunta sobre el protocolo MAC de 802.11 Wifi.¿Por qué esperar tiempo SIFS antes de enviar ACK?

Hemos aprendido que cuando una estación ha recibido los datos, espera la hora de SIFS. Luego envía el paquete. Al buscar en línea, la razón que siempre se menciona es otorgarle a los paquetes ACK una mayor prioridad. Esto es comprensible ya que una estación primero tiene que esperar la hora DIFS cuando desea enviar datos normales (y DIFS es más grande que SIFS).

¿Pero por qué esperar? ¿Por qué no enviar inmediatamente el ACK? La estación sabe que los datos han llegado y que el CRC es correcto, entonces ¿para qué esperar?

Respuesta

11

Es teóricamente posible saber que el CRC es correcto al final exacto de los datos recibidos del cable, pero en la práctica, necesita acumular todas las muestras en el último bloque para ejecutar el IFF T, deconvolución, FEC, y finalmente, al final, después de obtener finalmente los datos de entrada de la forma de onda, ¿sabe usted que el CRC es correcto? Además, a veces es necesario activar el circuito de transmisión para enviar el ACK, lo que puede dificultar el rendimiento de recepción. Si cada paso en la cadena de procesamiento fuera instantáneo, y si el circuito de transmisión definitivamente no interfiriera con el circuito de recepción, y si no hubiera un tiempo de entrega necesario para construir la forma de onda para el ACK, sería posible enviar el ACK inmediatamente después de obtener el último bit de la forma de onda. Pero, aunque cada elemento de esta cadena requiere un tiempo determinista, no es instantáneo. SIFS le da tiempo al receptor para obtener los datos de la PHY, verificarlos y enviar la respuesta.

Descargo de responsabilidad: Estoy más familiarizado con Homeplug que con 802.11.

+0

Esto parece ser confirmado por un enlace que encontré: http://protocols.netlab.uky.edu/~calvert/classes/571/lectureslides/WiFi.pdf En estados que "SIFS = Tiempo requerido para que la estación detecte" final del cuadro y comenzar a transmitir ". – Omega

+0

SIFS es para dar a los diseñadores de hardware un límite sobre cuánto tiempo pueden dedicar a decodificar y verificar el marco. Esto es necesario porque 802.11 originalmente era estrictamente entrega ordenada, por lo que el remitente no puede pasar al siguiente paquete hasta que tenga un ACK para el actual o se haya rendido. Para obtener un rendimiento razonable, el receptor debe tener un tiempo máximo de respuesta en el ACK. –

0

No puedo asegurarlo, pero suena como una estrategia de optimización similar a la IP. Si no necesita un ACK para cada paquete de datos, tiene sentido esperar un poco para que, si llegan más paquetes de datos, puede reconocerlos todos con un único ACK.

Ejemplo: el cliente envía 400 paquetes realmente rápido al servidor. En lugar de que el servidor envíe 400 ACK, simplemente puede esperar hasta que el cliente tome un respiro antes de devolver un solo ACK. Combinado con la probabilidad de que el cliente tome tome un respiro incluso bajo una carga pesada (tiene que hacerlo a medida que se llena el buffer de paquetes no reconocidos), esto sería factible.

Esto es posible en sistemas donde el ACK(n) significa "todo lo que he recibido hasta e incluyendo el paquete # n.

Usted obtendrá un mejor rendimiento y menos tráfico mediante el uso de una estrategia de este tipo. Mientras el wait-before-sending-ack time en el receptor es menor que el tiempo de retransmisión-si-no-ack-before en el emisor (teniendo en cuenta los retrasos de transmisión), no debería haber ningún problema.

+0

Tengo la impresión de que el ruido es un problema importante y que los marcos se dividen más a menudo en fragmentos más pequeños que se envían en ráfaga. Para cada fragmento, el receptor enviará ACK para confirmar para que solo los fragmentos defectuosos sean retransmitidos. –

+0

Así es como funciona el bloque ACK 802.11, pero la especificación original tiene SIFS y no tiene bloque ACK. Además, hasta que se agregaron MPDU, 802.11 fue estrictamente en el orden de entrega. –

3

Es así porque la modalidad de función de coordinación distribuida (DCF) y la función de coordinación de punto (PCF) puede coexistir dentro de una celda. Esa es una estación base que puede usar el sondeo mientras que al mismo tiempo la célula puede usar la coordinación distribuida usando CSMA/CA.

Por lo tanto, durante SIFS, pueden enviarse marcos de control o el siguiente fragmento. Durante PIFS, pueden enviarse tramas PCF y durante DIFS pueden enviarse tramas DCF. Durante SIFS y PIFS, PCF puede hacer su magia.

Aunque no todas las estaciones base admiten PCF, todas las estaciones deben esperar, ya que algunas pueden admitirlo.

Actualización:

mi modo de entender esto ahora es que durante la estación de SIFS puede enviar RTS, CTS y ACK y tener tiempo suficiente para cambiar de nuevo al modo de recepción antes de que el emisor comienza a transmitir. Si eso es correcto, enviará ACK durante SIFS. Luego cambiará al modo de recepción y esperará hasta que SIFS haya transcurrido. Cuando SIFS haya transcurrido, el transmisor comenzará a enviar.

Además, PCF está controlado por PIFS que viene después de SIFS y antes de DIFS y por lo tanto no es relevante para esta discusión (error mío). Es decir, SIFS < PIFS < DIFS < EIFS.

Fuentes: This PDF (page 8) y Computer Networks by Andrew S. Tanenbaum

+0

En ambos modos (DCF y PCF) no se envía nada durante el SIFS. Cada protocolo siempre espera el tiempo SIFS antes de enviar un fragmento. Por lo tanto, esto no explica por qué (léase: DCF y PCF) no enviaría el ACK inmediatamente después de recibir los datos. – Omega

+0

@Omega: La cosa es que una estación base debe admitir DCF, pero opcionalmente puede admitir PCF. Otras estaciones deben ser compatibles con DCF y pueden admitir PCF. Si no son compatibles con PCF, tienen que esperar, ya que otros pueden soportarlo. –

0

rápido curso rápido sobre 802.11:

802.11 es una esencia, un sistema gigante de temporizadores. Las implementaciones más comunes de 802.11 utilizan la función de coordinación distribuida, DCF. El DCF permite que los nodos entren y salgan del alcance de un canal de radio que se usa para 802.11 y coordina de forma distribuida quién debe enviar y recibir datos (ignorando los problemas de nodo oculto y expuesto para esta discusión). Antes de que un nodo pueda comenzar a enviar datos en el canal, todos deben esperar un período de DIFS, en el que se determina que el canal está inactivo; si está inactivo durante un período DIFS, el primer nodo que capta el canal comienza a transmitir. En el estándar 802.11, es decir, las implementaciones que no son 802.11e y las que no son 802.11n, cada paquete de datos individual que se transmite debe ser reconocido por una capa física, PHY, paquete de acuse de recibo, independientemente del protocolo de capa superior que se utilice. Después de que se envía un paquete de datos, un período de SIFS debe expirar, una vez que SIFS expira, pueden enviarse marcos de control destinados al nodo que tiene el control "tomado" del canal, en este caso se transmite el marco de acuse de recibo. SIFS permite que el nodo que envió el paquete de datos cambie de modo de transmisión a recepción. Si un paquete se pierde y no se recibe ACK después de que se produce el tiempo de espera de SIFS/ACK, se invoca el retroceso exponencial. El retroceso exponencial, a.k.una ventana de contención (CW), comienza en un valor CWmin, en algunas implementaciones de Linux esto es 15 veces de ranura, donde el tiempo de ranura varía según el protocolo 802.11 que se esté utilizando. El valor CW se elige de 1 a cualquiera que sea el límite superior que se haya calculado para CW. Si se perdió el paquete actual, entonces el CW se incrementa de 15 a 30, y luego se elige un valor aleatorio entre 1 y 30. Cada vez que hay una pérdida consecutiva, CW dobla hasta 1023, momento en el que golpea un límite. Una vez que un paquete se recibe con éxito, CW se reinicia a CWmin.

Con respecto a 802.11n/802.11e: Todos los paquetes de datos aún deben reconocerse, pero cuando se usa 802.11e (implementado en 802.11n) se pueden agregar múltiples paquetes de datos de dos maneras diferentes A-MSDU o A -MPDU. A-MSDU es un jumbo-frame que tiene una suma de comprobación para todo el paquete agregado que se envía, dentro de él hay muchos subtramas que contienen cada uno de los marcos de datos que se deben enviar. Si hay algún error en la trama A-MSDU y necesita retransmitirse, entonces se requiere que cada subtrama sea reenviada. Sin embargo, cuando se utiliza A-MPDU, cada subtrama tiene un pequeño encabezado y suma de comprobación que permite que cualquier subtrama que tenga un error se retransmita por sí misma/dentro de otro marco agregado la próxima vez que los nodos emisores ganen el canal . Con estos esquemas agregados de envío de paquetes existe la noción de bloqueo de bloqueos. El bloqueo de bloque contiene un mapa de bits de las tramas a partir de un número de secuencia de inicio que se acaba de enviar en el paquete agregado y se recibió de forma correcta o incorrecta. El uso del envío de cuadros agregados mejora en gran medida el rendimiento, ya que un nodo emisor puede enviar más datos por adquisición de canales, lo que también permite el envío de paquetes fuera de orden. Sin embargo, el envío de paquetes fuera de orden complica mucho la capa de MAC 802.11.

0

SIFS = D + M + Rx/Tx

Cuando,

D = (retardo del receptor (retardo de RF) y decodificación de procedimiento de convergencia de capa física (PLCP) preámbulo/cabecera)

M = (retardo de procesamiento MAC)

Rx/Tx = (tiempo de respuesta del transceptor)

Por encima de todos los retrasos no se puede evitar por lo que tiene que esperar el tiempo SIFS antes de enviar de acuse de recibo

1

SIFS = RTT (basado en la tasa de transmisión PHY) + trama de procesado RETRASO en el receptor (PHY PROCESAMIENTO DELAY + MAC PROCESAMIENTO DELAY) + FRAME retardo de procesamiento (para componer RESPUESTA CTS/ACK) + RF sintonizador DELAY (CAMBIO DE RX a TX)

A del lado del transmisor, después del último símbolo PHY (de RTS, por ejemplo), el tiempo requerido para cambiar al modo RX (a RF). Entonces, vería SIFS como un cálculo de lado de RX que un lado de TX.

Cuestiones relacionadas