MobileandWirelessCompu2ngCITS4419Week3MACProtocols

AssociateProfessorRachelCardell-OliverSchoolofComputerScience&So;wareEngineering

semester-22018

WhystudyMAC?(shouldCSstudentsstudyWSNMACprotocols)

•  ControllingwhentosendapacketandwhentolistenforapacketareperhapsthetwomostimportantoperaKonsinawirelessnetwork–  Especially,idlewaiKngwasteshugeamountsofenergy

•  CommunicaKoninasensornetworkischallengingbecause–  Powerislimited–  Thechannelisshared

•  MACprotocolsforsensornetworksaimtosharethechannelinanenergyefficientmanner

What

•  LastweekwesawhowdatacouldbetransmiQedonwirelesschannel

•  ThisisthePhysicalLayerofasensornetwork•  Thisweekwewillconsiderthenextlayer:theMAClayer

•  TheMAClayerisresponsibleformanagingtheexchangeofmessagesbetweenpairsofnodesinasensornetwork

Overview

•  WSNMACchallenges•  ContenKonMACs–Aloha•  ScheduledMACs–SMAC,FlexiMAC•  HybridMACs-IEEE802.15.4MAC•  LoRaWAN

SharedChannelChallenges

•  Energy– Tosaveenergyneedtominimisecollisions,overhearing,re-transmissions,hiddenterminal

•  Latency– ApplicaKondependent–deliverdataassoonaspossible

RecommendedReading

A.Bachir,M.Dohler,T.WaQeyne,andK.Leung,MACEssen)alsforWirelessSensorNetworks,CommunicaKonsSurveysandTutorials12(2)2010

WhatisaMACprotocol?

•  Thetermprotocolreferstotherulesthatgovernwhateachnodeinanetworkisallowedtodoandhowitshouldoperate

•  MACprotocolsdefinehowmulKplenodescontroltheiraccesstoasharedmedium

•  Theyaretermedmediaaccess(MAC)protocolsormul)pleaccessprotocols.

Challenge1:SharedChannel

PacketCollisions

Challenge2:Power

Powerconsump2oninWSNs

EnergyconsumpKon

Source:MACEssenKalsforWirelessSensorNetworks,Bachir2010

OverviewofMACprotocols

WSNMACRequirements•  DesignConstraints

–  Transmissionsarecostly–  Receivingaboutasexpensiveastransmi`ng–  IdlingcanbecheaperbutissKllexpensive

•  Energyproblems–  Collisions–wastedeffortwhentwopacketscollide–  Overhearing–wasteeffortinreceivingapacketdesKnedforanothernode

–  Idlelistening–si`ngidlyandtryingtoreceivewhennobodyissending

–  Protocoloverhead•  Alwaysnice:LowcomplexitysoluKon

Ad hoc & sensor networs - Ch 5: MAC protocols

SS 05 Ad hoc & sensor networs - Ch 5: MAC protocols 14

Main wireless MAC options Wirelessmediumaccess

Centralized

Distributed

ContenKonSchedule

Fixedassignment

Demandassignment

ContenKonSchedule

Fixedassignment

Demandassignment

ContenKonMACs

Aloha(1968Hawaii)

Byhelix84-Ownwork,CCBY2.5,hQps://commons.wikimedia.org/w/index.php?curid=1374485ByOriginal:KyurimVector:flThisvectorimageincludeselementsthathavebeentakenoradaptedfromthis:AlohaSvG.PNG.-AlohaSvG.PNG,CC0,hQps://commons.wikimedia.org/w/index.php?curid=27793990

Protocol=Whenreadythensendmessage(Distributed,ContenKon)

Alohaimprovements

Source:MACEssenKalsforWirelessSensorNetworks,Bachir2010

ScheduledMACs

ScheduledMACprotocols

Idea: Coordinate node schedules

Advantages: Turn off radio when not needed (allocated time slot) Limits collision, idle listening, overhearing

Disadvantages: Rigidity – fixed sleep times Not flexible to changes in sensor density or movements Sleep delays increase packet delivery time (latency)

