9.2.1. Tactile edge A

The tactile edge produces haptic data, as well as other conventional Internet data. The production of application data depends on the use cases, which are identified by IEEE 1918.1 as follows (Aijaz et al. 2018):

1. 1) “teleoperation;
2. 2) automotive;
3. 3) immersive virtual reality (IVR);
4. 4) Internet of drones;
5. 5) interpersonal communication;
6. 6) live haptic-enabled broadcast;
7. 7) cooperative automated driving”.

As a part of the tactile edge, the GNC plays an important role in the interoperability of the tactile edge with any kind of network domain; all of the functionalities related to QoS are performed there. However, the design of the GNC was not described extensively in IEEE 1918.1, although all management and orchestration functionalities are implemented there. We therefore suggest a new design for the GNC that can be adapted to the different use cases. Indeed, the GNC can be considered as the interface between the master, slave and the network domain, as it is not only forwarding data to the network domain, but also applying some rules and mechanisms of QoS to guarantee the requirements of the different audio, video and haptic data generated in the human-to-human and/or human-to-machine communications. The challenge that should be addressed by the GNC, is how to satisfy the QoS constraints for each media type. Specifically, violating the haptic QoS constraints would destabilize the global control loop, leading to undesirable consequences on the ongoing applications (Al Ja’afreh et al. 2018). Indeed, the classical definition of QoS is associated with the ability of a network to provide the required services for the different types of traffic that are generated throughout the network. In the context of TI with a mixture of traffic (traditional and haptic data), which can be again classified as mission or non-mission critical, the primary goal is to provide priority with respect to their requirements of QoS. Hence, adding a method to distinguish among the application flows in the tactile edge will guarantee the required resources for the critical applications. Meanwhile, this differentiation requires constantly obtaining knowledge of the state of the network, so an appropriate decision regarding packet forwarding should be made (Luo et al. 2012; Zhou et al. 2016). Hence, we suggest the introduction of the following modules in the GNC, in order to intercept the flows and decide how to deal with them depending on their type. These modules are listed below with brief descriptions (see Figure 9.1):

• – the admission and congestion control module is designed to decide whether or not to reject the requests from TDs, in case their QoS requirements are violated, and then send feedback status information to them;
• – the QoS mapping module performs QoS mapping through a process of automatic translation between the representations of QoS flows and the QoS mechanisms for different technologies. This module is very important since the GNC has several interfaces; wired and wireless connecting the tactile edge to the network domain;
• – the resource monitoring module makes use of the statistics of the current network states in terms of bandwidth, load, delays, etc. that are collected and maintained to make them available for the resource management module;
• – the resource management and optimization module is responsible for managing resources efficiently, by providing E2E bandwidth guarantees, especially for those flows with higher priority. This is achieved by configuring the output queues of the GNC node, according to scheduling algorithms and policies that give the haptic data a higher priority compared to the other types of data.

In our architecture, we propose a broad range of interfaces for the GNC (A, O and S interfaces) in order to connect different TDs to the network domain. Practically, it can have an interface to the network domain through the 5G NR network and another one through fiber optics. The latter is used for mission critical applications that require ultra-low latency, just like real-time teleoperations, while it can have WiFi or other interfaces connected with the TDs (T_b interface).

9.2.2. Network domain

In order to deliver TI services, we use 5G as the network domain starting from the RAN to the core network, as shown in Table 9.1. We map the functionalities of the UPE of the TI to UPF in 5G, as both are responsible for user plane functions, such as context activation, data forwarding to external networks and QoS support. The CPE is mapped to the corresponding modules in the 5G control plane, i.e. AMF, SMF, PCF, AUSF, UDM and NSSF, which are responsible for mobility management, policy and charging mechanism, and network slicing functionalities. The functionalities of the TSM are covered by the AF, NEF and NRF modules, since they are responsible for defining the characteristics of the services and exposing them to the tactile edges.

Finally, in the tactile edge, we propose to map the SE to the MEC entity that delivers cloud computing services directly at the edge of the network, as well as carrying out other highly intelligent capabilities, such as caching and improving QoE. IEEE 1918.1 specifies that SE can be located in the tactile edge A or in the network domain. However, we propose to integrate the MEC in the network domain. The MEC can be collocated with a local UPF, as shown in Figure 9.2. This is due to the fact that the 5G user plane is delegated to UPF, as it is playing a central role in routing the traffic to desired applications and network functions.

9.2.3. Protocol stack of 5G integration with IEEE 1918.1

The protocol stack that was adopted by IEEE 1918.1 is based on the TCP/IP model. Figure 9.3 shows both the user and control planes, as well as the connectivity between the layers starting from the TD to the core network of the 5G, which is our selected transport network for the haptic data. The user plane protocol stack starts from the TD that provides haptic, sensing and other types of data to the GNC. However, depending on the type of application generating the data, the application layer protocols will differ. For example, real-time protocol for interactive applications (RTP/I) can be adopted for classical Internet real-time applications, while haptic over IP (HoIP) can be used for haptic applications, where an adaptive sampling rate is needed. The GNC has a dual-protocol stack: one of them is based on the WiFi and/or Ethernet so that it can be connected to a network of TDs, and the other one is the 5G NR protocol stack that is connected to the gNB using NR via the T_b interface (3GPP 2018). Regarding the control plane, layers 1 and 2 of the protocol stack of the TD are the same as the ones used in the user plane; however, the third layer will be different since it is using the control plane protocol (CPP) to handle all of the functionalities related to the control plane, such as registration and authentication. Again, the key interoperability or connectivity between the tactile edge and the network domain is the GNC, which has two interfaces: one is used to be connected to the TD through the CPP, and the other one is represented by the 5G NR that connects the GNC to the gNB, as well as to the AMF, through the non-access-stratum (NAS) protocol, which provides the authentication, security, IP assignment, etc.

9.4.1. Master to slave (uplink) data rate in edge A

In this section, the amount of control and data bits from the master to the slave domain is found after digitizing the position and force data, in addition to a number of overhead bits. These bits are needed to differentiate the multiplexed data from the different sensors.

First, to find the amount of position data generated by the glove on the master side, we will fix the sampling of the sensors on the glove side to 1,000 Hz, which is faster than the speed of movement of a hand executing a thorough operation. Thus, we will have five analogue bending sensors on the glove, assuming eight bits ADC and three bits to distinguish between the five fingers’ information; then, 1, 000 · 5 · (8 + 3) = 55, 000 bits/sec are generated. Second, the hand orientation is sensed by the use of three gyroscopes, using 10 bit A/D converters and 1,000 Hz sampling rate, and two bits overhead to address the pitch, roll and yaw rotations; we then get: 1, 000 · 3 · (10 + 2) = 36, 000 bits/sec. Finally, for the six force pressure sensors, there will be one per fingertip, plus one on the palm of the hand and three bits overhead to address the different sensors. A sampling frequency of 1,000 Hz will produce: 1, 000 · 6 · (10 + 3) = 78, 000 bits/sec. According to the previous calculations, the total number of bits per second for the position orientation and force pressure data is then 169,000 bits/sec. This gives a total of 169 bits/ms or 169 bits/packet for a sampling rate of 1 kHz.

9.4.2. Slave to master (downlink) data rate in edge B

On the slave TD edge side, we suggest video media augmented with force/pressure sensors to close the global control loop. For the six force/pressure sensors sampled at 1 kHz, 10 bits ADC and the three addressing bits, we have 1, 000 · 6 · (10 + 3) = 78, 000 bits/sec. We use the the H.264 codec for video data compression. For an acceptable video quality, a data bit rate between 0.500 and 1.5 Mbps is possible (Tamhankar and Rao 2003). By considering the highest data bit rate of 1.5 Mbits/sec, a total of 1,500 kbps + 78 kbps = 1,578 kbits/sec of raw data has to be sent from the slave side.

9.4.3. Encapsulating the haptic data in HoIP

Upon the multiplexing of the raw data, a haptic protocol should be used to insert some additional overheads, which is specific to haptic operations. To this end, we use the HoIP (Gokhale et al. 2013a, 2015). This protocol is more useful in the case of adaptive haptic sampling, where connection speed can be restricted.

Depending on the GNC type on the user plan (see Figure 9.8), the HoIP acts as the application layer, which in turn becomes the application layer of the 5G UE in our use case. Otherwise, if heterogeneous TD with different communication stacks are available, then the HoIP should be implemented on the top of the TD stack.

In order to find the number of overhead bits added to the previously calculated position and force/pressure data, we use the format suggested in Gokhale et al. (2013a). This encapsulates the data into segments and packets, and then consequently transport frames. The HoIP can be implemented in both the master and slave domains, and the following calculations show the amount of overhead added by the different layers, starting from the HoIP layer to the IP layer:

