Ciao a tutti,
in attesa di formulare magari qualche documento, diagramma e quanto altro potrà tornare utile per avvicinarsi in maniera più consapevole a questo nuovo sistema StarNet, aggiungo qualche nota mediante E-mail.
Dal momento che il gruppo STN008 e STN055 e’ stato creato e messo a disposizione su un server con la banda internet sufficiente per gestire un traffico sostenuto, si sono potute iniziare le prime prove concrete anche in Italia.
Il sistema e’ molto giovane, non e’ esente da problemi e migliorie.
Se non altro poggia su un’infrastruttura decisamente più rodata: ircDDB.
Vi sono alcuni concetti chiave da assimilare, insieme alla terminologia che conviene usare quando si pensa a questa rete di servers StarNet.
Innanzitutto non esiste il concetto di link fisico; bensì si parla di sottoscrizione ad un gruppo di QSO.
Pertanto STN008 (come adesso anche STN055) sono due “gruppi” (nel senso del termine, consentono di raggruppare gli OM che sottoscrivono il gruppo stesso) a cui i vari OM possono sottoscrivere.
Il concetto di sottoscrizione e’ noto pensando ai vari gruppi di discussione su Yahoo; ogni OM che ne sottoscrive uno o più di uno in parallelo, riceverà un certo numero di e-mail dal gruppo stesso.
Il concetto e’ lo stesso, ovviamente riferito al transito della voce in DV.
Innanzitutto vorrei ribadire ancora una volta il concetto che questa rete StarNet poggia saldamente sul network di call routing ircDDB; non può esistere se non esistesse ircDDB, dal momento che i meccanismi per cui la voce viaggia tra i vari partecipanti e’ basata sul call routing.
Per chi aveva iniziato a fare esperimenti di call routing sia attraverso la rete ufficiale mondiale, oppure attraverso il server di test italiano, si sarà reso conto che il tipo di traffico era di tipo punto-a-punto, ovvero uno-a-uno.
In realtà con un minimo di estensione del concetto ad un’area affollata in un dato ripetitore, si poteva fare del traffico in parte uno-a-molti, ma bisognava settare bene le proprie radio per fare ciò.
Sicuramente non una soluzione fattibile da portare avanti.
Quello che mancava era la possibilità di sfruttare il call routing per permettere QSO di tipo uno-a-molti, ovvero come avviene via reflector.
Attraverso il reflector viene stabilito un link (non una connessione fisica come su EchoLink o altri sistemi VoIP) grazie al quale il reflector stesso e’ in grado di smistare tanti flussi UDP verso tutti i gateways e Dongles che desiderano partecipare al QSO.
Non vi e’ nessun tipo di routing e tutto il traffico che transita sul reflector giunge ai vari nodi linkati in quel momento inclusi i beacon APRS e tutto il resto, creando sopratutto in momenti di intenso traffico problemi al transito del normale traffico DV.
Mediante StarNet non esiste link tra un gateway e un altro (a meno che uno non lo realizzi volutamente, ovviamente) pertanto il fatto che tutti i gateways coinvolti nel traffico di gruppo possano ricevere il segnale DV dipende proprio dal routing dei pacchetti verso i sottoscrittori.
In questo modo passa solo il traffico che deve passare quando si e’ deciso di parlare nell’ambito del gruppo.
Chiariamo ulteriormente questo aspetto e vediamo quali sono gli elementi di questa rete.
Il sottoscrittore ad un gruppo e’ un OM che opera via D-Star con il proprio apparato e che si appoggia ad un nodo che lavora in rete ircDDB.
Pertanto, purtroppo, i vari HotSpot/Dongles che non usino ircDDB non potranno essere considerati dei punti di accesso per la rete StarNet.
Questo e’ un concetto da afferrare e tenere sempre a mente.
Nel momento che un OM, operante su un nodo compatibile e attivo su ircDDB, setta il proprio campo UR=STN008 (oppure UR=STN055) invia in rete una duplice informazione: che intende sottoscrivere il gruppo in questione e che intenderà riceverne il traffico mediante il nodo da cui ha fatto partire il pacchetto.
Dal momento che si sta operando in call routing, la rete memorizzerà questa informazione.
Supponendo che altri 9 OM, dai loro rispettivi nodi ircDDB di appoggio, decidessero di sottoscrivere lo stesso gruppo (o gli stessi gruppi, si puo’ essere sottoscrittori di piu’ gruppi alla volta, ovviamente attenzione a non andare in confusione dopo ;-)), la stessa informazione verrebbe registrata in rete ircDDB.
A questo punto appena uno dei 10 OM parla, tutti gli altri sentiranno il traffico, senza che nessuno dei 10 gateways di appoggio sia linkato tra di loro e tantomeno ad un reflector.
Se uno dei 10 OM dovesse spostarsi su un altro gateway (sempre di tipo irccDDB) automaticamente porterebbe con se la sua registrazione al gruppo, solo che l’audio verrebbe stavolta dirottato sul nuovo ripetitore di appoggio.
Pertanto, questo e’ importante da afferrare, la sottoscrizione ad un gruppo viaggia con l’utente non con il gateway di appoggio; ogni volta che l’OM si sposta e si registra sul nuovo gateway (inviando la portante) il QSO relativo al gruppo lo seguirà.
Tutto questo pone l’accento come sempre al buon senso, in quanto bisognerà evitare di far giungere una marea di QSO improvvisi sui vari gateways man mano che si viaggia.
Il buon senso deve sempre farla da padrone in questi casi.
Ogni gruppo StarNet ha un suo timeout per cui se un utente non trasmette verso il gruppo (ovvero deve avere UR=STN008 o UR=STN055) per un certo tempo (al momento settato su trenta minuti), la sua sottoscrizione decade automaticamente.
Inoltre, volendo annullare temporaneamente la sottoscrizione al gruppo, bastera’ inviare il comando UR con la T finale dopo il nome del gruppo, pertanto UR=STN008_t oppure UR=STN055_T.
Ovviamente fintanto che la sottoscrizione ad un gruppo permane, il modulo del ripetitore a cui l’utente era attestato continuerà a mandare traffico inerente il QSO di gruppo.
Pertanto sopratutto nel caso di gateways trafficati, ogni volta che si abbandona il QSO sarebbe buona norma togliere la propria sottoscrizione, in modo che eventuali altri QSO di gruppo non vengano irradiati anche dal ponte in oggetto.
In effetti a descriverlo può sembrare una cosa difficile e complicata, ma una volta visto e’ più semplice di quanto non si pensi.
Si sottoscrive un gruppo di QSO instradato, dal quel momento si continua a ricevere tale traffico fintanto che vi sara’ il QSO e la sottoscrizione sara’ mantenuta attiva; chiaramente sul ponte si sentira’ anche tutto il traffico proveniente da altri utenti locali o via reflector qualora il ponte fosse linkato ad uno.
E’ consigliabile fare questi tipi di QSO di gruppo su un modulo del ripetitore non linkati a nulla, per evitare di arrecare disturbo ed essere a su volta disturbati, visto che i flussi verranno sempre gestiti uno alla volta lato radio.
Bene, detto questo non resta che fare esperimenti con queste nuove evoluzioni che la rete D-Star e ircDDB stanno avendo di questi tempi, per visualizzare il traffico in stanza StarNet i link son : www.ircddb-italia.it e www.xreflector.net
Siamo a disposizione per ulteriori chiarimenti e test che vorrete fare, “73”.