Syntax Literate: Jurnal Ilmiah Indonesia p–ISSN:
2541-0849 e-ISSN: 2548-1398
Vol. 9, No.
4, April 2024
OPTIMIZING
TRAFFIC CONGESTION IN ROUTE PLANNING USING A SIMPLE PATH ALGORITHM
Brillian
Adhiyaksa Kuswandi1*, Faqih Hamami2, Riska Yanu Fa’rifah3
Telkom University, Bandung, West Java,
Indonesia1,2,3
Email:
[email protected]1*, [email protected]2,
[email protected]3
Abstract
The increasing demand for a reliable internet
network is very important to meet the needs of companies. However, currently
the ranking of mobile internet and internet in Indonesia is still below global
standards. Network congestion, which is a major contributor to low internet
quality, causes various challenges such as service outages, communication
failures, and decreased connection speeds. The study emphasizes the importance
of implementing effective congestion management mechanisms. Focusing on the
utilization of the simple path method and comparing its effectiveness with the
Dijkstra algorithm in managing internet networks, this study aims to develop
network traffic optimization methods and identify alternative routes to improve
overall network performance, especially in complex traffic conditions, within
the framework of a Decision Support System (DSS). The analysis showed that the
use of Simple Path increased packet delivery rates threefold and reduced packet
loss by half compared to the traditional Dijkstra method, with 58.54% of
packets successfully delivered and a 41.46% reduction in packet loss. In
addition, Simple Path facilitates the use of alternative routes for about 24%
of total requests using alternative routes. Network graph exploration
identifies solid points and analyzes the capacity on each network link. Twelve
links show occupancy rates above 90%, indicating congestion, with NE2-4-KBL to
NE3-KBL-HSI as the main cause of package delivery failures, accounting for
about 70.6% of total failed requests. Simple Path analysis highlights about 46%
of total failed requests, passing through this link. These findings emphasize
the importance of congestion management strategies and the use of alternative
routes to improve network performance and reduce packet loss, thereby
contributing to business efficiency, user experience, and customer
satisfaction.
Keywords: congestion management, simple path,
Alternative routing, Network Traffic Optimization
Introduction
The development of
internet network technology that continues to increase is a must to meet the
demands of companies in getting a reliable network (Zhou, et al, 2021). Along
with the times, the current internet network is not only expected to have high
speed but also optimal stability and minimal latency (Ngafifi, 2014). This need is
increasingly urgent along with the results of the Databoks report which records
the number of internet users in Indonesia in 2022 to reach 204.7 million
people, or equivalent to 73.7% of the total population. This figure reflects
significant internet penetration in the community, showing how important the
existence of a reliable internet network is in supporting the company's daily
activities and operations.
Currently, Indonesia
is in the 112th position for mobile internet and the 123rd for fixed internet
(Simon Kemp, 2022). This ranking underlines the quality of internet networks in
Indonesia which is still low compared to global standards. Low internet
connection quality, which is generally caused by network congestion, has the
potential to cause a variety of problems, including service outages,
communication failures, low connection speeds, and increased response times
(Salman, Ginting, & Wahyuningrum, 2021; Zulkifli, 2014; Siddik, Lubis,
& Sahren, 2023).
The impact of this
network congestion is very diverse, especially in the context of business and
user experience (Firdausi, 2022). First, network congestion can cause service
outages, especially in situations that require reliable connectivity, such as
online financial transactions or critical data transmissions. Second,
communication failures, such as virtual meetings, due to network congestion can
hamper company operations and result in financial losses (Sina, Amsikan, &
Salsinha, 2021).
In addition, low
connection speeds have the potential to slow down business processes and reduce
productivity. Delays in access to information or data processing can harm
companies in making quick and effective decisions (Sina, Amsikan, &
Salsinha, 2021). In the context of user experience, high response times due to
network congestion can create frustration and dissatisfaction. According to a
PricewaterhouseCoopers (PWC) report, the level of Internet customer
satisfaction in Indonesia has decreased by 61%. This shows that the level of
customer satisfaction with internet services in Indonesia is still low,
indicating the need to improve internet quality with a focus on Quality of
Service (QoS) (Ruth, 2015; Priyatna, Marsudi, & Rahadjeng, 2023).
Control over network
congestion is the main key to achieving a superior Quality of Service (QoS)
mechanism (Cardwell et al., 2019). Congestion management is an integral part of
error management that plays a crucial role in helping administrators address
problems that may arise on the network. With congestion control, administrators
can avoid manual actions such as path switching and short path calculations in
network topologies, ensuring higher operational efficiency.
However, in its
implementation, often the ability to optimize network traffic and provide
alternative routes to maintain smooth network operations is still not fully
realized in modern network design. This creates its challenges for
administrators who are often faced with similar problems. At present, the
solution to these problems is still often done manually or based on personal
experience.
A common method that
administrators can use to optimize traffic is to apply the Dijkstra algorithm.
This algorithm is effective in calculating the shortest and fastest routes, as
reinforced by research findings stating that Dijkstra is very suitable for
optimization (Lakutu et al., 2023). However, the use of Dijkstra has weaknesses
in handling optimization on networks that experience congestion. The Dijkstra
algorithm produces only one output path, and when that path is congested,
Dijkstra cannot provide an alternative path.
Alternative routes
are crucial for congestion management, as they play a pivotal role in reducing
congestion, enhancing environmental performance, and fostering connectivity (Szele
& Kisgyörgy, 2018). Recognizing these crucial aspects, it becomes
imperative to explore alternative methods that address the shortcomings of the
Dijkstra algorithm.
Research entitled
"A Multi-Stage Metaheuristic Algorithm for Shortest Simple Path Problem
with Must-Pass Nodes" has shown that simple path methods adeptly overcome
these limitations by providing alternative routes (Su, Zhang, & Lü, 2019).
This approach has proven to be more efficient in optimizing network conditions,
offering an alternative path in case of congestion. Simple path implementation
is emerging as a promising approach capable of improving network efficiency and
resilience to potential congestion, thus providing advantages in optimizing
network performance and overall service quality.
Based on these
issues, this research aims to develop methods to optimize network traffic and
provide alternative routes during congestion, using topology and network PT XYZ
as a case study. It will adopt an optimization approach, f
ocusing on the simple
path method, to identify solutions for enhancing network performance amidst
complex traffic scenarios. This research holds significant importance due to
the critical need for effective traffic optimization strategies, particularly
given Indonesia's subpar internet quality compared to global standards.
Based on the
formulation of the problem that has been described, the objectives of this
study can be described as follows:
1)
To assess and compare the results of the
analysis conducted using the Dijkstra and Simple Path algorithms in optimizing
the network topology of PT XYZ.
2)
To investigate the impact of implementing the
Simple Path algorithm on network routing within the network topology of PT XYZ.
3)
To find out the topology condition after
using the simple path method.
Research Methodology
Conceptual
Model
This research employs
the design science approach, a problem-solving paradigm aimed at constructing
knowledge to achieve goals (Vom Brocke, Hevner, & Maedche, 2020). The
primary objective of this study is to produce a research framework in the field
of information systems that integrates environmental aspects and foundational
knowledge from previous research. This framework aims to facilitate a better
understanding of the research by defining the problems and illustrating their
solutions. The problem-solving framework is depicted in Figure 1.
Figure 1. Conceptual model
This troubleshooting
framework focuses on technology environments, where administrators currently
perform network route mapping manually. Therefore, this research becomes
important to create IT artifacts that can optimize traffic density in route
planning. The output of this study will be evaluated by testing the packet
delivery rate and packet loss of the traffic density optimization architecture
on route planning developed by the authors. Basic concepts from previous
studies, such as network congestion, the Dijkstra algorithm, simple paths, and
alternative paths, were adopted in this study. The technologies used in this
study include Visual Studio Code, Python programming languages, NetworkX, and
Streamlit. This architecture development methodology uses a Decision Support
System (DSS).
Systematics
of Problem Solving
In conducting
research, a clear and structured system is needed. Therefore, a systematic
solution is needed to solve the research problem. The author uses the
systematics of solving the Decision Support System (DSS). The DSS concept has
five stages, namely initiation, data collection, preprocessing, system design,
and measurement. The following stages of research systematics are described in
Figure 2.
Figure 2. Research Systematics
Data
Collection
At this stage, a data collection
process was carried out sourced from PT XYZ, a company that was the focus of
research. The data taken involves several tabular data that present detailed
information about the network topology structure used by PT XYZ. In addition,
the data collected also includes information related to requests in the network
environment. This data collection process is carried out carefully to ensure
the accuracy and completeness of the information that forms the basis of
further analysis to understand and improve the efficiency and performance of PT
XYZ's network.
Data
Processing
The data that has been successfully collected comes in
the form of tabular data stored in CSV format. Ensuring the quality and
relevance of the data is the initial step in data processing, which involves
thorough handling of data duplication to eliminate redundancy and ensure data
integrity and accuracy. The subsequent step involves handling missing data,
aimed at addressing any absent data points. Following this, data scaling is
performed to standardize the units used in the data. Finally, the last step
involves data merging, integrating two initially separate data sources into one
comprehensive and cohesive dataset.
Design
Structures and Functions
Once the data preprocessing phase is
complete, the next steps involve creating a graph structure, optimization, and
designing the user interface. These components are crucial in designing the
foundation for effective and effective data analysis.
Measurement
Method
Results
and Discussion
Data Collection
In this
research, analysis was conducted using two different data sets. The first
dataset contains information about the network infrastructure, while the second
dataset contains internet traffic data.
Network
Data Infrastructure
The first
dataset, referred to as the network infrastructure data, is contained in a file
named “relationlink”. This dataset provides detailed information about the
network topology, including the connections between various network nodes. The
following is a sample of the network data infrastructure data in Table 1.
Table
1. Sample Relationlink Data
|
froma |
tob |
totalkap |
cost |
|
NE1-00-MGO-3 |
NE2--MGO |
30 |
NULL |
|
NE2--MGO |
NE2-9-KBL |
100 |
60000 |
|
NE2-9-KBL |
NE2-9-RKT |
500 |
10 |
|
NE2-9-KBL |
NE34-KBL-TRANSIT |
120 |
NULL |
|
NE2-9-KBL |
NE32-KBL-VPN |
110 |
NULL |
|
NE2-9-RKT |
NE32-RKT-VPN |
82 |
NULL |
|
NE32-RKT-VPN |
P-RKT |
20 |
NULL |
|
P-RKT |
NE34-KBL-TRANSIT |
10 |
65535 |
|
NE34-KBL-TRANSIT |
NE2-9-KBL |
66 |
NULL |
|
NE34-KBL-TRANSIT |
NE2-8-KBL |
40 |
NULL |
|
NE2-8-KBL |
NE32-KBL-VPN |
11 |
NULL |
|
NE32-KBL-VPN |
CN_Iptv |
110 |
NULL |
Following the description of network infrastructure data in Table IV.1,
it is important to outline the key attributes that play an important role in understanding
and optimizing network topology. The node identifier, denoted as the
"froma" and "tob" columns, serves as an important indicator
of the start and end points of a network link. These identifiers form the
backbone of the network structure, providing insight into connectivity and
relationships between various network nodes.
In addition, the "totalkap" column in the dataset is very
important, as it shows the overall capacity of each link in the network. These
capacity metrics play an important role in assessing the efficiency and
feasibility of the network to accommodate data flows. Understanding the total
capacity of network links is critical to making informed decisions regarding
data routing and resource allocation in the network infrastructure.
In addition, the "cost" column reflects the charges charged
for traversing a particular connection within the network. This cost factor is
integral in the decision-making process, influencing the selection of optimal
routes and resource utilization strategies. A thorough analysis of these key
attributes contributes to a comprehensive understanding of network
capabilities, enabling informed decision-making to improve the performance and
reliability of the overall network infrastructure. The following is an explanation
of the columns in relationlink data, which are found in Table 2.
Table
2. Relation link Column Explanation
|
Column Name |
Data Type |
Description |
|
froma |
string |
This
column represents the initial identification or starting point of a
connection or link in the network. |
|
tob |
string |
This
column reflects the identification of the connected points from the froma
column. |
|
totalkap |
integer |
This
column contains the total capacity of each path or connection in the network. |
|
cost |
float |
This
column reflects the charges charged for traversing a particular connection
within the network. |
Data
Usage
The second
dataset, titled "Uplink" and "Downlink," furnishes
information on network requests. This dataset encapsulates details regarding
bandwidth and the types of services operational in diverse network segments. It
stands as a pivotal source for comprehending the utilization of network
resources and the distribution of traffic load by various service types across
network segments. Analyzing the "Usage Data" offers profound insights
into network usage, aids in capacity planning, and supports decision-making
concerning resource optimization and overall network performance enhancement.
The distinction between uplink and downlink lies in the direction and
destination of requests, with uplink involving requests
from lower to higher levels, and downlink operating in the opposite
direction. Furthermore, an elucidation of the column descriptions for both
Uplink and Downlink data is provided in Table 3.
Table 3. Uplink and Downlink Column Explanation
|
Column Name |
Data Type |
Description |
|
froma |
string |
This column represents the starting point of network traffic,
providing information about the source of data movement within the system |
|
tob |
string |
This column represents the endpoint of the network traffic, giving
an idea of the destination or destination of the data in the network |
|
service |
categorical |
This describes the type of service using the network link, such as
retail, mobile, wholesale, and ebis services. |
|
bandwidth |
integer |
This
quantifies the amount of bandwidth used in each link, which is essential for
assessing the load and capacity utilization of the network. |
Uplink
The
Uplink dataset encompasses requests from lower to higher levels, specifically
focusing on those originating from lower-level nodes and directed towards
higher-level nodes in the network hierarchy. A sample of the Uplink data is
presented in Table 4.
Table 4. Sample
Uplink Data
|
froma |
tob |
service |
bandwidth |
|
NE1-00-MGO-3 |
CN_Iptv |
RETAIL |
82 |
|
NE1-00-ABU-2DSU |
CN_Netflix |
EBIS |
12 |
|
NE1-00-ABT-3 |
CGW-.BDS |
WHOLESALE |
35 |
|
NE1-00-SAR-5 |
CN_Google |
MOBILE |
16 |
|
NE1-02-KNN-3 |
CGW-.MDO |
MOBILE |
162 |
Downlink
The Downlink
dataset encompasses requests from higher to lower levels, specifically focusing
on those originating from higher-level nodes and directed towards lower-level
nodes in the network hierarchy. A sample of the Downlink data is presented in
Table 5.
Table
5. Sample Downlink Data
|
froma |
tob |
service |
bandwidth |
|
CGW2-.BTC |
NE1-00-ABT-3 |
RETAIL |
82 |
|
CN_Netflix |
NE1-00-ABU-2DSU |
EBIS |
35 |
|
CGW-.BDS |
NE1-00-ABT-3 |
WHOLESALE |
105 |
|
CN_Google |
NE1-00-SAR-5 |
MOBILE |
48 |
|
CGW-.MDO |
NE1-02-KNN-3 |
MOBILE |
487 |
Data
Preprocessing
Data
preprocessing is a critical step in the analysis process, particularly in
network optimization studies. This chapter details the procedures undertaken to
prepare the Network Infrastructure Data and the Usage Data for effective
utilization in the ant colony optimization algorithm for network topology and
capacity management.
Duplicate
Data Filtering
This process is designed to
filter the data under investigation or analysis, mitigating the risk of
duplication within the dataset. Throughout this procedure, searches are
conducted for comparable data entities within the dataset. If similar records
are identified, one of them will be eliminated. The outcomes of filtering
duplicate data in Table 6 are presented below.
Table 6.
Filtering Data Result
|
Filtering Data Results |
|
|
Before |
9900 rows |
|
After |
6138 rows |
With
reference to Table 6, before implementing the data screening process, there
were a total of 9900 reviews in the dataset. However, after going through the
filtering stage, the number of reviews was reduced to 6138, following the
deletion of 3762 data.
Missing Value Handling
In the
cost column, numerous entries were observed to be null or missing. Given the
focus of the study on network topology and capacity rather than cost analysis,
these null values were considered zero and hence not subject to cost
imputation.
Table
7. Missing Value Handing Result
|
froma |
tob |
totalkap |
cost |
|
NE1-00-MGO-3 |
NE2--MGO |
30 |
0 |
|
NE2--MGO |
NE2-9-KBL |
100 |
60000 |
|
NE2-9-KBL |
NE2-9-RKT |
500 |
10 |
|
NE2-9-KBL |
NE34-KBL-TRANSIT |
120 |
0 |
|
NE2-9-KBL |
NE32-KBL-VPN |
110 |
0 |
|
NE2-9-RKT |
NE32-RKT-VPN |
82 |
0 |
|
NE32-RKT-VPN |
P-RKT |
20 |
0 |
|
P-RKT |
NE34-KBL-TRANSIT |
10 |
65535 |
|
NE34-KBL-TRANSIT |
NE2-9-KBL |
66 |
0 |
|
NE34-KBL-TRANSIT |
NE2-8-KBL |
40 |
0 |
|
NE2-8-KBL |
NE32-KBL-VPN |
11 |
0 |
|
NE32-KBL-VPN |
CN_Iptv |
110 |
0 |
From
Table IV.2.2.1, the paths from NE1-00-MGO-3 to NE2--MGO, NE2-9-KBL to
NE34-KBL-TRANSIT, NE2-9-KBL to NE32-KBL-VPN, NE2-9-RKT to NE32-RKT-VPN,
NE32-RKT-VPN to P-RKT, NE34-KBL-TRANSIT to NE2-9-KBL, NE34-KBL-TRANSIT to
NE2-8-KBL, NE2-8-KBL to NE32-KBL-VPN, and NE32-KBL-VPN to CN_Iptv, the cost is
NULL. Subsequently, the NULL values will be replaced with a value of 0.
Data Scaling
Data scaling within the "relationlink" dataset is
indispensable owing to the inherent disparity in the units utilized for the "uplink"
and "downlink" data. While the "relationlink" dataset
employs Gbps (Gigabits per second) as its standard unit of measurement, the
"uplink" and "downlink" data are denoted in Mbps (Megabits
per second). Consequently, harmonizing these units becomes imperative to
facilitate a cohesive and uniform interpretation of the dataset. By aligning
the units to a common standard, such as converting Gbps to Mbps through a
multiplication factor of 1000.
Table
8. Data Scaling Result
|
froma |
tob |
totalkap |
cost |
|
NE1-00-MGO-3 |
NE2--MGO |
30000 |
0 |
|
NE2--MGO |
NE2-9-KBL |
100000 |
60000 |
|
NE2-9-KBL |
NE2-9-RKT |
500000 |
10 |
|
NE2-9-KBL |
NE34-KBL-TRANSIT |
120000 |
0 |
|
NE2-9-KBL |
NE32-KBL-VPN |
110000 |
0 |
|
NE2-9-RKT |
NE32-RKT-VPN |
82000 |
0 |
|
NE32-RKT-VPN |
P-RKT |
20000 |
0 |
|
P-RKT |
NE34-KBL-TRANSIT |
10000 |
65535 |
|
NE34-KBL-TRANSIT |
NE2-9-KBL |
66000 |
0 |
|
NE34-KBL-TRANSIT |
NE2-8-KBL |
40000 |
0 |
|
NE2-8-KBL |
NE32-KBL-VPN |
11000 |
0 |
|
NE32-KBL-VPN |
CN_Iptv |
110000 |
0 |
Data
Merging
Merging data is a crucial step in the analysis process because the
"Uplink" and "Downlink" datasets refer to the same request
in the context of the network. Without merging, the risk of inappropriate
prioritization may arise during the optimization process. This merger ensures
that data from both sources is brought together coherently, allowing uniform
handling of network requests. By aggregating data, we can avoid bias in the
optimization process and ensure that all types of requests, both from uplinks and
downlinks, are treated in a balanced manner.
Table
9.
Data Merging Result
|
froma |
tob |
service |
bandwidth |
|
NE1-00-MGO-3 |
CN_Iptv |
RETAIL |
27 |
|
NE1-00-ABU-2DSU |
CN_Netflix |
EBIS |
12 |
|
NE1-00-ABT-3 |
CGW-.BDS |
RETAIL |
35 |
|
NE1-00-SAR-5 |
CN_Google |
MOBILE |
16 |
|
CN_Iptv |
NE1-00-MGO-3 |
RETAIL |
82 |
|
CN_Netflix |
NE1-00-ABU-2DSU |
EBIS |
35 |
|
CGW-.BDS |
NE1-00-ABT-3 |
WHOLESALE |
105 |
|
CN_Google |
NE1-00-SAR-5 |
MOBILE |
48 |
Graph Structure
Figure 3. Graph structure of a
topology subset
In Figure 3 you can see the graph structure of a topology
subset. Each node has a unique name. Between the two nodes, there is a link
that indicates the direction of movement of traffic. In addition to providing
information about directions, the link also lists the total capacity marked in
green if the capacity has never been used or has a usage of 0%. If the usage
capacity reaches 90%, the link will be red. In addition to information about
capacity, there is also cost information written in orange.
Optimization
Optimization
refers to the process of improving or optimizing performance, efficiency, or
resources in a network. The main goal of network optimization is to achieve
better or optimal conditions to meet needs, minimize costs, or improve
operational efficiency.
Get
Available Path
The function to obtain
available paths has a crucial role in the network optimization process. In this
context, the use of certain algorithms, such as the Simple Path method, becomes
crucial to determine the optimal path between the 'froma' (origin) node and the
'tob' (destination) node. Note that the Simple Path method takes into account certain constraints, where the resulting path
should not be looped. For example, if it has passed a node on the path, it is
not allowed to pass the same node again, because this is considered looping. To
understand more, it is important to know the available paths from NE1-00-MGO-3
to CN_Iptv by paying attention to the restrictions imposed by the Simple Path
method.
1. Route 1 is
NE1-00-MGO-3, NE2--MGO, NE2-9-KBL, NE32-KBL-VPN, CN_Iptv is the initial path
that can be taken. This path does not loop, so it can be referred to as a
simple path.
Figure 4. Route 1
2. Route 2, which
consists of NE1-00-MGO-3, NE2--MGO, NE2-9-KBL, NE34-KBL-TRANSIT, NE2-8-KBL,
NE32-KBL-VPN, and CN_Iptv, serves as the alternative path. This route maintains
a non-looping trajectory, thus qualifying as a simple path. Route 2 is chosen
when Route 1 experiences congestion, particularly on the link connecting
NE2-9-KBL and NE32-KBL-VPN.
Figure 5. Route 2
3. Route 3, which
consists of NE1-00-MGO-3, NE2--MGO, NE2-9-KBL, NE2-9-RKT, NE32-RKT-VPN, P-RKT,
NE34-KBL-TRANSIT, NE2-8-KBL, NE32-KBL-VPN, and CN_Iptv, serves as the
alternative path. This route maintains a non-looping trajectory, thus
qualifying as a simple path. Route 3 is chosen when Route 2 experiences
congestion, particularly on the link connecting NE2-9-KBL to NE32-KBL-VPN and
NE2-9-KBL to NE34-KBL-TRANSIT.
Figure 6. Route 3
4. Route 4, which
consists of NE1-00-MGO-3, NE2--MGO, NE2-9-KBL, NE2-9-CTR, NE32-RKT-VPN, P-RKT,
NE34-KBL-TRANSIT, NE2-9-KBL, NE32-KBL-VPN, and CN_Iptv. This route cannot be
used because there is looping on the NE2-9-KBL node, so it is not included in
the simple path because it violates the looping rules. So, this route cannot be
said to be a simple path and alternative route. Therefore, this path will not
be included in the available path.
Figure 7. Route 4
Routing Optimization
After obtaining the available paths, routing optimization occurs,
prioritizing services by type: mobile, wholesale, ebis, and retail. The paths
obtained through the simple path method are then sorted based on length and
total cost, followed by sorting based on total_path count, from smallest to
largest.
1.
Service Type
Prioritizing based on service type is the main step to be taken because
the order of services from mobile, wholesale, ebis, and retail is regulated as
a policy by PT XYZ.
Table 10. Prioritize Service Types
|
Before |
||||
|
froma |
tob |
Service |
path |
total_ path |
|
NE1-00-MGO-3 |
CN_Iptv |
RETAIL |
[[NE1-00-MGO-3, NE2--MGO, NE2-9-KBL,
NE34-KBL-TRANSIT, NE2-8-KBL, NE32-KBL-VPN, CN_Iptv], [NE1-00-MGO-3, NE2--MGO,
NE2-9-KBL, NE32-KBL-VPN, CN_Iptv], [NE1-00-MGO-3, NE2--MGO, NE2-9-KBL,
NE2-9-RKT, NE32-RKT-VPN, P-RKT, NE34-KBL-TRANSIT, NE2-8-KBL, NE32-KBL-VPN,
and CN_Iptv]] |
3 |
|
NE1-00-ABU-2DSU |
CN_Netflix |
EBIS |
[['NE1-00-ABU-2DSU', 'NE2--ABT',
'NE2-2-SMP', 'NE2-9-RKT', 'NE3-RKT-VPN', 'P-KBL', 'NE3-KBL-VPN', 'NE2-4-KBL',
'NE3-KBL-HSI', 'CN_Netflix'], ['NE1-00-ABU-2DSU', 'NE2--ABT', 'NE2-2-SMP',
'NE2-9-RKT', 'NE32-RKT-TRANSIT', 'P-KBL', 'NE3-KBL-VPN', 'NE2-4-KBL',
'NE3-KBL-HSI', 'CN_Netflix']] |
2 |
|
NE1-00-ABT-3 |
CGW-.BDS |
RETAIL |
[['NE1-00-ABT-3', 'NE2--ABT',
'NE2-2-SMP', 'NE2-9-RKT', 'NE32-RKT-VPN', 'P-RKT', 'P-D1-BDS', 'CGW-.BDS'],
['NE1-00-ABT-3', 'NE2--ABT', 'NE2-2-SMP', 'NE2-9-RKT', 'NE3-RKT-VPN',
'P-RKT', 'P-D1-BDS', 'CGW-.BDS']] |
2 |
|
After |
||||
|
froma |
tob |
Service |
path |
total_ path |
|
NE1-00-ABU-2DSU |
CN_Netflix |
EBIS |
[['NE1-00-ABU-2DSU', 'NE2--ABT',
'NE2-2-SMP', 'NE2-9-RKT', 'NE3-RKT-VPN', 'P-KBL', 'NE3-KBL-VPN', 'NE2-4-KBL',
'NE3-KBL-HSI', 'CN_Netflix'], ['NE1-00-ABU-2DSU', 'NE2--ABT', 'NE2-2-SMP',
'NE2-9-RKT', 'NE32-RKT-TRANSIT', 'P-KBL', 'NE3-KBL-VPN', 'NE2-4-KBL',
'NE3-KBL-HSI', 'CN_Netflix']] |
2 |
|
NE1-00-MGO-3 |
CN_Iptv |
RETAIL |
[[NE1-00-MGO-3, NE2--MGO, NE2-9-KBL,
NE34-KBL-TRANSIT, NE2-8-KBL, NE32-KBL-VPN, CN_Iptv], [NE1-00-MGO-3, NE2--MGO,
NE2-9-KBL, NE32-KBL-VPN, CN_Iptv], [NE1-00-MGO-3, NE2--MGO, NE2-9-KBL,
NE2-9-RKT, NE32-RKT-VPN, P-RKT, NE34-KBL-TRANSIT, NE2-8-KBL, NE32-KBL-VPN,
and CN_Iptv]] |
3 |
|
NE1-00-ABT-3 |
CGW-.BDS |
RETAIL |
[['NE1-00-ABT-3', 'NE2--ABT',
'NE2-2-SMP', 'NE2-9-RKT', 'NE32-RKT-VPN', 'P-RKT', 'P-D1-BDS', 'CGW-.BDS'],
['NE1-00-ABT-3', 'NE2--ABT', 'NE2-2-SMP', 'NE2-9-RKT', 'NE3-RKT-VPN',
'P-RKT', 'P-D1-BDS', 'CGW-.BDS']] |
2 |
As
observed in Table 10, There has been a change in data, by categorizing by
service type. Priority is allocated to ebis services, reflecting the strategic
emphasis on this category of services, followed by retail services. This
categorization is in line with the protocol established at PT XYZ, where
services are sorted systematically, starting with mobile services, followed by
wholesale, ebis, and finally retail services.
2.
Path
Route planning by prioritizing the order from shortest to longest is an
optimization strategy that provides advantages in the initial inspection of
shorter routes, facilitating quicker decision-making and potentially reducing
computational complexity. Additionally, arranging routes based on their length,
complemented by sorting based on cost values from lowest to highest,
constitutes a fundamental step aimed at optimizing resource allocation and
minimizing cost usage. This meticulous process not only ensures the selection
of routes that are short and direct but also economically viable, thereby
enhancing the overall efficiency and robustness of the network infrastructure.
Table 11. Prioritize Path and Cost
|
Before |
||||
|
froma |
tob |
Service |
path |
total_ path |
|
NE1-00-ABU-2DSU |
CN_Netflix |
EBIS |
[['NE1-00-ABU-2DSU', 'NE2--ABT',
'NE2-2-SMP', 'NE2-9-RKT', 'NE3-RKT-VPN', 'P-KBL', 'NE3-KBL-VPN', 'NE2-4-KBL',
'NE3-KBL-HSI', 'CN_Netflix'], ['NE1-00-ABU-2DSU', 'NE2--ABT', 'NE2-2-SMP',
'NE2-9-RKT', 'NE32-RKT-TRANSIT', 'P-KBL', 'NE3-KBL-VPN', 'NE2-4-KBL',
'NE3-KBL-HSI', 'CN_Netflix']] |
2 |
|
NE1-00-MGO-3 |
CN_Iptv |
RETAIL |
[[NE1-00-MGO-3, NE2--MGO, NE2-9-KBL,
NE34-KBL-TRANSIT, NE2-8-KBL, NE32-KBL-VPN, CN_Iptv], [NE1-00-MGO-3, NE2--MGO,
NE2-9-KBL, NE32-KBL-VPN, CN_Iptv], [NE1-00-MGO-3, NE2--MGO, NE2-9-KBL,
NE2-9-RKT, NE32-RKT-VPN, P-RKT, NE34-KBL-TRANSIT, NE2-8-KBL, NE32-KBL-VPN,
and CN_Iptv]] |
3 |
|
NE1-00-ABT-3 |
CGW-.BDS |
RETAIL |
[['NE1-00-ABT-3', 'NE2--ABT', 'NE2-2-SMP',
'NE2-9-RKT', 'NE32-RKT-VPN', 'P-RKT', 'P-D1-BDS', 'CGW-.BDS'],
['NE1-00-ABT-3', 'NE2--ABT', 'NE2-2-SMP', 'NE2-9-RKT', 'NE3-RKT-VPN',
'P-RKT', 'P-D1-BDS', 'CGW-.BDS']] |
2 |
|
After |
||||
|
froma |
tob |
Service |
path |
total_ path |
|
NE1-00-ABU-2DSU |
CN_Netflix |
EBIS |
[['NE1-00-ABU-2DSU', 'NE2--ABT',
'NE2-2-SMP', 'NE2-9-RKT', 'NE3-RKT-VPN', 'P-KBL', 'NE3-KBL-VPN', 'NE2-4-KBL',
'NE3-KBL-HSI', 'CN_Netflix'], ['NE1-00-ABU-2DSU', 'NE2--ABT', 'NE2-2-SMP',
'NE2-9-RKT', 'NE32-RKT-TRANSIT', 'P-KBL', 'NE3-KBL-VPN', 'NE2-4-KBL', 'NE3-KBL-HSI',
'CN_Netflix']] |
2 |
|
NE1-00-MGO-3 |
CN_Iptv |
RETAIL |
[[NE1-00-MGO-3, NE2--MGO, NE2-9-KBL,
NE32-KBL-VPN, CN_Iptv], [NE1-00-MGO-3, NE2--MGO, NE2-9-KBL, NE34-KBL-TRANSIT,
NE2-8-KBL, NE32-KBL-VPN], [NE1-00-MGO-3, NE2--MGO, NE2-9-KBL, NE2-9-RKT,
NE32-RKT-VPN, P-RKT, NE34-KBL-TRANSIT, NE2-8-KBL, NE32-KBL-VPN, and CN_Iptv]] |
3 |
|
NE1-00-ABT-3 |
CGW-.BDS |
RETAIL |
[['NE1-00-ABT-3', 'NE2--ABT',
'NE2-2-SMP', 'NE2-9-RKT', 'NE32-RKT-VPN', 'P-RKT', 'P-D1-BDS', 'CGW-.BDS'],
['NE1-00-ABT-3', 'NE2--ABT', 'NE2-2-SMP', 'NE2-9-RKT', 'NE3-RKT-VPN',
'P-RKT', 'P-D1-BDS', 'CGW-.BDS']] |
2 |
Noted
in Table 11, there is a change in the line from NE1-00-MGO-3 to CN_Iptv because
sorting is based on the length of the line and the total cost of each line. For
lines through NE1-00-MGO-3, NE2--MGO, NE2-9-KBL, NE34-KBL-TRANSIT, NE2-8-KBL,
and NE32-KBL-VPN have a path length of 6 with a total cost of 60000. Meanwhile,
the line through NE1-00-MGO-3, NE2--MGO, NE2-9-KBL, NE32-KBL-VPN, and CN_Iptv
has a line length of 5 with a total cost of 60000. Finally, the path through
NE1-00-MGO-3, NE2--MGO, NE2-9-KBL, NE2-9-RKT, NE32-RKT-VPN, P-RKT,
NE34-KBL-TRANSIT, NE2-8-KBL, NE32-KBL-VPN, and CN_Iptv has a path length of 10
for a total cost of 125545. From the description, it can be concluded that a
line with a length of 5 will take precedence, followed by a line with a length
of 6 and the same total cost, and the last is a line with a length of 10 and a
total cost of 125545.
3.
Total Path
Similar to routing based on length and cost, this step involves
structuring routes according to their total length. Routes with shorter total
lengths are prioritized, ensuring efficient data packet delivery, while longer
routes undergo handling at the final stage to address complexities and
potential congestion points.
Table 12. Prioritize Total Path
|
After |
||||
|
froma |
tob |
Service |
path |
total_ path |
|
NE1-00-ABU-2DSU |
CN_Netflix |
EBIS |
[['NE1-00-ABU-2DSU', 'NE2--ABT',
'NE2-2-SMP', 'NE2-9-RKT', 'NE3-RKT-VPN', 'P-KBL', 'NE3-KBL-VPN', 'NE2-4-KBL',
'NE3-KBL-HSI', 'CN_Netflix'], ['NE1-00-ABU-2DSU', 'NE2--ABT', 'NE2-2-SMP',
'NE2-9-RKT', 'NE32-RKT-TRANSIT', 'P-KBL', 'NE3-KBL-VPN', 'NE2-4-KBL',
'NE3-KBL-HSI', 'CN_Netflix']] |
2 |
|
NE1-00-MGO-3 |
CN_Iptv |
RETAIL |
[[NE1-00-MGO-3, NE2--MGO, NE2-9-KBL,
NE32-KBL-VPN, CN_Iptv], [NE1-00-MGO-3, NE2--MGO, NE2-9-KBL, NE34-KBL-TRANSIT,
NE2-8-KBL, NE32-KBL-VPN], [NE1-00-MGO-3, NE2--MGO, NE2-9-KBL, NE2-9-RKT,
NE32-RKT-VPN, P-RKT, NE34-KBL-TRANSIT, NE2-8-KBL, NE32-KBL-VPN, and CN_Iptv]] |
3 |
|
NE1-00-ABT-3 |
CGW-.BDS |
RETAIL |
[['NE1-00-ABT-3', 'NE2--ABT',
'NE2-2-SMP', 'NE2-9-RKT', 'NE32-RKT-VPN', 'P-RKT', 'P-D1-BDS', 'CGW-.BDS'],
['NE1-00-ABT-3', 'NE2--ABT', 'NE2-2-SMP', 'NE2-9-RKT', 'NE3-RKT-VPN',
'P-RKT', 'P-D1-BDS', 'CGW-.BDS']] |
2 |
|
After |
||||
|
froma |
tob |
Service |
path |
total_ path |
|
NE1-00-ABU-2DSU |
CN_Netflix |
EBIS |
[['NE1-00-ABU-2DSU', 'NE2--ABT',
'NE2-2-SMP', 'NE2-9-RKT', 'NE3-RKT-VPN', 'P-KBL', 'NE3-KBL-VPN', 'NE2-4-KBL',
'NE3-KBL-HSI', 'CN_Netflix'], ['NE1-00-ABU-2DSU', 'NE2--ABT', 'NE2-2-SMP',
'NE2-9-RKT', 'NE32-RKT-TRANSIT', 'P-KBL', 'NE3-KBL-VPN', 'NE2-4-KBL',
'NE3-KBL-HSI', 'CN_Netflix']] |
2 |
|
NE1-00-ABT-3 |
CGW-.BDS |
RETAIL |
[['NE1-00-ABT-3', 'NE2--ABT',
'NE2-2-SMP', 'NE2-9-RKT', 'NE32-RKT-VPN', 'P-RKT', 'P-D1-BDS', 'CGW-.BDS'],
['NE1-00-ABT-3', 'NE2--ABT', 'NE2-2-SMP', 'NE2-9-RKT', 'NE3-RKT-VPN', 'P-RKT',
'P-D1-BDS', 'CGW-.BDS']] |
2 |
|
NE1-00-MGO-3 |
CN_Iptv |
RETAIL |
[[NE1-00-MGO-3, NE2--MGO, NE2-9-KBL,
NE32-KBL-VPN, CN_Iptv], [NE1-00-MGO-3, NE2--MGO, NE2-9-KBL, NE34-KBL-TRANSIT,
NE2-8-KBL, NE32-KBL-VPN], [NE1-00-MGO-3, NE2--MGO, NE2-9-KBL, NE2-9-RKT,
NE32-RKT-VPN, P-RKT, NE34-KBL-TRANSIT, NE2-8-KBL, NE32-KBL-VPN, and CN_Iptv]] |
3 |
Noted
in Table 12, the route from NE1-00-ABT-3 to CGW-. BDS is prioritized because it
has 2 total_path, while the route from NE1-00-MGO-3 to
CN_Iptv has 3 total_path.
Congest
Scenario
Rerouting
Figure 8. Rerouting if route 1 is
congest
In
flowchart optimization, the initiation uses a simple path algorithm to get all
available paths with optimized available paths and with simple path constrain.
After that, the path will be looping, the first iteration will check the path
is available to use and the capacity is bigger than bandwidth. If yes, then the
path is the first iteration. If no, it will check if is there any alternative
route, if yes then it will check again the capacity. If no, then no path can
used for the request. Here is a flowchart of the procedure to follow when
congestion occurs in the network.
Figure 9. Flowchart optimization
Design User Interface
Figure 10. Database wireframe
The start page of the user
interface is an interface that displays the databases available in the system.
This page displays the datasets used, such as relationship data and data
requests. At this stage, users can see directly information about data
relationships and data requests that are the basis for decision making. It
allows users to quickly explore relevant dataset content and understand the
information structures that can be used to support decision processes.
Figure 11. Action wireframe
Furthermore, on the action page, the user can
decide or action. This page gives users the ability to add new requests, either
individually or in bulk. When adding a new request, the user is given the
option to carry out the process manually or automatically. If users choose the
manual approach, they can choose an available and walkable path. Conversely, if
the automatic option is selected, the decision will be executed automatically
by the system. Thus, the action page becomes a focal point for users to take
concrete steps in support of the decision-making process.
Figure 12. Dashboard wireframe
The Dashboard page is also
important to provide a brief overview of the actual situation that are
happening. In addition, the Dashboard also provides various graphs that
visualize the data clearly. In this case, the included graphs include score
cards, barcharts, linecharts, dataframe occupancy, and dataframe
recommendations. With the Dashboard, users can quickly understand the overall
information and make the right decisions based on the visualization of the data
presented.
Measurement
Furthermore, calculations are made using packet delivery ratio and
packet loss metrics. This process involves several stages, including
calculating the percentage of delivery success and package failure for each
request. An example calculation is performed for requests from NE1-00-MGO-3 to
CN_Iptv, which will be routed according to the network conditions described in
the congestion scenario, with a total of three routes available. The following
is the result of calculating packet delivery rate and packet loss.
1.
Calculations on the first route
When
the packet delivery ratio is 0% and the packet loss is 100%, it signifies a
scenario where none of the data packets sent from the source successfully reach
their intended destination. This indicates a complete failure in data
transmission along the initial route. In practical terms, it means that no
information or communication can be effectively conveyed between the source and
destination nodes using the primary path due to congestion or network failure.
In such circumstances, having alternative routes becomes crucial for
maintaining connectivity and ensuring that data can still be transmitted
despite the failure of the primary route. Alternative routes provide backup
paths that bypass congested or malfunctioning segments of the network, allowing
data packets to reach their destination even when the primary route encounters
issues.
1.
Calculation on the second route or alternative
route
When
nodes become impassable and congestion arises, the packet delivery rate drops
to 0%, and packet loss surges to 100% due to congestion on some links in route
1. Specifically, the capacity between NE2-9-KBL and NE32-KBL-VPN is only 18,
while the required bandwidth is 82. Such a scenario severely undermines network
performance. Hence, rerouting becomes imperative. Following rerouting, the
outcome is a significant improvement: the packet delivery rate increase to
100%, and packet loss decrease to 0%.
Test
Scenario
Tests are carried out to measure the performance of the system that has
been developed by ensuring that the inputs produce output according to needs.
The purpose of this test is to measure and evaluate the performance of the
system that has been implemented.
Table
13. Test Scenario
|
Scenario |
Bandwidth |
Total
Link |
Length
Link |
Cost |
|
Scenario 1 |
Dijkstra |
|||
|
Scenario 2 |
X |
X |
X |
X |
|
Scenario 3 |
Ascending |
X |
X |
X |
|
Scenario 4 |
Descending |
X |
X |
X |
|
Scenario 5 |
Ascending |
Ascending |
X |
X |
|
Scenario 6 |
Descending |
Ascending |
X |
X |
|
Scenario 7 |
Ascending |
Ascending |
Ascending |
Ascending |
|
Scenario 8 |
Descending |
Ascending |
Ascending |
Ascending |
Conclusion
Based on the results of
the final project research that has been carried out, the following conclusion
formulation is obtained; (1) the results of network optimization testing
using the Dijkstra algorithm and Simple Path show that Simple Path consistently
provides far superior performance than Dijkstra. Overall, Simple Path managed
to increase packet delivery by 3 times and reduce packet loss by half compared
to Dijkstra. Further analysis also revealed that Simple Path's advantages are
not only limited to the overall level, but are also seen in every type of
service, including mobile, wholesale, ebis, and retail. This shows that Simple
Path has significant potential to improve overall network performance across
multiple service contexts, (2) the implementation of Simple Path has a positive
impact on overall network performance. Simple Path has consistently shown a
significant increase in package delivery, with 58.54% of packages successfully
delivered, as well as a 41.46% reduction in packet loss. In addition, the use
of Simple Path also opens opportunities for the use of alternative routes, as
evidenced by as many as 804 or about 24% of total requests using alternative
routes. Thus, Simple Path not only improves the efficiency of packet delivery
but also increases flexibility in network route management, which can
ultimately optimize overall network performance, and (3) several challenges
faced in network management, especially related to occupancy rates and package
delivery failures. From testing, it was identified that as many as 12 links had
an occupancy rate above 90%, indicating a congested state on these links.
Furthermore, there is one main link that is the main cause of package delivery
failure, namely NE2-4-KBL to NE3-KBL-HSI which causes as many as 2726 requests,
or about 70.6% of the total requests that fail to be sent. Analysis using
Simple Path also showed that 11093 routes, or about 46% of the total failed
requests, went through this link.
BIBLIOGRAPHY
Cardwell, N., Jacobson, V., Cheng, Y., Yeganeh, S.H.,
Vasiliev, V., Swett, I., Jha, P., Seung, Y., & Wetherall, D. (2019).
Model-based Network Congestion Control.
Databoks. Pusat Data Ekonomi dan Bisnis Indonesia. (2022,
March 23).
https://databoks.katadata.co.id/datapublish/2022/03/23/ada-2047-juta-pengguna-internet-di-indonesia-awal-2022
Firdausi, A. (2022). Pengoptimasian Traffic pada Jaringan
Wide Area Network Menggunakan Application Aware Routing Berbasis SD-WAN.
InComTech: Jurnal Telekomunikasi dan Komputer.
Lakutu,
N.F., Mahmud, S.L., Katili, M.R., & Yahya, N.I. (2023). Algoritma Dijkstra
dan Algoritma Greedy Untuk Optimasi Rute Pengiriman Barang Pada Kantor Pos
Gorontalo.
Ngafifi, M. (2014). Kemajuan Teknologi Dan Pola Hidup
Manusia Dalam Perspektif Sosial Budaya.
Priyatna, I.K., Marsudi, M., & Rahadjeng, E.R.
(2023). The Effect of Service Quality and Price on Purchasing Decision of
Telkomsel Internet Services in Indonesia.
Ruth, E. (2015). Deskripsi Kualitas Layanan Jasa Akses
Internet di Indonesia dari Sudut Pandang Penyelenggara.
Salman, S., Ginting, J.G., & Wahyuningrum, R.D.
(2021). Analisis Unjuk Kerja TCP Window Size 64k Menggunakan Algoritma TCP New
Reno pada Jaringan Wired dan Wireless.
Siddik, M., Lubis, A.P., & Sahren, S. (2023).
Optimalisasi Kecepatan Jaringan Internet Pada Mts Daarussalam Menggunakan
Metode Simple Queue.
Simon Kemp. (2022). DATAREPORTAL
Sina, G.O., Amsikan, S., & Salsinha, C.N. (2021).
Pengaruh Penggunaan Jaringan Internet Pada Pembelajaran Daring Dan Minat
Belajar Terhadap Hasil Belajar Mahasiswa.
Su, Z., Zhang, J., & Lü, Z. (2019). A Multi-Stage
Metaheuristic Algorithm for Shortest Simple Path Problem with Must-Pass Nodes.
doi: 10.1109/ACCESS.2019.2908011.
Szele, A.,
& Kisgyörgy, L. (2018). Traffic operation on a road network with recurrent
congestion. WIT Transactions on the Built Environment, 179, 233-244.
Zhou, W., Huang, H., Hua, Q., Yu, D., Jin, H., & Fu,
X. (2021). Core decomposition and maintenance in weighted graph. World Wide
Web, 1-21.
Zulkifli. (2014). Kecepatan Akses Layanan 3.5G Telkomsel
Flash Yang Digunakan Untuk Koneksi Internet.
|
Copyright holder: Brillian Adhiyaksa
Kuswandi, Faqih Hamami, Riska Yanu Fa’rifah (2024) |
|
First publication right: Syntax Literate: Jurnal Ilmiah
Indonesia |
|
This article is licensed under:
|
