行動寬頻尖端技術跨校教學聯盟 System Architecture of the IoT/M2M 物聯網系統架構 國立交通大學資訊工程系 Department of Computer Science National Chiao Tung University
Outline 1. IoT/M2M System Structure 2. Introduction to ETSI TC M2M and onem2m 3. IoT/M2M Use-Case-Driven Requirements 4. IoT/M2M High Level Architecture 2
IoT/M2M System Structure 3
IoT/M2M System Structure Application server Application server Business Applications Internet Communication networks device Gateway Agents/ End Users Scenario 1 M2M agent Scenario 2 M2M relationship Scenario 3 M2M area networks 4
M2M Area Networks M2M area network is introduced by ETSI Provide PHY and MAC layer connectivity between M2M devices connected to the same M2M area network Allow M2M devices to gain access to a public network via a gateway Gateway M2M area network devices + gateway 5
Characteristics of M2M Information exchange over communication networks Via mobile networks or public internets A group of similar devices Devices with limited capacities Hierarchical architecture Autonomous Application server Internet (Communication Network) Gateway 6
Characteristics of M2M Applications A large amount of devices Scalability issues Non-classical usage patterns in mobile networks E.g., not always active - only be triggered for specific reason and only do things in some fixed time. A large variety of devices Heterogeneous systems Diverse requirements, e.g., data exchange rate Build common-enabling capabilities Transparency: no need of the interference of humans Intrusiveness: privacy issues Criticality: life-savers, life-critical 7
Battery powered M2M Devices E.g., water meters are located outdoors and cannot be easily connected to a power supply. Embedded Many devices are deployed in systems with specific operating condition and with limited computation power. E.g., the OBD in car Here to stay Many devices are static or with very low mobility. 8
Challenges Fragmentation of solutions It is important to have service platforms that can be reused for multiple applications. Network misalignment large numbers of devices generating very small amounts of data transport and potentially a very significant overload of the control and connectivity planes. Security issues E.g., ehealth, Smart Grid, etc. Privacy issues 9
Introduction to ETSI TC M2M and onem2m 10
Introduction to ETSI TC M2M ETSI (European Telecommunications Standards Institute) TC (Technical Committee) M2M established in Jan 2009. Up to the end of 2012, There were active delegates from Europe, North America, China, Korea, and Japan with a composition of about 30% Operators, 60% Manufacturers and 10% others. Intensive effort with 8 plenary meetings per year plus numerous ad-hoc meetings and 3-5 conference calls per week About 300+ documents and 70+ delegates per meeting About 400+ members in M2M email list The name has been changed to ETSI TC SmartM2M since November 2013 to focus on EU regulations and verticals.
Goals of ETSI TC M2M To develop and maintain an end-to-end overall telecommunication high level architecture for M2M To identify gaps where existing standards and provide specifications to fill these gaps Source: ETSI M2M TC 12
ETSI M2M Network Client Applications M2M Area Network M2M Core Network M2M Device Service Capabilities M2M Gateway Service Capabilities M2M Network Service Capabilities M2M Gateway M2M Applications M2M Device Domain M2M Network Domain M2M Application Domain 13
M2M Device Domain (M2M Area Network) Different M2M devices for different vertical markets Diverse technologies employed to support various applications Two types of devices ones capable of directly connecting to the network and the others requires an M2M gateway in order to connect to the network. 14
M2M Network Domain It consists of M2M core and M2M service capabilities. The M2M core can leverage the existing telecom networks including fixed and mobile networks (2G,3G or 4G LTE). But, mobile networks will be the primary M2M network. M2M service capabilities are network functions defined to support M2M applications. 15
M2M Application Domain Two types of applications - M2M applications and client applications M2M applications: located on the servers, built upon M2M service capabilities and interacting with M2M devices. Client applications: used to serve end-users; either receive services from M2M applications or directly from M2M devices. 16
Technical Report (TR) Study before standards specifications These reports are not standards The ideas, however, lead to standards specifications. 17
Technical Specification (TS) There are official standards specifications. It follows three stages of specification from high level to low level Stage 1: Requirements Stage 2: Architecture Stage 3: Interfaces, APIs 18
Output of ETSI TC M2M M2M Release 1 Specifications completed at the end of 2011. May 2010 M2M use cases TRs for connected consumer, city automation, automotive, ehealth and smart metering. August 2010 Stage 1 TS (M2M Requirements) 3 rd Quarter 2011 Stage 2 TS (M2M Architecture) 4 th Quarter 2011 Stage 3 TS (M2M Interfaces, APIs) 19
ETSI M2M Specification Work TR 101 584 Study on Semantic Support of M2M Data TR 102 732 ehealth TR 102 935 Smart Grid Impacts on M2M Stage 1 TR 103 167 Threat analysis and counter measures to M2M service layer Stage 2 TS 103 104 Interoperability Test Specification for CoAP Binding of ETSI M2M Primitives Stage 3 TR 102 857 Connected Consumer TS 102 689 M2M Service Requirements TS 102 690 M2M Functional Architecture TS 102 921 M2M Communications, mia, dia, mid interfaces TR 102 898 Automotive TR 102 725 M2M Definitions TS 103 092 OMA DM compatible Management Objects TR 103 118 Smart Energy Infrastructure security Use cases TR 102 966 Interworking with M2M Area Networks TS 103 093 BBF TR-069 compatible Management Objects 20
Importance of ETSI TC M2M Work First to create a system-level architecture for mass-scale M2M applications, covering all domains of M2M, not just one domain in particular. Has become a major driver in creating the onem2m system-level international standard for the Internet of Things. 21
Why M2M System-Level Architecture Enable the development of M2M applications by focusing on high level functionality than lower level tasks like network access control, authentication or routing. Enable data retrieval and control of sensors by any application via a common horizontal service layer. Provide network-based services such as data publication and subscription. 22
Common Horizontal Service Layer SMART GRID CONNECTED VEHICLE E-HEALTH CONNECTED HOME Vertical Specific APIs Required Standards M2M Common ICT Services for Vertical Domains M2M Core Needs 23
Future Vision Applications Applications Applications Applications Network Domain Common Service Layer Converged Network Domain Devices Devices Devices Devices Gateway Devices Present Future 24
ETSI M2M TC Release 2 Finished in the beginning of 2013 with a short list of features: Charging: definition of the architectural framework for recording, tracking and exchange of events relevant for charging, including correlation with charging information from the underlying network Inter-domain communications between service platforms: inter-nscl communication, on mim reference point (a variant of mid). M2M Light: ETSI M2M Release1 was already supporting very constrained devices via gateways, in Release 2 very constrained device can connect directly to the network platform. Semantic interworking guidelines: common semantic rules has been defined for applications belonging to different industrial segment, to assure the understanding of the shared data, for a very wide set of commonly used technologies 25
Launched In July 2012 onem2m Effort Global Initiative focused on consolidation and standardization of a common M2M Service Layer which can be embedded in hardware or software Objectives are to enhance interoperability, simplify development of applications, boost economies of scale, and reduce standards overlap Release 1 of onem2m specifications was made available on February 4 2015! 26
Over 200 member organizations in onem2m Chunghwa Telecom HTC III National Chiao Tung University Source: onem2m 27
IoT/M2M Use-Case-Driven Requirements 28
What is a Use Case? A use case describes the interactions between one or more actors and the system under consideration for achieving certain functions. Actors can be a device or a person outside the system. The system is treated as a black box where the physical architecture of the system is not important. 29
Use Cases to Derive ETSI M2M Requirements From five families of use cases 1. Connected home 2. City automation 3. Automotive 4. ehealth 5. Smart metering Not exhaustive but to ensure the capture of all important requirements! 30
Methodology Used by ETSI M2M TC Use of a Template to Describe Use Case 1. General Use Case Description 2. Stakeholders 3. Scenario Case Description 4. Information Exchanges 5. Potential New Requirements 6. Use Case Source 31
Smart Metering Use Cases (1) Influenced and driven by the M/441 mandate of the European Commission to create standards that will enable interoperability of smart meter and raise customers awareness of their consumption of water, gas, electricity etc. The goal is to reduce energy consumption and mitigate CO2 and other greenhouse-gas emissions. 32
Smart Metering Use Cases (2) Six categories of functionalities were identified by SMCG (Smart Metering Coordination Group) in Europe Remote reading Two way communications Meter supporting advanced tariffing and payment systems Remote disablement and enablement of supply Secure communications Information display to an in-home/building display 33
Smart Metering Use Cases (3) Major contributor of use cases: ESMIG (European Smart Metering Industry Group) Example requirements identified: 1. Support of atomic transactions 2. Authentication and authorization of smart meters 3. Triggering of smart meters by network applications 34
ehealth Use Cases (1) Examples of ehealth applications Remote patient monitoring Disease managemenet Aging independence Personal fitness and health improvement 35
ehealth Use Cases (2) Types of sensors Blood pressure Pulse Oximeter Pedometer Employ short-range radio to transmit data to a device such as smart phone in order to send data to the backend server. 36
ehealth Use Cases (3) Example requirements identified: 1. Location tracking 2. Support of time-critical messaging 3. Support for accurate time stamping 4. No interference with electro-medical devices 5. Indication and control of radio transmission 37
Connected Home Use Cases Example requirements identified: Visualization of energy usage Visualization of historical data Alarms or messages to inform customers for special events Optimization of energy cost Avoidance of overload Demand response capabilities End user control 38
TS 102.689 M2M Requirements Major categories of requirements General requirements Management requirements Functional requirements for M2M services Security requirements Naming, numbering and addressing requirements Requirements from M2M Traffic Characteristics 39
M2M Management Requirement Examples Fault management (proactive monitoring, fault discovery, connectivity, verification, fault recovery, etc.) Configuration management (configuration of network and service parameters, installing of new application versions, etc.) Software upgrades, firmware updates and patches. 40
M2M Security Requirement Examples Mutual authentication between communicating entities Data transfer confidentiality Data transfer integrity verification No use of an M2M communication module for generic communication purposes Device/gateway integrity validation Security credential and software upgrade at the application level 41
M2M Naming and Addressing Requirement Examples Device names rather than network addresses are to be used by the application Support of multiple addressing schemes such as IP, E.164 etc. 42
Requirements from M2M Traffic Characteristics Different M2M applications impose different traffic requirement on the networks Most M2M devices nowadays are still dependent on 2G networks. Overall M2M traffic volumes are growing year after year. However, the traffic will gradually shift from 2G to 3G and from 3G to 4G or 5G. M2M traffic study is important to better understand its impact to telecom networks. 43
List of General Requirements from TS 102.689 (1) 4.1 M2M application communication principles 4.2 Message delivery for sleeping devices 4.3 Delivery modes 4.4 Message transmission scheduling 4.5 Message communication path selection 4.6 Communication with devices behind a M2M gateway 4.7 Communication failure notification and control 4.8 Scalability 4.9 Abstraction of technologies heterogeneity 4.10 M2M Service Capabilities discovery and registration 44
List of General Requirements from TS 102.689 (2) 4.11 M2M Trusted Application 4.12 Mobility 4.13 Communications integrity 4.14 Device/Gateway integrity check 4.15 Continuous connectivity 4.16 Confirm 4.17 Priority 4.18 Logging 4.19 Anonymity 4.20 Time Stamp 45
List of General Requirements from TS 102.689 (3) 4.21 Device/Gateway failure robustness 4.22 Radio transmission activity indication 4.23 Operator telco capabilities exposure 4.24 Location reporting support 46
IoT/M2M High Level Architecture 47
IoT/M2M High Level Architecture Specified in ETSI TS 102.690. Separation of device, network and application domains. Device domain*: M2M device networks Network domain: M2M access and core networks Application domain**: M2M applications *Device domain includes both device and gateway. **M2M applications can reside in either the device or network domain! 48
ETSI M2M Functional Architecture M2M Device/Gateway Applications dia M2M Gateway Service Capabilities mid M2M Network Applications mia M2M Network Service Capabilities Source: ETSI M2M TC
M2M Network Domain Wide Area Network: includes both access and core networks. Access networks can be wireless, mobile, fixed or other types. M2M Network Service Capabilities Layer (NSCL): functional modules that implement common M2M functions sharable by many M2M applications through open interfaces. Network Applications: M2M applications reside in the core network. 50
M2M Device & Gateway Domain M2M Area Network: Many varieties of protocols for different vertical applications Device Three types of devices 1. Proprietary devices: devices that only support proprietary interfaces. 2. Devices with M2M service capabilities (Device SCL) 3. Devices without M2M service capabilities Gateway Equipped with M2M service capabilities (Gateway SCL). 51
M2M Applications M2M applications can reside on application servers in the core network, M2M gateways or M2M devices. 52
Reference Points Define three interfaces Interface between M2M applications and NSCL -> mia Interface between M2M application and GSCL or DSCL -> dia Interface between NSCL and GSCL or DSCL -> mid d (device network domain) m (M2M network domain) a (SCL for application service capabilities) 53
ETSI M2M High Level Architecture Device Network View Source: ETSI M2M TC 54
Examples of M2M Area Networks Zigbee (IEEE 802.15.4) ANSI C12 Suite WiFi Power Line Communication BACnet KNX 6LoWPAN/RPL/CoAP 55
ETSI M2M High Level Architecture M2M Network View Source: ETSI M2M TC 56
Management Functions M2M Management Functions: provide MSBF (M2M Service Bootstrapping Function) and and MAS (M2M Authentication Service) etc. Network Management Functions: provide general access and core network service provisioning and supervision. 57
mia Interface Provides registration and authorization primitives for NAs to NSCL Supports service session management (event reporting or streaming sessions) Provides read/write/execute/subscribe/notify primitives for NAs to NSCL 58
dia Interface Provides registration and authorization primitives for DAs and GAs to the DSCL or GSCL. Supports service session management (event reporting or streaming sessions) Provides read/write/execute/subscribe/notify primitives for DAs and GAs to the DSCL or GSCL. 59
mid Interface Provides registration and authorization primitives for DSCL or GSCL to NSCL. Supports service session management (event reporting or streaming sessions) Provides read/write/execute/subscribe/notify primitives for DSCL or GSCL to NSCL. 60
What Are M2M Service Capabilities? M2M service capabilities can reside in the end device, in the gateway, or in the network. In the acronyms below x=d for SC in the device X=G for SC in the gateway X=N for SC in the network 61
Service Capabilities Identified in ETSI M2M Release 1 (1) 1. application enablement (xae); 2. generic communication (xgc); 3. reachability, addressing and repository (xrar); 4. communication selection (xcs); 5. remote entity management (xrem); 6. security (xsec); 62
Service Capabilities Identified in ETSI M2M Release 1 (2) 7. history and data retention (xhdr); 8. transaction management (xtm); 9. compensation broker (xcb); 10. telco operator exposure (xtoe); 11. interworking proxy (xip). 63
Finalization of M2M Service Capabilities Up to the ongoing effort in onem2m global initiative (or partnership) Further modifications and changes expected Thus more important to grasp the architectural concepts than to memorize all details! 64
Concluding Remarks (1) ETSI TC follows a rigorous process to define a high level architecture for IoT/M2M It starts from use case studies across five vertical markets to capture sufficient requirements. Based on these requirements, a high-level IoT/M2M architecture is developed. The architecture consists of three domains: M2M network domain, M2M application domain and M2M device domain. 65
Concluding Remarks (2) Three interfaces mia, dia and mid are defined for the M2M network. Eleven M2M service capabilities are also identified. These service capabilities are distributed in the M2M networks and can reside in the network, gateways or devices to support M2M services. 66
Where to Find ETSI M2M and onem2m Specifications ETSI M2M Published Documents http://www.etsi.org/technologies-clusters/technologies/m2m onem2m Published Documents http://www.onem2m.org/technical/published-documents 67