ZESZYTY NAUKOW E POLITECHNIKI ŚLĄSKIEJ Seria: ELEKTRONIKA z. 12
2000 Nr kol. 1492
Jerzy WOJTUSZEK
Politechnika Śląska, Instytut Elektroniki
WYKORZYSTANIE NOTACJI A SN .l DO KODOWANIA DANYCH SYGNALIZACYJNYCH W SIECIACH ISDN
Streszczenie. Scharakteryzowano abstrakcyjną syntaktykę A SN .l oraz reguły kodo
wania danych. Omówiono sposób określania struktury danych dla usług dodatkowych w sieciach ISDN. Przedstawiono przykład kodowania komponentu (jednostki danych proto- kołowych).
APPLICATION OF A S N .l NOTATION TO CODING OF SIGNALLING DATA IN ISDN NETWORKS
Summary. The ASN.l abstract syntax and rules o f data coding are characterized. The method o f defining structure o f data for supplementary services in ISDN networks is di
scussed. An example o f component (protocol data unit) encoding is presented.
1. Wprowadzenie
Realizacja protokołów telekomunikacyjnych polega na przesyłaniu bloków danych zwanych jednostkam i danych protokołowych (Protocol Data Unit - PDU). Ważnym elemen
tem specyfikacji każdego protokołu jest określenie struktury (formatu) poszczególnych PDU wykorzystywanych w tym protokole. W tradycyjnych metodach definiowania formatu PDU określa się zwykle znaczenie kolejnych oktetów lub bitów tworzących PDU. Używa się do tego celu rysunków podobnych do rys.l wspomaganych stosownym tekstem.
Pewną w adą tradycyjnych metod definiowania struktur PDU jest to, że jednocześnie definiowane są w nich typy danych tworzących PDU (np. liczby całkowite, łańcuchy znaków, itp.) oraz sposoby kodowania tych danych. W niektórych sytuacjach korzystne jest bowiem określanie budowy PDU jedynie na poziomie typów danych wchodzących w skład PDU (mogą to być typy o złożonej strukturze) bez określania sposobu kodowania tych danych
podczas przesyłania, czyli bez określania postaci transferowej danych. Potrzeba taka pojawia się np. podczas specyfikowania protokołów warstwy aplikacji [1]. Przyjmuje się wówczas, że postać transferowa danych zostanie wybrana jako jedna z wielu możliwych przez warstwę prezentacji na zasadzie dwustronnych negocjacji. Zasady kodowania danych na styku między warstwą aplikacji i prezentacji m ogą być wtedy zależne od specyfiki konkretnego systemu - m ogą się one różnić po stronie nadawczej i odbiorczej. Z przedstawionych rozważań wynika potrzeba poszukiwania nowej metody opisu formatu danych przesyłanych w sieciach teleko
munikacyjnych. Metoda taka powinna rozdzielać opis na poziomie typów danych i opis zasad kodowania.
Prezentacja struktury przesyłanych danych na poziomie typów danych nazywana jest abstrakcyjną syntaktyką (syntaktyka abstrahująca od kodowania). Najbardziej znaczącym przykładem takiej syntaktyki jest notacja ASN.l (Abstract Syntax Notation One) przedsta
wiona w standardzie X.208 [2]. Dla notacji tej opracowano standard X.209 [3], w którym przedstawiono sposoby kodowania poszczególnych typów danych. Zasady kodowania okre
ślone w standardzie X.209 należy traktować jako jedne z wielu możliwych dla notacji ASN.l Notacja A SN .l oraz reguły kodowania określone w standardzie X.209 znalazły zasto
sowanie m.in. w sieciach ISDN, gdzie wykorzystane są do opisu struktury danych sygnaliza
cyjnych związanych z realizacją tzw. usług dodatkowych (funkcja warstwy aplikacji). W chwili obecnej dla sieci ISDN zdefiniowano kilkanaście takich usług, a ich przykładami mo
gą być [4,5,6,12]:
- User-to-User Signalling (UUS) - przesyłanie danych między użytkownikami za pomocą wiadomości sygnalizacyjnych przesyłanych w kanale D (za darmo),
- Advice o f Charge (AOC) - informowanie użytkownika o taryfie dla zestawianego połącze
nia oraz przekazywanie informacji o opłacie - w trakcie trwania połączenia i po jego zakoń
czeniu,
- Completion o f Calls to Busy Subscriber (CCBS) - automatyczne zestawianie połączenia z wcześniej zajętym abonentem.
ISDN-owskie zasady opisu i kodowania danych związanych z usługami dodatkowymi przyjęte zostały w telefonii komórkowej GSM oraz w systemie łączności bezprzewodowej DECT. Zestaw usług dodatkowych oraz procedury ich realizacji są tam również wzorowane na sieciach ISDN.
Dla poszczególnych usług dodatkowych w sieci ISDN istnieją oddzielne standardy ETSI. Każdy z tych standardów zawiera rozdział, w którym za pomocą notacji ASN.l opisa
na jest struktura danych sygnalizacyjnych (sterujących) specyficznych dla danej usługi do
datkowej. Prawidłowa interpretacja tych opisów wymaga skojarzenia ze sobą kilku standar
dów CCITT (ITU) i ETSI pochodzących z różnych okresów (co najmniej standardy wymie
nione w spisie literatury). Standardy te nie zawsze w sposób jawny odwołują się do siebie (względnie odwołują się za pomocą notacji ASN. 1), co utrudnia ich studiowanie czytelnikom nie zajmującym się wcżeśniej omawianą dziedziną. Odczuwa się brak publikacji ujmujących
Wykorzystanie notacji A SN .l do kodowania. 265
w sposób syntetyczny problemy konkretnych zastosowań notacji A SN .l. Niniejszy artykuł jest próbą zapełnienia wspomnianej luki publikacyjnej w odniesieniu do zagadnień związa
nych z wkorzystaniem notacji ASN.l do definiowania danych sygnalizacyjnych przesyłanych w sieciach ISDN w ramach procedur realizujących usługi dodatkowe.
2. Podstawowe zasady realizacji usług dodatkowych w sieciach ISDN
W łączach abonenckich sieci ISDN wszystkie dane sygnalizacyjne przesyłane są w kanale D wyodrębnionym na zasadzie podziału czasu i m ają postać wiadomości [7,8,9,12].
Wiadomości te przesyłane są w polu informacyjnym ramek protokołu warstwy drugiej, tj.
protokołu LAPD. Wiadomość składa się z nagłówka określającego m.in. typ tej wiadomości oraz z pewnej liczby (rzadko kiedy więcej niż 5) tzw. elementów informacyjnych zawierają
cych właściwe dane sygnalizacyjne. Standard [9] definiuje 35 rodzajów elementów informa
cyjnych dla wiadomości przesyłających dane sygnalizacyjne. Z punktu widzenia realizacji usług dodatkowych zasadnicze znaczenie ma element informacyjny typu FACILITY. Ele
ment informacyjny FACILITY pojawia się najczęściej w wiadomości również nazywającej się FACILITY, ale może być on umieszczany także w innego rodzaju wiadomościach.
Dla każdej usługi dodatkowej określony jest w odpowiednim standardzie protokół przesyłania danych sygnalizacyjnych polegający na wymianie pomiędzy obiema stronami łącza abonenckiego jednostek danych protokołowych zwanych komponentami. Komponenty te przesyłane są w polu Komponent elementu informacyjnego FACILITY (rys. 1). W sieciach ISDN notacja A SN .l dotyczy głównie struktury komponentów przesyłanych za pomocą ele
mentów informacyjnych FACILITY.
Każdej usłudze dodatkowej odpowiada zestaw elementarnych operacji. Dla każdej z tych operacji zdefiniowany jest z kolei komponent Invoke i ewentualnie komponenty Return result i Return error [11,13], Zdefiniowany jest również komponent typu Reject, którego struktura nie jest zależna od rodzaju operacji.
Każda elementarna operacja związana z realizacją określonej usługi dodatkowej ini
cjowana jest przez jedną ze stron (abonent lub sieć) wysłaniem komponentu typu Invoke, na co zazwyczaj strona przeciwna odpowiada komponentem Return result, Return error lub Re
ject.
8 7 6 5 1 4 1 3 1 2 1 1
0 0 0 1 1 1 0 0
Identyfikator elementu informacyjnego długość dalszej części
1 0 0 1 0 0 0 1
ext. Zapas dyskryminator usługi = supplementary service
pole Komponent
Rys. 1. Budowa elementu informacyjnego FAC1L1TY Fig. 1. The structure o f the FACILITY information element
3. Charakterystyka notacji A SN .l
3.1. Zasady ogólneIdea notacji ASN .l polega na tym, że jednostka danych protokołowych (PDU, kom
ponent) traktowana jest jako pewien typ danych skomponowany według określonych reguł (np. sekwencja) z danych prostszego typu. Dane te znowu muszą być dekomponowane na dane jeszcze prostszego typu, aż do sprowadzenia wszystkich danych do typów prostych (np.
liczby określonego rodzaju).
Standard X.208 definiuje kilkanaście typów danych, przy czym część z nich to typy proste, natomiast reszta to typy złożone komponowane z typów prostych. Dla każdego z po
wyższych typów określono sposób zapisywania wartości.
Nazwy typów rozpoczynają się zawsze od dużej litery, przy czym nazwy typów zdefi
niowanych w standardzie X.208 składają się z samych dużych liter. Nazwy typów czasami pojawiają się w zapisach zwanych „typami nazwanymi” (NamedType) o postaci
identyfikator Typ
Identyfikator rozpoczyriany jest zawsze od małej litery (w identyfikatorach i nazwach typów dopuszczalny jest znak „minus”). Często w praktyce nazwy identyfikatora i Typu różnią się tylko „rozmiarem” pierwszej litery (identyfikator - mała, Typ - duża). Identyfikator może być np. nazwą pola PDU, w którym przesyła się dane typu „Typ”. Zapis składający się tylko z nazwy typu (bez identyfikatora) też zaliczany jest do kategorii „typ nazwany”. Typom na
zwanym odpowiadają „wartości nazwane” (NamedYalue) zapisywane w formie
Wykorzystanie notacji A SN .l do kodowania.. 267
identyfikator Wartość
Każdemu typowi danych odpowiada etykieta (tag) zastępująca podczas transferu na
zwę typu. Etykieta składa się z klasy i numeru określającego typ w obrębie klasy. Rozróżnia
ne są cztery klasy etykiet: universal - dla typów zdefiniowanych w standardzie X.208, appli
cation - typy zdefiniowane w innych standardach ISO lub ITU, private - typy zdefiniowane przez inne niż ISO lub ITU organizacje, context-specific - etykiety interpretowane w zależno
ści od kontekstu (znaczenie wartości etykiety zależne od miejsca, w którym jej użyto). W przypadku usług dodatkowych sieci ISDN praktyczne znaczenie m ają tylko klasy universal i context-specific. W tabeli 1 przedstawiono etykiety dla wybranych typów danych zdefinio
wanych w X.20 8.
Tabela 1 Etykiety dla-wybranych typów danych zdefiniowanych w X.208
Etykieta (Klasa numer) Typ
UNIVERSAL 1 BOOLEAN
UNIVERSAL 2 INTEGER
UNIVERSAL 5 NULL
UNIVERSAL 6 OBJECT IDENTIFIER
UNIVERSAL 16 SEQUENCE i SEQUENCE OF
Zapisy A SN .l tw orzą bloki zwane modułami ^często ujmowane w ramkę). Moduł ASN.l zawiera kolejno:
- nazwę modułu - jej druga część (o ile istnieje) zapisywana jako wartość typu OBJECT IDENTIFIER,
- słow o DEFINITIONS,
- zapis informujący o domyślnym sposobie traktowania etykiet typów bazowych w typach etykietowanych podczas transferu danych (EXPLICIT TAGS - etykietowanie jawne lub IMPLICIT TAGS - etykietowanie niejawne, czyli możliwość pominięcia etykiety podczas transferu) - brak tego zapisu oznacza etykietowanie jawne,
-znaki
- słow o BEGIN,
- wykaz symboli eksportowanych do innych modułów rozpoczynający się od słowa EXPORTS,
- wykaz symboli importowanych z innych modułów rozpoczynający się od słowa IMPORTS;
nazwa modułu, z ktorego importowane są symbole poprzedzona jest słowem FROM, - definicje typów i definicje wartości (część zasadnicza),
- słow o END.
Definicjom typów i wartości odpowiadają zapisy zwane produkcjami o postaci:
Nazwa_nowego_typu ::= Typ_pierwotny lub nazwa wartości T y p w arto ści ::= Wartość
Typ pierwotny może być typem prostym lub złożonym. Etykieta typu pierwotnego przecho
dzi na nowy typ.
W zapisach ASN. 1 można używać komentarzy rozpoczynających się od dwóch zna
ków „minus”.
3.2. Typy danych
Poniżej omówione zostaną wybrane typy danych zdefiniowane w standardzie X.208.
Zmienne dwuwartościowe - BOOLEAN
Wartości zapisywane sąjako TRUE i FALSE.
Liczby całkowite - INTEGER
W praktyce najczęściej korzysta się z typów będących podzbiorami liczb całkowitych zapisywanych jako
INTEGER {listaw arto ści}
lub INTEGER(wartość_minimalna.. w artośćm aksy malna)
lub rNTEGER{lista_wartości}(wartość_minimalna..wartość_maksymalna) Dwa ostatnie zapisy należy traktować jako podtypy (Subtype) typu INTEGER. Każda z wartości występująca na liście wartości zazwyczaj ma postać
identyfikator( wartość)
Brzmienie identyfikatora zwykle kojarzy się ze znaczeniem określonej wartości. Przykłady:
INTEGER {service 1 (1 ),service2(2),service3(3)}
typ składający się z trzech liczb całkowitych o wartościach 1, 2 i 3 i o identyfikatorach od
powiednio service 1, service2, service3.
INTEGER (-32768..32767)
typ składający się z kolejnych liczb całkowitych od -32768 do 32767.
INTEGER {service 1 (1 ),service2(2),service3(3)} (1 ..3)
jest to zapis takiego samego typu jak w pierwszym przykładzie, lecz rozszerzony (nadmiaro
wo) o zakres liczb tworzących typ.
Wartości tpu INTEGER zapisuje się dziesiętnie z pomijaniem zer prowadzących.
Typ NULL
Jest to specyficzny typ zawierający tylko jedną wartość zapisywaną również jako NULL. Praktycznie rzecz biorąc typ ten pojawia się zwykle jako składnik typu złożonego CHOICE, gdzie wartość NULL jest wybierana jako wartość typu CHOICE wtedy, gdy żaden inny składnik nie może zostać wybrany.
Wykorzystanie notacji ASN .l do kodowania. 269
Identyfikator obiektu - OBJECT IDENTIFIER Podstawową form ą zapisu wartości jest {lista_składników}
Elementy listy składników rozdzielane są spacjami lub znakami nowego wiersza i najczęściej m ają jedną z następujących postaci: identyfikator, liczba lub identyfikator(liczba).
Wartości omawianego typu określają pewną docelową wartość liczbową poprzedzoną danymi identyfikującymi organizację, która wartości tej przypisała jakieś znaczenie oraz dokument, w którym tego dokonano. Dopuszczalne wartości dwóch pierwszych składników (początko
we gałęzie drzewa identyfikatorów) określone są w standardzie X.208. Struktura dalszej czę
ści listy składników definiowana jest przez dokumenty wydawane przez odpowiednie organi
zacje standaryzacyjne (np. [10]), przy czym ostatnim składnikem jest zawsze docelowa war
tość liczbowa. Każdemu składnikowi odpowiada liczba, która może być określona jawnie w zapisie składnika bądź też niejawnie za pomocą identyfikatora. W drugim z wymienionych przypadków liczby odpowiadające identyfikatorom określone są w odpowiednich standar
dach.
W przypadku zapisu wartości typu OBJECT IDENTIFIER zdefiniowanych przez standardy ETSI [10] pełna lista składników składa się z sześciu pozycji. Przykładem takiego zapisu może być:
{ccitt identified-organization etsi(0) 359 operations-and-errors(l) 4}
Pierwsze trzy składniki m ają zawsze jednakową postać i określają ETSI jako organizację, która opracowała standard: Zgodnie z standardem X.208 pierwszemu składnikowi (ccitt) od
powiada liczba 0, natomiast drugiemu (identified-organization) - liczba 4. Liczba odpowia
dająca trzeciemu składnikowi (etsi(0)) podana jest jawnie i wynosi 0. Dalsze składniki ozna
czają: końcówkę numeru standardu ETSI (359 - w celu uzyskania pełnego numeru należy dodać 300 000), moduł A SN .l w tym standardzie definiujący wartość docelową ( operations- and-errors(l)) i docelową wartość liczbową (4). Przedstawiony wyżej przykładowy zapis jest równoważny poniższemu zapisowi, w którym wszystkie składniki reprezentowane są przez liczby:
{0 4 0 359 1 4}
Inną często spotykaną formą zapisu wartości omawianego typu jest {nazwa_innej_wartości_typu_OBJECTJDENTIFIER listaskładników }
W takim przypadku początkowe składniki listy składników zastąpione są przez nazwę warto
ści typu O B JE C T ID E N T IFIE R zdefiniowaną w innym miejscu modułu. Poniżej przedsta
wiono przykład takigo zapisu.
Definicja wartości cCBSOID typu OBJECT IDENTIFIER:
cCBSOID OBJECT IDENTIFIER ::= {ccitt identified-organization etsi(0) 359 operations-and-errors( 1)}
Pełny zapis wartości docelowej ma wówczas postać:
{cCBSOID 4}
i jest równoważny zapisom omówionym wcześniej.
Sekwencja - SEQUENCE
Omawiany typ jest typem złożonym będącym uporządkowaną listą innych typów, przy czym niektóre z tych typów m ogą być opcjonalne - ich wartości m ogą być pomijane w czasie transferu. Zapis typu SEQUENCE ma postać:
SEQUENCE{lista_elementów}
W najczęstszych przypadkach składnikami listy elementów są typy nazwane, przy czym typy opcjonalne m ają dodane słowo OPTIONAL. Przykładem zapisu typu SEQUENCE może być:
SEQUENCE{
pierwszy INTEGER,
drugi BOOLEAN OPTIONAL,
trzeci OBJECT IDENTIFIER}
Niekiedy elementy listy są tzw. typami etykietowanymi (omówionymi dalej). Stosowanie tych typów umożliwia jednoznaczne rozpoznanie poszczególnych składników w sytuacji, gdy lista elementów zawiera składniki opcjonalne.
Zapis wartości typu SEQUENCE ma postać
{lista_wartości_elementów}
gdzie każdy składnik listy wartości elementów jest wartością nazwaną.
Sekwencja jednakowych typów - SEQUENCE OF Typ
Powyższy typ jest sekwencją, której składniki są jednakowego typu (typu „Typ”).
Często stosowany jest podtyp omawianego typu, dla którego określona jest minimalna i mak
symalna liczba składników. Zapis tego podtypu ma postać:
SEQUENCE SIZE (min_składników..max_składników) OF Typ Zapisem wartości jest
{lista_wartości_elementów}
Wybór - CHOICE
Omawiany typ jest typem złożonym, będącym listą innych typów, przy czym jego wartością jest wartość jednego ze składników tej listy. Zapis typu CHOICE ma postać:
CHOICE{lista_altematywnych_typów}
Wykorzystanie notacji A SN .l do kodowania.. 271
Elementami listy alternatywnych typów są typy nazwane, przy czym typy te powinny się różnić etykietami. Z tego powodu często składnikami listy są typy etykietowane. Etykietę typu CHOICE należy traktować jak zmienną - jest ona równa etykiecie wybranego w danym przypadku składnika. Zapis wartości typu CHOICE ma postać wartości nazwanej wybranego składnika.
Typ etykietowany - tagged type
Powyższy typ występuje jako składnik typów złożonych (np. SEQUENCE, CHOICE). Jego stosowanie ma na celu jednoznaczne rozróżnienie składników w tych typach.
Typ etykietowany powstaje z innego typu (typ bazowy) poprzez przypisanie mu nowej ety
kiety. Zapis omawianego typu ma postać:
[Klasa numer] Typ_bazowy
lub [Klasa numer] IMPLICIT T y pbazow y lub [Klasa numer] EXPLICIT Typ bazowy
gdzie „Klasa numer” jest now ą etykietą. W praktyce zapis klasy etykiety w nawiasach pro
stokątnych jest zwykle pomijany, co odpowiada klasie context-specific. Słowo IMPLICIT oznacza, że etykieta typu bazowego nie musi być przesyłana podczas transferu danych (ety
kietowanie niejawne), natomiast słowo EXPLICIT - że etykieta typu bazowego powinna być przesyłana (etykietowanie jawne). W przypadku braku powyższych słów (zapis pierwszy) o sposobie etykietowania podczas transferu decyduje informacja zawarta w nagłówku modułu ASN.l, przy czym dla typów CHOICE i ANY zawsze stosowane jest etykietowanie jawne niezależnie od tej informacji. Etykietowanie niejawne zmniejsza rozmiary postaci transfero
wej danych.
Typ określony pośrednio - ANY DEFINED BY identyfikator
Powyższy typ może być używany tylko jako składnik typu SEQUENCE lub SET i tylko wtedy, gdy „identyfikator” pojawia się w typie nazwanym będącym innym nieopcjo- nalnym składnikiem tego samego typu SEQUENCE lub SET. W takim przypadku słowo ANY zostaje zastąpione typem wynikającym z wartości składnika określonego przez „identy
fikator”. Sposób przypisania wartościom tego składnika typów zastępujących ANY określony jest za pomocą komentarza lub specjalnego dokumentu. Etykieta typu jest nieokreślona.
Przykładowo, omawiany typ może być użyty w następujący sposób:
SEQUENCE]
value INTEGER,
parameter ANY DEFINED BY value}
W takim przypadku typ odpowiadający identyfikatorowi „parameter” będzie wynikał z war
tości składnika „value INTEGER” .
3.3. Makronotacje
Dodatkowym mechanizmem służącym do definiowania nowych typów danych i zapi
sywania wartości tych typów są makronotacje. Podobnie jak w językach programowania ma- kronotacja jest pewnym zapisem tworzonym na bazie makrodefinicji. Makrodefinicja określa:
- sposób tworzenia zapisu definiującego nowy typ (notacja nowego typu), - sposób zapisywania wartości tego typu (notacja wartości nowego typu),
- wartości standardowego typu odpowiadające wartościom nowego typu (wartości zwracane).
Przykładowo [2], za pomocą makronotacji można zdefiniować nowe typy o postaci PAIR
TYPEX=xxx TYPEY =yyy z zapisami wartości w formie
(X=uuu, Y=vvv)
i wartościami zwracanymi standardowego typu S E Q U E N C E {xxx^}
gdzie xxx, yyy - stndardowe typy A SN .l, uuu, vvv - wartości typu odpowiednio xxx i yyy.
Słowo PAIR jest nazwą makronotacj i (nazwy makronotacji pisane są dużymi literami).
Odwołania do makronotacji można podzielić na notacje nowych typów i notacje war
tości nowych typów. Notacja nowego typu składa się z nazwy makronotacji, po której nastę
puje zapis składający się z tekstów stałych (np. TYPEX=, TYPEY=) i parametrów (np. xxx, yyy). Teksty stałe zwykle pełnią rolę nazw parametrów. W przypadku makronotacji PAIR
przykładem notacji nowego typu może być PAIR
TYPEX=INTEGER TYPEY=BOOLEAN
Dla tak zdefiniowanego nowego typu notacja wartości może mieć postać:
(X=3,Y=TRUE)
Standardowy typ wartości zwracanych nie musi mieć wyraźnego związku z notacją nowego typu. W rozpatrywanym przykładzie związek taki raczej istnieje - makronotacja PAIR jest właściwie inną formą zapisu typu SEQUENCE. Może się jednak zdarzyć, że no
wemu typowi o dużej złożoności odpowiadać będą wartości np. typu INTEGER.
Notacja nowego typu może być umieszczana w miejscach, gdzie normalnie umiesz
czane są nazwy typów standardowych, a więc np. w zapisach określających zawartości okre
Wykorzystanie notacji ASN .l do kodowania.. 273
ślonych pól komponentu. W takich przypadkach w polu komponentu przesyłana będzie war
tość typu standardowego zwracana przez nowy typ.
4. Zasady kodowania danych określone w standardzie X.209
W najczęstszych przypadkach każdy typ danych (prosty lub złożony) kodowany jest w sposób przedstawiony na rys.2 i w tabeli 2. Jeżeli kodowany typ jest typem złożonym (np.
SEQUENCE), to w polu „zawartość” znajdują się obszary o takiej samej strukturze odpowia
dające poszczególnym składnikom tego typu. W przypadku typu prostego pole „zawartość”
określa wartość tego typu (np. jest zapisem liczby). Wartość zero bitu 8 oktetu 2 oznacza, że długość pola „zawartość” zapisana jest w jednym oktecie, tj. na bitach 1 + 7 oktetu 2 (wartość jeden oznacza zapis za pom ocą większej liczby oktetów).
8 7 6 5 | 4 | 3 | 2 | 1 oktet
Klasa etykiety P/C numer etykiety 1
0 długość dalszej części (zawartości) w oktetach 2
3 zawartość
P/C: 0 - typ prosty (primitive), 1 - typ złożony (constructed),
Rys. 2. Kodowanie pojedynczego typu danych Fig. 2. Coding o f a single data type
Tabela 2 Kodowanie klasy etykiety
Klasa Bit 8 Bit 7
Universal 0 0
Application 0 1
Context-specific 1 0
Private 1 1
Dla większości typów reguły kodowania wartości są proste i zgodne z intuicją. Wy
jątkiem jest kodowanie wartości typu OBJECT IDENTIFIER oraz typu etykietowanego i typu NULL, które omówione zostanie poniżej.
W przypadku typu OBJECT IDENTIFIER w polu „zawartość” następują kolejno po sobie zapisy liczb zwanych subidentyfikatorami. Pierwszy subidentyfikator obliczany jest jako (X*40)+Y, gdzie X - wartość pierwszego składnika typu OBJECT IDENTIFIER, Y - wartość drugiego składnika (omawiany typ zawiera zawsze co najmniej dwa składniki, przy czym wartość drugiego składnika jest zawsze mniejsza od 40). Każdy następny subidentyfi
kator jest równy składnikowi o numerze o jeden wyższym.
Pojedynczy subidentyfikator zależnie od wartości kodowany jest na jednym lub wielu oktetach, przy czym najbardziej znaczący bit wszystkich oktetów z wyjątkiem ostaniego ma wartość jeden. Pozostałe bity powyższych oktetów po połączeniu ze sobą tworzą wartość subidentyfikatora traktowaną jako liczba całkowita bez znaku, przy czym pierwszy oktet za
wiera najbardziej znaczącą część tej liczby, natomiast ostatni oktet - najmniej znaczącą. Przy
kładowo wartość
{0 4 0 359 1 4}
będzie reprezentowana przez następującą sekwencję oktetów (zapis szesnastkowy):
04, 00, 82, 6 7 ,0 1 ,0 4
Jeżeli w zapisie A SN .l typu etykietowanego zadeklarowano etykietowanie jawne, to w polu „zawartość” umieszcza się pełny zapis typu bazowego (jak na rys.2). W przeciwnym razie (etykietowanie niejawne) w polu „zawartość” znajduje się tylko „zawartość” typu bazo
wego - pomija się dwa pierwsze oktety typu bazowego. Jeżeli typ bazowy jest typem złożo
nym, to w omawianym przypadku bit P/C typu etykietowanego powinien mieć wartość jeden.
W przypadku typu NULL pole „zawartość” jest puste, tzn. długość zawartości okre
ślona w drugim oktecie wynosi zero.
5. Opis struktury ogólnej komponentów za pomocą notacji A SN .l
Struktura ogólna komponentów (PDU) używanych do realizacji usług dodatkowych w sieciach ISDN przedstawiona została za pomocą notacji ASN.l w tabeli 3 zaczerpniętej z [11]. Zgodnie z tą tabelą 3 (definicja typu Components) i z wcześniejszymi ustaleniami roz
różniane są cztery rodzaje komponentów: Invoke, Return result, Return error i Reject. Po
wyższym komponentom odpowiadają typy odpowiednio: InvokeComponent, RetumResult- Component, RetumErrorComponent i RejectComponent. Każdy z wymienionych typów zde
finiowany jest jako sekwencja danych innych typów. Poszczególne elementy tych sekwencji reprezentują pola komponentu. Postać transferowa komponentu zawierać będzie dodatkowe pole (nagłówek) identyfikujące rodzaj komponentu.
Jak wynika z tabeli 3, komponent Invoke składa się z następujących pól:
invokelD, linked-ID, operation-value, argument.
Wykorzystanie notacji A SN .l do kodowania. 275
Tabela 3 Struktura k o m p o n e n tó w
Facility-Inform ation-Elem ent-Com ponents {ccitt identified-organization etsi(O) 196 facility-inform ation-elem ent-com ponents(3)}
DEFINITIONS ::=
BEGIN
EXPORTS In vokelD T ype, Components;
IMPORTS O PER A TIO N , ERROR
FROM R em ote-O peration-Notation
(join t-iso-ccitt rem ote-operations(4) notation(O)};
Components ::= CHOICE {
invokeC om p [1] IMPLICIT InvokeCom ponent,
retumR esultCom p [2] IMPLICIT R etum R esultCom ponent, retumErrorComp [3] IMPLICIT RetumErrorComponent, rejectComp [4] IMPLICIT RejectCom ponent}
InvokeComponent ::= SEQ U E N C E {
in vok elD InvokelD T ype,
linked-ID [0] IMPLICIT InvokelD T ype O PTIONAL, operation-value OPERATION,
argument A N Y D EFIN ED BY operation-value OPTION AL}
— A N Y is filled by the single A S N .l data type fo llo w in g the
— keyword A R G U M E N T in the type definition o f a particular
— operation.
InvokelDType ::= INTEGER (-32768..327Ó 7) Retum ResultCom ponent ::= SEQ UENCE {
invok elD InvokelD T ype, S E Q U E N C E {
operation-value OPERATION,
result A N Y DEFIN ED B Y operation-value
— A N Y is filled by the single A S N .l data type follow in g - the keyword RESULT in the type definition o f -- a particular operation.
{O PTIO NAL}
RetumErrorComponent ::= SEQ U E N C E {
invok elD InvokelD T ype, error-value ERROR,
parameter A N Y D EFIN ED B Y error-value OPTION AL}
— A N Y is filled by the single A S N .l data type fo llo w in g the
— keyword PARAM ETER in the type definition o f a particular
— error.
RejectComponent ::= SEQ U E N C E {
invokelD CHOICE { InvokelD T ype, N U L L }, problem CHOICE {
[0] IMPLICIT GeneralProblem, [1] IMPLICIT InvokeProblem, [2] IMPLICIT RetumResuItProblem [3] IMPLICIT RetumErrorProblem}}
cd. tabeli 3 Struktura k o m p o n e n tó w
GeneralProblem ::= INTEGER { — ROSE-provider detected unrecognizedC om ponent (0),
m istypedC om ponent (1), badlyStructuredComponent (2)}
InvokeProblem ::= INTEGER { — ROSE-user detected - supplementary entity
duplicatelnvocation (0), unrecognizedOperation (1),
m istyped Argument (2), resourceLimitation (3), initiatorReleasing (4), unrecognizedLinkedID (5), linkedR esponseU nexpected (6),
unexpectedChildOperation (7)}
R etum R esultProblem ::= INTEGER { — ROSE-user detected unrecognizedlnvocation (0),
resultR esponseU nexpected (1), m istypedR esult (2)}
RetumErrorProblem ::= INTEGER { — ROSE-user detected
unrecognizedlnvocation (0), errorR esponseUnexpected (1), unrecognizedError (2), unexpectedError (3),
mistypedParameter (4)}
E N D — o f Facility-Inform ation-Elem ent-C om ponents
przy czym pola linked-ID i argument są opcjonalne. W polach invokelD oraz linked-ID prze
syłane są liczby całkowite z przedziału od -32768 do 32767 (16-bitowe). Pole operation- value zawiera wartość zwracaną przez opisaną dalej makronotację OPERATION. Wartość ta może być typu INTEGER lub OBJECT IDENTIFIER. Struktura pola argument jest za
leżna od wartości przesyłanej w polu operation-value i odpowiada ona typowi zdefiniowane
mu po słowie ARGUMENT w odpowiednim odwołaniu do makronotacji OPERATION znaj
dującym się w module A SN .l określającym typy danych dla poszczególnych operacji kon
kretnej usługi dodatkowej.
Znaczenie poszczególnych pól komponentu nie odgrywa żadnej roli w opisie struktu
ry przesyłanych danych, nie mniej wyjaśnimy krótko, że invokelD jest identyfikatorem ini
cjowanej operacji umożliwiającym skojarzenie żądania z odpowiedzią, linked lD jest identy
fikatorem wcześniej zainicjowanej operacji, do której nawiązuje aktualnie inicjowana opera
cja (bardzo rzadko używany), operation-value określa rodzaj operacji, natomiast argument (często najbardziej rozbudowane pole) zawiera parametry inicjowanej operacji.
Komponent Return result tworzą pola:
invokelD, operation-value, result.
przy czym sekwencja operation-value, result jest opcjonalna. Pola invokelD i operation value mają taką samą postać i znaczenie, jak w komponencie Invoke. Struktura pola result, podob
nie jak dla pola argument komponentu Invoke, jest zależna od wartości przesyłanej w polu operation-value i odpowiada ona typowi zdefiniowanemu po słowie RESULT w odpowied
Wykorzystanie notacji A SN .l do kodowania.. 277
nim odwołaniu do makronotacji OPERATION znajdującym się w module A SN .l określają
cym typy danych dla poszczególnych operacji konkretnej usługi dodatkowej.
Komponent Return error utworzony jest z pól:
invokelD, error-value, parameter.
przy czym pole parameter jest opcjonalne (w praktyce rzadko kiedy występuje). Pole invoke
lD ma taką sam ą postać i znaczenie jak w poprzednio omówionych komponentach. Pole er
ror-value zawiera wartość zwracaną przez opisaną dalej makronotację ERROR. Wartość ta może być typu INTEGER lub OBJECT IDENTIFIER. Struktura pola parameter jest zależna od wartości przesyłanej w polu error-value i odpowiada ona typowi zdefiniowanemu po sło
wie PARAMETER w odpowiednim odwołaniu do makronotacji ERROR znajdującym się w module A SN .l określającym typy danych dla poszczególnych błędów konkretnej usługi do
datkowej . Pole error-value określa rodzaj błędu, natomiast pole parameter zawiera dodatkowe dane dotyczące błędu.
Komponent Reject zawiera pola:
invokelD, problem.
Pole invokelD może zawierać wartość typu INTEGER (podobnie jak w poprzednich komponentach) lub wartość typu NULL (gdy nie jest możliwe zidentyfikowanie operacji, której dotyczy komponent). W polu problem znajduje się wartość jednego z czterech typów etykietowanych, dla których typem bazowym jest INTEGER etykietowany niejawnie. Ety
kiety w poszczególnych typach etykietowanych odpowiadają różnym grupom problemów (błędów). Każdy problem reprezentowany jest przez wartość liczbową o identyfikatorze koja
rzącym się z rodzajem problemu.
6. Definiowanie struktury danych sygnalizacyjnych dla konkretnych usług dodatkowych
Jak już wspomniano, dla każdej usługi dodatkowej określony jest zestaw elementar
nych operacji. Dla każdej z tych operacji struktura danych sygnalizacyjnych definiowana jest za pom ocą makronotacji OPERATION i ERROR. Makrodefinicje dla powyższych makro
notacji określone zostały w [13] (można je również znaleźć w [9,11]).
Obie makronotację zwracają wartość typu CHOICE {
local Value INTEGER,
global Value OBJECT IDENTIFIER }
czyli wartość typu INTEGER lub OBJECT IDENTIFIER o identyfikatorach odpowiednio
„localValue” lub „globalValue” (typy nazwane).
Każdej operacji odpowiada w standardach zapis wykorzystujący makronotację OPERATION (notacja nowego typu) mający postać:
Typ_rodząju_operacji::= OPERATION
ARGUMENT typ dla jp o la a rg u m e n t komponentu Invoke RESULT ty p d la _pola_result_komponentu_Return_reslt ERRORS {/ista błędów dla operacji}
LINKED {lista operacji_pochodnych}
Wartość zwracana przez makronotację OPERATION jest identyfikatorem operacji i umieszczana jest ona w polu „operation-value” komponentów Invoke i Return result. Nazwa
„Typ_rodzaju_operacji” dobierana jest zwykle tak, aby kojarzyła się z funkcją danej opera
cji.
Zgodnie z wcześniejszymi ustaleniami zapisy po słowach ARGUMENT I RESULT określają typ danych dla pól „argument” i „result” komponentów odpowiednio Invoke i Re
turn result.
Zapis po słowie ERRORS jest listą błędów sygnalizowanych za pomocą komponentu Return error. Elementami tej listy m ogą być nazwy wartości pojawiających się w polu „error- value” komponentu Return error, jak również nazwy typów odpowiadających tym warto
ściom. Lista błędów może zawierać zarówno błędy specyficzne dla danej operacji lub usługi dodatkowej, jak i tzw. błędy ogólnego zastosowania (generally applicable errors) zdefiniowa
ne w [11] (np. notSubscribed, notAvailable, notlmplemented).
Zapis po słowie LINKED jest listą operacji pochodnych w stosunku do danej operacji (child opérations). Elementami tej listy mogą być nazwy wartości pojawiających się w polu
„operation-value” komponentów Invoke i Return result operacji pochodnych, jak również nazwy typów odpowiadających tym wartościom.
Słowa ARGUMENT, RESULT, ERRORS, LINKED i zapisy po nich występujące m ogą być pomijane. Brak zapisu rozpoczynającego się od słów ARGUMENT lub RESULT oznacza brak pola „argument” lub „result” w komponencie Invoke lub Return result. Pomi
nięcie zapisu RESULT może też oznaczać, że komponent Return result nie jest dla danej ope
racji wykorzystywany. Brak zapisu rozpoczynającego się od słowa ERRORS oznacza, że żaden rodzaj błędu nie jest sygnalizowany za pomocą komponentu Return error. Brak zapisu rozpoczynającego się od słowa LINKED oznacza z kolei brak operacji pochodnych (dla aktu
alnie realizowanych usług dodatkowych brak tego zapisu jest regułą).
Po zapisie odwołującym się do makronotacji OPERATION następują zwykle defini
cje typów, do których odwołują się zapisy po słowach ARGUMENT i RESULT.
Określenie rodzaju operacji przesyłanego w polu „operation-value” realizowane jest za pomocą zapisu o postaci:
nazwa_wartości Typ_rodzaju_operacji ::= wartość
Wykorzystanie notacji ASN.l do kodowania. 279
przy czym nazwa wartości różni się od nazwy typu rodzaju operacji jedynie „rozmiarem”
pierwszej litery (nazwa wartości - mała litera, nazwa typu - duża litera).
Poniżej przedstawiono przykład omawianych zapisów dla operacji AOCEChargingU- nit realizowanej w ramach usługi Advice o f Charge (AOC) [5]. Celem operacji jest przesłanie do abonenta po zakończeniu rozmowy informacji o liczbie naliczonych impulsów oraz opcjonalnie - informacji o sposobie jej naliczania. Pominięte zostały zapisy definiujące typy opcjonalne. Dla omawianej operacji wykorzystuje się tylko komponent Invoke.
AOCEChargingUnit ::= OPERATION
ARGUMENT CHOICE {
chargeNotAvailable NULL, AOCEChargingUnitlnfo}
AOCEChargingUnitlnfo ::= SEQUENCE { CHOICE {
specificChargingUnits SEQUENCE {
recordedUnitsList [ 1 ] RecordedUnitsList,
aOCEBillingld [2] AOCEBillingld OPTION A L}, freeOfCharge [1] NULL},
chargingAssociation ChargingAssociation OPTIONAL}
RecordedUnitsList ::= SEQUENCE SIZE (1..32) OF RecordedUnits RecordedUnits ::= SEQUENCE {
CHOICE {
recordedNumberOfUnits NumberOfUnits,
not A vailable NULL},
recordedTypeOfUnits TypeOfUnit OPTIONAL } NumberOfUnits ::= INTEGER (0.. 16777215)
aOCEChargingUnit AOCEChargingUnit ::= 36
Pole argument komponentu Invoke zawiera normalnie sekwencję AOCEChargingU
nitlnfo, której jedynym składnikiem w najprostszym przypadku (odrzucenie typów opcjonal
nych i NULL) jest sekwencja specificChargingUnits. Jedynym obowiązkowym składnikiem tej sekwencji jest typ etykietowany [1] RecordedUnitsList będący sekwencją maksimum 32 typów RecordedUnits. Typ RecordedUnits jest znowu sekwencją, którą tworzy typ INTEGER reprezentujący liczbę naliczonych impulsów oraz (opcjonalnie) typ TypeOfUnit określający numer taryfy.
Rodzaj operacji określony jest przez wartość typu INTEGER rów ną 36. Typ wartości wynika ze sposobu jej zapisu. Definicja rodzaju operacji może w omawianym przypadku mieć alternatywną postać:
aOCEChargingUnit AOCEChargingUnit ::= localValue 36
W zapisie tym posłużono się wartością nazwaną.
W wielu przypadkach rodzaj operacji określony jest przez wartość typu OBJECT IDENTIFIER. Definicja tej wartości ma wówczas bardziej złożoną postać. Przykładowo, dla operacji CCBSRequest [6] może przedstawiać się ona następująco:
cCBSOID OBJECT IDENTIFIER ::= {ccitt identified-organization etsi (0) 359 operations-and-errors (1)}
cCBSRequest CCBSRequest ::= globalValue {cCBSOID 2}
Każdemu typowi występującemu w liście błędów makronotacji OPERATION (typ ten może być wykorzystywany przez wiele operacji związanych z daną usługą dodatkową) od
powiada definicja odwołująca się do makronotacji ERROR. Ma ona w ogólnym przypadku postać jak niżej.
Typ błędu ::= ERROR
PARAMETER typ dla_pola_parameter_komponentu_Return_error
Dla aktualnie realizowanych usług dodatkowych pole „parameter” nie występuje w komponentach Return error. W związku z powyższym zapis rozpoczynający się od słowa PARAMETER jest pomijany. Wartości określające rodzaje błędów przesyłane w polu „error- value” komponentu Return error definiowane są na podobnych zasadach co wartości określa
jące rodzaje operacji. Przykładowy zapis dotyczący określonego rodzaju błędu może mieć poniższą postać [5].
NoCharginglnfoAvailable ::= ERROR
noCharginglnfoAvailable NoCharginglnfo Available ::= 26
Tak więc dla błędu „NoCharginglnfoAvailable” w polu „error-value” komponentu Return result przesyłana jest wartość typu INTEGER równa 26.
7. Przykład kodowania komponentu przesyłanego w elemencie informacyjnym FACILITY
W tabeli 4 zaprezentowano postać transferową komponentu Invoke dla wcześniej omówionej operacji „AOCEChargingUnit” zarejestrowanego w łączu ISDN sieci T.P. S.A.
Komponent ten nie zawiera elementów opcjonalnych ani typów NULL.
W module ASN.l opisującym strukturę powyższego komponentu przyjęto domyślnie niejawny sposób etykietowania typów etykietowanych (IMPLICIT TAGS w nagłówku mo
dułu).
Postać transferowa omawianego komponentu wynika z wcześniej podanych zapisów ASN.l i z reguł kodowania określonych w [3]. Oktety 1 i 2 stanowią nagłówek identyfikujący rodzaj komponentu. Znaczenie dalszych grup oktetów jest następujące:
Wykorzystanie notacji ASN.l do kodowania. 281
- oktety 3 -r 6 - pole „invokelD”, - oktety 7 + 9 - pole „operation-value”, - oktety 10 + 20 - pole „argument”.
Warto zwrócić uwagę, że ze względu na niejawny sposób etykietowania typów ety
kietowanych nie są przesyłane etykiety typów InvokeComponent oraz RecordedUnitsList.
Zgodnie z wcześniejszymi definicjami, pierwszy typ jest w istocie inaczej nazwanym typem SEQUENCE, natomiast drugi - typem SEQUENCE OF. Zatem w razie jawnego etykietowa
nia należałoby dla obu wymienionych typów dodatkowo przesłać etykietę typu SEQUENCE lub SEQUENCE OF.
8. Uwagi końcowe
Głównym celem notacji ASN.l jest uniezależnienie opisu struktury danych od reguł kodowania. Stosowanie abstrakcyjnej syntaktyki daje też pewne dodatkowe korzyści. Po pierwsze, zapis ASN .l jest przejrzysty dla danych o złożonej strukurze - gdy występuje alter
natywna postać pól lub dopuszczalne jest pomijanie niektórych pól. W przypadku niektórych usług dodatkowych trudno sobie wręcz wyobrazić inny sposób opisywania danych sygnaliza
cyjnych. Omawiana cecha sprawia, że sensowne może okazać się stosowanie notacji ASN.l również do opisu danych przesyłanych w niższych warstwach modelu OSI/ISO. Po drugie, notacja A SN .l wymusza uporządkowane i jednolite reguły kodowania danych, co z kolei ułatwia ich programową analizę. Z powyższych względów w standardach ETSI dla usług dodatkowych ISDN całkowicie zrezygnowano z tradycyjnych metod opisu struktury danych sygnalizacyjnych.
T abela 4 Budowa komponentu Invoke dla operacji AOCEChargingUnit
N r oktetu Pole Znaczenie Komentarz
oktetu
1 10--- klasa e t y k i e t y : c on te x t - s p e c i f i c
— 1--- P/C : typ złożony
00001 n u me r e t y k i e t y : [1] In vo k eC om po n en t 2 0 --- format dług oś c i : jeden oktet
__________ - 0 0 1 00 1 0 d ł u g o ś ć zawartości : 18 okte tó w _________________
3 0 0 --- klasa e t y k i et y : u n iv ersal
— 0 --- P/C : typ p r o s t y
0 0010 nu m er e t y ki et y : INTE GE R - in vo k e l D 4 0 --- format dłu go ś ci : jeden oktet
- 0 0 0 0 0 1 0 d ł ug oś ć zawartości : 2 ok tety
5 0 0 0 0 0 01 0 z aw ar t oś ć - o ktet 1 : i n v o ke l D - high
_______ 6 10001111 za w artość - oktet 2 : in vo k e l D - low____________
7 0 0 --- klasa e t y k ie ty : u ni versal
— 0 --- P/C : typ p r o s t y
00010 n u m e r e t y k i e t y : I N T EG ER - o pe r at ion-value 8 0 --- format dłu go śc i : j eden oktet
- 00 00 00 1 d ł u go ść zawart oś c i : 1 oktet
_9 0 0 1 0 01 00 za w artość____________________: aOCE C h ar g in gU ni t __________
10 0 0 --- klasa e t y k i e t y : uni ve rs a l
- - 1 --- P/C : typ złożony
10000 n um er e t y k i e t y : S EQUENCE
: - A O C E C h a r g i n g U n i t l n f o 11 0 --- format dłu g oś ci : jeden oktet
___________- 00 01 0 0 1 d ł ug oś ć zawartości : 9 o k t e t ó w _____________
12 0 0 --- klasa et yk i e t y : universal
— 1--- P/C : typ złożony
10000 n um e r et y ki e t y : SEQ UE NC E
: - s p e c i f i cC ha r gi ng Un i ts 13 0 --- format dłu go śc i : jeden oktet
__________ - 0 0 0 01 11 d ł u g o ś ć zawartości : 7 o k t e t ó w __________________
14 1 0 --- klasa e t y k i e t y : c on t e x t - s p e c i f i c
- - 1 --- P/C : typ złożony
00001 n um e r e t y k i e t y : [1] R ec or d e d U n i t s L i s t 15 0 --- format d łu g o ś c i : j eden oktet
_______ - 0 0 0 01 01 d ł ug oś ć zawartości : 5 o k t e tó w___________________
16 0 0 --- klasa e t y k i e t y : universal
— 1— ' P/C : typ złoż on y
10000 nu me r e t y k i e t y : SE QU E N C E - Re c or de dU n it s 17 0 --- format d ł u g o śc i : jeden oktet
- 0 0 0 00 11 d ł u g o ś ć z awartości : 3 oktet y___________________
18 0 0 --- klasa e t y k i e t y : u n iv ersal
— 0 --- P/C : typ p r o s t y
00010 n um e r e t y k i e t y : I N TE GE R - N u mb er O f U n i t s 19 0 --- format dłu g oś ci : jeden oktet
- 0 0 0 00 01 d ł u go ś ć zawartości : 1 oktet
20 0 0 0 00 01 0 z a wa rtość_____________ : liczba i m p u l s ó w = 2_______
Wykorzystanie notacji A SN .l do kodowania. 283
Literatura
1. CCITT (ITU-T): Recommendation X.200. Reference Model o f Open Systems Intercon
nection for CCITT Applications. 1980.
2. CCITT (ITU-T): Recommendation X.208. Specification of Abstract Syntax Notation One (A SN .l). 1984.
3. CCITT (ITU-T): Recommendation X.209. Specification o f Basic Encoding Rules for Abstract Syntax Notation One (ASN.l). 1984.
4. ETSI: ETS 300 286. ISDN; User-to-User Signalling (UUS) supplementary service.
1996.
5. ETSI: ETS 300 182. ISDN; Advice-of-Charge (AOC) supplementary service. 1993.
6. ETSI: ETS 300 359. ISDN; Completion o f Calls to Busy Subscriber (CCBS) supple
mentary service. 1995.
7. Kabaciński W.: Standaryzacja w sieciach ISDN. Wydawnictwo Politechniki Poznań
skiej, Poznań 1996.
8. Kościelnik D.: ISDN cyfrowe sieci zintegrowane usługowo. WKŁ, Warszawa 1996.
9. ETSI: ETS 300 102. ISDN; User-network interface layer 3, Specifications for basic call control. 1990.
10. ETSI: ETS 300 351. ETSI object identifier tree; Rules and registration procedures. 1994.
11. ETSI: ETS 300 196. ISDN; Generic functional protocol for the support o f supplemen
tary services. 1993.
12. Brzeziński K.M.: Istota sieci ISDN. Oficyna Wydawnicza Politechniki Warszawskiej, Warszawa 1999.
13. CCITT (ITU-T): Recommendation X.219. Remote Operations: Model, Notation and Service Definition. 1988.
Recenzent: Dr hab.inż.Krystyna Macek-Kamińska
Abstract
Defining the structure (format) o f protocol data units (PDU) is an important part of communication protocol specification. Traditional methods o f PDU format defining depend usually on defining the meaning o f subsequent octets or bits creating this PDU (like fig. 1). A drawback o f these methods is that they simultaneously define types o f data contained in the PDU and rules o f coding the data. In some situations it is profitable to define PDU structure
only on the level o f data types without defining the transfer syntax of the data. The need of such an approach appears, for example, in specifications o f application layer protocols.
Presentation o f transfered data structure on the level o f data types is called abstract syntax (syntax abstracting from coding). The ASN. 1 notation (Abstract Syntax Notation One) described in X.208 standard is an example o f such a syntax. For this notation the X.209 stan
dard, that presents the rules o f coding particular types o f data, has been developed. The ASN. 1 notation and the rules o f coding defined in X.209 are adapted in ISDN networks and other telecommunications systems, where they are used in descriptions of signalling data re
lated to supplementary services. This paper presents a synthetic conception o f problems, that concern application o f ASN .l notation to define such a kind o f data.
Basic rules o f supplementary services realization are presented. Then, the ASN.l no
tation and the rules o f coding defined in X.209 are characterized. Kinds o f PDU (compo
nents) used in supplementary services and their general structure are next described using A SN .l notation (table 3). The method o f defining formats of signalling data for particular supplementary services is discussed. An example of real component encoding is depicted in the end (table 4).
