ETSI SmartBAN Architecture: The Global Vision for Smart Body Area Networks

This paper presents a condensed review of the European smart body area network (BAN) standardization work and its already published standards. The work is carried out under the ETSI Technical Committee (TC) SmartBAN. The goal of ETSI TC SmartBAN is to define and develop new European BAN standards; fostering the successful market adoption of wireless BAN technology by providing a standardized way to bring new interoperable products into the health, medical, sport, leisure and IoT markets, targeting to global exploitation. TC SmartBAN covers wireless communications, especially the physical and medium access control layers, associated security, semantic interoperability and open data representation, which are necessary features in the data transmissions, as well as building blocks of the future smart coordinator. The use of smart coordinator centralizes the network intelligence to the hub, which enables implementation of simple nodes. The SmartBAN approach will be computationally light, and it supports reliable operations across heterogeneous networks. Due to the semantic approach in all functional levels, SmartBAN also supports high interoperability. For emergency traffic, SmartBAN provides different priority classes and fast channel access associated with a low latency. Novel concept adopted in the SmartBAN for high-priority traffic is a multi-use channel access, which can also improve the spectral efficiency. Not only on-body nodes and applications, TC SmartBAN is considering in-body communications for capsule endoscopy. In addition, SmartBAN collaborates with other standardization groups, such as oneM2M and AIOTI, to widen the impact of its work.


I. INTRODUCTION
The Internet of Things (IoT) business is currently growing exponentially and the use of wearable electronics and body sensors/devices is expanding rapidly along with it. It is not only growth though in terms of the number of devices, but also with respect to the type of devices, their functionality, The associate editor coordinating the review of this manuscript and approving it for publication was Pietro Savazzi . services and the richness of connectivity. More and more, our personal systems must support not only wireless connectivity, but the ability to seamlessly interact with our environment and communicate in a secure, privacy preserving and dependable manner. This sets new and increasing demands on wireless part.
Today, there are various standards available which are suitable for wireless body area network (BAN), IoT and industrial applications. The most prominent ones are Bluetooth Low VOLUME 8, 2020 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ Energy (BLE), IEEE 802. 15.4 and IEEE 802.15.6. In addition to those, there are several proprietary technologies available. The use of BANs offers easy connectivity that can facilitate data sharing, interoperability and basic interaction in various environments, from homes and offices to automobiles, industrial and aerospace environments. However, as processing moves increasingly to the edge, our simple BAN devices will also become smarter and more capable. The capabilities that were once in a desktop may, for example, be found in a handset or even in a watch or wristband device in our current BAN. Interaction with the environment and cooperation between heterogeneous systems will become the norm. Accordingly, we will need BAN solutions capable of efficiently operating in the smart, hyper-connected environments of tomorrow, with embedded intelligence on the one hand, while co-existing with legacy systems on the other. This is the environment of future smart BAN's. It is the environment of increasingly smart personal edge devices in the IoT.
As can be seen, e.g., from [1]- [4], the use of BAN has been proposed for wearables quite a long time. As the wireless technology has become more mature and the miniaturization of components and devices has evolved, we assume that the BAN exploitation will grow fast during the coming years.
In order to realize our ''Smart BAN'' of the future, a number of design and implementation challenges must be addressed; including, the growing need for seamless interoperability with both new and existing radio standards sharing an increasingly crowded spectrum. Further, BAN use cases are expected to increasingly demand secure and privacy preserving solutions, jointly optimized for low power, low latency, robust operations, and the ability to interact with embedded intelligence and heterogeneous environments.
The European Telecommunications Standards Institute's (ETSI) Technical Committee (TC) SmartBAN was approved in March 2013. ETSI TC SmartBAN seeks to help pave the way towards a new generation of BAN's capable of efficiently supporting and operating in smart IoT environments of the future. TC SmartBAN is a vertical technical committee with responsibilities for development and maintenance of ETSI standards, specifications, reports, guides and other deliverables to support the development and implementation of Smart Body Area Network technologies (Wireless BAN, Personal BAN, Personal Networks, etc.) This paper is organized as follows. Chapter II shortly links SmartBAN to the existing technology map. Chapter III introduces the SmartBAN physical (PHY) and medium access control (MAC) layers. Chapter IV describes the SmartBAN interoperability. Chapter V presents examples of SmartBAN performance measures. Chapter VI discusses the open work items and future development plans. Finally, Chapter VII provides a summary and concluding remarks.

II. PRESENT WORK
SmartBAN covers wireless communications, and especially, the associated MAC [9], [10], PHY [11], [12] and network layers. SmartBAN is currently working to improve and tailor the performance of the PHY-MAC support of various popular applications, such as health, sport and leisure [1]. It also takes into account security, quality-of-service (QoS), and the need for easy adjustments for more generic applications and services. The original SmartBAN system and operational environment are described in [6], [7]. The use of a star network is envisioned around a ''smart'' hub, which could be, e.g., a hand-held device or a smart watch. An option for a multi-hop relay and hub-to-hub communications is also considered to improve the usability of the SmartBAN devices in the coming standard revision(s). Compared to its main short-range BAN competitors, such as Bluetooth R or IEEE 802.15.6 Std., SmartBAN provides new MAC layer and PHY layer functionalities, which improve its performance and also provides very low latency emergency messaging with low energy consumption.
Rapid initial setup time and a channel reassignment help to reduce energy consumption and enable faster network deployment. In addition, SmartBAN provides semantic and data analytic enablers, e.g., semantic discovery and reasoning/rules. In the future, such features will be become part of the smart coordinator or hub (e.g., handset, watch or even wristband). A smart coordinator may be viewed as a smart edge device that is capable of controlling and coordinating the operation of our BAN in an efficient and transparent manner. The key functionalities in smart coordinator include, e.g., 1) coordination/interface/ interoperability (in wireless and system levels), 2) security, privacy and trust, 3) interaction/cooperation and 4) edge processing/artificial intelligence (AI). The use of the semantic approach is another important step with respect to interoperability in smart environments that fixes the common data terminology enabling the seamless and vendor independent operation. Automatic node discovery is also supported by SmartBAN. The use of forward error correction (FEC) coding provides added robustness. Additionally, a key feature of SmartBAN today, which differentiates it with respect to its main competitors, is the support for operations across heterogeneous networks with enhanced interoperability and connectivity options. This feature is exploited in all defined data, network and semantic IoT interoperability levels.
Connectivity for portable and wearable devices is not the only thing that SmartBAN can provide for IoT. SmartBAN can be used as our secured personal interface towards the wider digital world; in particular, in the paradigm of the future healthcare system. Our goal is to provide a BAN standard guaranteeing reliable communications, low complexity and low power consumption with open data format. Moreover, the reasoning of the development comes via simpler and more robust implementation than the other existing BAN standards, like BLE and IEEE 802.15.6, are providing.
At the time of writing this article, 22 TC meetings have been held. So far, the group has released five technical specifications (TS) [9], [11], [13]- [15] and two technical reports (TR) [6], [16]. Further, to increase its impact, TC SmartBAN is collaborating with and contributing to, e.g., oneM2M [18] and the ITEA3 CareWare project demonstrator for elderly support at their homes [19]. In parallel, clinical tests in partnership with Office d'Hygiène Sociale based in Nancy, France, are ongoing. Liaisons with International Electrotechnical Commission (IEC) were established in SyC AAL (Active Assisted Living) [33] and TC124 (Wearable electronic devices and technologies) [34]. Additionally, TC SmartBAN has liaisons with IEEE [35] and the Alliance for Internet of Things Innovation (AIOTI) [36].

III. ETSI TC SMARTBAN
This chapter examines the main features of SmartBAN protocols, focusing mainly on PHY and MAC. The ultimate goal of the PHY-MAC activities in TC SmartBAN is to develop a standard for energy efficient, reliable wireless BAN. In addition, high security and secrecy features for endto-end communications chain must be taken into account to protect human's personal vital data.
The core device of the SmartBAN system is a hub, which is controlling all the operations of the whole BAN. We envision SmartBAN as a smart solution in the sense that it merges most of its operations to hub and is utilizing smart coordinator functionalities allowing node implementation to be very simple. This also means lower implementation cost and energy consumption for the nodes. Smartness will also provide heterogeneity management, semantic interoperability and IoT compliance to mention few SmartBAN specific features being available.

A. SMARTBAN PHY
The SmartBAN PHY structure consists of two different types of logical channels operating in the 2.4 GHz unlicensed industrial, scientific and medical (ISM) frequency band; Control Channels (CCH) and Data Channels (DCH). CCH is utilized only for broadcasting CCH beacon (C-Beacon) by the Hub, whereas bidirectional data, and control and management information between the Hub and the nodes are transmitted using the DCH. These two channels can be implemented in one RF chain. The utilized spectrum is divided into 40 channels, each having 2 MHz bandwidth. The 40 center frequencies are equally distributed between 2.402 GHz and 2.480 GHz. Three of these channels are dedicated for CCHs and the other 37 channels are reserved for DCHs. One CCH and one DCH are used within one SmartBAN and are selected by the Hub. In other words, all communications between the nodes and the Hub is carried out using the same DCH. Currently, different DCHs are used by different, i.e., neighbouring Hubs/SmartBANs, for coexistence management. In SmartBAN network, frequency hopping is not supported, which deviates it, e.g., from BLE. [11] SmartBAN utilizes Gaussian frequency shift keying (GFSK) with a modulation index h = 0.5 and a bandwidth-bit period duration BT = 0.5 [4]. To improve transmission reliability, SmartBAN uses FEC coding but also repetition coding. The standard defines mandatory  BCH (36,22,2) coding to protect Physical Layer Convergence Protocol (PLCP) Header. The MAC Protocol Data Unit (MPDU) is encoded using BCH(127,113,2), but in this case, the coding is not obligatory. The coded or uncoded MPDU forms the Physical layer Service Data Unit, and together with the Preamble and the PLCP Header, they form the Physical layer Protocol Data Unit (PPDU), which is the basic entity in the transmission. More details on the frame formats can be found from [9] and are also presented in Fig. 1, which merges the different data units described in [5].
For repetition coding, SmartBAN has three options: no repetition and 2-or 4-times repetitions. In the case of the SmartBAN repetition coding, the whole PPDU block is repeated. This differentiates SmartBAN, e.g., from the IEEE 802.15.6 Std., which uses the more commonly deployed bit-level repetition coding.

B. SMARTBAN MAC
The SmartBAN superframe, called as an inter-beacon interval (IBI), is divided into three channel access periods, as shown in Fig. 2a: scheduled access period (SAP); control and management period (C/M); and inactive period.
For medium access control, SmartBAN provides three different mechanisms. The SAP is dedicated for data traffic only and it is utilizing TDMA (time division multiple access) for contention free channel access. C/M period is essentially introduced for control and management messages between the nodes and the control hub, and it is utilizing slotted ALOHA channel access. In addition, if SAP does not provide sufficient resources for data transmission, C/M period can be used as a reserve. C/M period is available for all the nodes who are willing to transmit data. In Fig. 2a, T s and T D are depicting the durations of the time slot and the inter-beacon interval, respectively. N s and N CM are representing the number of available slots in SAP and C/M period, respectively.
The entire SmartBAN IBI is divided into the slots of equal durations, T s . From connection establishment for data transmission, all types of communications take place into the pre-defined fixed slot size, T slot . The minimum allowed slot length in SmartBAN is T min = 0.625 ms and the maximum limit is 20 ms. Smaller slot sizes are more favourable for low latency applications with smaller payloads while longer slot durations facilitate higher throughput due to the transmission of more payload at once. Table 1 summarizes the payload sizes for different slot sizes and PPDU repetition scenarios in SmartBAN. These payload sizes are computed for uncoded MPDU transmissions and further details about the calculations are given in [7].
A unique channel access solution introduced in the Smart-BAN is the Multi-use Channel Access (MCA), which can be used in SAP, as well as in C/M period. MCA provides very low-latency emergency/high-priority messaging, called as Priority Channel Access. MCA allows also utilization of the scheduled but unused time slots by secondary users. This method is called as Re-use Channel Access and can be utilized when the channel is not used by the primary user. Thus, MCA can significantly increase the channel capacity and decrease the latency. The above-mentioned features are enabled by the unique slot structure introduced for the SmartBAN MAC Std. and are shown in Fig. 2b, where T MUA depicts the total duration of a sensing period in MCA. [9] The MCA slot introduces a sensing period at the beginning of each slot for Clear Channel Assessment (CCA) with two different purposes. When MCA is enabled, all nodes in the SmartBAN shall perform a CCA before transmitting data in their scheduled slot during SAP, or before transmitting a data or control and management information during the C/M period, in order to detect a possible emergency transmission. In addition, nodes having outstanding packet in their queue can access the channel during every time slot in the SAP, i.e., before the slots scheduled for them. In this case, the nodes shall perform two CCAs; one for the possible emergency transmission, and one for the possible slot owner transmission.
For busy channel case, the standard defines a back-off mechanism for transmission reattempt. Inter-frame spaces (IFS) are used to separate data and acknowledgement (ACK) frames, and consecutive slots as seen from Fig. 2b. [9] From the deployment point-of-view, the Hub shall always support MCA, but the support is optional for the nodes. However, if MCA is used though, all the devices connected to that sub-network must support MCA functionality. [9] According to the first released SmartBAN MAC standard [9], every node is connected to a hub via one-hop star network topology. However, the work on an amendment to the MAC Std. is currently ongoing and the coming revision will provide definitions for two-hop relay and hub-to-hub communications still remaining the backward compatibility.

IV. ETSI TC SMARTBAN INTEROPERABILITY
One of the main objectives of ETSI TC SmartBAN is to provide solutions for heterogeneity and interoperability management for BANs. In particular, data/informational interoperability, technical interoperability (i.e., network and syntactic) and semantic interoperability should be guaranteed. The aim is therefore to develop and standardize a SmartBAN-dedicated global framework. This framework is provided with associated enablers/facilitators and application protocol interfaces. There will be a support for interoperability management, which includes cooperation between different SmartBANs and cross-domain use cases. The procedures for secure and unified interaction and access to any BAN data/information/entities are specified. For these purposes, the proposed SmartBAN solution concerns to the following aspects: • The specification, formalization and standardization of an open reference semantic model for BAN data, entities and environment, associated with corresponding unified metadata and reference modular ontology [14]: Measurements and control/monitoring data are included in the proposal. The SmartBAN Reference Model is a key element for BAN's data/information, device and semantic interoperability handling. It will also enable embedded semantic analytics, and thus, ease the implementation of automated monitoring and control strategies.
• The specification and formalization of a SmartBAN service/application layer reference model extension, associated with the corresponding sub-ontology [14]: This SmartBAN reference service model, coupled with a Web of Things (WoT) approach, will in particular enable management of the full semantic interoperability, device discovery, data sharing in application level, and cross domain application handling.
• The specification and validation of generic Multi-Agent based enablers and global IoT reference architecture with technical and semantic interoperability management, and embedded semantic analytics handling [15]: This SmartBAN reference architecture is providing generic service-level enablers for semantic data/information management, as well as distributed monitoring and control operations. The SmartBAN reference data and service models, as well as reference IoT architecture, are described in the following sub-sections in more details. Fig. 3 presents the high-level view of SmartBAN semantic Reference Model and ontology under discussion in [9], [10], i.e., the associated main modelled concepts (objects or classes) with their links (object properties). Within Fig. 3, the following conventions are used:

A. SMARTBAN REFERENCE MODEL
• Concepts, i.e. objects or classes, are denoted by rectangles.
• Sub-class relations are denoted by plain arrows with white triangles (the arrow origin is the sub-class of the class being the arrow destination).
• Relations between objects (concepts) are called object properties and are denoted by dashed arrows labelled by the object properties identifiers. SmartBAN semantic Reference Model was designed by using the modularity principle and the associated SmartBAN ontology and thus it has been modularized in the following fully decoupled modules: • BAN module that models all the concepts related to BANs (blue classes drawn in Fig. 3). A BAN logically contains nodes and has both a predefined communications process (periodic, event driven or on demand) and one or multiple contacts, as depicted in Fig. 3. A contact is a person, i.e. the one that uses the BAN and whose node can be attached to. This person can mainly be a responsible party (legal entity responsible for the BAN) or a patient, etc.
• Node module that models all the concepts related to BAN nodes (orange classes drawn in Fig. 3). A BAN node can mainly be a sensor, an actuator, the BAN hub or the BAN coordinator. This node has an interface and a type, as depicted in Fig. 3 (Interface and NodeType classes).
• Process module that models all the concepts related to measurement/actuation process and measures (green classes depicted in Fig. 3). A process has Action and Data, as depicted in Fig. 3, and finally, a Service module that models all concepts related to services that are offered by the SmartBAN nodes (white classes depicted in Fig. 3). Those modules are less complex to process in an embedded device than the full SmartBAN ontology, thus opening a door for device-embedded semantic data analytics and edge computing. This is also mandatory for local alarm management and caregiver/patient/helper support tools' implementation. Fig. 3 shows that the SmartBAN ontology first introduces unified metadata (i.e., additional information of data, data meaning) for describing the data, which typically are measurements' results provided by different sensor/wearable nodes through dedicated processes for which these nodes are being used. Data mainly has the following properties (see Fig. 3): • Measurements. Measurement has both a format (i.e., the unit of measure, such as beats per minute [bpm] for a heartbeat measurement) and corresponding values (decimal ones) that are directly modelled as data properties of the class Measurements.
• Constraints, such as validity (e.g., minimum and maximum allowable values) or legal (privacy related) ones. SmartBAN unified metadata (green classes depicted in Fig. 3) is mandatory since it provides a unique and unambiguous understanding of a measurement for any processes, applications or end users (e.g., caregivers and helpers). It already allows simple and automated data analytics and alarms' management, like detection of a body temperature or a heart rate fall above/below a predefined threshold, etc. SmartBAN unified metadata is fully aligned with BLE profiles of medical devices that were specified and formalized by Personal Connected Health Alliance (ex-Continua Health Alliance) [16]. Fig. 3 shows that the SmartBAN Reference Model is also extended with additional information, such as which device (BAN node) provides a measurement data (see orange classes depicted in Fig. 3), which BAN contains this device and which use that BAN (see blue classes depicted in Fig. 3), etc. This enables more complex semantic data analytics, like which collocated patients have the same pathology and so on.
As already aforementioned, a WoT strategy was in particular retained for SmartBAN, and the corresponding service model (i.e., upper level ontology) was specified as depicted in Fig. 3 (white classes). This in particular allows full semantic interoperability handling, (medical) device or BAN node discovery and data sharing at application level, as well as cross domain use cases handling (e.g., patient on the move, healthy lifestyles for citizens, emergency situation detection and warning, elderly at home, etc.). Indeed, if one, e.g., view a sensor as a service that is described/represented through a common reference model (white classes in Fig. 3), then whatever a sensor is (a medical, an automotive, a home-or a city-related one), it can always be viewed as a service (crossdomain common concept). As shown in Fig. 3 (white classes), this service: • Presents a service profile that models what the service does and enables its automatic discovery.
• Supports service grounding that models how the service is accessed (i.e., through which communications protocol).
• Is described by a service process that models the way to invoke a service (e.g., input/output modalities). This service process is related to the process for which a BAN node can be used (e.g., a measurement or an actuation, an alarm sending, a patient guideline, etc.)

