Draft ETSI TR 101 531 V<0.1.

3> (2011-01)
Technical Report

Machine- to- Machine communications (M2M);

Reuse of Core network functionality by M2M Service
Capabilities

CAUTION: This DRAFT document is provided for information

and is for future development work within the ETSI
Technical Committee M2M only. ETSI and its Members
accept no liability for any further use/implementation
of this Specification.

Approved and published Specifications and reports for

implementation of the M2M system shall be obtained
exclusively via the ETSI Documentation Service at
http://pda.etsi.org/pda/queryform.asp
 2 Draft ETSI TR 101 531 V<0.1.3> (2011-01)

Reference
<DTR/M2M-00013>

Keywords
<M2M, Network, Service>

ETSI

650 Route des Lucioles

F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

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 2011.

All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.

ETSI
 3 Draft ETSI TR 101 531 V<0.1.3> (2011-01)

Contents
Contents ..............................................................................................................................................................3
Intellectual Property Rights ................................................................................................................................4
Foreword.............................................................................................................................................................4
Introduction ........................................................................................................................................................4
1 Scope ........................................................................................................................................................5
2 References ................................................................................................................................................5
2.1 Normative references ......................................................................................................................................... 5
3 Definitions, and abbreviations ..................................................................................................................6
3.1 Definitions .......................................................................................................................................................... 6
Definition format ................................................................................................................................................................. 7
3.3 Abbreviations ..................................................................................................................................................... 7
Abbreviation format ............................................................................................................................................................ 7
4. Architectural Frameowork and Reference Points.....................................................................................7
4.1 Reference Architecture ....................................................................................................................................... 7
4.1.1 Refence Architecture for Interworking with XDMS..................................................................................... 7
4.1.2 OMA-DM/BBF-TR069 Integration ............................................................................................................ 11
4.2 Reference Points .............................................................................................................................................. 12
5. Delegation of M2M Service Capabilities ...............................................................................................14
5.1 Application Usage of XDMS for Management of M2M Service Capabilities Resources................................ 14
5.1.1 High level Principles ................................................................................................................................... 14
5.1.1. 1 M2M Service Capabilities Application Usages .................................................................................................... 14
5.1.1.2 Mapping between XDMS and M2M Service Capability AS ................................................................................ 16
5.1.2 Management of Device/Gateway SCL resources ....................................................................................... 17
5.1.3 Management of device/gateway Application resources .............................................................................. 17
5.1.4 Management of Network Application resources......................................................................................... 17
5.1.5 Management of Access Right Resources ................................................................................................... 17
5.1.6 Managament of Group Resources ............................................................................................................... 17
6 M2M Service Capabilities Procedures ............................................................................................................. 17
6.1.1 Service Bootstrap ........................................................................................................................................ 17
6.1.2 Registration Procedure ................................................................................................................................ 17
6.1.3 Secure Communication ............................................................................................................................... 17
6.1.4 M2M Service Capability Discovery Procedure .......................................................................................... 17
6.1.5 Group Communication Procedure .............................................................................................................. 17
6.1.6 Subscription Procedure ............................................................................................................................... 17
6.1.7 Reading and Writing Procedures ................................................................................................................ 17
6.1.8 Remote Entity Management Procedures ..................................................................................................... 17
7. Telco Operator Exposure (TOE) Related Procedures ............................................................................18
7.1 Location Procedure........................................................................................................................................... 18
7.2 SMS Procedure ................................................................................................................................................. 18
7.3 MMS Procedure ............................................................................................................................................... 18
7.4 Voice Call Procedure........................................................................................................................................ 18
7.5 Presence Procedure........................................................................................................................................... 18
Proforma copyright release text block ..............................................................................................................18
A.1 First clause of the annex .........................................................................................................................18
A.1.1 First subdivided clause of the annex................................................................................................................. 18
History ..............................................................................................................................................................20
History box entries ............................................................................................................................................................ 20

ETSI
 4 Draft ETSI TR 101 531 V<0.1.3> (2011-01)

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://webapp.etsi.org/IPR/home.asp).

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|ETSI Project|<other>} <long techbody>
(<short techbody>).

Introduction
This clause is optional. If it exists, it is always the third unnumbered clause.

ETSI
 5 Draft ETSI TR 101 531 V<0.1.3> (2011-01)

