S&D PPTs sensors and devices presentation

S&D PPTs sensors and devices presentation

1. Sensors and Devices
Unit-II
4/4/2024 1

2. Syllabus
4/4/2024 2

3. Machine-to-Machine (M2M)
•Machine-to-Machine(M2M)refersto
networkingofmachines(ordevices)forthe
purposeofremotemonitoringandcontroland
dataexchange.
4/4/2024 3

4. Machine-to-Machine (M2M)
•AnM2Mareanetworkcomprisesofmachines(orM2Mnodes)whichhave
embeddedhardwaremodulesforsensing,actuationandcommunication.
•VariouscommunicationprotocolscanbeusedforM2Mlocalareanetworkssuchas
ZigBee,Bluetooh,ModBus,M-Bus,WirlessM-Bus,PowerLineCommunication
(PLC),6LoWPAN,IEEE802.15.4,etc.
•ThecommunicationnetworkprovidesconnectivitytoremoteM2Mareanetworks.
•Thecommunicationnetworkcanuseeitherwiredorwirelessnetworks(IPbased).
•WhiletheM2Mareanetworksuseeitherproprietaryornon-IPbasedcommunication
protocols,thecommunicationnetworkusesIP-basednetwork.
4/4/2024 4

5. M2M Network
4/4/2024 5

6. M2M gateway
•Sincenon-IPbasedprotocolsareusedwithinM2Marea
networks,theM2Mnodeswithinonenetworkcannot
communicatewithnodesinanexternalnetwork.
•ToenablethecommunicationbetweenremoteM2Marea
networksM2Mgatewaysareused.
4/4/2024 6

7. M2M gateway
4/4/2024 7

8. Difference between IoTand M2M
CommunicationProtocols
•M2MandIoTcandifferinhowthecommunicationbetweenthemachinesordevices
happens.
•M2Museseitherproprietaryornon-IPbasedcommunicationprotocolsfor
communicationwithintheM2Mareanetworks.
MachinesinM2MvsThingsinIoT
•The"Things"inIoTreferstophysicalobjectsthathaveuniqueidentifiersandcan
senseandcommunicatewiththeirexternalenvironment(anduserapplications)or
theirinternalphysicalstates.
•M2Msystems,incontrasttoIoT,typicallyhavehomogeneousmachinetypeswithin
anM2Mareanetwork.
4/4/2024 8

9. Difference between IoTand M2M
HardwarevsSoftwareEmphasis
•WhiletheemphasisofM2Mismorehardwarewithembedded
modules,theemphasisofIoTismoreonsoftware.
DataCollection&Analysis
•M2Mdataiscollectedinpointsolutionsandofteninon-premises
storageinfrastructure.
•IncontrasttoM2M,thedatainIoTiscollectedinthecloud(canbe
public,privateorhybridcloud).
4/4/2024 9

10. Difference between IoTand M2M
Applications
•M2Mdataiscollectedinpointsolutionsandcanbeaccessedbyon-
premisesapplicationssuchasdiagnosisapplications,service
managementapplications,andonpremisesenterpriseapplications.
•IoTdataiscollectedinthecloudandcanbeaccessedbycloud
applicationssuchasanalyticsapplications,enterpriseapplications,
remotediagnosisandmanagementapplications,etc.
4/4/2024 10

11. Communication in IoTvsM2M
4/4/2024 11

12. Software-Defined Networking –PartI
1
Restructuring the Current NetworkInfrastructure

13. Overview of CurrentNetwork
UserI
UserII
OSPF Protocol executes
at theswitches
the switch has beenattacked!
needs to route through an alternate path!
Present: No centralizedcontrol.

14. Limitations in CurrentNetwork
OS
hardware
app
OS
hardware
app
OS
hardware
app
OS
hardware
app
OS
hardware
app
OS
hardware
app
Switches forward traffic
in a distributed manner.
They do not have a
global view of the
network

