ETSI TR 102 966 V1.1.1 (2014-02)

Machine-to-Machine communications (M2M); Interworking between the M2M Architecture and M2M Area Network technologies

DTR/M2M-00014ed111

General Information

• Status: Published
• Publication Date: 09-Feb-2014
• Technical Committee: SmartM2M - Smart M2M
• Current Stage: 12 - Completion
• Due Date: 10-Feb-2014
• Completion Date: 10-Feb-2014
• Mandate: M/441

Standards Content (Sample)

Technical Report
Machine-to-Machine communications (M2M);
Interworking between the M2M Architecture
and M2M Area Network technologies

2 ETSI TR 102 966 V1.1.1 (2014-02)

Reference
DTR/M2M-00014ed111
Keywords
interworking, M2M, 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 2014.
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 TR 102 966 V1.1.1 (2014-02)
Contents
Intellectual Property Rights . 6
Foreword . 6
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Abbreviations . 8
4 Scenarios for interworking . 9
5 Interworking with legacy devices (d) . 12
5.1 Implementation profile 1 . 12
5.1.1 Entity-relation representation of the M2M area network . 12
5.1.2 Mapping principles . 12
5.1.3 M2M Area Network specific technologies interworking . 17 ®
5.1.3.1 ZigBee Alliance . 17 ®
5.1.3.1.1 Implementation profile 1 for ZigBee PAN interworking with ETSI M2M . 18 ®
5.1.3.1.2 ZigBee Interworking Proxy Application resource structure . 19 ®
5.1.3.1.3 ZigBee network resource structure . 19 ®
5.1.3.1.4 ZigBee node resource structure . 19 ®
5.1.3.1.5 ZigBee application resource structure . 20 ®
5.1.3.1.6 Use of mirroring or retargeting for ZigBee interfaces (clusters) . 21
5.1.3.2 UPnP . 21
5.1.3.2.1 Implementation profile 1 for UPnP interworking with ETSI M2M . 23
5.1.3.2.2 UPnP Interworking Proxy Application resource structure . 23
5.1.3.2.3 UPnP network resource structure . 23
5.1.3.2.4 UPnP node resource structure . 24
5.1.3.2.5 UPnP service resource structure . 24
5.1.3.3 KNX™ . 25
5.1.3.3.1 Implementation profile 1 for KNX™ PAN interworking with ETSI M2M . 26
5.1.3.3.2 KNX™ Interworking Proxy resource structure . 26
5.1.3.3.3 KNX™ Network resource structure . 27
5.1.3.3.4 KNX™ Group resource structure . 27
5.1.3.3.5 KNX™ Node resource structure . 27
5.2 Implementation profile 2 . 27
6 Interworking with M2M devices without SCL (D') . 27
6.1 Security considerations . 27
6.1.1 D' devices traffic aggregation by Gateway acting as proxy/concentrator . 28
6.1.2 MAN devices generating traffic with their own identity and security via gateway acting as
multiplexer/funnel . 28
6.1.3 Gateway acting as security mediator between MAN and M2M Core . 29
Annex A: Example of syntax for searchstring Tags . 30
A.1 Category: ETSI.ObjectType . 30
A.2 Category: ETSI.ObjectSemantic . 30
A.3 Category: ETSI.ApplicationProfile . 30
A.4 Category: ZigBee.ApplicationProfile . 31
A.5 Category: ZigBee.DeviceIdentifier . 31
A.6 Category: KNX.DptID . 31
A.7 Category: KNX.AreaID. 31
ETSI
4 ETSI TR 102 966 V1.1.1 (2014-02)
A.8 Category: KNX.LineID . 31
Annex B: Example of Application/XML syntax, oBix 1.1 semantic conventions . 32
B.1 Generic Area Network object representations . 32
B.1.1 Generic Interworking Proxy Application resource content structure . 32
B.1.2 Generic Network resource content structure . 32
B.1.3 Generic Device resource content structure . 34
B.1.4 Generic Application resource content structure . 35
B.1.5 GenericInterface resource content structure . 35
B.1.6 Generic Point resource content structure . 36 ®
B.2 ZigBee Area Network object representations . 36 ®
B.2.1 Mapping of native ZigBee primitive types to oBix types . 36 ®
B.2.2 ZigBee Interworking Proxy Application resource content structure . 37 ®
B.2.3 ZigBee Network resource content structure . 38 ®
B.2.4 ZigBee Device resource content structure . 38 ®
B.2.5 ZigBee Application resource content structure . 39 ®
B.2.6 ZigBee cluster (Interface) resource content structure . 40 ®
B.2.7 ZigBee Point resource content structure . 40 ®
B.2.8 ZigBee Application representation examples . 41
B.3 wM-Bus Area Network object representations . 42
B.3.1 Mapping of native wM-Bus primitive types and units to oBix types and units . 42
B.3.2 wM-Bus Interworking Proxy Application resource content structure . 43
B.3.3 WM-Bus Network resource content structure . 43
B.3.4 WM-Bus Device resource content structure . 44
B.3.5 WM-Bus Application resource content structure . 45
B.3.6 WM-Bus profile (Interface) resource content structure . 45
B.3.7 WM-Bus Point resource content structure . 46
B.3.8 WM-Bus Application representation examples . 46
B.4 KNX™ Area Network object representations . 47
B.4.1 Mapping of native KNX™ data point types to oBix types and units . 47
B.4.2 KNX™ Interworking Proxy resource content structure . 57
B.4.3 KNX™ Network resource content structure . 58
B.4.4 KNX™ Group resource content structure (Device) . 59
B.4.5 KNX™ Group resource content structure (Application) . 59
B.4.6 KNX™ Group resource content structure (Interface) . 59
B.4.7 KNX™ Node resource content structure (Device) . 60
B.4.8 KNX™ Node resource content structure (Application) . 61
B.4.9 KNX™ Node resource content structure (Interface) . 61
Annex C: Example of Interworking Using Containers and Subscriptions . 63
C.1 NA/DA Registration to NSCL/DSCL . 64
C.2 Discovery of Announced NA Resource . 64
C.3 NA Creates M2M Container Resource & Announces it to DSCL . 65
C.4 Subscription to "socket1" NSCL Container Resource . 66
C.5 NSCL Sends Notification to SEP2 DA . 67
Annex D: Example of Interworking using aPoC . 69
D.1 GA and DA Registration and Discovery . . 69
D.2 GA and DA Communication via aPoC . 70
D.3 NA and DA Registration and Discovery . . 71
D.4 NA to DA Communication via aPoC . . 73
Annex E: dId interface for limited resource devices . 74
ETSI
5 ETSI TR 102 966 V1.1.1 (2014-02)
E.1 Scope . 74
E.2 dId interface . 74
E.2.1 Interworking Proxy Unit . 75
E.2.1.1 CREATE . 75
E.2.1.2 RETRIEVE . 75
E.2.1.3 UPDATE . 75
E.2.1.4 DELETE . 76
E.2.2 Network . 76
E.2.2.1 CREATE . 76
E.2.2.2 RETRIEVE . 76
E.2.2.3 UPDATE . 77
E.2.2.4 DELETE . 77
E.2.3 Device, Application and Interface . 77
E.2.3.1 CREATE . 77
E.2.3.1.1 Case 1: Define an area network device through a well-known device profile . 77
E.2.3.1.2 Case 2: Define an area network device through a set of well-known device application profiles . 78
E.2.3.1.3 Case 2 (variant) . 79
E.2.3.1.4 Case 3: Define an area network device through a set of well-known interface profiles . 79
E.2.3.1.5 Case 3 (variant) . 81
E.2.3.2 RETRIEVE . 81
E.2.3.3 UPDATE . 82
E.2.3.4 DELETE . 82
E.2.4 Data Field reporting. 82
E.2.4.1 CREATE . 82
E.2.4.2 RETRIEVE . 83
E.2.4.3 UPDATE . 83
E.2.4.4 DELETE . 83
E.2.5 Method retargeting . 83
E.2.5.1 CREATE . 83
E.2.5.1.1 IPU, Network, Device and Application level Methods . 84
E.2.5.2 RETRIEVE . 84
E.2.5.3 UPDATE . 84
E.2.5.4 DELETE . 84
E.2.6 Data Field retargeting . 84
E.2.6.1 CREATE . 84
E.2.6.2 RETRIEVE . 84
E.2.6.3 UPDATE . 85
E.2.6.4 DELETE . 85
E.3 CoV configuration . 85
E.3.1 XML element . 85
E.3.2 XML element . 85
E.3.3 XML element . 86
E.3.3.1 CoV configuration . 86
E.3.4 CoV configuration XML schema . 86
E.3.5 Example . 86
E.4 dId over USB . 87
E.4.1 Base URI . 87
E.4.2 Transport over serial link . 88
E.5 dId over IP . 89
Annex F: Bibliography . 90
History . 91

ETSI
6 ETSI TR 102 966 V1.1.1 (2014-02)
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 Report (TR) has been produced by ETSI Technical Committee Machine-to-Machine communications
(M2M).
ETSI
7 ETSI TR 102 966 V1.1.1 (2014-02)
1 Scope
The present document collects and evaluates implementation profiles for interworking with M2M Area Network
technologies.
An implementation profile is defined, for the purpose of the present document, as the description on how the ETSI
M2M architecture can be used to achieve interworking. Each implementation profile is evaluated against deployment
scenarios and applicable technologies in order to identify the most suitable for the specific conditions.
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
referenced 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.
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 TS 102 921: "Machine-to-Machine communications (M2M); mIa, dIa and mId interfaces".
[i.3] IEEE 802.15.4-2003: "IEEE Standard for Information technology - Telecommunications and
information exchange between systems - Local and metropolitan area networks - Specific
requirements Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY)
Specifications for Low-Rate Wireless Personal Area Networks (LR-WPANs)".
[i.4] CEN EN 13757: "Communication systems for meters and remote reading of meters".
[i.5] CEN EN 13757-3: "Communication systems for and remote reading of meters - Part 3: Dedicated
application layer".
[i.6] ISO 8601:2004: "Data elements and interchange formats -- Information interchange --
Representation of dates and times".
[i.7] IETF RFC 1006: "ISO Transport Service on top of the TCP Version: 3".
[i.8] IETF RFC 5023: "The Atom Publishing Protocol".
[i.9] ISO/IEC 14543-3-10:2012: "Information technology -- Home Electronic Systems (HES) --
Part 3-10: Wireless Short-Packet (WSP) protocol optimized for energy harvesting -- Architecture
and lower layer protocols".
[i.10] OASIS.OBIX_1_1: "OASIS oBix semantic conventions, version 1.1".
ETSI
8 ETSI TR 102 966 V1.1.1 (2014-02)
[i.11] ASHRAE.CSML_1_0: "ASHRAE 135 annex am Control System Modelling Language (CSML)
semantic conventions".
[i.12] IETF RFC 4287: "The Atom Syndication Format".
3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AES Advanced Encryption Standard
AN Area Network
ASHRAE American Society of Heating, Refrigeration, and Air-conditioning Engineers
ATOM XML document format defined in RFC 4287 [i.12]
COV Change Of Value
CSML Control System Modelling Language
DA Device Application
DDNS Dynamic DNS
DHCP Dynamic Host Configuration Protocol
DIF Data Information Field
DIP Device Interworking Proxy
DNS Domain Name System
DPT Data Point Type (KNX™ standard)
DSCL Device Service Capability Layer
GA Gateway Application
GENA General Event Notification Architecture
GIP Gateway Interworking Proxy
GSCL Gateway SCL
HAN Home Area Network
IN INPut
IP Internet Protocol
IPA Interworking Proxy Application
IPU Interworking Proxy Unit
ISO International Standard Organization
KNX™ Konnex protocol maintained by the KNX™ Association
LAN Local Area Network
MAC Medium Access Control (Layer)
MAN M2M Area Network
NA Network Application
NA/DA Network Application/Device Application
NIP Network Interworking Proxy
NSCL Network SCL
OASIS Organization for the Advancement of Structured Information Standards
OUT OUTput
PAN Personal Area Network
PC Personal Computer
PDA Personal Digital Assistant
REST REpresentational State Transfer
RF Radio Frequency
SCL Service Capability Layer
SLIP Serial Line IP
TBD To Be Defined
TC Technical Committee
UCP User/Universal Control Point
UDN Unique Device Name
UDP User Datagram Protocol
URI Uniform Resource Identifier
URL Uniform Resource Locator
USB Universal Serial Bus
UTC Coordinated Universal Time
VIF Value Information Block
ETSI
9 ETSI TR 102 966 V1.1.1 (2014-02)
WAN Wide Area Network
XML Extensible Markup Language ®
ZC ZigBee Coordinator ®
ZCL ZigBee Cluster Library ®
ZED ZigBee End Device ®
ZGD ZigBee Gateway Device ®
ZR ZigBee Router
4 Scenarios for interworking
Interworking is one of the main caracteric of the exploitation of the usage of the ETSI M2M solution. The scenarios for
interworking described in the present document make use of the ETSI TC M2M architecture as shown below. The
interworking makes use of GIP, NIP and DIP capabilities which are seen by the SCLs as specialized applications
dedicated to the semantic data model interworking.
Legacy case 1
d
(out of scope)
D
DA
Networ k
Case 1
Do main
dIa
mId
DSCL
NA
G GA
Legacy case 2 mIa
d
(out of scope)
(*dIa)
dIa
GIP
NIP
D‘
GSCL
mId
dIa
Case 2
DA NSCL
( *opt ionall y dIa)
D‘
dIa
Case 3
DA
mIm
mId
DA
D
(*dIa)
dIa
Legacy case 3 DI P Networ k
d
(out of scope)
Do main
DSCL
NA
mIa
NIP
NSCL
Figure 4.1: Mapping of reference points to different deployment scenarios
5 scenarios for interworking have been identified in the following table, each one applicable to different deployment
context. Guidelines for data model interworking between ETSI M2M and specific area network technologies are
provided in the rest of the present document.
ETSI
10 ETSI TR 102 966 V1.1.1 (2014-02)
Scenario 1: transparent retargeting
Type of device d Notes
Application on device (d, non using Specific technology aware
dIa)
Application on Network Specific technology aware The application is specific for the
interworked technology, A specific
adaptation is needed to use mIa.
Mechanism Interworking at the G/D with simple
retargeting
Security impact Use technology-specific security to the Decryption(/reencryption) required at
Gateway, independently of M2M Gateway, i.e. Gateway acts as
Service layer security Aggregator, to extend Service Layer
security end-to-end.
Leverage on M2M architecture minimum GIP/DIP is an application using
capabilities standard dIa towards the G/DSCL.
Deployment scenario example This interworking scenario is using ETSI M2M as a sort of pipe to carry the
specific protocols, so the level of interaction with the ETSI M2M resource
management capabilities (Access Rights, security, management, etc.) is limited
by visibility on the objects in the interworked technology, but with the relevant
advantage but that interworked protocols are preserved.
One typical scenarios is the deployment of a specific technology on top of a
consolidated ETSI M2M deployment, to leverage of already massively installed
ETSI M2M D/G.
Scenario 2: Retargeting with elements interworking
Type of device d Notes
Application on device (d, non using Specific technology aware
dIa)
Application on Network Specific technology aware The application is specific for the
interworked technology, A specific
adaptation is needed to use mIa.
Mechanism Interworking at the G/D based on GIP/DIP is an application using
retargeting and use of ETSI compliant standard dIa towards the G/DSCL.
resources
Security impact Use technology-specific security to the Decryption(/reencryption) required at
Gateway Gateway, i.e. Gateway acts as
Aggregator, to extend Service Layer
security end-to-end.
Leverage on M2M architecture Yes, level depends on specific
capabilities solutions
Example of applicability This interworking scenario is similar to scenario 1 but is leveraging on the
functionality offered by ETSI M2M by means of a more detailed mapping of
elements (sensors. Actuators, etc) on ETSI M2M resources. It also allows other
applications (e.g. native ETSI M2M application) to interact actively with the
elements of the interworked technology that are stored and manipulated by the
SCLs. Also in this case the interworked protocols are preserved.
One typical scenario is the deployment of a specific technology that leverages
on ETSI M2M for the interaction with the communication system.

