** AMHS MANAGEMENT **

AMHS  MANAGEMENT

1-1:آخرین پیشرفت در زمینه مخابرات در محیط ATS,"AMHS"می باشد.AMHS صورت تدریجا"تکامل یافته ای از AFTN/CIDIN،جایگزینی برای مدل تلگرافی با یک سیستم ارایه کننده ی پیامهای مدرن بر اساس استانداردهای بین المللی می باشد.

فرض بر این است که ATSMHS،به عنوان یک اجرای ATN،از زیر بنای شبکه ی داخلی ATN استفاده می کند.با این حال این یک شرط لازم برای آمادگی و توسعه ی مقدماتی ATSMHS نیست.

چندین مزیت AMHS نسبت به AFTN/CIDIN شامل موارد زیر می شود:

.سرعت،ظرفیت و میزان عملکرد بالاتر

.اعتبار بیشتر

.کارآیی گسترده تر

.استفاده از تجهیزات و خدمات COTS

1.2:مروری بر ATSMHS

1.2.1:کلی                                               

1.2.1.1:SARPهای ATN ,سرویس ذخیره و ارسال ICAO که برای مبادله ی پیامهای ATS بین کاربر و شبکه داخلیATN مورد استفاده قرار می گیرند را برای سیستم پیام رسانی سرویس های خطوط هوایی (ATSMHS) تعیین می نماید.

1.2.1.2:سیستم منابع محاسبه و ارتباط توسط سازمان های ATS انجام می شوند تا خدمات ارایه کننده ی پیامهای ATS را که به عنوان AMHS (سیستم ارایه کننده ی پیام ATS) شناخته می شوند,فراهم کنند.

 

1.2.2:عوامل کاربردی

از لحاظ کاربرد ATSMHS شامل عوامل زیر می باشد:

1)عامل انتقال پیام (MTA) که کار جابجا کردن پیام را انجام می دهد.

2)عامل کاربر(UA) که دسترسی کاربر را به MTA میسر می کند و یک نرم افزار عامل مناسب را فراهم میکند.

3)واحد الحاق (AU) که ارتباط مشترک با سیستمهای پیام رسانی دیگر را فراهم می کند.

1.2.3:سیستمهای مقصد

1.2.3.1:چهار دسته سیستمهای نهایی ATN,برای پشتیبانی خدمات پیام رسانی ATS تعریف شده اند:

.پیام رسان های ATS

.عامل کاربر پیامهای ATS

.ورودی و خروجی AFTN/AMHS

.ورودی و خروجی CIDIN/AMHS

1.2.3.2:این سیستمها ارتباط بین کاربر ها در سیستمهای مقصد ATNو کاربرهای ایستگاههای AFTNرا به سه شکل مختلف مجاور هم فراهم می کنند:

a.از یک ایستگاه AFTN/CIDINبه ایستگاه دیگری از AFTN از طریق ATN

b.از یک ایستگاه AFTN/CIDIN به ایستگاه(سیستم) مقصد ATN و بالعکس

c.از یک سیستم مقصد ATN به سیستم مقصد دیگری در ATN

2.1:مقدمه ...

هدف این بخش بررسی نیازمندی های عملی و تکنیکی سیستم COM است که با یک AMHS و یا افزودن قابلیت ATSMHS,جایگزین سیستم AFTN/CIDIN می گردد.

همانطور که در عنوان آمده است ,این بخش شامل راهنمایی هایی برای نیازمندی های SARPهای AMHS,بلکه از دیدگاه گروه قابل لحاظ شدن در سیستم CALL FOR TENDER برای تهیه ی یک سیستم AMHS می شود.

2.1.2:مهمترین ورودی این بخش ,زیر مجموعه ای از مشخصات یک CALL FOR TENDER واقعی استکه توسط یکی از اعضای گروه ارایه گردیده و به عنوان نمونه ای که مورد استفاده ی ATSO (سیستم سازنده ی AMHS) می باشد,ساخته و پرداخته گردیده است.

2.1.3:این بخش شامل نیازمندی های عملی و تکنیکی ذیل می باشد:

.امکانات کلی

.مرتب کردن و برنامه ریزی امکانات لیست شده

.مرتب کردن امکانات مدیریتی

.امکانات تکرار پیام

.پیدا کردن امکانات

.سایز بندی

.قابلیت دسترسی واعتبار

2.1.4:برای سیستم COM در پاراگرافهای بعدی ,اصطلاح "سیستم AMHS"مورد استفاده قرار خواهد گرفت.

2.1.5:به دلیل مشخصه ی این بخش (به عنوان راهنماهای نیازمندی های سیستم)اصطلاح "باید"استفاده می شود.در یک CALL FOR TENDER مشخص,"خواهد"جایگزین "باید"می شود.

2.2:نیازمندی های کلی

2.2.1:سیستم AMHS باید ATSMHS را اجرا نماید.و امکانات ورودی AFTN/AMHS را بر اساس مشخصات تعریف شده در آخرین SARPهای ATN تصویب شده برای خدمات اساسی ,تحقق بخشد و طول پیامهای پشتیبانی AFTN باید تا 64 کیلو بایت باشد.

