DAMA
¿un nuevo método de trabajar en Packet?

Ponencia realizada por EA5DOM en SYSEA'92.
Publicado en: DIGICLUB Nº 6, Octubre 1992.

Texto original de Detlef J. SCHMIDT, DK4EG. ARRL: Octava Conferencia de Redes de Ordenadores, 7 de Octubre de 1989. Re-edición: Pierre Cornelis, ON7PC. Traducción: Luís Fernández, EA5DOM.

Parece que de un tiempo a esta parte cada vez hay más y más estaciones que se quejan de problemas para usar su nodo local o digipiter. Por lo visto, los usuarios no tienen problemas para escuchar el nodo, pero el nodo no parece escucharlos a ellos de ninguna manera. Los síntomas parecen corresponder a que el receptor del nodo está "frito" o algo parecido. A pesar de que este tipo de fallo siempre es una posibilidad a tener en cuenta, este no es el tema de nuestro artículo.

El caso que vamos a tratar en este artículo es aquel en el que ocurren los síntomas anteriormente descritos, pero no debido a ninguna falta de sensibilidad del receptor. Por el contrario el problema se debe a que el receptor está escuchando demasiadas señales al mismo tiempo, y el usuario que llega bajito desde muy lejos se pierde irremediablemente en el "ruido".

El que esto ocurra es algo obvio si consideramos que mientras que todos los usuarios pueden estar escuchando el nodo bastante bien, en muchos casos no se escuchan entre ellos. Por lo tanto, en algunas ocasiones más de una estación transmitirá al mismo tiempo, provocando colisiones de paquetes. Esta situación se denomina problema de "estaciones ocultas", y para los usuarios más alejados el acceso a su nodo favorito se convierte en difícil o imposible durante las horas de más actividad.

Este no es un problema nuevo, y de hecho hay otros servicios que también lo sufren. Un ejemplo puede ser el de los barcos en alta mar intentando acceder a un satélite de comunicaciones.

Se han realizado varios experimentos diferentes para solucionar este dilema en el Radio Packet. Una posible solución que ha sido apuntada es a través del uso de repetidores full duplex (BTMA), sin embargo hay muchas desventajas en este sistema. En las instalaciones "full duplex" los costes de equipos suelen ser mucho más altos y el sistema ocupa dos frecuencias pero solamente usará una con el máximo rendimiento. Una solución mejor puede ser aumentar el rendimiento del canal a base de reducir las colisiones en un canal único, en vez de dividir el tráfico en dos canales. Sería ideal si pudiésemos incorporar un sistema capaz de trabajar de esta forma simplemente cambiando el software (o sea, cambiando la EPROM de una TNC) o modificando algunos parámetros.

Uno de los métodos usados que intenta solucionar el problema de las estaciones ocultas manteniendo a la vez una única frecuencia es el DAMA (Demand Assigned Multiple Access). La descripción de este método es la siguiente:

Trabajando con un protocolo orientado a la conexión, un usuario final intentará conectar con la estación principal (satélite) mediante un método basado en "huecos" (ALOHA = Acceso al canal sin coordinación alguna). Se pueden producir colisiones durante esta fase, pero son tolerables por ser relativamente escasas. Una vez que la petición de conexión es reconocida por la estación principal, el indicativo de la estación que se conecta se incluye en la lista de estaciones activas y de esta forma la estación principal controla a todas las que están conectadas. La autorización para enviar datos se garantiza mediante el empleo de peticiones que pueden estar incluidas en paquetes de tipo ACK o incluso dentro de paquetes de datos en plena transferencia. Por lo tanto en este caso, a un usuario sólo se le permitirá transmitir después de recibir la correspondiente autorización de la estación principal. Una vez que se reciba esta autorización se pueden enviar varios paquetes en un solo bloque. Sin embargo, si el usuario no responde en un tiempo establecido (digamos 1/2 segundo) entonces la estación principal supone que el usuario no llegó a recibir la autorización para transmitir. La estación principal va pasando entonces la autorización para transmitir a todos los demás usuarios de la lista de estaciones activas, y una vez terminada vuelve a atender al primer usuario y le da otra oportunidad.

Por otra parte, si un usuario recibe en un momento dado la autorización para transmitir (poll) y contesta enviando un paquete tipo I, la estación principal (master) no confirmará este paquete hasta que vuelva a tocarle el turno en la lista después de haber servido a todas las demás estaciones activas. Si cuando es autorizado por la estación principal, el usuario responde con un paquete vacío (Receive Ready/Final), entonces la estación principal reducirá la prioridad de autorizaciones para dicho usuario y se lo saltará de la lista en el siguiente turno.

