הפעולה הנוכחית של רשת 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 יגדיר וידחוף את כל סוגי האזעקות הראשון והשני לפלטפורמת ניהול מידע האזעקה, ולאחר מכן הפלטפורמה תנתח את מידע האזעקה של הפרעה בשירות יחיד, כאשר המידע העיקרי של אזעקת הפרעה בנתיב האופטי ו(אם קיים) מידע אזעקת מיתוג הגנה נשלחים למהנדס התפעול והתחזוקה. שלושת המידע הנ"ל כנראה יכול לשמש לאבחון ועיבוד תקלות. בעת הגדרת קליטה, ניתן להגדיר הגדרות התראה טלפוניות עבור אזעקות גדולות כגון כשלים באות מורכב המתרחשים רק כאשר סיבים אופטיים שבורים, כגון: