ETSI TS 103 378 V1.1.1 (2015-12)

Smart Body Area Networks (SmartBAN) Unified data representation formats, semantic and open data model

DTS/SmartBAN-009

General Information

• Status: Published
• Publication Date: 10-Dec-2015
• Technical Committee: SmartBAN - Smart Body Area Network
• Current Stage: 12 - Completion
• Due Date: 11-Dec-2015
• Completion Date: 11-Dec-2015

Standards Content (Sample)

TECHNICAL SPECIFICATION
Smart Body Area Networks (SmartBAN)
Unified data representation formats,
semantic and open data model
2 ETSI TS 103 378 V1.1.1 (2015-12)

Reference
DTS/SmartBAN-009
Keywords
health, information model, interoperability,
ontology, security, semantic
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2015.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TS 103 378 V1.1.1 (2015-12)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definitions, symbols and abbreviations . 9
3.1 Definitions . 9
3.2 Symbols . 9
3.3 Abbreviations . 9
4 Introduction . 11
5 Ambit and induced constraints . 11
6 SmartBAN open data model and ontology . 13
6.1 SmartBAN information analysis . 13
6.2 SmartBAN open data model ontology. 18
6.2.0 Introduction. 18
6.2.1 WBAN ontology . 21
6.2.2 Nodes ontology . 22
6.2.3 Process ontology . 24
6.2.4 Ontofull ontology . 25
6.2.5 OWL-DL formalization of the SmartBAN ontology . 26
6.3 SmartBAN ontology pre-validation . 27
Annex A (informative): Background and SoA . 30
A.0 Introduction . 30
A.1 Existing sensor/actuator and BAN data representation . 30
A.1.0 Introduction . 30
A.1.1 Wireless Sensor Networks (WSNs) common used data representation models and ontologies . 30
A.1.1.0 Introduction. 30
A.1.1.1 OGC's Observations & Measurements (O&M) and SensorModel Language (SensorML) . 30
A.1.1.1.1 Observations and Measurements (O&M). 30
A.1.1.1.2 Sensor Model Language (SensorML) . 32
A.1.1.2 Existing WSN ontologies . 34
A.1.1.3 OntoSensor ontology . 35
A.1.1.4 Semantic Sensor Network ontology (SSN) . 36
A.1.1.5 WSSN ontology . 37
A.1.1.6 Semantic Web Based Architecture for Managing Hardware Heterogeneity. 38
A.1.2 Proposed sensor ontologies in the eHealth sector. 39
A.1.2.1 CEN TC 251 Health Informatics . 39
A.1.2.2 IEEE reference models for medical device communications . 41
A.1.2.3 Bluetooth LE (Low Energy) profiles for medical devices proposed by Continua Alliance . 41
A.1.2.4 ASTM E31 . 42
A.1.3 Ontology validation methods . 43
A.1.3.0 Introduction. 43
A.1.3.1 Common used symbolic-based method . 44
A.1.3.2 Common used attribute-based methods . 44
A.1.4 Preliminary conclusion concerning existing sensor ontologies . 45
Annex B (normative): OWL-DL formalization of the SmartBAN ontology . 47
B.1 Wban.owl . 47
ETSI
4 ETSI TS 103 378 V1.1.1 (2015-12)
B.2 Nodes.owl . 50
B.3 Process.owl . 55
B.4 Ontofull.owl . 57
History . 63