ETSI
11 ETSI TR 102 966 V1.1.1 (2014-02)
Scenario 3: Interworking at the Device/Gateway
Type of device d Notes
Application on device (d, non using Specific technology aware
dIa)
Application on Network Independent from Specific technology The application is ETSI M2M native
and independent for the interworked
technology.
Mechanism Full Interworking at the G/D GIP/DIP is an application using
standard dIa towards the G/DSCL.
Security impact May rely on technology-specific Gateway may act according to any of
security over MAN, but interworking the scenarios in clause 6.
with M2M service layer security is
possible
Leverage on M2M architecture Full
capabilities
Example of applicability This interworking scenario is making the network applications independent from
the area network technologies.
One typical scenarios is the case of an application that has to deal with multiple
area network technologies (e.g. in case of long term deployments when the
available technologies are changing), so the interworking is confinated to the
new deployments.
Scenario 4: Native interworking on dIa
Type of device D' Notes
Application on device Independent from Specific technology The application is ETSI M2M native
and independent for the interworked
technology.
Application on Network Independent from Specific technology The application is ETSI M2M native
and independent for the interworked
technology.
Mechanism dIa transport on binding layer between Natively supported in ETSI M2M.
D' and G
Security impact Enables End-to-end encryption to/from Gateway may act according to any of
D' devices the scenarios in clause 6.
Leverage on M2M architecture Full
capabilities
Example of applicability This is the case of a technology supporting HPPT/COAP in case of deployment
of ETSI M2M compliant DA and NA.
It allows a complete independence of applications from area network
technology. Typical.
Scenario 5: Network based interworking
Type of device d Notes
Application on device (d, non using Specific technology aware
dIa)
Application on Network Independent from Specific technology The application is ETSI M2M native
and independent for the interworked
technology.
Mechanism NIP interworking Application needs to be able to handle
encrypted data in containers.
Security impact Use technology-specific security over Limited confidentiality as interworking
MAN may require application-related
information to be exposed in the
service layer.
Leverage on M2M architecture low, level depends on specific
capabilities solutions
Example of applicability This is to interwork with completely specific solutions already deployed without
touching the G/D.
One typical scenario is the introduction of ETSI M2M compliant solution for new
services reusing already deployed legacy D/G.

