Evaluating and enhancing internal networks for an institution to meet E-government demands: a case for fiber optics and wi-fi by using OPNET

1 Introduction

An increasing number of national governments are leveraging technology to manage interactions with their citizens more efficiently. Each advancement in information and communication technology (ICT) has a profound impact on daily life and has become one of the defining features of our era (Jaeger and Thompson, 2003; Abdulhassan and Al-Hamadani, 2012). The concept of e-government has been shaped by different policy agendas, but it generally refers to the delivery of government services to individuals, businesses, and non-governmental organizations through ICT (Abdullah, 2016). According to the World Bank (2001), e-government is “the government’s ownership or operation of information and communication technologies that transform relations with citizens, the private sector, and/or other government agencies to promote citizen empowerment, improve service delivery, strengthen accountability, increase transparency, and enhance government efficiency” (Ahmad, 2019; Al-Bayati, 2018). E-government can further be categorized into four main domains: government-to-business (G2B), government-to-citizen (G2C), government-to-employee (G2E), and government-to-government (G2G), each representing a distinct type of service provided (Ndou, 2004; Al-Dabbagh, 2011).

Governments worldwide face numerous challenges in achieving effective e-government. Key obstacles include inadequate ICT infrastructure, privacy and security concerns, regulatory and policy gaps, shortages of skilled personnel, weak collaboration, the digital divide, cultural barriers, and lack of management support (Abdulhassan and Al-Hamadani, 2012). Among these, ICT infrastructure remains the most critical challenge (AL-HILFI et al., 2018a). For e-government to succeed, a robust technological foundation must exist to provide services accessible to all citizens (Ziemba et al., 2016; AL-HILFI et al., 2018b). Governments must identify current gaps, adapt networks to meet new demands, and adopt solutions that address both present and future needs (Al-Sai and Abualigah, 2017). Many studies across different countries have examined factors influencing collaboration among local agencies to build strong and sustainable e-government systems.

With the rapid growth of big data driven by increased ICT use, especially during the COVID-19 pandemic, there has been an urgent need to identify gaps in communication networks and upgrade ICT infrastructures. These enhancements must ensure scalability, security, and availability to meet rising demands (Al-Taie and Kadry, 2013; Ali et al., 2019; Suh et al., 2015).

Many developing countries, including Iraq, lack the infrastructure necessary to immediately deploy e-government services, even when the political will exists (Alrammahi and Al Kim, 2018). The delay in building this infrastructure widens both the social and technological gaps within Iraqi society and across its institutions. Research indicates that Iraq must strengthen its ICT infrastructure and human resources to advance e-governance. The primary barriers to adoption have been identified, and urgent action is recommended to overcome them (Alshehri and Drew, 2010). With support from the United Nations Development Programme (UNDP), the Iraqi government began laying the groundwork for e-government initiatives. In June 2004, a Memorandum of Understanding was signed between the Italian Ministry of Innovation and Technology and Iraq’s Ministry of Science and Technology, following a UN request for Italian assistance in establishing Iraq’s e-government (Ameen and Nourildean, 2014). However, Iraq still lacks the infrastructure required to expand e-government services nationwide. Internet access remains costly, slow, and unreliable due to weak networks (Barznji et al., 2018).

In general, there is a lack of in-depth scientific research addressing the challenges facing e-government in Iraq and proposing robust solutions or consistent roadmaps for implementation (Bertot and Choi, 2013). Accelerating the development of this network requires strengthening Iraq’s existing communications infrastructure through modernization, expansion, and interconnection of all necessary sites nationwide. A reliable telecommunications backbone must support the requirements of e-government across ministries and institutions, which demands ongoing planning, development, and large-scale redesign (Barznji et al., 2018).

Despite several studies examining Iraq’s situation, United Nations e-government indicators continue to record low levels compared to neighboring countries, with only slight improvements. Notably, the 2020 UN survey showed progress in the Telecommunications Infrastructure Index, which raised Iraq’s global ranking from 155th in 2018 to 143rd in 2020. However, other indicators showed only marginal gains, underscoring the need for sustained reforms.

Wireless networks are considered effective solutions for networks due to their flexibility, ease of use, and portabil-ity. Their performance can be analyzed using OPNET simulations, even in heterogeneous environments with diverse applications, where results depend on the application type and implementation time. Wireless networks are highly vulnerable to security threats due to their shared transmission medium. In addition to jamming attacks, which disrupt network availability (Hasan et al., 2019). Wireless communications are also exposed to passive eavesdropping, posing serious risks to data confidentiality and privacy, particularly in institutional and e-government environments. These vulnerabilities compromise both the confidentiality and integrity of institutional communications and increase the risk of unauthorized data access and privacy breaches (Bolanio et al., 2021). Consequently, structured wired network architectures offer stronger security properties for sensitive institutional and e-government environments (Zou et al., 2016). Rhaif et al. (2020) employed OPNET Modeler to simulate a fiber-optic–based Wi-Fi network within a fixed LAN. The results showed that the baseline Wi-Fi configuration experienced higher delays compared to the fiber backbone.