Cuando la actividad en el canal aumente, la prioridad de autorizaciones para las estaciones inactivas puede bajar aun más, pero cuando esta estación responda con un paquete tipo I recobrará otra vez su prioridad original.

Si has entendido lo que se ha explicado hasta el aquí, puedes pensar que se está hablando de protocolo AX.25 nivel 2 y esta es la razón por la que DAMA puede aplicarse al Packet Radio. El protocolo AX.25 nivel 2 proporciona todos los elementos necesarios para implementar el DAMA y no es necesario emplear una nueva sintaxis. La mayoría de las nuevas funciones que hacen falta se pueden obtener simplemente modificando los actuales parámetros operacionales mientras que el resto se lograría a través de pequeños cambios en el firmware (EPROM) de las TNCs.

Por lo tanto, ¿cómo podemos incorporar el protocolo DAMA al AX.25?

Debido al hecho de que no se necesita una nueva sintáxis, la siguiente descripción solamente empleará términos comunes del AX.25. Ya que se va a emplear CSMA (CSMA= Carrier Sense Multiple Access= Acceso Múltiple por Detección de Portadora) así como también DAMA, entiéndase que todas la referencias futuras a DAMA son a CSMA-DAMA. El término "poll" usado en este texto (N del T: Traducido como: "autorización/petición de transmisión") no hace referencia de ninguna manera al bit de "poll" en el campo de control de los paquetes de AX.25, y este bit permanece inalterado para asegurar la compatibilidad. Las diferentes fases del protocolo serán descritas de forma independiente a continuación:

Estableciendo la conexión

Cuando un nodo intenta una conexión con un usuario, el nodo incluye el indicativo del usuario en la lista y empieza a enviar solicitudes de conexión a esa estación. Si después de un cierto número de intentos, no se recibe ningún paquete UA de la estación, el usuario se asume como "inoperable" y se elimina de la lista.

Cuando un nuevo usuario empieza una secuencia de conexión al nodo, comienza enviando paquetes SABM a la estación principal (nodo) en modo CSMA normal, tal y como lo hacemos hoy día. Se pueden producir colisiones durante esta fase, por lo tanto puede que sea necesario repetir los SABM varias veces hasta que el nodo conteste con UA. Una vez que el nodo reconoce el intento de conexión del usuario, su indicativo es añadido a la lista de una manera muy similar a la empleada por los nodos TheNet para la lista de usuarios, y así el nodo toma el control de las transmisiones de los usuarios. Después de que el usuario envía un SABM y el nodo le responde con un UA, el usuario contesta con RR0 para indicar al nodo que ha recibido correctamente el UA.

Estado inactivo

Mientras no exista ninguna transferencia de información entre el usuario y el nodo (inactividad), el nodo enviará sus autorizaciones de transmisión como un RR con el correspondiente número de conteo. Si la respuesta por parte del usuario es simplemente un RR#, entonces el tiempo transcurrido hasta la siguiente autorización para transmitir se alargará para evitar una carga innecesaria del canal. La cantidad exacta de tiempo a añadir depende de la actividad total del canal.

Si la transferencia de información de otros usuarios simultáneos del nodo es grande (determinada por el número de paquetes I enviados) entonces la cantidad de tiempo añadido antes de atender a una estación "inactiva" de la lista es mayor que en el caso en el que haya poca actividad en el canal. Eso quiere decir que cuando la frecuencia está prácticamente vacía, los tiempos de espera se reducen a un mínimo, con lo que no se produce una reducción de prestaciones en el nodo. Este es el principio del mecanismo de auto-regulación del DAMA, que asegura que un canal sea siempre empleado con sus máximas prestaciones.

Si alguna vez el nodo no recibe un RR del usuario (debido a colisiones con el envío de autorización a transmitir o de respuestas RR de otros usuarios) entonces el nodo pasará a atender a la siguiente estación de la lista. El nodo volverá a atender a esta estación cuando haya acabado con todas las demás de la lista. Si después de un cierto número de intentos enviando la autorización a transmitir esta estación aun no ha contestado, se le considerará fuera de alcance del nodo y se eliminará completamente de la lista. Esto es como decir que hay que mantener la estación activa contestando a las solicitudes del nodo para no quedar excluidos.

Transferencia de datos: Nodo ---> Usuario

No existen diferencias entre el CSMA normal y el DAMA en este caso. Ya que siempre va a ser la estación principal (nodo) la que actúe primero, puede enviar uno o más paquetes I, o una autorización para transmitir, al usuario. El usuario confirmará los paquetes I inmediatamente con un RR#, pero también puede enviar sus propios paquetes I con el correspondiente número de conteo. (El tener que corregir el número de conteo de los paquetes I enviados tiene el mismo propósito que los paquetes ACK en AX.25). El significado del bit de "Poll/Final" permanece invariable.

Transferencia de datos: Usuario ---> Nodo

Como hemos dicho anteriormente, el nodo enviará autorizaciones para transmitir a todos los usuarios que se encuentran conectados (en lista) y estos usuarios no responderán hasta que reciban esta autorización o un paquete I del nodo. Parece lógico indicar que cuando un usuario es autorizado a transmitir, siempre debe contestar con algún tipo de respuesta, incluso un RNR#. Si el nodo falla y no recibe respuesta del usuario entonces supone que algo funciona mal (se ha producido una colisión) y salta al siguiente usuario de la lista.

Este sistema de esperar siempre una autorización por parte del nodo para transmitir es el fundamento para evitar colisiones en casos donde existan estaciones ocultas entre sí (que no se escuchan). Esto contrasta con el método actual de CSMA, donde varias estaciones pueden transmitir a la vez. De forma adicional se ha solventado también el problema de las colisiones en "tiempo muerto". Por "tiempo muerto" se entiende el periodo que transcurre desde que la TNC determina que el canal está libre y comienza a transmitir, hasta que lleva en el aire el tiempo necesario para que otras TNCs detecten su portadora. Este no es ningún caso raro, y se puede ver en el ejemplo de una o más TNCs que están esperando a que la portadora de un nodo desaparezca para transmitir en la frecuencia. Usando DAMA el nodo NO confirmará los paquetes recibidos en el instante en que sean escuchados. En lugar de ello primero atenderá a todas las demás estaciones de la lista y luego responderá con un RR# a las estaciones que hayan enviado paquetes I junto con una autorización de transmisión para dichas estaciones. Esta autorización viene a significar "¿Tienes alguna otra cosa para mi?".

Desconexión

Si la estación principal quiere cortar la conexión, enviará el paquete habitual de DISC al usuario. El usuario responderá entonces rápidamente con un paquete UA (con el bit de final activado). Si el nodo no recibe el UA y vuelve a enviar el paquete DISC, el usuario responderá con un paquete DM. Esto funciona igual que en la versión actual de CSMA.

Cuando sea el usuario el que quiera desconectarse del nodo, esperará a enviar su paquete DISC hasta haber sido autorizado por el master. En este caso no hay diferencia entre que el nodo responda al usuario directamente con un UA o se espere al siguiente turno para hacerlo. Sin embargo es preferible una contestación inmediata de UA por parte del nodo.

Paquetes tipo UI

Tanto en CSMA como en el entorno DAMA, los paquetes tipo UI se manejan de una manera especial debido a que estos paquetes se emplean para pasar información al margen del protocolo normal usado. Normalmente los paquetes UI nunca se envían desde un usuario al nodo, y no es una práctica recomendable el llevar a cabo QSOs directos en modo desconectado en la frecuencia de entrada de un nodo. Sin embargo, a diferencia de un sistema duplex, actualmente es posible hacerlo. O sea que aunque los paquetes UI reducirán las prestaciones de un sistema CSMA, no será tan catastrófico como si ocurriese en un sistema duplex que tenga un QSO en su frecuencia de entrada. Los paquetes UI originados por el nodo no son un problema, ya que todas las estaciones los reciben. (Todas detectan Carrier).

Otros elementos del protocolo

Hemos recorrido de principio a fin toda la descripción de un sistema DAMA. No hemos traducido todos y cada unos de los elementos del AX.25 a uno que tenga un significado especial para el DAMA. Esto no es necesario ya que muchos de ellos conservan su significado original. DM, RNR, REJ, etc., se usarán de la misma forma que antes. La única desviación de la versión pura del CSMA es de hecho el que los usuarios sólo podrán transmitir estos paquetes después de haber recibido una autorización del nodo (master). El nodo solamente transmitirá este tipo de paquetes después de haber atendido a todos los usuarios en lista.

Compatibilidad entre DAMA y CSMA

