APRS iGaten ominaisuudet

This document exists also in english: APRS iGate properties

APRS iGate on sovellus, joka kuuntelee radion kuulemia APRS paketteja ja välittää niitä internettiin APRS-IS verkkoon. Sovelluksen on myös mahdollista välittää paikkatietoja APRS-IS verkosta radiolle tietyin rajoituksin.

APRS iGate ei yleensä ole Digipeater, vaan siihen on eri sovellus. igate kuitenkin tyypillisesti ottaa paketteja vastaan myös samassa laitteessa toimivalta Digipeaterilta.

Rx-iGatelta vaadittavia ominaisuuksia

APRS-IS:n tekijöiden Gating criteria dokumentti kertoo oleellisimmat, tässä selostetaan hieman lisää.

APRS-IS verkkoon lähetettäessä kaikki paketit (= rivit) päätetään CR/LF-yhdistelmään. Jos paketissa itsessään on sisältönä CR tai LF merkkejä, katkaistaan paketti juuri ennen ensimmäistä tällaista merkkiä ja lisätään perään normaali CR/LF.

Radiolta paketteja vastaanotettaessa päätetään paketti ensimmäiseen vastaanotettuun CR:ään tai LF:ään.

Kaikkien bandilta kuultujen pakettien sisältö välitetään sellaisenaan (huomioi myös nollatavujen mahdollisuus pakettien sisällössä - vaikkakin C-koodit eivät niitä käytännössä tue!) APRS-IS:ään seuraavin poikkeuksin:

• Kaikkien pakettien headerit muutetaan tarvittaessa ns. TNC2-muotoon (mm. KISS-paketit ja PK232-formaattiset), eli LAHDE-4>KOHDE-5,POLKU*,POLKU2:paketin datasisältö. Jos polkuosa on tyhjä, lyhenee paketti muotoon LAHDE-4>KOHDE-5:paketin datasisältö. Jos SSID on nolla, jätetään SSID ja sitä edeltävä väliviiva pois. Tähti polussa olevan kutsun perässä tarkoittaa, että ko. paketin on kyseinen asema toistanut (ns. has-been-digipeated bitti). Tähditys on syytä säilyttää alkuperäisenä, iGatella ei siis lisätä eikä poisteta niitä.
• Ei välitetä APRS-IS verkkoon paketteja, joiden VIA-polussa esiintyy TCPIP, TCPXX.
• Jos paketin polussa missä kohdassa tahansa on merkkijono RFONLY tai NOGATE, ei pakettia välitetä. Lisäämällä tämän pakettinsa polkuun käyttäjä voi halutessaan kieltää paketin välittämisen APRS-IS:ään ja vastaavasti APRS-IS:stä radioverkkoon (jos lähettävä asema on suoraan TCP/IP-verkossa kiinni).
• Dataosaltaan '?'-merkillä alkavia (ns. generic query) ei välitetä APRS-IS:ään.
• Dataosaltaan '}'-merkillä (ASCII koodi 125) alkavia paketteja (ns. 3rd party) käsitellään erityisesti:
  • Pakettia käsitellään alusta uudestaan alkaen '}' merkin seuraajasta, jossa pitää olla TNC2 tekstimuotoinen osoite ja sitä seuraava paketti.
• CR/LF-käsittely kuten yllä on kuvattu, eli paketti päätetään ensimmäiseen CR:ään tai LF:ään.
• Hienompi sovellus voi lisäksi pitää kirjaa äskettäin sekä radioverkosta että internetistä "kuulluista" paketeista ja olla välittämättä jo kuultuja paketteja. Mahdollinen duplikaattipakettien tunnistusmekanismi kuvataan alla.

Lopuksi kaikkiin APRS-IS:ään välitettyihin paketteihin lisätään polkuosan loppuun "qAR," ja iGaten kutsu, esimerkiksi

"qAR,OH1YYY-3"

Eli bandilla kuultu paketti

"OH2XYZ-11>APZYXW-4,RELAY*,WIDE:>pakettia  "

välitettäisiin APRS-IS:ään muodossa

"OH2XYZ-11>APZYXW-4,RELAY*,WIDE,qAR,OH1YYY-3:>pakettia  "

(Huomaa myös, että kaikki välissä ja perässä olevat välilyönnit säilytetään sellaisenaan.)

"Q-konstruktioilla" kerrotaan että saako paketin välittää bandille vai ei. Lisätietoja: http://www.aprs-is.net/q.aspx

Duplikaattipakettien tunnistus

