A Suite of Design Quality Metrics for Internet of Things by Modelling Its Ecosystem as a Schema Graph

Internet of ings (IoT) infrastructure connects consumer electronics, household appliances, and other smart gadgets. For designing IoT systems and applications, dierent architectures and protocols are being used. e design quality of an IoT system and its services is assessed with quality of service (QoS) factors such as complexity, functional appropriateness, performance, eciency, compatibility, maintainability, portability, and usability. e existing methods in the literature focus on measuring the quality of an IoT system during execution time; however, there is a need to dene some standards that may be used to determine the quality of an IoTsystem from its design.is workmodels the IoT EcoSystem as a schema graph and presents a suite of metrics to determine the design quality of an IoTsystem and its services under the dened QoS factors. e presented metrics are mapped to the ISO-9126 QoS factors to ensure the standards and quality of IoTservices during the design phase. e proposed metrics are validated with benchmarking on a case study smart healthcare IoT system. e results proved that the presented metrics are practical to quantify the quality of IoT design models under QoS factors, and the suite of metrics is able to compare dierently designed IoT services.


Introduction
For computing applications, design decisions have a substantial impact on the nal product's quality [1]. e Internet of things (IoT) domain has distinct design requirements because of the existence of many communication protocols, terminologies, and architectures and involves factors like heterogeneity, diverse application domains, varied functionalities, and components [2]. During the design process of an IoT application or system, quality criteria and related measurements must be observed. Determining the quality of IoT applications and services is considerably di erent from conventional software systems [3]. Various IoT architectures in the literature lead to challenges when designing IoT systems and applications. e resource-constrained IoT devices, being arrayed in vastly dynamic settings and union of a range of technologies, cause conventional design standards and models to be insu cient to measure the quality of service (QoS) in IoT applications [3][4][5][6].
Graph-based metrics are an important tool to quantify software design models' quality.
e IoT EcoSystem is a design model that interconnects the heterogeneous smart devices in a broad network of distinct components to operate e ciently [7].
e IoT EcoSystem interoperates web-enabled smart devices to collect, retrieve, send, and act on data from their surroundings by using the embedded system processors, sensors, and communication hardware [8,9]. e scope of this work is to model the IoT EcoSystem as a schema graph to de ne the quality measurement metrics for the IoT domain such that the service quality of an IoT system or application may be evaluated from its design model. A research matrix for the analysis of existing related research works is given in Table 1. It summarizes the current works on the base of (i) the IoT research area covered by the given works, (ii) the quality factors suggested for IoT applications, and (iii) whether the authors cover the design phase metrics. e research matrix shows that very few works have focused on defining and evaluating the quality of IoT services at the design phase through metrics. However, most works elaborate on the quality factors to standardize the IoT architectures and models. e literature survey categorized the related works into four levels based on the qualitative and quantitative measurements criteria presented in specific research work. At the top, the services inside an IoT infrastructure are divided into information aggregation services, identityrelated services, ubiquitous services, and collaborativeaware services [2]. e IoT services are usually composable and reconfigurable, leading to a dynamic environment requiring explicit support at different levels to ensure high quality for its users [15]. At the second level, Tambotoh et al. [14] identified the IoT characteristics as heterogeneity, resource-constrained devices, collaboration with hardware and resources, network mobility, embedded and adaptive devices, and design to monitoring IoT devices. At the next level, QoS factors for IoT systems and services are presented [3,4,6,17,22] based on ISO-9126 model [23]. It includes complexity, functional suitability, performance, efficiency, compatibility, maintainability, portability, and usability. At the fourth level, there are some quality analysis related works, including a 3-layer IoT architecture for QoS [10], a design and analysis process [5], and a software quality model [14].
It is evident from the data in Table 1 that the existing research focused on identifying the quality factors for IoT, whereas literature lacks quantitative metrics for design quality evaluation of IoT models and services. Existing research has mapped different features of IoT to the QoS parameters; however, there is a lack of design quality measuring metrics required for estimating the services quality of IoT systems at an early stage. is research aims to propose a suite of design quality metrics to ensure service quality in the IoT. More specifically, we have asked the following research questions: (a) What are the potential relationships between IoT service categories and identified IoT characteristics; (b) What are the QoS factors that affect the QoS in a heterogeneous IoT infrastructure; (c) How to define design metrics for IoT applications, needed to ensure the quality of services; (d) What are the possible metrics mappings to the IoT quality characteristics and services; (e) How should the presented design quality metrics be evaluated; (f ) What is the advantage of evaluating an IoT system under presented design quality metrics. is research modeled the IoT Ecosystem as a schema graph and defined a suite of design metrics to ensure the quality of IoT services. e newly defined metrics for IoT design quality assessments are IoT transactional complexity, IoT design complexity, IoT transactional network load, IoT interoperability resolving network complexity, IoT interoperability resolving network load, and IoTreusability factor. As given in Table 1, this work presented and evaluated the design quality metrics and mapped them to the QoS parameters. In a summarized form, we make the following contributions to the domain of IoT for design quality evaluation: e rest of this article is organized as follows. e next section is dedicated to the literature review. Section 3 defines the Internet of ings EcoSystem as an abstract graph and introduces its schema representation. e design quality metrics for the quality services in the Internet of things are proposed in section 4. e evaluation and results are given in section 5. Finally, section 6 concludes the article.

Literature Review
is section reviewed existing works related to IoT architecture(s), models, and those covering parameters and attributes for QoS in IoT. For IoT architecture, De et al. [24] proposed a dynamic creation of services and their testing in the IoT-A reference architecture-based IoTenvironment. e presented architecture is semantic oriented and test-driven and provides self-managing and testing for IoT services and creates dynamic test cases generation and execution. Yaqoob et al. [25] presented a three-layered IoT architecture with layers including application, transport, and network. ey summarized various IoT architectures, including peer-topeer, software-defined architecture, and network-based and Cloud ings architecture. ese architectures aim to provide QoS in heterogeneous wireless network environments and accelerate the software development process.
Li et al. [10] recognized that the varied and huge amount of devices in the IoT infrastructure makes it tough to fulfill QoS requirements. e services in IoT are reconfigurable and provide quality-aware scheduling of the service-oriented IoT architectures that increase the performance and minimize the cost. Al-Fuqaha et al. [11] highlighted the key IoT challenges and QoS criteria in terms of reliability, performance management, mobility, availability, scalability, privacy, security, interoperability, confidentiality, fault tolerance, safety, resource management, operations management, architecture standardization, protocols, and network addressing and identification.
Kiruthika and Khaddaj [12] highlighted the lack of standardization in IoT paradigm attributes like self-healing hardware, functional and nonfunctional requirement, and heterogeneous mix of devices as challenges for defining the QoS model for IoT. e identified QoS factors for IoT applications are security, performance, usability, reliability, interoperability, robustness, and scalability.
e QoS features vary according to the dynamic environment. Kim [13] described that the IoT applications are a complex mixture of a variety of heterogeneous devices and technologies. ey derive a practical model based on the qualities of IoT applications. e QoS factors are identified as functionality, reliability, efficiency, and portability. e metrics for these QoS factors can evaluate the quality of IoT applications.
Costa et al. [5] highlighted two major design issues of the IoT. One is the representation of complex heterogeneous entities. e other is the unavailability of the method to verify the QoS in the early design phase due to resourceconstrained devices deployed in a highly dynamic and unreliable environment. Performance, reliability, and availability are the features to be considered. Tambotoh et al. [14] presented an IoT software quality model that is established on ISO/IEC 25010 and information quality characteristics of COBIT 4.1.
e updated version of the ISO/IEC 9126 model is defined that determines the requirements of software product quality and evaluates them. Quality assurance is considered necessary for the security and safety of the system and users in IoT. e model evaluates the internal and external properties, and includes eight quality factors, namely, functional suitability, reliability compatibility, security, usability maintainability, performance efficiency, and portability. omas and Rad [22] described that the essential quality metrics to analyze and evaluate for measuring performance in the IoT system are availability, usability, reliability, and maintainability, as mentioned. White et al. [4] used ISO/IEC 25010 and OASIS WSQM as quality models for mapping of QoS factors. e quality factors for QoS evaluation were considered based on the ISO/IEC 25010 quality model. e reliability, efficiency, functional stability, and performance are the most considered/studied quality factors; however, many factors like maintainability, security, and compatibility that are critical for the proper working of the IoT applications and systems have been neglected. Moreover, it was identified that the most addressed layers are the network layer and physical layer, whereas deployment, middleware, and cloud layers lack primary studies.

Mathematical Problems in Engineering
Because communication, computing, and things are the three pillars of IoT, Singh and Baranwal [16] classified QoS components into QoS of communication, QoS of things, and QoS computing. Weight, interoperability, flexibility, reliability, availability, overall accuracy, stability, response time, range, sensitivity, precision security, and other communication quality factors include bandwidth, throughput, efficiency, network connection time, monetary cost, availability, security and privacy, interoperability, service level agreement, monitoring, and reliability. Communication quality factors include weight, interoperability, flexibility, reliability, availability, overall accuracy, stability, response time, range, sensitivity, and precision security. Scalability, dynamic availability, dependability, pricing, response time, security and privacy, capacity, customer support facility, user feedback, and review are all aspects of computing QoS.
Zhohov [26] proposed a quality of experience (QoE) model for dealing with the Industrial IoT application and services. e current models for evaluating the QoE are not suitable for IIOT applications as they mainly target multimedia services. Industry-related KPIs are defined to deliver the QoE for IIoT by associating the technology and business domains. ey proposed QoE layered model which forecasts efficiency, productivity, safety, and reliability as Industrial KPIs for QoS. Network performance evaluation is more complicated as each IIoT has specific QoS assurances than conventional systems. Bures et al. [17] discussed various issues and challenges faced in ensuring the QoS in the IoT environment. Many issues in quality assurance have arisen as a result of the IoT's development, including privacy and security of user information and data. Reliability, interoperability, and integration issues created a need to develop a methodology to ensure quality assurance in IoT. Systematical testing and quality assurance methods need improvement.
Zavala et al. [18] proposed an autonomic IoT infrastructure for transiting from partial-autonomic characteristics of IoT applications to complete autonomically. e inclusion of the architectural and functional blocks introduces the self-star properties. Self-configuration, selfadaptability, self-healing, self-optimization, and self-protection deal with the challenges of a dynamic, heterogeneous mix of devices, human-computer interaction, interoperability of communication protocols, scalability, and ubiquity.
Suryanegara et al. [19] established a framework for assessing IoT service QoE. e Absolute Category Rating with Hidden Reference (ACR-HR) scale served as the foundation for the framework. It assesses the quality based on the rating given by users based on their experiences. Users provide the score both before and after the implementation of the system. e user experience was evaluated via conduction of survey which is based on mean opinion score (MoS) and calculation of results is done using differential MoS based on ACR-HR. Samann et al. [21] reviewed the available techniques for QoS in IoT academia applications. Metrics considered for provisioning QoS using cloud computing in academia are latency, reliability, throughput, and network usage. However, it is not a unified process for providing all these factors. e literature review has shown that the heterogeneity and variety of application domains for IoT have resulted in varied specifications leading to a complex IoT system with different performances. Due to this reason, the design and architecture of IoT are affected and are not standardized, thus resulting in the different architectures [27]. Due to many application domains and heterogeneous entities communicating with one another using varied protocols, there are many standards for IoT architecture that leads to the challenges in designing the IoTapplications. e resource-constrained diverse mobiles and other devices resulted in the QoS concern [28]. e QoS in an IoT application is constrained by heterogeneity, resourceconstrained devices, collaboration with hardware, natural human interfaces, networked mobility and volatile connectivity, embedded and adaptive devices, and design to monitor IoT devices [14]. It is necessary to specify the quality characteristics of IoT applications and evaluate them to determine whether or not they are according to the design standards.

Internet of Things EcoSystem as Abstract Graph
is work is based on the IoT EcoSystem concept of Bansal and Kumar [7] that puts all the heterogeneous components of IoT together to build an efficient system. For defining measurement criteria in terms of design quality metrics for the said attributes, we define the IoT EcoSystem as an abstract graph. e IoT EcoSystem concept presented by Bansal and Kumar [7] is converted into an interaction graph 'G' as given in Figure 1. e sensors and actuator devices work at the base layer of the IoT EcoSystem. e sensor devices collect information about environmental/physical parameters and pass the data to a gateway node (working at the upper layer). e actuator devices take instructions from the gateway and act on the linked entities/ parameters/environmental attributes. e gateway manages the data flow between sensors/actuators devices. e sensors and actuators use different communication protocols to interact with the gateway. Hundreds to thousands of sensors and actuators can be managed via the gateway that filters and formats the data coming from/to sensors/actuators. Above the gateway layer, a controller interacts with the middleware. e controller controls data coming to gateways from the middleware or IoT platform. e controller is responsible for the high-level processing of data. It classifies, computes, and converts data into information. A controller can manage hundreds of gateways. e IoT middleware does various activities like data analysis, saving data into the database server, preparing reports and graphs, and ensuring privacy and security. It manages and controls the IoTsystem. e cloud supports the data available in the IoT middleware. All applications avail the services and the analytical statistics delivered by the middleware through the application programming interface (API). e application provides the user view of the IoT environment.

