IoT & M2M.pdf

IoT & M2M
Differences and Similarities between M2M and
IoT, SDN and NFV for IoT, Difference between SDN and NFV for IoT,
Basics of IoT System Management with
NETCONF, YANG-NETCONF, YANG and SNMP NETOPEER.

1. Unit2
IoT &M2M
-by
GVNSKSravya
ECEDept.
GNITS

2. Outline
•M2M
•Differences and Similarities between M2Mand
IoT
•SDN and NFV forIoT
•Difference between SDN and NFV forIoT
•Basics of IoT System Management with
NETCONF
•YANG-NETCONF
•YANG and SNMPNETOPEER.
IV/IVECE-CIoTbyGVNSKSravya3/14/202
2
2

3. Machine-to-Machine(M2M)
3/14/202
2
3
IV/IVECE-CIoTbyGVNSKSravya
•Machine-to-Machine(M2M)referstonetworkingofmachines(or
devices)
•Provides communicating and computation facilities between machines or
devices
•Purpose of remote monitoring and controlanddataexchange.
•Free of an humanintervention
•M2M provides cross platformintegration.

4. Machine-to-Machine(M2M)
3/14/202
2
4
IV/IVECE-CIoTbyGVNSKSravya

5. Machine-to-Machine(M2M)
3/14/202
2
5
IV/IVECE-CIoTbyGVNSKSravya

6. Machine-to-Machine(M2M)Applications
3/14/202
2
6
IV/IVECE-CIoTbyGVNSKSravya

7. Machine-to-Machine(M2M)Features
3/14/202
2
7
IV/IVECE-CIoTbyGVNSKSravya

8. Machine-to-Machine(M2M)
3/14/202
2
8
IV/IVECE-CIoTbyGVNSKSravya

9. Machine-to-Machine(M2M)
3/14/202
2
9
IV/IVECE-CIoTbyGVNSKSravya

10. Machine-to-Machine(M2M)
1
0
3/14/202
2
IV/IVECE-CIoTbyGVNSKSravya

11. Machine-to-Machine(M2M)
1
1
3/14/202
2
IV/IVECE-CIoTbyGVNSKSravya

12. Machine-to-Machine(M2M)
1
2
3/14/202
2
IV/IVECE-CIoTbyGVNSKSravya

13. Machine-to-Machine(M2M)
1
3
3/14/202
2
IV/IVECE-CIoTbyGVNSKSravya

14. Machine-to-Machine(M2M)
1
4
3/14/202
2
IV/IVECE-CIoTbyGVNSKSravya

15. Machine-to-Machine(M2M)
1
5
3/14/202
2
IV/IVECE-CIoTbyGVNSKSravya

16. Machine-to-Machine(M2M)
1
6
3/14/202
2
IV/IVECE-CIoTbyGVNSKSravya

17. Machine-to-Machine(M2M)
1
7
3/14/202
2
IV/IVECE-CIoTbyGVNSKSravya

18. Machine-to-Machine(M2M)
1
8
3/14/202
2
IV/IVECE-CIoTbyGVNSKSravya

19. Machine-to-Machine(M2M)
1
9
3/14/202
2
IV/IVECE-CIoTbyGVNSKSravya

20. Machine-to-Machine(M2M)
2
0
3/14/202
2
IV/IVECE-CIoTbyGVNSKSravya

21. Machine-to-Machine(M2M)
2
1
3/14/202
2
IV/IVECE-CIoTbyGVNSKSravya

22. Machine-to-Machine(M2M)
2
2
3/14/202
2
IV/IVECE-CIoTbyGVNSKSravya
•Machine-to-Machine(M2M)areanetworkcomprisesofmachineswhich
haveembeddedhardwaremodulesforsensing,actuationand
communication
•VariouscommunicationprotocolssuchasZigBee,Bluetooth,ModBus,
Powerlinecommunication(PLC),6LoWPANetc.,canbeused

23. Machine-to-Machine(M2M)
2
3
3/14/202
2
IV/IVECE-CIoTbyGVNSKSravya

24. Machine-to-Machine(M2M)
•An M2M area network comprises of machines (or M2M nodes)
whichhaveembedded hardware modules for sensing,
actuation andcommunication.
•Various communication protocols can be used for M2M local
areanetworks such as ZigBee, Bluetooh, ModBus, M-Bus,
WirlessM-Bus,PowerLine Communication (PLC),6LoWPAN,
IEEE 802.15.4,etc.
IV/IVECE-CIoTbyGVNSKSravya 2
4
3/14/202
2

25. Machine-to-Machine(M2M)
•Thecommunicationnetworkprovidesconnectivitytoremote
M2Mareanetworks.
•Thecommunicationnetworkcanuseeitherwiredorwireless
networks(IP-based).
•WhiletheM2Mareanetworksuseeitherproprietaryornon-IP
basedcommunicationprotocols,thecommunicationnetwork
usesIP-basednetworks.
IV/IVECE-CIoTbyGVNSKSravya 2
5
3/14/202
2

26. M2MGateway
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
26
•Since non-IP based protocols are used within M2M areanetworks,
theM2M nodes within one network cannot communicate with
nodesinanexternalnetwork.
•To enable the communication between remote M2Marea
networks,M2M gateways areused.

27. M2MGateway
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
27

28. Difference between IoT andM2M
CommunicationProtocols
•M2M and IoT can differ in how the communication betweenthe
machinesordeviceshappens.
•M2M uses either proprietary or non-IP basedcommunication
protocolsforcommunication within the M2M areanetworks.
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
28

29. Difference between IoT andM2M
Machines in M2M vs Things inIoT
•The "Things" in IoT refers to physical objects that haveunique
identifiersandcan sense and communicate with theirexternal
environment(anduserapplications) or their internal physical
states.
•M2M systems, in contrast to IoT, typically havehomogeneous
machine typeswithin an M2M areanetwork.
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
29

30. Difference between IoT andM2M
Hardware vs SoftwareEmphasis
•While the emphasis of M2M is more on hardwarewith
embeddedmodules, theemphasis of IoT is more onsoftware.
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
30

31. Difference between IoT andM2M
Data Collection &Analysis
•M2M data is collected in point solutions and often inon-
premisesstorageinfrastructure.
•In contrast to M2M, the data in IoT is collected in thecloud
(can be public,privateorhybridcloud).
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
31

32. Difference between IoT andM2M
Applications
•M2M data is collected in point solutions and can beaccessed
byon-premisesapplications such as diagnosis applications,
service management applications,andon-premisis
enterpriseapplications.
•IoT data is collected in the cloud and can be accessed by
cloud applicationssuchasanalytics applications,enterprise
applications, remote diagnosis and management
applications,etc.
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
32

33. Communication in IoT vsM2M
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
1
4

34. Communication in IoT vsM2M
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
1
4

35. Over View of CurrentNetwork
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
1
4

36. Over View of CurrentNetwork
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
1
4

37. Over View of CurrentNetwork
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
1
4

38. Over View of CurrentNetwork
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
1
4

39. Over View of CurrentNetwork
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
1
4

40. Over View of CurrentNetwork
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
1
4

41. Over View of CurrentNetwork
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
1
4

42. Over View of CurrentNetwork
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
1
4

43. Over View of CurrentNetwork
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
1
4

44. Over View of CurrentNetwork
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
1
4

45. Over View of CurrentNetwork
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
1
4

46. SDN
•Software-DefinedNetworking(SDN) is a networking
architecture thatseparatesthecontrol plane from thedata
plane andcentralizesthenetworkcontroller.
•Software-basedSDN controllersmaintain a unified view ofthe
network and make configuration, management and
provisioningsimpler.
3/14/202
2
IV/IVECE-CIoTbyGVNSKSravya 46

47. SDN
•The underlyinginfrastructureinSDN uses simple packet
forwardinghardwareasopposedtospecializedhardwarein
conventionalnetworks.
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
47

48. Conventional NetworkArchitecture
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
48

49. Limitations of ConventionalNetwork
Architecture
•Complex networkdevices
•ManagementOverhead
•LimitedScalability
SDN attempts to create network architectures that aresimple,
inexpensive, scalable and easy tomanage
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
49

50. SDNArchitecture
3/14/202
2
5
0
IV/IVECE-CIoTby

51. SDN LayeredArchitecture
3/14/202
2
5
1
IV/IVECE-CIoTbyGVNSKSravya

52. Key elements ofSDN
Centralized NetworkController
•With decoupled control and data planes and centralized
network controller,the network administrators canrapidly
configure thenetwork.
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
52

53. Key elements ofSDN
Programmable OpenAPIs
•SDNarchitecturesupportsprogrammableopenAPIs forinterface
betweenthe SDN application and control layers (Northbound
interface).
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
53

54. Key elements ofSDN
StandardCommunicationInterface(OpenFlow)
•SDNarchitectureusesastandardcommunicationinterface
betweenthecontrolandinfrastructurelayers(Southbound
interface).
•OpenFlow,whichisdefinedbytheOpenNetworkingFoundation
(ONF)isthebroadlyacceptedSDNprotocolfortheSouthbound
interface.
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
54