Network performance is strongly influenced by routing protocols such as Enhanced Interior Gateway Routing Protocol (EIGRP), Open Shortest Path First (OSPF), Routing Information Protocol (RIP), and Interior Gateway Routing Protocol (IGRP), which affect convergence time, throughput, end-to-end delay, and point-to-point efficiency. In İbrahim (2014), OPNET was used to simulate network designs, confirming that routing protocols significantly enhance network effectiveness. Modern networks also rely heavily on the Transmission Control Protocol (TCP) to manage data flow between interconnected devices. At Salahuddin University in Iraq (Rashid and Barznji, 2018; Hasan et al., 2017), a proposed network design was tested using OPNET to demonstrate TCP’s importance in ensuring efficient and reliable architecture. The results showed that the design, supported by appropriate devices, successfully delivered services while maintaining quality in terms of delay, throughput, bandwidth, data transfer, packet transmission, and delivery (Jameel, 2019).

In the same network, the effect of adding a firewall was evaluated on throughput, data transmission, delay, and packet handling. The results showed that the firewall did not reduce network speed and had no negative impact on VoIP performance or its parameters (Lafta et al., 2020). Similarly, Ameen and Nourildean (Liu, 2021) demonstrated that while VPNs and firewalls do affect network behavior, the impact is more pronounced on throughput than on delay.

Alrammahi and Al Kimgood (Mahmood, 2020) reported significant improvements in network performance, achieving high-quality voice transmission and reception as well as enhanced VoIP service performance through the use of OPNET for analyzing and optimizing VoIP algorithms in wireless networks. Similarly, Lafta et al. (Mehta and Baghla, 2015) simulated multimedia broadband wireless networks in OPNET to evaluate QoS in IP-based environments, effectively utilizing available resources to reduce delays in traffic carrying voice, video, and database services. OPNET was also used to implement Virtual Local Area Networks (VLANs), which partitioned a single physical network into multiple broadcast domains. This approach reduced switch traffic and improved bandwidth utilization, security, and efficiency. Owing to these advantages, many institutions and companies have employed OPNET to design, upgrade, and optimize communication networks ranging from small-scale internal LANs to large-scale external infrastructures (Mohammed et al., 2016).

Building on this literature, the present study contributes by providing a detailed analysis of internal government network models, offering recommendations for improving and modernizing network design, and serving as a reference for policymakers and IT professionals engaged in e-government network development.

2 Methodology

This study examined the internal communication networks of two Iraqi institutions as representative cases. The Information and Communications Technology Company (ITPC) was selected as an example of an enterprise that uses a Wi-Fi–centric LAN with limited structure and no centralized services, whereas the Ministry of Industry and Minerals was selected as an institution that relies on a fiber-based LAN with inefficient topology and device utilization. The study employed a two-stage research methodology. The first stage involved collecting data through site surveys. In the second stage, the collected data were analyzed and applied using the OPNET Modeler 14.5 to evaluate current configurations and generate results. The data collected through these visits—covering technical, security, and information management aspects (Nilsson, 2000; Nkomo, 2012; Noman and Hamad, 2020)- proved essential for developing redesigned models in OPNET. Several scenarios were proposed for each institution, based on its unique structures, functions, and application requirements, to ensure that the designs reflected the diversity of its services.

2.1 Network performance metrics

In this study, the baseline network refers to the existing, operational network configuration observed during on-site measurements, prior to any redesign, optimization, or architectural modification. The baseline represents the deployed infrastructure in daily use at each institution and serves as the reference point for evaluating all redesigned scenarios. No assumptions are made regarding optimization, service enhancement, or structural improvement for the baseline configuration.

To evaluate and compare the performance of the current and redesigned network architectures, a set of standard network performance metrics was employed. All metrics were obtained from OPNET Modeler 14.5 output statistics (Table 2) and represent time-averaged values measured after the simulation warm-up period.

• Throughput: Throughput represents the rate of successful data delivery across a network link or device. It is measured in bits per second (bps) and reflects the effective utilization of network resources under the applied traffic load.
• Traffic received: Traffic received denotes the amount of data successfully received by a network node (e.g., switch, server, firewall, or access point). Depending on the analysis level, it is reported as a data rate (bits/s or bytes/s) and is used to assess traffic distribution and bottlenecks within the network.
• End-to-end delay: End-to-end delay is the average time a packet takes to travel from the source to the destination at the application layer. This metric includes transmission, propagation, queuing, and processing delays. For wireless scenarios, it additionally accounts for medium access delay and access-point forwarding, as defined by OPNET’s WLAN MAC model. Delay is reported in seconds (s).
• Load: Load represents the total amount of traffic offered to a network element or link by upper-layer applications. It is typically measured in bits/s or bytes/s and indicates the demand placed on network resources.
• Application response time: Application response time measures the elapsed time between issuing an application request (e.g., email, HTTP, database, or FTP) and receiving the corresponding response. This metric reflects user-perceived performance and is distinct from network delay. It is reported in seconds (s). It does not represent round-trip time (RTT) or one-way propagation delay.

These metrics were selected to provide a comprehensive evaluation of network efficiency, responsiveness, and scalability, and to enable a consistent comparison between the existing infrastructures and the proposed redesign scenarios.

For each institution, the Real-world measurements components are as follows:

• Measurement Duration:

