Transfer principe

Om een transfer van data mogelijk te maken binnen DMR kan je gebruik maken van een aantal principes.

Data Transmit Protocol DTP

DMR kent een "connected mode" dedicated data protocol, waarbij een garantie van overdracht wordt nagestreefd. Dit protocol is enkel bruikbaar voor een "punt-tot-punt" verbinding.

Vermits het versturen van data naar een aantal deelnemers met dit protocol een herhaling van de transmissie met zich mee zou brengen, is deze "connected mode" communicatie niet wenselijk op lage bandbreedte systemen zoals DMR.

Text Message Protocol TMP

Buiten deze vorm van communicatie kent DMR geen "expliciet" data protocol, maar wel een "text message system TMS".

Dit TMS systeem laat je toe om via DMR tekst berichten te versturen naar andere gebruikers (private messages) en naar gebruikers groepen (group messages).

Private messages

De "private messages" wordt verstuurd naar een "private DMR ID" en worden eveneens bevestigd door de tegenpartij. Dit is dus identiek aan een "connected mode" data systeem, dus enkel bruikbaar voor "punt-tot-punt" verbindingen.

Group messages

Echter de "group messages" worden verstuurd naar een "talkgroup of group ID" en worden niet bevestigd door de tegenpartij. Dit is analoog aan een "unconnected mode" data transmissie (UI mode in AX25) of een "broadcast" mode.

Iedere deelnemer die in zijn RX lijst de bewuste "talkgroup of group ID" heeft vermeld, kan de "group message" ontvangen.

Afspraken binnen België

Van dit principe maken we gebruik in het DSyncFS protocol.

Binnen België zijn een aantal TG voorzien voor het gebruik van data. Het betreft de groepen TG20690 tot TG20699.

Broadcast mode

Het broadcast principe is fundamenteel voor onze vorm van overdracht. De data wordt "geproduceerd" door één station en alle andere "luisteren - consumeren" en slaan de ontvangen data op.

Echter deze methode van data overdracht is niet feilloos.

Om fouten te ondervangen worden een aantal principes gebruikt, die reeds gebruikt werden in het tijdperk van de "store-and-forward" packet satellieten.

Segmentatie

De TMS mode laat slechts een bericht toe met een maximale lengte van 256 "unicode characters", wat overeen komt met 512 bytes.

Het DMR protocol hakt deze berichten in stukjes en verstuurd deze in het 30ms frame raster, eigen aan DMR. De samenbouw en het verhakken gebeurt in het toestel, zodat we op software vlak hiermee geen rekening hoeven te houden.

Echter, in de software zullen we wel rekening moeten houden met de maximale lengte van 512 bytes. Hierdoor zullen we softwarematig alle data die verstuurd wordt segmenteren in stukken < 512 bytes.

Management info

Om de gesegmenteerde stukken terug aan elkaar te kunnen lijmen, zijn er extra gegevens noodzakelijk. In een specifieke header, die toegevoegd wordt aan ieder stuk data, worden de unieke gegevens vermeld noodzakelijk voor deze taak.

Tevens is er noodzaak aan het "dirigeren" van de verschillende datatransfers: wie mag wat zenden, naar wie, wie is "online", wat is de volgende file etc.

Ook hiervoor zijn een aantal specifieke berichten afgesproken, die voornamelijk door de master worden uitgezonden.

De master functie binnen DsyncFS is te vergelijken met de "Master Browser" in een windows omgevingen, echter hier wordt de master manueel aangeduid. Hij houd bij voorkeur de gegevens bij en antwoord als eerste op vraag van andere computers voor informatie.

Batch file principe

De enige files die verstuurd worden zijn de files die we terug vinden in de batch folder.

Een batch file wordt aangemaakt dmv Rsync en bevat enkel de aanpassingen die gebeurt zijn in de "work" folder tov de vorige batch generatie. Deze "delta-copy" file wordt gecomprimeerd en voorzien van een sequentienummer.

Uit de info verkregen in de management berichten kunnen alle ontvangende stations nagaan of ze in het bezit zijn van alle voorgaande batches.

Wanneer je alle batch files hebt van een bepaald station, kan je hieruit zijn "work" folder regenereren.

Dit principe wordt eveneens gebruikt om stations die later bij komen in het netwerk te voorzien van alle voorgaande data, zodat de ontbrekende data niet via radio dient verstuurd te worden. Hiervoor worden de voorgaande batch files via internet ter beschikking gesteld.

Hole list principe

Ondanks alle voorzieningen is het nog steeds mogelijk dat een ontvanger één of meerdere berichten mist.

Dit wordt ondervangen door de aanmaak en aanvraag van "hole-files".

Wanneer de zender alle segmenten van de over te dragen data verstuurd heeft, maken alle ontvangers van de data een lijst op van alle "ontbrekende" stukken.

Deze "hole-file" wordt uitgezonden door één van de ontvangers, waardoor de afzender weet welke stukken dienen herhaald te worden.

Vermits bij een radioverbinding waar één gebruiker wat gemist heeft, de kans groot is dat ook een andere gebruiker dezelfde data heeft gemist, is deze vorm van "re-transmit" een efficiënte manier van error-correction.

Na deze re-transmit maken alle ontvangers opnieuw een "hole-list" aan, om zo uiteindelijk tot een volledige transfer te komen bij iedere gebruiker.

Vermits het eveneens mogelijk is dat een gebruiker gedurende een bepaalde tijd "off-line" is, is er eveneens een principe voorzien dat reeds uitgezonden files in het verleden dmv de hole-list kunnen worden opgevraagd.

Zo komt men tot een gestabiliseerde toestand, waarbij in ieder station een identieke toestand van data heerst na het vervolledigen van alle hole-list aanvragen.