---

Примітка. SMARM ігнорує всі помилки в одержаному MAPDU Користувач послуги повідомлення про зміну стану також може проігнорувати подібні помилки чи перервати спілкування внаслідок цих помилок.

У разі одержання примітива послуги індикації CMIS M-EVENTREPORT, який містить MAPDU, що запитує послугу повідомлення про зміну стану, SMAPM має за умови правильно сформо­ваного MAPDU видати користувачу цієї послуги примітив індикації зміни стану, щоб повідомити користувачеві послуги, з параметрами, утвореними із сервісного примітива відповіді CMIS M-EVENT-REPORT.

В іншому разі SMAPM, діючи в режимі з підтвердженнями, має сформувати відповідний MAPDU, що містить повідомлення про помилку, і видати сервісний примітив відповіді CMIS M-EVENT-REPORT з параметром «помилка». У режимі без підтвердження процедуру 11.1.2.2 не використовують.

У режимі з підтвердженням SMAPM має прийняти примітив відповіді на повідомлення про зміну стану, сформувати MAPDU, що підтверджує повідомлення, й видати примітив відповіді CMIS M-EVENT-REPORT із параметрами, утвореними з примітива відповіді на повідомлення про зміну стану.

У цьому стандарті є посилання на такий об’єкт підтримання адміністративного керування, абстрактний синтаксис якого визначено в ССІТТ Rec. Х.721 | ISO/IEC 10165-2:

— запис зміни стану (StateChangeRecord).

У цьому стандарті є посилання на такі атрибути адміністративного керування, абстрактний синтаксис яких визначено в ССІТТ Rec. Х.721 | ISO/IEC 10165-2:

1. життєвий цикл (lifecycleState);

2. адміністративне керування (administrativeState);

3. аварійний статус (alarmstatus);

4. статус доступності (availabilitystatus);

є) статус керування (controlstatus);

6. робочий стан (OperationalState);

7. процедурний статус (proceduralStatus);

8. статус резервування (stancfbyStatus);

9. невідомий статус (unknownstatus);

10. стан використання (usageState).

У таблиці 3 показано відношення між параметрами, визначеними у 8.2, і специфікаціями типів атрибутів, визначеними в ССІТТ Rec. Х.721 | ISO/IEC 10165-2.

Таблиця 3 — Перетворення параметрів на атрибути

У цьому стандарті є посилання на наведену нижче групу атрибутів станів, абстрактний син­таксис якої визначено в ССІТТ Rec. Х.721 | ISO/IEC 10165-2:

— стан (state).

Жодні особливі дії не визначено в цьому стандарті.

У таблиці 4 ідентифіковано взаємини між сповіщеннями, визначеними у 8.1, і специфікаціями типів повідомлень, визначеними в ССІТТ Rec. Х.721 | ISOLIEC 10165-2.

Таблиця 4 — Повідомлення

У цьому стандарті надано таке значення ідентифікатору об’єкта:

{joint-iso-ccitt ms (9) Function (2) part2 (2) fimctionalUnitPackage (1)}.

Значення FimctionalUnitPackageld типу ASN.1 визначено в ССІТТ Rec. Х.701 | ISO/IEC 10040 та їх використовують для ведення переговорів щодо доступності подальшого функційного блоку:

0 — allEvents (усі події);

1. — control (керування);

2. — monitor (моніторинг);

З — objectEvents (події об’єкта), де номер ідентифікує бітову позицію, призначену функційному блоку, як визначено в розділі 10.

У рамках контексту застосування адміністративного керування систем механізм ведення пере­говорів щодо функційних блоків описано в ССІТТ Rec. Х.701 | ISO/IEC 10040.

Примітка. Вимоги до ведення переговорів щодо функційних блоків визначають за контекстом застосування.

12. ВІДНОШЕННЯ З ІНШИМИ ФУНКЦІЯМИ

Керування послугою повідомлення про зміну стану, визначену в цьому стандарті, забезпечують механізмами, установленими в ССІТТ Rec. Х.734 | ISO/IEC 10164-5. Послуга повідомлення про зміну стану може існувати незалежно від механізмів керування ССІТТ Rec. Х.734 | ISO/IEC 10164-5.

Якщо виконують операцію над атрибутом стану, цей стандарт використовує послуги PT-GET та PT-SET, які визначені в ССІТТ Rec. Х.730 | ISO/IEC 10164-1.

12. ВІДПОВІДНІСТЬ

Реалізації, які декларують відповідність цьому стандарту, мають підпорядковуватися вимогам відповідності, визначеним у наведених нижче підрозділах.

Реалізації мають підпорядковуватися вимогам цього стандарту до ролі адміністратора, ролі агента й обох ролей одночасно. Вимогу щодо відповідності хоча б до однієї ролі розглянуто в та­блиці А.1.

Якщо вимогу щодо відповідності зроблено для підтримання ролі адміністратора, реалізація має підтримувати хоча б одне оповіщення або одну з операцій адміністративного керування, опи­сану в цьому стандарті. Умови відповідності до ролі адміністратора для цих операцій адміністра­тивного керування та оповіщення описано в таблиці А.З та подальших таблицях додатка А.

Якщо вимогу щодо відповідності зроблено для підтримання ролі агента, реалізація має під­тримувати хоча б один з атрибутів, групу атрибутів, сповіщення, описаних у таблиці А.4. Умови відповідності до ролі агента описано в додатку А та подальших таблицях додатка А.