Jotta iGate (tai digipiitteri) ei tarpeettomasti toistelisi nettiin tai varsinkaan radiolle paketteja jotka se on saanut jo hiljattain jommasta kummasta suunnasta, se voi pitää kirjaa välitetyistä paketeista ja muistia säästääkseen näistä voidaan laskea tiiviste (hash, tarkistussumma).

Vertailtava paketti muodostetaan keräämällä kandidaatin "sisimmästä" AX.25 lähdeosoitteesta (call-ssid), kohdeosoitteesta (call, mutta ei ssid eikä myöskään polku) ja datakentän sisällöstä, mahdollisesti lopussa olevat välilyönnit (ja CR/LF) poistaen.

Jos esimerkiksi viimeisen 60 sekunnin aikana kuullaan sama paketti uudestaan, ei sitä tarvitse turhaan välittää.

Radiokanavan kapasiteetti on noin 8,000 merkkiä minuutissa, jolloin muistin säästäminen ei välttämättä ole hyvä perustelu tarkistussumman laskemiselle varsinkaan kun iGate on yleensä laite joka pyörittää Windowsia tai jotain UNIXia joilla muistin määrä lasketaan sadoissa miljoonissa merkeissä. Tavallisesti TNC:ssä implementoidut digipiitterit tutkivat 30 sekunnin aikaikkunaa, jolloin muistitarve on vastaavasti vähäisempi.

Paketin lopun välilyönnit jätetään tarkistussummalaskennassa huomiotta siksi, että jotkut iGate-ohjelmat lisäävät tai poistavat välilyöntejä pakettien lopuista, jolloin välilyöntien määrän vaihdellessa tarkistussumma voisi muuttua. Paketti kuitenkin välitetään aina alkuperäisen määrän välilyöntejä sisältävänä.

Esimerkiksi seuraavassa paketissa muodostuu sama vertailupaketti: "OH2XYZ-11>APZYXW:>pakettia":

"OH2XYZ-11>APZYXW-4,RELAY,WIDE:>pakettia  "
"OH2XYZ-11>APZYXW-4,OH3XYZ-3*,WIDE:>pakettia  "
"OH1YYY>APRS,WIDE:}OH2XYZ-11>APZYXW-4,TCPIP,OH1YYY*:>pakettia  "

Rx/Tx-iGatelta vaadittavia ominaisuuksia

Ensinnäkin: APRS-IS→RF iGate:n ei ole tarkoitus olla rakentajansa egon pönkittäjä ja liikkuvien asemien käyttämän kanavan tukkija

APRS-IS:n tekijöiden Gating criteria dokumentti kertoo oleellisimmat, tässä selostetaan lisää.

Kanavan tukkimisen välttäminen on tärkeää ja siksi kaksisuuntaisen iGate:n kanssa tarvitaan Rx-iGaten ominaisuuksien lisäksi seuraavia.

Kunnollinen suodatus internetistä radiolle välitettävälle liikenteelle:

• Ei välitetä radiolle paketteja, joiden polussa on ",qAX," tietoa — "tämän lähettäjä ei ole APRS-IS verkolle oikein tunnistautunut radioamatööri tai hänen iGatensa." (Lisätietoja: http://www.aprs-is.net/q.htm )
• Ei välitetä radiolle paketteja, joiden polussa esiintyy TCPXX, NOGATE tai RFONLY (Huom: TCPIP sallitaan!)

• Ei välitetä radiolle paketteja jotka on jo bandilla esim. viimeisen viiden minuutin sisään kuultu, joko suoraan tai jonkun toisen välittämänä (ks. tarkistussumma-algoritmi yllä). Ei välitetä bandille APRS-IS:stä saatuja paketteja jotka on jo kuultu bandilta tai jotka on lähetetty bandille viimeisen viiden minuutin sisään.
• Ei välitetä kovin kaukana iGaten kohdealueesta olevia paketteja radiolle yksinkertaisesti siksi, että ADSL-liittymänkin siirtonopeus on tyypillisesti vähintään tuhat kertaa suurempi kuin 1200 bps AX.25 APRS-kanavan. "Kaukopaketin" voi tunnistaa esimerkiksi sijaintipaketista lähettäjän sijainnin katsomalla ja laskemalla kuinka kaukana se on iGaten sijainnista. Tätä sijaintitietoa voi sitten hyödyntää myös muiden ko. lähettäjän pakettien suodattamiseen (esim. statuspaketit, bulletiinit, yms).
  • Käytetään area-filttereitä: vain 50 km säteellä olevat paikat, ei kauempaa! (Erittäin harvaan asutulla alueella 100-200 km, äärimmäisessä poikkeustapauksessa!)
  • Ei käytetä prefiksifilttereitä - Ei kaikkia OH-asemia!
• Pääsääntöisesti välitetään bandille ylipäätään vain kohdealueelle kuuluvaa paikkatietoa sisältäviä paketteja, ei telemetriaa tai muuta kohinaa joissa ei ole paikkatietoa.
• Poikkeuksena kaukopakettien välittämiskieltoon voidaan pitää APRS-viestejä, silloin kun viestin vastaanottaja tunnetusti sijaitsee iGaten lähistöllä (iGate pitää kirjaa lähistöllään radiolla kommunikoivista asemista). APRS-viestin yhteydessä radiolle voi välittää myös lähettävän aseman sijaintipaketin tai pari, jolloin viestin vastaanottaja näkee missä viestin lähettäjä sijaitsee.
• Käytetään laajuudeltaan hyvin lyhyttä polkua välitetyille paketeille, esimerkiksi vain WIDE1-1 (alias WIDE) jos iGate systeemi ei itsessään ole suoraan tarpeeksi laajalla (paikallisella) alueella kuuluva ja paketti pitää välittää jonkin digipiitterin kautta.
  • Vaikka välityspaikalla APRS-liikennettä olisi radiokanavalla hyvin vähän, se ei tarkoita sitä, että parin hypyn päässä esimerkiksi isommassa amatöörikeskittymässä olisi yhtä hiljaista. Tällöin alueen ulkopuolelta radioverkkoa pitkin "hyppivät" paketit voivat tukkia vilkkaamman alueen.
  • Digipiitteriä käytettäessä laitetaan poluksi mieluimmin kyseisen digipiitterin kutsumerkki. ("OH2XYZ-11>APRS,OH2RDY:}...")
• Kaikkien muiden suodattimien jälkeenkin rajoitetaan vielä bandille välitettävien pakettien maksimimäärä aikayksikössä esimerkiksi neljään pakettiin minuutissa. Tämän on tarkoitus toimia eräänlaisena failsafena, että koskaan ei tukittaisi kanavaa ja estettäisi bandilla olevien APRS-asemien toimintaa.
• Vaihtoehtoisesti pidetään kirjaa kanavan käyttöasteesta. Jos se nousee yli 33% tason (omat lähetykset + kanavan signaalitason nousu FM-ilmaisimen ilmaisukynnyksen yli), rajoitetaan omaa lähettämistä pudottaen ensin pois netistä tulevat paketit, sitten omat RF-beaconit. Liukuvassa 1 minuutin jaksossa sallitaan 50% käyttöaste, kunhan samanaikaisesti ei ylitetä liukuvassa 5 minuutin jaksossa 33% käyttöastetta.

Internetistä radiolle välitetyt paketit välitetään ns. 3rd party formaatissa, eli esimerkiksi iGaten OH4ZZZ-5 saadessa internetistä paketin

"OH2XYZ-11>APZYXW-4,RELAY*,WIDE,qAR,OH1YYY-3:>pakettia  "

välitetään se bandille muodossa

"OH4ZZZ-5>APZ123,WIDE2-2:}OH2XYZ-11>APZYXW-4,TCPIP,OH4ZZZ-5*:>pakettia  "

jossa APZ123 on igate-ohjelmiston käyttämä/tunnistava kohdeosoite, WIDE2-2 iGaten käyttämä polku ja OH4ZZZ-5 iGaten kutsu, joka siis toistuu sekä AX.25 headerissa, että paketin sisällössä. TCPIP "sisemmän" paketin polussa kertoo että paketti tuli internetistä. Paketin alkuperäinen polku siis poistetaan kokonaan tilaa viemästä.

APRS-IS yhteys

APRS-IS:n dokumentaatio on webissä: http://www.aprs-is.net/ ns. "Tier-2" APRS verkko on tuon päällä: http://www.aprs2.net/

APRS-IS:ään yhteys muodostetaan esimerkiksi johonkin seuraavista osoitteista:

• finland.aprs2.net
• rotate.aprs.net

Molemmissa tapauksissa jokaisella kerralla kun yhteyttä muodostetaan, nimi pitää resolvoida IP numeroksi, eikä sitä tulosta saa laittaa pysyvään käyttömuistiin, sillä näiden nimien takana on useita koneita ja kuormaa jakaakseen niihin yhteyden ottamisten pitäisi antaa jakautua "satunnaisesti". Jos nimi antaa useita IP numeroita, nämä kannattaa uudelleenjärjestellä satunnaiseen järjestykseen, koska jotkin systeemikirjastot ja resolverit haluavat järjestää saamansa osoitteet jollakin kriteerillä.

Suositeltava porttinumero kummassakin tapauksessa on 14580, joka mahdollistaa käyttäjän määritellä suotimen, jolla valikoidaan APRS-IS:stä igate:lle tulevia paketteja.

Kirjautuminen APRS-IS:ään tcp-yhteyden muodostumisen jälkeen: vähintään:

user <igaten kutsu> pass <kutsun passcode>

softaversion kanssa:

user <igaten kutsu> pass <kutsun passcode> vers <ohjelman_nimi ja versio>

suotimen kanssa (suodinta ei rx-igatessa käytännössä tarvita, koska igate välittää liikennettä vain yhteen suuntaan):

user <igaten kutsu> pass <kutsun passcode> vers <ohjelman_nimi ja versio> filter <suodinteksti>

esimerkiksi:

user OH9XYZ-13 pass 12944 vers munsofta 0.0.1 filter a/72/16/58/34 p/OF/OG/OH/OI/OJ

Suotimista kerrotaan sivulla: http://www.aprs-is.net/javAPRSSrvr/javaprsfilter.htm

Vastaanotettaessa #-merkillä alkavat rivit ovat kommentteja ja APRS-IS-palvelun omaa kohinaa, jolla ei ole määrämuotoa. Ne voi jättää huomiotta.

Kerrallaan saa olla vain yksi TCP-yhteys APRS-IS-palvelimeen, mutta TCP-yhteyden hereilläoloa kannattaa tarkkailla ja tarpeen mukaan vaihtaa yhteys johonkin toiseen APRS-IS-palvelimeen.

Vaikka radioverkossa ei olisikaan paikallisia tapahtumia, yllä mainitut APRS-IS järjestelmät käyttävät javAPRSSrvr ohjelmistoa joka juttelee "sydämenlyöntiään" TCP yhteydelle noin kerran 20 sekunnissa. Jos valvoo että TCP-yhteydeltä ei ole tullut mitään luettavaa 120 sekuntiin ja silloin sulkee vanhan yhteyden, ynnä avaa uuden normaalin käynnistysmenettelyn mukaisesti, systeemin pitäisi tuolloin huomata verkon häiriöt ja toipua niistä automaattisesti ja riittävän ripeästi.

Huomaa: Kaikki palvelinohjelmistot eivät anna tällaista "sydämenlyöntiä" yhteyksilleen!

Toinen keino vastaavan toiminnan tekoon kaikilla palvelinohjelmistolla on käyttää suodintoimintoja ja pyytämällä jonkin laajemman alueen datavirtaa, jolloin on melko jatkuva liikenne APRS-IS:stä igate:lle — tällöin linjavalvonnan valvonta-ajastinta virkistetään tiheään, vaikka ei olisi tarkoituskaan välittää mitään verkosta radiolle (kohtuus kuitenkin siinäkin datavirrassa!).

Kolmas keino on käyttää käyttöjärjestelmän tarjoamaa TCP keepalive-ominaisuutta, silloin on kuitenkin useimmiten syytä säätää käyttöjärjestelmän keepalive-pakettien tarkistussaikaa pienemmäksi oletuksesta, esimerkiksi 5 minuuttiin. Tämän aikasäätö ei ole ohjelmakoodin tehtävissä UNIXin verkkokoodin API:ssa, vaan systeemimanagerin pitää se tehdä järjestelmälaajuisesti. Pääsääntöisesti tätä ei pidetä hyvänä ideana.

Jos yhteyden muodostus epäonnistuu, ei kannata heti yrittää uudestaan, vaan odottaa 15-30 sekuntia ennen kuin aloittaa uuden yhteyden muodostamisen yrittämisen. (Näin ohjelma ei pyöri villinä paikallaan.)

Beaconit

Nykyisin (syksy 2007) verkossa näkyy voimakkaita piikkejä juuri tasa 10 minuutein ja hiukan pienempi viiden minuutin välein seinäkelloaikaa ja APRS-IS verkossa esiintyy isoja kuormahuippuja tuolla samalla rytmillä.

Tämä johtuu eräiden paljon käytettyjen ohjelmien tavasta ajastaa beaconinsa.

Käytettävän viiveintervallin tulisi olla satunnaisen pitkä 20-30 minuutin välillä. Jos lähetettävänä on useampi beacon sanoma, niiden lähetys pitäisi mieluimmin jakaa viiveintervallille tasaisin välein, eikä lähettää kaikkia yhtenä purskeena intervallin alussa.

Tämä koskee sekä APRS-IS verkkoon, että radiolle lähetettäviä beaconeita.