The document discusses developing an analytic dashboard for analyzing TM Berhad's International Private Leased Circuit (IPLC) capacity. Key objectives are to have a single monitoring dashboard for the network operations center to analyze IPLC capacity needs, perform failure analysis more quickly, and use advanced analytics like clustering and congestion prediction. Currently, analysis is done manually using performance monitoring tools and spreadsheets, which is time-consuming. The proposed dashboard would automate analysis and reporting to help optimize IPLC capacity planning and routing.

1. MOHD RIZAL BIN MOHD RAMLY
TELETRAFFIC ENGINEERING,
ISP NETWORK MANAGEMENT,
NOC
TM BERHAD
International Private Leased Circuit
(IPLC) ANALYTIC DASHBOARD

2. do analysis on the IPLC, we need to understand the IPLC design and traffic
International Private Leased Circuit (IPLC)?
IGW
IPOP
IGW
Domestic
Internet
Cloud
KLJ CBJBRFJHB
AMS
FFT
PNH
Upstream
Customer
Backhaul
Backhaul-
CustomerUpstream
Peering
Peering
Backhaul
Transit
Provider
Public/Private
Peering Customer
Global IPVPN
Overlay
Only link highlighted in
RED is taken into
International cap
calculation

3. Nearly 4.6 millions
row of performance data
sent to data lake daily &
lots of insight can be
explored with data
science technique

4. #4
#3
#2
#1
Just traditional tools without
integration with any dynamic
mathematic tools to do threshold
and forecasting
No forecasting
Do the behavior of traffic
based on source or
destination?
eak same time vs Peak Diff
time?
No clustering View
Unable to do any of
advanced analytic such as
congestion predictor during
failure
Advanced analytic
Problem Statement
Traditional Monitoring
Systems not suitable for
clustering view – slow/
unpresentable

5. q Analyse optimum capacity
requirement for TM’s internationa
traffic
ECTIVES
q Have sustainable single monitori
analytic dashboard for TM’s oper
centre for IPLC
q To have faster failure analytic dur
failure event

6. s international capacity:
ata June 2017
1.XXX Tbps ( XXX Links)
IP Leased Circuit (IPLC)
XXX Links (10XX Gbps)
Backhaul
XX Links (XX2.5 Gbps)
(ii) Upstream
XXX Gbps
(3X Links)
(ii) Peering
(XX0 Gbps)
(XX Links)
Upstream
XX Links (3XX.
5Gbps)
Direct Peering
XX links (1XX.
6Gbps)
Backhaul
Customer
XX links (4X.
7Gbps)

7. rder to verify the traffic peak time, we can do further analysis to calculate
ther each link peak at the same time
on time zone vs Source time zone
Europe
South Asia
Middle East
South East Asia
North Asia
US
• If the peak for each region diff
between each other in a day, we
cannot take a maximum
bandwidth everyday by snapshot
time.

8. m data analysis, the peak time for aggregate link as below and behaviour fo
h link
k Time Aggregation Link distribution vs Each link peak distribution
• Majority link peak during 10 pm
• Both hour distribution is traffic
behaviour and the maximum capacity
shall be taken from snapshot time
• Traffic peak behaviour not depending
on destination time zone but
SOURCE time zone
UPLOAD
TRAFFIC
DOWNLOAD
TRAFFIC