Baseline measurements were collected over multiple working days during peak and normal operating hours.

• Observation Windows:

For ITPC: 15-min measurement windows aligned with simulation duration.

For the Ministry: 1-h observation windows aligned with simulation runtime.

• Traffic Conditions: Measurements reflect routine institutional background traffic (HTTP, FTP, Print File, email, database access, VoIP).
• Aggregation Method:

All reported baseline values represent time-averaged application-layer statistics calculated after eliminating initialization artifacts.

2.2 QoS and QoE performance evaluation

In addition to the above performance metrics, the most important of which is the traffic received, application performance can also be evaluated using multiple QoS/QoE metrics, including packet loss rate, packet delay variation (jitter), queueing delay, and link utilization. Received traffic is used solely as a supporting indicator of successful delivery and should not be interpreted in isolation. This multi-metric approach ensures that performance evaluation reflects network quality rather than traffic generation settings. Table 1 below represents QoS/QoE metrics that can also be used to evaluate network performance.

TABLE 1. QoS/QoE Metrics used in performance evaluation.

2.3 Specifications of devices and equipment

Table 2 presents the hardware and equipment specifications used in OPNET Modeler 14.5 to design the proposed networks for the scenarios and the baseline network.

TABLE 2. Specifications of devices and equipment used in network design.

3 Results and discussion

3.1 Baseline network architectures

This study examines the internal communication networks of two Iraqi institutions with distinct architectural characteristics. The Information and Communications Technology Company (ITPC) primarily relies on a Wi-Fi-based LAN, whereas the Ministry of Industry and Minerals relies on a fiber-based LAN.

The baseline ITPC network is confined to a single multi-floor building, measuring 150 m in length, 50 m in width, and 50 m in height. And follows a star topology based largely on IEEE 802.11 wireless access points, supplemented by limited Ethernet cabling. It supports 320 subscribers, with a maximum cable length of 100 m from any switch to workstations, a total cable length of 1 km, and up to 25 devices per switch or hub. The network primarily uses Cisco devices (30%); the wired-to-wireless connection ratio is 10%. Each floor is equipped with a switch that connects to the main switch, which in turn links to an access point. The access point connects to a sub-switch, and all computers and devices on the floor connect through it, delivering wireless service to all subscribers, as shown in Figure 1. The average data transfer rate is 8 Mbps. The network lacks segmentation mechanisms such as VLANs and does not employ centralized security controls, resulting in congestion, higher latency, and limited scalability. While the building design is uniform, each floor accommodates distinct specializations and a different number of network subscribers. The detailed distribution of departments and participants is summarized in Table 3 below.

TABLE 3. Floor-by-Floor distribution of departments and subscribers in the institution.

In contrast, the Ministry of Industry and Minerals operates a fiber-optic-based LAN spanning multiple floors, with each floor divided into two wings. The building measures 100 m in width, 150 m in length, and 45 m in height. The current setup consists of a primary MikroTik router (model 1100 AX) and a secondary MikroTik router serving as a backup. Internet access is provided via an optical fiber link with a 30 Mbps capacity, an effective speed of 20 Kbps, and a transfer rate of 20 Mbps. In each wing, a fiber-optic backbone supports the network. Each wing is equipped with a Cisco 2,960 hub that connects all computers and devices, which in turn uplinks to a Cisco 2,700 sub-switch on the floor. These sub-switches are connected to the main switch located in the data center. Approximately 494 network subscribers are connected across its ten levels, as shown in Figure 2. Despite the use of optical links, the network relies heavily on hubs and multiple low-capacity switches, leading to inefficient traffic handling, increased access delays, and underutilization of the available transmission medium. While all the floors are equal in area and identical in design, each is divided into two wings (A and B) separated by a central corridor. Each wing maintains its own network infrastructure. Although structurally similar, the floors differ in the number of subscribers and their specializations—technical, administrative, or legal. Consequently, each floor hosts distinct applications and varying numbers of employees (network subscribers). The detailed distribution of departments and participants is summarized in Table 4 below.

TABLE 4. Floor-by-floor distribution of departments and subscribers in the ministry.

The following Table 5 summarizes the comparison between the two networks.

TABLE 5. Comparative Summary of the baseline networks.

3.2 Performance evaluation of baseline networks

To enable direct comparison, the performance of the two baseline networks was evaluated using identical OPNET simulation methodologies and similar application profiles for each network.

In the ITPC network, the baseline Wi-Fi-based LAN achieved an average throughput of approximately 5.8 Mbps and an average end-to-end application-layer delay of 0.00020 s. Performance degradation was observed under higher user loads due to medium contention, lack of traffic segmentation, and shared wireless access. Other shortcomings include the lack of consideration of cable performance factors such as transmission speed, maximum length, and interference resistance, as well as the types of networks to be interconnected. In addition, the network uses devices from multiple suppliers that do not adhere to standard specifications, and hubs are still used instead of switches, indicating the network was built haphazardly. Table 6 presents the requirements for simulating an ITPC network. To meet diverse user requirements, the network currently supports the following applications: HTTP, multimedia email, File Transfer Protocol (FTP), mixed data transfer/FTP between users, document retrieval and database access, web browsing and e-publishing, as well as voice, video, and visual text communications (printing and color scanning). Table 7 presents the distribution of applications and profiles used on the enterprise network by building floor.

TABLE 6. Baseline network simulation requirements.

TABLE 7. The applications and profiles used in the network.

The Ministry of Industry and Minerals network, despite its fiber-optic backbone, did not consistently outperform the ITPC network. While application traffic, such as FTP and database services, achieved reasonable throughput, excessive use of hubs and multiple intermediate switches increased access delay and reduced overall efficiency. Moreover, the network equipment comes from different vendors, resulting in inconsistent software and driver specifications, indicating that the network was also built haphazardly. This demonstrates that the transmission medium alone does not guarantee superior performance without proper network design. Table 8 presents the requirements for simulating the ministry network. Although structurally similar, the floors differ in the number of subscribers and their specializations—technical, administrative, or legal. Consequently, each floor hosts distinct applications and varying numbers of employees (network subscribers). This distribution highlights the complexity of the ministry’s operations and underscores the importance of a well-structured, scalable, and secure network design to support its diverse applications and departmental needs. Table 9 presents the distribution of applications and profiles used on the ministry network by building floors.

TABLE 8. Baseline network simulation requirements.

TABLE 9. The applications and profiles used in the network.

Overall, the comparison of the two baseline networks reveals that both architectures exhibit design inefficiencies, albeit for different reasons. The ITPC network is constrained primarily by wireless medium contention and limited scalability, whereas the Ministry network is constrained by suboptimal device selection and excessive network branching. These findings highlight the necessity of structured redesign scenarios, which are analyzed in the following sections.

3.3 Proposed network scenarios (ITPC)

The building layout is well-suited to implementing a structured LAN. The network can be designed by creating subnets for each floor, selecting appropriate devices, cabling, and applications, and connecting them to a central switch. This main switch, which receives the Internet feed from the primary router, serves as the backbone of the entire LAN. Subnet configurations can vary based on each floor’s requirements and the available tools in OPNET. Once deployed, the LAN will be ready to interconnect with other institutions’ networks via the main router. The goal of this design is to modernize and enhance the infrastructure by leveraging reliable networking components across endpoints and backbone connections. The proposed design ensures high-speed service delivery, enough bandwidth, low delay, and effective collaboration across the institution.

The proposed design outlines how to modernize ITPC’s network infrastructure by replacing its outdated Wi-Fi system, which relies on centralized databases and exhibits high latency. The new design demonstrates how to select appropriate technologies to enhance network performance and ensure compliance with updated standards. At its core, the design introduces a robust Gigabit Ethernet backbone capable of supporting high-bandwidth, high-speed connectivity to meet user and application requirements (Obaid, 2020). Based on the survey and subsequent analysis, the current design is unsuitable for supporting future e-government projects. Therefore, new designs and updates to the existing infrastructure have been proposed, as illustrated in the following scenarios.

3.3.1 Scenario 1: ethernet design using switches and hubs

In this design, an eleven-floor LAN (including the ground floor) is implemented using an Ethernet star topology. Device connections on each floor use 100Base-T links to sub-switches, while the backbone employs 1000Base-X (Gigabit Ethernet) connections to the central switch. This layout supports applications such as HTTP, email, FTP, databases, video, and audio, covering all users in the building (Figure 3).

Each floor’s workstations and devices connect to a local switch, which uplinks to the central switch. The central switch was chosen for scalability, enabling future expansion by allowing easy device addition or replacement. Switches replace hubs in this design, providing better scalability and allowing simultaneous operations. These switches support 16, 32, or 64 Ethernet interfaces and can only interconnect LANs of the same type (e.g., Ethernet-to-Ethernet, FDDI-to-FDDI, Token Ring-to-Token Ring). They also support speeds of 10 Mbps, 100 Mbps, 1 Gbps, and 10 Gbps.

The backbone between the central switch and each floor uses 1000Base-X (Gigabit Ethernet) cabling, compliant with IEEE 802.3, delivering speeds 10x faster than standard Ethernet. This upgrade significantly reduces delays caused by application traffic. Table 10 lists the types of Gigabit Ethernet cables used in the network (Onah et al., 2020).

TABLE 10. Types of gigabit ethernet.

3.3.2 Scenario 2: ethernet design using switches only

In this scenario, the same applications and profiles from the baseline network and the previous scenario were used. Ethernet technology was used with the same cables and devices, except that all hub devices were replaced with switches, as illustrated in Figure 4.

3.3.3 Scenario 3: ethernet design by using regrouping devices

In this scenario, the same Ethernet technology, applications, and profiles from the baseline and previous networks were used, but the switches were replaced with higher-capacity models. As a result, the total number of switches was reduced from 26 to 12, with one switch per floor. Additionally, 1000BaseX cables were used to connect devices to the sub-switches, while a 10 Gbps Ethernet backbone linked the sub-switches to the main switch, as shown in Figure 5.

3.3.4 Scenario 4: ethernet design by using regrouping devices and an external server

This scenario is similar to Scenario 3, but with an additional external server, as shown in Figure 6. Its purpose is to evaluate network performance when connected to other networks, with a focus on delay, load, and traffic.