نکته:این نیازمندی ها تحت پوشش SARPهایی که فقط عهده دار پشتیبانی از طول پیامهای AFTN استاندارد هستند,نمی باشند.

2.2.2:سیستم AMHS باید چندین ارتباط همزمان را توسط یک MTA همکار(حداقل 5تا) پشتیبانی کند.

2.2.3:سیستم AMHS باید چندین ارتباط همزمان را توسط چندین MTA همکار (یک یا چند ارتباط با هر MTA) پشتیبانی کند (طبق توافق حمل و نقل یا توافق نامه ای دیگر,برای مثال:TCP/IP که در EUR استفاده شود,ATN بین محیطهای ICAO).

2.2.4:سیستم AMHS باید بدون هیچ محدودیتی اعم از طبیعی سیستم(حافظه و ...)جمعا تعدادی از ارتباطهای همزمان را (مجموعه همه ی ارتباطات)را پشتیبانی کند.

2.2.5:سیستم AMHS باید اجازه رسیدگی به پایه گذاری ارتباطات با MTA همکار را توسط فرمان های اپراتور زنده بدهد.به این معنی که باید قادر باشد تا:

.ممانعت/اجازه ی تاسیس ارتباطات با یک MTA همکار که توسط سیستم AMHS ارایه گردیده (MTAمحلی),تنها با همه ی شریکهای MTA همکار و یا هر دوی همکار.

.ممانعت/اجازه ی تاسیس ارتباطات با همه ی شریکهای متشکل MTA توسط سیستم AMHS ) MTA محلی),تنها با همه ی شریکهای MTA ویا با همه ی شریکها.

.دستور خاتمه ارتباطات تاسیس شده با شریک MTA داده شده.

.دستور خاتمه پایان ارتباطات تاسیس شده با همه شریکهای  شکل یافته ی MTA.

تعداد ارتباطات همزمان واقعی که باید پشتیبانی شود بستگی دارد به:

.موقعیت نهایی شبکه ی AMHS:به طور مثال هر مرکز با مراکز دیگر و یا فقط با مراکز همجوار ارتباط مستقیمی برقرار می کند.(همانند AFTN)

.اینکه آیا ارتباطهای دایمی یا فعال برقرار می گردد یا خیر.این امتیاز تنها در شرایطی که نیازی به تبادل عبور و مرور مداوم نباشد,کارآیی دارد.

2.2.6:سیستم AMHS باید دسته بندی های MTA را به انجام برساند.این دسته بندی پیامهای AMHS را به گونه ای حفظ  می کند که:

1)یا برای ارسال معلق بمانند.

2)یا انتقال یابند اما یک گزارش دریافت مورد انتظار باشد.

نکته1:دسته بندی گروه اول باید در MTA انجام گیرد.

نکته2:دسته بندی گروه دوم باید در عوامل کاربر و MTCU های ورودی های AFTN/AMHS انجام گیرد.

عکس العمل یک سیستم AMHS در صورت گم شدن یک گزارش دریافت باید ثابت باشد.(جریان اجرا)به طور مثال :اینکه آیا پس از اتمام وقت ,پیام باید مجدداً ارسال گردد؟یا اینکه چه مقدار تلاش برای ارسال مجدد باید صورت گیرد؟

یک پیغام DR یا NDR (گزارش دریافت یا عدم دریافت) به پیام رسان فرستاده می شود.بنابراین پیام رسان باید روی DR های نرسیده به شیوه ای حرفه ای عمل کند و نسبت به دریافت NDR واکنش نشان دهد.

اگر پیام رسان یک کاربر غیر مستقیم (AFTN) باشد,دروازه های AFTN/AMHS مجبور است کارش را به نوبه ی خود انجام دهد.

به علاوه ,یک گزارش ممکن است از طریق دیگری غیر از پیام اصلی انتقال یابدیعنی از یک MTA یکسان با پیام اصلی.

2.2.7:برای هر MTA همکار شکل یافته می بایست یک ردیف MTA منطقی وجود داشته باشد.

2.2.8:

a.تشکیل قرارداد حمل و نقل (برای مثال :TP/X25,TCP/IP,ATN) که برای استفاده ی هر کدام از MTA های همکار باید امکان پذیر باشد.

این مثال لزوم انعطاف پذیری تشکیل هر MTA همکار را از طریق فرمانهای ONLINE برای هر یک از شاخص هایش نشان می دهد.در مثال های دیگر ذکر می شود که:

b:در حالت انتخاب TP/X25,تشکیل حداقل در اتصال داخلی X.25 برای استفاده در ارتباطات و چندین آدرس تماسهای گرفته شده و دریافتی که برای شروع کردن یک تماس و یا پذیرفتن یک تماس دریافتی مورد استفاده قرار می گیرند,باید امکان پذیر باشد.

c:برقراری حداکثر تعداد ارتباط های همزمان با هر شریک MTA باید امکان پذیر باشد.

d:بررسی کردن اینکه آیا ارتباطات ,دایمی هستند و یا بر طبق ترافیک پایه گذاری و اتمام می یابند نیز باید امکان پذیر باشد.

2.2.9:سیستم AMHS باید تشکیل شرح حال اقلام را مجاز شمارد.

 

2.2.10:سیستم AMHS باید تشکیل حداقل شرح اقلام زیر را جایز شمارد:

 a:برنامه ریزی بین نیازهای درجه اول AFTN و نیازهای درجه اول جعبه انتقال پیامهای AMHS

b:ارزش"rn","rnr" در موارد لزوم گزارش در محیط دریافت کننده ی IPM

    این ارزش به ارزش نیازهای درجه اول AFTN بستگی دارد.

نکته1:هر دو عمل بالا باید در UA ها و MTCU های ورودی های AFTN/AMHS انجام شوند.زیرا که MTA با پیامهای درجه اول ATS (و یا AFTN) که مشمول سه دسته ی پیامهای ATS به عنوان قسمتی از بدنه ی IPN می شوند,سرو کار ندارند.

نکته2:SARP ها ارزش این شرح اقلام را تعیین می کنند.به نظر می رسد که مرحله ی اجرا فقط در صورت اینکه تجربه اجرایی انتصاب دیگری را پیشنهاد کند,باید مجاز به تغییر آنها باشد.این پردازش یک جریان اجرایی است.

2.3:برنامه ریزی و تطبیق نیازمندی های فهرست

2.3.1:سیستم AMHS باید CAAS را پشتیبانی کند.

2.3.2:حتی اگر ATSO,CAAS را برای کاربر داخلی انتخاب کرده باشد,سیستم AMHS باید پیامهای AMHS را که با نام O/R در طرح برنامه ریزی XF دریافت شده اند پردازش و کنترل کند.

2.3.3:سیستم AMHS باید مکانیزم ورود فهرستهای برنامه ریزی شده ی مورد نیاز در ورودی AFTN/AMHS را فراهم کند.فهرستهای وارد شده از سیستم AMC قابل ذخیره سازی خواهند بود.

2.3.4:امکانات انجام شده در دروازه ی AFTN/AMHS که یک آدرس AFTN را به نام O/R ترسیم میکند باید قابلیت تغییر پذیری کافی را داشته باشند تا بتوانند ساختارهای مختلف O/R را تهیه کنندو از حداقل فهرستهای متشکل و حداقل ورودی ها استفاده کنند.

به عنوان مثال برای تطبیق یک آدرس AFTN با یک نام O/R ,اطلاعات زیر باید در فهرستهای تشکیل شده وارد شود.

a:نتایج و ارزشهای مربوطه که برای هر حالت ثابت هستند.

b:نسبت هایی که ارزش هایشان مستقیما" از آدرس AFTN تعیین می شود.

c:نسبتهایی که رقم های ارزشهای آنها بستگی به فهرست برنامه ریزی شده دارد.برای هر کدام از این نسبتها در هر محیط به این حالت عمل می شود:اسم فهرست برنامه ریزی شده و زیر مجموعه ی آدرس AFTN (برای مثال یک آدرس کامل AFTN چهاررقمی,می توانند برای تعریف  زیر مجموعه مورد استفاده قرار گیرند) که فهرست برنامه ریزی را مرتب می کنند.فهرست برنامه ریزی نیز خود باید فراهم شود.برای مثال:در صورتی که کشورها از طرح آدرس CAAS استفاده کنند,ارزش نسبتهای سازمان باید از این راه تعریف شود.

2.3.5:امکان استفاده از دفترچه راهنما نیز باید میسر شده باشد,حتی اگر این بخشی از خدمات اصلی نباشد.

 

2.4:مرتب سازی نیازمندی های مدیریت

2.4.1:سیستم AMHS باید علاوه بر امکان انتقال کامل ردیفهای صادره ,پردازش مجدد پیامهای X.400 ردیف های همجوار MTA را فراهم کند.

نکته:این امکانات پردازش مجدد در طول مدتی که مراکز AMHS و CIDIN/AFTN با هم در منطقه ی EUR وجود داشته باشند,خیلی مهم خواهد بود.

2.4.2:دو نمونه از پردازش مجدد باید اینگونه باشند:

.در سطح X.400  کامل

.در سطح AFTN (در مورد ورودیهای AFTN/AMHS)

 

2.4.3:پردازش مجدد در سطح X.400  خالص باید بتواند:

.پیامهای منتظر ارسال X.400 را از این صف خارج کند.

.این پیامها را دوباره در نرم افزار خط سیر X.400 پردازش کند.