B. SMARTBAN GLOBAL IoT REFERENCE ARCHITECTURE
The SmartBAN IoT reference architecture has been introduced for providing both system interoperability manage-ment (i.e., being multi-platform enabled) and secure and generic interaction/access to any BAN devices/entities and data/information (including measurements). This reference architecture fully relies on the SmartBAN Reference Model and ontology (see sub-section IVA) for offering a BANdedicated and more integrated global IoT platform with data, device, network and semantic interoperability management and embedded semantic analytics. The SmartBAN IoT Reference Architecture's high-level view is presented in Fig. 4. As shown in Fig. 4, the SmartBAN IoT reference architecture follows the oneM2M specifications [14] and thus it consists of three main layers: Network Layer (also called SmartBAN data provisioning layer), Service Layer (also called IoT Layer and composed of SmartBAN semantic and service sub-Layers), and Application Layer. The Smart-BAN IoT reference architecture is also directly mappable with AIOTI (Alliance for Internet of Things Innovation) IoT High Level Architecture [17] (see Fig. 4). Note that oneM2M entities are not described in this sub-section for redundancy purposes since their full specifications are already available in [14].
As also shown in Fig. 4, the SmartBAN Data Provision Layer (i.e., oneM2M Network Layer) consists of physical entities and things (sensors, actuators, wearables, hub, BAN coordinator, gateway, smartphone, etc.), users (i.e., person, such as caregivers, or patient and helpers) and human-machine interfaces. In other words, this layer covers any person/ device/process delivering raw data and using/controlling BAN-related mechanisms (such as physical entities and systems). Within this layer, interworking agents, called as Data Scanner Agents, are also provided for allowing interworking of non-SmartBAN enabled environment with SmartBAN. Those Agents were mainly designed for device discovery and associated row data real time retrieval/ notification purposes, thus masking heterogeneity of medical devices/data to any process, application or end user (patient, caregiver, etc.). For example, a BLE Data Scanner Agent was specified and integrated since currently most of the existing wireless medical devices being on market are either utilizing BLE or IEEE 802.11 based technology.
The SmartBAN Semantic Data Sub-Layer depicted in Fig. 4 is a part of the SmartBAN IoT layer (i.e., oneM2M Service Layer) that comprises IoT entities (or oneM2M Common Service Element, CSE) mainly providing SmartBAN ontology and semantic information distributed storage and management functionalities (e.g., semantic search/query/annotation, reasoning and semantic analytics, rule handling, eventing, and so on.) Therefore, this sub-layer extends standard BAN systems with the additional embedded intelligence (device/ edge/fog levels) for allowing automated alarm management and control operations (e.g., stroke or fall detection, etc.), as well as advanced decision support (e.g., in caregivers side critical situations detection, measurements similarity detection, etc.) and assisted living (patients side, e.g., patient reminders and warnings). The SmartBAN Service sub-Layer depicted in Fig. 4 is also a part of the SmartBAN IoT layer (i.e., oneM2M Service Layer). It mostly provides generic IoT entities or agents (or oneM2M CSEs) related to service management functionalities, such as service registration, discovery and scheduling. Those agents are directly deriving the strategy adopted for the WoT, and they offer full semantic interoperability handling [9], [10]. The services are semantically described through the SmartBAN ontology service module already introduced in sub-section IVA and specified in [9], [10]. This module provides BAN devices/data (sensors, wearables, actuators, etc.) automatic discovery and sharing, as services and via dedicated agents of the SmartBAN Service sub-Layer (see Fig. 4).
Finally, the SmartBAN application layer depicted in Fig. 4 consists of several IoT application entities. Those entities are implementing SmartBAN application logic, such as monitoring of vital data, evaluation results of certain patient, caregiver decision support or patient notification.

V. SMARTBAN PERFORMANCE EVALUATION
This section elaborates the SmartBAN performance evaluation under two different interference and channel models; one, which is based on the measurement campaigns [12], [13] and the other one using biomechanical mobility for emulating the realistic channel effects.
First, Table 2 gives a high level summary of the different functionalities between SmartBAN and two of its main competitors, namely BLE [24] and IEEE 802.15.6 [8]. The main topological difference comes from the coming support for smart relays, which distinguishes SmartBAN from BLE and IEEE 802.15.6, which are conventional one hub star topology-based networks. However, it should be noted that in IEEE 802.15.6 there is also support for relay functionality and since the Bluetooth version 5.0, there is also support for mesh topology. As the parameter values depend on the overall system settings, we do not provide absolute numbers in Table 2.
As allowing smart channel access, SmartBAN is a perfect solution for emerging messaging. In addition, re-use of the unused timeslots improves the spectral efficiency, as well as reduces the latency in the case of critical communications needs. The biggest deviation comes from the semantic approach, which is used only by the SmartBAN. This functionality makes SmartBAN really smart. The other two technologies do not provide this kind of approach.