3.4 Results and discussion for the ITPC network

Throughout this section, traffic values are reported as data rates (bits per second or bytes per second), consistent with OPNET output statistics. This paper demonstrates the use of OPNET to simulate the ITPC building, comprising eleven floors and diverse applications, and measures key network parameters, including delay, load, traffic, and throughput. These metrics were first recorded for the baseline wireless network and then compared against Ethernet-based designs. The selected hardware components were carefully chosen for cost-effectiveness and performance to ensure reliability and high efficiency. After constructing the network models, the simulator was used to evaluate the performance of all proposed scenarios.

The main parameters in this study were delay, load, and throughput, used as reference functions for comparison across the proposed scenarios. All plotted values below represent time-averaged statistics reported by OPNET over the simulation interval after the warm-up period. Therefore, Figures 7–17 present the results obtained from this network using these data.

Non-serviceable baseline scenarios represent intermediate configurations of the ITPC network in which centralized servers and external connectivity are intentionally absent. These scenarios are used solely to illustrate the inherent limitations of the existing Wi-Fi-based architecture under minimal service conditions and therefore exhibit negligible application traffic. They are not intended to represent deployable redesign options.

Service-enabled scenarios include identical application services, servers, user endpoints, and traffic profiles across all configurations. Only these scenarios are directly compared with respect to throughput, end-to-end delay, and application response time, ensuring that performance differences arise from network design choices rather than from service availability. Table 11 presents a concise scenario classification, with each ITPC scenario classified as either a baseline non-serviceable scenario or a serviceable scenario.

TABLE 11. Classification of ITPC simulation scenarios.

Only service-enabled scenarios are directly compared in terms of throughput, delay, and application performance. The following are the results from the ITPC network.

Figure 7 presents the time-averaged end-to-end delay for packets transmitted through the Ethernet-based network; the y-axis presents the average end-to-end delay (s). It includes medium access delay, fragment reception time, and frame transmission time through the Access Point (if enabled). The values reflect stable performance, showcasing Ethernet’s low-delay capability under l load.

Figure 8 illustrates the global delay in the wireless LAN, including medium access delay, fragmentation handling, and access-point forwarding, as reported by OPNET WLAN MAC statistics. The y-axis presents the average WLAN end-to-end delay (s). It highlights higher end-to-end delays due to increased medium access contention, revealing Wi-Fi’s performance limitations in dense environments.

Figure 9 represents the total offered traffic submitted by upper layers to baseline WLAN nodes; the y-axis represents the offered load (bits/s). The increasing load reflects growing user activity, contributing to congestion and delay in wireless networks.

Figure 10 illustrates the effective throughput achieved in the baseline Wi-Fi–centric LAN, measured as the amount of data successfully delivered to higher layers. Despite increasing the offered load, throughput remains limited by shared medium access and contention, reflecting the inherent efficiency constraints of the baseline wireless design. The y-axis represents the effective throughput (bits/s).

Figure 11 shows the time-averaged traffic rate received at the main switch in the baseline ITPC network. The y-axis represents the traffic received (bits/s). The results indicate steady performance, with the main switch handling traffic aggregation from all floors, peaking at 9.25 Mbps by the 10th minute.

Figure 12 presents the average traffic received by floor-level switches in the baseline ITPC network. The y-axis represents the traffic received (bits/s). The values range from 1.25 Mbps to 9.25 Mbps, reflecting varying user densities and activity levels across floors. The main switch shows a consistent peak load, validating its central role in the topology.

This figure compares the time-averaged application-layer end-to-end delay across all functionally comparable, service-enabled scenarios. The y-axis represents the average end-to-end delay (s). Delay values represent application-layer measurements collected after the simulation warm-up period. Scenarios 3 and 4 exhibit the lowest delays (0.000002 s), whereas the baseline network and non-optimized configurations show higher delays, highlighting the benefits of optimized switch configuration and upgraded cabling.

The measurements were recorded after 100 s of simulation time. This initial period encompasses the time required for all network components, such as clients, servers, routers, and hosts, to initialize and recognize one another. After this setup phase, the network begins operating normally, and the output curves quickly stabilize and peak, indicating full network functionality.

Although firewalls typically affect several network performance parameters, including throughput, data transmission, delay, and packet transfer, in this design, the firewall did not adversely affect delay. By contrast, the network maintained minimal delay while continuing to support the same services and applications, as illustrated in the figure above.

