Ero sivun ”IPv6-pakettiradio” versioiden välillä

Radioamatööriwikistä
Siirry navigaatioon Siirry hakuun
>Oh2mqk
(käännettiin protokollapilon esittely päinvastaiseen järjestykseen)
>Oh2mqk
p (hieman lisää löpinää)
Rivi 8: Rivi 8:
satutaan haluamaan.  Mieluiten UI-sovellukset käyttävät UDPv6
satutaan haluamaan.  Mieluiten UI-sovellukset käyttävät UDPv6
kehyksiä. CONS protokollana tarjolla on TCPv6.
kehyksiä. CONS protokollana tarjolla on TCPv6.
Tämä on lähtökohdaltaan datalähetyksen hoitamista kun runkoverkko
on kaupallisen lankaverkon päällä, kun taas Japanilainen [[D-STAR]]
tavoittelee digitaaliselle puheelle pienintä mahdollista
läpikulkuviivettä käyttämällä runkoyhteydellä isokronisia
ATM-tekniikoita ja kehysmuotoinen datalähete on jälkikäteen
päälle liimattua.


== Yksityiskohtia ==
== Yksityiskohtia ==
Seuraavassa kuvataan protokollapinoa.
Laitteiden oletetaan olevan kahta tasoa fiksuja ja se näkyy
lähinnä link- ja network- tasoilla.


Toisin kuin AX.25:ssä, Network Layer hoitaa tässä digi-beat toiminnot,
Tyhmemmät tarjoavat forward-suuntaan label-switchingiä jota fiksummat voivat
eli käytännössä hop-to-hop REITITYKSEN(Reititysprotokollana RSPF-v6
käyttääPaluusuunta ei kuitenkaan ole tarjolla, jos paluupaketin lähettäjä
fiksummissa noodeissa ja RIPv6 vähemmän fiksuissa.)
ei osaa käskeä sellaista oikein.


=== Physical layer ===
=== Physical layer ===
Rivi 59: Rivi 70:
** IPv6 paketti
** IPv6 paketti
** FCS
** FCS
==== Path-label-switching ? ====
Tekniikka, jolla fiksumpi noodi voi käyttää (mahdollisesti ketjuttaen)
vähemmän fiksun noodin lähetinportteja ottaakseen yhteyttä sellaisen
kautta toiseen fiksuun noodiin.
Paluusuuntaa '''ei''' tarvita.


=== Network Layer ===
=== Network Layer ===
Network-layerin oletetaan olevan jotakin, joka toimittaa datakehyksen IPv6 käsittelyyn.
Toisin kuin AX.25:ssä, Network Layer hoitaa tässä digi-beat toiminnot,
Alempana eräitä ajatuksia asiasta.
eli käytännössä hop-to-hop '''reitityksen'''.
 
Reititysprotokollana RSPF-v6 (tai BGP-v6) fiksummissa noodeissa ja RIPv6
vähemmän fiksuissa. (BGP-v6 vaatii luotettavia nopeita linkkejä)
 
Fiksuushierarkiassa vähemmän fiksut eivät ole fiksujen välillä viestejä
kuskaamassa, koska explisiittinen AX.25 path-route ei ole käytettävissä.
Pääasiassa tämä seuraa jo siitä, että tässä ei edes ole tarkoitus käyttää
radioverkkoa ensisijaisena pitkän matkan linkkinä.
 
Vaihtoehtona on, että fiksuilla noodeilla voidaan komentaa vähemmän fiksuja
forwardoimaan datapaketti annetusta etälinkistä ulos. (label-switching)


* Asemien IPv6 osoitteet ovat kahdenlaisia:
* Asemien IPv6 osoitteet ovat kahdenlaisia:

Versio 8. heinäkuuta 2005 kello 11.44

IPv6-pakettiradio on kokoelma höyrypäisiä ideoita, jotka tavoittelevat lähinnä AX.25:n UI protokollan päällä kulkevien protokollien kääntämistä päälaelleen siten, että IPv6:n IP-kehys on link-layer osoittamiseen ja korvaa kokonaan AX.25 kehyksen ja sen sisällä ajetaan sitten mitä protokollaa satutaan haluamaan. Mieluiten UI-sovellukset käyttävät UDPv6 kehyksiä. CONS protokollana tarjolla on TCPv6.

Tämä on lähtökohdaltaan datalähetyksen hoitamista kun runkoverkko on kaupallisen lankaverkon päällä, kun taas Japanilainen D-STAR tavoittelee digitaaliselle puheelle pienintä mahdollista läpikulkuviivettä käyttämällä runkoyhteydellä isokronisia ATM-tekniikoita ja kehysmuotoinen datalähete on jälkikäteen päälle liimattua.

Yksityiskohtia

Seuraavassa kuvataan protokollapinoa.

Laitteiden oletetaan olevan kahta tasoa fiksuja ja se näkyy lähinnä link- ja network- tasoilla.

Tyhmemmät tarjoavat forward-suuntaan label-switchingiä jota fiksummat voivat käyttää. Paluusuunta ei kuitenkaan ole tarjolla, jos paluupaketin lähettäjä ei osaa käskeä sellaista oikein.

Physical layer

Mahdollisia linkkitason lähestymistapoja:

  • Bell-202/NBFM -- ei kiitos
  • GMSK: paljon parempi
  • FEC + GMSK: vieläkin parempi
  • IEEE 802.11 BPSK/QPSK

GMSK + FEC

