Post on 10-Jun-2020
transcript
1
IoT LSP Standard Framework Concepts
Release 2.0 AIOTI WG03 – loT Standardisation
2015
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
AIOTI – Restricted 2
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
2
3
4
5
This deliverable introduces IoT Standards Developing Organisation (SDO), Alliance and Open
Source Software (OSS) landscapes to be used as input for the recommendations for Large
Scale Pilots (LSPs) standard framework and gap analysis. The LSPs can play an important role
in investigating and solving specific challenges for the IoT industry and promoting innovation
that is related to specific activities such as 1) the applied standards framework, 2)
deployments, 3) technological and business model validation and 4) acceptability.
The main objective of this deliverable is to briefly present the global dynamics and landscapes
of IoT SDO, Alliance and OSS initiatives, which can be used: 1) to leverage on existing IoT
standardization, industry promotion and implementation of standards and protocols, 2) as input
for LSP standards framework and gap analysis and 3) to provide a guideline for the proponents
of future project proposals associated with future IoT related calls financed by the EC on the
positioning of these initiatives within these landscapes.
Executive Summary
AIOTI – Restricted 3
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
6
Table of Contents 7
1. GOAL AND MOTIVATION............................................................................................................................. 4 8
2. IOT SDO AND ALLIANCE INITIATIVES LANDSCAPE........................................................................... 5 9
3. IOT OPEN SOURCE SOFTWARE INITIATIVES LANDSCAPE .............................................................. 7 10
4. MAPPING SDO/ALLIANCE/OSS/ INITIATIVES INTO KNOWLEDGE AREAS .................................. 8 11
5. APPENDIX 1: IOT SDOS, ALLIANCES AND OSSS .................................................................................. 10 12
5.1 SDO, ALLIANCE, AND OSS INITIATIVES TEMPLATE FOR INFORMATION COLLECTION ............................... 10 13 5.2 IOT SDO/ALLIANCE INITIATIVES ............................................................................................................... 12 14
5.2.1 3GPP (3rd Generation Partnership Project) ........................................................................................ 15 15 5.2.2 AVNU Alliance ...................................................................................................................................... 17 16 5.2.3 BBF (Broadband Forum): Broadband User Services (BUS) Work Area .............................................. 19 17 5.2.4 ETSI (European Telecommunications Standards Institute) .................................................................. 21 18 5.2.5 GSMA (GSM Association) ..................................................................................................................... 47 19 5.2.6 HyperCat ............................................................................................................................................... 49 20 5.2.7 IEC (International Electrotechnical Commission) ................................................................................ 50 21 5.2.8 IEEE P2413: Standard for an Architectural Framework for the Internet of Things ............................. 55 22 5.2.9 IETF (Internet Engineering Task Force) .............................................................................................. 56 23 5.2.10 IRTF (Internet Research Task Force): T2T RG (Thing to Thing) proposed RG ............................... 74 24 5.2.11 International Telecommunication Union – Telecommunication Standardization Sector (ITU-T) 76 25 5.2.12 (ISO/IEC) JTC1/WG10 Internet of Things ........................................................................................ 79 26 5.2.13 OIC (Open Interconnect Consortium) .............................................................................................. 81 27 5.2.14 OneM2M ........................................................................................................................................... 83 28 5.2.15 OSGi Alliance ................................................................................................................................... 86 29 5.2.16 Weightless ......................................................................................................................................... 90 30 5.2.17 WWRF (Wireless World Research Forum) ....................................................................................... 90 31
5.3 IOT OSS INITIATIVES ................................................................................................................................. 92 32 5.3.1 IoTivity .................................................................................................................................................. 93 33 5.3.2 OM2M (Open platform for M2M) ......................................................................................................... 95 34 5.3.3 sensiNact (aka BUTLER platform) ........................................................................................................ 96 35
6. APPENDIX 2: TECHNOLOGY TRENDS FOR THE SUPPORT OF IOT ............................................. 100 36
6.1 WIRELESS CONNECTIVITY TRENDS FOR THE SUPPORT OF IOT ................................................................. 100 37
7. REFERENCES ............................................................................................................................................... 100 38
39
40
41
AIOTI – Restricted 4
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
1. Goal and motivation 42
The IoT is becoming a market reality. However, in order to meet the IoT expectations such as a) 43
leveraging on hyper-connectivity, b) enabling interoperability of solutions and semantically 44
enriched information distributions and c) facilitating object and data reuse across application 45
domains, several challenges need to be addressed. In particular, three of the challenges that are 46
associated to LSPs (Large Scale Pilots) are: 1) large number of competing technology standards, 47
which are projected in both horizontal and vertical directions, 2) lack of understanding of new 48
business models and 3) social questions. The vertical direction implies that the standards and 49
protocols are developed for the support of applications/services that are belonging to a particular 50
application domain, i.e., a single vertical industry, such as home automation, smart mobility and 51
wearable medical devices, etc. The horizontal direction implies that the standards and protocols 52
are not targeting a specific vertical industry, but aim at providing general standard, protocols and 53
solutions for as many vertical industry types as possible with the implication of developing 54
limited adaptations to the applications that they need to support. 55
56
The realization of the IoT evolution and remaining challenges involve the development of 57
standards and protocols and as well the industry promotion and implementation of these 58
standards and protocols. This depends severely on the work and activities accomplished in SDO 59
(Standards Developing Organization), Alliance and OSS (Open Source Software) initiatives. It is 60
therefore, important to understand the global dynamics and landscapes of IoT SDO, Alliance and 61
OSS initiatives, which can be used: 1) to leverage on existing IoT standardization, industry 62
promotion and implementation of standards and protocols, 2) as input for LSP standards 63
framework and gap analysis and 3) to provide a guideline for the proponents of future project 64
proposals associated with future IoT related calls financed by the EC on the positioning of these 65
initiatives within these landscapes. 66
67
Currently there are many SDO, Alliance and Open Source initiatives that are active and 68
competing in the IoT technology and applications areas. This is a normal development 69
considering that IoT technology is still in the early phase of deployment. In this context, the 70
landscape is complex, dynamic and challenging to grasp and visualize. 71
72
This report gives several ways of visualising the landscape in order to simplify and facilitate the 73
usage of the information in various IoT application domains. AIOTI WG03 has chosen three 74
ways for this representation. First, the IoT landscape is divided into four quadrants, where the 75
horizontal axis represents the market type and the vertical axis represents the technology area 76
covered by these initiatives; second the initiatives are classified based on the vertical and 77
horizontal application domains and third the IoT landscape initiatives are clustered on seven 78
knowledge areas (e.g. sensors/actuators/edge devices, communication/connectivity, 79
integration/interoperability, applications, architecture, and security/privacy). 80
81
AIOTI – Restricted 5
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
2. IoT SDO and Alliance Initiatives Landscape 82
This section briefly introduces main IoT SDO and Alliance initiatives that have a worldwide 83
visibility and applicability and provides the global landscapes associated with these SDO and 84
Alliance initiatives. 85
86
Figure 1 shows the “IoT SDOs and Alliances Landscape (Technology and Marketing 87
Dimensions)”, where these initiatives are projected based on two projection dimensions. The 88
horizontal axis represents the market type and the vertical axis represents the 89
technology/solution/knowledge area that these initiatives cover and focus. It should be 90
understood that the most left part of the horizontal axis represents the customer (i.e., Business to 91
Customer: B2C) market, while the most right part of the same axis represents the industrial 92
internet (i.e., Business to Business: B2B) market. The top part of the vertical axis represents the 93
technology areas that are related to services and applications, while the bottom part of the same 94
axis represents the technology areas that are related to connectivity. 95
96
The projection of these initiatives on these two dimensions has been accomplished based on 97
discussions among experts participating in both AIOTI WG03 and relevant initiatives as well as 98
on the collected information presented in Appendix 1 (Section 5). 99
100
101 Figure 1: IoT SDO and Alliances Landscape 102
103
In addition to the SDO and Alliance landscape shown in Figure 1, a projection of these initiatives 104
into vertical industry domains is shown in Figure 2. The "IoT SDOs and Alliances Landscape 105
(Vertical and Horizontal Domains)" is a graphical representation aiming to highlight the main 106
activity (up to the day of generating this representation) of SDOs and Alliances with respect to 107
the IoT application domains represented as "verticals" and the IoT Telecommunication 108
Infrastructure domain represented as "Horizontal/Telecommunication". 109
AIOTI – Restricted 6
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
110 Figure 2: IoT SDO and Alliance Initiatives Projection on Vertical and Horizontal Domains 111
112
The landscapes described in Figure 1 and Figure 2 show the current level of complexity of the 113
activities related to the standardization of the Internet of Things from different perspectives. 114
It has however to be noted that there is a growing awareness in the market and in the 115
standardization arena with respect to the need of IoT standards convergence. Ongoing efforts in 116
this perspective (e.g., recent actions to strengthen the collaboration among relevant SDOs 117
involved in the horizontal/telecommunication dimension) are good premises of a simplification 118
of this standards landscape in the medium term. 119
In this sense, in line with the goal and motivation of this deliverable, the experts participating in 120
the AIOTI WG03 expect this landscaping exercise will also contribute to the promotion of the 121
IoT standards convergence within the international community. 122
123
Appendix 1 (Section 5) provides the brief description of several SDO and Alliance initiatives 124
shown in Figure 1 and Figure 2. 125
126
There are different technology trends to support IoT. Appendix 2 (Section 6) shows some of 127
these technology trends. 128
129
130
AIOTI – Restricted 7
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
3. IoT Open Source Software Initiatives Landscape 131
This section briefly introduces main IoT Open Source Software (OSS) initiatives that have a 132
worldwide visibility and applicability and provides the global landscapes associated with these 133
OSS initiatives. The "IoT Open Source Initiatives Landscape (Technology and Marketing 134
Dimensions)" is a graphical representation that highlights the main activity (up to the day of 135
generating this representation) of the open source initiatives in the area of IoT, according to the 136
Business to Consumer (B2C) vs. Business to Business (B2B) (horizontal axis) and the 137
Connectivity vs. Service & App (vertical axis) classifications. The dimensions of the landscape 138
and the method used to project these OSS initiatives into the landscape shown in Figure 3 are the 139
same ones as defined in Section 2. 140
141
142 Figure 3: IoT OSS Initiatives Landscape 143
144
It is important to be noticed that a projection of the OSS initiatives into vertical and horizontal 145
industry domains, similar to the one shown in Figure 2, is not useful since the OSS initiatives are 146
mainly focusing on the horizontal domain. Appendix 1 (Section 5) provides the brief description 147
of several OSS initiatives shown in Figure 3. 148
149
AIOTI – Restricted 8
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
4. Mapping SDO/Alliance/OSS/ Initiatives into Knowledge Areas 150
This section provides the mapping of each SDO/Alliance/OSS/Project initiative, mentioned in 151
Section 2 and Section 3, into one or more of the following knowledge areas: 152
153
Communication and Connectivity knowledge area: 154
o It covers mainly specification of communication protocol layers, including 155
PHY, MAC, NWK, Transport, Application layer, and their types, e.g., 156
Wireless/Radio and Wire line; it could also include management associated 157
with the connectivity area 158
Integration/Interoperability knowledge area: 159
o It covers mainly specification of common IoT features required to provide 160
integration and interoperability 161
Applications knowledge area: 162
o It covers the support of the applications lifecycle including development 163
tools/models, deployment and management; including Analytics, application 164
supporting tools and application domain specific activities 165
Infrastructure knowledge area: 166
o It covers aspects related to the design, deployment, and management of 167
computational platforms tailored to support IoT-based applications, 168
attending requirements such as large-scale deployments, multi-tenant WSN, 169
distributed computation and storage, and resource self-adaptation, among 170
others 171
o It includes topics such as software defined networks, cloud computing, 172
Mobile Edge Computing (MEC), and fog computing 173
o It considers the use cases and points-of-view of actors such as infrastructure 174
service providers (e.g. network operators) and application service providers 175
who use these infrastructures. 176
o It could also include management associated with the infrastructure level 177
IoT Architecture knowledge area: 178
o It covers integrated/complete IoT specification solutions, including 179
architecture descriptions 180
Devices and sensor technology knowledge area: 181
o It covers mainly device/sensor lifecycles, including operating systems, 182
platforms, configuration management, sensor/actuators virtualization etc. 183
Security and Privacy knowledge area: 184
o It covers security and privacy topics 185
186
Figure 4 and Figure 5 show the mapping of the SDO/Alliance and OSS initiatives, respectively, 187
into the knowledge areas described above. In Figure 4, the "Mapping of IoT SDOs/Alliances to 188
Knowledge Areas" is a representation of the SDO and Alliance activities focusing on the 189
different aspects of IoT, while in Figure 5, the "Mapping of IoT OSS initiatives to Knowledge 190
Areas" is a representation of the OSS initiatives, focusing on the different aspects of IoT. This 191
mapping representation focuses on the main SDO/Alliance and OSS initiatives up to the day of 192
generating this representation. 193
194
195
AIOTI – Restricted 9
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
The projection of these initiatives on these knowledge areas has been accomplished based on 196
discussions among experts participating in both AIOTI WG03 and as well in the relevant 197
initiatives and on the collected information presented in Appendix 1 (Section 5). 198
199
200 Figure 4: Mapping of IoT SDO and Alliance Initiatives into Knowledge Areas; 201
(*) A large number of initiatives shown in Section 2 that focus on vertical domains, can be mapped to 202
the Application knowledge area 203 204
205 Figure 5: Mapping of IoT OSS Initiatives into Knowledge Areas 206
207
AIOTI – Restricted 10
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
5. Appendix 1: IoT SDOs, Alliances and OSSs 208
This section provides a brief description of the SDO, Alliance and OSS initiatives shown in the 209
landscapes figures included in Section 2. 210
This information has been provided by the AIOTI WG03 members on a volunteering basis, generated by 211
filling in the templates shown in Section 5.1. Official confirmation/verification coming from the relevant 212
initiatives is expected to be realized in the future. 213
214
5.1 SDO, Alliance, and OSS Initiatives Template for Information Collection 215
If the SDO/Alliance/OSS is a large initiative then the template should be applied for each of the Working 216
Groups/Technical Committees that are focusing on IoT associated with that SDO/Alliance/OSS. The 217
large initiatives identified at this stage are ITU, IEEE, IEC, 3GPP, ETSI, IETF. 218
If the required information is not available, please fill in “Unable to find information” 219
220
Description: main objective and focus of the initiative 221
Features: high level functionalities covered by the initiative 222
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); for each criterion please 223
select one or more options. 224
Interoperability level: identify the interoperability levels considered by the SDO/Alliance/OSS 225
initiative, see Appendix A for details: 226
Syntactical interoperability 227
Technical interoperability 228
Semantic interoperability 229
Organisational interoperability 230
Standards: standards and protocols proposed (SDO/Alliance) or supported (Alliance/OSS); 231
include details on whether an SDO/Alliance specified original protocols, or whether is using and 232
integrating standards and protocols developed by other SDOs 233
Supporting organizations (mainly for Alliances/OSS): main organizations that back the initiative 234
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 2, 235
related to the market domain (consumer/industrial internet –horizontal axis) and the technical 236
domain (connectivity, service&applications – vertical axis); 237
Application area: 238
whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 239
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is focusing on a 240
particular vertical industry (e.g., Smart City), when applicable, see Figure 2 in Section 2 241
Scope: mapping to knowledge areas of concerns in IoT. 242
The identified knowledge areas are (Note that an initiative can be mapped to more than 243
one knowledge areas): 244
Communication and Connectivity knowledge area: 245
o It covers mainly specification of communication protocol layers, e.g., PHY, 246
MAC, NWK, Transport, Application layer, and their types, e.g., 247
Wireless/Radio and Wire line; it could also include management associated 248
with the connectivity area 249
Integration/Interoperability knowledge area: 250
o It covers mainly specification of common IoT features required to provide 251
integration and interoperability 252
Applications knowledge area: 253
o It covers the support of the applications lifecycle including development 254
tools/models, deployment and management; including Analytics, application 255
supporting tools and application domain specific activities 256
Infrastructure knowledge area: 257
o It covers aspects related to the design, deployment, and management of 258
computational platforms tailored to support IoT-based applications, 259
AIOTI – Restricted 11
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
attending requirements such as large-scale deployments, multi-tenant WSN, 260
distributed computation and storage, and resource self-adaptation, among 261
others 262
o It includes topics such as software defined networks, cloud computing, 263
Mobile Edge Computing (MEC), and fog computing 264
o It considers the use cases and points-of-view of actors such as infrastructure 265
service providers (e.g. network operators) and application service providers 266
who use these infrastructures. 267
o It could also include management associated with the infrastructure level 268
IoT Architecture knowledge area: 269
o It covers integrated/complete IoT specification solutions, including 270
architecture descriptions 271
Devices and sensor technology knowledge area: 272
o It covers mainly device/sensor lifecycles, including operating systems, 273
platforms, configuration management, sensor/actuators virtualization etc. 274
Security and Privacy knowledge area: 275
o It covers security and privacy topics 276
277
IPR Policy Available: mention if there is any IPR policy available (e.g., FRAND); if available 278
include a reference to the description of this IPR policy 279
Specification Access: describe whether and how SDO/Alliance/OSS members and non-members 280
can get access to published and non-published (draft) specifications and/or software 281
282
283
Table 1: OSS Readiness Criteria and Options 284
1. Community 285
Multiple individuals, no formal charter 286
Mostly one single organization 287
Multiple organizations 288
Formal consortium 289
2. Commitment 290
Mostly one committer 291
Multiple volunteer committers 292
Formally appointed committers from organizations 293
Dedicated committers from organizations 294
3. Road map: 295
Sporadic releases 296
Frequent but non planned releases (release when ready) 297
Planned releases 298
Formal road map 299
4. Alignment of ongoing Standards 300
Not aligned with SDO standards 301
OSS output is aligned with SDO specifications 302
5. Licensing 303
No license 304
Type of license 305
6. Portability 306
Only one target platform 307
Multiple platforms are possible but no developed 308
Multiple platforms are developed by project 309
Platform independent 310
AIOTI – Restricted 12
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
311
Table 2: SDO/Alliance Readiness Criteria and Options 312
1. Adoption (users base) 313
No implementations 314
Reference implementations 315
Widely adopted in industry 316
317
2. Development Status 318
Under development 319
Approved with no planned revisions 320
Approved with planned revisions 321
3. Compliance 322
Not managed 323
Having compliance testing process (include test suites, method, etc. ) 324
Formal certification process 325
4. Openness 326
Very restrictive membership and closed to few entities 327
Restrictive membership procedure 328
Open by formal membership 329
Open to public 330
5. Ratification process (how the standard is being approved?) 331
Closed process done by members only with no consultation from external parties 332
Done by members and open for consultation from external parties 333
Open process for all parties interested in the ratification 334
335
More details on interoperability levels are provided below: 336
Technical Interoperability: is usually associated with hardware/software components, systems 337
and platforms that enable machine-to-machine communication to take place. This kind of 338
interoperability is often centred on (communication) protocols and the infrastructure needed for 339
those protocols to operate. 340
Syntactical Interoperability: is usually associated with data formats. Certainly, the messages 341
transferred by communication protocols need to have a well-defined syntax and encoding, even if 342
it is only in the form of bit-tables. However, many protocols carry data or content, and this can be 343
represented using high-level syntaxes such as HTML or XML 344
Semantic Interoperability: is usually associated with the meaning of content and concerns the 345
human rather than machine interpretation of the content. Thus, interoperability on this level 346
means that there is a common understanding between people of the meaning of the content 347
(information) being exchanged. 348
Organizational Interoperability, as the name implies, is the ability of organizations to 349
effectively communicate and transfer (meaningful) data (information) even though they may be 350
using a variety of different information systems over widely different infrastructures, possibly 351
across different geographic regions and cultures. Organizational interoperability depends on 352
successful technical, syntactical and semantic interoperability. 353
354
5.2 IoT SDO/Alliance Initiatives 355
This section provides a brief description of the SDO and Alliance initiatives mentioned in Section 2. 356
These brief descriptions are following and are based on the SDO and Alliance template described in 357
Section 5.1. 358
359
The official URLs of each of these initiatives can be found via Table 3, Table 4 and Table 5. 360
361
AIOTI – Restricted 13
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
362
Table 3: SDO/Alliance initiatives and their Official URLs: Part 1 363
Initiative URL
3GPP (3rd Generation Partnership
Project)
http://www.3gpp.org/
ACEA (European Automobile
manufacturing Association):
http://www.acea.be/
AEF (Agricultural Industry
Electronics Foundation)
http://www.aef-online.org/
AIOTI (Alliance for Internet of
Things Innovation)
http://www.aioti.eu/
Allseen Alliance https://allseenalliance.org/
ASHRAE https://www.ashrae.org/
AVNU http://avnu.org/
Bluetooth http://www.bluetooth.com/
Broadband Forum https://www.broadband-forum.org/
Calypso https://www.calypsonet-asso.org/
C2C-CC (Car-2-Car Communication
Consortium)
https://www.car-2-car.org/
CCC (Car Connectivity Consortium) http://carconnectivity.org/
CC-Link http://www.cclinkamerica.org
CEN (European Committee for
Standardization)
https://www.cen.eu/
CENELEC (European Committee for
Electrotechnical Standardization)
http://www.cenelec.eu/
CIA (CAN IN Automation) http://www.can-cia.org/
CIIAII (China Integration and
Innovation Alliance of Internet and
Industry)
http://www.ciiaii.org.cn/
CLEPA http://www.clepa.eu/working-groups/technical-regulations-tr/
Continua: Health Alliance http://www.continuaalliance.org/
DICOM (Digital Imaging and
Communications in Medicine)
http://dicom.nema.org/
easyway https://www.easyway-its.eu/
eCl@ss http://www.eclass.de/
ERTICO - ITS Europe http://ertico.com/
ETSI (European
Telecommunications Standards
Institute)
http://www.etsi.org/
Enocean Alliance https://www.enocean-alliance.org/
364
365
AIOTI – Restricted 14
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
366
Table 4: SDO/Alliance initiatives and their Official URLs: Part 2 367
Initiative URL
GSMA http://www.gsma.com/
HGI (Home Gateway Initiative) http://www.homegatewayinitiative.org/
HL7 International (Health Level 7) http://www.hl7.org/
HYPER/CAT http://www.hypercat.io/
IEC (International Electrotechnical
Commission)
http://www.iec.ch/
IEEE (Institute of Electrical and
Electronics Engineers)
http://www.ieee.org/
IEEE 802 LAN/MAN Standards
Committee
http://www.ieee802.org/
IEEE P2413: http://grouper.ieee.org/groups/2413/
IETF (Internet Engineering Task
Force)
http://www.ietf.org/
IHE (Integrating the Healthcare
Enterprise)
http://www.ihe.net/
IIC (Industrial Internet Consortium) http://www.industrialinternetconsortium.org/
IPSO (Internet Protocol for Smart
Object)
http://www.ipso-alliance.org/
IRTF (Internet Research Task Force) http://www.3gpp.org/
IO-Link http://www.io-link.com/
IoT Security Foundation https://www.iotsecurityfoundation.org/
IPEN (Internet Privacy Engineering
Network)
https://secure.edps.europa.eu/EDPSWEB/edps/EDPS/IPEN
ISA (International Society of
Automation)
https://www.isa.org/
ISO (International Organization for
Standardization)
http://www.iso.org/
ISO/IEC JTC 1 http://www.iso.org/iso/jtc1_home.html
ITU (International
Telecommunication Union)
http://www.itu.int/
The KNX Association http://www.knx.org/
LoRa Alliance https://www.lora-alliance.org/
368
369
AIOTI – Restricted 15
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
370
Table 5: SDO/Alliance initiatives and their Official URLs: Part 3 371
Initiative URL
OASIS https://www.oasis-open.org/
OAA( Open Automotive Alliance) http://www.openautoalliance.net
ODVA https://www.odva.org/
OGC (Open Geospatial Consortium) http://www.opengeospatial.org/
OIC (Open Interconnect Consortium) http://openinterconnect.org/
OMA (Open Mobile Alliance) http://openmobilealliance.org/
The ULE (Ultra Low Energy)
Alliance
http://www.ulealliance.org/
OMG (Object Management Group) http://www.omg.org/
OneM2M http://www.onem2m.org/
OPC (Open Platform
Communications) Foundation
https://opcfoundation.org/
The Open Group http://www.opengroup.org/
OSGi Alliance http://www.osgi.org/
PI (Profibus - Profinet) International http://www.profibus.com/
Platform Industrie 4.0 http://www.plattform-i40.de/
SAE International http://www.sae.org/
SGIP (Smart Grid Interoperability
Panel)
http://sgip.org/
Thread group http://threadgroup.org/
UPnP (Universal Plug and Play) http://upnp.org/
W3C (World Wide Web
Consortium)
http://www.w3.org/
Weightless http://www.weightless.org/
Wi-Fi Alliance http://www.wi-fi.org/
Wireless World Research Forum http://www.wwrf.ch/
The ZigBee Alliance http://www.zigbee.org/
XMPP http://xmpp.org/
372
5.2.1 3GPP (3rd Generation Partnership Project) 373
Description: 374
(adapted /shortened from www.3gpp.org) 375
The project covers cellular telecommunications network technologies, including radio 376
access, the core transport network, and service capabilities - including work on codecs, 377
security, quality of service - and thus provides complete system specifications. 3GPP 378
specifications and studies are contribution-driven, by Member companies (originating 379
from its Organizational Partners), in Working Groups and at the Technical Specification 380
Group level. 381
The Four Technical Specification Groups (TSG) in 3GPP are; 382
Radio Access Networks (RAN), 383
Service & Systems Aspects (SA), 384
Core Network & Terminals (CT) and 385
GSM EDGE Radio Access Networks (GERAN). 386
The last meeting of a cycle of Plenary meetings is TSG SA, which also has responsibility 387
for the overall coordination of work and for the monitoring of its progress. 388
AIOTI – Restricted 16
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION The 3GPP technologies from these groups are constantly evolving through Generations 389
of commercial cellular / mobile systems. Since the completion of the first LTE and the 390
Evolved Packet Core specifications, 3GPP has become the focal point for mobile systems 391
beyond 3G. 392
Backward Compatibility 393
The major focus for all 3GPP Releases is to make the system backwards and forwards 394
compatible where-ever possible, to ensure that the operation of user equipment is un-395
interrupted. A good current example of this principle has been the priority placed in the 396
working groups on backward compatibility between LTE and LTE-Advanced, so that an 397
LTE-A terminal can work in an LTE cell and an LTE terminal works in the LTE-A cell. 398
399
400
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); For each criterion please 401
select one or more options. 402
1. Adoption (users base) 403
Widely adopted in industry 404
2. Development Status 405
Approved with planned revisions 406
3. Compliance 407
Having compliance testing process (include test suites, method, etc. ) 408
Formal certification process 409
4. Openness 410
Open by formal membership 411
Open to public 412
5. Ratification process (how the standard is being approved?) 413
Done by members and open for consultation from external parties 414
415
Interoperability level: identify the interoperability levels considered by the SDO/Alliance/OSS 416
initiative, see Appendix A for details: 417
Technical interoperability 418
Organisational interoperability 419
420
Standards: standards and protocols proposed (SDO/Alliance) or supported (Alliance/OSS); 421
Include details on whether an SDO/Alliance specified original protocols, or whether they are 422
using and integrating standards and protocols developed by other SDOs 423
As referred above 3GPP covers cellular telecommunications network technologies, 424
including radio access, the core transport network, and service capabilities - including 425
work on codecs, security, quality of service - and thus provides complete system 426
AIOTI – Restricted 17
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION specifications 427
3GPP specifications also provide hooks for non-radio access to the core network, and for 428
interworking with Wi-Fi networks. 429
In particular, 3GPP specifications are taking into account IoT needs, namely know 430
through a strong focus on the CIoT (Cellular IoT) and the support of Vehicular 431
communications (LTE-Vx). 432
Supporting organizations (mainly for Alliances/OSS): main organizations that back the initiative 433
The 3rd Generation Partnership Project (3GPP) unites [Seven] telecommunications standard 434
development organizations from Europe, China, India, Japan Korea and US (ARIB, ATIS, 435
CCSA, ETSI, TSDSI, TTA, TTC), known as “Organizational Partners” 436
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 2, 437
related to the market domain (consumer/industrial internet –horizontal axis) and the technical 438
domain (connectivity, service&applications – vertical axis); 439
3GPP provides network connectivity along the entire horizontal axis and mainly in 440
vertical axis part under the horizontal axis. 441
442
Application area: 443
whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 444
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is focusing on a 445
particular vertical industry (e.g., Smart City), when applicable, see Figure 2 in Section 2. 446
447
3GPP is not chartered to focus on a particular vertical industry. It provides 448
standardized network layer technologies that are applicable to the various 449
industry domains. 450
451
Scope: mapping to knowledge areas of concerns in IoT. 452
The identified knowledge areas are (Note that an initiative can be mapped to more than 453
one knowledge areas): 454
Communication and Connectivity knowledge area 455
Integration/Interoperability knowledge area 456
Infrastructure knowledge area 457
458
IPR Policy Available: mention if there is any IPR policy available (e.g., FRAND); if available 459
include a reference to the description of this IPR policy: 460
http://www.3gpp.org/about-3gpp/legal-matters 461
http://www.3gpp.org/ftp/Information/Working_Procedures/3GPP_WP.htm#Article_55 462
http://www.3gpp.org/ftp/Inbox/2008_web_files/3gppagre.pdf 463
464
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-members 465
can get access to published and non-published (draft) specifications and/or software 466
Specification open 3GPP web site – free to access for all. 467
5.2.2 AVNU Alliance 468
Description: 469
The AVnu Alliance is a community creating an interoperable ecosystem servicing the 470
precise timing and low latency requirements of diverse applications using open standards 471
through certification. www.avnu.org 472
473
AIOTI – Restricted 18
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); For each criterion please 474
select one or more options. 475
1. Adoption (users base) 476
Widely adopted in industry 477
2. Development Status 478
Approved with planned revisions 479
3. Compliance 480
Formal certification process 481
4. Openness 482
Open by formal membership 483
5. Ratification process (how the standard is being approved?) 484
Done by members and open for consultation from external parties 485
486
Interoperability level: identify the interoperability levels considered by the SDO/Alliance/OSS 487
initiative, see Appendix A for details: 488
Technical interoperability 489
Standards: standards and protocols proposed (SDO/Alliance) or supported (Alliance/OSS); 490
Include details on whether an SDO/Alliance specified original protocols, or whether they are 491
using and integrating standards and protocols developed by other SDOs 492
Certification procedures based on Open standards (IEEE 802.1TSN, 802.1 series, IEEE 493
1588, IETF DetNet…) 494
495
Supporting organizations (mainly for Alliances/OSS): main organizations that back the initiative: 496
Leader in 497
Automotive 498
Industrial automation 499
Audio / video 500
501
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 2, 502
related to the market domain (consumer/industrial internet –horizontal axis) and the technical 503
domain (connectivity, service&applications – vertical axis); 504
Automotive 505
Industrial automation 506
Audio / video 507
508
Application area: 509
whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 510
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is focusing on a 511
particular vertical industry (e.g., Smart City), when applicable, see Figure 2 in Section 2. 512
513
Smart manufacturing 514
Automotive 515
Audi / Video 516
517
Scope: mapping to knowledge areas of concerns in IoT. 518
The identified knowledge areas are (Note that an initiative can be mapped to more than 519
one knowledge areas): 520
Communication and Connectivity knowledge area: 521
Integration/Interoperability knowledge area: 522
Infrastructure knowledge area: 523
IoT Architecture knowledge area: 524
Devices and sensor technology knowledge area: 525
Security and Privacy knowledge area: 526
AIOTI – Restricted 19
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
527
IPR Policy Available: mention if there is any IPR policy available (e.g., FRAND); if available 528
include a reference to the description of this IPR policy 529
FRAND (http://avnu.org/wp-content/uploads/2014/05/AVnu-Alliance-IPR-Policy.pdf) 530
531
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-members 532
can get access to published and non-published (draft) specifications and/or software 533
Open to everyone with a fee. 534
5.2.3 BBF (Broadband Forum): Broadband User Services (BUS) Work Area 535
Description: 536
The BBF Work Area: Broadband User Services (BUS) work area is a new area that has been 537
created after the BBF restructuring that took place in 2015. Please note that previously, the 538
Working Group that focused the most on IoT related specifications was the BroadbandHome 539
WG, which was dismissed at the moment that the BUS Work Area has been created. The 540
BroadbandHome WG provided the TR-069 that specifies the CPE WAN Management 541
Protocol, intended for communication between a CPE and Auto-Configuration Server (ACS). 542
More details on this area can be found via: https://www.broadband-543
forum.org/technical/technicalwip.php#WABUS. The following text has been copied from the 544
provided URL: 545
Mission Statement: 546
The Broadband User Services Work Area provides the broadband industry with 547
technical specifications, implementation guides, reference implementations, test 548
plans, and marketing white papers for the deployment, management, and 549
consumption of services by the broadband end user. This Work Area represents the 550
end user perspective when incorporating into the Broadband Forum architecture. 551
Business Impact: 552
The Broadband User Services Work Area develops specifications and publications to 553
create a new kind of the Broadband experience for the end user and provides new 554
means for service providers and application developers to monetize the broadband 555
user's connection. This ranges from on-demand performance assured business and 556
entertainment services, IoT services related to energy, security, environment, etc. to 557
user control of what can become the data center in the home and small business 558
managed and control with zero- touch diagnostics. All of which opens up large 559
markets and profitable business models. 560
Scope: 561
Develop and evolve the TR-069 CPE WAN Management Protocol and a Universal 562
Service Platform (USP) to cover existing use cases, machine-to-machine/IoT use 563
cases, and the virtualization of broadband user services, prioritized by their potential 564
business value 565
Develop and specify new information models to broaden the range of for which TR-566
069 and USP can be used 567
Develop requirements for broadband user devices and associated software 568
Develop test plans and training programs for Work Area protocols and requirements 569
Develop marketing white papers that supplement Work Area protocols and 570
requirements 571
572
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); For each criterion please 573
select one or more options. 574
1. Adoption (users base) 575
Reference implementations 576
Widely adopted in industry 577
578
2. Development Status 579
Approved with planned revisions 580
AIOTI – Restricted 20
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
581
3. Compliance 582
Having compliance testing process (include test suites, method, etc. ) 583
Formal certification process 584
4. Openness 585
Open by formal membership 586
Open to public 587
5. Ratification process (how the standard is being approved?) 588
Closed process done by members only with no consultation from external parties 589
590
Interoperability level: identify the interoperability levels considered by the SDO/Alliance/OSS 591
initiative 592
Syntactical interoperability 593
Technical interoperability 594
595
Standards: standards and protocols proposed (SDO/Alliance) or supported (Alliance/OSS); 596
Include details on whether an SDO/Alliance specified original protocols, or whether they are 597
using and integrating standards and protocols developed by other SDOs 598
The BBF BUS Work Area will develop and evolve the TR-069 CPE WAN Management 599
Protocol (CWMP) and a Universal Service Platform (USP) to cover existing use cases, 600
machine-to-machine/IoT use cases, and the virtualization of broadband user services, 601
prioritized by their potential business value 602
The produced documents related to TR-069 are, listed below. These can be downloaded 603
via: https://www.broadband-forum.org/technical/trlist.php: 604
o TR-069: Ammendment 1: CPE WAN Management Protocol (December 2006) 605
o TR-069: Ammendment 2: CPE WAN Management Protocol v1.1 (December 2007) 606
o TR-069: Ammendment 3: CPE WAN Management Protocol (November 2010) 607
o TR-069: Ammendment 4: CPE WAN Management Protocol (July 2011) 608
o TR-069: Ammendment 5: CPE WAN Management Protocol (November 2013) 609
o TR-330: TR-069 UPnP DM Proxy Management Guidelines 610
o TR-181: Device Data Model for TR-069 (February 2010) 611
o TR-181 Device Data Model for TR-069 Issue 2, (May 2010) 612
o TR-181 Device Data Model for TR-069 Issue 2, Amendment 2 (February 2011) 613
o TR-181 Device Data Model for TR-069, Issue 2, Amendment 5 (May 2012) 614
o TR-181 Device Data Model for TR-069 Issue 2 Amendment 6 (November 2012) 615
o TR-181 Device Data Model for TR-069 Issue 2 Amendment 7 (November 2013) 616
o TR-181 Device Data Model for TR-069 Issue 2 Amendment 8 (september 2014 617
o TR-154: TR-069 Data Model XML User Guide (March 2012) 618
o TR-142: Framework for TR-069 enabled PON devices (March 2008) 619
o TR-142: Framework for TR-069 enabled PON devices Issue 2 (February 2010) 620
o TR-140: TR-069 Data Model for Storage Service Enabled Devices, Amendment 1 621
(April 2010) 622
o TR-140: TR-069 Data Model for Storage Service Enabled Devices. Issue 1.1: 623
(December 2007) 624
o TR-135: Data Model for a TR-069 Enabled STB (December 2007) 625
o TR-106: Amendment 1: Data Model Template for TR-069-Enabled Devices 626
(November 2006) 627
o TR-106: DSLHomeTM Data Model Template for TR-069 Enabled Devices 628
(September 2006) 629
o TR-098: Internet Gateway Device Data Model for TR-069 (December 2006) 630
o TR-157: Component Objects for CWMP (March 2009) 631
For more details on the CWMP (CPE WAN Management Protocol) protocol, please visit: 632
https://www.broadband-forum.org/cwmp.php 633
https://www.broadband-forum.org/cwmptools.php 634
635
AIOTI – Restricted 21
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
Supporting organizations (mainly for Alliances/OSS): main organizations that back the initiative: 636
BUS is a BBF Work Area. 637
638
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 2, 639
related to the market domain (consumer/industrial internet –horizontal axis) and the technical 640
domain (connectivity, service&applications – vertical axis); 641
Market domain: Closer to the Consumer market edge of the vertical axis. 642
Technical domain: Located on the horizontal axis, to show that it is equally focusing on 643
connectivity and service&applications. 644
645
Application area: whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 646
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is focusing on a 647
particular vertical industry (e.g., Smart City), when applicable, see Figure 2 in Section 2 648
The BUS Work Area is mainly focusing on horizontal industries. It needs to be 649
emphasized that the CWMP protocol specified in TR-069 is widely applied/used in the 650
Home/Building area. 651
652
Scope: mapping to knowledge areas of concerns in IoT. 653
The identified knowledge areas are (Note that an initiative can be mapped to more than 654
one knowledge areas): 655
Communication and Connectivity knowledge area: 656
o covers mainly the Application layer 657
Infrastructure knowledge area: 658
o Covers aspects related to the design, deployment, and management of 659
computational platforms tailored to support IoT-based applications, 660
attending requirements such as large-scale deployments, multi-tenant WSN, 661
distributed computation and storage, and resource self-adaptation, among 662
others 663
664
IPR Policy Available: 665
Information regarding the used BBF IPR policy can be found via: 666
https://www.broadband-forum.org/technical/ipdeclarations.php. 667
668
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-members 669
can get access to published and non-published (draft) specifications and/or software 670
For members: 671
Access of published and non-published specifications for members and non-672
members is open and free of payment. 673
For non-members: 674
Access of published specifications is open and free of payment 675
Access of non-published specifications is not possible. 676
Other SDO/Alliances/OSS initiative can access non-published documents via 677
written liaisons 678
679
5.2.4 ETSI (European Telecommunications Standards Institute) 680
This section provides a brief description of the ETSI SDO initiative and its IoT related Technical 681
Committees (TCs) and Industry Specification Groups (ISGs). 682
683
ETSI initiative 684
Description: 685
ETSI, the European Telecommunications Standards Institute, produces globally-686
applicable standards for Information and Communications Technologies (ICT), including 687
AIOTI – Restricted 22
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
fixed, mobile, radio, converged, broadcast and Internet technologies. Our standards 688
enable the technologies on which business and society rely. For example, our standards 689
for GSM™, DECT™, Smart Cards and electronic signatures have helped to revolutionize 690
modern life all over the world. 691
692
ETSI are officially recognized by the European Union as a European Standards 693
Organization. 694
695
ETSI are a not-for-profit organization with more than 800 member organizations 696
worldwide, drawn from 64 countries and five continents. Members include the world’s 697
leading companies and innovative R&D organizations. 698
699
ETSI are at the forefront of emerging technologies. We address the technical issues 700
which will drive the economy of the future and improve life for the next generation. 701
702
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); For each criterion 703
please select one or more options. 704
705
1. Adoption (users base) 706
Widely adopted in industry 707
2. Development Status 708
Depends on group and specification 709
3. Compliance 710
Having compliance testing process (include test suites, method, etc. ) 711
4. Openness 712
Open to public – most groups some only open to members 713
714
5. Ratification process (how the standard is being approved?) 715
Done by members and open for consultation from external parties 716
717
Interoperability level: identify the interoperability levels considered by the 718
SDO/Alliance/OSS initiative, see Appendix A for details: 719
Organisational interoperability 720
721
Standards: standards and protocols proposed (SDO/Alliance) or supported 722
(Alliance/OSS); Include details on whether an SDO/Alliance specified original protocols, 723
or whether they are using and integrating standards and protocols developed by other 724
SDOs 725
Depends on specification 726
727
Supporting organizations (mainly for Alliances/OSS): main organizations that back the 728
initiative 729
730
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 731
2, related to the market domain (consumer/industrial internet –horizontal axis) and the 732
technical domain (connectivity, service&applications – vertical axis); 733
Multiple domains 734
735
Application area: 736
whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 737
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is 738
AIOTI – Restricted 23
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION focusing on a particular vertical industry (e.g., Smart City), when applicable, see 739
Figure 2 in Section 2 740
Different specifications cover different areas. 741
742
Scope: mapping to knowledge areas of concerns in IoT. 743
The identified knowledge areas are (Note that an initiative can be mapped to more 744
than one knowledge areas): 745
Different specifications cover different areas 746
747
Communication and Connectivity knowledge area: 748
Integration/Interoperability knowledge area: 749
Applications knowledge area: 750
Infrastructure knowledge area: 751
IoT Architecture knowledge area: 752
Devices and sensor technology knowledge area: 753
Security and Privacy knowledge area: 754
755
IPR Policy Available: mention if there is any IPR policy available (e.g., FRAND); if 756
available include a reference to the description of this IPR policy 757
FRAND – ETSI IPR policy - http://www.etsi.org/about/how-we-758
work/intellectual-property-rights-iprs 759
760
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-761
members can get access to published and non-published (draft) specifications and/or 762
software 763
Specification open ETSI web site – free to access for all. 764
765
ETSI TC ATTM 766
767
Description: 768
The scope of Technical Committee (TC) ATTM addresses Access, Terminals, 769
Transmission and Multiplexing including all aspects within the ETSI scope covering 770
cabling, installations, signal transmission, multiplexing and other forms of signal 771
treatment up to digitalization in private and public domain, excluding those aspects that 772
relate to Hybrid Fibre-Coaxial cable networks which are covered by TC Cable. A close 773
cooperation and collaboration will be maintained between TC Cable and TC ATTM in 774
areas of mutual interest. 775
776
TC ATTM closely collaborates with the Technical Body(ies) (TB) responsible for 777
Communications Networking and Services and the exact border line between the 778
activities will be adapted to the members’ needs. Signalling protocols are excluded from 779
ATTM, except for identified technologies like POTS interaction between terminals and 780
networks, e.g. seizing, releasing the line, dialling and calling. 781
782
TC ATTM studies the applicability and implementation of ISO / IEC / CENELEC as 783
well as ITU / ETSI drafts and deliverables related to the Residential, Professional, 784
Industrial and Operators’ premises including communication equipment. The activities 785
cover all relevant influences from other organizations, coordination, convergence and 786
AIOTI – Restricted 24
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
standardization of the various initiatives and an efficient liaising effort with relevant 787
bodies. 788
789
TC ATTM primarily focuses on: 790
Attracting and enhancing expertise with the objective to develop and maintain ETSI 791
deliverables on all aspects of infrastructures and transmission within its scope 792
Where requested by another ETSI TB, support their work on infrastructures and 793
transmission aspects 794
Access network aspects within its scope 795
796
Within its scope, TC ATTM addresses the specific technology, equipment, installations 797
and regulatory aspects of the physical layer, e.g. of: 798
Transmission issues of interfaces 799
Frequency management on the non-radio Communication Infrastructures 800
Analogue and digital presented Communication interfaces of balanced wired (twisted 801
pair), and unbalanced wires (coaxial) and optical fibre Infrastructures 802
Interfaces based on new technologies as far as they are relevant for Communication 803
Infrastructures 804
Point-to-point and point-to-multipoint radio systems and infrastructures used for the fixed 805
service (core and access networks), covering all equipment aspects including antenna 806
parameters 807
Transmission related aspects of network architecture(s) (including protection issues) 808
Specification of the transmission functions and performance of the network elements 809
such as transmission paths, path elements, sections, systems, functional entities, antenna, 810
cable and optical fibre 811
812
Within its scope, TC ATTM will: 813
advise the relevant ESO bodies on transmission aspects of service requirements 814
work on end to end transmission over networks in support of customer’s 815
applications 816
support the development of appropriate interfaces to network based services 817
always in collaboration with relevant TB 818
819
Additionally each one of the ATTM WG in their area of activity, under the leadership of 820
TC ATTM will contribute to the promotion at a global level of the existing ETSI 821
deliverables to the development of a consistent approach to standardization of emerging 822
technologies and services with a view towards producing global standards. 823
824
TS 105 XXX Networks connecting digital multi-services in cities. 825
TS 105 174 Series Eco-efficient Engineering in order to support deployment of eco-826
efficient networks and sites. 827
ES 205 200 Series Global Key Performance Indicators - to provide ICT users with tools 828
to monitor their eco-efficiency and energy management in compliance with Kyoto 829
Protocol on climate change and reduction of greenhouse gas emissions. 830
TS 105 175-1 Engineering of plastic optical fibre networks within building. 831
EN 305 XXX Eco-efficient End of Life - to provide ICT suppliers and users with tools to 832
implement "Green" tools (indicators, recognized Green levels) to monitor waste 833
processing of ICT equipment in compliance with Kyoto Protocol on climate change and 834
reduction of greenhouse gas emissions. 835
AIOTI – Restricted 25
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
ES Planned Eco-efficient End of Life - to provide ICT suppliers and users with tools to 836
implement "Green" tools (indicators, recognized Green levels) to monitor sustainability 837
of broadband solutions. 838
839
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); For each criterion please 840
select one or more options. 841
842
1. Adoption (users base) 843
Widely adopted in industry 844
845
2. Development Status 846
Depends on specification, some published others under development 847
3. Compliance 848
Having compliance testing process (include test suites, method, etc. ) 849
4. Openness 850
Open to public – most groups some only open to members 851
852
5. Ratification process (how the standard is being approved?) 853
Done by members and open for consultation from external parties 854
855
Interoperability level: identify the interoperability levels considered by the 856
SDO/Alliance/OSS initiative, see Appendix A for details: 857
Organisational interoperability. 858
859
Standards: standards and protocols proposed (SDO/Alliance) or supported 860
(Alliance/OSS); Include details on whether an SDO/Alliance specified original protocols, 861
or whether they are using and integrating standards and protocols developed by other 862
SDOs 863
Depends on specification 864
865
Supporting organizations (mainly for Alliances/OSS): main organizations that back the 866
initiative 867
Not relevant 868
869
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 870
2, related to the market domain (consumer/industrial internet –horizontal axis) and the 871
technical domain (connectivity, service&applications – vertical axis); 872
Multiple domains 873
874
Application area: 875
whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 876
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is 877
focusing on a particular vertical industry (e.g., Smart City), when applicable, see 878
Figure 2 in Section 2 879
Different specifications cover different areas. Smart City focus in some 880
specifications 881
882
Scope: mapping to knowledge areas of concerns in IoT. 883
The identified knowledge areas are (Note that an initiative can be mapped to more 884
than one knowledge areas): 885
AIOTI – Restricted 26
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION Communication and Connectivity knowledge area: 886
Integration/Interoperability knowledge area: 887
Applications knowledge area: 888
Infrastructure knowledge area: 889
IoT Architecture knowledge area: 890
Devices and sensor technology knowledge area: 891
Security and Privacy knowledge area: 892
893
IPR Policy Available: mention if there is any IPR policy available (e.g., FRAND); if 894
available include a reference to the description of this IPR policy 895
FRAND – ETSI IPR policy - http://www.etsi.org/about/how-we-896
work/intellectual-property-rights-iprs 897
898
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-899
members can get access to published and non-published (draft) specifications and/or 900
software 901
Specification open ETSI web site – free to access for all. 902
903
ETSI TC CYBER 904
Description: 905
Responsibility: 906
The main responsibilities of ETSI TC CYBER are: 907
To act as the ETSI centre of expertise in the area of Cyber Security 908
Advise other ETSI TCs and ISGs with the development of Cyber Security 909
requirements 910
To develop and maintain the Standards, Specifications and other deliverables to 911
support the development and implementation of Cyber Security standardization 912
within ETSI 913
To collect and specify Cyber Security requirements from relevant stakeholders 914
To identify gaps where existing standards do not fulfil the requirements and 915
provide specifications and standards to fill these gaps, without duplication of 916
work in other ETSI committees and partnership projects 917
To ensure that appropriate Standards are developed within ETSI in order to meet 918
these requirements 919
To perform identified work as sub-contracted from ETSI Projects and ETSI 920
Partnership Projects 921
To coordinate work in ETSI with external groups such as Cyber Security 922
Coordination group in CEN CENELEC and ENISA 923
To answer to policy requests related to Cyber Security, and security in broad 924
sense in the ICT sector. 925
926
Areas of activity 927
The activities of TC CYBER will be performed in close co-operation with 928
relevant standards activities within and outside ETSI. 929
The activities of ETSI TC CYBER include the following broad areas: 930
Cyber Security 931
Security of infrastructures, devices, services and protocols 932
Security advice, guidance and operational security requirements to users, 933
manufacturers and network and infrastructure operators 934
Security tools and techniques to ensure security 935
AIOTI – Restricted 27
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION Creation of security specifications and alignment with work done in other TCs. 936
Organisation and working methods 937
TC CYBER shall work in accordance with the normal rules as given in the ETSI 938
Directives and, in particular, the Technical Working Procedures. 939
940
The tasks described above will require liaisons with relevant bodies within ETSI 941
as well as outside ETSI according to the rules prescribed by the ETSI Directives. 942
943
Internal to ETSI: 944
ETSI TCs that have a requirement for Security in their work. Examples are LI, 945
SAGE, and SmartM2M. It is recognised that Security is a vertical activity and 946
undertaken within groups, whilst TC CYBER may provide advice, guidance and 947
horizontal coordination 948
ETSI ISGs that have a requirement for security in their work 949
950
External to ETSI: 951
Coordination with European, National and International standards organisations, 952
as well as other bodies such as ENISA, 3GPP, oneM2M, and Professional 953
organisations etc. 954
955
Participation 956
Participation in TC CYBER is open to all ETSI members in accordance with the 957
Technical Working Procedures. Observers and non-members may participate at 958
the discretion of the Chairman in-line with clause 1.4 of the Technical Working 959
Procedures.. 960
961
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); For each criterion please 962
select one or more options. 963
1. Adoption (users base) 964
Widely adopted in industry 965
2. Development Status 966
Depends on specification, some published others under development 967
3. Compliance 968
Having compliance testing process (include test suites, method, etc. ) 969
4. Openness 970
Open to public – most groups some only open to members 971
972
5. Ratification process (how the standard is being approved?) 973
Done by members and open for consultation from external parties 974
975
Interoperability level: identify the interoperability levels considered by the 976
SDO/Alliance/OSS initiative, see Appendix A for details: 977
Organisational interoperability 978
979
Standards: standards and protocols proposed (SDO/Alliance) or supported 980
(Alliance/OSS); Include details on whether an SDO/Alliance specified original protocols, 981
or whether they are using and integrating standards and protocols developed by other 982
SDOs 983
Depends on specification 984
985
AIOTI – Restricted 28
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
Supporting organizations (mainly for Alliances/OSS): main organizations that back the 986
initiative 987
Not relevant 988
989
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 990
2, related to the market domain (consumer/industrial internet –horizontal axis) and the 991
technical domain (connectivity, service&applications – vertical axis); 992
Multiple domains 993
994
Application area: 995
whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 996
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is 997
focusing on a particular vertical industry (e.g., Smart City), when applicable, see 998
Figure 2 in Section 2 999
Different specifications cover different areas. Smart City focus in some 1000
specifications 1001
1002
Scope: mapping to knowledge areas of concerns in IoT. 1003
The identified knowledge areas are (Note that an initiative can be mapped to more 1004
than one knowledge areas): 1005
Security and Privacy knowledge area: 1006
1007
IPR Policy Available: mention if there is any IPR policy available (e.g., FRAND); if 1008
available include a reference to the description of this IPR policy 1009
FRAND – ETSI IPR policy - http://www.etsi.org/about/how-we-1010
work/intellectual-property-rights-iprs 1011
1012
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-1013
members can get access to published and non-published (draft) specifications and/or 1014
software 1015
Specification open ETSI web site – free to access for all. 1016
1017
ETSI TC DECT 1018
Description: 1019
DECT Ultra Low Energy (ULE) is a technology based on DECT, intended for 1020
Machine-to-Machine communications such as Home and Industrial automation. The 1021
main characteristics of the technology are ultra low power consumption and wider 1022
coverage 1023
The technology is suitable for sensors, alarms, Machine-to-Machine (M2M) 1024
applications, utility meters and industrial automation. 1025
ETSI TC DECT has the overall responsibility over DECT and ULE technologies. 1026
1027
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); For each criterion please 1028
select one or more options. 1029
1030
1. Adoption (users base) 1031
Reference implementations and first commercial products of Phase 1 (see 1032
standards) 1033
2. Development Status 1034
Approved with planned revisions 1035
AIOTI – Restricted 29
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
3. Compliance 1036
Formal certification process (managed by the ULE-Alliance) 1037
4. Openness 1038
Open to public 1039
5. Ratification process (how the standard is being approved?) 1040
Done by members and open for consultation from external parties 1041
1042
Interoperability level: identify the interoperability levels considered by the 1043
SDO/Alliance/OSS initiative, see Appendix A for details: 1044
Complete technical interoperability from Physical layer to application layer 1045
1046
Standards: standards and protocols proposed (SDO/Alliance) or supported 1047
(Alliance/OSS); Include details on whether an SDO/Alliance specified original protocols, 1048
or whether they are using and integrating standards and protocols developed by other 1049
SDOs 1050
TC DECT is the original developing organization of ULE technology . 1051
Other organizations may provide application protocols 1052
Standards: 1053
Main Specifications: ETSI TS 102 939-1 (DECT ULE phase 1) and ETSI 1054
TS 102 939-2 (DECT ULE phase 2) 1055
ULE functions are added to the DECT Common Interface specification 1056
(ETSI EN 300 175 parts 1 to 8) where technical details organized by 1057
layers can be found. 1058
ULE uses its own security model based on CCM (algorithms and 1059
procedures defined in EN 300 175-7) 1060
From radio compliance perspective, ULE re-uses the Harmonised ENs of 1061
DECT (EN 301 406 and EN 301 908-10) 1062
Under developing: 1063
Repeaters 1064
ULE-Alliance has developed an own application protocol (the FUN) , 1065
however ULE technology is open to any other higher layer. 1066
1067
Supporting organizations 1068
Open to ETSI membership 1069
Active participants from industry vendors and operators 1070
An industry Alliance, the ULE-Alliance is in charge of promoting the technology 1071
and driving the certification program. 1072
1073
Domain: 1074
position the initiative, with respect to the four quadrants, see Figure 1 in Section 1075
2, related to the market domain (consumer/industrial internet –horizontal axis) 1076
and the technical domain (connectivity, service&applications – vertical axis); 1077
Both consumer (home automation) and industrial markets addressed 1078
(industry automation) 1079
both horizontal and domain specific. Strong in Retail and Operators 1080
business. 1081
Technical domain :connectivity / communications and Networking 1082
1083
Application area: 1084
Home / building (Smart living) 1085
AIOTI – Restricted 30
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
Smart cities 1086
Energy 1087
Healthcare (Smart living) 1088
Wearables 1089
Smart manufacturing/ industry automation 1090
Scope: mapping to knowledge areas of concerns in IoT. 1091
The primary knowledge areas is Communication and Connectivity knowledge 1092
area: 1093
An additional knowledge areas is Devices and sensor technology knowledge 1094
area: 1095
1096
IPR Policy Available: mention if there is any IPR policy available (e.g., FRAND); if 1097
available include a reference to the description of this IPR policy 1098
FRAND 1099
1100
Specification Access: ETSI specifications are publicly available 1101
1102
1103
1104
ETSI TC ERM 1105
Description: 1106
Responsibility 1107
The Horizontal TC (EMC and Radio spectrum matters) has the primary 1108
responsibility for: 1109
ETSI deliverables (in whole or in part) dealing with EMC; 1110
ETSI deliverables (in whole or in part) dealing with radio spectrum parameters 1111
concerned with inter-system characteristics; 1112
co-ordination of ETSI positions on the efficient use of the radio spectrum and 1113
spectrum allocations; 1114
1115
Such ETSI deliverables may include harmonised standards intended to be used for 1116
regulatory purposes. 1117
co-ordination of ETSI positions on the efficient use of the radio spectrum and 1118
spectrum allocations; 1119
a range of ETSI deliverables dealing with radio equipment and systems where 1120
they are not undertaken by other ETSI groups, the deliverables may include 1121
product and harmonised (regulatory) standards concerned with inter-system 1122
characteristics; 1123
1124
The TC (EMC and Radio Spectrum Matters) is the formal interface in respect of 1125
radio spectrum and electromagnetic compatibility between ETSI and EC/EFTA, 1126
including RSCOM and RSPG; other bodies in the radio and EMC field, notably 1127
the CEPT ECC, relevant CEN and CENELEC committees, EUROCAE and EBU, 1128
relevant ICAO and ITU groups; IEC and CISPR. 1129
1130
Areas of activity 1131
1132
The activities of TC-ERM (EMC and Radio Spectrum Matters) falls into two 1133
broad areas of work, horizontal across ETSI and vertical project orientated 1134
AIOTI – Restricted 31
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION activities. All TC-ERM activities have a common theme of electromagnetic 1135
and/or radio spectrum compatibility. 1136
1137
Horizontal Activities 1138
Studies of the EMC and radio parameters and their methods of 1139
measurement - taking due account of the work in the international 1140
community and specifically IEC; 1141
Preparation of ETSI deliverables as required by ETSI members or those to 1142
support mandated work from the EC/EFTA in support of EU Directives or 1143
as requested by CEPT ECC; 1144
Preparation of ETSI deliverables including harmonised standards used to 1145
describe the electromagnetic and/or radio environment; 1146
Co-ordination of ETSI positions on the efficient use of the radio spectrum 1147
and spectrum allocations and the administration of the MoU between 1148
CEPT ECC and ETSI. These activities will be carried out in close co-1149
operation with relevant ETSI Technical Bodies; 1150
TC-ERM (EMC and Radio Spectrum Matters) also provides ETSI with a 1151
centre of technical expertise in the radio and EMC fields, able to offer 1152
advice to ETSI Technical Bodies, the ETSI Board, and the ETSI General 1153
Assembly. 1154
1155
Vertical Project Oriented Activities 1156
Following from the restructuring of the work of TC-RES, TC-ERM is the 1157
parent body for project oriented (vertical) radio equipment and system 1158
standardisation activities. TC-ERM, via designated Task Groups, provides 1159
ETSI with a range of deliverables for sundry radio equipment and 1160
systems. TC‑ERM is also designated as the host radio project activities 1161
that have entered their maintenance phase. 1162
1163
A non exhaustive activity list of radio standardisation activities includes:- 1164
Aeronautical - Automotive - Broadcast and broadcast ancillary equipment 1165
– CDMA for private and public access mobile radio - Short range devices 1166
including generic devices, avalanche beacons, inductive data 1167
communications, RF identification devices - Intelligent transport systems 1168
including road transport & traffic telematics - Maritime - Private mobile 1169
radio (PMR) including digital mobile radio - Measurement Uncertainty - 1170
Radio site engineering - Wireless medical devices - Wideband data 1171
systems - Ultra wideband (UWB) including automotive radar and short 1172
range communication plus Harmonised standards for the IMT-2000 1173
family (joint with MSG). 1174
1175
Organisation and working methods within the Committee 1176
TC-ERM has organised itself following the principles of ‘delayering’ in 1177
accordance with ETSI Technical Working Procedures by the creation of two 1178
Working Groups; ERM-RM (Radio Matters) and ERM-EMC (Electromagnetic 1179
Compatibility) together with a range of project oriented Task Groups, as indicated 1180
above, designated to undertake a specific task and when the task is completed to 1181
enter a dormant mode or be disbanded as appropriate. 1182
1183
AIOTI – Restricted 32
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION For work items of a radio spectrum and/or regulatory nature subject to the 1184
CEPT/ETSI MoU, joint groups with CEPT ECC and its working groups are 1185
planned if needed to facilitate the necessary coordination. 1186
1187
Co-operation with CENELEC - for EMC work items and specifically mandated 1188
activities, joint groups will be established where appropriate. Similarly in the 1189
maritime sector joint groups with the IEC TC80 are planned. 1190
1191
EN 303 204 Radio equipment to be used in the 870 MHz to 876 MHz 1192
frequency range with power levels ranging up to 500 mW. 1193
EN 300 220 Radio equipment to be used in the 25 MHz to 1 000 MHz 1194
frequency range with power levels ranging up to 500 mW: 1195
SSN is active in a number of Smart City application domains (e.g. Smart Street 1196
Lighting) and device connections via RF Mesh infrastructure to back-office 1197
applications meet many Smart City requirements as well as Smart Metering. 1198
Capacity available is sufficient to enable Smart City infrastructure to be shared by 1199
multiple applications and provide capacity for the future growth as Smart City 1200
services develop. 1201
Emerging interoperability specifications (e.g. Wi-SUN) are consistent with EN 1202
303 204 as well as EN 300 220 - continues to be principal underlying spectrum 1203
access standard for licence exempt devices. 1204
DTR/ERM-TGDMR-340 Technical Report on Smart Grid Systems and Other 1205
Radio Systems suitable for Utility Operations and their long-term spectrum 1206
requirements. 1207
1208
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); For each criterion please 1209
select one or more options. 1210
1. Adoption (users base) 1211
Widely adopted in industry 1212
2. Development Status 1213
Depends on specification, some published others under development 1214
3. Compliance 1215
Having compliance testing process (include test suites, method, etc. ) 1216
4. Openness 1217
Open to public – most groups some only open to members 1218
1219
5. Ratification process (how the standard is being approved?) 1220
Done by members and open for consultation from external parties 1221
1222
Interoperability level: identify the interoperability levels considered by the 1223
SDO/Alliance/OSS initiative, see Appendix A for details: 1224
Organisational interoperability. 1225
1226
Standards: standards and protocols proposed (SDO/Alliance) or supported 1227
(Alliance/OSS); Include details on whether an SDO/Alliance specified original protocols, 1228
or whether they are using and integrating standards and protocols developed by other 1229
SDOs 1230
Depends on specification 1231
1232
Supporting organizations (mainly for Alliances/OSS): main organizations that back the 1233
initiative 1234
AIOTI – Restricted 33
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
Not relevant 1235
1236
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 1237
2, related to the market domain (consumer/industrial internet –horizontal axis) and the 1238
technical domain (connectivity, service&applications – vertical axis); 1239
Multiple domains 1240
1241
Application area: 1242
whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 1243
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is 1244
focusing on a particular vertical industry (e.g., Smart City), when applicable, see 1245
Figure 2 in Section 2 1246
Different specifications cover different areas. Smart City focus in some 1247
specifications 1248
1249
Scope: mapping to knowledge areas of concerns in IoT. 1250
The identified knowledge areas are (Note that an initiative can be mapped to more 1251
than one knowledge areas): 1252
Communication and Connectivity knowledge area: 1253
Integration/Interoperability knowledge area: 1254
Applications knowledge area: 1255
Infrastructure knowledge area: 1256
IoT Architecture knowledge area: 1257
Devices and sensor technology knowledge area: 1258
Security and Privacy knowledge area: 1259
1260
IPR Policy Available: mention if there is any IPR policy available (e.g., FRAND); if 1261
available include a reference to the description of this IPR policy 1262
FRAND – ETSI IPR policy - http://www.etsi.org/about/how-we-1263
work/intellectual-property-rights-iprs 1264
1265
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-1266
members can get access to published and non-published (draft) specifications and/or 1267
software 1268
Specification open ETSI web site – free to access for all. 1269
1270
ETSI TC HF (Human Factors) 1271 1272
Description: 1273
The Human Factors committee is the technical body within ETSI responsible for Human Factors 1274
issues in all areas of Information and Communications Technology (ICT). It produces standards, 1275
guidelines and reports that set the criteria necessary to build optimum usability into the emerging 1276
digital networked economy (DNE). 1277
1278
The HF committee co-operates with other groups within ETSI and outside to assist them to 1279
produce standards, or other deliverables, which are in accordance with good Human Factors 1280
practice. Within ETSI it has a special responsibility for “Design for All” addressing the needs of 1281
all users, including young children, seniors and disabled people. 1282
1283
Human Factors is the scientific application of knowledge about human capacities and limitations 1284
AIOTI – Restricted 34
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
in order to make products, systems, services and environments effective, efficient and easy for 1285
everyone to use. It is a key factor for the commercial success of any ICT product or service in the 1286
digital networked economy. 1287
1288
New work area resulting from discussion with: 1289
EDF (European Disability Forum), 1290
European Blind Union, 1291
ANEC, 1292
European Age Platform. 1293
1294
1295
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); For each criterion please select 1296
one or more options. 1297
1298
1. Adoption (users base) 1299
Widely adopted in industry 1300
2. Development Status 1301
Depends on specification, some published others under development 1302
3. Compliance 1303
Having compliance testing process (include test suites, method, etc. ) 1304
4. Openness 1305
Open to public 1306
1307
5. Ratification process (how the standard is being approved?) 1308
Done by members and open for consultation from external parties 1309
1310
Interoperability level: identify the interoperability levels considered by the SDO/Alliance/OSS 1311
initiative, see Appendix A for details: 1312
Organisational interoperability. 1313
1314
Standards: standards and protocols proposed (SDO/Alliance) or supported (Alliance/OSS); 1315
Include details on whether an SDO/Alliance specified original protocols, or whether they are 1316
using and integrating standards and protocols developed by other SDOs 1317
Depends on specification 1318
1319
Supporting organizations (mainly for Alliances/OSS): main organizations that back the initiative 1320
Not relevant 1321
1322
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 2, 1323
related to the market domain (consumer/industrial internet –horizontal axis) and the technical 1324
domain (connectivity, service&applications – vertical axis); 1325
Multiple domains 1326
1327
Application area: 1328
whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 1329
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is focusing on a 1330
particular vertical industry (e.g., Smart City), when applicable, see Figure 2 in Section 2 1331
Focus on access for all 1332
1333
Scope: mapping to knowledge areas of concerns in IoT. 1334
The identified knowledge areas are (Note that an initiative can be mapped to more than 1335
one knowledge areas): 1336
Access for all – human interaction 1337
1338
AIOTI – Restricted 35
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
IPR Policy Available: mention if there is any IPR policy available (e.g., FRAND); if available 1339
include a reference to the description of this IPR policy 1340
FRAND – ETSI IPR policy - http://www.etsi.org/about/how-we-work/intellectual-1341
property-rights-iprs 1342
1343
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-members 1344
can get access to published and non-published (draft) specifications and/or software 1345
Specification open ETSI web site – free to access for all. 1346
1347
ETSI TC ITS (Intelligent Transport Systems) 1348
Description: 1349
Responsibility 1350
Development and maintenance of Standards, Specifications and other deliverables 1351
to support the development and implementation of ITS Service provision across 1352
the network, for transport networks, vehicles and transport users, including 1353
interface aspects and multiple modes of transport and interoperability between 1354
systems, but not including ITS application standards, radio matters, and EMC. 1355
1356
Scope includes communication media, and associated physical layer, transport 1357
layer, network layer, security, lawful intercept and the provision of generic web 1358
services 1359
Areas of Activity 1360
The activities of TC ITS will be performed in close co-operation with relevant 1361
standards activities within and outside ETSI. The activities of TC ITS include the: 1362
1363
To work in close liaison with other SDOs, particularly those responsible for 1364
providing application standards, to ensure seamless access and interoperability of 1365
Standards to support ITS service provision 1366
1367
To act as a focal point for initial standardisation and awareness of standardisation 1368
requirements and expertise for European development and provision of ITS 1369
services. 1370
1371
To act as a focal point and centre of expertise and excellence within ETSI in 1372
respect of Intelligent Transport Systems and coordinate with other ETSI 1373
committees, and where appropriate to represent ETSI in respect of ITS 1374
1375
To liaise and cooperate with the European Commission and ITS trade 1376
organisations in respect of enabling ITS service provision, quality assurance and 1377
certification 1378
1379
To liaise to ETSI ERM for ERM related spectrum matters and EMC, This 1380
includes that ERM and its TG’s remain as the focal point for spectrum related 1381
liaisons to ECC. 1382
1383
To organize regular meetings/workshops with appropriate stakeholders. 1384
1385
To establish external relationships (and joint working groups) where and 1386
whenever needed, including co-operation with 3GPP, CEN, CENELEC, ISO, ITU 1387
etc. Formal relationships will be established using the normal processes via the 1388
ETSI Secretariat (NIM/Partnerships). 1389
1390
AIOTI – Restricted 36
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
The technical standardization work of the following bodies is explicitly excluded: 1391
GSM-R and Interoperability issues under the Railway Directive being handled by 1392
TC RT, 1393
Air Traffic Management and Aeronautical issues being handled by ERM-TG25, 1394
Maritime issues being handled by ERM-TG26, 1395
Automotive radar issues being handled by ERM-TG31B. 1396
Organization and Working Methods 1397
TC ITS shall work in accordance with the normal rules as given in the ETSI 1398
Directives and, in particular, the Technical Working Procedures. 1399
TC ITS shall prepare ETSI deliverables of the type of EG, TR, TS, ES and EN. 1400
TC ITS shall provide progress reports to the ETSI Board and OCG from time to 1401
time. 1402
TC ITS will liaise with other ETSI TBs (particularly with TC ERM, TC MSG, TC 1403
TISPAN, TC BRAN, and TC RT) and other SDOs, including 3GPP, ITU (APSC 1404
TELEMOV), CEN and CENELEC as appropriate. 1405
TC ITS shall operate in accordance with the MoU with ECC. In particular, it 1406
should liaise through ERM with ECC on ITS related radio matters. 1407
1408
Existing related work items should remain in current Technical Bodies except 1409
where it is mutually agreed to transfer the work. Updates to existing ETSI 1410
standard deliverables should be done within the appropriate Technical Bodies and 1411
be co-ordinated with TC ITS where relevant. 1412
1413
Where appropriate, joint working groups with other Technical Bodies may be 1414
created to develop deliverables for submission to the lead body. 1415
1416
One of ‘verticals’ of Smart City. 1417
Applies ICT to Transport sector to increase efficiency, sustainability and 1418
accessibility and raise level of safety and security. 1419
Includes minimising environmental impact (CO2 emissions and fuel 1420
consumption) and improving traffic management. 1421
ITS has applications in road safety, traffic control, fleet and freight management 1422
and location-based services, providing driver assistance and hazard warnings and 1423
supporting emergency services. 1424
(In conjunction with CEN) first release of standards for initial deployment of Co-1425
operative ITS - will enable vehicles made by different manufacturers to 1426
communicate with each other and with road infrastructure systems. 1427
1428
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); For each criterion please 1429
select one or more options. 1430
1431
1. Adoption (users base) 1432
Widely adopted in industry 1433
2. Development Status 1434
Depends on specification, some published others under development 1435
3. Compliance 1436
Having compliance testing process (include test suites, method, etc. ) 1437
4. Openness 1438
Open to public – most groups some only open to members 1439
1440
5. Ratification process (how the standard is being approved?) 1441
AIOTI – Restricted 37
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION Done by members and open for consultation from external parties 1442
1443
Interoperability level: identify the interoperability levels considered by the 1444
SDO/Alliance/OSS initiative, see Appendix A for details: 1445
Organisational interoperability. 1446
1447
Standards: standards and protocols proposed (SDO/Alliance) or supported 1448
(Alliance/OSS); Include details on whether an SDO/Alliance specified original protocols, 1449
or whether they are using and integrating standards and protocols developed by other 1450
SDOs 1451
Depends on specification 1452
1453
Supporting organizations (mainly for Alliances/OSS): main organizations that back the 1454
initiative 1455
ECC, CENELEC 1456
1457
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 1458
2, related to the market domain (consumer/industrial internet –horizontal axis) and the 1459
technical domain (connectivity, service&applications – vertical axis); 1460
Multiple domains 1461
1462
Application area: 1463
whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 1464
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is 1465
focusing on a particular vertical industry (e.g., Smart City), when applicable, see 1466
Figure 2 in Section 2 1467
Different specifications cover different areas. Smart City focus in some 1468
specifications 1469
1470
Scope: mapping to knowledge areas of concerns in IoT. 1471
Communication and Connectivity knowledge area: 1472
Integration/Interoperability knowledge area: 1473
Applications knowledge area: 1474
Infrastructure knowledge area: 1475
IoT Architecture knowledge area: 1476
Devices and sensor technology knowledge area: 1477
Security and Privacy knowledge area: 1478
1479
IPR Policy Available: mention if there is any IPR policy available (e.g., FRAND); if 1480
available include a reference to the description of this IPR policy 1481
FRAND – ETSI IPR policy - http://www.etsi.org/about/how-we-1482
work/intellectual-property-rights-iprs 1483
1484
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-1485
members can get access to published and non-published (draft) specifications and/or 1486
software 1487
Specification open ETSI web site – free to access for all. 1488
1489
ETSI TC Smart M2M 1490
AIOTI – Restricted 38
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
Description: 1491
Responsibility 1492
TC Smart M2M will primarily provide specifications for M2M services and 1493
applications. Much of the work will focus on aspects of the Internet of Things 1494
(IoT) and Smart Cities. 1495
TC Smart M2M will support European policy and regulatory requirements 1496
including mandates in the area of M2M and the Internet of Things. 1497
TC Smart M2M work includes the identification of EU policy and regulatory 1498
requirements on M2M services and applications to be developed by oneM2M, 1499
and the conversion of the oneM2M specifications into European Standards. 1500
1501
Areas of activity 1502
The activities of TC Smart M2M will include the following: 1503
Be a centre of expertise in the area of M2M and Internet of Things (IoT) to 1504
support M2M services and applications; 1505
Maintain ETSI M2M published specifications; 1506
Produce specifications as needed for regulatory purposes; 1507
Transpose the output of oneM2M to TC M2M. 1508
1509
TC Smart M2M will aim at referring to existing work done elsewhere, or 1510
encouraging existing groups to fulfil Smart M2M requirements. The TC will 1511
undertake necessary work that is not being provided for elsewhere. 1512
1513
1514
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); For each criterion please 1515
select one or more options. 1516
1517
1. Adoption (users base) 1518
Widely adopted in industry 1519
2. Development Status 1520
Depends on specification, some published others under development 1521
3. Compliance 1522
Having compliance testing process (include test suites, method, etc. ) 1523
4. Openness 1524
Open to public – most groups some only open to members 1525
1526
5. Ratification process (how the standard is being approved?) 1527
Done by members and open for consultation from external parties 1528
1529
Interoperability level: identify the interoperability levels considered by the 1530
SDO/Alliance/OSS initiative, see Appendix A for details: 1531
Organisational interoperability 1532
1533
Standards: standards and protocols proposed (SDO/Alliance) or supported 1534
(Alliance/OSS); Include details on whether an SDO/Alliance specified original protocols, 1535
or whether they are using and integrating standards and protocols developed by other 1536
SDOs 1537
Depends on specification 1538
1539
Supporting organizations (mainly for Alliances/OSS): main organizations that back the 1540
initiative 1541
AIOTI – Restricted 39
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
OneM2M 1542
1543
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 1544
2, related to the market domain (consumer/industrial internet –horizontal axis) and the 1545
technical domain (connectivity, service&applications – vertical axis); 1546
Multiple domains 1547
1548
Application area: 1549
whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 1550
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is 1551
focusing on a particular vertical industry (e.g., Smart City), when applicable, see 1552
Figure 2 in Section 2 1553
Different specifications cover different areas. Smart City focus in some 1554
specifications 1555
1556
Scope: mapping to knowledge areas of concerns in IoT. 1557
The identified knowledge areas are (Note that an initiative can be mapped to more 1558
than one knowledge areas): 1559
Different specifications cover different areas: 1560
1561
Communication and Connectivity knowledge area: 1562
Integration/Interoperability knowledge area: 1563
Applications knowledge area: 1564
Infrastructure knowledge area: 1565
IoT Architecture knowledge area: 1566
Devices and sensor technology knowledge area: 1567
Security and Privacy knowledge area: 1568
1569
IPR Policy Available: mention if there is any IPR policy available (e.g., FRAND); if 1570
available include a reference to the description of this IPR policy 1571
FRAND – ETSI IPR policy - http://www.etsi.org/about/how-we-1572
work/intellectual-property-rights-iprs 1573
1574
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-1575
members can get access to published and non-published (draft) specifications and/or 1576
software 1577
Specification open ETSI web site – free to access for all. 1578
1579
ETSI ISG IP6 (Internet Protocol 6) 1580
Description: 1581
ETSI, the European Telecommunications Standards Institute, produces globally-1582
applicable standards for Information and Communications Technologies (ICT), including 1583
fixed, mobile, radio, converged, broadcast and Internet technologies. 1584
• The ETSI ISG IP6 (Internet Protocol 6) has the ambition to define best practices, garner 1585
support and create awareness of the impact of IPv6 on critical infrastructure and on 1586
emerging topics such as Cloud Computing, IoT (Internet of Things), SDN/NFV 1587
(Software Defined Networking/Network Function Virtualization) and 5G. 1588
• The main objectives are: 1589
AIOTI – Restricted 40
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
• Attract and garner support from all stakeholders worldwide to join and work on 1590
pre-standardization in a neutral membership environment with infrastructure and 1591
logistics caring also for IPR issues and working procedures 1592
• Stimulate interoperability harmonization and coalition efforts to converge and 1593
focus the work for greater impact and exploitations for the common good 1594
• Define best practices, focus on study and definition of requirements and use 1595
cases, garner support and create awareness of the impact of IPv6 on critical 1596
infrastructure and on emerging topics such as Cloud Computing, IoT, SDN/NFV 1597
and 5G 1598
• Focus on IPv4-IPv6 impact in early technical discussions, integrating new 1599
technologies with a holistic approach such as IPv6-based SDN, Machine-to-1600
Machine, Mobile Internet of Things, Mobile Cloud Computing and Fringe 1601
Internet, focusing on commonly agreed requirements toward the emergence of 1602
potential “IPv6 integration” 1603
1604
For more details see: https://portal.etsi.org/tb.aspx?tbid=827&SubTB=827 1605
1606
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); For each criterion 1607
please select one or more options. 1608
1609
1. Adoption (users base) 1610
No implementations 1611
2. Development Status 1612
Deliverables under development 1613
1614
3. Compliance 1615
Not relevant, since the specifications are not normative. 1616
4. Openness 1617
Open to public 1618
1619
5. Ratification process (how the standard is being approved?) 1620
Done by members and open for consultation from external parties 1621
1622
Interoperability level: identify the interoperability levels considered by the 1623
SDO/Alliance/OSS initiative, see Appendix A for details: 1624
Organisational interoperability. 1625
1626
Standards: standards and protocols proposed (SDO/Alliance) or supported 1627
(Alliance/OSS); Include details on whether an SDO/Alliance specified original protocols, 1628
or whether they are using and integrating standards and protocols developed by other 1629
SDOs 1630
It will not specify standards. It might use standards and protocols developed by 1631
other SDOs. 1632
1633
Supporting organizations (mainly for Alliances/OSS): main organizations that back the 1634
initiative 1635
Not relevant 1636
1637
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 1638
2, related to the market domain (consumer/industrial internet –horizontal axis) and the 1639
technical domain (connectivity, service&applications – vertical axis); 1640
AIOTI – Restricted 41
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
It can cover multiple domains 1641
1642
Application area: 1643
whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 1644
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is 1645
focusing on a particular vertical industry (e.g., Smart City), when applicable, see 1646
Figure 2 in Section 2 1647
It can cover multiple domains 1648
1649
Scope: mapping to knowledge areas of concerns in IoT. 1650
The identified knowledge areas are (Note that an initiative can be mapped to more 1651
than one knowledge areas): 1652
Communication and Connectivity knowledge area: 1653
Integration/Interoperability knowledge area: 1654
Infrastructure knowledge area: 1655
Security and Privacy knowledge area: 1656
1657
IPR Policy Available: mention if there is any IPR policy available (e.g., FRAND); if 1658
available include a reference to the description of this IPR policy 1659
FRAND – ETSI IPR policy - http://www.etsi.org/about/how-we-1660
work/intellectual-property-rights-iprs 1661
1662
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-1663
members can get access to published and non-published (draft) specifications and/or 1664
software 1665
Specification open ETSI web site – free to access for all. 1666
1667
ETSI ISG MEC (Mobile-Edge Computing) 1668
Description: 1669
Mobile-edge Computing provides IT and cloud-computing capabilities within the RAN 1670
(Radio Access Network) in close proximity to mobile subscribers. Located at the base 1671
station or at the Radio Network Controller (RNC), it also provides access to real-time 1672
radio and network information (such as subscriber location, cell load, etc.) that can be 1673
exploited by applications and services to offer context related services; these services are 1674
capable of differentiating the mobile broadband experience. For application developers 1675
and content providers, the RAN edge offers a service environment with ultralow latency 1676
and high-bandwidth as well as direct access to real-time radio network information. 1677
1678
Mobile edge computing allows content, services and applications to be accelerated, 1679
increasing responsiveness from the edge. The customer’s experience can be proactively 1680
maintained through efficient network and service operations, based on insight into the 1681
radio and network conditions. Operators can open the radio network edge to third-party 1682
partners, allowing them to rapidly deploy innovative applications and services towards 1683
mobile subscribers, enterprises and other vertical segments. Proximity, context, agility 1684
and speed can be translated into value and can be exploited by mobile operators, service 1685
and content providers, Over the Top (OTT) players and Independent Software Vendors 1686
(ISVs), enabling them to play complementary and profitable roles within their respective 1687
business models and allowing them to monetize the mobile broadband experience. 1688
1689
AIOTI – Restricted 42
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
This environment can create a new value chain and an energized ecosystem comprising 1690
application developers, content providers, OTT players, network equipment vendors and 1691
mobile operators. Based on innovation and business value, this value chain will allow all 1692
players to benefit from greater cooperation. 1693
1694
The intention is to foster dissemination of the deliverables produced by the ISG MEC in 1695
order to develop favourable market conditions which will create sustainable business for 1696
all players in the value chain, and to facilitate global market growth. 1697
1698
The goals of the ISG MEC are to: 1699
Create a standardized, open environment which will allow the efficient and 1700
seamless integration of third-party applications across multi-vendor Mobile-edge 1701
Computing platforms. This will ensure that the vast majority of the customers of a 1702
mobile operator can be served. 1703
Enable and accelerate the development of edge applications across the industry, 1704
increasing the market scale and improving the market economics. 1705
Address regulatory and legal requirements.. 1706
1707
MEC can help accelerate and enhance smart city applications. 1708
Example 1: Active device location tracking service: 1709
MEC tracks active devices (independent of GPS information) and 1710
provides real-time location information & location statistics of UEs 1711
located in coverage area of MEC server, 1712
Helps to understand how crowd is distributed, 1713
Crowd dynamics can help with smart transportation optimization as 1714
transportation systems require (anonymous) location information from a 1715
large population. Helps with utility planning, etc. 1716
Example 2: Intelligent video analytics at the edge: 1717
distributed live video streams analytics at mobile edge and events are 1718
triggered automatically (e.g. movement, objects, crowd, etc.), enables fast 1719
detection and action triggering. 1720
1721
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); For each criterion 1722
please select one or more options. 1723
1724
1. Adoption (users base) 1725
No implementations 1726
2. Development Status 1727
Specification under development 1728
3. Compliance 1729
Having compliance testing process (include test suites, method, etc. ) 1730
4. Openness 1731
Open to public 1732
1733
5. Ratification process (how the standard is being approved?) 1734
Done by members and open for consultation from external parties 1735
1736
Interoperability level: identify the interoperability levels considered by the 1737
SDO/Alliance/OSS initiative, see Appendix A for details: 1738
Organisational interoperability 1739
1740
AIOTI – Restricted 43
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
Standards: standards and protocols proposed (SDO/Alliance) or supported 1741
(Alliance/OSS); Include details on whether an SDO/Alliance specified original protocols, 1742
or whether they are using and integrating standards and protocols developed by other 1743
SDOs 1744
Depends on specification 1745
1746
Supporting organizations (mainly for Alliances/OSS): main organizations that back the 1747
initiative 1748
Not relevant 1749
1750
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 1751
2, related to the market domain (consumer/industrial internet –horizontal axis) and the 1752
technical domain (connectivity, service&applications – vertical axis); 1753
Multiple domains 1754
1755
Application area: 1756
whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 1757
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is 1758
focusing on a particular vertical industry (e.g., Smart City), when applicable, see 1759
Figure 2 in Section 2 1760
Different specifications cover different areas. Smart City focus in some 1761
specifications 1762
1763
Scope: mapping to knowledge areas of concerns in IoT. 1764
The identified knowledge areas are (Note that an initiative can be mapped to more 1765
than one knowledge areas): 1766
1767
Infrastructure knowledge area: 1768
1769
IPR Policy Available: mention if there is any IPR policy available (e.g., FRAND); if 1770
available include a reference to the description of this IPR policy 1771
FRAND – ETSI IPR policy - http://www.etsi.org/about/how-we-1772
work/intellectual-property-rights-iprs 1773
1774
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-1775
members can get access to published and non-published (draft) specifications and/or 1776
software 1777
Specification open ETSI web site – free to access for all. 1778
1779
ETSI ISG NFV (Network Functions Virtualisation) 1780
Description: 1781
The original target of ISG NFV consisted in providing a pre-standardisation study before 1782
considering later a broader standards proposal in a new or existing standardisation group. 1783
It was important at that stage to first clearly define, agree, and share the goals of 1784
virtualising network functions with the whole industry. This was addressed in the 2013-1785
2014 time frame, and resulted in the publication of the first ISG NFV specifications 1786
release. 1787
1788
In 2015 and 2016, the purpose of ISG NFV remains to produce the technical 1789
specifications for the virtualisation of network functions. 1790
AIOTI – Restricted 44
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
This will be achieved by delivering both informative documents (analysis, Use Case 1791
descriptions, feasibility studies, reports, etc…) and normative documents (requirements, 1792
architecture, interface specification, etc…) aiming at helping the industry in its quest for 1793
interoperability. 1794
1795
Through these documents ISG NFV will address technical challenges that include: 1796
• Ensuring that virtualised network platforms will be simpler to operate than what exists 1797
today. 1798
• Achieving high performance virtualised network appliances which are portable between 1799
different hardware vendors, and with different hypervisors. 1800
• Achieving co-existence with legacy hardware-based network platforms whilst enabling 1801
an efficient migration path to fully virtualised network platforms which re-use network 1802
operator BSS and OSS. 1803
• Management and orchestration of virtual network appliances (particularly alongside 1804
legacy management systems) while ensuring security from attack and misconfiguration. 1805
• Maintaining network stability and service levels without degradation during appliance 1806
load and relocation. 1807
• Ensuring the appropriate level of resilience to hardware and software failures. 1808
• Enable the creation of virtual network appliances which will run, ideally without 1809
recompilation, on any hypervisor and hardware configuration, and integrate “on the fly” 1810
into the network operators’ existing EMS, NMS, OSS, BSS and orchestration systems. 1811
ISG NFV will also perform a requirement analysis for future technical specifications & 1812
standards in ad hoc standardisation organisation & groups to be identified or created at 1813
ETSI and other relevant standards development organisations. 1814
1815
GS NFV 001 Use Cases identifies broad range of applications that could leverage 1816
distributed NFV Infrastructure (NFVI). Service models include multi-tenant 1817
arrangements that may provide useful paradigm for smart city services and applications 1818
to leverage. ISG NFV developing forward looking feature roadmap to understand how 1819
work can be leveraged by services and technologies developed in other industry bodies. 1820
1821
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); For each criterion 1822
please select one or more options. 1823
1824
1. Adoption (users base) 1825
Reference implementations 1826
2. Development Status 1827
Specification under development 1828
3. Compliance 1829
Having compliance testing process (include test suites, method, etc. ) 1830
4. Openness 1831
Open to public 1832
1833
5. Ratification process (how the standard is being approved?) 1834
Done by members and open for consultation from external parties 1835
1836
Interoperability level: identify the interoperability levels considered by the 1837
SDO/Alliance/OSS initiative, see Appendix A for details: 1838
Organisational interoperability. 1839
1840
AIOTI – Restricted 45
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
Standards: standards and protocols proposed (SDO/Alliance) or supported 1841
(Alliance/OSS); Include details on whether an SDO/Alliance specified original protocols, 1842
or whether they are using and integrating standards and protocols developed by other 1843
SDOs 1844
Depends on specification 1845
1846
Supporting organizations (mainly for Alliances/OSS): main organizations that back the 1847
initiative 1848
Not relevant 1849
1850
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 1851
2, related to the market domain (consumer/industrial internet –horizontal axis) and the 1852
technical domain (connectivity, service&applications – vertical axis); 1853
Multiple domains 1854
1855
Application area: 1856
whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 1857
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is 1858
focusing on a particular vertical industry (e.g., Smart City), when applicable, see 1859
Figure 2 in Section 2 1860
Network infrastructure 1861
1862
Scope: mapping to knowledge areas of concerns in IoT. 1863
The identified knowledge areas are (Note that an initiative can be mapped to more 1864
than one knowledge areas): 1865
1866
Infrastructure knowledge area: 1867
1868
IPR Policy Available: mention if there is any IPR policy available (e.g., FRAND); if 1869
available include a reference to the description of this IPR policy 1870
FRAND – ETSI IPR policy - http://www.etsi.org/about/how-we-1871
work/intellectual-property-rights-iprs 1872
1873
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-1874
members can get access to published and non-published (draft) specifications and/or 1875
software 1876
Specification open ETSI web site – free to access for all. 1877
1878
ETSI ISG OEU (Operational energy Efficiency for Users) 1879
Description: 1880
The goal is to create Global Efficiency Indicators for environmentally efficient ICT, e.g. 1881
infrastructure, equipment and software within data centres and networks taking into 1882
account at least power consumption and green house gas emission. 1883
1884
Energy efficiency of system installations (data centre buildings, transmission node 1885
building, computer rooms, networks and IT systems) is of high importance for the ICT 1886
Customers who are users of ICT System Installations as Car manufacturers, Banks, 1887
Insurance Companies, Network Operators, Airplane Companies, Governmental 1888
Ministries... (hereinafter the “Users”). 1889
1890
AIOTI – Restricted 46
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
Independently from the ICT systems integrators, service providers, producers and 1891
manufacturers of ICT system installations, the Users, in the perspective of EU Digital 1892
Agenda mechanism and law enforcements (e.g. “carbon taxes”) are proposing commonly 1893
agreed and proofed Key Performance Indicators (KPIs) and framework of 1894
implementation. For the Users, existing non-users specific indicators (Like PUE from 1895
The Green Grid association ) are not comprehensive enough and not taking into account 1896
all Users’ installation efforts and detailed operational constraints (external physical 1897
environment, climate and geography, redundancy, free cooling...) as well as all 1898
innovative energy efficiency techniques (e.g. increase of maximum operational 1899
temperature). With the support of ETSI ATTM members agreed in ATTM#9 Plenary 1900
meeting and the European Commission, the ETSI Members among the Users already 1901
grouped together in a non-for-profit Association (CRIP/CTO ALLIANCE) are proposing 1902
the creation of an ETSI Industry Specification Group (ISG) on “Operational energy 1903
Efficiency for Users” (OEU). This creation is done in close collaboration with other 1904
major Users like Banks, Insurance Companies..., who belong to CRIP/CTO ALLIANCE 1905
(Club des Responsables d’Infrastructures et de Production) but are not ETSI-Members 1906
1907
CRIP/CTO ALLIANCE is an association of ICT professionals seeking to dramatically 1908
raise the environmental efficiency of ICT areas through a series of short-term and long-1909
term proposals. CRIP/CTO ALLIANCE proposes the use of efficiency metrics which 1910
enable ICT actors to estimate energy efficiency of their activities driving energy 1911
efficiency improvements. In collaboration with ETSI this concept is strengthened. For 1912
example, the current indicators described in ETSI TS 105 174-2-2 Clause 5.3.1 need to 1913
take into account more factors to allow useful and meaningful Key Performance 1914
Indicators (KPIs) calculation, measurement and comparisons. 1915
1916
Such more reliable energy efficiency KPIs will help Users of Operational Architecture to 1917
easily identify, compare and scale the effective energy efficiency of their ICT 1918
installations internally and with the other Users. Users need a better common standard 1919
KPI and way of implementation. 1920
1921
This ISG OEU will elaborate ETSI Group Specifications (GSs) for Energy Efficiency of 1922
Operational Architecture and framework of implementation designed, implemented and 1923
validated by Users. These Users’ requirements will be provided to ETSI TCs (e.g. 1924
ATTM, EE) in order to develop ETSI standards (e.g. Global KPI definitions) for their 1925
inclusion in EU ICT Digital Agenda and proposed to all ICT communities. 1926
1927
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); For each criterion 1928
please select one or more options. 1929
1930
1. Adoption (users base) 1931
Reference implementations 1932
2. Development Status 1933
Specification under development 1934
3. Compliance 1935
Having compliance testing process (include test suites, method, etc. ) 1936
4. Openness 1937
Open to public 1938
1939
5. Ratification process (how the standard is being approved?) 1940
Done by members and open for consultation from external parties 1941
AIOTI – Restricted 47
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
1942
Interoperability level: identify the interoperability levels considered by the 1943
SDO/Alliance/OSS initiative, see Appendix A for details: 1944
Organisational interoperability. 1945
1946
Standards: standards and protocols proposed (SDO/Alliance) or supported 1947
(Alliance/OSS); Include details on whether an SDO/Alliance specified original protocols, 1948
or whether they are using and integrating standards and protocols developed by other 1949
SDOs 1950
Depends on specification 1951
1952
Supporting organizations (mainly for Alliances/OSS): main organizations that back the 1953
initiative 1954
Not relevant 1955
1956
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 1957
2, related to the market domain (consumer/industrial internet –horizontal axis) and the 1958
technical domain (connectivity, service&applications – vertical axis); 1959
Multiple domains 1960
1961
Application area: 1962
whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 1963
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is 1964
focusing on a particular vertical industry (e.g., Smart City), when applicable, see 1965
Figure 2 in Section 2 1966
Energy efficiency 1967
1968
Scope: mapping to knowledge areas of concerns in IoT. 1969
The identified knowledge areas are (Note that an initiative can be mapped to more 1970
than one knowledge areas): 1971
1972
Infrastructure knowledge area: 1973
o Energy efficiency 1974
1975
IPR Policy Available: mention if there is any IPR policy available (e.g., FRAND); if 1976
available include a reference to the description of this IPR policy 1977
FRAND – ETSI IPR policy - http://www.etsi.org/about/how-we-1978
work/intellectual-property-rights-iprs 1979
1980
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-1981
members can get access to published and non-published (draft) specifications and/or 1982
software 1983
Specification open ETSI web site – free to access for all. 1984
5.2.5 GSMA (GSM Association) 1985
Description: main objective and focus of initiative 1986
Features: high level functionalities covered by the initiative 1987
http://www.gsma.com/aboutus/ 1988
http://www.gsma.com/connectedliving/ 1989
AIOTI – Restricted 48
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION The GSMA represents the interests of mobile operators worldwide, uniting nearly 1990
800 operators with more than 250 companies in the broader mobile ecosystem, 1991
including handset and device makers, software companies, equipment providers 1992
and internet companies, as well as organisations in adjacent industry sectors. The 1993
GSMA also produces industry-leading events such as Mobile World Congress, 1994
Mobile World Congress Shanghai and the Mobile 360 Series conferences. 1995
The GSMA Connected Living programme 1996
(http://www.gsma.com/connectedliving/) is an initiative to help operators add 1997
value and accelerate the delivery of new connected devices and services in the 1998
Machine to Machine (M2M) market. 1999
2000
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); For each criterion 2001
please select one or more options. 2002
1. Adoption (users base) 2003
Widely adopted in industry 2004
2. Development Status 2005
Approved with planned revisions 2006
3. Compliance 2007
Not managed 2008
4. Openness 2009
Open by formal membership 2010
5. Ratification process (how the standard is being approved?) 2011
Closed process done by members only with no consultation from external 2012
parties 2013
Interoperability level: identify the interoperability levels considered by the 2014
SDO/Alliance/OSS initiative, see Appendix A for details: 2015
Technical interoperability 2016
2017
Standards: standards and protocols proposed (SDO/Alliance) or supported 2018
(Alliance/OSS); Include details on whether an SDO/Alliance specified original protocols, 2019
or whether they are using and integrating standards and protocols developed by other 2020
SDOs 2021
GSMA is mainly for public policy and spectrum policy lobby, mobile business 2022
development and mobile market promotion. The only one standard made by 2023
GSMA is eSIM. 2024
2025
Supporting organizations (mainly for Alliances/OSS): main organizations that back the 2026
initiative 2027
3GPP 2028
There are also more than 250 vendors and more than 800 MNOs in the GSMA. 2029
The membership types consist of Full Membership, Associate Membership and 2030
Rapporteur Membership. The full membership can be found 2031
http://www.gsma.com/membership/who-are-our-gsma-members . 2032
2033
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 2034
2, related to the market domain (consumer/industrial internet –horizontal axis) and the 2035
technical domain (connectivity, service&applications – vertical axis); 2036
GSMA make just one standard, eSIM. It locates in the connectivity domain, and 2037
can be used for both consumer and industrial market. 2038
2039
AIOTI – Restricted 49
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
Application area: 2040
whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 2041
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is 2042
focusing on a particular vertical industry (e.g., Smart City), when applicable, see 2043
Figure 2 in Section 2 2044
The GSMA is mainly for promotion of mobile industrial, which includes 2045
public policy and spectrum policy, management of mobile service, mobile 2046
API, mobile application in different vertical area of industry, and personal 2047
data. 2048
2049
Scope: mapping to knowledge areas of concerns in IoT. 2050
The identified knowledge areas are (Note that an initiative can be mapped to more 2051
than one knowledge areas): 2052
Applications knowledge area: 2053
IoT Architecture knowledge area: 2054
Devices and sensor technology knowledge area: 2055
Security and Privacy knowledge area: 2056
2057
IPR Policy Available: mention if there is any IPR policy available (e.g., FRAND); if 2058
available include a reference to the description of this IPR policy 2059
Reference: http://www.gsma.com/newsroom/wp-content/uploads/2013/09/AA-2060
32-v4-0.pdf 2061
2062 2063
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-2064
members can get access to published and non-published (draft) specifications and/or 2065
software 2066
GSMA published documents available at: 2067
http://www.gsma.com/newsroom/gsmadocuments/ 2068
2069
5.2.6 HyperCat 2070
Description: 2071
2072
AIOTI – Restricted 50
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
HyperCat is designed for representing and exposing Internet of Things data hub 2073
catalogues over standard web technologies, to improve data discoverability and 2074
interoperability. It allows a 2075
server to provide a set of resources identified by URIs to a client, each with a set of 2076
semantic annotations. 2077
2078
Technically, HyperCat is an open, lightweight JSON-based hypermedia catalogue format 2079
for exposing collections of URIs. Each HyperCat catalogue may expose any number of 2080
URIs, each with any number of RDF-like triple statements about it. 2081
2082
Readiness 2083
Multiple organisations/Reference Implementations 2084
2085
Interoperability level 2086
Semantic Interoperability 2087
2088
Standards 2089
The HyperCat 2.0 specification is going through the BSI PAS process (PAS 212 – 2090
Automatic resource discovery for the IoT), with a planned completion date of 2091
April 2016. 2092
2093
Supporting organizations 2094
A complete list of members of the HyperCat consortium is available at: 2095
http://www.hypercat.io/consortium.html. Leading members who have actively 2096
participated in specification development include: IBM, BT, Flexeye, 1248 Ltd & 2097
Thingful. 2098
2099
Domain: 2100
Relevant to both B2B and B2C, operates at “Service & App” level. 2101
2102
Application area: 2103
Integrated/complete IoT solutions (i.e. horizontal) 2104
Scope: 2105
Integration/Interoperability knowledge area: 2106
Applications knowledge area: 2107
Security and Privacy knowledge area: 2108
2109
IPR Policy Available 2110
Creative Commons Attribution 4.0 International License 2111
2112
Specification Access: 2113
The latest publically available version can be seen at: 2114
http://www.hypercat.io/standard.html 2115
5.2.7 IEC (International Electrotechnical Commission) 2116
This section provides a brief description of the IEC (International Electrotechnical Commission) 2117
initiative and its IoT related Technical Committees (TCs). 2118
IEC covers all electrotechnical aspects from plugs, wires, voltage levels to automation, control 2119
and management. 2120
AIOTI – Restricted 51
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
Various protocols are supported: e.g. IEC61850, IEC 61968/61970 (CIM), XMPP, 2121
DLMS/COSEM, OPC-UA, various field buses. 2122
Various mature standards are available that are widely adopted in the industry 2123
The important committees & groups are: 2124
SC3D Product properties and classes and their identification, 2125
TC 8 Systems aspects for electrical energy supply, 2126
TC13 Electrical energy measurement and control, 2127
TC 57 Power systems management and associated information exchange, 2128
TC65 Industrial-process measurement, control and automation, 2129
SG8 Industry 4.0 - Smart Manufacturing, 2130
SG 9 Communication Technologies, 2131
SG10 Wearable Smart Devices, 2132
SyC Smart Energy, 2133
SyC Active Assisted Living, 2134
SEG1 Smart Cities, 2135
SEG5 Electrotechnology for mobility, 2136
SEG6 Non-traditional Distribution Networks / Microgrids 2137
2138
Participation is open via the national committees. 2139
The followed IPR regime is (FRAND). 2140
Specifications are openly available for a fee. 2141
2142
IEC TC57 2143
2144
Description: 2145
To prepare international standards for power systems control equipment and systems 2146
including EMS (Energy Management Systems), SCADA (Supervisory Control And Data 2147
Acquisition), distribution automation, teleprotection, and associated information 2148
exchange for real-time and non-real-time information, used in the planning, operation and 2149
maintenance of power systems. Power systems management comprises control within 2150
control centres, substations and individual pieces of primary equipment including 2151
telecontrol and interfaces to equipment, systems and databases, which may be outside the 2152
scope of TC 57. 2153
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); For each criterion 2154
please select one or more options. 2155
1. Adoption (users base) 2156
Widely adopted in industry 2157
3. Compliance 2158
Not managed by IEC 2159
4. Openness 2160
Open to public 2161
5. Ratification process (how the standard is being approved?) 2162
Done by members and open for consultation from external parties 2163
2164
Interoperability level: identify the interoperability levels considered by the 2165
SDO/Alliance/OSS initiative, see Appendix A for details: 2166
Syntactical interoperability 2167
Technical interoperability 2168
Semantic interoperability 2169
2170
AIOTI – Restricted 52
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
Standards: standards and protocols proposed (SDO/Alliance) or supported 2171
(Alliance/OSS); Include details on whether an SDO/Alliance specified original protocols, 2172
or whether they are using and integrating standards and protocols developed by other 2173
SDOs . 2174
Some examples: 2175
IEC/TR 62357 Reference Architecture 2176
IEC 61968 Application integration at electric utilities - System interfaces for 2177
distribution management 2178
IEC 61970 Energy management system application program interface 2179
IEC 62325 Framework for energy market communications 2180
IEC61850 Communication networks and systems for power utility automation 2181
IEC 62351 Power systems management and associated information exchange - 2182
Data and communications security 2183
IEC 62746 Systems Interface between Customer Energy Management System 2184
and the Power Management System 2185
Supporting organizations (mainly for Alliances/OSS): main organizations that back the 2186
initiative 2187
Energy, Smart Grid, Smart Cities 2188
2189
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 2190
2, related to the market domain (consumer/industrial internet –horizontal axis) and the 2191
technical domain (connectivity, service&applications – vertical axis); 2192
Industrial 2193
Application area: 2194
whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 2195
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is 2196
focusing on a particular vertical industry (e.g., Smart City), when applicable, see 2197
Figure 2 in Section 2 2198
Smart Grid, Smart City 2199
2200
Scope: mapping to knowledge areas of concerns in IoT. 2201
The identified knowledge areas are (Note that an initiative can be mapped to more 2202
than one knowledge areas): 2203
Communication and Connectivity knowledge area: 2204
Integration/Interoperability knowledge area: 2205
Applications knowledge area: 2206
Infrastructure knowledge area: 2207
IoT Architecture knowledge area: 2208
Security and Privacy knowledge area: 2209
2210
IPR Policy Available: mention if there is any IPR policy available (e.g., FRAND); if 2211
available include a reference to the description of this IPR policy 2212
ITU / ISO / IEC code of practice. 2213
FRAND 2214
2215
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-2216
members can get access to published and non-published (draft) specifications and/or 2217
software 2218
Open to everyone with a fee. 2219
2220
AIOTI – Restricted 53
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
IEC TC65 2221
2222
Description: 2223
IEC TC65, established in 1968, prepares basic standards for industrial automation as 2224
well as process 2225
industry specific standards. The Scopes of TC65 and its SCs are as follows: 2226
2227
TC65: INDUSTRIAL PROCESS MEASUREMENT, CONTROL AND 2228
AUTOMATION 2229
2230
To prepare international standards for systems and elements used for industrial 2231
process 2232
measurement, control and automation. To coordinate standardization activities which 2233
affect integration of components and functions into such systems including safety and 2234
security aspects. This work of standardization is to be carried out in the international 2235
fields for equipment and systems. 2236
2237
SC65A: SYSTEM ASPECTS 2238
2239
To prepare international standards regarding the generic aspects of systems used in 2240
industrial process measurement, control and manufacturing automation: operational 2241
conditions (including EMC), methodology for the assessment of systems, functional 2242
safety, etc. 2243
2244
SC65A also has a safety pilot function to prepare standards dealing with functional 2245
safety 2246
of electrical/electronic/programmable electronic systems. 2247
2248
SC65B: MEASUREMENT AND CONTROL DEVICES 2249
2250
To prepare international standards in the field of specific aspects of devices 2251
(hardware 2252
and software) used in industrial process measurement and control, such as 2253
measurement devices, analysing equipment, actuators, and programmable logic 2254
controllers, and covering such aspects as interchangeability, performance evaluation, 2255
and functionality definition. 2256
2257
SC65C: INDUSTRIAL NETWORKS 2258
2259
To prepare international standards on wired, optical and wireless industrial networks 2260
for 2261
industrial-process measurement, control and manufacturing automation, as well as for 2262
instrumentation systems used for research, development and testing purposes. The 2263
scope includes cabling, interoperability, co-existence and performance evaluation. 2264
2265
SC65E: DEVICES AND INTEGRATION IN ENTERPRISE SYSTEMS 2266
2267
To prepare international standards specifying: 2268
2269
(1) Device integration with industrial automation systems. The models developed in 2270
these standards address device properties, classification, selection, configuration, 2271
AIOTI – Restricted 54
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
commissioning, monitoring and basic diagnostics. 2272
2273
(2) Industrial automation systems integration with enterprise systems. This includes 2274
transactions between business and manufacturing activities which may be jointly 2275
developed with ISO TC184. 2276
2277
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); For each criterion 2278
please select one or more options. 2279
1. Adoption (users base) 2280
Widely adopted in industry 2281
3. Compliance 2282
Not managed by IEC 2283
4. Openness 2284
Open to public 2285
5. Ratification process (how the standard is being approved?) 2286
Done by members and open for consultation from external parties 2287
2288
Interoperability level: identify the interoperability levels considered by the 2289
SDO/Alliance/OSS initiative, see Appendix A for details: 2290
Syntactical interoperability 2291
Technical interoperability 2292
Semantic interoperability 2293
Organisational interoperability 2294
2295
Standards: standards and protocols proposed (SDO/Alliance) or supported 2296
(Alliance/OSS); Include details on whether an SDO/Alliance specified original protocols, 2297
or whether they are using and integrating standards and protocols developed by other 2298
SDOs 2299
Publication Example 2300
2301
IEC 60050-351 (IEV vocabulary) 2302
IEC 61010 (Safety requirements for equipment) 2303
IEC 62443 (Cyber security) 2304
IEC 62708 (Documentation requirements) 2305
IEC 61326 (EMC) 2306
IEC 61508 Series (Functional Safety) 2307
IEC 61511 (Functional Safety process industry sector) 2308
IEC 61512 (Batch Control) 2309
IEC 61131 (PLC) 2310
IEC 61499 (Function Block) 2311
IEC 60534 (Industrial-process control valves) 2312
IEC 61207 (Expression of performance of gas analyzers) 2313
IEC 61158 Series (Fieldbus) 2314
IEC 61588 (Precision clock synchronization) 2315
IEC 61784 (Industrial communication networks – Profiles) 2316
IEC 61918 (Cabling) 2317
IEC 62439 (High availability automation networks) 2318
IEC 62591, IEC 62601, IEC 62734 (Wireless) 2319
IEC 62657 (Wireless coexistence) 2320
… 2321
AIOTI – Restricted 55
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
Supporting organizations (mainly for Alliances/OSS): main organizations that back the 2322
initiative 2323
Manufacturing 2324
Industrial automation 2325
2326
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 2327
2, related to the market domain (consumer/industrial internet –horizontal axis) and the 2328
technical domain (connectivity, service&applications – vertical axis); 2329
Industrial 2330
2331
Application area: 2332
whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 2333
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is 2334
focusing on a particular vertical industry (e.g., Smart City), when applicable, see 2335
Figure 2 in Section 2 2336
Smart manufacturing 2337
2338
Scope: mapping to knowledge areas of concerns in IoT. 2339
The identified knowledge areas are (Note that an initiative can be mapped to more 2340
than one knowledge areas): 2341
Communication and Connectivity knowledge area: 2342
Integration/Interoperability knowledge area: 2343
Applications knowledge area: 2344
Infrastructure knowledge area: 2345
IoT Architecture knowledge area: 2346
Devices and sensor technology knowledge area: 2347
Security and Privacy knowledge area: 2348
2349
IPR Policy Available: mention if there is any IPR policy available (e.g., FRAND); if 2350
available include a reference to the description of this IPR policy 2351
ITU / ISO / IEC code of practice. 2352
FRAND 2353
2354
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-2355
members can get access to published and non-published (draft) specifications and/or 2356
software 2357
Open to everyone with a fee. 2358
2359
5.2.8 IEEE P2413: Standard for an Architectural Framework for the Internet of Things 2360
Description: 2361
Defines an Architectural Framework for the IoT, including descriptions of various IoT 2362
domains, definitions of IoT domain abstractions, and identification of commonalities 2363
between different IoT domains. 2364
2365
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); For each criterion 2366
please select one or more options. 2367
2368
1. Adoption (users base) 2369
AIOTI – Restricted 56
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
No implementations 2370
2. Development Status 2371
Under development 2372
3. Compliance 2373
Not managed 2374
Having compliance testing process (include test suites, method, etc. ) 2375
4. Openness 2376
Open by formal membership 2377
5. Ratification process (how the standard is being approved?) 2378
Done by members and open for consultation from external parties 2379
2380
Interoperability level: identify the interoperability levels considered by the SDO/Alliance/OSS 2381
initiative, see Appendix A for details: 2382
Syntactical interoperability 2383
Technical interoperability 2384
Semantic interoperability 2385
Organisational interoperability 2386
2387
Standards: standards and protocols proposed (SDO/Alliance) or supported (Alliance/OSS); 2388
Include details on whether an SDO/Alliance specified original protocols, or whether they are 2389
using and integrating standards and protocols developed by other SDOs 2390
P2413 Standard for an Architectural Framework for the Internet of Things 2391
2392
Supporting organizations (mainly for Alliances/OSS): main organizations that back the initiative 2393
Not relevant 2394
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 2, 2395
related to the market domain (consumer/industrial internet –horizontal axis) and the technical 2396
domain (connectivity, service&applications – vertical axis); 2397
Market: consumer and industrial, 2398
Technology: closer to service & applications 2399
Application area: 2400
whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 2401
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is focusing on a 2402
particular vertical industry (e.g., Smart City), when applicable, see Figure 2 in Section 2 2403
Horizontal 2404
Scope: mapping to knowledge areas of concerns in IoT. 2405
The identified knowledge areas are (Note that an initiative can be mapped to more than 2406
one knowledge areas): 2407
IoT Architecture knowledge area: 2408
2409
IPR Policy Available: mention if there is any IPR policy available (e.g., FRAND); if available 2410
include a reference to the description of this IPR policy 2411
FRAND, royalty free 2412
2413
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-members 2414
can get access to published and non-published (draft) specifications and/or software 2415
Open to everyone with a fee. 2416
5.2.9 IETF (Internet Engineering Task Force) 2417
This section provides a brief description of the IETF (Internet Engineering Task Force) initiative and its 2418
IoT related Working Groups (WGs). 2419
The mission of the IETF is to make the Internet work better by producing high quality, relevant technical 2420
documents that influence the way people design, use, and manage the Internet. The IETF Mission 2421
Statement is documented in RFC 3935. The IETF has an IOT directorate to deal with IOT specificities. 2422
AIOTI – Restricted 57
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
2423
IETF WG 6lo (IPv6 over Networks of Resource-constrained Nodes) 2424 2425
Description: 2426
The official website of IETF 6lo (IPv6 over Networks of Resource-constrained Nodes 2427
(6lo) WG can be found via: https://datatracker.ietf.org/wg/6lo/charter/. 2428
6lo focuses on the work that facilitates IPv6 connectivity over constrained node networks 2429
with the characteristics of: 2430
* limited power, memory and processing resources 2431
* hard upper bounds on state, code space and processing cycles 2432
* optimization of energy and network bandwidth usage 2433 * lack of some layer 2 services like complete device connectivity and broadcast/multicast 2434
Specifically, 6lo will work on: 2435
1. IPv6-over-foo adaptation layer specifications using 6LoWPAN technologies (RFC4944, 2436
RFC6282, RFC6775) for link layer technologies of interest in constrained node networks 2437
2. Information and data models (e.g., MIB modules) for these adaptation layers for basic 2438 monitoring and troubleshooting. 2439
3. Specifications, such as low-complexity header compression, that are applicable to more 2440 than one adaptation layer specification 2441
4. Maintenance and informational documents required for the existing IETF specifications in 2442
this space. 2443
Only specifications targeting constrained node networks are in scope. 6lo will work closely 2444
with the 6man working group, which will continue to work on IP-over-foo documents outside 2445
the constrained node network space and will continue to be the focal point for IPv6 2446
maintenance. For adaptation layer specifications that do not have implications on IPv6 2447
architecture, 6man will be notified about 6lo's working group last call. Specifications that 2448
might have such an impact (e.g., by using IPv6 addresses in a specific way or by introducing 2449
new ND options or by exposing to IPv6 a link model different from either Ethernet or 2450
6lowpan) will be closely coordinated with 6man, and/or specific parts will be fanned out to 2451 6man documents. Beyond 6man, 6lo will also coordinate with LWIG and INTAREA. 2452
6lo works on small, focused pieces of work, but does not take on larger cross-layer efforts. 2453
The working group will continue to reuse existing protocols and mechanisms whenever 2454 reasonable and possible. 2455
Security and management work that is not specific to the link layers 2456
being worked on is out of scope. Work related to routing is out of 2457
scope. 6lo will coordinate closely with the working groups in other 2458
areas that focus on constrained node networks, such as ROLL (RTG) and 2459 CoRE (APP). 2460
Readiness: 2461
1: Adoption (users base) 2462
Reference implementations and interoperability plug test events done by ETSI 2463
2. Development Status 2464
RFC 7557 Approved 2465
3. Compliance 2466
Not IETF responsibility 2467
AIOTI – Restricted 58
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
4. Openness 2468
Open to public 2469
5. Ratification process (how the standard is being approved?) 2470
Open process for all parties interested in the ratification 2471
2472
Interoperability level: identify the interoperability levels considered by the SDO/Alliance/OSS 2473
initiative, see Appendix A for details: 2474
Syntactical interoperability 2475
Technical interoperability 2476
Semantic interoperability 2477
2478
Standards: standards and protocols proposed (SDO/Alliance) or supported (Alliance/OSS); 2479
Include details on whether an SDO/Alliance specified original protocols, or whether they are 2480
using and integrating standards and protocols developed by other SDOs 2481
Date Milestone
Apr 2015 WG adoption call for 6lo security related draft
Mar 2015 WG last call for draft-ietf-6lo-6lobac
draft-ietf-6lo-6lobac
Mar 2015 WG LC for draft-ietf-6lo-dect-ule
draft-ietf-6lo-dect-ule
Done WG adoption call for draft-hong-6lo-ipv6-over-nfc
draft-hong-6lo-ipv6-over-nfc
Done WG LC for draft-ietf-6lo-btle
draft-ietf-6lo-btle
Done WG decision on adoption of draft-mariager-6lowpan-v6over-dect-ule
draft-mariager-6lowpan-v6over-dect-ule
Done WG decision on adoption for draft-schoenw-6lo-lowpan-mib
draft-schoenw-6lo-lowpan-mib
Done WG decision on adoption for draft-ietf-6man-6lobac
draft-ietf-6man-6lobac
Done WG decision on adoption for draft-brandt-6man-lowpanz
draft-brandt-6man-lowpanz
Done WG decision on adoption for draft-bormann-6lo-ghc
draft-bormann-6lo-ghc
2482
Supporting organizations (mainly for Alliances/OSS): main organizations that back the initiative: 2483
6lo is an IETF WG. 2484
2485
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 2, 2486
related to the market domain (consumer/industrial internet –horizontal axis) and the technical 2487
domain (connectivity, service&applications – vertical axis); 2488
Market domain: Located on the vertical axis, to show that it is equally used by the 2489
consumer and industrial internet market. 2490
Technical domain: Closer to the service&applications edge of the vertical axis 2491
2492
Application area: 2493
whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 2494
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is focusing on a 2495
particular vertical industry (e.g., Smart City), when applicable, see Figure 2 in Section 2 2496
6lo WG is focusing on horizontal industry 2497
2498
Scope: mapping to knowledge areas of concerns in IoT. 2499
AIOTI – Restricted 59
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
The 6lo WG can be mapped to the following knowledge areas: 2500
Communication and Connectivity knowledge area: 2501
Integration/Interoperability knowledge area: 2502
Security and Privacy knowledge area: 2503
2504
IPR Policy Available: 2505
The IETF Intellectual property rules are defined in RFC 3739, “Intellectual Property 2506
Rights in IETF technology” (updated by RFC 4879) 2507
2508
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-members 2509
can get access to published and non-published (draft) specifications and/or software : 2510
Access of published (RFCs) and non-published (Internet draft) specifications for 2511
members and non-members is open and free of payment 2512
2513
IETF WG 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4e ) 2514
2515
Description: 2516
The official website of IETF 6TiSCH (IPv6 over the TSCH mode of IEEE 2517
802.15.4e (6tisch) ) WG can be found via: 2518
https://datatracker.ietf.org/wg/6tisch/charter/. 2519
Low-power and Lossy Networks (LLNs) interconnect a possibly large number 2520
of resource-constrained nodes to form a wireless mesh network. The 2521
6LoWPAN, ROLL and CoRE IETF Working Groups have defined protocols at 2522
various layers of the protocol stack, including an IPv6 adaptation 2523
layer, a routing protocol and a web transfer protocol. This protocol 2524
stack has been used with IEEE802.15.4 low-power radios. 2525
The IEEE802.15.4e Timeslotted Channel Hopping (TSCH) is a recent 2526
amendment to the Medium Access Control (MAC) portion of the IEEE802.15.4 2527
standard. TSCH is the emerging standard for industrial automation and 2528
process control LLNs, with a direct inheritance from WirelessHART and 2529
ISA100.11a. Defining IPv6 over TSCH, 6TiSCH is a key to enable the 2530
further adoption of IPv6 in industrial standards and the convergence of 2531
Operational Technology (OT) with Information Technology (IT). 2532
The nodes in a IEEE802.15.4e TSCH network communicate by following a 2533
Time Division Multiple Access (TDMA) schedule. A timeslot in this 2534
schedule provides a unit of bandwidth that is allocated for 2535
communication between neighbour nodes. The allocation can be programmed 2536
such that the predictable transmission pattern matches the traffic. This 2537
avoids idle listening, and extends battery lifetime for constrained 2538
nodes. Channel-hopping improves reliability in the presence of narrow- 2539
band interference and multi-path fading. 2540
These techniques enable a new range of use cases for LLNs, including: 2541
- Control loops in a wireless process control network, in which high 2542
reliability and a fully deterministic behaviour are required. 2543
- Service Provider networks transporting data from different independent 2544
clients, and for which an operator needs flow isolation and traffic 2545
shaping. 2546
- Networks comprising energy harvesting nodes, which require an 2547
extremely low and predictable average power consumption. 2548
AIOTI – Restricted 60
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION IEEE802.15.4e only defines the link-layer mechanisms. It does not define 2549
how the network communication schedule is built and matched to the 2550
traffic requirements of the network. 2551
Description of Working Group: 2552
----------------------------- 2553
The Working Group will focus on enabling IPv6 over the TSCH mode of the 2554
IEEE802.15.4e standard. The extent of the problem space for the WG is 2555
one or more LLNs, eventually federated through a common backbone link 2556
via one or more LLN Border Routers (LBRs). The WG will rely on, and if 2557
necessary extend, existing mechanisms for authenticating LBRs. 2558
Initially, the WG will limit its scope to distributed routing over a 2559
static schedule. In that case, a node's schedule can be either 2560
preconfigured, or learnt by a node when joining the network, but it 2561
remains unchanged after the node has joined a network. The Routing 2562
Protocol for LLNs (RPL) is used on the resulting network. 2563
The WG will interface with other appropriate groups in the IETF 2564
Internet, Operations and Management, Routing and Security areas. 2565
Work Items: 2566
----------- 2567
The group will: 2568
1. Produce "6TiSCH architecture" to describe the design of 6TiSCH 2569
networks. This document will highlight the different architectural 2570
blocks and signalling flows, including the operation of the network in 2571
the presence of multiple LBRs. Initially, the document will focus on 2572
distributed routing operation over a static TSCH schedule. 2573
2. Produce an Information Model containing the management requirements 2574
of a 6TiSCH node. This includes describing how an entity can manage the 2575
TSCH schedule on a 6TiSCH node, and query timeslot information from that 2576
node. A data model mapping for an existing protocol (such as Concise 2577
Binary Object Representation (CBOR) over the Constrained Application 2578
Protocol (CoAP)) will be provided. 2579
3. Produce "Minimal 6TiSCH Configuration" defining how to build a 6TiSCH 2580
network using the Routing Protocol for LLNs (RPL) and a static TSCH 2581
schedule. It is expected that RPL and the Objective Function 0 (OF0) 2582
will be reused as-is. 2583
The work will include a best practice configuration for RPL and OF0 2584
operation over the static schedule. Based on that experience the group 2585
may produce a requirements draft for OF0 extensions, to be studied in ROLL. 2586
Non-milestone work items: 2587
------------------------- 2588
The Working Group may maintain a number of running, often-respun 2589
documents, that evolve as the technology is refined for work items that 2590
do not affect the milestone work items: 2591
- implementers guide: this document will collect clarifying information 2592
based on input from implementers, in particular as it becomes available 2593
from interoperability events. This guide will contain information about 2594
test harnesses used for interoperability testing. 2595
- coexistence guide: this document will provide information on how 2596
6TiSCH can be operated in an environment shared with other protocols 2597
that use the same or a similar TSCH MAC, and/or operate on the same 2598
frequency band. 2599
AIOTI – Restricted 61
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION The WG will welcome requirements for dynamic timeslot operation, for 2600
example for centralized schedule computation. 2601
2602
Readiness: 2603
1: Adoption (users base) 2604
Reference implementations and interoperability plug test events done by ETSI 2605
2. Development Status 2606
RFC 7557 Approved 2607
3. Compliance 2608
Not IETF responsibility 2609
4. Openness 2610
Open to public 2611
5. Ratification process (how the standard is being approved?) 2612
Open process for all parties interested in the ratification 2613
2614
Interoperability level: identify the interoperability levels considered by the 2615
SDO/Alliance/OSS initiative, see Appendix A for details: 2616
Syntactical interoperability 2617
Technical interoperability 2618
Semantic interoperability 2619
2620
Standards: standards and protocols proposed (SDO/Alliance) or supported 2621
(Alliance/OSS); Include details on whether an SDO/Alliance specified original protocols, 2622
or whether they are using and integrating standards and protocols developed by other 2623
SDOs 2624
Date Milestone
Dec 2015 6TiSCH architecture and terminology in RFC publication queue
Jun 2015 6TiSCH Minimal and 6top draft(s) in RFC publication queue
Dec 2014 Evaluate WG progress, propose new charter to the IESG
Dec 2014 Initial submission of 6TiSCH architecture to the IESG
draft-ietf-6tisch-architecture
Dec 2014 Initial submission of 6TiSCH terminology to the IESG
draft-ietf-6tisch-terminology
Nov 2014 Initial submission of 6TiSCH TSCH to the IESG
draft-ietf-6tisch-tsch
Nov 2014 Initial submission of 6TiSCH data model for CoAP to the IESG
draft-ietf-6tisch-coap
Nov 2014 Initial submission of 6top draft(s) to the IESG
draft-ietf-6tisch-6top-interface
Nov 2014 Initial submission of 6TiSCH minimal configuration to the IESG
draft-ietf-6tisch-minimal
Aug 2014 Submit 6TiSCH architecture for preliminary SECDIR review
Done Submit YANG data model in 6top draft for preliminary OPSDIR review
Done WG to adopt 6TiSCH terminology
Done WG to adopt 6TiSCH data model for CoAP
Done WG to adopt 6top draft(s)
Done WG to adopt 6TiSCH minimal configuration
AIOTI – Restricted 62
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
Date Milestone
Done WG to adopt 6TiSCH architecture
Done WG to adopt IEEE802.15.4e TSCH overview
Supporting organizations (mainly for Alliances/OSS): main organizations that back the 2625
initiative: 6TiSCH is an IETF WG. 2626
2627
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 2628
2, related to the market domain (consumer/industrial internet –horizontal axis) and the 2629
technical domain (connectivity, service&applications – vertical axis); 2630
Market domain: Located on the vertical axis, to show that it is equally used by the 2631
consumer and industrial internet market. 2632
Technical domain: Closer to the service&applications edge of the vertical axis 2633
2634
Application area: 2635
whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 2636
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is 2637
focusing on a particular vertical industry (e.g., Smart City), when applicable, see 2638
Figure 2 in Section 2 2639
6TiSCH WG is focusing on horizontal industry 2640
2641
Scope: mapping to knowledge areas of concerns in IoT. 2642
The 6TiSCH WG can be mapped to the following knowledge areas: 2643
Communication and Connectivity knowledge area: 2644
Integration/Interoperability knowledge area: 2645
Security and Privacy knowledge area: 2646
2647
IPR Policy Available: 2648
The IETF Intellectual property rules are defined in RFC 3739, “Intellectual 2649
Property Rights in IETF technology” (updated by RFC 4879) 2650
2651
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-2652
members can get access to published and non-published (draft) specifications and/or 2653
software : 2654
Access of published (RFCs) and non-published (Internet draft) specifications for 2655
members and non-members is open and free of payment 2656
2657
IETF WG ACE (Authentication and Authorization for Constrained Environments) 2658 2659
Description: 2660
The official website of IETF ACE (Authentication and Authorization for Constrained 2661
Environments) WG can be found via: http://datatracker.ietf.org/wg/ace/charter/. The 2662
below text is copied from this charter: 2663
This working group aims to produce a standardized solution for authentication and 2664
authorization to enable authorized access (Get, Put, Post, Delete) to resources identified 2665
by a URI and hosted on a resource server in constrained environments. As a starting 2666
point, the working group will assume that access to resources at a resource server by a 2667
client device takes place using CoAP and is protected by DTLS. Both resource server and 2668
client may be constrained. This access will be mediated by an authorization server, which 2669
is not considered to be. Existing authentication and authorization protocols will be 2670
evaluated and used where applicable to build the constrained-environment solution. 2671
AIOTI – Restricted 63
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION Leveraging existing work means the working group benefits from available security 2672
analysis, implementation, and deployment experience. Moreover, a standardized solution 2673
for federated authentication and authorization will help to stimulate the deployment of 2674
constrained devices that provide increased security. This working group has the 2675
following tasks: 2676
o Produce use cases and requirements 2677
o Identify authentication and authorization mechanisms suitable for resource 2678
access in constrained environments. 2679
2680
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); For each criterion please 2681
select one or more options. 2682
1. Adoption (users base) 2683
No implementations, yet 2684
2. Development Status 2685
Under development 2686
3. Compliance 2687
Having compliance testing process (include test suites, method, etc. ) 2688
Formal certification process 2689
4. Openness 2690
Open to public 2691
5. Ratification process (how the standard is being approved?) 2692
Done by members and open for consultation from external parties 2693
Open process for all parties interested in the ratification 2694
2695
Interoperability level: identify the interoperability levels considered by the SDO/Alliance/OSS 2696
initiative, see Appendix A for details: 2697
Syntactical interoperability 2698
Technical interoperability 2699
2700
Standards: 2701
The ACE WG is specifying the Authentication and Authorization Solution" specification. 2702
Documents produced by this WG can be found via: 2703
http://datatracker.ietf.org/wg/ace/documents/ 2704
ACE WG Charter is approved on 16-06-2014, but no RFCs have been produced yet. This 2705
working group has the following tasks: 2706
Produce use cases and requirements 2707
Identify authentication and authorization mechanisms suitable for resource 2708
access in constrained environments. 2709
Milestones: 2710
Mar 2016 Submit "Authentication and Authorization Solution" specification to 2711
the IESG for publication as a Proposed Standard. 2712
Sep 2015 (Done) submit "Use cases and Requirements" document to the IESG 2713
for publication as an Informational RFC. 2714
2715
Supporting organizations (mainly for Alliances/OSS): main organizations that back the initiative: 2716
ACE is an IETF WG. 2717
2718
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 2, 2719
related to the market domain (consumer/industrial internet –horizontal axis) and the technical 2720
domain (connectivity, service&applications – vertical axis): 2721
Market domain: Located on the vertical axis, to show that it is equally used by the 2722
consumer and industrial internet market. 2723
Technical domain: Closer to the service&applications edge of the vertical axis 2724
2725
AIOTI – Restricted 64
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
Application area: whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 2726
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is focusing on a 2727
particular vertical industry (e.g., Smart City), when applicable, see Figure 2 in Section 2: 2728
ACE WG is focusing on horizontal industry 2729
2730
Scope: mapping to knowledge areas of concerns in IoT. 2731
The identified knowledge areas are (Note that an initiative can be mapped to more than 2732
one knowledge areas): 2733
Communication and Connectivity knowledge area: 2734
o Application layer, which include management associated with the 2735
connectivity area 2736
Integration/Interoperability knowledge area: 2737
o supports common IoT features, such as publish a value or event and discover 2738
resources. 2739
Security and Privacy knowledge area: 2740
o covers security and privacy topics 2741
2742
IPR Policy Available: 2743
The IETF Intellectual property rules are defined in RFC 3739, “Intellectual Property 2744
Rights in IETF technology” (updated by RFC 4879) 2745
2746
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-members 2747
can get access to published and non-published (draft) specifications and/or software: 2748
Access of published (RFCs) and non-published (Internet draft) specifications for 2749
members and non-members is open and free of payment 2750
2751
IETF WG CORE (Constrained RESTful Environments) WG 2752
Description: 2753
The official website of IETF CORE (Constrained RESTful Environments) WG can be found 2754
via: http://datatracker.ietf.org/wg/core/charter/. The below text is copied from this charter: 2755
The CoRE working group will define a framework for a limited class of applications: those 2756
that deal with the manipulation of simple resources on constrained IP networks. A 2757
constrained IP network has limited packet sizes, may exhibit a high degree of packet loss, and 2758
may have a substantial number of devices that may be powered off at any point in time but 2759
periodically "wake up" for brief periods of time. As part of the framework for building these 2760
applications, the WG will define a Constrained Application Protocol (CoAP) for the 2761
manipulation of Resources on a Device. CoAP will be designed for use between Devices on 2762
the same constrained network, between Devices and general nodes on the Internet, and 2763
between Devices on different constrained networks both joined by an internet. 2764
The initial work item of the WG is to define a protocol specification for CoAP that includes: 2765
The ability to create, read, update and delete a Resource on a Device. 2766
The ability to allow a Device to publish a value or event to another Device that has 2767
subscribed to be notified of changes, as well as the way for a Device to subscribe to 2768
receive publishes from another Device. 2769
The ability to support a non-reliable multicast message to be sent to a group of 2770
Devices to manipulate a resource on all the Devices in the group. 2771
The core CoAP functionality MUST operate well over UDP and UDP MUST 2772
be implemented on CoAP Devices. There may be OPTIONAL functions in CoAP 2773
(e.g. delivery of larger chunks of data) which if implemented are implemented over 2774
TCP. Applications which require the optional TCP features will limit themselves to a 2775
narrower subset of deployment cases. 2776
A definition of how to use CoAP to advertise about or query for a Device's 2777
description. This description may include the device name and a list of its Resources, 2778
each with a URL, an interface description URI (pointing e.g. to a Web Application 2779
AIOTI – Restricted 65
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
Description Language (WADL) document) and an optional name or identifier. The 2780
name taxonomy used for this description will be consistent with other IETF work. 2781
Specification for the HTTP REST based API and translation to communicate with 2782
Devices. Translation should make use of Device description information and should 2783
not need code updates to deal with new Devices. 2784
Consider operational and manageability aspects of the protocol and at a minimum 2785
provide a way to tell if a Device is powered on or not. 2786
Readiness: 2787
1: Adoption (users base) 2788
Reference implementations 2789
Widely adopted in industry 2790
2. Development Status 2791
Approved with planned revisions 2792
3. Compliance 2793
Having compliance testing process (include test suites, method, etc. ) 2794
Formal certification process 2795
4. Openness 2796
Open to public 2797
5. Ratification process (how the standard is being approved?) 2798
Done by members and open for consultation from external parties 2799
Open process for all parties interested in the ratification 2800
2801
Interoperability level: identify the interoperability levels considered by the SDO/Alliance/OSS 2802
initiative, see Appendix A for details: 2803
Syntactical interoperability 2804
Technical interoperability 2805
Semantic interoperability 2806
2807
Standards: 2808
The IETF CORE WG is specifying the COAP protocol. The produced documents can be 2809
retrieved via: http://datatracker.ietf.org/wg/core/documents/ 2810
The produced IETF RFCs are: 2811
RFC 6690: Constrained RESTful Environments (CoRE) 2812
RFC 7252: The Constrained Application Protocol (CoAP) 2813
RFC 7390: Group Communication for the Constrained Application Protocol (CoAP) 2814
2815
Supporting organizations (mainly for Alliances/OSS): main organizations that back the initiative: 2816
CORE is an IETF WG. 2817
2818
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 2, 2819
related to the market domain (consumer/industrial internet –horizontal axis) and the technical 2820
domain (connectivity, service&applications – vertical axis); 2821
Market domain: Located on the vertical axis, to show that it is equally used by the 2822
consumer and industrial internet market. 2823
Technical domain: Closer to the service&applications edge of the vertical axis 2824
2825
Application area: 2826
whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 2827
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is focusing on a 2828
particular vertical industry (e.g., Smart City), when applicable, see Figure 2 in Section 2 2829
CORE WG is focusing on horizontal industry 2830
2831
Scope: mapping to knowledge areas of concerns in IoT. 2832
The CORE WG can be mapped to the following knowledge areas: 2833
AIOTI – Restricted 66
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION Communication and Connectivity knowledge area: 2834
o Application layer, which include management associated with the 2835
connectivity area 2836
Integration/Interoperability knowledge area: 2837
o supports common IoT features, such as publish a value or event and discover 2838
resources. 2839
Security and Privacy knowledge area: 2840
o covers security and privacy topics 2841
2842
IPR Policy Available: 2843
The IETF Intellectual property rules are defined in RFC 3739, “Intellectual Property 2844
Rights in IETF technology” (updated by RFC 4879) 2845
2846
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-members 2847
can get access to published and non-published (draft) specifications and/or software : 2848
Access of published (RFCs) and non-published (Internet draft) specifications for 2849
members and non-members is open and free of payment 2850
2851
IETF WG COSE (CBOR Encoded Message Syntax) 2852
Description: 2853
The official website of IETF COSE (CBOR Encoded Message Syntax) WG can be found 2854
via: http://datatracker.ietf.org/wg/cose/charter/. The below text is copied from this 2855
charter. 2856
Concise Binary Object Representation (CBOR, RFC 7049) is a concise binary format for 2857
the serialization of data structured to an extended version of the JSON data model. COSE 2858
seeks to create CBOR-based object signing and encryption formats. One motivation for 2859
COSE was to reuse functionality from the JOSE working group using the CBOR data 2860
representation as it is more amenable to constrained nodes and constrained node 2861
networks (RFC 7228). The JOSE working group recently completed producing 2862
representations for cryptographic keys, message authentication (MACs), encryption, and 2863
digital signatures, using JSON representation. The resulting formats will not be 2864
cryptographically convertible from or to JOSE formats. This lack of a need for bit-for-bit 2865
compatibility will enable some simplification in the adaptation process. Criteria that 2866
should be considered in the decision making process, changing from JSON to CBOR 2867
encoding include: 2868
o Maintain the current JOSE paradigms and formatting where feasible. 2869
o Minimize message size, code size, and computational complexity to suit 2870
constrained environments, where this is expected to be used. 2871
o Improve security 2872
o Provide new functionality for additional use cases that were not required for 2873
JOSE. 2874
The WG will produce two deliverables: 2875
o A standards-track specification covering the same cryptographic formats from 2876
JOSE, with optimizations for constrained device processing, expressed in CBOR; 2877
o Registration for algorithms (such as AES-CCM-8) that are appropriate for 2878
constrained environments. 2879
2880
Readiness: 2881
1. Adoption (users base) 2882
No implementations, yet 2883
2. Development Status 2884
Under development 2885
3. Compliance 2886
Having compliance testing process (include test suites, method, etc. ) 2887
AIOTI – Restricted 67
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION Formal certification process 2888
4. Openness 2889
Open to public 2890
5. Ratification process (how the standard is being approved?) 2891
Done by members and open for consultation from external parties 2892
Open process for all parties interested in the ratification 2893
2894
Interoperability level: identify the interoperability levels considered by the SDO/Alliance/OSS 2895
initiative, see Appendix A for details: 2896
Syntactical interoperability 2897
Technical interoperability 2898
2899
Standards: standards and protocols proposed (SDO/Alliance) or supported (Alliance/OSS); 2900
Include details on whether an SDO/Alliance specified original protocols, or whether they are 2901
using and integrating standards and protocols developed by other SDOs 2902
o The IETF COSE WG is working on a standards-track specification covering the same 2903
cryptographic formats from JOSE, with optimizations for constrained device processing, 2904
expressed in CBOR. Documents produced by this WG can be found via: 2905
http://datatracker.ietf.org/wg/cose/documents/ 2906
The COSE WG charter has been approved on 3rd
of June 2015, but no RFCs have been 2907
produced yet. This working group has the following tasks on producing: 2908
A standards-track specification covering the same cryptographic formats from 2909
JOSE, with optimizations for constrained device processing, expressed in CBOR; 2910
Registration for algorithms (such as AES-CCM-8) that are appropriate for 2911
constrained environments. 2912
Milestones: 2913
Jan 2016 Submit COSE constrained-appropriate algorithms to the IESG, for 2914
publication as a Proposed Standard 2915
Jan 2016 Submit COSE specification to the IESG, for publication as a Proposed 2916
Standard 2917
Jun 2015 Submit COSE constrained-appropriate algorithms as a WG item 2918
Jun 2015 Submit COSE specification as a WG item 2919
2920
Supporting organizations (mainly for Alliances/OSS): main organizations that back the initiative: 2921
COSE is an IETF WG. 2922
2923
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 2, 2924
related to the market domain (consumer/industrial internet –horizontal axis) and the technical 2925
domain (connectivity, service&applications – vertical axis); 2926
Market domain: Located on the vertical axis, to show that it is equally used by the 2927
consumer and industrial internet market. 2928
Technical domain: Closer to the service&applications edge of the vertical axis 2929
2930
Application area: whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 2931
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is focusing on a 2932
particular vertical industry (e.g., Smart City), when applicable, see Figure 2 in Section 2: 2933
COSE WG is focusing on horizontal industry 2934
2935
Scope: mapping to knowledge areas of concerns in IoT. 2936
The identified knowledge areas are (Note that an initiative can be mapped to more than 2937
one knowledge areas): 2938
Communication and Connectivity knowledge area: 2939
o Application layer, which include management associated with the 2940
connectivity area 2941
AIOTI – Restricted 68
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION Integration/Interoperability knowledge area: 2942
o supports common IoT features, such as publish a value or event and discover 2943
resources. 2944
Security and Privacy knowledge area: 2945
o covers security and privacy topics 2946
2947
IPR Policy Available: 2948
o The IETF Intellectual property rules are defined in RFC 3739, “Intellectual Property Rights 2949
in IETF technology” (updated by RFC 4879) 2950
2951
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-members can 2952
get access to published and non-published (draft) specifications and/or software: 2953
o Access of published (RFCs) and non-published (Internet draft) specifications for members 2954
and non-members is open and free of payment 2955
2956
IETF WG Deterministic Networking (DetNet)) 2957
Description: 2958
The official website of IETF DetNet (Deterministic Networking 2959
(DetNet)) WG can be found via: https://datatracker.ietf.org/wg/DetNet/charter/. 2960
The Deterministic Networking (DetNet) Working Group focuses on 2961
deterministic data paths that operate over Layer 2 bridged and Layer 3 2962
routed segments, where such paths can provide bounds on latency, loss, 2963
and packet delay variation (jitter), and high reliability. The Working 2964
Group addresses Layer 3 aspects in support of applications requiring 2965
deterministic networking. The Working Group collaborates with IEEE802.1 2966
Time Sensitive Networking (TSN), which is responsible for Layer 2 2967
operations, to define a common architecture for both Layer 2 and Layer 2968
3. Example applications for deterministic networks include professional 2969
and home audio/video, multimedia in transportation, engine control 2970
systems, and other general industrial and vehicular applications being 2971
consider by the IEEE 802.1 TSN Task Group. 2972
The Working Group will initially focus on solutions for networks that 2973
are under a single administrative control or within a closed group of 2974
administrative control; these include not only campus-wide networks but 2975
also can include private WANs. The DetNet WG will not spend energy on 2976
solutions for large groups of domains such as the Internet. 2977
The Working Group will specify an overall architecture that encompasses 2978
the data plane, OAM (Operations, Administration, and Maintenance), time 2979
synchronization, management, control, and security aspects which are 2980
required to enable a multi-hop path, and forwarding along the path, with 2981
the deterministic properties of controlled latency, low packet loss, low 2982
packet delay variation, and high reliability. The work applies to 2983
point-to-point (unicast) and point-to-multipoint (multicast) flows which 2984
can be characterized in a manner that allows the network to 1) reserve 2985
the appropriate resources for the flows in advance, and 2) release/reuse 2986
the resources when they are no longer required. The work covers the 2987
characterization of flows, the encapsulation of frames, the required 2988
forwarding behaviours, as well as the state that may need to be 2989
established in intermediate nodes. Candidate Layer 3 data plane 2990
AIOTI – Restricted 69
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION technologies that may be used, without modification, include: IP and 2991
MPLS. 2992
The working group will document which deployment environments and types 2993
of topologies are within (or outside) the scope of the DetNet 2994
architecture. This work focuses on the data plane aspects and is 2995
independent from any path setup protocol or mechanism. The data plane 2996
will be compatible with the work done in IEEE802.1 TSN. 2997
The Working Group's scope explicitly excludes modifications of transport 2998
protocols, OAM, Layer 3 forwarding, encapsulations, and control plane 2999
protocols. 3000
DetNet is chartered to work in the following areas: 3001
Overall architecture: This work encompasses the data plane, OAM, 3002
time synchronization, management, control, and security aspects. 3003
Data plane: This work will document how to use IP and/or MPLS to 3004
support a data plane method of flow identification and packet 3005
forwarding over Layer 3. 3006
Data flow information model: This work will identify the information 3007
needed for flow establishment and control and be used by a 3008
reservation protocol or by YANG data models. The work will be 3009
independent from the protocol(s) used to control the flows 3010
(e.g. YANG+NETCONF/RESTCONF, PCEP or GMPLS). 3011
Identification of additional YANG models: This work will document 3012
device and link capabilities (feature support) and resources 3013
(e.g. buffers, bandwidth) for use in device configuration and status 3014
reporting. Such information may also be used when advertising the 3015
deterministic network elements to a control plane. Control plane 3016
related information will be independent from the protocol(s) which 3017
may be used to advertise this information (e.g. IS-IS or GMPLS 3018
extensions). Any new YANG models will be coordinated with the 3019
Working Groups that define any augmented base models. 3020
As needed, problem statement: This effort will establish the 3021
deployment environment and deterministic network requirements. 3022
As needed, vertical requirements: This effort will detail the 3023
requirements for deterministic networks in various industries, for 3024
example, professional audio, electrical utilities, building 3025
automation systems, wireless for industrial applications. 3026
To investigate whether existing data plane encryption mechanisms can 3027
be applied, possibly opportunistically, to improve security and 3028
privacy. 3029
AIOTI – Restricted 70
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION The WG coordinates with other relevant IETF Working Groups, including 3030
CCAMP, PCE, PALS, TEAS, OSPF, IS-IS, TSVWG, and 6TisSCH. As the work 3031
progresses, requirements may be provided to the responsible Working 3032
Group, e.g. PCE, TEAS, and CCAMP, with DetNet acting as a focal point to 3033
maintain the consistency of the overall architecture. The WG will liaise 3034
with appropriate groups in IEEE and other Standards Development 3035
Organizations (SDOs). 3036
WG deliverables include: 3037
As standard track or informational RFCs 3038
Overall architecture 3039
Data plane specification 3040
Data flow information model 3041
YANG model augmentations 3042
WG sustaining/informational documents may include: 3043
These documents may not necessarily be published, but may be 3044
maintained in a draft form or on a collaborative Working Group wiki 3045
to support the efforts of the Working Group and help new comers: 3046
Problem statement and (constrained) deployment environments 3047
User-driven use cases 3048
Readiness: 3049
1: Adoption (users base) 3050
Working Group not officially formed 3051
2. Development Status 3052
draft-finn-detnet-problem-statement-03
Deterministic Networking Problem Statement
draft-gunther-detnet-proaudio-req-01
Deterministic Networking Professional Audio Requirements
draft-korhonen-detnet-telreq-00
Deterministic networking for radio access networks
draft-wetterwald-detnet-utilities-reqs-02
Deterministic Networking Uitilities requirements
draft-zha-detnet-use-case-00
Deterministic Networking Use Case in Mobile Network
draft-dujovne-detnet-gap-analysis-01
AIOTI – Restricted 71
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
Deterministic Networks Gap Analysis
3. Compliance 3053
Not IETF responsibility 3054
4. Openness 3055
Open to public 3056
5. Ratification process (how the standard is being approved?) 3057
Open process for all parties interested in the ratification 3058
3059
Interoperability level: identify the interoperability levels considered by the 3060
SDO/Alliance/OSS initiative, see Appendix A for details: 3061
Syntactical interoperability 3062
Technical interoperability 3063
Semantic interoperability 3064
3065
Standards: standards and protocols proposed (SDO/Alliance) or supported 3066
(Alliance/OSS); Include details on whether an SDO/Alliance specified original protocols, 3067
or whether they are using and integrating standards and protocols developed by other 3068
SDOs 3069
3070
Supporting organizations (mainly for Alliances/OSS): main organizations that back the 3071
initiative: DetNet is an IETF WG. 3072
3073
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 3074
2, related to the market domain (consumer/industrial internet –horizontal axis) and the 3075
technical domain (connectivity, service&applications – vertical axis); 3076
Market domain: Located on the vertical axis, to show that it is equally used by the 3077
consumer and industrial internet market. 3078
Technical domain: Closer to the service&applications edge of the vertical axis 3079
3080
Application area: 3081
whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 3082
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is 3083
focusing on a particular vertical industry (e.g., Smart City), when applicable, see 3084
Figure 2 in Section 2 3085
DetNet WG is focusing on horizontal industry 3086
3087
Scope: mapping to knowledge areas of concerns in IoT. 3088
The DetNet WG can be mapped to the following knowledge areas: 3089
Communication and Connectivity knowledge area: 3090
o Application layer, which include management associated with the 3091
connectivity area 3092
Integration/Interoperability knowledge area: 3093
o supports common IoT features, such as publish a value or event and 3094
discover resources. 3095
Security and Privacy knowledge area: 3096
o covers security and privacy topics 3097
AIOTI – Restricted 72
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
3098
IPR Policy Available: 3099
The IETF Intellectual property rules are defined in RFC 3739, “Intellectual 3100
Property Rights in IETF technology” (updated by RFC 4879) 3101
3102
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-3103
members can get access to published and non-published (draft) specifications and/or 3104
software : 3105
Access of published (RFCs) and non-published (Internet draft) specifications for 3106
members and non-members is open and free of payment 3107
3108
IETF WG Dice (DTLS In Constrained Environments) 3109
Description: 3110
The official website of IETF Dice (DTLS In Constrained Environments (Dice)) 3111
WG can be found via: https://datatracker.ietf.org/wg/dice/charter/. 3112
The Constrained Application Protocol (CoAP) can be used to manipulate resources on a 3113
device in constrained environments secured by Datagram Transport Layer Security 3114
(DTLS, RFC 6347). The DTLS In Constrained Environments (DICE) working group 3115
focuses on supporting the use of DTLS Transport-Layer Security in these environments. 3116
Constrained environments looked at in DICE include constrained devices (e.g. memory, 3117
algorithm choices) and constrained networks (e.g. PDU sizes, packet loss). 3118
The first task of the working group is to define a DTLS profile that is suitable for Internet 3119
of Things applications and is reasonably implementable on many constrained devices. 3120
The second task of the working group is to define how DTLS record layer can be used to 3121
transmit multicast messages securely. Security for these multicast messages is needed in 3122
many Internet of Things environments, as some messages are commonly multicast 3123
among a set of receivers. Session keys are needed in order to use the DTLS record layer 3124
in this way. Changes to the DTLS handshake to support this may be needed in future but 3125
are not part of the initial charter for DICE WG. 3126
The third task of the working group is to investigate practical issues around the DTLS 3127
handshake in constrained environments. Many current systems end up fragmenting 3128
messages, and the re-transmission and re-ordering of handshake messages results in 3129
significant complexity and reliability problems. Additional reliability mechanisms for 3130
transporting DTLS handshake messages are required as they will ensure that handling of 3131
re-ordered messages needs to be done only once in a single place in the stack. The DICE 3132
working group may also look at alternative TLS transports in cooperation with the TLS 3133
WG. 3134
The DTLS state machine should not be modified and key management (including for 3135
multicast security) and multi-cast session setup are out the scope for the initial work. 3136
The DICE working group will work closely with the TLS, CoRE and LWIG working 3137
groups. 3138
Readiness: 3139
1: Adoption (users base) 3140
Widely used in the industry 3141
AIOTI – Restricted 73
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
2. Development Status 3142
draft-ietf-dice-profile-16
3. Compliance 3143
Not IETF responsibility 3144
4. Openness 3145
Open to public 3146
5. Ratification process (how the standard is being approved?) 3147
Open process for all parties interested in the ratification 3148
3149
Interoperability level: identify the interoperability levels considered by the 3150
SDO/Alliance/OSS initiative, see Appendix A for details: 3151
Syntactical interoperability 3152
Technical interoperability 3153
Semantic interoperability 3154
3155
Standards: standards and protocols proposed (SDO/Alliance) or supported 3156
(Alliance/OSS); Include details on whether an SDO/Alliance specified original protocols, 3157
or whether they are using and integrating standards and protocols developed by other 3158
SDOs 3159
Date Milestone
Jun 2014
Secure group communication specification
submitted to the IESG for publication as
standards track
May 2014 DTLS for IoT profile specification submitted to
the IESG for publication as standards track
Dec 2013 WG document for secure group communication
for IoT
Dec 2013 WG document for DTLS for Constrained
Environments profile
Supporting organizations (mainly for Alliances/OSS): main organizations that back the 3160
initiative: Dice is an IETF WG. 3161
3162
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 3163
2, related to the market domain (consumer/industrial internet –horizontal axis) and the 3164
technical domain (connectivity, service&applications – vertical axis); 3165
Market domain: Located on the vertical axis, to show that it is equally used by the 3166
consumer and industrial internet market. 3167
Technical domain: Closer to the service&applications edge of the vertical axis 3168
3169
Application area: 3170
whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 3171
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is 3172
focusing on a particular vertical industry (e.g., Smart City), when applicable, see 3173
Figure 2 in Section 2 3174
Dice WG is focusing on horizontal industry 3175
3176
Scope: mapping to knowledge areas of concerns in IoT. 3177
The Dice WG can be mapped to the following knowledge areas: 3178
AIOTI – Restricted 74
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION Communication and Connectivity knowledge area: 3179
o Application layer, which include management associated with the 3180
connectivity area 3181
Integration/Interoperability knowledge area: 3182
o supports common IoT features, such as publish a value or event and 3183
discover resources. 3184
Security and Privacy knowledge area: 3185
o covers security and privacy topics 3186
3187
IPR Policy Available: 3188
The IETF Intellectual property rules are defined in RFC 3739, “Intellectual 3189
Property Rights in IETF technology” (updated by RFC 4879) 3190
3191
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-3192
members can get access to published and non-published (draft) specifications and/or 3193
software : 3194
Access of published (RFCs) and non-published (Internet draft) specifications for 3195
members and non-members is open and free of payment 3196
5.2.10 IRTF (Internet Research Task Force): T2T RG (Thing to Thing) proposed RG 3197
Description: 3198
The T2T (Thing to Thing) proposed RG is not yet an official IRTF Research Group, 3199
but it can become an official one if there is satisfactory participation. More details 3200
regarding the T2T RG can be found via: https://github.com/t2trg/2015-ietf92 3201
The T2t RG will investigate open research issues in turning a true “Internet of 3202
Things” into reality, and on an Internet where low-resource nodes (“Things”, 3203
“Constrained Nodes”) can communicate among themselves and with the wider 3204
Internet, in order to partake in permissionless innovation. 3205
The focus of this RG will be on issues that touch opportunities for standardization in 3206
the IETF 3207
start at the adaptation layer connecting devices to IP, and 3208
end at the application layer with architectures and APIs for communicating 3209
and making data and management functions (including security functions) 3210
available. 3211
3212
The main areas of interest are: 3213
Understanding and managing the motivation for single purpose silos and 3214
gateways; facilitating a move towards small pieces loosely joined (hence 3215
“thing-to-thing”); scaling the number of applications in a single network 3216
Deployment considerations; scaling considerations; cost of ownership 3217
Management and Operation of Things 3218
Lifecycle aspects (including, but not limited to, security considerations) 3219
Cooperation with W3C, e.g. on data formats and semantics 3220
3221
Readiness: 3222
1. Adoption (users base) 3223
No implementations, yet 3224
2. Development Status 3225
Under development 3226
AIOTI – Restricted 75
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
3. Compliance 3227
Having compliance testing process (include test suites, method, etc. ) 3228
Formal certification process 3229
4. Openness 3230
Open to public 3231
5. Ratification process (how the standard is being approved?) 3232
Done by members and open for consultation from external parties 3233
Open process for all parties interested in the ratification 3234
3235
Interoperability level: identify the interoperability levels considered by the 3236
SDO/Alliance/OSS initiative, see Appendix A for details: 3237
Syntactical interoperability 3238
Technical interoperability 3239
Semantic interoperability 3240
3241
Standards: standards and protocols proposed (SDO/Alliance) or supported 3242
(Alliance/OSS); Include details on whether an SDO/Alliance specified original protocols, 3243
or whether they are using and integrating standards and protocols developed by other 3244
SDOs 3245
o The T2T RG is a proposed IRTF Research Group that will be using and providing 3246
input mainly to IETF, but also to the IOT research community. It has not 3247
produced any RFCs yet. 3248
3249
Supporting organizations (mainly for Alliances/OSS): main organizations that back the 3250
initiative: T2T (proposed) RG is belonging to IRTF that is closely cooperating with the 3251
IETF and it represents the research activities of IETF. 3252
3253
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 3254
2, related to the market domain (consumer/industrial internet –horizontal axis) and the 3255
technical domain (connectivity, service&applications – vertical axis); 3256
Market domain: Located on the vertical axis, to show that it is equally used by the 3257
consumer and industrial internet market. 3258
Technical domain: Closer to the service&applications edge of the vertical axis 3259
3260
Application area: whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing 3261
on integrated/complete IoT solutions, i.e. horizontal industry, or whether it is focusing on 3262
a particular vertical industry (e.g., Smart City), when applicable, see Figure 2 in Section 2 3263
IRTF T2T RG is focusing on horizontal industry 3264
3265
Scope: mapping to knowledge areas of concerns in IoT. 3266
The identified knowledge areas are (Note that an initiative can be mapped to more 3267
than one knowledge areas): 3268
Communication and Connectivity knowledge area: 3269
o Application layer, which include management associated with the 3270
connectivity area 3271
Integration/Interoperability knowledge area: 3272
o supports common IoT features, such as publish a value or event and 3273
discover resources. 3274
IoT Architecture knowledge area: 3275
AIOTI – Restricted 76
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
o plans to cover integrated/complete IoT specification solutions, 3276
including architecture descriptions. However, this is not yet agreed. 3277
Security and Privacy knowledge area: 3278
o covers security and privacy topics 3279
3280
IPR Policy Available: 3281
The IRTF follows the IETF Intellectual Property Rights (IPR) disclosure rules, 3282
https://irtf.org/ipr. This is a summary of these rules as they relate to IRTF research 3283
group discussions, mailing lists and Internet Drafts: 3284
o If you include your own or your employer’s IPR in a contribution to an IRTF 3285
research group, then you must file an IPR disclosure with the IETF. 3286
o If you recognize your own or your employer’s IPR in someone else’s 3287
contribution and you are participating in the discussions in the research group 3288
relating to that contribution, then you must file an IPR disclosure with the 3289
IETF. Even if you are not participating in the discussion, the IRTF still 3290
requests that you file an IPR disclosure with the IETF. 3291
o Finally, the IRTF requests that you file an IPR disclosure with the IETF if you 3292
recognize IPR owned by others in any IRTF contribution. 3293
The IRTF expects that you file IPR disclosures in a timely manner, i.e., in a 3294
period measured in days or weeks, not months. The IRTF prefers that the most 3295
liberal licensing terms possible are available for IRTF Stream documents, see 3296
RFC 5743. You may file an IPR disclosure here: http://www.ietf.org/ipr/file-3297
disclosure 3298
3299
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-3300
members can get access to published and non-published (draft) specifications and/or 3301
software 3302
Access of published (RFCs) and non-published (Internet draft) specifications for 3303
members and non-members is open and free of payment 3304
5.2.11 International Telecommunication Union – Telecommunication Standardization Sector 3305
(ITU-T) 3306
Description: International Telecommunication Union – Telecommunication 3307
Standardization Sector (ITU-T) 3308
The Study Groups of ITU-T assemble experts from around the world to develop 3309
international standards known as ITU-T Recommendations which act as defining 3310
elements in the global ICTs. 3311
ITU-T Study Group 20 [“IoT and its applications including smart cities and communities 3312
(SC&C)”], established in June 2015 and holding its first meeting in October 2015, is 3313
going to become the central venue of IoT standardization activities within ITU-T. 3314
SG20 will work to address the standardization requirements of Internet of Things (IoT) 3315
technologies, with an initial focus on IoT applications in smart cities and communities 3316
(SC&C). 3317
SG20, via the Joint Coordination Activity on Internet of Things whose supervision has 3318
been assigned to SG20, will ensure the coordination of IoT related studies across the 3319
various involved ITU-T Study Groups as well as with external SDOs, Alliances and 3320
Consortia. 3321
Specific study items of SG20 will include: 3322
o the development of international standards to enable the coordinated development of 3323
IoT technologies, including machine-to-machine communications and ubiquitous 3324
sensor networks. A central part of this study is the standardization of end-to-end 3325
AIOTI – Restricted 77
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
architectures for IoT, and mechanisms for the interoperability of IoT applications and 3326
datasets employed by various vertically oriented industry sectors. 3327
o the development of standards that leverage IoT technologies to address urban-3328
development challenges. 3329
3330
The IoT related specifications already published by ITU-T and the main IoT related 3331
activities of ITU-T have essentially involved Study Group 11, Study Group 13, Study 3332
Group 16 and Study Group 17 (the key involved Study Groups - September 2015 status): 3333
o SG11 has focused on the interoperability, protocol and testing aspects of IoT; 3334
o SG13 has mainly focused on the network aspects of IoT; 3335
o SG16 has mainly focused on the application aspects of IoT; 3336
o SG17 has focused on the security aspects of IoT. 3337
Other IoT related activities have been progressed within specific ITU-T Focus Groups 3338
which, by nature, do not generate standards: the main IoT related Focus Groups (now 3339
closed) have been the Focus Group on M2M Service Layer, the Focus Group on Smart 3340
Water Management and the Focus Group on Smart Sustainable Cities. 3341
Other complementary IoT activities have been progressed within Study Group 15 (Smart 3342
Grid and Home Network aspects) and the Collaboration on ITS Communication 3343
Standards. 3344
Future IoT activities are expected to involve also Study Group 2 (naming, numbering, 3345
addressing and identification; service definitions) and Study Group 3 (tariff and 3346
economic aspects). 3347
3348
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); For each criterion 3349
please select one or more options. 3350
1. Adoption (users base) 3351
No implementations/Reference implementations/Widely adopted in industry 3352
(according to the particular specification) 3353
2. Development Status 3354
Under development/ Approved with no planned revisions/ Approved with planned 3355
revisions (according to the particular specification) 3356
3. Compliance 3357
Not managed/Having compliance testing process (according to the particular 3358
specification). No process implemented yet for any IoT related specification. 3359
4. Openness 3360
o Open by formal membership 3361
5. Ratification process (how the standard is being approved?) 3362
Closed process done by members only with no consultation from external parties 3363
NOTE – In some specific cases, it can be done by members and open for consultation 3364
from external parties, previous agreement with the external parties. 3365
3366
Interoperability level: identify the interoperability levels considered by the 3367
SDO/Alliance/OSS initiative, see Appendix A for details: 3368
Technical interoperability/Syntactical interoperability (according to the particular 3369
specification) 3370
NOTE – Some specific ongoing studies are considering Semantic interoperability 3371
aspects (to be completed). 3372
3373
Standards: standards and protocols proposed (SDO/Alliance) or supported 3374
(Alliance/OSS); Include details on whether an SDO/Alliance specified original protocols, 3375
AIOTI – Restricted 78
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
or whether they are using and integrating standards and protocols developed by other 3376
SDOs 3377
Various standards have been proposed in published specifications (and others are 3378
considered in some ongoing studies). to be completed 3379
Some published specifications use and integrate standards and protocols developed by 3380
other SDOs (and other SDOs’ standards and protocols are considered in some ongoing 3381
studies). to be completed 3382
List of main published specifications to be added 3383
3384
Supporting organizations (mainly for Alliances/OSS): main organizations that back the 3385
initiative 3386
Telecommunication Hardware and Software Providers 3387
Service Providers, Network Providers, Application Provider, Integrators 3388
Member State entities (Administration entities, Academies, Public Research) 3389
National Regulation Authorities 3390
Other National and Regional Entities 3391
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in 3392
Section 0, related to the market domain (consumer/industrial internet –horizontal axis) 3393
and the technical domain (connectivity, service&applications – vertical axis); 3394
Most of the activities target the market without specific focus on consumer versus 3395
industrial internet - some special cases to be provided. 3396
Both sides of the technology domain are targeted, according to the particular 3397
specification. 3398
3399
Application area: whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 3400
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is focusing on a 3401
particular vertical industry (e.g., Smart City), when applicable, see Figure 2 in Section 2 3402
Focus on integrated/complete IoT solutions, i.e. horizontal industry: numerous 3403
activities (in all involved Study Groups, including SG20); 3404
Focus on particular vertical industries (September 2015status): Home/Building 3405
(SG13, SG15), Vehicular/Transportation (SG16), Healthcare (SG13, SG16), 3406
Cities (SG20), Farming/Agrifood (SG13). NOTE – In perspective, SG20 will be 3407
involved in all vertical industries. 3408
3409
Scope: mapping to knowledge areas of concerns in IoT. The identified knowledge areas 3410
are (Note that an initiative can be mapped to more than one knowledge areas): 3411
o All knowledge areas are concerned. At present time, the involved key Study 3412
Groups have mainly focused their activities, respectively, in the following areas: 3413
Communication and Connectivity knowledge area: SG11, SG13, (SG20) 3414
Integration/Interoperability knowledge area: SG11, SG13, (SG20) 3415
Applications knowledge area: SG13, SG16, (SG20) 3416
Infrastructure knowledge area:SG11, SG13, (SG20) 3417
IoT Architecture knowledge area: SG11, SG13, SG16, (SG20) 3418
Devices and sensor technology knowledge area: SG16 3419
Security and Privacy knowledge area: SG17, (SG20) 3420
3421
IPR Policy Available: mention if there is any IPR policy available (e.g., FRAND); if 3422
available include a reference to the description of this IPR policy 3423
ITU / ISO / IEC code of practice. 3424
AIOTI – Restricted 79
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION All details can be found at http://www.itu.int/en/ITU-T/ipr/Pages/default.aspx 3425
3426
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-3427
members can get access to published and non-published (draft) specifications and/or 3428
software 3429
o Published specifications: the vast majority is accessible to all free of charge once 3430
a final editing process is complete. Texts that are not free of charge include 3431
common ITU-T | ISO / IEC texts for which special arrangements exist. 3432
o Non-published specifications: freely accessible to members only; not accessible to 3433
non-members. 3434
5.2.12 (ISO/IEC) JTC1/WG10 Internet of Things 3435
Description: 3436
ISO and IEC have a joint technical committee called JTC 1. JTC1 is a member based 3437
organization with the possibility of one member from each country. In 2015 JTC1 3438
had 76 members. Standardization in JTC1 is builds on the WTO agreements on 3439
Technical Barriers to Trade. 3440
In 2012 ISO/IEC JTC 1 initiated preparatory work in the field of IoT. At the JTC1 3441
meeting in November 2014 the IoT report was accepted as presented by all members 3442
of JTC1. As a consequence of the report and its acceptance, JTC1 decided to establish 3443
a working group on IoT with the mandate to develop foundational standards. 3444
3445
Mission Statement: 3446
The working group has prepared a Strategic business plan but it will be confirmed at 3447
the upcoming JTC1 meeting in October in China. Until then the WG has the mandate 3448
to develop one standard which has got the following title and scope: 3449
Title: Information technology – Internet of Things Reference Architecture (IoT RA) 3450
Scope of the proposed deliverable – This new work item specifies IoT Conceptual 3451
Model, conceptual reference model, and reference architecture from different 3452
architectural views, common entities, and interfaces between IoT domains 3453
3454
Business Impact: 3455
All business will benefit from an international IoT standard provided from an 3456
conceptual to business specific IoT Architectures 3457
3458
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); For each criterion 3459
please select one or more options. 3460
1. Adoption (users base) 3461
Developing use cases as considerations for Reference Architecture 3462
The ISO/IEC JTC 1 standard is expected to be widely adopted in industry 3463
3464
2. Development Status 3465
In progress 3466
3467
3. Compliance 3468
Through 13external and 11internal liaisons with other SDO’s receiving input 3469
that balance with own work for selecting solutions to standards issues 3470
4. Openness 3471
Every standard document passes 6 stages to be realized as an international 3472
standard. National experts comment the documents at every stage for quality 3473
AIOTI – Restricted 80
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
completeness etc. National bodies vote on the document on every stage to 3474
insure quality and acceptance. 3475
Approved standards document are available through subscription or purchase 3476
3477
5. Ratification process (how the standard is being approved?) 3478
Every formal step in developing of the standard is done by national experts. 3479
The documents are casted and formally voted and commented on by national 3480
bodies. Comments and votes are being handled according to ISO/IEC 3481
Directives by the national body in charge of the secretariat. 3482
3483
Interoperability level: identify the interoperability levels considered by the 3484
SDO/Alliance/OSS initiative 3485
Syntactical interoperability 3486
Technical interoperability 3487
3488
Standards: will include functions for technical as well as Syntactical interoperability. 3489
It is also possibly that the standard will have opening for both semantic and 3490
pragmatic interoperability levels. 3491
3492
Supporting organizations (mainly for Alliances/OSS): main organizations that back the 3493
initiative: 3494
3495
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 3496
2, related to the market domain (consumer/industrial internet –horizontal axis) and the 3497
technical domain (connectivity, service&applications – vertical axis); 3498
Market domain: ISO/IEC JTC 1 standards document will benefit horizontal axis 3499
Technical domain: ISO/IEC JTC 1 standards document will benefit all IoT –3500
systems and integration on several interoperability levels 3501
3502
Application area: whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing 3503
on integrated/complete IoT solutions, i.e. horizontal industry, or whether it is focusing on 3504
a particular vertical industry (e.g., Smart City), when applicable, see Figure 2 in Section 2 3505
The ISO/IEC JTC 1 standards document will benefit horizontal industries 3506
3507
Scope: mapping to knowledge areas of concerns in IoT. 3508
The identified knowledge areas are (Note that an initiative can be mapped to more 3509
than one knowledge areas): 3510
Communication and Connectivity knowledge area: 3511
o Good knowledge in the Communication and Connectivity 3512
Infrastructure knowledge area: 3513
o Good knowledge in Infrastructure area 3514
3515
IPR Policy Available: 3516
http://www.iso.org/iso/home/standards_development/resources-for-technical-3517
work.htm 3518
https://connect.iso.org/display/ipr/Intellectual+Property 3519
3520
Specification Access: JTC1 standards are publicly available for everyone. They can be 3521
bought thru the National Standardization Bodies or thru ISO. 3522
AIOTI – Restricted 81
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
Members of a National Standardization Body who is mirroring the WG10 work 3523
will have full access to all working documents and drafts in the development 3524
process thru a web platform. Please note that liaisons to WG10 will have access to 3525
the same web platform as WG10 experts. 3526
Non members: cannot get access to draft standards or other working documents 3527
but can get access to all published standards. 3528
5.2.13 OIC (Open Interconnect Consortium) 3529
Description: 3530
The open interconnect consortium founded by leading technology companies with the 3531
goal of defining the connectivity requirements and ensuring interoperability of the 3532
billions of devices that will make up the emerging internet of things (IOT). 3533
3534
The Open Interconnect Consortium define and promote a single connectivity framework 3535
to enable communications and interoperability in support of the “Internet of Things” 3536
across multiple vertical markets, operating systems, platforms, modes of communication, 3537
transports and use cases and to encourage the development and distribution of products 3538
implementing such connectivity frameworks. 3539
3540
The above goal will be accomplished through the following activities and outputs: 3541
3542
Specifications. Development and publication of Specifications (as defined more 3543
fully in the Intellectual Property Rights Policy of the Corporation), which define 3544
and promote communication and interoperability requirements for the “Internet of 3545
Things.” 3546
Open Source Project. Cooperate with open source projects in the development of 3547
open source software in support of the Specifications. 3548
Test Tools: Technical resources, such as software in binary and/or source code 3549
form, for validating compliance with Specifications and open source projects. 3550
Testing Activities: “Plugfests” and other events and activities that provide 3551
opportunities for Members to test interoperability and validate compliance with 3552
Specifications and open source projects. 3553
Whitepapers: Technical and non-technical documents which discuss various 3554
technical and business considerations, insights, and consumer requirements for 3555
the “Internet of Things.” 3556
Ecosystem Development: Representing the Corporation and activities to attract 3557
industry membership and broad adoption. 3558
Marketing and Public Relations: Representing the Corporation, generating 3559
awareness of the Corporation, and providing liaison to other standards 3560
development organizations. 3561
Certification and Logo Program: Following publication of Specifications and 3562
open source projects, the Corporation will further develop a formal certification 3563
process, logo, trademark, and other marketing programs and collateral, the extent 3564
of which shall be determined by the Corporation, for promotion of Member 3565
products that comply with Specifications and open source projects. 3566
3567
The following sets forth the technical scope of the specifications: 3568
3569
Enabling devices, services and applications (“Products”) to discover, connect, 3570
communicate and interoperate through: 3571
A framework that includes: 3572
AIOTI – Restricted 82
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
Object models for devices, users, resources 3573
Discovery of and interaction between objects 3574
Associated security (authentication; encryption; privacy; access control) 3575
Device management (provisioning) 3576
Data management 3577
Mapping of the above onto multiple underlying technologies, but not the 3578
definition of those technologies (Bluetooth, Wi-Fi, IP, Zigbee, ZWave, etc…) 3579
Protocols, data formats and the mapping and adapting of both 3580
APIs 3581
Functions, input parameters, data structures, and services (including web services, 3582
web resources and software modules), to the extent that they are specifically 3583
described in detail 3584
3585
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); For each criterion 3586
please select one or more options. 3587
3588
1. Adoption (users base) 3589
Reference implementations 3590
2. Development Status 3591
Approved with planned revisions 3592
3. Compliance 3593
Formal certification process 3594
4. Openness 3595
Open by formal membership 3596
5. Ratification process (how the standard is being approved?) 3597
Closed process done by members only with no consultation from external parties 3598
3599
3600
Interoperability level: identify the interoperability levels considered by the 3601
SDO/Alliance/OSS initiative, see Appendix A for details: 3602
Organisational interoperability. Note work is ongoing to interoperate through the 3603
OneM2M platform as well as across the OIC ecosystem 3604
3605
Standards: standards and protocols proposed (SDO/Alliance) or supported 3606
(Alliance/OSS); Include details on whether an SDO/Alliance specified original protocols, 3607
or whether they are using and integrating standards and protocols developed by other 3608
SDOs 3609
3610
Combination of existing IETF and W3C standards with additional work 3611
3612
Supporting organizations (mainly for Alliances/OSS): main organizations that back the 3613
initiative 3614
Working with OneM2M 3615
3616
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 3617
2, related to the market domain (consumer/industrial internet –horizontal axis) and the 3618
technical domain (connectivity, service&applications – vertical axis); 3619
Multiple domains – initial release has a consumer focus with a mix of 3620
connectivity and services. 3621
3622
AIOTI – Restricted 83
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
Application area: 3623
whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 3624
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is 3625
focusing on a particular vertical industry (e.g., Smart City), when applicable, see 3626
Figure 2 in Section 2 3627
Different specifications cover different areas. The initial focus is on Smart 3628
Home 3629
3630
Scope: mapping to knowledge areas of concerns in IoT. 3631
The identified knowledge areas are (Note that an initiative can be mapped to more 3632
than one knowledge areas): 3633
Communication and Connectivity knowledge area: 3634
Integration/Interoperability knowledge area: 3635
Applications knowledge area: 3636
Infrastructure knowledge area: 3637
IoT Architecture knowledge area: 3638
Devices and sensor technology knowledge area: 3639
Security and Privacy knowledge area: 3640
3641
IPR Policy Available: mention if there is any IPR policy available (e.g., FRAND); if 3642
available include a reference to the description of this IPR policy 3643
FRAND – Free licensing 3644
3645
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-3646
members can get access to published and non-published (draft) specifications and/or 3647
software 3648
Specification open on OIC web site – free to access for all. 3649
3650
5.2.14 OneM2M 3651
Description: main objective and focus of initiative 3652
Following text from: http://www.onem2m.org/about-onem2m/why-onem2m 3653
The purpose and goal of oneM2M is to develop technical specifications which 3654
address the need for a common M2M Service Layer that can be readily embedded 3655
within various hardware and software, and relied upon to connect the myriad of 3656
devices in the field with M2M application servers worldwide. A critical objective 3657
of oneM2M is to attract and actively involve organizations from M2M-related 3658
business domains such as: telematics and intelligent transportation, healthcare, 3659
utilities, industrial automation, smart homes, etc. Initially, oneM2M shall prepare, 3660
approve and maintain the necessary set of Technical Specifications and Technical 3661
Reports for: 3662
Use cases and requirements for a common set of Service Layer 3663
capabilities; 3664
Service Layer aspects with high level and detailed service architecture, in 3665
light of an access independent view of end-to-end services; 3666
Protocols/APIs/standard objects based on this architecture (open interfaces 3667
& protocols); 3668
Security and privacy aspects (authentication, encryption, integrity 3669
verification); 3670
AIOTI – Restricted 84
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
Reachability and discovery of applications; 3671
Interoperability, including test and conformance specifications; 3672
Collection of data for charging records (to be used for billing and 3673
statistical purposes); 3674
Identification and naming of devices and applications; 3675
Information models and data management (including store and 3676
subscribe/notify functionality); 3677
Management aspects (including remote management of entities); and 3678
Common use cases, terminal/module aspects, including Service Layer 3679
interfaces/APIs between: 3680
Application and Service Layers; 3681
Service Layer and communication functions 3682
3683
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); For each criterion 3684
please select one or more options. 3685
1. Adoption (users base) 3686
Reference implementations 3687
Widely adopted in industry 3688
2. Development Status 3689
Approved with planned revisions 3690
3. Compliance 3691
Having compliance testing process (include test suites, method, etc. ) 3692
◦ oneM2M has developed a set of specifications for interoperability test, and 3693
the corresponding test event has been organized. 3694
◦ oneM2M is currently working on the compliance test specification 3695
development and held already an interop event that attracted participation 3696
of 30 companies 3697
Formal certification process 3698
◦ under investigation/discussion by oneM2M 3699
4. Openness 3700
Open to public 3701
5. Ratification process (how the standard is being approved?) 3702
Done by members and open for consultation from external parties 3703
3704
Interoperability level: identify the interoperability levels considered by the 3705
SDO/Alliance/OSS initiative, see Appendix A for details: 3706
Syntactical interoperability 3707
Technical interoperability 3708
Semantic interoperability 3709
3710
Standards: standards and protocols proposed (SDO/Alliance) or supported 3711
(Alliance/OSS); Include details on whether an SDO/Alliance specified original protocols, 3712
or whether they are using and integrating standards and protocols developed by other 3713
SDOs 3714
oneM2M R1 supports HTTP, CoAP and MQTT as the transport protocol bindings 3715
for native oneM2M interfaces over oneM2M Mca and Mcc reference points. 3716
oneM2M also adopts OMA DM (1.x/ 2.0), OMA LWM2M, BBF TR-069 as the 3717
alternative device management protocols in the case of reusing underlying 3718
network services over oneM2M Mcn reference point. 3719
AIOTI – Restricted 85
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
The latest work in oneM2M includes WebSocket protocol binding over Mca and 3720
Mcc, and specifies the use if W3C semantic web technologies (e.g. 3721
RDF/OWL/SPARQL) for IoT semantic interoperability: semantic annotation, 3722
semantic discovery, ontologies, etc. 3723
3724
Supporting organizations (mainly for Alliances/OSS): main organizations that back the 3725
initiative 3726
Partner Type 1: 3727
Alliance for Telecommunications Industry Solutions (ATIS) 3728
Association of Radio Industries and Businesses (ARIB) 3729
China Communications Standards Association (CCSA) 3730
European Telecommunications Standards Institute (ETSI) 3731
Telecommunications Industry Association (TIA) 3732
Telecommunications Standards Development Society (TSDSI) 3733
Telecommunications Technology Association (TTA) 3734
Telecommunications Technology Committee (TTC) 3735
Partner Type 2: 3736
Broadband Forum 3737
Continua 3738
GlobalPlatform 3739
Home Gateway Initiative (HGI) 3740
New generation M2M consortium 3741
Open Mobile Alliance (OMA) 3742
Associate Members: 3743
Ministry of Science, ICT and Future Planning (MSIP) 3744
National Institute of Standards and Technology (NIST) 3745
State Secretariat of Telecommunications and for the Information Society, 3746
Spain 3747
United States Department of Transportation 3748
There are also more than 200 member companies/institutes supporting this work. 3749
See the full member list at: http://www.onem2m.org/membership/current-3750
members 3751
3752
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 3753
2, related to the market domain (consumer/industrial internet –horizontal axis) and the 3754
technical domain (connectivity, service&applications – vertical axis); 3755
oneM2M is positioned at the horizontal service domain (layer), which provides 3756
common service functionalities for IoT applications across vertical market 3757
domains. 3758
As providing horizontal service layer technologies, oneM2M aims to cover a wide 3759
market range across both consumer and industrial domains. 3760
3761
Application area: 3762
whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 3763
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is 3764
focusing on a particular vertical industry (e.g., Smart City), when applicable, see 3765
Figure 2 in Section 2 3766
oneM2M is not chartered to focus on a particular vertical industry. It shall 3767
provide standardized common service layer technologies that are 3768
applicable to various industry domains including the cross domain 3769
interactions, i.e. horizontal industry. 3770
AIOTI – Restricted 86
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
However, it also investigates some selected vertical industries (e.g. home, 3771
industrial, and vehicle) in deep to ensure the provided standard/technology 3772
can fulfil the vertical requirements and interwork with the 3773
applications/network/devices in those industries. More industries may be 3774
investigated in the future. 3775
3776
Scope: mapping to knowledge areas of concerns in IoT. 3777
The identified knowledge areas are (Note that an initiative can be mapped to more 3778
than one knowledge areas): 3779
Integration/Interoperability knowledge area: 3780
Applications knowledge area: 3781
IoT Architecture knowledge area: 3782
Devices and sensor technology knowledge area: 3783
Security and Privacy knowledge area: 3784
3785
IPR Policy Available: mention if there is any IPR policy available (e.g., FRAND); if 3786
available include a reference to the description of this IPR policy 3787
Reference: 3788
http://www.onem2m.org/images/files/oneM2M_Partnership_Agreement.pdf 3789
3790 3791
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-3792
members can get access to published and non-published (draft) specifications and/or 3793
software 3794
oneM2M published documents available at: 3795
http://www.onem2m.org/technical/published-documents 3796
oneM2M latest drafts available at: http://www.onem2m.org/technical/latest-drafts 3797
3798
5.2.15 OSGi Alliance 3799
Description: main objective and focus of initiative 3800
o not for profit SDO. The OSGi Alliance is a worldwide consortium advancing a 3801
proven and mature process to create open specifications. These specifications 3802
enable dynamic end-to-end connectivity and facilitate the componentization of 3803
software and applications, thus increasing development productivity, reducing 3804
time to market and substantially decreasing the long term maintainability costs of 3805
the resulting modular solution. The technology also provides flexible remote 3806
management and interoperability for applications and services over a broad 3807
variety of devices. Member company industries include leading service and 3808
content providers, infrastructure/network operators, utilities, enterprise software 3809
vendors, software developers, gateway suppliers, consumer electronics/device 3810
suppliers (wired and wireless) and research institutions. 3811
Features: high level functionalities covered by the initiative 3812
AIOTI – Restricted 87
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
o OSGi inherently responds to many requirements of the IoT. Its most important 3813
features can be listed as: 3814
A Modular execution environment enabling functional reuse of components 3815
across diverse platforms 3816
A flexible Capabilities / Requirements model that enables environment-aware 3817
deployment and dependency management. 3818
A dynamic environment allowing system components to be updated and/or 3819
reconfigured without restarting them 3820
Lifecycle aware components that are able to respond to changes in their 3821
environment, for example the addition/activation of a hardware device 3822
Support for dynamic deployment of native libraries based on the discovered 3823
system capabilities. 3824
A defined security model for determining whether software modules are 3825
trusted and the actions they are permitted to perform 3826
Common API’s for device connectivity using various underlying 3827
communication protocols 3828
A standardised common remote management interface using a variety of 3829
protocols including JMX and HTTP/REST 3830
Programming models for distributed environments using synchronous or 3831
asynchronous invocations. Suitable for use in edge or cloud environments. 3832
3833
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2) 3834
Adoption: Widely adopted in industry. Enterprise (most application servers, cloud 3835
backend software; cloud portal services); smart home: a broad variety of smart home 3836
solutions including DT QIVICON, devolo, AT&T Digital Life, Miele@Home etc.; 3837
telematics: various telematics solutions, including Groeneveld telematics solution for 3838
lorries, and MMLab telematics solutions for waste collection and cleaning services; 3839
adoption in AAL mainly in research projects (UniversAAL, sensiNact, etc.). 3840
Development status: Release 6 Approved with planned revisions 3841
Compliance: Formal certification process, reference implementations and compliance 3842
tests 3843
Openness: Open to public. Publicly available specifications with reference 3844
implementations and compliance tests. Various open source and commercial 3845
implementations exist and are adopted by the industry 3846
Ratification process (how the standard is being approved?): Done by members and 3847
open for consultation from external parties 3848
3849
Interoperability level: identify the interoperability levels considered by the 3850
SDO/Alliance/OSS initiative, see Appendix A for details: 3851
• Syntactical interoperability: 3852
Application modules deployed as Java code packaged in JAR files with 3853
additional metadata 3854
Deployment of native binaries using standard API. 3855
Interaction with external devices through a unified abstraction layer 3856
3857
• Technical interoperability 3858
Management via HTTP/REST 3859
Application modules deployed as Java code packaged in JAR files with 3860
additional metadata 3861
AIOTI – Restricted 88
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
Runtime interoperability with any Java Virtual Machine language that has 3862
Java bindings (e.g. Java, Scala, EcmaScript), and native code via JNI. 3863
• Semantic interoperability 3864
Possibility of expressing relevant semantics via OSGi’s Requirements / 3865
Capabilities model. 3866
3867
Standards: standards and protocols proposed (SDO/Alliance) or supported 3868
(Alliance/OSS); Include details on whether an SDO/Alliance specified original protocols, 3869
or whether they are using and integrating standards and protocols developed by other 3870
SDOs 3871
The OSGi specifications provide a standardised service platform for interacting 3872
with services (both local and remote) using a variety of defined communication 3873
and messaging protocols, including UPnP, TR069, enOcean, OMA DM, 3874
HTTP/REST, JSON-RPC and many others built by the community 3875
3876
Supporting organizations (mainly for Alliances/OSS): main organizations that back the 3877
initiative 3878
The Strategic members of the OSGi Alliance include: Adobe, Deutsche Telekom, 3879
IBM, Liferay, NTT, Oracle, Paremus, ProSyst Software, Salesforce.com and 3880
Software AG. Numerous other companies are active contributing members , such 3881
as Orange, Telecom Italia, Sagemcom, Schneider Electric, Hitachi, NEC and 3882
Eclipse Foundation 3883
OSGi Alliance liaises with various organizations. A collaboration between HGI, 3884
BBF, UPnP Forum and OSGi Alliance resulted in end-to-end service 3885
specifications for CPEs; Open Source communities such as Eclipse Foundation 3886
and Apache Foundation offer various reference implementations for OSGi 3887
specifications; EnOcean collaborates with the OSGi Alliance; other liaisons in 3888
IoT not be publicly announced yet, but very soon. 3889
3890
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 3891
2, related to the market domain (consumer/industrial internet –horizontal axis) and the 3892
technical domain (connectivity, service&applications – vertical axis); 3893
o OSGi is being adopted in B2B and B2C product solutions, specifications are 3894
available for Smart Home, Enterprise, automotive, and mobile environments. An 3895
IoT Working Group has recently been established. 3896
3897
Application area: 3898
o whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 3899
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is 3900
focusing on a particular vertical industry (e.g., Smart City), when applicable, see 3901
Figure 2 in Section 2 3902
OSGi Alliance provides a horizontal platform with API’s and device 3903
abstraction for specific vertical markets; it also provides specifications for 3904
enterprise solutions (app servers; cloud product solutions) and a 3905
framework for modular web application development 3906
3907
Scope: mapping to knowledge areas of concerns in IoT. 3908
o The identified knowledge areas are (Note that an initiative can be mapped to more 3909
than one knowledge areas): 3910
Communication and Connectivity knowledge area: 3911
Gateway based architecture, interconnection of devices and the cloud. 3912
AIOTI – Restricted 89
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
3913
Integration/Interoperability knowledge area: 3914
OSGi Alliance provides a device abstraction layer and various APIs for 3915
providing common access to external resources (both physical hardware 3916
and external services) 3917
The OSGi Framework provides a Java execution environment capable 3918
of supporting existing Java applications on small embedded systems, 3919
or large server hardware. 3920
3921
Applications knowledge area: 3922
OSGi Alliance provides a dynamic lifecycle management layer and 3923
standardised API that allows users to remotely install, manage, configure 3924
and update software components 3925
The OSGi Alliance provides enRoute, a framework for modular 3926
development of web applications using OSGi best practices. 3927
Numerous tools for dependency management and resource access exist 3928
Configuration is able to be pushed to OSGi modules via a common 3929
interface, independent of how the configuration is stored. 3930
3931
Infrastructure knowledge area: 3932
OSGi Alliance provides specifications for large-scale enterprise 3933
deployments, embedded systems, and edge devices 3934
3935
Devices and sensor technology knowledge area: 3936
The OSGi specifications provide dynamic lifecycle management for 3937
modules and services, meaning that devices sensors can be dynamically 3938
added, removed, discovered, or updated within a running system. 3939
Dynamic configuration management is provided for application and 3940
infrastructure modules allowing them to be updated without restarting the 3941
system. 3942
A wide variety of operating platforms are supported. The core requirement 3943
is for a Java Virtual Machine implementation. 3944
3945
Security and Privacy knowledge area: 3946
The OSGi specifications include native support for trusted modules, and 3947
permission-based access to resources and services. 3948
Permissions can be dynamically changed at runtime based on 3949
configuration. 3950
3951
IPR Policy Available: mention if there is any IPR policy available (e.g., FRAND); if 3952
available include a reference to the description of this IPR policy 3953
OSGi specifications are royalty free 3954
3955
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-3956
members can get access to published and non-published (draft) specifications and/or 3957
software 3958
Publicly available specifications with reference implementations and 3959
compliance tests 3960
AIOTI – Restricted 90
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
Various open source and commercial implementations exist and are 3961
adopted by the industry 3962
3963
5.2.16 Weightless 3964
Description: 3965
A standard for wide area wireless IoT connectivity enabling low-power devices. 3966
Covers layers 1-3 of the OSI model. 3967
3968
Readiness: 3969
1. Adoption (users base) 3970
Reference implementations 3971
2. Development Status 3972
Approved with planned revisions 3973
3. Compliance 3974
Formal certification process 3975
3. Openness 3976
Open by formal membership 3977
5. Ratification process (how the standard is being approved?) 3978
Closed process done by members only with no consultation from external parties 3979
3980
Interoperability level: 3981
Technical interoperability 3982
3983
Standards: Original standard developed by Weightless 3984
3985
Supporting organizations : N/A 3986
3987
Domain: Already correctly positioned in this figure. 3988
3989
Application area: Horizontal connectivity layer. 3990
3991
Scope: mapping to knowledge areas of concerns in IoT. 3992
Communication and Connectivity knowledge area: 3993
3994
IPR Policy Available: 3995
FRAND with options for zero-royalty on the terminal side, all members required 3996
to agree. 3997
3998
Specification Access: 3999
Specification available only to members. 4000
4001
5.2.17 WWRF (Wireless World Research Forum) 4002
Description: main objective and focus of initiative 4003
WWRF’s goal is to encourage global research that will achieve unbounded 4004
communications to address key societal challenges for the future. The term 4005
“Wireless World” is used in a broad sense to address the support of innovation 4006
and business, social inclusion and infrastructural challenges. This will be 4007
achieved by creating a range of new technological capabilities from wide-area 4008
AIOTI – Restricted 91
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION networks to short-range communications, machine-to-machine communications, 4009
sensor networks, wireless broadband access technologies and optical networking, 4010
along with increasing intelligence and virtualization in networks. This will 4011
support a dependable future Internet of people, knowledge and things and the 4012
development of a service universe. 4013
Features: high level functionalities covered by the initiative 4014
User needs and requirements 4015
Services, devices and service architectures 4016
Communication architectures and technologies 4017
Radio communication technologies 4018
4019
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); For each criterion 4020
please select one or more options. 4021
1. Adoption (users base) 4022
No implementations 4023
2. Development Status 4024
Under development 4025
4026
3. Compliance 4027
Not managed 4028
4029
4. Openness 4030
Open by formal membership 4031
Open to public (contributions and meeting attendance open to non-members) 4032
5. Ratification process (how the standard is being approved?) 4033
Closed process done by members only with no consultation from external 4034
parties (WWRF does not produce standards, but white papers and other 4035
publications approved by Steering Board) 4036
4037
Interoperability level: identify the interoperability levels considered by the 4038
SDO/Alliance/OSS initiative, see Appendix A for details: 4039
Standards are not developed by WWRF, so no interoperability level 4040
applies 4041
Standards: standards and protocols proposed (SDO/Alliance) or supported 4042
(Alliance/OSS); Include details on whether an SDO/Alliance specified original protocols, 4043
or whether they are using and integrating standards and protocols developed by other 4044
SDOs 4045
WWRF does not produce standards or protocols, but produces white papers and 4046
technology overviews that provide information to SDO partners such as ITU-R 4047
and ETSI 4048
4049
Supporting organizations (mainly for Alliances/OSS): main organizations that back the 4050
initiative 4051
Nokia, Huawei and China Mobile are sponsors, other members include: 4052
Qualcomm, Fujitsu, Bell Canada, Sagem, HP, NEC, Ericsson, Intel, LG, 4053
DoCoMo 4054
4055
AIOTI – Restricted 92
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 4056
2, related to the market domain (consumer/industrial internet –horizontal axis) and the 4057
technical domain (connectivity, service&applications – vertical axis); 4058
WWRF covers all these areas, so a position close to the centre is appropriate 4059
4060
Application area: 4061
whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 4062
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is 4063
focusing on a particular vertical industry (e.g., Smart City), when applicable, see 4064
Figure 2 in Section 2 4065
Horizontal/Telecommunication 4066
4067
Scope: mapping to knowledge areas of concerns in IoT. 4068
The identified knowledge areas are (Note that an initiative can be mapped to more 4069
than one knowledge areas): 4070
Communication and Connectivity knowledge area: 4071
Applications knowledge area: 4072
Infrastructure knowledge area: 4073
4074
IPR Policy Available: mention if there is any IPR policy available (e.g., FRAND); if 4075
available include a reference to the description of this IPR policy 4076
WWRF IPR Policy is included in the Articles of Association 4077
(http://www.wwrf.ch/files/wwrf/content/files/Membership/AoA_WWRF_revision4078
_2015_revision%20F1.pdf). All IPR generated by members remains with 4079
members, WWRF does not seek to own IPR other than copyright of publications 4080
and registration of trademarks. 4081
4082
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-4083
members can get access to published and non-published (draft) specifications and/or 4084
software 4085
Published WWRF white papers and other documents are available at 4086
http://www.wwrf.ch/publications.html 4087
Draft documents are available to members at http://www.wwrf.ch/member-4088
pages.html 4089
4090
5.3 IoT OSS Initiatives 4091
This section provides a brief description of the IoT OSS initiatives mentioned in Section 3. These brief 4092
descriptions are following and are based on the OSS template described in Section 5.1. 4093
4094
The official URLs of each of these initiatives can be found via Table 6. 4095
4096
AIOTI – Restricted 93
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
4097
Table 6: OSS initiatives and their Official URLs 4098
Initiative URL
AllJoyn https://allseenalliance.org/developers
Apache Spark https://spark.apache.org
Arduino: https://www.arduino.cc/
Contiki http://www.contiki-os.org/
EclipseIoT http://iot.eclipse.org/
Fi-ware www.fiware.org
IoTivity https://www.iotivity.org/
InfluxDB https://influxdb.com/
LinuxIoTDM https://wiki.opendaylight.org/view/IoTDM:Main
Mosquitto https://projects.eclipse.org/projects/technology.mosquitto
Node-RED http://nodered.org
OpenIoT https://github.com/OpenIotOrg/openiot
openHAB http://www.openhab.org/
OM2M http://www.eclipse.org/om2m/
ONOS http://onosproject.org/
OPFNV https://www.opnfv.org
OpenDaylight https://www.opendaylight.org/
OpenRemote http://www.openremote.com/
OpenStack https://www.openstack.org/
OpenWSN https://openwsn.atlassian.net/wiki/pages/viewpage.action?pageId=688187
OWASP (Open Web
Application Security
Project)
https://www.owasp.org/
Particle (formally Spark) http://spark.github.io/
Paho http://www.eclipse.org/paho/
Riot: Real time OS for
sensor networks
http://www.riot-os.org/
ROS (Robot Operating
System)
http://www.ros.org/
SensiNact http://open-platforms.eu/library/butler-smart-gateway
Sofia2 http://sofia2.com/home_en.html
ThingSpeak https://thingspeak.com/
UniverSaal http://www.universaal.org
4099
5.3.1 IoTivity 4100
Description: 4101
IoTivity is an Open Source Project sponsored by the Open Interconnect Consortium 4102
(OIC) and hosted by the Linux Foundation. The aim of this project is to develop an open 4103
source software framework to seamlessly connect the billions of devices in the emerging 4104
Internet of Things (IoT), across multiple operating systems and network protocols. 4105
4106
The founders of the OIC believe that both an industry standard specification and an open 4107
source implementation are necessary to drive true interoperability across these IoT 4108
devices. Moreover, the founders believe that true innovation can only happen when 4109
multiple parties come together, developing the source code in an open form, under open 4110
source governance rules. 4111
4112
AIOTI – Restricted 94
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
OIC have released 1.0 standard specification. At the same time, the IoTivity project will 4113
release a full open source implementation of that specification. However, you can get 4114
started today by downloading and exploring the current release, and start contributing. 4115
4116
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); For each criterion 4117
please select one or more options. 4118
4119
1. Community 4120
Formal consortium 4121
2. Commitment 4122
Dedicated committers from organizations 4123
3. Road map: 4124
Formal road map 4125
4. Alignment of ongoing Standards 4126
OSS output is aligned with SDO specifications - OIC 4127
5. Licensing 4128
Apache License version 2.0. 4129
6. Portability 4130
Multiple platforms are developed by project 4131
4132
Interoperability level: identify the interoperability levels considered by the 4133
SDO/Alliance/OSS initiative, see Appendix A for details: 4134
Organisational interoperability. Note work is ongoing to interoperate through the 4135
OneM2M platform as well as across the OIC ecosystem 4136
4137
Standards: standards and protocols proposed (SDO/Alliance) or supported 4138
(Alliance/OSS); Include details on whether an SDO/Alliance specified original protocols, 4139
or whether they are using and integrating standards and protocols developed by other 4140
SDOs 4141
OIC 4142
4143
Supporting organizations (mainly for Alliances/OSS): main organizations that back the 4144
initiative 4145
OIC 4146
4147
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 4148
2, related to the market domain (consumer/industrial internet –horizontal axis) and the 4149
technical domain (connectivity, service&applications – vertical axis); 4150
Multiple domains – initial release has a consumer focus with a mix of 4151
connectivity and services. 4152
4153
Application area: 4154
whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 4155
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is 4156
focusing on a particular vertical industry (e.g., Smart City), when applicable, see 4157
Figure 2 in Section 2 4158
Different specifications cover different areas. The initial focus is on Smart 4159
Home 4160
AIOTI – Restricted 95
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION 4161
Scope: mapping to knowledge areas of concerns in IoT. 4162
The identified knowledge areas are (Note that an initiative can be mapped to more 4163
than one knowledge areas): 4164
4165
Communication and Connectivity knowledge area: 4166
Integration/Interoperability knowledge area: 4167
Applications knowledge area: 4168
Infrastructure knowledge area: 4169
IoT Architecture knowledge area: 4170
Devices and sensor technology knowledge area: 4171
Security and Privacy knowledge area: 4172
4173
IPR Policy Available: mention if there is any IPR policy available (e.g., FRAND); if 4174
available include a reference to the description of this IPR policy 4175
FRAND – Free licensing 4176
4177
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-4178
members can get access to published and non-published (draft) specifications and/or 4179
software 4180
Code open on IoTivity web site – free to access for all - https://www.iotivity.org/ 4181
4182
5.3.2 OM2M (Open platform for M2M) 4183
Description: 4184
OM2M (Open platform for M2M) is an open source implementation of the SmartM2M 4185
standard and OneM2M standard diffused by Eclipse foundation. The project is initiated 4186
by LAAS-CNRS. It provides a horizontal M2M service platform for developing services 4187
independently of the underlying network, with the aim to facilitate the deployment of 4188
vertical applications and heterogeneous devices. 4189
4190
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2); For each criterion 4191
please select one or more options. 4192
1. Community 4193
Multiple organizations 4194
2. Commitment 4195
Multiple volunteer committers 4196
3. Road map: 4197
Frequent but non planned releases (small extension) 4198
Planned releases (synchronization with standard) 4199
4. Alignment of ongoing Standards 4200
SmartM2M (OM2M version 0.8) 4201
OneM2M (OM2M version 1.0) 4202
5. Licensing 4203
Eclipse Public License (ou EPL) 4204
6. Portability 4205
Platform independent 4206
4207
Interoperability level: 4208
AIOTI – Restricted 96
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
Syntactical interoperability 4209
4210
Standards: 4211
OneM2M - OneM2M consortium 4212
SmartM2M – ETSI 4213
4214
Supporting organizations (mainly for Alliances/OSS): 4215
LAAS-CNRS 4216
Eclipse foundation 4217
4218
Domain: 4219
OM2M creates horizontal service and allows to create applications. It concerns 4220
B2C and B2B. 4221
4222
Application area: 4223
OM2M creates a complete IoT solutions for horizontal industry. Several 4224
companies and research laboratories use OM2M in different domains: smart-4225
building, transportation, healthcare, energy and smart cities. 4226
4227
Scope: mapping to knowledge areas of concerns in IoT. 4228
Integration/Interoperability knowledge area: 4229
IoT Architecture knowledge area: 4230
Security and Privacy knowledge area: 4231
4232
IPR Policy Available: 4233
Eclipse Public License (ou EPL) 4234
4235
Specification Access: 4236
http://eclipse.org/om2m 4237
4238
5.3.3 sensiNact (aka BUTLER platform) 4239
Description: 4240
- sensiNact (aka BUTLER platform) is a horizontal IoT platform issued from the large 4241
scale FP7 project on IoT, BUTLER (~20 partners, 15M€ budget). The platform 4242
provides an abstraction layer underlying heterogeneous IoT ecosystem and provides 4243
common APIs and allow developers focusing on the business logic instead of 4244
underlying IoT technologies (communication, routing, device OS, etc.). Support for 4245
various IoT protocols and platforms is provided. 4246
4247
Features: high level functionalities covered by the initiative 4248
Generic APIs providing homogeneous access to underlying IoT devices and 4249
platforms; not only sensing but also actuating. 4250
Support for various southbound IoT protocols and platforms (CoAP, Zigbee, 4251
enOcean, KNX, Xbee, Sigfox, NFC, BLE, MQTT, XMPP, FIWARE, etc.) 4252
Support for various northbound remote access protocols (HTTP REST, JSON-4253
RPC, OneM2M, OMA LWM2M, CDMI, NGSI etc.) 4254
Platform as a Service providing easy deployment and management of IoT 4255
application and services 4256
Complex Event Processing engine for fusion of events from various sensors 4257
AIOTI – Restricted 97
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
Tools and libraries for developers for rapid prototyping of IoT applications 4258
4259
Readiness: (for OSS, use Table 1, for SDO/Alliances, use Table 2) 4260
sensiNact is a relatively new born initiative which is around the level 1-2 of readiness in 4261
the table, that will rapidly reach to level 2 - 3 4262
Community: currently mostly one single organization (CEA) is the main contributor + 4263
contributions from ongoing EU project partners. 4264
Commitment: Formally appointed committers from CEA + multiple volunteer committers 4265
from ongoing EU projects 4266
Roadmap: Regular planned releases 4267
Alignment of ongoing Standards: Support for various IoT standards (see above), active 4268
participation to standardization (e.g., OSGi) 4269
Licensing: Apache Software License 2.0 4270
Portability: multiple platforms are developed by project 4271
4272
Interoperability level: identify the interoperability levels considered by the 4273
SDO/Alliance/OSS initiative, see Appendix A for details: 4274
Syntactical interoperability 4275
o Defines device/service/resource model serialized in JSON format 4276
Technical interoperability 4277
o Provides interoperability among various IoT protocols and platforms (CoAP, 4278
Zigbee, enOcean, KNX, Xbee, Sigfox, NFC, BLE, MQTT, XMPP, FIWARE, 4279
Semantic interoperability 4280
o Possibility of extending the resource model with semantics capabilities (e.g. 4281
JSON-LD). 4282
Organisational interoperability 4283
Standards: standards and protocols proposed (SDO/Alliance) or supported 4284
(Alliance/OSS); Include details on whether an SDO/Alliance specified original protocols, 4285
or whether they are using and integrating standards and protocols developed by other 4286
SDOs 4287
Supported standards: CoAP, Zigbee, enOcean, KNX, NFC, BLE, MQTT, XMPP, OMA 4288
NGSI, OMA LWM2M, OneM2M, CDMI 4289
Leveraging the OSGi standard 4290
4291
Supporting organizations (mainly for Alliances/OSS): main organizations that back the 4292
initiative 4293
CEA is the main organization + several industrial and academic partners providing their 4294
support. 4295
4296
Domain: position the initiative, with respect to the four quadrants, see Figure 1 in Section 4297
2, related to the market domain (consumer/industrial internet –horizontal axis) and the 4298
technical domain (connectivity, service&applications – vertical axis); 4299
o sensiNact is a platform for managing IoT services & applications. It is domain 4300
agnostic and can be applied to consumer or industrial business. 4301
4302
Application area: 4303
o whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 4304
integrated/complete IoT solutions, i.e. horizontal industry, or whether it is 4305
focusing on a particular vertical industry (e.g., Smart City), when applicable, see 4306
Figure 2 in Section 2 4307
AIOTI – Restricted 98
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
o sensiNact is focusing the horizontal industry, a plug&play application platform 4308
for various IoT vertical domains. Deployments in smart home, smart office, smart 4309
transportation, and smart city have already been done. 4310
Scope: mapping to knowledge areas of concerns in IoT. 4311
o The identified knowledge areas are (Note that an initiative can be mapped to more 4312
than one knowledge areas): 4313
Communication and Connectivity knowledge area: 4314
o covers mainly specification of communication protocol layers, e.g., 4315
PHY, MAC, NWK, Transport, Application layer, and their types, e.g., 4316
Wireless/Radio and Wireline; it could also include management 4317
associated with the connectivity area 4318
o sensiNact provides protocol bridges for various communication 4319
protocols (Zigbee, KNX, enocean, MQTT, XMPP, CoAP, etc.) 4320
Integration/Interoperability knowledge area: 4321
o covers mainly specification of common IoT features required to 4322
provide integration and interoperability 4323
o sensiNact’s main knowledge area is integration since it provides a 4324
platform integration various IoT devices and exposing their 4325
functionalities in terms of sensing and actuating services. It allows 4326
interoperability among those devices on top of which applications 4327
from vertical domains can be built. 4328
Applications knowledge area: 4329
o covers the support of the applications lifecycle including development 4330
tools/models, deployment and management; including Analytics, 4331
application supporting tools and application domain specific activities 4332
o sensiNact provides SDK and tool for IoT application development, 4333
deployment and run-time management 4334
Infrastructure knowledge area: 4335
o covers aspects such as SDN, cloud computing, Mobile Edge 4336
Computing (MEC), fog computing, and other infrastructure topics, 4337
leaving all topics related “only” to communications in the connectivity 4338
knowledge area; it could also include management associated with the 4339
at the infrastructure level 4340
IoT Architecture knowledge area: 4341
o covers integrated/complete IoT specification solutions, including 4342
architecture descriptions 4343
o sensiNact is based on the BUTLER architecture, which shares 4344
commonalities with the IoT-A architecture (device/service/resource 4345
model) 4346
Devices and sensor technology knowledge area: 4347
o covers mainly device/sensor lifecycles, including operating systems, 4348
platforms, configuration management, sensor/actuators virtualization 4349
etc. 4350
o sensiNact is agnostic to device and sensor technologies 4351
Security and Privacy knowledge area: 4352
AIOTI – Restricted 99
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
o covers security and privacy topics 4353
o Provides token based authentication and profile based authorization 4354
4355
IPR Policy Available: mention if there is any IPR policy available (e.g., FRAND); if 4356
available include a reference to the description of this IPR policy 4357
o Apache Software License 2.0 4358
4359
Specification Access: Describe whether and how SDO/Alliance/OSS members and non-4360
members can get access to published and non-published (draft) specifications and/or 4361
software 4362
o First public information at http://open-platforms.eu/library/butler-smart-gateway/. 4363
Github repository under construction. 4364
4365
4366
4367
AIOTI – Restricted 100
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
6. Appendix 2: Technology Trends for the Support of IoT 4368
This section provides a brief description of technology trends for the support of IoT. 4369
4370
6.1 Wireless Connectivity Trends for the Support of IoT 4371
Wireless communications are strongly regulated by National and International rules and directives. SDOs 4372
are allocating frequency bands with related radiated power and issuing standards on how technologies 4373
must comply to specific region's regulation. 4374
4375
There are several technologies used for connectivity for the support of IoT. Figure 6 shows the wireless 4376
connectivity trends, which is divided into four quadrants. The horizontal axis represents the device cost in 4377
terms of the supported bit rate and the vertical axis represents the wireless technology coverage range. 4378
Please note that by using meshed technologies and topologies, the WPAN (Wireless Local Access 4379
Network) and WLAN (Wireless Personal Area Network) technologies can also be enabled to support a 4380
wider coverage e.g., Neighbourhood Area deployments. In case a wider coverage is needed, the range 4381
limit of the radio technologies could be overcome by using multiple access points/base stations and/or 4382
gateways that are geographically distributed and connected to a common backbone. 4383
The depicted arrow in Figure 6 emphasizes that current developments in LTE standardization, e.g., 4384
Cellular IoT (CIoT), will enable the LTE technology to be used within low power consumption wireless 4385
devices. 4386
4387 Figure 6: Wireless Connectivity Trends 4388
7. References 4389
[ETSI-position] “ETSI White Paper No. 3: Achieving Technical Interoperability - the ETSI Approach”, 4390
ETSI White paper, to be retrieved via: 4391
http://www.etsi.org/images/files/ETSIWhitePapers/IOP%20whitepaper%20Edition%203%20final.pdf 4392
4393
[IERC-position] “Internet of Things, IoT Semantic Interoperability: Research Challenges, Best Practices, 4394
Recommendations and Next Steps”, IERC white paper, to be retrieved via: 4395
http://docbox.etsi.org/SmartM2M/Open/AIOTI/!!SemanticDev/20150724FirstTelcoSemanticDev/IERC_P4396
osition_Paper_IoT_Semantic_Interoperability_Final.pdf 4397
4398
AIOTI – Restricted 101
AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION
4399
Acknowledgements
The AIOTI would like to thank the European Commission services for their support in the planning and
preparation of this document. The recommendations and opinions expressed in this document do not necessarily
represent those of the European Commission. The views expressed herein do not commit the European
Commission in any way.
© European Communities, 2015. Reproduction authorised for non-commercial purposes provided the source is
acknowledge.
Authors
Name Company/Organisation Email address Georgios Karagiannis Huawei georgios.karagiannis@huawei.com
Howard Benn Samsung howard.benn@samsung.com
Werner Berns Texas Instruments Werner.Berns@ti.com
Angel Boveda Wireless Partners angel.boveda@wirelesspartners.es
Marco Carugi NEC marco.carugi@gmail.com
Pablo Chacin SenseFields SL pchacin@sensefields.com
John Davies BT john.nj.davies@bt.com
Thierry Demol CITC-EuraRFID tdemol@citc-eurarfid.com
Jean-Pierre Desbenoit Schneider Electric jean-pierre.desbenoit@schneider-
electric.com
Zeta Dooly Waterford Institute of
Technology
zdooly@tssg.org
Omar Elloumi Alcatel-Lucent omar.elloumi@alcatel-lucent.com
Patrick Guillemin ETSI patrick.guillemin@etsi.org
Levent Gurgen CEA levent.gurgen@cea.fr
Juergen Heiles Siemens juergen.heiles@siemens.com
Sharadha Kariyawasam HW Communications Ltd sharadha@HWCOMMS.COM
Jochen Kilian DSPG jochen.kilian@dspg.com
Guenter Kleindl ATOS guenter.kleindl@atos.net
Paul Murdock LANDIS+GYR Paul.Murdock@LANDISGYR.COM
Thomas Paral TE Industrial thomas.paral@te.com
Nigel Rix KTN: Knowledge Transfer
Network
nigel.rix@ktn-uk.org
Friedhelm Rodermund Vodafone rodermund@vodafone.de
Mohammad-Reza Tazari Fraunhofer IGD saied.tazari@igd.fraunhofer.de
Martin Serrano National University of Ireland
Galway
martin.serrano@insight-centre.org
Carlos Ralli Ucendo Telefonica carlos.ralliucendo@telefonica.com
Ovidiu Vermesan SINTEF Ovidiu.Vermesan@sintef.no
Alexander Vey IBM VEY@de.ibm.com
Patrick Wetterwald CISCO pwetterw@cisco.com
Reviewers:
Patrick Guillemin, WG3 Chair, ETSI, France
Jean-Pierre Desbenoit, WG3 alternate Chair, Schneider Electric, France