onem2m security and access control (rel.3) - etsi · onem2m security and access control (rel.3)...
TRANSCRIPT
© ETSI 2019
OneM2M security and Access Control (Rel.3)
Enrico ScarroneoneM2M Steering Committee ChairmanETSI TC SmartM2M chairman
ETSI Security Week20 June 2020, Sophia Antipolis, France, EU
© ETSI 2019 2
How big is the IOT value
𝑖=1
𝑛
𝑁𝑖2
𝑖=1
𝑛
𝑁𝑖( )2𝑛= Number of different indipendent sytems
N= Connected device in each system
Metcalfe Law (1993) Robert Metcalfe
demonstrated that the value in
connected system is proportional to
the square of the number of
interconnected devices of the system.
From indipendent systems to IoT:
sharing information and collaborating across systems
© ETSI 2019 3
40% of economic impact of IoT requiresinteroperability between IoT systems
Source: McKinsey
© ETSI 2019 4
An integrated solution is needed
Highly fragmented market with small vendor-specific or sector-specific solutions.Reinventing the wheel: Same services developed again and again-Limited communication and high integration costs
© ETSI 2019 5
Opportunities and problems
Diversity is the richness that allows evolution and innovation: combination of services is the biggest opportunity for the future
But fragmentation of solutions and technologies is the enemy that is delaying and blocking the developments
Simplify the environment, remove the unnecessary duplicated solutions (economy of scale), preserve the necessary/opportune solution specialization by interwoking
© ETSI 2019 6
The role of Standardization for IOT
Support the developers community accelerating the development of IoT
Transfer the competition from integration and platforms to services unlocking the market
Reduce the cost due to the silos approach and its management
Enable Inter-technology and inter-domain data sharing generating new services and new business opportunity
Reduce platform development and integration costs,
enlarge the market,
enable real competition on services
7© ETSI 2019
OneM2M
Service Layer
…and most importantly: is a Global Standard – not controlled by a single private company!
Application Layer
Network Layer
• oneM2M is distributed software/middleware layer, sitting between applications and underlying communication networking HW/SW,Integrated into devices, gateways & servers
• It enables distributed intelligence• It bridges communication technologies, e.g.: fixed, NB-IoT,
3GPP 4G, 5G, LoRa..• It provides functions that applications across different
industry segments commonly need• Interworks existing solutions (data models) • Manages data (communicate, store, share)• Allows to annotate data with semantic descriptions• It typically rides on top of IP protocol stack• It exposes common set of functions to applications via
developer friendly APIs
© ETSI 2019 8
Over 200 member organizations in oneM2M
oneM2M Partnership Project
www.oneM2M.org
founded1 July, 24th 2012
TP#1: Sep 24th-29th 2012
© ETSI 2019 9
UnderlyingNetwork
UnderlyingNetwork
AE
NSE
AE
NSE NSENSE
Application Service Node Middle Node Infrastructure Node
ApplicationLayer
NetworkLayer
AE
Application Entity Provides application logic for the end-to-end M2M solutions
Network Services Entity Provides services to the CSEs besides the pure data transport
Node Logical equivalent of a physical (or possibly virtualized, especially on the server side) device
oneM2M simplified Architecture
© ETSI 2019 10
UnderlyingNetwork
UnderlyingNetwork
CSE
AE
NSE
CSE
AE
NSE
CSE
AE
NSENSE
Application Service Node Middle Node Infrastructure Node
ApplicationLayer
ServiceLayer
NetworkLayer
Mca
Mcn
Mca Mca
McnMcnMcnMcc Mcc
Reference Point One or more interfaces - Mca, Mcn, Mcc and Mcc’ (between 2 service providers)
Common Services Entity Provides the set of "service functions" that are common to the M2M environments
Application Entity Provides application logic for the end-to-end M2M solutions
Network Services Entity Provides services to the CSEs besides the pure data transport
Node Logical equivalent of a physical (or possibly virtualized, especially on the server side) device
oneM2M simplified Architecture
CSE
Mcc’
Inf. Node
Multiple protocol bindings (HTTP, CoAP, MQTT, or WebSocket) over Mca, Mcc, Mcc’
© ETSI 2019 11
RegistrationGroup
ManagementSecurity
Discovery & Announcement
Data Management &
Repository
Application & Service
Management
Device Management
Subscription & Notification
Communication Management
Service Charging & Accounting
LocationNetwork Service
Exposure
Common Service Functions
Semantics Interworking
© ETSI 2019 12
12
Organization
SteeringCommittee
TechnicalPlenary
Finance
Industry Liaison
Marketing
Legal
Methods/Procedures
Work Programme
Coordination Group
Methods of Work
RDM TDESDS
WG1 – RDM Chair: Saïd Gharout, OrangeVice Chairs: Catalina Mladin, Convida WirelessTaeHyun Kim, SyncTechno IncBei Xu (Echo), Huawei (elected @TP39)
Secretariat Support: tbc
WG 2 SDS Chair:Dale Seed, Convida WirelessVice Chairs: SeungMyeong Jeong, KETIWei Zhou, Datang TelecomPeter Niblett, IBM (elected @TP39)
Secretariat Support: Karen Hughes (ETSI) & Victoria Mitchell (TIA)
WG3 – TDE Chairman: Andrew Min-gyu Han, Hansung UniversityVice Chairs: Mahdi Ben Alaya, SensinovSubhash Gajare, SpirentN.N.
Secretariat Support: Peter Kim (TTA) & Laurent Velez (ETSI)
Part
ne
rsM
emb
ers
/ Pa
rtn
ers
http://onem2m.org/about-onem2m/organisation-and-structure
Requirements and Domain Models
Working GroupsSystem Design and Security Testing and Developers Ecosystem
TP Chair:Roland Hechwartner, Deutsche Telekom (ETSI)Vice Chairs:Josef Blanz, Qualcomm (TIA) JaeSeung Song, KETI (TTA) Yongjing Zhang, Huawei Technologies (CCSA)
Secretariat Support: Karen Hughes, ETSI
SC Chair: Enrico Scarrone, Telecom Italia (ETSI)Vice Chairs: Rouzbeh Farhoumand, Huawei Technologies (ATIS)Nick Yamasaki, KDDI Corporation (TTC)Omar Elloumi, Nokia (ETSI)
Secretariat support: Victoria Mitchell (TIA)
New WG structure agreed at TP #38December 8, 2018
Approved ToR:TP-2018-0287R02-draft_ToR_for_new_WG1TP-2018-0288R03-Draft_ToR_for_new_WG2TP-2018-0289R01-draft_ToR_for_new_WG3(w.o. names of WGs)
© ETSI 2019 13
Many others!!!
Work flow
Public ServicesEnterprise HealthcareEnergy
TransportationIndustryResidential
REQUIREMENTSTS-0002
TECHNICAL SPECSTECHNICAL REPORTS
© ETSI 2019 14
oneM2M integrates the vertical silos!
Smart Emergency
ServicesV
ert
ica
l
Da
ta/C
on
tro
l
Flo
w
Apps
Ve
rtic
al
Da
ta/C
on
tro
l
Flo
w
Ve
rtic
al
Da
ta/C
on
tro
l
Flo
w
Ve
rtic
al
Da
ta/C
on
tro
l
Flo
w
Ve
rtic
al
Da
ta/C
on
tro
l
Flo
w
Ve
rtic
al
Da
ta/C
on
tro
l
Flo
w
Apps Apps
Smart Transportation
Services
Smart Infrastructure
Services
…
Horizontal
Data/Control
Flow
Service Layer
…
Apps
Horizontal
Data/Control
Flow
Horizontal
Data/Control
Flow
Horizontal
Data/Control
Flow
oneM2M breaks down the vertical silos!
Non-oneM2M
(e.g. LWM2M, OCF, ...)
Summary of Release 2/3 FeaturesIndustrial Domain Enablement
• Time series data management• Atomic Transactions• Action Triggering• Optimized Group Operations
oneM2MRel-2/3 FeaturesSemantics
• Semantic Description/Annotation• Semantic Querying• Semantic Mashups• oneM2M Base Ontology
Smart City & Automotive Enablement• Service Continuity• Cross resource subscriptions
Market Adoption • Developer Guides• oneM2M Conformance Test• Feature Catalogues• Product Profiles
Security• Dynamic Authorization• End to End Security• Enrollment & Authentication APIs • Distributed Authorization• Decentralized Authentication• Interoperable Privacy Profiles• Secure Environment Abstraction
oneM2M as generic interworking framework
• 3GPP SCEF• OMA LWM2M • DDS• OPC-UA• Modbus• AllJoyn/OCF• OSGi• W3C WoT
Management• M2M Application & Field Domain
Component Configuration
Home Domain Enablement• Home Appliance Information Models & SDT• Mapping to existing standards (OCF, ECHONET, GoTAPI...)
© ETSI 2019 16
oneM2M Releases.
16
2018 2020Rel-2 Submission
201920172016
Rel-3 Ratification Date
Rel-3 Stage 1 (Requirements)
Rel-3 Stage 2 (Architecture)
Rel-3 Stage 3 (Protocol)
Rel-3 Start Date
Rel-4 Stage 1 (Requirements)
Rel-4 Stage 2 (Architecture)
Rel-4 Stage 3 (Protocol)
Rel-3 Submission
Rel-4 Submission
Rel-4 Start Date
Rel-4 Ratification Date
© ETSI 2019 17
oneM2M IoT opensource & industry implementation
IotDM
Some Products & field trial implementations
Major Opensource implementations
Certification programs
CERTIFIED!!!!
OS-IoT
© ETSI 2018 18© ETSI 2018
Share information across the differences
3) Communication
Framework
2) Semantic Support IoT base ontology
1) Vertical ontologies
support
IoT Semantic
SAREF and its extensions
IoT Data sharing
Unspecific base
Ontology
Specific Abstraction
Models, grouped around
a core common ontology
OneM2M resources
Semantic annotation of data
SAREF
© ETSI 2018 19© ETSI 2018
SAREF and itsextensions
Semantic interoperability
SA
RE
F C
ore
En
erg
y
Bu
ind
ing
En
viro
nm
en
t
Sm
art
Cit
ies
Ind
ust
ry &
m
an
fact
uri
ng
Sm
art
A
gri
cult
ure
Au
tom
oti
ve
E-H
ea
lth
/
We
llA
gin
g
We
ara
ble
s
Sm
art
W
ate
rin
g
ETSI TS 103 264: SAREF and oneM2M Mapping
ETSI TS 103 410 (1-10 ): SAREF extensions
ETSI TS 103 267: Communication Framework
ETSI TS 103 268 (1-4 ): SAREF Test Suite
© ETSI 2018 20
How to contribute to SAREF
Ontologies are dynamic structures constantly evolving with the technologies and the
products, so direct contributions from stakeholders are needed to sustain SAREF evolution.
TC SmartM2M is working on the development of an open portal to gather direct contribution
to SAREF, a sort of “open source” project dealing with ontologies instead of source code.
The stakeholders’ data model inputs will be then reflected in the ETSI SAREF and oneM2M
specifications by TC SmartM2M.
Requirements and prototyping are under development in
TR 103 608 SAREF “Publication framework for its community of users” (STF 556)
TC Smart M2M
SAREF/oneM2M core and
Extensions
Open SAREF Portal
Stakeholder 1 inputStakeholder input
Stakeholder input
Stakeholder inputStakeholder
inputStakeholder
inputStakeholder
inputStakeholder n
input
© ETSI 2019 21
Security in oneM2M Release 2- Release 3
© ETSI 2019 22
Security in oneM2M Release 2 & 3
Main security functions supported:
• Identification and Authentication• Identification: checking if the identity of the request originator
provided for authentication is valid• Authentication: validating if the identity supplied in the identification
step is associated with a trustworthy credential• Security Association Establishment
• Establishment of a security context between communicating entitiesto provide confidentiality (encryption) and integrity
• Range of authentication options supported • Authorization („Access Control“)
• Authorizing services and data access to authenticated entities• Remote Provisioning
© ETSI 2019 23
Security in oneM2M Release 2 & 3
Additional security functions:
• Identity protection• Capability to use pseudonyms to protect anonymity of transactions
• Sensitive data handling• Capability to protect sensitive data (e.g. local credentials) and
functions (e.g. data encryption/decryption) in a Secure Environment (e.g. Smart Card or Virtual Smart Cart)
• Security administration (related to device management)• Creates and administers dedicated Secure Environments and post-
provisioning of master credentials
© ETSI 2019 24
oneM2M Secure Environment and security levels« Secure Environment » concept abstracts the security implementation
Expose common services to applications, depending on implementation
Provide common interface for remote security administration, if needed
oneM2M supported implementations distinguish 4 security levels
No additional securitydevices otherwise protected from attackers, i.e. on trusted networks
Software only security (obfuscation, White box crypto etc.)Always vulnerable to sufficiently motivated attacker
Acceptable when compromise is not critical
« Trusted Execution Environment » (TEE) relying on main CPU hardware featuresGood barrier against software based attacks
Sufficient for remotely accessible, but not physically exposed devices
Tamper resistant hardware embedded Secure Element (eSE)Required to protect secrets within devices physically exposed to attackers (SPA / DPA etc.)
E.g. to protect unattended devices against cloning
Security in oneM2M Release 2 & 3
© ETSI 2019 25
Enrolment services (RSPF / MEF)Credentials Provisioning/Security Configuration of the M2M System
Secure communications services (SAEF / MAF)Methods for Securing Information (PSK/PKI/Trusted Party)
Point-to-point and end-to-end solutions (TLS / DTLS)
Access Control & Authorization servicesRequester Authentication
Information access Authorization(ACL based)
Static and Dynamic solutions
Privacy Policy Management
Security in oneM2M Release 2&3
SecuritySolutions
TS-0003
Device Configuration TS-0022
MEF & MAF interfacesTS-0032
© ETSI 2019 26
Onboarding oneM2M field devices
Onboarding is the procedure of bringing M2M Field Devices into operation in an M2M network
Procedures must cope with large variety of field devices types and Service Provider‘s business models
oneM2M has specified an „M2M Enrolment Function“ (MEF) which enables stakeholders to setup their preferred onboarding and enrolment mechanisms in an interoperable way
IN-CSEFieldDevice
MEF
Onboarding Device(e.g. smartphone)
Web Portal
optional,not in scope ofoneM2M specifications
1)3)
2)
1) Field Device, provisioned with credentials, contacts MEF. MEF configures Field Device with parameters and credentials of an IN-CSE
2) Field device sends registration request to IN-CSE3) IN-CSE authenticates the Field Device
© ETSI 2019 27
M2M Enrolment Function (MEF)
M2M Enrolment Function allows 3 types of Remote Security Provisioning Frameworks (RSPF)
Symmetric key authenticated RSPF
Certificate authenticated RSPF
GBA-authenticated RSPF; in this case the MEF is the Bootstrapping Server Function (BSF) of 3GPP Generic Bootstrapping Architecture (GBA)
Node 2
SA
MAF
Node 1
MEF RSPF
MAF-based SAEF
SAEF
• MEF can trigger the Field Device to execute a variety of procedures, including
• Configuration of Field devices with registration parameters and authentication profiles applicable to the operational Security Frameworks (see next slide)
• Provisioning of symmetric key credentials
• Provisioning of certificates (certificate (re-)enrolment using EST and SCEP specified by IETF recommendations)
• MEF is operated by M2M Service Provider or trusted 3rd party (device manufacturer, underlying network operator)
© ETSI 2019 28
Message Security between adjacent Entities:The operational security framework
Uses (Datagram) Transport Layer Security Protocols, TLS/DTLS Version 1.2
Several Security Association Establishment Frameworks are supported:
1) Authentication and session key establishment using symmetric keys shared by devices
2) Authentication and session key establishment using Certificates provisioned to devices
3) Authentication facilitated by an M2M Authentication Function (MAF) hosted by M2M-SP or third-party
The MAF authenticates the end-points (PSK or certificates) and facilitates establishing a symmetric key
ADN MN IN
SA2SA1Legend:SA Security AssociationADN Application Dedicated NodeMN Middle NodeIN Infrastructure Node
ADN/ASN/MN
IN
SA
IN
SA
MAF
ADN/ASN/MN
(D)TLS
© ETSI 2019 29
Operational Security Frameworks
Tie together credential management, configuration parameters, establishing security session (by TLS/DTLS handshake) and protecting the messages or data
Security Association Establishment Framework (SAEF): Adjacent entities
End-to-End Security of Primitive (ESPrim): Originator ↔ Hosting CSE
End-to-End Security of Data (ESData): Data producer to data consumer
ADN-AE
SA2SA1
IN-AE
SA3
MN-CSE IN-CSE
ESPrim MN cannot see or alter messages
CRUDN CRUDN
Legend:SA Security AssociationADN Application Dedicated NodeMN Middle NodeIN Infrastructure Node
MN-CSE can see and alter message. What if it is not trusted?
© ETSI 2019 30
Operational Security Frameworks
Tie together credential management, configuration parameters, establishing security session (by TLS/DTLS handshake) and protecting the messages or data
Security Association Establishment Framework (SAEF): Adjacent entities
End-to-End Security of Primitive (ESPrim): Originator ↔ Hosting CSE
End-to-End Security of Data (ESData): Data producer to data consumer
ADN-AE
SA2SA1
IN-AE
SA3
MN-CSE IN-CSE
Protect using ESData
Protected using ESData.
IN-CSE cannot see or alter app data
IN-AE usesusing ESData to extract app
data
What if IN-CSE is not trusted with this
app data
Legend:SA Security AssociationADN Application Dedicated NodeMN Middle NodeIN Infrastructure Node
CRUDN CRUDN
© ETSI 2019 31
Data Access & Control Authorization(aka. "Access Control“)
• M2M authorization procedure controls access to resources by CSEs and AEs
• Access Control Procedure requires that the originator of a request has been identified and authenticated, and verified to be associated with an M2M Service Subscription
• Every M2M Resource is associated with one or more instances of an <AccessControlPolicy> resource
31
<resourceType>
accessControlPolicyID0..1
Common Attributes1
Attribute 11
Attribute 21
Childresource1
<accessControlPolicy>
selfPermissions
permissions1
1
0..n
<subscription>
attributes(s)
URI of an <accessControlPolicy>
resource
CRUDN Request arriving at resource
hosting CSE
permissions:determine who is allowed to perform which operationon the resource under certain context constraints (e.g. originator IP address, location, date/time)selfPermissions:determine who is allowed to perform which operationon this accessControlPolicyresource itself
permissions
selfPermissions
© ETSI 2019 32
Authorization using Access Control Lists
Access control rules define who can do what under which circumstances
© ETSI 2019 33
Dynamic Authorization
Dynamic Authorization: Originator or Hosting CSE requesting authorization of Originator – provided by a Dynamic Authorization System (DAS) Server
Direct Dynamic Authorisation: Hosting CSE submits request to DAS, Originator not communicating with DAS Server
Indirect Dynamic Authorisation: Originator submits request to DAS Server using info provided by Hosting CSE. Similar to Open Authentication (OAuth) mechanism
DAS has multiple options for authorizing: Issue/update access control rules, assign Role(s) to the Originator, issue JSON Web Tokens (JWT)
HostingCSE
Originator(AE or CSE)
1. Request
DASServer
4. Response (‘success’)
3. Request (with parameters from step 1)
3. Response(with Token or
dynamicACPInfo)
Direct Dynamic Authorisation
AE
© ETSI 2019 34
Privacy Policy Manager (PPM)
The PPM is a personal data management framework which converts the User’s privacy preferences into access control information in order to protect the User's Personally Identifiable Information (PII) from access by unauthorized parties.
Access control information consists of static and dynamic access control policies (ACP) and policies for issuing access Tokens
Uses a “Terms and Condition’s Mark-up language” to derive consensus between the User’s privacy preferences and the ASP’s privacy policies
CSE (hosting PII)
Privacy Policy Manager(operated by M2M SP or trusted 3rd party)
Application Service Provider (ASP)
User
1. User privacy preferences
2. ASP privacy policy
7. ASP’s AE requests PII
4. Customized privacy policy
3. Creates user-friendly customized ASP privacy policy for User
8. ACPs or dynamic authorization
5. Accept/decline
6. Creates access control policies (ACPs)
9. PII
KEY
When User and ASP Register w/ PPM
When User subscribes for ASP service
When ASP requests PII
M2M Device (source of PII)
AE
© ETSI 2019 35
Contact details
Thank you!
Enrico ScarroneETSI tc smartM2M Chairman,
oneM2M Steering Committee Chairman
Standards Coordination
Torino, Via G. R. Romoli 274
I-10148 Italia
Phone: +39 0112287084 Mobile: +39 3356121214
IOT:
It is not which protocol… or which platform… or which cloud…..that makes the IoT!
The key is to share the information among different systems and applications , and among different business sectors !
© ETSI 2019 36
36
Publicly Accessible Links
Developer Guides are now accessible via the public link:http://www.onem2m.org/developer-guides
© ETSI 2019 37
Web Site
http://www.oneM2M.org
Developer Guides
http://www.onem2m.org/developer-guides
Technical Questions
http://www.onem2m.org/technical/technical-questions
Published Specifications
http://www.onem2m.org/technical/published-documents
Documents developed in oneM2M
http://www.onem2m.org/technical/latest-drafts
37
Publicly Accessible Links
• Webinars
• http://www.onem2m.org/technical/webinars
• YouTube Channel• https://www.youtube.com/c/onem2morg
• Events• http://www.onem2m.org/news-events/events
TS 0001: Functional Architecture
TS 0002: Requirements
TS 0003: Security Solutions
TS 0004: Service Layer Core Protocol
TS 0005: Management Enablement (OMA)
TS 0006: Management Enablement (BBF)
TS 0007: Service Components
TS 0009: HTTP Protocol Binding
TS 0010: MQTT Protocol Binding
TS 0011: Common Terminology
TS 0012: oneM2M Base Ontology
TS 0014: LWM2M Interworking
TS 0015: Testing Framework
TS 0020: WebSocket Protocol Binding
TS 0021: oneM2M and AllJoyn Interworking
TS 0023: Home Appliances Information Model and Mapping
TS 0024: OIC Interworking
TR 0001: Use Cases Collection
TR 0007: Study of Abstraction and Semantic Enablements
TR 0008: Security
TR 0012: oneM2M End-to-End security and Group Authentication
TR 0016: Study of Authorization Architecture for Supporting Heterogeneous Access Control Policies
TR 0017: Home Domain Abstract Information Model
TR 0018: Industrial Domain Enablement
TR 0022: Continuation and Integration of HGI Smart Home Activities
TR 0024: 3GPP Release 13 Interworking
TS-0032 – MAF and MEF Interface Specification
TR-0025 Application developer guide
TR-0034 CoAP binding and long polling for temp. monit.
TR-0035 Device management use case
TR-0037 Smart farm example using MQTT binding
TR-0039 Developer guide-SDT-based implementation
TR-0045 Implementing semantics
Rel
ease
1
Rel
ease
2
Rel
ease
2A
oneM2M Releases and Specifications
For details see also[1] ADM-0008-Release 1 Control Document[2] ADM-0011-Release 2 Control Document[3] ADM-0012-Release 2A Control Document
oneM2M Release 3 Deliverables
TS 0001 - Functional Architecture, V 3.13.2
TS 0002 - Requirements, V 3.1.2
TS 0003 - Security Solutions, V 3.10.2
TS 0004 - Service Layer Core Protocol, V 3.11.0
TS 0005 – Management enablement (OMA), V 3.4.2
TS 0006 – Management enablement (BBF), V 3.6.2
TS 0008 – CoAP Protocol Binding, V 3.3.1
TS 0009 – HTTP Protocol Binding, V3.2.0
TS 0010 – MQTT Protocol Binding, V 3.0.2
TS 0011 – Common Terminology, V 3.0.2
TS-0012 – Base Ontology, V 3.7.3
TS-0014 – LWM2M Interworking, V 3.1.1
TS-0016 – Secure Environment Abstraction V 3.0.2
TS-0020 – WebSocket Protocol Binding, V 3.0.1
TS-0022 – Field Device Configuration-V 3.0.1
TS-0023 – Home Appliances Information Model and Mapping, V 3.7.3
TS-0024 – OCF Interworking, V 3.2.2
TS-0026 – 3GPP Interworking V3.0.0
TS-0030 – Ontology Based Interworking V 3.0.3
TS-0031 – Feature Catalogue V 3.0.0
TS-0032 – MAF and MEF Interface Specification V 3.0.1
TS-0033 – Interworking Framework V 3.0.0
TS-0034 – Semantics Support V 3.0.0
TS-0035 – OSGi Interworking V 3.0.0
TR-0001 Use Cases Collection, V 3.1.1
TR-0026 Vehicular Domain Enablement, V 3.0.1
TR-0033 Study on Enhanced Semantic Enablement V 3.0.0
Technical Specifications
TechnicalReports
ADM-0017 Release 3 Control Document
© ETSI 2019 40
Developer Guide Series
Deliverable Title Examples of
TR-0025 Application developer guideHTTP binding,
XML/JSON serialization
TR-0034Temperature monitoring example using CoAP
bindingCoAP binding,
<pollingChannel>
TR-0035 Developer guide of Device Management <mgmtObj>, OMA DM, LwM2M, BBF TR-069
TR-0037 Smart Farm Example using MQTT Binding MQTT binding
TR-0038Developer guide - Implementing security
exampleProvisioning, Security Association Establishment
TR-0039 Developer guide - SDT based implementation SDT for home appliances
TR-0045 Developer Guide: Implementing Semantics Semantic annotation and discovery
TR-0047 Developer Guide of 3GPP Interworking MBMS, Device Triggering