הפעולה הנוכחית של רשת DCI (חלק שני)

3 ניהול תצורה

במהלך תצורת הערוץ, נדרשות תצורת שירות, תצורת קישור לוגי בשכבה אופטית ותצורת מפת טופולוגיה וירטואלית של קישורים.אם ניתן להגדיר ערוץ בודד עם נתיב הגנה, תצורת הערוץ בשלב זה תהיה מסובכת יותר, וניהול התצורה שלאחר מכן יהיה גם יותר מסובך.נדרשת טבלת שירות ייעודית רק כדי לנהל את כיוון הערוץ, ויש להבחין בין כיוונים עסקיים בטבלה, באמצעות קווים מוצקים ומקווקוים.כאשר ההתאמה בין ערוצי OTN לקישורי IP מנוהלת, במיוחד במקרה של הגנת OTN, קישור IP אחד צריך להתאים למספר ערוצי OTN.בשלב זה כמות הניהול עולה והניהול מסובך, מה שמגדיל גם את הניהול של טבלאות אקסל.דרישות, לניהול מלא של כל האלמנטים של העסק, עד 15. כאשר מהנדס רוצה לנהל קישור מסוים, הוא צריך לברר את טופס האקסל, ואז ללכת ל-NMS של היצרן כדי למצוא את המתאים, ולאחר מכן לבצע פעולה הַנהָלָה.זה דורש סנכרון של מידע משני הצדדים.מכיוון שפלטפורמת ה-NMS של OTN והאקסל שנעשו על ידי המהנדס הם שני נתונים מעשה ידי אדם, קל שהמידע לא מסונכרן.כל טעות תגרום למידע העסקי שלא יהיה תואם למערכת היחסים בפועל.בהתאם, זה עשוי להשפיע על העסק בעת שינוי והתאמה.לכן, נתוני הציוד של היצרן נאספים לפלטפורמת ניהול דרך הממשק לכיוון צפון, ולאחר מכן מותאם המידע של קישור ה-IP בפלטפורמה זו, כך שניתן להתאים את המידע באופן אוטומטי בהתאם לשינויי השירות של הרשת הקיימת , ומובטח הניהול הריכוזי של המידע.ומקור יחיד של דיוק כדי להבטיח את הדיוק של מידע ניהול תצורה.

בעת קביעת התצורה של אספקת שירות OTN, הכן את תיאור המידע של כל ממשק, ולאחר מכן אסוף מידע OTN דרך הממשק לכיוון צפון המסופק על ידי OTN NMS, וצמד את התיאור הרלוונטי למידע היציאה שנאסף על ידי התקן ה-IP דרך הממשק לכיוון צפון.הניהול מבוסס הפלטפורמה של ערוצי OTN וקישורי IP מבטל את הצורך בעדכון מידע ידני.

לשימוש ברשת השידור DCI, נסה להימנע משימוש בתצורת שירות חיבור צולב חשמלי.שיטה זו מורכבת ביותר בלוגיקת ניהול, והיא אינה חלה על מודל רשת DCI.ניתן להימנע מכך כבר מההתחלה של עיצוב DCI.

4 ניהול אזעקות

בשל תקורה הניהולית המורכבת של OTN, ניטור האותות במהלך שידור למרחקים ארוכים, וריבוי וקינון של חלקיקי שירות שונים, תקלה עשויה לדווח על עשרות או מאות הודעות אזעקה.אמנם היצרן סיווג אזעקות לארבע רמות, ולכל אזעקה יש שם אחר, אבל זה עדיין מסובך ביותר מבחינת תפעול ותחזוקה של מהנדס, ודורש כוח אדם מנוסה כדי לקבוע את סיבת התקלה מלכתחילה.פונקציית שליחת התקלות של ציוד OTN מסורתי משתמשת בעיקר במודם SMS או דוא"ל, אך שתי הפונקציות מיוחדות לאינטגרציה עם פלטפורמת ניהול אזעקות הרשת הקיימת של המערכת הבסיסית של חברת האינטרנט, ועלות הפיתוח הנפרד היא גבוהה, ולכן צרכים נוספים להתבצע.הממשק הסטנדרטי לכיוון צפון אוסף מידע אזעקה, מרחיב את הפונקציות תוך שמירה על הפלטפורמות הרלוונטיות הקיימות של החברה, ולאחר מכן דוחף את האזעקה למהנדס התפעול והתחזוקה.

לכן, עבור אנשי התפעול והתחזוקה, יש צורך לתת לפלטפורמה להתכנס אוטומטית למידע האזעקה שנוצר על ידי תקלת ה-OTN, ולאחר מכן לקבל את המידע.לכן, תחילה הגדר את סיווג האזעקה ב-OTN NMS, ולאחר מכן בצע את עבודת השליחה והסינון בפלטפורמת ניהול מידע האזעקה האחרונה.שיטת האזעקה הכללית של OTN היא שה-NMS יגדיר ותדחוף את כל סוגי האזעקות הראשון והשני לפלטפורמת ניהול מידע האזעקה, ולאחר מכן הפלטפורמה תנתח את מידע האזעקה של הפרעת שירות בודדת, העיקרית אזעקת הפסקת הנתיב האופטי מידע ומידע (אם יש) מיתוג הגנה נדחפים למהנדס התפעול והתחזוקה.שלושת המידע הנ"ל יכולים לשמש כנראה לאבחון ועיבוד תקלות.בעת הגדרת קליטה, אתה יכול להגדיר הגדרות הודעות טלפוניות עבור אזעקות גדולות כגון תקלות אות מורכבות המתרחשות רק כאשר סיבים אופטיים נשברים, כגון: