# Performance Evaluation of a Dual Coverage System for Internet of Things Environments

Authors: Omar Said; Amr Tolba
Journal: Mobile Information Systems
 (2016)

---

## Abstract

A dual coverage system for Internet of Things (IoT) environments is introduced. This system is used to connect IoT nodes regardless of their locations. The proposed system has three different architectures, which are based on satellites and High Altitude Platforms (HAPs). In case of Internet coverage problems, the Internet coverage will be replaced with the Satellite/HAP network coverage under specific restrictions such as loss and delay. According to IoT requirements, the proposed architectures should include multiple levels of satellites or HAPs, or a combination of both, to cover the global Internet things. It was shown that the Satellite/HAP/HAP/Things architecture provides the largest coverage area. A network simulation package, NS2, was used to test the performance of the proposed multilevel architectures. The results indicated that the HAP/HAP/Things architecture has the best end-to-end delay, packet loss, throughput, energy consumption, and handover.


---

## Body

## 1. Introduction

During the past three decades, the wireless communication field has had notable development. New technology in wireless communication provides users the freedom to connect to different types of networks. Terrestrial and satellite technologies provide services to High Data Rate and dynamic networks such as in mobile networks, Radio Frequency Identification (RFID) networks, and Wireless Sensor Networks (WSNs). Terrestrial links provide these services but with high complex propagation restrictions. Satellite links are used instead of terrestrial links to provide communication services for ships, planes, and TV broadcasting. The satellites provide these services to an assigned area on the earth. Many parameters control bandwidth power for the satellite systems such as target footprint size, traffic control complexity, and ground station cost. Focused satellite transmissions based on target goals provide satellite systems with high efficiency due to interference minimizing and use of efficient spectrums [1–10].High Altitude Platforms (HAPs) can be constructed using airships, planes, or balloons at altitudes of 17–22 kilometers (or higher). They can also deliver a range of services for communication and remote sensing with features that are better than terrestrial and satellite systems. HAPs are competitors with terrestrial and satellite systems, which make them good candidates for the next generation of communication systems. In addition, HAPs can act as a base station that can easily communicate with satellite systems using very tall antennas and can handle the increasing demand of broadband wireless access [11–13].Internet of Things (IoT) is a new technology that has attracted the attention of many network and communication researchers in the last few years. IoT has many applications in military, healthcare, marketing, and learning [14–16]. IoT is roughly defined as a computing model where various physical things communicate with each other using the Internet and provide information about themselves and their environment to other passive or active things [17–20]. IoT has many challenges associated with diversity in communication nodes (things), large amounts of processing data, large numbers of communication nodes (things), routing, security, energy consumption for active nodes, and things coverage [21]. Each challenge has important impacts on the performance of IoT systems. These challenges may also affect the level of coverage, which depends on communication technology between IoT nodes. It is well known that ground communication between things has a very limited coverage range due to various impairments. Many existing technologies for IoT nodes have limited coverage (a few meters) [22–24]. The communication between IoT nodes using satellites or HAPs will provide much larger coverage, especially with Internet signals, which represent a main connection medium in IoT systems. For example, the possibility of coverage for large WSNs using HAPs has been proved [25]. The radius of this coverage area can be extended to several tens of kilometers. In addition, the power of sensors did not need enhancement from external sources. HAPs provide many advantages over satellites such as low transmission power and less delay [26]. Because satellites also have many advantages, such as large coverage areas, there are benefits to constructing and testing multilevel satellite/HAP architectures. Using HAPs in addition to satellites provides efficient IoT systems with satellites at the top of architecture that link with HAPs used for efficient power transmission from ground or space things. For maximum efficiency, these types of architectures may require special hardware such as sensors with parabolic antennas [11, 12, 27]. Using these architectures, many applications may be constructed to manage IoT system nodes in space and on the earth surface. These applications can be merged for management in one smart management application, which represents the IoT core idea. Different satellite/HAP architectures allow diversity in applications, which makes IoT systems more flexible and scalable. Therefore, the proposed architectures are Satellite/HAP/HAP/Things, Satellite/HAP/Things, and HAP/HAP/Things.The paper is organized as follows. Section2 presents work related to HAP and satellite use in IoT. In Section 3, the research objective and paper contribution are presented. The dual coverage system and proposed satellite/HAP architectures are introduced in Section 4. Section 5 provides a comparative analysis of the proposed architectures. A performance evaluation of the proposed architectures is provided in Section 6. Finally, the conclusion and the future work are presented in Sections 7 and 8, respectively.


## 2. Related Work

The related work review included work using IoT with satellite systems, WSN with satellite systems, and general Internet satellite systems. Few studies were available related to IoT and satellite systems. De Sanctis et al. used a satellite communication system to support the IoT [28]. This satellite system collects data from RFID or sensor systems and sends data to actuators. This theoretical research did not scale with the efficiency of the proposed architecture. In addition, this research did not discuss how the communication between things and satellite would be achieved. Limited discussion of IoT and satellites was available on Internet web sites but these websites presented only general discussion and did not address this research area in depth [29].Many research papers define the relation between satellite, HAPs, and WSN. Celandroni et al. proposed a model for management of disasters remotely. This model includes unmanned aerial vehicles (UAVs) equipped with cameras that are communicated with wirelessly. UAVs hover over disaster areas, such as a massive fire or huge traffic accident, and convey information using recording videos and images acquired in real time using high technology data sensors. The extracted information is sent to specialists for evaluation and action determination during disasters. This research considered optimal sensor distribution as a challenge. This model is not suitable for IoT applications because it used only WSNs.The distribution of cells in the HAP coverage area is an important parameter that affects the capacity of HAP systems. Many researchers have studied cell distributions and several proposed dividing HAP coverage areas using 12 to 19 cells for capacity enhancement [30, 31]. Based on this research, Yang and Mohammed proposed architectures comprised of HAPs and a WSN [32]. Mitchell et al. further developed this idea and proposed two HAP/WSN architectures appropriate for many vital applications such as monitoring and security [33]. The first proposed architecture permits information to be transmitted directly to the HAP and decreases energy consumption and complexity. It is appropriate for applications that have low data transmission and need large coverage areas. The second proposed architecture is comprised of nodes organized in clusters such that there is no direct communication between sensor nodes and HAPs. The collected data are sent to the cluster head that passed it directly to the HAP. Cluster head node selection and energy consumption are two important challenges in this architecture. This architecture is suitable for multimedia applications that transmit large numbers of bytes in small intervals.Daniel et al. studied the relationship between satellites and WSN [34]. There are many applications using satellites and WSNs constructed for emergency communication systems and remote area surveillance. Many researchers have attempted to solve problems that may occur in satellite/WSN systems. Verma et al. evaluated the performance of a WSN/satellite framework using a network simulation package, NS2. The simulation calculated many metrics such as end-to-end delay, energy consumption, and data gathering efficiency. In addition, this research studied the security problem in WSN/satellite systems [35]. Another method to evaluate WSN/satellite performance was constructed by Henaut et al. Multiband Orthogonal Frequency Division Multiplexing (MB-OFDM) was evaluated as a radio interface for new High Data Rate (HDR). The results proved that performance was acceptable for MB-OFDM and WSN applications [36]. Raveneau et al. proposed an architecture model to interconnect WSN and satellite technologies. This architecture is called store-carry-and-forward, which is based on the Delay Tolerant Networking (DTN) technique. In addition, a comparison between new proposed scheduling policy and traditional solutions of DTN was presented [37]. Li et al. presented an algorithm to collect small satellites into one system where energy consumption is optimized. This algorithm increased the network lifetime. This proposed algorithm is adaptable to network size and the communication mechanism used [38]. Amirijoo et al. designed a communication server architecture that is used as a tier between end users and sensor nodes where a satellite communication technology is considered a major link. This proposed server design is used to gather sensor data. These researchers also presented a dynamic mechanism that adapts to collected data quality [39]. Poulakis et al. proposed a monitoring application where a Collaborative Beamforming (CB) mechanism is deployed in the WSN/satellite system without the need for a gateway. An analysis of the link budget is presented in addition to an examination of the proposed application under different numbers of nodes [40]. Shahzad introduced a monitoring system that consists of a WSN connected to a satellite system. This system utilized Google mapping to extract 3D images in high resolution. This research also utilized an interactive web application to decode and send messages (gathered data) to a service provider, which stores data into a database [41]. Mohapatra et al. studied location-tracking systems based on WSNs. This research used many scenarios and methods to estimate the angle of arrival (AoA) for tracked locations [42]. Albagory et al. proposed many satellite/HAP architectures and tested their coverage efficiency but did not discuss methods for applying these architectures on the IoT environment. The efficiency of these architectures was also not measured according to network metrics such as end-to-end delay and packet loss ratio [43].


## 3. Paper Contribution

IoT is an emerging technology that communicates physical objects (things) in space, in seas, and on earth. The coverage of these diverse objects is considered a challenge. The Internet is the main transmission medium by which IoT nodes can transmit their data. Despite the large spread of the Internet globally, many objects do not have Internet connections, however, which presents a problem for IoT scalability. This paper addresses this problem by introducing a dual coverage system to provide IoT nodes with full coverage regardless of their locations. The proposed system has three multilevel architectures comprised of four elements: satellites, HAPs, Internet, and things. The IoT objects will be covered by satellite or HAPs when unable to access Internet signals. The proposed multilevel architectures determine the relationships between satellites, HAPs, Internet, and things. In addition, a performance analysis was completed for these architectures evaluating coverage ability and many network metrics such as end-to-end delay, packet loss ratio, throughput, energy consumption, and handover.


## 4. Proposed Dual Coverage System

The proposed dual coverage system objective is to guarantee full coverage for each IoT object regardless of its location. The proposed systems consist of satellites, HAPs, Internet, and things arranged in three types of multilevel architectures. These architectures are Satellite/HAP/HAP/Things, Satellite/HAP/Things, and HAP/HAP/Things. These architectures may also include Internet signals. Each of the proposed architectures has two scenarios for IoT object locations.


### 4.1. Satellite/HAP/HAP/Things Architecture

