La presente información toma como base un artículo de Lynn KJ4ERJ traduciéndolo y adaptándolo con información actual.
URL original: http://aprsisce.wikidot.com/doc:aprs-messaging-explainedComo sabrás, APRS utiliza tramas UI de Packet Radio (AX25) para funcionar. Son tramas sin conexión, sin orden entre ellas y sin garantizar que lleguen al destino. Básicamente en APRS una estación lanza una transmisión al aire y no tiene la certeza de que sea recibida por otra estación. Esto es correcto para un sistema de balizas, pero no es bueno para utilizarlo como mensajería. APRS utiliza unas «vías (path)» similares a las que usábamos en Packet Radio, pero puede contener alias para saber los indicativos de los digipeaters por los que ha pasado.
Bien. Un mensaje APRS se manda como una trama sin identificar (UI) pero el destinatario del mensaje, no está en la cabecera de AX.25, sino en los datos que le siguen, delimitado por el símbolo de dos puntos «:» (por ejemplo :EB2DJB-7:). Se pueden mandar solicitando una confirmación de recepción o no. Si se pide confirmación (ACK) el emisor del mensaje, pondrá «{xxxxx» al final del mensaje de texto. La confirmación será otra trama diferente enviada por el destinatario del mensaje dirigido al emisor del mensaje con el texto «ackxxxxx».
SIMPLEX en Radio… 144.800 Mhz.
El escenario mas sencillo, son dos estaciones que se escuchan entre si en radio: la estación emisora lanza el mensaje APRS. El receptor tiene que escuchar la trama, decodificarla correctamente en algún tipo de TNC (AX.25 lleva checksum para verificar que el contenido es correcto), y opcionalmente crear un mensaje de confirmación «ack» que enviar al remitente por radio RF, que éste tendrá que recibir, decodificar correctamente y casarla con el mensaje original, para así mostrar al remitente, que su mensaje ha sido recibido. El cliente APRS incorporará un número de reintentos hasta que escuche el ack. …y ¡¡éste es el caso mas sencilo!!…
A través de APRS-IS (el lado Internet del APRS)
No hay un servidor central APRS como algunos piensan. APRS-IS es una red de servidores donde las tramas APRS fluyen entre ellos en tiempo real y sin que éstos almacenen la información. Sitios como aprs.fi ó findu.com no son parte de APRS-IS, solo monitorizan el tráfico que circula entre los servidores APRS-IS, la almacenan en una base de datos y la muestran a los usuarios.
Para poder enviar información a un servidor APRS-IS es obligatorio configurar un PASSCODE que es diferente según el indicativo. Si tienes puesto -1 o uno que no sea el tuyo, el servidor rechazará todas las tramas que mande el iGate. Y esto, también afecta a la mensajería.
Por lo tanto, enviar un mensaje APRS desde una estación conectada a un APRS-IS a otra estación conectada a otro servidor APRS-IS es como la situación en simplex descrita arriba, pero sin necesitar TNC y evitando la repetición por haber recibido un checksum erroneo. Así que el servidor APRS-IS únicamente entrega «buenas» tramas. Además, el receptor del mensaje, tiene que estar conectado. Aún no hay la posibilidad de almacenamiento en la Red de APRS.
¿Como funciona en sentido RF -> IS? ¿Qué es un iGate? ¿Cómo influye en la mensajería?
Un iGate es una estación de APRS con equipo de radio (RF) que escucha las tramas en radio (144.800 Mhz), las decodifica, valida su checksum y las inyecta a un servidor APRS-IS para su difusión.
La red de servidores, dispone de un sistema para detectar información duplicada (una trama que haya llegado a dos iGates diferentes) y en el caso de los mensajes, ocurre lo mismo… por lo tanto todos los mensajes están presentes en la red, siempre que lo haya escuchado al menos un iGate. Ésta es la parte receptora de un iGate, y en la mayor parte de los casos funciona correctamente.
La otra parte, es la pasarela del servidor de Internet a Radio (IS -> RF). Cualquier información (no solo los mensajes) puede configurarse para que salga en radio en un iGate determinado. Pero ten en cuenta, que el servidor APRS-IS es mucho más rápido que una conexión AX.25 a 1200 baudios, por lo tanto, no va a poder salir toda (aparte que tampoco es el objetivo), así que no todos los mensajes salen a Radio.
El iGate, mira que estaciones han sido escuchadas en Radio, mantiene una lista (habitualmente, los últimos 30 minutos), y únicamente los mensajes escuchados en un servidor APRS-IS cuyo destinatario esté en la lista, serán pasados al puerto de Radio.
Así que para que una estación APRS-IS envíe un mensaje a otra estación en Radio, el software cliente APRS crea el mensaje y lo inyecta al servidor APRS-IS. Este mensaje se difunde a todos los servidores APRS-IS, y los iGates conectados comprobarán a ver si va dirigido a una estación que ha escuchado recientemente, caso en el que emitirá la trama en Radio. Si son varios los iGates que le han escuchado, saldrá por todos ellos. Bueno, concretamente, no todos los iGates sino aquellos que hayan sido configurados para pasar mensajes de Internet a RF.
Una vez que el mensaje está en Radio, la estación receptora tiene que escuchar la trama, decodificarla, validar el checksum y devolver un ACK si lo ha pedido el remitente. Esta parte, es idéntica al caso RF Simplex descrito anteriormente, pero en este caso el ACK tiene que escucharlo un iGate (puede ser cualquiera, no necesariamente el que ha emitido el mensaje), decodificarlo, validar e inyectar la trama de nuevo en la Red APRS-IS para que la estación emisora lo reciba y pare de repetir el mensaje.
Así que para el sentido APRS-IS -> RF, necesitamos al menos un iGate bidireccional que haya escuchado a la estación destino recientemente.
La secuencia completa
Imaginemos dos estaciones, una en Bilbao (origen) y otra Vitoria-Gasteiz (destino). No es escuchan en radio y no hay un digipeater que escuchen ambas. Por lo tanto, necesitaría el apoyo de la Red APRS-IS.
Sería así:
- La estación origen crea el mensaje APRS para el destino.
- Un iGate lo escucha, decodifica, verifica checksum y lo inyecta a un servidor APRS-IS
- El mensaje llega a toda la Red de servidores, incluso al que está conectado el iGate de destino.
- Con suerte, ese iGate ha escuchado recientemente una trama de la estación destino y éste iGate está configurado para pasar los mensajes de Internet a Radio.
- El iGate transmite el mensaje en radio en destino
- Con suerte, el receptor del mensaje lo escucha, lo decodifica, verifica checksum y lo visualiza al operador.
- Como la mayor parte de las veces, se piden ACKs, la estación receptora crea el mensaje de confirmación ACK y lo envía por Radio.
- Repetir el paso 2 en Vitoria-Gasteiz
- Repetir el paso 3 en Bilbao
- Repetir el paso 4 en Bilbao
- Repertir el paso 5
- Repetir el paso 6 pero no lo muestra al operador, solo marca el mesaje como recibido, y para de retransmitirlo.
Asi que ya ves que para que todo ésto funcione tiene que:
- Haber iGates instalados
- estar configurados correctamente (pasar mensajes de Internet a RF)
- escuchar las tramas sin errores de checksum
Ahora, imagínate todo ese «paseo» para cada mensaje de una conversación por mensajería, y podrás valorar el milagro que los QSO’s por APRS representan.
Somos Radioaficionados, y nos gustan los retos… 😀