-
1
2
3
O NE M2M
T EC H NIC A L S PEC I FIC A T ION
Document Number
TS-0026-V-0.2.0
Document Name:
3GPP Interworking
Date:
2017-04-27
Abstract:
This document specifis interworking between oneM2M service layer and
3GPP Rel-13 & Rel-14 features, so that some 3GPP Rel13 & Rel14 features
can be exposed to oneM2M service layer for the benefit of IoT
applications, and vice-versa
Template Version: 08 September 2015 (Dot not modify)
4
5
6
7
8
9
10
11
This Specification is provided for future development work within oneM2M only. The Partners accept no
liability for any use of this Specification.
12
13
14
The present document has not been subject to any approval process by the oneM2M Partners Type 1.
Published oneM2M specifications and reports for implementation should be obtained via the oneM2M
Partners' Publications Offices.
15
16
17
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC)
Page 1 of 19
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
-
18
About oneM2M
19
20
21
22
The purpose and goal of oneM2M is to develop technical specifications which address the
need for a common M2M Service Layer that can be readily embedded within various
hardware and software, and relied upon to connect the myriad of devices in the field with
M2M application servers worldwide.
23
More information about oneM2M may be found at: http//www.oneM2M.org
24
Copyright Notification
25
© 2015, oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSTDI, TTA, TTC).
26
All rights reserved.
27
The copyright extends to reproduction in all media.
28
29
Notice of Disclaimer & Limitation of Liability
30
31
32
33
The information provided in this document is directed solely to professionals who have the
appropriate degree of experience to understand and interpret its contents in accordance with
generally accepted engineering or other professional standards and applicable regulations.
No recommendation as to products or vendors is made or should be implied.
34
35
36
37
38
39
40
41
42
43
44
45
NO REPRESENTATION OR WARRANTY IS MADE THAT THE INFORMATION IS
TECHNICALLY ACCURATE OR SUFFICIENT OR CONFORMS TO ANY STATUTE,
GOVERNMENTAL RULE OR REGULATION, AND FURTHER, NO
REPRESENTATION OR WARRANTY IS MADE OF MERCHANTABILITY OR
FITNESS FOR ANY PARTICULAR PURPOSE OR AGAINST INFRINGEMENT OF
INTELLECTUAL PROPERTY RIGHTS. NO oneM2M PARTNER TYPE 1 SHALL BE
LIABLE, BEYOND THE AMOUNT OF ANY SUM RECEIVED IN PAYMENT BY
THAT PARTNER FOR THIS DOCUMENT, WITH RESPECT TO ANY CLAIM, AND IN
NO EVENT SHALL oneM2M BE LIABLE FOR LOST PROFITS OR OTHER
INCIDENTAL OR CONSEQUENTIAL DAMAGES. oneM2M EXPRESSLY ADVISES
ANY AND ALL USE OF OR RELIANCE UPON THIS INFORMATION PROVIDED IN
THIS DOCUMENT IS AT THE RISK OF THE USER.
46
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC)
Page 2 of 19
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
-
47
Contents
48
Contents .............................................................................................................................................................. 3
49
1
Scope ........................................................................................................................................................ 4
50
51
52
2
References ................................................................................................................................................ 4
53
54
55
56
57
3
58
4
Conventions.............................................................................................................................................. 5
59
60
61
62
63
5
oneM2M Architecture for 3GPP cellular IoT interworking with oneM2M ............................................. 6
64
65
66
67
68
69
70
71
72
73
74
75
7
76
77
8
78
79
80
Annex <A> (Informative): Informative introduction of 3GPP Cellular IoT network ...................................... 16
81
Annex <X>
82
83
X.1
84
85
History .............................................................................................................................................................. 18
2.1
2.2
3.1
3.2
3.3
3.4
Normative references ......................................................................................................................................... 4
Informative references ....................................................................................................................................... 4
Definitions, symbols and abbreviations ................................................................................................... 4
Definitions ......................................................................................................................................................... 4
Symbols ............................................................................................................................................................. 5
Abbreviations ..................................................................................................................................................... 5
Acronyms ........................................................................................................................................................... 5
6.1 Overview ...................................................................................................................................................................... 8
6.2
ASN/MN-CSE Pre-configuration ...................................................................................................................... 9
6.3 ASN/MN-CSE or ADN-AE Initiated Connectivity Establishment Procedure ........................................................... 10
6.4 IN-CSE initiated connectivity establishment procedure ............................................................................................. 11
7.1
7.2
7.3
7.4
7.5
7.6
7.7
7.8
7.9
7.10
7.11
8.1
A.1
A.2
X.1.1
Interworking with CIoT network features exposed to service layer ...................................................... 11
Cellular IoT IP and non-IP data delivery ......................................................................................................... 11
UE context information storage ....................................................................................................................... 11
High latency communications.......................................................................................................................... 11
Monitoring events ............................................................................................................................................ 11
SMS Based Device triggering .......................................................................................................................... 11
Configuration of Traffic Patterns ..................................................................................................................... 14
Group message delivery................................................................................................................................... 16
Informing about Potential Network Issues ....................................................................................................... 16
Setting up an AS session with required QoS procedure .................................................................................. 16
Resource management of background data transfer ........................................................................................ 16
Change the chargeable party at session set-up or during the session procedure .............................................. 16
Cellular IoT device management ........................................................................................................... 16
sub-function of device management (e.g. Device Configuration) ................................................................... 16
Main concepts of 3GPP cellular IoT network .................................................................................................. 16
The 3GPP architecture for service capabilities exposure ................................................................................. 17
18
First clause of the annex (style H1) ........................................................................................................ 18
First subdivided clause of the annex (style H2) ............................................................................................... 18
86
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC)
Page 3 of 19
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
-
87
1
Scope
88
89
90
The present document specifies interworking between oneM2M service layer and 3GPP network, so that relevant 3GPP
features defined by Cellular IoT i.e.Rel13 & Rel14 and by previous Releases (including Rel11 & Rel12) can be used by
oneM2M service layer for the benefit of IoT applications
91
2
92
The following text block applies.
93
94
95
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.
96
2.1
97
The following referenced documents are necessary for the application of the present document.
98
[1] oneM2M TS-0001 Reference Architecture (v3)
References
Normative references
99
100
[2] 3GPP 23.682 Architecture enhancements to facilitate communications with packet data networks and applications;
(Release 14)
101
102
[3] OMA-TS-REST-NetAPI-CommunicationPatterns-V1-0: '"RESTful Network API for Communication Patterns'",
Version 1.0, Open Mobile Alliance.
103
2.2
104
105
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.
Informative references
106
107
108
[i.1] oneM2M Drafting Rules (http://member.onem2m.org/Static_pages/Others/Rules_Pages/oneM2M-DraftingRules-V1_0.doc)
109
110
3
Definitions, symbols and abbreviations
111
Delete from the above heading the word(s) which is/are not applicable.
112
3.1
Definitions
113
114
Clause numbering depends on applicability.
115

A definition shall not take the form of, or contain, a requirement.
116
117

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).
118