• – Master to slave: starting from the application layer, the HoIP overhead per packet is found by adding the HoIP, UDP and IP. We can then obtain the number of overheads by adding 96 (HoIP) + 64 (UDP) + 192 (IP), giving 352 bits/packet. Summing both data and overhead, we obtain 169 + 352 = 521 bits/packet (i.e. 521 kbps in the uplink direction).
• – Slave to master: on this side, we have five force sensors for each of the robotic hand fingertips and one in the palm of the mechanical hand, in addition to the video signal. By using the same application layer protocol and a sampling rate of 1,000 samples/sec, we obtain 1, 000.6.(10 + 3) = 78, 000 bps. A proportional-integral-derivative (PID) system can be used on the slave side to generate the haptic signal feedback to the operator side (master domain), before encapsulating it into the HoIP and then the UDP and IP layers. The total number of bits per packet (data+overhead) obtained from the slave side is: 78 + 1, 500 + 352 = 1, 930 bits/ms or (1,930 bits/packet) on the uplink path of the slave side.

9.4.4. 5G network data and control handling

In the previous sections, we found the data rates necessary for a correct functioning of the system. Here, we will check the possibility of transmitting these data rates on a 5G NR wireless network with an acceptable delay. This can be achieved by analyzing the frame structure of the UL and DL radio communications, since they have a significant impact on the QoS parameters, such as latency and throughput (Vihriala et al. 2016).

The NR interface has some new features like the massive multiple-input multiple-output (MIMO), small-size base stations, carrier aggregation (CA), beamforming and full-duplex. These evolutions are largely introduced in the physical layer (Zaidi et al. 2016). The NR is envisioned to operate from sub-1 GHz to 100 GHz to cover a variety of services and deployment options. It supports scalable OFDM numerology, with 2ⁿ scaling of subcarrier spacing, which creates a family of OFDM waveforms with frame structures for the NR–air interface (Zaidi et al. 2016; Jeon 2018). This family is classified into FR1, which supports the subcarrier spacings of 15, 30 and 60 kHz, and FR2, which supports the subcarrier spacings of 60 and 120 kHz (Jeon 2018). The NR supports the QPSK, 16QAM, 64QAM and 256QAM modulation schemes for downlink and uplink transmissions (ETSI 2018d). Based on these physical layer parameters and the data rate estimated in the previous section, the feasibility of our use case can be determined. Assuming the configurations, as shown in Table 9.3, we can calculate the total data rate per subframe (where 1 subframe = 1 ms) that the radio access can handle as follows:

(Number of symbols per subslot · Number of subcarriers · Number of bits per OFDM symbol · Number of resource blocks (RB) · Number of slots per subframe)

which gives a total of:

The part of the synchronization signal block (SSB) used for the synchronization and cell search for the above case, can be found to be 6% of a subframe length (see Campos (2017)). Therefore, 0.94 * 26, 880 = 25, 536 bits/subframe can be used for data and control for both UL and DL connections.

In fact, two types of information elements are exchanged through the radio links, namely cell search and synchronization control, and data and control. We are interested in finding out the overall generated bits. In the following, we will find out part of the radio link utilization:

• – Synchronization and cell search: the NR supports a multi-beam operation using SSB, which is repeated L times to make an SS burst. The repetition of many bursts within 5 ms is called a burst set, which is used for a gNB beam-sweeping transmission. The periodicity of the burst set is of 20 ms (ETSI 2018e; Omri et al. 2019). The maximum number of L depends on the numerology used for the physical layer (ETSI 2018e). Considering the case with 15 kHz subcarrier spacing, L = 4 for carrier frequency f < 3GHz. This gives a total of 280 symbols for two frames, since the periodicity of a burst set is 20 ms. Knowing that the PSS, SSS and PBCH channels occupy four OFDM symbols, it can be found that only 90.0% of the radio resources remained for data and other control signals, while in the case of 30 kHz subcarrier spacing, with L = 8, the same radio resource availability for data and control is possible, but with a higher bit rate.
• – Data and control: each IP packet found in section 9.10 (on the master and slave side) is considered as the service data unit (SDU) for the SDAP layer, which is then passed to the following sub-layers PDCP, RLC and MAC, as shown in Figure 9.3. Each layer will add a header (composed of some bytes) to the input SDU to obtain the protocol data units (PDU) on its output (Dahlman et al. 2018). Referring to the standardization documents ETSI (2018a), ETSI (2018b), ETSI (2018c) and ETSI (2018f), a total of approximately 60 bytes is counted as a total number of bytes to be added as headers for different control tasks. Hence, by adding the 60 · 8 = 480 bits/packet (control) to the 512 bits/packet and the 1,930 bits/packet for the uplink and downlink radio connection on the master side, respectively, 992 bits/packet on the UL and 2,410 bits/packet on the DL are expected.