Schema Representation of Internet of ings EcoSystem.
For IoT EcoSystem's schema representation based on the abstract graph (Figure 1), we define the following terms for each layer of IoT EcoSystem: (i) D n : LowEnd Device G p : Gateway Devices C q : Controller Devices P r : IoT-Platform/Middleware U t : User/Doctor Gadgets e integer numbers p, q, r, t, and n denote the number of devices at the associated level of IoT EcoSystem.
To define measurements related to the design quality of the IoT services, the interaction graph 'G' in ( Figure 1) is formally represented in terms of its vertices V(G), given in the terms u, v, w, x, y are integers to de note index-number of Low End Devices, Gateway Devices, Controller, IoT-Platform, and User Devices, respectively.
Here, an important thing to note is that more than one edge may originate from a vertex, i.e., IoT modules of the graph. So, the bidirectional edges inside the ADT Graph denote the under-given interactions between different vertices and are represented with the symbols mentioned against each edge.
User Device (D n )↔ Edge/Fog/Cloud ---δ i y y e edges' subscript integers v, w, x, and y are denoting the originating vertex number for α, β, c, and δ edges, respectively, whereas the superscript integers i v , i w , i x , and i y are denoting the edge number originating from vertices G p , C q , P r , U t , and D n , respectively (as a counter of multiple edges from a node). e edges are iterated in following fashion (example iterations are given for α :: :: ese edge weights are measured in terms of the amount of data (in bytes) exchanged during a single interaction activation.

Design Quality Metrics for Quality Services in the Internet of Things
IoT applications generate a set of read-write operations representing a certain service in a transactional manner [29].
is work considers such operations as IoT Transactional Activities, where an IoT Transaction is a set of ordered pairs of request and response-based communications among IoT entities/modules. So, interactions among different components of an IoT EcoSystem are involved in a transaction. In terms of interaction edges emanating from distinct vertices of the schema graph, an IoT transaction (T r ) is described as follows:

IoT Transactional Complexity Metric (ITCM).
We define the complexity of an IoT transaction as the number of its constituting interactions that originates from various vertices (modules of the IoT system, including IoT devices and network nodes). IoT transactional complexity metric (ITCM), defined in (3), counts the number of interactions involved in the transaction by taking the edge weight for each of the interactions as a unit value.
ITCM metric is used to measure the complexity of an IoT transaction. For determining the Total Transactional Complexity of an IoT system, the metric defined in (4) simply adds the complexity of each transaction available in an IoT system.
e average transactional complexity is then measured by A rise in the value of these measures indicates an increase in complexity, which impacts understandability and maintainability. e average transactional complexity scale is based on the works [30,31] on software complexity. e following are the ranges on the average transactional Complexity scale: Low( < 5), Medium(5 to 10), High( > 10).
In general, the longer an IoT transaction is, the longer it takes to complete it via the network. As a result, latency will be noticed. Each additional interaction wastes time and causes delays. By integrating numerous unnecessary encounters into a single interaction, the Transactional Complexity score can be decreased. e measurements assist in selecting a better alternative for an IoT transaction among the many accessible options.

IoT Design Complexity Metric (IDCM).
On the base of interactions among different components of an IoT Eco-System, we define the IoT Design Complexity Metric given as follows: Here, the edge weight value for each interaction is taken as a unit value. e average design complexity for an IoT system is then determined as given in Average DesignComplexity � Total numberof Interactions Total numberof Devices .
is metric determines how complex the IoT system will be, with an increasing number of IoT devices and their interactions. e complexity scale defined for the transactional complexity metric applies here as well.