The terms and definitions shall be presented in alphabetical order.
119
For the purposes of the present document, the [following] terms and definitions [given in ... and the following] apply:
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC)
Page 4 of 19
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
-
120
Definition format
121
<defined term>: <definition>
122
123
If a definition is taken from an external source, use the format below where [N] identifies the external document which
must be listed in Section 2 References.
124
<defined term>[N]: <definition>
125
example 1: text used to clarify abstract rules by applying them literally
126
NOTE:
This may contain additional information.
127
3.2
128
Clause numbering depends on applicability.
129
For the purposes of the present document, the [following] symbols [given in ... and the following] apply:
130
Symbol format
131
132
133
Symbols
<symbol>
<2nd symbol>
<3rd symbol>
<Explanation>
<2nd Explanation>
<3rd Explanation>
134
3.3
135
Abbreviations should be ordered alphabetically.
136
Clause numbering depends on applicability.
137
For the purposes of the present document, the [following] abbreviations [given in ... and the following] apply:
138
Abbreviation format
139
140
141
Abbreviations
<ABREVIATION1> <Explanation>
<ABREVIATION2> <Explanation>
<ABREVIATION3> <Explanation>
142
3.4
143
Acronyms should be ordered alphabetically.
144
Clause numbering depends on applicability.
145
For the purposes of the present document, the [following] abbreviations [given in ... and the following] apply:
146
Acronym format
147
148
149
Acronyms
<ACRONYM1> <Explanation>
<ACRONYM2> <Explanation>
<ACRONYM3> <Explanation>
150
151
4
Conventions
152
153
The key words “Shall”, ”Shall not”, “May”, ”Need not”, “Should”, ”Should not” in this document are to be interpreted
as described in the oneM2M Drafting Rules [i.1]
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC)
Page 5 of 19
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
-
5
oneM2M Architecture for 3GPP cellular IoT
interworking with oneM2M
156
5.1
Introduction
157
158
159
160
161
This document introduces a baseline architecture for supporting 3GPP interworking and 3GPP CIoT features such as IP
and non-IP data Control Plane Data Delivery. It describes how the oneM2M system may leverage the IoT related
features and services that 3GPP added in releases 10 through 13. Features and services may be accessed by an ADNAE, MN-CSE, or an ASN-CSE that is hosted on a UE, an IN-CSE that is able to access services that are exposed by a
mobile network operator.
162
163
Figure 5.1-1 shows, at a high level, how 3GPP interfaces with external entities. A more detailed picture can be found in
3GPP TS 23.682 [2].
164
165
166
The Service Capability Server (SCS) is a 3GPP term that refers to an entity which connects to the 3GPP network to
communicate with UEs used for MTC and the MTC-IWF and/or SCEF. The SCS offers services to MTC Applications
that are hosted on the UE or in an Application Server (AS).
167
168
169
In addition to connecting to the 3GPP though the SGi (IP based data plane) interface, the SCS connects to the 3GPP
network via the MTC Interworking Function (MTC-IWF) and/or the Service Capability Exposure Function (SCEF).
Both the MTC-IWF and SCEF are described 3GPP TS 23.682 [2].
170
171
The MTC-IWF offers a single service to the SCS: device triggering via SMS. This service is accessed via the Tsp
Reference point which is a Diameter based interface.
172
173
174
175
The SCEF offers multiple services to the SCS. These services are accessed via an API exposed by the SCEF. The API
is not defined by 3GPP. The API maybe defined by other standardization bodies or it may be customized by the SCEF
operator. OMA has standardized APIs that may be used to access some of the exposed services, e.g. Communication
Patterns [3].
176
177
178
The SCEF and MTC-IWF may be co-located. In this type of deployment, the Tsp interface would not be exposed to the
SCS; SMS device triggering functionality would be exposed to the SCS by the SCEF via API. The SCEF API and the
Tsp interface are also described in 3GPP TS 23.682 [2].
179
180
181
182
183
MTC Applications on the UE interact with the 3GPP network via 3 different interfaces. MTC Applications may use the
3GPP network to send IP packets to and from the SCS and/or other MTC Applications. SMS device triggers may be
received by MTC Applications that are hosted in the UE. Also, NAS messaging may be used to send and receive nonIP data, send and receive IP data, configure power savings mode, configure extended idle mode DRX, configure low
priority indicators, etc.
154
155
3GPP Trust Domain
SMS-SC
MTC-IWF
MME
SCEF
SGSN /
S-GW
GGSN /
P-GW
Tsp
UE
SMS
API
SCS
NAS
S1-U
(IP Data Plane)
SGi
SGi
AS
184
185
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC)
Page 6 of 19
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
-
Figure 5.1-1: 3GPP IoT Related Interfaces
186
187
188
5.2
Functional mapping between 3GPP and oneM2M
189
190
191
Figure 5.2-1 is an updated version of Figure 5.1-1. This figure has been updated to show, at a high level, how oneM2M
functional entities may access the features and services that are exposed by 3GPP. The oneM2M entities are shaded in
grey.
192
193
194
The “MTC Applications” that are hosted on the UE correspond to oneM2M entities which may be ADN, ASN or MN,
or the UE may host a noDN. The SCS may be an IN-CSE, and the “MTC-Applications” or ASs that are hosted in an
external network may be an IN-AE.
195
196
197
The “3GPP Domain” box in Figures 5.1-1 and Figure 5.2-1 captures the functional entities that MUST be part of the
3GPP domain (the network). Although Figure 5.2-1 show that the IN-CSE and IN-AE are outside of the 3GPP Domain,
it should be noted that the IN-CSE may be part of the operator domain.
198
199
200
201
This figure also shows the oneM2M reference points Mcn and Mca. The Mcc reference point is not shown explicitly as
it would have rendered the picture less legible, but as is defined in [1], clause 5, the Mcc reference point is per
definition between the two CSEs on respectively the left-hand side and the right-hand side of the figure. It is transported
over any available data path between the two CSEs.
202
203
3GPP Domain
UE
SMS-SC
AE
MTC-IWF
Tsp Mcn
Mca
ASN/MN-CSE
SMS
Mcn
NAS
3GPP
Communication
Unit
Mcn
IP
MME
SCEF
SGSN /
S-GW
GGSN /
P-GW
IN-CSE
(SCS)
API
Mcn
(S)Gi
(S)Gi
Mca
IN-AE (AS)
oneM2M entity
Optionally present oneM2M entity
204
205
Direct connection option not
currently supported
Figure 5.2-1: oneM2M Interfaces to the 3GPP Network
206
207
Several implementation options for the placement of the oneM2M (IN) CSE relative to the SCEF and the 3GPP
network are envisioned. In all implementations, the SCEF always resides within 3GPP domain.
208
209
In some options the IN-CSE and the SCEF are deployed by a mobile network provider and are both part of the operator
domain. In other options the SCEF is part of the 3GPP domain and the IN-CSE is not part of the operator domain.
210
In all options, services within the IN-CSE may access the network services that are exposed by the SCEF via the API.
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC)
Page 7 of 19
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
-
211
5.3
Cellular IoT Features and Services
212
213
The SCEF exposes the following services to the IN-CSE. This document describes how the IN-CSE may access each
service.
214
1.
Configuring Communication Patterns, see clause 6.6.
215
2.
Configuring Session QoS, see clause 6.9.
216
3.
Configuring Session Sponsorship, see clause 6.11.
217
4.
Background Data Transfer, see clause 6.10.
218
5.
Monitoring, see clause 6.4.
219
6.
High Latency Communication – Extended S-GW and SCEF Buffering, see clause 6.3.
220
7.
High Latency Communication – Configuring PSM and eDRX, see clause 6.3.
221
8.
Mobile Core Network Issue Reports, see clause 6.8.
222
9.
SMS Based Device Triggering, see clause 6.5.
223
10. Group Messaging (via MBMS), see clause 6.7.
224
11. Non-IP Data Delivery, see clause 6.1.1.
225
226
A UE hosted ADN-AE, MN-CSE, or ASN-CSE may access the following features that may be exposed by the 3GPP
modem. This document describes how the UE hosted ADN-AE, MN-CSE, or ASN-CSE may access each service.
227
1.
SMS Based Device Triggering, see clause 6.5.
228
2.
Group Messaging (via MBMS), see clause 6.7.
229
3.
Non-IP Data Delivery, see clause 6.1.1.
230
4.
Configuring Low Access Priority Connections, see clause TBD.
231
5.
High Latency Communication – Configuring PSM and eDRX, see clause 6.3.
232
6.
User Plane CIoT Optimizations (Suspend / Resume), see clause TBD.
233
234
235
236
237
Editor’s Note: A full list of 3GPP Release 13 & Release 14 service capabilities exposure functions will be shown and in
order to scope down the work in R3, a subset of functions that are considered to be the highest priority and are aimed to
be specified in this TS in R3 will also be given in this subclause.
238
6 Connectivity Establishment
239
6.1 Overview
240
241
242
243
ASN/MN-CSE and the serving IN-CSE communicate after completion of the Underlying Network bearer establishment
and discovery of the serving IN-CSE. Data can then traverse between CSEs over the IP connection in the Underling
Network over 3GPP Gi/SGi interface. In addition, the signalling connectivity between the two CSEs is also realized.
Figure 6.11 depicts the connectivity between the ASN/MN-CSE and the IN-CSE.
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC)
Page 8 of 19
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
-
ASN/MN-CSE
or ADN-AE
IN
oneM2M System
AE
AE
Mca
Mca
UE
CSE
CSE
Mcc/Mca
over Uu
3GPP
Air-Interface
Mcc/
Mca
Mcn
(Tsp)
MTCIWF
Mcc (over Gi/SGi)
IP connection
Services
Capability
Server
GGSN/
P-GW
3GPP Underlying Network
244
245
Figure 6.1-1: Connectivity Establishment between ASN/MN-CSE or ADN-AE and IN-CSE
246
247
248
249
250
For ASN/MN initiated connectivity establishment, it is assumed that there is no connectivity previously established, i.e.
no association between the ASN/MN-CSE or ADN-AE and the serving IN-CSE exists. When the ASN/MN-CSE or
ADN-AE needs to send data to the serving IN-CSE it first discovers the serving IN-CSE, which is located in a packet
data network, and establishes connection. Two methods can be used, as follows:
251
1) Use of DHCP and DNS.
252
2) Pre-configuration.
253
254
255
256
For serving IN-CSE initiated connectivity establishment, it is assumed that there is no connectivity previously
established between the ASN/MN-CSE and the serving IN-CSE. When the serving IN-CSE needs to contact the
ASN/MN-CSE to send data or request data, connectivity between them is established. This connectivity is triggered by
the serving IN-CSE.
257
258
NOTE: How the serving IN-CSE triggers a non-CSE capable M2M device (e.g. ADN) within the 3GPP Underlying
Network is not specified in this release of the document.
259
260
The ASN/MN-CSE or ADN-AE requests the DNS server address from the DHCP server followed by requesting the
serving IN-CSE IP address from the DNS server.
261
6.2
262
263
The ASN/MN-CSE or ADN-AE is preconfigured with the fully qualified domain name (FQDN) of the serving IN-CSE
or the IP address of the serving IN-CSE. If the FQDN is known, DNS resolution is used to obtain the IP address.
ASN/MN-CSE Pre-configuration
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC)
Page 9 of 19
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
-
264
265
6.3 ASN/MN-CSE or ADN-AE Initiated Connectivity Establishment
Procedure
Gi / SGi
UE
(ASN/MN-CSE
or ADN-AE)
3GPP Network
Entities
(GGSN/PGW)
+ NAT
SCS
(IN-CSE)
DHCP
Server
0. Trigger
DNS
1. Bearer setup Procedure
(Ref: 3GPP TS23.401, 23.060)
2. DHCP Query & Response
3. DNS Query & Response
4. Connection establishment
5. PoA Update
266
267
268
Figure 6.3-1: ASN/MN-CSE or ADN-AE initiated connectivity establishment
269
Step-0: Trigger
270
271
Subsequent procedures are triggered either when the ASN/MN-CSE or ADN-AE powers on or resulting from Device
Triggering
272
Step-1: Bearer Setup Procedure
273
Establish a 3GPP bearer(s) if not already available by using the procedures available in the 3GPP network.
274
Step-2: DHCP Query & Response
275
276
277
The ASN/MN-CSE or ADN-AE sends a query to a DHCP server to find a particular DNS server IP address. The DHCP
server responds with the IP address of a corresponding DNS server. Additionally, it is also possible to include one or a
list of domain names, i.e. FQDNs of target IN-CSEs.
278
Step-3: DNS Query & Response
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC) Page 10 of 19
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
-
279
280
281
The ASN/MN-CSE or ADN-AE performs a DNS query to retrieve the IN-CSE(s) IP addresses from which one is
selected. If the response does not contain the IP addresses, an additional DNS query is needed to resolve a Fully
Qualified Domain Name (FQDN) of the serving IN-CSE to an IP address.
282
Step-4: Connection Establishment
283
284
285
After reception of domain name and IP address of an IN-CSE, the ASN/MN-CSE or ADN-AE can initiate
communication towards the IN-CSE via the IP connection. The IN-CSE at this time shall be informed which Trigger
Recipient ID of the ASN/MN-CSE or ADN-AE or the AE-PoA of the ADN-AE to use for establishing communication.
286
Step-5: CSE-PoA Update
287
288
Once the M2M Service Connection (Mcc) is established, in the IN-CSE the CSE-PoA of the ASN-CSE/MN-CSE or the
AE-PoA of the ADN-AE shall be updated with the new established IP address.
289
The IN-CSE holds the state information and needs to be informed when the connection is closed.
290
291
6.4 IN-CSE initiated connectivity establishment procedure
292
293
See clause 7.5 SMS Based Device Triggering.
294
Editor’s note: NIDD section should be added
295
7
296
297
298
299
300
Interworking with CIoT network features exposed to
service layer
Editor’s Note: the signalling flows and resources specified in the following clauses should focus on the Mca and Mcn
interfaces: CIoT features synergy with oneM2M service layer. At the time when this skeleton is drafted, the subclauses of
clause 6 intend to capture all the 3GPP service capabilities exposure function categories. Once the subset of functions is
fixed in subclause 5.3, some 3GPP service capabilities exposure functions may be removed in this TS.
301
302
303
7.1
Cellular IoT IP and non-IP data delivery
304
7.2
UE context information storage
305
7.3
High latency communications
306
7.4
Monitoring events
307
7.5
SMS Based Device triggering
308
Connection Establishment between IN-CSE and ASN/MN-CSE or ADN-AE
309
310
311
Whenever the IN-CSE requires to establish a connection towards another entity (e.g. ASN/MN-CSE or ADN-AE,
ADN-AE), Device Triggering procedure over the Tsp interface as described in 3GPP TS 23.682 [Error! Reference
source not found.] shall be used.
312
This procedure assumes the ASN/MN-CSE or ADN-AE is directly connected to 3GPP access network.
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC) Page 11 of 19
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
-
313
Mcc/Mca
UE
(ASN/MN-CSE
or ADN-AE)
3GPP Network
Entities
3GPP
MTC-IWF
Tsp (Mcn)
SCS
(IN-CSE)
IN-AE
Mca
DNS
2. DNS Query /
Response
1. Request targeted
to ASN/MN-CSE
or AND-AE
3. Device Triggering
request
4. Device Triggering delivery procedure
6. Device Triggering
report
5. ASN-CSE receives
trigger
7. Connection establishment
8.PoA/Reachability state
updated
9. Re-sending of original request
314
315
Figure 7.5.1-1: IN-CSE initiated connectivity establishment
316
317
Pre-condition
318
319
320
321
The IN-CSE checks the state information of the target device. Some of this state information is the result of
provisioning or a previous connection establishment or triggering requests, such as the case of power-off, dormant
and/or connected state. The IN-CSE decides its next action, e.g. if it needs to start device triggering or to report to INAE about the inability to perform the request.
322
323
324
The CSE-PoA for the ASN/MN-CSE or AE-PoA of the ADN-AE either already contains an IP address which is not
valid anymore or no IP address at all, or FQDN does not resolve to a valid IP address. This is a pre-requisite for
performing the device triggering procedure.
325
Step 1 (Optional): Request targeted to ASN/MN-CSE or ADN-AE
326
327
328
The IN-AE requests to perform one of the CRUD operation on a resource residing on the ASN/MN-CSE or ADN-AE,
the request is sent via the Mca reference point to the IN-CSE. The request from IN-AE includes the address of the target
resource.
329
Step 2: DNS Query/Response
330
The IN-CSE determines the need to trigger the ASN/MN-CSE or ADN-AE.
331
332
333
If the IN-CSE has no contact details for a contact MTC-IWF, it may determine the IP address(es)/port(s) of the
MTC-IWF by performing a DNS query using the M2M-Ext-ID (M2M External Identifier) assigned to the target
ASN/MN-CSE or ADN-AE, or using a locally configured MTC-IWF identifier.
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC) Page 12 of 19
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
-
334
Step-3: Device Triggering Request
335
336
The IN-CSE buffers the original request information and sends the Device Trigger Request message that contains
information as specified in 3GPP TS 23.682 [i.14Error! Reference source not found.]. Such information includes:
337