.بر اساس فهرستهای X.400 جدید و یا موقتا" تعریف شده,خط سیر را مشخص کند.این چنین مکانیزمی باید اجازه ی خروج پیامها را از ردیف پیامهای غیر قابل دسترسی صادر کند.پیامها می توانند از طریق مرکز دیگری (MTA) عبور کنند و از طریق مسیری متناوب پیش بروندالبته فقط برای آن دسته از آدرسهای دریافت شده که مسیرهایی متناوب برای آنها فعال شده است.برای تمامی آدرسهای دیگر پیامها در صف باقی می مانند.این عمل از عبور پیامها به یک مرکز دیگر (MTA) با آدرسهای دریافتی مغایر با مسیرهای مجدد مورد نظر ,جلوگیری می کند.

2.4.4:پردازش مجدد سطح X.400 خالص باید در سرویس دهنده های پیام ATS,در ورودی های AFTN/AMHS و (در آینده) در ورودی های CIDIN/AMHS انجام گیرد.

2.4.5:پردازش مجدد در سطح AFTN باید:

.پیامهای منتظر در صف X.400 را خارج کند.

.آن ها را با لایه AFTN پردازش مجدد کند و

.بر اساس فهرستهای X.400 و CIDIN و AFTN  متداول به آنها مسیر بدهد.

این پردازش مجدد مسئله غیر قابل دسترس بودن را در یک محیط AFTN/CIDIN/AMHS  غیر مشابه, حل می کند.

2.4.6:یک ردیف X.400 می تواند شامل پیامها و گزارش ها شود.عمل پردازش مجدد AFTN باید تنها شامل پیامها شود.این پیامها می توانند از نمونه های مختلف باشند.پیامهایی از ورودی AFTN/AMHS , پیامهایی از ورودی های CIDIN/OPMET/AMHS,UA خالص به تبادلات UA و غیره.

تمامی این پیامها ,پیامهای IPM خواهند بود,بنابراین برای تشخیص آنها در سطح قراردادی X.400 هیچ راهی وجود ندارد.

2.4.7:پردازش مجدد باید تنها به پیلمهای تولید شده به وسیله ی ورودی AFTN/AMHS محدود شود.

2.5:نیازمندی های تکرار پیام

2.5.1:سیستم AMHS باید امکانات بالای تکرار پیام ها در انجامش های سیستم های تابع CIDIN و AFTN و AMHS را فراهم کند.

2.5.2:امکانات تکرار پیامها باید قادر باشند تا پیامها را همانطوری که از اصل انتقال یافته اند,تکرار کنند.بدین معنی که آن ها باید در حالی که همان راه عبور را دنبال می کنند,به دریافت کننده ها فرستاده شوند.

2.5.3:علاوه بر آن امکانات تکرار پیامها باید قادر باشند تا مقصد های کلی را معین کنند.این مقاصد می توانند یک آدرس AFTN باشند یا یک نام O/R  یا همه ی آدرسهای AFTN موجود در یک AX داده شده و غیره.

2.5.4:سیستم AMHS باید تمامی پیامهایی را که به این مقصد های کلی انتقال یافته اند در یک وقفه زمانی مشخص شده ,پیدا کند و آنها را دوباره به مقصد های در حال انتظار انتقال دهد.

برای جلوگیری از انتقال پیامها به مقصدهای دیگر که به طور طبیعی پیام آنها را در بر می گیرد,آدرسهایی که با مقصد کلی تطبیق ندارند باید مسدود شوند.

2.6:دنبال کردن نیاز مندیهای  دستگاهها

2.6.1:سیستم AMHS باید امکاناتی را فراهم کند تا اجازه ی تولید سوندها X.400 را بدهد.

2.6.2:قسمت مبادله ی اطلاعات کاربر باید اجازه وارد شدن نیازهای درجه اول ,نام O/R مبداء ,مقصدها و طول پیامها را بدهد.

2.6.3:سیستم AMHS باید پیامهای در ارتباط با سوند (دریافت شده ها و غیر دریافت شده ها) را به یک مثال تبدیل کند.(به عنوان مثال:صف عدم پذیرش)

نکته:این به نیاز مبادله اطلاعات کاربر مربوط می شود.کاربر باید از گزارش های ارسال سوند دریافت شده نیز خبر بگیرد.این یک مورد اجرایی است که آیا این اجرا تنها با معین کردن نام O/R یک مبداء ثابت به یکی از صف های سیستم اجرا می شود و یا از طریقی دیگر.

محتوی اینگونه گزارش ها باید در یک قالب قابل فهم آماده و رمز گشایی شود.

2.6.4:سیستم AMHS باید بتواند امکاناتی را فراهم کند که آغاز ,انقطاع و اتمام و ارتباطهای مربوط به MTA همجوار را در زمان واقعی نشان دهد.

2.7:طبقه مندی نیاز مندی ها

2.7.1:طبقه بندی نرم افزار کاربردی سیستم AMHS باید از طرق ذیل حمایت ترافیک را در ساعات اوج مصرف به عهده گیرد.

a:میانگین مصرف کلی CPU در ساعات اوج مصرف در حداکثر 30%

b:بارگیری آداپتورهای ارتباطی تا حداکثر 30% نهایت ظرفیت (غیر از موارد نظری) و حذف نیازهای زائد.

