OLSR ( Optimized Link State Routing Protocol ) er en protokoll for ruting for maskenettet , trådløs eller mobil . Protokollen er en optimalisering av ren koblingen tilstand algoritmen . Nøkkelkonseptet som brukes i protokollen er bruken av flerpunktsreléer (MPR). MPR-settet er valgt slik at det dekker alle noder som er to humle på rad. Det fungerer som en proaktiv protokoll, topologiinformasjon med andre nettverksnoder utveksles regelmessig.
I OLSR introduseres to typer meldinger: “Hello” og “TC” ( topology control ). Hver node sender en Hello-melding som inneholder informasjon om nabolaget og koblingens tilstand. Utvekslingen av disse meldingene gjør det mulig å bli kjent med nabolaget. For å bygge tabellene som er nødvendige for ruting av pakkene, sender hver node periodisk en TC-pakke som inneholder listen over naboene som har valgt den som MPR. TC-meldingen sendes gjennom hele nettverket. Bare MPR-naboer sender på nytt en TC-pakke for å unngå flom.
Denne protokollen ble foreslått av prosjektgruppen HIPERCOM- INRIA . Det er definert i RFC 3626 av IETF , som anerkjenner det som en av de fire grunnleggende protokollene i bruk av MANET- nettverk .
For sitt dynamiske aspekt er OLSR-protokollen sårbar for et visst antall angrep, spesielt fastkjøring, sending av oppdateringer av ugyldige meldinger, samt angrep beregnet på kontrollmeldingen under generering eller overføring. Forskning på autentisering og påvisning av inntrengingsteknikker har blitt utført for å sikre protokollen. Endringer ble gjort under protokollens ytelsesstudier når det gjelder tjenestekvalitet og energiforbruk, i henhold til de forskjellige maskinvare- og programvareimplementeringene.
En ny versjon er under utvikling (2010).
Innen MANETs er det to klasser av protokoller: reagenser og proaktive.
Reaktive protokoller må systematisk be om sine ruter ved å oversvømme nettverket med deres forespørsel og motta tilhørende svar.
Bruk av en protokoll av denne kategorien i en MANET innebærer konstruksjon av en topologi i den aktuelle sonen bare når behovet oppstår.
De reaktive protokollene er: AODV & DSR .
Protokoller som er proaktive, sørger i mellomtiden for at hver node til enhver tid har den nødvendige informasjonen om topologien for å bygge en vei til et annet punkt i nettverket. Dette er mulig gjennom jevnlige oppdateringer av topologien.
De proaktive protokollene er: OLSR, Topologi-spredning basert på revers-path forwarding (en) (TBRPF).
Til slutt er det protokoller som kombinerer fordelene med reaktive og proaktive protokoller, protokoller som er hybrider som Zone Routing Protocol (en) (ZRP) og TORA .
OLSR-protokollen er en variant av LSR ( på engelsk " Link State Routing ") spesielt designet for MANET. I motsetning til LSR hvor alle noder er udifferensierte, er optimaliseringen av OLSR å bruke flerpunktsreléer (MPR). MPR er utvalgte noder som sender kringkastingsmeldinger under flomprosessen. De er de eneste som erklærer koblingene sine og er valgt av de andre nodene slik at de kan nå hvem som helst i to humler. Denne teknikken reduserer overhead betydelig på grunn av meldinger sammenlignet med en konvensjonell flommekanisme, der hver node sender hver melding på nytt når den mottar den første kopien av meldingen. I OLSR produseres informasjon om koblingstilstand bare av noder valgt som MPR, og dermed oppnås en andre optimalisering ved å minimere antall kontrollmeldinger som oversvømmes i nettverket. Som en tredje optimalisering, bør en MPR-node kun rapportere koblinger mellom seg selv og dens velgere.
De to hovedtrekkene ved OLSR er:
OLSR er en optimalisering av en koblingsstatusprotokoll for ad hoc -mobilnettverk .
For det første reduserer det størrelsen på kontrollpakken: i stedet for alle lenker, erklærer den en del av lenkene med naboene, som er dens flerpunktsrelévelgere. For det andre minimerer det trafikkflom ved denne kontrollen ved å bare bruke de valgte nodene, kalt flerpunktsreléer, for å kringkaste meldingen i nettverket. Bare flerpunktsreléene til en node kan overføre kringkastingsmeldingene på nytt. Denne teknikken reduserer antall retransmissjoner i en flom- eller kringkastingsprosedyre.
Protokollen er designet for å fungere på en fullstendig distribuert måte og trenger derfor ikke være avhengig av noen sentral enhet. Protokollen krever ikke pålitelig overføring for sine kontrollmeldinger: hver node sender sine kontrollmeldinger med jevne mellomrom, meldinger som kan oppleve tap av noen av pakkene, noe som skjer veldig ofte i radionettverk på grunn av kollisjoner eller andre overføringsproblemer.
Hver node må oppdage naboenoder som den har en direkte og toveis lenke med. Usikkerhet rundt radioutbredelse kan gjøre noen lenker ensrettet. Derfor må alle lenker kontrolleres i begge retninger for å bli ansett som gyldige.
For å oppnå dette sender hver node jevnlig sine HELLO-meldinger som inneholder informasjon om naboene og deres koblingsstatus. Disse kontrollmeldingene overføres i kringkastingsmodus. De blir mottatt av alle naboer i et humle, men de blir ikke videreformidlet til flere noder.
En av HELLO-meldingene inneholder:
HELLO-meldinger brukes til nabodeteksjon og MPR-beregninger. De overføres regelmessig til alle 1-hopp-naboer. HELLO-meldinger inkluderer typen kobling, nodens vilje til å bli MPR, naboinformasjon etc. Koblingstypen i disse meldingene indikerer om lenken er symmetrisk, asymmetrisk eller bare tapt.
Disse meldingene er bare beregnet på naboens noder (ett hopp) til avsenderen for å oppdage koblingene mellom dem, så de skal aldri sendes av en MPR.
Avsender: hver node i nettverket sender HELLO-meldinger
Mottaker: kringkastingsadresse
Funksjon: HELLO-meldingen overfører flere opplysninger og har flere bruksområder.
Den brukes først til å oppdage hele nettverket. Deretter overfører status og type kobling mellom avsenderen og hver naboenode.
Den inneholder også tre lister:
Datagram :
Disse meldingene brukes til å lage rutetabellen. Dette er statusmeldinger for lenker, som sendes periodisk over hele nettverk.
Avsender: bare MPR-er sender TC-meldinger
Mottaker: kringkastingsadresse
Funksjon: TC-meldingen lar MPR overføre listen over naboene som har valgt den som MPR. Den brukes til å etablere rutetabellene. Også for det som skal kringkastes over hele nettverket , TTL-verdien i meldingstoppteksten er 255, den maksimale verdi (se "typisk pakke som sendes av protokollen").
Datagram :
Disse meldingene overføres av noder som kjører OLSR-protokollen på mer enn ett grensesnitt.
MID-meldinger brukes til å koble adressene til OLSR-grensesnitt og de primære adressene for OLSR-noder med flere grensesnitt.
MID-meldingen inneholder listen over adresser til grensesnittene som er tilknyttet hovedadressen. Den sendes av noden i nettverket for å erklære dem til alle andre noder. For å oppnå bedre pålitelighet og gjennomstrømning, kan MID-meldinger brukes til å velge flere grensesnitt som primære og derved etablere flere stier mellom to nabo noder. For ruting vil en node med flere grensesnitt vises som to separate noder. Hvis en kobling er nede, kan en node med flere grensesnitt fremdeles gi rutebanen til de andre nodene.
MeldingsaggregasjonHELLO- og TC-meldinger kan pakkes i samme pakke.
Dette muliggjør overføring av flere meldinger samtidig på nettverket.
Behandlingen og metoden for forplantning av meldinger forblir likevel spesifikk for deres kategori. For eksempel sendes ikke HELLO-meldinger mens TC-type meldinger er.
Ideen med flerpunktsreléer er å minimere flom av kringkastingspakker i nettverket ved å redusere dupliserte videresendinger til samme node. Hver node i nettverket velger et sett med noder i nabolaget, som videresender pakkene sine. Dette valgte settet med nabo noder kalles nodenes flerpunktsrelé eller MPR.
Naboer til node N som ikke er en helhet MPR kan lese og behandle pakken, men kan ikke overføre kringkastingspakken mottatt fra node N. For dette opprettholder hver node en liste over naboene som kalles MPR-velgerne for denne noden. Hver kringkastingsmelding fra disse MPR-velgerne for en node antas å bli overført på nytt av den noden. Dette settet kan endres over tid, noe som er angitt av nodevelgeren i meldingene.
Hver node velger sine multipoint-stafetter blant sine naboer en hopp unna. Et hopp tilsvarer en node hvis avstand er nærmest hovednoden. Flerpunktsreléer er valgt slik at de (når det gjelder radiorekkevidde) dekker alle noder som ligger to noder fra hverandre. Flerpunktsrelésettet til en node N, betegnet MPR (N), er en vilkårlig delmengde av noden til N som tilfredsstiller følgende tilstand: hver node hvis avstand er to hopp fra N, må ha en toveiskobling til flerpunktsreléer til node N Figuren viser valget av flerpunktsreléer rundt noden N.
OLSR er avhengig av valget av flerpunktsreléer, og beregner rutene til alle kjente destinasjoner gjennom nodene. MPR-noder velges som mellomnoder i banen. For å implementere denne ordningen, sender hver node i nettverket med jevne mellomrom informasjon til sine naboer som er valgt som flerpunktsreléer. Ved mottak av informasjon om MPR-velgerne, beregner og oppdaterer hver node sine ruter for hvert kjent mål. Derfor er ruten en sekvens av humle gjennom flerpunktsreléer fra kilde til destinasjon.
Flerpunktsreléer velges blant one-hop naboer med en toveis lenke. Dermed unngår ruting gjennom flerpunktsreléer automatisk problemene knyttet til overføring av pakkedata over enveiskoblinger.
For ruteberegning beregner hver node sin rutetabell ved hjelp av en "korteste banehoppalgoritme" basert på topologien til det delnettverket den har lært.
DefinisjonPå MPR-valgalgoritmediagrammet består settet N av one-hop naboer fra noden (her i rødt), hvis MPR-er skal bestemmes. Et humle tilsvarer alle naboene som svarte på Hello-meldingen, dette tilsvarer radioområdet for Wi-Fi- nettverk .
Settet N2 består av 2-hopp-naboene til samme node som tidligere. Alle naboer som hopper vekk fra den røde noden ved hjelp av hei-meldinger, vil erklære naboene sine et hopp unna. Dermed vil den røde noden kjenne en-hopp-nodene som må be om å overføre en pakke til en 2-hopp-nabo.
En asymmetrisk lenke (eller ensrettet, lenken er kun gyldig i en retning) er representert av en enkelt rød linje. De oppdages av Hello-meldinger, men brukes ikke før de er symmetriske.
En symmetrisk lenke (eller toveis, lenken er gyldig i begge retninger) er representert med en dobbel rød linje.
AlgoritmeDe forskjellige trinnene i algoritmen er:
Valget av MPR er nøkkelpunktet i OLSR-protokollen. Valget av MPR gjøres ved å velge enhopp-nabo-noden. Hvis det er flere noder, er den valgte noden den med flest naboer. Tabellen viser hvordan Node B velger en MPR, basert på nettverket vist i figuren:
Hvis vi tar node B, dekker nodene C og F settet til nabolandene med to hopp. Imidlertid er node C valgt som MPR fordi den har 5 naboer mens node F har 4 (graden C sies da å være større enn graden F).
OLSR-protokollen er sårbar for forskjellige typer angrep. Denne sårbarheten økes fordi det ikke er nødvendig å gå gjennom et tilgangspunkt for å koble til nettverket. Bruken av en dynamisk topologi gir rom for store sikkerhetshull. Bruk av MPR-er gjør OLSR-protokollen mindre sikker enn LSR, siden bare nyttig tilkobling utnyttes, nodene ikke lenger dupliserer informasjon.
Vi kan klassifisere angrep i to kategorier:
Siden denne siden bare gjelder OLSR-protokollen, gjelder sårbarhetene som presenteres hovedsakelig angrep som er spesifikke for denne protokollen. Hver node har den primære rollen som å generere trafikk som er spesifikk for rutingsprotokollen, og den andre er ansvarlig for å videreformidle ruteinformasjon fra andre noder i nettverket. Feil oppførsel skyldes derfor generering av feil informasjon om rutingen, eller fra fravær av videreformidling av denne informasjonen.
Et angrep for å gi ulovlig tilkobling til nettverket må skyldes unormal oppførsel av minst en av nodene som komponerer det.
En unormal holdning kan skyldes to atferd:
Det er mange muligheter for å introdusere noder i OLSR-protokollen (fra en OLSR definert av RFC, uten en valideringsprosedyre) for å starte forskjellige angrep:
OLSR er sårbar for forstyrrelser, noe som også er tilfelle for alle andre rutingsprotokoller som brukes i ad-hoc-nettverk.
Jamming er etableringen av en stor mengde radiointerferens. Den genererte støyen gjør det da umulig for nodene å utveksle nyttig informasjon med hverandre, spesielt deres respektive ruter, og forhindrer dermed konstruksjonen av et nettverk.
Dette sikkerhetsproblemet kan ikke rettes på rutingsprotokollnivå.
Sender ugyldige oppdateringsmeldingerEn node har normalt to ansvarsområder:
For å kompromittere hele ruteprotokollen kan angriperen enten sende feil kontrollpakker når noden genererer kontrollmeldingene, eller endre dem når kontrollmeldingene sendes. En kontrollmelding kan tukles med ved å endre identiteten (på engelsk "identity spoofing") eller ved å skade dens data (på engelsk "link spoofing").
Angrep på kontrollmeldingen i løpet av generasjonenI de følgende diagrammene er de gule nodene klassiske noder og de andre er MPR.
Identitetstyveri med en HELLO-meldingEn ondsinnet node utgir seg for å være en annen ved å spoof IP-adressen sin ( IP-adresse spoofing ), for å sende en HELLO-melding til nabolaget.
HELLO-meldingene vil inneholde forfalskninger av topologien i nettverket med innsetting av ikke-eksisterende noder, slik at spoofere blir gjenkjent som MPR, og kan deretter kontrollere alle strømmer som passerer gjennom dem. Det er også mulig å slette eksisterende noder (ved utelatelse i HELLO-meldingene) for å gjøre dem utilgjengelige i den således konstruerte topologien.
Etterligning av en node med en TC-meldingKnutepunkt 5 skal sende en TC-melding som indikerer at det er siste hopp til nodene 6 og 7.
Datakorrupsjon i TC-meldinger består i å sette inn eller fjerne ikke-eksisterende MPRer. Hvis du fjerner MPR-er fra rutetabeller, risikerer du å fragmentere nettverket, og noen MPR-er vil ikke lenger være tilgjengelige. Innsettingen av ikke-eksisterende MPR-noder gjør det mulig å opprette falske lenker og å forvride topologien i nettverket, noe som vil ha en konsekvens av å skape "sløyfer" under ruting eller å generere konflikter under beregningen av rutetabellene.
Angrep på kontrollmeldingen under overføringTC-meldinger må overføres gjennom MPR-er til hele nettverket for å kunne føre viktig informasjon på rutetabellene. Relénoder kan tukle med disse meldingene mens de overføres, ved å legge til eller fjerne MPRer. Problemene kan være mer alvorlige enn når trafikk av HELLO-meldinger, fordi TC-meldinger brukes av alle noder. Det er derfor veldig enkelt å sette i gang et angrep av typen "sort hull" , som bruker noder som diskret får trafikken til å forsvinne.
Det er utført forskning for å sikre protokollen på flere nivåer:
To tilnærminger som er kjent for å være effektive nok til å blokkere uautoriserte brukere eller noder:
Disse løsningene beskytter ikke mot eksterne angrep. I tillegg er bruken av nøkler i et MANET-nettverk komplisert og tungvint å administrere.
Egenskaper for OLSR-meldingerRedundansen mellom HELLO-meldinger og TC-meldinger er en mulighet til å verifisere motstridende informasjon mellom noder for å beskytte OLSR-protokollen. I alle de følgende egenskapene tilsvarer TCp settet med selektorer av P, MPRp med settet med MPRer koblet til P og HELLOp med settet med direkte naboer til p.
Eiendom 1 En HELLO-melding inneholder alle naboer i ett hopp fra den sendende noden, mens en TC-melding inneholder nodenes MPR-velgere (det vil si TC-meldingen, sendt av en MPR, har alle nodene som har valgt dette som relé) . Meldingen TC inneholder derfor et delsett av meldingen HELLO, TCp ← HELLOp. Hvis denne egenskapen brytes, betyr det at den opprinnelige noden til TC-meldingen har satt inn MPR-velgerne og hevder å være en link spoofing (MPR) -node.
3 og 4 er ikke tilstøtende og har valgt 5 som relé. TCp = {3,4} og HELLOp = {1,2,3,4}.Eiendom 2 Hvis en MANET-node mottar en TC-melding som viser den som en MPR-velger, må den opprinnelige være i nærheten av den noden. Hvis C Є TCp, må P Є HELLOc først være sant. Hvis ikke, kan det indikere flere angrep. Den opprinnelige noden til TC-meldingen hevder å være en MPR (koblingsspoofing på en TC-melding).
Hvis node C mottar en TCp = {C ...} melding, må HELLOc = {P ...} sendes først.Eiendom 3
Hvis en MANET-node mottar en TC-melding fra sine naboer informert om at den er en MPR-velger, må denne noden først ha oppført avsenderen av meldingen som en MPR i sin HELLO-melding. Hvis Q Є TCp, må P Є MPRq først være sant. Hvis denne egenskapen blir brutt, later den opprinnelige noden til TC-meldingen til å være en MPR-node for mottakeren og hele dens nabolag, for å avlede trafikken (link spoofing).
Hvis TCp = {C, D}, må P tilhøre MPRene knyttet til C og D.Eiendom 4
Alle videresendte TC-meldinger har identisk innhold. For å bekrefte dette, kan en komponent distribueres i alle noder i nettverket for å oppdage alle ulovlige oppdateringer på kontrollmeldingen. Nodene som mottar TC-meldingene vil bruke "validering", som også vil bli brukt av nodene som overfører dem. Konfliktkontroll gjør det da mulig å øke sikkerhetsnivået til protokollen, så vel som robustheten til rutingsoperasjonene.
For å takle ulempene med OLSR-protokollen er forskjellige protokoller under utvikling eller har blitt utviklet for å svare på manglene ved protokollen.
BATMANOLSR lider av et alvorlig problem med synkroniseringen av TC-meldingene og ruteinformasjonen i hver av nodene.
Faktisk kan rutene som er kjent av nodene og den virkelige tilstanden til topologien variere i løpet av en viss tidsperiode, og det er nødvendig å vente til oppdateringen av topologien er utført for å få igjen riktige ruter. Som kan skape sløyfer i nettverket.
Dette er en av grunnene til at utviklingen av BATMAN- protokollen ble startet.
OLSRv2OLSRv2 har også vært under utvikling av IETF siden 2005, og korrigerer manglene ved OLSR, og er foreløpig fortsatt i standardiseringsfasen, en endelig versjon (RFC) bør snart se dagens lys.
CE-OLSRCE-OLSR er en versjon basert på OLSR, men som integrerer plasseringen av noder.
Hver HELLO-melding blir således lagt til et felt der dets egen posisjon (GPS-koordinater) så vel som de av naboene legges til.
Hver TC-melding blir også lagt til av MPR-ene et felt dedikert til koordinatene til de andre MPR-velgerne.
CE-OLSR gir dermed følgende forbedringer:
M-OLSR er en variant av OLSR som endrer protokollen for å gi bedre ytelse innen WMN (trådløse nettverk), nemlig:
WMN-er skiller seg fra MANET-er i sin noe forskjellige arkitektur. Faktisk, mens en MANET ikke har noe fast punkt blant alle noder, har en WMN en node som er kjent for alle de andre, og spiller rollen som ryggrad i nettverket. Følgene av en modifisering av OLSR-protokollen er derfor ikke nødvendigvis den samme, avhengig av om det aktuelle nettverket er av typen WMN eller MANET.
TjenestekvalitetDe QoS støttes ikke direkte i OLSR, men et prosjekt integrere denne funksjonen er under utvikling.
QoS-styring er ikke trivielt i tilfelle en ruteprotokoll for koblingstilstand på grunn av dens stadig skiftende struktur og den begrensede kraften som er tilgjengelig i nodene som utgjør MANET-er.
En proaktiv ruteprotokoll har fordelen av å kunne opprettholde forhåndsberegnede ruter som QoS kan stole på for å ta raske avgjørelser, noe som ikke er tilfelle med reaktive ruteprotokoller som bare beregner ruter.
Dette er en betydelig fordel i sammenheng med nettverk av uforutsigbar natur, som MANET. Kontrolllaget kan enkelt verifisere om en forhåndsberegnet rute kan oppfylle etterspørselen, og hvis ikke, og dermed unngå å generere unødvendig trafikk knyttet til ruting og topologi.
Valg av PRMEn første måte å gå videre på er å endre valgalgoritmen til MPR-ene. Oppførselen definert av OLSR RFC indikerer at dette valget er gjort på grunnlag av antall naboer, noden valgt som MPR er den med flest 2-hopp-naboer.
Imidlertid tar denne valgmetoden ikke hensyn til kvaliteten på lenkene som forbinder nodene, noe som fra et servicekvalitetsperspektiv likevel er et av de mest kritiske punktene.
En annen algoritme kan bestå i å stole på tilgjengelig båndbredde som det første kriteriet for valg av MPR. Målet er da å oppnå en rute med høyest mulig gjennomstrømning, en faktor som spiller en overveiende rolle i sanntidsapplikasjoner som mer og mer brukes i dag.
Opprinnelig velger OLSR den korteste banen når du velger MPR-er, noe som ikke nødvendigvis er synonymt med ytelse. Det er fortsatt nødvendig å definere begrepet "ytelse" (latens, båndbredde, redundans osv.).
I tilfelle man ønsker å orientere ytelsen mot et eller annet aspekt spesielt, må algoritmen modifiseres for å velge MPR-er i henhold til andre faktorer enn forbindelsen til nodene, for eksempel hastigheten, i tilfelle båndbredde er den primære begrensningen for QoS.
Et forsøk på å modifisere OLSR-protokollen er vist nedenfor, med sikte på å maksimere end-to-end båndbredde, samtidig som det sikres at hver 2-hop node fortsatt er tilkoblet. Verdiene som er angitt representerer båndbredden: jo høyere den er, desto mer er båndbredden viktig.
StandardalgoritmeI sin opprinnelige versjon tar OLSR ikke hensyn til båndbredden som er tilgjengelig for hver lenke.
Node B vil derfor velge C som sin MPR i dette tilfellet, fordi det er den som har flest forbindelser med de andre nodene.
Dette betyr derfor at når D bygger rutetabellen sin, vil han automatisk velge DCB-ruten for å bli med i node B. Denne ruten er den verste av alle med en flaskehals som lider av den mest restriktive hastigheten på hele MANET. (Verdi 3) mellom D og C.
Ved dette blatante eksemplet innser vi at OLSR ikke vil velge den raskeste banen.
Algoritmen forblir nesten identisk med den opprinnelige versjonen.
Når det er mer enn en en-hopp-node, men de dekker alle det samme antallet to-hopp-noder, blir den med høyest båndbredde valgt til MPR.
F blir derfor valgt til MPR i stedet for C, fordi lenken som forbinder B til F (100) har høyere hastighet enn koblingen mellom B og C (50).
Ideen med denne andre versjonen er å velge noder med den beste båndbredden først, så lenge alle tohopp-noder er dekket.
I dette tilfellet vil nodene A og F velges med henholdsvis en båndbredde på 110 og 100 fra B.
À blir først valgt takket være den høyeste båndbredden, men å velge bare node A som MPR vil ikke tillate tilkobling til alle to-hopp-noder (E vil ikke nås av B).
Dette er grunnen til at node F er valgt som den andre MPR (og ikke C, fordi 100> 50).
Den tredje modifikasjonen av algoritmen sammenligner hver bane fra B til hverandre node som ligger 2 humle fra MANET. Deretter velger den eneste banen med høyest båndbredde til hver av disse nodene.
Under tabellen vises sammenligningen av båndbredden og årsaken til at node F er valgt for å koble til noder B og D.
startnode | Båndbredde mellom noder | mellomknute | Båndbredde mellom noder | sluttnode | Maksimal resulterende båndbredde |
---|---|---|---|---|---|
B |
110 |
PÅ |
5 |
D |
5 |
B |
50 |
VS |
3 |
D |
3 |
B |
100 |
F |
10 |
D |
10 |
→ F er MPR som tillater å ha høyest båndbredde. |
Samme begrunnelse for sammenføyning av noder B og E: C er valgt MPR.
Disse forskjellige modifikasjonene har potensial til å forbedre ytelsen ved å bringe bedre båndbredde til hver node.
På den annen side kan de også generere en overbelastning av kontrolltrafikken (bærer informasjon om topologien), spesielt i det tredje eksemplet der det potensielt er mulig å velge en annen MPR per 2-hopp-node.
Nodene i MANET-nettverket er ikke koblet til det elektriske nettverket, og som et resultat er batterienergien begrenset. Batteriets levetid kan også påvirke nettverkets kommunikasjonsytelse. Når en node går tom for tilgjengelig strøm, slutter den å fungere, og det kan være mangel på mobile verter i nettverkspartisjonering. Av denne grunn er redusert strømforbruk et viktig tema i trådløse ad hoc-nettverk. OLSR-protokollen tar ikke hensyn til strømforbruket under valg av MPR-node, heller ikke under ruting av datapakker, og har ingen fordeler av unicast-koblingsinformasjonen i nettverket. Endringene som er tenkt for å ta hensyn til disse aspektene er blant annet protokollene EE-OLSR , EOLSR og DE-OLSR :
For å ta hensyn til energiforbruket til nodene, er det innført visse beregninger i nettverkslaget for EE-OLSR :
Med inkluderingen av disse beregningene og to andre forbedringer av energiaspektet til OLSR-protokollen, etablerer EE-OLSR-protokollen disse mekanismene:
EOLSR- protokollen ble designet som EE-OLSR for å minimere strømforbruket for pakkeoverføring, for å gjøre lastbalansering mellom nettverksnoder, for å unngå noder med lite gjenværende kraft og redusere overbelastning. For å gjøre dette har designet blitt utarbeidet i disse fire aspektene:
I et rammeverk som er litt annerledes enn de to andre, ble DE-OLSR- protokollen designet for ad-hoc VANET-nettverk. Disse ligner konseptuelt på MANET-nettverk og er ment for trådløs kommunikasjon av kjøretøy utstyrt med innebygde datamaskiner, elektroniske elementer fra trafikksignaler, sensorer og fotgjengere med smarttelefoner. I utgangspunktet implementerer ikke denne algoritmen en løsning spesielt designet for å være effektiv når det gjelder energikostnader. Hovedideen er å finne en effektiv innstilling for å optimalisere kvaliteten på tjenesten til OLSR-protokollen fra synspunktet til pakkeleveringshastigheten til den normaliserte rutingbelastningen og en gjennomsnittlig punkt-til-punkt-forsinkelse av datapakker fra VANET-nettverk. . Dette utføres ved kobling med en metaheuristisk differensiell evolusjon (DE). Protokollen klarer i gjennomsnitt å spare nesten to tredjedeler energi sammenlignet med standard OLSR på utveksling av kontrollmeldinger i et VANET-nettverk, samtidig som energiforbruket i dataoverføring og belastning reduseres.
Andre ruteprotokoller finnes for mobilnettverk. Her er en ikke-uttømmende sammenligning mellom noen av dem:
OLSR og BATMAN.Flere ytelsestester ble utført, inkludert en praktisk sammenligning mellom implementeringer av OLSRv1 og BATMAN i nettverk av varierende størrelse og trafikk.
Når det gjelder forholdet mellom leverte pakker, viste det seg at når trafikken er lav, presterer OLSR bedre enn BATMAN. Tendensen snus når trafikken blir viktig.
Når det gjelder trafikkoverbelastning (ruting og topologiinformasjon), presterer OLSR bedre enn BATMAN så lenge antall noder forblir beskjedent, uavhengig av trafikkintensitet.
Når antall noder øker, blir BATMAN den mer effektive protokollen for de to.
DSR, AODV og OLSREn sammenligning mellom DSR og AODV (reaktive) og OLSR (pro-aktive) protokoller ble også utført, og fremhevet appellen til OLSR for CBR- kilder (for eksempel voice over IP ), noe som garanterte kortere ledetid enn de tidligere nevnte reaktive protokollene. .
På den annen side bruker OLSR mye mer båndbredde på grunn av rutene som den opprettholder kontinuerlig og genererer kontinuerlig vedvarende trafikk.
Testene viste at de reaktive protokollene var mer passende enn OLSR innen datakopiering (for eksempel filutveksling), uten å vite hvordan man tydelig skiller DSR og AODV fra et ytelsesperspektiv.
OLSR, AODV og TORAEn annen sammenligning mellom OLSR-, AODV- og TORA-protokollene førte frem følgende resultater:
Ytelsesbegrensning | OLSR | AODV | TORA |
---|---|---|---|
Kategori |
Proaktiv |
Reagens |
Hybrid |
Protokolltype | Koblingsstatusskjema | Avstandsvektor | Tilbakeføring av lenker |
Ruter vedlikeholdt i | Rutetabell | Rutetabell | Rutetabell |
Sløyfefrihet | Ja | Ja | Ja |
Veifilosofi | Tallerken | Tallerken | Tallerken |
Flere ruter | Nei | Nei | Ja |
Multicast | Ja | Ja | Nei |
Nettverk overbelastning | Minimal | Moderat | Moderat |
Periodisk kringkasting | Mulig | Mulig | Mulig |
Krever datasekvenser | Nei | Ja | Ja |
Rute omkonfigureringsmetode | Kontrollmeldinger sendt på forhånd for å øke responsen | Rutefjerning og kildevarsling | Vegreparasjon ved reversering av lenker |
sammendrag | Kontrollmeldinger for koblingsdeteksjon, nabodeteksjon (MPR), deteksjon av flere grensesnitt, ruteberegning. | Oppdagelse av veier, ringutvidelse, forskning, forfølgelse av stien. | Omvendte lenker, ruteoppdagelse, ruteoppdateringspakker |
Lav mobilitet og lite trafikk | ||||
---|---|---|---|---|
Protokoll | End-to-end forsinkelse | Leveringsforhold | Stiens optimalitet | Routing protokoll overbelastning |
OLSR |
Lav |
Høy |
God |
Lav |
AODV | Vei | Høy | Gjennomsnitt | Lav |
TORA | Lav | Høy | God | Gjennomsnitt |
Høy mobilitet og høy trafikk | ||||
---|---|---|---|---|
Protokoll | End-to-end forsinkelse | Leveringsforhold | Stiens optimalitet | Routing protokoll overbelastning |
OLSR |
Lav |
Vei |
Gjennomsnitt |
Lav |
AODV | Vei | Vei | Gjennomsnitt | Lav |
TORA | Høy | Lav | Gjennomsnitt | Gjennomsnitt |
Studien som sammenlignet disse tre protokollene fra forskjellige familier førte til følgende funn:
Siden OLSR er et lag 3-nettverk , er det svært bærbart og kjøres på ethvert standard I386- og PPC- operativsystem gjennom OLSRd-brukergrensesnitt-pluginet.