Finally, considering the LDPC algorithm for the channel coding, with a code rate of (n = 5, k = 1), this produces a raw bit rate of 5, 107 bits/subframe, to be compared with the sum of the uplink and downlink data and control bit rates (i.e. 2, 410 + 992 = 3, 502 bit/subframe). Since the radio link bit rate (5,107 bits/subframe) is greater than the overall data, plus the control bit rate (3,502 bits/subframe), we can conclude that the 5G NR can easily handle the requirements of a haptic data communication, in terms of data rate. Since the overall data and control are contained in 1 ms duration (i.e. one subframe), this would guarantee a transmission delay within the required range for haptic perception.

9.4.5. Case study operational states

In this section, we introduce the operational states to show the steps from the establishment of a connection to the termination between the TDs. Based on the generic TI (device and architecture) operation states given in the IEEE 1918.1, we present a Moore finite state machine (FSM), along with a state mapping to the functional block in the proposed user and control plane architecture. The FSM illustrated in Figure 9.7 represents an E2E communication between two TD, through an edge–network–edge paradigm. This generally starts with a registration process, carried out by a TD within the tactile edge itself; however, this would be visible through the GNC, which should in turn, register to the services of the 5G through message exchange through the gNB with AMF, UPF and UDM, which are considered as the main modules of the core network that are involved in the process of registration. Therefore, the GNC can be considered as a special UE as it has the same capabilities of any UE, as well as the capability of relaying TDs to the network domain through its multiple interfaces. Then comes the authentication phase, where the AMF, AUSF and UDM functions will be involved. These are the modules that provide access, authentication and authorization, as well as the security credentials used during the session. Once registered and authenticated, the control synchronization would start between the GNC and the SMF for establishing an E2E connection with other TDs in other edges. In this phase, it should be decided which state the transition should go to, according to the type of data. If the data is haptic, then the next step will be haptic synchronization, where GNC and SMF are involved. These functional blocs are both responsible for setting up some parameters, such as codecs and session parameters, message formats, etc. In the case of the classical types of data, the operation state will be encompassed through GNC, MEC, UPF and DN. These functions are located in the data plane. During any data or control transmission, failure or errors may happen. Hence, we add two transitions to the operation state: one of them is an operation recovery, which indicates errors in the data and only involves GNC to manage or re-transmit the data. The second state is the recovery, which indicates a failure in the transmission, and uses GNC to fix it, and as a consequence, a transition will be made to the state of control synchronization, in order to enable the re-synchronization of the haptic data transmission. In both cases, once the recovery is performed, a transition from operation state to termination will be done to indicate a normal completion of the transmission.

9.4.6. Case study protocol stack

Figure 9.8 shows the protocol stack for our use case, with reference to Figure 9.3, which we have suggested for the integration of IEEE 1918.1 and 5G. Depending on the system design of the case study, in the user plane, there will be a direct communication between the application layer (the data multiplexing and packetization) of the TD and the GNC. The data multiplexer and demultiplexer is the part to be implemented on an embedded system. The HoIP layer can either be built in the GNC or in the TD, subject to the access method to the GNC. The UDP and IP layers will create the packets to be passed to the 5G stack layers in the GNC. After transmission of data and control through the radio, a similar stack on the gNB side will ensure the communication of data on the user plane 9.3. Concerning the control plane protocol stack, there will be no control messages generated by the tactile device; the GNC will take this in charge through the CPP module, which generates control messages regarding session registration, authentication, control synchronization, etc. following the transition states shown in Figure 9.7.

9.5.1. Simulation topology