This figure shows the traffic received by the main switch across all scenarios. The y-axis represents the traffic received (bits/s); all values are reported as time-averaged traffic rates. Scenarios 1 and 2 represent non-serviceable baseline configurations and exhibit lower effective traffic delivery. The recorded traffic values were 6.8 Mbps and 7.3 Mbps, respectively. These relatively low values are attributable to intensive network resource utilization, including multiple switches and hubs. Scenarios 3 and 4 are service-enabled redesigns that achieve higher traffic reception by optimizing the topology and reducing congestion. Scenario 3 achieved a higher traffic value of 9 Mbps, despite using fewer resources—only 13 switches and a single server—indicating efficient handling and reduced congestion despite fewer hardware components. This outcome is particularly noteworthy, as it was achieved despite a network firewall. Moreover, Scenario 3 recorded a delay of just (0.0000019 s), which is significantly lower than the delay observed in the baseline network as well as in Scenarios 1 and 2. Scenario 4 recorded a traffic value of 8.4 Mbps and a delay of (0.000018 s), one of the lowest delays among all scenarios. This scenario differs from the others in that it adds an external network. Its primary purpose is to evaluate the performance of the proposed network design when data flows between networks over the Internet, i.e., to test the connectivity between two separate networks via an Internet link. The original network maintained a stable traffic reception rate of approximately 5.8 Mbps. This relatively low value is attributable to the substantial resource utilization in the network, including 19 access points, 13 switches, 3 servers, and extensive cabling. As a result, the network is economically costly to build and maintain. In addition to the high resource cost, the recorded delay in this network was (0.00020 s).

This figure illustrates the traffic received by the main server in Scenarios 3 and 4. The y-axis represents the traffic received (bits/s). Scenario 3 records slightly higher traffic than Scenario 4, reflecting differences in topology and the presence of external network connectivity in Scenario 4.

Figure 16 reports the time-averaged processing load at the main server. The y-axis represents the average server load (bits/s). Scenario 3 exhibits a higher load than Scenario 4, consistent with observed traffic reception patterns. This reflects efficient server utilization under optimized switch and firewall configurations.

This figure presents the traffic handled by the firewall in all scenarios. The y-axis represents the traffic received (bits/s). Scenarios 3 and 4 show active firewall utilization, while Scenarios 1 and 2 record zero traffic due to the absence of centralized services and external connectivity.

The redesigned scenarios, especially Scenarios 3 and 4, demonstrate significantly improved performance with fewer resources, optimized device configurations, and advanced cabling. This will result in efficient and effective data and packet transmission across all network nodes.

In brief, for ITPC, the baseline Wi-Fi-based LAN recorded 5.8 Mbps traffic at the main switch with a delay of (0.00020 s), but required 19 access points, 13 switches, and 3 servers, making it costly and inefficient. The best-performing design (Scenario 3) achieved a throughput of 9 Mbps and a server traffic of 1.93 Mbps with only 13 switches and 1 server, reducing the delay to (0.0000019 s). Scenario 4 validated Internet-connected resilience with 8.4 Mbps traffic, (0.000018s) delay, and 2.6 Mbps firewall throughput. These results confirm that the baseline ITPC network cannot adequately support all subscribers. The limitations stem from limited scalability, the growing number of users, and the inability to support advanced applications. To address these challenges, ITPC must modernize its network by upgrading devices and equipment, ensuring scalability, and enabling secure communication with other networks through appropriate transmission media.

In general, the findings reaffirm that wired networks provide more secure, faster, and more reliable connectivity than wireless alternatives.

In this study, “cost-effective” refers to a network design that meets the required service performance with fewer active devices, lower architectural complexity, and reduced operational and maintenance overhead, without relying on vendor-specific pricing. Table 12 represents the comparative cost and feasibility indicators for ITPC Scenarios.

TABLE 12. Comparative cost and feasibility indicators for ITPC scenarios.

Accordingly, Scenario 3 is now deemed cost-effective based on quantified reductions in infrastructure and operational simplicity, rather than on qualitative judgment alone. In contrast, the baseline network and Scenarios 1–2 require more devices and exhibit greater structural complexity without corresponding performance gains, thereby increasing deployment and maintenance costs. Scenario 4, while functionally robust, introduces additional infrastructure and external connectivity, thereby reducing its cost-effectiveness for internal institutional deployment.

3.5 Proposed network scenarios (ministry)

3.5.1 Scenario 1: ethernet technology by using an ethernet 1000BaseX cable

In the first scenario, the network configuration was changed from fiber optic to Ethernet. Two types of switches were deployed as secondary switches on each floor. The first type is a 32-port Ethernet switch node model that supports up to 32 Ethernet interfaces at data rates of 10, 100, or 1,000 Mbps. This switch implements the Spanning Tree Protocol (STP) to ensure a loop-free topology, exchanging Bridge Protocol Data Units (BPDUs) to maintain stable connectivity. It can only interconnect LANs of the same type (e.g., Ethernet-to-Ethernet, FDDI-to-FDDI, or Token Ring-to-Token Ring).

The second type, used as floor-level and main switches, is similar in function but has a smaller capacity, supporting up to 16 Ethernet interfaces.

For backbone connectivity, 1000Base-X cables (Gigabit Ethernet) were used to link the secondary switches to the floor switches, and subsequently to the main switch and server, as shown in Figure 18 below.

The 1000Base-X duplex link represents a Gigabit Ethernet connection operating at 1 Gbps (1,000 Mbps). It supports connections among various node types, including stations, bridges, switches, and LAN nodes, but not Hub-to-Hub links. The link specification includes propagation speed (in meters per second), which is used to calculate propagation delay when the ‘Distance-Based’ delay attribute is enabled.

For workstation connectivity, 100Base-T cables were used. These cables share the same specifications as the backbone cable but operate at a lower capacity of 100 Mbps.