1 Scope
The present document describes the ways in which M2M Service Capabilities can delegate aspects of its functionalities
to existing underlying core network functionality. Leveraging existing deployed standard core network functionality to
fulfil M2M Service Capabilities functionality is particularly attractive for incumbent service providers who have
already deployed networks and intend to offer M2M services.

There is no restriction on which core network functionality can be used to fulfil a role as long as it can fulfil the
intended role without any changes to its functionality nor to its standard interfaces

The report will document supported M2M Service Capabilities on a per procedure basis as defined in the mIa and mID
interfaces versus the corresponding core network functionality(ies) that can fulfil the role for the procedure, and the
manner in which that role is fulfilled. This ensures successful interworking in a multi-vendor environment.

In addition to the delegation aspect described above, this document describes how M2M Service Capabilities interwork
with core network nodes to fulfil tasks required, but are not directly related, to defined procedures on the mIa and mId
interfaces.

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.

ETSI
 6 Draft ETSI TR 101 531 V<0.1.3> (2011-01)

The following referenced documents are required for the application of the present document:

[1] ETSI TR 102 725: " Machine to Machine Communications (M2M); Definitions".
The acronyms and the abbreviations defined in TR 102 725 and used inside this document (TS 102
690) are normative by means of this reference.

[2] ETSI TS 102 xxx: " Machine to Machine Communications (M2M); mIa, mId, dIa Interfaces".

[3] 3GPP TS 23.002: "3rd Generation Partnership Project; Technical Specification Group Services
and Systems Aspects; Network architecture".

[4] 3GPP TS 33.220: "3rd Generation Partnership Project; Technical Specification Group Services
and System Aspects; Generic Authentication Architecture (GAA); Generic bootstrapping
architecture".

[5] OMA-ERELD-XDM-V2_1: "Enabler Release Definition for XML Document Management".

[6] 3GPP TS 29.229: "3rd Generation Partnership Project; Technical Specification Group Core
Network and Terminals; Cx and Dx interfaces based on the Diameter protocol; Protocol details"

[7] 3GPP TS 29.329: "3rd Generation Partnership Project; Technical Specification Group Core
Network and Terminals; Sh Interface based on the Diameter protocol; Protocol details".

[8] 3GPP TS 29.214: "3rd Generation Partnership Project; Technical Specification Group Core
Network and Terminals; Policy and Charging Control over Rx reference point".

[9] 3GPP TS 32.299: "3rd Generation Partnership Project; Technical Specification Group Services
and System Aspects; Telecommunication management; Charging management; Diameter charging
applications".

[10] 3GPP TS 23.271: "3rd Generation Partnership Project; Technical Specification Group Services
and System Aspects; Functional stage 2 description of Location Services (LCS)".

[11] OMA-AD-DM-V1_3: “Device Management Architecture, Version 1.3”

[12] OMA-TS-DM_Notification-V1_3: “OMA Device Management Notification Initiated Session,

Version 1.3”

[13] OMA-TS-DM-Protocol-V1_3: “OMA Device Management Protocol, Version 1.3”

[14] OMA-TS-DM_Sessionless-V1_3: “OMA Device Management Sessionless Message, Version 1.3”

[15] OMA-TS-DM_TNDS-V1_3: “OMA Device Management Tree and Description Serialization,

Version 1.3”

[16] ETSI TS 102 690: “M2M Functional Architecture”

[17] ETSI TS 102 921: “M2M mIa, dIa and mId interfaces”

[18] Broadband Forum “TR-069 Amendment 3 CPE WAN Management Protocol”

http://www.broadband-forum.org/technical/download/TR-069_Amendment-3.pdf

[19] Broadband Forum “TR-181 Device Data Model for TR-069”, Issue 2, Issue Date: May 2010.
http://www.broadband-forum.org/technical/download/TR-181_Issue-2.pdf

3 Definitions, and abbreviations

Delete from the above heading those words which are not applicable.