The first proposed architecture is composed of four layers. These layers are satellite, HAP, HAP, and things. This architecture is used to cover isolated areas that are impossible to cover with HAPs alone. The first satellite layer satellite can be used in case of communication failure between isolated things and things covered by the third HAP layer. The communication cost will be decreased by restricting the satellite use. This architecture is similar to the second proposed architecture, which is described in Section4.2, but it has an additional HAP layer that may be used in special cases. Use of the satellite can close communication gaps that may result from using HAPs. The location of the first satellite layer is approximately thousands of kilometers, and this layer can be used as a spare communication tool if failure occurs in the HAP second or third layers. The location of the second HAP layer is approximately located near to 50 km. The location of the third HAP layer is approximately located near to 20 km. The IoT objects may be attached to HAP components or found on the ground (depending on the needs of the IoT application). Refer to Figures 1 and 2.Figure 1
Satellite/HAP/HAP/Things architecture (scenario 1).Figure 2
Satellite/HAP/HAP/Things architecture (scenario 2).


### 4.2. Satellite/HAP/Things Architecture

The Satellite/HAP/Things architecture consists of a satellite backbone, HAP, things, and Internet connections. The IoT objects (passive or active) should have a direct connection to the HAP. Data that are sent or emitted from passive things should be collected by the HAP (i.e., the HAP is considered a sink node for its region nodes). Accordingly, each of the HAPs should send its collected data to the satellite backbone. The satellite can then redirect these data to the destination (predetermined objects in the IoT system). This architecture supposes that there are two locations of IoT nodes, on the ground and attached to HAPs, as shown in Figures3 and 4. Under this assumption, only one HAP network transmits the data, which are collected by other HAPs, to the satellite backbone. This strategy decreases the communication overhead and system cost. The selection of the HAP used to communicate with the satellite is an important issue and techniques have been proposed for this [44, 45]. The communication between sensors, RFID networks, and mobile ad hoc networks is possible using Internet or satellite/HAP networks as transmission mediums. The long distance between HAP and satellite represents a challenge in this architecture because HAP coverage radius is limited by thing power, transmission band, and bit rate. Therefore, the Satellite/HAP/Things architecture is considered a backup coverage mechanism in case of failing Internet coverage. Using this architecture as a backup coverage system increases the overall system cost. Hence, this architecture should be used as a basic one for many active things such as sensors. In this case, the transmission power will be decreased and the applications of IoT will became more prevalent.Figure 3
Satellite/HAP/Things architecture (scenario 1).Figure 4
Satellite/HAP/Things architecture (scenario 2).


### 4.3. HAP/HAP/Things Architecture

The first proposed architecture seems to be costly using a satellite layer. As an alternative, the satellite backbone layer can be replaced with one or more HAP layers. Hence, the third proposed architecture is composed of three layers. The first and second layers are HAPs and the third layer is comprised of IoT nodes (things). It is well known that HAPs are cheap, flexible, and stable comparable with satellites [11, 12]. HAPs can be reconfigured, relocated, and repaired in case of failure. The HAP communication system has less transmission delays and has acceptable links with ground things. Furthermore, for mobile users and end users-access providers, HAPs have more efficient communication than satellites. These HAP features are adaptable to various IoT application needs. However, the coverage area of HAPs is small relative to satellites, which represents a problem in our proposed architecture. One solution to this problem involves using more HAPs to maximize the coverage area. Additional HAPs increase cost, but this cost is still less than a satellite layer. In this case, inter-HAP links are used to allow HAPs to communicate with each other.The first HAP layer in this second architecture should be located at approximately 50 km. The second HAP layer should also be located at approximately 20 km. The third layer is things, which may be attached directly to HAPs or on the ground. Refer to Figures5 and 6. The sensitivity of thing location may represent a challenge in this proposed architecture. This is because of the definition of IoT, which states that thing location is a dynamic parameter and requires that things should be covered anywhere. The second layer collects the data from the third layer comprised of IoT nodes. For example, suppose that the third layer has WSN, RFID networks, and mobile ad hoc networks. The communication between these network nodes may be accomplished using the second layer. In this scenario, sending and receiving data between IoT objects will be achieved using intelligent applications such as healthcare systems [46–48]. The first layer is used to communicate with second layer HAPs. The communication between HAPs in the second layer and between the third layer and second layer is simpler due to satellite replacement [11].Figure 5
HAP/HAP/Things architecture (scenario 1).Figure 6
HAP/HAP/Things architecture (scenario 2).


## 4.1. Satellite/HAP/HAP/Things Architecture

The first proposed architecture is composed of four layers. These layers are satellite, HAP, HAP, and things. This architecture is used to cover isolated areas that are impossible to cover with HAPs alone. The first satellite layer satellite can be used in case of communication failure between isolated things and things covered by the third HAP layer. The communication cost will be decreased by restricting the satellite use. This architecture is similar to the second proposed architecture, which is described in Section4.2, but it has an additional HAP layer that may be used in special cases. Use of the satellite can close communication gaps that may result from using HAPs. The location of the first satellite layer is approximately thousands of kilometers, and this layer can be used as a spare communication tool if failure occurs in the HAP second or third layers. The location of the second HAP layer is approximately located near to 50 km. The location of the third HAP layer is approximately located near to 20 km. The IoT objects may be attached to HAP components or found on the ground (depending on the needs of the IoT application). Refer to Figures 1 and 2.Figure 1
Satellite/HAP/HAP/Things architecture (scenario 1).Figure 2
Satellite/HAP/HAP/Things architecture (scenario 2).


## 4.2. Satellite/HAP/Things Architecture

The Satellite/HAP/Things architecture consists of a satellite backbone, HAP, things, and Internet connections. The IoT objects (passive or active) should have a direct connection to the HAP. Data that are sent or emitted from passive things should be collected by the HAP (i.e., the HAP is considered a sink node for its region nodes). Accordingly, each of the HAPs should send its collected data to the satellite backbone. The satellite can then redirect these data to the destination (predetermined objects in the IoT system). This architecture supposes that there are two locations of IoT nodes, on the ground and attached to HAPs, as shown in Figures3 and 4. Under this assumption, only one HAP network transmits the data, which are collected by other HAPs, to the satellite backbone. This strategy decreases the communication overhead and system cost. The selection of the HAP used to communicate with the satellite is an important issue and techniques have been proposed for this [44, 45]. The communication between sensors, RFID networks, and mobile ad hoc networks is possible using Internet or satellite/HAP networks as transmission mediums. The long distance between HAP and satellite represents a challenge in this architecture because HAP coverage radius is limited by thing power, transmission band, and bit rate. Therefore, the Satellite/HAP/Things architecture is considered a backup coverage mechanism in case of failing Internet coverage. Using this architecture as a backup coverage system increases the overall system cost. Hence, this architecture should be used as a basic one for many active things such as sensors. In this case, the transmission power will be decreased and the applications of IoT will became more prevalent.Figure 3
Satellite/HAP/Things architecture (scenario 1).Figure 4
Satellite/HAP/Things architecture (scenario 2).


## 4.3. HAP/HAP/Things Architecture

The first proposed architecture seems to be costly using a satellite layer. As an alternative, the satellite backbone layer can be replaced with one or more HAP layers. Hence, the third proposed architecture is composed of three layers. The first and second layers are HAPs and the third layer is comprised of IoT nodes (things). It is well known that HAPs are cheap, flexible, and stable comparable with satellites [11, 12]. HAPs can be reconfigured, relocated, and repaired in case of failure. The HAP communication system has less transmission delays and has acceptable links with ground things. Furthermore, for mobile users and end users-access providers, HAPs have more efficient communication than satellites. These HAP features are adaptable to various IoT application needs. However, the coverage area of HAPs is small relative to satellites, which represents a problem in our proposed architecture. One solution to this problem involves using more HAPs to maximize the coverage area. Additional HAPs increase cost, but this cost is still less than a satellite layer. In this case, inter-HAP links are used to allow HAPs to communicate with each other.The first HAP layer in this second architecture should be located at approximately 50 km. The second HAP layer should also be located at approximately 20 km. The third layer is things, which may be attached directly to HAPs or on the ground. Refer to Figures5 and 6. The sensitivity of thing location may represent a challenge in this proposed architecture. This is because of the definition of IoT, which states that thing location is a dynamic parameter and requires that things should be covered anywhere. The second layer collects the data from the third layer comprised of IoT nodes. For example, suppose that the third layer has WSN, RFID networks, and mobile ad hoc networks. The communication between these network nodes may be accomplished using the second layer. In this scenario, sending and receiving data between IoT objects will be achieved using intelligent applications such as healthcare systems [46–48]. The first layer is used to communicate with second layer HAPs. The communication between HAPs in the second layer and between the third layer and second layer is simpler due to satellite replacement [11].Figure 5
HAP/HAP/Things architecture (scenario 1).Figure 6
HAP/HAP/Things architecture (scenario 2).


## 5. Coverage Comparative Study for Proposed Architectures