IoT Transactional Network Load (ITNL).
An IoT transaction involves interactions among different components of an IoT EcoSystem involved in a transaction. IoT transactional network load (ITNL) is proportional to the complexity of an IoT transaction, determined by (7) by taking the edge weight for each interaction as a unit value. e ITNL value for an IoT transaction is determined with (3) by taking the actual edge weight values. e transaction's edge weights add to calculate the ITNL metric, given as For determining the total transactional network load of an IoT system, the metric defined in (10) simply adds the network load of each transaction happening in an IoT system.

Total Transactional Network Load
An average Transactional Network Load is determined by the following formula: More value of the transactional network load for an IoT service means overburdening the IoT network and may choke the system. Transactional network load value may be reduced by reducing the data size in request and response if possible. e metrics help choose a better IoT transaction from the available option, which brings the least data burden for the IoT network. e ITNL value at each hope must be within the available bandwidth.

IoT Communication Channel Demand (ICCD).
IoT communication channel demand for a network hop is the byte size of data traveled between its nodes. e communication channel demand is the sum of data weights of all edges activated for an IoT transaction. However, all transactions need to be considered to determine the channel demand for each hope of the IoT system. If multiple transaction activities occur simultaneously through one hop, the channel demand depends upon the transaction with the largest data size (weight) for that edge. e IoT communication channel demand (ICCD) of an IoT design model can be determined from the schema design presented in Figure 1. It is identifiable as the maximum interaction weight between any two graph vertices (i.e., IoT modules). For determining the communication channel demand (CCD) among the low-end devices and the gateway devices, the edge weights α i v v are to be considered. e metric in equation (11) chooses maximum interaction weight value for α where, β iw w represents the packet the packet size being sent to or recieved from the upper layer and the second paramaters is the (Request/Response) packet size of the low end devices (sensor/actuator).
e communication channel demand among the gateway devices and the controller devices (β i w w ) is determined by the weights of the upper and lower links. It is measured as the maximum interaction weight value from the accumulated interaction weights α To find the communication channel demand among the controller devices and the middleware devices (c i x x ), the maximum interaction weight value from the interaction weights β i w w and the maximum interaction weight value from the interaction weights δ i y y are to be selected. e metric is defined in e metric defined in (15) finds the communication channel demand among the platform and the user devices, i.e., δ i y y . From the interaction weights, the metric selects the maximum interaction weight value c i x x (as response size) and request packet size is equal to request/response packet length of the user end device.
Finally, the ICCD metric selects the maximum interaction weight value from four sets of interaction weights (i.e., α x , and δ i y y ). e maximum interaction weight value amongst these interaction weights gives the maximum data size that may transfer over an interaction. Its value can be determined by the metric defined in the following equation: In both local and distributed IoT systems, ICCD calculations aid in determining the required bandwidth. A higher ICCD value indicates a higher cost of bandwidth acquisition. is statistic aids in determining whether or not we can pay the costs of a projected IoT system and whether or not its development is realistic. e ICCD calculation can also be used to discover any additional data being sent over the expensive lines and, if possible, minimize it. ICCD calculation also can be used to identify any extra information being sent over the costly links and can be reduced if possible. Miscalculations about the communication channel demand or guessing its demand without proper measurements may affect the efficiency of the IoT system (if a guess is lower than the required demands) or results in extra payments (if the guess is too above the required demands).

IoT Interoperability Resolving Network Complexity (IIRNC) and Interoperability Resolving Network Load (IIRNL).
For interoperability of heterogeneous IoT devices, translation of data from the source device into the sink device format is performed either at the source, the sink, or some middleware device (being at the edge, fog, or cloud levels) [20]. Other interoperability operations may require protocol translation, or semantic translations, that are performed either at the source device or by a third-party device available at edge, fog, or cloud level [32]. e edges traversed during an interoperability translation process (ITP) present the interactions involved among the IoT devices. More number of traversed edges means more interoperability resolving complexity (IRC) for the ITP. By considering the edge weights as unit values, the IIRNC metric is defined as follows: e IoT interoperability resolving network complexity (IIRNC) is then calculated as the sum of IRC's for all ITPs, given in the following: e size of data (in bytes) sent over a one-time interaction activation is used to calculate the edge weights. e IIRNL metric is defined in equation (18), which calculates the network traffic generated during interoperability resolving action.
e IIRNL measure calculates the system's burden in message size generated for each interoperability operation. e worst case is when all interoperability operations activates concurrently, calculated by e interoperability performance of an IoT system is inversely proportional to IIRNL as given in the following: Mathematical Problems in Engineering If the network data traffic load exceeds the available bandwidth, the system will run slowly or perhaps become stopped. is problem can be avoided by checking for any excess information supplied in a message; otherwise, network bandwidth will need to be raised to keep the system operational.

