2. 網路管理維運部組織 網路管理維運部 莊朝顯 傅青義 周璣謀 畢孫武 人員二 人員三 潘俊鋒 沈浩傑 林秋菊 許嘉惠 黃雅慧 整合 HFC 頭端組 機動及備勤 Network Operation Center 三班制 Technology Operation Center 正常班及 機動 頭端播放組 輪班制

4. 預防性施工管理 在建立網路維護作業的各項工項及維護週期，以達到預防性之網路維護，來增加網路品質的穩定度及可靠性，在這背後有一群默默付出的工程人員，新建設好的網路若不加以維護，久而久之，網路只會越來越糟，不可能有所改善，因此，不做任何的預防性維護作業，網路品質要好，是不可能的；祇有盡可能的做好預防性維護作業。 1.CMTS 各回傳端口實時 SNR 值的監測，通過歷史數據還可以看到趨勢圖。在網絡狀況剛開始劣化時及時採取措施，避免用戶斷線報修。 2. 實時監測各設備端口的流量、在線用戶數量，以便調整網絡帶寬配置，均衡網絡流量，充分利用帶寬資源。 3. 定期檢測用戶 Cable Modem 設備的射頻參數，發現有超標劣化傾向時及時提醒維修人員處理，避免用戶投訴。 4. 用戶報修時，迅速判斷故障原因，縮短維修時間。 5. 根據實際情況的需要，隨時將需要監測的參數編寫到動態網頁中供維護人員使用，並結合 EXCEL 報表輸出。

5. Network Operation Center 功能介紹 使用網路管理系統監測到用戶及網路設備之各種屬性之流量及狀態，分析整體頻寬使用狀況、隨時掌握及監控每一網路相關環節。 針對用戶的使用時間行為，提供二十四小時的監控線路系統的穩定和異常的處理及通報流程。 NOC 人員可透過監控系統掌控機房及所有線路，及瞭解每一客戶的頻寬使用量及訊號品質。 機房設備及線路之運作，網管人員會在發生異常警示前，可以在全程監控過程中發現異常及不穩定之訊號，並加以處理，以免除異常發生時所造成的無謂之損失。 將網管中心將所有之監控內容記錄於資料庫，並將資料庫所記錄之訊資料加以分析整理，可供各部門作必要性報表之查詢。 提供相關部門查詢每日、每週或每月的影響服務的事件原因、事件類別、影響時間、影響範圍及影響件數等報表統計資訊。

7. 監控項目 網路雜訊監控 CATV Slingbox 畫面 環控畫面 ( 預留 ) 數位頭端網管 MRTG- CMTS Interface MRTG- ISP Traffic SDH & 專線網管 FTTB 異常告警視窗 GAME/ 熱門網站 MRTG 及 PING OUTDOORMODEM 告警 網管作業電腦

8. Network Operation Center NOC 常態性工作內容 _ 作業內容如下 執行 ISP 各項維護業務。建置、維護、測試、評估及上線。 FTTB 及負責網管作業，負責處理後端問題、網路監控。 ISP 軟硬體維護及協助網路維運進行機動網路查測作業。 相關後端障礙排除、新增 / 管理硬體設備 (Router 、 Switch 、 FOT) 建置等維護外勤作業。 技術性報表分析，以及相關程式修改擬寫。 建立環狀骨幹路由，提供更穩定的上網環境。 提供網路相關技術之諮詢服務。 專案執行及評估 ELLACOYA 頻寬管理器建置管理 ( 計畫為 EXCEL 檔 _8/3 日上線 ) 搭配室外 OUTDOORMODEM 建置監視系統 分階段性規劃及優化未來高速網路所應用之網路環境 (10 G 系統 ) 數位頭端 SDH 環路建置規劃 新技術引進 頻寬管理及 DOCSIS 3.0 系統時程規畫 EOC 評估及網路防禦系統建設規劃 Operation Event Management System 突發性障礙告警系統開發及引進 專案執行時則需搭配 2 人力以上協同處理。

