ETSI TS 102 689 V2.1.1 (2013-07)

Machine-to-Machine communications (M2M); M2M service requirements

RTS/M2M-00001ed211

General Information

• Status: Published
• Publication Date: 30-Jun-2013
• Technical Committee: SmartM2M - Smart M2M
• Current Stage: 12 - Completion
• Due Date: 26-Jul-2013
• Completion Date: 01-Jul-2013
• Mandate: M/441

Standards Content (Sample)

Technical Specification
Machine-to-Machine communications (M2M);
M2M service requirements
2 ETSI TS 102 689 V2.1.1 (2013-07)

Reference
RTS/M2M-00001ed211
Keywords
M2M, requirements, service
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2013.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TS 102 689 V2.1.1 (2013-07)
Contents
Intellectual Property Rights . 6
Foreword . 6
Introduction . 6
1 Scope . 7
2 References . 7
2.1 Normative references . 8
2.2 Informative references . 8
3 Abbreviations . 8
4 General requirements . 9
4.1 M2M Application communication principles . 9
4.2 Message Delivery for sleeping devices . 9
4.3 Void . 9
4.4 Message transmission scheduling . 9
4.5 Message communication path selection . 9
4.6 Communication with devices behind a M2M gateway . 9
4.7 Communication failure notification . 9
4.8 Scalability . 10
4.9 Abstraction of technologies heterogeneity . 10
4.10 M2M Service Capabilities discovery and registration . 10
4.11 M2M Trusted Application . 10
4.12 Mobility . 10
4.13 Communications integrity . 10
4.14 Device/Gateway integrity check . 10
4.15 Continuous connectivity . 10
4.16 Confirm . 10
4.17 Void . 11
4.18 Logging . 11
4.19 Void . 11
4.20 Time Stamp . 11
4.21 Device/Gateway failure robustness . 11
4.22 Void . 11
4.23 Operator telco capabilities exposure. 11
4.24 Location reporting support . 11
4.25 Support of multiple M2M Applications . 11
4.26 Support for subscribing to receive notification . 12
4.27 Support for optimizing notification . 12
4.28 Support for store and forward. 12
4.29 Multiple M2M Service Providers . 12
5 Management . 12
5.1 Fault Management . 12
5.1.1 Proactive monitoring. 12
5.1.2 Diagnostics mode . 12
5.1.3 Connectivity test . 12
5.1.4 Fault discovery and reporting . 12
5.1.5 Fault Recovery by Remote Management . 12
5.1.6 Void . 13
5.2 Configuration Management . 13
5.2.1 Pre-provisioning and auto configuration of the M2M Devices and Gateways . 13
5.2.2 M2M Area Network resilience . 13
5.2.3 Time synchronization . 13
5.2.4 Configuration Management . 13
5.3 Accounting . 13
5.3.1 Charging . 13
ETSI
4 ETSI TS 102 689 V2.1.1 (2013-07)
5.3.1.1 Charging recorded information . 13
5.3.1.2 Offline Charging . 13
5.3.1.3 Online Charging . 13
5.3.1.4 Operational requirement . 13
5.3.1.5 Security for charging . 14
6 Functional requirements for M2M services . 14
6.1 Data collection & reporting . 14
6.2 Remote control of M2M Devices . 14
6.3 Group mechanisms . 14
6.4 Void . 14
6.5 M2M Devices/Gateways type varieties . 14
6.6 Information reception . 14
6.7 Reachability . 15
6.8 Asymmetric flows . 15
6.9 Paths diversity . 15
6.10 Heterogeneous M2M Area Networks . 15
6.11 Information collection & delivery to multiple applications . 15
6.12 Management of multiple M2M Devices/Gateways . 15
6.13 M2M Devices/Gateways description. 15
6.14 Data store and share . 15
6.15 Multiple M2M service providers . 15
7 Security. 16
7.1 Authentication . 16
7.2 Authentication of M2M service layer capabilities or M2M applications . 16
7.3 Void . 16
7.4 Data integrity . 16
7.5 Prevention of abuse of network connection. 16
7.6 Privacy . 16
7.7 Multiple actors . 16
7.8 Device/Gateway Integrity Validation . 16
7.9 Trusted Environment . 17
7.10 Security credential and software upgrade at the Application level . 17
7.11 System protection . 17
7.12 Multiple M2M Service Providers . 17
8 Naming, numbering and addressing . 17
8.1 Naming . 17
8.2 Identification . 17
8.3 Addressing . 18
Annex A (informative): M2M System Overview . 19
A.1 High Level System Architecture . 19
Annex B (informative): M2M use cases . 20
B.1 M2M use cases generalized from SCP UICC . 20
B.1.1 Track and trace use cases . 20
B.1.2 Monitoring use cases . 21
B.1.3 Transaction use cases . 22
B.1.4 Control use cases . 22
B.2 Compensation use cases . 23
B.2.1 Utility account management for prepaid . 23
B.2.2 Micro compensation for sensor readings . 23
B.2.3 Additional areas of applicability . 23
B.2.4 Service capabilities and primitives . 23
B.2.5 Example micro compensation scheme . 23
B.3 Home Automation use cases . 24
B.3.1 Energy efficiency at home . 24
B.4 Other use cases . 25
ETSI
5 ETSI TS 102 689 V2.1.1 (2013-07)
B.4.1 Data from Wireless Sensor Networks . 25
Annex C (informative): Security aspects . 26
C.1 Trusted and secure Environment . 26
Annex D (informative): Rationale texts related to some of the Requirements. 28
D.1 Rationale texts for some of the Requirements of clause 4 . 28
D.1.1 Related to clause 4.1 . 28
D.1.2 Related to clause 4.2 . 28
D.1.3 Related to clause 4.3 . 28
D.1.4 Related to clause 4.4 . 28
D.1.5 Related to clause 4.5 . 28
D.1.6 Related to clause 4.6 . 29
D.1.7 Related to clause 4.7 . 29
D.1.8 Related to clause 4.8 . 29
D.1.9 Related to clause 4.13 . 29
D.1.10 Related to clause 4.15 . 29
D.1.11 Related to clause 4.20 . 29
D.2 Rationale texts for some of the Requirements of clause 5 . 29
D.2.1 Related to clause 5.1.3 . 29
D.2.2 Related to clause 5.1.5 . 30
D.2.3 Related to clause 5.2.1 . 30
D.2.4 Related to clause 5.2.2 . 30
D.2.5 Related to clause 5.2.3 . 30
D.2.6 Related to clause 5.2.4 . 30
D.3 Rationale texts for some of the Requirements of clause 6 . 30
D.3.1 Related to clause 6.1 . 30
D.3.2 Related to clause 6.3 . 31
D.3.3 Related to clause 6.4 . 31
D.3.4 Related to clause 6.5 . 31
D.3.5 Related to clause 6.7 . 32
D.3.6 Related to clause 6.8 . 32
D.3.7 Related to clause 6.9 . 32
D.3.8 Related to clause 6.10 . 32
D.3.9 Related to clause 6.11 . 32
D.3.10 Related to clause 6.12 . 32
D.4 Rationale texts for some of the Requirements of clause 7 . 32
D.4.1 Related to clause 7.1 . 32
D.4.2 Related to clause 7.2 . 33
D.4.3 Related to clause 7.3 . 33
D.4.4 Related to clause 7.4 . 33
D.4.5 Related to clause 7.5 . 33
D.4.6 Related to clause 7.6 . 33
D.4.7 Related to clause 7.8 . 33
D.4.8 Related to clause 7.10 . 34
History . 35