A topology is defined for the considered 5G network architecture and is shown in Figure 4.2. The end-to-end network is represented by master and slave domains, connected together through the 5G core network as a network domain. The master and slave domains have the same capability and capacity in terms of network and node features. Each of them is composed of a 5G access network containing 25 stationary UEs, randomly distributed around the evolved node bases (eNodeBs) at both ends. The association with the eNodeB occurs according to the signal-to-interference-plus-noise ratio (SINR) values. Since the mmWave is used, its higher frequency does not permit the signal to travel long distances; hence, the distance set between UEs and eNodeB ranges between 30 and 150 meters. All UEs are generating haptic data and communicating with the eNodeB through the mmWave technology in 5G NR. Both access networks are connected via the packet gateway (PGW)/service gateway (SGW), which are generally collocated with each other in the 5G core network. The PGW/SGW is considered as the user plane in 5G, as it is responsible for packet routing and forwarding QoS mechanisms, connecting access networks together, and so on. Both eNodeBs are connected to the PGW/SGW through wired technology, represented in this topology by high-speed network cables with 100 Gbps data rate.

9.5.2. NS3 network architecture

The NS3 is considered as a full-stack simulator, as it models all of the network-layer protocol stacks, starting from the physical layer to the application layer. For each layer, different models are used, depending on the functionalities enabled in that layer. However, in order to technically implement these models through the C++ programming language, a modular technique for simulating the network models is used. In this thesis, the mmWave module is used to simulate the end-to-end communication system, where the main difference with LTE is in the physical layer. Figure 9.12 is proposed for the end-to-end network architecture, including all of the modules used in the different network layers.

We start with the UE and its protocol stack model. In the higher layer represented by the application layer, the HoIP is used to generate haptic data. In order to model HoIP, the packet sink application module is used to generate packets, respecting the same format of HoIP as in Gokhale et al. (2013a). Then, the generated data will be encapsulated in UDP by creating a client application that sends packets adding 64 bits as overhead. Afterwards, the packets will be encapsulated in the IP layer by adding its header information with a 192 bit overhead. This would give a total header for the packet, including header of HoIP + header of UDP + header of IP. The rationale behind these values can be based on the original values of the header of the IP (Osanaiye and Dlodlo 2015) and UDP (Long and Zhenkai 2010), shown in Figures 9.10 and 9.11, respectively.

Since the UE is connected to the eNodeB through the 5G NR interface, they will have the same radio stack, where mmWave module is installed. The NetDevice classes supporting the 5G NR interface used in both eNodeB and UE, are MmWaveEnbNetDevice and MmWaveUeNetDevice, respectively. Both NetDevices will include PHY and medium access control (MAC) layer functionalities as follows:

• – MmWaveEnbMac and MmWaveUeMac: These classes are used to provide the MAC mechanisms used for accessing the channel, as well as deploying the method of re-transmissions. The adaptive modulation and coding (AMC) scheme is used here, with interactions with the physical layer, is based on information provided by the MiErrorModel, especially the SINR, while HARQ is used to enable the re-transmission of the erroneous packets, using the soft combining method. This would allow the error correction procedure when errors occur during transmission. The class scheduler exists only in the eNodeB implementation of mmWave, since it is the centralized entity that controls the communication among UEs. Four schedulers were implemented in the eNodeB just like the Round Robin, Proportional Fair, Earliest Deadline First and Maximum Rate schedulers. In this thesis, Round Robin is used to allocate the resources in terms of slots to the UEs.
• – MmWaveEnbPYH: The 5G mmWave is supporting TDD; therefore, TDD frames are used in the simulation. Since the physical layer is directly connected to the channel model, several channel models were used, including the path loss model, which provided line of sight (LOS)/non-line of sight (NLOS) characteristics and small-scale fading, while beamforming and multiple antennas were used to gain capacity in the network.

In the proposed architecture (as shown in Figure 9.12), the eNodeB has two protocol stacks as it has two network interfaces. The first one uses 5G NR to connect to the UEs, and the other is connected to the 5G core network through PGW/SGW through a network cable. This is the reason behind seeing two protocol stacks in the eNodeB node architecture. On the top of the radio stack is the EpcEnbApplication, which is responsible for bridging the data generated in the data plane from the UE and data plane part from PGW/PGW. Note that the GTP or GPRS tunneling protocol (GTP) is used to decapsulate packets coming from the eNodeB and tunnel them to the PGW/SGW (since packets do not have the same format) that it is connected to. Then, the PGW/SGW will encapsulate the payload to be transmitted to the eNodeB2 through the EpcSgwPgwApp class; thus, the eNodeB2 will receive the packet and send it to the UE destination. Note that the path crossed by packets in the UL direction is similar to the aforementioned description, but in the opposite direction.

9.5.3. Simulation scenario