11. 系統偵測到 HFC 異常時， 主動發佈手機簡訊通告 事件發生。 1. 確認有無網路異常狀況 2. 客服回報無異常申告 確認用戶申告狀況 確認障礙 用戶數及流量 是否回復 系統偵測到 HFC 異常時， 簡訊通知及 WEB 頁面告警 通告案件發生 1. 進行障礙事件確認作業 (SOP_1) 2. 頭端 /ISP 障礙項目依頭端 SOP 維運流程機制處理。 工程通告系統 1‧ 區斷申告發生時，工程部協助查修 需 30 分 內回報障礙維修進度、障礙因素及 預估維修時間。 2‧ 障礙為確認 FTTX 、 CMTS 系統、 IP 、 路由骨幹申告，由 NOC 回報障礙 狀態，確認障礙於 30 分 內回報。 3 、判斷為 ISP 問題則轉由 NOC 窗口統一報 修 ISP 障礙處理， NOC 直接轉由 ISP 查修。 依障礙公告查詢影響範圍 進行檔單作業 申告 CM 障礙告知 經 NOC 確認後，為 ISP 障礙 ，請求協助查修 回報 障礙維修進度及 故障原因 未回復 更新進度回報 NOC 並說明預計修復時間 告警系統 工程中心 5min 客服中心 NOC 網管中心 ISP/ 設備維護商 障礙事件通告發佈 客管系統 進行結案 網管系統 依告警項目，通報障礙隸屬單位 進行第一次通報障礙發生。 通告內容為 (HUB/NODE) 事件或 ISP 其他障礙 客服中心調度組 更新障礙訊息 通告工程值班主管 通告障礙發生 / 障礙影響範圍 3min 3min WEB 頁面確認 告知障礙發生 10min 查看影響範圍 輸入影響範圍 告警系統 修復完成由通報 NOC 進行確認結案 NOC 事件追蹤 / 處理 更新障礙訊息 30min 工程障礙排除 已經回復 已經回復 通告工程值班主管 進行結案 及 填寫故障原因 修復完成由通報 NOC 進行確認結案 告知回復狀況 臨時線系統 工程結案 臨時線架設 工程派工

13. 計畫性工程通告系統 輸入頁面 Add.php 即時通告輸出頁面 Index.php NOC 確認頁面 Nocdetail.php 統計功能 詳細敘述頁面 detail.php 資料庫 MySQL DB 主動維護部 計畫性調測 公共工程部 計畫性工程 網建工程部 計畫性工程 NOC 網路維運 頭端維運 工程幹線組 計畫性維護 事件編修頁面 edit.php 障礙結案確認頁面 handicap.php 非計畫性工程 圖檔上傳 NOC 確認每日發生告警事件 1. 是否需要發電機 ( 通知 ) 2. 該工程是否到場監察 ( 提醒 ) 3.NODE 預警通知

14. 工程臨時線系統 輸入頁面 / 修繕圖 LineAdd.php 即時通告輸出頁面 Index.php NOC 確認頁面 Nocdetail.php 統計功能 詳細敘述頁面 detail.php 資料庫 MySQL DB 工程填寫修繕單 修繕單輸入系統 設計 工程施工 工程架設臨時線 編修更新頁面 edit.php 完成統計頁面 happcount.php 施工完成確認頁面 handicap.php 設計確認 des.php 工程臨時線佈放管理，以每週進行追蹤。 超過三個月以上案件，進行統計。

16. 非計畫性告警系統 輸入頁面 Add.php 即時通告輸出頁面 Index.php NOC 確認頁面 Nocdetail.php 統計功能 詳細敘述頁面 detail.php 資料庫 MySQL DB 主動維護部 計畫性調測 公共工程部 計畫性工程 網建工程部 計畫性工程 NOC 網路維運 頭端維運 工程幹線組 計畫性維護 事件編修頁面 edit.php 障礙結案確認頁面 handicap.php 告警 圖檔上傳 NOC 確認每日發生告警事件 1. 是否需要發電機 ( 通知 ) 2. 該工程是否到場監察 ( 提醒 ) 3.NODE 預警通知

17. 故障管理 _CM 異常處理流程 HFC 網路 _CM 用戶數下降處理流程 1. 網路監控系統伺服器自動判斷是否為異常事件。 2. 自動在簡訊系統通知工程及 NOC 及 TSR ，並於 Web 即時訊息內公告告警；當系統判斷事件已排除時， 此訊息會即時於 Web 公告內出現回復訊息 。 3.NOC 進行 CMTS 系統訊息確認，並通報工程及 CSR 斷線 NODE 區域及 MAIL 告知。 4. 機房光機訊號確認，及確認停電通知。 5.NOC/CSR 進行訊息確認，並將斷訊原因回報 NOC 後填入系統內確認。 6. 工程人員至現場維護網路，將事件排除。 7. 回報 NOC/CSR 填寫系統回單完成斷訊事件處理。 ISP 網路異常處理流程 1. 網路監控系統伺服器自動判斷是否為異常事件。 2. 自動在簡訊系統通知工程及 NOC 及 TSR ，並於 Web 即時訊息內公告告警 3.NOC 進行訊息確認，並將斷訊原因通知 TSR 進行擋單。 4.NOC 事件排除後，填寫系統回單完成斷訊事件處理。 5. 確認客服中心是否收到訊息。 搭配 WEB 網管系統系統能即時監控 HFC 網路

18. 故障管理 _CM 異常處理流程 HFC 網路 _CM 用戶數下降處理流程 (A 級簡訊發送 ) 1. 網路監控系統伺服器自動判斷是否為異常事件。 2. 自動在簡訊系統通知工程及 NOC 及 TSR ，並於 Web 即時訊息內公告告警；當系統判斷事件已排除時， 此訊息會即時於 Web 公告內消失 ( 未完成 ) 。 3.NOC 進行 CMTS 系統訊息確認，並直通報工程及 CSR 斷線 NODE 區域及 MAIL 告知。 4. 機房光機訊號確認， ODTR 光纖路徑確認及確認停電通知。 5. 判斷為光纖斷線時，緊急通告工程主管及客服中心，並告知工程主管斷線 NODE 及斷點米數，並從光纖示意圖確認光纖蕊數。 6. 工程人員至現場維護網路，將事件排除。 7. 每 30 分鐘追蹤並告知 CSR 及工程主管，直到狀況排除。 8. 回報 NOC/CSR 填寫系統回單完成斷訊事件處理。 9. 狀況排除後送出 A 級簡訊狀況報告書。 搭配 WEB 網管系統系統能即時監控寬頻網路

19. 權責單位分工 項目 服務影響 權責單位 改善工作重點 CMTS 上、下行流量壅塞 1. 連線緩慢 NOC+ 後端 1.CMTS 容量擴充 CMTS 上行 SNR 不良 1. 連線緩慢 工程 1.HFC 雙向網路雜訊查修 2. 即時性應用 (on-line game, VoIP..) 瞬斷 頭端 +NOC 2.FN 實體切割 CM 品質連線不合格率 1. 連線緩慢 工程 +NOC 1.HFC 雙向網路設計、調測與維修 2. 即時性應用 (on-line game, VoIP..) 瞬斷 頭端 +NOC 2.FN 實體切割 Internet 連外品質 1. 特定網頁無法連線或連線緩慢 NOC 1. 連外網站品質監測 2. 遊戲網站 Lag NOC 2. 客訴件的個案追蹤

20. 狀況一 CATV 不能看， CM 就一定無法上網 狀況二 CM 無法上網， CATV 還可以看 一、 A 級障礙案件成立條件 (3 個 NODE 以上包含 3 個 NODE 的 CATV 用戶無法收視或上網 ) ISP 定義 _ 服務完全無法正常運作及大範圍用戶影響 1.NOC 同仁於告警系統收到三個 NODE 警訊 (SNR 及用戶數變成 0) 。 2. 客服人員於開博系統；三個 NODE 的 TV 無訊號及 CM 無法上網達 5 件維修單。 3. 成立及發佈障礙案件。 二、 B 級障礙案件成立條件 (1 個 NODE 以上 2 個以下 ) ISP 定義 _ 部分服務異常 _ 影響多數用戶 ( 例如 : 流量雍塞 ) 1.NOC 同仁於告警系統收到該 NODE 警訊 (SNR 及用戶數變成 0) 。 2. 客服人員於開博系統；同 NODE 的 TV 無訊號及 CM 無法上網達 5 件維修單。 3. 總用戶數 50 戶以上。 4. 成立及發佈障礙案件。 三、一般障礙案件成立條件 (NODE 某一個路由故障 ) ISP 定義 _ 部分服務異常 _ 影響少數用戶 (30 戶以下 ) 1.NOC 同仁於告警系統收到該 NODE 警訊 ( 該 NODE 用戶數變成 1/4 ) 。 2. 客服人員於開博系統；同 NODE 的 TV 無訊號及 CM 無法上網達 3 件維修單。 3. 一般區斷派工。 簡訊發放定義