Reusability Factor of IoT Metric.
e reusability of an IoT system is based on the reuse factor of the sensors, actuators, and other low-end, middle-level, and high-level devices in different IoT transactions. e reusability metrics for each of these modules are defined as follows: e total reusability factor of an IoT system is then determined from the following:

Mappings of IoT Services, Characteristics, QoS Factors, and Design Quality Metrics.
In this section, we mapped the newly defined design quality metrics to the QoS factors taken from the ISO 9126 model [23] (defined for the quality assessment of computing systems and applications). e QoS factors selected for this purpose, from the works of [3,4,6,17,22], include complexity, functional suitability, performance, efficiency, compatibility, maintainability, portability, and usability. e metrics defined for design quality evaluation of IoT services are IoT design complexity metric, IoT transactional complexity metric, IoT transactional network load metric, IoT communication channel demand metric, IoT interoperability resolving network complexity metric, and IoTinteroperability resolving network load metric.
As presented in Figure 2, the QoS factor complexity is quantified with design complexity, transactional complexity, and interoperability resolving network complexity. e QoS factor stability is measured with transactional complexity. For determining the efficiency and performance factor of QoS, the metrics used are transactional complexity, transactional network load, and interoperability resolving network load. Next, we quantified the compatibility QoS factor with interoperability metrics resolving network complexity and interoperability resolving network load. At the same time, the QoS factors of maintainability and portability are mapped with interoperability resolving network load. Lastly, the QoS factor of usability is determined with the metric named as reusability factor. e mapping between the second and third layer of Figure 2 links the QoS factors with IoTcharacteristics. e IoT characteristics as presented by Tambotoh et al. [14] are heterogeneity, resource-constrained devices, collaboration with hardware and resources, network mobility, embedded and adaptive devices, and design to monitoring IoT devices.
e IoT characteristic 'heterogeneity' is mapped with complexity, maintainability, and portability of QoS factors. e IoT 'resource-constrained devices' characteristic is mapped with QoS factors complexity, efficiency and performance, and usability.
e IoT 'collaboration with hardware and resources' characteristic is linked with QoS factors stability, compatibility, and usability. IoT's 'network mobility' characteristic is attached to compatibility, maintainability, and portability. IoT's 'embedded and adaptive devices' characteristic is linked to compatibility, maintainability, portability, and usability. Lastly, the IoT characteristic of 'design to monitor IoT devices' is mapped to maintainability, portability, and usability. e services inside an IoT infrastructure are defined by Gigli et al. [2] as information aggregation services, identityrelated services, ubiquitous services, and collaborativeaware services. Although all of these services are somehow related to each of the IoT characteristics, as presented in Figure 2, we categorically mapped each IoT service to the maximally related IoT characteristic(s). erefore, in the pattern given in Figure 2, we can map the IoT services to IoT characteristics to IoT QoS factors which are mapped to the design quality metrics presented in this work. It allows us to determine the IoTservices quality from defined design quality metrics.

Results and Discussion
A smart city healthcare setup is taken as a case study to assess IoT service quality measuring metrics defined in this work. In our smart city healthcare model, various medical IoT devices communicate with each other and share patients' records and live data through the cloud, fog, and edgecomputing paradigms. In the smart healthcare setup, a medical application connects a healthcare provider to his patient's smart medical devices, as illustrated in Figure 3. We consider a hospital ICU having a specific number of patient beds. On each patient's bed, various low-end devices as sensors are deployed to monitor the patient. e sensors include glucose level monitor (GLM), heartbeat rate (HBR) monitor, oxygen level flow (OLF), and blood pressure monitor (BPM). ese devices are connected with the edge, fog, and cloud networks to make them accessible anywhere in the hospital, labs, and remotely to the doctor/specialist. e doctor can observe the patient through these medical devices and can give a prescription. Moreover, a specialist can set the actuators' dosage and levels remotely for the advised medicine dosage for the patient.
For evaluation, we considered different scenarios of the case study system to evaluate the metrics defined in this work. e sensors and actuator devices considered in the case study are given in Table 2. e sensors are deployed for monitoring patients' vital signs and are connected to the network for the edge, fog, and cloud connectivity. e doctor observes a patient through the sensor devices and sets the actuators to the appropriate level for administering medicine to the patient.

