Wymagania techniczne i eksploatacyjne dla interfejsów umożliwiających wykonywanie zadań i obowiązków na rzecz obronności, bezpieczeństwa państwa oraz bezpieczeństwa i porządku publicznego.
Dz.U.2012.200
Akt obowiązującyROZPORZĄDZENIE
RADY MINISTRÓW
z dnia 20 stycznia 2012 r.
w sprawie wymagań technicznych i eksploatacyjnych dla interfejsów umożliwiających wykonywanie zadań i obowiązków na rzecz obronności, bezpieczeństwa państwa oraz bezpieczeństwa i porządku publicznego 1
ZAŁĄCZNIK 2
WYMAGANIA TECHNICZNE I EKSPLOATACYJNE
dla interfejsów umożliwiających wykonywanie zadań i obowiązków na rzecz obronności, bezpieczeństwa państwa oraz bezpieczeństwa i porządku publicznego
WYMAGANIA TECHNICZNE I EKSPLOATACYJNE
dla interfejsów umożliwiających wykonywanie zadań i obowiązków na rzecz obronności, bezpieczeństwa państwa oraz bezpieczeństwa i porządku publicznego
1.1. ETSI ES 201 671 V3.1.1 Lawful Interception (LI); Handover interface for the lawful interception of telecommunications traffic, zwany dalej "ETSI ES 201 671".
1.2. ETSI TS 102 232-1 V2.5.1 Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 1: Handover specification for IP delivery, zwany dalej "ETSI TS 102 2324".
1.3. ETSI TS 102 232-3 V2.2.1 Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 3: Service-specific details for internet access services, zwany dalej "ETSI TS 102 232-3".
1.4. ETSI TS 102 232-5 V2.5.1 Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 5: Service-specific details for IP Multimedia Services, zwany dalej "ETSI TS 102 232-5".
1.5. ETSI TS 102 232-6 V2.3.1 Lawful Interception (LI);Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 6: Service-specific details for PSTN/ISDN services, zwany dalej "ETSI TS 102 232-6".
1.6. ETSI TS 102 657 V1.7.1 Lawful Interception (LI); Retained data handling;Handover interface for the request and delivery of retained data, zwany dalej "ETSI TS 102 657".
1.7. ETSI ETS 300 927 Digital cellular telecommunications system (Phase 2+) (GSM); Numbering, addressing and identification (GSM 03.03 version 5.2.1 Release 1996), zwany dalej "ETSI ETS 300 927".
1.8. ETSI TS 102 280 V1.1.1 X.509 V.3 Certificate Profile for Certificates Issued to Natural Persons" (2004-03), zwany dalej "ETSI TS 102 280".
1.9 802.3ab-1999 - IEEE Standard for Local and Metropolitan Area Networks - Part 3 Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications - Physical Layer Parameters and Specifications for 1000 Mb/s Operation over 4 pair of Category 5 Balanced Copper Cabling, Type 1000BASE-T, zwany dalej "IEEE 802.3ab".
1.10. IETF RFC 0791 Internet Protocol, zwany dalej "IETF RFC 0791".
1.11. IETF RFC 0793 Transmission Control Protocol, zwany dalej "IETF RFC 0793".
1.12. IETF RFC 0959 File Transfer Protocol, zwany dalej "IETF RFC 0959".
1.13. IETF RFC 2315 Cryptographic Message Syntax, Version 1.5, zwany dalej "IETF RFC 2315".
1.14. IETF RFC 2460 Internet Protocol Version 6 (IPv6) Specification, zwany dalej "IETF RFC 2460".
1.15. IETF RFC 3852 Cryptographic Message Syntax (CMS), zwany dalej "IETF RFC 3852".
1.16. IETF RFC 3261 SIP: Session Initiation Protocol, zwany dalej "IETF RFC 3261".
1.17. IETF RFC 4291 Internet Protocol Version 6 (IPv6) Addressing Architecture, zwany dalej "IETF RFC 4291".
1.18. ITU-T X.680 Abstract Syntax Notation One (ASN.1): Specification of basic notation, zwany dalej "ITU-T X.680".
1.19. ITU-T X.681 Abstract Syntax Notation One (ASN.1): Information object specification, zwany dalej "ITU-T X.681".
1.20. ITU-T X.682 Abstract Syntax Notation One (ASN.1): Constrain specification, zwany dalej "ITU-T X.682".
1.21. ITU-T X.683 Abstract Syntax Notation One (ASN.1): Parameterization of ASN.1 specifications, zwany dalej "ITU-T X.683".
1.22. ITU-T X.690 ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), zwany dalej "ITU-T X.690".
II. Stosowane skróty
1. ADMF - system przedsiębiorcy telekomunikacyjnego umożliwiający realizację dostępu do wybranych treści przekazów telekomunikacyjnych (Administration Function).
2. ASCII - kod przyporządkowujący liczby, z zakresu od 0 do 127, literom alfabetu angielskiego, cyfrom, znakom przestankowym i innym symbolom oraz poleceniom sterującym (American Standard Code for Information Interchange).
3. ASN.1 - znormalizowany zapis składni stosowany do opisu struktur danych przenoszonych przez wiadomości wymieniane pomiędzy komunikującymi się elementami systemu (Abstract Syntax Notation One), zdefiniowany w ITU-T X.680, ITU-T X.681, ITU-T X.682 i ITU-T X.683.
4. BER - sposób kodowania informacji zapisanej przy użyciu notacji ASN.1 do postaci transmitowanej w sieciach telekomunikacyjnych (Basic Encoding Rules), zgodny z ITU-T X.690.
5. CC - treść przekazu telekomunikacyjnego (Content of Communication).
6. CMS - standard zabezpieczania wiadomości (Cryptographics Message Syntax), zdefiniowany w IETF RFC 3852.
7. CSD - transmisja danych z wykorzystaniem komutacji łączy (Circuit Switched Data).
8. CS - komutacja kanałów (Circuit Switched).
9. DER - sposób kodowania informacji (Distinguished Encoding Rules), zgodny z ITU-T X.690.
10. ESN - indywidualny numer identyfikujący telekomunikacyjne urządzenie końcowe używane w ruchomej publicznej sieci telefonicznej wykorzystującej technologię CDMA (Code Division Multiple Access) (Electronic Serial Number).
11. FTP - protokół transferu plików (File Transfer Protocol), zdefiniowany w IETF RFC 0959.
12. GLIC - mechanizm przekazywania treści monitorowanej komunikacji do LEMF, dotyczący monitorowania transmisji danych pakietowych w sieciach ruchomych (GPRS LI Correlation).
13. IMEI - indywidualny międzynarodowy numer identyfikacyjny telekomunikacyjne urządzenie końcowe używane w ruchomej publicznej sieci telefonicznej (International Mobile Equipment Identity).
14. IMSI - (International Mobile Subscriber Identity) - międzynarodowy numer przydzielony karcie identyfikującej użytkownika w ruchomej publicznej sieci telefonicznej.
15. IRI - informacje związane z przekazem telekomunikacyjnym (Intercept Related Information).
16. ISDN - sieć cyfrowa z integracją usług (Integrated Services Digital Network).
17. LEA - podmiot uprawniony do monitorowania (Law Enforcement Agency).
18. LEMF - system monitorowania uprawnionego podmiotu umożliwiający dostęp do wybranych treści przekazów telekomunikacyjnych (Law Enforcement Monitoring Facility).
19. LI HI - interfejs pomiędzy systemem monitorowania uprawnionego podmiotu a systemem przedsiębiorcy telekomunikacyjnego, wykorzystywany na potrzeby uprawnionego monitorowania (Lawful Interception Handover Interface).
20. LIID - identyfikator obiektu monitorowanego (Lawful Interception Identifier).
21. LOGIN - nazwa użytkownika logującego się do sieci, używana w procesie jego uwierzytelnienia.
22. MAC - sprzętowy adres karty sieciowej (Media Access Control).
23. MEID - unikalny numer identyfikujący telekomunikacyjne urządzenie końcowe używane w ruchomej publicznej sieci telefonicznej wykorzystującej technologię CDMA, zastępujący ESN (Mobile Equipment Identifier).
24. MSISDN - numer przydzielony użytkownikowi końcowemu ruchomej publicznej sieci telefonicznej z integracją usług (Mobile Subscriber Integrated Services Digital Network),
25. PKI - Infrastruktura Klucza Publicznego będąca systemem kryptograficznym, w którego skład wchodzą urzędy certyfikacyjne, użytkownicy certyfikatów (subskrybenci) oraz oprogramowanie i sprzęt (Public Key Infrastructure).
26. PSTN - publiczna komutowana sieć telefoniczna (Public Switched Telephone Network).
27. SIP - protokół sygnalizacyjny warstwy aplikacyjnej wykorzystywany do inicjowania, zarządzania oraz zakańczania sesji (połączenia telefonii internetowej, konferencji multimedialnej) (Session Initiation Protocol), zdefiniowany w IETF RFC 3261.
28. SMS - krótka wiadomość tekstowa (Short Message Service).
29. TCP - protokół komunikacji w sieci komputerowej (Transmission Control Protocol), zdefiniowany w IETF RFC 0793.
30. VoIP - telefonia internetowa (Voice over IP),
31. WAN - rozległa sieć komputerowa (Wide Area Network).
III. Określenia użyte w załączniku oznaczają:
IV. Interfejs LI HI
1.1. W warstwie fizycznej stosowany jest interfejs standardu Ethernet 100/1000BASE-T zgodny z IEEE 802.3ab. Do obsługi każdego z uprawnionych podmiotów przewidziany jest oddzielny port w standardzie Ethernet, z zastrzeżeniem pkt 1.8.
1.2. Protokołem warstwy sieciowej interfejsu LI HI jest protokół IPv4, zgodny z IETF RFC 0791, lub IPv6, zgodny z IETF RFC 2460 i IETF RFC 4291. Stosuje się publiczne adresy IP.
1.3. Sieć pomiędzy ADMF a LEMF jest siecią wydzieloną (w ramach sieci WAN), za którą odpowiada LEA. Wybór protokołu, o którym mowa w pkt 1.2, dostosowanie przesyłanych informacji oraz szyfrowanie sygnału na łączach sieci WAN leży w gestii LEA.
1.4. Szyfrowanie transmisji realizuje się poza interfejsem LI HI na poziomie warstwy łącza danych lub warstwy sieciowej.
1.5. W celu identyfikacji obiektów monitorowanych wykorzystuje się niepowtarzalny dla każdego obiektu numer LIID.
1.6. Dla każdej usługi w ramach danego kryterium wyboru, o którym mowa w pkt 2.4, przydzielany jest odrębny numer LIID. W przypadku monitorowania większej niż jedna liczby usług w ramach tego samego kryterium wyboru, dla każdej kolejnej usługi nadaje się unikalny numer LIID.
1.7. System LEMF w wiadomościach interfejsu LI HI używa poniżej zdefiniowanego formatu LIID. Numer LIID składa się z dwóch członów: LEAID + SEQ (kolejny niepowtarzalny numer). LIID jest utworzone z 17 znaków numerycznych ASCII od 0 do 9, w tym 2 cyfr określających LEAID oraz 15 cyfr wskazujących numer SEQ, zgodnie z tabelą nr 1. Wartość LEAID jest przydzielona każdemu LEA, zgodnie z tabelą nr 2.
Tabela nr 1
LIID |
LEAID + SEQ |
2 cyfry + 15 cyfr |
Np.: 01000300056043015 |
Tabela nr 2
LEAID | ||
Wartość | LEA | Opis |
00 | LEMF Operatora | Przedsiębiorca telekomunikacyjny |
01 | ABW | Agencja Bezpieczeństwa Wewnętrznego |
02 | Policja | Policja |
03 | SKW | Służba Kontrwywiadu Wojskowego |
04 | ZW | Żandarmeria Wojskowa |
05 | SG | Straż Graniczna |
06 | MF | Ministerstwo Finansów |
07 | CBA | Centralne Biuro Antykorupcyjne |
08 | SOP | Służba Ochrony Państwa |
09 | BNW | Biuro Nadzoru Wewnętrznego |
1.8. Dopuszcza się wykorzystanie jednego portu do obsługi więcej niż jednego uprawnionego podmiotu. Wykorzystanie takiego rozwiązania ustala się na etapie uzgadniania zasad współpracy poprzez interfejs pomiędzy przedsiębiorcą telekomunikacyjnym i zainteresowanymi LEA.
2.1. Interfejs HI1 zapewnia:
2.2. W celu aktywacji każdego zlecenia monitoringu, LEA określa:
2.3. Interfejs HI1 zapewnia następujące kryteria wyboru obiektu obserwacji w sieciach telekomunikacyjnych, stosownie do rodzaju sieci:
2.4. Interfejs HI1 zapewnia następujące kryteria wyboru monitorowanych usług, stosownie do rodzaju sieci:
2.5. Poprzez zakres monitorowania LEA wskazuje jeden z dwóch zakresów odnoszących się do danych:
2.6. Wysyłanie zleceń, aktywacji następuje w chwili rzeczywistego uruchamiania monitoringu albo z wyprzedzeniem. Maksymalne wyprzedzenie ustala się na etapie uzgadniania zasad współpracy poprzez interfejs. W zleceniu aktywacji określa się czas zakończenia monitorowania.
2.7. Zlecenie modyfikacji monitorowania obejmuje:
2.8. System monitoringu przedsiębiorcy telekomunikacyjnego przesyła do systemu LEMF informację o czasie faktycznego wykonania polecenia aktywacji, deaktywacji albo modyfikacji monitorowania. W przypadku błędu w trakcie wykonywania polecenia, przesyła informację o fakcie pojawienia się błędu lub braku możliwości wykonania polecenia.
2.9. Przedsiębiorca telekomunikacyjny przesyła do każdego z uprawnionych podmiotów informacje o objętych awarią numerach LIID, które znajdują się w jego dyspozycji.
2.10. Po usunięciu awarii, o której mowa w pkt 2.9, przedsiębiorca telekomunikacyjny niezwłocznie przesyła do uprawnionego podmiotu informacje o czasie trwania przerwy w monitorowaniu.
2.11. ADMF w odpowiedzi na pytanie o status obserwacji nie przesyła żadnych danych identyfikujących obiekt poza LIID.
2.12. Zlecenia wystawiane przez użytkownika LEMF, za wyjątkiem włączenia/wyłączenia trybu online oraz weryfikacji stanu obserwacji, są podpisywane elektronicznie.
2.13. Formatem stosowanego podpisu elektronicznego żądań HI1 jest CMS. Na potrzeby stosowania podpisu elektronicznego wykorzystywane są certyfikaty określone w ETSI TS 102 280, z uwzględnieniem wymagań technicznych zawartych w aktach wykonawczych wydanych na podstawie art. 10 ust. 4, art. 17 ust. 2 i art. 18 ust. 3 ustawy z dnia 18 września 2001 r. o podpisie elektronicznym (Dz. U. Nr 130, poz. 1450, z 2002 r. Nr 153, poz. 1271, z 2003 r. Nr 124, poz. 1152 i Nr 217, poz. 2125, z 2004 r. Nr 96, poz. 959, z 2005 r. Nr 64, poz. 565, z 2006 r. Nr 145, poz. 1050, z 2009 r. Nr 18, poz. 97, z 2010 r. Nr 40, poz. 230 i Nr 182, poz. 1228 oraz z 2011 r. Nr 106, poz. 622), oraz PKI.
2.14. Szczegółowa specyfikacja elementów interfejsu HI1 przedstawiona jest w pkt VI.
2.15. Za zgodą uprawnionego podmiotu dopuszcza się pracę interfejsu HI1 w trybie półautomatycznym, w którym pracownik przedsiębiorcy telekomunikacyjnego spełniający wymagania określone w art. 179 ust. 4b ustawy, po odebraniu zlecenia od LEMF wykonuje prace niezbędne do przygotowania sieci przedsiębiorcy telekomunikacyjnego do realizacji zlecenia. Czas na przeprowadzenie tych prac nie przekracza 24 godzin.
3.1. Informacje związane z objętymi monitorowaniem przekazami telekomunikacyjnymi przekazywane są do LEMF niezwłocznie, jednak nie później niż 10 minut od zakończenia przekazu. Raporty dotyczące zdarzeń występujących w danej sesji komunikacyjnej powinny być wysyłane w kolejności wystąpienia tych zdarzeń.
3.2. Przesyłanie do LEMF informacji związanych z objętymi monitorowaniem przekazami telekomunikacyjnymi odbywa się z wykorzystaniem protokołu FTP zdefiniowanym w IETF RFC 959 na zasadach określonych w ETSI ES 201 671.
3.3. Sesje FTP są nawiązywane tylko w kierunku od ADMF do LEMF w trybie pasywnym.
3.4. Do nazewnictwa plików wykorzystuje się Metodę A zdefiniowaną w ETSI ES 201 671 (Annex C, pkt C.2.2). Zgodnie z tą metodą nazwa pliku ma postać: <LIID>_<seq>.<ext>.
3.5. Nazwa przesyłanego pliku jest zmieniana na docelową po udanym nagraniu. Plik tymczasowy posiada dodatkowe rozszerzenie .tmp (<LIID>_<seq>.<ext>.tmp).
3.6. Zawartości plików (dane IRI) kodowane są w formacie ASN.1/BER zgodnie z:
3.7. Specyfikacja interfejsu HI2 jest rozszerzona o parametr ExtendedPartyIdentity. Specyfikacja struktur danych w notacji ASN.1 opisujących ten parametr znajduje się w pkt VII.
3.8. Przesyłany plik może zawierać wiele pojedynczych rekordów IRI, pod warunkiem że dotyczą one tego samego LIID.
3.9. Nie stosuje się agregacji wielu rekordów IRI w jednej strukturze ASN.1.
3.10. Wartości parametrów IRI definiuje się w formatach zalecanych przez normy telekomunikacyjne, które ich dotyczą (np. ISDN user part, DSS1, MAP, IP).
3.11. Po skutecznym przekazaniu rekordów IRI, system monitoringu przedsiębiorcy telekomunikacyjnego usuwa związane z nimi dane ze swoich zasobów.
3.12. Interfejs HI2 nie wymaga stosowania podpisu elektronicznego.
4.1. Rozpoczęcie przekazywania do LEMF treści objętych monitorowaniem następuje niezwłocznie, jednak nie później niż 10 minut od zakończenia przekazu.
4.2. Korelacja pomiędzy rekordami IRI (HI2) a przekazywaną treścią komunikacji CC (HI3) odbywa się z wykorzystaniem numeru LIID, a w przypadku usług sieci z komutacją kanałów również parametru CIN.
4.3. Do przekazywania treści komunikacji objętych monitorowaniem, dla usług sieci ruchomych stosuje się:
gdzie:
LIID - identyfikator celu LIID
CIN - Communication Identity Number
ext - rodzaj zawartej informacji, gdzie:
4.4. Dopuszcza się przekazywanie treści komunikacji objętej monitorowaniem, o których mowa w pkt 4.3, zgodnie z zasadami określonymi w ETSI TS 102 232-1 i ETSITS 102 232-6.
4.5. W przypadku usług transmisji pakietowej w sieci ruchomej, do przekazywania treści komunikacji objętych monitorowaniem stosuje się protokół GLIC z zastosowaniem zasad określonych w ETSI ES 201 671.
4.6. Przekazywanie treści komunikacji objętej monitorowaniem w sieci stacjonarnej jest realizowane zgodnie z zasadami określonymi w ETSI TS 102 232-1 i ETSI TS 102 232-6.
4.7. W przypadku usług dostępu do Internetu, przekazywanie treści komunikacji objętej monitorowaniem jest realizowane zgodnie z zasadami określonymi w ETSI TS 102 232-1 i ETSI TS 102 232-3.
4.8. W przypadku usług telefonii internetowej, przekazywanie treści komunikacji objętej monitorowaniem jest realizowane zgodnie z zasadami określonymi w ETSI TS 102 232-1 i ETSI TS 102 232-5.
4.9. Po skutecznym przekazaniu treści komunikatów do LEMF system monitoringu przedsiębiorcy telekomunikacyjnego usuwa je ze swoich zasobów.
4.10. Interfejs HI3 nie wymaga stosowania podpisu elektronicznego.
V. Interfejs HI A-B
Tabela nr 3
Punkt w normie ETSI TS 102 657 0 | Nazwa pola | |
dateOfBirth | ||
Table | A. 12: | gender |
IndividualInfo parameters | identificationNumber | |
authenticationInfo | ||
Profession | ||
subscriberID | ||
Table | B.3: | serviceID |
TelephonyBillingDetails parameters | billingAddress | |
billingIdentifier | ||
billingRecords | ||
Time | ||
Table | B.4: | Place |
BillingRecords parameters | amount | |
currency | ||
method | ||
Table | B.11: | postalLocation |
Location parameters | extendedLocation | |
subscriberID | ||
Table | D.3: | serviceID |
MultimediaBillingDetails parameters | billingAddress | |
billingIdentifier | ||
billingRecords | ||
Time | ||
Table | D.4: | Place |
MultimedaBillingRecords parameters | amount | |
currency | ||
method | ||
Table | E.3: | octetsDownloaded |
NAserviceUsage parameters | octetsUploaded | |
Table | E.8: | billingAddress |
NABillingDetails parameters | billingIdentifier | |
billingRecords |
VI. Struktura interfejsu HI1
1.1. Stosowany jest protokół TCP.
1.2. Zestawiane są połączenia TCP w kierunkach:
1.3. W ramach jednego połączenia TCP wysyłana jest jedna wiadomość warstwy aplikacyjnej (tj. żądanie, alarm), która jest potwierdzana przez drugą stronę (potwierdzenie otrzymania żądania, alarmu).
Wiadomości wysyłane w warstwie aplikacyjnej zostały zdefiniowane w notacji ASN.1 i są kodowane w standardzie BER lub DER.
2.1. Opis
2.1.1. Przeznaczenie: aktywacje, dezaktywacje i modyfikacje dedykacji, zapytania o dedykacje, alarmy, raporty, status interfejsu.
2.1.2. Stosowane są dwa protokoły zdefiniowane w ASN.1:
2.1.3. Operacje, o których mowa w pkt 2.1.2, są całkowicie od siebie niezależne.
2.1.4. Każda operacja/zapytanie to jedna sesja TCP.
2.1.5. Każde zapytanie jest potwierdzane przez drugą stronę.
2.2. Protokół HI1LEMFOperations
2.2.1. Operacje wykonywane przez LEMF:
2.2.2. Każda wiadomość definiująca zapytanie wysłane przez LEMF (Request) jest potwierdzana przez wiadomość zawierającą odpowiedź ADMF na wysłane żądanie LEMF (Respond), zgodnie ze schematem przedstawionym na rys. 1.
Rys. 1. Schemat operacji
2.2.3. LEMF czeka na odpowiedź 10 sekund. Po tym czasie uznaje wysłaną wiadomość za utraconą.
2.2.4. Nad harmonogramem aktywacji i dezaktywacji czuwa LEMF. Dopuszcza się wysłanie zlecenia aktywacji z wyprzedzeniem. Zlecenie aktywacji posiada określony czas zakończenia obserwacji. Przesunięcie momentu zakończenia obserwacji ponad ten czas wymaga zlecenia modyfikacji.
2.2.5. System monitoringu przedsiębiorcy telekomunikacyjnego przesyła do LEMF informacje o założeniu lub zdjęciu obserwacji w elementach sieci przedsiębiorcy telekomunikacyjnego.
2.2.6. LEMF ma możliwość zadania zapytania (ListRequest) służącego do weryfikacji stanu obserwacji.
2.2.7. Zlecenie dezaktywacji oznacza niezwłoczne zakończenie wskazanej obserwacji. W przypadku obserwacji, która się jeszcze nie rozpoczęła oznacza to, że w ogóle nie zostanie zrealizowana. Fakt jej założenia ma jednak zostać ze wszystkimi tego konsekwencjami odnotowany w logach systemu.
2.2.8. Modyfikacji podlegają jedynie zlecenia, które nie zakończyły się. Modyfikować można czasy zakończenia obserwacji oraz typ monitoringu (włączenie/wyłączenie online). Włączenie/wyłączenie obserwacji w trybie online nie powoduje zmian (zakłóceń) transmisji w trybie offline. Po rozpoczęciu obserwacji czas startu nie może być już modyfikowany.
2.2.9. Wiadomości są podzielone na dwie grupy:
2.2.10. Dopuszczalne są następujące interakcje pomiędzy LEMF a ADMF:
Zapytanie LEMF | Odpowiedź ADMF | Alternatywna odpowiedź |
SignedRequest | GeneralRespond | |
HelloRequest | GeneralRespond | |
ListRequest | ListRespond | GeneralRespond |
RTRequest | GeneralRespond |
2.2.11. Zapytania podpisane (SignedRequest)
Sposób tworzenia i weryfikacji wiadomości podpisanych za pomocą diagramów aktywności przedstawiony jest na rys. 2 i rys. 3.
Rys. 2. Tworzenie podpisanego zapytania
Rys. 3. Weryfikacja podpisanego zapytania
2.2.12. Uwagi:
OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } |
Struktura opisująca szczegóły zapytania aktywacji, modyfikacji i deaktywacji dedykacji. Po zakodowaniu do postaci DER jest podpisywana zgodnie ze specyfikacją przedstawioną w dokumencie IETF RFC 2315. Struktura UnsignedRequestDetail przedstawiona jest na rys. 6.
Obiekt reprezentujący usługi świadczone przez operatora.
2.3. Protokół HI1ADMFOperations
2.3.1 Operacje wykonywane przez ADMF:
2.3.2 Wiadomości są podzielone na dwie grupy, zgodnie ze schematem przedstawionym na rys. 4:
Rys. 4. Schemat operacji
2.3.3 Dopuszczalne są następujące interakcje pomiędzy ADMF a LEMF:
Wiadomość ADMF | Odpowiedź LEMF |
HelloRequest | GeneralRespond |
AlarmIndicator | GeneralRespond |
NotificationIndicator | GeneralRespond |
2.3.4 Uwagi:
3.1 Struktura HI1LEMFPDU
Rys. 5. Struktura HI1LEMFPDU
3.2 Specyfikacja ASN.1 dla HI1LEMFPDU
4.1. Struktura UnsignedRequestDetail
Rys. 6. Struktura UnsignedRequestDetail
4.2. Specyfikacja ASN.1 dla UnsignedRequestDetail
Dokumenty powiązane
Jeżeli chcesz mieć dostęp do wszystkich dokumentów powiązanych, zaloguj się do LEX-a Nie korzystasz jeszcze z programów LEX? Zamów dostęp testowy »