21. 利用 CMTS SUMMARY 每次的變化先做第一次的比對，每 20 秒 ~30 秒為一周期， 例如 2009/10/01 12:00:20 上線數為 (ONLINE)120 戶， 2009/10/01 12:00:40 上線數為 (ONLINE)100 戶， 系統就會告警有 20 戶下線。目前系統條件可依照 ” 同時下線 ” 告警比例去做設定。 然而我們已經知道有 20 個 CM 消失了，那麼就可利用 CMTS 的一些功能性變化去把這 20 戶同時消失之用戶比對出來。 介面資訊會呈現出該 PORT 的 CM 戶數變化 異常資訊經確認解除 後會把資料存放在 系統裡

22. 告警系統 MAIL 通知

24. NOC 提供協助項目 1. 無法確認上下行信號 ( 用戶無 PC) 。 2. 無法決定衰減器裝置條件。 3. 需要轉調測之訊號品質確認。 4. 其他協助 裝機回報流程 CM 裝機 訊號判斷 完工 CM 裝機回報系統 訊號正常 衰減器 異常 訊號正常 NOC 異常 處理後訊號正常 NOC 追蹤 數據異常 工程調測 異常追蹤表 提出改善 Cm 內置網頁

25. 一、點選 CM 裝機參數異常回報 (NOC) 裝機回報流程

26. 二、安裝時參數異常列表 , 從安裝開通起算 72 小時內以”待處理”顯示超過 72 小時未完成處理回報 , 則顯示”逾時” 說明 裝機要求以時效性為主要訴求，如超過 3 天以上未完成，表示此 NODE 的網路狀態不理想， 或該裝機戶管內線或網路設計不良，所以可能需要多次施工，需用預防性作業流程來看待。 裝機回報流程

27. 三、點選”待處理”，進入該筆工單資料作處理回報 四、當該筆工單 CM 現況仍有參數未符合標準，顯示”尚有參數未符合標準”，且無法作回報處理 PL( 上行 ) LEVEL 裝機參數未達標準 裝機回報流程

28. 五、當該筆所有參數皆符合標準時 , 可作回報處理 PL( 上行 ) LEVEL 裝機 參數未達標準，如有及時 修正參數則會出現處理後 參數選項 裝機回報流程 處理原因 處理情況

29. 六 、 經處理回報後 , 該筆工單狀況顯示 ” 已處理 ” 裝機回報流程

30. 七、經處理回報後，後端會紀錄處理後參數及問題說明統計 裝機回報流程

31. 每周提出裝機異常報表

33. 在建立網路維護作業的各項工項及維護週期，以達到預防性之網路維護，來增加網路品質的穩定度及可靠性。 在這背後有一群默默付出的工程人員，新建設好的網路若不加以維護，久而久之，網路只會越來越糟，不可能有所改善，因此，不做任何的預防性維護作業，網路品質要好，是不可能的；祇有盡可能的做好預防性維護作業。 1.CMTS 各回傳端口實時 SNR 值的監測，通過歷史數據還可以看到趨勢圖。在網絡狀況剛開始劣化時及時採取措施，避免用戶斷線報修。 2. 定期檢測用戶 Cable Modem 設備的射頻參數，發現有超標劣化傾向時及時提醒維修人員處理，避免用戶投訴。 3. 根據實際情況的需要，隨時將需要監測的參數提供維護人員使用，並結合 EXCEL 報表輸出。 4. 依據 MRTG 網路 SNR 趨勢圖及數據即時監控網路狀態，如遇網路訊號品質低於標準，則立即以簡訊通知 TSR 與工程單位進行處理， NOC 並對障礙原因進行判斷後告知。 預防性網路維護

