Adhoc wireless sensor network unit 5 notes

Adhoc Wireless Sensor Networks

1. UNIT V
SENSOR NETWORK
PLATFORMS AND
TOOLS

2. Syllabus

3. Sensor Node Hardware
Sensor node hardware can be grouped into three
categories.
They are
(i) Augmented general-purpose computers
(ii)Dedicated embedded sensor nodes
(iii) System-on-chip (SoC) nodes

4. Sensor Node Hardware
Augmentedgeneral-purposecomputers
Someexamplesare
(i)Low-powerPCs
(ii)EmbeddedPCs(e.g.,PC104),
(iii)Custom-designedPCs(e.g.SensoriaWINSNG
nodes)
(iv)Personaldigitalassistants(PDAs)
Thesenodesuse
(i)Off-the-shelf(OTS)operatingsystemssuchasWinCE,
Linux,orreal-timeoperatingsystems
(ii)Standardwirelesscommunicationprotocolssuchas
BluetoothorIEEE802.11

5. Sensor Node Hardware
Characteristics of Nodes
•Relativelyhigherprocessingcapability
•Possibletoaccommodatewidevarietyofsensors
•Availabilityoffullysupportednetworking
protocol,popularprogramminglanguages,
middlewareandotherOTSsoftwareareadvantages
ofplatforms

6. Sensor Node Hardware
Dedicated embedded sensor nodes
Some examples are
(i) Berkeley mote family
(ii) UCLA Medusa family
(iii) Ember nodes
(iv)MIT μ AMP
Theseplatformsuse
(i)CommercialOTS(COTS)chipsetswithemphasison
smallformfactor
(ii)Lowpowerprocessingandcommunication,andsimple
sensorinterfaces.
(Note:

7. Sensor Node Hardware
System-on-chip (SoC) nodes:
Some Examples of SoChardware are
(i)Smart dust
(ii)BWRC picoradio node
(iii)PASTA node
•The goal is to find new ways of integrating CMOS, MEMS, and RF
technologies
(i)To build extremely low power and small footprint
sensor nodes
(ii)To provide certain sensing, computation and
communication capabilities.

8. Operating systems are capable of running many
tasks at the same time –called multitasking
operating system.
Task-basic unit of programming
-made up of actions or steps
Process-a sequence of tasks.
Threads-can have one task running at a time.
Stack -temporary storage memory where variables
are declared , stored and initialized
Sensor Node Hardware

9. Pre empty scheduling:
the executing process is interrupted in the
middle of execution where high priority one
comes in the queue.
Kernel-provides interface between application
and hardware.
-for memory management, disk
management, process management and task
management
Sensor Node Hardware

10. –Motesaretiny,self-contained,batterypoweredcomputerswith
radiolinks,whichenablethemtocommunicateandexchangedata
withoneanother,andtoself-organizeintoadhocnetworks
–Motesformthebuildingblocksofwirelesssensornetworks
–TinyOS[TinyOS],component-basedruntimeenvironment,is
designedtoprovidesupportforthesemoteswhichrequire
concurrencyintensiveoperationswhileconstrainedbyminimal
hardwareresources
Berkeley mote

11. Berkeley mote
•Hardware Platform
–Consists of
omicro-controller with internal
flash program memory
odata SRAM
odata EEPROM
oa set of actuator and sensor
devices, including LEDs
oa low-power transceiver
oan analog photo-sensor
oa digital temperature sensor
oa serial port
oa small coprocessor unit

12. Berkeley Mote
Berkeley Motes
•The Berkeley motes are a family of embedded
sensor nodes sharing roughly the same
architecture.
•Let us take the MICA mote as an example.

13. MICA Mote Architecture

14. •TheMICAmoteshaveatwo-CPUdesign
(i)Themainmicrocontroller(MCU),anAtmel
ATmega103L-Forregularprocessing
(ii)Lesscapablecoprocessorisonlyactivewhen
theMCUisbeingreprogrammed.
ATmega103LMCU:
•Ithasintegrated512KBflashmemoryand4KBof
datamemory.
•Writingsoftwareformotesischallengingwithsmall
memory.
•Thecodeisoptimizedatassemblyleveltokeepcode
footprintsmall.
MICA Mote Architecture

15. •However, high-level support and software services are
not free.
•only necessary software components are used to
support a particular application to achieve a small
footprint.
•A separate 512 KB flash memory unit is used to hold
data.
•Low-speed serial peripheral interface (SPI) protocol is
used to connect the external memory and MCU
•So the external memory is more suited for storing data
for later batch processing than for storing programs.
MICA Mote Architecture

16. •The RF communication on MICA motes uses the TR1000 chip set
(from RF Monolithics, Inc.) operating at 916 MHz band.
•With hardware accelerators, it can achieve a maximum of 50 kbps raw
data rate.
•MICA motes implement a 40 kbps transmission rate.
•The transmission power can be digitally adjusted by software through
a potentiometer (Maxim DS1804).
•The maximum transmission range is about 300 feet in open space.
•MICA motes support a 51 pin I/O extension connector
MICA Mote Architecture

17. •Sensors,actuators,serialI/Oboards,orparallelI/O
boardscanbeconnectedviatheconnector.
•Asensor/actuatorboardcanhostatemperaturesensor,a
lightsensor,anaccelerometer,amagnetometer,a
microphone,andabeeper.
•TheserialI/O(UART)connectionallowsthemoteto
communicatewithaPCinrealtime.
•Theparallelconnectionisprimarilyfordownloading
programstothemote.
MICA Mote Architecture

18. Power consumption of MICA motes
MICA Mote Architecture

19. Sensor Network Programming Challenges

20. Sensor Network Programming Challenges
•Operating systems in traditional programming languages used
to provide
(i)Abstraction for processing
(ii)I/O, networking
(iii)user interaction hardware
•For sensor networks, the application programmers also need
to deal
(i)Message passing
(ii)Event synchronization
(iii)Interrupt handing
(iv)Sensor reading.

21. An application is typically implemented as a finite state machine
(FSM) that covers all extreme cases:
(i)Unreliable communication channels
(ii)Long delays
(iii)Irregular arrival of messages
(iv)Simultaneous events
Example: Target Tracking Application
Linux operating system with directed diffusion routing, roughly
40% of the code implements the FSM and the glue logic of
interfacing computation and communication
Sensor Network Programming Challenges

22. Traditional embedded system programming
interface

23. •For resource-constrained embedded systems with real-time
requirements
•Several mechanisms are used in embedded operating systems
to reduce code size, improve response time, and reduce
energy consumption.
Mechanisms:
1. The necessary parts of the operating system are
deployed with the application.
2.Real-time scheduling allocates resources to more urgent
tasks
Sensor Network Programming Challenges

24. 3.Event-drivenexecutionallowsthesystemtofallinto
low-powersleepmodewhennointerestingevents
needtobeprocessed.
4.Embeddedoperatingsystemstendtoexposemore
hardwarecontrolstotheprogrammerstodirectlyface
devicedriversandschedulingalgorithms,andoptimize
codeattheassemblylevel.
Thisworkwellforsmall,stand-aloneembeddedsystems
Sensor Network Programming Challenges

25. Thesemechanismsdonotscaleupfortheprogrammingof
sensornetworksfortworeasons.
●Sensornetworksarelarge-scaledistributedsystems,where
programexecutiontakesplaceinamassivenumberof
distributednodes.
Distributedalgorithmsthemselvesarehardtoimplement,
especiallywheninfrastructuresupporthaslimitedresources.
●Asensornetworkshouldbeabletorespondtomultiple
concurrentstimuliatthespeedofchangesofthephysical
phenomenaofinterest.
Sensor Network Programming Challenges

26. DesignmethodologiesandDesignplatforms:
•Adesignmethodologyimpliesaconceptualmodelfor
programmers,withassociatedtechniquesforproblem
decompositionforthesoftwaredesigners.
•Adesignplatformsupportsadesignmethodologyby
providingdesign-time(precompiletime)languageconstructs
andrestrictions,andrun-time(postcompiletime)execution
services.
•Thereisnosingleuniversaldesignmethodologyforall
applications.
Sensor Network Programming Challenges

27. Depending on the specific tasks of a sensor network ,the
methodologies may differ.For example,
1.If the network is used for monitoring a small set of phenomena
and the sensor nodes are organized in a simple star topology,
then a client –server software model would be sufficient.
2. If the network is used for monitoring a large area from a
single access point (i.e., the base station), and if there is sensor
readings from a subset of sensor nodes, then a tree structure that
is rooted at the base station is a better choice.
3 . If the network is used for monitoring a moving targets, then
neither the simple client –server model nor the tree organization
is optimal. More sophisticated design methodologies and
platforms are required.
Sensor Network Programming Challenges

29. Node-Level Software Platforms
•Sensornetworksoftwaredesignsarenode-centric-i.e
Programmersthinkhowanodeshouldbehaveinthe
environment.
•Anode-levelplatformcanbe
(i)Node-centricoperatingsystem-provideshardwareand
networkingabstractionsofasensornodetoprogrammers
(ii)Languageplatform-providesalibraryofcomponentsto
programmers.
•Atypicaloperatingsystemprovidingasetofservices
(i)Filemanagement
(ii)Memoryallocation
(iii)Taskscheduling
(iv)Peripheraldevicedrivers
(v)Networking.

30. Node-Level Software Platforms
Forembeddedsystemoperatingsystemsmakedifferenttrade-
offswhenprovidingtheseservices(duetolimitedresources).
•Forexample,ifthereisnodynamicmemoryallocationthen
memorymanagementcanbesimplified.
•Ifprioritizationamongtasksiscriticalthenamoreelaborate
priorityschedulingmechanismmaybeadded.
•Therearetworepresentativeexamplesofnode-level
programmingTools
(i)TinyOS
(ii) TinyGALS

31. Node-Level Software Platforms
Otherrelatedsoftwareplatforms:Eg:MATE
(i)Mate,avirtualmachinefortheBerkeleymotes.
(ii)Mate:definesvirtualmachineinstructionstoabstractthe
operationssuchaspollingsensorsandaccessinginternalstatesare
commontoallsensornetworkapplication.
(iii)Compatibility-Whenanewhardwareplatformisintroduced,
softwarewrittenintheMateinstructionsetdoesnothavetobe
rewritten.

33. Operating System: TinyOS
CharacteristicsofTinyOS:
•Itsupportsthesensornetworkapplicationsonresource-
constrainedhardwareplatforms,suchastheBerkeleymotes.
•Theapplicationcodehasanextremelysmallfootprint
•Ithasnofilesystem
•Itsupportsonlystaticmemoryallocationandimplementsa
simpletaskmodel
•TinyOSprovidesminimaldeviceandnetworkingabstractions.

34. Operating System: TinyOS
•Ittakesalanguage-basedapplicationdevelopmentapproach
•Thenecessarypartsoftheoperatingsystemarecompiledwith
theapplication.
•EachTinyOSapplicationisbuiltintotheoperatingsystem.
•TinyOSorganizescomponentsintolayers.
•Thelowerlayer–hardwareandthehigherlayer–application
•TinyOShasauniquecomponentarchitectureandprovidesasa
libraryasetofsystemsoftwarecomponents

35. Operating System: TinyOS
•Althoughmostcomponentsencapsulatesoftware
functionalities,somearejustthinwrappersaroundhardware.
•Anapplication,typicallydevelopedinthenesClanguage
•Thisnescwiresthesecomponentstogetherwithother
applicationspecificcomponents.

36. Operating System: TinyOS
•LetusconsideraTinyOSapplicationexample—Field
MonitorApplication
•Allnodesinasensorfieldperiodicallysendtheirtemperature
andphotosensorreadingstoabasestationviaanadhoc
routingmechanism.
•Inthediagram,blocksrepresentTinyOScomponentsand
arrowsrepresentfunctioncallsamongthem.
•Thedirectionsofthearrowsarefromcallerstocallees.

37. TinyOS-Field Monitor Application

38. Timer Component and its interfaces

39. Operating System: TinyOS
•Thetimercomponentisdesignedtoworkwithaclock,
•Thiscomponentisasoftwarewrapperaroundahardware
clockthatgeneratesperiodicinterrupts.
•Anarrowheadpointingintothecomponentisamethodofthe
componentthatothercomponentscancall.
•Anarrowheadpointingoutwardisamethodthatthis
componentrequiresanotherlayercomponenttoprovide.
•Theabsolutedirectionsofthearrows,upordown,illustrate
thiscomponent’srelationshipwithotherlayers.Forexample,

40. Operating System: TinyOS
•TheTimerdependsonalowerlayerHWClockcomponent.
FunctionofTimer:
•Itcansettherateoftheclock
•TheTimerhasaninit()methodthatinitializesitsinternal
Booleanflag(evenflag)
•TheTimercanbeenabledanddisabledviathestartandstop
calls
•Whenthereisaclockinterrupt,ittogglestheevenFlag
,betweentrue(or1)andfalse(or0).
•Iftheflagis0,theTimerproducesatimer0Fireeventto
triggerothercomponents;otherwise,itproducesatimer1Fire
event.
.

41. Operating System: TinyOS
•AprogramexecutedinTinyOShastwocontexts
(i)Tasks
(ii)Events
Tasks:
•Theyarecreated(alsocalledposted)bycomponentstoatask
scheduler.
•TheTinyOSschedulermaintainsataskqueueandinvokes
tasksaccordingtotheorderinwhichtheywereposted.
•Tasksalwaysruntocompletionwithoutpreemptingorbeing
preemptedbyothertasks.
•Thustasksarenonpreemptive(noblocking).

42. Operating System: TinyOS
•Theschedulerinvokesanewtaskfromthetaskqueueonly
whenthecurrenttaskhascompleted.
•Whennotasksareavailableinthetaskqueue,thescheduler
putstheCPUintothesleepmodetosaveenergy.
Events:
•The execution of an interrupt handler is called an event context
•The processing of events also runs to completion, but it can be
preempted by other events.
•Because events always preempt tasks, programmers are
required to chop their code into small execution pieces, so that
it will not block other tasks for too long.

43. Operating System: TinyOS
•Anexampleofasplit-phaseoperationisthepacketsend
methodintheActiveMessages(AM)component.
•Sendingapacketisalongoperation,involvingconvertingthe
packetstobytes,thentobits,andultimatelydrivingtheRF
circuitstosendthebitsonebyone.
•Withoutasplit-phaseexecution,sendingapacketwillblock
theentiresystemfromreactingtoneweventsforasignificant
periodoftime.
•IntheTinyOSimplementation,thesend()commandintheAM
componentreturnsimmediately.

44. Operating System: TinyOS
•However,itisthecaller’sresponsibilitytorememberthatthe
packethasnotyetbeensent.
•Whenthepacketisindeedsent,theAMcomponentwillnotify
itscallerbyasendDone()methodcall.
•OnlyatthistimeistheAMcomponentreadytoacceptanother
packet.

45. Operating System: TinyOS
Advantages:
•TinyOSisextremelylightweight.
•Disallowingdynamicmemoryallocationreducesthememory
managementoverheadandmakesthedatamemoryusage
staticallyanalyzable.
•Thesimpleconcurrencymodelallowshighconcurrencywith
lowthreadmaintenanceoverhead.
•TheentireFieldMonitorsystemtakesonly3KBofspacefor
codeand226bytesfordata.

46. Operating System: TinyOS
Disadvantages:
•Costismore.
•Manyhardwareunusualfeaturesandcomplexitiesof
concurrencymanagementareleftfortheapplication
programmerstohandle.
•Severaltoolshavebeendevelopedtogiveprogrammers
languagelevelsupportforimprovingprogramming
productivityandcoderobustness.

48. nesC
•nesCisanextensionofCtosupportthedesignof
TinyOS.
•nesCClassifiedintotwotypes
1.Asynchronouscode(AC):Codethatisreachablefrom
atleastoneinterrupthandler
2.SynchronousCode(SC):Codethatisonlyreachable
fromtask.
•Acomponentspecificationisindependentofthe
componentimplementation.
•Itprovidesasetoflanguageconstructsand
restrictionstoimplementTinyOScomponentsand
applications
.

49. nesC

50. ComponentInterface
•InterfaceofnesCcomponentclassifiesas
–ProvidesInterfaces
–Usesinterface
•ProvidesInterface:Asetofmethodcallsexposedto
theupperlayerscomponents
•Usesinterface:Asetofmethodcallshidingtothe
lowerlayercomponents
nesC

51. ComponentInterface
•nesCdistinguishesthedirectionsoftheinterfacecalls
betweenlayersas
–Eventcalls
–Commandcalls
•EventCall:Methodofcallfrom“Lowerlayer
componenttoHigherlayercomponents”
•CommandCall:Methodcallfrom“Higherlayer
componenttoLowerlayercomponents”
nesC

52. ComponentImplementations
TwotypesofcomponentsinnesCdependingon
howtheyareimplemented
1.Modules
2.Configurations
1.Modules:Itisimplementedbyapplicationcode(written
inaClikesyntax)askeywordandtheseindicatesevent
triggeringaseventscheduledqueue.
2.Configuration:itiskindofimplementationof
components,byconnectingexistingcomponentslike
timer,Hardwareclock(HWClock)toprovidetimer
servicecalledTimerC
nesC

53. nesC
Implementation of Timer Component

55. Contiki OS
Contiki especially for IoT (Internet of Things)

56. IoTRelated Technologies
1.Embedded systems
2.Embedded System OS (Contiki, Tiny OS,
RIOT)
3.Communication Technologies
4.Sensor Technologies
5.Real Time systems
6.Smart things and technologies
7.Machine-to-Machine comunications
8.Big Data Analytics
Contiki OS

57. Contiki OS
Contiki is an
•Open source
•Highly portable
•Multi-tasking operating system
Contiki for
•Memory efficient
•Networked embedded systems
•And Wireless sensor networks

58. Where Contiki Used?
Contiki has been used in variety of projects from
–Road tunnel fire monitoring
–Intrusion detection
–Water monitoring to surveillance networks
Contiki OS

59. Contiki OS
Contiki Features
•TCP/IP communication with Stack
•Loadable modules
•Event-driven kernel
•Proto threads
•Protocol-independent radio network with the Rime
stack
•Cross-layer network simulation with COOJA
•Networked shell
•Memory efficient flash based file system
•Software-based power profiling

60. Comparison between
Contiki OS

61. Programming Languages
Contiki OS

63. Node Level Simulator
•Itisadesignmethodologieswhichare
associatedwithsimulatorsthatsimulate
behaviorofsensornetworkonper-nodebasis
•GenerallyEngineersordesignerscanquickly
studytheperformanceinterms
–Timing
–Power
–Bandwidthand
–Scalability

64. •Simulators are consisted by the following models
–Sensor Node Model
–Communication Model
–Physical Environment Model
–Statistics and Visualization
Node Level Simulator

65. •Sensornodemodel
–Mobilityofnodes
–Energyconsumption
•Communicationmodel
–Capturedetailsofcommunication(RFpropagationdelay,MAC
layeretc.)
•Physicalenvironmentalmodel
–Modelphysicalphenomenainoperatingenvironment
•Statisticsandvisualization
–Collectresultsforanalysis
Node Level Simulator

66. Timer Concept
•Asensornetworksimulatorsimulatesthe
behaviorofsensornetworkwithrespectto
time
•Inwhich,timemayadvanceindifferways:
cycle-drivenordiscrete-event
Node Level Simulator

67. Cycle Driven (CD) Simulation
•Acycle-driven(CD)discretizethecontinuousreal
timeinto“ticks”
•Simulatorcomputesphenomenonateachtick.Like:
physicalenvironment,sensingdata,communication
data,etc.
•CommunicationbyRFisassumedtobefinishedina
tick.
•Easytoimplementanduse
•NOTE_-MostCDsimulatorsissuearedetecting
anddealingcycledependenciesamongnodes(ex
RF)oralgorithms(exThreads)
Node Level Simulator

68. Discrete –Event (DE) Simulations
•Discrete-event(DE)simulatorassumesthetimeis
continuous.
•UsuallyuseaGlobaleventqueuetostoreevents.
•AlleventsarestoredchronologicallyintheGlobal
eventqueue.
Node Level Simulator

69. Cycle Driven and Discrete Event Simulation
Node Level Simulator

70. Comparisonb/wCDandDE
•DEsimulatorsareconsideredasbetterthanCD
simulators,becausetheyaremoreactual,butthey’re
morecomplextodesignandimplement.
•MostpopularsensornetworksimulatorsareDE
simulators,like
–TOSSIM
–NS2.
Node Level Simulator

71. NS2 Simulator
•Apackageoftoolsthatsimulatesbehaviorofnetworks
•Oneofthemostpopularsimulatoramongnetworking
researchers
–Freeopensource
•Discreteeventsimulatortargetedatnetworking
researchandeducation
–Protocoldesign,TrafficStudies,etc.
–Wiredandwirelessnetworks
•BackendisinC++andfrontendisoTcl
Node Level Simulator

72. NS2 with Sensor Networks Extension
Ns2wasmeanttobewirednetworksimulator,so
extensionsarebeingmadeforwireless(802.11,TDMA,
MAC)andmorerecentsensornetworks.
Node Level Simulator

73. NS2withSensorNetworksExtension
•Itsupportslogicaladdressforeachnode
•Itintroducesthenotionofnodeslocationsandchannel
model
•Thisisnottrivialextension,sinceoncethenodemove,
thesimulatorneedtocheckforeachphysicallayer
evenwhetherthedestinationnodeiswithinthe
communicationrange
Node Level Simulator

74. NS2 with Sensor Networks Extension
•TwoEffortsinNS2toextendsensorn/w
1.SensorSim
2.NRLsensornetworkextension
•SensorSim:Providinganenergymodelforsensor
nodeandcommunication,sothatpowerpropertiescan
besimulated,alsosupporthybridsimulationsi.e.,in
realapplicationssupportandexecutegroupofnodes
together
•NRLSensorNetworkextension:Physicalphenomena
aremodeledasn/wandcommunicatethroughphysical
layers
Node Level Simulator

75. NS2 simulator
Protocol supported
•802.3 z 802.11
•TDMA
•Ad hoc routing (such as DSDV and AODV)
•Sensor network routing (such as Direct diffusion,
Geographical routing(GEAR), Geographical adaptive
fedility(GAF))
Node Level Simulator

76. TOSSIM
•WhichisdedicatedtoTinyOSapplicationstorunning
ononeormoreBerkeleyMotes.
•ThekeydesigndecisionsonbuildingTOSSIMwereto
makeitscalablen/wwithpotentiallythousandsof
nodesandabletouseactuals/wcodeinsimulation
Node Level Simulator

77. TOSSIM
•EventDrivenModel:Inthisexecutionmodel
ofTinyOSgreatlysimplifiesthedesignof
TOSSIM,byreplacingafewlow-level
components,suchas
–ADCconverter
–Systemclock
–Radiofrontend
•AlltheseTOSSIMtranslateshardware
interruptsinto“Discrete-eventsimulatorevents”
Node Level Simulator

78. TOSSIM
TinyViz:
•ItisaTOSSIMvisualizationpackagewhichisaJAVA
applicationsthatcanconnecttoTOSSIMsimulation
•Itprovides“Mechanismtocontrolarunningsimulationby
followings
–ModifyingADCreadings
–Changingchannelproperties
–Injectingpacketsforpreventingmessagefromsecurity
issues
•Withsomevisualizationpacket,theTinyViz.Resultcanbe
plotinsomemoreunderstandablegraphs
Node Level Simulator

80. COOJA IS EMULATOR
Accordingtodifferentsources,itisanemulator
Ahardwareorsoftwaresystemthatenablesonecomputer
system(calledashost)tobehavelikeanothercomputer
system(calledasguest):
e.g.COOJAenablingyourlaptoptobehavelikeaZ1
mote.
asystemthattypicallyenablesthehostsystemtorun
softwareoruseperipheraldevicesdesignedfortheguest
system:
e.g.CoojaenablingyourlaptoptoruntheRPLprotocol,

81. CoojaisaContikinetworkemulator
AnextensibleJava-basedsimulatorcapableofemulating
T-mote,Sky(andother)nodes
Thecodetobeexecutedbythenodeistheexactsame
firmwareyoumayuploadtophysicalnodes
Allowslargeandsmallnetworksofmotestobesimulated
Motescanbeemulatedatthehardwarelevel
Slowerbutallowsforpreciseinspectionofsystem
behavior
Motescanalsobeemulatedatalessdetailedlevel
COOJA IS EMULATOR

83. State-CentricProgramming
Applicationsthatisn’tjustsimplygeneric
distributedprogramsoveranadhocnetwork.We
havetocentralizedataintonodes.
EX:targettracking.
83

84. State-CentricProgramming
Def:
X: state of asystem
U:inputs
Y:outputs
K: updateindex
F: state updatefunction
G: output observationfunction
84

85. State-CentricProgramming
X
k+1 = F( X
k, U
k )
Y
k = G( X
k , U
k)
In state-centric programming, X and K come
from many nodes. So many issue are discussed.
85

86. END OF UNIT 5