The global coverage for all things is the core objective and contribution of this paper. The proposed architectures should therefore be compared relative to this objective metric. A comparative study of global earth coverage was done for the proposed architectures. The required cellular coverage area determines the number of satellites and HAPs that should be used in the target IoT application. Suppose that a HAP or satellite is located at an altitude ofh km and a minimum elevation angle for covering an area is E. So, using h and E variables, the target footprint area can be calculated using (1) and (2) below. The satellite/HAP geometry is shown in Figure 7,(1)A=2πre21-cos⁡θ,(2)θ=cos-1recos⁡Ere+h-E.The variable re is the radius of earth that can be approximately evaluated as 6,378 km.Figure 7
Satellite/HAP geometry of coverage.In this IoT coverage analysis, a cellular shape should be determined. It is supposed to be a hexagonal shape with circle areaa=πrc2, where rc is a radius as shown in Figure 8. The actual cell distribution should be treated as a hexagonal shape (not a circular one) due to the circular footprints, which are tessellated with overlapped areas. The cell in the hexagonal view has a radius rc and its area is given by(3)ah=332rc2.Therefore, the cell radius, which is calculated in (1), has a relation to (3). Hence, the resulting area of the cell is given by(4)ah=33re21-cos⁡θ.For covering the entire earth with satellite/HAP, the number of satellites and HAPs must be determined. This number can be determined using two relations that are defined in (5) and (6),(5)NS/H=Area  of  Earth  SurfaceArea  of  Station  Coverage,(6)NS/H=4π331-cos⁡θ.The above analysis is more general and fulfills the IoT application needs. However, the IoT will take a long time to cover the whole earth and become dominant in the world. Therefore, we need to clarify how to recover part of the earth. For example, if we need to cover a land as a portion of the entire earth space, (6) should be decreased by 29 percent. This percentage represents the land ratio relative to the whole earth. Accordingly, NS/HL, which represents the coverage land ratio, can be calculated using(7)NS/HL=1.16π331-cos⁡θ.For a global coverage target, a number of satellites and HAPs are needed as determined by (6) and (7) (assuming that the coverage area equals the cell areas). Hence, each of the architectures should be examined to show its coverage feasibility. In our analysis, the geostationary orbit (GEO) is located at an altitude of 36,000 km, and the low-earth orbit (LEO) is located at an altitude of 800 km. These two satellite orbits are most common orbits. With respect to HAPs, there are two common heights. The first one is at 20 km, representing lower layer HAPs, and the second is at 50 km, representing upper layer HAPs. The results proved that the number of required HAPs is much greater than the number of LEO or GEO satellites. This is because the satellites have high altitudes that provide large coverage areas. The coverage of the whole earth may require approximately one million HAPs with an elevation angle of 55°. To minimize the number of required HAPs, we have to increase their coverage areas or reduce the elevation angle. Optimization of the required architecture is a target but this will be addressed in the simulation section. In order to determine the orbit that fits the required coverage, it is mandatory to use satellites in communication between IoT nodes. For LEO satellites, the orbit is not fixed relative to the earth things. In addition, the power required for data transmission is low. Accordingly, when using LEO satellites in the proposed architectures, the HAPs in the lower layer should communicate with LEO satellites at the visible times. The LEO satellites should have the ability for switching and tracking. However, GEO satellites require much more power for data transmissions. They are also fixed with respect to earth objects. The number of required satellites or HAPs at different elevation angles is displayed in Figure 9.Figure 8
Satellite/HAP coverage footprint of cell.Figure 9
Satellite/HAP coverage cell footprint.


## 6. Simulation and Evaluation

### 6.1. Simulation Setup

The simulation environment was built using the network simulation package, NS2. This environment was comprised of five types of networks: satellite, HAP, WSN, RDIF, and mobile ad hoc networks. There are six satellites that communicate with each other to create a network. The data can be redirected from one satellite to another until it reaches the target satellite. Table1 shows the configuration parameters of the satellite network. In addition, there are 60 HAPs configured in one network. The communication between HAPs may be achieved using inter-HAPs technology or using a selected satellite [11]. Table 2 shows the configuration parameters of the HAP network. Nodes in the other three networks, WSN, RFID, and mobile ad hoc, are distributed randomly in the covered areas for HAPs and satellite networks. The percentage of things covered by the Internet is 75% and the remaining 25% of things are covered by the HAPs and satellite networks. The percentage of things on the ground is 80%, with 15% of things in space, and 5% of things in the sea or underground. The simulation of the IoT environment is flexible since these percentages can be changed dynamically to get accurate performance results for the proposed IoT coverage systems. Tables 3, 4, and 5 contain the configuration parameters of WSN, RDIF, and mobile ad hoc networks, respectively.Table 1
Configuration parameters for satellite simulation.
Parameter Value Satellite type LEO Altitude 800 km Inclination degree 86 (degree) Elevation mask 8.2 (degree) Uplink/downlink 1.5 Mb/s Cell size 50 km Power 1 watt Number of satellites 4 Intersatellite links bandwidth 25 Mb/s Intersatellite links per satellite 6 Cross-seam intersatellite links Not found Intersatellite link delay 7.8 ms Intersatellite distance 60 kmTable 2
Configuration parameters for HAP simulation.
Parameter Value Altitude 20–50 km Bit error rate 10−6 Elevation mask Flat Power 1 watt Return channel HAP 30 Mb/s Forward channel HAP 60 Mb/s Cell size 0.5 to 10 km BS max. Tx power per link 30 dBm Common pilot channel Tx power 27 dBm UL load limit 0.75 BS noise figure 5 dB UE max. TX power 21 dBm SHO add window 3 dB Traffic bit rate 12.2 kbps E b /N 0UL 5 dB E b /N 0DL 9.5 dB Slow fading standard deviation 4 dB DL orthogonality factor 0.9 SHO gain (UL and DL) 1 dB Number of HAPs 60Table 3
Configuration parameters for WSN simulation.
Parameter Value Frequency 2400 MHz Transmit (TX) data rate 250 Kb/s RF power −10 dBm Receive (RX) sensitivity −94 dBm Current drain in transmit mode 11 mA Current drain in receive mode 19.7 mA Battery 2x 1,250 mAH, 1.5 V Covered area 1,000 m × 1,000 m Number of nodes 1,000Table 4
Configuration parameters for RFID simulation.
Parameter Value Data channel frequency 915 MHz Control channel frequency 930 MHz Interchannel interference No Fading No SNR based signal reception 10 Data rate 2 Mbps Radio Rx sensitivity −91 dBm Rx threshold −81 dBm RFID transmission power −45 dBm Read range 1.62 meters Sensing range 5.4 meters Interference range 7.1 meters Number of nodes 1200Table 5
Configuration parameters for mobile ad hoc simulation.
Parameter Value Packet size 1 Mb Network area 500 m × 500 m Total number of requests 3200 Interval between requests’ transmission 500 ms TTL Random between 4 and 7 ms Link availability Between 0 and 1 Maximum transmission distances 30 to 210 m Maximum node speed 30 km/h to 60 km/h Changing direction probability P = 0 Number of nodes 83There are four possible simulation scenarios: full ground Internet coverage, full satellite/HAP network coverage, Internet over satellite/HAP network coverage, and satellite/HAP network with ground Internet coverage. The first scenario supposes that nodes in the IoT environment are covered by ground Internet. Hence, there is no need for satellite and HAP networks as shown in Figure10. In this scenario, each node should have Internet connection capability. Accordingly, most of IoT objects are supposed to be active. This scenario is not considered in the simulation. This is because using ground Internet makes IoT nodes (things) lack full coverage, which does not meet our objective. The second scenario supposes that the IoT objects will be covered using a satellite/HAP network as shown in Figure 11. This scenario does not meet the IoT definition because it does not use the Internet as a communication tool between things. Therefore, this second scenario is also not considered in the simulation. The third scenario supposes that a part of the IoT nodes is covered by ground Internet and other things are covered by satellite or HAP as shown in Figure 12. In this scenario, the communication between IoT objects is not unified; that is, there are two different communication environments, satellite/HAPs and ground Internet. Accordingly, the data can be transmitted to the HAP; it will be directed to the nearest HAP or to the upper satellite layer. A gateway should be present in this scenario to transmit the data from satellite or HAP networks to the Internet and then to the end user or central management system. This third scenario is considered in our simulation because it contains two coverage systems, satellite/HAPs and ground Internet, that meet our objective. The fourth scenario supposes that the IoT nodes are covered by Internet over satellite or HAP as shown in Figure 13. Hence, each node should have an Internet connection using ground Internet or satellite Internet.Figure 10
First simulation scenario: full Internet coverage.Figure 11
Second simulation scenario: full satellite/HAP coverage.Figure 12
Third simulation scenario: satellite/HAP and ground Internet coverage.Figure 13
Fourth simulation scenario: Internet over satellite/HAP coverage.In our simulation, 60 routers are distributed over different locations in five countries. Each router is connected to a number of nodes that is determined randomly, from 50 to 100 nodes (things). The IoT nodes are connected directly to the router or through a sink node that is used to gather information from its things. The relation between routers and HAPs depends on the applied scenario. In addition, there are five servers to manage the Internet routers and other networks such as satellite and HAP. These servers are used by end users for building interactive IoT applications. Additionally, there are six LEO-Iridium satellites, which communicate with 60 HAPS. Each satellite communicates with 10 HAPs. Data is redirected from HAPs in one location to HAPs in different locations using the satellites. The relation between HAPs, satellites, and routers also depends on the executed architecture. The link bandwidth between satellites is 10 Mb/s. The link bandwidth between HAPs and satellites is 10 Mb/s. The link bandwidth between HAPs and routers is 1.5 Mb/s. The bandwidth between routers and sinks or things randomly varies between 1 and 2 Mb/s. The propagation delay of links varies according to the distance between network components, satellites, HAPs, and routers. In our simulation, the propagation delay ranged from 25 to 30 ms. However, the edge propagation delay was 5 ms. The routing paths for transmitting packet streams are determined using optimized link state routing protocols [49] in addition to ant colony optimization [50]. The routing genie is used to adapt the routing process in LEO satellites networks [51, 52]. In addition, in our simulation, the things are divided into two classes, passive and active. The passive things use RFID technology to communicate with satellites, HAPs, or the Internet. The active things can send or receive data to/from other things using coverage methods. There are four types of traffic loads: video, audio, image, and text. MPEG-2 is used as the compression coding for video streams. The compression coding for audio streams is PCM. The coding of images is JPG. Creation of traffic is a random process. The tree topology is used in the proposed architectures. In addition, the ground, space, and underground nodes are distributed randomly to reflect the real meaning of IoT environment. Moreover, the traffic generation model, used in this simulation, is governed by Poisson distribution. Each network component has a buffer to store data packets and redirect them to a predetermined destination. The buffer size of satellites and HAPs is determined using proposed techniques [53, 54]. The buffer size of Internet components, such as routers or servers, is a random value from 100 to 1,000 kb. For Internet connections, the TCP and UDP are used as transport layer protocols. The selection of the transport layer protocol is achieved dynamically depending on the flow size of packet streams and types. In case of network starvation (i.e., the number of lost packets and delay ratio are notably increased), UDP will be used. On the contrary, in the normal case of the IoT system (i.e., the IoT metrics have normal values), TCP will be used. The performance metrics in this simulation are end-to-end delay, packet loss ratio, throughput, energy consumption, and handover. The proposed simulation environment measures these performance metrics for the third and fourth scenarios. The simulation was executed for 1,000 minutes. For best results, five simulation iterations were executed and results averages were determined.