9. ge gap for forecast due to different assumption
gap due to different calculation methodology and assumption of destination time zone
erational team ISPNM team
imum traffic requirement by operational team
Diff using max monthly vs max at a
time:
DEC 2016 Example
By using forecast function in Excel, operational team able to do forecasting for 2017 expected traffic BUT
Operational team calculate monthly maximum for each link and aggregate 1XX ++ IPLC links to get total bandwidth
requirement.
R programming able to calculate peak concurrent in terms of time to get the maximum 1XX IPLC links.
Multiple more elegant forecast algorithm can be done using R programming and visualize by Shiny R (arima, prophet alg
Different about 3X.X% due to different calculation methodology
7XX
5XX
time_max
-3X.X%
month_max
TotalBWReq

10. prevent mistake on utilization capacity calculation, dashboard do the time
main aggregation and multiple types of clustering analysis
dip.intra.tm:8080/sample-apps/global_capacity/
• Beneficial to TM to do proper monitoring and planning for IPLC.

11. c: Clustering analytic for selection of link type (2/3)

12. c: Clustering analytic for selection of link type (3/3)

13. c: Clustering analytic for selection of cable (1/1)

14. estion List: List of link with congestion – current hour (1/1)

15. estion List: List of link with congestion – current day (1/1)

16. HANCEMENT: CABLE FAILURE ANALYTIC
ata, we able to identify each Point of Presence (PoP) router bandwidth requirement
connect Topology to US
IGWSY.LA
IGWSY.LA2
IGWXY.SJ
02.CBJ02.JRC
01.MCCS
02.KLJ
IGWSY.PA
01.CBJ
SY.SJ
01.JRCBRF 21.MECS 22.MECS
PartnerA
CustA
10G
PartnerD
CustC
30G 10G 10G
PartnerC
20G
PartnerD
10G
PartnerE
10G
PartnerB
G 20G
PartnerF
CustB
20G 10G
PartnerB
10G
PartnerA
30G
4G 3.8G
4.7G
1.1G 2.5G
0%
2.6G
9.1G
7G
9.4G
9.4G
3G
1.5G
1.6G
1.5G
100G6.5G
2.3G
G 3G 1G 1.5G3.2G 9.8G 23G 4.5G4.6G 0.9G 4.3 G 8.4 G
• If the routing do
not change from
the previous da
& the data traffi
have daily
seasonal
behaviour, we
able to predict
which link will b
congested durin
peak hour
• Easy to network
engineer to do
route
optimization.

17. le system fault simulator application – (1/4)
1
2Select region to simulat
Select Failure Analysis
3
15 interconnect from
Malaysia Node to POI node
4
Interconnect between TM
Malaysia nodes to POI at
each region
5
Click same tab as [2] to
view interconnect diagram

18. 6
Link for interconnect failure
can be highlight by clicking
each row
le system fault simulator application – (2/4)

19. 7
Simulation for link
down as highlighted
8
of
gested
W router
rtner
umn]
9
Historical daily maximum
traffic for (n-3) where n is
current date
10
Maximum traffic for IGW
router for past 3 days 11
Capacity available for
IGW backhaul
le system fault simulator application– (3/4)

20. 12 Select Global Inventory
13
Barplot for capacity each
cable systems to each
region
le system fault simulator application – (4/4)

21. Supplement Facts
Serving Size: 1,XXX Gbps. Servings Per Container: 1XX Links
Amount Per Serving %Daily Value
Tukang Fikir Mohd Rizal 30%
Tukang Tulis Mohd Rizal 10%
Tukang Jaga Nur Fadzlina 10%
Tukang Analisis Mohd Rizal / Mohd Akram Akmal 30%
Penasihat M Haikal/Mohd Izni Zuhdi/Amzari 5%
Tukang Komen Semua di atas 5%
** Daily Value (DV) not established
T H A N K Y O U
Tukang Present Mohd Rizal 10%

22. cess Improvement: Benefit of the IPLC Analytic Dashboard (before & after)
Breakdown
Happen & fault
management
system triggered
Link Utilization
Check using
performance
monitoring and
router
Data Extraction
and Analysis
Action and
Reporting
Breakdown Happen &
fault management
system triggered
Link Utilization and
analytic. Action and
reporting via Dashboard
• Link loss triggered
by NOC
• Link utilization
check per link.
• Manually at router
and monitoring tools
• Data extraction using
performance
monitoring
• Manual analysis using
excel
• Manual reporting a
presentation prepa
to management
Immediate 1 hours 3 hours 2 hours
• Link loss triggered
Immediate
• Automate in analytic
and report
15 minutes
ith analytic dashboard, the reporting will be more consistent due to eliminate manual process be
with improvement about 95% from previous process.

23. ng Six Sigma, we can understand and come out with correct mechanism to
rol
6σ
Understand current
process and methodology
of IPLC monitoring
Measure overall traffic
requirement concurrent
monthly maximum
Analyse traffic behaviour
per region to identify
traffic pattern in 24H.
Improve calculation
methodology and traffic
behaviour
recommendation
Develop Analytic
Dashboard for IPLC for
easy control and monitor
IPLC Bandwidth

24. en the performance monitoring
nually check each links before
alyse (performance monitoring
rtal)
aggregate view for each region or
ble
me consuming
hat is our EFFECTIVE
ANDWIDTH
blem Statement
Submarine
Cable
Down
Manual Check
for all links one
by one
Manual
Analysis
1
2
3
Time
consuming!!!
Manual checking using
fault management
system & performance
monitoring!!!
Cable Down!!!
v Submarine cable may be dow
due to many reasons.
v Traffic will overflow to
another submarine cable
v Loss of capacity will affected
customers experience
twork engineer will check fault management
tem for any alarm and performance monitoring
traffic performance (utilization).
overall aggregation view. Manual and prone to
or without automation