It's an introduction slides about Healthcare / Fitness / Wearable Application development based on OCF standards & IoTivity open source.

1. OCF & IoTivity for
Healthcare/Fitness/Wearable
Jonghong Jeon
ETRI, PEC
Email: hollobit@etri.re.kr
http://www.etri.re.kr

2. OCF & IOTIVITY
2

3. 3

4. OCF Basics
• The Open Interconnect Consortium (OCF) defines a
common communication framework that connects
and intelligently manages the flow of information
among devices to address the emerging needs of the
Internet of Things
– Regardless of form factor, operating system, vertical
market, manufacturer or service provider
– Based on industry standard technologies
• OCF certifies products for interoperability and
compliance with the OCF specifications
• OCF sponsors the IoTivity Project, an open source
reference implementation of the OCF framework.
• OCF promotes the goal of broad interoperability via
collaboration with other organisations and standards
4

5. OCF Goals
• Make it easy for developers to deal with the
complexity of IoT comms
– Provide a common data model that developers
can use to interface with all IoT devices and
data
• Deliver as much interoperability as possible
in the short term
• Provide a path towards future consolidation
• Supports the needs of multiple vertical
markets (since many use cases span multiple
vertical markets)
• Establish an architectural foundation that
can achieve the necessary scalability
5

6. OCF & IoTivity Structure
6
Board of Directors
Standards Work Group
Open Source Work Group
Planning / Marketing / Etc…
Specifications Certification
IoTivity Steering Group
Projects
Functions
Sponsored (funded) by OCF
Develops reference implementation
of the OCF specification
Coordination
Innovative coordination – Specs & Open Source ready simultaneously

7. Best of Both
7
• Necessary for some
vertical markets
• Simplest path to
international
standardisation
• Allows liaisons with
organisations that
operate under NDA
• Proven process to gain
broad agreement on
direction of new
technology
• Fastest way to enable
developers
• Can contain more
than just the
specification (optional
features, development
tools, etc…)
• Proven process to
deliver innovation
Standards Open Source

8. OCF & IoTivity Governance
• OCF is a non-profit entity governed by its own
bylaws
– Board of Directors has fiduciary responsibility
(financial, legal, etc…)
– Sets up Working Groups to accomplish OCF goals
• IoTivity.org is a project hosted by the Linux
Foundation
– Independent governance and infrastructure,
sponsored (funded) by OCF
– Charter to provide reference implementation of OCF
standard (but not limited to only a reference
implementation)
8

9. OCF Organisational Structure
9
Open Source
Work Group
Standards
Work Group
Board of Directors
Marketing Communications
Work Group
Compliance &
Conformance
Core
Security
Smart Home
Technology Planning
Work Group
Membership
Work Group
Industrial
New Items
PR
Branding
Liaisons
Discovery &
Connectivity
Primitive Services
Project Planning &
Requirements
Security
Health
Events
Ecosyste
m
Use Cases
oneM2M
UPnP
Work Group
AV
IoT Data Modelling
Tool
UPnP Certification
Certification
Work Group
Remote
Access
Digital
Media

10. IPR Policy - Royalty Free* Licenses
10
Apache v2.0
Incoming:
Companies license their patent claims
covering their code
Outgoing:
All users (unless they sue another user for
patent infringement via IoTivity code)
RAND-Z
(By default – RAND under some circumstances*)
Incoming:
All members license their claims to IP
essential to implementing the
specification
Outgoing:
Compliant portion of certified products

11. Code Related Patent License ­ Apache v2.0
11
+
+
+
+
License
License
License
License
CODE
CODE
CODE
CODE
Developer
or User
Patent license covers company’s code contributions

12. Spec-Related Patent License ­ RAND-Z
12
Member
Product
SPEC Certification
Program
Compliant
Portion
License
Patent license covers everything in specification

13. OCF IPR Scope
13

14. TECHNICAL ARCHITECTURE
(COMMUNICATIONS)
14

15. The challenge of IoT Communications
• Value will be delivered by apps & services, and…
• Apps & services need access to data & control
points to deliver that value, but…
• Developers find it difficult to access all the data
and control points
• Use cases are more complicated
• The system and therefore comms needs to
achieve massive scale
• The solution must work across form factors, OSs,
platforms, manufacturers, service providers and
vertical markets.
• The solution must also scale from constrained
devices to smart devices to the Cloud.
15

16. Scope of IoT
16
service #2
domain
service #1
domain
Local Control Remote Control Server to Server
Industrial
Smart
Home
Healthcare
SecurityDevice
management
Group
management
Protocol
Bridge/GW
Messaging StreamingDiscovery
ID &
Addressing
CRUDN
Common
Resource
Model
…
Wi-Fi BT/BLE Thread …
Vertical
Profiles
Baseline
Functionality
Connectivity
Controller
Controller
Cloud Servers Cloud Servers
Things
Controller App
Cloud Interface
Controller

17. Comms Framework - Simple IoT Layers Model
17
Transports Transports
Applications &
Services
Comms Protocols
Profiles, Data &
Resource Models
Data & Control Points
Comms Protocols
Profiles, Data &
Resource Models
What to talk
about and how to
describe it
(which words in
what order –
grammar &
spelling)
Language
(French, Chinese,
English)
Method of
Communication
(Letter, Phone, E-
Mail)

18. Example ­ Current Consumer Radio-
Based Standards
18
Applications &
Services
Data & Control Points
Comms Protocols
Transports
Profiles, Data &
Resource Models
Wi-Fi
ZigBee
Thread
Z-Wave
IP
802.15.4
802.15.4
IP
Bluetooth®LowEnergy
?
?
BLE
IP
?
IP
=
6LoWPAN
Extensible

19. Example ­ Comms Frameworks
(Consumer)
19
Wi-Fi
BLE
OCF Comms Framework
(Single Resource & Data
Model)
IP IP ThreadIP802.15.4
Bluetooth®LowEnergy
Applications &
Services
Data & Control Points
Z-Wave
ZigBee802.15.4

20. TECHNICAL ARCHITECTURE
(DEFINITION OF THING)
20

21. Definition of various Things
21
e.g., Light bulb
BinarySwitch
Dimming
Brightness
- true(on), false(off)
- dimmingSetting (int)
- step (int)
- range [0-100]
- brightness (int)
Resources
- properties
SetSwitch
SetDimmingLevel
SetBrightness
- Power(in)
- brightness (in)
- step(in), range(in)
Functions
- Input & Output Parameters
• By defining resources of things
and its properties
• By defining
functions/operations of things
- (no Verbs) + Objects
*Fixed set of verbs (CRUDN) from
transport layer will be used
- Resource model in RESTful
Architecture
(e.g., W3C, CSEP, etc.)
- (Verbs + Objects)
- RPC model

22. Support of Constrained Things
• Less overhead/ Less Traffic
– Minimize CPU Load, Memory impacts,
Traffic and Bandwidth
- Compact header
- Binary protocol
- Compressed encoding of payload
• Low Complexity
- Simple Resource Model
> Short URI (Late Binding w/ resource type
defined)
> Broad and Shallow Hierarchy
22
*RAM <10KB, Flash <100KB (RFC 7228)

23. TECHNICAL ARCHITECTURE
(STANDARD & INTEROPERABILITY)
23

24. Interoperability & Certification
24
Prerequisites:
Dependency Certification
(e.g. Connectivity)
Conforman
ce Test
Interopera
bility Test
Certificate
Issue
& Logo
Licensing
Device under Test
CERTIFIED
Mandatory
(in spec, cert &
committed in Open
Source Project)
Option
al
Open
Source
Featur
es
Tested
Option
al
Open
Source
Featur
es
Tested
Option
al
Spec
Featur
es
Option
al
Spec
Featur
es
SpecificationOpen Source
• Conformance test - Each device proves conformance to specifications
• Interoperability test - Each device proves interoperability with other devices
• Certification Scope

25. OCF Specification Structure
25
Infrastructure
• Core Framework
• Security
• Remote Access
• Certification Test Plans and Test Cases
Resource Model
• Resource Specification (Domain agnostic)
Per Vertical Domain
• Device Specification
• Domain Specific Resource Specification

26. OCF Conceptual Framework
26
Device
Profiles
Smarthome Enterprise Industrial Automotive Education Health
Transports
LE
Remote
Access Cloud
Core Framework
Security, Identity & Permissions
Discovery
Data
Transmission
Data
Management
Device
Management
Resource Model
Remote Access

27. OCF Specification 1.0
27
OIC 1.0 세부 표준명 표준 설명 (작업그룹)
1 Core Framework
OIC 프로파일이 동작될 수 있도록 하기 위한 핵심 구조,
인터페이스, 프로토콜과 서비스들을 정의 (SWG CFTG)
2 Resource Type
스마트홈 리소스들에 대한 기본 스키마와 이를 기반으로
확장된 다양한 리소스 집합들에 대해 정의 (smarthome TG)
3 Security
상이한 암호화 능력을 갖는 장비들 사이에서 장치 구동과
연결에 필요한 도구와 보안 자원 모델을 정의 (Security TG)
4 Smart Home Device
스마트홈 응용 분야에서 사용되는 OIC 호환 장치 규격을 정의
(smarthome TG)
5 Remote Access
XMPP와 같은 산업표준을 기반으로 원격 접속에 필요한 제반
사항들과 기능들을 정의 (SWG RATG)
http://openconnectivity.org/resources/specifications

28. TECHNICAL ARCHITECTURE
(CORE FRAMEWORK)
28

29. OIC Architecture
29
• OIC adopted RESTful Architecture
• Current OIC Architecture defines 2 logical roles that
devices can take
- OIC Server : A logical entity that exposes hosted resources
- OIC Client : A logical entity that accesses resources on an
OIC Server
OIC
Client
OIC
Client
OIC
Server
OIC
Server
Model 1
RR

30. Organization of an OIC Device
30
• OIC Device concept
Physical Device e.g. light bulb
OIC Device 2OIC Device 1
/oic/p
/oic/res/oic/res
/oic/d/oic/d
/oic/prs/oic/mnt
Resource URI:
/oic/p
Resource URI:
/oic/prt: oic.wk.prt: oic.wk.p
if: oic.if.rif: oic.if.r
n: homePlatformn: homePlatform
policy: bm:11policy: bm:11
pi: at1908pi: at1908
mnmn: Samsungmnmn: Samsung
Mandatory
Optional

31. Device example: light device (oic.d.light)
31
• Example overview
- Smart light device with i) binary switch & ii) brightness resource
• Device type: Light device (oic.d.light) [Defined by the domain]
• Associated resources
- Core resources: ① oic/res, ② oic/d
- Device specific resources: ③ Binary switch (oic.r.switch.binary),
- Other optional resources can be exposed, in this example ④
Brightness resource (oic.r.light.brightness)
Device
Title
Device
Type
Associated Resource Type M/O
Light oic.d.light
oic/res (oic.wk.core) M
oic/d (oic.d.light) M
Binary switch (oic.r.switch.binary) M
Brightness (oic.r.light.brightness) O
Example: Smart light device with 4
resources
oic/res
oic/d
Binary
switch
Brightness

32. OIC Spec Features ­ Core Framework Spec
32
① Discovery: Common method for device
discovery (IETF CoRE)
② Messaging: Constrained device support as
default (IETF CoAP) as well as protocol
translation via intermediaries
③ Common Resource Model: Real world entities
defined as data models (resources)
④ CRUDN: Simple Request/Response
mechanism with Create, Retrieve, Update,
Delete and Notify commands
⑤ Device Management: Network connection
settings and remote monitoring/reset/reboot
functions
⑥ ID & Addressing: OIC IDs and addressing for
OIC entities (Devices, Clients, Servers,
Resources)
⑦ Security: Basic security for network, access
control based on resources, key
management etcTransportNetworkingL2 Connectivity
Vertical
Profiles
Industrial
Internet
Smart Home …
OIC Core Framework
Security
Device
management
Group
management
Protocol
Bridge/GW
Messaging StreamingDiscovery
ID &
Addressing
CRUDN
Common
Resource
Model
① ②
③ ④ ⑤
⑥
⑦

33. Protocol Stack
33
UDPUDP TCPTCP
IPv6IPv6
Resource ModelResource Model
DTLSDTLS TLSTLS
L2 Connectivity (Wi-Fi)L2 Connectivity (Wi-Fi)
Encoding (CBOR)Encoding (CBOR)
CoAPCoAP
Encoding
JSON or XML/EXI can
be negotiated
IP Version
v6 (v4 supported for
legacy devices)
ApplicationApplication Alternatives
Project B OIC Stack

34. Encoding Schemes ­ JSON, XML/EXI, CBOR
34
• OIC resource is represented as sequence of bits by encoding
schemes when to transfer it over the network
• OIC supports several encoding schemes and it will be negotiated
and accepted by OIC Server when OIC Client requests
• OIC has mandated CBOR as the default encoding scheme
* JSON: JavaScript Object Notation, EXI: Efficient XML
Interchange, CBOR: Concise Binary Object Representation
JSON XML/EXI CBOR
Description - Lightweight, text-based,
language-independent
data interchange format
- Binary compression
standard for XML
- Concise binary object
representation based on
JSON data model
Standard IETF RFC 7159 W3C Efficient XML
Interchange Format 1.0
IETF RFC 7049
Content Type /application/json /application/exi /application/cbor
OIC M/O Optional Optional Mandatory

35. OCF HEALTHCARE
35

36. [참고] 국제표준화 연관도
36
OIC
Healthcare
(Wearable/Fitnes
s/Healthcare)
PHR
Healthcare
(Continua, ISO/IEC,
ISO/IEEE, ITU-T, PHA)
OIC IoT
Medical,
Wellness,
Personal,
Remote,
Smarthome
Industrial

37. Defining OIC Components (on top of CORE)
37
• OIC Servers
• Defined by device identifier: standardized name of the
device
• List of mandatory OIC resources per device
• Note that OIC Clients are implicitly specified as
“opposite” side of an OIC Server.
• Currently OIC does not impose interaction sequences.
• All Resources are allowed to talk to/from any OIC Client at any
point in time
• OIC Resource
• Defined by resource identifier: standardized name of the
resource
• List of mandatory properties per resource
• List of allowed actions (read/readwrite/..) per resource

38. Specifications
38
• Specifications are split in 2 documents:
• Device specification
• Resource specification
The Device specification uses the resources defined
in the resource specification

39. Device Specification
39
• Contains profiles of
• Core specification
• security specification
• Contains list of
healthcare/fitness/wearable
devices
• Each Healthcare device
definition contains:
• unique identifier (rt)
• a list of mandatory resources

40. Resource Specification
40
• List of reusable resources that are used in an Healthcare
Device
• Contains generic list of error codes
• Uses core definitions
• Each Healthcare resource definition contains:
• unique identifier (rt)
• Indication if the resource is an sensor or actuator
• List supported methods
• List per method the JSON schema for input and
output
• Resources are specified in RESTful API Modelling
Language (RAML)

41. 표준화 계획 ­ OCF Healthcare
41

42. OCF Healthcare Use Cases
42
• Selected key enabling use cases to scope activity
Use Case Priority
Fitness and Medical Data
Collection
1
Health Monitor & Notify 2
Smart watch notification and Data
Transmission
7
Wearable device control 8
Quantified Self(Self monitoring) UC3
PERS(personal emergency response
system)
UC3
Find My Thing UC3
Diabetes management UC3
1 Control proximal OIC Devices
On board new Devices
Control remotely with an OIC Client
2
3
CloudCloud
Gateway
1
2
3
Smart
Phone
OIC OIC
OIC
OIC OIC

43. OCF Healthcare Use Cases
• Next Phase 2 - Medical Healthcare
– 만성질환관리
– 건강증진
– 응급의료
– PHR(Personal Health Record)
– Mobile EMR (Electronic Medical Record)
– Mobile EMR (Electronic Medical Record)
– 원격의료
43

44. Healthcare Device Type (24)
44
Device Type Required Resource
Activity Tracker
Activity
steps
Airflow Sensor (Breathing) Breath
Blood Pressure Monitor bloodpressure
Body composition analyzer
bodyfat
bodyMassIndex
bodyMetrics
bodywater
slm
Continuous Glucose
Monitoring
CGM
Cycling computer
CyclingComputer
Distance
Cycling Power Meter
CyclingPower
Speed
Cycling Speed and Cadence CyclingSpeedCadence
Electromyography Sensor EMG
Galvanic Skin Response Sensor GSR
Glucose Meter bloodGlucoseSensor
Device Type Required Resource
Handheld GPS Devices Geolocation
Heart Rate Monitor heartrate
Height Scale bodyheight
Muscle Oxygen Monitor MuscleOxygenSaturation
Patient Position Sensor BodyPosition
Peak flow
fev1
ffm
pef
Pulse Oximeter oxygenSaturation
Respiration rate monitor respirationRate
Scale bodyweight
Sleep Monitor sleep
Smart Watch
Clock
Altimeter
Strength fitness equipment
bodysite
repetition
Thermometer bodyTemperature

45. Healthcare Resource Type (35)
45
Resource Types Use Case
Activity
steps
Breath
bloodpressure
Bodyfat
bodyMassIndex
bodyMetrics
Bodywater
Slm
CGM
CyclingComputer
Distance
CyclingPower
Speed
CyclingSpeedCadence
EMG
GSR
bloodGlucoseSensor
Resource Types Use Case
Geolocation
heartrate
bodyheight
MuscleOxygenSaturation
BodyPosition
fev1
ffm
pef
oxygenSaturation
respirationRate
bodyweight
sleep
Clock
Altimeter
bodysite
repetition
bodyTemperature

46. OCF HEALTHCARE
POC IMPLEMENTATION
46

47. OIC 표준 기반 PoC 구현
47
링크: https://www.youtube.com/watch?v=O8AWchL0vwg
OIC 헬스케어 PoC 구현 동영상 제작 및 배포
세계 최초로 OIC 헬스케어 리소스 및 디바이스 표준을 오픈소스 기반으로 구현

48. IoTivity PoC 구현결과물 시연
• 소프트웨어 구현 플랫폼
– IoTivity 1.0.1 적용
– Client: 안드로이드 단말의 앱으로 구현
– Server: 아두이노 응용으로 구현
• 하드웨어 플랫폼
– Client: 안드로이드 5.1.x 이상이 탑재된 단말
– Server: 아두이노 due + BLE shield + e-health sensor platform
48
Arduino due BLE shield E-health sensor platform

49. IoTivity PoC 구현결과물 시연
49

50. IoTivity PoC 구현결과물 시연
• 시연 시나리오
– 아두이노 보드에 장착된 e-health sensor board 에서
사람의 생체신호를 검지해서 IoTivity 플랫폼을 통해
안드로이드 단말에서 구동되고 있는 앱으로 전달받음
50

51. 시연 동영상
51

52. OIC 표준 + IoTivity 오픈소스의 장점
원천기술을 빠르게 확보
확장 개발/개작/배포/유통
빠른 개발/적용
도입비용과 TCO 절감
신기술이 반영되는 소스
글로벌 경쟁력 확보
사물인터넷 생태계와 연계
52

53. 2016년도 PoC 구현 계획
• 개선된 하드웨어 지원 (RP3)
• 보다 다양한 기기 지원 (BLE/ANT+)
• 보다 손쉬운 프로그래밍 (Node.js)
• Legacy BLE 연동 bridge
• 스마트홈/자동차/웨어러블 연동
시나리오 구현
53

54. 2016년도 확장 계획
• 국내 기업들과 협력한 상용화 연동 및 표준 확장
• 2단계 OIC 표준화
– 1단계 표준 제정 및 Wearable/Health/Fitness Device
추가 및 확장
• 표준특허 창출
54

55. OCF/IoTivity Timeline
55
‘17 Jan
CES ’17
Demo
‘16 May
‘15 November‘15 August
‘15
Jun
Healthcare TG
Launched
Draft of first Healthcare spec.
We are here.
Done!
Ver 0.3
‘16 Aug
Two Healthcare Specs.
‘16 Jan
Identify Healthcare resource and
devices in relation to ISO/IEEE
11073, Bluetooth GATT, ANT+
‘16 Feb
Define Healthcare-specific
and OCF-generic resources
and devices, and share with
SHTG for comments
Ver 0.5
‘16 April
Ver 0.5
Align with
other TGs
Ready for IPR
Review
Ver 0.7
Ver 1.0
Publish OCF Healthcare
specifications with OCF
Specification 2.0
OCF 2.0
standards
Healthcare 표준 기반 구현 1차 Healthcare 표준 기반 구현 2차
Hackathon Hackathon
Plugfest #6
Beaverton, OR
(Feb 22-26)
Plugfest #7
Krakow, Poland
(Apr 25-29)
Plugfest #8
Seoul, S. Korea
(Jul 11-15)
Plugfest #9
Fremont, CA
(Sep 26-30)
Plugfest #10
Taipei,
Taiwan
(Dec 5-9)
Ver 1.01
(12/18/2015)
Ver 1.1.0
(03/29/2016)
Ver 2.0.
(07/29/2016)
Ver 2.1.
(10/31/2016)
Ver 1.0
(10/28/2015)

56. FUTURE POTENTIAL
56

57. Health + ICT ??
57
Source: 스마트의료정보 표준화 framework개발추진계획_20130307(정영복 코디)

58. Health + ICT ??
58Source: 스마트의료정보 표준화 framework개발추진계획_20130307(정영복 코디)

59. Health + ICT ??
59Source: 스마트의료정보 표준화 framework개발추진계획_20130307(정영복 코디)

60. 문제는 표준이 아닌 규제!!
• 크라우드 펀딩을 받아 체온계를 생산하고자 했던 업체가 직면했던 벽들
1. 의료기기법(시행령, 시행규칙)
2. 의료기기 인허가(동등, 개량, 임상)
3. 모바일 의료용 앱 안전관리 지침
4. 전기, 기계적 안정성(IEC 60601-1 3.X판)
5. 전자파 안정성(IEC 606011-2)
6. 생물학적 안전규격(ISO 10993)
7. 의료기기별 안정성 시험기준
8. 의료기기 소프트웨어 벨리데이션 가이드라인
9. 개인의료정보 보안의 요구사항(개인정보보호법, 의료법, 생명윤리법, 정보통신망법)
10. 의료기기 데이터 국제 표준(ISO/IEEE, IHE, HL7) 상호운용성 평가기준(유헬스케어)
11. KC 전파 인증
12. SIG 블루투스 인증
13. GMP 품질 인증
14. 신의료기기 평가(보험수가)
15. 의료기기 포장 공정 벨리데이션
16. 의료기기 판매업 허가/신고(체온계는 면제)
17. 의료기기 광고 사전심의 규정
60
https://www.facebook.com/groups/koreamobilehealthcare/permalink/1711243019151465/

61. 새로운 기회들 ­ IoT Network effect
61

62. IoT Network effect !!
62

63. IoT Network effect !!
63

65. JongHong Jeon (hollobit@etri.re.kr)
+82-42-860-5333
https://www.linkedin.com/in/hollobit
http://twitter.com/hollobit