### 6.2. Results and Discussion

In this subsection, the performance metrics, end-to-end delay, packet loss, throughput, energy consumption, and handover are evaluated, and the results are discussed. The performance metrics are measured for the three proposed architectures relative to the third and the fourth simulation scenarios only. The first simulation scenario supposes that the Internet is the only coverage tool for IoT objects and neglects satellite and HAP tools. This scenario is considered a traditional IoT idea that does not meet the targeted objective of this paper. The second simulation scenario also fails to meet the targeted objective because it uses satellite and HAPs only without the Internet and does not meet the typical IoT definition.


#### 6.2.1. End-To-End Delay

The end-to-end delay is considered an important performance metric due to the large numbers of data packets that may be transmitted through IoT systems. The end-to-end delay metric is measured from the time a packet is generated to the time it reaches its destination. The end-to-end delay includes the buffering delay that results from queuing packets at sources and destinations. The results of end-to-end delay analysis are shown in Figures14 and 15. The x-axis in the end-to-end graph represents the simulation time in minutes. As stated above, the simulation time is 1,000 minutes. The end-to-end delay is calculated by averaging 10 delay values (one delay value is extracted every minute). The y-axis represents the average end-to-end delay values in milliseconds. Figure 14 shows the end-to-end delay result for the third scenario, and Figure 15 shows the end-to-end delay result for the fourth scenario. Result graphs show that the third simulation scenario has less end-to-end delay values than the fourth scenario. This can be explained as the IoT nodes in the third scenario are covered by ground Internet in addition to the satellite/HAP network. However, the nodes in the fourth scenario are covered by Internet over the satellite/HAP network, which has significant delays caused by long distances. The results shown in Figures 14 and 15 indicate that the best average end-to-end delay is for the HAP/HAP/Things architecture. This is due to the HAP height (or altitude) being less than the satellite height, which means the IoT data can be transmitted with less delay (refer to Section 4). In addition, at the simulation time point 8, the delay is suddenly decreased and smoothly increased in the next simulation time points. This is because the IoT simulation model includes passive things that are randomly distributed, which means the size of IoT data may increase or decrease suddenly. The hesitation in the plots is also due to bandwidth diversity, which is considered a main feature of IoT environments.Figure 14
The average end-to-end delay of the third simulation scenario.Figure 15
The average end-to-end delay of the fourth simulation scenario.


#### 6.2.2. Packet Loss

The packet loss ratio is another important metric to assess the delivery performance of data through an IoT environment. The packet loss ratio is the percentage of lost packets to the total sent packets within a time interval under specific buffer sizes (or window sizes). Packet sequence numbers are also analyzed for packets, which are received successfully. The average gross number of lost packets within the simulation time is measured for the third and the fourth simulation scenarios. This metric is measured in environments with different power settings, encoding types, and bandwidth channels. Figure16 shows the packet loss ratio for the third simulation scenario and Figure 17 shows the packet loss ratio for the fourth simulation scenario. The x-axis represents the packet loss ratio and the y-axis represents the simulation time. As stated above in end-to-end delay discussion, the values of packet ratio are calculated for 10 time points. For both third and fourth simulation scenarios, the HAP/HAP/Things architecture has the lowest packet loss ratio and the Satellite/HAP/HAP/Things architecture has the highest packet loss ratio. This is due to long distances between the components of the Satellite/HAP/HAP/Things architecture, which in turn reflects on the data delivery performance. The Satellite/HAP/Things architecture has a packet loss ratio less than that of the Satellite/HAP/HAP/Things architecture and larger than that of the HAP/HAP/Things architecture. Generally, the third simulation scenario has a lower packet loss ratio than the fourth simulation scenario. This is explained by the high bit error rate for satellite and HAP compared with the bit error rate for the ground Internet. In addition, for the third simulation scenario, the number of packets that are sent through satellite or HAP channels is less than the number of packets that are sent through the ground Internet. Moreover, the number of things that is covered by the satellite or HAP is less than the number of things that are covered by ground Internet, which means that the packet loss ratio of the fourth simulation scenario increases continuity due to its use of satellite and HAP in the data transmission process. This is in contrast to the third simulation scenario where most of the IoT data are transmitted by ground Internet. At most simulation time points, the packet loss ratio is stable to some extent. However, the packet loss ratio at little points of simulation time is extremely high (such as 26, 39, 76, and 80). This is due to the large amount of data that can be sent at these simulation times from the IoT nodes (large transmitted data means large packet loss). A sudden increase in transmitted data amounts is due to a sudden increase in the number of nodes that transmit data, which is also an important feature of IoT environments. As stated above, the number of nodes that can transmit data within interval times is determined randomly.Figure 16
The packet loss ratio of the third simulation scenario.Figure 17
The packet loss ratio of the fourth simulation scenario.


#### 6.2.3. Throughput

The throughput of IoT systems can be defined as the number of bits that are successfully delivered from sources to destinations. To determine the efficiency of IoT systems, the throughput metric should be analyzed. Figures18 and 19 show a throughput comparison of the three proposed architectures relative to the third and the fourth simulation scenarios. The results showed that the HAP/HAP/Things architecture has higher throughput than the other two architectures, especially when the bit error rate increases. In the satellite systems, when the utilization of the links exceeds specified thresholds, the rate of packet loss increases dramatically. This explains the throughput superiority of the HAP/HAP/Things architecture in the third and the fourth simulation scenarios. The distance between architecture components also plays an important role in the throughput measurement. It is well known that a minimum number of nodes in the routing path are a targeted efficiency goal. However, sometimes a small number of nodes (with fixed distances between sources and destinations) mean long distances between intermediate path nodes (routers), which in turn means high bit error rates, like that found in the Satellite/HAP/HAP/Things and Satellite/HAP/Things architectures. The sudden increase of throughput value in the first five simulation points comes from a sudden increase in the data sources with low bit error rates and delays. After that, the plots became stable in the three proposed architectures due to regular continuity in sending and receiving data to/from the IoT nodes with high rates. The sending and receiving data in the proposed simulation environments is determined randomly with lower and upper limits, which mostly provide stability in the transmission rates. The passive things throughput value is calculated by the average number of bits sent from their attached RFID tags and received at a specific server (target destination). In Figure 18, minor differences are shown in the throughput values for the three proposed coverage architectures. In Figure 19, significant differences are shown in the throughput values for the proposed coverage architectures, which reflect the impact of high packet delays and losses using the Internet over satellite/HAP network. The throughput value in the third simulation scenario is higher than that in the fourth simulation scenario. This is explained by high bit error rates that may be a result of Internet signals that are transmitted over satellite or HAP that negatively affect the packet loss and the delay metrics. In contrast, the ground Internet provides a reliable data transmission medium for IoT data. Also, high throughputs, which are found in the third and the fourth simulation scenario plots, are explained by large numbers of nodes that are simulated in the IoT environment that provide large and fast data transmission (in contrast, slow transmission decreases the throughput by consuming large amounts of medium time).Figure 18
The throughput of the third simulation scenario.Figure 19
The throughput of the fourth simulation scenario.


#### 6.2.4. Energy Consumption

The IoT system is comprised of energy-based nodes. Energy consumption therefore represents an important factor in the proposed coverage system. Energy savings for each node increase the IoT system lifetime. As stated above, there are three types of networks with energy-based nodes: WSN, RFID, and mobile ad hoc. To test the energy consumption in the three different networks, proposed research techniques were used [55–57]. In the graphs of energy consumption, the x-axis represents 10 simulation time points and the y-axis represents the values of energy consumption. For each network, each energy consumption value that is represented on the y-axis equals the average of node energy consumption within 100 minutes. The number of extracted energy consumption values equals 10 (i.e., 100/1,000). Figure 20 shows energy consumption according to the third simulation scenario. Figures 20(a), 20(b), and 20(c) show energy consumption results for WSN, RFID, and mobile ad hoc network nodes. For the three networks, the HAP/HAP/Things architecture has the lowest energy consumption in the most time points. The next lowest energy consumption is in the Satellite/HAP/Things architecture. The Satellite/HAP/HAP/Things architecture has the largest energy consumption values. It is well known that data communication consumes more energy than data processing or sensing [55]. Short-range communication, like that in HAP/HAP/Things architectures, saves more energy than long-range communication, like that in Satellite/HAP/HAP/Things architecture, which explains the results shown in Figure 20. Figure 20 also shows only a few values that contrast with most energy consumption results (such as points 3, 4 in WSN, points 1, 8, and 2 in RFID, and points 1, 4, and 7 in the mobile ad hoc network). This is explained by the generation of large amounts of data at these time points, which consumes high energy in processing and transmission functions. Figure 21 shows the results of energy consumption for the three networks, WSN, RFID, and mobile ad hoc, according to the fourth simulation scenario. Results shown in Figure 21 are similar to those shown in Figure 20. For the three proposed coverage architectures, the energy consumption of nodes that are covered using tools in the third simulation scenario is less than the energy consumption of nodes that are covered using tools in the fourth simulation scenario. This is due to the communication overhead in addition to the large packet loss ratio, which in turn causes retransmission that increases the total number of transmitted bits.Figure 20
Energy consumption in the third simulation scenario.
(a)
Energy consumption for WSN nodes: third simulation scenario (b)
Energy consumption for RFID nodes: third simulation scenario (c)
Energy consumption for mobile ad hoc nodes: third simulation scenarioFigure 21
Energy consumption in the fourth simulation scenario.
(a)
Energy consumption for WSN nodes: fourth simulation scenario (b)
Energy consumption for RFID nodes: fourth simulation scenario (c)
Energy consumption for mobile ad hoc nodes: fourth simulation scenario


#### 6.2.5. Handover Measurement