IoT Transactional Complexity Metric (ITCM).
e IoT transactional complexity metric is evaluated with three transactional scenarios of a smart healthcare system. Scenario (i) is presented in Figure 4 where a doctor retrieves the data from only one sensor 'BPM' attached to bed 1 of hospital 1. e IoT transaction is shown in blue lines for this situation, and these data read complexity for the transaction calculated using equation (3) [14], QoS factors [3,4,6,22], and design quality metrics (this work).  Figure 3: A healthcare IoT-enabled smart city, where a patient (in a smart intensive care unit) is wearing IoT-enabled medical devices, managed with his smartphone. e data are shared in the healthcare system through edge, fog, and cloud [20].
e transactional response load for the sensor is also 4 units. So, the total response-request transaction complexity is 8 units.
Scenario (ii) is depicted in Figure 5 in purple edges where the doctor requests data from all sensors attached to the patient bed 1 in hospital 1. e transactional request complexity for all sensors accessed through the hospital gateway is 9 units, and the same is the transactional response complexity, i.e., 9 units.
e total response-request transactional complexity is 18 units.
Scenario (iii) is depicted in Figure 6 in green edges where data are retrieved from ICUs of a hospital attached via two different gateways. e transactional request complexity for   Mathematical Problems in Engineering all sensors accessed through the hospital gateway is 16 units, and the same is the transactional response complexity, i.e., 16 units. e total response-request transactional complexity is 32 units.

IoT Design Complexity Metric (IDCM) Evaluation.
e design complexity metric determines the overall complexity of an IoT system from its design model. Figure 4, Figure 5, and Figure 6 depict an IoT system design model with different remote data accessing scenarios for a doctor to connect with sensors through the cloud infrastructure for accessing the patient's vital information. e design complexity of this IoT system is measured with the IDMC metric defined in (7) by taking the unit cost of the weight of each edge.
e average design complexity (8) for this case study model is calculated to be � (24/25), which means it is less than one, which is a perfect case. So, the design model is a very simple system.

IoT Transactional Network Load (ITNL).
e metric defined in (9) determines the IoT transactional network load by taking the edge weight values in place of unit costs. e data packet size for each relevant IoT device (IoT node) is considered edge weight to determine a transaction's network load. IoT transactional network load is then calculated by summing up the data loads introduced from each node involved in an IoT transaction. Table 3 presents the data size returned by each sensor/actuators device used in the case study.

IoT Communication Channel Demand Evaluation.
For IoT communication channel demand evaluation, we consider the IoTdesign model of Figure 8, where doctors D1, D2, and D3 can access the patients' data through the gateway, controller, and platform channels connected at the edge, fog, and cloud levels, respectively. A doctor may have its own request format, and each sensor may have a different response format.
In the first case (depicted with blue edges and vertices), the doctor D1 is attached to the gateway G1 and wants to access data of bed 1 patient admitted to the ICU of hospital 1. e request is sent to the sensors and actuators attached to the patient bed in MQTT format. e sensors, in this case, are HBRM and GLM, and the actuators are SID and AID. e data size detail of these devices is given in Table 4. In this scenario, the data travel a single hop. e communication channel demand for this case is calculated in Table 5 using (16) and is determined as 56 bytes. Now, take the other scenario where a doctor D2 is attached to the controller at fog level and wants to access the data of patient bed 2 and patient bed 3 of hospital 1. e healthcare device sent the data to the controller in CoAP format and forwarded it to relevant gateways. Detail of attached sensors/actuators and response size is given in Table 4. As given in Table 6, the maximum communication channel demand for hospital 1 is calculated as 64 bytes and for hospital 2 and hospital 3, it is calculated to be 95 bytes each. e next scenario of ICCD assessment is where the doctor D3 is linked to the cloud platform and wants to access the data of different patients admitted to different hospitals. e request is forwarded to the sensor through the platform to the controller to the gateway down to the sensors. e request format is AMPQ with 8 bytes. By using the details given in Table 7, Figure 8, and (16), the maximum communication channel demand for this scenario is determined to be 95B. It is the largest amount of data that can transfer over an interaction which is determined by the maximum interaction weight value among all of these interaction weights.