M2M-Ext-ID or MSISDN;
338

SCS-Identifier, (is set to the IN-CSE ID);
339

Trigger reference number (used to correlate the request with the response);
340

Validity period, (which indicates how long the request is valid);
341

Priority (this field allows to set the priority on or off);
342
343

Application Port ID, (is set to the ASN/MN-CSE or ADN-AE Trigger-Recipient-ID since it is the triggering
application addressed in the device from 3GPP point of view);
344

Trigger payload, (optional information can be set to the payload).
345
346
347
348
349
NOTE 1: In case that the Device Triggering request is for an M2M Service Connection setup request as in the
present flow, it is assumed that when the target (i.e. ASN/MN-CSE or or ADN-AE) is woken up on
receiving the trigger it initiates connection establishment with the IN-CSE with which it is registered. The
information of the IN-CSE may be pre-stored in the target (i.e. ASN/MN-CSE or ADN-AE) or obtained
from the payload.
350
Acknowledge
351
352
353
354
Once, 3GPP-MTC-IWF receives the Trigger Request, it asks the HSS to determine if the IN-CSE is authorized to
perform the triggering to the target (i.e. ASN/MN-CSE or ADN-AE) and the HSS resolves the M2M-Ext-ID to IMSI
(or MSISDN). Then the 3GPP MTC-IWF acknowledges to the IN-CSE with the confirmation of receiving Device
Triggering Request.
355
Step-4: Device Triggering delivery procedure
356
357
The MTC-IWF initiates the T4 trigger delivery procedure according to the 3GPP TS 23.682 [i.14Error! Reference
source not found.], based on the information received from HSS and local policy.
358
359
NOTE 2: 3GPP Network Entities (e.g. SMS-SC) can select appropriate device triggering mechanism (e.g. SMS
based or SIP based via IP-SM-GW) according to the device capabilities.
360
Step 5: ASN/MN-CSE receives the trigger
361
As a result of the triggering procedure, the payload is delivered to the ASN/MN-CSE or ADN-AE trigger recipient.
362
363
364
NOTE 3: In case the Device Trigger contains the optional part of the trigger payload, it is assumed that such trigger
payload is forwarded to the application inside the ASN/MN-CSE or ADN-AE that is started as a result of
device trigger.
365
Step 6: Device Triggering report
366
Request:
367
368
369
The MTC-IWF sends the Device Trigger Report message (containing the M2M-Ext-ID or MSISDN and trigger
reference number) to the IN-CSE with a cause value indicating whether the trigger delivery succeeded or failed and the
reason for the failure.
370
Acknowledge:
371
IN-CSE acknowledges to the MTC-IWF with the conformation of the received Device Triggering Report.
372
Step 7 (Optional): Connection establishment procedure
373
374
The ASN/MN-CSE or ADN-AE performs the Connection establishment procedure as described in clause 6.4 and
oneM2M TS-0003 [2] for Secure Connection establishment.
375
As a result of this procedure the initial request over the reference point Mcc can be executed.
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC) Page 13 of 19
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
-
376
Step 8 (Optional): CSE-PoA/Reachability state updated
377
378
Once the connection over Mcc is established, the PoA of the ASN/MN-CSE or ADN-AE shall be updated at the INCSE with the new established IP address and the IN-CSE holds the reachability state of the ASN/MN-CSE or ADN-AE.
379
Step 9 (Optional): Re-sending of original request
380
381
As a result of step 7, the communication is established and now the initial request with the information stored in the
buffer of the IN-CSE at Step 3 can be re-issued over the reference point Mcc.
382
7.6
383
384
385
386
oneM2M uses the 3GPP MTC feature for Configuration of Device Communication Patterns to configure Node Traffic
Patterns in the Underlying Network (see TS-0001 section 8.3.5 Configuration of Node Traffic Patterns).
To that purpose the IN-CSE translates the oneM2M Node Traffic Pattern (TP) into a 3GPP Device Communication
Pattern. The generic oneM2M procedure for configuration of Node traffic Patterns is shown in Figure 7.6-1
Configuration of Traffic Patterns
387
Infrastructure Domain
NSE
Any Domain
Mcn
CSE hosting the
<node>
CSE hosting the
<AE>
AE
Mca
0. Create / Update / Delete
Traffic Patterns of the AE
1. Create / Update / Delete Traffic Patterns of a Field
Domain Node or a group of Field Domain Nodes
2. Select the NSE for
handling the Traffic
Pattern parameter sets
3. Request to provide / remove
Traffic Pattern parameter sets
4. Response
5. If TP is set at NSE, set
providedToNSE attribute of
traffic pattern TRUE
388
389
Figure 7.6.1-1: General procedure for configuration of Traffic Patterns
390
391
392
393
The 3GPP Underling Network signalling sequence for provisioning of CP parameters is described in 3GPP TS 23.682
[Error! Reference source not found.]. Figure 7.6-2 provides the signalling sequence derived from the 3GPP
specification.
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC) Page 14 of 19
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
-
MME
HSS
SCEF
SCS/AS
1. Update request (Communication Pattern)
2. Select CP
parameter
3. Update CP Parameter Request
4. Update UE
subscription
5. Update CP Parameter Response
6. Update Response
7. Provide CP parameters or
deletion notice to the MME
394
Figure 7.6-1: Signalling sequence for provisioning of CP Parameters
395
396
3GPP TS 23.682 [i.14] defines the request message of step 1 as below:
397
Editor’s note: the following text should be updated for R14
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
1.
The SCS/AS sends an Update Request (External Identifier or MSISDN, SCS/AS Identifier, SCS/AS
Reference ID(s), CP parameter set(s), validity time(s), SCS/AS Reference ID(s) for Deletion) message to the
SCEF.
NOTE 1: The SCS/AS uses this procedure to add, change or delete some or all of the CP parameter sets of the UE,
e.g. if the AS is aware that the UE has started or stopped moving for a significant time period, especially
if the AS is instructing the UE to do so, then the SCS/AS provides the corresponding CP parameter set(s)
and its validity time to the SCEF. The interface between SCEF and SCS/AS is outside the scope of 3GPP
and the messages in the Figure are exemplary.
3GPP TS 23.682 [Error! Reference source not found.] defines the request message of step 3 as below:
2.
The SCEF sends Update CP Parameter Request (External Identifier or MSISDN, SCEF Reference ID(s),
SCEF Address, CP parameter set(s), validity time(s), SCEF Reference ID(s) for Deletion) messages to the
HSS for delivering the selected CP parameter set(s) per UE. There may be multiple CP parameter sets
included in this message where each CP parameter set for addition or modification has been determined to
be non-overlapping with other CP parameter sets either included in the message or already provisioned for a
given UE. The SCEF derives the SCEF Reference (IDs) for CP parameter sets to be sent to the HSS based
on the SCS/AS Reference ID(s) from the SCS/AS.
414
415
NOTE 2: A request for deletion of a CP parameter set from the SCS/AS may result in a request for modification of
the non-overlapping CP parameter set by the SCEF.
416
417
418
419
420
421
422
423
424
425
426
427
EXAMPLE 1:
In the case that the selected server NSE is a 3GPP HSS, the protocol of the S6t reference point
defined by 3GPP is used for the request. The S6t uses one of Diameter Application protocols
defined by 3GPP. The request on the S6t reference point for the configuration of the CP parameter
sets (a CIR command) must include a User-Identifier AVP (either an External Identifeir or a
MSISDN of the UE), may include one or more AESE-Communication-Pattern AVP. An
AESE-Communication-Pattern AVP must include a SCEF-ID AVP (represent the ID of the
IN-CSE or M2M-SP-ID), may include a SCEF-Reference-ID AVP (assigned by the IN-CSE or
M2M-SP to identify the configuration of CP parameter sets uniquely) , may include one or more
Communication-Pattern-Set AVP. A Communication-Pattern-Set AVP may include AVPs for
Periodic-Communication-Indicator, Communication-Duration-Time, Periodic-Time, one or more
Scheduled-Communication-Time, Stationary-Indication, and Validity-Time. Refer to the
3GPP TS 29.336 [Error! Reference source not found.] for the detailed protocol description.
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC) Page 15 of 19
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
-
428
3GPP TS 23.682 [Error! Reference source not found.] defines the response message of step 5 as below:
429
430
3.
The HSS sends Update CP Parameter Response (SCEF Reference ID, Cause) message to the SCEF. The
cause value indicates successful subscription update or the reason of failed subscription update.
431
432
4.
The actual parameters for the request and response messages in above steps 3 and 5 are defined by 3GPP
TS 29.336 [Error! Reference source not found.], clauses 7 and 8 for S6t reference point.
433
434
435
436
437
438
439
440
EXAMPLE 2:
In the case that the selected server NSE is a 3GPP HSS, the protocol of the S6t reference point
defined by 3GPP is used for the response. The response on the S6t reference point for the
configuration of the CP parameter sets (a CIA command) must include either Result-Code AVP or
Experimental-Result AVP, may include a User-Identifier AVP if successful case, may include one
or more AESE-Communication-Pattern-Config-Status AVP. An AESE-Communication-PatternConfig-Status AVP must include the SCEF-Reference-ID AVP (same value in the request), may
include the SCEF-ID (same value in the request) and an AESE-Error-Report AVP. Refer to the
3GPP TS29.336 for the detailed protocol description.
441
3GPP TS 23.682 [Error! Reference source not found.] defines the response message of step 6 as below:
442
443
The SCEF sends the Update Response (SCS/AS Reference ID, Cause) message to inform the SCS/AS whether the
provision of the CP parameter set(s) was successful.
444
7.7
Group message delivery
445
7.8
Informing about Potential Network Issues
446
7.9
Setting up an AS session with required QoS procedure
447
7.10
Resource management of background data transfer
448
7.11
Change the chargeable party at session set-up or during
the session procedure
450
8
Cellular IoT device management
451
8.1
sub-function of device management (e.g. Device
Configuration)
449
452
454
Annex <A> (Informative): Informative introduction of 3GPP
Cellular IoT network
455
A.1
456
457
Editor’s Note: Introduction of basic concepts of 3GPP cellular IoT network including Radio Access Network technologies
(NB-IoT, LTE-M, EC-GSM) and the core network. For oneM2M, the focus is the interface to the 3GPP core network.
453
Main concepts of 3GPP cellular IoT network
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC) Page 16 of 19
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
-
458
A.2
The 3GPP architecture for service capabilities exposure
459
460
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC) Page 17 of 19
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
-
461
Annex <X>
462
463
X.1
464
<Text>
First clause of the annex (style H1)
465
466
X.1.1
467
<Text>
First subdivided clause of the annex (style H2)
468
469
History
470
471
This clause shall be the last one in the document and list the main phases (all additional information will be removed at
the publication stage).
Publication history
V1.1.1
<dd-Mmm-yyyy> <Milestone>
472
473
474
Draft history (to be removed on publication)
V0.0.1
19-10-2016
ARC-2016-0394R04-New_TS_on_3GPP-interworking_Draft_Baseline
V0.1.1
16-11-2016
Includes agreed contribution at TP#25 meeting:
WI-0058 Cellular IoT IWK V0.1.0 : Update the document name.
ARC-2016-0471R01-TS-0026_Scope-section：Add new scope content.
ARC-2016-0439R03-TS-0026_sec5:Add new section 5.
V0.2.0
2017-04-27
Includes agreed contribution at TP#28 meeting:
ARC-2017-0091R03-3GPP_TS_0001_to_TS_0026
475
476
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC) Page 18 of 19
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.
-
477
© oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC) Page 19 of 19
This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1.