IoT LSP Standard Framework Concepts - Directory …...AIOTI – Restricted 4 AIOTI ALLIANCE FOR...

1

IoT LSP Standard Framework Concepts

Release 2.0 AIOTI WG03 – loT Standardisation

2015

AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION

AIOTI – Restricted 2


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



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



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



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



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



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



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



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



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


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


o It covers mainly specification of common IoT features required to provide 251

integration and interoperability 252


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


o It covers aspects related to the design, deployment, and management of 258






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


o It covers integrated/complete IoT specification solutions, including 270



o It covers mainly device/sensor lifecycles, including operating systems, 273

platforms, configuration management, sensor/actuators virtualization etc. 274


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



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



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



366


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



370


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

http://www.3gpp.org/Specification-Groups

http://www.3gpp.org/RAN

http://www.3gpp.org/SA

http://www.3gpp.org/rubrique34

http://www.3gpp.org/GERAN


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






3. Compliance 407



4. Openness 410


Open to public 412



415





420


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


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




3GPP provides network connectivity along the entire horizontal axis and mainly in 440

vertical axis part under the horizontal axis. 441

442




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




Communication and Connectivity knowledge area 455

Integration/Interoperability knowledge area 456

Infrastructure knowledge area 457

458


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


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

http://www.3gpp.org/Partners

http://www.3gpp.org/about-3gpp/legal-matters

http://www.3gpp.org/ftp/Information/Working_Procedures/3GPP_WP.htm#Article_55

http://www.3gpp.org/ftp/Inbox/2008_web_files/3gppagre.pdf

http://www.avnu.org/









3. Compliance 480


4. Openness 482




486







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




Automotive 505


Audio / video 507

508




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












527



FRAND (http://avnu.org/wp-content/uploads/2014/05/AVnu-Alliance-IPR-Policy.pdf) 530

531



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






578



https://www.broadband-forum.org/technical/technicalwip.php#WABUS

https://www.broadband-forum.org/technical/technicalwip.php#WABUS



581

3. Compliance 582



4. Openness 585


Open to public 587



590


initiative 592



595




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

https://www.broadband-forum.org/technical/trlist.php

https://www.broadband-forum.org/cwmp.php

https://www.broadband-forum.org/cwmptools.php




BUS is a BBF Work Area. 637

638




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



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





o covers mainly the Application layer 657


o Covers aspects related to the design, deployment, and management of 659




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



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

https://www.broadband-forum.org/technical/ipdeclarations.php



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




Depends on group and specification 709

3. Compliance 710


4. Openness 712

Open to public – most groups some only open to members 713

714



717

Interoperability level: identify the interoperability levels considered by the 718

SDO/Alliance/OSS initiative, see Appendix A for details: 719


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



integrated/complete IoT solutions, i.e. horizontal industry, or whether it is 738


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


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








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



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



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



842



845


Depends on specification, some published others under development 847

3. Compliance 848


4. Openness 850


852



855



Organisational interoperability. 858

859




SDOs 863


865


initiative 867

Not relevant 868

869





874




focusing on a particular vertical industry (e.g., Smart City), when applicable, see 878


Different specifications cover different areas. Smart City focus in some 880

specifications 881

882





AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION Communication and Connectivity knowledge area: 886







893





898



software 901


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







3. Compliance 968


4. Openness 970


972



975




979




SDOs 983


985




initiative 987

Not relevant 988

989





994







specifications 1001

1002





1007





1012



software 1015


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



1030


Reference implementations and first commercial products of Phase 1 (see 1032

standards) 1033





3. Compliance 1036

Formal certification process (managed by the ULE-Alliance) 1037

4. Openness 1038

Open to public 1039



1042



Complete technical interoperability from Physical layer to application layer 1045

1046




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


Home / building (Smart living) 1085



Smart cities 1086

Energy 1087

Healthcare (Smart living) 1088

Wearables 1089

Smart manufacturing/ industry automation 1090


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



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


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







3. Compliance 1215


4. Openness 1217


1219



1222




1226




SDOs 1230


1232


initiative 1234



Not relevant 1235

1236





1241







specifications 1248

1249











1260





1265



software 1268


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



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





3. Compliance 1303


4. Openness 1305

Open to public 1306

1307



1310




1314





1319


Not relevant 1321

1322





1327





Focus on access for all 1332

1333




Access for all – human interaction 1337

1338





FRAND – ETSI IPR policy - http://www.etsi.org/about/how-we-work/intellectual-1341

property-rights-iprs 1342

1343




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



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



1431





3. Compliance 1436


4. Openness 1438


1440



AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION Done by members and open for consultation from external parties 1442

1443




1447




SDOs 1451


1453


initiative 1455

ECC, CENELEC 1456

1457





1462







specifications 1469

1470









1479





1484



software 1487


1489

ETSI TC Smart M2M 1490



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


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



1517





3. Compliance 1522


4. Openness 1524


1526



1529




1533




SDOs 1537


1539


initiative 1541



OneM2M 1542

1543





1548







specifications 1555

1556




Different specifications cover different areas: 1560

1561








1569





1574



software 1577


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



• 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



1609




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



1622




1626




SDOs 1630

It will not specify standards. It might use standards and protocols developed by 1631

other SDOs. 1632

1633


initiative 1635

Not relevant 1636

1637




https://portal.etsi.org/tb.aspx?tbid=827&SubTB=827



It can cover multiple domains 1641

1642






It can cover multiple domains 1648

1649








1657





1662



software 1665


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



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



1724




Specification under development 1728

3. Compliance 1729


4. Openness 1731

Open to public 1732

1733



1736




1740






SDOs 1744


1746


initiative 1748

Not relevant 1749

1750





1755







specifications 1762

1763




1767


1769





1774



software 1777


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



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



1824





3. Compliance 1829


4. Openness 1831

Open to public 1832

1833



1836




1840






SDOs 1844


1846


initiative 1848

Not relevant 1849

1850





1855






Network infrastructure 1861

1862




1866


1868





1873



software 1876


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



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



1930





3. Compliance 1935


4. Openness 1937

Open to public 1938

1939





1942




1946




SDOs 1950


1952


initiative 1954

Not relevant 1955

1956





1961






Energy efficiency 1967

1968




1972


o Energy efficiency 1974

1975





1980



software 1983


5.2.5 GSMA (GSM Association) 1985

Description: main objective and focus of initiative 1986


http://www.gsma.com/aboutus/ 1988

http://www.gsma.com/connectedliving/ 1989

http://www.gsma.com/aboutus/


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







3. Compliance 2007

Not managed 2008

4. Openness 2009



Closed process done by members only with no consultation from external 2012

parties 2013




2017




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


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




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

http://www.mobileworldcongress.com/

http://www.mwcshanghai.com/

http://www.mobile360series.com/

http://www.gsma.com/membership/who-are-our-gsma-members/full-membership/

http://www.gsma.com/membership/who-are-our-gsma-members/associate-membership/

http://www.gsma.com/membership/who-are-our-gsma-members/rapporteur-membership/

http://www.gsma.com/membership/who-are-our-gsma-members








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








2057



Reference: http://www.gsma.com/newsroom/wp-content/uploads/2013/09/AA-2060

32-v4-0.pdf 2061

2062 2063



software 2066

GSMA published documents available at: 2067

http://www.gsma.com/newsroom/gsmadocuments/ 2068

2069

5.2.6 HyperCat 2070

Description: 2071

2072

http://www.gsma.com/newsroom/gsmadocuments/



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


Integrated/complete IoT solutions (i.e. horizontal) 2104

Scope: 2105




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

http://www.hypercat.io/consortium.html

http://creativecommons.org/licenses/by/3.0/

http://www.hypercat.io/standard.html



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





3. Compliance 2158

Not managed by IEC 2159

4. Openness 2160

Open to public 2161



2164






2170






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


initiative 2187

Energy, Smart Grid, Smart Cities 2188

2189




Industrial 2193






Smart Grid, Smart City 2199

2200










2210



ITU / ISO / IEC code of practice. 2213

FRAND 2214

2215



software 2218


2220



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



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





3. Compliance 2282

Not managed by IEC 2283

4. Openness 2284

Open to public 2285



2288







2295




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




initiative 2323

Manufacturing 2324


2326




Industrial 2330

2331






Smart manufacturing 2337

2338











2349




FRAND 2353

2354



software 2357


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



2368







3. Compliance 2373

Not managed 2374


4. Openness 2376




2380







2387




P2413 Standard for an Architectural Framework for the Internet of Things 2391

2392


Not relevant 2394




Market: consumer and industrial, 2398

Technology: closer to service & applications 2399





Horizontal 2404





2409



FRAND, royalty free 2412

2413




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

http://www.ietf.org/rfc/rfc3935.txt



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


RFC 7557 Approved 2465

3. Compliance 2466

Not IETF responsibility 2467



4. Openness 2468

Open to public 2469



2472






2478




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


6lo is an IETF WG. 2484

2485




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





6lo WG is focusing on horizontal industry 2497

2498


https://datatracker.ietf.org/doc/draft-ietf-6lo-6lobac/

https://datatracker.ietf.org/doc/draft-ietf-6lo-dect-ule/

https://datatracker.ietf.org/doc/draft-hong-6lo-ipv6-over-nfc/

https://datatracker.ietf.org/doc/draft-ietf-6lo-btle/

https://datatracker.ietf.org/doc/draft-mariager-6lowpan-v6over-dect-ule/

https://datatracker.ietf.org/doc/draft-schoenw-6lo-lowpan-mib/

https://datatracker.ietf.org/doc/draft-ietf-6man-6lobac/

https://datatracker.ietf.org/doc/draft-brandt-6man-lowpanz/

https://datatracker.ietf.org/doc/draft-bormann-6lo-ghc/



The 6lo WG can be mapped to the following knowledge areas: 2500




2504


The IETF Intellectual property rules are defined in RFC 3739, “Intellectual Property 2506

Rights in IETF technology” (updated by RFC 4879) 2507

2508


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


Reference implementations and interoperability plug test events done by ETSI 2605


RFC 7557 Approved 2607

3. Compliance 2608


4. Openness 2610

Open to public 2611



2614






2620




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

https://datatracker.ietf.org/doc/draft-ietf-6tisch-architecture/

https://datatracker.ietf.org/doc/draft-ietf-6tisch-terminology/

https://datatracker.ietf.org/doc/draft-ietf-6tisch-tsch/

https://datatracker.ietf.org/doc/draft-ietf-6tisch-coap/

https://datatracker.ietf.org/doc/draft-ietf-6tisch-6top-interface/

https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/



Date Milestone

Done WG to adopt 6TiSCH architecture

Done WG to adopt IEEE802.15.4e TSCH overview


initiative: 6TiSCH is an IETF WG. 2626

2627







2634






6TiSCH WG is focusing on horizontal industry 2640

2641


The 6TiSCH WG can be mapped to the following knowledge areas: 2643




2647


The IETF Intellectual property rules are defined in RFC 3739, “Intellectual 2649

Property Rights in IETF technology” (updated by RFC 4879) 2650

2651



software : 2654



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

http://datatracker.ietf.org/wg/ace/charter/


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




No implementations, yet 2684



3. Compliance 2687



4. Openness 2690

Open to public 2691




2695





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


ACE is an IETF WG. 2717

2718



domain (connectivity, service&applications – vertical axis): 2721




2725





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





o Application layer, which include management associated with the 2735

connectivity area 2736


o supports common IoT features, such as publish a value or event and discover 2738

resources. 2739


o covers security and privacy topics 2741

2742




2746


can get access to published and non-published (draft) specifications and/or software: 2748



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

http://datatracker.ietf.org/wg/core/charter/



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






3. Compliance 2793



4. Openness 2796

Open to public 2797




2801






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


CORE is an IETF WG. 2817

2818







2825





CORE WG is focusing on horizontal industry 2830

2831


The CORE WG can be mapped to the following knowledge areas: 2833

http://datatracker.ietf.org/wg/core/documents/







resources. 2839



2842




2846


can get access to published and non-published (draft) specifications and/or software : 2848



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





3. Compliance 2886


http://datatracker.ietf.org/wg/cose/charter/


AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION Formal certification process 2888

4. Openness 2889

Open to public 2890




2894





2899




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


COSE is an IETF WG. 2922

2923







2930



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







http://datatracker.ietf.org/wg/cose/documents/


AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION Integration/Interoperability knowledge area: 2942


resources. 2944



2947


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


Working Group not officially formed 3051


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

https://datatracker.ietf.org/doc/draft-finn-detnet-problem-statement/

https://datatracker.ietf.org/doc/draft-gunther-detnet-proaudio-req/

https://datatracker.ietf.org/doc/draft-korhonen-detnet-telreq/

https://datatracker.ietf.org/doc/draft-wetterwald-detnet-utilities-reqs/

https://datatracker.ietf.org/doc/draft-zha-detnet-use-case/

https://datatracker.ietf.org/doc/draft-dujovne-detnet-gap-analysis/



Deterministic Networks Gap Analysis

3. Compliance 3053


4. Openness 3055

Open to public 3056



3059






3065




SDOs 3069

3070


initiative: DetNet is an IETF WG. 3072

3073







3080






DetNet WG is focusing on horizontal industry 3086

3087


The DetNet WG can be mapped to the following knowledge areas: 3089





o supports common IoT features, such as publish a value or event and 3094

discover resources. 3095





3098




3102



software : 3105



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


Widely used in the industry 3141




draft-ietf-dice-profile-16

3. Compliance 3143


4. Openness 3145

Open to public 3146



3149






3155




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


initiative: Dice is an IETF WG. 3161

3162







3169






Dice WG is focusing on horizontal industry 3175

3176


The Dice WG can be mapped to the following knowledge areas: 3178

https://datatracker.ietf.org/doc/draft-ietf-dice-profile/










3187




3191



software : 3194



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





https://github.com/t2trg/2015-ietf92



3. Compliance 3227



4. Openness 3230

Open to public 3231




3235






3241




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


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







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













o plans to cover integrated/complete IoT specification solutions, 3276

including architecture descriptions. However, this is not yet agreed. 3277



3280


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



software 3302



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

https://irtf.org/ipr

http://www.ietf.org/ipr/file-disclosure

http://www.ietf.org/ipr/file-disclosure



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




No implementations/Reference implementations/Widely adopted in industry 3352

(according to the particular specification) 3353


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



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



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






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


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




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





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



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




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


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

http://www.itu.int/en/ITU-T/ipr/Pages/default.aspx



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


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


SDO/Alliance/OSS initiative 3485



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


initiative: 3494

3495




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





o Good knowledge in the Communication and Connectivity 3512


o Good knowledge in Infrastructure area 3514

3515


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

http://www.iso.org/iso/home/standards_development/resources-for-technical-work.htm

http://www.iso.org/iso/home/standards_development/resources-for-technical-work.htm

https://connect.iso.org/display/ipr/Intellectual+Property



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



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



3588





3. Compliance 3593


4. Openness 3595




3599

3600



Organisational interoperability. Note work is ongoing to interoperate through the 3603

OneM2M platform as well as across the OIC ecosystem 3604

3605




SDOs 3609

3610

Combination of existing IETF and W3C standards with additional work 3611

3612


initiative 3614

Working with OneM2M 3615

3616




Multiple domains – initial release has a consumer focus with a mix of 3620

connectivity and services. 3621

3622








Different specifications cover different areas. The initial focus is on Smart 3628

Home 3629

3630











3641



FRAND – Free licensing 3644

3645



software 3648

Specification open on OIC web site – free to access for all. 3649

3650

5.2.14 OneM2M 3651


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



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








3. Compliance 3691


◦ 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


◦ under investigation/discussion by oneM2M 3699

4. Openness 3700

Open to public 3701



3704






3710




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



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


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




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






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

http://www.onem2m.org/membership/current-members

http://www.onem2m.org/membership/current-members



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









3785



Reference: 3788

http://www.onem2m.org/images/files/oneM2M_Partnership_Agreement.pdf 3789

3790 3791



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


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


http://www.onem2m.org/images/files/oneM2M_Partnership_Agreement.pdf

http://www.onem2m.org/technical/published-documents

http://www.onem2m.org/technical/latest-drafts



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



• 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



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




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


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




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


o whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 3899




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


o The identified knowledge areas are (Note that an initiative can be mapped to more 3909



Gateway based architecture, interconnection of devices and the cloud. 3912



3913


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


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


OSGi Alliance provides specifications for large-scale enterprise 3933

deployments, embedded systems, and edge devices 3934

3935


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


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



OSGi specifications are royalty free 3954

3955



software 3958

Publicly available specifications with reference implementations and 3959

compliance tests 3960



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





3. Compliance 3974


3. Openness 3976




3980

Interoperability level: 3981


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



3994


FRAND with options for zero-royalty on the terminal side, all members required 3996

to agree. 3997

3998


Specification available only to members. 4000

4001

5.2.17 WWRF (Wireless World Research Forum) 4002


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


User needs and requirements 4015

Services, devices and service architectures 4016

Communication architectures and technologies 4017

Radio communication technologies 4018

4019







4026

3. Compliance 4027

Not managed 4028

4029

4. Openness 4030


Open to public (contributions and meeting attendance open to non-members) 4032


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



Standards are not developed by WWRF, so no interoperability level 4040

applies 4041




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


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






WWRF covers all these areas, so a position close to the centre is appropriate 4059

4060






Horizontal/Telecommunication 4066

4067







4074



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



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

http://www.wwrf.ch/files/wwrf/content/files/Membership/AoA_WWRF_revision_2015_revision%20F1.pdf

http://www.wwrf.ch/files/wwrf/content/files/Membership/AoA_WWRF_revision_2015_revision%20F1.pdf

http://www.wwrf.ch/publications.html



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



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



4119

1. Community 4120

Formal consortium 4121

2. Commitment 4122

Dedicated committers from organizations 4123

3. Road map: 4124

Formal road map 4125


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



Organisational interoperability. Note work is ongoing to interoperate through the 4135

OneM2M platform as well as across the OIC ecosystem 4136

4137




SDOs 4141

OIC 4142

4143


initiative 4145

OIC 4146

4147




Multiple domains – initial release has a consumer focus with a mix of 4151

connectivity and services. 4152

4153






Different specifications cover different areas. The initial focus is on Smart 4159

Home 4160


AIOTI ALLIANCE FOR INTERNET OF THINGS INNOVATION 4161




4165








4173



FRAND – Free licensing 4176

4177



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



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


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

http://www.etsi.org/technologies-clusters/technologies/m2m

http://www.etsi.org/technologies-clusters/technologies/m2m

https://www.laas.fr/public/en




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


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





4232


Eclipse Public License (ou EPL) 4234

4235


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


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

http://eclipse.org/om2m



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




o Defines device/service/resource model serialized in JSON format 4276


o Provides interoperability among various IoT protocols and platforms (CoAP, 4278

Zigbee, enOcean, KNX, Xbee, Sigfox, NFC, BLE, MQTT, XMPP, FIWARE, 4279


o Possibility of extending the resource model with semantics capabilities (e.g. 4281

JSON-LD). 4282





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


initiative 4293

CEA is the main organization + several industrial and academic partners providing their 4294

support. 4295

4296




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


o whether the SDO/Alliance/OSS (or the WG/TC) initiative is focusing on 4304






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


o The identified knowledge areas are (Note that an initiative can be mapped to more 4312



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


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


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


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


o covers integrated/complete IoT specification solutions, including 4342


o sensiNact is based on the BUTLER architecture, which shares 4344

commonalities with the IoT-A architecture (device/service/resource 4345

model) 4346


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





o Provides token based authentication and profile based authorization 4354

4355



o Apache Software License 2.0 4358

4359



software 4362

o First public information at http://open-platforms.eu/library/butler-smart-gateway/. 4363

Github repository under construction. 4364

4365

4366

4367

http://open-platforms.eu/library/butler-smart-gateway/



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

http://www.etsi.org/images/files/ETSIWhitePapers/IOP%20whitepaper%20Edition%203%20final.pdf






http://docbox.etsi.org/SmartM2M/Open/AIOTI/!!SemanticDev/20150724FirstTelcoSemanticDev/IERC_Position_Paper_IoT_Semantic_Interoperability_Final.pdf

http://docbox.etsi.org/SmartM2M/Open/AIOTI/!!SemanticDev/20150724FirstTelcoSemanticDev/IERC_Position_Paper_IoT_Semantic_Interoperability_Final.pdf



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 [email protected]

Howard Benn Samsung [email protected]

Werner Berns Texas Instruments [email protected]

Angel Boveda Wireless Partners [email protected]

Marco Carugi NEC [email protected]

Pablo Chacin SenseFields SL [email protected]

John Davies BT [email protected]

Thierry Demol CITC-EuraRFID [email protected]

Jean-Pierre Desbenoit Schneider Electric jean-pierre.desbenoit@schneider-

electric.com

Zeta Dooly Waterford Institute of

Technology

[email protected]

Omar Elloumi Alcatel-Lucent [email protected]

Patrick Guillemin ETSI [email protected]

Levent Gurgen CEA [email protected]

Juergen Heiles Siemens [email protected]

Sharadha Kariyawasam HW Communications Ltd [email protected]

Jochen Kilian DSPG [email protected]

Guenter Kleindl ATOS [email protected]

Paul Murdock LANDIS+GYR [email protected]

Thomas Paral TE Industrial [email protected]

Nigel Rix KTN: Knowledge Transfer

Network

[email protected]

Friedhelm Rodermund Vodafone [email protected]

Mohammad-Reza Tazari Fraunhofer IGD [email protected]

Martin Serrano National University of Ireland

Galway

[email protected]

Carlos Ralli Ucendo Telefonica [email protected]

Ovidiu Vermesan SINTEF [email protected]

Alexander Vey IBM [email protected]

Patrick Wetterwald CISCO [email protected]

Reviewers:

Patrick Guillemin, WG3 Chair, ETSI, France

Jean-Pierre Desbenoit, WG3 alternate Chair, Schneider Electric, France

Date post:	10-Jun-2020
Category:	Documents
Upload:	others
View:	5 times
Download:	0 times