The server in this network is modeled as an Ethernet_server node, representing a server that runs applications over TCP and UDP. It supports a single Ethernet interface at 10 Mbps, 100 Mbps, or 1 Gbps, with the operational speed determined by the connected link’s data rate. Supported protocols include UDP, IP, Ethernet, RIP, TCP, and OSPF.

The Ethernet MAC in this node can operate in either full-duplex or half-duplex mode. When connected to a hub, it must always be configured for half-duplex operation. Packet routing requires a fixed processing time, defined by the node’s IP Forwarding Rate attribute. Packets are handled on a first-come, first-served (FCFS) basis and may experience queuing delays at lower protocol layers, depending on the output interface’s transmission rate.

The workstations are modeled as Ethernet_wkstn nodes, representing client-server systems running applications over TCP/IP and UDP/IP. Each workstation supports a single Ethernet connection at 10 Mbps, 100 Mbps, or 1,000 Mbps. Packet routing requires a fixed processing time, defined by the IP Forwarding Rate attribute, and processes packets on a first-come, first-served (FCFS) basis. Queuing may occur at lower protocol layers depending on the output interface’s transmission rate. Supported protocols include UDP, IP, IEEE 802.3 (Ethernet, Fast Ethernet, Gigabit Ethernet), RIP, TCP, and OSPF.

Key attributes of the workstation include: Client Custom Application, Client Database Application, Client Email, Client FTP, Client Remote Login, Client X Windows, Client Video Conferencing, and Client Start Time. These attributes enable traffic generation and node addressing. The same applications and user profiles were applied to the same number of subscribers as in the real network.

3.5.2 Scenario 2: ethernet technology by using an ethernet 10 Gbps Link

In this scenario, the network design is identical to the first scenario, using the same components, except that the secondary cable was upgraded from 100Base-T to 1000Base-X, and the backbone cable was replaced from 1000Base-X to a 10 Gbps Ethernet duplex link, as shown in Figure 19.

The 10 Gbps Ethernet duplex link operates at 10 Gbps and requires full-duplex mode, as the IEEE 802.3ae standard does not support half-duplex operation. It can connect nodes such as stations, workstations, servers, routers, switches, and switched LAN nodes, but not hubs. The propagation speed of the medium (in meters/sec) is used to calculate delay if the ‘delay’ attribute is set to ‘Distance Based,’ reflecting the distance between nodes.

3.5.3 Scenario 3: ethernet technology using an ethernet 10 Gbps link and using devices regrouping

In this scenario, the same cables, components, and primary setup were retained, but the number of secondary switches was reduced. Instead of three switches per floor, only one switch was used for each floor, resulting in a total of 11 switches compared to 31 in the other scenarios, as shown in Figure 20.

3.6 Results and discussion for the ministry network

The results of this network differ from those of the previous institution due to variations in their operations, services, and applications. All figures report time-averaged statistics obtained after the initial simulation warm-up period. In Figure 21 (Database, Voice, Print, FTP, Email, HTTP), the y-axis represents the traffic received (bytes/s). The outcomes are summarized as follows:

Figure 21A shows the time-averaged database application traffic received over 1 hour for the baseline network and all simulated scenarios. Received traffic fluctuates across scenarios, with the highest value reaching 270,000 bytes/s. The baseline network and Scenario 3 record higher throughput than Scenarios 1 and 2, suggesting greater efficiency and capacity. Conversely, the lower traffic in Scenarios 1 and 2 indicates potential bottlenecks or inefficiencies.

Figure 21B presents the received voice traffic for each network configuration, reflecting the relative ability to support VoIP services. Measured over 1 hour of simulation time, with the peak reaching 220,000 bytes/s. The baseline network and Scenario 3 yield higher values, indicating greater efficiency in handling voice traffic. Scenarios 1 and 2 exhibit lower performance, indicating capacity limits and potential congestion. These results confirm that network design directly affects VoIP service quality.

Figure 21C shows the average application-layer traffic rate measured over 1 hour of simulation time. Print traffic received varies across scenarios, peaking at 24,000 bytes/s. The original network and Scenario 3 record relatively higher throughput, highlighting improved efficiency in handling print services. Scenarios 1 and 2 show lower traffic, indicating minor inefficiencies. Overall, print traffic remains sensitive to design and resource allocation.

Figure 21D shows the average FTP traffic received over a 1-h period for each scenario, with a maximum of 18,000 bytes/s. Across all scenarios, traffic patterns remain similar, with slight differences. The original network achieves a marginally higher throughput, suggesting more efficient handling of FTP transfers, whereas Scenarios 1–3 exhibit slightly lower values. Overall, FTP performance appears stable across configurations.

Figure 21E shows the average application-layer traffic rate measured over 1 hour of simulation time, peaking at 9,000 bytes/s. Scenarios 1 and 2 outperform the original network and Scenario 3, demonstrating greater efficiency in handling email loads.

Figure 21F shows the average HTTP traffic rate received by servers, with a maximum of 8,500 bytes/s. Scenario 1 achieves higher throughput, comparable to the baseline network, indicating more efficient handling of HTTP requests. Other designs show slightly reduced efficiency.

The weaker results for the email application in scenario 3 and the baseline network are attributed to slower upload/download response times. Figure 22 shows the average application-level response time (Email upload/download), not network RTT, where the response time is not equal to the delay time. The y-axis represents the application response time (s).