S-MAC

Strategy:Eachnodebroadcastsandfollowsitslisten/sleepscheduleTotalktoyourneighbour,wakeupwhensheislisteningUseRTS/CTStoresolveconflictPeriodicallylistenforallnodes’schedulesSYNCpktssynchronisenodes’clocksYeetal,MediumAccessControlwithCoordinatedAdap)veSleepingforWSNs,IEEETransacKonsonNetworking2004

S-MACcoordinaKon

Source:MACEssenKalsforWirelessSensorNetworks,Bachir2010

FlexiTP

FlexiTP:AFlexible-Schedule-BasedTDMAProtocolforFault-TolerantandEnergy-EfficientWirelessSensorNetworks,Lee,WinnieLouis;DaQa,Amitava;Cardell-Oliver,Rachel,InIEEETransac2onsonParallelandDistributedSystems,vol.19,no.6,pp.851-864,June2008

22Sep2010 22MannheimSummerSchool

HybridMACs

IEEE802.15.4

IEEE802.15.4Standard

•  Forlow-ratewirelesspersonalareanetworks•  10mcommsrange,datarate250kbit/s•  DefinesphysicallayerandMACprotocols•  Usedasbaseprotocolsfor

–  ZigbeeIoTmeshprocotol–  ISA100.11aProcessandfactoryautomaKon– WirelessHARTreal-KmeautomaKonandindustryapps– MiWi,SNAP–  6LoWPANforIPv6overpersonalareanets

•  Home Networking

•  Automotive Networks

•  Industrial Networks

•  Interactive Toys

•  Remote Metering

•  Environmental Monitoring sensor networks

•  Infrastructure monitoring sensor networks

IEEE 802.15.4 Applications Space

Joe Dvorak, Motorola 9/27/05 22Sep2010 26MannheimSummerSchool

Features

•  Networkbeaconsforcommsmanagement•  GuardedKmeslots(foreg.alarms)•  Securitysupport•  Frequencybands:868/915/2450MHz

Topologies

•  MACsupportspeertopeerorstarnetworks•  Peertopeerforselfmanaging,adhocnetworks(meshnetworks)

•  StarpaQernhascoordinators,fullfuncKondevices(clusterheads)andreducedfuncKondevices(leafnodes)

•  FullfuncKondevice(FFD)–  Anytopology–  Networkcoordinatorcapable–  Talkstoanyotherdevice

•  ReducedfuncKondevice(RFD)–  Limitedtostartopology–  Cannotbecomeanetworkcoordinator–  Talksonlytoanetworkcoordinator–  VerysimpleimplementaKon

IEEE 802.15.4 MAC Overview Device Classes

Slide 29 Joe Dvorak, Motorola 9/27/05 22Sep2010 29MannheimSummerSchool

Sensornode

Basenodeorclusterhead

Full function device

Reduced function device

CommunicaKonsflow

Master/slave

PANCoordinator

IEEE 802.15.4 MAC Overview Star Topology

Slide 30 Joe Dvorak, Motorola 9/27/05 22Sep2010 30MannheimSummerSchool

Full function device Communications flow

Point to point Cluster tree

IEEE 802.15.4 MAC Overview Peer-Peer Topology

Slide 31 Joe Dvorak, Motorola 9/27/05 22Sep2010 31MannheimSummerSchool

Full function device

Reduced function device

Communications flow

Clusteredstars-forexample,clusternodesexistbetweenroomsofahotelandeachroomhasastarnetworkforcontrol.

IEEE 802.15.4 MAC Overview Combined Topology

Slide 32 Joe Dvorak, Motorola 9/27/05 22Sep2010 32MannheimSummerSchool

FrameTypes

•  Data•  Acknowledgement•  Beacon•  MACcommand

•  SloQedorunsloQedCSMA/CA

•  Datatransfer=beaconsync+datainslots+opKonalack=request+confirm+response

052004 MarcoNaeve,EatonCorp. Slide34

GeneralMACFrameFormat