Two different scenarios are studied in this thesis. As shown in Figure 4.2, the main difference is the load generated in each one of them. In the first scenario, the HoIP is used in the application layer and encapsulated in the UDP datagram. Then, an IP packet composed of 1,400 will be transmitted over 5G NR in each frame (i.e. 1 ms); this scenario can be named as a low-load scenario. In the second scenario, 4,200 bytes are transmitted, which is triple the size of the packet used in the same scenario. The aim is to study the performance of the HoIP with two different loads in two different channel models for path loss, namely line of sight (LoS) and non-line of sight (NLOS).

9.5.4. Simulation results

9.5.4.1. Low-load scenario

The most important performance parameters that were studied in this chapter are delay and throughput. Both parameters were studied in the case of LoS and NLoS models of the channel.

Figure 9.13 shows the delay experienced by the number of UEs at both ends of the network, i.e. master and slave domains, as there are 25 UEs in the master domain and 25 UEs in the slave domain. It is clear from Figure 9.13 that the delay is increasing in the case of NLoS compared to LoS; however, it is not violating the QoS in terms of delay, which is fixed to 10 ms. The delay experienced by UEs in NLoS is related to the HARQ retransmission, as erroneous packets will be re-transmitted every time the channel is experiencing bad conditions.

Figure 9.14 shows the throughput in the case of low load, while LoS and NLoS are considered. The throughput in the case of LoS is higher than in the case of NLoS. This is a normal behavior since the channel is not experiencing any bad conditions. However, for the same amount of data to be transmitted, there will be errors and some packets that will not be fully transmitted because of channel conditions.

9.5.4.2. High-load scenario

Again, Figure 9.15 illustrates the delay in the high-load scenario, where the packet size is 4,200 bytes for both channel models LoS and NLoS. The delay in the case of NLoS is higher than in the case of LoS. The delay is increased in the case of NLoS, since the channel varies over time and its quality changes accordingly. In the case of an erroneous channel, the HARQ mechanism will be used to correct the errors; however, it demands some redundancy in the retransmission, according to the implemented mechanism of retransmission. This would increase the E2E delay, as shown in Figure 9.15. In the simulation, the number of HARQ retransmissions is fixed to 20, which would increase the delay, as the delay includes not only the transmission of the correct data, but also data with errors through the HARQ mechanism. It is noted that when the number of users reaches 40, there will be so many errors in the packets that no packets will transmitted anymore. Hence, the curve will stop at 40 UEs.

As shown in Figure 9.16, the throughput in the case of LoS for high load is higher than in the case of NLoS. Again, the same issue which occured in the previous figure, occurs here. This means that the channel condition is bad and when the number of users is increases, the number of big-size packets will increase. This means that there are more errors and simulation will stop at this stage, due to the huge number of HARQ retransmission. It cannot go beyond 20 re-transmissions.

9.5.4.3. Comparison between low-load and high-load scenarios

Figure 9.17 shows the delay in both cases when high and low loads are considered under the LoS channel condition. The delay of LoS includes the delay of the transmission, plus the delay that the packets are experiencing in the PGW/SGW. This is due to the technology difference of communication, as when frames are transmitted between the gNodeB1 and PGW/SGW, the MTU of both technologies are different. The frames transmitted from the UE and gNodeB1 are transmitted respecting the mmWave format of frame; then, when it is transmitted to the PGW/PGW through the high-speed Ethernet, the MTU will change. In this case, fragmentation will occur in PGW/SGW as the LTE frames are bigger than the MTU of Ethernet, which is 1,500 bytes. Thus, the delay of fragmentation will be added to the delay of transmission. The same process will occur, in inverse, between the PGW/SGW, as the frames should be defragmented to be transmitted to the gNodeB2.

The delay comparison of low load and high load under the NLoS condition is considered in Figure 9.18. The same concern encountered in the previous figure, regarding the delay, is true; however, the delay of transmission of HARQ will be added, so here, the delay especially consists of the high load to propagation delay + transmission delay + HARQ delay + fragmentation/defragmentation delay.

Throughput is compared between high load and low load under LoS and NLoS scenarios. It is obvious that throughput in the case of high load under LoS is higher than in the case of low load, as shown in Figure 9.19. This is because the impact of the size of the packet is so large.

In Figure 9.20, the throughput in the case of LoS is higher for high load compared to low load, until the number of UEs reaches 40. When the number of UEs are greater than 40, errors are generated in the channel, such that the channel is no longer able to transfer data.