Instruktion: Namngivning och klassificering av noder i Meshcore-nät

Status: Utkast
Senast ändrad: 2026-04-15

Om du har bråttom

Om du har en companion och vi antar du utgår ifrån UME som geografi, dess public key börjar på ac och du heter Nils Nilsson. Då kan du döpa din companion såhär:

UME-NiNi-AC

Om du också sätter upp en repeater utanför hemmet för att få bättre täckning inomhus och den har en public key som börjar på ab och du bor på Hemvägen så kan du döpa den såhär:

UME-ACC-Hemvagen-AB

Förklaringar till ovanstående följer nedan.

Inledning

Denna instruktion beskriver ett standardiserat sätt att klassificera och namnge noder i ett Meshcore-nät. Syftet är att skapa ett system där nodens namn direkt förmedlar dess funktionella roll i nätets topologi och tillförlitlighet, vilket möjliggör enkel och logisk meddelandeplanering.

Dokumentet innehåller rekommendationer. Det viktiga är att man bestämmer sig inom ett mesh och använder samma principer konsekvent, så att namn blir begripliga för alla deltagare. Systemet är decentraliserat och det finns därför ingen som entydigt kan säga vad som är rätt eller fel. Se Appendix A för utökat resonemang.

Namnkonvention

Klassificeringen bygger på principen att noder definieras utifrån tre huvudaspekter:

Tabell 1. Namnets huvudaspekter

Dessa motsvarar namnets struktur:

1

<IATA>-<TYP>(-M)-<NAMN>-<ID>

Kortformat för personliga noder (PER)

För personliga companions (typ PER) är det OK att utelämna <TYP> för att få ett kortare, mer lättläst namn.

1

<IATA>-<NAMN>-<ID>

Tolkning: om <TYP> saknas ska noden antas vara PER.

För mobila noder tillkommer även:

• Tillförlitlighet (mobilitet) → markeras med -M direkt efter TYP

Regler för versaler och gemener

För att namn ska vara lätta att läsa och jämföra ska samma skrivsätt användas konsekvent.

Tabell 2. Rekommenderat skrivsätt per fält

Designprincip

Namngivningen ska vara tillräcklig för att förstå:

• var noden hör hemma
• vilken funktion den har
• vem noden är (identifiering)

utan att behöva extern information.

Referensexempel

Tabell 3. Referensexempel för nodnamn

Fältbeskrivning

Tabell 4. Fält i nodnamnet

IATA definition

IATA-koden anger nodens geografiska hemvist, inte dess aktuella position.

• Fasta noder använder den plats där de är installerade
• Mobila noder använder sin organisatoriska eller logiska hemvist
• IATA ska inte ändras under drift

Se Tabell 3 för exempel på hur geografisk hemvist används för fasta, mobila och personliga noder.

Nodtyper

Detta avsnitt innehåller giltiga värden för fältet .

För varför nätmodellen finns och hur den används för effektiv kommunikation och routing, se Appendix B: Nätmodell.
För praktiska designregler, se Routingprincip.

Repeater typer

Tabell 5. Primära repeater typer

Specialroller

BRG och EXT är specialfall som används när huvudstrukturen inte räcker; se Appendix B: Nätmodell.

Tabell 6. Specialroller

Companion typer

Companions är namngivna nodtyper, men de tillhör inte den topologiska huvudstrukturen BCK → DST → ACC.
De används för personliga, observerande eller kartläggande noder där funktionen är viktigare än placeringen i routinghierarkin.

Tabell 7. Companion typer

Mobilitet (-M)

-M anger att noden är mobil och ej tillförlitlig över tid. Den kan försvinna ur path utan förvarning. Av det skälet används nästan uteslutande -M tillsammans med typ ACC (den mobila repeatern ger access till companions i fordon).

Regler:

• -M placeras direkt efter TYP
• Companions är mobila till sin natur och dessa behöver inte märkas med -M

Se Tabell 3 för exempel på mobil namnform.

Namn

Regler:

• Använd ID för att skilja mellan personer med samma namn och mellan flera companions hos samma ägare
• IATA, TYP och eventuell M skrivs alltid med versaler
• NAMN skrivs med ett mänskligt läsbart namn, till exempel Alidhem, Savar eller Storgatan23
• NAMN skrivs i PascalCase även när det är en roll eller generisk beteckning för mobil nod, till exempel Car, Tmp eller Bike
• Personnamn och egennamn i NAMN skrivs normalt med inledande versal, till exempel Johan
• Undvik mellanslag i NAMN och ID; använd PascalCase om flera ord behöver skiljas åt, till exempel SodraBerget eller NorraLanken
• Undvik å, ä, ö och andra specialtecken i NAMN och ID; använd helst ASCII, till exempel A, O, Angsvagen eller Umea
• ID skrivs alltid med versaler

Rekommendation:

Om ett namn normalt innehåller svenska tecken, translitterera dem konsekvent: å -> a, ä -> a, ö -> o.

Om ett namn normalt innehåller mellanslag, ersätt dem med PascalCase, till exempel Sodra Berget -> SodraBerget.

Se Tabell 3 för normaliserade exempel på rekommenderad skrivning.

ID

ID ska utgöras av ett kort utdrag ur nodens public key och placeras sist i namnkonventionen.

Tabell 8. Rekommenderade ID-format

Regler:

• ID ska baseras på nodens public key enligt Meshcore-standard och vara unikt inom samma IATA + TYP + NAMN
• ID ska hämtas från nodens public key, inte från personnamn, enhetsnamn eller löpnummer
• ID får bestå av 1 byte (3F) eller 2 byte (3F7A) från public key enligt Meshcore-standard
• ID skrivs med versaler och hextecken
• Ett mesh bör välja en standardbredd för hela nätet, normalt 2 eller 4 tecken

Rekommendation:

Använd i första hand 1 byte / 2 hextecken när det räcker för tydlig identifiering i drift. Använd 2 byte / 4 hextecken när nätet är större eller när risk för kollision finns.

Exempel:

1
2

UME-BCK-Alid-3F
UME-DST-Savar-3F7A

Appendix A: Decentraliserad klassificering

Meshcore-nätet är decentraliserat i sin natur. Det finns ingen central instans som avgör hur noder ska klassificeras eller namnges.

Klassificeringen av en nod ska ses som en självskattning av dess avsedda funktion, inte en absolut sanning.

Det innebär att:

• Samma typ av nod kan klassificeras olika av olika operatörer
• Klassificeringen speglar vad nodägaren anser att noden ska bidra med i nätet
• Klassificeringen kan förändras över tid i takt med att nätet utvecklas

Designprincip

1
2

En nods typ anger dess avsedda roll i nätet,
inte en objektiv eller verifierad egenskap.

Exempel: parallella distributionsnoder

Två grannar sätter upp varsin nod på sina tak och klassificerar båda som:

1

DST

Är detta korrekt?

Ja.

I detta fall innebär det att området får:

• Redundans
• Flera möjliga distributionsvägar
• Ökad robusthet

Det är alltså inte ett problem att flera noder “anser sig” vara samma roll — det kan vara en styrka.

Exempel: gemensam distributionspunkt

Fem grannar samarbetar och placerar en nod på en lokal höjd.

• Denna nod klassificeras som:

1

DST

• Varje hushåll har egna noder som klassificeras som:

1

ACC

Detta ger en tydlig och logisk struktur:

1

DST → ACC → användare

Tolkning i praktiken

Vid osäkerhet:

• Klassificera noden utifrån hur du vill att den ska användas
• Inte nödvändigtvis hur den används just nu

Viktig konsekvens

1

Felklassificering är mindre problematisk än inkonsekvent klassificering.

Det viktigaste är att:

• Noder klassificeras konsekvent
• Klassificeringen ger rimlig vägledning för routing

Sammanfattning

• Klassificering är avsikt, inte fakta
• Flera noder med samma roll är tillåtet och ofta önskvärt
• Systemet bygger på lokala beslut och samverkan, inte central styrning

Appendix B: Nätmodell

Nätmodellen är ett gemensamt språk för varför vi namnger noder med typer och hur nätet bör användas när man vill kommunicera effektivt.

Syftet är att:

• göra det lätt att planera meddelandevägar utan att känna till varje enskild nod
• minska onödiga hopp och belastning på högre lager i nätet
• uppmuntra stabila, lokala vägar när de finns

I korthet: håll trafik så lågt som möjligt i nätet och använd BCK som transportlager först när det behövs.

Modellens tre lager

• ACC (Access): kanten av nätet – där användare och companions ansluter
• DST (Distribution): lokal spridning/aggregat – bär lokal trafik och försörjer flera ACC
• BCK (Backbone): transport – binder samman områden över längre avstånd

Tänk på pilen som en normalt önskvärd riktning när trafik behöver lämna sin lokala kontext:

1

ACC → DST → BCK

Hur du använder modellen (effektivitet)

När du väljer typ vill du i praktiken svara på frågan: vilken roll ska noden spela för andras trafik?

Förenklade tumregler:

• Klassificera som ACC om noden främst ger täckning/anslutning för en plats, ett hushåll eller ett fordon.
• Klassificera som DST om noden ska vara ett stabilt lokalt nav som andra noder förväntas gå via.
• Klassificera som BCK om noden primärt ska bära trafik mellan områden och vara ett transportlager.

När du planerar kommunikation är grundidén:

• Om två noder kan nå varandra via ACC ↔ DST ↔ ACC, så ska den vägen normalt prioriteras.
• Gå upp till BCK först när det saknas rimliga DST-vägar.

