ETSI TR 118 524 V2.0.0 (2016-09)

TECHNICAL REPORT
oneM2M;
3GPP Release 13 Interworking
(oneM2M TR-0024 version 2.0.0)

oneM2M TR-0024 version 2.0.0 2 ETSI TR 118 524 V2.0.0 (2016-09)

Reference
DTR/oneM2M-000024
Keywords
interworking, IoT, M2M
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
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (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
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2016.
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
oneM2M TR-0024 version 2.0.0 3 ETSI TR 118 524 V2.0.0 (2016-09)
Contents
Intellectual Property Rights . 5
Foreword . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.3 Abbreviations . 7
4 Conventions . 7
5 Introduction to 3GPP Service Capability Exposure . 7
5.1 oneM2M Underlying Network related requirements. 7
5.2 3GPP Release 13 MTC features . 8
5.3 3GPP architecture for Service Capability Exposure . 9
5.4 OMA API Program . 10
5.4.1 Overview . 10
5.4.2 OMA work to be considered by oneM2M for 3GPP IWK . 10
5.4.2.1 OMA Service Exposure Framework (ServiceExposure). 10
5.4.2.2 OMA Exposing Network Capabilities to M2M (ENCap-M) . 10
6 Reference architecture . 10
7 Potential impact for interworking with oneM2M . 11
8 Potential solutions for interworking with oneM2M . 12
8.1 Interworking Architecture with a 3GPP underlying network . 12
8.1.1 Exclusive Support through 3GPP Reference Points . 12
8.1.2 Exclusive Support through OMA API . 12
8.1.3 Hybrid Mode . 13
8.2 Configuration of Device Triggering Recall/Replace . 13
8.2.1 Description . 13
8.2.2 3GPP Release-13 MTC procedure . 14
8.2.3 3GPP Parameters . 15
8.2.4 Solution(s). 15
8.2.4.1 Solution1 . 15
8.2.4.1.1 Proposed resource types and attributes . 15
8.2.4.1.2 Proposed Flow(s) . 16
8.3 Configuration of Traffic Patterns . 17
8.3.1 Description . 17
8.3.2 3GPP Release-13 MTC Procedure . 18
8.3.3 3GPP Parameters . 19
8.3.4 Solution(s). 20
8.3.4.1 Solution1 . 20
8.3.4.1.1 Proposed resource types and attributes . 20
8.3.4.1.2 Proposed Flow . 23
8.4 Configuration of Background Data Transfers . 25
8.4.1 Description . 25
8.4.2 3GPP Release-13 MTC procedure . 26
8.4.3 3GPP Parameters . 27
8.4.4 Solution(s). 28
8.4.4.1 Solution1 . 28
8.4.4.1.1 Proposed resource types and attributes . 28
8.4.4.1.2 Proposed Flow(s) . 30
8.5 Support for Group Messaging . 32
8.5.1 Description . 32
ETSI
oneM2M TR-0024 version 2.0.0 4 ETSI TR 118 524 V2.0.0 (2016-09)
8.5.2 3GPP Release-13 MTC procedure . 32
8.5.3 3GPP Parameters . 36
8.5.4 Solution(s). 37
8.5.4.1 Solution1 . 37
8.5.4.1.1 Overview . 37
8.5.4.1.2 Proposed resource types and attributes . 37
8.5.4.1.3 Proposed Flow(s) . 39
8.6 Support for Network status report . 41
8.6.1 Description . 41
8.6.2 3GPP Release-13 MTC procedure . 42
8.6.2.1 Request procedure for one-time or continuous reporting of network status. 42
8.6.2.2 Report procedure for continuous reporting of network status . 43
8.6.2.3 Removal procedure for continuous reporting of network status . 44
8.6.3 3GPP Parameters . 45
8.6.4 Solution(s). 45
8.6.4.1 Solution1 . 45
8.6.4.1.1 Proposed resource types and attributes . 45
8.6.4.1.2 Proposed Flow(s) . 47
History . 50

ETSI
oneM2M TR-0024 version 2.0.0 5 ETSI TR 118 524 V2.0.0 (2016-09)
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 (https://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 Partnership Project oneM2M (oneM2M).
ETSI
oneM2M TR-0024 version 2.0.0 6 ETSI TR 118 524 V2.0.0 (2016-09)
1 Scope
The present document is a study of interworking between oneM2M Architecture and 3GPP Rel-13 architecture for
Service Capability Exposure as defined in the release 13 version of ETSI TS 123 682 [i.5]. The key objective and value
is analyzed and described. The document also investigates the potential solution in oneM2M by evaluating the existing
technical solutions.
2 References
2.1 Normative 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
https://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.
The following referenced documents are necessary for the application of the present document.
Not applicable.
2.2 Informative 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.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
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] oneM2M Drafting Rules.
NOTE: Available at http://www.onem2m.org/images/files/oneM2M-Drafting-Rules.pdf.
[i.2] ETSI TS 118 102: "oneM2M; Requirements (oneM2M TS-0002)".
[i.3] ETSI TS 122 101: "Service aspects; Service principles (3GPP TS 22.101 Release 13)".
[i.4] ETSI TS 122 115: "Service aspects; Charging and billing (3GPP TS 22.115 Release 13)".
[i.5] ETSI TS 123 682: "Architecture enhancements to facilitate communications with packet data
networks and applications (3GPP TS 23.682 Release 13)".
[i.6] OMA API Inventory.
NOTE: Available at http://technical.openmobilealliance.org/Technical/technical-information/oma-api-program.
[i.7] OMA Service Exposure Framework.
NOTE: Available at http://member.openmobilealliance.org/ftp/Public_documents/ARCH/ServiceExposure.
[i.8] OMA Exposing Network Capabilities to M2M.
NOTE: Available at http://member.openmobilealliance.org/ftp/Public_documents/ARCH/ENCap-M2M.
ETSI
oneM2M TR-0024 version 2.0.0 7 ETSI TR 118 524 V2.0.0 (2016-09)
[i.9] ETSI TS 118 101: "oneM2M; Functional Architecture (oneM2M TS-0001)".
[i.10] ETSI TS 129 336: "Home Subscriber Server (HSS) diameter interfaces for interworking with
packet data networks and applications (3GPP TS 29.336 Release 13)".
[i.11] ETSI TS 123 203: "Policy and charging control architecture (3GPP TS 23.203 Release 13)".
[i.12] ETSI TS 122 368: "Service requirements for Machine-Type Communications (MTC); Stage 1
(3GPP TS 22.368)".
[i.13] ETSI TS 126 346: "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs
(3GPP TS 26.346)".
[i.14] ETSI TS 123 468: "Group Communication System Enablers for LTE (GCSE_LTE); Stage 2
(3GPP TS 23.468)".
[i.15] ETSI TS 123 246: "Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional
description (3GPP TS 23.246)".
[i.16] ETSI TS 118 111: "oneM2M; Common Terminology (oneM2M TS-0011)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ETSI TS 118 111 [i.16] apply.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI TS 118 111 [i.16] apply.
4 Conventions
The keywords "Shall", "Shall not", "May", "Need not", "Should", "Should not" in the present document are to be
interpreted as described in the oneM2M Drafting Rules [i.1].
5 Introduction to 3GPP Service Capability Exposure
5.1 oneM2M Underlying Network related requirements
Following requirements are defined in ETSI TS 118 102 [i.2], but not implemented or partially implemented in
release 1.
Most of these requirements except OSR-052 can be achieved through the 3GPP features addressed in the subsequent
sections, with and without support by OMA API.
OSR-006: The oneM2M System should be able to reuse the services offered by Underlying Networks to M2M
Applications and/or M2M Services by means of open access models (e.g. OMA, GSMA OneAPI framework).Examples
of available services are:
• IP Multimedia communications.
• Messaging.
• Location.
ETSI
oneM2M TR-0024 version 2.0.0 8 ETSI TR 118 524 V2.0.0 (2016-09)
• Charging and billing services, including sponsoring data flows.
• Device information and profiles, including configuring expected communication patterns.
• Configuration and management of devices.
• Triggering, monitoring of devices.
• Small data transmission.
• Group management and group messaging.
• Configuring QoS.
• Receiving Reports about the condition of the uderlying network.
• Partially implemented in Rel-1 (see note 1).
NOTE 1: Rel-1 covers: Location, Charging and billing services, Configuration and management of devices, Device
information and profiles, Triggering.
OSR-045a: The oneM2M System should be able to receive and utilize information provided by the Underlying
Network about when an M2M Device can be reached.
• Not implemented in Rel-1.
OSR-051: Depending on availability of suitable interfaces provided by the Underlying Network the oneM2M System
should be able to request the Underlying Network to broadcast / multicast data to a group of M2M Devices in a
specified area.
• Implemented in Rel-1 -> Not implemented in Rel-1. ??
OSR-052: The oneM2M System should be able to select an appropriate Underlying Network to broadcast or multicast
data depending on the network's broadcast/multicast support and the connectivity supported by the targeted group of
M2M Devices/Gateways.
• Not implemented in Rel-1.
OPR-004: When suitable interfaces are provided by the Underlying Network, the oneM2M System should have the
ability to schedule traffic via the Underlying Network based on instructions received from the Underlying Network.
• Not implemented in Rel-1.
OPR-005: The oneM2M System should be able to exchange information with M2M Applications related to usage and
traffic characteristics of M2M Devices or M2M Gateways by the M2M Application. This should include support for the
3GPP feature called: "Time controlled" (see note 2).
• Not implemented in Rel-1.
NOTE 2: "Time controlled" is equivalent to the MTC Features specified in clause 7.2 of ETSI TS 122 368 [i.12].
OPR-006: Depending on availability of suitable interfaces provided by the Underlying Network the oneM2M System
should be able to provide information related to usage and traffic characteristics of M2M Devices or M2M Gateways to
the Underlying Network.
• Not implemented in Rel-1.
5.2 3GPP Release 13 MTC features
In 3GPP Release 13, requirements for "Service exposure with 3rd party service providers" features are specified in
clause 29 of ETSI TS 122 101 [i.3] and the "Charged party selection" feature is defined in sub-clause 5.1.3 of
ETSI TS 122 115 [i.4].
3GPP Release 13 architecture supports these features and they can be used to implement the oneM2M requirements as
described in the previous clause.
ETSI
oneM2M TR-0024 version 2.0.0 9 ETSI TR 118 524 V2.0.0 (2016-09)
These 3GPP features are not only intended for M2M communication, but also for human usable applications such as
smartphone applications.
3GPP intends to expose these additional features through the 3GPP Service Capability Exposure Function (SCEF) as
described in the following clause.
5.3 3GPP architecture for Service Capability Exposure
The 3GPP architecture for the Service Capability Exposure Function (SCEF) is defined in ETSI TS 123 682 [i.5]. The
specification includes two different architectures. One is for the "MTC Device triggering" feature and was specified in
rd
3GPP release 11. The other one is for 3GPP Service exposure with 3 party service providers features newly provided
in Release 13 which is the focus of the present document. Refer to the following figure 5.3-1, taken from the release 13
version of ETSI TS 123 682 [i.5].

Application
Application
Application
...
API 1 API 2 API 3 API n
OMA/
GSMA/
Service Capability Exposure Function
other SDOs
TRUST
3GPP
DOMAIN
T6a/
3GPP
Ns
S6t Rx, Nt Tsp ISC
MB2
T6b interface
...
MTC- Network
MME/
BM-SC RCAF
HSS PCRF S-CSCF
IWF Entity
SGSN
Figure 5.3-1: 3GPP Architecture for Service Capability Exposure
While 3GPP release 13 specifies the Service Capability Exposure Function (SCEF) as a 3GPP entity, residing in the
trust domain of the 3GPP operator, 3GPP does not specify the APIs exposing these functions. Specification of these
APIs is expected by external SDOs, e.g. OMA. As described in ETSI TS 123 682 [i.5]. the SCEF covers services such
as the the ability to configure device communication patterns, the QoS of a data flow, sponsor a data flow, scheduling
data transfers, monitor a device's state, optimizing a device's communication patterns for high latency applications,
receive reports about the condition of the mobile core network, trigger devices, and send group messages via MBMS.
ETSI
oneM2M TR-0024 version 2.0.0 10 ETSI TR 118 524 V2.0.0 (2016-09)
5.4 OMA API Program
5.4.1 Overview
The OMA API Program provides standardized interfaces to the service infrastructure residing within communication
networks and on devices. Focused primarily between the service access layer and generic network capabilities, OMA
API Program specifications allow operators and other service providers to expose device capabilities and network
resources in an open and programmable way-to any developer community independent of the development platform. By
deploying OMA APIs, fundamental capabilities such as SMS, MMS, Location Services, Payment and other core
network assets are now exposed in a standardized way. Additional OMA APIs may be found in OMA API Inventory
[i.6].
5.4.2 OMA work to be considered by oneM2M for 3GPP IWK
5.4.2.1 OMA Service Exposure Framework (ServiceExposure)
OMA ARC WG is working to define the Service Exposure Framework specification [i.7] which covers non-functional
capabilities that a network operator or a service provider should consider when it exposes the service capabilities
through the Network APIs. Such non-functional capabilities implemented in the intermediation layer may include
Authentication and Authorization, Infrastructural Policy, Business Policy, Assurance and Accounting.
OMA Service Exposure Framework can be considered as an OMA specified SCEF which can be used by oneM2M s
platforms.
5.4.2.2 OMA Exposing Network Capabilities to M2M (ENCap-M)
Recently, OMA ARC WG is developing new APIs for exposing network capabilities to M2M applications and/or M2M
service platforms.
The OMA work item "Exposing Network Capabilities to M2M" [i.8] lists requirements on standard APIs derived from
use cases in which third parties, such as oneM2M or any other can leverage network capabilities to enrich the services
or to streamline the operation. It also includes a gap analysis to identify any missing Network APIs to address above
requirements and use cases. This enables utilization of the latest evolution in cellular networks, e.g. 3GPP.
6 Reference architecture
Editor's Note: this clause describes the reference architecture of 3GPP interworking.
ETSI
oneM2M TR-0024 version 2.0.0 11 ETSI TR 118 524 V2.0.0 (2016-09)
Application Entity
Mca
oneM2M IN-CSE
Mcc
NSSE
Mcn
Mcn (OMA APIs)
Mcn (Other APIs)
(3GPP exposed
Interfaces)
APIs APIs
APIs APIs
OMA Other exposure
Trust Domain
SCEF function
(Mcn)
Trust
Domain
TBD
3GPP exposed
Interfaces
3GPP Network Other Underlying Network

Figure 6-1: Interworking architecture
This architecture supports the following interworking modes:
• The NSSE invokes services of the underlying network directly via the reference points of the applicable nodes
within the underlying network. This model is applicable to the case where the oneM2M service provider and
the underlying network provider is the same or there is trust relation between both service providers if they are
different.
• The NSSE exclusively invokes services of a 3GPP underlying network using OMA API.
• The NSSE invokes exclusively services of any underlying network using third party APIs.
• Any combination of the above, where some services are invoked using an API (OMA or third party depending
on the underlying network) while other services are invoked directly with the underlying network using the
applicable reference point.
The functionality supported by the NSSE is different depending on the interworking mode.
7 Potential impact for interworking with oneM2M
Editor's Note: this clause propose the enhancements based on architecture defined by oneM2M. What mechanisms can
be reused and what need to be newly defined.
There are specific high level functions defined in ETSI TS 123 682 [i.5], clause 4.5, such as device triggering,
information storage, group message delivery, monitoring, high latency communications, network status reporting,
background data transfer, communication patterns parameters provisioning, session QoS setting up, chargeable party
changing.
According to the end-to-end oneM2M functional architecture described in ETSI TS 118 101 [i.9], all Common Services
Functions (CSFs) reside within CSE may support those functions defined by ETSI TS 123 682 [i.9] and no architecture
functional changing.
ETSI
oneM2M TR-0024 version 2.0.0 12 ETSI TR 118 524 V2.0.0 (2016-09)
The Network Service Exposure, Service Execution and Triggering (NSSE) CSF manages communications with the
3GPP MTC Release-13 Underlying Networks. The NSSE CSF may be deployed as SCEF using 3GPP defined
interfaces (e.g. Rx, Tsp, etc.) bound to Mcn reference point. The NSSE CSF may also use OMA APIs or other APIs
bound to Mcn reference point.
The Communication Management and Delivery Handling (CMDH) CSF may support those functions such as device
triggering, group message delivery, monitoring, high latency communications, network status reporting, background
data transfer, communication patterns parameters provisioning, session QoS setting up, chargeable party changing.
The Data Management and Repository (DMR) CSF may support those functions such as information storage,
monitoring.
The Device Management (DMG) CSF may support monitoring function.
The Group Management (GMG) CSF may support group message delivery function.
The Location (LOC) CSF may support those functions such as monitoring, network status reporting.
Special authentication and authorization mechanisms for 3GPP Underlying Network such as IMSI, ACL, profile
managements, policy control may be supported by the Security (SEC) CSF.
The Service Charging and Accounting (SCA) CSF may support those functions such as monitoring, chargeable party
changing.
For supporting those functions, oneM2M system may add new attributes in existing resource types and changing
existing service flowsor create new resource types and new service flows. For detail, please refer to section 8 potential
solutions for interworking with oneM2M.
8 Potential solutions for interworking with oneM2M
8.1 Interworking Architecture with a 3GPP underlying network
8.1.1 Exclusive Support through 3GPP Reference Points
Figure 8.1.1-1 depicts this architectural model.
In this case 3GPP services capabilities are exclusively invoked via the 3GPP reference points for the applicable 3GPP
node.
SCEF is deployed as the
oneM2M
(SCESCFE)F   NSSE
IN-CSE
oneM2M NSSE CSF within
SCEF southbound interface is
the IN-CSE.
bound to the oneM2M Mcn
Mcn
reference point and is bound
to 3GPP defined interfaces
(e.g. Rx, Tsp, etc.).
3GPP Network
Figure 8.1.1-1: oneM2M interworking with a 3GPP underlying network via 3GPP Reference Points
8.1.2 Exclusive Support through OMA API
Figure 8.1.2-1 depicts this architectural model. In this case 3GPP services capabilities are exclusively invoked via the
OMA API. Hence, the SCEF is fully implemented outside the oneM2M environment.
ETSI
oneM2M TR-0024 version 2.0.0 13 ETSI TR 118 524 V2.0.0 (2016-09)
oneM2M
NSSE
IN-CSE
SCEF northbound interface
Mcn using
API (OMA APIs) is bound to
(OMA APIs)
oneM2M Mcn reference
The SCEF may exhibit
point.
different subsets of OMA
SCSCEEFF
APIs depending on the trust
relationship between the
SCEF southbound interface
M2M SP and the 3GPP SP.
3GPP
made up of 3GPP defined
Reference
interfaces (e.g. Rx, Tsp, etc.)
Points
and is out of scope for
oneM2M.
3GPP Network
Figure 8.1.2-1: oneM2M interworking with a 3GPP underlying network via OMA API
8.1.3 Hybrid Mode
Figure 8.1.3-1 depicts this architectural model.
In this case 3GPP services capabilities are invoked on a per service basis which can include OMA API for some service,
proprietary APIs for others and finally some services can be invoked directly using the 3GPP reference points.
This SCEF is bound to oneM2M
Mcn reference point and is
bound to 3GPP defined
interfaces (e.g. Rx, Tsp,etc.)
Northbound proprietary
exposure interface API is
oneM2M
SCEF   NSSE
bound to oneM2M Mcn
IN-CSE
SCEF northbound interface API
reference point.
(OMA APIs) is bound to
Mcn using Mcn (Operator
oneM2M Mcn reference point.
(OMA APIs) A’s API)
n
c
Proprietary
SCEF
M
Exposure Function
Proprietary exposure
functions uses 3GPP
3GPP Reference Points
reference points interfaces
SCEF southbound interfaces is
(e.g. Rx, Tsp, etc).
oneM2M Mcn reference point
3GPP Network
and is bound to 3GPP defined
interfaces (e.g. Rx, Tsp, etc.).

Figure 8.1.3-1: oneM2M interworking with a 3GPP underlying network in a hybrid mode
8.2 Configuration of Device Triggering Recall/Replace
8.2.1 Description
Device Triggering is the means by which a SCS sends information to the UE via the 3GPP network to trigger the UE to
perform application specific actions that include initiating communication with the SCS for the indirect model or an AS
in the network for the hybrid model. Device Triggering is required when an IP address for the UE is not available or
reachable by the SCS/AS.
ETSI
oneM2M TR-0024 version 2.0.0 14 ETSI TR 118 524 V2.0.0 (2016-09)
Device triggering recall/replace functionality allows a SCS to recall or replace previously submitted trigger messages
which are not yet delivered to the UE.
8.2.2 3GPP Release-13 MTC procedure
oneM2M uses the 3GPP Release-13 MTC feature for Device Trigger Recall/Replace to request to recall or replace
previous Device Trigger message by using the oneM2M Device Tigger resource to provide the corresponding 3GPP
information.
A signalling sequence for Device Trigger Recall/Replace is described in the clause 5.2.3 of ETSI TS 123 682 [i.5].
Figure 8.2.2-1 provides the signalling sequence derived from the 3GPP specification with oneM2M terminologies
mapping (ETSI TS 123 682 [i.5], figure 5.2.3.1-1).

Figure 8.2.2-1: Device trigger recall/replace procedure over Tsp
1. The SCS determines it needs to recall/replace a trigger message that it has previously submitted. The SCS
sends Device Action Request (External Identifier or MSISDN, SCS Identifier, old trigger reference number,
new trigger reference number, validity period, priority, Application Port ID and trigger payload) message with
action type set to "Trigger Recall Request" or "Trigger Replace Request". The SCS needs to include new
trigger reference number, validity period, priority, Application Port ID and trigger payload for trigger replace
request only. The old trigger reference number indicates the trigger reference number which was assigned to
the previously submitted trigger message that the SCS wants to cancel. The new trigger reference number is
assigned by the SCS to the newly submitted trigger message.
If the SCS is not authorized to perform device triggering or the SCS has exceeded its quota or rate of trigger
submission over Tsp, the MTC-IWF rejects the Device Action Request message with action type set to
"Trigger Recall Request" or "Trigger Replace Request" by sending a Device Action Answer message with a
cause value indicating the reason for the failure condition, and the flow stops at this step.
NOTE 1: The validity period in a trigger replace request needs to be greater than zero for the MTC-IWF to attempt
its delivery.
2. The MTC-IWF sends a Subscriber Information Request (External Identifier or MSISDN and SCS Identifier)
message to the HSS/HLR to determine if SCS is authorized to perform device triggering to the UE. This
message is also to resolve the External Identifier or MSISDN to IMSI and retrieve the related HSS stored
"Routing information" including the identities of the UE's serving CN node(s) which are needed for trigger
replace request only.
NOTE 2: Optionally, mapping from External Identifiers to MSISDN is also provided for legacy SMS infrastructure
not supporting MSISDN-less SMS.
ETSI
oneM2M TR-0024 version 2.0.0 15 ETSI TR 118 524 V2.0.0 (2016-09)
3. The HSS/HLR sends the Subscriber Information Response (IMSI and/or MSISDN and related "Routing
information" including the serving node(s) identities, cause) message. The IMSI and/or MSISDN and related
"Routing information" including the serving node(s) identities in the Subscriber Information Response
message is only needed for trigger replace request and not used by MTC-IWF for trigger recall request.
HSS/HLR policy (possibly dependent on the VPLMN ID) may influence which serving node identities are
returned. If the cause value indicates the SCS is not allowed to perform device triggering to this UE, or there is
no valid subscription information, the MTC-IWF sends a Device Action Answer message with a cause value
indicating the reason for the failure condition and the flow stops at this step. Otherwise this flow continues
with step 4.
4. If trigger message which should be recalled or replaced was submitted to a SMS-SC as defined in clause 5.2.2
of ETSI TS 123 682 [i.5], T4 device trigger replace procedure according to clause 5.2.3.2 of ETSI
TS 123 682 [i.5] or T4 device trigger recall procedure according to clause 5.2.3.3 of ETSI TS 123 682 [i.5] is
performed.
5. The MTC-IWF indicates trigger recall/replace success or failure in Device Action Answer message to the
SCS. The MTC-IWF generates the necessary CDR information including the External Identifier or MSISDN
and SCS Identifier.
If recall/replace of a trigger is successful, this is reflected in the "Device Trigger Report" of the original trigger
message (per step 7 in clause 5.2.1 of ETSI TS 123 682 [i.5]) with delivery outcome "Recalled"/"Replaced".
NOTE 3: If recall/replace of a trigger failed because the trigger was already delivered or has expired, a "Device
Trigger Report" of the original trigger will already have been created with the appropriate delivery
outcome.
6. For trigger replace request, the new trigger message will be delivered to the UE immediately or when the UE
is available following steps 4 - 9 as defined in clause 5.2.2 of ETSI TS 123 682 [i.5].
8.2.3 3GPP Parameters
A set of Device Trigger Recall/Replace parameters can be associated with a Device Trigger Recall/Replace request, as
defined in table 8.2.3-1.
Table 8.2.3-1: Device Trigger Recall/Replace parameters
Parameter Description
External Identifier or MSISDN It is used to identify the corresponding External Identifiers in the delivery
report. This can be also the MSISDN if used.
SCS Identifier It is used to allow the SMS SC to send the trigger response back to the
appropriate SCS.
old trigger reference number This is to identify the previous device trigger request.
new trigger reference number This is to identify the device trigger recall/replace request.
validity period To indicate the time period for which the trigger request is valid.
priority It is used to indicate the priority of trigger request.
SMS Application Port ID It is used to route the short message to the triggering function in the UE.
trigger payload The SMSC will store the Trigger payload until it receives the delivery
confirmation.
NOTE 1: The Trigger Payload is stored as user data in SMS-SC.
NOTE 2: Priority, Validity period and SMS Application Port ID are included in the Trigger payload.

8.2.4 Solution(s)
8.2.4.1 Solution1
8.2.4.1.1 Proposed resource types and attributes
This clause provides information of new resource types and new attributes including relationship with existing resource
types and attributes.
ETSI
oneM2M TR-0024 version 2.0.0 16 ETSI TR 118 524 V2.0.0 (2016-09)
The attribute triggerReferenceNumber is suggested to put under the resource in table 9.6.4-3 ETSI
TS 118 101 [i.9].
Table 8.2.4.1.1-1: Attribute triggerReferenceNumber adds under
RW/ Attributes of
Multiplicity RO/ Description nnc>

WO Attributes
triggerReferenceNumber 0.1 RW This is to identify device trigger request. NA
This attribute is used only for device
trigger and assigned by the IN-CSE.

8.2.4.1.2 Proposed Flow(s)
Figure 8.2.4.1.2-1 depicts a generic procedure for device triggering recall/replace between oneM2M and 3GPP network.

Figure 8.2.4.1.2-1: General device triggering recall/replace procedure
between oneM2M and 3GPP network
Pre-condition
The IN-CSE has already send device trigger request to 3GPP network and connectivity is not established yet.
ETSI
oneM2M TR-0024 version 2.0.0 17 ETSI TR 118 524 V2.0.0 (2016-09)
Step-1: Device Trigger Recall/Replace request
IN-CSE issues the device trigger Recall/Replace request to 3GPP network.
Some information provided to 3GPP Network for device trigger recall/replace includes:
• M2M-Ext-ID associated with the ASN/MN-CSE as the target of the triggering request.
• IN-CSE ID which could be used by 3GPP network to authorize the IN-CSE for device trigger recall/replace.
• The old trigger reference number was assigned to the previously submitted trigger message that the IN-CSE
wants to recall/replace.
• For trigger replace request, the new trigger reference number which is assigned by the IN-CSE to the newly
submitted trigger message.
Step-2: 3GPP Network Device Trigger Recall/Replace procedure
Device Trigger Recall/Replace procedure is performed in 3GPP Network, which is specified in ETSI TS 123 682 [i.5].
Step-3: Device Trigger Recall/Replace response
The IN-CSE receives a response for the Device Trigger Recall/Replace request via the Mcn reference point.
Step-4: For trigger replace request, deliver new trigger message.
For trigger replace request, the new trigger message will be delivered to the target Node as specified in ETSI
TS 123 682 [i.5].
8.3 Configuration of Traffic Patterns
8.3.1 Description
M2M devices that have predicable communication behaviour - e.g. in the form of repeating Traffic Patterns - can profit
in terms of reduction of signalling, energy saving, fewer sleep/awake transitions, etc., when their Traffic Patterns are
communicated to the underlying network.
EXAMPLE 1: 3GPP devices could use new 3GPP power savings features such as eDRX (extended discontinuous
reception) and PSM (Power Saving Mode) on LTE devices.
Also the underlying network can benefit from being informed about a device's Traffic Patterns by the oneM2M System.
EXAMPLE 2: If the IN-CSE knows the device's Traffic Patterns and transmits them to an underlying 3GPP
network, then this information can be used by a 3GPP network to set the device's "Maximum
Response Time" (3GPP Term) to tune the UE's DRX and PSM parameters.
Thus the network will benefit because the UE will have fewer sleep/wake transitions and unnecessary signalling in the
network can be avoided. Also, if the IN-CSE knows when the device is awake then data can be sent to the device
exactly at the time when the device is listening, thus requiring the network to buffer less data for unavailable devices.
The purpose of the Configuration of Traffic Patterns feature is to provide a means to the oneM2M System to inform the
Underlying Network on parameters that can be used for optimizing the processing at the Underlying Network for a
specific Field Domain Node. The feature includes the following functionalities:
• An Application Entity (AE) or a Common Service Entity (CSE) should be able to provide information on the
communication behavior of a Field Domain Node (ASN or MN) to the underlying network.
• To that purpose the AE or CSE should be able to set Traffic Patterns of a particular Field Domain Node via the
Mca or Mcc reference point of a IN-CSE:
- The Field Domain Node is addressed using the (NodeID, AE-IDs) of the Node.
ETSI
oneM2M TR-0024 version 2.0.0 18 ETSI TR 118 524 V2.0.0 (2016-09)
• The IN-CSE should in turn use the Mcn interface towards the Underlying Network
...