Wilamowski B.M., Irwin J.D. The Industrial Electronics Handbook. Second Edition: Industrial Communication Systems

Подождите немного. Документ загружается.

51-2 Industrial Communication Systems

51.2.1 IP as Open Standard Protocol Instead of Proprietary Protocols

On.low-power.wireless.devices.like.WSN.nodes.and.for.smart.and.cooperating.objects.(SCO),.Zigbee.

ove

.IEE

.802

.15.4

.is.the.pre

dominating

.pro

tocol

.toda

.Alt

ernatively,

.for.mac

hine-to-machine

.com

munication

.(M2

.and.for.int

egration

.pur

poses

.in.ent

erprise

.sys

tems,

.IP.wou

.be.a.sui

table

.con

tribu-

tor.

.Unt

.rec

ently,

.IP.was.not.an.opti

.bec

ause

.the

.wer

.no.IP.sta

cks

.ava

ilable,

.whi

.wou

.run.on.

reso

urce-constrained

.WSN.nod

es.

.How

ever,

.tod

.reso

urce

.opt

imized

.IP.sta

cks

.are.avai

lable

.whi

.run.

on.tin

.8.bit.micr

ocontrollers

.lik

.TI’

.MSP.430

—a

.com

monly

.use

.micr

ocontroller

.in.WSN

. e.foo

tprint

of.su

.IP.st

acks

.fo

.mi

crocontrollers

.is.ar

ound

.12.k.by

.(c

.uI

Pv6

.[D

ur08]).

51.2.2 IP routers Instead of Complex Gateways

WSN.lie.on.the.edge.of.networks.or.at.the.eld.level.in.process.automation..Today,.specic.gateway.or.

pro

.con

cepts

.are.use

.to.int

egrate

.WSN.wit

.the

.pro

prietary

.pro

tocols

.into.ent

erprise

.sys

tems

.or.

hig

her

.val

.ser

vices

.in.IP-b

ased

.net

works.

.Cha

nges

.in.pro

tocol

.dat

.rep

resentation

.and.dat

.enc

oding

req

uire

.hig

.eo

rts

.on.the.nec

essary

.app

lication

.lay

.(AP

.gat

eways.

.In.con

trast

.to.gat

eways,

.rou

ters

jus

.for

ward

.pac

kets

.and.do.not.nee

.to.hav

.a.dee

.kno

wledge

.abo

.the.mis

sion

.of.the.spe

cic

.WSN.

and.ap

plied

.pr

otocols.

51.2.3 Use of already Existing Protocols, tools, and applications

Hooked.on.IP,.other.higher.level.protocols,.tools,.and.applications.have.been.established..Protocols.like.

DNS

.DHC

.Zer

oconf,

.etc

.can.be.use

.for.nam

ing,

.add

ressing,

.dis

covery,

.and.con

guration.

.Too

lik

.SNM

.pin

.arp

.tra

ceroute,

.etc

.are.usa

ble

.for.man

agement

.pur

poses.

.Eve

.on.APL

.mat

ured

.pro

tocols,

.dat

.mod

els,

.and.ser

vices,

.suc

.as.HTT

.HTM

.XML

.SOA

.RES

.etc

.are.wel

.est

ablished

and.fu

ndamental

.fo

.im

portant

.IT.de

velopments.

51.2.4 New architectural Styles like Service-Oriented architectures

New. methodologies. and. paradigms. like. service-oriented. architectures. (SOA). would. benet. from.

IP-b

ased

.com

munication

.[Bo

h09].

.So

ware

.and.ser

vice

.ind

ustry

.use

.Web.ser

vices

.as.glu

.bet

ween

di

erent

.app

lications

.for.int

egration

.and.int

eroperability.

.WSN.are.int

egrated

.in.net

working

.env

iron-

ments

.by.usin

.Web.ser

vices

.via.com

plex

.APL.gat

eways.

.But.thi

.is.not.a.goo

.sol

ution

.on.a.lon

.ter

In.fut

ure

.app

lications,

.new.con

cepts

.and.arc

hitectures

.are.pos

sible

.and.muc

.res

earch

.is.nec

essary

.to.

nd.acc

eptable

.sol

utions

.for.ser

vice

.ori

entation

.in.WSN

.Cha

llenges

.are

.e.g

.to.nd.acc

eptable

.com

pression

.for.XML.dat

.rep

resentation,

.to.spe

cify

.Web.ser

vice-compliant

.pro

les

.(sim

ilar

.to.the.dev

ices

pro

le

.for.Web. ser

vices—DPWS—for

.WSN

.to.rea

lize

.cos

t-eective

.SOA. sol

utions,

.and.to.red

uce

ene

rgy

.co

nsumption

.fo

.se

rvice-oriented

.so

lutions

.fo

.WS

.[M

or09,Mor09_2].

51.2.5 IP Support in Operating Systems

Today,.IP.is.supported.by.all.classes.of.operating.systems.ranging.from.desktop.operating.systems,.

embe

dded

.and.rea

l-time

.ope

rating

.sys

tems,

.to.ope

rating

.sys

tems

.for.WSN.lik

.Con

tiki

.[Du

n04].

.IP.

pro

tocol

.sta

cks

.are.ava

ilable

.as.an.int

egral

.par

.of.the.ope

rating

.sys

tem,

.as.ope

n-source

.so

ware

.sta

cks

and.com

mercial

.sol

utions.

. e.uIP

.[Du

n07,Dur08]

.sta

.is.an.imp

lementation

.of.the.6Lo

WPAN

pro

tocols

.des

cribed

.in.thi

.sec

tion.

.For.pro

prietary

.pro

tocols,

.the

.are.onl

.a.few.ope

n-source

.sol

utions

ava

ilable.

. ey.are.lim

ited

.to.spe

cic

.app

lication

.are

.and.app

lication

.nic

hes.

.Fut

ure

.net

works

.of.SCO.

are.not.for.nic

.mar

ket

.onl

. ey.wil

.pav

.the.way.for.ver

.new.and.bro

.app

lication

.are

as.

.So,.IP.

rad

ically

.he

lps

.to.en

force

.th

.de

velopment.

6LoWPAN: IP for Wireless Sensor Networks and Smart Cooperating Objects 51-3

51.2.6 Lessons Learned From Maintaining the Internet

New.protocols.require.a.deep.understanding.and.a.profound.knowledge.of.the.internals..By.decades.

of.iterations,.IP.and.further.protocols.are.matured,.wide.ranging,.and.well.understood.. is.results.in.

reduced.educational,.implementation,.installation,.and.maintenance.costs.

51.3 Introduction in 802.15.4

Developments.of.new.protocols.for.WSN.and.SCO.have.just.started.and.are.in.progress..Based.on.IEEE.

802.15.4.[IEEE154],.which.denes.the.PHY.and.MAC.communication.layers.as.depicted.in.Figure.51.1,.

various.upper.layer.protocols.are.dened.by.large.industrial.consortia,.e.g.,.WirelessHART,.ISA.SP100,.

ZigBee..Open.standards.and.proprietary.industrial.consortia.standards.will.be.in.a.close.competition..

Key.features.of.all.protocols.are

•

. Long.battery.life.through.low-power.concepts

•

. Self-healing.networks

•

. Scalability.and.support.of.large.networks

•

. Low-cost.node

•

. Low.data.rate

IEEE

.802.15.4.is.a.standard.for.WPANs.with.low.data.rates.(LR.WPAN)..While.technologies.like.Wi-Fi.

(802.11).and.Bluetooth.have.been.developed.for.high.data.throughput,.the.focus.of.IEEE.802.15.4.net-

works

.was.power-aware.and.low-cost.design,.which.results.in.low.data.rates.(up.to.250.kbps).

IEEE

.802.15.4.standard.distinguishes.between.two.device.classes:.full.function.devices.(FFD).and.reduced.

function.devices.(RFD)..In.accordance.to.IEEE.802.15.4,.a.device.is.“any.entity.(RFD.or.FFD).containing.an.

implementation.of.IEEE.802.15.4.MAC.and.PHY.interface.to.the.wireless.medium.”.A.coordinator.is.an.FFD.

with.network.device.functionality.that.provides.synchronization.and.other.services.to.the.network..A.PAN.

coordinator.is.the.principal.controller.of.a.personal.area.network.(PAN)..An.IEEE.802.15.4.network.has.one.

PAN.coordinator.

.main.dierence.between.RFDs.and.FFDs.is.the.requirements.for.resources.as.RFDs.are.only.

applied.for.simple.applications..An.FFD.can.operate.in.any.topology.and.can.run.as.PAN.coordinator,.

coordinator,.and.device..RFDs.are.limited.to.star.topologies.and.end.devices.. ey.are.communicating.

directly.with.a.coordinator,.while.FFDs.can.both.interact.with.any.type.of.device.(RFD.and.FFD).and.

operate.in.star.and.peer-to-peer.networks..In.star.topology,.all.devices.are.communicating.with.a.PAN.

coordinator..In.peer-to-peer.topologies—also.known.as.mesh.networks—all.devices.can.communicate.

with.each.other.(cf..Figure.51.2).

For

.the.communication.of.FFDs.and.RFDs,.802.15.4.describes.a.beacon-enabled.mode..RFDs.can.

stay.in.low-power.sleep.states.for.predened.time.slots.. ey.only.wake.up.to.receive.the.periodical.

beacons.of.the.coordinator.(FFD)..Additional.to.the.beacon.signal,.further.information.is.included.if.

IEEE 802.15.4

MAC

Network

Application

Transport

DPWS/SOAP/WSDL

XML Schema/HTTP/...

Prole

TCP/UDP

IPv4, IPv6

IEEE 802.3,

802.11a/b/g...

ZigBee

IETF 6LoWPAN

802.15.1

Prole

Bluetooth

Application specic

prole

...

Wireless-

HART

(draft)

ISA SP100

(draft)

IEEE 802.15.4e (+TDMA

and channel hopping)

PHY

Gateway/proxy required

FIGURE 51.1 802.15.4.dened.PHY.and.MAC.layers.

51-4 Industrial Communication Systems

data.is.pending.to.be.received.by.the.specic.RFD.and.the.time.slot.reserved.for.the.data.transmission..

 us,.RFDs.only.need.to.wake.up.and.activate.power-consuming.radio.for.receiving.of.beacons.and.data.

addressed.directly.to.them.

.IEEE.802.15.4.network.requires.at.least.one.FFD.as.a.network.coordinator;.all.other.devices.can.

be.RFDs..Because.transmission.range.of.LR.WPAN.is.very.limited,.by.means.of.integrating.additional.

routers,.meshed.networks.can.be.built.. ese.routers.are.FFDs.. ey.forward.data.hop.wise.and.enlarge.

the.dimension.of.the.network.

All

.devices.shall.have.unique.64.bit.IEEE.end-system.unique.identier.(EUI).addresses.[EUI64],.typi-

cally

.hard.coded.by.manufacturers.. is.64.bit.address.may.be.used.for.direct.communication.in.the.

network..To.elide.protocol.and.addressing.overhead,.alternatively.a.PAN.coordinator.may.allocate.a.short.

16.bit.address.to.devices.that.allows.theoretically.65,535.end.devices.to.be.included.in.one.network..Short.

addresses.are.unique.for.one.subset.of.the.network.and.the.same.short.address.can.be.used.in.dierent.

subset.networks..In.such.a.case,.the.additional.16.bit.PAN-ID.is.used.to.dierentiate.between.the.networks.

.IEEE.802.15.4.standard.denes.two.PHY.layers:.the.2.4.GHz.and.868/915.MHz.band.PHY.layers..

 e.PHY.layer.depends.on.local.regulation.and.user.preference.. e.unlicensed.2.4.GHz.is.valid.world-

wide

.and.has.a.higher.data.rate.(240.kbps).compared.to.915.MHz.band.with.40.kbps.(United.States).and.

868.MHz.(EU).band.with.20.kbps.data.rate.. e.radio.can.operate.on.16.channels.in.the.2.4.GHz.band,.

10.channels.in.the.915.MHz.band,.and.1.channel.in.the.868.MHz.band.

.IEEE.802.15.4.MAC.denes.four.frame.structures:

. 1.. A.data.frame,.used.for.all.transfers.of.data.and.all.later-described.6LoWPAN.transmissions.

(see.Figure.51.3)

. 2.. An.acknowledgment.frame,.used.for.conrming.successful.frame.reception

. 3..A.MAC.command.frame,.used.to.manage.and.control.network

. 4.. A.beacon.frame,.used.by.a.coordinator.to.transmit.beacons

Data

.frames.of.PHY.layer.start.with.4.bytes.preamble.and.1.byte.Start-of-Frame.(SOF).delimiter.and.

both.are.used.for.synchronization.. e.following.7.bit.eld.species.the.frame.length.of.following.data.

frame.(up.to.127),.a.last.bit.in.that.octet.is.reserved.

MAC

.frame.format.is.composed.of.MAC.Header.(MHR),.Payload,.and.MAC.Footer.(MFR)..MHR.

consists.of.2.byte.frame.control.eld,.1.byte.sequence.number,.address.information,.and.security-related.

information.(4–20.byte).. e.frame.control.eld.species.the.type.of.above-mentioned.frame.types.and.

address.mode.. e.payload.has.a.variable.data.length.and.provides.information.specic.to.individual.

frame.types.. e.frames.end.with.2.byte.checksum.

PAN coordinator

(FFD)

Coordinator (FFD)

End device (RFD)

Star topology Peer-to-peer topology

FIGURE 51.2 IEEE.802.15.4.network.topologies.

6LoWPAN: IP for Wireless Sensor Networks and Smart Cooperating Objects 51-5

51.4 802.15.4 and 6LoWPaN

 e.number.of.wireless.networking.nodes.is.expected.to.rise.in.future,.whereby.low.power.and.low.cost.

“are.essential.enablers.toward.their.deployment.in.networks”.[IETF6LoW].. ese.networks.are.char-

acterized

.by.signicantly.more.devices.than.current.LANs,.severely.limited.code.and.RAM.space,.and.

unobtrusive.but.very.dierent.user.interfaces.for.conguration.[IETF6LoW].. e.assumptions.for.IEEE.

802.15.4.made.above.like.peer-to-peer.network.topology.and.limited.frame.size.require.further.eorts.

to.enable.emerging.IPv6.[RFC2460].on.top.of.802.15.4.as.MAC.and.PHY.layers.. us,.the.IETF.founded.

the.6LoWPAN.[IETF6LoW].working.group.(IPv6.over.low-power.WPAN),.which.has.produced.cur-

rently

.two.RFCs:

•

. IPv6.over. low-power.wireless.personal.area. networks. (6LoWPANs):.overview,.assumptions,.

problem.statement,.and.goals.(RFC4919)

•

. Transmission.of.IPv6.packets.over.IEEE.802.15.4.networks.(RFC4944)

.RFC4919.document.describes.the.requirements.that.have.to.be.considered.for.realizing.IPv6.in.

low-power.wireless.networks.and.focuses.on.IEEE.802.15.4.based.on.application.scenarios.of.6LoWPAN.

protocols.. e.RFC4944.instead.describes.dierent.dedicated.compression.formats.and.required.adap-

tations

.and.enhancements.for.IPv6.on.IEEE.802.15.4.

Additionally,

.the.working.group.has.published.four.documents.“to.ensure.interoperable.implemen-

tations

.of.6LoWPAN.networks”.and.to.“dene.the.necessary.security.and.management.protocols.and.

constructs.for.building.6LoWPAN.networks,.paying particular attention to protocols already available”.

[IETF6LoW].. ese.documents.and.further.eorts.in.and.around.the.6LoWPAN.working.group.focus.

on.applicability.of,.e.g.,.neighbor.discovery.(ND),.MIB,.and.SNMP..Reuse.of.existing.technologies.and.

protocols.is.a.core.characteristic.of.6LoWPAN.and.related.eorts.. e.6LoWPAN.working.group.and.

miscellaneous.dra.documents.are.still.active.at.the.time.of.writing.this.section.. erefore,.this.section.

concentrates.on.the.existing.RFCs,.explanations.of.the.core.concepts,.and.not.on.still.active.and.inten-

sively

.discussed.dras..Routing.protocols.for.6LoWPAN.networks.are.not.focused.by.the.6LoWPAN.

working.group.at.all.and.will.be.dened.by.the.routing.over.low-power.and.lossy.networks.(ROLL).

[IETFROLL].working.group..Hence,.the.6LoWPAN.working.group.denes.only.recommendations.for.

the.ROLL.working.group.based.on.their.experiences.and.provides.header.elds.that.may.be.used.by.

future.routing.protocols..Further.deployments.of.existing.and.adopted.application.layer.protocols.like.

HTTP,.SOAP,.etc.,.are.examined.in.the.6LoWAPP.activities.of.the.IETF..6LoWAPP.is.not.an.IETF.work-

ing

.group,.but.the.intention.is.the.creation.of.new.working.groups.or.further.activities,.which.will.lead.

to.specications,.for.6LoWPAN.networks.

Frame

control

Sequence

number

Addressing

fields

2 1 4–20

MAC payload

Frame check

sequence

(FCS)

Octets:

MAC

sublayer

MAC header (MHR)

MAC footer

(MFR)

MAC service data unit (MSDU)

Preamble

sequence

Start of frame

delimter

Frame

length

PHY payload

4 11

5 + (4–20) + n

Synchronization header (SHR)

PHY header

(PHR)

PHY service data unit (PSDU)

Octets:

PHY protocol data unit (PPDU)

11 + (4–20) + n

MAC protocol data unit (MPDU)

PHY

layer

FIGURE 51.3 IEEE.802.15.4.PHY.and.MAC.frame.format.

51-6 Industrial Communication Systems

 e.reader.should.keep.in.mind.that.6LoWPAN.networks.will.not.take.the.role.of.transit.networks..

Moreover,. 6LoWPANs. are. applied. as. the. sensing. parts. placed. at. the. edges. of. existing. networks.

(seeFigure.51.4)..Hence,.routers.connecting.6LoWPANs.and.IPv6.networks.are.called.edge.routers.

.deploy.IPv6.on.802.15.4,.6LoWPAN.concentrates.on.two.major.points:.fragmentation.and.header.

compression..For.a.comprehensive.specication,.6LoWPAN.also.includes.rules.for.stateless.address.

autoconguration,.address.mapping,.and.security.

Stateless Address Autoconguration.

.Because.of.the.expected.high.number.of.nodes.within.WSNs,.state-

less

.address.autoconguration.is.required..6LoWPAN.examined.how.to.use.the.EUI-64.device.identi-

er,

.assigned.to.every.802.15.4.device,.to.generate.an.identier.for.the.IPv6.interface.

Addressing Mapping.

.As.802.15.4.does.not.support.multicast.natively,.a.mapping.of.IPv6.multicast.to.the.

802.15.4.link.layers.have.to.be.examined..For.an.optimized.header.compression,.further.mapping.even.

of.unicast.IPv6.addresses.is.required.

Fragmentation.

. e.maximum.PHY.layer.packet.size.of.IEE.802.15.4.is.127.bytes.. e.maximum.MAC.

layer.frame.size.is.102.octets..If.link.layer.security.is.enabled,.further.overhead.is.imposed.and.81.octets.

are.le.for.upper.layers.. is.is.far.below.the.minimum.packet.size.(MTU).of.1280.octets.required.by.

the.IPv6.specication.. us,.6LoWPAN.must.provide.a.fragmentation.and.reassembly.layer.between.

the.MAC.and.the.IP.layer.

Header Compression.

.Due.to.the.limited.packet.size.of.802.15.4,.protocol.headers.have.to.be.reduced.

to.provide.a.suitable.payload.to.header.ratio.and.to.avoid.protocol.overhead..IPv6.basic.headers.have.

a.size.of.40.octets..UDP.headers.use.8.octets.and.TCP.headers.need.20.octets.. is.leaves.33.octets.for.

UDP.and.only.21.octets.for.TCP.communication.. us,.a.header.compression.scheme.is.dened.by.the.

6LoWPAN.working.group.

Security.

. e.application.of.WPAN.implies.requirements. for.data.security,. e.g.,.for.personal.health.

records.. e.working.group.has.also.considered.the.secure.exchange.of.messages.and.analyzed.how.the.

available.link.layer.security.of.802.15.4.can.be.used.to.ensure.secure.IP.trac.

Routing.

.As.stated.above,.6LoWPAN.does.not.focus.on.routing.of.IPv6.on.802.15.4..Hence,.the.6LoWPAN.

does.not.provide.a.full.specication.for.mesh.routing..Nevertheless,.existing.routing.over.IP.protocols.

and.routing.under.IP.over.MAC.layer.in.a.mesh.network.are.examined.and.specic.frame.types.are.

dened.to.be.used.by.the.mesh.routing.under.protocols..For.more.detailed.information.about.route over.

(IP).and.mesh under.(IP).routing,.please.refer.to.the.ROLL.working.group.[IETFROLL],.which.is.still.

examining.dierent.strategies.for.routing.concepts.in.the.time.of.writing.this.section.

.common.goal.of.all.eorts.in.the.6LoWPAN.working.group.is.the.minimization.of.required.band-

width

.and.power.consumption,.protocol.overhead,.packet.overhead,.and.processing.requirements.due.

to.the.limited.resources.. us,.the.presented.issues.could.not.have.been.solved.one.aer.the.other.but.

requires.cross.layer.design..For.example,.address.autoconguration.has.to.collaborate.with.header.com-

pression

.schemes.and.network.management.as.well..As.key.concept,.6LoWPAN.elides.any.redundant.

information/header.elds,.which.already.exist.in.the.lower.layers.or.may.be.derived.by.their.combination.

Internet

IPv4/IPv6 core network

Enterprise network

IPv4/IPv6 core network

Subnetwork

IPv4/IPv6 core network

Wireless sensor network

6LoWPAN

Wireless sensor network

6LoWPAN

Wireless sensor network

6LoWPAN

IP router

6LoWPAN/IP edge router

FIGURE 51.4 6LoWPAN.WSN.integration.

6LoWPAN: IP for Wireless Sensor Networks and Smart Cooperating Objects 51-7

51.5 6LoWPaN

In.general,.IEEE.802.15.4.denes.four.types.of.frame.formats:.beacon.frames,.MAC.command.frames,.

ackn

owledge

.fram

es,

.and.data.fram

es.

.For.6LoW

PAN-compliant

.tran

smission,

.only.data.fram

.are.

used

. Furt

hermore,

. 802.

15.4

. prov

ides

. beac

oned

. and. non-b

eaconed

. data. tran

smission.

. It. is. reco

mended

.to.use.the.beac

on-enabled

.mode.beca

use

.the.beac

ons

.are.usef

.for.the.devi

.disc

overy

.with.

uppe

.laye

rs.

.Neve

rtheless,

.no.dedi

cated

.mapp

ing

.of.beac

ons

.on.devi

.disc

overy

.proto

cols

.is.desc

ribed

by.6Lo

WPAN.

.foll

owing

.subs

ections

.are. deri

ved

.from.the. RFC4

944,

.subm

itted

.by.the. 6LoW

PAN

.work

ing

grou

. e.conc

epts

.and.mean

ings

.are.expl

ained

.and.addi

tional

.comm

ents

.are.adde

.At.the.end.of.this.

sect

ion,

.the.die

rent

.desc

ribed

.fram

.and.head

.type

.are.summ

arized

.and.comp

ared.

.Furt

her,

.head

comp

ression

.and.impr

oved

.mult

icast

.mapp

ing

.will.be.den

.by.the.work

ing

.grou

.in.thei

.curr

ently

acti

.dra

.Beca

use

.the.dra

.are.not.matu

red

.in.the.time.of.writ

ing

.this.sect

ion,

.they.cann

.be.full

exam

ined

.her

51.5.1 address autoconguration

An.IPv6-compliant.interface.address.is.128.bit.wide.with.64.bit.for.the.interface.identier.and.a.64.bit.

pre

.Two.die

rent

.addr

ess

.type

.are.den

.by.802.

15.4

.that.can.be.used.to.gene

rate

.an.IPv6

-compliant

inte

rface

.iden

tier:

.the.16.bit.shor

.addr

ess

.and.the.exte

nded

.IEEE.64.bit.addr

ess.

. e.64.bit.inte

rface

iden

tier

.may.base.on.the—

for

.ever

.devi

.uniq

ue—EUI-64

.iden

tier

.[EUI

64]

.but.can.also.be.chan

ged

by.the.sowa

.netw

ork

.stac

.If.this.64.bit.addr

ess

.is.appl

ied,

.the.inte

rface

.iden

tier

.can.be.form

.in.

accor

dance

.to.the.“IPv

.over.Ethe

rnet”

.(RFC

2464)

.speci

cation

.[RFC

2464].

. e.shor

ter

.16.bit.addr

esses

are.used.by.802.

15.4

.node

.insi

.a.speci

c

.PAN.aer.an.assoc

iation

.even

.with.the.coor

dinator.

.If.16.bit.

shor

.addr

esses

.are.appl

ied,

.a.48.bit.addr

ess

.can.be.gene

rated,

.which.in.turn.is.conv

erted

.into.a.64.bit.addr

ess

foll

owing

.RFC24

.also.[RFC

2464].

Generating

.a.64.bit.inte

rface

.iden

tier

.out.of.16.bit.shor

.addr

esses

.cann

.gran

.that.the.deri

ved

addr

esses

.are.glob

ally

.uniq

ue,

.whic

.has.to.be.anno

unced

.by.sett

ing

.the.univ

ersal/local

.bit—t

.seve

nth

bit.in.an.IPv6.inte

rface

.iden

tier—to

.zero

.When.gene

rating

.an.inte

rface

.iden

tier

.out.of.the.16.bit.shor

addr

ess

.used.in.one.802.

15.4

.PAN,.the.deri

ved

.addr

ess

.is.limi

ted

.to.the.life

time

.of.the.conn

ection

.with.

the.PAN.coo

rdinator.

. us

.it.mig

.be.app

licable

.to.use.64.bit.add

resses

.dir

ectly

.if.pos

sible.

.64.bit.pre

.for.the.IPv6.addr

ess

.is.obta

ined

.by.the.(edg

.rout

.in.acco

rdance

.to.RFC4

862

.“IPv

State

less

.Addr

ess

.Autoc

onguration”

.[RFC

4862].

.“Nei

ghbor

.Disc

overy

.(ND).for.IP.versi

.6.(IPv

6)”

[RFC

4861]

.e.g.,.dupl

icated

.addr

ess

.dete

ction

.and.ndi

.of.rout

ers,

.make

.exte

nsive

.use.of.IP.mul-

icast.

. ere.is.no.nati

.supp

ort

.for.mult

icast

.in.IEEE.802.

15.4

.and.thus.furt

her

.eor

.are.requ

ired.

Furt

hermore,

.RFC4

861

.assu

mes

.all.devi

ces

.of.a.subn

.comm

unicating

.on.one.singl

.link

. ese.two.

points.make.standard.ND.not.applicable.to.be.applied.in.6LoWPAN.networks..It.should.be.noted.that.

ther

.is.an.acti

.docu

ment

.of.the.6LoW

PAN

.work

ing

.grou

.whic

.desc

ribes

.an.alte

rnative

.ND.for.

6LoW

PAN

.netw

orks.

. e.rout

ers

.adve

rtise

.thei

.pres

ence

.with. peri

odical

.mult

icast

.mess

ages.

. is.

requ

ires

.almo

.all.node

.to.wake.up.peri

odically

.for.powe

.cons

uming

.rece

iving

.and/

.forw

arding

.of.

mult

icast

.mess

ages.

. e.impl

icit

.unre

liable

.comm

unication

.in.LoWP

ANs

.and.the.abse

nce

.of.mult

icast

mess

aging

.cap

abilities

.on.the.lin

.lay

.mak

.sta

ndard

.ND.pro

tocols

.not.pra

ctical.

51.5.2 Frame types and Fragmentation

 e.802.15.4.specication.denes.a.maximum.packet.size.of.127.byte.for.physical.packets.. e.number.

of.avai

lable

.octe

.is.furt

her

.redu

ced

.by.the.MAC.laye

.head

.and.foot

er.

.IPv6.requ

ires

.a.mini

mum

MTU.of.1280.octe

ts.

.To.t.the.requ

ired

.IPv6.MTU,.a.sepa

rate

.frag

mentation

.and.reas

sembly

.laye

.has.

to.be.prov

ided

.on.top.over.MAC.laye

.and.belo

.IP.laye

.(kno

.as.laye

.2.5)

. us,.it.is.requ

ired

.to.

den

.addi

tional

.fram

.form

ats

.to.the.stan

dard

.IPv6.fram

.All.fram

.type

.are.pre

xed

.by.an.8.bit.wide.

51-8 Industrial Communication Systems

dispatch.eld,.which.species.the.frame.type.and.what.specic.frame.type.format.follows.this.dispatch.

eld..Four.groups.are.dened.and.identied.by.the.rst.two.bits.of.the.dispatch.eld:.Not.a.LoWPAN.

frame.(NALP),.mesh.frame.(MESH),.rst.fragmentation.frame.(FRAG1),.and.subsequent.fragmentation.

frame.(FRAGN).

.the.overall.packet.size.exceeds.the.limit.of.the.MAC.layer,.the.fragmentation.frame.as.depicted.in.Figure.

51.5.has.to.be.applied..Because.the.FRAG.frame.header.is.located.at.layer.2.5.between.link.layer.and.IP,.the.

FRAG.header.encloses.the.IP.frame.. e.IP.header.is.included.in.the.rst.fragment.only.and.interpreted.

on.the.destination.node.aer.reassembling.the.IPv6.packet.and.not.on.intermediate.nodes..A.maximum.

2.048.bytes.can.be.transmitted.within.one.IP.packet..Packets.with.a.bigger.size.have.to.be.fragmented.on.IP.

layer.or.above.. e.MTU.of.IPv6.requires.only.1280.bytes..Dierent.existing.IPv6.stacks.for.computer.and.

server.platforms.autonomously.fragment.larger.frames.independent.of.the.minimum.available.MTU.on.

the.route.to.the.destination.to.avoid.the.need.of.resending.packets.. is.can.reduce.communication.latency.

and.memory.requirements.because.it.is.assured.that.the.frame.size.complies.with.all.link.layer.technologies.

on.the.route.to.the.destination..It.might.be.applicable.not.to.exceed.the.MTU.of.1280.bytes.per.frame.in.

6LoWPANs.also.and.realize.a.fragmentation.on.IP.layer.or.above.. e.complete.fragmentation.frame.header.

size.diers.between.32.bit.for.the.rst.fragment.and.40.bit.for.subsequent.fragments..In.accordance.to.the.

IPv6.reassembly.timeout,.a.receiver.of.a.fragmented.packet.must.discard.received.fragments.if.the.packet.

could.not.be.reassembled.within.60.s.aer.the.rst.fragment.was.received.. e.802.15.4.specication.denes.

a.beacon-enabled.mode,.where.RFDs.only.wake.up.in.dened.time.slots.to.receive.a.beacon.from.their.coor-

dinator.

. is.beacon.contains.information.if.data.are.pending.to.be.received.by.the.endpoint.. e.beacons.

are.transmitted.in.periodical.time.slots.between.15.ms.and.252.s..If.beacon-enabled.mode.is.deployed.on.the.

802.15.4.layers,.the.beacon.distance.has.to.t—particularly.in.multi-hop.scenarios.depending.on.the.network.

topology—to.ensure.a.maximum.delay.of.60.s.between.the.endpoints.

51.5.3 Mesh Frame type

For.mesh.network.topologies.(named.peer-to-peer.in.IEEE.802.15.4).and.multi-hop.scenarios,.an.addi-

tional

.mesh.frame.header.is.applied.that.encloses.all.other.frame.types.including.FRAG.type,.which.in.

turn.encloses.the.IP.frame.(cf..Figure.51.6).. e.additionally.required.mesh.header.includes.three.parts.. e.

rst.part.denes.the.format.of.the.addresses.for.originator.and.nal.interface,.which.can.be.either.the.16.bit.

short.addresses.or.64.bit.EUI-64.addresses.format.. e.second.part.is.the.Hops.Le.eld.that.denes.aer.

how.many.hops.the.packet.can.be.discarded.by.the.forwarding.node.to.avoid.routing.loops.and.can.have.a.

maximum.value.of.256.. e.third.eld.includes.the.originator.and.nal.address.in.the.format.specied.by.

the.rst.eld..Depending.on.the.address.format,.the.complete.MESH.frame.header.has.a.size.of.5–17.bytes.

802.15.4 MAC/PHY

Includes information

elided in upper layers

MESH

Interpreted on each

intermediate node

FRAG

For reassembling on

destination node

Interpreted on

destination node

802.15.4 MAC/PHY

...

FIGURE 51.6 Frame.formats.and.order.

First fragment

Subsequent fragment

1 1 1 0 0

00011

datagram_size/11

datagram_tag/16

datagram_tag/16 datagram_offset/8

Frag type Frag header Following headers/payload

...

FIGURE 51.5 Fragmentation.header.structure.

6LoWPAN: IP for Wireless Sensor Networks and Smart Cooperating Objects 51-9

 e.mesh.frame.includes.address.information.in.addition.to.the.MAC.and.PHY.layers.address.information..

 is.is.required.because.in.multi-hop.network.topologies,.every.forwarding.node.of.a.mesh.frame.has.to.

adapt.the.source.and.destination.addresses.in.the.link.layer.. e.overall.originator.address.and.the.overall.

nal.destination.address.are.given.by.the.mesh.frame.address.eld.and.stay.unchanged..Before.trans-

mitting,

.the.forwarding.node.analyzes.the.mesh.nal.destination.address.eld.to.determine.the.overall.

destination..If.the.node.itself.is.not.the.nal.destination,.the.Hops.Le.eld.is.reduced..If.the.result.is.zero,.

the.packet.is.discarded..Otherwise,.the.node.invokes.the.link.layer.routing.table.to.retrieve.the.next.node.

toward.the.nal.destination.. is.address.of.the.next.hop.is.put.into.the.link.layer.address.eld.. e.source.

address.in.the.link.layer.is.changed.to.the.address.of.the.current.node.and.the.packet.is.transmitted.

.mesh.frame.type.can.be.used.by.routing.protocols.to.be.developed.in.particular.by.the.IETF.

ROLL.working.group..Later.on.(cf..Section.51.5.6),.applicability.of.the.mesh.header.and,.thus,.routing.

strategies.of.IP.packets.in.6LoWPAN.networks.are.discussed.

51.5.4 Broadcast and Multicast address Mapping

As.IPv6.makes.extensive.use.of.multicast.messaging,.6LoWPAN.species.an.additional.compressed.

multicast.mapping.as.well.. ere.are.no.multicast.concepts.dened.in.IEEE.802.15.4.natively..IPv6.mul-

ticasts

.must.be.carried.by.802.15.4.link.layer.broadcast.messages,.if.no.routing.on.IP.layer.is.available..

 e.broadcast.message.includes.a.specic.PAN-ID.. us,.the.messages.are.forwarded.by.the.routers.to.

the.PAN.in.question.only..IEEE.802.15.4.denes.0xFFFF.as.16.bit.short.address.for.broadcast.messag-

ing.

.In.addition.to.this.broadcast.mapping.of.multicast.messages,.for.mesh-enabled.networks,.support.

of.further.address.transformations.are.possible..Like.all.IPv6.addresses,.the.multicast.addresses.have.a.

size.of.128.bit.(16.octets)..For.6LoWPAN.messaging,.these.addresses.are.converted.to.16.bit.addresses.

to.allow.integration.into.the.short.address.scheme.of.IEEE.802.15.4.(cf..Figure.51.7)..Each.of.these.16.bit.

addresses.starts.with.the.predened.3.bit.preamble.(100,.should.be.common.for.all.multicast.addresses.

in.6LoWPANs),.followed.by.the.last.5.bits.of.the.15th.octet.of.the.IPv6.multicast.address.. e.last.8.bits.

of.the.mapped.address.are.copied.from.the.16th.octet.of.the.128.bit.address.. e.full.specication.of.

a.multicast.mesh.routing.algorithm.is.out.of.scope.of.the.6LoWPAN.specication..Nevertheless,.such.

a.specication.is.a.vital.requirement.to.avoid.ooding.low-power.WSNs.with.multicasts.mapped.on.

broadcasts.(cf..broadcast.storm).and.will.be.focused.in.particular.by.the.ROLL.working.group.

51.5.5 Header Compression

 e.transport-specic.IPv6.addresses,.which.are.used.in.6LoWPAN.networks,.can.be.generated.by.the.

EUI-64.link.layer.identier.that.is.unique.for.every.device..Hence,.the.additional.addressing.informa-

tion

.in.the.IP.layer.are.redundant.. us,.6LoWPAN.provides.header.compression.schemes.for.address.

information.and.additional.elds.like.length.indications.to.avoid.redundant.data.in.the.dierent.layers..

All.header.elds,.which.are.already.present.in.the.802.15.4.elds,.are.elided.in.further.headers,.which.

is.a.key.design.decision.in.6LoWPAN..Basically,.the.header.compression.is.applied.without.assuming.

context.information.for.the.payload.or.additional.information.about.the.frame.(stateless.header.com-

pression).

.A.full.compressed.6LoWPAN.header.compliant.with.RFC4944.has.a.size.of.only.2.octets.in.

...

1 0 0

IPv6 128 bit

Mapped 16 bit multicast

Octet 1–14 Octet 15 Octet 16

FIGURE 51.7 Derive.16.bit.short.address.for.multicast.addressing.

51-10 Industrial Communication Systems

opposite.to.40.octets.for.standard.IPv6.headers..Because.the.following.described.header.compression.

is.not.fully.compliant.with.the.IPv6.specication,.compressed.headers.might.be.used.for.messaging.

inside.the.802.15.4.network.only..For.message.exchange.with.external.networks.via.dedicated.edge.rout-

ers,

.compliant.IPv6.headers.might.be.used..If.compressed.headers.are.applied.for.external.messaging.

also,.the.edge.router.is.responsible.for.translating.the.compressed.headers.in.compliant.IPv6.headers..

 e.current.6LoWPAN.specication.describes.header.compression.for.IPv6.and.UDP.headers.also..

Compression.schemes.for.TCP.and.further.protocols.are.not.described.yet.

51.5.5.1

IPv6 Header Compression

The

.IPv6.header.compression.is.described.by.the.HC1.encoding..This.HC1.encoding.scheme.is.

independent.from.IPv6.and.unique.for.6LoWPANs..The.128.bit.IPv6.transport.addresses.are.sepa-

rated

.in.64.bit.prefixes.derived.from.the.(edge).router.of.the.subnet.and.64.bit.for.the.interface.

identifier..It.is.possible.to.define.separate.compression.for.the.four.different.address.parts.of.origi-

nator

.and.destination:.prefix.of.originator,.interface.identifier.of.originator,.prefix.of.destination,.

and.interface.identifier.of.destination..Because.6LoWPANs.are.estimated.to.operate.within.one.

subnet.with.one.unique.prefix,.it.is.not.applicable.to.include.the.prefixes.into.the.headers.for.inter-

nal

.communication.and.can.be.elided..For.communication.out.of.the.6LoWPAN,.prefixes.can.be.

carried.in-line..The.interface.identifier.might.be.carried.in-line.also..If.elided,.in.opposite.to.the.

prefixes,.the.interface.identifier.for.the.destination.address.might.be.either.derived.from.the.link.

layer.directly.or.in.meshed.networks.from.the.addressing.fields.in.the.according.MESH.header..

A.compliant.IPv6.header.additionally.includes.the.IPv6.version.identifier,.the.traffic.class.field,.

the.flow.label.field,.the.hop.limit.field,.and.a.payload.length.field..The.length.field.is.omitted.and.

derived.from.the.801.15.4.layers.or.from.fragmentation.frame.header..The.traffic.class.and.the.flow.

label.field.can.be.compressed.and.thereby.defined.as.zero..The.IPv6.version.identifier.is.omitted.

in.general..The.8.bits.long.Hop.Limit.field.is.the.only.field.in.the.IPv6.header.that.cannot.be.com-

pressed

.and.must.be.completely.included.in-line..The.Hop.Limit.defines.the.maximum.number.

of.IP.hops.a.packet.can.be.forwarded.before.it.is.dropped..One.IP.hop.must.not.be.equal.with.a.

physical.hop.because.not.every.intermediate.node.in.a.mesh.network.must.be.an.IP-enabled.node..

The.additional.next.header.field.specifies.the.header.type.following.the.IP.header,.e.g.,.UDP,.TCP,.

or.ICMP..Such.next.header.fields.are.derived.from.the.evolving.IPv6.standard..In.opposite.to.IPv4,.

IPv6.does.not.always.include.all.required.parts,.e.g.,.fragmentation.and.routing.information.in.

the.header..Headers,.known.as.extension.headers.in.IPv6,.are.added.separately.depending.on.the.

scenario.and.refer.to.each.other.with.defined.next.header.fields,.comparable.to.that.ones.used.by.

the.6LoWPAN.compression.formats.(header.chaining)..To.sum.up,.the.complete.RFC4944.HC1.

encoded.IPv6.header.includes.at.least.2.octets.for.8.bit.Hop.Limit.and.8.bit.for.the.LOWPAN_HC1.

field.(cf..Figure.51.8)..The.size.of.the.complete.header.can.be.between.2.octets.and.37.octets.plus.4.

bit.(cf..MTU.of.IEEE.802.15.4.is.102.byte)..The.4.bits.are.necessary.to.complete.the.octet.with.zero.

padding.and.allow.routers.a.more.efficient.and.byte-size-optimized.packet.handling.

Following fields/headers/payload

LOWPAN_HC1

IPv6 destination address

Preifx carried inline or elided

Interface identifier carried inline or derived from lower layers

Following header compressed per HC2 encoding or not

Next Header (UDP, ICMP, TCP, not compressed)

Traffic class/flow label zero or carried inline

IPv6 source address

Preifx carried inline or elided

Interface identifier carried inline or derived from lower layers

Hop count

FIGURE 51.8 LOWPAN_HC1.encoding.dened.in.RFC4944.

6LoWPAN: IP for Wireless Sensor Networks and Smart Cooperating Objects 51-11

51.5.5.2 UDP Header Compression

Further,

.pro

tocol-specic

.com

pressions

.in.add

ition

.to.the.abo

ve-presented

.IPv

.hea

der

.com

pression

.are.

sum

marized

.in.the.RFC

4944

.HC2.enc

oding

.for

mat.

.In.the.cur

rent

.ver

sion

.of.the.6Lo

WPAN

.spe

cica-

tion,

.on

.th

.HC

_UDP

.sc

heme

.is.de

scribed

.fo

.HC

.en

coding.

.sta

ndard

.UDP.hea

der

.con

sists

.of.2.oct

ets

.for.the.sou

rce

.por

.of.the.mes

sage,

.2.oct

ets

.for.the.des

ti-

nation

.por

.2.oct

ets

.ind

icating

.the.len

gth

.of.the.fra

me,

.and.2.oct

ets

.for.the.che

cksum

.el

. is.sum

up.in.8.oct

ets,

.whi

.can.be.com

pressed

.to.4.oct

ets

.in.6Lo

WPAN

.net

works.

.Lik

.the.Hop.Lim

.el

.in.

the.HC1.hea

der,

.the.che

cksum

.el

.can

not

.be.com

pressed

.and.mus

.be.car

ried

.in-

line

.ful

.Acc

ording

to.the.IP.len

gth

.el

.the.UDP.len

gth

.el

.is.omi

tted

.by.ref

erring

.to.oth

.len

gth

.el

.inc

luded

.in.the.

lin

.lay

.or.the.mes

.hea

der.

. e.sou

rce

.and.des

tination

.por

.can.be.sep

arately

.car

ried

.ful

.in-

line

.or.be.

com

pressed

.to.4.bit

.If.com

pressed,

.the.4.bit

.det

ermine

.a.por

.bet

ween

.61,

616

.and.61,

631.

. e.res

ulting

ove

rall

.le

ngth

.of.th

.co

mpressed

.RF

C4944

.UD

.he

ader

.is.be

tween

.4.oc

tets

.an

.9.oc

tets.

51.5.6 Scopes

 e.architecture.of.wireless.sensor.mesh.networks.diers.signicantly.from.existing.IP-based.networks..

Net

works

. usi

. wir

. tec

hnologies

. lik

. Eth

ernet

. use.one. sin

gle-hop

. sha

red

. med

ium

. and. di

erentiate

bet

ween

.uni

cast

.mes

sages

.sen

.to.onl

.one.end

point

.or.bro

adcast

.sen

.to.all.end

points.

.Mul

ticast

.mes

sages

are.hyb

rids

.carr

ied

.to.mul

tiply

.end

points,

.con

trolled

.by.the.rou

ters

.in.the.net

work.

. e.rou

ters

.are.als

res

ponsible

.for.for

warding

.pac

kages

.dep

ending

.on.the

.tar

get

.add

ress

.int

.the.cor

rect

.sub

nets.

.Wir

eless

tec

hnologies

.lik

.Wi-

.ach

ieve

.a.simi

lar

.beh

avior

.by.abs

traction

.and.lin

.emu

lation

.of.the.use

.wir

eless

cha

nnel.

.Wi-

.end

points

.can.onl

.be.con

nected

.to.one.oth

.end

point

.(pe

er-to-peer)

.or.to.one.acc

ess

.poi

(AP

. is.cau

ses

.the.req

uired

.abs

traction

.and.thu

.the.app

licability

.of.exi

sting

.IP-

based

.pro

tocols

.and.

tec

hnologies.

.Fur

thermore,

.Wi-

.dev

ices

.are.not.sub

jected

.by.the.sam

.ene

rgy

.con

straints

.lik

.WSN

Emerging

.mes

hed

.sen

sor

.net

works

.hav

.mor

.com

plex

.top

ologies

.wit

.one.com

mon

.wir

eless

.com

mu-

nication

.med

ium,

.but.in.con

trast

.to.Eth

ernet

.and.Wi-

Fi,

.als

.wit

.lim

ited

.com

munication

.ran

ge.

.Uni

cast

mes

sages

.cann

.be.tra

nsmitted

.onl

.to.one.end

point

.wit

hout

.an.ee

.on.oth

.end

points

.in.com

munica-

tion

.ran

.and.mig

.be.for

warded

.by.end

points

.als

.and.not.onl

.by.ded

icated

.rou

ters.

. is.has.a.dee

imp

act

.on.act

ive

.dis

cussions

.on.sco

pes

.and.the

.ee

.as.use

.in.IPv

.IPv

.di

ers

.bet

ween

.lin

k-local

.sco

pe,

sit

e-local

.sco

pe,

.and.glo

bal

.sco

pe.

.Lin

k-local

.sco

.add

resses

.are.not.for

warded

.by.rou

ters.

.Glo

bal

.sco

add

resses

.are.glo

bally

.uni

que

.and.thu

.can.be.use

.as.tar

get

.add

ress

.by.eve

.oth

.end

point.

.If.rou

ting

.of.IP.

pac

kets

.is.per

formed

.und

.IP.lay

.(ro

ute

.und

er),

.the.com

plete

.6Lo

WPAN

.net

work

.mig

.com

municate

.in.

one.sin

gle

.lin

k-local

.sco

.and.new.rou

ting

.con

cepts

.mus

.be.dev

eloped.

.Espe

cially

.for.mul

ticast

.mes

sages,

.a.

pro

per

.map

ping

.mus

.be.fou

nd,

.to.avo

.oo

ding

.of.the.net

work.

. e.6Lo

WPAN

.hea

der

.com

pression

.mak

use.of.existing.information.in.the.link.layers.to.omit.redundant.data..Route.under.concepts.require.further.

map

pings

.of.oth

.lin

.lay

ers

.lik

.Eth

ernet

.or.Wi-

.to.t.the.6Lo

WPAN

.req

uirements

.or.cro

ss-layered

.sol

tions.

.If.rou

ting

.is.don

.on.the.IP.lay

.(ro

ute

.ove

r),

.exi

sting

.con

cepts

.mig

.be.use

.but.req

uires

.eve

.nod

in.the.6Lo

WPAN,

.whi

.is.not.an.end.nod

.(le

af)

.in.the.rou

ting

.tre

.to.per

form

.rou

ting.

.But.rou

.ove

.con

cepts

.lim

.the.lin

k-local

.sco

.to.all.end

points

.in.dir

ect

.com

munication

.ran

ge.

.In.cur

rent

.dev

elopments

.of.

IET

.ROL

.wor

king

.gro

up,

.rou

.ove

.con

cepts

.are.pre

ferred,

.whi

.wou

.mak

.the.mes

.hea

der

.des

cribed

in.thi

.cha

pter

.and.the.bro

adcast/multicast

.map

ping

.obs

olete.

51.5.7 Summary of Frame types and Compression Schemes

 e.miscellaneous. frame.formats. and. compression.schemes.result. in.various. dierent.frame.types.

and.comb

inations

.dep

ending,

.e.g

.on.the.sce

nario,

.app

lication,

.and.sco

.of.com

munication.

.A.vit

req

uirement

.for.IPv

.tra

c

.on.IEE

.802

.15.4

.is.the.ada

ption

.to.t.into.the.max

imum

.pac

ket

.size.of.

102.byt

.tha

.is.de

ned

.for.the.MAC.lay

.by.802

.15.4.

.Kee

.in.min

.tha

.wit

.sec

urity

.on.MAC.lay

ena

bled,

.thi

.size.is.dec

reased

.to.81.byt

.In.thi

.sec

tion,

.di

erent

.res

ulting

.fra

.hea

der

.size

.and.the

comb

ination

.are.sum

marized.

. e.com

parison

.is.pre

sented

.in.Tab

.51.

.and.der

ived

.fro

.the.cur

rently