ETSI
6 ETSI TS 102 689 V2.1.1 (2013-07)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://ipr.etsi.org).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Machine-to-Machine
communications (M2M).
Introduction
Machine-to-Machine (M2M) communications is the communication between two or more entities that do not
necessarily need any direct human intervention. M2M services intend to automate decision and communication
processes.
The M2M service requirements detailed in the present document enable consistent, cost-effective, communication for
wide-range ubiquitous applications. Examples of such applications include: fleet management, smart metering, home
automation, e-health, etc.
The present document, together with the architecture specification, TS 102 690 [i.1], forms the basis for the M2M
communications detailed technical specifications.
The present document specifies general and functional requirements for M2M communication services.
ETSI
7 ETSI TS 102 689 V2.1.1 (2013-07)
1 Scope
The present document specifies the M2M service requirements aiming at an efficient end-to-end delivery of M2M
services.
It contains the following clauses:
• General requirements - describes communications features necessary for the correct establishment of M2M
communications.
• Management - specifies requirements related to the management modes (malfunction detection,
configuration, accounting, etc.).
• Functional requirements for M2M services - describes functionalities-related requirements for M2M (data
collection & reporting, remote control operations, etc.).
• Security - covers the requirements for M2M device authentication, data integrity, privacy, etc.
• Naming, numbering and addressing - provides the requirements relating to naming, numbering and
addressing schemes specific to M2M.
The M2M requirements in the present document are influenced by the following use cases:
• Smart meter use cases as described in TR 102 691 [i.2].
• eHealth use cases as described in TR 102 732 [i.3].
• Track and Trace use cases as described in annex B.
• Monitoring use cases as described in annex B.
• Transaction use cases as described in annex B.
• Control use cases as described in annex B.
• Home Automation use cases as described in annex B.
• City automation use cases as described in TR 102 897 [i.4].
• Connected consumer used cases as described in TR 102 875 [i.5].
• Automotive use cases as described in TR 102 898 [i.6].
• Smart Grid use cases as described in TR 102 935 [i.10].
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
ETSI
8 ETSI TS 102 689 V2.1.1 (2013-07)
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
Not applicable.
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TS 102 690: "Machine-to-Machine communications (M2M); Functional architecture".
[i.2] ETSI TR 102 691: "Machine-to-Machine communications (M2M); Smart Metering Use Cases".
[i.3] ETSI TR 102 732: "Machine to Machine Communications (M2M); Use cases of M2M
applications for eHealth".
[i.4] ETSI TR 102 897: "Machine to Machine Communications (M2M); Use cases of M2M
applications for City Automation".
[i.5] ETSI TR 102 875: "Access, Terminals, Transmission and Multiplexing (ATTM); Study of
European requirements for Virtual Noise for ADSL2, ADSL2plus and VDSL2".
[i.6] ETSI TR 102 898: "Machine to Machine Communications (M2M); Use cases of Automotive
Applications in M2M capable networks".
[i.7] ISO 16750: "Road vehicles -- Environmental conditions and testing for electrical and electronic
equipment".
[i.8] ETSI TS 102 412: "Smart Cards; Smart Card Platform Requirements Stage 1 (Release 8)".
[i.9] ETSI TR 102 725: "Machine to Machine Communications (M2M) Definitions".
[i.10] ETSI TR 102 935: "Machine-to-Machine communications (M2M); Applicability of M2M
architecture to Smart Grid Networks; Impact of Smart Grids on M2M platform".
3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AEC Automotive Electronics Council
CO Connected Object
CPE Customer Premises Equipment
CPU Central Processing Unit
EPOS Electronic Point of Sale
FW Firmware
HLR Home Location Register
HLSA High-Level M2M System architecture
HSS Home Subscriber Server
HW Hardware
IMSI International Mobile Subscriber Identity
ITS Intelligent Transport System
M2M Machine-to-Machine (communication)
MNO Mobile Network Operator
MS Mobile System
MVNO Mobile Virtual Network Operator
NAT Network Address Translator
NFC Near Field Communication
OAM Over-The-Air Management
PLC Power Line Communication
ETSI
9 ETSI TS 102 689 V2.1.1 (2013-07)
QoS Quality of Service
RFID Radio Frequency IDentification
SLA Service Level Agreement
SW Software
TrE Trusted Environment
UICC Universal Integrated Circuit Card
USSD Unstructured Supplementary Service Data
WAN Wide Area Network
WLAN Wireless Local Area Network
WSN Wireless Sensor Networks
4 General requirements
General requirements specified below are for the M2M System in general, meaning that not all particular M2M systems
or components of these systems need to implement every requirement.
4.1 M2M Application communication principles
The M2M System shall be able to allow communication between M2M Applications in the Network Domain, and the
M2M Device Domain, by using multiple communication meansbased on IP Access.
Also a Connected Object may be able to communicate in a peer-to-peer manner with any other Connected Object.
The M2M System should abstract the underlying network structure including any network addressing mechanism used,
e.g. in case of an IP based network the session establishment shall be possible when IP static or dynamic addressing are
used.
NOTE: Abstraction (e.g. operational environment and topology) of the network can reduce the effort in
application development for varying scenarios.
4.2 Message Delivery for sleeping devices
The M2M System shall be able to manage communication towards a sleeping device.
4.3 Void
4.4 Message transmission scheduling
The M2M System shall be able to manage the scheduling of network access and of messaging.
The M2M System shall be aware of the scheduling delay tolerance of the M2M Application.
4.5 Message communication path selection
Assuming multiple paths are available, the M2M System shall be able to select communication paths, based on
e.g. policies or rely on routing mechanisms in case of transmission failures.
4.6 Communication with devices behind a M2M gateway
The M2M System should be able to communicate with Devices behind a M2M gateway.
4.7 Communication failure notification
M2M Applications, requesting reliable delivery of a message, shall be notified of any failures to deliver the message.
ETSI
10 ETSI TS 102 689 V2.1.1 (2013-07)
4.8 Scalability
The M2M System shall be scalable in terms of number of Connected Objects.
4.9 Abstraction of technologies heterogeneity
The M2M Gateway may be capable of interfacing to various M2M Area Network technologies.
4.10 M2M Service Capabilities discovery and registration
The M2M System shall support mechanisms to allow M2M Applications to discover M2M Service Capabilities offered
to them.
Additionally the M2M Device and M2M Gateway shall support mechanisms to allow the registration of its M2M
Service Capabilities to the M2M system.
4.11 M2M Trusted Application
The M2M Core may handle service request responses for trusted M2M Applications by allowing streamlined
authentication procedures for these applications.
The M2M system may support trusted applications, that are applications pre-validated by the M2M Core.
4.12 Mobility
If the underlying network supports seamless mobility and roaming, the M2M System shall be able to use such
mechanisms.
4.13 Communications integrity
The M2M System shall be able to support mechanisms to assure communications integrity for M2M services.
4.14 Device/Gateway integrity check
The M2M System may support M2M Device and M2M Gateway Integrity Validation [i.9].
4.15 Continuous connectivity
The M2M System shall support continuous connectivity, for M2M applications requesting the same M2M service on a
regular and continuous basis. This continuous connectivity may be de-activated upon request of the Application or by
an internal mechanism in the M2M Core.
4.16 Confirm
The M2M System may support mechanisms to confirm messages.
The M2M System shall support the delivery of the confirmation in a time that is configurable e.g. 1 s.
ETSI
11 ETSI TS 102 689 V2.1.1 (2013-07)
4.17 Void
4.18 Logging
Messaging and transactions requiring non-repudiation shall be capable of being logged. Important events (e.g. received
information from the M2M Device or M2M Gateway is faulty, unsuccessful installation attempt from the M2M Device
or M2M Gateway, service not operating, etc.) may be logged together with diagnostic information. Logs shall be
retrievable upon request.
4.19 Void
4.20 Time Stamp
The M2M System shall be able to support accurate and secure and trusted time stamping. M2M Devices and M2M
Gateways may support accurate and secure and trusted time stamping.
4.21 Device/Gateway failure robustness
After a non-destructive failure, e.g. after a power supply outage, a M2M Device or Gateway should immediately return
in a full operating state autonomously, after performing the appropriate initialization e.g. Integrity Validation [i.9] if
supported.
4.22 Void
4.23 Operator telco capabilities exposure
The M2M interface to the external M2M applications shall enable the exposition of telco operator capabilities
(e.g. SMS, USSD, localization, subscription configuration, authentication (e.g. Generic Bootstrapping Architecture),
etc.). The service platform shall be able to provide access to non-M2M resources abstracted as M2M resources to
provide to the applications a consistent use of the M2M capabilities.(e.g. to send an SMS to common cellular phones).
4.24 Location reporting support
The M2M System shall be able to report M2M Device/Gateway location to M2M applications when this information is
available. The location information of the M2M device/M2M gateway may be determined by the underlying network
procedures (taking into account relevant privacy/security settings for transfer of such information), by application-level
information reported from the M2M device/gateway application, or a combination of both.
4.25 Support of multiple M2M Applications
The M2M System shall support a mechanism to manage a multiple M2M Applications and to provide a mechanism to
interact between multiple M2M Applications. This mechanism shall support as following:
• Maintenance of the list of registered M2M Applications.
• Maintenance of registration information of M2M Applications.
• Notification of newly registered M2M Applications towards the subscribing M2M Applications authenticated
and authorized for the information exchange.
ETSI
12 ETSI TS 102 689 V2.1.1 (2013-07)
4.26 Support for subscribing to receive notification
The M2M System shall support a mechanism for allowing applications or Connected Objects to subscribe and being
notified of changes.
4.27 Support for optimizing notification
The M2M System may support a mechanism for delaying notifying a Connected Objects.
4.28 Support for store and forward
The M2M System may support a mechanism to manage a remote access of information from other Connected Objects.
When supported the M2M system shall be able to aggregate requests and delay to perform the request depending on a
given delay and/or category.
4.29 Multiple M2M Service Providers
• An application on a device or gateway in a M2M system shall be able to operate resources belonging to a
different M2M system.
• An application on a M2M core shall be able to operate resources belonging to a different M2M system.
5 Management
5.1 Fault Management
5.1.1 Proactive monitoring
The M2M System shall be capable of proactively monitoring the M2M system in order to attempt to prevent and correct
errors.
5.1.2 Diagnostics mode
The M2M System shall provide the means to allow diagnostics for M2M Application functioning.
5.1.3 Connectivity test
The M2M System shall support testing the connectivity towards a selected set of Connected Objects (COs) at regular
intervals provided the COs support the function.
5.1.4 Fault discovery and reporting
The Connected Object (CO) operational status shall be monitorable, provided the CO supports the function.
5.1.5 Fault Recovery by Remote Management
M2M devices may support remote management for fault recovery e.g. firmware update, quarantine device. After this
operation of firmware update, the device may reboot to a known and consistent state.
ETSI
13 ETSI TS 102 689 V2.1.1 (2013-07)
5.1.6 Void
5.2 Configuration Management
5.2.1 Pre-provisioning and auto configuration of the M2M Devices and
Gateways
The M2M Application or Capabilities in the Service Capabilities shall support autoconfiguration, that is without human
intervention, of M2M Device or M2M Gateway when these are turned-on. The M2M Device or M2M Gateway may
support autoconfiguration and registration to M2M Application functions.
The M2M System shall support mechanisms to perform simple and scalable pre-provisioning of M2M
Devices/Gateways. The pre-provisioning mechanism shall be able to work even when the communication path to the
M2M Device/Gateway is absent.
5.2.2 M2M Area Network resilience
An M2M Device or M2M Gateway experiencing a fault shall not affect the normal operation of the M2M Area
Network.
5.2.3 Time synchronization
The M2M System should support time synchronization. M2M Devices and M2M Gateways may support time
synchronization. The level of accuracy and of security for the time synchronization can be system specific.
5.2.4 Configuration Management
The M2M System and M2M Gateways shall support configuration management (i.e. manageability will depend on the
end-system).
5.3 Accounting
5.3.1 Charging
5.3.1.1 Charging recorded information
The M2M system shall be able to record charging specific information. The format of the recorded information shall be
fully specified including mandatory and optional elements.
The M2M system shall be able to support correlation between the charging records of the M2M service layer and
available charging records from the Core/Access Network.
5.3.1.2 Offline Charging
The M2M system shall support offline charging at the M2M service layer.
5.3.1.3 Online Charging
TheM2M system shall support online charging at the M2M service layer.
5.3.1.4 Operational requirement
The M2M system shall be able to reuse existing charging mechanisms of Mobile and/or Fixed networks.
ETSI
14 ETSI TS 102 689 V2.1.1 (2013-07)
5.3.1.5 Security for charging
The M2M system shall be able to provide integrity protection of the stored and transferred charging related information
(e.g. CDRs).
6 Functional requirements for M2M services
6.1 Data collection & reporting
The M2M System shall support the reporting from a specific M2M Device or M2M Gateway or group of M2M Devices
or group of M2M Gateways in the way requested by the M2M Application as listed below:
• a periodic reporting with the time period being defined by the M2M application;
• an on-demand reporting with two possible modes. One is an instantaneous collecting and reporting of data, the
other one is a reporting of the data that were pre-recorded at the indicated specific time period;
• a scheduled reporting; or
• an event-based reporting.
6.2 Remote control of M2M Devices
The M2M System shall support the capability for an Application to remotely control M2M Devices that support this
capability.
6.3 Group mechanisms
The M2M System shall support a mechanism to create and remove groups, and to introduce an entity into a group,
modify the invariants (i.e. characteristics) of the members in a group, remove an entity from a group, li
...