Реалізація має підтримувати синтаксис передавання, базованого на правилах кодування, описаних в ССІТТ Rec. Х.209 | ISO/IEC 8825, що називаються

{joint-iso-ccitt asnl(l) basicEncoding(l)},
для абстрактних типів даних, що посилаються на ті визначення, для яких заявлено підтримання.

Примітка. У цьому стандарті ідентифіковано загальні та залежні класи відповідності. Вимогу щодо відповідності, подібну до класу загальної відповідності, може бути зроблено через заяву про підтримання ролі адміністратора, ролі агента чи обох ролей одночасно для функційного блоку подій об'єкта в таблиці А.2.

Вимогу щодо відповідності, подібну до класу залежної відповідності, може бути зроблено через заяву про підтримання хоча б одного з елементів таблиці А.З чи А.4.

Реалізація, що претендує на підтримання цього стандарту, має підтримувати елементи про­цедури та визначення семантики, відповідні до тих визначень, для яких декларується підтримання.

Усі проформи MCS, проформи MICS та проформи MOCS, які відповідають цьому стандар­ту, мають бути технічно ідентичними проформам, описаним у додатках А, В та С, зберігаючи нумерацію таблиць та індексні номери елементів, та відрізнятися тільки розділенням на сторінки та заголовками сторінок.

Постачальник реалізації, який декларує відповідність цьому стандарту, має комплектувати копію резюме відповідності адміністративного керування (MCS), наведену в додатку А як частину вимог відповідності разом із проформами ICS, на які посилаються як на відповідні до MCS. В ICS, що відповідають цьому стандарту:

• має бути описано реалізації, які відповідають цьому стандарту,

• має бути доповнено відповідно до інструкцій для комплектації, наведених в ITU-T Rec. Х.724 | OSI/ISO 10165-6;

• внесено інформацію, необхідну для унікальної ідентифікації як розробника (постачальника), так і реалізації.

Вимоги відповідності до інформації адміністративного керування, визначені в цьому стандарті у класах об’єкта адміністративного керування, визначені ще де-небудь, мають містити вимоги про­форми MIDS, як визначено в додатку D, у MOCS для класу об’єкта адміністративного керування.

ДОДАТОК A
(довідковий)

ПРОФОРМА MCS³

А.1 Вступ

А. 1.1 Призначення та структура

Резюме відповідності адміністративного керування (MCS) є заявою постачальника, яка іден­тифікує реалізацію та забезпечує інформацію щодо того, чи може реалізація декларувати відпо­відність до будь-якого з множини перерахованих документів, які специфікують відповідність вимог до адміністративного керування OSI.

Проформа MCS — це документ у формі анкети, який після заповнення постачальником роз­робки стає MCS.

А.1.2 Інструкції щодо заповнення проформи MCS для створення MCS

Постачальник розробки має ввести точне твердження в кожному з розділів анкети. Спеціальні інструкції містяться в тексті, що передує кожній із таблиць.

А.1.3 Символи, абревіатури та терміни

Для всіх додатків цього стандарту для колонки «Статус» використовують такі загальні познаки, визначені в CCITT Rec. Х.291 | ISO/1EC 9646-2 та ITU-T Rec. Х.296 | ISO/IEC 9646-7:

m —■ обов’язковий (Mandatory);

о — необов’язковий (Optional);

с — умовний (Conditional);

х — заборонений (Prohibited);

не використовують або поза областю дії (Not applicable or out of scope).

Примітка 1. «с» може передувати «с», «гл» та «о» в разі вкладеності умовних та необов'язкових елементів в одній таблиці;

Примітка 2. «о» може продовжуватися «N» (де N — унікальний номер) для опцій, які може бути вибрано з множини значень стану. Обов’язковою е підтримання хоча б одного з варіантів вибору (з елементів з такими самими значеннями N).

Значення «т» колонки «Статус» для параметрів, що одержують, для таблиць типу MCS додатка А вказує, що це — мінімальні вимоги до реалізації, здатної одержувати параметр. Колонку «Додаткова інформація» можна використовувати для вказівки, що реалізація забезпечує щось більше за мінімальні вимоги.

Для всіх додатків цього стандарту для колонки «Статус» використовують наведені нижче загальні познаки, визначені в CCITT Rec. Х.291 | ISO/IEC 9646-2 та ITU-T Rec. Х.296 | ISO/IEC 9646-7:

Y — реалізовано;

N — не реалізовано;

відповідь не потрібна;

Ід — елемент ігнорується (тобто обробляється тільки синтаксично, але не семантично).

А.1.4 Формат таблиці

Деякі з таблиць цього стандарту займають більше ніж одну сторінку. У таких випадках у про­довженні таблиць у перших комірках використовують нумерацію колонок таблиць. Повну таблицю представлено з частин за таким правилом:

У цьому стандарті складові частини таблиць з'являються послідовно, починаючи з перших блоків колонок.Якщо таблиця з підрядками надто широка для того, щоб уміститися на одній сторінці, продо­вження таблиці має бути побудовано за допомогою індексних номерів, ідентичних для індексних номерів у відповідних рядках першої таблиці та з підіндексними номерами відповідних підрядків у кожному проіндексному рядку. Наприклад, якщо таблиця Х.І має 2 рядки та продовження табли­ці Х.І має 2 підрядки для кожного рядка, тоді таблицю представляють так:

Таблиця Х.1 — Заголовок

Таблиця Х.1 (продовження) — Заголовок

Повна таблиця складається з окремих частин відповідно до такого плану: