ETSI TS 103 327 V1.1.1 (2019-04)

Smart Body Area Networks (SmartBAN); Service and application standardized enablers and interfaces, APIs and infrastructure for interoperability management

DTS/SmartBAN-004

General Information

• Status: Published
• Publication Date: 04-Apr-2019
• Technical Committee: SmartBAN - Smart Body Area Network
• Current Stage: 12 - Completion
• Due Date: 30-Apr-2019
• Completion Date: 05-Apr-2019

Standards Content (Sample)

TECHNICAL SPECIFICATION
Smart Body Area Networks (SmartBAN);
Service and application standardized enablers and interfaces,
APIs and infrastructure for interoperability management

2 ETSI TS 103 327 V1.1.1 (2019-04)

Reference
DTS/SmartBAN-004
Keywords
application layer, control, health, information
model, interface, interoperability, interworking,
IoT, network, ontology, privacy, protocol, security,
service
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 prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
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
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
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.

© ETSI 2019.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI TS 103 327 V1.1.1 (2019-04)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definition of terms, symbols and abbreviations . 9
3.1 Terms . 9
3.2 Symbols . 9
3.3 Abbreviations . 10
4 Ambit and induced constraints . 12
5 High Level Architecture of SmartBAN heterogeneity management architecture . 14
5.0 Introduction . 14
5.1 SmartBAN reference model and architecture . 15
5.1.0 Introduction. 15
5.1.1 SmartBAN reference model High Level Architecture (HLA) . 15
5.1.2 ETSI SmartBAN and AIOTI [i.5] IoT High Level Architecture (HLA) mapping . 16
5.1.3 ETSI SmartBAN and oneM2M[i.3] High Level Architecture (HLA) mapping . 17
5.1.4 ETSI SmartBAN and HL7 Fast Healthcare Interoperability Resources Specification (FHIR [i.6])
interactions . 19
5.1.5 SmartBAN reference architecture: agents definitions . 24
5.1.6 SmartBAN reference architecture: Process and data flows . 26
5.1.6.0 Introduction . 26
5.1.6.1 Set up phase . 26
5.1.6.2 Node Discovery Phase . 27
5.1.6.3 Measurement Collection Phase . 27
5.1.6.4 Service Discovery Phase . 28
5.1.6.5 Service Processing Phase . 29
5.1.6.6 Network Management . 29
5.1.7 Summary . 30
5.2 SmartBAN IoT compliant layering reference architecture validation . 30
5.2.1 Validation use case: elderly at home monitoring . 30
5.2.2 Tests and results . 34
Annex A (informative): Background and SoA . 37
A.0 Introduction . 37
A.1 Existing data sharing/transfer formats, protocols and interoperability frameworks for (or
applicable for) sensors/actuators and BANs. 37
A.1.1 Sensor Web Enablement (SWE [i.16]) . 37
A.1.2 WSN's data communication protocols . 39
A.1.2.0 Introduction. 39
A.1.2.1 JSON and JSON-LD protocols ([i.11], [i.17]) . 39
A.1.2.2 Constrained Application Protocol (CoAP [i.12]) . 39
A.2 e-health related architectures . 41
A.2.0 Introduction . 41
A.2.1 ContoExam ([i.21]) . 41
A.2.2 Personal Connected Health Alliance global healthcare architecture . 43
A.2.3 ASTM Healthcare Informatics architecture ([i.26]) . 44
A.2.4 MedCom ([i.32]) . 45
A.2.5 The pan-Canadian EHR ([i.34]) . 45
ETSI
4 ETSI TS 103 327 V1.1.1 (2019-04)
A.3 Existing Semantic Web Service Architectures . 48
A.3.1 OWL-S [i.35] . 48
A.3.2 Service Profile . 48
A.3.3 Service Model . 49
A.3.4 Service Grounding . 49
A.4 Existing generic service layers and enablers for in particular WSNs and WBANs . 50
A.4.1 Service Oriented Architecture for WSN . 50
A.4.2 Semantic SOA for WSN . 53
A.4.3 Open Sensor Web Architecture (OSWA [i.43]) . 55
History . 56

ETSI
5 ETSI TS 103 327 V1.1.1 (2019-04)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables 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 (https://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.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
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.
Introduction
The present document gives the high level description of infrastructure and mechanisms providing solutions for
interoperability management in SmartBAN. The scope mainly covers the networking level up to the service and
application level. The expected solutions will mainly concern the description and the specification of a standardized
infrastructure for SmartBAN entities (e.g. sensors, actuators) interactions, data access and monitoring, irrespective of
whatever lower layers and radio technologies are used underneath. On the service and application side, standardized
APIs, in particular, for secure interaction and access to SmartBAN data/entities (data transfer and sharing mechanisms
included) will be addressed.
ETSI
6 ETSI TS 103 327 V1.1.1 (2019-04)
1 Scope
The present document describes and specifies the high level infrastructure, its building blocks and associated APIs
providing interoperability management solutions for SmartBAN. The architecture described in the present document
also enables generic interaction and access to BAN data and entities, and thus paves the way to interoperability
(networks and syntactic interoperability). Since the SmartBAN reference architecture specified and formatized in the
present document fully relies on SmartBAN open semantic data model and corresponding ontologies as already
standardized in [1], it therefore also addresses data and semantic interoperability.
The present document is applicable to a BAN and/or a SmartBAN 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 is also addressing syntactic interoperability by defining unified data transfer and message
formats.
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
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://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 378 (V1.1.1) (12-2015): "Smart Body Area Networks (SmartBAN) Unified data
representation formats, semantic and open data model".
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
referenced 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.
[i.3] oneM2M TS-0001-V2.10.0 (08-2016): "Functional Architecture".
NOTE: Available at http://www.onem2m.org/images/files/deliverables/Release2/TS-0001-
%20Functional_Architecture-V2_10_0.pdf.
ETSI
7 ETSI TS 103 327 V1.1.1 (2019-04)
[i.4] Alliance for Internet of Things Innovation (AIOTI) WG03 - IoT Standardization: "IoT High Level
Architecture (HLA) Release 3.0".
NOTE: Available at https://aioti.eu/wp-content/uploads/2017/06/AIOTI-HLA-R3-June-2017.pdf.
[i.5] Alliance for Internet of Things Innovation (AIOTI) WG03 - IoT Standardization: "High Level
Architecture (HLA) Release 4.0".
NOTE: Available at https://aioti.eu/wp-content/uploads/2018/06/AIOTI-HLA-R4.0.7.1-Final.pdf.
[i.6] HL7 FHIR® Specification 3 document.
NOTE 1: Available at http://hl7.org/fhir/index.html.
NOTE 2: FHIR® is an example of an existing eHealth standard. This information is given for the convenience of
users of the present document and does not constitute an endorsement by ETSI of this standard.
[i.7] IETF RFC 2616 (04-2014): "Hypertext Transfer Protocol -- HTTP/1.1".
NOTE: Available at https://tools.ietf.org/html/rfc2616.
[i.8] ZigBee® Specification document.
NOTE: Available at http://www.zigbee.org/download/standard-zigbee-pro-specification-2/#.
[i.9] OASIS MQTT Version 3.1.1 (04-2014).
NOTE: Available at http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/csprd02/mqtt-v3.1.1-csprd02.pdf.
[i.10] 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.11] ECMA-404 (12-2017): "The JSON Data Interchange Format".
NOTE: Available at http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf.
[i.12] IETF RFC 7552 (06-2014): "The Constrained Application Protocol (CoAP)".
NOTE: Available at https://tools.ietf.org/html/rfc7252.
[i.13] Roy T. Fielding: "Architectural styles and the design of network-based software architectures".
PhD Thesis, University of California, Irvine, 2000.
NOTE: Available at http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.
[i.14] W3C SPARQL 1.1 Query Language (03-2013).
NOTE: Available at https://www.w3.org/TR/sparql11-query/.
[i.15] W3C SWRL (05-2004): "A Semantic Web Rule Language Combining OWL and RuleML".
NOTE: Available at https://www.w3.org/Submission/SWRL.
[i.16] Open Geosatial Consortium (OGC) Sensor Web Enablement tutorial.
NOTE: Available at http://www.opengeospatial.org/domain/swe.
[i.17] M. LANTHALER, C. GÜTL: "On using JSON-LD to create evolvable RESTful services", in
Proceedings of the Third International Workshop on RESTful Design, pp. 25-32, Lyon, France,
April 2012.
ETSI
8 ETSI TS 103 327 V1.1.1 (2019-04)
[i.18] IETF RFC 0793 (09-1981): "Transmission Control Protocol".
NOTE: Available at https://www.ietf.org/rfc/rfc793.txt.
[i.19] IETF Constrained RESTful Environments (core) working group.
NOTE: Available at https://datatracker.ietf.org/wg/core/charter/.
[i.20] IETF RFC 0768 (08-1980): "User Datagram Protocol".
NOTE: Available at https://tools.ietf.org/html/rfc768.
[i.21] P. Brandt, T., Basten, S. Stuijk: "ContoExam: an ontology on context-aware examinations", in
Proceedings of FOIS2014, pp. 303-316, Brazil, September 2014.
[i.22] SNOMED CT® starter guide.
NOTE 1: Available at https://confluence.ihtsdotools.org/display/DOCSTART/SNOMED+CT+Starter+Guide.
NOTE 2: SNOMED CT® is an example of an existing eHealth reference terminology. This information is given
for the convenience of users of the present document and does not constitute an endorsement by ETSI of
this reference terminology.
[i.23] NISO spring 2015 ISQ issue.
NOTE: Available at https://groups.niso.org/publications/isq/2015/.
[i.24] Personal Connected Health Alliance.
NOTE: Available at http://www.pchalliance.org/.
TM
[i.25] ISO/IEEE 11073 standards: "Health informatics -- Personal health device communication".
NOTE: Available at https://www.iso.org/search.html?q=11073.
[i.26] ASTM International Technical Committee E31 description.
NOTE: Available at https://www.astm.org/COMMIT/E31_FactsheetHI.pdf.
[i.27] ASTM E1238-97: "Standard Specification for Transferring Clinical Observations Between
Independent Computer Systems" (Withdrawn 2002).
NOTE: Available at https://www.astm.org/DATABASE.CART/WITHDRAWN/E1238.htm.
[i.28] ASTM E1394-97: "Standard Specification for Transferring Information Between Clinical
Instruments and Computer Systems" (Withdrawn 2002).
NOTE: Available at https://www.astm.org/DATABASE.CART/WITHDRAWN/E1394.htm.
[i.29] ASTM E1467-94: "Standard related to the transfer of digital neurophysiological data between
independent computer systems" (Withdrawn 2004).
NOTE: Available at https://www.astm.org/Standards/E1467.htm.
[i.30] ASTM E2369-12: "Standard Specification for Continuity of Care Record (CCR)".
NOTE: Available at https://www.astm.org/Standards/E2369.htm.
[i.31] ASTM E1384-07 (2013): "Standard Practice for Content and Structure of the Electronic Health
Record (EHR)" (Withdrawn 2017).
NOTE: Available at https://www.astm.org/Standards/E1384.htm.
[i.32] J. H. Bjerregaard, P. C. Duedal. MedCom: "Danish health care network. Studies in health
technology and informatics", 2003. Vol. 100, p. 59-65.
ETSI
9 ETSI TS 103 327 V1.1.1 (2019-04)
[i.33] W3C SOAP Version 1.2 specification (04-2007).
NOTE: Available at https://www.w3.org/TR/soap/.
[i.34] Dennis Giokas Chief Technology Officer Solution Architecture Group Canada Health Infoway
Inc. 1: "SOA in the pan-Canadian EHR".
NOTE: Available at http://www.omg.org/news/meetings/workshops/HC-Australia/Giokas.pdf.
[i.35] W3C OWL-S (11-2004): "Semantic Markup for Web Services".
NOTE: Available at https://www.w3.org/Submission/OWL-S/.
[i.36] Lan, M. Qilong, J. Du: "Architecture of wireless sensor networks for environmental monitoring. In
Education Technology and Training", in Proceedings of IEEE IITA-GRS 2008, Shanghai, China,
December 2008.
[i.37] E. Avilés-López, J. García-Macías, J. Antonio: "TinySOA: a service-oriented architecture for
wireless sensor networks", Service Oriented Computing and Applications. 2009. Vol. 3, n 2,
pp. 99-108.
[i.38] F. C. Dedicato, P. F. Pires, L. Pirmez, T. Batista: "Wireless Sensor Networks as a service", In
Proceedings of IEEE ECBS2010, pp. 410-417, UK, March 2010.
[i.39] A. Ghobakhlou, A. Kmoch, P. Sallis: "Integration of Wireless Sensor Network and Web Services",
in Proceedings of the 20th International Congress on Modelling and Simulation, pp. 1-6, Adelaide,
Australia, 2013.
[i.40] K. K. Khedo, R. K. Subramanian: "A service-oriented component-based middleware architecture
for wireless sensor networks", International Journal of Computer Science and Network Security,
2009. Vol. 9, n 3, pp. 174-182.
[i.41] A. P. Singh, O. P. Vyas, S. Varma: "Flexible Service Oriented Network Architecture for Wireless
Sensor Networks", International Journal of Computers Communications & Control. 2014. Vol. 9,
n 5, pp. 610-622.
[i.42] F. Amato, V. Casola, A., Gaglione, A. Mazzeo: "A semantic enriched data model for sensor
network interoperability", Simulation Modelling Practice and Theory. 2011. Vol. 19, n 8,
pp. 1745-1757.
[i.43] CHU, Xingchen: "Open sensor web architecture: core services", The University of Melbourne,
Australia, 2005.
3 Definition of terms, symbols and abbreviations
3.1 Terms
Void.
3.2 Symbols
For the purposes of the present document, the following symbols apply:
bpm beats per minute
bps bit per second
s second
ETSI
10 ETSI TS 103 327 V1.1.1 (2019-04)
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACK Acknowledgement (e.g. ACK message)
AE Application Entity
AIOTI Alliance for Internet of Things Innovation
API Application Programming Interface
ASTM American Standards for Testing and Materials
AT ATtention (e.g. AT Command)
BAN Body Area Network
BANID Body Area Network IDentifier
BLE Bluetooth Low Energy
BLES Bluetooth LE Scanner agent
CCR Continuity of Care Record
CCU Central Control Unit
CEN Comité Européen de Normalisation (European Committee for Standardization)
CoAP Constrained Application Protocol
CON Confirmable (e.g. CON message)
Core Constrained RESTful Environments
CPU Central Processing Unit
CSE Core Service Entity
DIM Domain Information Model
DS Data Scanner agents
DTLS Datagram Transport Layer Security
E2E End-to-End
ECG Electrocardiogram
EDI Electronic Document Interchanged
EEG Electroencephalogram
EHR Electronic Health Record
EHRS Electronic Health Record Solution
EU European Union
FHIR Fast Healthcare Interoperability Resources
GATT Generic Attribute Profile
GCM Google Cloud Messaging
GUI Graphical User Interface
GW Gateway
HDF HL7 Development Framework
HDP Health Device Profile
HIAL Health Information Access Layer
HL7 Health Level Seven International
HLA High Level Architecture
HMI Human-Machine Interface
HR Heart Rate
HTTP Hypertext Transfer Protocol
ICT Information and Communication Technology
IEEE Institute of Electrical and Electronics Engineers
IHE Integrating the Healthcare Enterprise
IoT Internet of Things
IP Internet Protocol
ISM Industrial, Scientific and Medical
ISQ Information Standards Quarterly
IT Information Technology
JS JSON Scanner
JSON JavaScript Object Notation
JSON-LD JavaScript Object Notation Linked Data
JW JSON Writer
LAN Local Area Network
LAN-IF Local Area Network Interface
LD Linked Data
LE Low Energy
ETSI
11 ETSI TS 103 327 V1.1.1 (2019-04)
LRS Longitude Record Services
M2M Machine to Machine
MAC Medium Access Control
MAS Management Abstraction and Semantics
MBAN Medical Body Area Network
MQTT Message Queue Telemetry Transport
MVTU Ministry of Science Technology and Innovation
MW Measurement Wrapper
NICTA National ICT Australia
NISO National Information Standards Organization
NON Non-confirmable (e.g. NON message)
NSE Network Service Entity
NW Node semantic Wrappers
OGC Open Geospatial Consortium
OMA Open Mobile Alliance
OSWA Open Sensor Web Architecture
OWL Web Ontology Language
OWL-S Web Ontology Language for Services
PAN Personal Area Network
PAN-IF Peripheral Area Network Interface
PDA Personal Digital Assistant
PER Packet Error Rate
PHY Physical
PoS Point of Services
PW Process semantic Wrappers
QoI Quality of Information
QoS Quality of Service
RAM Random Access Memory
RDF Resource Description Framework
REST REpresentational State Transfer
RFID Radio Frequency Identification
RSSI Received Signal Strength Indication
RST Reset (e.g. RST message)
RTLS Real Time Location Services
SAS Sensor Alert Service
SCS Sensor Collection Service
SDO Standards Development Organizations
SensorML Sensor Model Language
SIG Special Interest Group
SMS Short Message Service
SOA Service Oriented Architecture
SOAP Simple Object Access Protocol
SOS Sensor Observation Service
SPARQL Simple Protocol and RDF Query Language
SPS Sensor Planning Service
SW Semantic Wrapper
SWE Sensor Web Enablement
SWRL Semantic Web Rule Language
TAN Touchable Area Network
TAN-IF Touchable Area Network Interface
TBD To Be Defined
TC Technical Committee
TCP Transmission Control Protocol
TML TransducerML
TransducerML Transducer Model Language
TS Technical Specification
UDDI Universal Description, Discovery and Integration
UDI Universal Device Identifier
UDP User Datagram Protocol
UI User Interface
UML Unified Model Language
URI Uniform Resource Identifier
ETSI
12 ETSI TS 103 327 V1.1.1 (2019-04)
URL Uniform Resource Locator
US United States
UUID Universally Unique IDentifier
W3C World Wide Web Consortium
WAN Wide Area Network
WAN-IF Wide Area Network Interface
WBAN Wireless Body Area Network
WNS Web Notification Service
WoT Web of Things
WRS Web Registry Service
WSDL Web Services Description Language
WSN Wireless Sensor Network
WW WSN Writer
XaaS Everything as a Service
xHRN-IF Electronic/Personal Health Records Network Interface
XML eXtensible Markup Language
4 Ambit and induced constraints
The scope of the present clause is to briefly investigate the initial TC SmartBAN use case requirements in order to point
out their impact on High level specifications and designs of the present document. The initial additional requirements
induced by scenario addressed within the present document are also 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: Initial technical requirements retained by TC SmartBAN for WBAN parameters
Parameter SmartBAN 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
ETSI
13 ETSI TS 103 327 V1.1.1 (2019-04)
The initial ambit envisioned by TC SmartBAN 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 smartphone), should be responsible for all the heavy
processing data collection and management/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)
routing (multi-hop) and data forwarding 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]. Figure 1 gives a
simple example of the considered SmartBAN end-to-end architecture.

Figure 1: Example of considered SmartBAN end-to-end architecture
BANs are made of a growing number of small sensing devices and are used in multiple use cases for which data
procurement, collection, monitoring and control are mandatory. Generally domain dedicated, those devices are provided
by an increasing number of manufacturers, which leads to interoperability problems (e.g. heterogeneous interfaces
and/or grounding, heterogeneous descriptions, profiles, models, etc.). Interoperability management is thus a SmartBAN
key requirement and shall be handled.
Therefore, the main objective of the present document is the BAN interoperability management through the
specification of an high level infrastructure, its building blocks and associated APIs providing generic interaction and
access to BAN data and entities. This kind of open middleware/framework will not only enable vertical interoperability
within a given application domain (such as e.g. well-being, m-health, tele-health, safety/emergency, entertainment) but
will also ease the cross domain interworking of in particular devices. This represents a first step towards the horizontal
management of BAN multiple vertical application domains. SmartBAN interoperability management also involves the
design of interworking components (entities, APIs or gateways) for allowing non SmartBAN enabled environments to
interoperate with SmartBAN.
Interoperability of multiple and new BAN technologies not only implies a generic interconnection between BANs
components (sensors, actuators, relays, concentrators and hubs) but also a shared and mutual understanding of BAN
devices and environment description, as well as of exchanged data format (syntactic and structural interoperability
among frameworks). Syntactic and structural interoperability will thus be addressed in the present document.
ETSI
14 ETSI TS 103 327 V1.1.1 (2019-04)
Finally, the following reminder has to be made: BAN interoperability and heterogeneity management have to be
handled by taking into account other strong constraints like in particular low complexity, ultra-low power and
dynamicity (e.g. node mobility, topology changes). That is why the SmartBAN dedicated interoperability framework
that is specified in the present document shall be designed as modular/distributable and extensible. Therefore, existing
distributed and Multi-Agents based architectures like, e.g. oneM2M [i.3] and IoT [i.4] are, in particular, considered in
the present document.
All the aforementioned issues are addressed in the present document.
5 High Level Architecture of SmartBAN heterogeneity
management architecture
5.0 Introduction
Actually, almost all SmartBAN services are presented as close solutions where the users adopts a low-level sensor
network configuration, and use a specific application coupled with this implemented network configuration. This
application prohibits the possibility to benefit from collected data among different solutions and service providers. For
this reason, a general architecture should be designed to achieve interoperability, not only between SmartBAN's
components, but also between different solutions and applications. In SmartBAN, body sensors should communicate
with the body getaway or hub, which in turn will send data to a local server and/or remote and distributed monitoring
servers and services distributed among medical specialists, caregivers, relatives and even home managers. This transfer
of data within a SmartBAN should be described in a general architecture to facilitate the interconnection between
different nodes.
Beside interoperability within the SmartBAN, linking patients to their history records as well as patient identification
should be required for improving patient care, safety and decrease health care cost. For illustration, consider a patient
who is accessing the emergency part of a hospital, it will be very useful if the hospital staff identifies the patient and
retrieves all historical data (allergies, surgeries, medical consultations, etc.) for intelligent and accurate intervention.
However, relating patients to their records is still tedious because actually data warehouse systems are siloed and
proprietary systems where interoperability is still the big challenge. Thus, standardizing the approaches to patient
identification among different health-care systems is required. For this reason, SmartBAN reference architecture shall
emphasize the cooperation between different SmartBANs and should also lead to new cross domain applications in
order to integrate the SmartBANs in the Web of Things (WoT). In addition, this architecture shall:
• provide sensor/actuators/device interoperability, as well as network interoperability, i.e. be multi-platform
enabled. For network interoperability management purposes, the SmartBAN reference model should follow
the oneM2M specifications;
• provide ontology-based intelligence with semantic interoperability and data reusability functionalities;
• enhance the nodes registration process toward zero configuration and automatic BAN nodes/services
discovery;
• handle urgent cases and notifications;
• provide dynamic reconfiguration of the network when necessary to extend the lifetime of the network;
• provide faults' management;
• address security, privacy and confidentiality;
• ensure the freshness of the data and services; and
• especially enable the automatic patient identification, device/data/service discovery and description.
ETSI
15 ETSI TS 103 327 V1.1.1 (2019-04)
To achieve this goal, XaaS (Everything as a Service) and WoT (Web of Things) approaches should be envisioned.
A semantic representation of the information and semantic interoperability strategies are also the key issues to manage
the interoperability between different vendors and applications. Furthermore, to provide a smart and context aware
environment where computers will accomplish tasks instead of people, the multi-agent architecture is the most
promising technique. This architecture is dynamic, where agents are invoked when needed and can communicate to
invoke other agents. These agents will work autonomously and cooperatively. In addition, the multi-agent architecture
provides a good level of granularity and redundancy where agents can be implemented on different devices; thus
enabling a distributed computing architecture.
5.1 SmartBAN reference model and architecture
5.1.0 Introduction
To improve the maintainability and the flexibility, the proposed SmartBAN reference model and architecture is
designed as a multi-agent IoT architecture. The SmartBAN reference model shall also fully rely on BAN semantic data,
service model, corresponding ontologies (as already standardized in [1]), and shall also address semantic
interoperability. It is specified for both: allowing a generic and secure interaction/access to any BAN data/entities,
providing a unified reference platform for BAN distributed monitoring and control operations.
5.1.1 SmartBAN reference model High Level Architecture (HLA)
The SmartBAN reference architecture follows a multi-layer model where all layers:
• are communicating to each other;
• can be implemented independently in a device depending on the device capabilities and the needs, thus
allowing for constraint devices to include just the required functionality.
It consists of four layers: the data provision layer; the semantic data layer, the service layer and the application layers.
Each of those layers provides a set of both agents and generic feature modules that offer a cohesive set of services.
Figure 2 depicts these four layers.

Figure 2: SmartBAN High Level Architecture
Data Provision layer: Figure 2 consists of the physical nodes and things (sensors, actuators, wereables, hub,
coordinator, gateway, smartphone, etc.) as well as of external users (i.e. people such as the medical staff, caregivers, or
the patient and its relatives) and HMIs (human-machine interfaces). In other terms, the data provision layer
encompasses any person/device/process that deliver raw data or control a mechanisms or a system.
ETSI
16 ETSI TS 103 327 V1.1.1 (2019-04)
Semantic Data layer: is composed of entities mainly providing SmartBAN semantic and ontologies management
functionalities (like e.g. reasoning, semantic search/annotation/eventing, etc.). This layer also extends standard BAN
systems with additional embedded intelligence related functionalities through some rules management entities. Due to
the integration of a set of agents and generic feature modules that offer semantic rules management and rezoning
functionalities, this layer also permits to correlate different collected data for advanced decision making. The semantic
data can be retrieved by using Semantic Query Language (SPARQL).
Service layer: mainly provides generic entities related to service management functionalities like e.g. service creation,
discovery and execution. The services shall be semantically described using SmartBAN service ontology specified and
formalized in [1]. This ontology permits the automatic service discovery in terms of QoS, QoI, I/O parameters, effects,
etc. This also helps service developer/user to interact with the SmartBAN regardless the underneath layers.
SmartBAN Service and Semantic Data layers link the application layer to the data provision layer. They shall fully rely
on SmartBAN data model and ontologies as already specified and formalized in [1]. Service and Semantic Data layers
provide a set of agents and generic feature modules that offer a cohesive set of services. Those agents and modules can
exchange data or command with each other and this is done through dedicated data templates and a specific interface
(see Figure 2).
Application layer: is composed of several Application Entities, each one implementing a given SmartBAN application
logic (e.g. data monitoring, patient evaluation result, patient notification, etc.). SmartBAN Application Entities can
exchange data or command with each other and this is done through dedicated data templates and a specific interface
(see Figure 2).
5.1.2 ETSI SmartBAN and AIOTI [i.5] IoT High Level Architecture (HLA)
mapping
The Alliance for Internet of Things Innovation (AIOTI) has been initiated as a result of the European and global IoT
technology and market developments. AIOTI is a non-profit association under the Belgium law
...