A. USING THE INTERFERENCE-BASED CHANNEL MODEL
The comparative analysis between SmartBAN and BLE v4.0 with the measurement-based interference model was studied under the ETSI Specialist Task Force (STF) 511 project.
The STF 511 group developed a simulator using MAT-LAB Simulink environment, implementing both the physical and MAC layers of SmartBAN and BLE. MATLAB multipath fading channel model for indoor environment was used and 2.4 GHz ISM band was considered. Additionally, STF 511 has included into the simulator a block that simulates the interference in an hospital environment. The analytical model of the interference was developed by part of the authors in [12], based on the measurement campaigns in a real modern hospital. In particular, the lowest and highest interference scenarios were implemented into the interference block of the simulator. SmartBAN and BLE were VOLUME 8, 2020 compared in terms of bit error rate (BER) and frame error rate (FER), and varying additional parameters, such as frame size (50, 250, 500), signal-to-interference ratio (SIR = 0, 3,9), repetition rate (PPDU = 1, 2), and retransmission (ReTx = on, off).
The stochastic interference models used in the studies were based on several one-week long measurements carried out in different environments at the Oulu University Hospital, Finland, and at the hospital in Florence, Italy. Within a one week, the samples of the electromagnetic (EM) spectrum were taken every 22 ms using Agilent E4440a spectrum analyser. These experiments gave a good and statistically reliable view on the EM characteristics within the frequency band of interest in those environments. Part of the authors of this paper were also involved in the experiments and data post-processing. References [12] and [13] report the generated models in more details. The overall SmartBAN simulator is detailed in [22].
As a conclusion, it can be summarized that the repetition coding, being either 1 or 2, would be required when operating SmartBAN in a highly interfered environment. In [23], the corresponding performance evaluation of the SmartBAN system is done by considering the interference, as well as the applicable radio channel model taken from literature. Fig. 5 shows the performance comparison in terms of BER as a function of signal-to-noise ratio (E b /N 0 ) between SmartBAN and BLE v4.2. The results have been carried out by the simulator mentioned above. The simulation parameters are the following: frame rate = 50 bytes; SIR = 0, 3, 9 dB; repetition coding with PPDU = 1, 2; retransmission ReTx = OFF. From the reported interference models, low-interference frequency is considered [16]. The simulations consider hospital environment and fading radio channel. As it can be seen, SmartBAN outperforms BLE v4.2 in all studied cases. In particular, when a PPDU = 2 is used, SmartBAN obtains a FER two magnitude orders lower than BLE at E b /N 0 = 7 dB.
Figs. 6 and 7 show the FER performance comparison of SmartBAN and BLE v.4.2 when the retransmission is ON and the interference scenario changes from LOW (Fig. 6) to HIGH (Fig. 7). These results show how much the retransmission capability is able to decrease the FER of SmartBAN, even in high interference scenario. The gain of SmartBAN is about 15 dB over BLE at FER = 10 −1 . Fig. 8 lets us appreciate the impact of increasing the frame size from 50 to 500 bytes. A short frame size seems to be a suitable choice for reduced FER in SmartBAN.

B. USING THE BIOMECHANICAL MOBILITY MODEL
The biomechanical mobility model is based on the CM3B channel model, proposed by IEEE in [4]. However, model integrates the impact of human body shadowing, caused by the mobility, in the pathloss calculations. In biomechanical mobility model, dynamic distances and link types are generated for different on-body links using biomechanical mobility trace files. Dynamic distances and link types, as defined by a specific mobility pattern, like walking, running or sitstand, are taken as inputs for the pathloss calculations. The space-time varying link types identify a particular on-body link as being either line-of-sight (LOS) or non-line-of-sight (NLOS). An additional NLOS component of 13% is added to the resultant pathloss values with time-varying distances for NLOS link status, otherwise the pathloss remains unchanged. After computing the pathloss values, radio link modelling is performed including SNR, BER and packet error rate (PER) computations. Further details about biomechanical mobilitybased channel model can be found from [37].
For evaluating the SmartBAN performance with biomechanical mobility model, a precise athlete monitoring usecase is considered. This is a real-time monitoring application. The performance is evaluated in terms of packet reception rate (PRR), throughput and latency. PRR can be defined as the fraction of packets received and decoded successfully at the Hub. The effective throughput of an individual BAN node can be calculated by N times of the ratio of successfully received packets at the given node-Hub link and duration of the mobility/pathloss trace file, where N is the maximum possible payload size, as given in Table 1. The packet latency is calculated as the time difference between the data packet generation at the MAC layer and its successful reception at Hub. The precise athlete monitoring use-case has one electromyography (EMG) sensor for measuring the electrical activity in muscles and four accelerometers for monitoring the body motion and posture. An EMG requires a data rate of 100 kbps -600 kbps, while data rates required by accelerometers range from 640 bps to 16 kbps, determined by the sampling rate and bit resolution. Therefore, the aggregated data rate requirement for this use-case is 102.6 kbps -664 kbps. For a real-time use-case, the latency should be below 10 ms and PRR is supposed to be above 90% [29]. The IBI is made of a single scheduled access slot per sensor node, and two slots in both C/M and inactive periods. We consider the slot sizes of 0.625 ms, 1.25 ms and 2.5 ms, and an information rate of 1000 kbps. The evaluations are also conducted for single PPDU transmissions with uncoded and BCH coded MPDU, with two and four PPDU repetitions. The transmission power levels are varied from −10 dBm to 0 dBm, while a receiver sensitivity of −92.5 dBm is assumed [29]. Fig. 9 illustrates the PRR performance under the biomechanical mobility-based channel model for the given usecase. Single PPDU transmission, and two and four PPDU repetitions are represented by REP = 1, REP = 2 and REP = 4, respectively. The smallest slot duration of 0.625 ms can achieve the required PRR (above 90%) for the transmission power levels of more than −5 dBm with uncoded MPDU transmission while with BCH coded MPDU, a transmission power level of −7.5 dBm is enough to achieve the required PRR. PPDU repetitions with 0.625 ms slot duration are not possible because the amount of related PHY-MAC overheads to constitute a complete PPDU cannot be transmitted more than once. For 1.25 ms and 2.5 ms slot durations, the transmission power should be −7.5 dBm or above to obtain the required PRR for single PPDU transmission with BCH coded MPDU. The PPDU repetitions for these slot durations improve PRR performance but BCH encoding over MPDU results in a significant improvement, compared to the repetition coding. Overall, the transmission  power levels of −2.5 dBm or above are required in larger slot durations and uncoded MPDU to obtain the required PRR. Larger slot durations, despite carrying more payload with less PHY-MAC overheads, can have decreased PRR because of the increase in the overall packet size [37]. Fig. 10 depicts the aggregated throughput results of all the sensor nodes in the given use-case. It can be observed that the longer slot durations result in higher throughput for the same transmission power level. The increase in throughput with the increase in slot duration can be explained by the phenomenon that the longer slots allow the transmission of more payload with the same PHY-MAC overheads, as compared to the shorter slots in a single transmission. The aggregated throughput decreases for two and four PPDU repetitions because of the duplicate transmissions of the similar payload multiple times for improving the error performance. Overall, single PPDU transmissions with the BCH coded MPDU provide the best throughput results at all transmission powers except at 0 dBm, at which the single PPDU transmission with uncoded MPDU results in the highest throughput. In this usecase, 2.5 ms slot duration with single PPDU transmission and BCH coded MPDU serves as the best option for attaining a high aggregated throughput since it enables the transmission of more payload at once.
The average latency values for the given use-case and the resulting IBI with 0.625 ms, 1.25 ms and 2.5 ms slots durations are observed to be 3.1 ms, 6.3 ms and 12.5 ms, respectively. The latency values increase with the increase in slot durations because larger slot durations have longer IBIs. A detailed analysis about the PRR, throughput and latency characteristics of SmartBAN is provided in [29] for different use-cases. The paper concludes that in low data rate applications, smaller slot durations will give a better performance than the usage of longer slots. On the contrary, better throughput is achieved with longer slot sizes. This study does not consider MCA, which would reduce the attained latency for emergency nodes.