Octets:2 1 0/2 0/2/8 0/2 0/2/8 variable 2Destination

PAN identifier

Destination address

Source PAN

identifier

Source address

MAC payload MAC footer

Frame check

sequence

MAC header

Addressing fields

Frame control

Sequence number

Frame payload

Bits: 0-2 3 4 5 6 7-9 10-11 12-13 14-15

Frame type Sequrity enabled

Frame pending

Ack. Req. Intra PAN ReservedDest.

addressing mode

ReservedSource

addressing mode

Framecontrolfield

052004 MarcoNaeve,EatonCorp. Slide35

BeaconFrameFormat

Bits: 0-3 4-7 8-11 12 13 14 15Beacon

orderSuperframe

orderFinal CAP

slotBattery life extension Reserved

PAN coordinator

Association permit

Octets:2 1 4 or 10 2 variable variable variable 2

MAC footer

Frame check

sequence

MAC header

Source address information

MAC payload

Superframe specification

GTS fields

Pending address

fields

Frame control

Beacon sequence number

Beacon payload

052004 MarcoNaeve,EatonCorp. Slide36

MACCommandFrame

•  CommandFrameTypes–  AssociaKonrequest–  AssociaKonresponse–  DisassociaKonnoKficaKon–  Datarequest–  PANIDconflictnoKficaKon

–  OrphanNoKficaKon–  Beaconrequest–  Coordinatorrealignment–  GTSrequest

Octets:2 1 4 to 20 1 variable 2

MAC footer

Frame check

sequence

Frame control

Data sequence number

Address information

MAC header MAC payload

Command type

Command payload

052004 MarcoNaeve,EatonCorp. Slide37

DataFrameFormat

Acknowledgement Frame Format Octets:2 1 2

MAC footer

Frame check

sequence

MAC header

Frame control

Data sequence number

Octets:2 1 4 to 20 variable 2

MAC Payload MAC footer

Data payloadFrame check

sequence

MAC header

Frame control

Data sequence number

Address information

LoRaWAN

LoraWAN

LoRa-Alliance.org

MeshNetwork

•  Meshnetwork:individualend-nodesforwardtheinformaKonofothernodestoincreasethecommunicaKonrangeandcellsizeofthenetwork.Whilethisincreasestherange,italsoaddscomplexity,reducesnetworkcapacity,andreducesbaQerylifeKme

LoRa-Alliance.org

StarNetwork•  Singlehopefromsensornodestoagateway•  LongrangestararchitecturemakesthemostsenseforpreservingbaQerylifeKmewhenlong-rangeconnecKvitycanbeachieved

LoRa-Alliance.org

End-devices

Eachend-deviceclasshasdifferentbehaviordependingonthechoiceofopKmizaKon:•  BaQeryPowered–ClassA•  LowLatency–ClassB•  NoLatency–ClassC

LoRa-Alliance.org

BaQeryPowered–ClassA•  BidirecKonalcommunicaKons

•  Unicastmessages•  Smallpayloads,longintervals•  End-deviceiniKatescommunicaKon(uplink)•  Servercommunicateswithend-device(downlink)duringpredeterminedresponsewindows:

LoRa-Alliance.org

LowLatency–ClassB•  BidirecKonalwithscheduledreceiveslots•  UnicastandMulKcastmessages•  Smallpayloads,longintervals•  Periodicbeaconfromgateway•  Extrareceivewindow(pingslot)•  ServercaniniKatetransmissionatfixedintervals

LoRa-Alliance.org

NoLatency–ClassC

•  BidirecKonalcommunicaKons•  UnicastandMulKcastmessages•  Smallpayloads•  ServercaniniKatetransmissionatanyKme•  End-deviceisconstantlyreceiving

LoRa-Alliance.org

TTNthethingsnetwork

•  Furtherreading•  hQps://www.thethingsnetwork.org/

Summary

•  WSNMACchallenges•  ContenKonMACs–Aloha•  ScheduledMACs–SMAC,FlexiMAC•  HybridMACs-IEEE802.15.4MAC•  LoRaWAN