To complete the evaluation of the proposed architectures, handover issue should be evaluated. The previous Quality of Service (QoS) metrics are evaluated mostly for immobile nodes or nodes that are moving at slow speed. Therefore, evaluation of these metrics as regards the mobile nodes completes the performance evaluation of the proposed architectures. In the proposed architectures, the flow of signals can be transmitted from HAP segment to satellites segment or from HAP segment to another HAP segment. Transmission of signals from satellite coverage area to another satellite coverage area is not considered due to a large area, which is covered by one satellite. Hence, there are two types of handovers, HAP-to-Satellite and HAP to HAP. Mobile routers, DHCP servers, wireless LANs, wireless LANs, and RFID networks are main components in the IoT system. The handover process comprises three main functions which are stated as follows: information gathering, decision, and execution. Information gathering function is used to determine the thresholds of QoS parameters which are required by the transmitted data. The decision is used to determine whether a handover should be initiated without delay. The execution is used to allocate the required QoS for the transmitted data at the new location. The mobile router is used to achieve the handover process by using mobile server that represents a home agent (HA). In addition, RSVP will be used as a resource reservation protocol in the proposed architectures. Moreover, mobile IP method is used to address the IoT system nodes.To test the handover issue in the proposed architectures, mobile nodes such as mobile phones are used. In the simulation environment, users are randomly distributed under the coverage area of HAP or satellite. The call generation process is governed by Poisson distribution. The exponential distribution is used to determine the change of call holding time. The generated traffic is uniformly distributed. HAP movement starts from the center of the coverage area to its end and then it returns to the other end. The random walk and reflection movements of HAPs are determined in [58]. There are three handover metrics, which are used to determine the QoS of mobile calls. These metrics are the handover probability, the blocking probability, and the drop probability. The HAP speed equals a range between 0 and 150 km/h, the offered traffic equals 2800, the initial position of HAP is at (0, 0, 20) km, and the user mean arrival call rate equals 10 calls/h. The speed of LEO satellite equals 11150 km/h. The handover is measured only in the first scenario of Satellite/HAP/HAP/Things architecture. The handover in the Satellite/HAP/Things and the HAP/HAP/Things architectures is considered a special case form the handover in the Satellite/HAP/HAP/Things architecture. In addition, the things in the second scenarios of the proposed architectures are attached directly to the coverage component (space tings) which means that there is no handover occurrence. The relation between satellite and HAP speeds is described in satellite-HAP networks [59].Figures22, 23, and 24 show the handover probability, the blocking probability, and the dropping probability, respectively, when the handover occurred for generated calls at interlayer and intralayer of the Satellite/HAP/HAP/Things architecture. Interlayer means that the calls are transformed from HAP to HAP in the same layer. Nevertheless, intralayer means that the calls are transformed from one layer to its upper layer. The x-axis represents the speed of HAPs in km/h. The y-axis represents the handover metrics; the handover probability, the blocking probability, and the dropping probability. The three metrics at the architecture third layer level have the lowest values. In addition, the three metrics’ values at the second layer level come after the third layer metrics’ values. Furthermore, the three metrics’ values at the first layer level have the largest values. This could be explained by the high speed of satellite in addition to its high altitude. Also, the three metrics’ values are increased with increasing of HAP or satellite speeds. In Figure 22, there are a little number of speed points such as 130 at which the blocking probability value at the first layer is less than that at the second layer. This is due to the little number of calls which may be generated at this speed point. In Figure 23, the handover probability values increase with HAP speed increase without any hesitations or up-normal values. In Figure 24, there are hesitations in the first and the second layers’ plots. This could be explained by random walk movement of users which makes the dropping probability plots have more hesitations at the first and the second layers. Moreover, it is notable that the three metrics’ values decrease when the speed is decreased. This means that better channels may be available for the new incoming users’ calls. Generally, the handover for HAP to HAP, even for interlayer or intralayer, has the lower values as regards the blocking and the dropping probabilities. This means that the HAP/HAP/Things architecture is recommended to guarantee the required QoS in case of handover.Figure 22
The handover probability in the Satellite/HAP/HAP/Things architecture.Figure 23
The blocking probability in the Satellite/HAP/HAP/Things architecture.Figure 24
The dropping probability in the Satellite/HAP/HAP/Things architecture.


## 6.1. Simulation Setup

The simulation environment was built using the network simulation package, NS2. This environment was comprised of five types of networks: satellite, HAP, WSN, RDIF, and mobile ad hoc networks. There are six satellites that communicate with each other to create a network. The data can be redirected from one satellite to another until it reaches the target satellite. Table1 shows the configuration parameters of the satellite network. In addition, there are 60 HAPs configured in one network. The communication between HAPs may be achieved using inter-HAPs technology or using a selected satellite [11]. Table 2 shows the configuration parameters of the HAP network. Nodes in the other three networks, WSN, RFID, and mobile ad hoc, are distributed randomly in the covered areas for HAPs and satellite networks. The percentage of things covered by the Internet is 75% and the remaining 25% of things are covered by the HAPs and satellite networks. The percentage of things on the ground is 80%, with 15% of things in space, and 5% of things in the sea or underground. The simulation of the IoT environment is flexible since these percentages can be changed dynamically to get accurate performance results for the proposed IoT coverage systems. Tables 3, 4, and 5 contain the configuration parameters of WSN, RDIF, and mobile ad hoc networks, respectively.Table 1
Configuration parameters for satellite simulation.
Parameter Value Satellite type LEO Altitude 800 km Inclination degree 86 (degree) Elevation mask 8.2 (degree) Uplink/downlink 1.5 Mb/s Cell size 50 km Power 1 watt Number of satellites 4 Intersatellite links bandwidth 25 Mb/s Intersatellite links per satellite 6 Cross-seam intersatellite links Not found Intersatellite link delay 7.8 ms Intersatellite distance 60 kmTable 2
Configuration parameters for HAP simulation.
Parameter Value Altitude 20–50 km Bit error rate 10−6 Elevation mask Flat Power 1 watt Return channel HAP 30 Mb/s Forward channel HAP 60 Mb/s Cell size 0.5 to 10 km BS max. Tx power per link 30 dBm Common pilot channel Tx power 27 dBm UL load limit 0.75 BS noise figure 5 dB UE max. TX power 21 dBm SHO add window 3 dB Traffic bit rate 12.2 kbps E b /N 0UL 5 dB E b /N 0DL 9.5 dB Slow fading standard deviation 4 dB DL orthogonality factor 0.9 SHO gain (UL and DL) 1 dB Number of HAPs 60Table 3
Configuration parameters for WSN simulation.
Parameter Value Frequency 2400 MHz Transmit (TX) data rate 250 Kb/s RF power −10 dBm Receive (RX) sensitivity −94 dBm Current drain in transmit mode 11 mA Current drain in receive mode 19.7 mA Battery 2x 1,250 mAH, 1.5 V Covered area 1,000 m × 1,000 m Number of nodes 1,000Table 4
Configuration parameters for RFID simulation.
Parameter Value Data channel frequency 915 MHz Control channel frequency 930 MHz Interchannel interference No Fading No SNR based signal reception 10 Data rate 2 Mbps Radio Rx sensitivity −91 dBm Rx threshold −81 dBm RFID transmission power −45 dBm Read range 1.62 meters Sensing range 5.4 meters Interference range 7.1 meters Number of nodes 1200Table 5
Configuration parameters for mobile ad hoc simulation.
Parameter Value Packet size 1 Mb Network area 500 m × 500 m Total number of requests 3200 Interval between requests’ transmission 500 ms TTL Random between 4 and 7 ms Link availability Between 0 and 1 Maximum transmission distances 30 to 210 m Maximum node speed 30 km/h to 60 km/h Changing direction probability P = 0 Number of nodes 83There are four possible simulation scenarios: full ground Internet coverage, full satellite/HAP network coverage, Internet over satellite/HAP network coverage, and satellite/HAP network with ground Internet coverage. The first scenario supposes that nodes in the IoT environment are covered by ground Internet. Hence, there is no need for satellite and HAP networks as shown in Figure10. In this scenario, each node should have Internet connection capability. Accordingly, most of IoT objects are supposed to be active. This scenario is not considered in the simulation. This is because using ground Internet makes IoT nodes (things) lack full coverage, which does not meet our objective. The second scenario supposes that the IoT objects will be covered using a satellite/HAP network as shown in Figure 11. This scenario does not meet the IoT definition because it does not use the Internet as a communication tool between things. Therefore, this second scenario is also not considered in the simulation. The third scenario supposes that a part of the IoT nodes is covered by ground Internet and other things are covered by satellite or HAP as shown in Figure 12. In this scenario, the communication between IoT objects is not unified; that is, there are two different communication environments, satellite/HAPs and ground Internet. Accordingly, the data can be transmitted to the HAP; it will be directed to the nearest HAP or to the upper satellite layer. A gateway should be present in this scenario to transmit the data from satellite or HAP networks to the Internet and then to the end user or central management system. This third scenario is considered in our simulation because it contains two coverage systems, satellite/HAPs and ground Internet, that meet our objective. The fourth scenario supposes that the IoT nodes are covered by Internet over satellite or HAP as shown in Figure 13. Hence, each node should have an Internet connection using ground Internet or satellite Internet.Figure 10
First simulation scenario: full Internet coverage.Figure 11
Second simulation scenario: full satellite/HAP coverage.Figure 12
Third simulation scenario: satellite/HAP and ground Internet coverage.Figure 13
Fourth simulation scenario: Internet over satellite/HAP coverage.In our simulation, 60 routers are distributed over different locations in five countries. Each router is connected to a number of nodes that is determined randomly, from 50 to 100 nodes (things). The IoT nodes are connected directly to the router or through a sink node that is used to gather information from its things. The relation between routers and HAPs depends on the applied scenario. In addition, there are five servers to manage the Internet routers and other networks such as satellite and HAP. These servers are used by end users for building interactive IoT applications. Additionally, there are six LEO-Iridium satellites, which communicate with 60 HAPS. Each satellite communicates with 10 HAPs. Data is redirected from HAPs in one location to HAPs in different locations using the satellites. The relation between HAPs, satellites, and routers also depends on the executed architecture. The link bandwidth between satellites is 10 Mb/s. The link bandwidth between HAPs and satellites is 10 Mb/s. The link bandwidth between HAPs and routers is 1.5 Mb/s. The bandwidth between routers and sinks or things randomly varies between 1 and 2 Mb/s. The propagation delay of links varies according to the distance between network components, satellites, HAPs, and routers. In our simulation, the propagation delay ranged from 25 to 30 ms. However, the edge propagation delay was 5 ms. The routing paths for transmitting packet streams are determined using optimized link state routing protocols [49] in addition to ant colony optimization [50]. The routing genie is used to adapt the routing process in LEO satellites networks [51, 52]. In addition, in our simulation, the things are divided into two classes, passive and active. The passive things use RFID technology to communicate with satellites, HAPs, or the Internet. The active things can send or receive data to/from other things using coverage methods. There are four types of traffic loads: video, audio, image, and text. MPEG-2 is used as the compression coding for video streams. The compression coding for audio streams is PCM. The coding of images is JPG. Creation of traffic is a random process. The tree topology is used in the proposed architectures. In addition, the ground, space, and underground nodes are distributed randomly to reflect the real meaning of IoT environment. Moreover, the traffic generation model, used in this simulation, is governed by Poisson distribution. Each network component has a buffer to store data packets and redirect them to a predetermined destination. The buffer size of satellites and HAPs is determined using proposed techniques [53, 54]. The buffer size of Internet components, such as routers or servers, is a random value from 100 to 1,000 kb. For Internet connections, the TCP and UDP are used as transport layer protocols. The selection of the transport layer protocol is achieved dynamically depending on the flow size of packet streams and types. In case of network starvation (i.e., the number of lost packets and delay ratio are notably increased), UDP will be used. On the contrary, in the normal case of the IoT system (i.e., the IoT metrics have normal values), TCP will be used. The performance metrics in this simulation are end-to-end delay, packet loss ratio, throughput, energy consumption, and handover. The proposed simulation environment measures these performance metrics for the third and fourth scenarios. The simulation was executed for 1,000 minutes. For best results, five simulation iterations were executed and results averages were determined.


