El Blog de Pablo Serrano

La ironía no funciona en los blojs

Calculando el máximo número de conversaciones en 802.11b (I)

El proceso de transmisión de una trama en 802.11 viene a ser una cosa tal que así (véase la Estación A):

dcf_backoff

Eso es: se espera un tiempo DIFS, se transmite la trama, y la entidad receptora emite un asentimiento (ACK) cuando ha pasado un tiempo SIFS.

En el mejor caso posible, todo el tiempo disponible lo emplearemos para la transmisión de tramas. Esto es: ni colisiones, ni proceso de backoff (representado en la figura por los numeritos, y que intenté explicar aquí). En el mejor caso posible (repito), las estaciones “se coordinarán” (¡magia!) para que al llegar una trama el medio justo esté libre, y transmitir sin mayor complicación.

Pues bien, ni aún así tendremos 86 conversaciones de voz (cálculo incorrecto explicado aquí).

¿Cuántas caben como mucho? Veamos:

Supongamos una fuente de generación constante de paquetes a 64 Kbps: 80 bytes cada 10 ms (codificación bastante común). Para poder transmitir el tráfico con éxito, debo tener un hueco de 80 bytes cada 10 ms. Si tengo N conversaciones (y son bidireccionales, recuérdese), debo tener 2xN huecos de 80 bytes cada 10 ms. ¿Cuánto ocupa un hueco? Para 802.11b tenemos lo siguiente:

  • DIFS: 50 us.
  • SIFS: 10 us.
  • Preámbulo de Trama y ACK: 96 us (seamos optimistas).
  • Ack: 14 octetos.
  • Cabecera de trama. 34 octetos.

Supongamos una tasa de 11 Mbps. Entonces, transmitir 80 bytes cuesta… unos 350 microsegundos. Luego la ecuación a despejar es la siguiente:

2 x N x 350 = 10.000

Total, que en el mejor de los mundos posibles, caben 14 conversaciones de voz.

Cosas que me he dejado en el tintero

  • El factor de actividad (la gran mayoría de nosotros no estamos siempre hablando). Pero eso no significa que nuestra aplicación de VoIP no transmita… (a veces hay que pasar un NAT)
  • El uso de otros codificadores: los 80 bytes no son un problema (aportan muy poco a la duración total de la transmisión), los 10 ms sí que resultan más importantes.
  • El impacto de las colisiones y proceso de backoff (es una situación irreal)
  • La ausencia de garantías en el servicio (sólo nos hemos preocupado de que quepa, nada más)

Agosto 24, 2006 Publicado por pabloserrano | Tecnología para pillar | | 5 comentarios