Una ventaja del método DAMA es que no implica el que todo el mundo cambie todo de una sola vez. Por el contrario cuantos más usuarios modifiquen sus TNCs para trabajar en modo DAMA, más se notará el aumento de prestaciones del nodo. Incluso los usuarios que están a la espera de modificación pueden ayudar a la descongestión del canal ajustando unos cuantos parámetros. Por ejemplo, el retardo entre la recepción de un paquete y la confirmación de la TNC (a veces denominado D2 o DWAIT) debe ser reducido a un valor inferior a 1 segundo. Al mismo tiempo, el intervalo de tiempo entre que se envía un paquete I y la TNC envía un RR# para preguntar por un ACK pendiente, debe ser ajustado a un valor que sea claramente mayor que el tiempo entre dos autorizaciones a transmitir enviadas por el nodo (normalmente más de 30 segundos a 1200 Bd).

Para obtener las máximas prestaciones del DAMA nodo y usuarios deben trabajar juntos en un sistema tipo "master/slave". Suponiendo que la TNC del usuario es capaz de trabajar en modo DAMA y normal, aun tenemos el problema de como decir al usuario que cambie a "modo DAMA". Hay varias maneras de hacer esto:

Detección automática de la versión de protocolo mediante el byte de identificación de protocolo o el byte reservado de SSID del nodo (opción preferida).
Añadiendo un parámetro específico del canal que controle la versión de protocolo.
Añadiendo un nuevo comando UPLINK aparte del CONNECT, que sería empleado para acceder a nodos DAMA.
Añadiendo un elemento más al protocolo como los paquetes tipo SABM (similar al X.25) para que al conectar, el nodo avise al usuario de la existencia de nuevas características.

En caso de la opción #1 será suficiente decir al usuario que pase a modo DAMA una sola vez al realizar la conexión. De esta forma permanecería en ese modo hasta la desconexión. Sin embargo, ya que no existe campo de PID en los paquetes SABM esta información hay que enviarla de alguna otra forma, como pueda ser el utilizar el bit 5 del campo SSID del nodo. Se ha propuesto que las versiones de test de DAMA pongan este bit a 0 para dar a la TNC del usuario la información necesaria sobre el tipo de protocolo a emplear.

Conclusión

La versión existente de AX.25 se estableció en 1982 cuando el radio packet no estaba tan extendido como ahora. La mayoría de las estaciones pioneras eran muy similares y no había diferencias entre funciones DTE y DCE. Sin embargo con la puesta en marcha de redes con amplia cobertura no todas las estaciones están realizando la misma función. De hecho los nodos actuales están funcionando como DCE considerando sus aspectos de control y de intercambio de información. Estas funciones se podrán llevar a cabo mucho mejor mediante el empleo del DAMA.

Los métodos explicados en este artículo pueden aumentar las prestaciones de un canal de AX.25 tremendamente. Una ventaja es el erradicar la saturación del sistema que existe cuando se sobrecarga el canal. Empleando DAMA, las prestaciones del canal aumentan continuamente hasta alcanzar el máximo. No existe el efecto que se produce en CSMA, donde a un 60% las prestaciones caen en picado.

También se da un fuerte componente "social" en el DAMA, sistema en el que incluso las estaciones menos potentes pueden trabajar a través del nodo de forma decente sin ser chafadas por las estaciones cercanas al nodo.

Es posible mantener conexiones con otras estaciones en la frecuencia del nodo sin saturarlo, a diferencia de los sistemas duplex. Como añadido, las TNCs de los usuarios aun mantienen la función de digipiter propia de nuestros actuales sistemas simplex. Todos los elementos del protocolo mantienen su significado original, lo que posibilita que ambas versiones puedan coexistir en el mismo canal, y aun las prestaciones irán mejorando a medida que más y más usuarios cambien al nuevo sistema.

NOTA DE ON7PC:: El glosario y las referencias bibliográficas no se incluyen.
Nota de DB2OS:: El protocolo DAMA se encuentra totalmente implementado en la última versión de TheNetNode (TheNet para PC) como DAMA MASTER y TheFirmware (WA8DED Hostmode para TNC) como DAMA SLAVE por NORD><LINK. El protocolo DAMA está también soportado por TFPCX, un software residente para PC emulador de TNC AX.25 (sólo se necesita un modem externo, no TNC) y el último software DIGICOM para C64. El protocolo DAMA se está empleando actualmente en varios nodos Alemanes y los resultados son francamente prometedores.
Nota de EA5SW:: Al parecer el DAMA SLAVE está implementado también en la versión 1.5A de Baycom.

[Todo el software anterior estará disponible en SYSEA'92]

Fédération Digitale EA

DIGICLUB

DAMA¿un nuevo método de trabajar en Packet?

DAMA
¿un nuevo método de trabajar en Packet?