نکته:ارزش های قبلی باید بوسیله ی هر ATSO بسته به طول عمر انتظار سیستم AMHS در نظر گرفته شود.برای مثال:اگر انتظار می رود که طول عمر 10 سال باشد و ترافیک ساعات اوج مصرف مربوط به پایان طول عمر تخمین زده شود,نیازمندی های معمول CPU و آداپتورها ی خطوط ارتباطی باید بیشتر از 30% باشند.(درغیر اینصورت ,سایز سیستم خریداری شده باید در طی چند سال بالاتر رود.)

c:پردازش کردن مدت زمان یک پیام (بالاترین مدل QOS) حداقل کمتر از 5 ثانیه .مدت زمان پردازش اینگونه تعریف می شود:اختلاف بین لحظه ای که آخرین بخش پیام وارد سیستم AMHS می شود و لحظه ای که اولین بخش پیام فرستاده می شود.این برای تمام قراردادهای داخلی و خارجی انجام شده به کار می رود.برای پیامهای دیگر ,زمان پردازش باید کمتر از 3 ثانیه باشد.

نکته:این ارزش,خصوصا"برای AMHS ,همکاری مهم و قابل ملاحظه ای در طبقه بندی نرم افزار و زمان انتقال شبکه ی کلی دارد.اگر که ارزش اصلی پایین باشد,یک نرم افزار خیلی قوی مورد نیاز است.اگر ارزش خیلی بالا باشد,می تواند تاخیر قابل ملاحظه ای را در سرتاسر انتقال پیام ایجاد کند.(مخصوصا" اگر دیگر مرکزها نیز ارزش بالایی داشته باشند.)

d:به دستورات زنده ی(ON LINE) مدیریت در کمتر از 3 ثانیه واکنش زمانی نشان دهد.این واکنش زمانی مربوط به درخواست هایی می شود که از طرف مدیریت صادر شده و برای عمل هایی که نیاز به تحقق نداشته و از یک گزارش هوایی آمده اند (مانند:بستن به یک PVC,تولید یک AX و غیره)

e:حداقل 50%,پس از موارد ذیل ,از فضای دیسک قابل دسترسی باقی می ماند:

1)تمامی نسخه های نرم افزارتوسعه یافته ی معین و استاندارد (شامل احتمال وجود بیشتر از یک نسخه ی نرم افزار و دو شکل برای هر نسخه) روی دیسک آماده هستند.

2)تمام گزارش های هوایی و پوشه های بایگانی متناسب با تعداد روزها,که به صورت زنده در سیستم نگهداری  می گردد,روی دیسک آماده هستند.

نکته:تعداد دقیق روزها به سیاست مخصوص هر ATSO بستگی دارد تا بر طبق نیازمندی های قانونی ICAO عمل شود.