## 6.2. Results and Discussion

In this subsection, the performance metrics, end-to-end delay, packet loss, throughput, energy consumption, and handover are evaluated, and the results are discussed. The performance metrics are measured for the three proposed architectures relative to the third and the fourth simulation scenarios only. The first simulation scenario supposes that the Internet is the only coverage tool for IoT objects and neglects satellite and HAP tools. This scenario is considered a traditional IoT idea that does not meet the targeted objective of this paper. The second simulation scenario also fails to meet the targeted objective because it uses satellite and HAPs only without the Internet and does not meet the typical IoT definition.


### 6.2.1. End-To-End Delay

The end-to-end delay is considered an important performance metric due to the large numbers of data packets that may be transmitted through IoT systems. The end-to-end delay metric is measured from the time a packet is generated to the time it reaches its destination. The end-to-end delay includes the buffering delay that results from queuing packets at sources and destinations. The results of end-to-end delay analysis are shown in Figures14 and 15. The x-axis in the end-to-end graph represents the simulation time in minutes. As stated above, the simulation time is 1,000 minutes. The end-to-end delay is calculated by averaging 10 delay values (one delay value is extracted every minute). The y-axis represents the average end-to-end delay values in milliseconds. Figure 14 shows the end-to-end delay result for the third scenario, and Figure 15 shows the end-to-end delay result for the fourth scenario. Result graphs show that the third simulation scenario has less end-to-end delay values than the fourth scenario. This can be explained as the IoT nodes in the third scenario are covered by ground Internet in addition to the satellite/HAP network. However, the nodes in the fourth scenario are covered by Internet over the satellite/HAP network, which has significant delays caused by long distances. The results shown in Figures 14 and 15 indicate that the best average end-to-end delay is for the HAP/HAP/Things architecture. This is due to the HAP height (or altitude) being less than the satellite height, which means the IoT data can be transmitted with less delay (refer to Section 4). In addition, at the simulation time point 8, the delay is suddenly decreased and smoothly increased in the next simulation time points. This is because the IoT simulation model includes passive things that are randomly distributed, which means the size of IoT data may increase or decrease suddenly. The hesitation in the plots is also due to bandwidth diversity, which is considered a main feature of IoT environments.Figure 14
The average end-to-end delay of the third simulation scenario.Figure 15
The average end-to-end delay of the fourth simulation scenario.


### 6.2.2. Packet Loss

The packet loss ratio is another important metric to assess the delivery performance of data through an IoT environment. The packet loss ratio is the percentage of lost packets to the total sent packets within a time interval under specific buffer sizes (or window sizes). Packet sequence numbers are also analyzed for packets, which are received successfully. The average gross number of lost packets within the simulation time is measured for the third and the fourth simulation scenarios. This metric is measured in environments with different power settings, encoding types, and bandwidth channels. Figure16 shows the packet loss ratio for the third simulation scenario and Figure 17 shows the packet loss ratio for the fourth simulation scenario. The x-axis represents the packet loss ratio and the y-axis represents the simulation time. As stated above in end-to-end delay discussion, the values of packet ratio are calculated for 10 time points. For both third and fourth simulation scenarios, the HAP/HAP/Things architecture has the lowest packet loss ratio and the Satellite/HAP/HAP/Things architecture has the highest packet loss ratio. This is due to long distances between the components of the Satellite/HAP/HAP/Things architecture, which in turn reflects on the data delivery performance. The Satellite/HAP/Things architecture has a packet loss ratio less than that of the Satellite/HAP/HAP/Things architecture and larger than that of the HAP/HAP/Things architecture. Generally, the third simulation scenario has a lower packet loss ratio than the fourth simulation scenario. This is explained by the high bit error rate for satellite and HAP compared with the bit error rate for the ground Internet. In addition, for the third simulation scenario, the number of packets that are sent through satellite or HAP channels is less than the number of packets that are sent through the ground Internet. Moreover, the number of things that is covered by the satellite or HAP is less than the number of things that are covered by ground Internet, which means that the packet loss ratio of the fourth simulation scenario increases continuity due to its use of satellite and HAP in the data transmission process. This is in contrast to the third simulation scenario where most of the IoT data are transmitted by ground Internet. At most simulation time points, the packet loss ratio is stable to some extent. However, the packet loss ratio at little points of simulation time is extremely high (such as 26, 39, 76, and 80). This is due to the large amount of data that can be sent at these simulation times from the IoT nodes (large transmitted data means large packet loss). A sudden increase in transmitted data amounts is due to a sudden increase in the number of nodes that transmit data, which is also an important feature of IoT environments. As stated above, the number of nodes that can transmit data within interval times is determined randomly.Figure 16
The packet loss ratio of the third simulation scenario.Figure 17
The packet loss ratio of the fourth simulation scenario.


### 6.2.3. Throughput

The throughput of IoT systems can be defined as the number of bits that are successfully delivered from sources to destinations. To determine the efficiency of IoT systems, the throughput metric should be analyzed. Figures18 and 19 show a throughput comparison of the three proposed architectures relative to the third and the fourth simulation scenarios. The results showed that the HAP/HAP/Things architecture has higher throughput than the other two architectures, especially when the bit error rate increases. In the satellite systems, when the utilization of the links exceeds specified thresholds, the rate of packet loss increases dramatically. This explains the throughput superiority of the HAP/HAP/Things architecture in the third and the fourth simulation scenarios. The distance between architecture components also plays an important role in the throughput measurement. It is well known that a minimum number of nodes in the routing path are a targeted efficiency goal. However, sometimes a small number of nodes (with fixed distances between sources and destinations) mean long distances between intermediate path nodes (routers), which in turn means high bit error rates, like that found in the Satellite/HAP/HAP/Things and Satellite/HAP/Things architectures. The sudden increase of throughput value in the first five simulation points comes from a sudden increase in the data sources with low bit error rates and delays. After that, the plots became stable in the three proposed architectures due to regular continuity in sending and receiving data to/from the IoT nodes with high rates. The sending and receiving data in the proposed simulation environments is determined randomly with lower and upper limits, which mostly provide stability in the transmission rates. The passive things throughput value is calculated by the average number of bits sent from their attached RFID tags and received at a specific server (target destination). In Figure 18, minor differences are shown in the throughput values for the three proposed coverage architectures. In Figure 19, significant differences are shown in the throughput values for the proposed coverage architectures, which reflect the impact of high packet delays and losses using the Internet over satellite/HAP network. The throughput value in the third simulation scenario is higher than that in the fourth simulation scenario. This is explained by high bit error rates that may be a result of Internet signals that are transmitted over satellite or HAP that negatively affect the packet loss and the delay metrics. In contrast, the ground Internet provides a reliable data transmission medium for IoT data. Also, high throughputs, which are found in the third and the fourth simulation scenario plots, are explained by large numbers of nodes that are simulated in the IoT environment that provide large and fast data transmission (in contrast, slow transmission decreases the throughput by consuming large amounts of medium time).Figure 18
The throughput of the third simulation scenario.Figure 19
The throughput of the fourth simulation scenario.


### 6.2.4. Energy Consumption