55. Open FlowSwitch
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
55

56. Key elements ofSDN
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
56

57. NFV
•Network Function Virtualization (NFV) is a technology that
leveragesvirtualization to consolidate the heterogeneous network
devices onto industry standard high volume servers, switches and
storage.
•NFViscomplementaryto SDNasNFVcanprovidethe
infrastructureonwhich SDN canrun.
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
2
1

58. NFV
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
2
1

59. Key elements ofNFV
Virtualized Network Function(VNF):
•VNF is a software implementation of a network function whichis
capableofrunning over the NFV Infrastructure(NFVI).
NFV Infrastructure(NFVI):
•NFVIincludescompute,networkandstorageresourcesthatare
virtualized.
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
2
2

60. Key elements ofNFV
NFV Management andOrchestration:
•NFV Management and Orchestration focuses on allvirtualization-
specificmanagement tasks and covers the orchestrationand life-
cyclemanagement of physical and/or software resources that
supporttheinfrastructure virtualization, and thelife-cycle
management ofVNFs.
IV/IVECE-CIoTbyGVNSKSravya
3/14/202
2
2
2

61. NFV UseCase
NFV can be used to virtualize the Home Gateway. The NFV
infrastructure in the cloud hosts a virtualized Home Gateway.
The virtualized gateway provides private IP addresses to the
devices in the home. The virtualized gateway also connects
to network services such as VoIP andIPTV.
3/14/202
2
61IV/IVECE-CIoTbyGVNSKSravya

62. NFV Use CaseConventional
HomeArchitecture
•
3/14/202
2
62IV/IVECE-CIoTbyGVNSKSravya

63. Need for IoT Systems
Management
•AutomatingConfiguration
•Monitoring Operational & Statistical
Data
•ImprovedReliability
•System WideConfigurations
•Multiple SystemConfigurations
•Retrieving & ReusingConfigurations

65. Simple Network Management Protocol
(SNMP)
•SNMP is a well-known and widely used
network management protocol that allows
monitoring and configuring network devices
such as routers, switches, servers, printers,
etc.
•SNMP component include
•Network Management Station(NMS)
•Managed Device
•Management Information Base(MIB)
•SNMP Agent that runs on thedevice

66. Limitations ofSNMP
•SNMP is stateless in nature and each SNMP request contains all
the information to process the request. The application needs to be
intelligent to manage thedevice.
•SNMP is a connectionless protocol which uses UDP as the transport
protocol, making it unreliable as there was no support for
acknowledgement of requests.
•MIBs often lack writable objects without which device configuration
is not possible usingSNMP.
•It is difficult to differentiate between configuration and state data in
MIBs.
•Retrieving the current configuration from a device can be difficult
with SNMP.
•Earlier versions of SNMP did not have strong securityfeatures.

67. Network Operator
Requirements
•Ease ofuse
•Distinction between configuration and state
data
•Fetch configuration and state dataseparately
•Configuration of the network as awhole
•Configuration transactions across devices
•Configuration deltas
•Dump and restoreconfigurations
•Configuration validation
•Configuration databaseschemas
•Comparingconfigurations
•Role-based accesscontrol
•Consistency of access control lists:
•Multiple configurationsets
•Support for both data-oriented and
task-oriented access control

68. NETCONF
•NetworkConfigurationProtocol(NETCONF)isasession-basednetworkmanagement
protocol.NETCONFallowsretrievingstateorconfigurationdataandmanipulating
configurationdataonnetworkdevices

69. NETCONF
•NETCONF works on SSH transportprotocol.
•Transport layer provides end-to-end connectivity and ensure reliable delivery of
messages.
•NETCONF uses XML-encoded Remote Procedure Calls (RPCs) for framing
request and responsemessages.
•The RPC layer provides mechanism for encoding of RPC calls andnotifications.
•NETCONF provides various operations to retrieve and edit configuration
data from networkdevices.
•The Content Layer consists of configuration and state data which isXML-encoded.
•The schema of the configuration and state data is defined in a data modeling
language calledYANG.
•NETCONF provides a clear separation of the configuration and statedata.
•The configuration data resides within a NETCONF configuration datastore on the
server.

70. NETCONF

71. IV/IV ECE-C IoT by GVNSK
Sravya
4/6/2022
6
3

72. IV/IV ECE-C IoT by GVNSK
Sravya
4/6/2022
6
4