IoT Interoperability Resolving Network Complexity (IIRNC) and Interoperability Resolving Network Load (IIRNL)
Evaluation. Consider a scenario where a doctor initiates a request to the gateway G1 devices for accessing patient data in JSON format. e gateway retrieves the data from devices and checks its format. If the format is as required, the data are transferred to the health care doctor's device. However, if the data format translation is required, the gateway sends the data to the fog layer, which transfers the data to the cloud for translation. e translated data are sent back to the gateway through the fog layer and then sent to the doctor. e translation scenario is presented in Figure 9. e IoT interoperability resolving network complexity and load is determined by hop count and the weight of the edges involved. In the scenario given in Figure 9, four hops are traversed when the interoperability is not required, so the interoperability network complexity is 4, and the interoperability network load is 78 bytes. However, the data translation is required for interoperability when the doctor needs data in JSON format and his device supports CoAP format. is scenarios is given in Figure 8 for patient at bed-2 of hospital-1. e bed 2 has devices BPM, POM, TMS, SID, AID, and SV and is supporting data format Number/binary, text, number/binary, XML, JSON, and XML, respectively. e protocols supported are MQTT, REST, and AMQP as   given in Table 3. After interoperability, the involved network's complexity using (19) is calculated as 8, and the network load introduced is 69 bytes.

Discussion.
e basic aim of this research was to present measurement criteria for quantitatively assessing the design quality of IoT systems and services. To achieve our goal, we defined a suite of design quality metrics for IoT systems evaluation. We take the IoT EcoSystem as a base of this work and drafted the IoT EcoSystem model as an abstract graph to define the IoT transactions model in terms of schema graph. e formal definitions are used to define the design quality metrics for IoT services quality assessment from its design models. e metrics defined are IoT design complexity metric, IoT transactional complexity metric, IoT    1  Bed 2  Sensors  HRBM, GLM  BPM, POM, TMS  CMS, BPM, POM  CSI, ID  ECG, GLM, POM  Actuators  SID, AID  SID, AID, SV  SID, SR, SV  SID, SV  AID, SV, SID  Response-size  Sensor  12B, 8B  7B, 5B, 6B  8B, 7B, 12B  16B, 20B  10B, 8B, 12B  Actuator  20B, 16B  20B, 16B, 24B  20B, 24B, 24B  20B, 20B 16B, 24B, 20B IoT interoperability resolving network load, and IoT reusability factor. e assessment of defined design quality metrics is made with a case study of the smart healthcare IoT system. We evaluated the proposed metrics using different scenarios of the smart healthcare system. e calculated results are given in tabular form which presents the metrics outcomes to be compared with realistic outcomes. e metrics results are proved validated against benchmark values taken from field experts. It validates the accuracy of defined metrics as the obtained values are consistent with known parameters (i.e., predicted results). e results are useful in comparing the design quality of different models designed for an IoT service. Using these metrics, we can compare different designs available for an IoT system or its services. e best service model will be the one having minimum value for the metrics applied for evaluation.

Conclusion
is work presented metrics for design quality evaluation of IoT services by defining the IoT EcoSystem as a schema Graph. e metrics defined for different IoT parameters measure design complexity, transactional complexity, transactional network load, communication channel demand, interoperability resolving network complexity, interoperability resolving network load, and reusability. e quality metrics have been mapped to the quality factors of the IoT system, including efficiency, portability, compatibility, maintainability, usability, and functional suitability according to IoT characteristics. e IoT quality factors have been mapped to IoT characteristics which include heterogeneity, resource-constrained devices, collaboration with hardware and resources, network mobility, embedded and adaptive devices, and design to monitor IoT devices. e QoS factors are then mapped to IoT services which are divided into information aggregation, identity-related, ubiquitous, and collaborative-aware services. e defined metrics are evaluated with different use cases of a smart IoT healthcare system. Finally, we conclude that the proposed design quality metrics can be used to compare and evaluate design level quality for the quality of services in IoT systems.
is research work can be automated in future work, and the metrics can be directly computed to save validation time.
ese proposed metrics can also be used in different conditions to measure the accuracy and correctness of an IoT project.

Data Availability
Data are available on request. 4 .t r a n s . r e q M a x = 7 8 B Health care Worker Figure 9: IIRNL-IoT interoperability resolving network load metric calculation with a use case of healthcare IoT-enabled smart city.