اگر سیاست حکم کند که تمامی داده ها باید در سیستم AMHS نگهداری شوند,سیستم باید حداقل 30 روز را پشتیبانی کند.اگر نشان می دهد که داده ها به این منظور در جای دیگری ذخیره شده اند(مثلا" در سیستمی دیگر ,در یک واسطه ی خارجی مثل CD-ROM,PAT و غیره)داده های کوتاه مدت تر روی خط نگه داشته می شوند.(برای مثال سه روز,یک هفته)

نکته:همانند CPU  و کاربرد آداپتور ارتباطی :ارزش فضای دیسک بسته به طول عمر مورد انتظار سیستم AMHS و تخمین ترافیک مربوطه ,باید توسط هر ATSO در نظر گرفته شود.

2.8:قابلیت دسترسی و ضریب اطمینان نیازمندی ها

2.8.1:سیستم AMHS باید هر 24 ساعت روز و تمامی 365 روز سال را فعال باشد.

نکته:ارزش های فراهم شده ی زیر باید به عنوان حداقل نیازمندی ها در نظر گرفته شود.ATSO باید آنها را بر اساس خط مشی خود و SLA های داخلی با کاربرهای داخلی اش در نظر بگیرد.

2.8.2:وقفه ها برای نگهداری و نصب سیستم باید به حداقل مطلق محدود شوند و باید کمتر از 60 ثانیه باشند.

2.8.3:وقتی سیستم AMHS روشن می شود باید حداکثر بعد از 15 ثانیه به مرحله ی عمل درآید.

2.8.4:سیستم AMHS باید نشان دهد:

.حالت فرآیندهای استعمال

.حالت فرآیندهای سیستم

.حالت سخت افزار سیستم

2.8.5:سیستم AMHS باید به طور خودکار تلاش کند تا نقص هایش را در مراحل استعمال برطرف کند.اگر امکان رفع نقص  بدون وجود خدمات امکان پذیر نباشد,سیستم AMHS باید به به تمام مراحل کاری خود به شیوه ای منظم پایان دهد و به طور خودکار آن ها را از نو شروع کند.

 

2.8.6:سیستم AMHS  باید این اجازه را به اپراتور بدهد تا :          

a:استعمال AMHS را به طرزی عالی متوقف کند(با شروع خودکار مجدد)

b:استعمال AMHS را خیلی خوب متوقف کند(بدون شروع مجدد خودکار)

c:استعمال AMHS را مجبور به متوقف شدن سازد(بدون شروع مجدد خودکار)

d:استعمال AMHS را به وسیله بازیافت پیامها آغاز کند(پیامهایی که هنگام خاموشی سیستم در صف بوده اند,پردازش و ارسال می گردند)    

e:استعمال AMHS را بدون بازیافت پیامها آغاز کند.(پیامهایی که هنگام خاموشی سیستم در صف بوده اند از رده خارج می شوند.)

2.8.7:طبق قرارداد پیام رسانی مربوطه,سیستم AMHS نباید هیچ پیامی را که از پیش تائید کرده است گم کند,مگر اینکه اپراتوری به طور ضمنی تقاضا نماید.

2.8.8:سیستم AMHS نباید هیچ پیامی را به دلیل بارگیریش گم کند.

2.8.9:در صورت وقوع یک جابه جایی نیازهای ذیل الزامی است:

a:پس از مشاهده یک  نقص در واحد اصلی سیستم یا یک فرمان اپراتور,فرایند جا بجایی باید کمتر از 5 دقیقه به طول انجامد.مدت زمان جابجایی از لحظه ی مشاهده ی نقص(یا فرمان اپراتور) تا زمانی که AMHS ارسال مجدد پیامها را از سر گیرد محاسبه می گردد.(با این فرض که پیامهایی در نوبت وجود دارند یا پیامهای جدید دریافت می گردد.)

b:زمان مورد نیاز واحد آماده باش برای تشخیص یک نقص در واحد اصلی کمتر از 3 دقیقه باشد.

c:فرآیند جابجایی باید کاملا" به طور خودکار فارغ از هرگونه اتصال و انقطاع هرگونه کابل (ارتباطات,دیسکتها,...)باشد.

2.8.10:هرگونه فاصله زمانی بیش از یک دقیقه که سیستم AMHS درآن مدت به دلیل مشکل در نرم افزار یا سخت افزار انتقال پیام انجام ندهد (به طور کلی یا نسبی) یک وقفه در سرویس دهی محسوب می شود.

2.8.11:وقتی که ترمیم به طور خودکار انجام گیرد,زمان وقفه ی سرویس مستقیم AMHS نباید بیش از 10 دقیقه باشد.زمان وقفه از لحظه ی دریافت آخرین پیام تا لحظه ی ارسال مجدد پیام توسط  سیستم AMHS محاسبه می گردد.(با این فرض که پیامهایی در حالت انتظار یا پیامهای جدید وجود داشته باشند)

2.8.12:در یک دریچه ی اسلاید شش ماه نباید بیش از یک وقفه بدون ترمیم خودکار وجود داشته باشد.

2.8.13:در یک روز نباید بیش از یک وقفه بدون ترمیم خودکار وجود داشته باشد.

2.8.14:دریک ماه ,نباید بیش از دو وقفه بدون ترمیم خودکار وجود داشته باشد.

2.8.15:در یک دریچه ی اسلاید سه ماهه نباید بیش از سه وقفه بدون ترمیم خودکار وجود داشته باشد.

2.8.16:MTBF سخت افزار سیستم  AMHS نباید از 52 هفته بیشتر باشد.

2.9:نیازمندی های آمارگیری

2.9.1:سیستم AMHS باید برای هر MTA همکار مستقیم به روش زیر اطلاعات آماری را تولید و نظلرت نماید:

a:سایز متوسط پیامهای اطلاعاتی ارسال شده

b:تعداد پیامهای اطلاعاتی ارسال شده

c:حداکثر مقدار پیامهای اطلاعاتی ارسال شده

d:تعداد متوسط آدرسهای مقصد برای هر پیام ارسال شده

e: تعداد پیامهای اطلاعاتی دریافت شده

f:سایز متوسط پیامهای اطلاعاتی دریافت شده

g:سایز نهایی پیامهای اطلاعاتی دریافت شده

h:زمان متوسط انتقال

i:تعداد گزارشات پیامهای ارسال شده

j:تعداد گزارشات پیامهای ارسال نشده

k:تعداد گزارشات پیامهای دریافت شده

l:تعداد گزارشات پیامهای دریافت نشده

m:کمترین سایز پیامهای اطلاعاتی دریافت شده

n:کمترین سایز پیامهای اطلاعاتی ارسال شده

o:حداکثر,حداقل و متوسط زمان پاسخ

p:تعداد گیرنده های تحت فرایند

q:تعداد پیامهای به تعویق افتاده(میزان این پیامها باید توسط یک شاخص سیستم شکل پذیر معین گردد.)

r:تعداد پیامهای برگشت داده شده

s:تعداد پیامهای پذیرفته نشده

t:تعداد حلقه های یافت شده

2.9.2:در ضمن ,سیستم AMHS بایستی به صورت کلی برای همه ی MTA های همکار اطلاعاتی راکه در مورد 2.9.1 ذکر شد تولید نماید.

2.9.3:سیستم AMHS باید حداقل قادر به تولید آمارهای فوق در فواصل ذیل باشد:

مدت زمان:یک روز,یک ساعت,سی دقیقه یا کمتر

2.9.4:سیستم AMHS  باید قابلیت تعیین زمانهای دیگری در دوره های آماری کاربردی را داشته باشد.

2.9.5:سیستم AMHS باید قابلیت ارائه آمار در سطح مفصل تری را نیز داشته باشد.به طور مثال,مداخل عبور MTA,نشانهای O/R خاص,اسامی فردی O/R.

نکته:هرATSO باید در نظر داشته باشد بر اساس نیاز هایی که دارد (ملی یا بین المللی) و هدف از آمار تولید خود ,چه آمارهایی را در سیستم AMHS  موجود خواهد یافت.مثلل" ممکن است ATSO  هایی وجود داشته باشد که گزارش تبادلات را به سیستم دیگری انتقال دهد که همه ی آمارهای مورد نیاز را تولید می نماید.در این قبیل موارد ,سیستم AMHS باید از نیازمندی های بیش از حد آماری رهایی یابد.اگر ATSO  این سیستم را دارا نباشد.AMHS  خود باید همه ی آمارها را تهیه نماید.

2.9.6:سیستم AMHS  باید قادر به صدور صورت ماهیانه آمارهای خاص باشد این صورت باید حاوی اطلاعاتهای آماری روزانه و نیز آمار ساعات اوج مصرف در یک طرح استاندارد باشد.

3.1:ضروریات لازم برای مدیریت AMHS

3.1.1:فعالیتهای مدیریت AMHS ذیل قابل مشاهده است:

OFF-LINE

بلند مدت

OFF-LINE

کوتاه مدت

ONLINE 24ساعته

هفت روز هفته

جدول زمانی 

                       فعالیت                       

تغییرات سطح بالا برای ارتقاء ضرایب اطمینان ، کاهش شک و پرسش کاربر

رفع نقص

کنترل نقص

جدول گزارش خطاها و سرویس کنترل دسترسی

مدیریت خطا

طراحی سطح بالا برای اتصال بین المللی و سرویس بهبود ملی

فعال سازی / پیداکردن تغییرات ، تغییرات ثابت منتشر شده

اینها خصوصیات ثابت سیستم ONLINE نیست

تغییرات سیستم و کاربر ONLINE ثبت میشود ولی OFFLINE اجرا میگردد

مدیریت ترکیب

سخت افزارها

فعالیتهای طراحی و تدبیر مرتبط با طراحهای سرمایه گذاری ، نگهداری و گنجایش

تولید آمارهای ثابت

N/A

مدیریت حسابرسی

طراحی بلند مدت و بین المللی برای مدیریت ظرفیت

تنظیم کردن فعالیتهای اجرائی

کنترل کاربرد ، عمل کننده ها ، ردیفها ، ارتباطات ، دیسکها و غیره

مدیریت اجرا

تدابیر ایمنی ، تغییرات خاص مهندسی / جغرافیایی برای

ارتقاء امنیت

کنترل سلامتی بطور مرتب ، مرور اخطارها از صنعت و ATSOهای دیگر ، آموزش ایمنی

کنترل حملات ، اقدام متقابل

ایمنی

                                        جدول 6 . دسته بندی فعالیتها براساس جدول زمانی

 

3.2:ترکیب سخت افزارها

3.2.1:با وجود اینکه ترکیب سخت افزارها یک مسئولیت داخلی است,نیاز عمده ای به همپایگی اطلاعات ارسال و فرمان ارسال می باشد.

3.2.2:یک مرکز کنترل OFFLINE.AMHS برای تهیه ,هماهنگ سازی و توضیح اطلاعات فرمان و ارسال AMHS در دوره EUR خلق می گردد.این ترکیب در یک دوره AIRAC چهار هفته ای تغییر می یابد.

3.3:مدیریت حسابرسی

3.3.1:در مرحله ی اولیه عملکرد AMHS حسابرسی صورت نمی گیرد.

3.3.2:صورت هزینه ها نهایتا" به صورت موضعی ارائه می گردند.

3.4:مدیریت اجرا

3.4.1:اجرا:

3.4.1.1:کنترل اجرای زنده شامل کنترل سیستم مقادیر همچون اندازه ی دسته بندی ها ,زمانهای انتقال عوامل مصرف,در حالی که روالهای دستی و/یا خودکار در زمانی که سرفصلها در گذرند به کار گرفته شوند.

3.4.1.2:هدف مدیریت اجرایی OFF LINE توانایی سرویس برای اهداف آتی می باشد.این امر مستلزم آمار دقیق عملکرد سیستم و طرحهای ترافیکی است.

3.4.1.3:هر دو جنبه ی مدیریتی به صورت محلی در یک ATSO موجود هستند و تطبیق بین المللی نیاز ندارند.

3.4.2:آمار:

3.4.2.1:بهتر است آمارها با استفاده از MTA های توافق شده ی بین المللی جمع آوری گردند.

3.4.2.2:ابزار ها باید طراحی قابل انعطافی داشته باشند و قادر به دربرگیری اطلاعات در حد جزئی ترین اپراتور و گیرنده در فاصله زمانی 30 دقیقه و حتی کمتر باشند.

3.4.2.3:یک دوره کمترین آمار ماهیانه باید قابل ارسال باشد.این صورت باید شامل اطلاعات روزانه و نیز اوج مصرف در یک قالب استاندارد باشد.

مشخصات مفصل باید در نظامنامه ی مدیریت مخابرات ATS ذکر گردد.

3.4.3:گزارشات آمارها:

3.4.3.1:صورت آماری اطلاعات روزانه و اوج مصرف باید ماهیانه به مرکز مدیریت مخابرات ATS ارائه گردد.

3.4.3.2:برای آمارهایی که برای استفاده ملی گزارش می گردند توصیه خاص ارائه نمی گردد.

3.5:مدیریت امنیتی:

3.5.1:مدیریت امنیتی در داخل یک ایالت موضوعی محلی تلقی می گردد.حال آنکه اگر یک تخلف امنیتی یا یک تهدید مشاهده گردد,پیشنهاد می گردد که به واحد گزارش خطاها اطلاع داده شود و واحد گزارش خطاها متعاقبا"هشدارهای امنیتی را به ایالتهای دیگر و سایر قلمروها منتقل می کند.

4.روشهای کاربردی و پیشنهادات

4.1:معرفی یک مرکز AMHS COM در شبکه ی AMHS

4.1.1:مفاد اقدام

4.1.1.1:این روش گامهای لازم برای اجرای مرحله ی معرفی یک مرکز  AMHS COM در شبکه ی  AMHS را تصریح می کند.اصطلاح"مرکز AMHS COM جدید " ممکن است به سه مورد مشخص دلالت داشته باشد.:

.مرکز COM قبلا" وجود داشته است.این مرکز وظیفه تهیه ی اتصال CIDIN و احیانا" AFTN قراردادی و حمایت از اجرای  CIDIN  AFTN  برای کاربران ملی را بر عهده دارد.AMHS  به عنوان یک سیستم عملی الحاقی موجود درمرکز COM معرفی می گردد.این مورد به اکثر مراکز COM در قلمرو EUR/NAT مربوط می شود.

.مرکز COM قبلا" وجود نداشته است و سرویس عملی مستقیمی با AMHS آغاز خواهد کرد.اگر چه در فرض ممکن است ولی در عمل چنین موردی در قلمرو EUR/NAT وجود ندارد.در مورد این حالت در نسخه ی موجود این شیوه بیش از این بحث نخواهد شد.

4.1.1.2:از موارد بالا به طور جدی قلمداد می گردد که این شیوه به معرفی سرویس AMHS عملی در یک مرکز COM شبکه بین المللی AFTN/CIDIN/AMHS مربوط می گردد.

 

 

4.1.2:شبکه ی AMHS  هدف:

4.1.2.1:شبکه ی AMHS  نهایی که این هدف شیوه رسیدن به آن است وقتی که به همه ی مراکز COM در قلمرو EUR/NAT متصل گردد خصوصیات زیر را دارا خواهد بود.

.یک شبکه AMHS  الحاقی خواهد بود متشکل از یک جزیره ی واحد AMHS که همه ی مراکز COM در آن ارتباط متقابل خواهند داشت.

.یک شبکه کاملا" مشبک است.یعنی یک رابط نوع به نوع در سطوح ارتباط  AMHS بین مراکز COM است.

4.1.3:اهداف کیفی:

اهداف پیشنهادی این شیوه به سه دسته ی اصلی تقسیم می گردند:

1)برای انتقال همه ی جریانات ابلاغی اتصال CIDIN به اتصال AMHS رابط CIDIN  در پایان انتقال به دست نمی آید.

2)برای انتقال جریانات کاربردی به رابط AMHS برای:

.آسان سازی تثبیت عملی(کم کردن تعداد تغییرات هر مرحله برای سهولت تحلیل نتایج)

.امکان بازگشت آسان در صورتی که کاملا" نیاز باشد.

3)محدود کردن تاثیر به مراکز  COM به جای آنهایی که فرایند برای آنها به کار گرفته می شود و کاهش حتی الامکان هماهنگی بین قلمرو ها ,در طول مدت انتقال .

4.1.4:شیوه کلی:

4.1.4.1:معرفی یک مرکز AMHS COM جدید به شبکه ی کاربردی AFTN/CIDIN/AMHS طی یک حالت دقیق انجام می گیرد.اصولا" فعال سازی یک ارتباط عملی AMHS پس از اتصال صحیح لایه های زیرین و تکمیل موفقیت آمیز تست عمل متقابل اتفاق می افتد.سپس انتقال تدریجی حمل و نقل AMHS و CIDINوAFTN به یک اتصال جدید انجام می گیرد.    

منبع : شاهین صادقی