狠狠撸

狠狠撸Share a Scribd company logo
?
網路管理維運部組織 網路管理維運部 莊朝顯 傅青義 周璣謀 畢孫武 人員二 人員三 潘俊鋒 沈浩傑 林秋菊 許嘉惠 黃雅慧 整合 HFC 頭端組 機動及備勤 Network Operation  Center 三班制 Technology Operation  Center 正常班及 機動 頭端播放組 輪班制
網路管理頭端部  成立維運模式 1 、負責寬頻 HFC 網路、  CMTS 系統與 IP 數據骨幹網路之整合監控與管理, FTTX 及專線監 控及異常處理,提升網路工程維運與服務品質。 2 、新技術引進及網路整合性測試及網路優化工程規劃及執行。 3 、 HFC 網路及數位頭端維護。 4 、整合頭端自製節目無帶狀自動播放系統。 5 、網管四大管理模組 _ 故障管理、配置管理、安全管理、預防性施工管理。 維運模式 網管系統開發以 WEB 網路化、自製化及客製化提供整合性網管程式。 擔任與客服中心與工程部及各部門、各單位之維運橋樑。 運用各類網管系統,故障初判後主動聯繫維運單位。 利用各種即時及主動告警性網路監控環境,掌握每一 NODE 連線品質及人員掌控。 5. 提供網管資料查詢與分析,除有助於查修外,也將依據分析結果,降低故障率,以達成預防性維護與網管之目標。
預防性施工管理 在建立網路維護作業的各項工項及維護週期,以達到預防性之網路維護,來增加網路品質的穩定度及可靠性,在這背後有一群默默付出的工程人員,新建設好的網路若不加以維護,久而久之,網路只會越來越糟,不可能有所改善,因此,不做任何的預防性維護作業,網路品質要好,是不可能的;祇有盡可能的做好預防性維護作業。 1.CMTS 各回傳端口實時 SNR 值的監測,通過歷史數據還可以看到趨勢圖。在網絡狀況剛開始劣化時及時採取措施,避免用戶斷線報修。  2. 實時監測各設備端口的流量、在線用戶數量,以便調整網絡帶寬配置,均衡網絡流量,充分利用帶寬資源。  3. 定期檢測用戶 Cable Modem 設備的射頻參數,發現有超標劣化傾向時及時提醒維修人員處理,避免用戶投訴。  4. 用戶報修時,迅速判斷故障原因,縮短維修時間。  5. 根據實際情況的需要,隨時將需要監測的參數編寫到動態網頁中供維護人員使用,並結合 EXCEL 報表輸出。
Network Operation  Center 功能介紹 使用網路管理系統監測到用戶及網路設備之各種屬性之流量及狀態,分析整體頻寬使用狀況、隨時掌握及監控每一網路相關環節。 針對用戶的使用時間行為,提供二十四小時的監控線路系統的穩定和異常的處理及通報流程。 NOC 人員可透過監控系統掌控機房及所有線路,及瞭解每一客戶的頻寬使用量及訊號品質。 機房設備及線路之運作,網管人員會在發生異常警示前,可以在全程監控過程中發現異常及不穩定之訊號,並加以處理,以免除異常發生時所造成的無謂之損失。 將網管中心將所有之監控內容記錄於資料庫,並將資料庫所記錄之訊資料加以分析整理,可供各部門作必要性報表之查詢。 提供相關部門查詢每日、每週或每月的影響服務的事件原因、事件類別、影響時間、影響範圍及影響件數等報表統計資訊。
監控項目 MRTG 網頁監控項目 ROUTER 、 SWITCH 、 InterfacePort 流量。詳細記錄 CMTS 每個上下行流量。 GAME SERVER  監控、熱門網站流量監控。 Solarwinds 監控系統 可列出 SNR 較差的 Cable Modems, 以方便改善 、迅速的查知頭端設備 up or down  Cable Modems 有振盪狀態 "Flapping“ 可透過頭端設備表列或圖示 Cable modem 的 SNR 及 Power Level 整體狀態  Cable Modems 的 power levels 狀態、 Cable Modem 各個介面的使用狀態 FTTB 監控用戶異常流量 監控大樓交換機狀態與 log 、 FTTB 用戶 IP 存量控管、 FTTB Switch Port  使用量控管 數位頭端設備 監控數位頭端設備運作狀態、監控數位頻道節目品質狀態 告警系統 CM 異常告警、網路異常告警系統
監控項目 網路雜訊監控 CATV Slingbox  畫面 環控畫面 ( 預留 ) 數位頭端網管 MRTG- CMTS Interface MRTG- ISP Traffic SDH &  專線網管 FTTB 異常告警視窗 GAME/ 熱門網站 MRTG 及 PING OUTDOORMODEM 告警 網管作業電腦
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  人力以上協同處理。
頭端工程師 頭端為常態人力編制維護頭端運作狀態,現階段除北高 (CL) 外南高 (GD) 已經建置頭端環控機制,而 ISP  業務於頭端之相關硬體設備均可由遠端加以監控,故目前僅類比頻道需由人工進行監控,以頭端設備妥善率而言,故需常態投入人力進行維護工作。 工作項目 負責網路硬體設備的架設 ( 規劃,發包,鋪設 ) 、管理與維護。 負責鋪設網路連接光纖傳輸設備及所需的網路連接(轉接)設備。 基本訊號量測及頭端環境記錄等作業。
?
系統偵測到 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 進行確認結案 告知回復狀況 臨時線系統 工程結案 臨時線架設 工程派工
故障管理 _CATV 異常處理流程 系統警訊告知。 確認是否為計畫性工程或是非計畫性工程。 先行預先通告客服及工程窗口告知事件發生。 確認機房光送收發設備是否有訊號發送。 (DB 表、頻譜、 POWER METER 、反向頻譜 SST) ODTR 光纖路徑確認。 ( 光纖示意圖、光纖對照表 ) 判斷為光纖斷線時,緊急通告工程主管及客服中心,並告知工程主管斷線 NODE 及斷點米數,並從光纖示意圖確認光纖蕊數。 開啟該 NODE 佈線圖,並協同工程人員判斷斷線路段 ( 縮小範圍 ) ,並指揮前往修復。 通知客服中心事件發生情況。 工程人員至現場維護網路,將事件排除。 工程人員回報 NOC 網管中心。 NOC 網管中心進行事件確認,並將斷訊原因填入系統中進行確認結案。 客服中心進行事件訊息確認,進行開博系統用戶確認結案。 回報並確認是否需求,工程臨時線佈放管理,並以每週進行追蹤。 網管中心通報機制: 1. 接獲障礙案件後 (. 突發性障礙 mail 通報機制 ) , 10 分鐘 內通報障礙權責單位,上班時間 30 分鐘或非上班時間 60 分鐘 內障礙單位回報或 NOC 主動聯繫障礙單位, 2 小時 內維修人員回報或 NOC 主動聯繫維修人員並於告警系統填入判斷障礙原因、修復時間。 2. 現場維修人員於障礙修復完成,回報 NOC 實際修復時間及障礙原因, NOC 接獲修復完成通報後聯繫客服中心人員協請去電申告客戶複查。 3. 各權責單位回報障礙機制為使障礙通報窗口單一化及 NOC 詳細統計障礙歷程,協請工程部及現場維修人員配合回報 NOC 。
計畫性工程通告系統 輸入頁面 Add.php 即時通告輸出頁面 Index.php NOC 確認頁面 Nocdetail.php 統計功能 詳細敘述頁面 detail.php 資料庫 MySQL DB 主動維護部 計畫性調測 公共工程部 計畫性工程 網建工程部 計畫性工程 NOC 網路維運 頭端維運 工程幹線組 計畫性維護 事件編修頁面 edit.php 障礙結案確認頁面 handicap.php 非計畫性工程 圖檔上傳 NOC 確認每日發生告警事件 1. 是否需要發電機 ( 通知 ) 2. 該工程是否到場監察 ( 提醒 ) 3.NODE 預警通知
工程臨時線系統 輸入頁面 / 修繕圖 LineAdd.php 即時通告輸出頁面 Index.php NOC 確認頁面 Nocdetail.php 統計功能 詳細敘述頁面 detail.php 資料庫 MySQL DB 工程填寫修繕單 修繕單輸入系統 設計 工程施工 工程架設臨時線 編修更新頁面 edit.php 完成統計頁面 happcount.php 施工完成確認頁面 handicap.php 設計確認 des.php 工程臨時線佈放管理,以每週進行追蹤。 超過三個月以上案件,進行統計。
?
非計畫性告警系統 輸入頁面 Add.php 即時通告輸出頁面 Index.php NOC 確認頁面 Nocdetail.php 統計功能 詳細敘述頁面 detail.php 資料庫 MySQL DB 主動維護部 計畫性調測 公共工程部 計畫性工程 網建工程部 計畫性工程 NOC 網路維運 頭端維運 工程幹線組 計畫性維護 事件編修頁面 edit.php 障礙結案確認頁面 handicap.php 告警 圖檔上傳 NOC 確認每日發生告警事件 1. 是否需要發電機 ( 通知 ) 2. 該工程是否到場監察 ( 提醒 ) 3.NODE 預警通知
故障管理 _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 網路
故障管理 _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 網管系統系統能即時監控寬頻網路
權責單位分工 項目 服務影響 權責單位 改善工作重點 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. 客訴件的個案追蹤
狀況一 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. 一般區斷派工。 簡訊發放定義
利用 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 戶數變化 異常資訊經確認解除 後會把資料存放在 系統裡
告警系統 MAIL 通知
目的:數位時代的來臨,高速傳輸條件嚴謹,為了確保網路品質的穩定度及可靠性 ,必須提昇整體網路品質管控,減低工程維護負擔。未來 DTV 用戶, STB 傳輸供裝方式 雙向用戶區提供一 CM (32kbps)+STB 進行機上盒雙向回傳功能。 雙向用戶區提供整合型 STB 進行機上盒雙向回傳功能。 FTTB 供裝區域利用 STB Ethernet REV 進行機上盒雙向回傳功能。 ( 未定 ) 單向區或無安裝上網設備,則利用 080 免付費電話進行訂購。 ( 未定 ) 開放他家 isp 網路傳輸上傳功能。 ( 降低競爭力 )  ( 未定 ) 因為所有的服務都是透過同路由之同軸網路,所以裝機時更要確保網路的品質,任何異常參數 將都會影響整體的收視及上網品質,影響甚大,所以特別看重此事。 未來則要再考慮匯集雜訊的產生,及 cmts 的整體負擔。 要求 CM 裝機之工程師一定要把訊號調整到最佳品質 ( 可以參閱 CM 內頁 ) 。 目前中嘉定的標準  下行  SNR  >+35dB 上行  SNR  >+24dB 下行  power >- 10dB 下行  power <+12dB 上行  power >+30dB 上行  power <+55dB 為了讓訊號品質更穩定,位準一旦變化的時候不會造成異常工單,目前裝機先針對 CM Power Level ( 下 / 上 )  的準位先修到理想的比例。 CM Power Level ( 下行 / 上行 )  5dB /42dB 衰減器加太少,信號在合格邊緣值的時候,當網路訊號產生變化時容易再造成異常工單。 例如 13dB/ 34dB  加 10dB 衰減器  ?   3dB/44dB 9dB/ 37dB  加 6dB 衰減器  ?   3dB/43dB 7dB/ 26dB  加 10dB 衰減器  ?   -3dB/36dB 預防性裝機回報流程
NOC 提供協助項目 1. 無法確認上下行信號 ( 用戶無 PC) 。 2. 無法決定衰減器裝置條件。 3. 需要轉調測之訊號品質確認。 4. 其他協助 裝機回報流程 CM 裝機 訊號判斷 完工 CM 裝機回報系統 訊號正常 衰減器 異常 訊號正常 NOC 異常 處理後訊號正常 NOC 追蹤 數據異常 工程調測 異常追蹤表 提出改善 Cm 內置網頁
一、點選  CM 裝機參數異常回報 (NOC) 裝機回報流程
二、安裝時參數異常列表 , 從安裝開通起算 72  小時內以”待處理”顯示超過 72  小時未完成處理回報 , 則顯示”逾時” 說明 裝機要求以時效性為主要訴求,如超過 3 天以上未完成,表示此 NODE 的網路狀態不理想, 或該裝機戶管內線或網路設計不良,所以可能需要多次施工,需用預防性作業流程來看待。 裝機回報流程
三、點選”待處理”,進入該筆工單資料作處理回報 四、當該筆工單 CM  現況仍有參數未符合標準,顯示”尚有參數未符合標準”,且無法作回報處理 PL( 上行 ) LEVEL 裝機參數未達標準 裝機回報流程
五、當該筆所有參數皆符合標準時 , 可作回報處理 PL( 上行 ) LEVEL 裝機 參數未達標準,如有及時 修正參數則會出現處理後 參數選項 裝機回報流程 處理原因 處理情況
六 、 經處理回報後 , 該筆工單狀況顯示 ” 已處理 ” 裝機回報流程
七、經處理回報後,後端會紀錄處理後參數及問題說明統計 裝機回報流程
每周提出装机异常报表
?
在建立網路維護作業的各項工項及維護週期,以達到預防性之網路維護,來增加網路品質的穩定度及可靠性。 在這背後有一群默默付出的工程人員,新建設好的網路若不加以維護,久而久之,網路只會越來越糟,不可能有所改善,因此,不做任何的預防性維護作業,網路品質要好,是不可能的;祇有盡可能的做好預防性維護作業。 1.CMTS 各回傳端口實時 SNR 值的監測,通過歷史數據還可以看到趨勢圖。在網絡狀況剛開始劣化時及時採取措施,避免用戶斷線報修。 2. 定期檢測用戶 Cable Modem 設備的射頻參數,發現有超標劣化傾向時及時提醒維修人員處理,避免用戶投訴。  3. 根據實際情況的需要,隨時將需要監測的參數提供維護人員使用,並結合 EXCEL 報表輸出。  4. 依據 MRTG 網路 SNR 趨勢圖及數據即時監控網路狀態,如遇網路訊號品質低於標準,則立即以簡訊通知 TSR 與工程單位進行處理, NOC 並對障礙原因進行判斷後告知。 預防性網路維護
H/N 妥善表 判斷派工類別 網路整體訊 號品質統計 數據正常 提出網路查 修成效分析 以 NODE 派 修表進行派工 工程單位 派工查修 查修完成回 報 NOC 確認 參數是否正常 須查修 須調測 以 NODE 派 修表進行派工 網路問題 數據不良 NOC 循環監控
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% ) 預防性網路妥善率流程
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 點進行各服務區故障率評比,針對故障率較高的區域進行重點式的問題改善,同時針對當月報修多次之用戶裝機址進行檢討,以改善網路品質或人員維修品質。
總表 各區 NODE 狀態 ( 整體網路妥善率分佈標準 = 每週 / 每月 % >=98% ) 從表中可以看出哪個區域 的網路狀況是否常常斷線 或網路不穩定
代表該 NODE 長時間品質不良,需要整理 從上表中可以看出哪個區域 此表可以看出該區域的 NODE 網路狀況是否常常斷線,或網路不穩定 預防性網路妥善率流程
從系統撈取異常資料讓工程有判斷依據 預防性網路妥善率流程 從上表中可以看出哪個 NODE 網路狀況是否常常斷線,或網路不穩定 出 PM 工單讓工程查修
?
每日杂讯派工追踪
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 連線品質不合格紀錄查詢
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 裝機紀錄查詢
主要計劃項目 規劃 HFC NODE 為監控模式 以 HFC 網路用戶為即時監控範圍 即時提供 HFC CM Alert  戶數差異資訊 預期效益 強化 CSR 與工程單位客戶來電與障礙判斷依據。 提昇工程單位網路維運成效。 同步提昇 HFC 網路圖資正確度。 提供後續 NOC 系統整合作業參考。
HFC 網路用戶即時監控 為於 HFC  網路發生異常時,可立即了解障礙發生方位 ( 迴路 ) 與異常用戶資訊,以利 CSR 客戶來電與工程單位維運時判斷,提高工程單位查修成效。 建置目的 使用工具及範圍 使用 Solarwinds  監控平台與後端 CMTS Status Date 匯出資訊。監控模式以 NODE 為單位 ( 初期建置 1 個 NODE 測試成效 ) 再擴大至 HUB 範圍監控。 協作單位 NOC/CSR/ 工程單位 ( 設計部 )/ 資訊部。 預估建置時程
HFC 網路用戶即時監控 自目前工程 HFC NODE 網路圖資各延伸迴路末端 CM 用戶分別找出 3 個監控點。 監控方式 利用 SMMP 模式持續監控 CM 用戶 Status 狀態。
當 HFC 網路發生 CM 用戶數劇減或 SNR 降為 0 時,  MRTG Top Alerts 即產生告警訊息。 HFC 網路用戶即時監控
HFC 網路用戶即時監控 利用 SMMP 模式觀察監控 CM 用戶 Status 是否為異常狀態。 監控方式 藉此提供異常路段予 CSR 及工程單位,作為客戶來電與障礙判斷依據。
HFC 網路用戶即時監控 自 CMTS 匯出 CM 用戶 Status 狀態與客戶資料差異比對。 監控方式 CM Status CM MAC / IP
HFC 網路用戶即時監控 提供異常客戶資料於 CSR 與工程單位作為客戶來電與障礙判斷依據。 監控方式 範例
HFC 網路用戶即時監控 協作流程
?
?
自動播放系統評估 為了能讓 NTOC 運轉更流暢,及人員調度上的優勢,預計引進新系列的自動播放系統,及 16 畫面切割頻道監控系統。 為了符合自製頻道播映之條文,為此必須切割自製頻道共同訊號源。 目前自製頻道播放系統,為較為老舊之播放系統,都是屬於帶狀化節目製作,保存占空間及不易保存,目前之自動播片程式支援度低,頭端人員執行節目轉檔、存檔、節目排程等均難以操作,且設備故障率高,且要常常人工換帶,影響自製頻道播映品質,必須即時更換系統。 BETACAM 及 DVD 撥放設備已經接近年限或超過年限,維修費用逐年升高,部分已經無產品零件維護。側錄節目內容大多數轉錄為 DVD ,轉錄存檔不易又浪費人力工時,建議採購 MPEG2 自動撥放系統及儲存磁碟櫃,定立播放節目儲存標準。 公益頻道為 CH - 03 、自製頻道 ( 收費性質 ) 為 CH - 04 共計 2 個頻道需採購 4 組電腦播放系統 ( 港都、慶聯、大信、 ) 及一台 DATA 資料儲存櫃 *1(8T) 。 經由 NOC 與頭端監控中心的結合,及簡化播放流程才能有效作最大人力整合需求。
跑馬燈的簽呈流程 因跑馬燈的簽呈流程至客服中心,往往已超過施工時間 請各位主管注意並宣導 , 日後有關跑馬燈的申請,除了正式簽核流程外 請各位主管將跑馬燈申請之申請文件放在共用資料區 , 以讓客服中心能提早了解 192.168.1.8共用資料區 客服轉工程 - 不可刪 SO 工程部斷訊通知 頭端網管

