The DEWI high-level architecture: Wireless sensor networks in industrial applications

This paper presents the high-level architecture (HLA) of the research project DEWI (dependable embedded wireless infrastructure). The objective of this HLA is to serve as a reference for the development of industrial wireless sensor and actuator networks (WSANs) based on the concept of the DEWI Bubble. The DEWI Bubble is defined here as a high-level abstraction of an industrial WSAN with enhanced interoperability (via standardized interfaces), technology reusability, and cross-domain development. This paper details the design criteria used to define the HLA and the organization of the infrastructure internal and external to the DEWI Bubble. The description includes the different perspectives, models or views of the architecture: the entity model, the layered model, and the functional view model (including an overview of interfaces). The HLA constitutes an extension of the ISO/IEC SNRA (sensor network reference architecture) towards the support of industrial applications. To improve interoperability with existing approaches the DEWI HLA also reuses some features from other standardized technologies and architectures. The HLA will allow networks with different industrial sensor technologies to exchange information between them or with external clients via standard interfaces, thus providing a consolidated access to sensor information of different domains. This is an important aspect for smart city applications, Big Data and internet-of-things (IoT).


I. INTRODUCTION
The number of objects connected to the cloud is expected to rise dramatically in the coming years [1].The Internet-ofthings (IoT) and machine-to-machine (M2M) communications will represent a major portion of traffic in future networks [2].The use of wireless links as the final hop between infrastructure and objects is key in achieving mobility, pervasiveness and flexible deployment.Wireless sensor and actuator networks (WSANs) are thus considered as the one of the main enablers of concepts such as Big Data, cloud computing and smart cities.These new schemes will use large numbers of sensor/tags to collect measurements from the physical world and produce added-value business, control or management information.
Funded by FCT/MEC (Fundac ¸ão para a Ciência e a Tecnologia), ERDF (European Regional Development Fund) under PT2020, CISTER Research Unit (CEC/04234), and by ARTEMIS/0004/2013-JU grant nr.621353 (DEWI, www.dewi-project.eu) The use of wireless technologies in critical industrial applications has been usually linked to risks of reliability and interference.This idea has changed in the past few years.Wireless technologies have been constantly improving, becoming now serious candidates to compete and in some cases replace their wireline counterparts [3].However, there are still several issues to address in the integration of modern wireless technologies into highly critical industrial applications.DEWI (dependable embedded wireless infrastructure) is an ARTEMIS European project focused on the development of dependable WSANs in four industrial domains: automotive, aeronautics, rail and building [4].DEWI is a project based on a set of use-cases that attempt to show the benefits of industrial WSANs by enforcing dependability, reusability, interoperability, and cross-domain development.The core of the DEWI solution is the concept of the DEWI Bubble.A DEWI Bubble is a logical entity operating in a physical space delimited by the range of the wireless transmission technologies employed for intra-Bubble communications.A DEWI Bubble is formed by a group of DEWI Bubble Nodes, DEWI Bubble Gateways and internal users.They are located in short range to each other to ensure a local confinement.The Bubble may be organized in different topologies: distributed (ad-hoc), centralized (with an access point), or hybrid.The DEWI Bubble is therefore a high-level abstraction of an industrial WSAN with enhanced interoperability, standardized access to sensor readings, and cross-domain development.
This paper provides the description of the DEWI High-Level Architecture (HLA).The objective of the DEWI HLA is to boost the use of WSANs in industrial applications.This HLA defines the hierarchical organization of the different devices/modules/entities that constitute the infrastructure internal and external to the DEWI Bubble.This infrastructure organization also implies the description of functionalities, as well as the definition of DEWI Bubble Services, interfacing protocols, and interoperability features.The term high-level is used here to denote a system-level overview of a sensor network.A highlevel architecture is thus useful to provide a coherent structure to a network, improve resource organization, and optimize infrastructure.
In different types of architectures, it is common to use what is called views or perspectives of the architecture.This approach allows designers to look at the architecture from different angles matching the multiple requirements of modern network design and providing an enriched perspective of the system.This paper uses this multi-perspective approach to understand in a better way the different aspects and attributes of the DEWI Bubble and its services.This paper is organized as follows.Section II provides an overview of the DEWI HLA and its main design elements.Section III presents the entity model.Section IV presents the layers of the architecture that are useful for the organization of the Bubble infrastructure.Section V presents the functional model as an extension of the functional model of the ISO/IEC SNRA (sensor network reference architecture) in [5].Finally, Section VII presents the conclusions.