The IoT system is comprised of energy-based nodes. Energy consumption therefore represents an important factor in the proposed coverage system. Energy savings for each node increase the IoT system lifetime. As stated above, there are three types of networks with energy-based nodes: WSN, RFID, and mobile ad hoc. To test the energy consumption in the three different networks, proposed research techniques were used [55–57]. In the graphs of energy consumption, the x-axis represents 10 simulation time points and the y-axis represents the values of energy consumption. For each network, each energy consumption value that is represented on the y-axis equals the average of node energy consumption within 100 minutes. The number of extracted energy consumption values equals 10 (i.e., 100/1,000). Figure 20 shows energy consumption according to the third simulation scenario. Figures 20(a), 20(b), and 20(c) show energy consumption results for WSN, RFID, and mobile ad hoc network nodes. For the three networks, the HAP/HAP/Things architecture has the lowest energy consumption in the most time points. The next lowest energy consumption is in the Satellite/HAP/Things architecture. The Satellite/HAP/HAP/Things architecture has the largest energy consumption values. It is well known that data communication consumes more energy than data processing or sensing [55]. Short-range communication, like that in HAP/HAP/Things architectures, saves more energy than long-range communication, like that in Satellite/HAP/HAP/Things architecture, which explains the results shown in Figure 20. Figure 20 also shows only a few values that contrast with most energy consumption results (such as points 3, 4 in WSN, points 1, 8, and 2 in RFID, and points 1, 4, and 7 in the mobile ad hoc network). This is explained by the generation of large amounts of data at these time points, which consumes high energy in processing and transmission functions. Figure 21 shows the results of energy consumption for the three networks, WSN, RFID, and mobile ad hoc, according to the fourth simulation scenario. Results shown in Figure 21 are similar to those shown in Figure 20. For the three proposed coverage architectures, the energy consumption of nodes that are covered using tools in the third simulation scenario is less than the energy consumption of nodes that are covered using tools in the fourth simulation scenario. This is due to the communication overhead in addition to the large packet loss ratio, which in turn causes retransmission that increases the total number of transmitted bits.Figure 20
Energy consumption in the third simulation scenario.
(a)
Energy consumption for WSN nodes: third simulation scenario (b)
Energy consumption for RFID nodes: third simulation scenario (c)
Energy consumption for mobile ad hoc nodes: third simulation scenarioFigure 21
Energy consumption in the fourth simulation scenario.
(a)
Energy consumption for WSN nodes: fourth simulation scenario (b)
Energy consumption for RFID nodes: fourth simulation scenario (c)
Energy consumption for mobile ad hoc nodes: fourth simulation scenario


### 6.2.5. Handover Measurement

To complete the evaluation of the proposed architectures, handover issue should be evaluated. The previous Quality of Service (QoS) metrics are evaluated mostly for immobile nodes or nodes that are moving at slow speed. Therefore, evaluation of these metrics as regards the mobile nodes completes the performance evaluation of the proposed architectures. In the proposed architectures, the flow of signals can be transmitted from HAP segment to satellites segment or from HAP segment to another HAP segment. Transmission of signals from satellite coverage area to another satellite coverage area is not considered due to a large area, which is covered by one satellite. Hence, there are two types of handovers, HAP-to-Satellite and HAP to HAP. Mobile routers, DHCP servers, wireless LANs, wireless LANs, and RFID networks are main components in the IoT system. The handover process comprises three main functions which are stated as follows: information gathering, decision, and execution. Information gathering function is used to determine the thresholds of QoS parameters which are required by the transmitted data. The decision is used to determine whether a handover should be initiated without delay. The execution is used to allocate the required QoS for the transmitted data at the new location. The mobile router is used to achieve the handover process by using mobile server that represents a home agent (HA). In addition, RSVP will be used as a resource reservation protocol in the proposed architectures. Moreover, mobile IP method is used to address the IoT system nodes.To test the handover issue in the proposed architectures, mobile nodes such as mobile phones are used. In the simulation environment, users are randomly distributed under the coverage area of HAP or satellite. The call generation process is governed by Poisson distribution. The exponential distribution is used to determine the change of call holding time. The generated traffic is uniformly distributed. HAP movement starts from the center of the coverage area to its end and then it returns to the other end. The random walk and reflection movements of HAPs are determined in [58]. There are three handover metrics, which are used to determine the QoS of mobile calls. These metrics are the handover probability, the blocking probability, and the drop probability. The HAP speed equals a range between 0 and 150 km/h, the offered traffic equals 2800, the initial position of HAP is at (0, 0, 20) km, and the user mean arrival call rate equals 10 calls/h. The speed of LEO satellite equals 11150 km/h. The handover is measured only in the first scenario of Satellite/HAP/HAP/Things architecture. The handover in the Satellite/HAP/Things and the HAP/HAP/Things architectures is considered a special case form the handover in the Satellite/HAP/HAP/Things architecture. In addition, the things in the second scenarios of the proposed architectures are attached directly to the coverage component (space tings) which means that there is no handover occurrence. The relation between satellite and HAP speeds is described in satellite-HAP networks [59].Figures22, 23, and 24 show the handover probability, the blocking probability, and the dropping probability, respectively, when the handover occurred for generated calls at interlayer and intralayer of the Satellite/HAP/HAP/Things architecture. Interlayer means that the calls are transformed from HAP to HAP in the same layer. Nevertheless, intralayer means that the calls are transformed from one layer to its upper layer. The x-axis represents the speed of HAPs in km/h. The y-axis represents the handover metrics; the handover probability, the blocking probability, and the dropping probability. The three metrics at the architecture third layer level have the lowest values. In addition, the three metrics’ values at the second layer level come after the third layer metrics’ values. Furthermore, the three metrics’ values at the first layer level have the largest values. This could be explained by the high speed of satellite in addition to its high altitude. Also, the three metrics’ values are increased with increasing of HAP or satellite speeds. In Figure 22, there are a little number of speed points such as 130 at which the blocking probability value at the first layer is less than that at the second layer. This is due to the little number of calls which may be generated at this speed point. In Figure 23, the handover probability values increase with HAP speed increase without any hesitations or up-normal values. In Figure 24, there are hesitations in the first and the second layers’ plots. This could be explained by random walk movement of users which makes the dropping probability plots have more hesitations at the first and the second layers. Moreover, it is notable that the three metrics’ values decrease when the speed is decreased. This means that better channels may be available for the new incoming users’ calls. Generally, the handover for HAP to HAP, even for interlayer or intralayer, has the lower values as regards the blocking and the dropping probabilities. This means that the HAP/HAP/Things architecture is recommended to guarantee the required QoS in case of handover.Figure 22
The handover probability in the Satellite/HAP/HAP/Things architecture.Figure 23
The blocking probability in the Satellite/HAP/HAP/Things architecture.Figure 24
The dropping probability in the Satellite/HAP/HAP/Things architecture.


## 6.2.1. End-To-End Delay

The end-to-end delay is considered an important performance metric due to the large numbers of data packets that may be transmitted through IoT systems. The end-to-end delay metric is measured from the time a packet is generated to the time it reaches its destination. The end-to-end delay includes the buffering delay that results from queuing packets at sources and destinations. The results of end-to-end delay analysis are shown in Figures14 and 15. The x-axis in the end-to-end graph represents the simulation time in minutes. As stated above, the simulation time is 1,000 minutes. The end-to-end delay is calculated by averaging 10 delay values (one delay value is extracted every minute). The y-axis represents the average end-to-end delay values in milliseconds. Figure 14 shows the end-to-end delay result for the third scenario, and Figure 15 shows the end-to-end delay result for the fourth scenario. Result graphs show that the third simulation scenario has less end-to-end delay values than the fourth scenario. This can be explained as the IoT nodes in the third scenario are covered by ground Internet in addition to the satellite/HAP network. However, the nodes in the fourth scenario are covered by Internet over the satellite/HAP network, which has significant delays caused by long distances. The results shown in Figures 14 and 15 indicate that the best average end-to-end delay is for the HAP/HAP/Things architecture. This is due to the HAP height (or altitude) being less than the satellite height, which means the IoT data can be transmitted with less delay (refer to Section 4). In addition, at the simulation time point 8, the delay is suddenly decreased and smoothly increased in the next simulation time points. This is because the IoT simulation model includes passive things that are randomly distributed, which means the size of IoT data may increase or decrease suddenly. The hesitation in the plots is also due to bandwidth diversity, which is considered a main feature of IoT environments.Figure 14
The average end-to-end delay of the third simulation scenario.Figure 15
The average end-to-end delay of the fourth simulation scenario.


## 6.2.2. Packet Loss

The packet loss ratio is another important metric to assess the delivery performance of data through an IoT environment. The packet loss ratio is the percentage of lost packets to the total sent packets within a time interval under specific buffer sizes (or window sizes). Packet sequence numbers are also analyzed for packets, which are received successfully. The average gross number of lost packets within the simulation time is measured for the third and the fourth simulation scenarios. This metric is measured in environments with different power settings, encoding types, and bandwidth channels. Figure16 shows the packet loss ratio for the third simulation scenario and Figure 17 shows the packet loss ratio for the fourth simulation scenario. The x-axis represents the packet loss ratio and the y-axis represents the simulation time. As stated above in end-to-end delay discussion, the values of packet ratio are calculated for 10 time points. For both third and fourth simulation scenarios, the HAP/HAP/Things architecture has the lowest packet loss ratio and the Satellite/HAP/HAP/Things architecture has the highest packet loss ratio. This is due to long distances between the components of the Satellite/HAP/HAP/Things architecture, which in turn reflects on the data delivery performance. The Satellite/HAP/Things architecture has a packet loss ratio less than that of the Satellite/HAP/HAP/Things architecture and larger than that of the HAP/HAP/Things architecture. Generally, the third simulation scenario has a lower packet loss ratio than the fourth simulation scenario. This is explained by the high bit error rate for satellite and HAP compared with the bit error rate for the ground Internet. In addition, for the third simulation scenario, the number of packets that are sent through satellite or HAP channels is less than the number of packets that are sent through the ground Internet. Moreover, the number of things that is covered by the satellite or HAP is less than the number of things that are covered by ground Internet, which means that the packet loss ratio of the fourth simulation scenario increases continuity due to its use of satellite and HAP in the data transmission process. This is in contrast to the third simulation scenario where most of the IoT data are transmitted by ground Internet. At most simulation time points, the packet loss ratio is stable to some extent. However, the packet loss ratio at little points of simulation time is extremely high (such as 26, 39, 76, and 80). This is due to the large amount of data that can be sent at these simulation times from the IoT nodes (large transmitted data means large packet loss). A sudden increase in transmitted data amounts is due to a sudden increase in the number of nodes that transmit data, which is also an important feature of IoT environments. As stated above, the number of nodes that can transmit data within interval times is determined randomly.Figure 16
The packet loss ratio of the third simulation scenario.Figure 17
The packet loss ratio of the fourth simulation scenario.


## 6.2.3. Throughput