VI. DISSEMINATION AND MOVING AHEAD
A first workshop on SmartBAN, Connected Things for Wellbeing and Health, was kept on Oct 25, 2018 at ETSI headquarters, Sophia-Antipolis, France. At this workshop, SmartBAN technology, including semantic interoperability and Smart-BAN reference IoT/oneM2M platform for remote monitoring and control applications, and the SmartBAN 2.4 GHz PHY were jointly demonstrated. In addition, a dedicated Smart-BAN Workshops were organized in-conjunction with the 9th International Symposium on Medical Information and Communication Technology (ISMICT2015) in Kamakura, Japan on 2015 and with the Bodynets 2018 conference in Oulu, Finland on 2018.
Due to the COVID-19 pandemic, the following planned SmartBAN dissemination activities at 2020 were postponed: SmartBAN Workshop for ETSI Week 2020 with demo and ''Smart Body Area IoT in the era of Beyond 5G/6G'' at URSI GASS 2020, Rome, were both moved to year 2021. However, dissemination of SmartBAN is continuously ongoing process.
Moving Ahead: To increase SmartBAN coverage, revision work for MAC layer specification [5] to support hub-tohub and relaying has started. The results are planned to be published in RTS/SmartBAN-005r1 (TS 103 325) by 2021.
In Q1/2018, a new work item on implant communications was initiated in cooperation with ETSI ERM TG 30. This work is focusing on ultra wideband communications for ultralow power medical devices. The main targeted application is a swallowable wireless capsule endoscope, which is a way to study human's gastro-intestine (GI) track in an userfriendly way. A pill-like device is swallowed, and the endoscope, which contains camera, wireless communications and battery, is providing visual information (image/video) of the GI-track's status. In addition to transferring visual data, the localization of the capsule inside a GI-track is an important feature. SmartBAN is aiming to contribute to this technology development by providing standardized technology reference. The ongoing work is done under DTR/SmartBAN-003 (TR 103 751) thus providing a Technical Report as a first output.
A work item on SmartBAN security, privacy and trust was also initiated in 2018. This work targets the development of computationally light security mechanisms for smart BANs. Due to the sensitive medical information handled by smart BANs, it is necessary to provide for a high security across all  levels of data security and wireless connectivity. This work belongs to DTR/SmartBAN-0010 (TR 103 638). By reviewing first the possible threats SmartBAN can face, it could further protect itself against them.
A joint group between ETSI TC SmartBAN and ETSI TC SmartM2M is collaborating to merge and/or align the SmartBAN ontology with the corresponding Smart Appliances REFerence ontology (SAREF) [31] and oneM2M [32] ontologies. SAREF4EHAW [34] is an extension of SAREF ontology for the eHealth Ageing Well domain for which a minimal core version is being standardized also within ETSI TC SmartM2M. SAREF4EHAW is a priori promised to be one of the most accomplished ontology for the eHealth Ageing Well vertical. However, it is not yet fully standardized and validated, fully aligned and mapped with the aforementioned SmartBAN Reference Model, and not yet complying with all the requirements already listed in [35].
However, collaboration and contribution to [34] and [35] will significantly increase the impact of SmartBAN by extending the utilization of the SmartBAN ontology to various application fields.
Beyond this, we envision SmartBAN solutions to be available in a wider and more general IoT context, as illustrated in Fig. 11. In this environment, SmartBAN could be the standard used jointly with smart, secure environments, providing seamless connectivity between heterogeneous sensors, wireless installations and, more broadly, the cloud, allowing SmartBAN enabled solutions to serve as a secure and trusted interface for future Digital Health. In addition, the recent advances in AI and machine learning (ML) technologies can drive the long-term analysis of health data acquired by SmartBANs far more successful than ever before.
In addition, to be our trusted interface to the digital world, the smart coordinator must maintain the security and privacy of our personal information. To do so, we envision the realization and embedding of an open and modular end-to-end (E2E) security, privacy and trust platform within the smart coordinator (e.g., mobile, watch or wristband). This solution would provide efficient, robust and secure communications in the local domain. Moreover, it provides useful functionalities in outer domain and helps patients/users to maintain high confidence in the security and privacy of their personal data.
The functionalities of the E2E security platform is shown in Fig. 12 within the intersection of our personal cloud and the IoT cloud secure infrastructure. They include, e.g., anonymization, authentication, identity management, secure access control, local analytics, fail safe & alarms and lots of more functionalities. We envision the coordinator in this sense as our personal interface to the healthcare system of the future. Our ''avatar'' is effectively an artificial intelligence. We rely on our trusted smart coordinator to perform anything from low level radio adaptation to high level functionalities related to filtering and processing of personal information and security.
Our smart coordinator (and the other capable edge devices) may processes this data locally and provide us with tailored feedback. The feedback is based on the knowledge of our personal case and the collective wisdom established via AI-based analysis of big data gathered over years from all the persons in the system. It may also perform predictive simulations and projections in reply to ''what if'' questions that we may pose, or which it poses on our behalf, and it supports personalized medicine (e.g., monitoring of dosage and drug combinations). The smart coordinator receives reference data from the system and returns anonymized data to the system, enabling it to continuously refine and update the global database.
The smart coordinator is also capable of interacting with sensors in the environment and cooperating with other AI-based devices. It can also serve as a ''fail safe'' as storing recent personal history and confirming that incoming data and requests are consistent with expectations, which is potentially important in the event of the system corruption (e.g., spoofing or falsification of reference data.) The realization of the smart coordinator of the future requires an unprecedented combination of intelligence embedded in a miniaturized, energy efficient processing platform with trusted and dependable connectivity to the cloud 24/7.
In this way, SmartBAN is ''our edge'' and personal interface to the digital healthcare system of the future and the smart coordinator can be our trusted personal guardian and interface in an increasingly complex digital society.