34. H/N 妥善表 判斷派工類別 網路整體訊 號品質統計 數據正常 提出網路查 修成效分析 以 NODE 派 修表進行派工 工程單位 派工查修 查修完成回 報 NOC 確認 參數是否正常 須查修 須調測 以 NODE 派 修表進行派工 網路問題 數據不良 NOC 循環監控

35. NOC 管理報表定義 ( 計算基礎 ) 說明 作業定義：利用 Solarwinds 「 CM Database 」所持續監控的 CMTS DS/US Interface Ports SNR 並利用其 Database 進行 SNR Mining ，藉以分析現階段 HFC 雙向網路之整體妥善率。 資料來源： Solarwinds 「 CM Database 」。 作業說明：如圖 1 、 2 「網路妥善率行政區 (HUB) 分佈狀況」 1. 使用 OBBC 來存取後端「 SQL Server Database 」進行 Mining 後，分析出每 CMTS Upstream Interface Ports SNR 低於標準值 (<24dB) 次數，算出其不良比例進行排序，共分「 Interface 數」、「 NODE 數」、「客戶數」 等三項得知網路整體妥善率與比例分佈狀況。 ( 妥善率 %= 1-SUM(SNR<24dB Frequency/9minutes/1008(weekly))) ( 妥善率 % 分佈標準 =Interface Ports >=95% ) 2. 平均每週 CMTS Interface Ports 妥善率後可得知該週 / 該月整體網路妥善率狀況，再與前月份相同週期之妥善率比較分析出網路現況是否符合要求。 ( 整體網路妥善率 %=AVERAGE(CMTS Interface Ports SNR 妥善率 ) ( 整體網路妥善率分佈標準 = 每週 / 每月 % >=98% ) 3. 針對 CMTS Interface Ports 所涵蓋之 NODE 進行妥善率分析後，可得知每週每 Interface Ports 之網路妥善率狀況，藉以提供維運、頭端等單位進行網路查測與 CMTS Interface Ports 分接調整參考。 (Interface SNR Quality%=AVERAGE( 每週 CMTS All Interface SNR 妥善率 ) ( 妥善率 % 分佈標準 =Interface Ports >=95% ) 預防性網路妥善率流程

36. 4. 每週進行 CMTS Interface Ports 客戶數更新，藉以提供維運、頭端等單位進行網路查測與 CMTS Interface Ports 分流調整參考。 5. 平均每週 CMTS Interface Ports 妥善率後可得知該月該 Interface Ports 網路妥善率狀況。 (Interface Ports 妥善率 %=AVERAGE( 每週 Interface Ports SNR 妥善率 ) ( 整體網路妥善率分佈標準 = 每月 % >=95% ) 6. 以分析出之 CMTS Upstream Interface Ports SNR 低於標準值 (<24dB) 次數，再以系統 Polling 時間間隔 9 分鐘進行換算出該 Upstream Interface Ports SNR 不良時間週期，藉以提供維運單位進行網路查測參考。 (SNR Total Bad Time( 小時 ) =SUM( 每週 Interface Ports SNR<24Db( 次數 )×9minutes/60) 7. 使用 OBBC 存取後端「 SQL Server Database 」進行 Mining ，分析出每 CMTS Upstream Interface Ports SNR 低於標準值 (<24dB) 次數，算出不良比例進行排序，藉以提供維運、頭端等單位進行網路查測與 CMTS Interface Ports 分接調整參考。 ( 妥善率 %= 1-SUM(SNR<24dB Frequency/9minutes/1008(weekly))) ( 妥善率 % 分佈標準 =Interface Ports >=95% ) 。 8/9. 平均每週 CMTS Interface Ports 涵蓋之 H/N 與行政區後，統計出該 HUB( 行政區 ) 之網路妥善率狀況，藉以提供維運、頭端等單位進行網路查測與 CMTS Interface Ports 分接調整參考。 (HUB/ 行政區網路妥善率 %=AVERAGE( 每週 HUB 涵蓋 NODE 妥善率 ) ( 整體網路妥善率分佈標準 = 每月 % >=98% ) 預防性網路妥善率流程 依各 NODE 點進行各服務區故障率評比，針對故障率較高的區域進行重點式的問題改善，同時針對當月報修多次之用戶裝機址進行檢討，以改善網路品質或人員維修品質。

37. 總表 各區 NODE 狀態 ( 整體網路妥善率分佈標準 = 每週 / 每月 % >=98% ) 從表中可以看出哪個區域 的網路狀況是否常常斷線 或網路不穩定

38. 代表該 NODE 長時間品質不良，需要整理 從上表中可以看出哪個區域 此表可以看出該區域的 NODE 網路狀況是否常常斷線，或網路不穩定 預防性網路妥善率流程

39. 從系統撈取異常資料讓工程有判斷依據 預防性網路妥善率流程 從上表中可以看出哪個 NODE 網路狀況是否常常斷線，或網路不穩定 出 PM 工單讓工程查修

41. 每日雜訊派工追蹤

42. KPI 項次 項目 定義 KPI 資料來源 1 HFC 網路妥善率 ( 全區 ) 平均每週 CMTS Interface Ports 妥善率後可得知該週 / 該月整體網路妥善率狀況，再與前月份相同週期之妥善率比較分析出網路現況是否符合要求。 >98% ( 整體網路妥善率 %=AVERAGE(CMTS Interface Ports SNR 妥善率 ) ( 整體網路妥善率分佈標準 = 每週 / 每月 % >=98% 預防性網路維護 2 HFC 網路妥善率 (node) 針對 CMTS Interface Ports 所涵蓋之 NODE 進行妥善率分析後，可得知每週每 Interface Ports 之網路妥善率狀況，藉以提供維運、頭端等單位進行網路查測與 CMTS Interface Ports 分接調整參考。 >95% (Interface SNR Quality%=AVERAGE( 每週 CMTS All Interface SNR 妥善率 ) ( 妥善率 % 分佈標準 =Interface Ports >=95% ) 3 BB 寬頻客訴維修率 ( 後送 ) BB 客訴障礙案件後送 SO 處理之障礙率 4 BB 寬頻品質連線不合格率 不符合 CM 連線品質的 CM 數量佔一個月總連線數之比率 < 20% CM 連線品質不合格紀錄查詢 CM 連線品質不合格紀錄查詢

43. KPI 項次 項目 定義 KPI 資料來源 5 CMTS 上行 SNR 不合格率 SO 所有 CMTS 上行 port SNR 不合格 (<24dB)Port 數比率 <2% MRTG 6 CMTS 上行流量壅塞率 CMTS 上行埠每週最高流量 (>90%)Port 數比率 <2% CMTS-Traffic Rate Report 7 CMTS 下行流量壅塞率 CMTS 下行埠每週最高流量 (>90%)Port 數比率 <5% CMTS-Traffic Rate Report 8 BB 每日裝機不合格率 每日不符合 CM 連線品質的數量總連線數之比率 <5% 每日 CM 裝機紀錄查詢

51. HFC 網路用戶即時監控 協作流程

54. 自動播放系統評估 為了能讓 NTOC 運轉更流暢，及人員調度上的優勢，預計引進新系列的自動播放系統，及 16 畫面切割頻道監控系統。 為了符合自製頻道播映之條文，為此必須切割自製頻道共同訊號源。 目前自製頻道播放系統，為較為老舊之播放系統，都是屬於帶狀化節目製作，保存占空間及不易保存，目前之自動播片程式支援度低，頭端人員執行節目轉檔、存檔、節目排程等均難以操作，且設備故障率高，且要常常人工換帶，影響自製頻道播映品質，必須即時更換系統。 BETACAM 及 DVD 撥放設備已經接近年限或超過年限，維修費用逐年升高，部分已經無產品零件維護。側錄節目內容大多數轉錄為 DVD ，轉錄存檔不易又浪費人力工時，建議採購 MPEG2 自動撥放系統及儲存磁碟櫃，定立播放節目儲存標準。 公益頻道為 CH － 03 、自製頻道 ( 收費性質 ) 為 CH － 04 共計 2 個頻道需採購 4 組電腦播放系統 ( 港都、慶聯、大信、 ) 及一台 DATA 資料儲存櫃 *1(8T) 。 經由 NOC 與頭端監控中心的結合，及簡化播放流程才能有效作最大人力整合需求。