II. OVERVIEW OF THE HLA AND DESIGN ELEMENTS
The design elements of the DEWI HLA are summarized in Fig. 1.The HLA considers the high-level requirements of a set of industrial use-cases from different domains.It also considers technology innovations, standardization, cross-domain development, technology reusability, and interoperability.
The DEWI HLA is key for the cross-domain innovation encapsulated by the DEWI technology items (TIs) .These TIs are specific topics of technology innovation within each industrial domain.Innovations proposed in aeronautics domain can be potentially reused, adapted, improved or cross-optimized in some automotive or rail applications.This cross-domain fertilization also concerns potential synergies, improvements, and eventually with the development of common middleware components that will exploit, manage and transfer data and technological solutions across multiple domains.These ideas are in line with the vision for future networks based on the concepts of the IoT, M2M communications, and Big Data.The DEWI HLA provides flexible, federated and standardized access to sensor readings and technology items of different industrial domains with distinct underlying transmission technologies and data formats.This is one of the main issues in future systems of the IoT.The DEWI HLA also enables the use of actuators controlled by automated applications or by human clients using sensor and context information acquired by DEWI nodes.Therefore, our approach crossovers with the field of M2M communications.External developers will be able to create smart city and Big Data applications using the DEWI application program interfaces (APIs).

HIGH-LEVEL ARCHITECTURE
The DEWI HLA constitutes an extension of the ISO/IEC 29182 SNRA in [5] towards the support of industrial applications.To formally introduce interoperability and technology re-usability, the DEWI HLA has adopted the model driven approach presented in the INTEROP project [6].To achieve high-level interoperability and data exchange over Internet infrastructure, the HLA has considered previous works such as the IoT-A reference architecture [8] , the IoT6 architecture [12] and the Arrowhead framework [7].Regarding the use of actuators and automated control of devices based on sensor readings, the architecture design has also considered the ETSI M2M [9] and one M2M [10] frameworks.DEWI will also consider 5G frameworks such as METIS in [13] for compatibility with future technologies.

III. ENTITY MODEL
The DEWI HLA hosts a set of entities with different roles and functionalities.The following entities constitute the intraand extra-Bubble infrastructure in the HLA.

A. DEWI Bubble Node
Any tag, sensor, and actuator (or combination of some of them as one single node entity) working under the DEWI Bubble framework.DEWI Bubble Nodes implement several of the functions described by the DEWI functional model (see Section V).The nodes may have different radio technologies and may not necessarily lie within the wireless range of each other.A DEWI Bubble Node will host a computer processing unit (CPU), storage unit, one or more sensors, a communication module, potentially actuator(s), and power supply (including batteries and/or energy harvesting modules).

B. DEWI Gateways (DEWI GWs)
In the DEWI HLA there are three types of DEWI Gateways (DEWI GWs): DEWI Bubble Gateway (DEWI BGW), DEWI Relay Gateway (RGW) and the DEWI WSN Gateway (WGW).At any time only one master logical DEWI GW must act as the interface between the DEWI Bubble and the external entities.However, redundant DEWI GWs are allowed to improve dependability in case of failure.DEWI GWs host a central processing unit, a storage unit, multiple communication modules and power supply units.

1) DEWI Bubble Gateway (DEWI BGW):
The entity that acts as the main logical interface of a DEWI Bubble to communicate with other DEWI Bubbles, users (internal and external), and with other external (outer-Bubble) entities.It also provides protocol translation and management functionalities for all the DEWI Nodes and all the WSNs inside the DEWI Bubble.For redundancy purposes, alternative physical GWs can be deployed, but there must be always only one logical master GW acting as interface of the DEWI Bubble. 2

) DEWI Relay Gateway (RGW):
The entity that allows direct Bubble-to-Bubble communication without specific infrastructure.It can also relay the functionalities of a DEWI BGW. 3

) DEWI WSN Gateway (WGW):
The entity in charge of the management and protocol translation of an intra-Bubble WSN.The DEWI WGWs can be a legacy device (e.g., a ZigBee GW).The WGW communicates with the DEWI BGW, which manages all the WSNs inside the Bubble.

D. DEWI Service providers
An entity or set of entities that provide services to third parties based on the aggregation of multiple DEWI Bubbles.DEWI Services can be provided at three levels: 1) Node Services: Provide sensor data and information services for that particular sensor node.
2) Bubble Services: Accessed through the DEWI BGW and provide data and information services related to all nodes in a DEWI Bubble.
3) Federated Bubble Services: Provide data and information services related to multiple DEWI Bubbles over potentially multiple DEWI industrial domains.

A. Overview
Two main features of the DEWI Bubble define the layered structure of the DEWI HLA as shown in Fig. 2: 1) Only one DEWI BGW (master) will act as the main point of interface with the outside world (alternate GWs are allowed but only for redundancy purposes), and 2) A DEWI Bubble will be able to host one or more WSNs, where each WSN can operate with a different technology (including legacy standards).The intra-WSN (intra-Bubble WSN) technology will be called Level 0 or L0.Each WSN contains a set of devices (e.g., actuators or sensors) also known as DEWI Nodes.In case there is more than one WSN per DEWI Bubble, the DEWI Nodes will be controlled by the corresponding WGW.Otherwise, they will be controlled directly by the DEWI BGW.Each WGW will establish communication with the DEWI BGW, which will act as the coordinator of the different WSNs inside a Bubble.Therefore, the DEWI Bubble is effectively defined by the space where DEWI Bubble Services enabled by the master DEWI BGW are available to the following entities: WGWs (if there is any of them inside the Bubble), sensors/actuators (i.e., DEWI Nodes), and internal users.These features place the DEWI Bubble as a high-level abstraction of a WSAN enabled with DEWI Bubble services.
The infrastructure between WGWs and the DEWI BGW will be called Level 1 (L1) or intra-Bubble.DEWI Bubbles will thus have the ability of encapsulating underlying heterogeneous technologies (including legacy standards).This layered model will enable compatibility between manufacturers and technologies.Additionally, layered models have shown effectiveness in terms of scalability, interoperability, and infrastructure design.Level 1 is used to interconnect several WSNs to their corresponding DEWI BGW.The DEWI BGW gets the data of each WSN and exposes this information to the outside world.Level 1 is optional, mainly because in some applications one DEWI Bubble will only contain one WSN.In such case, the DEWI BGW thus acts as the direct coordinator of the DEWI Nodes (using L0).
The DEWI Bubble will always have one logical master DEWI BGW.However, the architecture allows for redundant network devices, thereby supporting safety critical scenarios of industrial applications.In those use cases where wired infrastructure is not available, a DEWI Gateway acting in relay mode (RGW) can be used to provide direct Bubble-to-Bubble communication (ah-doc infrastructure).
Level 2 or L2 is the technology that allows external entities to have access to the information of a DEWI Bubble via a DEWI BGW.This access to the information generated by the DEWI Bubble is achieved through convenient APIs that describe the set of DEWI Bubble services.Level 2 technology provides connection through the Internet and its protocol stack.IoT-based web services have been used for L2 communication.The development a standard technology for accessing Bubble information of different use-cases of different domains is one of the main contributions of DEWI to the state of the art.This management of sensor information and Bubble services will be reflected in the DEWI high level language with the convenient semantics to match the requirements of modern interoperability challenges plus the technology re-usability features for cross-domain application development.

B. Level 0 (intra-WSN)
Level 0 (L0) is the technology used inside each WSN of a DEWI Bubble.L0 technology can be used to interconnect the DEWI Nodes with two different entities: 1) the WGWs (in case the DEWI Bubble contains more than one WSN) or 2) the DEWI BGW (in case a DEWI Bubble only hosts one WSN, i.e.L1 does not exist).Level 0 technology choice is independent in each use-case.Level 0 is the short-range wireless technology used to interconnect, manage and retrieve the information from/to sensors and actuators (DEWI Nodes).The challenge in the design of the DEWI HLA and its appropriate infrastructure is to host such a diverse and heterogeneous landscape of technologies communicating with each other over standardized, open interfaces, and using common data formats.Fig. 3

C. Level 1 (inter-WSN, intra-Bubble)
Level 1 (L1) is the technology used to interconnect all the intra-Bubble WSNs to their corresponding DEWI BGW (in case the DEWI Bubble hosts more than one WSN).L1 is an optional technology.There are two main reasons why L1 is an optional feature in the HLA: • There are some use-cases in which the DEWI Bubble will host only one intra-Bubble WSN.In this case, the DEWI BGW and the WGWs converge in one single entity: L1 disappears and only L0 and L2 technologies are implemented; and • Different use cases have different requirements to interconnect the intra-Bubble WSNs.There are several advantages of using a different L1 technology for different use cases.Some of them are listed below: • It allows network designers to meet domain-specific or use-case-specific design criteria, network where high security and quality of service requirements can be enforced.The decision of using L1 also conveys some additional efforts summarized as follows: • L1 needs an additional RRM layer to organize the different WSNs inside the Bubble.• L1 needs to design gateways and scheduling policies that match the quality of service and dependability requirements between L0 and L1.• The DEWI Bubble becomes a complex set of heterogeneous WSNs and wireline transmission protocols that need special cross-layer optimization algorithms.Level 1 technology must also comply with several of the requirements and attributes of DEWI for intra-Bubble communications.Some of these requirements are the following: • L1 must provide reliable and transparent access to the information of the DEWI Nodes inside each Bubble.• L1 must preserve the dependable, self-configurable and secure data transfer of the DEWI Bubble.• L1 must provide the DEWI Bubble with a framework for the management, resource allocation, configuration, troubleshooting and maintenance of the intra-Bubble WSNs.• L1 must provide conflict resolution or deterministic allocation of the data streams and traffic of all WSNs.• L1 provides an interface for internal users of the DEWI Bubble to access the DEWI Bubble Services.Level 1 in DEWI HLA is closely related to the existing infrastructure (wired) of each industrial use-case.An overview of L1 wired technologies in different industrial domains is shown in Fig. 4. Since L1 must preserve the dependability requirements inside the Bubble, middleware tools with message-oriented and application-oriented approaches are rec-ommended.Service-oriented architecture for L1 provides the HLA with the flexibility to organize resources across different WSNs and model them as available services inside L1.Publish-subscribe middleware technologies fit perfectly the requirements of L1 high quality of service.

D. Level 2 (outer Bubble)
Level 2 (L2) is the layer of the HLA in charge of the communication between DEWI Bubbles or the communication between DEWI Bubbles and external user(s) or agent(s).Level 2 is thus responsible for the interoperability and cross-domain application development.Level 2 is the way a DEWI Bubble will expose its information to the outer world.There are several features unique of Level 2 in comparison with the other two Levels of the HLA: • L2 will use Internet-based (IoT) protocols to enable external users with access to the set of DEWI Bubble services from anywhere in L2. • L2 will be also responsible to provide federated access to a set of different DEWI Bubbles • L2 must support interoperability, cross-domain application development and technology re-usability.• L2 must enforce security and protection to the data and operation of the DEWI Bubble against external malicious attacks • L2 must use international standards to enable interoperability with other external systems.In order to achieve these goals, L2 has adopted a service oriented architecture (SOA) with a middleware paradigm based on request-response.This paradigm is inherently nonreal time.Therefore, L2 is envisioned as a layer where external users will request access to a summarized version or non-real time information generated by the DEWI Bubbles.The DEWI functional model includes specific L2 services.
The solution to realize the concept of technology reusability and cross-domain application development is the use of a profile repository.This repository will store configuration details, technology items and other cross-domain parameters.DEWI Bubbles will have access to this repository where they will retrieve technology solutions developed across different use cases.These technology solutions will be reused, optimized, and modified across different DEWI Bubbles.The DEWI high level language will reflect the interoperability and technology reuse attributes of the DEWI HLA.This language will be able to host the DEWI high level functionalities.This high level language will also rely on an API that will use the middleware services of a SOA.This SOA reuses aspects of existing approaches such as the Arrowhead project [7].
The DEWI Bubble represents a hybrid solution by combining three main aspects: 1) it extends the ISO/IEC SNRA to be fit for industrial applications of WSNs via the two first levels of three-tier model, 2) it enables compatibility with existing and potentially real-time infrastructure via L1, and 3) it uses modern M2M and IoT tools for cross-domain interoperability and technology reusability via L2.

V. FUNCTIONAL MODEL A. Overview
The DEWI HLA functional decomposition model is an extension of the functional model of the ISO/IEC SNRA in [5].The benefit of this functional decomposition is the simplification of system analysis by breaking global tasks into basic functionalities easier to manage and easier to insert into global system design.Following the ISO SNRA standard, the DEWI functional components are organized into four layers plus one cross-layer and cross-domain management.These layers are displayed in protocol stack view in Fig. 5.

B. DEWI node hardware layer (DNHL/SNHL)
The DEWI Node Hardware Layer (DNHL) or Sensor Node Hardware Layer (SNHL) encapsulates the low-level device functionalities that are common to all DEWI nodes.These functions are: sensing, actuation, and energy harvesting.Therefore, the DEWI NHL is in charge of the interface between the virtual world of computing and the physical world of objects, via measurements of physical phenomena.Sensors are used to measure physical quantities.Actuators are used to change a physical quantity in response to a signal or command.Energy harvesting is used to obtain energy from the surroundings of the DEWI Node and extend battery life.

C. Basic function layer (BFL)
The Basic Function Layer (BFL) contains the basic functionalities to transport, process and store the data generated by the SNHL.Physical entities may also make use of an operating system that is able to manage the computational resources and provide a simple language for applications to have access to such resources.BFL functionalities include: Operating system (OS), data communication, data storage, data processing, sensor/actuator/device identification, and device drivers management.

D. Service layer (SL)
The service layer (SL) is in charge of providing upper layers with the application programme interfaces that encapsulate all the lower functionalities of a sensor network.The SL acts as an interface between the application and the basic functions and it helps to speed up the development and deployment of applications.The DEWI SL includes services specific of each domain, in particular services related to the technology items.
1) DEWI Core and technology item services: The DEWI Bubble L2 will use a service oriented architecture (see Fig. 6) with particular services that will be called here Core services.These services depend on the architecture and middleware approach to be used.The DEWI TI services aim to enable the update, retrieve and uploading of technology innovations developed in each use case.The profile repository will store details of the technology items and will communicate with different DEWI Bubbles to proceed with TIs operations.

E. Application layer (AL)
The AL uses the services provided by the lower layers, but it is completely insulated from the details of the network hardware.It describes how applications interact with the network operating system.This interface is commonly known as an API.Common application components are the software agent, the rules engine and collaborative information processing.An agent is a piece of code that runs continuously.It can run tasks by itself, react to events on the Bubble and communicate with other agents.A rules engine is a software system whose behaviour is determined by a set of high-level business rules.Business rules can be inference rules, very much like an ifthen statement that is called manually, or reaction rules that executes a program when an event is detected.

F. Cross-layer and cross-domain management (CLM/CDM)
Layered design has been the staple in the evolution of modern telecommunication networks.However, the layered model started to show some shortcomings, particularly in wireless networks where layers are tightly connected to each other.Wireless network should be designed by using crosslayer concepts, where parameters and issues across different layers must be addressed or optimized simultaneously.In the DEWI HLA, the layers of the functional model will be able to exchange information and allow cross-layer design and optimization.A key concept in the DEWI HLA is crossdomain application development.So, in addition to the crosslayer management, cross-domain allocation will be also incorporated.Typical cross-domain use cases include supply chain applications where goods are transported by trucks, planes and trains, while stored in warehouses and offices.This covers different industrial domains.CLM/CDM functionalities include device management, resource management, QoS management and security management.

VI. INTERFACES
This section defines the interfaces between the modules and components of a DEWI HLA.An interface is the boundary shared by two modules that allows the communication between them.When the modules are physical entities, then the interface will be a hardware (HW) interface.When the modules are Functions/Services then the interface will be a software (SW) interface.

A. HW Interfaces (between entities)
HW Interfaces establish how to exchange messages between physical entities.The interface should define the physical support for the exchange, the structure of messages that can be received or transmitted, and the logic that controls the exchange of the messages.

1) Interface DEWI node-WSN GW:
The DEWI Node -DEWI WGWs interface is used to transmit messages containing data from the nodes and sensor network management messages to and from the DEWI WGW.The protocols defined in this interface depend on the application requirements and on the WSAN architecture chosen to build up the network.The data information transmission from the nodes to the DEWI WGW might be done periodically, triggered by events, or on request by the DEWI WGW.The following definitions are required in this interface: AL, SL, and BFL protocols.
2) Interface DEWI WSN GW-DEWI BGW: This interface is used to relay the data gathered by the sensor nodes to a higher-level entity.The granularity of the data and control information will depend on the needs of each application service provided by the DEWI Bubble and the level of control over individual DEWI Nodes and the DEWI Bubble required by users from outside of the WSN.Some applications may need information from individual Nodes, e.g. to know the temperature of particular sensor located in a certain place in the vehicle, while it would be enough for other applications with the average temperature measured by all the nodes in the Bubble.If the DEWI WGW and the DEWI Gateway are not the same physical entity, the interface should be implemented through a Level 1 network.The following definitions are required in this interface: AL, SL and BFL protocols (this last oned needed only if the DEWI WGW and the DEWI Gateway are separate physical entities).
3) Interface DEWI BGW -external users/services: The interface DEWI BGW -External Users/Services is used to offer the data collected in the DEWI Bubble as services to multiple users (other DEWI Gateways or final users).This interface also allows the management and configuration of the DEWI Bubbles.The communication is done using a Level 2 network that connects the DEWI BGWs to the Internet or to other DEWI BGWs directly.This interface should comply at least with the defined DEWI Core Services to establish a common mechanism to access the services provided by different DEWI Bubbles.The following definitions are required in this interface: AL and SL protocols.

B. SW interfaces (between functions)
SW Interfaces define how to communicate with adjacent layers.Usually upper layers access resources provided by the lower layers and exchange control commands with layers in the same level through a Service Access Point (SAP).Each interface can be divided into two SAPs: the data SAP and the management SAP.
1) Interface SNHL -BFL: The SNHL -BFL interface connects the BFL with the node hardware and enables it to use the infrastructure provided by the SNHL, i.e. processor, memory, communication devices, power supply, sensors, and actuators.This interface defines: • Mechanical, electrical, logical and management signals that allows accessing and managing the node hardware.• The method to access hardware metadata.
• Interface standards based on sensor types or connection types.
2) Interface BFL -SL: The BFL -SL interface is a logical interface that enables the SL to access the functionality of the BFL.This interface defines: • The data type and format of operations in the BFL, i.e. description of the functions performed, information generated, and structure of the transmitted data.• Message format and exchange mechanism between the BFL and SL according to the requirements of the SL.

3) Interface SL -AL:
The SL -AL interface is a logical interface that enables the target application to access the functionality provided by the SL.This interface defines: • The data type and format of services in the SL, i.e. service type, service state information, and service management information.• Message format and message exchange mechanism between the SL and AL according to the requirements of the AL.• A service API to use as construction blocks for the target application.4) Interfaces with CLM/CDM: The BFL, SL and AL provide management functionality to the CLM/CDM module.There are different logical interfaces with the CLM/CDM, one for each layer.These interfaces define: Message format and message exchange mechanism between each layer and the CLDM/CDM, VII.CONCLUSIONS This paper has presented a summary of the definition of the DEWI High-Level Architecture (HLA).The HLA aims to act as a reference framework for the design of wireless sensor and actuator industrial networks compliant with the concept of the DEWI Bubble.It offers a robust and interoperable framework to develop industrial wireless solutions for monitoring and actuation.The DEWI HLA offers the versatility to be adapted to any kind of application/scenario requirements, and is agnostic to the underlying WSN technologies, becoming a powerful architecture for long-term industrial solutions.One of the main aspects achieved in this paper is the formalization of the entity model, the layered model, and the functional decomposition of the DEWI HLA, which is an extension of the ISO/IEC SNRA for industrial applications.
C. DEWI Users (internal and external) The entities that can access and use the set of DEWI Bubble services provided by the DEWI BGWs or RGWs.Internal users are meant to be inside the DEWI Bubble accessing the DEWI BGW via the intra-Bubble communication infrastructure.The external users access the DEWI Bubble services through the outer-Bubble communication framework.This access is mainly via Internet and over open standard middleware application program interfaces (APIs).

Fig. 3 .
Fig. 3. Data rate vs. range comparison for different wireless commercial standards L0 HLA.

Fig. 5 .
Fig. 5. Protocol stack view of functional model of the DEWI/ISO HLA.

•
It also improves scalability in the HLA, mainly because several WSNs can be hosted by one single DEWI BGW.Thus, the number of DEWI Nodes hosted per DEWI BGW increases according to the supported WSNs hosted by L1 technology.• It provides a useful organization of resources in dense WSAN deployments.• It allows for an efficient resource allocation by centralizing all the WSN management in one single location (logical): the DEWI BGW.This means, for example, that adjacent WSANs can be allocated in different channels by the DEWI BGW, thereby reducing interference inside the same DEWI Bubble (intra-Bubble interference).• The existence of L1 technology facilitates the integration of wireless DEWI Bubble solutions with the existing wired technologies of each domain, which is a unique aspect of DEWI.This aspect also improves the technology re-usability features of the HLA, mainly because some wireline technologies share common aspects across different industrial domains, • L1 can provide wired/wireless infrastructure for internal users to obtain access to DEWI Bubble services, and • L1 allows network designers to create a private internal