Se Routingprincip för en konkret prioriteringsordning och regler.

Specialroller (BRG och EXT)

BRG och EXT är specialfall som inte är en del av huvudstrukturen, men som ibland behövs för räckvidd eller konnektivitet.

• BRG (Bridge): en medveten länk mellan separata meshcore-domäner (“wormhole”/inter-nät). Använd sparsamt och tydliggör syftet.
• EXT (Extend): räckviddsförlängning inom samma domän/topologi utan att skapa ett inter-nät.

Konceptuellt kan de se ut så här:

1
2

BCK → BRG → BCK
DST → EXT → DST

För mer utförliga beskrivningar och exempel, se Appendix C: Råd vid val av typ.

Appendix C: Råd vid val av typ

Nedan följer mer utförliga beskrivningar av de olika typer och deras karaktäristik.

BCK (Backbone)

• Långdistans
• Stabil och permanent
• Ska inte belastas med lokal trafik

Typiska egenskaper:

• Placeras högt (master, tak, berg, torn)
• Fri sikt över stora områden
• Riktade länkar i flera riktningar
• Optimerad för räckvidd och länkbudget

Drift och förvaltning:

• Hög tillgänglighet är prioriterad
• Aktivt övervakad (monitorering)
• Byggs med redundans där möjligt
• Förväntas vara kontinuerligt i drift

DST (Distribution)

• Försörjer flera noder
• Primär bärare av lokal trafik

Typiska egenskaper:

• Strategiskt placerad i eller nära bebyggelse
• Har god länk upp till BCK
• Sprider trafik i ett område (fan-out)
• Ofta sektor- eller flerriktad täckning

Drift och förvaltning:

• Viktig för nätets funktion i ett område
• Bör vara stabil men inte lika kritisk som BCK
• Kan byggas ut successivt

ACC (Access)

• Nära användare
• Endpoint-fokuserad
• Standardklass för mobila noder

Typiska egenskaper:

• Låg till medelhöjd (hus, fordon, inomhusnära)
• Kortare räckvidd
• Fokus på täckning snarare än räckvidd
• Ofta omni- eller bred täckning

Drift och förvaltning:

• Ej kritisk för nätets struktur
• Kan vara många och dynamiska
• Varierande tillförlitlighet

BRG (Bridge)

• Löser konnektivitet — primärt mellan separata meshcore-nät (“wormholes”)
• Skapar en logisk länk mellan fristående meshcore-domäner
• Har i regel få länkar och är inte avsett för distribution

Typiska egenskaper:

• Används för att länka två nät eller nätsegment som annars är separata
• Ofta punkt-till-punkt
• Riktade antenner och fokuserade länkar
• Minimal fan-out; inte avsedd för lokal distribution

Drift och förvaltning:

• Funktionell snarare än strukturell
• Kan vara temporär eller opportunistisk
• Används när det finns behov att binda ihop fristående meshcore-domäner
• Bör dokumenteras tydligt eftersom det ändrar nätgränser/logiska domäner

EXT (Extend)

• Räckviddsförlängare inom samma mesh/topologi
• Används för att förbättra täckning eller överbrygga svaga länkar utan att koppla ihop separata meshcore-domäner

Typiska egenskaper:

• Placerad för att öka räckvidd eller förbättra länkbudget inom ett nät
• Kan ha omni- eller riktade antenner beroende på behov
• Kan vara temporär eller permanent beroende på ändamål

Drift och förvaltning:

• Funktionellt inriktad på att förbättra intra-nät räckvidd
• Får inte användas för att osynligt slå ihop separata meshcore-domäner — det är BRG:s roll
• Namnges som EXT för att tydliggöra syftet i topologin

Viktig princip

1
2

Egenskaper ovan är typiska, inte krav.
Klassificering baseras alltid på nodens funktion i nätet.

Se Tabell 5, Tabell 6 och Tabell 7 för den sammanfattade klassöversikten.

Routingprincip

Kommunicera så lågt som möjligt

1
2
3
4

1. ACC ↔ ACC (via DST)
2. ACC ↔ DST
3. DST ↔ DST
4. BCK (endast vid behov)

Designregler

1
2
3

- Undvik BCK om DST räcker
- Undvik -M noder om stabil väg finns
- Undvik BRG om direktlänk finns

Viktiga regler

1
2
3
4

Om två noder kan kommunicera utan att gå via BCK
→ ska den vägen prioriteras

En rutt får inte vara beroende av en -M-nod

Exempel

Rekommenderat

1

ACC → DST → ACC

Ska undvikas

1

ACC → BCK → ACC

Sammanfattning

• BCK → DST → ACC är huvudstruktur
• BRG används endast för att koppla segment
• -M anger mobil och opålitlig nod
• Mobila noder är som standard ACC
• Namn ska möjliggöra direkt förståelig routing
• Trafik ska hållas så lågt i nätet som möjligt