2003
Poznañskie Warsztaty TelekomunikacyjnePoznañ 11-12 grudnia 2003
Krzysztof M.Brzeziński
Instytut Telekomunikacji Politechniki Warszawskiej ul.Nowowiejska 15/19
00-665 Warszawa
e-mail: kb@tele.pw.edu.pl
METODYKA TWORZENIA I ZAPISU WYMAGAŃ OPERATORA
DLA IMPLEMENTACJI PROTOKOŁU TELEKOMUNIKACYJNEGO
Streszczenie: Rozważa się problem skutecznego zadawaniai korzystania z wymagań technicznych dla implementacji protokołów telekomunikacyjnych w kontekście działań Operatora telekomunikacyjnego. Rozważono niedostatki dotychczasowej praktyki w tym zakresie. Zaproponowano nowy, sformalizowany sposób tworzenia i zapisu takich wymagań. Opisano doświadczenia płynące z zastosowania tej notacji do protokołu ISUPv2.
1. WPROWADZENIE
Sieci telekomunikacyjne są systemami rozproszonymi, w których działaniu szczególną rolę pełnią, z definicji, protokoły sygnalizacyjne. Protokoły te sprawiają, że zbiór rozproszonych, autonomicznych węzłów może uczestniczyć w realizacji usług w sposób skoordynowany, poprawny i efektywny.
W telekomunikacji uznawanej za "tradycyjną" (w sieciach zintegrowanych PSTN/ISDN, w sieciach inteligentnych, w rozwiązaniach dla przenośności numeru i naliczania opłaty, itd.), protokoły są przedmiotem międzynarodowych dokumentów standaryzacyjnych (Zaleceń ITU-T i standardów ETSI). Dokumenty te zawierają specyfikację protokołu traktowanego jako obiekt abstrakcyjny, a dokładniej -specyfikację zachowania jednostek (stron) tego protokołu. Abstrakcyjną specyfikację zachowania następnie się implementuje. Żąda się przy tym, by zachowanie tak wytworzonej implementacji było zgodne z zachowaniem wyrażonym w specyfikacji (co się bada z wykorzystaniem testów zgodności - conformance) oraz by różne implementacje były faktycznie zdolne do skutecznego współdziałania (co się bada z wykorzystaniem testów współpracy - interoperability). Są to postulaty, których spełnienie można konkluzywnie stwierdzić jedynie post factum, w wyniku badania już wytworzonych implementacji.
Przemysłowe środowisko rzeczywistego operatora sieci telekomunikacyjnej ma swoją specyfikę, której nie w pełni odpowiada przedstawiony wcześniej schemat przejścia od specyfikacji ku uruchomionej (wdrożonej) implementacji. Punkt krytyczny faktycznego procesu dotyczy formułowania dodatkowych wymagań względem implementacji protokołu, na etapie przygotowania zapytania ofertowego i podczas
negocjacji w sprawie dostawy sprzętu dla sieci. Operator ma prawo kształtować funkcje i sposób działania central (i innych węzłów pracujących w jego sieci) zgodnie z własną strategią rozwojową i marketingową. Stosowanie szczególnej, operatorskiej wersji protokołu sygnalizacyjnego jest jednym z mechanizmów realizacji strategii wyróżnienia się na konkurencyjnym, deregulowanym rynku telekomunikacyjnym. Ta refleksja ma szczególne zastosowanie do protokołów bardzo złożonych, o charakterze platformy realizacji usług. Przykładem takiego protokołu jest ISUP (Integrated Services User Part), stanowiący funkcjonalną część Systemu Sygnalizacji Nr 7.
Można argumentować, że sama specyfikacja protokołu pośrednio zawiera wymagania w stosunku do implementacji. Jednakże spełnienie wszystkich takich wymagań nie gwarantuje uzyskania implementacji spójnej ani odpowiadającej oczekiwaniom Operatora. Konieczne są dodatkowe wymagania, które byłyby w stanie szczegółowo i skutecznie wpływać na kształt implementacji, zgodnie z potrzebami Operatora.
Poza własnymi wstępnymi próbami [1,2], w literaturze nie odnaleziono wcześniejszych prac, które by skupiały się na aspekcie formalizacji wymagań Operatora. Raportowane tu prace nad opracowaniem metodyki formułowania wymagań Operatora spełniających wyżej wskazane postulaty prowadzono na przykładzie protokołu ISUP. Do tego przypadku odnoszą się analizy zawarte dalej. Natomiast efekt tych prac wydaje się wystarczająco ogólny, by skutecznie wspierać działania Operatora związane także z innymi, złożonymi protokołami sygnalizacyjnymi.
2. TRADYCYJNA PRAKTYKA FORMUŁOWANIA WYMAGAŃ
Wymagania dla implementacji protokołów sygnalizacyjnych (inne, niż zawierające jedynie żądanie implementacji "zgodnej z treścią norm międzynarodowych") były formułowane już wcześniej. Wśród takich wymagań występują wymagania krajowe WTE (Wymagania Techniczno-Eksploatacyjne, obowiązujące także poszczególnych operatorów) oraz wymagania WTO (Wymaga Techniczne Operatora).
We wcześniej opracowywanych w kraju dokumentach WTE i WTO formułowano wymagania w sposób beletrystyczny, np.:
(a) "Wiadomość aaa powinna być nadawana tylko wtedy, gdy numer bbb nie został odebrany oraz gdy kategoria ccc nie została ustawiona na "ddd" lub też gdy we wskaźnikach eee wskaźnik pochodzenia wywołania nie jest ustawiony na fff". W tego typu zdaniu przeplata się właściwe wymaganie w stosunku do implementacji ("powinna być nadana...", czyli "implementacja powinna nadać...") z definicją/specyfikacją określonego fragmentu protokołu. Zapis sugeruje, że na implementację nakłada się bardzo złożone i zawikłane wymaganie. Jak w takim przypadku dostawca sprzętu ma zadeklarować fakt spełnienia tego wymagania? Co oznaczałaby deklaracja "zgodny" (compliant)" bądź Y (tak) / N (nie) / P (partly - częściowo zgodny)?
(b) "Tablicę aaa należy uzupełnić następująco: w wierszu xxx w miejsce (Uwaga) wpisać 50 (dotyczy numeru tablicy odniesienia). Do punktu yyy dodać poniższe podpunkty...". W ten sposób modyfikuje się dokument odniesienia (treść standardu). Tymczasem samo istnienie standardu (oryginalnego bądź zmodyfikowanego) nie nakłada żadnych wymagań na implementację. W tym przypadku wymaganie postawione jest niejawnie: sugeruje się, że implementacja ma zawierać zdolność do obsługi wprowadzonego elementu. Nie ma jednak powodu, by w dokumencie wymagań, służącym do jawnego stawiania wymagań, stawiać je niejawnie.
(c) "Należy przyjąć zasadę, że wszystkie wymagania określone jako "international" (międzynarodowe) powinny być traktowane jako "national" (krajowe) i powinny obowiązywać w polskiej sieci krajowej." [3]. Zapis nie informuje, czy przyjęto tę zasadę, czy też jedynie postuluje się jej przyszłe przyjęcie. Jeśliby zasadę przyjęto, to z zapisu nie wynika, czy wówczas wymagania byłyby traktowane jako "national", czy w dalszym ciągu byłoby to kwestią rozważań (a przed przyjęciem bardziej stanowczego określenia - przedmiotem dowolności interpretacyjnej). Każdy z tych i podobnych zapisów jest nieformalny i pozostawia pole dla sporów interpretacyjnych. Poszukuje się zatem innej, sformalizowanej formuły zapisu, lecz zarazem na tyle elastycznej, by mogła zostać zaakceptowana w działaniach służb Operatora.
3. WCZEŚNIEJSZE PRACE WŁASNE NAD ZAPISEM WYMAGAŃ
We wcześniejszych pracach własnych zastosowano odpowiednio rozwiniętą metodykę wprowadzoną przez ISO 9646 do celów testowania zgodności. W szczególności, jako kluczowy element formułowania wymagań potraktowano rozróżnianie:
definicji protokołu i jego elementów (własności); wymagania, rozumianego jako wyrażenie konieczności / możliwości / zakazu wprowadzenia danej własności do implementacji.
Samo wymaganie jest wyrażone bardzo zwięźle, przez podanie statusu własności:
M (Mandatory): implementacja wymagana; O (Optional): impl. dozwolona, opcjonalna; O.i: opcja kwalifikowana (np. "jeden z kilku.."); X (eXcluded): implementacja zabroniona; NR (Not Required): cecha nie wymagana, nie formułuje się wymagania.
Ustosunkowanie się do tak postawionego wymagania (np. przez Dostawcę) także może być bardzo zwięzłe (zaimplementowano: TAK, NIE). Natomiast to, czego się w istocie wymaga (jakiego zachowania, w jakich warunkiach i okolicznościach) jest zawarte w definicji obiektu (elementu protokołu), w stosunku do którego formułuje się wymaganie. Ten zapis może być dowolnie złożony.
Drugim kluczowym elementem jest odróżnianie: wymagań wynikających wprost z treści standardu
-wymagań integralnych;
wymagań stawianych np.przez Regulatora (WTE) i Operatora (WTO) - wymagań zewnętrznych. Zgodnie z ogólną metodyką przyjętą przez ITU-T i ETSI, w standardach identyfikuje się własności protokołu i wylicza się je w tabeli, wraz z przydzielonym im statusem wymagania integralnego. Taki dokument (PICS, Protocol Implementation Conformance Statement) może stanowić podstawę do sporządzenia wymagań zewnętrznych. Te wymagania przybierają wówczas postać tabeli zawierającej identyfikację cechy, jej status integralny i status
zmodyfikowany, stanowiący właściwe wymaganie zewnętrzne. Żąda się przy tym, by wprowadzane
modyfikacje nie wymuszały niezgodności z wymaganiami "wyższego rzędu". Pragmatyczne uszeregowanie "wagi" wymagań jest następujące: (1)wymagania integralne, zawarte w normach; (2) wymagania zewnętrzne - regulacyjne; (3) wymagania zewnętrzne - Operatora. Dopuszczalne, formalnie poprawne (niesprzeczne) modyfikacje statusu są następujące: (M>M), (M>NR), (O>M), (O>X), (O>O), (O>NR), (X>X), (X>NR).
Jeśli wymagania zewnętrzne miałyby odnosić się do cechy nie występującej w standardzie, wówczas należałoby zidentyfikować taką cechę i przydzielić jej status w nowym, uzupełniającym, "zastępczym" formularzu ICS wprowadzonym do dokumentu Wymagań.
Opisywana tu metodyka została z powodzeniem zastosowana do sformułowania wymagań dla implementacji protokołów DSS1 i INAP. Zbudowano także narzędzie komputerowe, wspomagające tworzenie i stosowanie wymagań w takiej formie [2]. Jednakże dla protokołu ISUP metodyka ta okazała się zbyt ograniczona i "sztywna". Podstawową tego przyczyną jest niewielka liczba własności zidentyfikowanych w standardowych formularzach PICS dla tego protokołu oraz tak duży stopień ogólności tych własności, że przestają one być skuteczne przy wyrażaniu potrzeb Operatora.
4. WZORCE ZAGRANICZNE
Wymagania Operatora dla rozważanego tu protokołu ISUP były także tworzone przez operatorów zagranicznych. Można zidentyfikować następujące charakterystyczne wzorce dla sposobu formułowania takich Wymagań:
(a) Tekst integralny: przytoczona treść standardów (dla ISUP: zwykle Q.763 i Q.764), z adnotacjami: zmianami względem standardu oraz modyfikacjami: dodatkowymi klauzulami krajowymi.
(b) Delta-dokument: zapis różnicowy, w którym przytacza się nagłówki rozdziałów standardu (wszystkich bądź jedynie wysokiego poziomu), z adnotacjami. W razie braku zmian - wyraźna adnotacja Noted, Applicable itp. W razie wprowadzenia zmian - występuje stwierdzenie w rodzaju: Applicable with exceptions indicated in Annex.... Dla wzmocnienia różnicowego charakteru dokumentu, nagłówki mogą zostać przytoczone w cudzysłowiu, np. jako: Application of section xxx: Exceptions and clarifications for...
(c) Delta-dokument, w którym występują jedynie
informacje o zmianach, zwykle w tabeli. W razie braku
odniesienia do rozdziału, przyjmuje się, że jego treść zostaje przyjęta bez zmian - "Where no reference is given the procedures specified in Q.xxx apply"
(d) Postać tabelaryczna - pochodna dokumentów PICS; identyfikuje się funkcjonalności protokołu oraz nadaje się im pożądany status implementacyjny. Samo zastosowanie postaci tabelarycznej absolutnie nie oznacza, że rozwiązano problem formalizacji i jednoznaczności określania cech protokołu. Przeciwnie, tak identyfikowane elementy protokołu z reguły nie pozwalają na sensowne opatrywanie ich statusem.
5. PROPONOWANA KONCEPCJA WYMAGAŃ
Na podstawie analizy niedostatków dotychczasowej praktyki formułowania wymagań implementacyjnych opracowano nową koncepcję formuły zapisu i sposobu wykorzystania Wymagań Operatora i wypróbowano ją w praktyce dla przypadku protokołu ISUP (konkretnie -ISUP v2). Przyjęto tezę, że dla sformułowania WTO należy:
(a) zidentyfikować własności sygnalizacji ISUP; (b) przypisać im status implementacyjny w danej sieci.
Kluczowe dla projektu WTO jest zidentyfikowanie: (a) wszystkich własności, o których należy postanowić (WTO powinny być kompletne i nie pozostawiać bez rozstrzygnięcia tych zagadnień, których kształt jest dla Operatora merytorycznie istotny);
(b) tylko takich własności, które są niezbędne do skutecznego wskazania pożądanego profilu sygnalizacji i uzyskania jednoznacznej informacji o jego realizacji. W szczególności, WTO powinny być rozsądnie zwięzłe (granica "rozsądnej" liczby punktów-własności jest rzędu 1000). W przypadku, gdy pozostawia się zaimplementowanie własności do decyzji producenta (bądź ogólniej - gdy nie dokonuje się zmiany statusu
implementacyjnego względem standardu), nie będzie celowe usuwanie takiej własności z treści Wymagań. Jawne wskazanie statusu implementacyjnego jest pożądane choćby w zastosowaniu WTO do celów dokumentacyjnych. Ponadto umożliwia późniejsze modyfikacje Wymagań, przez zmianę tego statusu.
Dla zaproponowanej formuły zapisu WTO kluczowe znaczenie ma zatem zidentyfikowanie i wyliczenie odpowiednich własności. Przydzielenie tym własnościom statusu implementacyjnego jest zadaniem także istotnym, ale rutynowym, dokonywanym przy każdej późniejszej modyfikacji Wymagań. Poszukuje się takich własności, co do których możnaby:
(a) zwięźle wskazać, o jaką własność chodzi; (b) skutecznie i jasno postawić wymaganie, to jest wskazać, czy żąda się implementacji własności w urządzeniach sieci oraz jakiej klasy urządzeń wymaganie dotyczy (identyfikacja roli węzła);
(c) uzyskać od dostawcy sensowną i jednoznaczną deklarację realizacji danej własności.
Jeśli definicja zidentyfikowanej własności zawiera wiele wewnętrznych opcji realizacyjnych, bądź jeśli tę własność można stosować w wielu różnych, nie związanych ze sobą okolicznościach, wówczas własność jest zapewne zdefiniowana zbyt ogólnie i należałoby ją "rozbić" na kilka własności o lepiej zdefiniowanym zakresie. Z drugiej strony jest często spotykane, że Dostawca zgłasza do swej deklaracji uwagi, wyjaśnienia i zastrzeżenia. Można z tego wnioskować, że własność jest złożona i w istocie składa się z szeregu pod-własności, które dają się rozpatrywać oddzielnie.
Źródeł dla formułowania własności protokołu ISUP do zamieszczenia w WTO można poszukiwać:
(Z1) bezpośrednio w tekście standardów bazowych; (Z2) w zestawieniach i tabelach, pomocniczo
zamieszczanych w standardach; (Z3) w dokumentach PICS;
(Z4) w dokumentach TSS&TP (testy).
Główne dokumenty należące do tak zdefiniowanych klas zidentyfikowano w Tabeli 1, z rozbiciem na ISUPv2 i ISUPv3 oraz na usługi (U): podstawowej obsługi wywołań/utrzymania (P) i usługi dodatkowe (D).
Tabela 1. Źródła własności protokołu ISUP
Z U ISUP2 ISUP3 1 P Q.761-Q.764'93 ETS 300 356-1(95) Q.761-764'97 EN 300 356-1(98) D Q.730-737 (ISUP'93) ETS 300 356-2..30 Q.730-737 (ISUP'97) EN 300 356-2..30 2 P,D Tab.1/Q.761'93 Tab.1/Q.761'97 3 P Q.784.2 (97) Annex A ETS 300 356-31 (98) EN 300 356-31 (00) D ETS 300 356-34 (98) EN 300 356-34 (00) 4 P Q.784.2 (97) rozdz. 6 i 7 ETS 300 356-32 EN 300 356-32 (00) D ETS 300 356-35 (98) EN 300 356-35 (00)
Własności w tekście standardu. Można uznać, że
każdy rozdział / punkt standardu zawiera definicję pewnej własności. Jednakże tak definiowane własności są najczęściej złożone, uwikłane. Generalnie nie nadają się do zadawania prostych pytań ("czy zaimplementowano?") i oczekiwania prostych i jednoznacznych odpowiedzi ("Tak / Nie"). Ewentualne dokonywanie modyfikacji w tekście danego punktu standardu w żaden sposób nie zmienia tej sytuacji. Przeszkodą najistotniejszą jest to, że tekst standardu w praktyce nie definiuje hierarchicznej struktury powiązanych ze sobą własności. Najczęściej, różne przejawy tej samej własności są definiowane w różnych (często odległych od siebie) punktach standardów.
Standardowe listy własności. Listy własności, o
których tu mowa, są rutynowo wykorzystywane do porównania własności różnych implementacji i istnieje silna pokusa, by je wykorzystać do zadawania własności wymaganych. Jest to praktyka dość niebezpieczna, gdyż na listach figurują jedynie hasła - generalnie nie są to własności, których zaimplementowanie można jednoznacznie zadeklarować. Na przykład, lista własności ISUP v3 zawarta w Tab.2/EN 300 356-1 (98) jest nadzbiorem funkcjonalności wyszczególnionych w ETS 300 356-1 (95) dla ISUPv2. Jednakże nadzbiór ten nie ma uzasadnienia merytorycznego - lista powstała głównie w wyniku staranniejszego zidentyfikowania i nazwania funkcjonalności istniejących już w wersji ISUPv2, więc można sobie wyobrazić jeszcze
staranniejsze i bardziej szczegółowe wyliczenie. Warto
też zauważyć, że zawartość formularzy PICS dla protokołu znacznie się różni od zawartości tej listy.
Własności w dokumentach PICS. Punkty
dokumentu PICS są formułowane z myślą o skutecznym wyborze testów. Nie można liczyć na to, że struktura zapisów w formularzu PICS będzie odpowiadać strukturze powiązań między poszczególnymi własnościami wyrażonymi w specyfikacji. Struktura zapisów PICS jest najczęściej płaska (lista kolejnych punktów). Lista ta jest zwykle podzielona na tabele, grupujące własności właściwe dla poszczególnych rodzajów urządzeń (central) - identyfikuje się role urządzeń, a przedmiotem konkretnego, wypełnionego formularza PICS jest urządzenie pełniące wskazaną rolę. Z pierwotnym przeznaczeniem dokumentów PICS jest związany sposób formułowania punktów jako pytań (skierowanych do dostawcy). Wymagania mają inną postać: są formułowane jako zdania oznajmujące, uzupełnione o status implementacyjny.
Własności w dokumentach TSS&TP. Dokument
TSS&TP (Test Suite Structure and Test Purposes) ma na celu zidentyfikowanie wszystkich fragmentów protokołu, których implementację w rzeczywistym urządzeniu należałoby przetestować, aby właściwie ocenić poprawność implementacji. Dla każdego takiego fragmentu formułuje się cel testu, który zawiera w sobie wskazanie (często ogólnikowe) oczekiwanego, pożądanego zachowania. W praktyce, zidentyfikowanie wszystkich niezbędnych celów testów nie jest realne.
Dlatego dokument TSS&TP można oceniać pod kątem
pokrycia (stopnia uwzględnia własności protokołu).
Dokument TSS&TP zawiera dwie części, obie istotne z punktu widzenia wyboru własności dla WTO:
(a) struktura zestawu testów, identyfikująca grupy własności i wskazująca ich hierarchiczne powiązania. Nie wszystkie powiązania zostają w ten sposób zidentyfikowane, ale jest to wielki postęp w stosunku do praktycznie pozbawionego struktury tekstu standardu bazowego. Zidentyfikowane tu powiązania i grupy własności mają charakter merytoryczny.
(b) zbiór celów testów. Liczba celów testów sformułowanych dla "jednej" własności (to jest np. odwołujących się do tego samego punktu w specyfikacji bazowej bądź powołujących się na ten sam punkt w dokumencie PICS) jest znamienna. Duża liczba celów wskazuje, że własność jest w istocie złożona.
Cele testów można przekształcić w wymagania (wywieść) w następujący sposób:
(a) Oryginalne sformułowanie celu testu:
"To verify that if ...x... then ...y... will be omitted." (b) Wymaganie wywiedzione, sformułowane tradycyjnie:
"Wymaga się, by w sytuacji x opuszczono y". (c) Wymaganie wywiedzione, sformułowane zgodnie z proponowaną formułą WTO:
definicja: "W sytuacji x zostaje opuszczone y". status implementacyjny: M
6. PROPONOWANA FORMUŁA ZAPISU WTO
Posiłkując się wnioskami z analiz przedstawionych wyżej, zidentyfikowano przestrzeń wzajemnie powiązanych własności protokołu ISUP, liczącą ok. tysiąca własności. Dla ich efektywnego zapisu i późniejszego sprawnego przetwarzania zaproponowano pół-formalną formułę zapisu (rys.1), umożliwiającą zachowanie zależności hierarchicznych i niehierarchicznych (lateralnych) pomiędzy własnościami oraz zachowanie związków tych własności z dokumentami standaryzacyjnymi (definicją protokołu, zawartością dokumentów PICS i TSS&TP). Ponadto, ze względów pragmatycznych, w proponowanej formule zapisu uwzględniono potrzebę zamieszczania fragmentów specyfikacji protokołu (specyficznych dla Operatora) w notacji "swobodnej", np. tekstowej. Mały fragment treści opracowanych Wymagań pokazano dla przykładu na rys.2.
Obszar właściwych wymagań (R) ma postać tabeli z kolumnami oznaczonymi na rys.1 jako A--K.
Generalną zasadą jest, że każdy wiersz tej tabeli zawiera zwięzłą identyfikację konkretnej własności protokołu ISUP oraz wymaganie co do implementacji tej własności w danej sieci (wyrażone poprzez nadanie tej własności konkretnego statusu implementacyjnego
-REQ). Dla uniknięcia niespójności bądź wątpliwości
interpretacyjnych, do identyfikowania własności protokołu używa się wyłącznie języka angielskiego.
A B C D E F G H I J K (R): Id Capability Links Ref Stat Cond REQ USE Op. notes SUP Sup. notes
(S): (N):
Operator-specific features Notes S1.
S2...
N1/0 N1.1/1...
Rys.1 Struktura zapisów WTO
Obszar specyfikacji (S) zawiera definicje
własności sygnalizacyjnych specyficznych dla Operatora. Zasadą jest, że definicję własności umieszcza się w obszarze (S) wtedy, gdy jest to własność nie występująca w standardach źródłowych bądź gdy zawarcie jej opisu bezpośrednio w wierszu tabeli wymagań jest utrudnione. Definicje są formułowane w sposób narracyjny, z elementami pół-formalnymi (np. tabela dla struktury parametru).
Obszar not (N) zawiera dodatkowe wyjaśnienia.
Wyjaśnienia są formułowane w sposób narracyjny. Kolumny tabeli Wymagań (R) mają przeznaczenie opisane poniżej:
(A) Id (Identifier, Identyfikator). Identyfikator punktu-wiersza Wymagań, jednoznacznie wskazujący własność, o której chce się postanowić. Własności są numerowane (identyfikowane) w sposób hierarchiczny. Na przykład, własności oznaczone identyfikatorem 2.4.1 i 2.4.2 są własnościami składowymi (podrzędnymi) własności oznaczonej identyfikatorem 2.4. Własność może zostać wskazana (powołana) w kolumnie C (Links) bądź F (Cond), przez zamieszczenie identyfikatora tej własności.
(B) Capability (Własność). Nazwa własności (cechy), zawierająca jej zwięzłą charakterystykę. Nazwa własności z reguły nie zawiera w sobie pełnej definicji tej własności. Jest wówczas niezbędne zamieszczenie (w kolumnie D - Ref.) odniesienia do definicji własności, zamieszczonej w dokumentach źródłowych bądź w obszarze (S) Wymagań.
(C) Links (Powiązania). Pole zawiera
identyfikator(y) własności, z którą dana własność jest powiązana (np. ^2.4.1). Ten element nie ma żadnego
odpowiednika we wcześniej formułowanych wymaganiach. W jednym polu powiązań można
zamieścić identyfikatory wielu takich własności. Charakter powiązania własności nie jest jawnie wskazywany, lecz wynika z charakteru samej własności. Z reguły, w polu Links wskazuje się własność Y, z której dana własność X korzysta. Ta reguła została w WTO zastosowana m.in. w przypadku elementów statycznych protokołu: wiersze dotyczące poszczególnych wiadomości / parametrów ISUP nie zawierają powiązań (links) z procedurami je wykorzystującymi, lecz wiersze dotyczące tych procedur zawierają powiązanie wskazujące na wykorzystywane elementy statyczne. Na przykład, aby odszukać
wymagania związane z procedurami wykorzystującymi parametr Redirecting number, należy odszukać wiersze Wymagań zawierające w polu Links wskazanie: ^6.2.64. (D) Ref (References, Odniesienia). Pole zawiera identyfikację (wskazanie dokumentu, rozdziału, punktu) zapisu związanego z daną własnością. Na przykład, jedna własność może jednocześnie odwoływać się do: punktu standardu źródłowego, punktu w standardowym formularzu PICS, celu bądź celów testów w dokumencie TSS&TP oraz punktu w obszarze (S), zawierającego np. uszczegółowienie i rozwinięcie odnośnych zapisów standardu źródłowego.
(E) Stat (Status, Status standardowy). Pole zawiera status implementacyjny danej własności, wynikający z treści standardów źródłowych i niezależny od woli i potrzeb Operatora. Zamieszczenie statusu standardowego nie zawsze jest praktyczne i możliwe. Należy to czynić, gdy status własności zawartej w standardzie jest całkowicie jasny i wyrażony w samym standardzie (zwykle - w tomie formularza PICS). Jeśli status standardowy zostanie zamieszczony, wówczas może służyć do sprawdzenia, czy wymaganie Operatora nie wprowadza formalnej niezgodności z wymaganiem integralnym oraz do syntetycznej oceny charakteru (specyfiki, kierunku) zapisów WTO.
(F) Cond (Condition, Warunek) Pole zawiera warunek sterujący wymaganiem zamieszczonym w polu (G). Warunek jest wyrażeniem logicznym, operującym na składnikach mogących przybierać wartości "Y" (1) lub "N" (0). Przy zapisie warunku stosuje się standardowe operatory logiczne: and, or, not. Po wykonaniu wskazanych operacji logicznych, warunek przyjmuje wartość "Y" (1) lub "N" (0). Składniki, na których operuje warunek, są wartościami wskazanych pól (J) - SUP. Jeśli wartość warunku wynosi "Y", wówczas ma zastosowanie wymaganie wskazane na pierwszej pozycji pola (G). Jeśli wartość warunku wynosi "N", wówczas ma zastosowanie wymaganie alternatywne, wskazane w polu (G) po słowie "else" (lub "n/a", jeśli wymagania alternatywnego nie wskazano).
(G) REQ (Requirement, wymaganie Operatora). Wymaganie dotyczy konieczności / możliwości / zakazu implementacji danej własności w sieci Operatora. Wymaganie jest zwięźle wyrażane przez podanie jednej ze zdefiniowanych wartości statusu.
(H) USE (wskazanie zastosowania w danej sieci). Pole pomocnicze, używane do wewnętrznych celów
Operatora, podające informację o zastosowaniu danej własności w sieci Operatora. Stosowanie własności nie j e s t r ó w n o z n a c z n e z w y m a g a n i e m j e j zaimplementowania. Na przykład, kombinacja: REQ = "M", USE = "N" oznacza, że wymaga się implementacji danej własności w urządzeniach sieci (z myślą o przyszłym zastosowaniu), lecz własność ta pozostaje niewykorzystana - "uśpiona".
(I) Op.notes (nota Operatora). To pole może zawierać krótki tekst wyjaśniający bądź powołanie na dłuższą notę, zamieszczoną w obszarze not (N).
(J) SUP (Support, deklaracja zaimplementowania). Pole wypełniane przez deklarującego faktyczny stan implementacji: Y (zaimplementowano), N (nie zaimplementowano), bądź P (partly - z uwagami).
(K) Sup.notes (Uwagi Dostawcy). W tym polu Dostawca wypełniający formularz Wymagań wskazuje własne uwagi.
Ponadto opracowano szereg zasad zapisu i grupowania poszczególnych własności. Dla przykładu:
(a) Numeracja własności pozwala na tworzenie, w ramach tabeli, hierarchicznej struktury rozdziałów i podrozdziałów. Własności umieszczone w podrozdziałach są własnościami składowymi bądź podrzędnymi względem danej własności.
(b) Specjalny zabieg notacyjny (Req = "H", od: Header) pozwala na tworzenie nagłówków rozdziałów, w których zgrupowano własności powiązane ze sobą.
(c) Wprowadzenie "pseudo-własności" o charakterze parametrów pozwala na parametryzację Wymagań przez Operatora, zgodnie z ich bieżącym zastosowaniem, np. na wskazanie wyłącznie własności dotyczących central tranzytowych, a nie końcowych. Nie tylko pojedyncze własności, ale także całe rozdziały Wymagań mogą być wyłączane (uznawane za niebyłe) w zależności od wartości parametru podanego przez Operatora.
Opracowano także koncepcję wykorzystania Wymagań w działaniach projektowo/implementacyjnych Operatora (poza zakresem niniejszego artykułu).
7. PODSUMOWANIE
W artykule rozważono niedogodności związane z dotychczasową praktyką tworzenia wymagań dla implementacji protokołów sygnalizacyjnych (wymagań krajowych - regulacyjnych i wymagań Operatora). Na tej podstawie sformułowano alternatywną, sformalizowaną metodykę zapisu i stosowania takich wymagań. Tę metodykę zweryfikowano praktycznie, na przykładzie wymagań Operatora dla protokołu ISUP v2. W ramach tego projektu zbudowano przestrzeń "wszystkich", powiązanych ze sobą własności protokołu ISUP. Własności te zapisano w pół-formalnej notacji tabelarycznej. Jednym z postulowanych efektów zastosowania tej notacji jest możliwość tworzenia kolejnych wersji wymagań Operatora poprzez zmiany statusu implementacyjnego poszczególnych własności, bez konieczności kosztownego, czasochłonnego przygotowywania wymagań od podstaw.
Dalsze prace skupiają się na opracowaniu metodyki i narzędzi dla zautomatyzowanego wspomagania pracy z wymaganiami zapisanymi w nowej formule.
SPIS LITERATURY
[1] K.M.Brzeziński, "Towards formality of Technical Requirements for protocols", EWDC'98, Gdańsk, 1998
[2] R.Artych, K.M.Brzeziński, "External Conformance Requirements: concepts, methods and tools", IWTCS'99, Budapest, 1999
[3] Wymagania techniczne i eksploatacyjne dla cyfrowych systemów komutacyjnych dla polskiej sieci telekomunikacyjnej użytku publicznego. Załącznik nr 5 do Rozporządzenia MŁ z dnia 4 września 1997r
Id. Capability Links Ref Stat Cond REQ USE N1 SUP N2
2.4.2 Transit Network (Service Provider) Selection [A4]2.1.11 [B1]Tab.2
H
2.4.2.1 Ability to send and react (as appropriate) to selection information carried in:
H
2.4.2.1.1 -- additional address digits --- ANY M
2.4.2.1.2 -- Transit network selection parameter ^6.2.1.75 O ANY X
2.4.2.1.2.1 Allow a sequence of transit networks to be specified by repeating the Transit network selection parameter
O ^2.4.2.1.2 X
else n/a 2.4.2.2 Operator-configurable choice of a method to carry
selection information for a call (among the implemented methods)
ANY NR
2.4.2.3 Handle (generate and route according to) the transit network selection received from the access
[C31]A.4/5 O OLE M
2.4.2.4 Route according to the transit network selection [C31]A.10/1 O NTE M