Definitions and abbreviations extracted from ETSI deliverables can be useful when drafting documents and can be
consulted via the Terms and Definitions Interactive Database (TEDDI) (http://webapp.etsi.org/Teddi/).

3.1 Definitions

ETSI
 7 Draft ETSI TR 101 531 V<0.1.3> (2011-01)

Clause numbering depends on applicability.

• A definition shall not take the form of, or contain, a requirement.

• The form of a definition shall be such that it can replace the term in context. Additional information
shall be given only in the form of examples or notes (see below).

• The terms and definitions shall be presented in alphabetical order.

For the purposes of the present document, the [following] terms and definitions [given in ... and the following] apply:

Definition format
<defined term>: <definition>

example 1: text used to clarify abstract rules by applying them literally

NOTE: This may contain additional information.

3.3 Abbreviations
Abbreviations should be ordered alphabetically.

Clause numbering depends on applicability.

For the purposes of the present document, the [following] abbreviations [given in ... and the following] apply:

Abbreviation format
<ACRONYM1> <Explanation>
<ACRONYM2> <Explanation>
<ACRONYM3> <Explanation>

4. Architectural Framework and Reference Points

4.1 Reference Architecture

4.1.1 Reference Architecture for Interworking with XDMS
There are two potential options for interworking between an M2M Service Capability Application Server and XDMS
for the purpose of supporting the management of M2M SC resources . Below is a brief description of each option
including the architectural impacts.

4.1.1.1 Option1: M2M SCL and Core network Nodes owned by different Providers
Figure 1 below shows the architecture for option 1.

In this option, the provider of the M2M SCL is independent from the provider of the core network nodes which include
HSS, XDMS and the Aggregation Proxy depicted in Figure 4.1.1-1.

ETSI
 8 Draft ETSI TR 101 531 V<0.1.3> (2011-01)

M2M Applications

mIa
M2M Service Capabilities
XDMS
M2M Device Domain NAE
NSEC11
NSEC
1
M2M Applications NRAR
NHDR
dIa XDM-4
Routing
NCB function
M2M NTOE
Service XDM-11
Capabilities NCS NTM TLS per user Aggregation
mId Proxy
NGC TLS per user

Communication modules Zh, Zh++

Core Network Connection

Notes:
•Aggregation proxy includes
HSS
M2M Gateway
Authentication proxy
M2M Applications Core Network A Core Network B
•Zh currently supports UICC-
dIa/Internal
based authentication
M2M
Service
Capabilities
•3GPP is currently studying
non-UICC based
M2M Devices
authentication schemes
Communication modules
•Zh++ supports UICC and non-
UICC based authentication
schemes

Figure 4.1.1-1 : Option 1 - interworking XDMS- M2M SCL for different service providers

Notes:

1- Denotes an XDM agent implemented in NRAR and NSEC. Note that typically there would be 1 XDM
agent per M2M SCL

In option 1, the Aggregation proxy is the node of interaction between the 2 providers. The aggregation proxy includes
an embedded authentication proxy which performs the authentication for user (device application/network
application/SCL) requests arriving to the M2M SC. User authentication is performed against user credentials stored in
HSS.

Every request arriving to the M2M SCL and that requires a creation/retrieval/update/deletion of a resource, results in an
equivalent XCAP request created by the XDM agent towards the Aggregation Proxy.

The M2M SCL establishes a separate TLS tunnel for every distinct user prior to exchanging any user traffic with the
Aggregation Proxy. The TLS tunnel establishes mutual authentication between the M2M SCL and the aggregation
proxy and is bound to the user. The TLS tunnel eliminates the need to authenticate the user for every request. This is
however the M2M SCL provider policy choice and a user can be authenticated for every request. Typically, the user is
authenticated when the TLS is established and need not be authenticated for subsequent transactions as long as there is a
TLS tunnel bound to the user. An M2M SCL provider may choose to tear down the TLS tunnel once a transaction is
completed to force authentication for every user initiated request.

The duration of the TLS tunnel for a user session is subject to policies for either the M2M SCL or the aggregation
proxy. Certain events can also lead to the tearing down of a user TLS tunnel such as the de-registration of the user.
Either node can tear town the TLS tunnel.

Once a user is successfully authenticated for an incoming request, the equivalent XCAP request is forwarded to the
XDMS for further processing.

Figure 4.1.1-2 below shows a high level call flow for an exemplary case for illustrative purposes:

ETSI
 9 Draft ETSI TR 101 531 V<0.1.3> (2011-01)

Aggregation
User M2M SCL proxy HSS XDMS
NRAR/NEC XDM Agent

1. mId/mIa/dIa Create resource

2. Establish TLS for user if

one does not exist
3. XCAP Create resource

4. Authenticate User if TLS

established for the first time
for user
5. XCAP Create resource

7. Response 6. Response
8. Response

Figure 4.1.1-2 : Option 1 Example

The following is a brief description steps in the call flow:

1- In step 1 a user initiates a creation request for a new resource to its local SCL.
2- The local /hosting SCL verifies is there is an existing TLS tunnel bound to the user. If none is found, the Local
SCL establishes a TLS tunnel towards the aggregation proxy for the user.
3- Once the tunnel is successfully established the XDM agent creates the XCAP request equivalent to the
incoming user request and forwards it to the aggregation proxy.
4- The aggregation proxy performs user authentication first against user credentials stored in HSS, if the TLS for
the user was just established.
5- Once the user is successfully authenticated, the aggregation proxy forwards the request to the XDMS
6- XDMS sends back the response to the aggregation proxy
7- The aggregation proxy forwards the response to the Local SCL (XDM agent)
8- The locals SCL returns the response to the user
4.1.1.2 Option2: M2M SCL and Core network Nodes owned by the same Provider
Figure 4.1.1-3 below shows the architecture for option 2.

In this option, the provider of the M2M SCL is the same provider of the core network nodes which include HSS, and
XDMS depicted in Figure 3.

Note that this option equally applies to the case when the MSM SCL and the core network provider are independent but
have an agreement that allows such an architecture to be deployed

ETSI
 10 Draft ETSI TR 101 531 V<0.1.3> (2011-01)

M2M Applications

mIa
M2M Service Capabilities

M2M Device Domain NAE

NSEC1 XDM-14 XDMS
M2M Applications NRAR1
NHDR
dIa/Internal
Routing
NCB
function
M2M NTOE
Service
Capabilities NCS NTM
mId
NGC

Communication modules
Zh, Zh++
Core Network Connection

M2M Gateway Notes:

HSS
M2M Applications
Core Network B
•In this option the
Core Network A
dIa/Internal authentication proxy is
M2M
Service
basically embedded in
Capabilities
the XDM agent
M2M Devices
Communication modules

Figure 4.1.1-3 : Option 2 - interworking XDMS- M2M SCL for same service providers

Notes:

1 Denotes an XDM agent implemented in NRAR and NSEC.

Option 2 does not include an aggregation proxy. Rather, the XMD agent includes an embedded authentication proxy
which performs the authentication for every user (device application/network application/SCL) request arriving to the
M2M SCL.

Every request arriving to the M2M SCL and that requires a creation/retrieval/update/deletion of a resource, results in an
equivalent XCAP request from the XDM agent towards the XDMS.

The XDM agent in the M2M SCL authenticates every user request requiring access to a resource. The authentication is
performed against user credentials stored in HSS.

Once a user is successfully authenticated for an incoming request, the XDM agent creates an equivalent XCAP request
towards XDMS for further processing

Figure 4.1.1-4 below shows a high level call flow for an exemplary case for illustrative purposes:

ETSI
 11 Draft ETSI TR 101 531 V<0.1.3> (2011-01)

User M2M SCL HSS XDMS

NRAR/NEC XDM Agent

1. mId/mIa/dIa Create resource

2. Authenticate User

3. XCAP Create resource

4. Response
5. Response

Figure 4.1.1-4 : Option 2 Example

The following is a brief description steps in the call flow:

1- In step 1 a user initiates a creation request for a new resource to its local SCL.
2- The local /hosting SCL authenticates the user against user credentials stored in HSS.
3- Once the user is successfully authenticated, the XDM agent creates the XCAP request equivalent to the user
request and forwards it to the XDMS
4- XDMS sends back the response to the Local SCL (XDM agent)
5- The locals SCL returns the response to the user

4.1.2 OMA-DM/BBF-TR069 Integration

M2M Applications

M2M Device/Gateway mIa

M2M Service Capabilities

M2M Applications
SC1

dIa SC8 SC2

M2M Service
Capabilities Routing
SC7 SC3
function
D/GREM
NREM
Device Mgmt
Device Mgmt interface Device Mgmt SC4
Client Server

SC5
mId
Core Network Connection
Communication modules
Core Network A Core Network B

ETSI
 12 Draft ETSI TR 101 531 V<0.1.3> (2011-01)

Figure 4.1.2-1 Integration of device management enablers for M2M Remote Entity Management

In this option, the Device Management Client is integrated as a part of the D/GREM Service Capability, while the
Device Management Server is integrated as a part of the NREM Service Capability.

• If OMA-DM is re-used for remote entity management then:

o Device Management Client refers to an OMA-DM DM Client and
o Device Management Server refers to an OMA-DM DM Server
o Device Management interface refers to DM-1 and DM-2 as defined in [11].

• If BBF TR-069 is re-used for remote entity management then:

o Device Management Client refers to a CPE and
o Device Management Server refers to an ACS
o Device Management interface refers to TR-069 CWMP as defined in [18].

On the Device and Gateway side:

The D/GREM may collect the Management Object data from the Device Management Client in the local M2M
Device/Gateway via an internal interface, and may create/update the corresponding mgmtObj resource(s) in the N-
SCL via the mId reference point using the RESTful access methods as described in ETSI M2M TS 102 690 [16] and
TS 102 921 [17].

Alternatively, the mgmtObj resource may be created by administrative means in the N-SCL.

Any device management activity (e.g. firmware update, fault management) in the Device/Gateway is carried out by
the Device Management Client, communicating with a Device Management Server in NREM via existing device
management interfaces.

The GREM is also responsible for the management of the D’-type devices associated with the M2M Gateway. The
Management Object data of the D’-type device is a part of the Management Object data of the M2M Gateway. The
interactions between the GREM and the D’-type device for device management purpose is out of scope.

On the Network side:

NREM triggers OMA-DM [11] or BBF-TR069 [18] Device Management procedures over mId resulting from actions
on the mgmtObj resources by M2M Network Applications via mIa or by M2M Management Functions.

Note: Alternatively to Device Management Server being integrated as a part of the NREM a Device Management
Server may be external to NREM but interface with NREM via an implementation-specific interface exposed by the
Device Management Server.

Editor’s note: The text below need to be further checked.

mgmtObj resource represent either

• high-level management functionalities (e.g. ETSI M2M specific data model) which shall be supported by the
underlying Management Object(s) on the remote entity.
or

• low-level functionalities on the remote entity mapped from the data model as specified by existing device
management technologies (e.g. OMA-DM, BBF-TR069).

4.2 Reference Points

The following is a brief overview of the purpose of the reference points:

Zh reference point: The Zh is an intra-operator interface. The protocol is based on Diameter as specified in 3GPP TS
33.220 [4].

Zh++ reference point: The Zh ++ reference point is an extension of the Zh reference point to support Digest-based
authentication schemes. The extensions are currently proprietary but there is ongoing work in 3GPP to support such a

ETSI
 13 Draft ETSI TR 101 531 V<0.1.3> (2011-01)

scheme at which point reference shall be made to the standardized reference point. Given that this is an intra-operator
interface no interoperability issues is foreseen.

XDM-11: The XDM-11 Reference Point supports the communication between the XDM Agent and the Aggregation
Proxy. The protocol for the XDM-11 Reference Point is XCAP and XDCP.

The XDM-11 Reference Point provides the following functions:

• Management of XDM Resources (e.g. create, modify, retrieve, delete) handled by any XDMS in any network.
XDM-14: The XDM-14 Reference Point provides the following functions:

• Management of XDM Resources (e.g. create, modify, retrieve, delete) handled by a particular XDMS residing
in the same network as the XDM Agent;

• Forwarding of XDM Resources handled by a particular XDMS residing in the same network as the XDM
Agent.
XDM-4: The XMD-4 Reference Point provides the following functions:

• Management of XDM Resources (e.g. create, modify, retrieve, delete, restore) handled by a particular XDMS;

• History Information management for XDM Documents (e.g. retrieve the History information related to an
XDM Document);

• Forwarding of XDM Resources handled by a particular XDMS;

• Access Permissions management for XDM Documents handled by a particular XDMS;

• History function related preferences management (e.g. enable/disable History function) for XDM Documents
handled by particular XDMS;

• Management (e.g. create, modify, retrieve, delete, restore) of XDM Resources requested by an XDMS but
handled by any other XDMS.
mId:

Editor’s Note: The text below need to be further checked.

This reference point shall support the RESTful interface as defined in ETSI M2M TS 102 690 [16] and TS 102 921
[17], which allows the D/GREM to create mgmtObj resources in the NREM for the purpose of the remote entity
management thereafter.

If OMA-DM technology is re-used for the M2M remote entity management, this reference point shall also support DM-
1 and DM-2 interfaces as defined in [11].

• DM-1 provides an interface over which DM Server in the M2M Core may send device management
notification to DM Client on the M2M Device/Gateway to trigger the initiation of a DM session. See details in
[11]. The protocol communicated over this interface is DM Notification [12].

• DM-2 provides an interface over which DM Server in the M2M Core may send device management
commands to DM Client on the M2M Device/Gateway and DM Client may return status and alerts to DM
Server. See details in [11]. The protocol communicated over this interface can be DM session [13] or
sessionless messages [14].

If TR-069 technology is reused for the M2M remote entity management, this reference point shall also support TR-069
CWMP interfaces as defined in [18].

• TR-069 CWMP provides an interface over which TR-069 ACS Server in the M2M Core may send device
management notification to TR-069 CPE on the M2M Device/Gateway and CPE may return status and alerts
to ACS Server. See details in [18]. The protocol communicated over this interface is the CPE WAN
Management Protocol (CWMP).

ETSI
 14 Draft ETSI TR 101 531 V<0.1.3> (2011-01)

5. Delegation of M2M Service Capabilities

This sections describes the M2M Service capabilities whose roles can be delegated to core network functionalities.

5.1 Application Usage of XDMS for Management of M2M

Service Capabilities Resources
5.1.1 High level Principles
Given that an M2M service provider has several independent entities (clients) and different business agreements with
different entities that require complete privacy, the following directory scheme shown below shall be applied. In this
scheme, the following can be noted:

- Every independent entity shall have a different tree under the XCAP-root and where its resources are stored
under the appropriate application usages. This ensures complete privacy and simplifies the entire XDMS
operation.
- Application usages common to all entities shall be defined immediately under the XCAP-root. (e.g. AUIDn in
the figure below)
- All entities share the same Application usages (e.g. AUIDm, AUID1 in the figure below)
- OMA defined Application usages shall retain their location in the M2M directory scheme. In other words,
xcap-caps AUID shall be located immediately beneath the XCAP root. The same applies to the
oma.openmpobilealliance.xcap-directory AUID, which shall be located immediately beneath the XCAP root.

The figure below shows a high level overview of the above principles

XCAP-Root

<SCLBase1>
Entity 1 <SCLBase2> Org.openmobileallia AUIDn xcaps-cap
nce.xcap-directory

AUID1 AUIDm AUID1 AUIDm

users global users global

User1 Userz Usera Userb

Document Document Document Document

Figure 5.1.1-1: XDMS Framework for M2M

5.1.1. 1 M2M Service Capabilities Application Usages

The two figures below show the proposed directory structure for the M2M resources.

ETSI
 15 Draft ETSI TR 101 531 V<0.1.3> (2011-01)

XCAP-Root

SCLBase

org.ETSI.M2M-
org.ETSI.M2M- org.ETSI.M2M- org.ETSI.M2M- org.ETSI.M2M- org.ETSI.M2M-
Registered- org.ETSI.M2
Groups SCL-Remote- SCL-Local- Containers Access-Rights
SCLs M-SCLbase
Applications Applications

Maps to <scls>
Global Maps to
users information under users
users
<sclbase> root
<accessRight>
<group> <applicationAnnc>
users Includes *ALL*
Includes *ALL* Access Rights
groups created created by an
locally by
global application or
application, or <container> by a remote
by a remote a M2M entity
M2M entity.
users Includes *ALL* containers
users global created by an a local
application or a remote
M2M entity.

<SCL> <application>

Figure 5.1.1-2:Part 1: Overall Directory Structure

XCAP-Root

SCLBase

org.ETSI.M2M-
org.ETSI.M2M- org.ETSI.M2M-
org.ETSI.M2M- AccessRight-
Application- Container-
Group-Collections Collections
Collections Collections

users users users users

<GroupCollection> <Appplicationcollection> <ContainerCollection> <ARcolllection>

Figure 5.1.1-3: Part 2- Overall Directory Structure

Eleven Application Usages are identified for managing M2M resources. They are as follows:-

- Access Right Application Usage defined under the sclbase tree. This Application Usage handles the
management of M2M access rights resources created under the sclbase.

ETSI
 16 Draft ETSI TR 101 531 V<0.1.3> (2011-01)

- Group Application Usage defined under the sclbase tree. This Application Usage handles the management of
M2M group resources created under the sclbase tree.

- Container Application Usage defined under the sclbase tree. This Application Usage handles the management
of M2M container resources created under the sclbase tree

- The Registered SCL (remote gateways/devices) Application Usage defined under the sclbase tree. This
Application Usage handles the management of M2M SLCs (registered SCLs) created under the sclbase tree.

- Registered M2M Applications Application Usage defined under the sclbase tree. This Application Usage
handles the management of M2M applications created under the sclbase tree.

- Announced Applications (Remotely registered M2M Applications) Application Usage defined under the
sclbase tree. This Application Usage handles the management of M2M announced applications resources
created under the sclbase tree.

- Container Collection Application Usage defined under the sclbase tree. This Application Usage handles the
management of M2M container collection resources, including announced containers resources, created under
the sclbase tree.

- Group Collection Application Usage defined under the sclbase tree. This Application Usage handles the
management of M2M group collection resources, including announced groups resources, created under the
sclbase tree.

- Access Rights Collection Application Usage defined under the sclbase tree. This Application Usage handles
the management of M2M access rights collection resources, including announced access rights resources,
created under the sclbase tree.

- Application Collection Application Usage defined under the sclbase tree. This Application Usage handles the
management of M2M application collection resources, including announced applications resources, created
under the sclbase tree.

- M2M SCL base Application usage defined under the leg e tree. This Application Usage handles the
management of all M2M resources created under the sclbase tree.

Note that in all Application Usages dealing with Collections, notably the last four, none of the referenced resources
included in any collection are referenced more than once. It is the responsibility of the M2M SC to enforce this
restriction.

5.1.1.2 Mapping between XDMS and M2M Service Capability AS

There is a one to one mapping between every XCAP URI used in XDMS and HTTP URI used over the mId and mIa
interfaces. The mapping is maintained in the M2M Service Capability AS.

Initially the XCAP root is provisioned in the M2M AS, or discovered through defined XDMS procedures. Following
that, and through the application usage, the M2M Service Capability AS creates the necessary XCAP URIs for storing
an XML document in the XCAP directory and maintains a mapping between that XCAP URI and the equivalent HTTP
URI for the XML document.

The mappings will be further described in the various application usages that govern the M2M application

ETSI
 17 Draft ETSI TR 101 531 V<0.1.3> (2011-01)

5.1.2 Management of Device/Gateway SCL resources

5.1.3 Management of device/gateway Application resources

5.1.4 Management of Network Application resources

5.1.5 Management of Access Right Resources

5.1.6 Management of Group Resources

6 M2M Service Capabilities Procedures

6.1.1 Service Bootstrap

6.1.2 Registration Procedure

6.1.2.1 M2M Device Registration

6.1.2.2 M2M Gateway Registration

6.1.2.3 Application Registration

6.1.3 Secure Communication

6.1.4 M2M Service Capability Discovery Procedure

6.1.5 Group Communication Procedure

6.1.6 Subscription Procedure

6.1.7 Reading and Writing Procedures

6.1.8 Remote Entity Management Procedures

ETSI
 18 Draft ETSI TR 101 531 V<0.1.3> (2011-01)

7. Telco Operator Exposure (TOE) Related Procedures

7.1 Location Procedure

7.2 SMS Procedure

7.3 MMS Procedure

7.4 Voice Call Procedure

7.5 Presence Procedure

ETSI
 19 Draft ETSI TR 101 531 V<0.1.3> (2011-01)

History
Document history
V0.0.0 October 2010 Template

V0.0.1 October 2010 First draft

V.0.1.1 December 2010 Included M2M-XDMS interwork architecture for two business models. First
model, where the M2M SP owns the core network, and the second model where
the 2 providers are different

V.0.1.2 January 2011 Included the XDMS M2M overall Application Usage architecture, and Device
Management architecture

V.0.1.3 January 2011 Minor editorial updates by the M2M support team

ETSI