ETSI
12 ETSI TR 102 966 V1.1.1 (2014-02)
5 Interworking with legacy devices (d)
5.1 Implementation profile 1
5.1.1 Entity-relation representation of the M2M area network
Figure 5.1 provides a resource-entity model that represents an M2M area network as well as its relationship to an
Interworking Proxy Application (IPA).
1 n M2M Area
IPU
Network
n
d device
n
Application
n
Data Field
n
Interface
Method
n
Figure 5.1: Generic entity-relation diagram for an IPU and
an M2M Area Network running legacy d devices
This entity-relation diagram is applicable to the following M2M Area Networks: ®
• ZigBee
• DLMS/COSEM
• Zwave
• BACnet
• ANSI C12
• mBus
5.1.2 Mapping principles
NOTE: The mapping principles proposed in the present document are initial ones, some others may exist.
This clause describes the mapping principles that are used to map a generic M2M Area Network into a structured tree of
ETSI M2M resources in this implementation profile.
ETSI
13 ETSI TR 102 966 V1.1.1 (2014-02)
More specifically, the IPU is responsible to:
• discover the M2M Area Network structure;
• create an ETSI M2M resource structure representing the M2M Area Network structure in the ETSI M2M
Service Capability Layer; and
• manage the ETSI M2M resource structure in case the M2M Area Network structure changes.
In order to facilitate the navigation through the various resources representing the M2M Area Network structure,
created by the IPU, a specific format for the searchString attribute of the resources is used. This specific format is
referred to as a Tag, and it is specified in annex A. These tags help locate M2M Area Network elements modeled as
ETSI M2M resources.
The rules the IPU follows to create the ETSI M2M resource structure are the following:
• The IPU is modeled with an ETSI M2M resource. The "searchString" attribute of this resource
contains an ETSI.ObjectType/ETSI.IP tag which identifies it as an IPU. The URI used to access this
resource has the following format:
/applications/< interworking_proxy_application>
The resource contains an ETSI M2M sub resource. The "searchString" attribute of
this sub resource contains a tag of category ETSI.ObjectSemantic which indicates the semantic conventions
used in the representation of this object. The URI used to access this resource has the following
format:
/applications/< interworking_proxy_application>/containers/descriptor
The resource contains one or more sub resource. The "content" attribute of this
sub resource contains the representation of the IPU. In particular, since a single IPU can give access to
multiple M2M Area Networks, each of them modeled with an ETSI M2M resource (see next bullet for
description), the "content" attribute of the resource may contain the URIs of the ETSI M2M
resources representing these M2M Area Networks. The URI used to access the resource
containing the current representation of the IPU has the following format:
/applications/< interworking_proxy_application>/containers/descriptor/contentInstances/latest
The reason is that a new resource is created each time the IPU representation changes
(e.g. a new M2M Area Network is created, or an old one is deleted). So, in case a new
resource is created and the old ones are kept in order to maintain an history, there can be more than one
resources. But, in any case, the resource pointed by the "latest" attribute
of the contentInstances resource contains always the current representation of the IPU.
• Each M2M Area Network controlled by an IPU is modeled with an ETSI M2M resource. The
"searchString" attribute of this resource contains an ETSI.ObiectType/ETSI.AN_NWK tag which identifies it
as an M2M Area Network. The URI used to access this resource has the following format:
/applications/
The resource contains an ETSI M2M sub resource. The "searchString" attribute of
this sub resource contains a tag of category ETSI.ObjectSemantic which indicates the semantic conventions
used in the representation of this object. The URI used to access this resource has the following
format:
/applications//containers/descriptor
ETSI
14 ETSI TR 102 966 V1.1.1 (2014-02)
The resource contains one or more sub resource. The "content" attribute of this
sub resource contains the representation of the M2M Area Network. In particular, since a single M2M Area
Network can be composed by several Devices (N.B.: they are not ETSI M2M Devices), each of them modeled
with an ETSI M2M resource (see next bullet for description), the "content" attribute of the
resource may contain the URIs of the ETSI M2M resources representing these Devices. The URI used to
access the resource containing the current representation of the M2M Area Network has the
following format:
/applications//containers/descriptor/contentInstances/latest
The reason is that a new resource is created each time the M2M Area Network
representation changes (e.g. a new Device is created, or an old one is deleted). So, in case a new
resource is created and the old ones are kept in order to maintain an history, there can be
more than one resources. But, in any case, the resource pointed by the
"latest" attribute of the contentInstances resource contains always the current representation of the M2M Area
Network.
• Each Device belonging to an M2M Area Network (N.B.: they are not ETSI M2M Devices) is modeled with an
ETSI M2M resource. The "searchString" attribute of this resource contains an
ETSI.ObiectType/ETSI.AN_NODE tag which identifies it as a Device belonging to an M2M Area Network.
The URI used to access this resource has the following format:
/applications/
The resource contains an ETSI M2M sub resource. The "searchString" attribute of
this sub resource contains a tag of category ETSI.ObjectSemantic which indicates the semantic conventions
used in the representation of this object. The URI used to access this resource has the following
format:
/applications//containers/descriptor
The resource contains one or more sub resource. The "content" attribute of this
sub resource contains the representation of the Device. In particular, since a Device can contain several
Applications (N.B.: they are not ETSI M2M Applications), each of them modeled with an ETSI M2M
resource (see next bullet for description), the "content" attribute of the resource may
contain the URIs of the ETSI M2M resources representing these Applications. The URI used to access the
resource containing the current representation of the Device has the following format:
/applications/<
...