The performance of HTTP on the baseline network is attributable to its lower average response time than that of other networks. Figure 23 shows the average application-layer HTTP response time observed in each scenario. The y-axis represents the HTTP response time (s).

Based on the previous results and given the haphazard implementation, the core network’s performance, despite its optical infrastructure, does not outperform the other scenarios. This is primarily due to the use of hubs instead of switches, and secondly, to the excessive use of secondary switches and their limited capacity. Therefore, these branches and the use of hubs also led to higher core-network latency than in the other scenarios. Figure 24 compares the average application-layer end-to-end delay across all network configurations, not round-trip time (RTT), and the y-axis represents the average end-to-end delay (s).

The shape of the lines in the figure above (for example, flat or somewhat wavy) gives an idea of the stability of the network’s transmission time over an hour.

In brief, for the Ministry of Industry and Minerals, Scenario 3 consistently outperformed others in database (270,000 bytes/s), voice (220,000 bytes/s), print (24,000 bytes/s), and FTP (18,000 bytes/s) traffic. However, Scenarios 1 and 2 achieved higher email throughput (9,000 bytes/s), and Scenario 1 matched the baseline network in HTTP traffic (8,500 bytes/s) due to lower response times.

Across all six applications—database, voice, print, FTP, email, and HTTP—the results consistently highlight the influence of network design on efficiency and service quality. While Scenarios 1 and 2 occasionally show modest improvements (notably in email and HTTP), they generally suffer from bottlenecks stemming from excessive resource consumption and limited scalability. The baseline network performs relatively well in FTP traffic but remains constrained by outdated design choices such as hubs and multiple low-capacity switches. In contrast, Scenario 3 consistently delivers superior performance across most applications.

Collectively, these results confirm that Scenario 3 provides the most balanced, cost-effective, and scalable design, outperforming the baseline and other scenarios in throughput, latency, and resource optimization. This makes Scenario 3 the most technically viable architecture.

Overall, the results show that structured Ethernet designs significantly outperform the Ministry’s current randomized fiber optic network designs. This means that a carefully planned network architecture significantly improves data exchange efficiency and overall performance.

4 Conclusion

Many Iraqi institutions, including ITPC, continue to rely on Wi-Fi networks due to their ease of installation. However, Wi-Fi-based infrastructures suffer from major limitations in transmission quality, particularly for voice, video, and data, and often deliver poor quality of service. Performance is further constrained by weak topology design, inadequate hardware, and the rising demand for data-intensive applications. These problems are especially acute in IEEE 802.11-based networks, where non-standardized implementation and inadequate planning resulted in generally weak performance metrics and limited economic feasibility.

To overcome these challenges and keep pace with rapid advances in telecommunications, several institutions, including the Ministry of Industry and Minerals, have started upgrading to fiber-optic networks. Yet, our analysis revealed that the lack of a structured design approach has prevented these optical networks from reaching their full potential, highlighting the need for systematic planning to achieve optimal performance.

This study presented a comprehensive evaluation of existing and redesigned institutional networks using a measurement-informed simulation approach. Real-world baseline observations were used to characterize current network behavior and to guide the development of realistic OPNET simulation models. These models were evaluated to analyze the impact of different services, applications, user loads, and network resource allocations. The simulation results showed clear performance superiority of the proposed networks over existing ones, confirming the importance of careful design and verification through modeling. By leveraging OPNET, institutions can develop optimized enterprise network scenarios that enable assessment of application performance, transmission efficiency, and resource utilization prior to real-world deployment. This approach not only reduces costs and shortens implementation timelines but also enhances data throughput while requiring fewer resources.

The comparative evaluation of the two current institutional networks demonstrates that neither wireless nor fiber-optic infrastructure can achieve satisfactory performance without a structured design, appropriate device selection, and traffic management. Based on the simulation outcomes, we recommend an optimized network design that incorporates carefully selected components and transmission media to achieve higher reliability, scalability, and efficiency.

The results confirm that network performance is strongly influenced by architectural design choices rather than transmission medium alone. This research provides practical insights into strengthening telecommunications infrastructure, emphasizing the critical role of thoughtful network design and simulation in advancing initiatives such as e-government development. By aligning technical strategies with real-world challenges, institutions can deliver more reliable, secure, and scalable network solutions.

Future studies may expand upon this analysis by incorporating additional traffic models or operational constraints, or by broadening the scope of quality of service (QoS) evidence to include packet loss/drop rate, jitter (especially for voice), link utilization, and queueing delay. However, this study establishes a clear and reproducible foundation for thoughtful network redesign.

Generative AI statement

The author(s) declared that generative AI was not used in the creation of this manuscript.

Any alternative text (alt text) provided alongside figures in this article has been generated by Frontiers with the support of artificial intelligence and reasonable efforts have been made to ensure accuracy, including review by the authors wherever possible. If you identify any issues, please contact us.

Publisher’s note

All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.

Footnotes

Edited by: Stefano Caputo, University of Florence, Italy

Reviewed by: Giacomo Borghini, University of Florence, Italy

Roberto Picchi, University of Florence, Italy