The throughput of IoT systems can be defined as the number of bits that are successfully delivered from sources to destinations. To determine the efficiency of IoT systems, the throughput metric should be analyzed. Figures18 and 19 show a throughput comparison of the three proposed architectures relative to the third and the fourth simulation scenarios. The results showed that the HAP/HAP/Things architecture has higher throughput than the other two architectures, especially when the bit error rate increases. In the satellite systems, when the utilization of the links exceeds specified thresholds, the rate of packet loss increases dramatically. This explains the throughput superiority of the HAP/HAP/Things architecture in the third and the fourth simulation scenarios. The distance between architecture components also plays an important role in the throughput measurement. It is well known that a minimum number of nodes in the routing path are a targeted efficiency goal. However, sometimes a small number of nodes (with fixed distances between sources and destinations) mean long distances between intermediate path nodes (routers), which in turn means high bit error rates, like that found in the Satellite/HAP/HAP/Things and Satellite/HAP/Things architectures. The sudden increase of throughput value in the first five simulation points comes from a sudden increase in the data sources with low bit error rates and delays. After that, the plots became stable in the three proposed architectures due to regular continuity in sending and receiving data to/from the IoT nodes with high rates. The sending and receiving data in the proposed simulation environments is determined randomly with lower and upper limits, which mostly provide stability in the transmission rates. The passive things throughput value is calculated by the average number of bits sent from their attached RFID tags and received at a specific server (target destination). In Figure 18, minor differences are shown in the throughput values for the three proposed coverage architectures. In Figure 19, significant differences are shown in the throughput values for the proposed coverage architectures, which reflect the impact of high packet delays and losses using the Internet over satellite/HAP network. The throughput value in the third simulation scenario is higher than that in the fourth simulation scenario. This is explained by high bit error rates that may be a result of Internet signals that are transmitted over satellite or HAP that negatively affect the packet loss and the delay metrics. In contrast, the ground Internet provides a reliable data transmission medium for IoT data. Also, high throughputs, which are found in the third and the fourth simulation scenario plots, are explained by large numbers of nodes that are simulated in the IoT environment that provide large and fast data transmission (in contrast, slow transmission decreases the throughput by consuming large amounts of medium time).Figure 18
The throughput of the third simulation scenario.Figure 19
The throughput of the fourth simulation scenario.


## 6.2.4. Energy Consumption

The IoT system is comprised of energy-based nodes. Energy consumption therefore represents an important factor in the proposed coverage system. Energy savings for each node increase the IoT system lifetime. As stated above, there are three types of networks with energy-based nodes: WSN, RFID, and mobile ad hoc. To test the energy consumption in the three different networks, proposed research techniques were used [55–57]. In the graphs of energy consumption, the x-axis represents 10 simulation time points and the y-axis represents the values of energy consumption. For each network, each energy consumption value that is represented on the y-axis equals the average of node energy consumption within 100 minutes. The number of extracted energy consumption values equals 10 (i.e., 100/1,000). Figure 20 shows energy consumption according to the third simulation scenario. Figures 20(a), 20(b), and 20(c) show energy consumption results for WSN, RFID, and mobile ad hoc network nodes. For the three networks, the HAP/HAP/Things architecture has the lowest energy consumption in the most time points. The next lowest energy consumption is in the Satellite/HAP/Things architecture. The Satellite/HAP/HAP/Things architecture has the largest energy consumption values. It is well known that data communication consumes more energy than data processing or sensing [55]. Short-range communication, like that in HAP/HAP/Things architectures, saves more energy than long-range communication, like that in Satellite/HAP/HAP/Things architecture, which explains the results shown in Figure 20. Figure 20 also shows only a few values that contrast with most energy consumption results (such as points 3, 4 in WSN, points 1, 8, and 2 in RFID, and points 1, 4, and 7 in the mobile ad hoc network). This is explained by the generation of large amounts of data at these time points, which consumes high energy in processing and transmission functions. Figure 21 shows the results of energy consumption for the three networks, WSN, RFID, and mobile ad hoc, according to the fourth simulation scenario. Results shown in Figure 21 are similar to those shown in Figure 20. For the three proposed coverage architectures, the energy consumption of nodes that are covered using tools in the third simulation scenario is less than the energy consumption of nodes that are covered using tools in the fourth simulation scenario. This is due to the communication overhead in addition to the large packet loss ratio, which in turn causes retransmission that increases the total number of transmitted bits.Figure 20
Energy consumption in the third simulation scenario.
(a)
Energy consumption for WSN nodes: third simulation scenario (b)
Energy consumption for RFID nodes: third simulation scenario (c)
Energy consumption for mobile ad hoc nodes: third simulation scenarioFigure 21
Energy consumption in the fourth simulation scenario.
(a)
Energy consumption for WSN nodes: fourth simulation scenario (b)
Energy consumption for RFID nodes: fourth simulation scenario (c)
Energy consumption for mobile ad hoc nodes: fourth simulation scenario


## 6.2.5. Handover Measurement

To complete the evaluation of the proposed architectures, handover issue should be evaluated. The previous Quality of Service (QoS) metrics are evaluated mostly for immobile nodes or nodes that are moving at slow speed. Therefore, evaluation of these metrics as regards the mobile nodes completes the performance evaluation of the proposed architectures. In the proposed architectures, the flow of signals can be transmitted from HAP segment to satellites segment or from HAP segment to another HAP segment. Transmission of signals from satellite coverage area to another satellite coverage area is not considered due to a large area, which is covered by one satellite. Hence, there are two types of handovers, HAP-to-Satellite and HAP to HAP. Mobile routers, DHCP servers, wireless LANs, wireless LANs, and RFID networks are main components in the IoT system. The handover process comprises three main functions which are stated as follows: information gathering, decision, and execution. Information gathering function is used to determine the thresholds of QoS parameters which are required by the transmitted data. The decision is used to determine whether a handover should be initiated without delay. The execution is used to allocate the required QoS for the transmitted data at the new location. The mobile router is used to achieve the handover process by using mobile server that represents a home agent (HA). In addition, RSVP will be used as a resource reservation protocol in the proposed architectures. Moreover, mobile IP method is used to address the IoT system nodes.To test the handover issue in the proposed architectures, mobile nodes such as mobile phones are used. In the simulation environment, users are randomly distributed under the coverage area of HAP or satellite. The call generation process is governed by Poisson distribution. The exponential distribution is used to determine the change of call holding time. The generated traffic is uniformly distributed. HAP movement starts from the center of the coverage area to its end and then it returns to the other end. The random walk and reflection movements of HAPs are determined in [58]. There are three handover metrics, which are used to determine the QoS of mobile calls. These metrics are the handover probability, the blocking probability, and the drop probability. The HAP speed equals a range between 0 and 150 km/h, the offered traffic equals 2800, the initial position of HAP is at (0, 0, 20) km, and the user mean arrival call rate equals 10 calls/h. The speed of LEO satellite equals 11150 km/h. The handover is measured only in the first scenario of Satellite/HAP/HAP/Things architecture. The handover in the Satellite/HAP/Things and the HAP/HAP/Things architectures is considered a special case form the handover in the Satellite/HAP/HAP/Things architecture. In addition, the things in the second scenarios of the proposed architectures are attached directly to the coverage component (space tings) which means that there is no handover occurrence. The relation between satellite and HAP speeds is described in satellite-HAP networks [59].Figures22, 23, and 24 show the handover probability, the blocking probability, and the dropping probability, respectively, when the handover occurred for generated calls at interlayer and intralayer of the Satellite/HAP/HAP/Things architecture. Interlayer means that the calls are transformed from HAP to HAP in the same layer. Nevertheless, intralayer means that the calls are transformed from one layer to its upper layer. The x-axis represents the speed of HAPs in km/h. The y-axis represents the handover metrics; the handover probability, the blocking probability, and the dropping probability. The three metrics at the architecture third layer level have the lowest values. In addition, the three metrics’ values at the second layer level come after the third layer metrics’ values. Furthermore, the three metrics’ values at the first layer level have the largest values. This could be explained by the high speed of satellite in addition to its high altitude. Also, the three metrics’ values are increased with increasing of HAP or satellite speeds. In Figure 22, there are a little number of speed points such as 130 at which the blocking probability value at the first layer is less than that at the second layer. This is due to the little number of calls which may be generated at this speed point. In Figure 23, the handover probability values increase with HAP speed increase without any hesitations or up-normal values. In Figure 24, there are hesitations in the first and the second layers’ plots. This could be explained by random walk movement of users which makes the dropping probability plots have more hesitations at the first and the second layers. Moreover, it is notable that the three metrics’ values decrease when the speed is decreased. This means that better channels may be available for the new incoming users’ calls. Generally, the handover for HAP to HAP, even for interlayer or intralayer, has the lower values as regards the blocking and the dropping probabilities. This means that the HAP/HAP/Things architecture is recommended to guarantee the required QoS in case of handover.Figure 22
The handover probability in the Satellite/HAP/HAP/Things architecture.Figure 23
The blocking probability in the Satellite/HAP/HAP/Things architecture.Figure 24
The dropping probability in the Satellite/HAP/HAP/Things architecture.


## 7. Conclusion

This paper has demonstrated a dual coverage system in which IoT objects are covered regardless of their locations and access to ground Internet. This coverage system is implemented with three main architectures. The proposed multilevel architectures have hierarchical shapes and consist of satellites and/or HAPs. Two scenarios were examined for the proposed architectures related to the locations of IoT objects, on the ground or directly attached to satellites or HAPs. The research reported in this paper showed that the Satellite/HAP/HAP/Things architecture provides the largest coverage area and the HAP/HAP/Things architecture (with a small number of HAPs) has the lowest coverage area. A simulation environment was constructed using a network simulation package, NS2, to test the performance of the proposed architectures under two scenarios. The simulation results showed that the HAP/HAP/Things architecture has the lowest end-to-end delay, packet loss ratio, and nodes energy consumption, in addition to the largest throughput and smooth handover when compared to the other proposed architectures. The Satellite/HAP/Ground Internet scenario is recommended rather than the Internet over Satellite/HAP network scenario, assuming that the number of HAPs is a considered parameter in the coverage architecture design.


## 8. Future Work

In the future work, different codings of multimedia such as MPEG-4 should be transmitted through the proposed architectures and the results should be discussed. In addition, in order to get the nearest spec of IoT environment, the complexity of simulation should be increased. Furthermore, study of data flow through the components of each layer in the proposed architectures should be accomplished.



---

*Source: 3464392-2016-12-20.xml*