15. Limitations in CurrentNetwork
7
✓Vendor Specific Architecture of switches limitsdynamic
configuration according to application-specificrequirements.
✓Switches are required to configure according to the installed
operating system(OS).
✓Centralized control is not feasible in traditionalnetwork.

16. Limitations in CurrentNetwork
Specialized packet
forwardinghardware
appappapp
Operatingsystem
Routing, mobility
management,etc.
Cost-expensive
Millions ofgates,
~10GBRAM
Thousands
lines of
code

17. Current Network toSDN
hardware
OS
app
hardware
OS
app
hardware
OS
app
hardware
OS
app
hardware
OS
app
hardware
OS
app

18. Current Network toSDN
packet
forwarding
hardware
Operatingsystem
app app app
packet
forwarding
hardware
packet
forwarding
hardware

19. Origin ofSDN
✓2006Stanforduniversityteamproposesaclean-slatesecurityarchitecture
(SANE)tocontrolsecuritypoliciesinacentralizedmannerinsteadofdoingitat
edges.
✓2008:Theideaofsoftware-definednetworkisoriginatedfromOpenFlowproject
(ACMSIGCOMM2008).
✓2009: Stanford publishes OpenFlow V1.0.0specs.
✓June 2009: Nicira network isfounded.
✓March 2011: Open Networking Foundation isformed.
✓Oct 2011: First Open Networking Summit. Many Industries (Juniper, Cisco
announced toincorporate.

20. SDNArchitecture
Notes
-NorthboundAPI
-SouthboundAPI
(viaOpenFlow)
NetworkFunction
Virtualization

21. Basic Concepts ofSDN
✓Separate control logic from hardware switches
✓Define the control logic in a centralizedmanner
✓Control the entire network including individualswitches
✓Communication between the application, control, and data
planes are done throughAPIs

22. Components/Attributes ofSDN
✓Hardware switches
✓Controller
✓Applications
✓Flow Rules
✓Application programming interfaces(APIs)

23. Current Status ofSDN
✓Companies such as Google have started to implement SDN at
their datacenternetworks.
✓It is required to change the current network with SDN in a
phasedmanner.
✓Operational cost and delay caused due to link failure can be
significantlyminimized.

24. Challenges
✓Ruleplacement
✓Controllerplacement

25. Rule PlacementI
✓Switches forward traffic based on a rule –‘Flow-Rule’ –
defined by the centralized controller.
▪Traditionally, Routing Table in every switch (L3 switch/router). SDN
maintains Flow Table at everyswitch.
▪Flow Rule Entry in the FlowTable.
✓Each rule has a specific format, which is also defined by a
protocol (e.g.,OpenFlow).

26. Rule PlacementII
Example of a flow-rule based on OpenFlowprotocol

27. Rule Placement ChallengesI
✓Size of ternary content-addressable memory (TCAM) is limited
at theswitches.
▪Limited number of rules can beinserted.
✓Fast processing is done using TCAM at theswitches.
✓TCAM is verycost-expensive.

28. RulePlacementChallengesII
✓On receiving a request, for which no flow-rule is present in
the switch, the switch sends a PACKET-IN message tothe
controller.
✓The controller decides a suitable
flow-rule for therequest.
✓The flow rule is insertedat the
switch.
✓Typically, 3-5ms delay is involved in a
new ruleplacement
Controller

29. Rule PlacementIII
✓How to define/place the rules at switches, while considering
availableTCAM.
✓How to define rules, so that less number ofPACKET-IN
messages are sent tocontroller.

30. OpenFlow ProtocolI
✓Only one protocol is available for rule placement –OpenFlow.
✓It has different versions –1.0, 1.1, 1.2, 1.3, etc. –to have
different number ofmatch-fields.

31. OpenFlow ProtocolII
✓Differentmatch-fields
▪SourceIP
▪DestinationIP
▪SourcePort
▪Priority
▪etc.

32. OpenFlow ProtocolIII
How much time a flow-rule is to be kept at theswitch?
✓Hard timeout
▪All rules are deleted from the switch at hardtimeout.
▪This can used to reset theswitch.
✓Softtimeout
▪If NO flow is received associated with a rule for a particular time, the
rule isdeleted.
▪This is used to empty the rule-space by deleting an unusedrule.

33. OpenFlow ProtocolIV
✓SDN is NOTOpenFlow
▪SDN is atechnology/concept
▪OpenFlow is a protocol used to communicate between data-plane and
control-plane.
▪We may have other protocols for this purpose. However, OpenFlow is
the only protocol presenttoday.
▪Open vSwitch: Open Source, it is the MOST popular one present
today.

34. Summary
✓Basics ofSDN
✓Challenges present inSDN
✓Rule Placement withOpenFlow
✓Controller Placement –to be discussed in nextlecture

35. APIs inSDN
✓SouthboundAPI
▪Used to communicate between control layer and infrastructurelayer.
▪OpenFlow protocol isused.
✓NorthboundAPI
▪Used to communicate between control layer and applicationlayer.
▪Standard APIs areused.
✓East West Bound APIs
▪Used to communicate among multiple controllers in the controllayer.

36. Controller PlacementI
✓Controllers define flow-rule according to the application-
specificrequirements.
✓The controllers must be able to handle all incoming requests
fromswitches.
✓Rule should be placed without incurring muchdelay.
✓Typically, a controller can handle 200 requests in a second
(through a singlethread).

37. Controller PlacementII
✓The controllers are logically connected to the switches in one-
hopdistance.
▪Physically, they are connected to the switches in multi-hopdistance.
✓If we have a very small number of controllers for a large
network, the network might be congested with control
packets (i.e., PACKET-INmessages).

38. FlatArchitecture
Packet-IN
Flow-Rule

39. Hierarchical (tree)Architecture

40. RingArchitecture

41. MeshArchitecture
UserI
UserII

42. ControlMechanisms
✓Distributed
▪The control decisions can be taken in a distributedmanner
▪Ex: each subnetwork is controlled by different controller
✓Centralized
▪The control decisions are taken in a centralizedmanner.
▪Ex: A network is controlled by a singlecontroller.

43. BackupController
✓If a controller is down, what willhappen?
▪Backup controller isintroduced
▪Replica of the main controller iscreated
▪If the main controller is down, backup controller controls the network
to have uninterrupted networkmanagement.

44. SecurityI
✓Enhanced security usingSDN
▪Firewall
▪Proxy
▪HTTP
▪Intrusion detection system(IDS)

45. SecurityII
Example of potential data plane ambiguity to implement the policy chain
Firewall-IDS-Proxy in the exampletopology.
3

46. Experimenting withSDN
✓Simulator/Emulator
▪Infrastructure deployment –MUST be supported withOpenFlow
▪Controller placement –MUST supportOpenFlow
▪oRenmtroltler–ccan be situated in a remote place, and communicated
using IP address and portnumber
▪Local

47. SwitchDeployment
✓Mininet
▪Used to create a virtual network with OpenFlow-enabledswitches
▪Based on Pythonlanguage
▪Supports remote and localcontrollers

48. Controller ConfigurationSoftware
✓Pox
✓Nox
✓FloodLight
✓OpenDayLight[Popular!]

49. Summary
✓Performance of SDN depends on rule placement and
controller placement in thenetwork.
✓Control message overhead may be increased due to
additional number of packets (PACKET-INmessages).
✓Unified network management is possible using SDN, while
leveraging global view of thenetwork.

50. Software-Defined IoT Networking –PartI
RecentAdvancesofSDNinIoT

51. IoTArchitecture

52. BenefitsofIntegratingSDNinIoT
✓Intelligent routing decisions can be deployed usingSDN
✓Simplification of information collection, analysis and decision
making
✓Visibility of network resources –network management is
simplified based on user, device and application-specific
requirements
✓Intelligent traffic pattern analysis and coordinateddecisions

53. SDN for IoTI

54. SDN for IoTII
Control of end-devices, such as sensors
andactuators

55. SDN for IoTIII
R
u
w
h
e
le-placement at access
devices, hile
considering mobility
and terogeneity ofend-
users

56. SDN for IoTIV
Rule-placement and traffic
engineering at backbonenetworks

57. SDN for IoTV
Flow classification and enhanced
security at data centernetworks

58. Wireless Sensor NetworkI
✓Challenges
▪iRmeael-ptrogramming of sensornodes
▪Vpencidfiocra-srchitecture
▪Resource constrained –heavy computation cannot beperformed
▪Limited memory –cannot insert too many controlprograms

59. Wireless Sensor NetworkII
✓Opportunities
▪Can we program the sensor nodes inreal-time?
▪Can we change the forwarding path inreal-time?
▪Can we integrate different sensor nodes in aWSN?

60. Software-Defined WSNI
✓Sensor OpenFlow (Luo et al., IEEE Comm. Letters’12)
▪nVatrliuced-caetaforwarding
▪Forward the sensed data if exceeds a certainvalue
▪nIDtr-cicedataforwarding
▪Forward the sensed data based on the ID of the sourcenode
Real-life implementation of such method NOTdone

61. Software-Defined WSNII
✓SNo(ft-WSBera et al., IEEE SJ’16)
▪Sensor DeviceManagement
▪Sensormanagement
▪Multiple sensors can be implemented in a single sensorboard
▪Sensors can be used depending on application-specificrequirements
▪Delaymanagement
▪Delay for sensing can be changed dynamically inreal-time
▪AeectpivMe-aSnlagement
▪States of active and sleep mode can be changeddynamically

62. Software-Defined WSNIII
–forwarding logic of a particular sensorcan
✓SNoft-WS
▪TopologyManagement
▪Npeocdifei-csmanagement
bemodified
▪Npectiwfioc rmk-asnagement
▪Forward all traffic of a node in thenetwork
▪Drop all traffic of a node in thenetwork
Experimental results show that network performance can be improved using
software-defined WSN over traditionalWSN

63. Soft-WSN: ResultI
Packet delivery ratio in the network increases using Soft-WSN
compared to the traditionalWSN.

64. Soft-WSN: ResultII
Number of replicated data packets is reduced using Soft-WSN over
the traditionalWSN.

65. Soft-WSN: ResultIII
Number of control messages in the network is higher using Soft-WSN over the
traditional WSN. This is due to the PACKET-IN message in the network. Each time a
node receives a new packet, it asks the controller for getting adequate forwardinglogic.

66. Software-Defined WSNIII
✓SISDEN(-WGalluccio et al., IEEE INFOCOM’15)
▪A software-defined WSN platform isdesigned
▪Falbolwe-ftor rule placement at sensor nodes isdesigned
▪Any programming language can be used through API to program the
nodes inreal-time

67. SDN-WISE ProtocolStack
✓Sensor nodeincludes
▪IEEE 802.15.4protocol
▪Micro control unit(MCU)
▪Above IEEE 802.15.4stack,
Forwarding layer consists of
Flow-rules.
▪INPP –In Network Packet
Processing
Source: Galluccio et al., IEEE INFOCOM’15

68. Summary
19
✓SDN is useful to manage and control IoTnetwork
✓Wireless sensor nodes and network can be controlled using
SDN-basedapplications
✓Network performance can be improved significantly using
SDN-based approaches over the traditionalapproaches

69. Traditional (Wireless) Mobile
Network
✓Problems in Traditional MobileNetwork
▪Difficult to Scale –static over-provisioned network are inflexible to
manage the mobile traffic with highdemand
▪Difficult to manage –many times lead tomisconfigurations
▪Inflexible –Requires too much time to introduce a new service as the
hardware architecture isinflexible
▪Cxpoestn-seive – Both capital expenditure and operational expenditure are
high
•*Based on information from Open Networking Foundation(ONF)

70. SDN for Mobile NetworkingI
✓Falbolwe-PTaradigm ofSDN
▪Well suited for end-to-end communication over multiple technologies
such as WiFi, 3G, 4G,etc.
✓Logically CentralizedControl
▪Particularly useful for efficent base-station coordination for
addressing inter-cellinterference

71. SDN for Mobile NetworkingII
✓Path Management
▪Data can be routed based on service requirements without depending
on core routingpolicies
✓NetworkVirtualization
▪Abstracts the physical resources from the networkservices
▪Helps in providing seamless connectivity and service differentiation
amongusers

72. SDWMN-Use Case: InterferenceManagement
TraditionalMobileNetwork Software-Defined MobileNetwork
Signals of
eNodeB 2will
not affect
signals of
eNodeB3

73. SDWMN-Use Case: Mobile Traffic
Management
Mobile traffic offloading based onOpenFlow
ANDSF –access
network discovery
and servicefunction

74. KeyBenefits
✓Centralized control of devices manufactured by multiple
vendors
✓Higher rate of integration of newservices
✓Abstracted network control andmanagement
▪Network abstracted from theuser

75. Rule Placement at Access
Devices
✓Challenges
▪General OpenFlow does not support wirelessnetwork
▪Modified version of OpenFlow isrequired
▪Typically, users are mobile in nature –network is highlydynamic
▪Frequent changes in rule placement is alsorequired
▪Presence of heterogeneous devices in thenetwork
▪How to support such heterogeneous devices in a singleplatform

76. Approaches
Introduction to Internet ofThings
76
✓ODIN
✓Uwbi-Flo
✓wMobi-Flo

77. ODINI
✓An agent is placed at access points to communicatewith
controller
✓Two components arepresent
▪Odin agent –placed with the physicaldevices
▪Odin master –placed at the controllerend
77

78. ODINII
✓Conversion of802.11
✓LigVhAtPv–irtLualAP

79. Ubi-FlowI
✓Mobility management inSDIoT
▪Scalable control of the APs
▪Faulttolerance
✓Fchloewd-uSling
▪Networkpartition
▪Networkmatching
▪Loadbalancing

80. Mobi-FlowI
✓wMaorbeilfiltoyw-a -rule placement inSDIoT
80

81. Mobi-FlowII
81
✓Proactive rule placement depending on users’ movement in
thenetwork
✓Approach
▪Predict location of end-users at (t+1) time, while the users are at (t)
time
▪Pulecseatfltohwe-rAPswhich can be associated to the users based
on their predictedlocations

82. Mobi-FlowIII
–takes last k-th location instances topredict
✓Locationprediction
▪OMrdaerkro-Kvpredictor
next location
✓Flelopwla-cruement
▪Linear programming can be used to select optimalAP

83. Mobi-
FlowIV
Message Overhead intheNetwork Energy consumption in theNetwork
Control message overhead and energy consumption can be minimized significantly
using Mobi-Flow compared to the conventional flow-rule placementschemes.

84. Rule Placement at Backbone
Network
✓Existing rule placement schemes for wired network can be
used
✓Load balancing is an important issue due to the dynamic
nature of the IoTnetwork
✓Dynamic resource allocation can also beintegrated

85. Data CenterNetworking
–Wildcard rules can be placed to deal withmice-✓Mwice-Flo
flows
✓Elephant Flow –Exact match rules areuseful
✓We need to classify the flows before inserting flow-rules at
the switches to adequately forward them in thenetwork

86. AnomalyDetectioninIoT
Network
✓Monitor the network through OpenFlow to detect any
anomaly in thenetwork
▪This can be done by monitoring each flow in thenetwork
▪We can also collect the port statistics of theswitches
▪If there is any anomaly, it may generate large number of packets in the
network –it can be detected by monitoring the flows

87. Experimenting with Wireless
Network
✓iMFiininet-W
▪Can be used to deploy anetwork
▪Supports both wired and wirelessnetwork
▪tWheirrende–tpErotocol
▪Wireless –WiFi protocol (IEEE 802.11group)
✓ONOS
▪Can be used to place the controllers