VII. CONCLUDING REMARKS
In this paper, the work and current status of ETSI TC Smart-BAN towards a global standard for smart body area networks were presented. SmartBAN aims to provide low power, low latency reliable wireless communications strategy especially, but not limited to, health and wellness related data transmission. Utilizing different channel access mechanisms and priority levels, the latency of communications can be substantially reduced compared to the current level. SmartBAN introduces fast channel reassignment and association for new nodes. Semantic ontology and unified data formats improve interoperability and utilization of heterogeneous networks. The technical specifications defining physical and medium access control layers, as well as open data models and semantic ontology are published and ready for implementation. Lot of potential is seen in the utilization of smart coordinator in the near future's personal and wearable IoT and WoT applications. This work has just started.
The future work is also providing SmartBAN recommendations for wireless communications with capsule endoscopy. In addition, TC SmartBAN has recognized the importance of security, privacy and trust in the target operation domain and is developing computationally light mechanisms to support these requirements. She co-invented a patent on the use of RFID for health application. She has been involved in several national and European research projects on satellite communications, tele-medicine systems, wireless systems, and radar signal processing. She has been the Scientific Coordinator of the EU COST Action 252. She has served as an Expert for the European Committee in the area of satellite communications. She has coauthored several international articles. Her current research interest includes wireless communication systems, especially in the topics of 4G/5G systems, resource management, D2D communications, multipleinput multiple-output antenna systems, cooperative communications, and security for wireless sensor networks and IoT. She was a recipient of the IWCMC 2016 Best Paper Award and the Globecom 2016 Best Paper Award. She is currently serving as an Associate Editor for Telecommunication Systems, the IEEE Communications Magazine, and the IEEE INTERNET OF THINGS JOURNAL. PHILIPPE DALLEMAGNE (Member, IEEE) received the Ph.D. degree in computer science from the Université Henri Poincaré of Nancy, France, in 1998. He joined the Swiss Center for Electronics and Microtechnology (CSEM), in 1999. He is an Expert in ultra-low power wireless systems. He is currently managing projects at CSEM in the domains of energy-autonomous wireless sensor networks, real-time communication and smart, edge computing, and complex and collaborative systems. Before joining CSEM, he worked for the IBM Analysis and Design Tools Laboratory, Paris. He was the Leader of the ETSI Project Team 49 for the Videotext Enhanced Man-Machine Interface (VEMMI). He has an extensive experience of the software design and development in the context of wireless technologies for the Internet of things, robust and reconfigurable embedded software, and high-performance realtime communication. He is the author of several articles in international conferences and workshops. He took part in several EU projects in the FP6, FP7, and now H2020 EC programmes. He is also the Swiss Representative and Secretary of the IFIP Technical Committee 5.