73. IV/IV ECE-C IoT by GVNSK
Sravya
4/6/2022
6
5

74. IV/IV ECE-C IoT by GVNSK
Sravya
4/6/2022
6
6

75. YANG
IV/IV ECE-C IoT by GVNSK
Sravya
4/6/2022
6
7
•YANGisadatamodelinglanguageusedtomodelconfigurationand
statedata
manipulated by the NETCONFprotocol
•YANG modules contain the definitions of the configuration data, state
data,
RPC calls that can be issued and the format of thenotifications.
•YANG modules defines the data exchanged between the NETCONF
clientand server.
•Amodulecomprisesofanumberof'leaf'nodeswhichareorganized
intoa hierarchical treestructure.

76. YANG
IV/IV ECE-C IoT by GVNSK
Sravya
4/6/2022
6
8
•The 'leaf' nodes are specified using the 'leaf' or 'leaf-list'constructs.
•Leaf nodes are organized using 'container' or 'list'constructs.
•A YANG module can import definitions from othermodules.
•Constraints can be defined on the data nodes, e.g. allowedvalues.
•YANGcanmodelbothconfigurationdataandstatedatausingthe
'config' statement.

77. YANG
IV/IV ECE-C IoT by GVNSK
Sravya
4/6/2022
6
8

78. YANG
IV/IV ECE-C IoT by GVNSK
Sravya
4/6/2022
6
9

79. IV/IV ECE-C IoT by GVNSK
Sravya
4/6/2022
7
0

80. IV/IV ECE-C IoT by GVNSK
Sravya
4/6/2022
7
0

81. IV/IV ECE-C IoT by GVNSK
Sravya
4/6/2022
7
0

82. IV/IV ECE-C IoT by GVNSK
Sravya
4/6/2022
7
0

83. IV/IV ECE-C IoT by GVNSK
Sravya
4/6/2022
7
0

84. IV/IV ECE-C IoT by GVNSK
Sravya
4/6/2022
7
0

85. YANG
IV/IV ECE-C IoT by GVNSK
Sravya
4/6/2022
7
0

86. YANG
IV/IV ECE-C IoT by GVNSK
Sravya
4/6/2022
7
0

87. IV/IV ECE-C IoT by GVNSK
Sravya
4/6/2022
7
0

88. IV/IV ECE-C IoT by GVNSK
Sravya
4/6/2022
7
0

89. NETOPEER
•NETOPEER is a set of open source NETCONF tools built on
the Libnetconflibrary.
•It allows operators to connect to their NETCONF enabled
devices as well as developers to allow control their devices via
NETCONF.
•NETOPEER tools include
NETOPEER Server
NETOPEER Agent
NETOPEER Cli
NETOPEER Manager
NETOPEER Configurator
IV/IV ECE-C IoT by GVNSK
Sravya
4/6/2022
7
1

90. IV/IV ECE-C IoT by GVNSKSravya
4/6/2022

91. NETOPEER
NETOPEER-Server
•It is a NETCONF protocol server that runs on the managed
device.
•It provides an environment for configuring the device using
NETCONF RPC operations and also retrieving the state data
from the device.
IV/IV ECE-C IoT by GVNSK
Sravya
4/6/2022
7
1

92. NETOPEER
NETOPEER-agent
•It is a NETCONF protocol agent running as a SSH/TLS
subsystem.
•It accepts incoming NETCONF connection and passes the
NETCONF RPC operations received from the NETCONF client
to the NETOPEER Server.
IV/IV ECE-C IoT by GVNSK
Sravya
4/6/2022
7
1

93. NETOPEER
NETOPEER-cli
•It is a NETCONF client that provides a command line interface
for interfacing with the NETOPEER-Server.
•The operator can use the NETOPEER-Clifrom the
management system to send NETCONF RPC operations for
configuring the device and retrieving the state information.
IV/IV ECE-C IoT by GVNSK
Sravya
4/6/2022
7
1

94. NETOPEER
NETOPEER-manager
•NETOPEER manager allows managing the YANG and
LibnetconfTransaction API (Trans API) modules on the
NETOPEER-Server.
•With NETOPEER manager modules can be loaded or removed
from the server.
NetopeerConfigurator
•It is a tool that can be used to configure the Netopeer-Server.
IV/IV ECE-C IoT by GVNSK
Sravya
4/6/2022
7
1

95. IV/IV ECE-C IoT by GVNSK
Sravya
4/6/2022
7
0

96. IV/IV ECE-C IoT by GVNSK
Sravya
4/6/2022
7
0