ETSI
5 ETSI TS 103 378 V1.1.1 (2015-12)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://ipr.etsi.org).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Smart Body Area Network
(SmartBAN).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
6 ETSI TS 103 378 V1.1.1 (2015-12)
1 Scope
The present document specifies and formalizes SmartBAN unified data representation formats (including in particular
sensor/actuator/relay/coordinator/Hub descriptions and sensed/measured data), semantic open data model and
corresponding ontology.
The present document is applicable to a BAN and/or a Smart BAN comprising wearable sensors/actuators devices, a
relay/coordinator device and a Hub. The relay/Coordinator and the Hub functionalities may be handled by a single
device or by two distinct devices.
The present document does not yet address the specification and the formalization of the SmartBAN service ontology
and associated enablers. This will be addressed in the future release of the present document.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI TS 103 325 (V1.1.1) (04-2015): "Smart Body Area Network (SmartBAN); Low Complexity
Medium Access Control (MAC) for SmartBAN".
[2] ETSI TS 103 326 (V1.1.1) (04-2015): "Smart Body Area Network (SmartBan); Enhanced Ultra-
Low Power Physical Layer".
[3] R. Hodgson, P. Keller, J. Hodges, J. Spivak: "QUDT - Quantities, Units, Dimensions and Data
Types Ontologies", 2013.
NOTE: Available at http://www.qudt.org/.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] S. Movassaghi, M. Abolhasan, J. Lipman, D. Smith and A. Jamalipour: "Wireless Body Area
Networks: A Survey", In IEEE Communications Surveys & Tutorials, issue 99, pp. 1-29, January
2014.
[i.2] J. Y. Khan and M. R. Yuce: "Wireless Body Area Network (WBAN) for Medical Applications",
New Developments in Biomedical Engineering, Domenico Campolo (Ed.), 2010, ISBN: 978-953-
7619-57-2.
ETSI
7 ETSI TS 103 378 V1.1.1 (2015-12)
[i.3] A. B. M. Moniruzzaman, S. A. Hossain: "NoSQL Database: New Era of Databases for Big data
Analytics - Classification, Characteristics and Comparison," International Journal of Database
Theory and Application, Vol. 6, August 2013.
[i.4] I. döt Net, C. Evans, O. Ben-Kiki: "YAML Ain't Markup Language", 2011.
NOTE: Available at http://www.yaml.org/about.html.
[i.5] ECMA - 404 (10-2013): "The JSON Data Interchange Format".
NOTE: Available at http://json.org/.
[i.6] Apache Avro™ 1.7.7 Documentation.
NOTE 1: Available at http://avro.apache.org/docs/current/.
NOTE 2: Apache Avro™ is an example of a suitable product freely available. This information is given for the
convenience of users of the present document and does not constitute an endorsement by ETSI of this
product.
[i.7] IEEE 802.15.6 standard tutorial.
NOTE: Available at https://mentor.ieee.org/802.15/dcn/11/15-11-0826-02-0006-ieee-802-15-6-tutorial.ppt.
[i.8] J. Ison, M.Kalas: "EDAM: an ontology of bioinformatics operations, types of data and identifiers,
topics and formats", 2013.
NOTE: Available at http://bioportal.bioontology.org/ontologies/EDAM.
[i.9] Location owl ontology.
NOTE: Available at http://dbpedia.org/ontology/location.
[i.10] M. Smethurst, R. Styles, T. Scott: "The Places ontology", 2007.
NOTE: Available at https://github.com/mmmmmrob/Places-Ontology/blob/master/schema.rdf.xml.
[i.11] I. Horrocks, P. F. Patel-Schneider, H. Boley, S. Tabet, B. Grosof and M. Dean: "SWRL: A
Semantic Web Rule Language Combining OWL and RuleML", W3C Recommendation, May
2004.
[i.12] D. P. Swain, K. S. Abernathy, C. S. Smith, S. J. Lee, S. A. Bunn: "Target heart rates for the
development of cardio respiratory fitness", Med Sci Sports Exerc., 26(1):112-116, PMID:8133731,
1994.
[i.13] S. Cox: "Observations and measurements-xml implementation" OGC document, 2011.
NOTE: Available at http://www.opengeospatial.org/standards/om.
[i.14] ISO 19156: "Geographic information -- Observations and measurements".
NOTE: Available at http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=32574. ®
[i.15] OGC Sensor Web Enablement.
NOTE: Available at http://www.opengeospatial.org/ogc/markets-technologies/swe. ®
[i.16] OGC Sensor Model Language (SensorML).
NOTE: Available at http://www.ogcnetwork.net/SensorML.
[i.17] R. Bendadouche, C. Roussey, G. De Sousa, J. Chanet and K. Mean Hou: "Extension of the
Semantic Sensor Network Ontology for Wireless Sensor Networks: The Stimulus-WSNnode-
Communication Pattern," In Proceedings of the 11th International Semantic Web Conference,
Boston, USA, November 2012.
ETSI
8 ETSI TS 103 378 V1.1.1 (2015-12)
[i.18] M. Compton, C. Henson, L. Lefort and H. Neuhaus: "A survey of the semantic specification of
sensors," In Proceedings of the 2nd International Workshop on Semantic Sensor Networks,
Washington DC., USA, October 2009.
[i.19] D.J. Russomanno, C. Kothari and O. Thomas: "Building a Sensor Ontology: A Practical Approach
Leveraging ISO and OGC Models," In Proceedings of 2005 International Conference on Artificial
Intelligence, pp. 637-643, Las Vegas, NV USA, 2005.
[i.20] ISO 19115-1:2014: "Geographic information -- Metadata -- Part 1: Fundamentals".
NOTE: Available at http://www.iso.org/iso/catalogue_detail.htm?csnumber=53798.
[i.21] W3C Semantic Sensor Network Incubator Group.
NOTE: Available at http://www.w3.org/2005/Incubator/ssn/.
[i.22] S. Nicoliċ, V. Penca, M. Segedinac and Z. Konjoviċ: "Semantic Web Based Architecture for
managing hardware heterogeneity in Wireless Sensor Network", International Journal of Computer
Science Issues, Vol. 8, Issue 4, No 2, July 2011.
[i.23] CEN Technical Commitee 251 on health informatics - published standards.
NOTE: Available at
http://standards.cen.eu/dyn/www/f?p=204:32:0::::FSP_ORG_ID,FSP_LANG_ID:6232,25&cs=1FFF281
A84075B985DD039F95A2CAB820.
[i.24] CEN/ISO 13606 standard on semantic interoperability in the electronic health record
communication.
NOTE: Available at http://www.en13606.org/the-ceniso-en13606-standard
[i.25] ISO/IEEE 11073 standards: "Health informatics -- Personal health device communication".
NOTE: Available at http://www.iso.org/iso/home/search.htm?qt=11073&published=on&active-
tab=standards&sort-by=rel. ®
[i.26] Bluetooth Core Specification 4.2 document.
NOTE 1: Available at https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=286439. ®
NOTE 2: Bluetooth is an example of a suitable product available commercially. This information is given for the
convenience of users of the present document and does not constitute an endorsement by ETSI of this
product.
[i.27] Recommendation ITU-T H.810: "Interoperability design guidelines for personal health systems".
NOTE: Available at http://www.itu.int/rec/T-REC-H.810-201312-S/en.
[i.28] ASTM - Committee E31 on Healthcare Informatics.
NOTE: Available at http://www.astm.org/COMMIT/E31_Fact_Sheet_2015.pdf.
[i.29] ASTM E1238-97: "Standard Specification for Transferring Clinical Observations Between
Independent Computer Systems".
NOTE: Available at http://www.astm.org/Standards/E1238.htm.
[i.30] ASTM E1394-97: "Standard Specification for Transferring Information Between Clinical
Instruments and Computer Systems".
NOTE: Available at http://www.astm.org/Standards/E1394.htm.
[i.31] ASTM E1467-94 (2000): "Standard Specification for Transferring Digital Neurophysiological
Data Between Independent Computer Systems".
NOTE: Available at http://www.astm.org/Standards/E1467.htm.
ETSI
9 ETSI TS 103 378 V1.1.1 (2015-12)
[i.32] ASTM E2369: "Standard Specification for Continuity of Care Record (CCR)".
NOTE: Available at http://www.astm.org/Standards/E2369.htm
[i.33] ASTM E1384: "Standard Practice for Content and Structure of the Electronic Health Record
(EHR)".
NOTE: Available at http://www.astm.org/Standards/E1384.htm
[i.34] S. Tartir, I. Arpinar and A. Sheth: "Ontological Evaluation and Validation", Theory and
Applications of Ontology: Computer Applications, Springer, pp. 115-130, 2010.
[i.35] N. Guarino, C. Welty: "An overview of OntoClean", Handbook On ontologies, Springer,
Chapter 8, 2009.
[i.36] V. Cross and A. Pal: "OntoCAT: An Ontology Consumer Analysis Tool and Its Use on Product
Services Categorization Standards", Computer Science and Systems Analysis, Miami University.
[i.37] A. Lozano-Tello, A. Gomez-Perez: "ONTOMETRIC: A method to choose the appropriate
Ontology", Journal of Database Management, 2 (15) pp. 1-18, 2004.
3 Definitions, symbols and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
example 1: text used to clarify abstract rules by applying them literally
3.2 Symbols
For the purposes of the present document, the following symbols apply:
s second
bps bit per second
bpm beats per minute
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ANP Alert Notification Profile
ASTM American Standards for Testing and Materials
BAN Body Area Network
CCR Continuity of Care Record
CCU Central Control Unit
CEN European Committee for Standardisation
CESN Coastal Environmental Sensor Networks
CRS Coordinate Reference Systems
CSIRO Commonwealth Scientific and Industrial Research Organisation
DL Description Logic
ECG Electrocardiogram
EDAM Embrace Data and Methods
EEG Electroencephalogram
EHR Electronic Health Record
GAP Generic Access Profile
GATT Generic Attribute Profile
GPS Global Positioning System
GW Gateway
HID Human Interface Device
HL7 Health Industry Level 7
HOGP HID Over GATT Profile
ETSI
10 ETSI TS 103 378 V1.1.1 (2015-12)
HR Heart Rate
IC-ISM Intelligence Community Information Security Marking
ICT Information and Communications Technology
IEEE Institute of Electrical and Electronics Engineers
IP Internet Protocol
ISM Industrial, Scientific and Medical
JSON JavaScript Object Notation
KB Knowledge Base
LAN Local Area Network
LE Low Energy
LSDIS Large Scale Distributed Information Systems
MAC Media Access Control
MBAN Medical Body Area Network
MIPS Microprocessor without Interlocked Pipeline Stages
MMI Marine Metadata Interoperability
NoSQL Not only SQL
NT Node Type
O&M Observations & Measurements
OGC Open Geospatial Consortium
OpenGIS Open Geospatial Consortium
OSI Open Systems Interconnection
OUI Organizationally Unique Identifier
OWL Web Ontology Language
OWL DL Web Ontology Language Description Logic
PDA Personal Digital Assistant
PER Packet Error Rate
PHD Personal Health Device
PHY Physical layer
RAM Random Access Memory
ROM Read-Only Memory
RTLS Real Time Location Services
SDO Sleep Domain Ontology
SEEK Science Environment for Ecological Knowledge
SensorML Sensor Model Language
SIG Special Interest Group
SPARQL SPARQL Query Language
SPP Scan Parameters Profile
SQL Structured Query Language
SSN Semantic Sensor Network
SUMO Suggested Upper Merged Ontology
SWAMO Sensor Web for Autonomous Mission Operations
SWE Sensor Web Enablement
TBD To Be Defined
TC Technical Committee
TTL Time to Live
UML Unified Modeling Language
US United States
UUID Universally Unique IDentifier
UWB Ultra Wide Band
W3C World Wide Web Consortium
WBAN Wireless Body Area Network
WBANID Wireless Body Area Network Identifier
WSN Wireless Sensor Network
WSNs Wireless Sensor Networks
WSSN Wireless Semantic Sensor Network
XML Extensible Markup Language
YAML Yet Another Markup Language
ETSI
11 ETSI TS 103 378 V1.1.1 (2015-12)
4 Introduction
The present document gives the high level description of a unified data format providing one of the building blocks for
heterogeneity management in Smart BANs. The present document will in particular define a unified description model
with an extensible semantic metadata for Smart BAN entities related data as well as for monitoring and control
information. The corresponding metadata management and indexing framework will also be investigated.
5 Ambit and induced constraints
The scope of clause 5 of the present document is to briefly investigate the initial TC SmartBAN use case requirements
in order to point out their impact on ETSI TS 103 378 specifications and designs. The initial additional requirements
induced by ETSI TS 103 378 scenario will also be listed.
Wireless Body Area Networks (WBANs) are made of a collection of low-power embedded devices, mainly sensors or
actuators that are used for monitoring vital data of a human and its environment (but not limited to human). Those
embedded devices are located in the vicinity or on or inside the body, and are mainly provided with short range
communication technologies. BANs are short distance networks of maximum 6 m that contain maximum 6 networks
per m and maximum 256 nodes per network [i.1]. These nodes may be mobile and the network topology may change
frequently. The data rate of sensed data can actually vary from 75,9 kbps to 15,6 Mbps [i.1]. WBANs are not expected
to be operated in licensed frequency bands. Hence, the frequency spectrum of operation will be in the unregulated
frequency bands for industrial, scientific and medical (ISM) applications. If ISM and MBAN bands (US and European)
with frequency between 2,3 GHz and 2,5 GHz are initially considered within TC SmartBAN, higher frequency bands
(from 3,2 to 10,2 GHz) will also be considered for allowing the support of Real Time Location Services (RTLS).
Finally, WBANs are characterized by strong constraints in terms of low power, low latency, low Packet Error Rate
(PER), reliability, QoS, coexistence and security. The initial technical requirements retained by TC SmartBAN for
WBAN parameters are listed in table 1.
Table 1
Parameter Smart BAN Requirements
Good (low interference to other systems, high tolerance to
Coexistence/robustness
interference)
Data rates (Sensor) Nominally < 100 kbps/node (vital sign monitoring)
Transmission rate (PHY) Up to 1 Mbps
Network topology Star network
Power consumption (node) TBD
Priority based control and cross layer optimization. Emergency signal
QoS control
transmission supported.
Reliability Robust to shadowing and multipath interference
Max. node capacity up to 16 nodes (typically 8)
Range < 1,5 m
Latency < 125 ms (high sampling applications e.g. ECG, EEG.)
Security / privacy TBD
The initial ambit envisioned by TC SmartBAN contributors is a BAN network organized around a Hub and mainly
following a star topology. The Hub play the role of the BAN cluster head and also serves as an intermediary Gateway
(GW) node allowing the interconnection of the BAN cluster with an healthcare local/remote monitoring and control
centre. This node, with extended memory and processing capacity (e.g. a smart phone), should be responsible for all the
heavy processing management and control operations of the SmartBAN. In case of a multi hope routing strategy, the
BAN shall be provided with at least a bridge/relay functionality that could be handle by the SmartBAN's Hub or within
a dedicated SmartBAN device. This relay/bridge device offers enhanced performance and robustness (e.g. relay around
hidden devices), as well as optimized SmartBAN solutions with enhanced connectivity (multi-radio) and routing
(multi-hop) capabilities. In some global healthcare architectures, the BAN's Hub role may sometimes be handled by a
cluster-external intermediary node called Central Control Unit (CCU) [i.2]. Finally, BAN discovery functionality and
interworking shall be handled and shall thus be taken into consideration for the specification of the SmartBAN semantic
open data model. Figure 1 gives a simple example of the considered SmartBAN end-to-end architecture.
ETSI
12 ETSI TS 103 378 V1.1.1 (2015-12)

Figure 1: Example of considered SmartBAN end-to-end architecture
One main objective of the present document is the BAN heterogeneity management through the specification of a
generic sensor and sensor data description and transfer format. This description format shall be as rich as possible to
allow e.g. conflict resolution or similarity detection, but shall also be handled with low processing, low power and in
quasi real time (e.g. latency < 125 ms and node addition or removal time < 3 s [i.1]). In that context, two scenarios shall
a priori be envisioned:
• Or the proposed ontology is sufficiently light for allowing the sensor raw data pre-processing within the sensor
itself,
• Or the pre-processing is deported to most powerful BAN's nodes. In that case, aforementioned nodes such as
the BAN Hub or the BAN coordinator seem a priori good candidates for handling that pre-processing.
Furthermore, the ontology pre-processing and processing operations complexity strongly depend on the ontology format
and storage format used (e.g. NoSQL [i.3] compared to SQL, or -YAML [i.4], JavaScript Object Notation [i.5], Extract
Load Transfer strategies and Avro Schemas [i.6], etc. - compared to in particular XML, could significantly reduce the
processing power required).
The aforementioned issues will be addressed in the present document.
ETSI
13 ETSI TS 103 378 V1.1.1 (2015-12)
6 SmartBAN open data model and ontology
6.1 SmartBAN information analysis
The objective of clause 6.1 of the present document is first to perform information analysis of the SmartBAN scenarios
and to identify:
• the relevant related information sources, types, formats and owners;
• the information processing operations and functionality towards the SmartBAN related information.
Then, based on the analysis of existing information models already investigated in the SoA clause (see clause A.1 of the
present document), the SmartBAN information meta-model (UML diagram) will be defined in clause 6.1 of the present
document.
Dealing with tiny devices in WBAN shall lead towards the design of a modular model where some classes should be
implemented in the sensor/actuator nodes depending on its resource's availability, and some others should be
implemented and processed in more capable nodes like e.g. the SmartBAN' Hub or coordinator. Basically, the
SmartBAN open data model shall be divided into three main parts: WBAN (SmartBAN or BAN cluster in the TC
SmartBAN context), Nodes (i.e. Hub, sensors, actuators, etc.), Process and Measurements. Figure 2 depicts the class
diagram that shall be introduced for the WBAN/Smart BAN.
OnlineRessource
<>
Contact
ResponsibleParty
Patient
Person
*
hasContact
UserID
Gender
Weight
DOB
Height
Email
WBAN
RestingHR
FName
WaistCircumference
MName
WBANID
HipCircumferenec
LName
FaultTolerence
Language
PhoneNumber
Node Density
FatBurnHR_LowerLimit
*
LifeTime
Contains
FatBurnHR_UpperLimit
NodeID
DeploymentTime
Tr ustL evel
Location
Po s i tio n
ApplicationDomain
Phenomena
Topology
RadioTechnology
*
has Communication Process
<>
CommunicationProcess
Periodic
Event-Driven
Request
CommFrequency
Figure 2: UML classes - TCSmartBAN_WBAN
ETSI
14 ETSI TS 103 378 V1.1.1 (2015-12)
First, a WBAN shall be identified by its WBANID that shall be unique (e.g. the 8-bit BAN ID defined within the TC
SmartBAN MAC TS [1]) and accessible by any authorized user. It is deployed on the human body or implanted in the
human body. Thus, the location of the WBAN, when available and needed, shall be given relatively to the one of the
human body can refer to the location of the patient wearing the WBAN. The WBAN will monitor a specific
phenomenon (burned calories during exercises, glucose level, etc.) belonging to a specific domain of application
(healthcare, telemedicine, assisted living, sport training, pervasive computing, safety and emergency, etc.). The WBAN
is composed of certain number of nodes (WBAN's density). Theses nodes are distributed based on a physical topology
(star in the special case of SmartBANs). The required lifetime and the fault tolerance differ from one application to
another. Whereas WBAN for entertainment purposes should have a lifetime of weeks or few years, WBAN dedicated
for assisted living or anomaly monitoring should last for many years. In addition a WBAN shall measure accurate value
and shall require a small fault tolerance. This parameter is essential in the management of the networks where the fault
tolerance shall be respected and may imply nodes reconfiguration where some nodes are considered down due to the
inaccurate sensed data. The data within the WBAN will be exchanged using in particular SmartBAN radio technology
defined in ETSI TS 103 326 [2] and ETSI TS 103 325 [1].
Each WBAN shall have contacts, and this assumption still holds for SmartBANs. In SensorML model, a contact can be
a person described by his name, userID, email and phone number. A contact can also be an organization described by its
name and address. In our model, a contact shall be:
• An online resource or document, and in that case, a reference to the document is simply given as the class
attribute.
• Or a Responsible Party which plays the role of the patient's reference. It should be an organization or a person.
The creation of the responsible party is very useful for emergency cases. For example, if the WBAN is
developed for the monitoring of elderly, in urgent cases, the system can generate a notification and send it to
the responsible party's mobile phone.
• Or a person which may be a Patient. In the context of TC SmartBAN, the WBAN may have as contact one ®
Alliance (see note), (see clause A.1.2.3 of the present document), describes the patient
patient. The Continua
information in the user data service within the Bluetooth LE standard by patient's full name, weight, height,
email, date of birth, gender, resting heart rate, waist circumference, hip circumference, fat burn heart rate
lower limit, fat burn heart rate upper limit and language (these patient's data shall be added to the patient's
attributes of the SmartBAN open data model). In order to enhance the management of electronic health data
shared between medical systems, the diseases, blood type, allergy or any other medical descriptions shall be
added to this information. The patient shall also be identified by a unique ID that may be his user ID or social
security number. Sharing these data among different biomedical systems allow any clinic or hospital to
identify the patient and deduce his medical archive.
NOTE: Continua is an example of a suitable product available commercially. This information is given for the
convenience of users of the present document and does not constitute an endorsement by ETSI of this
product.
Whereas the WBAN can be formed by many clusters, the present document is focused on the topology shown in
figure 1 where a SmartBAN shall be formed of only one cluster. This work can be extended to multi cluster topology
where the cluster shall be identified by the Cluster ID. If Bluetooth LE is used for wireless communication, the channel
for each cluster shall be saved in addition to the number of nodes and the topology used within the cluster. Finally, the
SmartBAN shall contain nodes.
In WBAN architecture, three types of communication shall be differentiated: Intra WBAN communication between the
nodes and the Hub, Inter WBAN communication between the Hub and the internet and beyond WBAN communication
with the medical servers and health care systems on e.g. a cloud. The inter WBAN communication shall obey to one of
these three ways. The first type is the periodic communication where the nodes send data to the BAN coordinator (i.e.
the cluster Hub) every T seconds. The second one is based on BAN coordinator requesting BAN nodes for triggering
their reply. The third one is based on event-triggering. When certain events occur, the nodes send their data to the BAN
coordinator. That is why the inter WBAN communication type shall be precised to enhance remote management. For
example, if periodic exchange is used, and the hub did not receive data during T seconds, it should identify that this
node is malfunctioning.
ETSI
15 ETSI TS 103 378 V1.1.1 (2015-12)
The description of the SmartBAN node's model is now presented. Figure 3 represents the UML class diagram that shall
at least be specified for the SmartBAN's nodes. The node shall be a sensor, an actuator which acts according to data
received from the sensors or through interaction with user, or a node responsible of data routing or pre-processing like a
BAN coordinator or relay, a cluster head (BAN's hub), or others. As an example, an actuator equipped with a built-in
reservoir and pump can administer the correct dose of insulin to give to diabetics based on the glucose level
measurements. The node may be a cluster head (BAN's hub) which is responsible for collecting the data and for sending
it outside the WBAN to a local or remote monitoring and control centre. In some cases, the coordinator is called
aggregator, collector or body centre unit. In the SmartBAN model, the coordinator is called the Hub. In many cases
especially in m-health applications, the Smart Phone or the PDA of the user will play this role. It will collect the data
from the sensors via Bluetooth interfaces and send it to the medical servers via 3G/4G or wireless interfaces.
Moreover, each node shall be identified by the Node ID that may be the MAC address, the serial number or any other
unique descriptor. A new class named "NodeType" and describing the physical characteristics of a node (as described in
the SoA clause A.1.1.2 of the present document) has been introduced within the SmartBAN data model for redundancy
avoidance. Each node shall have only one node's type. The survival properties, which describe the conditions to which a
sensor can be exposed without causing lasting damage, shall also be added. When these properties occurred on a
network, all data sent from this node should be considered as insignificant data and trigger the stopping of this node.

Figure 3: UML Class Diagram- Nodes
ETSI
16 ETSI TS 103 378 V1.1.1 (2015-12)
The mobility also enhances the performance of the sensor networks. Basically, the nodes in WBAN have mobility
capability. Thus, the velocity of a mobile sensor, the energy consumption during its movement and the maximum
distance that it can travel should be registered in the SmartBAN node model. This feature will help in collecting data.
Many times it will be more efficient for the network that a mobile sensor travels over the network to collect data or send
request or reconfigure certain nodes. Each node type has certain functioning modes (Sleep, active, down, transmission,
reception, etc.). Keeping in mind the power management of the WBAN (SmartBAN low energy constraint), the power
consumed in each mode will help us in estimating the lifetime of the WBAN and shall be registered in the SmartBAN
node model. For example, if the communication within the WBAN is a periodic communication, it will be useful to
switch the node from active mode to sleep mode during a period t (since no data will be sent during that period), thus
permitting a reduction of power consumption on the node.
Each node type shall have wakeup latency. The wakeup latency is the time required by the sensor to generate a correct
value once activated. Clearly, if the sensor reading is performed before the wakeup latency has elapsed, the acquired
data is not valid. Furthermore, each node type shall have a processor identified by a processor ID. The processor shall
have RAM, ROM and a flash memory. The node with higher memory resources has the priority to be elected as cluster
head or a BAN coordinator. In addition, the MIPS, frequency and duty cycle shall be introduced in the SmartBAN node
model because they reflect the speed of processing certain data.
While the nodes are typically powered by batteries with a limited lifetime, they should benefit from additional energy
harvested from the external environment. Recently, many researches have been investigated in the domain of energy
scavenging from on-body sources such body heat and body vibration. Where the source of energy for the same node can
vary, the source of energy shall be revealed in the SmartBAN open data model.
Data transmissions within a WBAN are via interfaces. Each node type may have many interfaces (e.g. SmartBAN PHY
& MAC TS, Bluetooth, UWB, IEEE 802.15.6 [i.7], serial interface, etc.). A new class "interface type" that describes the
standard characteristics of the interface's protocol, the baud rate and the functional layer shall be added for redundancy
avoidance. Regarding the interface, it shall be identified by the interface ID that may be the IP address or the unique
address used in the communication protocol. The interface may have many addresses like MAC address, IP address or
others. One shall precise if the interface is considered as gateway in order to help the monitoring and control server in
finding how it can communicate with the WBAN from its LAN, backbone, or infrastructure side.
The dynamic characteristics of a node that vary during the WBAN lifetime are now presented. First, each node shall
have only one current mode. For example, if a BAN coordinator has sent a request to collect certain information, only
nodes who are in Active mode can reply. Moreover, the patient's information shall be always available to the physician.
By tracking the current mode of each node, in addition to the features mentioned before, one may choose how the
switching process shall be done. The node occupies certain position, it can be planted in the human body, on the body
surface (head, waist, chest, wrist, etc.), or not in contact with the human body with a distance of few meters [i.1].
Moreover, security is a key point in WBAN management, that is why the Trust Level for each node shall be added
within the SmartBAN data model.
The dynamic memory and energy components of the nodes shall be described in the "MemoEnergy" class. The
remaining lifetime or memory may influence directly on the selection of the BAN Hub or coordinator, especially that
the hub's death may cause the malfunctioning of the entire WBAN.
Finally, a crucial issue is the reliability of the transmission in order to guarantee that the monitored data is received
correctly and in reasonable time. In general, the Hub is the node who can monitor other nodes to predict any failure. To
assure the reliability, the link state for the path between nodes shall be added to the SmartBAN data model for
indicating the last time the Hub has received a message from a node. If this time is too long, the Hub can therefore
predict that this node is facing some trouble. In addition, it will keep track of the error rate of a node and its delay to
consider a node as invalid and asks it to go to the inactive mode in order to reduce bandwidth consumption.
The third parts of the SmartBAN open data model shall be provided with the process classes presented in Figure 4.
ETSI
...