More Related Content

Catv h fc

  • 1. ?
  • 2. 網路管理維運部組織 網路管理維運部 莊朝顯 傅青義 周璣謀 畢孫武 人員二 人員三 潘俊鋒 沈浩傑 林秋菊 許嘉惠 黃雅慧 整合 HFC 頭端組 機動及備勤 Network Operation Center 三班制 Technology Operation Center 正常班及 機動 頭端播放組 輪班制
  • 3. 網路管理頭端部 成立維運模式 1 、負責寬頻 HFC 網路、 CMTS 系統與 IP 數據骨幹網路之整合監控與管理, FTTX 及專線監 控及異常處理,提升網路工程維運與服務品質。 2 、新技術引進及網路整合性測試及網路優化工程規劃及執行。 3 、 HFC 網路及數位頭端維護。 4 、整合頭端自製節目無帶狀自動播放系統。 5 、網管四大管理模組 _ 故障管理、配置管理、安全管理、預防性施工管理。 維運模式 網管系統開發以 WEB 網路化、自製化及客製化提供整合性網管程式。 擔任與客服中心與工程部及各部門、各單位之維運橋樑。 運用各類網管系統,故障初判後主動聯繫維運單位。 利用各種即時及主動告警性網路監控環境,掌握每一 NODE 連線品質及人員掌控。 5. 提供網管資料查詢與分析,除有助於查修外,也將依據分析結果,降低故障率,以達成預防性維護與網管之目標。
  • 4. 預防性施工管理 在建立網路維護作業的各項工項及維護週期,以達到預防性之網路維護,來增加網路品質的穩定度及可靠性,在這背後有一群默默付出的工程人員,新建設好的網路若不加以維護,久而久之,網路只會越來越糟,不可能有所改善,因此,不做任何的預防性維護作業,網路品質要好,是不可能的;祇有盡可能的做好預防性維護作業。 1.CMTS 各回傳端口實時 SNR 值的監測,通過歷史數據還可以看到趨勢圖。在網絡狀況剛開始劣化時及時採取措施,避免用戶斷線報修。 2. 實時監測各設備端口的流量、在線用戶數量,以便調整網絡帶寬配置,均衡網絡流量,充分利用帶寬資源。 3. 定期檢測用戶 Cable Modem 設備的射頻參數,發現有超標劣化傾向時及時提醒維修人員處理,避免用戶投訴。 4. 用戶報修時,迅速判斷故障原因,縮短維修時間。 5. 根據實際情況的需要,隨時將需要監測的參數編寫到動態網頁中供維護人員使用,並結合 EXCEL 報表輸出。
  • 5. Network Operation Center 功能介紹 使用網路管理系統監測到用戶及網路設備之各種屬性之流量及狀態,分析整體頻寬使用狀況、隨時掌握及監控每一網路相關環節。 針對用戶的使用時間行為,提供二十四小時的監控線路系統的穩定和異常的處理及通報流程。 NOC 人員可透過監控系統掌控機房及所有線路,及瞭解每一客戶的頻寬使用量及訊號品質。 機房設備及線路之運作,網管人員會在發生異常警示前,可以在全程監控過程中發現異常及不穩定之訊號,並加以處理,以免除異常發生時所造成的無謂之損失。 將網管中心將所有之監控內容記錄於資料庫,並將資料庫所記錄之訊資料加以分析整理,可供各部門作必要性報表之查詢。 提供相關部門查詢每日、每週或每月的影響服務的事件原因、事件類別、影響時間、影響範圍及影響件數等報表統計資訊。
  • 6. 監控項目 MRTG 網頁監控項目 ROUTER 、 SWITCH 、 InterfacePort 流量。詳細記錄 CMTS 每個上下行流量。 GAME SERVER 監控、熱門網站流量監控。 Solarwinds 監控系統 可列出 SNR 較差的 Cable Modems, 以方便改善 、迅速的查知頭端設備 up or down Cable Modems 有振盪狀態 &quot;Flapping“ 可透過頭端設備表列或圖示 Cable modem 的 SNR 及 Power Level 整體狀態 Cable Modems 的 power levels 狀態、 Cable Modem 各個介面的使用狀態 FTTB 監控用戶異常流量 監控大樓交換機狀態與 log 、 FTTB 用戶 IP 存量控管、 FTTB Switch Port 使用量控管 數位頭端設備 監控數位頭端設備運作狀態、監控數位頻道節目品質狀態 告警系統 CM 異常告警、網路異常告警系統
  • 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 人力以上協同處理。
  • 9. 頭端工程師 頭端為常態人力編制維護頭端運作狀態,現階段除北高 (CL) 外南高 (GD) 已經建置頭端環控機制,而 ISP 業務於頭端之相關硬體設備均可由遠端加以監控,故目前僅類比頻道需由人工進行監控,以頭端設備妥善率而言,故需常態投入人力進行維護工作。 工作項目 負責網路硬體設備的架設 ( 規劃,發包,鋪設 ) 、管理與維護。 負責鋪設網路連接光纖傳輸設備及所需的網路連接(轉接)設備。 基本訊號量測及頭端環境記錄等作業。
  • 10. ?
  • 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 進行確認結案 告知回復狀況 臨時線系統 工程結案 臨時線架設 工程派工
  • 12. 故障管理 _CATV 異常處理流程 系統警訊告知。 確認是否為計畫性工程或是非計畫性工程。 先行預先通告客服及工程窗口告知事件發生。 確認機房光送收發設備是否有訊號發送。 (DB 表、頻譜、 POWER METER 、反向頻譜 SST) ODTR 光纖路徑確認。 ( 光纖示意圖、光纖對照表 ) 判斷為光纖斷線時,緊急通告工程主管及客服中心,並告知工程主管斷線 NODE 及斷點米數,並從光纖示意圖確認光纖蕊數。 開啟該 NODE 佈線圖,並協同工程人員判斷斷線路段 ( 縮小範圍 ) ,並指揮前往修復。 通知客服中心事件發生情況。 工程人員至現場維護網路,將事件排除。 工程人員回報 NOC 網管中心。 NOC 網管中心進行事件確認,並將斷訊原因填入系統中進行確認結案。 客服中心進行事件訊息確認,進行開博系統用戶確認結案。 回報並確認是否需求,工程臨時線佈放管理,並以每週進行追蹤。 網管中心通報機制: 1. 接獲障礙案件後 (. 突發性障礙 mail 通報機制 ) , 10 分鐘 內通報障礙權責單位,上班時間 30 分鐘或非上班時間 60 分鐘 內障礙單位回報或 NOC 主動聯繫障礙單位, 2 小時 內維修人員回報或 NOC 主動聯繫維修人員並於告警系統填入判斷障礙原因、修復時間。 2. 現場維修人員於障礙修復完成,回報 NOC 實際修復時間及障礙原因, NOC 接獲修復完成通報後聯繫客服中心人員協請去電申告客戶複查。 3. 各權責單位回報障礙機制為使障礙通報窗口單一化及 NOC 詳細統計障礙歷程,協請工程部及現場維修人員配合回報 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 工程臨時線佈放管理,以每週進行追蹤。 超過三個月以上案件,進行統計。
  • 15. ?
  • 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 戶數變化 異常資訊經確認解除 後會把資料存放在 系統裡
  • 23. 目的:數位時代的來臨,高速傳輸條件嚴謹,為了確保網路品質的穩定度及可靠性 ,必須提昇整體網路品質管控,減低工程維護負擔。未來 DTV 用戶, STB 傳輸供裝方式 雙向用戶區提供一 CM (32kbps)+STB 進行機上盒雙向回傳功能。 雙向用戶區提供整合型 STB 進行機上盒雙向回傳功能。 FTTB 供裝區域利用 STB Ethernet REV 進行機上盒雙向回傳功能。 ( 未定 ) 單向區或無安裝上網設備,則利用 080 免付費電話進行訂購。 ( 未定 ) 開放他家 isp 網路傳輸上傳功能。 ( 降低競爭力 ) ( 未定 ) 因為所有的服務都是透過同路由之同軸網路,所以裝機時更要確保網路的品質,任何異常參數 將都會影響整體的收視及上網品質,影響甚大,所以特別看重此事。 未來則要再考慮匯集雜訊的產生,及 cmts 的整體負擔。 要求 CM 裝機之工程師一定要把訊號調整到最佳品質 ( 可以參閱 CM 內頁 ) 。 目前中嘉定的標準 下行 SNR >+35dB 上行 SNR >+24dB 下行 power >- 10dB 下行 power <+12dB 上行 power >+30dB 上行 power <+55dB 為了讓訊號品質更穩定,位準一旦變化的時候不會造成異常工單,目前裝機先針對 CM Power Level ( 下 / 上 ) 的準位先修到理想的比例。 CM Power Level ( 下行 / 上行 ) 5dB /42dB 衰減器加太少,信號在合格邊緣值的時候,當網路訊號產生變化時容易再造成異常工單。 例如 13dB/ 34dB 加 10dB 衰減器 ? 3dB/44dB 9dB/ 37dB 加 6dB 衰減器 ? 3dB/43dB 7dB/ 26dB 加 10dB 衰減器 ? -3dB/36dB 預防性裝機回報流程
  • 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. 六 、 經處理回報後 , 該筆工單狀況顯示 ” 已處理 ” 裝機回報流程
  • 32. ?
  • 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 工單讓工程查修
  • 40. ?
  • 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 裝機紀錄查詢
  • 44. 主要計劃項目 規劃 HFC NODE 為監控模式 以 HFC 網路用戶為即時監控範圍 即時提供 HFC CM Alert 戶數差異資訊 預期效益 強化 CSR 與工程單位客戶來電與障礙判斷依據。 提昇工程單位網路維運成效。 同步提昇 HFC 網路圖資正確度。 提供後續 NOC 系統整合作業參考。
  • 45. HFC 網路用戶即時監控 為於 HFC 網路發生異常時,可立即了解障礙發生方位 ( 迴路 ) 與異常用戶資訊,以利 CSR 客戶來電與工程單位維運時判斷,提高工程單位查修成效。 建置目的 使用工具及範圍 使用 Solarwinds 監控平台與後端 CMTS Status Date 匯出資訊。監控模式以 NODE 為單位 ( 初期建置 1 個 NODE 測試成效 ) 再擴大至 HUB 範圍監控。 協作單位 NOC/CSR/ 工程單位 ( 設計部 )/ 資訊部。 預估建置時程
  • 46. HFC 網路用戶即時監控 自目前工程 HFC NODE 網路圖資各延伸迴路末端 CM 用戶分別找出 3 個監控點。 監控方式 利用 SMMP 模式持續監控 CM 用戶 Status 狀態。
  • 47. 當 HFC 網路發生 CM 用戶數劇減或 SNR 降為 0 時, MRTG Top Alerts 即產生告警訊息。 HFC 網路用戶即時監控
  • 48. HFC 網路用戶即時監控 利用 SMMP 模式觀察監控 CM 用戶 Status 是否為異常狀態。 監控方式 藉此提供異常路段予 CSR 及工程單位,作為客戶來電與障礙判斷依據。
  • 49. HFC 網路用戶即時監控 自 CMTS 匯出 CM 用戶 Status 狀態與客戶資料差異比對。 監控方式 CM Status CM MAC / IP
  • 50. HFC 網路用戶即時監控 提供異常客戶資料於 CSR 與工程單位作為客戶來電與障礙判斷依據。 監控方式 範例
  • 52. ?
  • 53. ?
  • 54. 自動播放系統評估 為了能讓 NTOC 運轉更流暢,及人員調度上的優勢,預計引進新系列的自動播放系統,及 16 畫面切割頻道監控系統。 為了符合自製頻道播映之條文,為此必須切割自製頻道共同訊號源。 目前自製頻道播放系統,為較為老舊之播放系統,都是屬於帶狀化節目製作,保存占空間及不易保存,目前之自動播片程式支援度低,頭端人員執行節目轉檔、存檔、節目排程等均難以操作,且設備故障率高,且要常常人工換帶,影響自製頻道播映品質,必須即時更換系統。 BETACAM 及 DVD 撥放設備已經接近年限或超過年限,維修費用逐年升高,部分已經無產品零件維護。側錄節目內容大多數轉錄為 DVD ,轉錄存檔不易又浪費人力工時,建議採購 MPEG2 自動撥放系統及儲存磁碟櫃,定立播放節目儲存標準。 公益頻道為 CH - 03 、自製頻道 ( 收費性質 ) 為 CH - 04 共計 2 個頻道需採購 4 組電腦播放系統 ( 港都、慶聯、大信、 ) 及一台 DATA 資料儲存櫃 *1(8T) 。 經由 NOC 與頭端監控中心的結合,及簡化播放流程才能有效作最大人力整合需求。
  • 55. 跑馬燈的簽呈流程 因跑馬燈的簽呈流程至客服中心,往往已超過施工時間 請各位主管注意並宣導 , 日後有關跑馬燈的申請,除了正式簽核流程外 請各位主管將跑馬燈申請之申請文件放在共用資料區 , 以讓客服中心能提早了解 192.168.1.8共用資料區 客服轉工程 - 不可刪 SO 工程部斷訊通知 頭端網管

Editor's Notes

  1. 【展示方式】 本頁不需滑鼠操作,僅以口頭說明。 【展示主旨】 如文中所述