GMSK modulaatio tarjoaa seuraavat ominaisuudet:

  • Vakio teho (kuten FM)
  • tuotettavissa ja vastaanotettavissa FM yhteensopivilla radioilla

FEC (Forward Error Correction) on tapa lisätä linkin S/N:ää hyötyliikenteelle, kun apuna käytetään datavirtaan lisättyä korjaavaa redundanssidataa. Mahdollisia tapoja:

  • Reed-Solomon: vanha ja patenttivapaa
  • Turbokoodit: 1-2 dB parempi, mutta patentit kiusaa

FEC+Interleave: tekniikalla lisätään hyötybittien ja tarkistusbittien ajallista etäisyyttä toisistaan niin, että lyhyt (kipinä-)häiriö ei nitistäisi kaikkia bittejä, vaan kehys saataisiin pelastettua.

Implementaatio on mahdollisesti yhdistelmä FPGA:ta ja DSP:tä. KISS-TNC voisi olla tehtävissä. TNC:hen tulee suoraan radion IF, sekä RSS jännite ja se tuottaa ulos IF:ää. Kytkentä audio-linjaan ei toimi.

Sama IF-KISS-TNC osaisi kyllä tehdä myös nykyiset modulaatiot.

IEEE 802.11 BPSK/QPSK

WLAN-raudan käyttö...

Surplussaa on jonkin verran, mutta kuluttajatekniikan (kuten muunkin) ongelma on, että mikään kompleksisempi komponentti X ei ole saatavilla kymmentäkään vuotta...

Link layer

Link-layer on äärimmäisen yksinkertainen, toisin kuin AX.25:ssä:

  • HDLC-kehys
    • A=0
    • C=0
    • 2 tavua jotka kertoo perässä tulevan paketin pituuden (network byte order)
    • 2 tavua jotka kertoo protokolla-id:n (IPv6:lle Ethernetin: 0x86DD, network byte order)
    • IPv6 paketti
    • FCS

Path-label-switching ?

Tekniikka, jolla fiksumpi noodi voi käyttää (mahdollisesti ketjuttaen) vähemmän fiksun noodin lähetinportteja ottaakseen yhteyttä sellaisen kautta toiseen fiksuun noodiin. Paluusuuntaa ei tarvita.

Network Layer

Toisin kuin AX.25:ssä, Network Layer hoitaa tässä digi-beat toiminnot, eli käytännössä hop-to-hop reitityksen.

Reititysprotokollana RSPF-v6 (tai BGP-v6) fiksummissa noodeissa ja RIPv6 vähemmän fiksuissa. (BGP-v6 vaatii luotettavia nopeita linkkejä)

Fiksuushierarkiassa vähemmän fiksut eivät ole fiksujen välillä viestejä kuskaamassa, koska explisiittinen AX.25 path-route ei ole käytettävissä. Pääasiassa tämä seuraa jo siitä, että tässä ei edes ole tarkoitus käyttää radioverkkoa ensisijaisena pitkän matkan linkkinä.

Vaihtoehtona on, että fiksuilla noodeilla voidaan komentaa vähemmän fiksuja forwardoimaan datapaketti annetusta etälinkistä ulos. (label-switching)

  • Asemien IPv6 osoitteet ovat kahdenlaisia:
    • Kiinteitä asemakohtaisia osoitteita, joiden prefiksit ovat esim. peräisin lähimmän tukiaseman tarjoamasta prefiksistä
    • Dynaamisia MOBILEv6 osoitteita, jotka vaihtuvat lähimmän reitittävän tukiaseman mukaan
  • "NETWORK" prefiksit jaetaan tukiasemille manuaalisella verkonsuunnitteluprosessilla, joka ottaa huomioon tukiasemien väliset yhteydet.
  • "LOCAL" suffiksit ovat kuin uniikit MAC osoitteet eetterikorteissa, niihin voidaan koodata (vaikkapa ASCIIna) asematunnus
  • AX.25:n WIDE* kohdeosoitteet implementoidaan määrittämällä joukko IPv6 multicast kohdeosoitteita, jotka leviävät halutuille alueille ja yhdistämällä tähän sopivan alhainen HOPLIMIT arvo IPv6 paketin headeriin.
    • e.g. WIDE-3: HopLimit=3, Dst: Mcgroup-Wide
    • e.g. OHWIDE-*: HopLimit=31, Dst: Mcgroup-Wide-OH
NETWORK
2001:XXXX:XXXX:XXXX
LOCAL
0x00,'O','H','2','N','X','X',0x00
  • LOCAL-osan tavu 0 on vakio 0x00 ja määrittää aseman kutsun koodausmenetelmän
    • tavut 1..7 ovat aseman kutsumerkki isoina ASCII kirjaimina
    • tavujen 1..4 ylimpiin bitteihin koodataan AX.25 SSID arvo (vaikkakin payload-protokollan ID:t on parempi paikka tälle)
    • tavujen 5..7 ylimmät bitit ovat nollia
  • LOCAL-osan tavu 0 on vakio 0x01 ja määrittää aseman kutsun koodausmenetelmän
    • tavut 1..6 koodaavat aseman kutsumerkin shiftatulla ASCII-koodilla (ord(c)-32; käyttämällä ASCII-merkit 32..95) kompressoimalla 6 bittiä per merkki siten, että tähän tilaan mahtuu 8 kirjainta ja numeroa.
    • tavu 8 on varattu AX.25 SSID datalle

Linkkejä

http://ham.zmailer.org/oh2mqk/packet-ipv6.html