1448

Druk nr 1448 Warszawa, 30 pa!dziernika 2008 r. SEJM RZECZYPOSPOLITEJ POLSKIEJ VI kadencja Prezes Rady Ministrów RM 10-162-08 Pan Bronis"aw Komorowski Marsza"ek Sejmu Rzeczypospolitej Polskiej

Na podstawie art. 118 ust. 1 Konstytucji Rzeczypospolitej Polskiej z dnia 2 kwietnia 1997 r. przedstawiam Sejmowi Rzeczypospolitej Polskiej projekt ustawy

-

o zmianie ustawy - Prawo telekomunikacyjne oraz niektórych innych ustaw wraz z projektami aktów wykonawczych.

Projekt ma na celu wykonanie prawa Unii Europejskiej. W za"#czeniu przedstawiam tak$e opini% proponowanych regulacji z prawem Unii Europejskiej.

dotycz#c#

zgodno&ci

Ponadto uprzejmie informuj%, $e do prezentowania stanowiska Rz#du w tej sprawie w toku prac parlamentarnych zosta" upowa$niony Minister Infrastruktury.

(-) Donald Tusk

Projekt USTAWA z dnia o zmianie ustawy – Prawo telekomunikacyjne oraz niektórych innych ustaw1)2) Art. 1. W ustawie z dnia 16 lipca 2004 r. – Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800, z pó!n. zm.3)) wprowadza si% nast%puj#ce zmiany: 1) w art. 2 pkt 48 otrzymuje brzmienie: „48) us"uga telekomunikacyjna – us"ug% polegaj#c# g"ównie na przekazywaniu sygna"ów w sieci telekomunikacyjnej;”; 2) art. 6 otrzymuje brzmienie: „Art. 6. 1. Przedsi%biorca telekomunikacyjny lub podmiot, który uzyska" pozwolenie radiowe, rezerwacj% cz%stotliwo&ci lub zasobów orbitalnych lub przydzia" numeracji, z wy"#czeniem osób fizycznych i podmiotów, o których mowa w art. 4, jest obowi#zany do przekazywania na $#danie Prezesa UKE informacji niezb%dnych do wykonywania przez Prezesa jego uprawnie' i obowi#zków, okre&lonych w art. 192 ust. 1. 2. (#danie, o którym mowa w ust. 1, powinno by) proporcjonalne do celu, jakiemu ma s"u$y), oraz zawiera): 1) wskazanie Prezesa UKE oraz przedsi%biorcy lub podmiotu, o którym mowa w ust. 1; 2) dat% $#dania; 3) wskazanie $#danych informacji oraz okresu, których dotycz#; 4) wskazanie celu, jakiemu informacje maj# s"u$y);

1)

Niniejsza ustawa dokonuje w zakresie swojej regulacji wdro$enia dyrektywy 2006/24/WE Parlamentu Europejskiego i Rady z dnia 15 marca 2006 r. w sprawie zatrzymywania generowanych lub przetwarzanych danych w zwi#zku ze &wiadczeniem ogólnie dost%pnych us"ug "#czno&ci elektronicznej lub udost%pnianiem publicznych sieci "#czno&ci oraz zmieniaj#ca dyrektyw% 2002/58/WE (Dz. Urz. UE L 105 z 13.4.2006, str. 54). 2) Niniejsz# ustaw# zmienia si% ustawy: ustaw% z dnia 6 kwietnia 1990 r. o Policji, ustaw% z dnia 12 pa!dziernika 1990 r. o Stra$y Granicznej, ustaw% z dnia 28 wrze&nia 1991 r. o kontroli skarbowej, ustaw% z dnia 6 czerwca 1997 r. – Kodeks post%powania karnego, ustaw% z dnia 16 marca 2001 r. o Biurze Ochrony Rz#du, ustaw% z dnia 24 sierpnia 2001 r. o (andarmerii Wojskowej i wojskowych organach porz#dkowych, ustaw% z dnia 24 maja 2002 r. o Agencji Bezpiecze'stwa Wewn%trznego oraz Agencji Wywiadu, ustaw% z dnia 28 lutego 2003 r. – Prawo upad"o&ciowe i naprawcze, ustaw% z dnia 9 czerwca 2006 r. o Centralnym Biurze Antykorupcyjnym, ustaw% z dnia 9 czerwca 2006 r. o S"u$bie Kontrwywiadu Wojskowego oraz S"u$bie Wywiadu Wojskowego, ustaw% z dnia 26 kwietnia 2007 r. o zarz#dzaniu kryzysowym. 3) Zmiany wymienionej ustawy zosta"y og"oszone w Dz. U. z 2004 r. Nr 273, poz. 2703, z 2005 r. Nr 163, poz. 1362 i Nr 267, poz. 2258, z 2006 r. Nr 12, poz. 66, Nr 104, poz. 708 i 711, Nr 170, poz. 1217, Nr 220, poz. 1600, Nr 235, poz. 1700 i Nr 249, poz. 1834, z 2007 r. Nr 23, poz. 137, Nr 50, poz. 331 i Nr 82 poz. 556 oraz z 2008 r. Nr 17, poz. 101.

5) wskazanie terminu przekazania informacji adekwatnego do zakresu tego $#dania, nie krótszego ni$ 7 dni; 6) uzasadnienie; 7) pouczenie o karze, o której mowa w art. 209 ust. 1. 3. Prezes UKE mo$e zastosowa) do pozyskania informacji, o których mowa w ust. 1, opracowane przez siebie formularze, d#$#c do ujednolicenia i zapewnienia spójno&ci pozyskanych danych.”; 3) art. 8 otrzymuje brzmienie: „Art. 8. 1. Prezes UKE zapewnia dost%p do informacji otrzymanych od przedsi%biorców telekomunikacyjnych organom regulacyjnym innych pa'stw cz"onkowskich Unii Europejskiej oraz pa'stw cz"onkowskich Europejskiego Porozumienia o Wolnym Handlu (EFTA) – stronom umowy o Europejskim Obszarze Gospodarczym, zwanych dalej „pa'stwami cz"onkowskimi”, i Komisji Europejskiej, z wyj#tkiem przypadków okre&lonych w ustawie. 2. Prezes UKE informuje przedsi%biorc% telekomunikacyjnego o udost%pnieniu informacji dostarczonej uprzednio przez tego przedsi%biorc% na $#danie Prezesa UKE.”; 4) w art. 10: a) ust. 1 otrzymuje brzmienie: „1. Dzia"alno&) telekomunikacyjna b%d#ca dzia"alno&ci# gospodarcz# jest dzia"alno&ci# regulowan# i podlega wpisowi do rejestru przedsi%biorców telekomunikacyjnych, zwanego dalej „rejestrem”. Wpisowi do rejestru podlega równie$ dzia"alno&) telekomunikacyjna prowadzona przez przedsi%biorc% telekomunikacyjnego z pa'stwa cz"onkowskiego albo pa'stwa, które zawar"o ze Wspólnot# Europejsk# i jej pa'stwami cz"onkowskimi umow% reguluj#c#

swobod%

&wiadczenia

us"ug,

który

czasowo

&wiadczy

na

terytorium

Rzeczypospolitej Polskiej us"ugi na zasadach okre&lonych odpowiednio w przepisach Traktatu ustanawiaj#cego Wspólnot% Europejsk#, umowy o Europejskim Obszarze Gospodarczym albo w przepisach innej umowy reguluj#cej swobod% &wiadczenia us"ug.”, b) w ust. 4 pkt 4 otrzymuje brzmienie: „4) numer w rejestrze przedsi%biorców albo ewidencji dzia"alno&ci gospodarczej lub innym w"a&ciwym rejestrze w pa'stwie cz"onkowskim lub innym pa'stwie okre&lonym w ust. 1;”;

2

5) w art. 15 pkt 1 otrzymuje brzmienie: „1) okre&lenia rynku w"a&ciwego, o którym mowa w art. 22 ust. 1, a tak$e jego analizy i wyznaczenia przedsi%biorcy telekomunikacyjnego o znacz#cej pozycji rynkowej lub przedsi%biorców telekomunikacyjnych zajmuj#cych kolektywn# pozycj% znacz#c#, lub uchylenia decyzji w tej sprawie,”; 6) w art. 19 ust. 2 i 3 otrzymuj# brzmienie: „2. Je$eli w zakresie ustalenia znacz#cej pozycji rynkowej oraz w zakresie zamiaru zdefiniowania rynku w"a&ciwego innego ni$ rynki okre&lone w zaleceniu Komisji Europejskiej w sprawie w"a&ciwych rynków produktów i us"ug w sektorze "#czno&ci elektronicznej podlegaj#cych regulacji ex ante, zwanego dalej „zaleceniem Komisji”, Komisja Europejska stwierdzi, $e proponowane rozstrzygni%cie mo$e utrudni) rozwój jednolitego rynku lub mog"oby naruszy) prawo wspólnotowe, Prezes UKE po up"ywie terminu, o którym mowa w art. 16 ust. 2, zawiesza post%powanie na okres 2 miesi%cy. W przypadku otrzymania w tym okresie wezwania Komisji Europejskiej do wycofania projektu rozstrzygni%cia, Prezes UKE uwzgl%dnienia stanowisko Komisji Europejskiej i umarza post%powanie. 3. Prezes UKE uwzgl%dnia przy stosowaniu ustawy w najwi%kszym mo$liwie stopniu wytyczne Komisji Europejskiej w sprawie analizy rynku i ustalania znacz#cej pozycji rynkowej oraz zalecenie Komisji w ich aktualnym brzmieniu, a w przypadku odst#pienia od ich stosowania powiadamia Komisj% Europejsk#, uzasadniaj#c swe stanowisko.”; 7) w dziale II rozdzia" 1 otrzymuje brzmienie: „Rozdzia" 1 Analiza rynku, post%powanie w sprawie okre&lania rynków w"a&ciwych, nak"adania, zmiany i uchylenia obowi#zków regulacyjnych Art. 21. Prezes UKE przeprowadza analiz% rynku w zakresie wyrobów i us"ug telekomunikacyjnych. Art. 22. 1. Po przeprowadzeniu analizy, o której mowa w art. 21, nie rzadziej ni$ co 2 lata, a tak$e niezw"ocznie po wydaniu albo zmianie zalecenia Komisji Prezes UKE przeprowadza post%powanie w celu: 1) okre&lenia rynku w"a&ciwego, zgodnie z prawem konkurencji, w zakresie wyrobów i us"ug telekomunikacyjnych, zwanego dalej „rynkiem w"a&ciwym”, 3

2) ustalenia, czy na rynku w"a&ciwym wyst%puje przedsi%biorca telekomunikacyjny o znacz#cej pozycji rynkowej lub przedsi%biorcy telekomunikacyjni zajmuj#cy kolektywn# pozycj% znacz#c#, 3) wyznaczenia przedsi%biorcy telekomunikacyjnego o znacz#cej pozycji rynkowej lub przedsi%biorców telekomunikacyjnych zajmuj#cych kolektywn# pozycj% znacz#c#, w przypadku stwierdzenia, $e na rynku w"a&ciwym nie wyst%puje skuteczna konkurencja oraz 4) na"o$enia, utrzymania, zmiany lub uchylenia obowi#zków regulacyjnych na przedsi%biorc%

telekomunikacyjnego

o

znacz#cej

pozycji

rynkowej

lub

przedsi%biorców telekomunikacyjnych zajmuj#cych kolektywn# pozycj% znacz#c#. 2. Przez obowi#zek regulacyjny rozumie si% obowi#zek, o którym mowa w art. 34, 36 – 40, 42, 44 – 47 lub art. 72 ust. 3. Art. 23. 1. W przypadku ustalenia, $e na rynku w"a&ciwym nie wyst%puje przedsi%biorca telekomunikacyjny o znacz#cej pozycji rynkowej lub przedsi%biorcy telekomunikacyjni zajmuj#cy kolektywn# pozycj% znacz#c# Prezes UKE, po przeprowadzeniu post%powania, o którym mowa w art. 22 ust. 1, wydaje postanowienie, w którym: 1) okre&la rynek w"a&ciwy, maj#c na uwadze poziom rozwoju krajowego rynku produktów i us"ug telekomunikacyjnych, zgodnie z prawem konkurencji; 2) stwierdza, $e na tym rynku w"a&ciwym wyst%puje skuteczna konkurencja. 2. Do projektu postanowienia, o którym mowa w ust. 1, stosuje si% przepisy o post%powaniu konsultacyjnym. Art. 24. W przypadku ustalenia, $e na rynku w"a&ciwym wyst%puje przedsi%biorca telekomunikacyjny o znacz#cej pozycji rynkowej lub przedsi%biorcy telekomunikacyjni zajmuj#cy kolektywn# pozycj% znacz#c# Prezes UKE, po przeprowadzeniu post%powania, o którym mowa w art. 22 ust. 1, wydaje decyzj%, w której: 1) okre&la rynek w"a&ciwy, maj#c na uwadze poziom rozwoju krajowego rynku produktów i us"ug telekomunikacyjnych, zgodnie z prawem konkurencji; 2) wyznacza przedsi%biorc% telekomunikacyjnego o znacz#cej pozycji rynkowej lub przedsi%biorców telekomunikacyjnych zajmuj#cych kolektywn# pozycj% znacz#c# oraz:

4

a) nak"ada

obowi#zki

regulacyjne,

bior#c

pod

uwag%

adekwatno&)

i proporcjonalno&) danego obowi#zku do problemów rynkowych, których rozwi#zanie s"u$y realizacji celów okre&lonych w art. 1 ust. 2, albo b) utrzymuje

na"o$one

obowi#zki

regulacyjne,

je$eli

przedsi%biorca

telekomunikacyjny lub przedsi%biorcy telekomunikacyjni nie utracili tej pozycji, albo c) zmienia

na"o$one

obowi#zki

regulacyjne,

je$eli

przedsi%biorca

telekomunikacyjny lub przedsi%biorcy telekomunikacyjni nie utracili tej pozycji, ale zmiany na rynku w"a&ciwym uzasadniaj# zmian% tych obowi#zków. Art. 24a. 1. Je$eli przed wydaniem rozstrzygni%cia, o którym mowa w art. 23 ust. 1 albo w art. 24, na tym samym rynku w"a&ciwym wyst%powa" przedsi%biorca telekomunikacyjny o znacz#cej pozycji rynkowej lub przedsi%biorcy telekomunikacyjni zajmuj#cy kolektywn# pozycj% znacz#c#, którzy utracili t% pozycj%, Prezes UKE, w drodze decyzji, okre&la termin uchylenia obowi#zków regulacyjnych, tak aby uchylenie to uwzgl%dnia"o sytuacj% przedsi%biorców telekomunikacyjnych dzia"aj#cych na rynku obj%tych t# decyzj#, nie d"u$szy jednak ni$ przewidziane w umowach zawartych pomi%dzy przedsi%biorcami okresy wypowiedzenia umowy. 2. Decyzj%, o której mowa w ust. 1, og"asza si% na stronie podmiotowej Biuletynu Informacji Publicznej Urz%du Komunikacji Elektronicznej. Art. 25. 1. Przedsi%biorca telekomunikacyjny zajmuje znacz#c# pozycj% rynkow#, je$eli na rynku w"a&ciwym samodzielnie posiada pozycj% ekonomiczn# odpowiadaj#c# dominacji w rozumieniu przepisów prawa wspólnotowego. 2. Prezes UKE przy ocenie pozycji rynkowej przedsi%biorcy telekomunikacyjnego na rynku w"a&ciwym bierze pod uwag% kryteria wymienione w wytycznych Komisji, o których mowa w art. 19 ust. 3. 3. Dwóch lub wi%cej przedsi%biorców telekomunikacyjnych zajmuje kolektywn# pozycj% znacz#c#, je$eli nawet przy braku powi#za' organizacyjnych lub innych zwi#zków mi%dzy nimi posiadaj# na rynku w"a&ciwym pozycj% ekonomiczn# odpowiadaj#c# dominacji w rozumieniu przepisów prawa wspólnotowego. 4.

Prezes

UKE

przy

ustalaniu,

czy

dwóch

lub

wi%cej

przedsi%biorców

telekomunikacyjnych zajmuje kolektywn# znacz#c# pozycj% na rynku w"a&ciwym ocenia 5

cechy rynku w"a&ciwego, w szczególno&ci udzia" przedsi%biorców w rynku

oraz

jego

przejrzysto&), a je$eli ocena tych cech nie wskazuje na brak kolektywnej pozycji znacz#cej dodatkowo stosuje w szczególno&ci nast%puj#ce kryteria: 1) dojrza"o&) rynku, 2) zastój albo umiarkowany wzrost popytu, 3) nisk# elastyczno&) popytu, 4) jednorodno&) produktów, 5) podobne struktury kosztów przedsi%biorców, 6) brak innowacji technologicznych, dojrza"o&) technologii, 7) brak mo$liwo&ci zwi%kszenia produkcji lub &wiadczenia us"ug, 8) wysokie bariery dost%pu do rynku, 9) brak równowa$#cej si"y nabywczej, 10) brak potencjalnej konkurencji, 11) ró$nego rodzaju nieformalne lub inne powi#zania pomi%dzy danymi przedsi%biorcami, 12) brak albo ograniczenie konkurencji cenowej, 13) mo$liwo&) stosowania mechanizmów odwetowych – które nie musz# by) spe"nione "#cznie. Art. 25a. W przypadku okre&lenia rynku w"a&ciwego odbiegaj#cego od zalecenia Komisji Prezes UKE poddaje projekt rozstrzygni%cia, o którym mowa w art. 23 ust. 1 albo w art. 24, post%powaniu konsolidacyjnemu. Art. 25b. Rozstrzygni%cie, o którym mowa w art. 23 ust. 1 albo w art. 24: 1) wydaje si% po zasi%gni%ciu opinii Prezesa UOKiK wydanej w formie postanowienia; 2) og"asza si% na stronie podmiotowej Biuletynu Informacji Publicznej Urz%du Komunikacji Elektronicznej. Art. 25c. W przypadku rynku w"a&ciwego uznanego decyzj# Komisji Europejskiej za rynek ponadnarodowy Prezes UKE przeprowadza jego analiz% w porozumieniu z organami regulacyjnymi innych pa'stw cz"onkowskich. Przepis art. 23 lub 24 stosuje si% odpowiednio.”; 8) w art. 34 w ust. 2 pkt 12 otrzymuje brzmienie:

6

„12) &wiadczeniu us"ug telekomunikacyjnych z uwzgl%dnieniem pierwsze'stwa zgodnie z art. 176a ust. 2 pkt 3.”; 9) art. 56 otrzymuje brzmienie: „Art. 56. 1. *wiadczenie us"ug telekomunikacyjnych odbywa si% na podstawie umowy o &wiadczenie us"ug telekomunikacyjnych. 2. Umow% o &wiadczenie us"ug telekomunikacyjnych zawiera si% w formie pisemnej. Wymóg formy pisemnej nie dotyczy umowy o &wiadczenie us"ug telekomunikacyjnych zawieranych przez dokonanie czynno&ci faktycznych obejmuj#cych w szczególno&ci umowy o &wiadczenie us"ug telefonicznych za pomoc# aparatu publicznego lub przez wybranie numeru dost%pu do sieci dostawcy us"ug. 3. Umowa o &wiadczenie us"ug telekomunikacyjnych, z zastrze$eniem ust. 5, powinna okre&la) w szczególno&ci: 1) strony umowy, w tym nazw% (firm%), adres i siedzib% dostawcy us"ug; 2) rodzaj &wiadczonych us"ug; 3) termin oczekiwania na przy"#czenie do sieci lub termin rozpocz%cia &wiadczenia us"ug; 4) okres, na jaki zosta"a zawarta umowa; 5) pakiet taryfowy, je$eli na &wiadczone us"ugi obowi#zuj# ró$ne pakiety taryfowe; 6) sposób sk"adania zamówie' na pakiety taryfowe oraz dodatkowe opcje us"ugi; 7) okres rozliczeniowy; 8) tryb i warunki dokonywania zmian umowy oraz warunki jej przed"u$enia; 9) zakres &wiadczonych publicznie dost%pnych us"ug telekomunikacyjnych, ze wskazaniem elementów sk"adaj#cych si% na op"at% abonamentow#; 10) dane dotycz#ce jako&ci us"ug; 11) zakres obs"ugi serwisowej; 12) sposób i termin rozwi#zania umowy; 13) zakres odpowiedzialno&ci z tytu"u niewykonania lub nienale$ytego wykonania umowy, wysoko&) odszkodowania oraz zasady i terminy jego wyp"aty; 14) zasady, tryb i terminy sk"adania oraz rozpatrywania reklamacji; 15) informacj% o polubownych sposobach rozwi#zywania sporów; 16) sposób uzyskania informacji o aktualnym cenniku us"ug oraz kosztach us"ug serwisowych.

7

4. Umowa o zapewnienie przy"#czenia do publicznej sieci telekomunikacyjnej poza elementami, o których mowa w ust. 3, powinna okre&la) numer przydzielony abonentowi, a w przypadku przy"#czenia do publicznej stacjonarnej sieci telefonicznej tak$e adres zako'czenia sieci. 5. Dane, o których mowa w ust. 3 pkt 9-16, na podstawie wyra!nego postanowienia umowy, mog# by) zawarte w regulaminie &wiadczenia publicznie dost%pnych us"ug telekomunikacyjnych.”; 10) w art. 57: a) ust. 4 otrzymuje brzmienie: „4. Przepisów ust. 2 i 3 nie stosuje si% do umów o &wiadczenie us"ug telekomunikacyjnych zawieranych przez dokonanie czynno&ci faktycznych, o których mowa w art. 56 ust. 2.”, b) ust. 6 otrzymuje brzmienie: „6. W przypadku zawarcia umowy o &wiadczenie us"ug telekomunikacyjnych, w tym o zapewnienie przy"#czenia do publicznej sieci telekomunikacyjnej, zwi#zanego z ulg# przyznan# abonentowi, wysoko&) roszczenia z tytu"u jednostronnego rozwi#zania umowy przez abonenta lub przez dostawc% us"ug z winy abonenta przed up"ywem terminu ustalonego w umowie nie mo$e przekroczy) warto&ci ulgi przyznanej abonentowi pomniejszonej o proporcjonaln# jej warto&) za okres od dnia zawarcia umowy do dnia jej rozwi#zania.”; 11) w art. 59 ust. 2 otrzymuje brzmienie: „2. Przepis ust. 1 stosuje si% do u$ytkowników ko'cowych us"ugi przedp"aconej &wiadczonej w ruchomej publicznej sieci telefonicznej.”; 12) art. 60 otrzymuje brzmienie: „Art. 60. Regulamin &wiadczenia us"ug dostawcy publicznie dost%pnych us"ug telekomunikacyjnych dla u$ytkowników ko'cowych us"ugi przedp"aconej &wiadczonej w ruchomej publicznej sieci telefonicznej powinien okre&la) w szczególno&ci: 1) nazw% (firm%), adres i siedzib% dostawcy us"ug; 2) zakres &wiadczonych publicznie dost%pnych us"ug telekomunikacyjnych, ze wskazaniem elementów sk"adaj#cych si% na op"at% za &wiadczenie us"ug;

8

3) standardowe warunki umowy, w tym wskazanie minimalnego czasu trwania umowy, je$eli taki zosta" okre&lony; 4) zakres obs"ugi serwisowej; 5) zakres odpowiedzialno&ci z tytu"u niewykonania lub nienale$ytego wykonania umowy, wysoko&) odszkodowania oraz zasady i terminy jego wyp"aty; 6) zasady, tryb i terminy sk"adania oraz rozpatrywania reklamacji; 7) sposób uzyskania informacji o aktualnym cenniku us"ug oraz kosztach us"ug serwisowych.”; 13) po art. 60 dodaje si% art. 60a w brzmieniu: „Art. 60a. 1. Dostawca publicznie dost%pnych us"ug telekomunikacyjnych: 1) dor%cza abonentowi na pi&mie tre&) ka$dej proponowanej zmiany warunków umowy, o której mowa w art. 56 ust. 3, 2) dor%cza abonentowi na pi&mie oraz podaje do publicznej wiadomo&ci tre&) ka$dej proponowanej zmiany warunków umowy okre&lonych w regulaminie, o którym mowa w art. 59 ust. 1, oraz 3) podaje do publicznej wiadomo&ci tre&) ka$dej proponowanej zmiany warunków umowy okre&lonych w regulaminie, o którym mowa w art. 60 – z wyprzedzeniem co najmniej jednego okresu rozliczeniowego przed wprowadzeniem tych zmian w $ycie. Jednocze&nie abonent powinien zosta) poinformowany o prawie wypowiedzenia umowy w przypadku braku akceptacji zmian w regulaminie. 2. W razie skorzystania z prawa wypowiedzenia umowy w przypadku braku akceptacji niekorzystnej dla abonenta zmiany w umowie lub regulaminie, dostawcy publicznie dost%pnych us"ug telekomunikacyjnych nie przys"uguje roszczenie odszkodowawcze, a tak$e zwrot ulgi, o której mowa w art. 57 ust. 6, o czym abonent powinien zosta) tak$e poinformowany. Je$eli proponowane zmiany dotycz# warunków umowy, o których mowa w art. 56 ust. 3, a abonent nie skorzysta" z prawa wypowiedzenia umowy, warunki umowy pozostaj# bez zmian. 3. Przepisu ust. 2 nie stosuje si%, je$eli konieczno&) wprowadzenia zmian, o których mowa w ust. 1, nast%puje na skutek zmiany przepisów prawa.”; 14) w art. 61: a) ust. 5 i 6 otrzymuj# brzmienie:

9

„5. Dostawca publicznie dost%pnych us"ug telekomunikacyjnych dor%cza abonentowi na pi&mie oraz podaje do publicznej wiadomo&ci tre&) ka$dej zmiany w cenniku, z wyprzedzeniem co najmniej jednego okresu rozliczeniowego przed wprowadzeniem tych zmian w $ycie. Jednocze&nie abonent powinien zosta) poinformowany o prawie wypowiedzenia umowy w przypadku braku akceptacji zmiany w cenniku. 6. W przypadku, o którym mowa w ust. 5, abonent powinien zosta) poinformowany tak$e o tym, $e w razie skorzystania z prawa wypowiedzenia umowy w przypadku braku akceptacji podwy$szenia cen dostawcy publicznie dost%pnych us"ug telekomunikacyjnych nie przys"uguje roszczenie odszkodowawcze, a tak$e zwrot ulgi, o której mowa w art. 57 ust. 6.”, b) po ust. 6 dodaje si% ust. 6a w brzmieniu: „6a. Przepisu ust. 6 nie stosuje si%, je$eli konieczno&) wprowadzenia zmiany, o której mowa w ust. 5, nast%puje na skutek zmiany przepisów prawa.”; 15) w art. 71 dodaje si% ust. 4 i 5 w brzemieniu: „4. Prezes UKE prowadzi baz% danych zawieraj#c# przeniesione numery, o których mowa w ust. 1. 5. Operator publicznej sieci telefonicznej jest obowi#zany po"#czy) t% sie) bezpo&rednio lub za po&rednictwem publicznej sieci telefonicznej innego operatora z baz# danych, o której mowa w ust. 4. Operator publicznej sieci telefonicznej jest obowi#zany dokonywa) na bie$#co aktualizacji bazy danych, o której mowa w ust. 4.”; 16) w art. 153 w ust. 4 uchyla si% pkt 5 – 7; 17) w art. 159 w ust. 1 pkt 5 otrzymuje brzmienie: „5) dane o próbach uzyskania po"#czenia mi%dzy zako'czeniami sieci, w tym dane o nieudanych

próbach

po"#cze',

oznaczaj#cych

po"#czenia

mi%dzy

telekomunikacyjnymi urz#dzeniami ko'cowymi lub zako'czeniami sieci, które zosta"y zestawione i nie zosta"y odebrane przez u$ytkownika ko'cowego lub nast#pi"o przerwanie zestawionych po"#cze'.”; 18) w art. 161 w ust. 2 pkt 6 otrzymuje brzmienie:

10

„6) nazwy, serii i numeru dokumentów potwierdzaj#cych to$samo&), a w przypadku cudzoziemca, który nie jest obywatelem pa'stwa cz"onkowskiego albo Konfederacji Szwajcarskiej – numeru paszportu lub karty pobytu;”; 19) w art. 165: a) uchyla si% ust. 1, b) ust. 5 otrzymuje brzmienie: „5. Do przetwarzania danych transmisyjnych, zgodnie z ust. 2-4, uprawnione s# podmioty dzia"aj#ce z upowa$nienia operatorów publicznych sieci telekomunikacyjnych i dostawców publicznie dost%pnych us"ug telekomunikacyjnych, zajmuj#ce si% naliczaniem op"at, zarz#dzaniem ruchem w sieciach telekomunikacyjnych, obs"ug# klienta, systemem wykrywania

nadu$y)

finansowych,

marketingiem

us"ug

telekomunikacyjnych

lub

&wiadczeniem us"ug o warto&ci wzbogaconej. Podmioty te mog# przetwarza) dane transmisyjne wy"#cznie dla celów niezb%dnych przy wykonywaniu tych dzia"a'.”; 20) w art. 166 uchyla si% ust. 5; 21) w art. 169 w ust. 1 wprowadzenie do wyliczenia otrzymuje brzmienie: „Dane osobowe posiadane przez przedsi%biorc% telekomunikacyjnego zawarte w publicznie dost%pnym spisie abonentów, zwanym dalej „spisem”, wydawanym w formie ksi#$kowej lub elektronicznej, a tak$e udost%pniane za po&rednictwem s"u$b informacyjnych przedsi%biorcy telekomunikacyjnego powinny by) ograniczone do:”; 22) w art. 171: a) ust. 2 i 3 otrzymuj# brzmienie: „2. Dostawca us"ug &wiadczonych w publicznej sieci telefonicznej umo$liwiaj#cej prezentacj% identyfikacji linii wywo"uj#cej jest obowi#zany zapewni), za pomoc# prostych &rodków: 1) u$ytkownikowi wywo"uj#cemu – mo$liwo&) jednorazowego wyeliminowania prezentacji identyfikacji linii wywo"uj#cej u u$ytkownika wywo"ywanego podczas wywo"ania i po"#czenia; 2) abonentowi wywo"uj#cemu – mo$liwo&) sta"ego wyeliminowania prezentacji identyfikacji linii wywo"uj#cej u u$ytkownika wywo"ywanego podczas wywo"ania 11

i po"#czenia, u operatora, do którego sieci jest przy"#czony abonent b%d#cy stron# umowy z dostawc# us"ug; 3) abonentowi wywo"ywanemu – mo$liwo&) eliminacji dla po"#cze' przychodz#cych prezentacji identyfikacji linii wywo"uj#cej, a je$eli taka prezentacja jest dost%pna przed rozpocz%ciem po"#czenia przychodz#cego, tak$e mo$liwo&) blokady po"#cze' przychodz#cych od abonenta lub u$ytkownika stosuj#cego eliminacj% prezentacji identyfikacji linii wywo"uj#cej. 3. Dostawca us"ug &wiadczonych w publicznej sieci telefonicznej zapewniaj#cej prezentacj% identyfikacji zako'czenia sieci, do której zosta"o przekierowane po"#czenie, zwan# dalej „prezentacj# identyfikacji linii wywo"ywanej”, jest obowi#zany zapewni) abonentowi wywo"ywanemu mo$liwo&) eliminacji, za pomoc# prostych &rodków, prezentacji identyfikacji linii wywo"ywanej u u$ytkownika wywo"uj#cego.”, b) ust. 8 otrzymuje brzmienie: „8. Przedsi%biorcy telekomunikacyjni s# obowi#zani do zapewnienia s"u$bom ustawowo powo"anym do niesienia pomocy dost%pu do identyfikacji linii wywo"uj#cej oraz danych dotycz#cych

lokalizacji,

bez

uprzedniej

zgody

zainteresowanych

abonentów

lub

u$ytkowników, je$eli jest to konieczne do umo$liwienia tym s"u$bom wykonywania ich zada' w mo$liwie najbardziej efektywny sposób.”, c) ust. 10 otrzymuje brzmienie: „10. Dane, o których mowa w ust. 9, pozostaj# w dyspozycji przedsi%biorcy telekomunikacyjnego. Do ich udost%pniania stosuje si% art. 180d.”; 23) art. 176 otrzymuje brzmienie: „Art. 176. Przedsi%biorca telekomunikacyjny jest obowi#zany do wykonywania zada' i obowi#zków na rzecz obronno&ci, bezpiecze'stwa pa'stwa oraz bezpiecze'stwa i porz#dku publicznego w zakresie i na warunkach okre&lonych w niniejszej ustawie oraz w przepisach odr%bnych.”; 24) po art. 176 dodaje si% art. 176a w brzmieniu: „Art. 176a. 1. Przedsi%biorca telekomunikacyjny, w celu zapewnienia ci#g"o&ci &wiadczenia us"ug telekomunikacyjnych lub dostarczania sieci telekomunikacyjnej, jest obowi#zany uwzgl%dnia) mo$liwo&) wyst#pienia: 12

1) sytuacji kryzysowych, 2) stanów nadzwyczajnych, 3) bezpo&rednich zagro$e' dla infrastruktury przedsi%biorcy – zwanych dalej „sytuacjami szczególnych zagro$e'”. 2. Przedsi%biorca telekomunikacyjny, z zastrze$eniem ust. 5 pkt 2, jest obowi#zany posiada) aktualne i uzgodnione plany dzia"a' w sytuacjach szczególnych zagro$e', zwane dalej „planami”, dotycz#ce w szczególno&ci: 1) wspó"pracy z innymi przedsi%biorcami telekomunikacyjnymi; 2) wspó"pracy z zagranicznymi operatorami telekomunikacyjnymi, a w szczególno&ci pa'stw s#siaduj#cych; 3) wspó"pracy z podmiotami i s"u$bami wykonuj#cymi zadania w zakresie ratownictwa, niesienia pomocy ludno&ci, a tak$e zadania na rzecz obronno&ci, bezpiecze'stwa pa'stwa oraz bezpiecze'stwa i porz#dku publicznego oraz z podmiotami w"a&ciwymi w sprawach zarz#dzania kryzysowego, wskazanymi w ramach uzgodnie' planów, o których mowa w ust. 3, przez organy uzgadniaj#ce plany; 4) zabezpieczenia

infrastruktury

telekomunikacyjnej w sytuacjach szczególnych

zagro$e' oraz przed nieuprawnionym dost%pem; 5) utrzymania ci#g"o&ci, a w przypadku jej utraty, odtwarzania: a) &wiadczenia us"ug telekomunikacyjnych, b) dostarczania sieci telekomunikacyjnej – z uwzgl%dnieniem pierwsze'stwa dla podmiotów i s"u$b, o których mowa w pkt 3; 6) technicznych i organizacyjnych przygotowa', w przypadku wprowadzenia ogranicze' w dzia"alno&ci telekomunikacyjnej przewidzianych ustaw#; 7) sposobu udost%pniania urz#dze' telekomunikacyjnych, o którym mowa w art. 177 ust. 3, przez przedsi%biorców telekomunikacyjnych; 8) ewidencji i gromadzenia rezerw przedsi%biorcy lub wspó"pracy z dostawcami sprz%tu oraz us"ug serwisowych i naprawczych. 3. Z zastrze$eniem ust. 5 pkt 1 lit. c, przedsi%biorca telekomunikacyjny sporz#dzaj#cy plany dokonuje uzgodnienia ich zawarto&ci z organami, o których mowa w ust. 5 pkt 1 lit. b. 4. Po stwierdzeniu wyst#pienia sytuacji szczególnych zagro$e' lub po uzyskaniu informacji o ich wyst#pieniu od podmiotów lub s"u$b, o których mowa w ust. 2 pkt 3, przedsi%biorca telekomunikacyjny podejmuje niezw"ocznie dzia"ania okre&lone w planach.

13

5. Rada Ministrów, maj#c na uwadze zakres i rodzaj wykonywanej dzia"alno&ci telekomunikacyjnej, wielko&) przedsi%biorcy telekomunikacyjnego i jego znaczenie dla gospodarki, obronno&ci, bezpiecze'stwa pa'stwa oraz bezpiecze'stwa i porz#dku publicznego, a tak$e wymagania, o których mowa w ust. 2, w drodze rozporz#dzenia: 1) okre&li: a) rodzaje planów, ich zawarto&) oraz tryb sporz#dzania i aktualizacji, b) organy uzgadniaj#ce plany oraz zakres tych uzgodnie', c) rodzaje przedsi%biorców telekomunikacyjnych obowi#zanych do uzgadniania zawarto&ci planów; 2) mo$e okre&li) rodzaje dzia"alno&ci telekomunikacyjnej lub rodzaje przedsi%biorców telekomunikacyjnych niepodlegaj#cych obowi#zkowi sporz#dzania planu.”; 25) w art. 177: a) uchyla si% ust. 1 i 2, b) ust. 3 – 5 otrzymuj# brzmienie: „3. Przedsi%biorca telekomunikacyjny w sytuacjach szczególnych zagro$e' jest obowi#zany do nieodp"atnego udost%pniania urz#dze' telekomunikacyjnych niezb%dnych do przeprowadzenia akcji ratowniczej innemu przedsi%biorcy telekomunikacyjnemu, podmiotowi i s"u$bie, o których mowa w art. 176a ust. 2 pkt 3, z zachowaniem zasady minimalizowania negatywnych skutków takiego udost%pnienia tych urz#dze' dla ci#g"o&ci wykonywania dzia"alno&ci telekomunikacyjnej przez przedsi%biorc%. 4. Podmioty, w tym nieb%d#ce przedsi%biorcami telekomunikacyjnymi, u$ywaj#ce radiowe

urz#dzenia

nadawcze

lub

nadawczo-odbiorcze

stosowane

w

s"u$bach

radiokomunikacyjnych, w sytuacjach szczególnych zagro$e' s# obowi#zane do nieodp"atnego udost%pniania urz#dze' telekomunikacyjnych niezb%dnych do przeprowadzenia akcji ratowniczej podmiotom koordynuj#cym dzia"ania ratownicze, podmiotom w"a&ciwym w sprawach zarz#dzania kryzysowego, s"u$bom ustawowo powo"anym do niesienia pomocy, a tak$e innym podmiotom realizuj#cym zadania na rzecz obronno&ci, bezpiecze'stwa pa'stwa oraz bezpiecze'stwa i porz#dku publicznego. 5. Przepisy ust. 3 i 4 stosuje si% odpowiednio podczas przeprowadzania akcji ratowniczej o zasi%gu mi%dzynarodowym, co najmniej w zakresie ustalonym umowami mi%dzynarodowymi, których Rzeczpospolita Polska jest stron#.”,

14

c) dodaje si% ust. 6 w brzmieniu: „6. Rada Ministrów okre&li, w drodze rozporz#dzenia, tryb nieodp"atnego udost%pniania radiowych urz#dze' nadawczych lub nadawczo-odbiorczych stosowanych w s"u$bach radiokomunikacyjnych przez podmioty nieb%d#ce przedsi%biorcami telekomunikacyjnymi, maj#c na uwadze konieczno&) zachowania zasady minimalizowania negatywnych skutków udost%pniania tych urz#dze'.”; 26) w art. 178: a) w ust. 1 pkt 1 otrzymuje brzmienie: „1) utrzymania ci#g"o&ci lub odtwarzania: a) dostarczania sieci telekomunikacyjnej, b) &wiadczenia us"ug telekomunikacyjnych – z uwzgl%dnieniem pierwsze'stwa dla podmiotów i s"u$b, o których mowa w ust. 2 pkt 1;”, b) ust. 2 i 3 otrzymuj# brzmienie: „2. Decyzja Prezesa UKE, o której mowa w ust. 1: 1) wydawana jest z urz%du lub na wniosek podmiotów koordynuj#cych dzia"ania ratownicze, podmiotów w"a&ciwych w sprawach zarz#dzania kryzysowego, s"u$b ustawowo powo"anych do niesienia pomocy, a tak$e innych podmiotów realizuj#cych zadania na rzecz obronno&ci, bezpiecze'stwa pa'stwa oraz bezpiecze'stwa i porz#dku publicznego; 2) mo$e by) og"oszona ustnie, bez uzasadnienia, w ca"o&ci lub cz%&ci, je$eli wymagaj# tego wzgl%dy obronno&ci, bezpiecze'stwa pa'stwa oraz bezpiecze'stwa i porz#dku publicznego. 3. W przypadkach i na zasadach okre&lonych w przepisach odr%bnych Komendant G"ówny Policji, komendant wojewódzki Policji, Komendant G"ówny Stra$y Granicznej, komendant Oddzia"u Stra$y Granicznej, Komendant G"ówny (andarmerii Wojskowej, komendant Oddzia"u (andarmerii Wojskowej, Szef Agencji Bezpiecze'stwa Wewn%trznego, Szef S"u$by Kontrwywiadu Wojskowego oraz Szef Biura Ochrony Rz#du mog# zarz#dzi) o zastosowaniu urz#dze' uniemo$liwiaj#cych telekomunikacj% na okre&lonym obszarze.”; 27) w art. 179: a) uchyla si% ust. 1, 15

b) ust. 3 otrzymuje brzmienie: „3. Przedsi%biorca telekomunikacyjny, z zastrze$eniem ust. 12 pkt 2, jest obowi#zany do: 1) zapewnienia warunków technicznych i organizacyjnych dost%pu i utrwalania, zwanych dalej „warunkami dost%pu i utrwalania”, umo$liwiaj#cych jednoczesne i wzajemnie niezale$ne: a) uzyskiwanie przez Policj%, Stra$ Graniczn#, Agencj% Bezpiecze'stwa Wewn%trznego, S"u$b% Kontrwywiadu Wojskowego, (andarmeri% Wojskow#, Centralne

Biuro

Antykorupcyjne

i

wywiad

skarbowy,

zwane

dalej

„uprawnionymi podmiotami”, w sposób okre&lony w ust. 4b, dost%pu do: – tre&ci rozmów telefonicznych i innych informacji przekazywanych za pomoc#

sieci

telekomunikacyjnych,

zwanych

dalej

„przekazami

telekomunikacyjnymi”, nadawanych lub odbieranych przez u$ytkownika ko'cowego lub urz#dzenie ko'cowe, – posiadanych przez przedsi%biorc% danych zwi#zanych z przekazami telekomunikacyjnymi, o których mowa w ust. 9, art. 159 ust. 1 pkt 1 i pkt 3-5, b) uzyskiwanie przez uprawnione podmioty danych zwi#zanych ze &wiadczon# us"ug# telekomunikacyjn# i danych, o których mowa w art. 161, c) utrwalanie przez uprawnione podmioty przekazów telekomunikacyjnych i danych, o których mowa w lit. a i b; 2) utrwalania na rzecz s#du i prokuratora przekazów telekomunikacyjnych i danych, o których mowa w pkt 1 lit. a i b.”, c) po ust. 3 dodaje si% ust. 3a i 3b w brzmieniu: „3a. Przedsi%biorca telekomunikacyjny zapewnia, na w"asny koszt, warunki dost%pu i utrwalania w zakresie wszystkich &wiadczonych us"ug telekomunikacyjnych, pocz#wszy od dnia rozpocz%cia dzia"alno&ci telekomunikacyjnej, a w przypadku rozpocz%cia &wiadczenia nowej us"ugi telekomunikacyjnej od dnia jej uruchomienia. 3b. Przedsi%biorca telekomunikacyjny zapewnia, na w"asny koszt, utrwalanie na rzecz s#du lub prokuratora przekazów telekomunikacyjnych i danych, o których mowa w ust. 3 pkt 1 lit. a i b.”, d) ust. 4 otrzymuje brzmienie:

16

„4. Przedsi%biorca telekomunikacyjny zapewnia warunki dost%pu i utrwalania z zachowaniem wymaga' okre&lonych w rozporz#dzeniu, o którym mowa w ust. 12.”, e) po ust. 4 dodaje si% ust. 4a – 4c w brzmieniu: „4a. Warunki dost%pu i utrwalania mog# by) zapewniane za pomoc# interfejsów zlokalizowanych w miejscach obejmowanych przez sie) przedsi%biorcy telekomunikacyjnego na zasadach okre&lonych w umowach zawartych przez uprawnione podmioty z przedsi%biorc# telekomunikacyjnym. Umowa mo$e okre&la) wspó"udzia" stron w kosztach zastosowania interfejsów. W przypadku braku uzgodnie' w zakresie lokalizacji interfejsu uprawnione podmioty wskazuj# miejsce lokalizacji pozostaj#ce w obr%bie sieci telekomunikacyjnej przedsi%biorcy telekomunikacyjnego, umo$liwiaj#ce: techniczn# realizacj% interfejsu, niezb%dn# ochron% tego miejsca wynikaj#c# z przepisów odr%bnych oraz minimalizacj% nak"adów ponoszonych przez przedsi%biorc% telekomunikacyjnego i podmioty uprawnione. 4b. Zapewnienie warunków dost%pu i utrwalania powinno umo$liwia) uprawnionym podmiotom dost%p do przekazów telekomunikacyjnych i danych bez udzia"u pracowników przedsi%biorcy telekomunikacyjnego. Za zgod# uprawnianego podmiotu warunki dost%pu i utrwalania mog# by) zapewnione przy niezb%dnym wspó"udziale upowa$nionych pracowników przedsi%biorcy telekomunikacyjnego gwarantuj#cych prawid"ow# realizacj% przedmiotowych czynno&ci w zakresie okre&lonym przez uprawniony podmiot. 4c. Dopuszcza si% mo$liwo&) zapewnienia warunków dost%pu i utrwalania przez dwóch lub wi%cej przedsi%biorców telekomunikacyjnych za pomoc# tych samych interfejsów. Szczegó"owe zasady wspó"pracy przedsi%biorców telekomunikacyjnych w tym zakresie reguluj# umowy zawarte pomi%dzy nimi. Przed zawarciem umowy przedsi%biorcy telekomunikacyjni uzgadniaj# warunki techniczne i eksploatacyjne z uprawnionymi podmiotami. Zawarcie umowy nie zwalnia jej stron z indywidualnej odpowiedzialno&ci za zapewnienie warunków dost%pu i utrwalania.”, f) uchyla si% ust. 5, g) ust. 6 otrzymuje brzmienie: „6. Prezes UKE, na uzasadniony wniosek przedsi%biorcy telekomunikacyjnego, po uzyskaniu, w terminie okre&lonym w art. 106 Kodeksu post%powania administracyjnego zgody uprawnionych podmiotów, mo$e, w ca"o&ci lub w cz%&ci, w drodze decyzji, zawiesi) na okres nie d"u$szy ni$ 6 miesi%cy, obowi#zek zapewnienia warunków dost%pu i utrwalania. 17

Wniosek sk"ada si% w terminie nie d"u$szym ni$ 14 dni od dnia wyst#pienia zdarzenia, o którym mowa w zdaniu pierwszym. Do wniosku do"#cza si% harmonogram osi#gni%cia przez przedsi%biorc% telekomunikacyjnego pe"nej zdolno&ci do wykonywania obowi#zku.” , h) po ust. 6 dodaje si% ust. 6a i 6b w brzmieniu: „6a. Przepisu ust. 6 nie stosuje si% do przedsi%biorcy telekomunikacyjnego rozpoczynaj#cego dzia"alno&) telekomunikacyjn# lub rozpoczynaj#cego &wiadczenie nowej us"ugi telekomunikacyjnej. 6b. Z"o$enie wniosku lub zawieszenie obowi#zku zapewnienia warunków dost%pu i utrwalania nie zwalnia przedsi%biorcy telekomunikacyjnego z obowi#zku zapewnienia warunków dost%pu i utrwalania, w zakresie posiadanych mo$liwo&ci technicznych, organizacyjnych i finansowych.”, i) ust. 7 i 8 otrzymuj# brzmienie: „7. Przedsi%biorca telekomunikacyjny mo$e powierzy), w drodze umowy, innemu przedsi%biorcy telekomunikacyjnemu zapewnienie warunków dost%pu i utrwalania. Powierzenie to nie zwalnia powierzaj#cego z odpowiedzialno&ci za zapewnienie warunków dost%pu i utrwalania. 8. Przedsi%biorca telekomunikacyjny jest obowi#zany do wskazania Prezesowi UKE: 1) jednostki organizacyjnej lub osoby maj#cej siedzib% lub miejsce zamieszkania na terytorium

Rzeczypospolitej

Polskiej

uprawnionej

do

reprezentowania

tego

przedsi%biorcy w sprawach zwi#zanych z zapewnieniem warunków dost%pu i utrwalania; 2) przedsi%biorcy telekomunikacyjnego, który b%dzie w jego imieniu zapewnia" warunki dost%pu i utrwalania; 3) przedsi%biorcy telekomunikacyjnego, wspólnie z którym b%dzie zapewnia" warunki dost%pu i utrwalania za pomoc# tych samych interfejsów.”, j) po ust. 8 dodaje si% ust. 8a w brzmieniu: „8a. W przypadku zmiany danych podmiotów, o których mowa w ust. 8, przedsi%biorca telekomunikacyjny jest obowi#zany poinformowa) Prezesa UKE o tych zmianach.”, k) ust. 10 otrzymuje brzmienie:

18

„10. Prezes UKE przekazuje niezw"ocznie informacje, o których mowa w ust. 8 i 8a, Ministrowi Sprawiedliwo&ci, Ministrowi Obrony Narodowej, ministrowi w"a&ciwemu do spraw wewn%trznych, ministrowi w"a&ciwemu do spraw finansów publicznych, Szefowi Agencji Bezpiecze'stwa Wewn%trznego, Szefowi Centralnego Biura Antykorupcyjnego, Szefowi S"u$by Kontrwywiadu Wojskowego, a tak$e ministrowi, którego zakres zada' obejmuje koordynowanie dzia"alno&ci s"u$b specjalnych – je$eli zosta" powo"any.”, l) uchyla si% ust. 11, m) dodaje si% ust. 12 w brzmieniu: „12. Rada Ministrów okre&li, w drodze rozporz#dzenia: 1) wymagania i sposób zapewnienia warunków dost%pu i utrwalania, o których mowa w ust. 3 i art. 180d, z wy"#czeniem spraw uregulowanych w art. 242 Kodeksu post%powania karnego, kieruj#c si% zasad# osi#gania celu przy jak najni$szych nak"adach; 2) rodzaje

dzia"alno&ci

telekomunikacyjnej

lub

rodzaje

przedsi%biorców

telekomunikacyjnych niepodlegaj#cych obowi#zkowi zapewnienia warunków dost%pu i utrwalania, o których mowa w ust. 3 i art. 180d, kieruj#c si% zakresem i rodzajem &wiadczonych us"ug telekomunikacyjnych lub wielko&ci# sieci telekomunikacyjnych przedsi%biorców.”; 28) po art. 180 dodaje si% art. 180a – 180g w brzmieniu: „Art. 180a. 1. Z zastrze$eniem art. 180c ust. 2 pkt 2, operator publicznej sieci telekomunikacyjnej oraz dostawca publicznie dost%pnych us"ug telekomunikacyjnych s# obowi#zani na w"asny koszt: 1) zatrzymywa) i przechowywa) dane, o których mowa w art. 180c, generowane w sieci telekomunikacyjnej lub przez nich przetwarzane, na terytorium Rzeczypospolitej Polskiej, przez okres 24 miesi%cy, licz#c od dnia po"#czenia lub nieudanej próby po"#czenia, a z dniem up"ywu tego okresu dane te niszczy); 2) udost%pnia) dane, o których mowa w pkt 1, uprawnionym podmiotom, a tak$e s#dowi i prokuratorowi, na zasadach i w trybie okre&lonym w przepisach odr%bnych; 3) chroni) dane, o których mowa w pkt 1, przed przypadkowym lub bezprawnym zniszczeniem,

utrat#

lub

zmian#,

nieuprawnionym

lub

bezprawnym

19

przechowywaniem, przetwarzaniem, dost%pem lub ujawnieniem, zgodnie z przepisami art. 159 – 175 i art. 180e. 2. Z zastrze$eniem ust. 3, obowi#zek, o którym mowa w ust. 1, uwa$a si% za wykonany, je$eli operator publicznej sieci telekomunikacyjnej lub dostawca publicznie dost%pnych us"ug telekomunikacyjnych w przypadku zaprzestania dzia"alno&ci telekomunikacyjnej, przeka$e dane do dalszego przechowywania, udost%pniania oraz ochrony innemu operatorowi publicznej

sieci

telekomunikacyjnej

lub

dostawcy

publicznie

dost%pnych

us"ug

telekomunikacyjnych. 3. Je$eli og"oszono upad"o&) operatora publicznej sieci telekomunikacyjnej lub dostawcy publicznie dost%pnych us"ug telekomunikacyjnych, upad"y operator lub dostawca ma obowi#zek przekazania danych, o których mowa w ust. 1, do dalszego przechowywania, udost%pniania oraz ochrony Prezesowi UKE. 4. Prezes Rady Ministrów okre&li, w drodze rozporz#dzenia, sposób przekazywania Prezesowi UKE danych w przypadku, o którym mowa w ust. 3, oraz sposób udost%pniania przez Prezesa UKE tych danych podmiotom, o których mowa w ust. 1 pkt 2, w celu zapewnienia realizacji zada' przez te podmioty. 5. Obowi#zkowi, o którym mowa w ust. 1, podlegaj# dane dotycz#ce po"#cze' zrealizowanych i nieudanych prób po"#cze', o których mowa w art. 159 ust. 1 pkt 5. 6. Obowi#zek, o którym mowa w ust. 1, powinien by) realizowany w sposób, który nie powoduje ujawniania przekazu telekomunikacyjnego. 7. Udost%pnianie danych, o którym mowa w ust. 1 pkt 1, mo$e nast#pi) za pomoc# sieci telekomunikacyjnej, chyba $e przepisy odr%bne stanowi# inaczej. Art. 180b. 1. Obowi#zek, o którym mowa w art. 180a ust. 1, mo$e by) wykonywany wspólnie przez dwóch lub wi%cej operatorów publicznej sieci telekomunikacyjnej lub dostawców publicznie dost%pnych us"ug telekomunikacyjnych. 2. Operator publicznej sieci telekomunikacyjnej lub dostawca publicznie dost%pnych us"ug telekomunikacyjnych mo$e powierzy) realizacj% obowi#zku, o którym mowa w art. 180a ust. 1, w drodze umowy, innemu przedsi%biorcy telekomunikacyjnemu. Powierzenie to nie zwalnia powierzaj#cego z odpowiedzialno&ci za realizacj% tego obowi#zku. Art. 180c. 1. Obowi#zkiem, o którym mowa w art. 180a ust. 1, obj%te s# dane niezb%dne do: 20

1) ustalenia

zako'czenia

sieci,

telekomunikacyjnego

urz#dzenia

ko'cowego

i u$ytkownika ko'cowego: a) inicjuj#cego po"#czenie, b) do którego kierowane jest po"#czenie; 2) okre&lenia: a) daty i godziny po"#czenia telefonicznego oraz czasu jego trwania, b) rodzaju po"#czenia telefonicznego, c) lokalizacji

telekomunikacyjnego

urz#dzenia

ko'cowego

u$ywanego

w ruchomej publicznej sieci telefonicznej, dotycz#cej po"#czenia lub próby uzyskania po"#czenia. 2. Minister w"a&ciwy do spraw "#czno&ci w porozumieniu z ministrem w"a&ciwym do spraw wewn%trznych, maj#c na uwadze rodzaj wykonywanej dzia"alno&ci telekomunikacyjnej przez operatorów publicznej sieci telekomunikacyjnej lub dostawców publicznie dost%pnych us"ug telekomunikacyjnych, dane okre&lone w ust. 1, koszty pozyskania i utrzymania danych oraz potrzeb% unikania wielokrotnego zatrzymywania i przechowywania tych samych danych, okre&li, w drodze rozporz#dzenia: 1) szczegó"owy wykaz danych, o których mowa w ust. 1; 2) rodzaje operatorów publicznej sieci telekomunikacyjnej lub dostawców publicznie dost%pnych

us"ug

telekomunikacyjnych

obowi#zanych

do

zatrzymywania

i przechowywania tych danych. Art. 180d. Przedsi%biorcy telekomunikacyjni s# obowi#zani do zapewnienia warunków dost%pu i utrwalania oraz do udost%pniania uprawnionym podmiotom na w"asny koszt, a tak$e s#dowi i prokuratorowi, przetwarzanych przez siebie danych, o których mowa w art. 159 ust. 1 pkt 1 i pkt 3-5, w art. 161 oraz w art. 179 ust. 9, zwi#zanych ze &wiadczon# us"ug# telekomunikacyjn#, na zasadach i przy zachowaniu procedur okre&lonych w przepisach odr%bnych. Art. 180e. W celu ochrony danych, o której mowa w art. 180a ust. 1 pkt 3, przedsi%biorca telekomunikacyjny stosuje w"a&ciwe &rodki techniczne i organizacyjne oraz zapewnia dost%p do tych danych jedynie upowa$nionym pracownikom. Art. 180f. 1. Przedsi%biorca telekomunikacyjny jest obowi#zany dostarcza) Prezesowi UKE dane dotycz#ce infrastruktury telekomunikacyjnej eksploatowanej lub u$ywanej przez 21

tego przedsi%biorc%, niezb%dnej do przygotowania systemów "#czno&ci na potrzeby obronne pa'stwa, w tym systemu kierowania bezpiecze'stwem narodowym, i aktualizowa) niezw"ocznie po ka$dej zmianie. 2. Dane, o których mowa w ust. 1, s# gromadzone w bazie danych utworzonej i zarz#dzanej przez Prezesa UKE. Baz% aktualizuje si% niezw"ocznie po ka$dej zmianie danych. 3. Minister w"a&ciwy do spraw "#czno&ci okre&li, w drodze rozporz#dzenia, szczegó"owy zakres danych, o których mowa w ust 1, form% i tryb ich dostarczania oraz aktualizacji, maj#c na uwadze warunki i sposób przygotowania oraz wykorzystania systemów "#czno&ci na potrzeby obronne pa'stwa, bezpiecze'stwo przekazywanych danych oraz zapewnienie ich jednorodnej postaci. Art. 180g. 1. Przedsi%biorca telekomunikacyjny, w terminie do dnia 31 stycznia, sk"ada Prezesowi UKE, za rok poprzedni informacje o: 1) liczbie przypadków, w których uprawnionym podmiotom, s#dowi i prokuratorowi by"y udost%pnione dane, o których mowa w art. 180a ust. 1; 2) czasie, jaki up"yn#" mi%dzy dat# zatrzymania danych a dat# z"o$enia przez podmioty, o których mowa w pkt 1, wniosku lub ustnego $#dania o ich udost%pnienie; 3) przypadkach, w których wniosek lub ustne $#danie, o którym mowa w pkt 2, nie móg" by) zrealizowany. 2. Prezes UKE przekazuje corocznie Komisji Europejskiej informacje, o których mowa w ust. 1. 3. Minister w"a&ciwy do spraw "#czno&ci okre&li, w drodze rozporz#dzenia, wzór formularza s"u$#cego do przekazywania informacji Prezesowi UKE, kieruj#c si% potrzeb# przekazania Komisji Europejskiej pe"nej i rzetelnej informacji.”; 29) uchyla si% art. 181; 30) art. 182 otrzymuje brzmienie: „Art. 182. Rada Ministrów okre&li, w drodze rozporz#dzenia, wymagania techniczne i eksploatacyjne dla interfejsów, o których mowa w art. 179 ust. 4a, umo$liwiaj#cych wykonywanie zada' i obowi#zków na rzecz obronno&ci, bezpiecze'stwa pa'stwa oraz bezpiecze'stwa i porz#dku publicznego, o których mowa w art. 179 ust. 3 i w art. 180d,

22

kieruj#c si% zasad# minimalizacji nak"adów przedsi%biorcy telekomunikacyjnego i podmiotów uprawnionych.”; 31) tytu" dzia"u X otrzymuje brzmienie: „DZIA+ X Administracja "#czno&ci i post%powanie przed Prezesem UKE”; 32) w art. 190: a) ust. 2 otrzymuje brzmienie: „2. Prezes UKE sk"ada ministrowi w"a&ciwemu do spraw "#czno&ci coroczne sprawozdanie

ze

swojej

dzia"alno&ci

regulacyjnej

oraz

realizacji

polityki

rz#du

i wspólnotowej polityki telekomunikacyjnej, za rok poprzedni, w terminie do dnia 30 kwietnia. Minister w"a&ciwy do spraw "#czno&ci opiniuje sprawozdanie w terminie 1 miesi#ca od dnia jego przedstawienia przez Prezesa UKE i przekazuje sprawozdanie wraz z opini# Prezesowi Rady Ministrów. Negatywna opinia stanowi podstaw% do z"o$enia przez Prezesa Rady Ministrów wniosku o odwo"anie Prezesa UKE.”, b) po ust. 2 dodaje si% ust. 2a w brzmieniu: „2a. Prezes UKE przekazuje ministrowi w"a&ciwemu do spraw "#czno&ci, na jego $#danie, informacje o swojej dzia"alno&ci.”, c) ust. 4 otrzymuje brzmienie: „4. Prezesa UKE powo"uje i odwo"uje Sejm za zgod# Senatu na wniosek Prezesa Rady Ministrów. Kadencja Prezesa UKE trwa 5 lat. Po up"ywie kadencji Prezes UKE pe"ni swoj# funkcj% do czasu powo"ania nast%pcy.”, d) po ust. 4 dodaje si% ust. 4a w brzmieniu: „4a. Prezes UKE mo$e by) odwo"any przed up"ywem kadencji, na któr# zosta" powo"any, wy"#cznie w przypadku: 1) ra$#cego naruszenia prawa; 2) skazania prawomocnym wyrokiem s#du za pope"nione umy&lnie przest%pstwo lub przest%pstwo skarbowe; 3) orzeczenia zakazu zajmowania kierowniczych stanowisk lub pe"nienia funkcji zwi#zanych ze szczególn# odpowiedzialno&ci# w organach pa'stwa; 4) choroby trwale uniemo$liwiaj#cej wykonywanie zada'; 5) z"o$enia rezygnacji; 6) nierealizowania przez Prezesa UKE celów, o których mowa w art. 1 ust. 2.”; 23

33) w art. 192 w ust. 1 po pkt 5 dodaje si% pkt 5a – 5c w brzmieniu: „5a) kontrolowanie realizacji obowi#zków wynikaj#cych z przepisów rozporz#dzenia WE nr 717/2007 Parlamentu Europejskiego i Rady z dnia 27 czerwca 2007 r. w sprawie roamingu w publicznych sieciach telefonii ruchomej wewn#trz Wspólnoty oraz zmieniaj#cego dyrektyw% 2002/21/WE (Dz. Urz. WE L 171 z 29.06.2007, str. 32); 5b) wykonywanie kontroli nad operatorami publicznej sieci telekomunikacyjnej i dostawcami publicznie dost%pnych us"ug telekomunikacyjnych w zakresie realizacji obowi#zków, o których mowa w art. 180a ust. 1, z wyj#tkiem realizacji obowi#zków dotycz#cych danych osobowych chronionych zgodnie z przepisami o ochronie danych osobowych; 5c) prowadzenie baz danych, o których mowa w art. 71 ust. 4 oraz w art. 180f ust. 2;”; 34) w art. 206 ust. 2 – 2b otrzymuj# brzmienie: „2. Od decyzji w sprawach o ustalenie znacz#cej pozycji rynkowej, na"o$enia, zniesienia lub zmiany obowi#zków regulacyjnych, na"o$enia kar oraz od decyzji wydawanych w sprawach spornych, z wyj#tkiem decyzji w sprawie rezerwacji cz%stotliwo&ci po przeprowadzeniu przetargu albo konkursu oraz od decyzji o uznaniu przetargu albo konkursu za nierozstrzygni%ty, przys"uguje odwo"anie do S#du Okr%gowego w Warszawie – s#du ochrony konkurencji i konsumentów. 2a. Decyzje, o których mowa w ust. 2, z wyj#tkiem decyzji w sprawie na"o$enia kar i zniesienia obowi#zków regulacyjnych, podlegaj# natychmiastowemu wykonaniu. 2b. Na postanowienie, o którym mowa w art. 23, przys"uguje za$alenie do S#du Okr%gowego w Warszawie – s#du ochrony konkurencji i konsumentów.”; 35) w art. 209 w ust. 1: a) po pkt 13 dodaje si% punkt 13a w brzmieniu: „13a) nie wype"nia lub nienale$ycie wype"nia obowi#zki okre&lone w art. 56 ust. 5, art. 57 ust. 6, art. 60, art. 60a ust. 2 i art. 61 ust. 6,”, b) dodaje si% pkt 28 i 29 w brzmieniu: „28) nie wype"nia obowi#zków wynikaj#cych z art. 180g, 29) nie wype"nia obowi#zków okre&lonych w art. 3-6 rozporz#dzenia WE nr 717/2007 Parlamentu Europejskiego i Rady z dnia 27 czerwca 2007 r. w sprawie roamingu w

publicznych

sieciach

telefonii

ruchomej

wewn#trz

Wspólnoty

oraz

zmieniaj#cego dyrektyw% 2002/21/WE”; 24

36) u$yte w art. 34 ust. 1, art. 36, art. 37 ust. 1, art. 38 ust. 1, art. 39 ust. 1, art. 40 ust. 1, art. 42 ust. 1 oraz art. 43 ust. 3 wyrazy „art. 25 ust. 4” zast%puje si% wyrazami „art. 24 pkt 2 lit. a”; 37) u$yte w art. 46 ust. 1, art. 72 ust. 3, art. 134, art. 192 ust. 1 pkt 18, art. 206 ust. 2b wyrazy „art. 23” zast%puje si% wyrazami „art. 23 i 24”. Art. 2. W ustawie z dnia 6 kwietnia 1990 r. o Policji (Dz. U. z 2007 r. Nr 43, poz. 277, z pó!n. zm.4)) wprowadza si% nast%puj#ce zmiany: 1) po art. 18b dodaje si% art. 18c w brzmieniu: „Art. 18c. 1. W przypadkach, o których mowa w art. 18 ust. 1, Komendant G"ówny Policji lub komendant wojewódzki Policji mo$e zarz#dzi) zastosowanie przez Policj% urz#dze' uniemo$liwiaj#cych telekomunikacj% na okre&lonym obszarze, przez czas niezb%dny do wyeliminowania zagro$enia lub jego skutków, z uwzgl%dnieniem konieczno&ci minimalizacji skutków braku mo$liwo&ci korzystania z us"ug telekomunikacyjnych. 2. O zastosowaniu urz#dze', o których mowa w ust. 1, Komendant G"ówny Policji lub komendant wojewódzki Policji niezw"ocznie informuje Prezesa Urz%du Komunikacji Elektronicznej.”; 2) w art. 20c: a) ust. 1 i 2 otrzymuj# brzmienie: „1. W celu zapobiegania lub wykrywania przest%pstw Policja mo$e mie) udost%pniane dane, o których mowa w art. 180c i 180d ustawy z dnia 16 lipca 2004 r. – Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800, z pó!n. zm.3)), zwane dalej „danymi telekomunikacyjnymi”, oraz mo$e je przetwarza). 2. Podmiot prowadz#cy dzia"alno&) telekomunikacyjn# udost%pnia nieodp"atnie dane telekomunikacyjne: 1) policjantowi wskazanemu w pisemnym wniosku Komendanta G"ównego Policji lub komendanta wojewódzkiego Policji albo osoby przez nich upowa$nionej; 4)

Zmiany tekstu jednolitego wymienionej ustawy zosta"y og"oszone w Dz. U. z 2007 r. Nr 57, poz. 390, Nr 120, poz. 818, Nr 140, poz. 981 i Nr 165, poz. 1170 oraz z 2008 r. Nr 86, poz. 521 i Nr 171, poz. 1065.

25

2) na ustne $#danie policjanta posiadaj#cego pisemne upowa$nienie osób, o których mowa w pkt 1; 3) za po&rednictwem sieci telekomunikacyjnej policjantowi posiadaj#cemu pisemne upowa$nienie osób, o których mowa w pkt 1.”,

b) po ust. 2 dodaje si% ust. 2a w brzmieniu: „2a. W przypadku, o którym mowa w ust. 2 pkt 3, udost%pnianie danych telekomunikacyjnych odbywa si% bez udzia"u pracowników podmiotu prowadz#cego dzia"alno&) telekomunikacyjn# lub przy niezb%dnym ich udziale, je$eli mo$liwo&) taka jest przewidziana w porozumieniu zawartym pomi%dzy Komendantem G"ównym Policji a tym podmiotem.”,

c) uchyla si% ust. 3 i 4,

d) ust. 5 otrzymuje brzmienie: „5. Udost%pnienie Policji danych telekomunikacyjnych mo$e nast#pi) za po&rednictwem sieci telekomunikacyjnej je$eli: 1) wykorzystywane sieci telekomunikacyjne zapewniaj#: a) mo$liwo&) ustalenia osoby uzyskuj#cej dane, ich rodzaju oraz czasu, w którym zosta"y uzyskane, b) zabezpieczenie

techniczne

i

organizacyjne

uniemo$liwiaj#ce

osobie

nieuprawnionej dost%p do danych; 2) jest to uzasadnione specyfik# lub zakresem zada' wykonywanych przez jednostki organizacyjne Policji albo prowadzonych przez nie czynno&ci.”, e) uchyla si% ust. 8.

26

Art. 3. W ustawie z dnia 12 pa!dziernika 1990 r. o Stra$y Granicznej (Dz. U. z 2005 r. Nr 234, poz. 1997, z pó!n. zm.5)) wprowadza si% nast%puj#ce zmiany: 1) w art. 10b ust. 1 – 4 otrzymuj# brzmienie: „1. W celu zapobiegania lub wykrywania przest%pstw Stra$ Graniczna mo$e mie) udost%pniane dane, o których mowa w art. 180c i 180d ustawy z dnia 16 lipca 2004 r. – Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800, z pó!n. zm.3)), zwane dalej „danymi telekomunikacyjnymi”, w trybie: 1) pisemnego wniosku Komendanta G"ównego Stra$y Granicznej lub komendanta oddzia"u Stra$y Granicznej albo osoby przez nich upowa$nionej, 2) ustnego $#dania funkcjonariusza posiadaj#cego pisemne upowa$nienie osób, o których mowa w pkt 1, 3) za po&rednictwem sieci telekomunikacyjnej funkcjonariuszowi posiadaj#cemu pisemne upowa$nienie osób, o których mowa w pkt 1, oraz mo$e przetwarza) te dane. 2. W przypadku, o którym mowa w ust. 1 pkt 3, udost%pnianie danych telekomunikacyjnych odbywa si% bez udzia"u pracowników podmiotu prowadz#cego dzia"alno&) telekomunikacyjn# lub przy niezb%dnym ich udziale, je$eli mo$liwo&) tak# przewiduje porozumienie zawarte pomi%dzy Komendantem G"ównym Stra$y Granicznej a tym podmiotem. 3. Podmiot wykonuj#cy dzia"alno&) telekomunikacyjn# udost%pnia nieodp"atnie dane telekomunikacyjne, funkcjonariuszowi wskazanemu we wniosku w"a&ciwego organu Stra$y Granicznej lub funkcjonariuszowi, o którym mowa w ust. 1 pkt 2 i 3. 4. Udost%pnienie Stra$y Granicznej danych telekomunikacyjnych mo$e nast#pi) przy pomocy sieci, je$eli: 1) wykorzystywane sieci telekomunikacyjne zapewniaj#: a) mo$liwo&) ustalenia osoby uzyskuj#cej dane, ich rodzaju oraz czasu, w którym zosta"y uzyskane, b) zabezpieczenie

techniczne

i

organizacyjne

uniemo$liwiaj#ce

osobie

nieuprawnionej dost%p do danych; 5)

Zmiany tekstu jednolitego wymienionej ustawy zosta"y og"oszone w Dz. U. z 2005 r. Nr 90, poz. 757, z 2006 r. Nr 104 poz. 708 i 711 i Nr 170, poz. 1218, z 2007 r. Nr 57, poz. 390 i Nr 82, poz. 558 oraz z 2008 r. Nr 86, poz. 521.

27

2) jest to uzasadnione specyfik# lub zakresem wykonywanych przez jednostki organizacyjne Stra$y Granicznej zada' albo prowadzonych przez nie czynno&ci.”; 2) po art. 10c dodaje si% art. 10d w brzmieniu: „Art. 10d. 1. W celu realizacji zada', o których mowa w art. 1 ust. 2 pkt 1, 2, 4-5d i 10 Komendant G"ówny Stra$y Granicznej lub komendant oddzia"u Stra$y Granicznej mo$e zarz#dzi) o zastosowaniu urz#dze' uniemo$liwiaj#cych telekomunikacj% na okre&lonym obszarze, przez czas niezb%dny do wykonywania czynno&ci przez Stra$ Graniczn#, z uwzgl%dnieniem konieczno&ci minimalizacji skutków braku mo$liwo&ci korzystania z us"ug telekomunikacyjnych. 2. O zastosowaniu urz#dze', o których mowa w ust. 1, Komendant G"ówny Stra$y Granicznej lub komendant oddzia"u Stra$y Granicznej niezw"ocznie informuje Prezesa Urz%du Komunikacji Elektronicznej.”. Art. 4. W ustawie z dnia 28 wrze&nia 1991 r. o kontroli skarbowej (Dz. U. z 2004 r. Nr 8, poz. 65, z pó!n. zm.6)) wprowadza si% nast%puj#ce zmiany: 1) art. 36b otrzymuje brzmienie: „1. W celu zapobiegania lub wykrywania przest%pstw skarbowych lub przest%pstw, o których mowa w art. 3 pkt 4 i 5, wywiad skarbowy mo$e mie) udost%pniane dane: 1) o których mowa w art. 180c i 180d ustawy z dnia 16 lipca 2004 r. – Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800, z pó!n. zm.3)), zwane dalej „danymi telekomunikacyjnymi”, 2) identyfikuj#ce podmiot korzystaj#cy z us"ug pocztowych oraz dotycz#ce faktu, okoliczno&ci &wiadczenia us"ug pocztowych lub korzystania z tych us"ug oraz mo$e je przetwarza). 2. Podmiot prowadz#cy dzia"alno&) telekomunikacyjn# lub operator &wiadcz#cy us"ugi pocztowe udost%pnia nieodp"atnie dane, o których mowa w ust. 1: 1) na pisemny wniosek Generalnego Inspektora Kontroli Skarbowej; 2) na pisemny wniosek pracownika wywiadu skarbowego posiadaj#cego pisemne upowa$nienie Generalnego Inspektora Kontroli Skarbowej do wyst%powania w jego imieniu o udost%pnienie danych, o których mowa w ust. 1; 6)

Zmiany tekstu jednolitego wymienionej ustawy zosta"y og"oszone w Dz. U. z 2004 r. Nr 64, poz. 594, Nr 91, poz. 868, Nr 171, poz. 1800 i Nr 173, poz. 1808, z 2005 r. Nr 132, poz. 1110 i Nr 183, poz. 1537, z 2006 r. Nr 66, poz. 470, Nr 104, poz. 708 i 711, Nr 157, poz. 1119, Nr 191, poz. 1413 i Nr 217, poz. 1590, z 2007 r. Nr 171, poz. 1207 oraz z 2008 r. Nr 110, poz. 707.

28

3) za po&rednictwem sieci telekomunikacyjnej pracownikowi wywiadu skarbowego posiadaj#cemu pisemne upowa$nienie, o którym mowa w pkt 2. 3. W przypadku, o którym mowa w ust. 2 pkt 3, udost%pnianie danych telekomunikacyjnych odbywa si% bez udzia"u pracowników podmiotu prowadz#cego dzia"alno&) telekomunikacyjn# lub przy niezb%dnym ich udziale, je$eli mo$liwo&) tak# przewiduje porozumienie zawarte pomi%dzy Generalnym Inspektorem Kontroli Skarbowej a tym podmiotem. 4. Podmiot wyst%puj#cy z wnioskiem, o którym mowa w ust. 2, informacj% o wyst#pieniu z wnioskiem przekazuje niezw"ocznie ministrowi w"a&ciwemu do spraw finansów publicznych. Minister w"a&ciwy do spraw finansów publicznych w ka$dej chwili mo$e za$#da) od Generalnego Inspektora Kontroli Skarbowej informacji o przyczynach uzasadniaj#cych wyst#pienie z wnioskiem, a tak$e o sposobie wykorzystania danych uzyskanych od podmiotu prowadz#cego dzia"alno&) telekomunikacyjn# lub operatora &wiadcz#cego us"ugi pocztowe. 5. Minister w"a&ciwy do spraw finansów publicznych nakazuje niezw"oczne, komisyjne i protokolarne zniszczenie danych uzyskanych od podmiotu prowadz#cego dzia"alno&) telekomunikacyjn# lub operatora &wiadcz#cego us"ugi pocztowe, w przypadku gdy uzna wyst#pienie z wnioskiem, o którym mowa w ust. 2, za nieuzasadnione. 6. Udost%pnienie wywiadowi skarbowemu danych telekomunikacyjnych mo$e nast#pi) za po&rednictwem sieci telekomunikacyjnej, je$eli sie) ta zapewnia: 1) mo$liwo&) ustalenia pracownika wywiadu skarbowego uzyskuj#cego dane, ich rodzaju oraz czasu, w którym zosta"y uzyskane; 2) zabezpieczenie techniczne i organizacyjne uniemo$liwiaj#ce osobie nieuprawnionej dost%p do danych. 7. Udost%pnianie wywiadowi skarbowemu danych, o których mowa w ust. 1, nast%puje na koszt podmiotu prowadz#cego dzia"alno&) telekomunikacyjn# i operatora &wiadcz#cego us"ugi pocztowe.”; 2) w art. 36c ust. 10 otrzymuje brzmienie: „10. Operator publicznej sieci telekomunikacyjnej, dostawca publicznie dost%pnych us"ug telekomunikacyjnych oraz operator &wiadcz#cy us"ugi pocztowe s# obowi#zani do zapewnienia na w"asny koszt warunków technicznych i organizacyjnych umo$liwiaj#cych prowadzenie przez wywiad skarbowy kontroli operacyjnej.”.

29

Art. 5. W ustawie z dnia 6 czerwca 1997 r. – Kodeks post%powania karnego (Dz. U. Nr 89, poz. 555, z pó!n. zm.7)) wprowadza si% nast%puj#ce zmiany: 1) w art. 218 § 1 otrzymuje brzmienie: „§ 1. Urz%dy, instytucje i podmioty prowadz#ce dzia"alno&) w dziedzinie poczty lub dzia"alno&) telekomunikacyjn#, urz%dy celne oraz instytucje i przedsi%biorstwa transportowe obowi#zane s# wyda) s#dowi lub prokuratorowi, na $#danie zawarte w postanowieniu, korespondencj% i przesy"ki oraz dane, o których mowa w art. 180c i 180d ustawy z dnia 16 lipca 2004 r. – Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800, z pó!n. zm.3)), je$eli maj# znaczenie dla tocz#cego si% post%powania. Tylko s#d lub prokurator maj# prawo je otwiera) lub zarz#dzi) ich otwarcie.”; 2) art. 218b otrzymuje brzmienie: „Art. 218b. Minister Sprawiedliwo&ci w porozumieniu z ministrem w"a&ciwym do spraw "#czno&ci, Ministrem Obrony Narodowej oraz ministrem w"a&ciwym do spraw wewn%trznych okre&li, w drodze rozporz#dzenia, sposób technicznego przygotowania systemów i sieci s"u$#cych do przekazywania informacji – do gromadzenia danych, o których mowa w art. 218 § 1, niestanowi#cych tre&ci rozmowy telefonicznej lub innego przekazu informacji, a tak$e sposoby zabezpieczania danych informatycznych w urz#dzeniach zawieraj#cych te dane oraz w systemach i na informatycznych no&nikach danych, maj#c na uwadze konieczno&) zabezpieczenia tych danych przed ich utrat#, zniekszta"ceniem lub nieuprawnionym ujawnieniem.”. Art. 6. W ustawie z dnia 16 marca 2001 r. o Biurze Ochrony Rz#du (Dz. U. z 2004 r. Nr 163, poz. 1712, z pó!'. zm.8)) po art. 7 dodaje si% art. 7a w brzmieniu: „Art. 7a. 1. Szef BOR, w celu realizacji zada' BOR, okre&lonych w art. 2 ust. 1, mo$e zarz#dzi) o zastosowaniu urz#dze' uniemo$liwiaj#cych telekomunikacj% na okre&lonym obszarze, przez czas niezb%dny do wykonywania czynno&ci przez BOR, z uwzgl%dnieniem

7)

Zmiany wymienionej ustawy zosta"y og"oszone w Dz. U. z 1999 r. Nr 83, poz. 931, z 2000 r. Nr 50, poz. 580, Nr 62, poz. 717, Nr 73, poz. 852 i Nr 93, poz. 1027, z 2001 r. Nr 98, poz. 1071 i Nr 106, poz. 1149, z 2002 r. Nr 74, poz. 676, z 2003 r. Nr 17, poz. 155, Nr 111, poz. 1061 i Nr 130, poz. 1188, z 2004 r. Nr 51, poz. 514, Nr 69, poz. 626, Nr 93, poz. 889, Nr 240, poz. 2405 i Nr 264, poz. 2641, z 2005 r. Nr 10, poz. 70, Nr 48, poz. 461, Nr 77, poz. 680, Nr 96, poz. 821, Nr 141, poz. 1181, Nr 143, poz. 1203, Nr 163, poz. 1363, Nr 169, poz. 1416 i Nr 178, poz. 1479, z 2006 r. Nr 15, poz. 118, Nr 66, poz. 467, Nr 95, poz. 659, Nr 104, poz. 708 i 711, Nr 141, poz. 1009 i 1013, Nr 167, poz. 1192 i Nr 226, poz. 1647 i 1648, z 2007 r. Nr 20, poz. 116, Nr 64, poz. 432, Nr 80, poz. 539, Nr 89, poz. 589, Nr 99, poz. 664, Nr 112, poz. 766 i Nr 123, poz. 849 oraz z 2008 r. Nr 100, poz. 648 i Nr 107, poz. 686. 8)

Zmiany tekstu jednolitego wymienionej ustawy zosta"y og"oszone w Dz. U. z 2004 r. Nr 210, poz. 2135, z 2006 r. Nr 1054, poz. 708 i 711 oraz z 2008 r. Nr 66, poz. 402.

30

konieczno&ci minimalizacji skutków braku mo$liwo&ci korzystania z us"ug telekomunikacyjnych. 2. O zastosowaniu urz#dze', o których mowa w ust. 1, Szef BOR niezw"ocznie informuje Prezesa Urz%du Komunikacji Elektronicznej.”. Art. 7. W ustawie z dnia 24 sierpnia 2001 r. o (andarmerii Wojskowej i wojskowych organach porz#dkowych (Dz. U. Nr 123, poz. 1353, z pó!n. zm.9)) wprowadza si% nast%puj#ce zmiany: 1) w art. 30: a) ust. 1 i 2 otrzymuj# brzmienie: „1. W celu zapobiegania lub wykrywania przest%pstw, w tym skarbowych, (andarmeria Wojskowa, mo$e mie) udost%pniane dane, o których mowa w art. 180c i 180d ustawy z dnia 16 lipca 2004 r. – Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800, z pó!n. zm.3)), zwane dalej „danymi telekomunikacyjnymi”, oraz mo$e je przetwarza). 2. Podmiot prowadz#cy dzia"alno&) telekomunikacyjn# udost%pnia nieodp"atnie dane telekomunikacyjne: 1) $o"nierzowi (andarmerii Wojskowej wskazanemu w pisemnym wniosku Komendanta G"ównego (andarmerii Wojskowej lub komendanta oddzia"u (andarmerii Wojskowej albo osoby przez nich upowa$nionej, 2) na ustne $#danie $o"nierza (andarmerii Wojskowej posiadaj#cego pisemne upowa$nienie osób, o których mowa w pkt 1, 3) za po&rednictwem sieci telekomunikacyjnej $o"nierzowi (andarmerii Wojskowej posiadaj#cemu

pisemne

upowa$nienie,

osób

o

których

mowa

w pkt 1.”, b) po ust. 2 dodaje si% ust. 2a w brzmieniu: „2a. W przypadku, o którym mowa w ust. 2 pkt 3, udost%pnianie danych telekomunikacyjnych odbywa si% bez udzia"u pracowników podmiotu prowadz#cego dzia"alno&) telekomunikacyjn# lub przy ich niezb%dnym wspó"udziale, je$eli mo$liwo&) tak# przewiduje

porozumienie

zawarte

pomi%dzy Komendantem G"ównym (andarmerii

Wojskowej a tym podmiotem.”,

9)

Zmiany wymienionej ustawy zosta"y og"oszone w Dz. U. z 2001 r. Nr 154, poz. 1800, z 2002 r. Nr 74, poz. 676 i Nr 89, poz. 804, z 2003 r. Nr 113, poz. 1070 i Nr 139, poz. 1326, z 2004 r. Nr 116, poz. 1203, Nr 171, poz. 1800 i Nr 273, poz. 2703, z 2006 r. Nr 104, poz. 711 oraz z 2007 r. Nr 176, poz. 1242.

31

c) uchyla si% ust. 3, d) ust. 4 otrzymuje brzmienie: „4. Udost%pnienie (andarmerii Wojskowej danych telekomunikacyjnych mo$e nast#pi) za po&rednictwem sieci telekomunikacyjnej, je$eli: 1) wykorzystywane sieci i system teleinformatyczny zapewniaj#: a) mo$liwo&) ustalenia osoby uzyskuj#cej dane, ich rodzaju oraz czasu, w którym zosta"y uzyskane, b) zabezpieczenie

techniczne

i

organizacyjne

uniemo$liwiaj#

osobie

nieuprawnionej dost%pu do danych, 2) jest to uzasadnione specyfik# lub zakresem zada' wykonywanych przez jednostki organizacyjne (andarmerii Wojskowej albo prowadzonych przez nie czynno&ci.”; 2) po art. 30 dodaje si% art. 30a w brzmieniu: „Art. 30a. 1. W celu realizacji zada', o których mowa w art. 4 ust. 1 pkt 2-4, 5 i 8, Komendant G"ówny (andarmerii Wojskowej lub – po uzyskaniu zgody Komendanta G"ównego (andarmerii Wojskowej – komendant oddzia"u (andarmerii Wojskowej mog# zarz#dzi) zastosowanie urz#dze' uniemo$liwiaj#cych telekomunikacj% na okre&lonym obszarze, przez czas niezb%dny do wykonywania czynno&ci przez (andarmeri% Wojskow#, z uwzgl%dnieniem konieczno&ci minimalizacji skutków braku mo$liwo&ci korzystania z us"ug telekomunikacyjnych. 2. O zastosowaniu urz#dze', o których mowa w ust. 1, Komendant G"ówny (andarmerii Wojskowej niezw"ocznie informuje Prezesa Urz%du Komunikacji Elektronicznej.”. Art. 8. W ustawie z dnia 24 maja 2002 r. o Agencji Bezpiecze'stwa Wewn%trznego oraz Agencji Wywiadu (Dz. U. Nr 74, poz. 676, z pó!n. zm.10)) wprowadza si% nast%puj#ce zmiany: 1) po art. 26 dodaje si% art. 26a w brzmieniu: „Art. 26a. 1. W celu realizacji zada', o których mowa w art. 5 ust. 1 pkt 1 i 2, Szef ABW mo$e zarz#dzi) o zastosowaniu przez ABW urz#dze' uniemo$liwiaj#cych telekomunikacj% na okre&lonym obszarze, przez czas niezb%dny do wykonywania czynno&ci 10)

Zmiany wymienionej ustawy zosta"y og"oszone w Dz. U. z 2003 r. Nr 90, poz. 844, Nr 113, poz. 1070, Nr 130, poz. 1188 i Nr 166, poz. 1609, z 2004 r. Nr 109, poz. 1159, Nr 171, poz. 1800, Nr 267, poz. 2647 i Nr 273, poz. 2703, z 2006 r. Nr 104, poz. 708 i 711 i Nr 218, poz. 1592 oraz z 2008 r. Nr 11, poz. 59.

32

przez ABW, z uwzgl%dnieniem konieczno&ci minimalizacji skutków braku mo$liwo&ci korzystania z us"ug telekomunikacyjnych. 2. O zastosowaniu urz#dze', o których mowa w ust. 1, Szef ABW niezw"ocznie informuje Prezesa UKE.”; 2) art. 28 otrzymuje brzmienie: „Art. 28. 1. Obowi#zek uzyskania zgody s#du, o której mowa w art. 27 ust. 1, nie dotyczy informacji niezb%dnych do realizacji przez ABW zada', o których mowa w art. 5 ust. 1, w postaci danych: 1) o których mowa w art. 180c i 180d ustawy z dnia 16 lipca 2004 r. – Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800, z pó!n. zm.3)), 2) identyfikuj#cych podmiot korzystaj#cy z us"ug pocztowych oraz dotycz#cych faktu, okoliczno&ci &wiadczenia us"ug pocztowych lub korzystania z tych us"ug. 2. Podmiot wykonuj#cy dzia"alno&) telekomunikacyjn# lub operator &wiadcz#cy us"ugi pocztowe udost%pnia nieodp"atnie dane, o których mowa w ust. 1, odpowiednio: 1) funkcjonariuszowi ABW wskazanemu w pisemnym wniosku Szefa ABW lub osoby upowa$nionej przez ten organ, 2) na ustne $#danie funkcjonariusza ABW posiadaj#cego pisemne upowa$nienie Szefa ABW, 3) za po&rednictwem sieci telekomunikacyjnej funkcjonariuszowi ABW posiadaj#cemu upowa$nienie, o którym mowa w pkt 2. 3. W przypadku, o którym mowa w ust. 2 pkt 3, udost%pnianie danych telekomunikacyjnych odbywa si% bez udzia"u pracowników podmiotu wykonuj#cego dzia"alno&) telekomunikacyjn# lub przy ich niezb%dnym wspó"udziale, je$eli mo$liwo&) tak# przewiduje porozumienie zawarte pomi%dzy Szefem ABW a tym podmiotem. 4. Udost%pnienie ABW danych, o których mowa w ust. 1 pkt 1, mo$e nast#pi) za po&rednictwem sieci telekomunikacyjnej, je$eli sie) ta zapewnia: 1) mo$liwo&) ustalenia funkcjonariusza ABW uzyskuj#cego dane, ich rodzaju oraz czasu, w którym zosta"y uzyskane, 2) zabezpieczenie techniczne i organizacyjne uniemo$liwiaj#ce osobie nieuprawnionej dost%p do tych danych.”;

33

Art. 9. W ustawie z dnia 28 lutego 2003 r. – Prawo upad"o&ciowe i naprawcze (Dz. U. Nr 60, poz. 535, z pó!n. zm.11)) w art. 53 dodaje si% ust. 6 w brzmieniu: „6. Je$eli upad"y jest operatorem publicznej sieci telekomunikacyjnej lub dostawc# publicznie dost%pnych us"ug telekomunikacyjnych w rozumieniu przepisów ustawy z dnia 16 lipca 2004 r. – Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800, z pó!n. zm.3)), o og"oszeniu upad"o&ci powiadamia si% Prezesa Urz%du Komunikacji Elektronicznej. Powiadomienie nast%puje w dniu og"oszenia upad"o&ci i dokonuje si% go przy zastosowaniu &rodków bezpo&redniego przekazu informacji, takich jak telefon, faks, poczta elektroniczna.”. Art. 10. W ustawie z dnia 9 czerwca 2006 r. o Centralnym Biurze Antykorupcyjnym (Dz. U. Nr 104, poz. 708, Nr 158, poz. 1122 i Nr 218, poz. 1592 oraz z 2008 r. Nr 171, poz. 1056) art. 18 otrzymuje brzmienie: „Art. 18. 1. Obowi#zek uzyskania zgody s#du, o której mowa w art. 17, nie dotyczy informacji niezb%dnych do realizacji przez CBA zada' okre&lonych w art. 2, w postaci danych: 1) o których mowa w art. 180c oraz 180d ustawy z dnia 16 lipca 2004 r. – Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800, z pó!n. zm.3)), zwanych dalej „danymi telekomunikacyjnymi”; 2) identyfikuj#cych podmiot korzystaj#cy z us"ug pocztowych oraz dotycz#cych faktu, okoliczno&ci &wiadczenia us"ug pocztowych lub korzystania z tych us"ug. 2. Podmiot wykonuj#cy dzia"alno&) telekomunikacyjn# lub podmiot uprawniony do wykonywania dzia"alno&ci pocztowej udost%pnia nieodp"atnie dane, o których mowa w ust. 1: 1) na pisemny wniosek Szefa CBA lub osoby przez niego upowa$nionej; 2) na ustne $#danie funkcjonariusza CBA, posiadaj#cego pisemne upowa$nienie Szefa CBA lub osoby przez niego upowa$nionej; 3) za po&rednictwem sieci telekomunikacyjnej funkcjonariuszowi CBA posiadaj#cemu pisemne upowa$nienie osób, o których mowa w pkt 1. 3. W przypadku, o którym mowa w ust. 2 pkt 3, udost%pnianie danych telekomunikacyjnych odbywa si% bez udzia"u pracowników podmiotu prowadz#cego dzia"alno&) telekomunikacyjn# lub przy niezb%dnym ich wspó"udziale, je$eli mo$liwo&) tak# przewiduje porozumienie zawarte pomi%dzy Szefem CBA a tym podmiotem. 11)

Zmiany wymienionej ustawy zosta"y og"oszone w Dz. U. z 2003 r. Nr 217, poz. 2125, z 2004 r. Nr 91, poz. 870 i 871, Nr 96, poz. 959, Nr 121, poz. 1264, Nr 146, poz. 1546, Nr 173, poz. 1808 i Nr 210, poz. 2135, z 2005 r. Nr 94, poz. 785, Nr 183, poz. 1538 i Nr 184, poz. 1539, z 2006 r. Nr 47, poz. 347, Nr 133, poz. 935 i Nr 157, poz. 1119, z 2007 r. Nr 123, poz. 85 i Nr 179, poz. 1279 oraz z 2008 r. Nr 96, poz. 606 i Nr 116, poz. 731.

34

4. Udost%pnienie CBA danych, o których mowa w ust. 1, mo$e nast#pi) za po&rednictwem sieci telekomunikacyjnej, je$eli: 1) sie) ta zapewnia: a) mo$liwo&) ustalenia funkcjonariusza CBA uzyskuj#cego te dane, ich rodzaju oraz czasu, w którym zosta"y uzyskane, b) zabezpieczenie

techniczne

i

organizacyjne

uniemo$liwiaj#ce

osobie

nieuprawnionej dost%p do uzyskiwanych danych; 2) jest to uzasadnione specyfik# lub zakresem zada' wykonywanych przez jednostki organizacyjne CBA albo prowadzonych przez nie czynno&ci.”. Art. 11. W ustawie z dnia 9 czerwca 2006 r. o S"u$bie Kontrwywiadu Wojskowego oraz S"u$bie Wywiadu Wojskowego (Dz. U. Nr 104, poz. 709 i Nr 218, poz. 1592) wprowadza si% nast%puj#ce zmiany: 1) po art. 29 dodaje si% art. 29a w brzmieniu: „Art. 29a. 1. W celu realizacji zada', o których mowa w art. 5 ust. 1 pkt 1 lit. a-c, f, g oraz art. 39 ust. 1, Szef SKW mo$e zarz#dzi) o zastosowaniu urz#dze' uniemo$liwiaj#cych telekomunikacj% na okre&lonym obszarze, przez czas niezb%dny do wykonywania czynno&ci przez SKW, z uwzgl%dnieniem konieczno&ci minimalizacji skutków braku mo$liwo&ci korzystania z us"ug telekomunikacyjnych. 2. W zwi#zku z wykonywaniem zada', o których mowa w art. 6 ust. 1 w zwi#zku z ust. 3 i art. 39 ust. 1, Szef SWW mo$e zarz#dzi) o zastosowaniu przez SWW urz#dze' uniemo$liwiaj#cych telekomunikacj% na okre&lonym obszarze, przez czas niezb%dny do wykonywania czynno&ci, z uwzgl%dnieniem konieczno&ci minimalizacji skutków braku mo$liwo&ci korzystania z us"ug telekomunikacyjnych. 3. O zastosowaniu urz#dze', o których mowa w ust. 1 i 2, Szef SKW niezw"ocznie informuje Prezesa Urz%du Komunikacji Elektronicznej.”; 2) w art. 31 ust. 11 otrzymuje brzmienie: „11. Operator publicznej sieci telekomunikacyjnej, dostawca publicznie dost%pnych us"ug lub operator &wiadcz#cy us"ugi pocztowe s# obowi#zani do zapewnienia na w"asny koszt warunków technicznych i organizacyjnych umo$liwiaj#cych prowadzenie przez SKW kontroli operacyjnej.”; 3) art. 32 otrzymuje brzmienie:

35

„Art. 32. 1. Obowi#zek uzyskania zgody s#du, o której mowa w art. 31 ust. 1, nie dotyczy informacji niezb%dnych do realizacji przez SKW zada' okre&lonych w art. 5 i 6, w postaci danych: 1) o których mowa w art. 180c oraz 180d ustawy z dnia 16 lipca 2004 r. – Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800, z pó!n. zm.3)), zwanych dalej „danymi telekomunikacyjnymi”; 2) identyfikuj#cych podmiot korzystaj#cy z us"ug pocztowych oraz dotycz#cych faktu, okoliczno&ci &wiadczenia us"ug pocztowych lub korzystania z tych us"ug. 2. Udost%pnienie przez przedsi%biorc% telekomunikacyjnego lub operatora &wiadcz#cego us"ugi pocztowe danych, o których mowa w ust. 1, nast%puje nieodp"atnie: 1) na pisemny wniosek Szefa SKW lub osoby przez niego upowa$nionej; 2) na ustne $#danie funkcjonariusza SKW, posiadaj#cego pisemne upowa$nienie Szefa SKW; 3) za po&rednictwem sieci telekomunikacyjnej funkcjonariuszowi SKW posiadaj#cemu pisemne upowa$nienie Szefa SKW. 3. O udost%pnieniu danych w trybie okre&lonym w ust. 2 pkt 2 przedsi%biorca telekomunikacyjny lub operator &wiadcz#cy us"ugi pocztowe informuje Szefa SKW. 4. Przedsi%biorca telekomunikacyjny oraz operator &wiadcz#cy us"ugi pocztowe s# obowi#zani udost%pni) dane, o których mowa w ust. 1, funkcjonariuszom wskazanym we wniosku. 5. W przypadku, o którym mowa w ust. 2 pkt 3, udost%pnianie danych telekomunikacych odbywa

si%

bez

udzia"u

pracowników

podmiotu

wykonuj#cego

dzia"alno&)

telekomunikacyjn# lub przy niezb%dnym ich wspó"udziale, je$eli mo$liwo&) tak# przewiduje porozumienie zawarte pomi%dzy Szefem SKW a tym podmiotem. 6. Udost%pnienie SKW danych telekomunikacyjnych mo$e nast#pi) za po&rednictwem sieci telekomunikacyjnej, je$eli: 1) wykorzystywane sieci i system teleinformatyczny zapewniaj#: a) mo$liwo&) ustalenia osoby uzyskuj#cej te dane, ich rodzaju oraz czasu, w którym zosta"y uzyskane, b) zabezpieczenie

techniczne

i

organizacyjne

uniemo$liwiaj#

osobie

nieuprawnionej dost%p do tych danych; 2) jest to uzasadnione specyfik# lub zakresem zada' wykonywanych przez SKW albo prowadzonych przez ni# czynno&ci.”.

36

Art. 12. W ustawie z dnia 26 kwietnia 2007 r. o zarz#dzaniu kryzysowym (Dz. U. Nr 89, poz. 590) po art. 11 dodaje si% art. 11a w brzmieniu: „Art. 11a. Centrum informuje Komisj% Europejsk# i pa'stwa cz"onkowskie Unii Europejskiej o &rodkach zastosowanych w sytuacji kryzysowej w celu zabezpieczenia prawid"owego dzia"ania publicznej sieci telekomunikacyjnej oraz stacji nadawczych i odbiorczych u$ywanych do zapewnienia bezpiecze'stwa, w zakresie dotycz#cym systemu "#czno&ci i sieci teleinformatycznych.”. Art. 13. 1. Do spraw wszcz%tych i niezako'czonych przed dniem wej&cia w $ycie ustawy stosuje si% przepisy dotychczasowe, z zastrze$eniem ust. 2. 2. Sprawy wszcz%te na podstawie art. 179 ust. 6 i art. 222 ust. 2 ustawy, o której mowa w art. 1, niezako'czone przed dniem wej&cia w $ycie ustawy, umarza si%. Art. 14. 1. Dotychczasowe przepisy wykonawcze wydane na podstawie art. 176 ust. 4 i art. 181 ustawy, o której mowa w art. 1, zachowuj# moc do dnia wej&cia w $ycie przepisów wykonawczych wydanych na podstawie art. 176a ust. 5 i art. 179 ust. 12 tej ustawy w brzmieniu nadanym niniejsz# ustaw#. 2. Dotychczasowe przepisy wykonawcze wydane na podstawie art. 218b ustawy, o której mowa w art. 5, zachowuj# moc do czasu wydania przepisów wykonawczych wydanych na podstawie art. 218b tej ustawy w brzmieniu nadanym niniejsz# ustaw#. Art. 15. Prezes UKE powo"any na podstawie ustawy, o której mowa w art. 1, pe"ni swoj# funkcj% do czasu powo"ania Prezesa UKE zgodnie z przepisami niniejszej ustawy. Art. 16. Operator publicznej sieci telekomunikacyjnej i dostawca publicznie dost%pnych us"ug telekomunikacyjnych przechowuj# dane, o których mowa w art. 165 ust. 1 i art. 166 ust. 5 ustawy, o której mowa w art. 1, w zakresie danych zwi#zanych z dost%pem do sieci Internet, telefonii internetowej i poczty elektronicznej, na zasadach dotychczasowych. Art. 17. Bazy danych, o których mowa w art. 71 ust. 4 oraz w art. 180f ust. 2 ustawy, o której mowa w art. 1, tworzy si% nie pó!niej ni$ po up"ywie 24 miesi%cy od dnia wej&cia w $ycie niniejszej ustawy.

37

Art. 18. Ustawa wchodzi w $ycie po up"ywie 30 dni od dnia og"oszenia, z wyj#tkiem art. 180a ust. 3, który wchodzi w $ycie z dniem 1 stycznia 2010 r.

27/10/BS

38

UZASADNIENIE

Niemal czteroletni okres obowi#zywania ustawy z dnia 16 lipca 2004 r. – Prawo telekomunikacyjne wskaza" na potrzeb% usprawnienia niektórych mechanizmów i instytucji, w tym pe"niejsze dostosowanie przepisów ustawy do prawa Unii Europejskiej – obowi#zek implementacji nowej dyrektywy 2006/24/WE Parlamentu Europejskiego i Rady z dnia 15 marca 2006 r. w sprawie zatrzymywania generowanych lub przetwarzanych danych w zwi#zku ze &wiadczeniem ogólnie dost%pnych us"ug "#czno&ci elektronicznej lub udost%pnianiem publicznych sieci "#czno&ci, zmieniaj#cej dyrektyw% 2002/58/WE. W&ród przepisów projektu nale$y wymieni) równie$ propozycje zmian innych ustaw w zakresie realizacji przez przedsi%biorców telekomunikacyjnych obowi#zków na rzecz obronno&ci, bezpiecze'stwa pa'stwa oraz bezpiecze'stwa i porz#dku publicznego.

Uzasadnienie szczegó"owe Art. 2 pkt 48 – zmiana definicji us"ugi telekomunikacyjnej Zmiana w definicji us"ugi telekomunikacyjnej ma na celu obj%cie regulacjami telekomunikacyjnymi tych aspektów poczty elektronicznej, które polegaj# na przekazywaniu sygna"ów w sieci telekomunikacyjnej. W tym celu wykre&lono zapis, i$ us"uga poczty elektronicznej nie stanowi us"ugi telekomunikacyjnej. Jest to zgodne z dyrektywami 2002/58/WE i 2002/21/WE, a tak$e pozwoli na wyeliminowanie w#tpliwo&ci interpretacyjnych co do poj%cia poczty elektronicznej. Istniej#cy dotychczas przepis móg" budzi) w#tpliwo&ci interpretacyjne co do zakresu poj%cia przekazywania poczty elektronicznej i us"ugi poczty elektronicznej. Tymczasem nie s# to poj%cia to$same, co wynika jednoznacznie z dyrektyw. Dyrektywa 2002/58/WE nie definiuje wprost us"ugi poczty elektronicznej, definiuje jedynie poczt% elektroniczn#, jako wszelkiego rodzaju wiadomo&ci tekstowe, g"osowe, d!wi%kowe lub wizualne przesy"ane przez publiczn# sie) telekomunikacyjn#, które mog# by) przechowywane w sieci lub w urz#dzeniu ko'cowym odbiorcy, dopóki nie zostan# przez niego odebrane. Poczta elektroniczna jest jednym z rodzajów przekazu, który podlega ochronie zgodnie z przepisami omawianej dyrektywy. Z kolei poj%cie us"ugi przekazywania poczty elektronicznej jest wyra!nie obj%te dyrektyw# ramow#, co statuuje pkt 10 motywów tej dyrektywy. Powy$sze potwierdza równie$ art. 2c tej dyrektywy w definicji us"ugi "#czno&ci elektronicznej, tj. us"ugi polegaj#cej ca"kowicie lub cz%&ciowo na przekazywaniu sygna"ów w sieciach "#czno&ci elektronicznej, w zakres której wchodz# us"ugi telekomunikacyjne i us"ugi transmisyjne &wiadczone przez sieci nadawcze. Definicja ta jest to$sama z definicj# us"ugi telekomunikacyjnej w polskim Prawie telekomunikacyjnym. Obie te definicje obejmuj# swoim zakresem us"ug% przekazywania poczty elektronicznej. Sama us"uga poczty elektronicznej nie jest us"ug# telekomunikacyjn#, gdy$ jej zasadniczymi elementami s#: udost%pnienie indywidualnego konta pocztowego, zapewnienie mo$liwo&ci odbierania poczty elektronicznej kierowanej na konto pocztowe, zapewnienie mo$liwo&ci

wysy"ania poczty elektronicznej z konta pocztowego, zapewnienie mo$liwo&ci przechowywania poczty elektronicznej. W zwi#zku z powy$szym nale$y uzna), i$ us"uga ta jest us"ug# spo"ecze'stwa informacyjnego, wy"#czon# moc# art. 2c dyrektywy ramowej z zakresu us"ug "#czno&ci elektronicznej. Jedynie drugie z powy$szych poj%), czyli poj%cie „us"uga przekazywania poczty elektronicznej”, jest us"ug# telekomunikacyjn# i zmieniona nowelizacj# tre&) przepisu art. 2 ust. 48 jest skutkiem przyj%tej powy$ej interpretacji definicji zwi#zanych z poczt# elektroniczn#. Art. 6 Wprowadzenie tej zmiany spowodowane jest konieczno&ci# zbierania informacji niezb%dnych do prowadzenia analiz rynku telekomunikacyjnego, prowadzenia statystyk oraz przekazywania danych organom regulacyjnym innych pa'stw cz"onkowskich Unii Europejskiej i Komisji Europejskiej. Dodatkowo Prezes UKE b%dzie mia" prawo $#dania tych informacji w terminie nie krótszym ni$ 7 dni i w okre&lonym zakresie, uzasadnionym celem $#dania. Zgodnie z projektowanym brzmieniem ust. 3 $#danie powinno by) proporcjonalne do celu, jakiemu ma s"u$y). Zbieranie informacji nie dotyczy osób fizycznych oraz podmiotów, o których mowa w art. 4. Art. 8 i art. 161 ust. 2 pkt 6 Rozszerzono zakres obowi#zku zapewnienia dost%pu do informacji w zwi#zku z zobowi#zaniami mi%dzynarodowymi Rzeczypospolitej Polskiej wobec krajów EFTA. W ust. 2 art. 8 uregulowany zosta" obowi#zek informowania o przekazaniu Komisji Europejskiej i organom regulacyjnym innych pa'stw cz"onkowskich informacji, otrzymanych od przedsi%biorcy telekomunikacyjnego. Przepis ten wynika z brzmienia art. 5 ust. 2 dyrektywy ramowej, zgodnie z którym (...) Je$eli dostarczona informacja odnosi si% do informacji dostarczonej uprzednio przez przedsi%biorstwo na wniosek krajowego organu regulacyjnego, przedsi%biorstwa takie winne zosta) o tym poinformowane. (...). Regulacja art. 8 ust. 2 tym ró$ni si% od przepisów art. 6, i$ dotyczy sytuacji, kiedy Prezes UKE posiada ju$ informacje od przedsi%biorcy (uzyska" je wcze&niej, dla innych celów ni$ przekazanie Komisji Europejskiej) i przekazuje te informacje KE lub organom regulacyjnym innych pa'stw cz"onkowskich, a nast%pnie informuje o tym przedsi%biorc%. Art. 6 dotyczy za& sytuacji, kiedy Prezes UKE nie posiada okre&lonych informacji i zwraca si% z $#daniem informacji, wskazuj#c przy tym cel, jakim mo$e by) np. konieczno&) przekazania informacji KE lub organom pa'stw cz"onkowskich. Art. 10 Zmiana art. 10 ust. 1 ma na celu umo$liwienie wpisania do rejestru, w zwi#zku z art. 49 TWE, przedsi%biorcy telekomunikacyjnego nieposiadaj#cego siedziby na terytorium Rzeczypospolitej Polskiej, je$eli zamierza &wiadczy) na terytorium Rzeczypospolitej Polskiej us"ugi. Zmiana art. 10 ust. 4 pkt 4 spowodowana jest zmian# ust. 1 oraz tym, $e obowi#zek przedstawienia numeru rejestracji powinien mie) zastosowanie jedynie wobec tych podmiotów, które numer taki posiadaj#, nie powinien za& stanowi) bariery dla podmiotów, które dzia"aj# w pa'stwie pochodzenia bez konieczno&ci rejestracji. Równie$ takie podmioty 2

powinny mie) bowiem mo$liwo&) uzyskania wpisu do polskiego rejestru przedsi%biorców telekomunikacyjnych. Art. 15 Zaproponowana zmiana jest zwi#zana ze zmian# art. 21 – 25c okre&laj#cych post%powanie w sprawie okre&lania rynków w"a&ciwych, nak"adanie, zmiana i znoszenie obowi#zków regulacyjnych. Zmiana s"u$y stworzeniu w ustawie jednoznacznych, w odniesieniu do procedury konsultowania, rozstrzygni%) Prezesa UKE z zainteresowanymi podmiotami. Art. 21 – 25c Zmiany w art. 21 – 25c s# zwi#zane z zarzutami Komisji Europejskiej, która wielokrotnie podnosi"a brak mo$liwo&ci skutecznego odwo"ania si% od rozstrzygni%cia w przedmiocie wyznaczenia, zdefiniowania rynku w"a&ciwego, gdy$ rozporz#dzenie ministra w"a&ciwego do spraw "#czno&ci w sprawie okre&lenia rynków w"a&ciwych jako akt powszechnie obowi#zuj#cy nie daje mo$liwo&ci zakwestionowania rozstrzygni%) przez przedsi%biorców telekomunikacyjnych w normalnym trybie odwo"awczym. Proces analizy rynków rozpoczyna si% od ich okre&lenia przez regulatora (zdefiniowania) przez analiz% danych, którymi UKE dysponuje, a$ po stwierdzenie, czy wyst%puje na nich skuteczna konkurencja czy te$ nie wyst%puje, a co za tym idzie wyznaczenie przedsi%biorcy zajmuj#cego znacz#c# pozycj% i na"o$enie obowi#zków regulacyjnych. Wprowadzone zmiany maj# umo$liwi) Prezesowi UKE wyznaczanie rynków w"a&ciwych zgodnie z Zaleceniem Komisji. Prezes UKE b%dzie wydawa" decyzje, w których w pierwszej kolejno&ci okre&li rynek w"a&ciwy, dokona analizy tego rynku pod k#tem wyst%puj#cych na nim problemów, a nast%pnie wyznaczy przedsi%biorc% lub przedsi%biorców o znacz#cej pozycji (co oznacza, $e rynek nie jest skutecznie konkurencyjny) i na"o$y obowi#zki regulacyjne. W ten sposób strony post%powania b%d# mia"y mo$liwo&) zaskar$enia decyzji tak$e w cz%&ci dotycz#cej wyznaczenia rynku w"a&ciwego. W przypadku ustalenia, $e na danym rynku w"a&ciwym istnieje konkurencja, tzn. nie wyst%puje przedsi%biorca o znacz#cej pozycji rynkowej, Prezes UKE wydaje rozstrzygni%cie w formie postanowienia, na które podmiotom zainteresowanym przys"uguje tryb odwo"awczy – za$alenie. Nale$y tu podkre&li), i$ w ten sposób uj%ta zostanie dodatkowa regulacja – dotychczas nieokre&lona w ustawie – Prawo telekomunikacyjne – okre&laj#ca konsekwencje stwierdzenia, $e operator utraci" pozycj% rynkow#. W decyzji o zniesieniu obowi#zków Prezes UKE oznacza termin ich uchylenia w taki sposób, aby uchylenie uwzgl%dnia"o sytuacj% przedsi%biorców dzia"aj#cych na rynku obj%tych t# decyzj#. Zainteresowane strony zostan# zawiadomione przez Prezesa UKE o podj%tym przez niego rozstrzygni%ciu równie$ na stronie Biuletynu Informacji Publicznej UKE.

Zgodnie z przepisem art. 15(3) zdanie ostatnie dyrektywy ramowej: Krajowe organy regulacyjne b%d# post%powa) zgodnie z procedurami, o których mowa w art. 6 i 7 3

(konsultacje i konsolidacje), zanim zdefiniuj# rynki ró$ne od tych, które zosta"y zdefiniowane w zaleceniach. Regulacje te pozwalaj# na konsolidowanie projektów rozstrzygni%cia, które definiuje rynek inny ni$ wskazany w zaleceniach i jednocze&nie wyznacza SMP i nak"ada obowi#zki. Proponowane rozwi#zanie usprawni równie$ proces okre&lania rynków w"a&ciwych. Art. 34 ust. 2 pkt 12 Zmiana ma charakter porz#dkowy w zwi#zku ze zmian# przepisów dzia"u VIII. Art. 56 Wprowadzone zmiany w art. 56 ustawy s"u$# wyeliminowaniu dotychczasowych powtórze' w zakresie informacji i danych, które powinny by) okre&lone w umowie i w regulaminie, przy jednoczesnym spe"nieniu wymogów okre&lonych w art. 20 dyrektywy o us"udze powszechnej oraz Za"#czniku II dyrektywy. Dodatkowo wyra!nie wskazano, które z obligatoryjnych elementów umowy mog# zosta) okre&lone w regulaminie przez dostawc% publicznie dost%pnych us"ug telekomunikacyjnych. Art. 57 ust. 4 i 6 Proponowany przepis zwi%ksza ochron% konsumentów, gdy$ wysoko&) kary w przypadku zawarcia umowy o &wiadczenie us"ug telekomunikacyjnych, w tym o zapewnienie przy"#czenia do sieci, zwi#zanego z ulg# przyznan# abonentowi, stanowi równowarto&) przyznanej ulgi na dzie' rozwi#zania umowy, a nie jak dotychczas na dzie' jej podpisania. W przypadku jednostronnego rozwi#zania umowy przez abonenta lub przez dostawc% us"ug z winy abonenta przed up"ywem terminu ustalonego w umowie abonent powinien zwróci) ulg% przyznan# mu przy podpisywaniu umowy. Dotychczas abonent zwraca" ulg% w pe"nej wysoko&ci, bez wzgl%du na to, czy rozwi#zanie umowy mia"o miejsce zaraz po podpisaniu umowy czy tu$ przed jej rozwi#zaniem. Aktualne rozwi#zanie okre&la, $e wysoko&) zwracanej przez abonenta ulgi nie mo$e przekroczy) warto&ci ulgi pomniejszonej o proporcjonaln# jej warto&) za okres od dnia zawarcia umowy do dnia jej rozwi#zania. Przedmiotowa zmiana jest prokonsumencka. Art. 59 ust. 2 Przepis dotycz#cy przypadków zmiany regulaminu przez dostawc% us"ug telekomunikacyjnych zosta" przeniesiony do nowo projektowanego art. 60a, z uwagi na fakt, i$ reguluje szczególn# sytuacj% zmian warunków umownych. W zwi#zku z powy$szym oraz konieczno&ci# prawid"owej implementacji art. 20 ust. 4 dyrektywy o us"udze powszechnej, przepis zosta" odpowiednio zmodyfikowany oraz wydzielony w ramach nowej jednostki redakcyjnej art. 60a. Z uwagi na fakt, i$ ust. 1 okre&la zawarto&) regulaminu i definiuje obowi#zek jego dostarczania przez dostawc% us"ug abonentom, nowo projektowany ust. 2 statuuje, i$ dostawca us"ug ma takie same obowi#zki wobec u$ytkowników us"ug przedp"aconych, którzy w &wietle definicji ustawowych abonentami nie s#. W konsekwencji przepis ust. 1 znajdzie równie$ zastosowanie w relacjach z u$ytkownikami us"ug przedp"aconych, którzy zawieraj# umow% o &wiadczenie us"ug w drodze kupna tzw. „startera”. 4

Art. 60 Dotychczasowa tre&) art. 60 wprowadzaj#ca niezamkni%ty katalog informacji, jakie powinny znale!) si% w regulaminie &wiadczenia us"ug telekomunikacyjnych, pozostawa"a w niespójno&ci z tre&ci# art. 56 i powodowa"a nieuzasadnion# konieczno&) powtarzania tych samych informacji zarówno w umowie, jak i w regulaminie &wiadczenia us"ug. Z tego wzgl%du wyra!nie wskazano, i$ art. 60 dotyczy regulaminu &wiadczenia us"ug przedp"aconych, których odbiorcami s# u$ytkownicy nieposiadaj#cy umowy pisemnej. Art. 60a Projektowana zmiana jest konsekwencj# uchylenia art. 59 ust. 2. Pierwsza zmiana polega na okre&leniu zakresu informacji, do podania których dostawca us"ug jest zobowi#zany w przypadku zamiaru dokonania zmian warunków umownych. Z uwagi na fakt, i$ dotychczas dostawca us"ug mia" obowi#zek informowania wy"#cznie o zmianach w regulaminie bez podawania ich tre&ci, w wyniku zmiany dostawca us"ug b%dzie zobowi#zany do podawania ich tre&ci, a abonenci lub u$ytkownicy nie b%d# zmuszeni do samodzielnego ustalania dokonanych przez dostawc% zmian. Kolejna zmiana dotyczy dookre&lenia obowi#zków informacyjnych dostawcy us"ug w przypadku zmiany warunków umownych z uwagi na fakt, i$ warunki te mog# zosta) zawarte w umowie lub stosowanych przez dostawc% regulaminach. Dodatkowo ust. 1 lit. c okre&la obowi#zek dostawcy us"ug przedp"aconych do informowania swoich u$ytkowników o zmianach w regulaminie przez podanie go do publicznej wiadomo&ci. Ponadto, z uwagi na zidentyfikowanie przez KE nieprawid"owej implementacji ww. przepisu dyrektywy oraz niezgodne z intencj# ustawodawcy stosowanie przepisów przez urz#d regulacyjny, wyra!nie wskazano, i$ abonent nie nabywa okre&lonego w ust. 2 uprawnienia do odst#pienia od umowy, w przypadku gdy dostawca us"ug dokonuje zmian warunków umownych z przyczyn od siebie niezale$nych na skutek zmiany przepisów prawa (ust. 3). W tym samym celu w ust. 1 zastosowano termin „proponowana zmiana”, wskazuj#c, i$ w zakresie ust. 1 intencja wprowadzenia zmian le$y wy"#cznie po stronie dostawcy us"ug, nie wynika za& z konieczno&ci dostosowania okre&lonych warunków umownych w zwi#zku z faktem zmiany przepisów prawa (sytuacji okre&lonej w ust. 3). Bior#c równie$ pod uwag% w#tpliwo&ci interpretacyjne dotycz#ce dwóch analogicznych sytuacji, w wyniku zaistnienia których abonent nabywa okre&lone uprawnienia, tj. sytuacji podwy$szenia przez dostawc% cen us"ug (art. 61 ust. 6) oraz sytuacji zmiany warunków umownych okre&lonej w niniejszej jednostce redakcyjnej, doprecyzowano, i$ w przypadku braku akceptacji przez abonenta proponowanych zmian, które w ocenie abonenta s# dla niego niekorzystne, dostawcy us"ug, oprócz roszczenia odszkodowawczego, nie b%dzie równie$ przys"ugiwa" zwrot ulgi, o której mowa w art. 57 ust. 6. Art. 61 Przepis ma na celu zapewnienie jednolitych regu" i zasad dokonywania zmian w cennikach &wiadczenia us"ug telekomunikacyjnych, analogicznie jak ma to miejsce w przypadku zmiany warunków umownych. Wyra!nie wskazano równie$, i$ uprawnienie do wypowiedzenia umowy bez obowi#zku zap"aty kary umownej w zwi#zku ze zmian# cennika przez dostawc% us"ug abonent nabywa wy"#cznie w przypadku podwy$szenia cen us"ug. Ponadto, 5

analogicznie do zmian w art. 60, czyli przypadków zmiany regulaminu lub warunków umownych, wprowadzono wyj#tek od powy$szej zasady, w my&l którego wspomniane uprawnienie abonentowi nie przys"uguje, je&li konieczno&) podwy$szenia cen wynika ze zmiany przepisów prawa. Art. 71 W celu sprawnej realizacji przedsi%wzi%) zwi#zanych z obs"ug# numerów przeniesionych proponuje si%, aby Prezes UKE prowadzi" centraln# baz% numerów przeniesionych. Obowi#zkiem operatorów publicznych sieci telefonicznych by"oby po"#czenie swojej sieci bezpo&rednio lub za pomoc# sieci innego operatora z t# baz# w celu jej aktualizacji. Art. 153 ust. 4 Zmiany w art. 153 ust. 4 pkt 5 i 6 wynikaj# z rozporz#dzenia (WE) nr 552/2004 Parlamentu Europejskiego i Rady z dnia 10 marca 2004 r. (Dz. Urz. WE L 096 z 31.03.2004, str. 26), na podstawie którego urz#dzenia zarz#dzania ruchem lotniczym podlegaj# ocenie zgodno&ci z zasadniczymi wymaganiami okre&lonymi na podstawie tego rozporz#dzenia. Zmiana pkt 7 jest konsekwencj# zmian wprowadzonych ustaw# z dnia 17 listopada 2006 r. o systemie oceny zgodno&ci wyrobów przeznaczonych na potrzeby obronno&ci i bezpiecze'stwa pa'stwa. Ustawa ta wprowadza do ustawy – Prawo telekomunikacyjne art. 152a, zgodnie z którym do wymaga' aparatury, w tym telekomunikacyjnych urz#dze' ko'cowych i urz#dze' radiowych przeznaczonych na powy$sze cele, stosuje si% przepisy ww. ustawy. Telekomunikacyjne urz#dzenia ko'cowe i urz#dzenia radiowe nieprzeznaczone na potrzeby obronno&ci i bezpiecze'stwa pa'stwa powinny spe"nia) zasadnicze wymagania i podlega) obowi#zkowej ocenie zgodno&ci z nimi. Wyj#tkiem s# urz#dzenia wymienione w ust. 4 pkt 1 – 5, zwolnione z takich wymaga' przepisami unijnymi. Art. 159 ust. 1 pkt 5 Zmian% w art. 159 ust. 1 pkt 5 ustawy – Prawo telekomunikacyjne wynika z implementacji do krajowego porz#dku prawnego dyrektywy 2006/24/WE Parlamentu Europejskiego i Rady z dnia 15 marca 2006 r. w sprawie zatrzymywania generowanych lub przetwarzanych danych w zwi#zku ze &wiadczeniem ogólnie dost%pnych us"ug "#czno&ci elektronicznej lub udost%pnianiem publicznych sieci "#czno&ci oraz zmieniaj#cej dyrektyw% 2002/58/WE (Dz. Urz. UE L 105 z 13.04.2006, str. 54). Polska ma obowi#zek jej implementacji do przepisów krajowych w terminie 18 (telefonia) i 36 miesi%cy (us"ugi internetowe). W tym przypadku proponowana zmiana ma za zadanie zast#pienie niejasnego poj%cia „próba uzyskania po"#czenia”, okre&lonym w przepisach dyrektywy poj%ciem „nieudanej próby po"#czenia”. Poj%cie to jest zdecydowanie bardziej jednoznaczne, a jego wprowadzenie do ustawy niezb%dne w zwi#zku z procesem transpozycji przepisów dyrektywy do regulacji krajowych. Art. 161 Zmiana art. 161 ust. 2 pkt 6 polega na rozszerzeniu kr%gu osób o obywateli Konfederacji Szwajcarskiej, a zwi#zana jest z konieczno&ci# wdro$enia decyzji Rady nr 2006/245/WE.

6

Art. 165 i 166 Uchylenie art. 165 ust. 1 oraz art. 166 ust. 5 ustawy – Prawo telekomunikacyjne jest konsekwencj# wprowadzenia przepisów art. 180a wprost zwi#zanych z implementacj# dyrektywy 2006/24/WE. W istocie przepisy art. 180a zast%puj# uchylone przepisy w sposób zgodny z przepisami dyrektywy. Art. 169 Doprecyzowano, i$ dane osobowe udost%pniane s# ograniczone do danych posiadanych przez przedsi%biorc% telekomunikacyjnego. Art. 171 Zmiany wprowadzone w art. 171 maj# charakter zmian porz#dkuj#cych w zwi#zku ze zmian# przepisów dzia"u VIII ustawy. Wynikaj# równie$ z konieczno&ci dostosowania tego przepisu do przepisów dyrektywy o prywatno&ci i "#czno&ci elektronicznej, w szczególno&ci w zakresie u$ywanej terminologii. W art. 171 ust. 8 i 10 wprowadzono poj%cie „przedsi%biorca telekomunikacyjny”. Okre&lone obowi#zki powinny ci#$y) na wszystkich przedsi%biorcach telekomunikacyjnych, a nie tylko na operatorach sieci czy te$ na dostawcach publicznie dost%pnych us"ug telekomunikacyjnych. Ponadto w ust. 10 wprowadzono przepis, i$ do udost%pniania danych ust. 9, stosuje si% art. 180d. Art. 176 – 182 Obowi#zki na rzecz obronno&ci, bezpiecze'stwa pa'stwa oraz bezpiecze'stwa i porz#dku publicznego Zmiany proponowane w art. 176 – 182 ustawy – Prawo telekomunikacyjne s# zmianami, których wprowadzenie ma za zadanie dopasowanie siatki poj%ciowej stosowanej w ustawie – Prawo telekomunikacyjne i w ustawach kompetencyjnych precyzuj#cych zadania organów pa'stwowych posiadaj#cych uprawnienia do prowadzenia dzia"a' operacyjnych z wykorzystaniem telekomunikacji, a tak$e w innych przepisach ustawowych dotycz#cych sytuacji szczególnych zagro$e' i powinno&ci przedsi%biorców zwi#zanych z wykonywaniem obowi#zków zwi#zanych z obronno&ci# pa'stwa. Wprowadzone zmiany maj# za zadanie wyra!ne odró$nienie, przez wydzielenie odr%bnych tematycznie jednostek redakcyjnych ustawy, obowi#zków zwi#zanych z dzia"aniami przedsi%biorców telekomunikacyjnych w sytuacjach szczególnych zagro$e', wprowadzania dodatkowych ogranicze' i obowi#zków w funkcjonowaniu sieci telekomunikacyjnych i &wiadczeniu us"ug oraz utrzymywaniu i odtwarzaniu zdolno&ci us"ugowych przedsi%biorców na zasadach preferencyjnych, wspó"pracy z uprawnionymi organami pa'stwowymi prowadz#cymi dzia"ania operacyjne oraz obowi#zków w zakresie zachowywania danych zwi#zanych z po"#czeniami telekomunikacyjnymi, obligatoryjnie zatrzymywanych przez przedsi%biorc% na potrzeby &cigania sprawców przest%pstw i prowadzenia w tym wzgl%dzie post%powa' s#dowych. Dotychczasowy kszta"t przepisów dzia"u VIII powodowa" powstawanie trudno&ci interpretacyjnych, w szczególno&ci dotycz#cych zakresu zobowi#za' oraz organów pa'stwowych, na rzecz których realizowane by"y obowi#zki zwi#zane z obronno&ci#, bezpiecze'stwem pa'stwa oraz bezpiecze'stwem i porz#dkiem publicznym. Proponowane zmiany maj# na celu unikni%cie wymienionych wy$ej problemów interpretacyjnych.

7

Przepisy znowelizowanego dzia"u VIII ustawy okre&laj# warunki dost%pu i utrwalania oraz rodzaje danych podlegaj#cych retencji, których jednoznaczne i szczegó"owe okre&lenie nast#pi w drodze rozporz#dzenia. Przepisy te okre&laj# jako podstawowy sposób realizacji obowi#zków w zakresie zapewnienia warunków dost%pu i utrwalania z zachowaniem wymaga' okre&lonych w rozporz#dzeniu, o którym mowa w art. 179 ust. 12. Ponadto przewidziano fakultatywn# mo$liwo&) zapewnienia warunków dost%pu i utrwalania za pomoc# interfejsów na zasadach okre&lonych w umowach zawartych przez uprawnione podmioty z przedsi%biorc# telekomunikacyjnym. Umowa mo$e okre&la) wspó"udzia" stron w kosztach zastosowania interfejsów. Proponowane przepisy nie zawieraj# rozwi#za' szczegó"owych, w zakresie ochrony danych, wykraczaj#cych poza ochron% tajemnicy telekomunikacyjnej, gdy$ wymogi szczegó"owe w zakresie niezb%dnym do zastosowania przy wykonywaniu obowi#zków okre&lonych w dziale VIII, a w szczególno&ci w art. 179 i 180a zale$# od przyj%tego sposobu realizacji ww. zada' i s# okre&lone przepisami odr%bnymi, w tym w szczególno&ci przepisami ustawy o ochronie informacji niejawnych i ustawy o ochronie danych osobowych. Przepisy tych ustaw maj# zastosowanie niezale$nie od minimalnego standardu zabezpieczenia danych telekomunikacyjnych, okre&lonego w dziale VII ustawy. Art. 176 otrzyma" brzmienie, które w swojej tre&ci zawiera obecnie obowi#zuj#cy art. 179 ust. 1. Dodany zosta" nowy artyku" art. 176a, który wprowadza definicj% sytuacji szczególnych zagro$e', której wprowadzenie postulowa"o &rodowisko przedsi%biorców telekomunikacyjnych. Zaproponowana definicja jest oparta na siatce poj%ciowej zaczerpni%tej z ustawy o zarz#dzaniu kryzysowym oraz z ustaw o stanach nadzwyczajnych i uwzgl%dnia równie$ sytuacje zwi#zane z awariami technicznymi i uszkodzeniami infrastruktury telekomunikacyjnej przedsi%biorcy. W ust. 2 ograniczono zakres zawarto&ci planów wykluczaj#c z niego obszary tematyczne okre&lone w poprzednich przepisach w art. 176 ust. 2 pkt 4 oraz cz%&ciowo art. 176 ust. 2 pkt 7 (priorytety). W znowelizowanych przepisach uj%to, poza aspektami zwi#zanymi ze &wiadczeniem us"ug telekomunikacyjnych, tak$e problematyk% dostarczania sieci z uwzgl%dnieniem pierwsze'stwa dla podmiotów koordynuj#cych, podmiotów zarz#dzania kryzysowego, s"u$b ustawowo powo"anych do niesienia pomocy, podmiotów realizuj#cych zadania na rzecz obronno&ci, bezpiecze'stwa pa'stwa oraz bezpiecze'stwa i porz#dku publicznego, bardzo istotn#, a niestety pomini%t# w przepisach dotychczasowych. W art. 176a ust. 3 wskazano organy, z którymi przedsi%biorca telekomunikacyjny uzgadnia zawarto&) planu dzia"a' w sytuacjach szczególnych zagro$e'. Nowy przepis art. 176a ust. 4 okre&la, w którym momencie przedsi%biorca praktycznie podejmuje dzia"ania okre&lone w planie i od jakich organów uzyskuje ewentualn# informacj% o wyst#pieniu sytuacji szczególnych zagro$e'. Wprowadzenie przepisu by"o postulowane przez &rodowisko przedsi%biorców. W art. 176a ust. 5 rozszerzono delegacj% do wydania rozporz#dzenia o okre&lenie organów dokonuj#cych uzgodnie' planów przedsi%biorców. Zmieniono tak$e delegacj% w zakresie okre&lenia przedsi%biorców i rodzajów dzia"alno&ci telekomunikacyjnej niepodlegaj#cych obowi#zkowi sporz#dzenia planu. Uchylenie art. 177 ust. 1 i 2 spowodowane jest ma"# czytelno&ci# i brakiem jednoznaczno&ci przepisów dotychczasowych, rezygnacj# z wprowadzania do przepisów ustawowych obowi#zków z zakresu &wiadczenia us"ug o okre&lonych priorytetach, spowodowan# brakiem technicznej standaryzacji w tym zakresie

8

oraz praktycznym brakiem mo$liwo&ci wydania rozporz#dzenia, delegacja do wydania którego znajdowa"a si% w art. 177 ust. 2. Najistotniejszy przepis dotychczasowego art. 177 ust. 1 znajduje swoje odzwierciedlenie w nowym art. 176a ust. 5, w którym "#cznie z przepisem art. 176a ust. 2 pkt 3 okre&la, jakie podmioty i s"u$by oraz w jaki sposób wskazane, b%d# podmiotami i s"u$bami, dla których realizowane jest &wiadczenie us"ug i dostarczania sieci, a tak$e utrzymania ci#g"o&ci i ich odtwarzanie, z uwzgl%dnieniem pierwsze'stwa. W art. 177 dokonano zmian redakcyjnych w zwi#zku z uchyleniem ust. 1 i 2. W art. 177 ust. 6 zosta"a zawarta delegacja do wydania rozporz#dzenia przez Rad% Ministrów, które ureguluje tryb nieodp"atnego udost%pniania w sytuacji szczególnego zagro$enia przedsi%biorcom telekomunikacyjnym oraz podmiotom i s"u$bom wykonuj#cym zadania w zakresie ratownictwa, niesienia pomocy ludno&ci, zarz#dzania kryzysowego, a tak$e zadania na rzecz obronno&ci, bezpiecze'stwa pa'stwa oraz bezpiecze'stwa i porz#dku publicznego, urz#dze' nadawczych lub nadawczo-odbiorczych przez podmioty nieb%d#ce przedsi%biorcami telekomunikacyjnymi. Zmiana art. 178 ust. 1 pkt 1 jest konsekwencj# zmian w art. 176 i 177. Nowe brzmienie art. 178 ust. 2 jest podyktowane tym, $e w przepisach dotychczasowych okre&lono zbyt w#ski i zamkni%ty katalog podmiotów mog#cych wyst%powa) z wnioskiem do Prezesa UKE o wydanie decyzji okre&lonych w art. 178 ust. 1. W sytuacjach szczególnych zagro$e' podmiotami takimi mog# by) tak$e podmioty koordynuj#ce dzia"ania ratownicze, podmioty w"a&ciwe w sprawach zarz#dzania kryzysowego oraz s"u$by ustawowo powo"ane do niesienia pomocy. W art. 178 ust. 2 zosta" zaprojektowany nowy przepis, który umo$liwia og"oszenie decyzji Prezesa UKE w formie ustnej oraz odst#pienie od uzasadnienia decyzji. Stosownie do art. 14 § 2 K.p.a. sprawy mog# by) za"atwiane ustnie, gdy przemawia za tym interes strony, a przepis prawa nie stoi temu na przeszkodzie – zdaniem autorów komentarzy do K.p.a. wyra$enie: „gdy przemawia za tym interes strony” nale$a"oby uwa$a) za równoznaczne pod wzgl%dem swojego sensu z wyra$eniem: „gdy strona na to si% zgadza”. Tre&) „o&wiadczenia” strony co do zgody musi mie) charakter wyra!ny. Wyra$enia zgody nie mo$na domniemywa). W sytuacji istnienia jakichkolwiek w#tpliwo&ci a zw"aszcza, gdy w ocenie organu za ustnym za"atwieniem sprawy przemawia interes strony, organ jest obowi#zany zwróci) si% do strony o jej stanowisko. Brak zgody nak"ada na organ administracji publicznej obowi#zek zastosowania formy pisemnej. W przypadku ustnego za"atwienia sprawy tre&) oraz istotne motywy takiego za"atwienia powinny by) utrwalone w aktach w formie protoko"u lub podpisanej przez stron% adnotacji. W uchwale s%dziów NSA z dnia 13 pa!dziernika 1997 r. (FPK 13/97, ONSA 1998, nr 1, poz. 70) stwierdzono, $e „og"oszenie ustne decyzji administracyjnej, jako wyj#tek od zasady pisemno&ci, wymaga utrwalenia tej czynno&ci na pi&mie w drodze sporz#dzenia protoko"u (art. 67 § 2 pkt 5 K.p.a.), który powinien odpowiada) wymaganiom art. 68 i 107 K.p.a. w zakresie koniecznych elementów decyzji”. Sk"adniki decyzji administracyjnej okre&la art. 107 § 1 K.p.a. Wobec braku wyra!nego postanowienia w tej kwestii nale$y przyj#), $e powy$szy przepis ma zastosowanie do decyzji pisemnych i decyzji og"oszonych ustnie, z tym $e w odniesieniu do decyzji ustnych niektóre wymagania okre&lone w art. 107 § 1 z natury rzeczy nie b%d# mog"y by) spe"nione, np. podpis osoby upowa$nionej do wydania decyzji. Art. 107 § 1 K.p.a. do niezb%dnych elementów decyzji zalicza uzasadnienie faktyczne i prawne. Od uzasadnienia decyzji mo$na odst#pi) w dwóch przypadkach – gdy decyzja uwzgl%dnia w ca"o&ci $#danie strony (nie dotyczy to jednak decyzji rozstrzygaj#cych sporne interesy stron oraz decyzji wydanych na skutek 9

odwo"ania) oraz gdy z dotychczasowych przepisów ustawowych wynika"a mo$liwo&) zaniechania lub ograniczenia uzasadnienia ze wzgl%du na interes bezpiecze'stwa pa'stwa lub porz#dek publiczny. Niestety w przypadku decyzji wydawanych przez Prezesa UKE na podstawie art. 178 ustawy – Prawo telekomunikacyjne nie ma mo$liwo&ci rezygnacji z uzasadnienia. Aby takie rozwi#zanie by"o mo$liwe zosta" wprowadzony do projektu przepis zezwalaj#cy na odst#pienie od uzasadnienia. W projektowanym art. 178 ust. 2 dopuszczono odst#pienie od uzasadnienia decyzji w ca"o&ci lub w cz%&ci, je$eli wymagaj# tego wzgl%dy obronno&ci lub bezpiecze'stwa pa'stwa oraz bezpiecze'stwa i porz#dku publicznego. W art. 178 ust. 3 zawarto zamkni%ty katalog organów, które mog# dysponowa) urz#dzeniami, których zastosowanie ma na celu uniemo$liwienie na okre&lonym obszarze telekomunikacji z zastrze$eniem, $e przypadki i zasady ich u$ycia zostan# okre&lone w przepisach odr%bnych. W ustawach kompetencyjnych uprawnionych podmiotów zosta"y zawarte przepisy materialne sankcjonuj#ce u$ywanie urz#dze' uniemo$liwiaj#cych telekomunikacj%, przypadki i zasady ich zastosowania, a tak$e obowi#zek poinformowania o ich u$yciu Prezesa Urz%du Komunikacji Elektronicznej. Jednocze&nie przepis dotychczasowy mówi#cy jedynie o uniemo$liwieniu po"#cze' telefonicznych nie by" mo$liwy do wykonania z powodów technicznych. Uchylenie ust. 1 w art. 179 jest zwi#zane z przebudow# ca"ego rozdzia"u VIII. Uchylenie ust. 1 jest podyktowane zb%dno&ci# tego przepisu. Przepis ten w istocie wskazywa" jedynie na obowi#zek wykonywania zada' w zakresie obronno&ci, bezpiecze'stwa pa'stwa, bezpiecze'stwa i porz#dku publicznego, okre&lonych w ustawie i przepisach odr%bnych. Przepis art. 179 ust. 1 zosta" przeniesiony z niewielkimi zmianami do oddzielnej jednostki redakcyjnej, tj. art. 176. Zmiany wprowadzone w art. 179 ust. 3 maj# na celu ujednolicenie siatki poj%ciowej stosowanej w ustawie – Prawo telekomunikacyjne i w ustawach kompetencyjnych precyzuj#cych zadania organów pa'stwowych posiadaj#cych uprawnienia do prowadzenia kontroli operacyjnej w telekomunikacji. W tym wzgl%dzie wprowadzono w ust. 3 poj%cie „warunków dost%pu i utrwalania” oraz „przekazów telekomunikacyjnych”, zdefiniowane na podstawie poj%) u$ytych w ustawach kompetencyjnych. Dodatkowo dokonano zmiany przez ukierunkowanie wskazania przez uprawnione podmioty „u$ytkownika ko'cowego” w miejsce wyst%puj#cego w poprzedniej redakcji art. 179 ust. 3 wskazania „tre&ci i danych”, co by"o organizacyjnie i technicznie niemo$liwe. W zwi#zku z niejasno&ci#, któr# powodowa"o poprzednie okre&lenie podmiotów uprawnionych, szczególnie w kontek&cie jednoczesnego i wzajemnie niezale$nego dost%pu, przyj%to rozwi#zanie definiuj#ce jako „uprawnione podmioty” Policj%, Stra$ Graniczn#, Agencj% Bezpiecze'stwa Wewn%trznego, S"u$b% Kontrwywiadu Wojskowego, (andarmeri% Wojskow#, Centralne Biuro Antykorupcyjne i wywiad skarbowy. Dodano równie$ wyrazy „urz#dzenia ko'cowego”, które maj# na celu ujednolicenie i doprecyzowanie zasad wspó"pracy uprawnionych podmiotów z przedsi%biorcami telekomunikacyjnymi, które wynikaj# zarówno z przepisów ustawy – Prawo telekomunikacyjne, jak i ustaw kompetencyjnych uprawnionych podmiotów. Nowy art. 179 ust. 3a zast%puje uchylony art. 179 ust. 5. Zosta" wprowadzony nowy art. 179 ust. 3b, który ze wzgl%dów legislacyjnych zosta" wyodr%bniony z art. 179 ust. 3.

10

W art. 179 ust. 4 wprowadzono jako podstawowy sposób realizacji obowi#zków przez przedsi%biorc% telekomunikacyjnego przez zapewnienie warunków dost%pu i utrwalania z zachowaniem wymaga' okre&lonych w rozporz#dzeniu, o którym mowa w art. 179 ust. 12. W art. 179 ust. 4a wprowadzono jako fakultatywny sposób realizacji przedmiotowych obowi#zków – sposób oparty na interfejsach przygotowywanych przez przedsi%biorc% – zlokalizowanych w miejscach obejmowanych przez sie) przedsi%biorcy telekomunikacyjnego i wskazanych przez uprawnione podmioty, na zasadach okre&lonych w umowach zawartych przez uprawnione podmioty z przedsi%biorc# telekomunikacyjnym. Umowa mo$e okre&la) wspó"udzia" stron w kosztach zastosowania interfejsów. Zgodnie z art. 179 ust. 4b interfejsy powinny umo$liwi) uprawnionym podmiotom dost%p do przekazów telekomunikacyjnych i danych bez udzia"u pracowników przedsi%biorcy telekomunikacyjnego. Przepis art. 179 ust. 4c dopuszcza wspólne przygotowanie interfejsu przez kilku przedsi%biorców. Szczegó" wspólnego przygotowania interfejsów zostan# zawarte w umowach. Przed zawarciem umowy przedsi%biorcy telekomunikacyjni uzgadniaj# warunki techniczne i eksploatacyjne z uprawnionymi podmiotami. Zosta" uchylony art. 179 ust. 5 ze wzgl%du na zmian% terminologii u$ytej w dziale VIII i dostosowanie do pozosta"ych przepisów z tej jednostki redakcyjnej. W art. 179 ust. 6 zawarto znowelizowany przepis dotycz#cy zawieszenia obowi#zku zapewnienia warunków dost%pu i utrwalania tre&ci przekazów telekomunikacyjnych i danych zwi#zanych z tymi przekazami, okre&lonych w ustawie, po wyra$eniu zgody podmiotów uprawnionych. W zwi#zku z niejasno&ciami interpretacyjnymi zrezygnowano z poj%cia „odroczenia terminu”, natomiast wprowadzono mo$liwo&) czasowego zawieszenia, w ca"o&ci lub w cz%&ci, obowi#zku zapewnienia warunków dost%pu i utrwalania, które b%dzie mog"o by) zastosowane wy"#cznie na czas okre&lony, nie d"u$szy ni$ 6 miesi%cy, w szczególnie uzasadnionych przypadkach, na wniosek zainteresowanego przedsi%biorcy telekomunikacyjnego. Istot# rozwi#zania wprowadzaj#cego cezur% czasow#, w przypadku wydawania przez Prezesa UKE decyzji zawieszaj#cych wykonanie przez przedsi%biorców telekomunikacyjnych obowi#zków na rzecz obronno&ci i bezpiecze'stwa pa'stwa, jest konieczno&) ograniczenia dzia"a' przedsi%biorców polegaj#cych na sta"ym odraczaniu i faktycznym braku wykonywania na"o$onych na nich – ju$ w 2004 r. – przez ustawodawc% obowi#zków. Zgodnie z zaproponowan# zmian#, Prezes UKE zosta"by wyposa$ony w harmonogram osi#gni%cia przez przedsi%biorc% telekomunikacyjnego pe"nej zdolno&ci do wykonywania obowi#zku i móg"by na tej podstawie w sposób bardziej efektywny, przy pomocy instrumentów ustawowych, egzekwowa) jego wykonanie. W art. 179 ust. 6a zosta"o przewidziane wy"#czenie, które powoduje $e zapisów art. 179 ust. 6 nie stosuje si% do przedsi%biorcy telekomunikacyjnego rozpoczynaj#cego dzia"alno&) telekomunikacyjn# lub rozpoczynaj#cego &wiadczenie nowej us"ugi telekomunikacyjnej. W art. 179 ust. 6b zosta" okre&lony przypadek gdy przedsi%biorca telekomunikacyjny z"o$y" wniosek lub zosta" zawieszony obowi#zek zapewnienia warunków dost%pu i utrwalania, jednak$e jest zobowi#zany do realizacji ww. obowi#zków w zakresie posiadanych mo$liwo&ci technicznych, organizacyjnych i finansowych. W art. 179 ust. 7 zosta"o wprowadzone rozwi#zanie, które minimalizuje koszty po stronie przedsi%biorcy telekomunikacyjnego, polegaj#cego na umo$liwieniu outsourcingu obowi#zku z art. 179 ust. 3 na podmiot wyspecjalizowany w &wiadczeniu tego typu us"ug, którym jest 11

przedsi%biorca telekomunikacyjny, przy zachowaniu odpowiedzialno&ci przedsi%biorcy telekomunikacyjnego (powierzaj#cego). Zmiana w art. 179 ust. 8 pkt 1 i 2 polega na usuni%ciu niejasnego odwo"ania do wymogów przepisów odr%bnych, które powinny spe"nia) osoby reprezentuj#ce przedsi%biorc% telekomunikacyjnego w zakresie przewidzianym przepisami art. 179. Dodatkowy pkt 3 obliguje przedsi%biorców do podania Prezesowi UKE informacji uzupe"niaj#cej, w przypadku skorzystania kilku z nich z mo$liwo&ci przygotowania i wspólnego eksploatowania interfejsów. W dodanym ust. 8a zosta" zawarty obowi#zek informowania Prezesa UKE przez przedsi%biorc% telekomunikacyjnego w przypadku zmiany danych, o których mowa w art. 179 ust. 8. Zmiany w art. 179 ust. 10 maj# charakter porz#dkuj#cy. Uchylony przepis art. 179 ust. 11, po wprowadzeniu stosownych korekt zwi#zanych ze zmian# terminologii, znajduje si% w proponowanej nowelizacji w art. 179 ust. 3a. Art. 179 ust. 12 precyzuje delegacj% do wydania rozporz#dze'. Delegacja zawarta w art. 179 ust. 12 zast%puje uchylony przepis deleguj#cy zawarty w art. 181 w poprzednich przepisach ustawy. Nowy przepis uwzgl%dnia nowelizacj% siatki poj%ciowej oraz konsekwencje zmian wprowadzonych w ca"ym art. 179. Nowy art. 180a stanowi pierwsz# cz%&) implementacji do krajowego porz#dku prawnego dyrektywy UE w sprawie retencji danych telekomunikacyjnych. W artykule tym wskazano, $e retencja danych b%dzie s"u$y"a szczególnie wykrywaniu przest%pstw skierowanych przeciwko obronno&ci, bezpiecze'stwu pa'stwa, bezpiecze'stwu i porz#dkowi publicznemu oraz przest%pstw skarbowych. Przepis art. 180a ust. 1 pkt 2 nak"ada na operatora publicznej sieci telekomunikacyjnej oraz dostawc% publicznie dost%pnych us"ug telekomunikacyjnych obowi#zek zatrzymywania i przechowywania danych przez 24 miesi#ce. Wprowadzenie maksymalnego terminu zatrzymywania danych przez 24 miesi#ce wynika z okoliczno&ci, $e Polska jest lub mo$e by) wykorzystywana jako zaplecze logistyczne lub punkt tranzytowy dla ugrupowa' terrorystycznych. Z uwagi na po"o$enie geograficzne Polski, na szlakach wschód – zachód i pó"noc – po"udnie, istnieje bardzo du$e prawdopodobie'stwo wykorzystania terytorium naszego pa'stwa w"a&nie w ten sposób. Dotyczy to zarówno islamistów, jak i innych grup terrorystycznych. Pomijaj#c oczywiste zagro$enia zwi#zane z nielegaln# dzia"alno&ci# (przemyt broni, materia"ów wybuchowych i innych niebezpiecznych materia"ów, przemyt ludzi, prowadzenie dzia"alno&ci szkoleniowej, rekrutacyjnej i propagandowej), które maj# charakter po&redni dla spo"ecze'stwa, istnieje tak$e zagro$enie bezpo&rednie w momencie ujawnienia faktu prowadzenia takiej dzia"alno&ci. Mo$e to by) stawianie oporu w celu udaremnienia wykonania czynno&ci s"u$bowych przez funkcjonariuszy (w tym z u$yciem broni i "adunków wybuchowych), branie zak"adników w celu umo$liwienia sobie ucieczki, tak$e poza terytorium Rzeczypospolitej Polskiej, dokonywanie zamachów terrorystycznych w celu wymuszenia na w"adzach uwolnienia aresztowanych osób, jak równie$ odst#pienia od czynno&ci wobec sprawców tych dzia"a', tak$e organizowanie ucieczek i buntów w zak"adach karnych i aresztach &ledczych. Podobny charakter mog# mie) sytuacje, w których terrory&ci b%d# próbowa) wykorzysta) terytorium Polski jako drog% ucieczki. Z uwagi na wspomniane po"o$enie geograficzne, cz"onkostwo Rzeczypospolitej Polskiej w Unii Europejskiej ("atwiejsze podró$owanie w kierunku zachodnim i pó"nocnym), blisko&) Ba"kanów, pa'stw postradzieckich, rozwini%t# infrastruktur% transportow# i telekomunikacyjn#, a tak$e czynniki spo"eczne i ekonomiczne (kontakty handlowe z krajami bliskowschodnimi, przesz"# obecno&) wielu obywateli tych pa'stw) nale$y uzna), $e istnieje wysokie ryzyko wykorzystania terytorium Polski do 12

opisanej dzia"alno&ci (by) mo$e ju$ taka dzia"alno&) jest prowadzona). Wbrew powszechnemu przekonaniu o trudno&ci z „wtopieniem si%” w otoczenie, nie stanowi to problemu w du$ych miastach. Jakkolwiek obecnie centrum logistycznym i werbunkowym islamistów w Europie s# pa'stwa zachodnie, to wraz ze zwi%kszaniem skuteczno&ci dzia"a' policji i s"u$b specjalnych w tych pa'stwach, terrory&ci mog# zosta) zmuszeni do znalezienia sobie innego miejsca, z mniej skuteczn# i mniej do&wiadczon# w ich zwalczaniu policj#. Ponadto nale$y zak"ada), $e wzrost imigracji do krajów UE dotknie tak$e Polsk%, co stworzy nowe uwarunkowania do aktywno&ci &rodowisk radykalnych. Powa$nym problemem mo$e by) te$ dzia"alno&) rekrutacyjna prowadzona przez islamistów w&ród rdzennych mieszka'ców krajów europejskich, co prze"o$y si% na zagro$enie wy$ej opisanymi sytuacjami kryzysowymi, które równie$ nale$y oceni) jako du$e. Kolejnym wa$nym problemem, który dotknie bezpo&rednio bezpiecze'stwa Polski, mo$e by) utworzenie nowego szlaku przerzutu heroiny do Europy przez terytorium Polski za po&rednictwem $o"nierzy s"u$#cych w Afganistanie. Sprzeda$ heroiny to jedno ze !róde" finansowania al-Kaidy. W sytuacji uczestnictwa polskich $o"nierzy w przemycie narkotyków mog"aby zosta) zagro$ona sojusznicza wiarygodno&) Polski. Polscy $o"nierze pomagaliby bowiem po&rednio, nie wiedz#c o tym, finansowa) dzia"alno&) al-Kaidy oraz talibów. Warto równie$ przypomnie), $e na terytorium Polski ma swoj# siedzib% Europejska Agencja Zarz#dzania Wspó"prac# Operacyjn# na Zewn%trznych Granicach Pa'stw Cz"onkowskich Unii Europejskiej (FRONTEX). Do jej zada' nale$y m.in.: przeprowadzanie analizy ryzyka, &ledzenie rozwoju bada' maj#cych znaczenie dla kontroli i ochrony granic zewn%trznych, wspomaganie pa'stw cz"onkowskich w sytuacjach wymagaj#cych zwi%kszonej pomocy technicznej i operacyjnej na granicach zewn%trznych. Drug# cz%&ci# tej implementacji b%dzie wydanie szczegó"owych rozporz#dze', zgodnie z delegacj# zawart# w art. 180c ust. 2. Przepisy art. 180a ust. 1 okre&laj# obowi#zek wynikaj#cy z dyrektywy, a w art. 180c zawieraj# ogóln# klasyfikacj% danych podlegaj#cych retencji. Art. 180a ust. 3 i 4 reguluje istotn# kwesti% przej%cia danych telekomunikacyjnych od upad"ego operatora publicznej sieci telekomunikacyjnej lub dostawcy publicznie dost%pnych us"ug telekomunikacyjnych. Dane mog# stanowi) bardzo wa$ny materia" dowodowy w post%powaniach karnych, dlatego powinny by) one w dalszym ci#gu przechowywane przez operatora – nast%pc% prawnego operatora, który zaprzesta" dzia"alno&ci. Dane takie by"yby przej%te przez Prezesa UKE na zasadach okre&lonych w rozporz#dzeniu Prezesa Rady Ministrów. Konsekwencj# tych propozycji jest zmiana w ustawie – Prawo upad"o&ciowe i naprawcze (nowy ust. 6 w art. 53). W art. 180b ust. 1 dopuszczono mo$liwo&) wykonywania obowi#zków, o których mowa w art. 180a, (zatrzymywania, przechowywania i udost%pniania oraz chronienia danych) wspólnie przez kilku operatorów publicznej sieci telekomunikacyjnej lub dostawców publicznie dost%pnych us"ug telekomunikacyjnych. W art. 180b ust. 2 zosta"o wprowadzone rozwi#zanie, które minimalizuje koszty po stronie operatora publicznej sieci telekomunikacyjnej lub dostawcy publicznie dost%pnych us"ug telekomunikacyjnych, polegaj#ce na umo$liwieniu outsourcingu obowi#zku z art. 180a ust. 1 na podmiot wyspecjalizowany w &wiadczeniu tego typu us"ug, którym jest przedsi%biorca telekomunikacyjny, przy zachowaniu odpowiedzialno&ci przedsi%biorcy telekomunikacyjnego (powierzaj#cego).

13

W art. 180c zosta"y okre&lone kategorie danych dost%pnych operatorowi publicznej sieci telekomunikacyjnej lub dostawcy publicznie dost%pnych us"ug telekomunikacyjnych, które podlegaj# obowi#zkowi z art. 180a ust. 1. Art. 180c ust. 2 stanowi delegacj% dla ministra w"a&ciwego do spraw "#czno&ci w porozumieniu z ministrem w"a&ciwym do spraw wewn%trznych do wydania rozporz#dzenia okre&laj#cego szczegó"owy wykaz danych podlegaj#cych retencji oraz rodzajów operatorów publicznej sieci telekomunikacyjnej lub dostawców publicznie dost%pnych us"ug telekomunikacyjnych zobowi#zanych do zatrzymywania i przechowywania okre&lonych rodzajów danych telekomunikacyjnych. Zwa$ywszy na dwustopniowy proces wdro$enia dyrektywy retencyjnej, odr%bnie dla danych zwi#zanych z dost%pem do Internetu, telefonii internetowej i internetowej poczty elektronicznej, delegacja powy$sza b%dzie wymaga"a wydania dwóch odr%bnych rozporz#dze'. W art. 180d zosta"y okre&lone organy pa'stwowe, którym przedsi%biorcy telekomunikacyjni, s# zobowi#zani zapewni) warunki dost%pu i utrwalania oraz udost%pni) zgromadzone dane na zasadach i przy zachowaniu procedur okre&lonych w przepisach odr%bnych. Zapewnienie warunków dost%pu i utrwalania, o których mowa w art. 180d, jest mo$liwe na trzy sposoby: – przez wykorzystanie interfejsu, o którym mowa w art. 179 ust. 4a. Zgodnie z zawart# w art. 182 delegacj# do wydania przez Rad% Ministrów rozporz#dzenia, b%dzie mo$liwe takie okre&lenie warunków technicznych i eksploatacyjnych dla interfejsów, aby by"y to interfejsy to$same, – przez budow% oddzielnego interfejsu, w oparciu o wymagania zawarte w rozporz#dzeniu Rady Ministrów wydanym na podstawie art. 182 projektu, – przez wykorzystanie obecnie posiadanych przez przedsi%biorców telekomunikacyjnych rozwi#za' technicznych oraz rozwi#za' planowanych w zwi#zku z konieczno&ci# udost%pniania danych retencyjnych. W ka$dym z wy$ej wymienionych przypadków skorzystanie z udost%pnienia danych przez interfejs b%dzie mo$liwe tylko w przypadku zawarcia porozumienia mi%dzy przedsi%biorc# telekomunikacyjnym a uprawnionym podmiotem, co minimalizuje koszty zarówno po stronie przedsi%biorcy, jak i podmiotu uprawnionego. Art. 180e ogranicza dost%p do danych podlegaj#cych retencji jedynie do upowa$nionych pracowników przedsi%biorców telekomunikacyjnych. Przepis art. 180f umo$liwia uzyskiwanie danych niezb%dnych do realizacji przez Prezesa UKE przepisów rozporz#dzenia Rady Ministrów z dnia 3 sierpnia 2004 r. w sprawie przygotowania i wykorzystania systemów "#czno&ci na potrzeby obronne pa'stwa (Dz. U. Nr 180, poz. 1855), nak"adaj#cych na Prezesa UKE obowi#zek dokonywania analizy mo$liwo&ci przedsi%biorców telekomunikacyjnych w zakresie ich wykorzystania na potrzeby obronne pa'stwa oraz utworzenia bazy danych o przedsi%biorcach telekomunikacyjnych niezb%dnej do przygotowania i wykorzystania obronnych systemów "#czno&ci. Proponowany przepis umo$liwi pozyskiwanie danych niezb%dnych do tworzenia takiej bazy oraz aktualizacji centralnej bazy danych o systemach "#czno&ci na potrzeby obronne pa'stwa zarz#dzanej przez Ministra Obrony Narodowej. Dotychczas nie by"o narz%dzia prawnego pozwalaj#cego skutecznie pozyskiwa) ww. danych. Wprowadzenie tego przepisu umo$liwi Prezesowi UKE w"a&ciwe wykonywanie zada' w zakresie obronno&ci. Art. 180g ust. 3 zawiera delegacj% do wydania rozporz#dzenia, którego przepisy okre&l# wzór formularza s"u$#cego do przekazywania informacji Prezesowi UKE .

14

Uchylenie przepisu art. 181 ustawy – Prawo telekomunikacyjne jest konsekwencj# przebudowy dzia"u VIII ustawy, przeniesienia delegacji z art. 181 do nowego art. 179 ust. 12. Art. 182 otrzyma" nowe brzmienie; zosta"y wykre&lone wytyczne dotycz#ce wymaga' europejskich organizacji normalizacyjnych i wymaga' innych mi%dzynarodowych organizacji normalizacyjnych, których Rzeczpospolita Polska jest cz"onkiem. Art. 190 ust. 4 i 4a Przywrócono kadencyjno&) Prezesa UKE oraz uzupe"niono przes"anki odwo"ania Prezesa UKE o mo$liwo&) jego odwo"ania z powodu nierealizowania przez niego celów ustawy – Prawo telekomunikacyjne. Propozycja ta wychodzi naprzeciw d#$eniom Komisji Europejskiej do zwi%kszenia niezale$no&ci krajowego organu regulacyjnego m.in. przez okre&lenie przejrzystych przes"anek odwo"ania jego szefa. W ramach przegl#du ram regulacyjnych "#czno&ci elektronicznej jest proponowany nast%puj#cy przepis art. 3 ust. 3 dyrektywy ramowej 2002/21/WE: „…Pa'stwa cz"onkowskie zapewniaj#, by zwolnienie szefów krajowych organów regulacyjnych lub ich zast%pców by"o mo$liwe wy"#cznie wówczas, gdy nie b%d# oni spe"nia) warunków wymaganych do wykonywania ich obowi#zków okre&lonych wcze&niej w prawie krajowym lub je$eli dopuszcz# si% powa$nego uchybienia. Decyzja o zwolnieniu szefa krajowego organu regulacyjnego zawiera uzasadnienie i jest opublikowana w chwili tego zwolnienia…”. Art. 192 W art. 192 ust. 5a zosta" rozszerzony katalog zakresu dzia"ania Prezesa UKE przez dodanie kompetencji do kontrolowania realizacji obowi#zków wynikaj#cych z przepisów rozporz#dzenia Parlamentu Europejskiego i Rady nr 717/2007/WE z dnia 27 czerwca 2007 r. w sprawie roamingu w publicznych sieciach telefonii ruchomej wewn#trz Wspólnoty oraz zmieniaj#cego dyrektyw% 2002/21/WE (Dz. Urz. WE L 171/32 z 29.06.2007, str. 32). W art. 192 ust. 5b zosta"a dodana kompetencja dotycz#ca wykonywania kontroli nad operatorami publicznej sieci telekomunikacyjnej i dostawcami publicznie dost%pnych us"ug telekomunikacyjnych w zakresie realizacji obowi#zków, o których mowa w art. 180a ust. 1. Przechowywanie danych retencyjnych ma by) podporz#dkowane podstawowym zasadom dotycz#cym prawid"owej ochrony i bezpiecze'stwa danych. W prawie polskim kontrola przestrzegania owych zasad mo$e by) prowadzona przez Generalnego Inspektora Ochrony Danych Osobowych jedynie po&rednio i w zakresie ograniczonym do danych osobowych, wed"ug zasad wynikaj#cych z ustawy o ochronie danych osobowych. Ww. nadzór b%dzie wykonywany przez Prezesa UKE z wy"#czeniem danych osobowych chronionych zgodnie z przepisami o ochronie danych osobowych. W art. 192 ust. 5c dodano kompetencj% Prezesa UKE do prowadzenia centralnej bazy numerów przeniesionych oraz bazy zawieraj#cej dane dotycz#ce infrastruktury telekomunikacyjnej eksploatowanej lub u$ywanej przez tego przedsi%biorc% niezb%dnej do przygotowania systemów "#czno&ci na potrzeby obronne pa'stwa, w tym systemu kierowania bezpiecze'stwem narodowym. Art. 206 ust. 2, 2a i 2b W art. 206 zosta" rozszerzony katalog roztrzygni%), od których przedsi%biorcom telekomunikacyjnym s"u$y odwo"anie. Zosta" uwzgl%dniony tryb odwo"awczy od 15

postanowienia o uznaniu rynku w"a&ciwego za rynek konkurencyjny oraz od decyzji w sprawie zniesienia lub zmiany obowi#zków regulacyjnych. Art. 209 ust. 1 pkt 28 i 29 Zaproponowane przepisy powsta"y w zwi#zku z: –

niewykonywaniem przez przedsi%biorców telekomunikacyjnych obowi#zku rejestrowania przypadków udost%pniania danych, o których mowa w art. 180c ust. 1 pkt 3 oraz w art. 180d,

–

wej&ciem w $ycie dnia 30 czerwca 2007 r. rozporz#dzenia (WE) nr 717/2007 Parlamentu Europejskiego i Rady z dnia 27 czerwca 2007 r. w sprawie roamingu w publicznych sieciach telefonii ruchomej wewn#trz Wspólnoty oraz zmieniaj#cego dyrektyw% 2002/21/WE, które nak"ada na pa'stwa cz"onkowskie Unii Europejskiej obowi#zek wprowadzenia przepisów okre&laj#cych kary stosowane w przypadku naruszenia ww. rozporz#dzenia.

Zmiany w ustawach: –

o Policji,

–

o Stra$y Granicznej,

–

o Biurze Ochrony Rz#du,

–

o kontroli skarbowej,

–

Kodeks post%powania karnego,

–

o (andarmerii Wojskowej i wojskowych organach porz#dkowych,

–

o Agencji Bezpiecze'stwa Wewn%trznego oraz Agencji Wywiadu,

–

o Centralnym Biurze Antykorupcyjnym,

–

o S"u$bie Kontrwywiadu Wojskowego oraz S"u$bie Wywiadu Wojskowego.

Przepisy zmieniaj#ce ustawy kompetencyjne zawarte w odpowiednich art. 2 – 11 ustawy maj# na celu dostosowanie siatki poj%ciowej stosowanej w ustawach kompetencyjnych precyzuj#cych uprawnienia podmiotów uprawnionych i nowych przepisów art. 180a ustawy dotycz#cych retencji danych telekomunikacyjnych. W ustawach kompetencyjnych Policji, Stra$y Granicznej, wywiadu skarbowego, (andarmerii Wojskowej, Biura Ochrony Rz#du, Agencji Bezpiecze'stwa Wewn%trznego, a tak$e S"u$by Kontrwywiadu Skarbowego, dodane zosta"y przepisy, które pozwalaj# na zastosowanie urz#dze' uniemo$liwiaj#cych telekomunikacj% na okre&lonym obszarze. Ponadto przewidziano obowi#zek informowania Prezesa UKE o zastosowaniu tych urz#dze', a tak$e wskazano, $e przy ich zastosowaniu b%dzie istnie) konieczno&) minimalizacji skutków braku mo$liwo&ci korzystania z us"ug telekomunikacyjnych. W ustawach kompetencyjnych zosta"y wprowadzone przepisy umo$liwiaj#ce przekazywanie danych retencyjnych za pomoc# sieci telekomunikacyjnych przedstawicielom upowa$nionych podmiotów. Rozwi#zanie takie w znacznym stopniu skróci czas oczekiwania na uzyskanie danych retencyjnych od podmiotu prowadz#cego dzia"alno&) telekomunikacyjn# oraz zmniejszy jego koszty. Zosta"y tak$e 16

wprowadzone przepisy pozwalaj#ce na udost%pnianie danych retencyjnych za po&rednictwem sieci telekomunikacyjnej bez udzia"u pracowników podmiotu prowadz#cego dzia"alno&). Zmiany w ustawie – Prawo upad"o&ciowe i naprawcze Dodanie ust. 6 w art. 53 ustawy – Prawo upad"o&ciowe i naprawcze jest konsekwencj# propozycji polegaj#cej na przej%ciu danych telekomunikacyjnych od upad"ego operatora publicznej sieci telekomunikacyjnej lub dostawcy publicznie dost%pnych us"ug telekomunikacyjnych. Dane takie by"yby przej%te przez Prezesa UKE w przypadku og"oszenia upad"o&ci lub braku nast%pcy prawnego podmiotu, który zako'czy" dzia"alno&) telekomunikacyjn#, na zasadach okre&lonych w rozporz#dzeniu Prezesa Rady Ministrów. Zmiana w ustawie o zarz#dzaniu kryzysowym W toku prac prowadzonych nad projektem ustawy o kompatybilno&ci elektromagnetycznej, wdra$aj#cej do krajowego systemu prawnego dyrektyw% 2004/108/WE – „Dyrektywa 2004/108/WE Parlamentu Europejskiego i Rady z dnia 15 grudnia 2004 r. w sprawie zbli$enia ustawodawstw Pa'stw Cz"onkowskich odnosz#cych si% do kompatybilno&ci elektromagnetycznej oraz uchylaj#ca dyrektyw% 89/336/EWG” – wyst#pi"a kwestia w"a&ciwej implementacji art. 4 ust. 2 lit. b ww. dyrektywy, dotycz#cego zastosowania przez pa'stwa cz"onkowskie &rodków specjalnych w zakresie oddawania do u$ytku lub u$ytkowania urz#dze' i &rodków specjalnych podejmowanych ze wzgl%dów bezpiecze'stwa, w celu ochrony publicznej sieci telekomunikacyjnej lub stacji odbiorczych lub nadawczych, u$ytkowanych w celach zapewnienia bezpiecze'stwa w wyra!nie okre&lonym spektrum sytuacji. *rodki te nie maj# zwi#zku z kwestiami kompatybilno&ci elektromagnetycznej, ale ich ewentualne wprowadzenie mo$e mie) wp"yw na swobodny przep"yw urz#dze', które musz#, na podstawie przepisów ustawy o kompatybilno&ci elektromagnetycznej, spe"nia) zasadnicze wymagania dotycz#ce kompatybilno&ci elektromagnetycznej zarówno na etapie wprowadzania ich do obrotu, jak równie$ w fazie u$ywania tych urz#dze' przez operatorów telekomunikacyjnych i innych u$ytkowników. Poniewa$ „&rodki podejmowane ze wzgl%dów bezpiecze'stwa” by"yby wprowadzane z przyczyn innych, ni$ brak zgodno&ci z zasadniczymi wymaganiami w zakresie kompatybilno&ci elektromagnetycznej, wydaje si% w"a&ciwe wdro$enie ww. przepisu dyrektywy 2004/108/WE w ustawie o zarz#dzaniu kryzysowym. Proponowane umiejscowienie ww. zmiany jako art. 11a ustawy o zarz#dzaniu kryzysowym wi#$e si% z tre&ci# art. 11, w którym w ust. 2 dotycz#cym zada' Rz#dowego Centrum Bezpiecze'stwa w pkt 6 jest wymieniona wspó"praca ze strukturami Paktu Pó"nocnoatlantyckiego i Unii Europejskiej. Proponowana zmiana do ustawy o zarz#dzaniu kryzysowym by"a wnoszona na etapie prac parlamentarnych nad t# ustaw#, jednak propozycja ta nie znalaz"a swojego fina"u w ostatecznym tek&cie ustawy. Przepisy przej&ciowe Art. 13 Przepis przej&ciowy dotycz#cy umorzenia post%powa' administracyjnych wszcz%tych na podstawie przepisów dotychczasowych zwi#zanych z odroczeniem terminu wykonywania przez przedsi%biorców obowi#zków zwi#zanych z przygotowaniem warunków do prowadzenia kontroli operacyjnej przez podmioty uprawnione. 17

Aktualnie w UKE s# prowadzone dwie grupy post%powa' administracyjnych ("#cznie 332) z wniosków przedsi%biorców telekomunikacyjnych: –

o odroczenie terminu zapewnienia uprawnionym podmiotom technicznych i organizacyjnych mo$liwo&ci realizacji zada' na rzecz obronno&ci, bezpiecze'stwa pa'stwa oraz bezpiecze'stwa i porz#dku publicznego, z"o$onych na podstawie przepisów art. 40 ust. 2 ustawy z dnia 21 lipca 2000 r. – Prawo telekomunikacyjne (249 post%powa'),

–

o odroczenie terminu wykonywania przedmiotowych zada' i obowi#zków, z"o$onych na podstawie przepisów art. 179 ust. 6 ustawy z dnia 16 lipca 2004 r. – Prawo telekomunikacyjne (83 post%powania).

Post%powania pierwszej grupy s# prowadzone od marca 2003 r., za& drugiej grupy od kwietnia 2005 r. W sprawie tych post%powa' Prezes URTiP wielokrotnie wydawa" postanowienia informuj#ce o niemo$liwo&ci rozpatrzenia sprawy w terminie ustawowym i wyznaczaj#ce nowy termin za"atwienia sprawy. Wydawane postanowienia by"y uzasadniane przede wszystkim brakiem mo$liwo&ci za"atwienia sprawy z uwagi na niewydanie (do dnia wydania postanowienia) aktu wykonawczego b%d#cego wype"nieniem delegacji do art. 182 Prawa telekomunikacyjnego, tj. okre&laj#cego 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. W proponowanej nowelizacji odchodzi si% od instytucji „odraczania terminu”, natomiast wprowadza si% mo$liwo&) zwolnienia przedsi%biorcy telekomunikacyjnego z zapewnienia warunków dost%pu i utrwalania tre&ci przekazów telekomunikacyjnych i danych zwi#zanych z tymi przekazami. Zwolnienia te s# przewidziane wy"#cznie w szczególnie uzasadnionych przypadkach i nie mog# by) realizowane masowo, tak jak to umo$liwiaj# przepisy dotycz#ce odroczenia terminu. Ponadto przepisy rozporz#dzenia Rady Ministrów z dnia 13 wrze&nia 2005 r. w sprawie wype"niania przez przedsi%biorców telekomunikacyjnych zada' i obowi#zków na rzecz obronno&ci, bezpiecze'stwa pa'stwa oraz bezpiecze'stwa i porz#dku publicznego, niezale$nie od mo$liwo&ci 6-miesi%cznego odroczenia terminu, przewiduj# 12-miesi%czny termin dostosowania si% przedsi%biorcy telekomunikacyjnego do wymaga' wynikaj#cych z rozporz#dzenia, tj. do dnia 11 pa!dziernika 2006 r. Tak wi%c w obecnie obowi#zuj#cym stanie prawnym wszyscy przedsi%biorcy telekomunikacyjni, bez wzgl%du na konieczno&) wyst#pienia szczególnie uzasadnionych okoliczno&ci, korzystaj# z mocy prawa z 12-miesi%cznego okresu przej&ciowego, w którym nie musz# spe"nia) wymaga' okre&lonych w przepisach. St#d te$ prowadzone post%powania administracyjne sta"y si% w istocie bezzasadne, jednak istniej#ce przepisy prawa nie pozwalaj# Prezesowi UKE na ich umorzenie. Art. 15 W zwi#zku z proponowanymi zmianami w art. 190 w zakresie mo$liwo&ci odwo"ywania Prezesa UKE i przywrócenia jego kadencyjno&ci, które przyczyniaj# si% do niezale$no&ci organu, rozwi#zanie takie wydaje si% najw"a&ciwsze. Art. 16 Przepis przej&ciowy dotycz#cy retencji danych internetowych, których nie dotyczy przedmiotowa nowelizacja (w odniesieniu do tej kategorii danych Polska skorzysta"a z odroczenia stosowania postanowie' dyrektywy 2006/24/WE, zgodnie z art. 15 ust. 3 ww. dyrektywy). W zwi#zku z powy$szym, do czasu uregulowania kwestii retencji danych

18

internetowych, jest konieczne zachowanie dotychczasowych zasad przechowywania tych danych. Art. 165 ust. 1 i art. 166 ust. 5 Prawa telekomunikacyjnego w obecnym brzmieniu nak"adaj# na operatorów publicznych sieci telekomunikacyjnych i dostawców publicznie dost%pnych us"ug telekomunikacyjnych obowi#zek przechowywania przez okres 2 lat danych transmisyjnych dotycz#cych abonentów i u$ytkowników ko'cowych i ich udost%pniania „z uwagi na realizacj% przez uprawnione organy zada' i obowi#zków na rzecz obronno&ci, bezpiecze'stwa pa'stwa oraz bezpiecze'stwa i porz#dku publicznego”. Rozwi#zanie to jest oparte na przewidzianej w art. 15 ust. 1 dyrektywy 2002/58/WE Parlamentu Europejskiego i Rady z dnia 12 lipca 2002 r. dotycz#cej przetwarzania danych osobowych i ochrony prywatno&ci w sektorze "#czno&ci elektronicznej mo$liwo&ci odst%pstwa od tajemnicy telekomunikacyjnej. W zwi#zku z przyj%ciem dyrektywy 2006/24/WE Parlamentu Europejskiego i Rady z dnia 15 marca 2006 r. w sprawie zatrzymywania generowanych lub przetwarzanych danych w zwi#zku ze &wiadczeniem ogólnie dost%pnych us"ug "#czno&ci elektronicznej lub udost%pnianiem publicznych sieci "#czno&ci oraz zmieniaj#cej dyrektyw% 2005/58/WE, re$im przechwytywania danych zwi#zanych z przekazami telekomunikacyjnymi uleg" daleko id#cym zmianom. Dyrektywa 2006/24/WE wprowadzi"a szczegó"owe regulacje w zakresie zatrzymywania i przechowywania okre&lonych kategorii danych telekomunikacyjnych, stanowi#c w tym zakresie lex specialis wobec dyrektywy 2002/58/WE (wyra!nie podkre&la to art. 11 dyrektywy 2006/24/WE). Oznacza to, $e retencja danych we Wspólnocie b%dzie odt#d regulowana w dwojaki sposób: – dane telekomunikacyjne, o których mowa w art. 5 dyrektywy 2006/24/WE, b%d# zatrzymywane i przechowywane zgodnie ze standardami okre&lonymi w tej dyrektywie, – pozosta"e dane – b%d# zatrzymywane i przechowywane w sposób okre&lony w art. 15 ust. 1 dyrektywy 2002/58/WE (wyra!nie podkre&la to motyw 12 preambu"y do dyrektywy 2006/24/WE). Prawo krajowe powinno uwzgl%dnia) ró$nice wynikaj#ce ze wspólnotowej regulacji retencji danych telekomunikacyjnych w zale$no&ci od ich kategorii. Oznacza to konieczno&) uchylenia b#d! zmiany art. 165 ust. 1 Prawa telekomunikacyjnego w jego obecnym kszta"cie. Przepis ten ustanawia, w zakresie retencji danych telekomunikacyjnych, ten sam re$im prawny dla wszystkich danych transmisyjnych obejmuj#cych równie$ dane obj%te postanowieniami dyrektywy 2006/24/WE. Art. 17 Ustawa wchodzi w $ycie po up"ywie 30 dni od dnia og"oszenia, z wyj#tkiem art. 180a ust. 3, który wchodzi w $ycie z dniem 1 stycznia 2010 r. Art. 180a ust. 3 reguluje kwestie przej%cia danych telekomunikacyjnych od upad"ego operatora publicznej sieci telekomunikacyjnej lub dostawcy publicznie dost%pnych us"ug telekomunikacyjnych przez Prezesa UKE. Bior#c pod uwag% konieczno&) podj%cia wszystkich dzia"a' logistycznych i organizacyjnych zwi#zanych z utworzeniem systemu zwi#zanego z przechowywaniem, udost%pnianiem oraz ochron# przej%tych przez Prezesa UKE od upad"ego operatora danych planuje si%, $e uruchomienie systemu nast#pi na pocz#tku 2010 r. Warto podkre&li), $e aktualnie nie s# znane przypadki prowadzenia post%powa' upad"o&ciowych wobec operatorów publicznej sieci telekomunikacyjnej i dostawców publicznie dost%pnych us"ug telekomunikacyjnych. Ze wzgl%du na d"ugotrwa"o&) post%powania upad"o&ciowego, przesuni%cie w czasie uruchomienia funkcjonowania systemu nie nast#pi ze szkod# ani dla operatorów publicznej sieci telekomunikacyjnej i dostawców publicznie dost%pnych us"ug telekomunikacyjnych, ani dla podmiotów uprawnionych.

19

Projekt ustawy nie podlega notyfikacji zgodnie z trybem przewidzianym w przepisach dotycz#cych sposobu funkcjonowania krajowego systemu notyfikacji norm i aktów prawnych. Projekt ustawy jest zgodny z prawem Unii Europejskiej. Zgodnie z art. 5 ustawy z dnia 7 lipca 2005 r. o dzia"alno&ci lobbingowej w procesie stanowienia prawa (Dz. U. Nr 169, poz. 1414) projekt ustawy zosta" udost%pniony w Biuletynie Informacji Publicznej Ministerstwa Infrastruktury. Organizacje o charakterze lobbingowym wymienione w rejestrze podmiotów wykonuj#cych zawodow# dzia"alno&) lobbingow# (bip.mswia.gov.pl) nie zg"osi"y zainteresowania pracami nad projektem ustawy.

20

OCENA SKUTKÓW REGULACJI 1. Podmioty, na które oddzia"uj# projektowane regulacje Do podmiotów, na które oddzia"uj# projektowane regulacje nale$# przedsi%biorcy telekomunikacyjni wpisani do rejestru prowadzonego przez Prezesa UKE, których jest obecnie oko"o siedmiu tysi%cy, podmioty posiadaj#ce rezerwacj% cz%stotliwo&ci, pozwolenia radiowe, konsumenci, u$ytkownicy ko'cowi, organy administracji rz#dowej. Przepisy art. 176 – 178 dotycz#ce obowi#zków przedsi%biorców telekomunikacyjnych w sytuacjach szczególnych zagro$e', w tym planowania procedur uruchamianych w przypadku zagro$e', wprowadzania specyficznych ogranicze' w prowadzonej dzia"alno&ci telekomunikacyjnej oraz udost%pniania urz#dze' w przypadku ich niezb%dno&ci przy prowadzeniu akcji ratowniczej, s# przepisami uporz#dkowanymi pod wzgl%dem poj%ciowym i terminologicznym w stosunku do obecnych przepisów ustawy – Prawo telekomunikacyjne. Zak"adaj# one m.in. z"agodzenie obowi#zków przez okre&lenie katalogu przedsi%biorców i rodzajów dzia"alno&ci telekomunikacyjnej niepodlegaj#cych obowi#zkowi wykonywania planów dzia"a' w sytuacjach szczególnych zagro$e'. Zosta" ograniczony tak$e zakres przedmiotowy zawarto&ci planów przedsi%biorców. Wprowadzono postulowane przez przedsi%biorców okre&lenie sytuacji szczególnych zagro$e' oraz skonkretyzowano przepisy okre&laj#ce, w którym momencie nale$y przyst#pi) do realizacji procedur zawartych w planach. W tre&ci przepisów zrezygnowano ze &wiadczenia us"ug na zasadach priorytetowych, gdy$ jak wskaza"y techniczne analizy i badania, realizacja tak sformu"owanego obowi#zku jest, wobec braku jednoznacznych standardów technicznych mo$liwych do zaimplementowania w urz#dzeniach telekomunikacyjnych, niemo$liwa do realizacji w sposób jednolity i obejmuj#cy wszystkie rodzaje urz#dze' komutacyjnych u$ytkowanych i eksploatowanych na krajowym rynku telekomunikacyjnym. Ocenia si%, $e przepisy art. 176 – 178 projektu "agodz# i konkretyzuj# obowi#zki narzucone na przedsi%biorców aktualnie obowi#zuj#cymi w tym zakresie przepisami ustawy – Prawo telekomunikacyjne i nie spowoduj# $adnych skutków negatywnych do prowadzenia przez przedsi%biorców dzia"alno&ci telekomunikacyjnej. Przepisy te, a w szczególno&ci przepisy art. 176, przy merytorycznym podej&ciu do ich wykonania powinny wp"yn#) na wi%ksz# wiarygodno&) przedsi%biorców, przez okre&lenie specyficznych mechanizmów i procedur pozwalaj#cych na kontynuowanie dzia"alno&ci tak$e w sytuacjach szczególnych zagro$e'. Podobnie nale$y oceni) nowe przepisy art. 179 i cz%&ciowo zwi#zane z nimi przepisy art. 180a – g. W projekcie, dokonano przede wszystkim konkretyzacji zapisów i ujednolicenia poj%) stosowanych nie tylko w ustawie nowelizowanej, ale tak$e przepisach ustaw kompetencyjnych. Powinno si% to przyczyni) do jednoznaczno&ci i usuni%cia szeregu w#tpliwo&ci formu"owanych przez &rodowisko telekomunikacyjne do obecnie funkcjonuj#cych przepisów precyzuj#cych obowi#zki przedsi%biorców w zakresie wspierania dzia"a' operacyjnych prowadzonych przez uprawnione organy pa'stwa. Dokonano m.in. konkretyzacji zakresu przedmiotowego danych podlegaj#cych utrwalaniu w"#cznie z tre&ciami korespondencji podlegaj#cej kontroli. W zakresie nowych przepisów dotycz#cych obowi#zków w zakresie zatrzymywania danych telekomunikacyjnych, sformu"owanych w art. 180a – 180f oraz 180i, dokonano pierwszego etapu (poziom ustawowy) implementacji dyrektywy UE w sprawie retencji danych telekomunikacyjnych. Koszty zwi#zane z przystosowaniem si% przedsi%biorców do realizacji obowi#zków w zakresie zatrzymywania danych s# pochodn# obowi#zku zatrzymywania pewnych kategorii 21

danych, z punktu widzenia przedsi%biorców zb%dnych, a uznanych za istotne i obj%tych obowi#zkiem zgodnie z dyrektyw# UE, takich jak np. dane o nieudanych próbach po"#cze', a tak$e silnie zale$# od okresu, z którego dane nale$y przechowywa). Skonkretyzowanie szacunkowych kosztów pe"nego wdro$enia przedmiotowych przepisów jest w chwili obecnej niemo$liwe, gdy$ brak jest na dzie' dzisiejszy gotowych do zastosowania technicznych rozwi#za', jak równie$ nie istniej# specyfikacje i standardy mi%dzynarodowe precyzuj#ce sposób realizacji przepisów dyrektywy w zakresie zatrzymywania danych dotycz#cych us"ug zwi#zanych z sieci# Internet, w tym poczty elektronicznej. 2. Konsultacje W ramach konsultacji spo"ecznych projekt ustawy zosta" przes"any do: Krajowej Izby Gospodarczej Elektroniki i Telekomunikacji, Polskiej Izby Komunikacji Elektronicznej, Polskiej Izby Informatyki i Telekomunikacji, Konfederacji Pracodawców Polskich, Polskiej Konfederacji Pracodawców Prywatnych, Stowarzyszenia Budowniczych Telekomunikacji, Krajowej Izby Gospodarczej Budownictwa Telekomunikacyjnego, Federacji Zwi#zków Pracowników Telekomunikacji, Stowarzyszenia In$ynierów Telekomunikacji oraz Stowarzyszenia Elektryków Polskich . Uwagi zg"oszone przez zainteresowane podmioty by"y dok"adnie analizowane i zosta"y cz%&ciowo uwzgl%dnione w ostatecznej wersji projektu. Uwzgl%dniono m.in. uwag% PIIT, PKPP i FZZPT, aby art. 6 dotyczy" obowi#zku przekazywania przez przedsi%biorców telekomunikacyjnych tylko informacji a nie dokumentów – co w konsekwencji spowodowa"o zdj%cie z tych przedsi%biorców obowi#zku t"umaczenia niektórych dokumentów przez t"umaczy przysi%g"ych i ponoszenia przez nich kosztów z tym zwi#zanych (uwaga KIGEiT). Uwzgl%dniono, ze wzgl%du na du$e koszty, jak i trudno&ci w realizacji przez przedsi%biorców, wniosek PIIT, PKPP, KIGEiT i FZZPT o wykre&lenie art. 80a, który przewidywa" mo$liwo&) nieodp"atnego ograniczenia przez abonenta wysoko&ci maksymalnej miesi%cznej kwoty za po"#czenia telefoniczne, po przekroczeniu której &wiadczenie us"ug mia"o by) zawieszone. W projekcie uwzgl%dniono cz%&ciowo uwagi zg"oszone w trakcie konsultacji &rodowiskowych do przepisów reguluj#cych obowi#zki przedsi%biorców telekomunikacyjnych na rzecz obronno&ci, bezpiecze'stwa pa'stwa, bezpiecze'stwa i porz#dku publicznego. Obowi#zki okre&lone w art. 171 ust. 8 i 10 zosta"y na"o$one na wszystkich przedsi%biorców telekomunikacyjnych. W art. 179 ust. 7 zosta"o wprowadzone rozwi#zanie, które minimalizuje koszty po stronie przedsi%biorcy telekomunikacyjnego, polegaj#ce na umo$liwieniu outsourcingu obowi#zku z art. 179 ust. 3 na podmiot wyspecjalizowany w &wiadczeniu tego typu us"ug, którym jest przedsi%biorca telekomunikacyjny, przy zachowaniu odpowiedzialno&ci przedsi%biorcy telekomunikacyjnego (powierzaj#cego). W art. 180b ust. 2 zosta"o wprowadzone rozwi#zanie, które minimalizuje koszty po stronie operatora publicznej sieci telekomunikacyjnej lub dostawcy publicznie dost%pnych us"ug telekomunikacyjnych, polegaj#ce na umo$liwieniu outsourcingu obowi#zku z art. 180a ust. 1 na podmiot wyspecjalizowany w &wiadczeniu tego typu us"ug, którym jest przedsi%biorca telekomunikacyjny, przy zachowaniu odpowiedzialno&ci przedsi%biorcy telekomunikacyjnego (powierzaj#cego). Natomiast w art. 180b ust. 2 odst#piono od obowi#zku przekazywania w terminie 30 dni od dnia zawarcia przez operatorów publicznej sieci telekomunikacyjnej lub dostawców

22

publicznie dost%pnych us"ug telekomunikacyjnych Prezesowi UKE umów zawartych mi%dzy nimi, które reguluj# realizacj% obowi#zku, o którym mowa w art. 180a ust. 1. W art. 180c ust. 1 zosta"y wprowadzone poprawki polegaj#ce na wprowadzeniu poj%) zgodnych z Prawem telekomunikacyjnym. 3. Wp"yw regulacji na sektor finansów publicznych 1) wej&cie w $ycie projektowanych zmian ustawy spowoduje skutki finansowe dla bud$etu pa'stwa zwi#zane z rozszerzeniem katalogu narusze' skutkuj#cych na"o$eniem kar pieni%$nych nak"adanych przez Prezesa UKE, co mo$e spowodowa) dodatkowe wp"ywy do bud$etu pa'stwa, 2) w zwi#zku z propozycj# Ministra Sprawiedliwo&ci, aby po og"oszeniu upad"o&ci przez operatora publicznej sieci telekomunikacyjnej lub dostawcy publicznie dost%pnych us"ug telekomunikacyjnych dalsze przechowywanie, udost%pnianie oraz ochron% danych telekomunikacyjnych powierza si% Prezesowi UKE. Przewiduje si%, zgodnie z wyliczeniami Prezesa UKE, $e wst%pne koszty zwi#zane z zapewnieniem przejmowania i udost%pnienia przez Prezesa UKE danych „retencyjnych” od podmiotu, wobec którego og"oszono upad"o&), wynios#: a) zakup sprz%tu informatycznego i oprogramowania – ok. 7 mln z", b) budowa systemu zabezpieczenia zasilania oraz klimatyzacji – ok. 2 mln z", c) koszty utrzymania systemu informatycznego i oprogramowania – eksploatacja, aktualizacja oprogramowania, zabezpieczenie informatyczne (bez zapewnienia ochrony fizycznej) – ok. 1 mln z" (rocznie), d) okre&lenie wymaga', standardów dla interfejsu importowego do systemu informatycznego prowadzonego przez Prezesa UKE (koszt ekspertyzy) – ok. 100 tys. z", e) opracowanie SIWZ do systemu informatycznego i jego oprogramowania (koszt ekspertyzy) – ok. 500 tys. z", f) zatrudnienie 10 osób * &r. wynagr. 5000 z" – 600 tys. z". Wst%pny, ca"kowity koszt szacuje si% na ok. 11 mln z" (bez kosztów pozyskania budynku, w którym mia"by by) prowadzony system; w chwili obecnej nie mo$na oszacowa) tego kosztu z uwagi na to, $e Prezes UKE wyst#pi" do Ministra Obrony Narodowej o przekazanie informacji nt. mo$liwo&ci udost%pnienia budynku). ,ród"em finansowania b%d# &rodki finansowe zaplanowane w bud$ecie pa'stwa, w cz%&ci której dysponentem jest Prezes UKE. Koszty przechowywania danych retencyjnych w przypadku zaprzestania dzia"alno&ci przez przedsi%biorc% telekomunikacyjnego s# generowane g"ównie przez ilo&) przedsi%biorców, którzy zaprzestali prowadzenia dzia"alno&ci telekomunikacyjnej, przygotowanie warunków do przechowywania, wyboru i udost%pniania w"a&ciwych danych na $#danie uprawnionych podmiotów oraz zapewnienia warunków bezpiecze'stwa. Szacuje si%, $e tylko w niewielkim stopniu koszty te b%d# uzale$nione od okresu przechowywania danych transmisyjnych.

23

4. Wp"yw regulacji na rynek pracy Przyj%cie projektowanej regulacji nie b%dzie oddzia"ywa) na rynek pracy. 5. Wp"yw regulacji na konkurencyjno&) gospodarki i przedsi%biorczo&) Proponowane regulacje mog# mie) wp"yw na konkurencyjno&) w zakresie rynku telekomunikacyjnego. Celem proponowanych regulacji jest zapewnienie i zwi%kszenie skutecznej konkurencji na rynku telekomunikacyjnym. W zwi#zku z powy$szym ceny dost%pu do sieci Internet oraz ceny us"ugi powszechnej powinny ulega) stopniowemu zmniejszeniu.! Zgodnie z dyrektyw# ramow# organy regulacyjne poszczególnych krajów s# zobowi#zane do przeprowadzania analiz rynkowych w celu zidentyfikowania problemów na nich wyst%puj#cych, okre&lenia czy dany rynek jest konkurencyjny. W przypadku stwierdzenia, $e dany rynek nie jest w pe"ni konkurencyjny organ regulacyjny wyznacza na tym rynku przedsi%biorc% (lub przedsi%biorców) o znacz#cej pozycji rynkowej i nak"ada na niego (na nich) obowi#zki regulacyjne. Obowi#zki na"o$one w decyzji organu regulacyjnego na przedsi%biorc% (lub przedsi%biorców) o znacz#cej pozycji rynkowej maj# na celu zwi%kszenie konkurencyjno&ci panuj#cej na danym rynku. W&ród przyk"adowych obowi#zków jakie mog# zosta) na"o$one przez organ regulacyjny mo$na wskaza): – obowi#zek zapewnienia przedsi%biorcom telekomunikacyjnym dost%pu do sieci przedsi%biorcy posiadaj#cego pozycj% SMP, w tym u$ytkowania elementów infrastruktury lub sieci oraz udogodnie' towarzysz#cych, w celu &wiadczenia us"ugi, – obowi#zek równego traktowania przedsi%biorców telekomunikacyjnych w zakresie dost%pu telekomunikacyjnego, w szczególno&ci przez oferowanie jednakowych warunków w porównywalnych okoliczno&ciach, a tak$e oferowaniu us"ug oraz udost%pnianiu informacji na warunkach niegorszych od stosowanych w ramach w"asnego przedsi%biorstwa lub w stosunkach z podmiotami zale$nymi, – obowi#zek og"aszania informacji w sprawach zapewnienia dost%pu telekomunikacyjnego dotycz#cych specyfikacji technicznych sieci i urz#dze' telekomunikacyjnych, charakterystyki sieci, zasad i warunków &wiadczenia us"ug oraz korzystania z sieci, a tak$e op"at, – obowi#zek polegaj#cy na prowadzeniu rachunkowo&ci regulacyjnej w sposób umo$liwiaj#cy identyfikacj% przep"ywów transferów wewn%trznych zwi#zanych z dzia"alno&ci# w zakresie dost%pu telekomunikacyjnego w celu unikni%cia zawy$ania op"at lub stosowania innych rodzajów dyskryminacji cenowej, – obowi#zek polegaj#cy na ustalaniu op"at z tytu"u dost%pu telekomunikacyjnego w celu &wiadczenia dost%pu telekomunikacyjnego w oparciu o ponoszone koszty operatora i przedstawienia organowi regulacyjnemu uzasadnienia ich wysoko&ci w okre&lonym terminie od dnia dor%czenia decyzji, – obowi#zek polegaj#cy na przygotowaniu i przedstawieniu w okre&lonym terminie od dnia dor%czenia decyzji oferty ramowej o dost%pie telekomunikacyjnym, – oferowanie us"ug na warunkach hurtowych w celu ich dalszej odsprzeda$y przez innego przedsi%biorc%.

24

6. Wp"yw regulacji na sytuacj% i rozwój regionów Zapisy projektu mog# wp"yn#) na sytuacj% przedsi%biorców telekomunikacyjnych, a przez to równie$ na rozwój regionów. 7. Wst%pna ocena zgodno&ci regulacji z prawem Unii Europejskiej Projekt jest zgodny z prawem UE. Dostosowuje obowi#zuj#ce zapisy do regulacji unijnych.

28/10/BS

25

.'j) '.in ., : . .t .t

URZ4D EIJROPEJSKIEJ KOMITETIJINTEGR.ACJI SEKRETARZ KOMITETU INTEGRACJ] EUROPEJSK]EJ SEKRETARZ STANU Mikolaj Dowgielewicx MLn.MD,4i, lC /08/DPidb 2003r. Warszawa.dnia f pa2dziemika

Pan Maciej Berek SekretarzRadv Ministr6rv

Opinia o zgodno6ciz prawem Unii Europejskiej ustawy o zmianie ustawy - Frawo telekomunikacyjneoraz niekt6rych innych ustaw (pismo z dnia 24 wrzeSnia2008; nr RM-10-162-08)sporz4dzonanapodstawieart.9pkt3wnv.zart.2ust'1pkt2iust.2 pkt 2a ustawy z dnia I sierpnia 1996 r. o Komitecie Integracji Europejskiej(Dz. U. Nr 106, poz. 494) oraz art. 42 ust 4 Regulaminu Sejmu przez Sekretarza Komitetu Integracji EuropejskiejMikolaja Dowgielewicza

Szcutoutty Puni e M i nistrze, W ni iqzku z przedloZonlmdo rozpatrzeniaprzez Radp Nlinistrdrvprojektem ustc.wyo zmianieustawl,- Prawo telekomnnikacyjne oraz niekt6rTchinnychurslaw(pismonr RM-10opiniq: 162-08)pozwalamsobiewyrazi6nastEpujqc4 I.

Projekt rv obecnymbrzmieniu jest zgodnyz prawem Unii Europejskiej.

II. W projekcie zmiany ustawy Prawo telekomunikacyne Minister lnfrastnktury zaproponowal,aby w ustawieo zarz^{lzediukryzysowl'm doda6art. Ila, zgodruez L:t6rym (dalej Centrum)informuje Komisjq Europejsk4i paitstwa RzqdoweCentrumBezpieczefistwa czlonkvskie Unii Europejskielo irodkach zastosowanychw sytuacji lolzysowej, w celu zabezpieczeniaprou'idlowego dzialania publicznej s[eci telekomunikacyinejoraz staciI w zakres[edot]czqcym i odbiorczychu4wanych do zapewnieniabezpieczeitstwa, nadtr,vczych lqcznoicii sieci teleinformat.ycznych. sy.stemu Minister Spraw Wewnqtrmych i Administracji zaklvestionowalnalo2enie na Centrurn obowiEzkuinforrnorvaniaKomisji o stosowaniu\,D/zejwymienionychSrodk6w,jak rowniez podni6slw4tpliwodcico do kompetencjiCentrumw tym zakresie. Art. lla ma na celu irnplementacjqdyrekty*y 2004/108A\lE rv sprawie zblilania elektromagnetyczne.l panstwczlonkowskichodnoszzlcych siEdo kompatybilnoSci ustawodarvstw otv, uchyiaj4cej dyektyuE 89/336/E\\rG' (dalej dyrektyrva). Dy'rektyrva regulqe urzldzefl na rynkachwewnEtrznych. kompa!-bilno56elektromagletycznych r D z . U r zW . E L J O 9' - 3 1 . 1 2 . 2 0 0 4 . s r . . 2 2 . .':

--_.:,:,r\

,,

r:(iir\i

'l l00B10o

PROJEKT

ROZPORZ!DZENIE RADY MINISTRÓW z dnia ................................. w sprawie planu dzia"a# przedsi$biorcy telekomunikacyjnego w sytuacjach szczególnych zagro%e# (Dz. U. z dnia .......................)

Na podstawie art. 176a ust. 5 ustawy z dnia …….. - Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800, z pó!n. zm.1)) zarz#dza si%, co nast%puje: § 1. Rozporz#dzenie okre&la: 1) zawarto&) oraz tryb sporz#dzania i aktualizacji przez przedsi%biorc% telekomunikacyjnego, zwanego dalej "przedsi%biorc#", planu dzia"a' w sytuacjach szczególnych zagro$e', zwanego dalej "planem"; 2) zakres uzgodnie' planu z organami, o których mowa w § 8; 3) rodzaje przedsi%biorców obowi#zanych do uzgadniania zawarto&ci planów; 4) rodzaje przedsi%biorców nie podlegaj#cych obowi#zkowi sporz#dzania planu. § 2. Obowi#zkowi sporz#dzenia planu nie podlega przedsi%biorca, który wykonuje dzia"alno&) gospodarcz#: 1) polegaj#c# wy"#cznie na dostarczaniu udogodnie' towarzysz#cych; 2) wy"#cznie na obszarze nie przekraczaj#cym granic administracyjnych gminy. § 3. 1. Przedsi%biorca, z zastrze$eniem ust. 2, sporz#dza plan dla obszaru wykonywania dzia"alno&ci telekomunikacyjnej, okre&lonego we wniosku o wpis do rejestru przedsi%biorców telekomunikacyjnych. 2. Przedsi%biorca sporz#dza plan dla faktycznego obszaru wykonywanej dzia"alno&ci w przypadku, gdy obszar ten jest mniejszy od okre&lonego we wniosku, o którym mowa w ust. 1. 3. Przedsi%biorca wykonuj#cy dzia"alno&) telekomunikacyjn# na jednym lub kilku obszarach, które nie przekraczaj# granic administracyjnych powiatu, sporz#dza plan dla ca"o&ci lub cz%&ci powiatu, na obszarze którego wykonuje dzia"alno&), zwany dalej "planem lokalnym". 4. Przedsi%biorca wykonuj#cy dzia"alno&) telekomunikacyjn# na jednym lub kilku obszarach, które przekraczaj# granice administracyjne powiatu, sporz#dza plan dla cz%&ci lub ca"o&ci ka$dego województwa, na obszarze którego wykonuje dzia"alno&), zwany dalej "planem rejonowym". 5. Przedsi%biorca, o którym mowa w wykazie stanowi#cym za"#cznik do rozporz#dzenia Rady Ministrów z dnia 9 listopada 2007 r. w sprawie wykazu przedsi%biorców o szczególnym

1)

Zmiany wymienionej ustawy zosta"y og"oszone w Dz. U. z 2004 r. Nr 273, poz. 2703, z 2005 r. Nr 163, poz. 1362 i numer 267, poz. 2258, z 2006 r. Nr 12, poz. 66, Nr 104, poz. 708 i 711, Nr 170, poz. 1217, Nr 220, poz. 1600, Nr 235, poz. 1700 i Nr 249, poz. 1834, z 2007 r. Nr 23, poz. 137, Nr 50, poz. 331, Nr 82, poz. 556 oraz z 2008 Nr 17, poz. 101.

znaczeniu gospodarczo-obronnym (Dz. U. Nr 214, poz. 1571), sporz#dza plan dla obszaru ca"ego kraju, zwany dalej "planem ogólnym", oraz plan rejonowy odr%bnie dla obszaru ka$dego województwa, na obszarze którego wykonuje dzia"alno&). § 4. 1. Przedsi%biorca sporz#dzaj#cy plan dokonuje: 1) analizy potencjalnych, szczególnych zagro$e' na obszarze, na którym wykonuje dzia"alno&) telekomunikacyjn#; 2) oceny wp"ywu szczególnych zagro$e' na w"asn# infrastruktur% telekomunikacyjn# oraz zdolno&) do zachowania ci#g"o&ci prowadzonej przez siebie dzia"alno&ci telekomunikacyjnej; 3) analizy potrzeb w zakresie &wiadczenia, utrzymania i odtwarzania us"ug telekomunikacyjnych oraz dost%pu telekomunikacyjnego do wspó"pracy z: a) podmiotami koordynuj#cymi dzia"ania ratownicze, b) podmiotami zarz#dzania kryzysowego, c) s"u$bami ustawowo powo"anymi do niesienia pomocy, d) podmiotami realizuj#cymi zadania na rzecz obronno&ci, bezpiecze'stwa pa'stwa oraz bezpiecze'stwa i porz#dku publicznego, wskazanymi przez organy, o których mowa w § 8; 2. Analizy i oceny, o których mowa w ust. 1 pkt 1 i 3, na potrzeby sporz#dzania planów rejonowych i lokalnych, przedsi%biorca dokonuje na podstawie danych uzyskanych, po wyst#pieniu o ich udost%pnienie, od w"a&ciwych terytorialnie wojewodów lub starostów. 3. Analizy i oceny, o których mowa w ust. 1 pkt 1 i 3, na potrzeby sporz#dzania planów ogólnych, przedsi%biorca dokonuje na podstawie danych uzyskanych, po wyst#pieniu o ich udost%pnienie, od organów, o których mowa w § 8 ust. 1 pkt 1 i 2, lub wskazanych przez nie centralnych organów administracji rz#dowej, odpowiednio do ich kompetencji. § 5. Plan ogólny powinien zawiera) w szczególno&ci: 1) podstawowe dane identyfikuj#ce przedsi%biorc% okre&lone w art. 10 ust. 4 pkt 1, 2, 5 i 6 ustawy z dnia 16 lipca - Prawo telekomunikacyjne, zwanej dalej "ustaw#"; 2) imiona, nazwiska, adresy i numery telefonów osób odpowiedzialnych za sporz#dzenie planu, wraz z okre&leniem zakresu ich kompetencji; 3) wykaz przeprowadzonych uzgodnie', wraz z potwierdzeniem ich dokonania przez podmioty, o których mowa w § 8; 4) ogóln# charakterystyk% prowadzonej dzia"alno&ci telekomunikacyjnej, w tym charakterystyk% &wiadczonych us"ug oraz wykaz obiektów infrastruktury telekomunikacyjnej o znaczeniu kluczowym dla funkcjonowania przedsi%biorcy i obiektów szczególnie wa$nych dla bezpiecze'stwa i obronno&ci pa'stwa ustalonych zgodnie z przepisami rozporz#dzenia Rady Ministrów z dnia 24 czerwca 2003 r. w sprawie obiektów szczególnie wa$nych dla bezpiecze'stwa i obronno&ci pa'stwa oraz ich szczególnej ochrony (Dz. U. Nr 116, poz. 1090); 5) wyniki analiz i oceny, o których mowa w § 4 ust. 1; 6) procedury wspó"pracy przedsi%biorcy w sytuacjach szczególnych zagro$e' z innymi przedsi%biorcami, dotycz#ce zapewnienia dost%pu telekomunikacyjnego, w tym w szczególno&ci wspó"pracy z zagranicznymi przedsi%biorcami telekomunikacyjnymi; 7) procedury wspó"pracy przedsi%biorcy z podmiotami, o których mowa w art. 4 pkt 1, 2, 4, 5, 7 i 8 ustawy, w zakresie &wiadczenia, utrzymania i odtwarzania us"ug telekomunikacyjnych oraz zapewnienia i odtwarzania dost%pu telekomunikacyjnego, w tym na zasadach pierwsze'stwa, po dokonaniu oceny, o której mowa w § 4 ust. 1 pkt 3; 2

8) procedury, warunki i sposób zapewnienia po"#cze' telekomunikacyjnych na zasadach pierwsze'stwa dla w"a&ciwych organów i s"u$b, innych ni$ okre&lone w pkt 7, ustalone na podstawie oceny, o której mowa w § 4 ust. 1 pkt 3, wraz z ich wykazem; 9) wykaz elementów sieci telekomunikacyjnych oraz sposób ich przygotowania do zapewnienia telekomunikacji na potrzeby podmiotów i s"u$b wymienionych w § 4, ust. 1, pkt 3 wraz z procedurami uruchomienia tych elementów zgodnie z art. 176a, ust. 2 pkt 4 ustawy; 10) procedury wspó"pracy z ministrem w"a&ciwym do spraw "#czno&ci, Prezesem Urz%du Komunikacji Elektronicznej, zwanym dalej "Prezesem UKE", oraz w"a&ciwymi organami i s"u$bami w zakresie sposobów wzajemnego przekazywania informacji, alarmowania i ostrzegania, dotycz#cych sytuacji szczególnych zagro$e', a tak$e powiadamiania o konieczno&ci podj%cia lub zaprzestania dzia"a' okre&lonych w planie, wraz z wykazem imion i nazwisk osób lub nazw s"u$b, w"a&ciwych w sprawach zarz#dzania kryzysowego, adresów lub siedzib, numerów telefonów i innych danych kontaktowych oraz zakresem ich kompetencji; 11) opis struktur organizacyjnych przedsi%biorcy obowi#zuj#cych w przypadku wyst#pienia sytuacji szczególnych zagro$e' wraz z wykazem imion i nazwisk osób lub nazw s"u$b, w"a&ciwych w sprawach zarz#dzania kryzysowego, adresów lub siedzib, numerów telefonów i innych danych kontaktowych oraz zakresem ich kompetencji; 12) opis wdro$onych systemów zabezpiecze' przed zak"óceniami, skutkami katastrof, kl%sk $ywio"owych i nieuprawnionym dost%pem oraz procedur dzia"ania i &rodków wdra$anych w sytuacjach szczególnych zagro$e' dla zabezpieczenia w"asnej infrastruktury telekomunikacyjnej przedsi%biorcy; 13) wykaz obiektów i elementów infrastruktury telekomunikacyjnej dostosowanych do wspó"pracy z ruchomymi urz#dzeniami telekomunikacyjnymi u$ywanymi przez podmioty, o których mowa w art. 4 pkt 1 ustawy, wraz z procedurami ich u$ycia; 14) wykaz zrealizowanych inwestycji, o których mowa w § 11 ust. 1 pkt 1 lit. d rozporz#dzenia Rady Ministrów z dnia 3 sierpnia 2004 r. w sprawie przygotowania i wykorzystania systemów "#czno&ci na potrzeby obronne pa'stwa (Dz. U. Nr 180, poz. 1855) zgodnie z art. 176a, ust. 2 pkt 3 i pkt 4 ustawy. 1) 2) 3)

4)

5)

§ 6. Plan rejonowy powinien zawiera) w szczególno&ci: tre&ci okre&lone w § 5 pkt 1-6, 8 i 10-14; procedury wspó"pracy przedsi%biorcy z w"a&ciwymi organami i s"u$bami w zakresie zachowania ci#g"o&ci &wiadczenia us"ug oraz ich odtwarzania na zasadach pierwsze'stwa w sytuacjach szczególnych zagro$e'; wykaz urz#dze' telekomunikacyjnych przeznaczonych lub mo$liwych do udost%pnienia przez przedsi%biorc% innym przedsi%biorcom telekomunikacyjnym lub w"a&ciwym organom i s"u$bom, niezb%dnych do przeprowadzenia akcji ratowniczych oraz procedury udost%pniania tych urz#dze'; charakterystyk% asortymentow# i ilo&ciow# zgromadzonych przez przedsi%biorc% rezerw przeznaczonych na utrzymanie ci#g"o&ci &wiadczenia us"ug oraz ich odtwarzanie w sytuacjach szczególnych zagro$e' wraz z procedurami ich u$ycia lub charakterystyk% warunków zapewnienia dostawy urz#dze' i podzespo"ów rezerwowych oraz us"ug zgodnie z umowami zawartymi z dostawcami; wykaz w"a&ciwych organów i s"u$b, dla których przedsi%biorca zapewnia dost%p telekomunikacyjny lub &wiadczy us"ugi wraz z okre&leniem ich rodzajów oraz procedur, warunków i sposobów &wiadczenia, utrzymania i odtwarzania tych us"ug lub dost%pu, 3

realizowanych po dokonaniu oceny, o której mowa w § 4 ust. 1 pkt 3. § 7. Plan lokalny powinien zawiera) w szczególno&ci: 1) tre&ci okre&lone w § 5 pkt 1-6, 8, 11, 12 oraz § 6 pkt 2-5; 2) procedury wspó"pracy z Prezesem UKE oraz w"a&ciwymi organami i s"u$bami w zakresie sposobów wzajemnego przekazywania informacji, alarmowania i ostrzegania, dotycz#cych sytuacji szczególnych zagro$e', a tak$e powiadamiania o konieczno&ci podj%cia lub zaprzestania dzia"a' okre&lonych w planie, wraz z wykazem imion i nazwisk osób lub nazw s"u$b, w"a&ciwych w sprawach zarz#dzania kryzysowego, adresów lub siedzib, numerów telefonów i innych danych kontaktowych oraz zakresem ich kompetencji. § 8. 1. Ka$dy przedsi%biorca sporz#dzaj#cy plan ogólny dokonuje jego uzgodnie' z: 1) Ministrem Obrony Narodowej, ministrem w"a&ciwym do spraw wewn%trznych - w zakresie okre&lonym w § 5 pkt 7-10 i 13; 2) ministrem w"a&ciwym do spraw zagranicznych, ministrem w"a&ciwym do spraw finansów publicznych, Ministrem Sprawiedliwo&ci, Szefem Agencji Bezpiecze'stwa Wewn%trznego oraz Szefem Agencji Wywiadu - w zakresie okre&lonym w § 5 pkt 7 i 8; 3) ministrem w"a&ciwym do spraw "#czno&ci - w zakresie okre&lonym w § 5 pkt 9, 10 i 14; 4) Prezesem UKE - w zakresie okre&lonym w § 5 pkt 10, 13 i 14. 2. Ka$dy przedsi%biorca sporz#dzaj#cy plan rejonowy (z zastrze$eniem ust. 4) dokonuje jego uzgodnie' z: 1) ministrem w"a&ciwym do spraw "#czno&ci - w zakresie okre&lonym w § 5 pkt 10 i 14; 2) Prezesem UKE - w zakresie okre&lonym w § 5 pkt 10, 13 i 14; 3) w"a&ciwym terytorialnie wojewod# - w zakresie okre&lonym w § 5 pkt 8 i 10 oraz w § 6 pkt 2 i 5. 3. Ka$dy przedsi%biorca sporz#dzaj#cy plan lokalny (z zastrze$eniem ust. 4) dokonuje jego uzgodnie' z: 1) Prezesem UKE - w zakresie okre&lonym w § 7 pkt 2; 2) w"a&ciwym terytorialnie starost# - w zakresie okre&lonym w § 5 pkt 8, § 6 pkt 2 i 5 oraz § 7 pkt 2. 4. Obowi#zkowi uzgadniania planu nie podlega przedsi%biorca, którego jedyn# form# dzia"alno&ci telekomunikacyjnej jest tylko i wy"#cznie: 1) *wiadczenie us"ug telefonii komórkowej jako operator wirtualnej sieci ruchomej MVNO (Mobile Virtual Network Operator) lub; 2) *wiadczenie us"ug transmisji programów radiofonicznych lub telewizyjnych. § 9. Po dokonaniu uzgodnie', o których mowa w § 8, przedsi%biorca wprowadza plan do stosowania, co potwierdza podpisem osoba uprawniona do prowadzenia spraw przedsi%biorcy w zakresie okre&lonym w rozporz#dzeniu. § 10. 1. Po zatwierdzeniu planu przedsi%biorca przekazuje: 1) po jednym egzemplarzu planu, o którym mowa w § 3 ust. 4 i 5, ministrowi w"a&ciwemu do spraw "#czno&ci oraz Prezesowi UKE; 2) jeden egzemplarz planu, o którym mowa w § 3 ust. 3, Prezesowi UKE. 2. W przypadku stwierdzenia braku kompletno&ci planu, Prezes UKE zwraca go przedsi%biorcy, wyznaczaj#c termin jego uzupe"nienia. 3. Przedsi%biorca sporz#dza i przekazuje nieodp"atnie wyci#g z planu, sporz#dzony w

4

zakresie zagadnie' podlegaj#cych uzgodnieniom, organom uzgadniaj#cym plan, na ich wniosek. 4. Obowi#zkowi przekazania planu osobom wymienionym w ust. 1 nie podlega przedsi%biorca wymieniony w § 8 ust. 4. § 11. 1. Plan podlega okresowej aktualizacji - nie rzadziej ni$ raz na 3 lata, w trybie okre&lonym w § 4-10. 2. Plan podlega bie$#cej aktualizacji w przypadku wyst#pienia okoliczno&ci wp"ywaj#cych na jego zawarto&), a w szczególno&ci: 1) w przypadku zmian w infrastrukturze telekomunikacyjnej oraz zakresie wykonywanej dzia"alno&ci telekomunikacyjnej, wp"ywaj#cych na zmian% sposobu i form% realizacji planu; 2) w przypadku zmiany danych identyfikuj#cych przedsi%biorc%, warunków lub procedur wspó"pracy z organami uzgadniaj#cymi zawarto&) planu; 3) na wniosek w"a&ciwych organów administracji publicznej uzgadniaj#cych zawarto&) planu, uzasadniony zmianami potrzeb, o których mowa w § 4 ust. 1 pkt 3; 4) w przypadku zmiany danych dotycz#cych szczególnych zagro$e'. 3. Zmiana tre&ci planu, o których mowa w § 5 pkt 7-10, 13 i 14, § 6 pkt 2 i 5 oraz § 7 pkt 2, wymaga uzgodnienia z organami, o których mowa w § 8, w zakresie ich w"a&ciwo&ci. 4. Tre&) ka$dej zmiany planu ogólnego i rejonowego przedsi%biorca przekazuje odpowiednio ministrowi w"a&ciwemu do spraw "#czno&ci oraz Prezesowi UKE. 5. Tre&) ka$dej zmiany planu lokalnego przedsi%biorca przekazuje tylko Prezesowi UKE. 6. Do zmiany planu stosuje si% przepisy § 10. § 12. 1. Przedsi%biorca sporz#dza plan zgodnie z przepisami rozporz#dzenia w terminie dwunastu miesi%cy od dnia rozpocz%cia &wiadczenia us"ug telekomunikacyjnych lub dostarczania sieci telekomunikacyjnej albo od dnia wej&cia w $ycie rozporz#dzenia, w zale$no&ci od tego, który z tych terminów nast#pi pó!niej. 2. Plany przedsi%biorców sporz#dzone na podstawie przepisów dotychczasowych zachowuj# moc do czasu sporz#dzenia planów na podstawie rozporz#dzenia. § 13. Rozporz#dzenie wchodzi w $ycie po up"ywie 14 dni od dnia og"oszenia.

PREZES RADY MINISTRÓW

5

UZASADNIENIE Projekt rozporz#dzenia Rady Ministrów w sprawie planu dzia"a# przedsi$biorcy telekomunikacyjnego w sytuacjach szczególnych zagro%e# jest wykonaniem delegacji zawartej w art. 176a ust. 5 ustawy z dnia ........... - Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800 z pó!n. zm.) Niniejszy projekt rozporz#dzenia by" poprzedzony rozporz#dzeniem Ministra Infrastruktury z dnia 16 czerwca 2005 r. w sprawie planu dzia"a' przedsi%biorcy telekomunikacyjnego w sytuacjach szczególnych zagro$e' (Dz. U. Nr 122, poz. 1029) wydanym na podstawie art. 176 ust. 4 ustawy z dnia 16 lipca 2004 r. - Prawo telekomunikacyjne. Zgodnie z tre&ci# znowelizowanej delegacji ustawowej nie zmieni" si% cel wydania regulacji, a jedynie jego zakres i jest w nim okre&lenie: 1) zawarto&) oraz tryb sporz#dzania i aktualizacji przez przedsi%biorc% telekomunikacyjnego, zwanego dalej "przedsi%biorc#", planu dzia"a' w sytuacjach szczególnych zagro$e', zwanego dalej "planem"; 2) zakres uzgodnie' planu z organami, o których mowa w § 8; 3) rodzaje przedsi%biorców obowi#zanych do uzgadniania zawarto&ci planów; 4) rodzaje przedsi%biorców nie podlegaj#cych obowi#zkowi sporz#dzania planu. W niniejszym rozporz#dzeniu doprecyzowano rodzaje przedsi%biorców telekomunikacyjnych obowi#zanych do uzgadniania zawarto&ci planów z „w"a&ciwymi organami”. W poprzednim rozporz#dzeniu taki obowi#zek spoczywa" na wszystkich przedsi%biorcach telekomunikacyjnych wykonuj#cych plany. A wi%c zmniejszono liczb% przedsi%biorców dokonuj#cych uzgodnie' oraz dok"adniej okre&lono jaki przedsi%biorca telekomunikacyjny nie dokonuje uzgodnie'. Z powy$szego obowi#zku wy"#czono operatorów wirtualnej sieci ruchomej MVNO oraz przedsi%biorców telekomunikacyjnych &wiadcz#cych us"ugi transmisji programów radiofonicznych lub telewizyjnych, je&li jest to jedyna forma ich dzia"alno&ci telekomunikacyjnej.

6

OCENA SKUTKÓW REGULACJI I.

Podmioty, na które oddzia"uje rozporz#dzenie.

Podmiotami, do których adresowane jest rozporz#dzenie s# przedsi%biorcy telekomunikacyjni oraz uprawnione organy pa'stwowe realizuj#ce zadania na rzecz obronno&ci, bezpiecze'stwa pa'stwa, bezpiecze'stwa i porz#dku publicznego. II.

Konsultacje spo"eczne.

Wobec faktu, $e rozporz#dzenie zast%puje rozporz#dzenie Ministra Infrastruktury z dnia 16 czerwca 2005 r. w sprawie planu dzia"a' przedsi%biorcy telekomunikacyjnego w sytuacjach szczególnych zagro$e' (Dz. U. Nr 122, poz. 1029), nie zmieniaj#c zakresu obowi#zków nak"adanych na przedsi%biorców telekomunikacyjnych, projektu nie skierowano do konsultacji spo"ecznych.

III

Wp"yw na sektor finansów publicznych, w tym na bud%et pa#stwa i bud%et jednostek samorz&du terytorialnego oraz przychody i wydatki przedsi$biorców.

Wej'cie w %ycie rozporz&dzenia nie b$dzie mia"o wp"ywu na bud%et pa#stwa ani bud%et samorz&du terytorialnego oraz przychody i wydatki przedsi$biorców.

IV Wp"yw regulacji na rynek pracy. Wej&cie w $ycie rozporz#dzenia nie b%dzie mia"o wp"ywu na rynek pracy. V Wp"yw regulacji na konkurencyjno&) gospodarki i przedsi%biorczo&). Wej&cie w $ycie rozporz#dzenia nie b%dzie mia"o wp"ywu na konkurencyjno&) gospodarki. VI Wp"yw regulacji na sytuacj% i rozwój regionów. Wej&cie w $ycie powy$szego rozporz#dzenia nie b%dzie mia"o wp"ywu na sytuacj% i rozwój regionalny. VII Zgodno&) z prawem Unii Europejskiej. Przedmiot projektowanego aktu prawnego nie jest obj%ty zakresem prawa Unii Europejskiej.

13-10-tg

7

Projekt ROZPORZ!DZENIE RADY MINISTRÓW z dnia w sprawie okre'lenia wymaga# i sposobu zapewnienia przez przedsi$biorców telekomunikacyjnych, uprawnionym podmiotom, warunków dost$pu i utrwalania w odniesieniu do niektórych danych b$d&cych w posiadaniu przedsi$biorców telekomunikacyjnych Na podstawie art. 179 ust. 12 ustawy z dnia 16 lipca 2004 r. - Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800, z pó!n. zm.1)) zarz#dza si%, co nast%puje: § 1. 1. Rozporz#dzenie okre&la: 1) wymagania i sposób zapewnienia, przez przedsi%biorców telekomunikacyjnych, uprawnionym podmiotom warunków dost%pu i utrwalania, o których mowa w art. 179 ust. 3 ustawy, z wy"#czeniem spraw uregulowanych w art. 242 Kodeksu post%powania karnego; 2) rodzaje dzia"alno&ci telekomunikacyjnej oraz rodzaje przedsi%biorców telekomunikacyjnych niepodlegaj#cych obowi#zkowi zapewnienia warunków dost%pu i utrwalania, o którym mowa w art. 179 ust. 3 ustawy. 2. Ilekro) w rozporz#dzeniu jest mowa o "ustawie", rozumie si% przez to ustaw% z dnia 16 lipca 2004 r. - Prawo telekomunikacyjne. § 2. Z zastrze$eniem § 11, przedsi%biorca telekomunikacyjny nie korzystaj#cy z rozwi#zania interfejsowego zapewnia uprawnionym podmiotom warunki dost%pu i utrwalania, o których mowa w art. 179 ust. 3 ustawy, poprzez stworzenie mo$liwo&ci technicznych i organizacyjnych w"#czenia urz#dze' b%d#cych na wyposa$eniu uprawnionych podmiotów w punkcie styku lub w miejscu zapewniaj#cym: 1) zapoznanie si% z tre&ci# i danymi w sposób umo$liwiaj#cy dost%p: a) do tre&ci komunikatu i innych danych, o których mowa w art. 159 ust. 1 ustawy, przekazywanych w sieci telekomunikacyjnej przedsi%biorcy, wysy"anych lub odbieranych w zako'czeniach tej sieci uprawnione podmioty, b) do posiadanych lub przetwarzanych przez przedsi%biorc% danych: - okre&lonych w art. 159 ust. 1 pkt 3 i 5 ustawy, dotycz#cych wskazanego przez uprawnione podmioty zako'czenia sieci tego przedsi%biorcy, - okre&laj#cych zako'czenia sieci, u$ytkownika lub abonenta, w przypadku zastosowania &rodków s"u$#cych przekierowywaniu po"#cze' do sieci innych przedsi%biorców lub innych zako'cze' sieci, - okre&lonych w art. 159 ust. 1 pkt 4 ustawy, dotycz#cych wskazanych przez uprawnione podmioty zako'cze' sieci tego przedsi%biorcy, - dotycz#cych rodzajów us"ug telekomunikacyjnych, z których korzysta wskazany przez uprawnione podmioty u$ytkownik lub abonent, - okre&lonych w art. 161 ust. 2 i 3 ustawy lub zgromadzonych w wykazie, o którym mowa w art. 179 ust. 9 ustawy, dotycz#cych zako'cze' sieci, u$ytkownika lub abonenta, c) do dokonania utrwalania przez uprawnione podmioty: - tre&ci komunikatu i danych, o których mowa w pkt 1 lit. a, - danych, o których mowa w pkt 1 lit. b tiret pierwsze i drugie, - danych, o których mowa w pkt 1 lit. b tiret trzecie, wraz z czasem ich zaistnienia; 1)

Zmiany wymienionej ustawy zosta"y og"oszone w Dz. U. z 2004 r. Nr 273, poz. 2703, z 2005 r. Nr 163, poz. 1362 i Nr 267, poz. 2258, z 2006 r. Nr 12, poz. 66, Nr 104, poz. 708 i 711, Nr 170, poz. 1217, Nr 220, poz. 1600, Nr 235, poz. 1700 i Nr 249, poz. 1834 oraz z 2007 r Nr 23, poz. 137, Nr 50, poz. 331 i Nr 82, poz. 556.

2

2) sta"y dost%p uprawnionym podmiotom do punktu styku i miejsca jego lokalizacji poprzez takie zorganizowanie przez przedsi%biorc% pracy podleg"ych mu pracowników aby dost%p ten by" mo$liwy na ka$de $#danie uprawnionego podmiotu. § 3. Z zastrze$eniem § 11, przedsi%biorca telekomunikacyjny eksploatuj#cy sie) telekomunikacyjn# obs"uguj#c# wi%cej ni$ 50.000 zako'cze' sieci zapewnia warunki dost%pu i utrwalania za pomoc# interfejsu, o którym mowa w art. 179 ust. 4 ustawy. Przepis § 2 i 4 stosuje si% odpowiednio. § 4. Warunki, o których mowa w § 2, zapewnia si% w sposób umo$liwiaj#cy: 1) rozpocz%cie dost%pu, o którym mowa w § 2 pkt 1 lit a i b, lub utrwalania, o którym mowa w pkt. 1 lit c, niezw"ocznie po wskazaniu przez uprawnione podmioty zako'cze' sieci; 2) ca"odobowy, równoczesny z wysy"aniem lub odbiorem komunikatu, dost%p i utrwalanie tre&ci komunikatu i danych, o których mowa w § 2 pkt 1 lit. a, natomiast je$eli dost%p równoczesny nie jest mo$liwy - niezw"oczne dostarczenie tre&ci komunikatu lub danych, które nie mog"y by) dostarczone; 3) dost%p i utrwalanie tre&ci komunikatu lub danych w sposób pozwalaj#cy na ich odtworzenie przy pomocy standardowych urz#dze' odtwarzaj#cych lub powszechnie stosowanego sprz%tu komputerowego, w postaci: a) wysy"anej lub odbieranej we wskazanych zako'czeniach sieci przedsi%biorcy - w przypadku tre&ci komunikatu, o którym mowa w § 2 pkt 1 lit. a, b) wyst%puj#cej w sieci telekomunikacyjnej, jak równie$ przetwarzanej przez przedsi%biorc%, a je$eli ich nie przetwarza - w postaci, w jakiej wyst%puj# w sieci telekomunikacyjnej - w przypadku danych, o których mowa w § 2 pkt 1 lit. b; 4) dost%p i utrwalanie tre&ci komunikatu lub danych, tak aby na skutek zastosowania systemu jako&) oraz zakres us"ugi telekomunikacyjnej &wiadczonej kontrolowanemu abonentowi lub u$ytkownikowi nie uleg"y zmianie. § 5. 1. Przedsi%biorca w ramach realizacji warunków dost%pu i utrwalania powinien stosowa) si% do wymaga' ustawy z dnia 22 stycznia 1999 r. o ochronie informacji niejawnych (Dz. U. z 2005 r. Nr 196, poz. 1631, zpó!n. zm.2)). 2. Przedsi%biorca zapewniaj#cy warunki dost%pu i utrwalania za pomoc# interfejsu, o którym mowa w art. 179 ust. 4 ustawy, powinien zapewnia) warunki do ochrony informacji niejawnych oznaczonych klauzul# "&ci&le tajne", potwierdzone &wiadectwem bezpiecze'stwa przemys"owego pierwszego stopnia. 3. Przedsi%biorca nie wymieniony w ust. 2 oraz w przypadku: 1) eksploatowania sieci telekomunikacyjnej obs"uguj#cej od 5.000 do 50.000 zako'cze' sieci -powinien zapewnia) warunki do ochrony informacji niejawnych oznaczonych klauzul# "&ci&le tajne", potwierdzone &wiadectwem bezpiecze'stwa przemys"owego - drugiego stopnia; 2) eksploatowania sieci telekomunikacyjnej obs"uguj#c# od 500 do 5000 zako'cze' siecipowinien zapewnia) warunki do ochrony informacji niejawnych oznaczonych klauzul# "&ci&le tajne", potwierdzone &wiadectwem bezpiecze'stwa przemys"owego - trzeciego stopnia. 4. Do dost%pu do informacji niejawnych przez przedsi%biorc% eksploatuj#cego sie) telekomunikacyjn# obs"uguj#c# do 500 zako'cze' sieci lub &wiadcz#cego us"ugi dost%pu do sieci Internet za po&rednictwem sieci telekomunikacyjnej obs"uguj#cej do 500 zako'cze' sieci posiadaj#cych w"asny adres IP, który nie posiada &wiadectwa bezpiecze'stwa przemys"owego, maj# zastosowanie przepisy art. 49 ustawy z dnia 22 stycznia 1999 r. o ochronie informacji niejawnych. § 6. 1. Przedsi%biorca przekazuje: 1) informacje wskazuj#ce miejsce realizacji dost%pu i utrwalania tre&ci komunikatu i danych; 2) Zmiany wymienionej ustawy zosta"y og"oszone w Dz. U. z 2006 r. Nr 104, poz. 708 i 711, Nr 149, poz. 1078, Nr 218, poz. 1592 i Nr 220, poz. 1600.

3

2) specyfikacj% techniczn# punktów styku, o których mowa w § 2, nast%puj#cym podmiotom: Ministrowi Obrony Narodowej, ministrowi w"a&ciwemu do spraw wewn%trznych, ministrowi w"a&ciwemu do spraw finansów publicznych, Szefowi Agencji Bezpiecze'stwa Wewn%trznego i Szefowi Agencji Wywiadu. § 7. Udzia" pracowników przedsi%biorcy w zapewnieniu warunków dost%pu i utrwalania powinien by) ograniczony do niezb%dnego minimum. § 8. W przypadku wyst#pienia okoliczno&ci uniemo$liwiaj#cych dost%p lub utrwalanie tre&ci komunikatu i danych przedsi%biorca sk"ada, na pisemny wniosek uprawnionego podmiotu, pisemne wyja&nienie zawieraj#ce opis okoliczno&ci uniemo$liwiaj#cych realizacj% zada'. § 9. 1. Miejsce dost%pu i punkt styku, o którym mowa w § 2, przedsi%biorca przygotowuje w sposób zapewniaj#cy uprawnionym podmiotom jednoczesny i wzajemnie niezale$ny dost%p lub utrwalanie tre&ci komunikatu i danych. 2. Maksymalna liczba zako'cze' sieci, które mog# by) wskazane przez uprawnione podmioty w celu zapewnienia warunków dost%pu i utrwalania jest uzgadniana, w drodze odr%bnych pisemnych porozumie' zawartych przez przedsi%biorc% z Ministrem Obrony Narodowej, ministrem w"a&ciwym do spraw wewn%trznych, ministrem w"a&ciwym do spraw finansów publicznych, Szefem Agencji Bezpiecze'stwa Wewn%trznego i Szefem Agencji Wywiadu. 3. W przypadku braku uzgodnienia, liczba zako'cze' sieci dla ka$dego z organów, o których mowa w ust. 2, powinna wynosi) co najmniej: 1) 0,05 % pojemno&ci ka$dej centrali wchodz#cej w sk"ad sieci przedsi%biorcy lub 2) 0,03 % zako'cze' sieci przedsi%biorcy zapewniaj#cego warunki dost%pu i utrwalania - z tym $e nie mo$e by) mniejsza ni$ dwa. § 10. 1. Warunkami udzielenia zawieszenia, o którym mowa w art. 179 ust. 6 ustawy, s#: 1) wyst#pienie, niezale$nych od przedsi%biorcy, trudno&ci organizacyjnych, technicznych lub finansowych uniemo$liwiaj#cych zapewnienie warunków dost%pu i utrwalania; 2) z"o$enie wraz z pisemnym wnioskiem, o którym mowa w art. 179 ust. 6 ustawy, harmonogramu osi#gni%cia przez przedsi%biorc% pe"nej zdolno&ci do zapewnienia warunków dost%pu i utrwalania. 2. Wniosek, o którym mowa w ust. 1 pkt 2, przedsi%biorca sk"ada najpó!niej w terminie 14 dni od dnia powstania okoliczno&ci, o których mowa w ust. 1 pkt 1. 3. Z"o$enie wniosku, o którym mowa w ust. 1 pkt 2, nie zwalnia przedsi%biorcy od obowi#zku zapewnienia warunków dost%pu i utrwalania, w zakresie posiadanych mo$liwo&ci technicznych, organizacyjnych i finansowych. § 11. Obowi#zkowi zapewnienia warunków dost%pu i utrwalania nie podlega wykonywanie dzia"alno&ci telekomunikacyjnej polegaj#cej na: 1) dostarczaniu udogodnie' towarzysz#cych; 2) rozpowszechnianiu lub rozprowadzaniu programów radiofonicznych lub telewizyjnych. § 12. Przedsi%biorcy dostosuj# si% do wymaga' wynikaj#cych z niniejszego rozporz#dzenia w terminie 12 miesi%cy od dnia jego wej&cia w $ycie. § 13. Czynno&ci maj#ce na celu rozpocz%cie i zako'czenie dost%pu lub utrwalania zwi#zanego z wykorzystaniem urz#dze', których mowa § 2, b%d#cych na wyposa$eniu uprawnionych podmiotów wykonywane s# przez upowa$nionego funkcjonariusza, $o"nierza lub pracownika tego podmiotu. § 14. Rozporz#dzenie wchodzi w $ycie po up"ywie 14 dni od dnia og"oszenia. Prezes Rady Ministrów

4

Uzasadnienie Projektowane rozporz#dzenie stanowi wykonanie upowa$nienia ustawowego zawartego w art. 179 ust. 12 ustawy z dnia 16 lipca 2004 r. – Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800, z pó!n. zm.), które zosta"o wprowadzone ustaw# o zmianie ustawy - Praw telekomunikacyjne oraz niektórych innych ustaw (Dz. U. Nr …, poz. …), a celem nowelizacji by"a implementacja do krajowego porz#dku prawnego postanowie' dyrektywy 2006/24/WE Parlamentu Europejskiego i Rady z dnia 15 marca 2006 roku w sprawie zatrzymywania przetwarzanych danych w zwi#zku ze &wiadczeniem publicznych us"ug "#czno&ci elektronicznej oraz dostarczaniem publicznych sieci komunikacji elektronicznej, zmieniaj#cej dyrektyw% 2002/58/WE. Delegacja zawarta w art. 179 ust. 12 zast%puje uchylony przepis deleguj#cy zawarty w art. 181, w poprzednich przepisach ustawy. Nowy przepis uwzgl%dnia zmian% siatki poj%ciowej oraz zmiany wprowadzonych w ca"ym art. 179. Rozporz#dzenie okre&la wymagania i sposób zapewnienia przez przedsi%biorców telekomunikacyjnych na rzecz uprawnionych podmiotów, warunków dost%pu i utrwalania w odniesieniu do niektórych danych b%d#cych w ich posiadaniu, a tak$e rodzaje dzia"alno&ci telekomunikacyjnej oraz rodzaje przedsi%biorców telekomunikacyjnych niepodlegaj#cych obowi#zkowi zapewnienia warunków dost%pu i utrwalania. Projekt rozporz#dzenia jest zgodny z prawem Unii Europejskiej Projekt rozporz#dzenia nie podlega notyfikacji zgodnie z trybem przewidzianym w przepisach dotycz#cych sposobu funkcjonowania krajowego systemu notyfikacji norm i aktów prawnych.

5

OCENA SKUTKÓWREGULACJI Podmioty na które oddzia"uje projektowane rozporz&dzenie Projektowane rozporz#dzenie oddzia"uje na przedsi%biorców telekomunikacyjnych obowi#zanych do zapewnienia warunków dost%pu i utrwalania na rzecz uprawnionych podmiotów warunków dost%pu i utrwalania w odniesieniu do niektórych danych b%d#cych w ich posiadaniu oraz na podmiotu uprawnione na rzecz których &wiadczony jest ten obowi#zek. Zakres konsultacji Projekt rozporz#dzenia zostanie przekazany w ramach konsultacji do szerokiego kr%gu przedsi%biorców telekomunikacyjnych Wp"yw regulacji na: 1) sektor finansów publicznych w tym bud$et pa'stwa jednostek samorz#du terytorialnego – brak wp"ywu; 2) rynek pracy – brak wp"ywu; 3) konkurencyjno&) gospodarki i przedsi%biorczo&), w tym funkcjonowanie przedsi%biorstw – brak wp"ywy; 4) sytuacje i rozwój regionalny – brak wp"ywu.

14-10-tg

Projekt ROZPORZ!DZENIE PREZESA RADY MINISTRÓW z dnia w sprawie sposobu przekazywania i udost$pniania danych telekomunikacyjnych w przypadku upad"o'ci operatora publicznej sieci telekomunikacyjnej lub dostawcy publicznie dost$pnych us"ug telekomunikacyjnych Na podstawie art. 180a ust. 4 ustawy z dnia 16 lipca 2004 r. - Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800, z pó!n. zm.1)) zarz#dza si%, co nast%puje: § 1. Rozporz#dzenie okre&la sposób: 1) przekazywania Prezesowi Urz%du Komunikacji Elektronicznej, zwanego dalej „Prezesem UKE”, danych, o których mowa w art. 180c ustawy z dnia 16 lipca 2004 r. Prawo telekomunikacyjne, zwanych dalej „danymi”, przechowywanych przez operatora publicznej sieci telekomunikacyjnej lub dostawc% publicznie dost%pnych us"ug telekomunikacyjnych w przypadku og"oszenia jego upad"o&ci, zwanego dalej „upad"ym”; 2) udost%pniania przez Prezesa UKE danych podmiotom, o których mowa w art. 180a ust. 1 pkt 3 ustawy z dnia 16 lipca 2004 r. Prawo telekomunikacyjne, zwanych dalej „podmiotami uprawnionymi”. § 2. 1. Upad"y przekazuje dane Prezesowi UKE w terminie 90 dni od dnia wydania przez s#d postanowienia o og"oszeniu upad"o&ci. 2. Dane przekazuje si% na informatycznych no&nikach danych w postaci zapisu w formacie tekstowym lub innym formacie umo$liwiaj#cym ich odczyt za pomoc# powszechnie dost%pnego sprz%tu informatycznego i oprogramowania, wraz ze wskazaniem: 1) nazwy i wersji zastosowanego formatu oraz oprogramowania; 2) rodzaju sprz%tu informatycznego, umo$liwiaj#cego odczyt danych. 3. W przypadku zastosowania przez upad"ego specjalistycznych programów informatycznych do przetwarzania danych, przed przekazaniem Prezesowi UKE danych, upad"y dokonuje ich konwersji do formatu, o którym mowa w ust. 2. 4. Upad"y wraz z danymi przekazuje szczegó"owy opis nazw, skrótów i struktury przekazywanych danych, pozwalaj#cy na jednoznaczne ich interpretowanie. § 3. Z czynno&ci przekazania danych Prezes UKE sporz#dza protokó", w którym zamieszcza si%:

1)

Zmiany wymienionej ustawy zosta"y og"oszone w Dz. U. z 2004 r. Nr 273, poz. 2703, z 2005 r. Nr 163, poz. 1362 i Nr 267, poz. 2258, z 2006 r. Nr 12, poz. 66, Nr 104, poz. 708 i poz. 711, Nr 170, poz. 1217, Nr 220, poz. 1600, Nr 235, poz. 1700 i Nr 249, poz. 1834, z 2007 r. Nr 23, poz. 137, Nr 50, poz. 331 i Nr 82, poz. 556 oraz z 2008 r. Nr 17, poz. 101.

2 1) oznaczenie upad"ego, w szczególno&ci jego nazw%, adres i numer z rejestru przedsi%biorców telekomunikacyjnych; 2) imi%, nazwisko i stanowisko s"u$bowe osoby przekazuj#cej dane oraz oznaczenie dokumentu upowa$niaj#cego t% osob% do reprezentowania upad"ego; 3) imi%, nazwisko i stanowisko s"u$bowe osoby przyjmuj#cej dane oraz oznaczenie dokumentu upowa$niaj#cego t% osob% do reprezentowania Prezesa UKE; 4) wskazanie pojemno&ci informatycznego no&nika danych, na którym przekazywane s# dane, z podaniem ilo&ci i wielko&ci plików zawartych na tym no&niku; 5) nazw% i okre&lenie wersji zastosowanego formatu zapisu danych oraz nazw% i okre&lenie wersji oprogramowania oraz rodzaju sprz%tu informatycznego, za pomoc# którego b%dzie mo$liwe odtwarzanie przekazywanych danych; 6) szczegó"owy opis zastosowanych nazw, skrótów i kodów pozwalaj#cych na interpretowanie danych; 7) opis struktury danych zapisanych na informatycznym no&niku danych; 8) opis zabezpiecze' i wykaz zastosowanych hase" lub kodów dost%pu - w przypadku zastosowania zabezpiecze' dost%pu do przekazywanych danych. § 4. Na $#danie podmiotów uprawnionych Prezes UKE udost%pnia dane w postaci zapisu w formacie tekstowym lub innym formacie umo$liwiaj#cym odczyt danych za pomoc# powszechnie dost%pnego sprz%tu informatycznego i oprogramowania. § 5. Z czynno&ci udost%pniania danych Prezes UKE sporz#dza notatk% zawieraj#c#: 1) dat% i miejsce sporz#dzenia notatki oraz sygnatur% sprawy; 2) informacje dotycz#ce podstawy udost%pnienia danych; 3) oznaczenie upad"ego, którego dane s# udost%pniane, w szczególno&ci jego nazw%, adres i numer z rejestru przedsi%biorców telekomunikacyjnych; 4) okre&lenie zakresu danych, które udost%pniono; 5) imi%, nazwisko i stanowisko s"u$bowe osoby udost%pniaj#cej dane oraz oznaczenie dokumentu upowa$niaj#cego t% osob% do reprezentowania Prezesa UKE; 6) imi%, nazwisko i stanowisko s"u$bowe osoby przyjmuj#cej dane oraz oznaczenie dokumentu upowa$niaj#cego do przyj%cia udost%pnionych danych; 7) wskazanie pojemno&ci informatycznego no&nika danych, na którym udost%pniane s# dane, z podaniem ilo&ci i wielko&ci plików zawartych na tym no&niku; 8) nazw% i okre&lenie wersji zastosowanego formatu zapisu danych oraz nazw% i okre&lenie wersji oprogramowania oraz rodzaju sprz%tu informatycznego, za pomoc# którego b%dzie mo$liwe odtwarzanie udost%pnionych danych; 9) szczegó"owy opis zastosowanych nazw, skrótów i kodów pozwalaj#cych na interpretowanie danych; 10) opis struktury danych zapisanych na informatycznym no&niku danych;

3 11) opis zabezpiecze' i wykaz zastosowanych hase" lub kodów dost%pu - w przypadku zastosowania zabezpiecze' dost%pu do udost%pnianych danych. § 6. Rozporz#dzenie wchodzi w $ycie po up"ywie 30 dni od dnia og"oszenia.

PREZES RADY MINISTRÓW

4 UZASADNIENIE Projekt rozporz#dzenia Prezesa Rady Ministrów w sprawie sposobu przekazywania i udost%pniania danych telekomunikacyjnych w przypadku upad"o&ci operatora publicznej sieci telekomunikacyjnej lub dostawcy publicznie dost%pnych us"ug telekomunikacyjnych, stanowi wykonanie upowa$nienia zawartego w art. 180a ust. 4 ustawy z dnia 16 lipca 2004 r, Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800, z pó$n. zm.). Regulacja niniejsza zwi#zana jest z transpozycj# Dyrektywy 2006/24/WE Parlamentu Europejskiego i Rady z dnia 15 marca 2006 r. w sprawie zatrzymywania generowanych lub przetwarzanych danych w zwi#zku ze &wiadczeniem ogólnie dost%pnych us"ug "#czno&ci elektronicznej lub udost%pnianiem publicznych sieci "#czno&ci. Przepisy projektu rozporz#dzenia reguluj# sposób przekazywania Prezesowi Urz%du Komunikacji Elektronicznej, zwanego dalej „Prezesem UK.6", danych telekomunikacyjnych zgromadzonych prze* operatora publicznej sieci telekomunikacyjnej lub dostawc%, publicznie dost%pnych us"ug- telekomunikacyjnych - w przypadku og"oszenia jego upad"o&ci. Zaprojektowane regulacje okre&laj# format przekazywanych danych oraz dodatkowe informacje, które powinny by) przekazane wraz z danymi w celu umo$liwienia odczytywania przekazywanych danych. Rozporz#dzenie okre&la tak$e sposób dokumentowania procesu przekazywania danych. Rozporz#dzenie okre&la równie$ sposób udost%pniania danych telekomunikacyjnych przez Prezesa UKJi podmiotom, o których mowa w arl. I80a ust. 1 pkt 3 ustawy - Prawo telekomunikacyjne. W tym przypadku równie$ okre&lono form% przekazywania danych oraz sposób dokumentowania przypadków udost%pniania danych. Przedmiotowy projekt nie podlega notyfikacji zgodnie z trybem przewidzianym w przepisach dotycz#cych sposobu funkcjonowania krajowego systemu notyfikacji norm i aktów prawnych. Przedmiotowy projekt jest zgodny z prawem unijnym.

OCENA SKUTKÓW REGULACJI I. Podmioty, nu które oddzia"uje rozporz#dzenie. Podmiotami, do których adresowane jest rozporz#dzenie s# operatorzy publicznych sieci telekomunikacyjnej i dostawcy publicznie dost%pnych us"ug telekomunikacyjnych, po og"oszeniu ich upad"o&ci, Prezes UK..E oraz podmioty uprawnione, o których mowa w art. 180a ust. 1 pkt 3 ustawy- Prawo telekomunikacyjne, II. Konsultacje spo"eczne. W ramach konsultacji spo"ecznych projekt b%dzie przedstawiony izbom zrzeszaj#cym przedsi%biorców telekomunikacyjnych. Zg"oszone uwagi zostan#, wykorzystane w trakcie prac nad niniejszym projektem. III. Wp"yw na sektor finansów publicznych, w tym nn bud$et pa'stwa i bud$et samorz#du terytorialnego.

5 Wej&cie w $ycie rozporz#dzenia spowoduje dodatkowe wydatki bud$etowe Prezesa UKE. Przepis art. 180a ust. 3 ustawy Prawa telekomunikacyjne nak"ada obowi#zek zabezpieczenia danych telekomunikacyjnych w przypadku og"oszenia upad"o&ci operatora publicznych sieci telekomunikacyjnej lub dostawcy publicznie dost%pnych us"ug telekomunikacyjnych, poprzez przekazanie ich Prezesowi UKE do dalszego przechowywania i ochrony oraz udost%pniania uprawnionym podmiotom. Prezes UKE b%dzie musia" zatem zapewni) warunki organizacyjne i techniczne dla przyj%cia, bezpiecznego przechowywania oraz udost%pniania danych telekomunikacyjnych uprawnionym podmiotom. Udost%pnianie danych wymaga) b%dzie dokonywania odczytu danych oraz ich przeszukiwania w zakresie wskazanym przez uprawnione podmioty, zainteresowane udost%pnieniem danych. Z uwagi na to, $e przepisy rozporz#dzenia s# now# regulacj# i brak jest w tym wzgl%dzie jakichkolwiek do&wiadcze', trudne jest okre&lenie skali obci#$e' finansowych, które powstan# po wej&ciu ich w $ycie. Przede wszystkim nie jest mo$liwe do oszacowania jak# skal% b%dzie mie) proces przekazywania danych i ilu podmiotów b%dzie dotyczy). Niezb%dne jest jednak przygotowanie sprz%tu informatycznego dedykowanego do odczytu i przygotowywania danych do udost%pnienia oraz zapewnienie w tym wzgl%dzie odpowiednio przygotowanego personelu. Szacowane koszty minimalne wynios# ok. 200 ty& zl. Powy$szy szacunek nie dotyczy kosztów eksploatacyjnych i materia"owych zwi#zanych z udost%pnianiem danych uprawnionym podmiotom. Wej&cie w $ycie powy$szego rozporz#dzenia nie b%dzie mia"o wp"ywu na bud$et samorz#du terytorialnego. IV. Wp"yw regulacji na rynek pracy. Wej&cie w $ycie powy$szego rozporz#dzenia nie b%dzie mia"o wp"ywu na rynek pracy. V. Wp"yw regulacji nu konkurencyjno&) wewn%trzn# i zewn%trzn# gospodarki. Wej&cie w $ycie powy$szego rozporz#dzenia nie b%dzie mia"o wp"ywu na konkurencyjno&) gospodarki i przedsi%biorczo&). VI. Wp"yw regulacji na sytuacj% i rozwój regionalny. Wej&cie w $ycie powy$szego rozporz#dzenia nie b%dzie mia"o wp"ywu na sytuacj% i rozwój regionalny, VII. Zgodno&) z prawem Unii Europejskiej. Przedmiot projektowanego aktu prawnego nie jest obj%"y jest zakresem prawa Unii Europejskiej.

10-10-tg

Projekt ROZPORZ!DZENIE MINISTRA INFRASTRUKTURY1) z dnia w sprawie szczegó"owego wykazu danych oraz rodzajów operatorów publicznej sieci telekomunikacyjnej lub dostawców publicznie dost$pnych us"ug telekomunikacyjnych obowi&zanych do ich zatrzymywania i przechowywania

Na podstawie art. 180c ust. 2 ustawy z dnia 16 lipca 2004 r. - Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800, z pó!n. zm.2)) zarz#dza si%, co nast%puje: § 1. Rozporz#dzenie okre&la: 1) szczegó"owy wykaz danych niezb%dnych do: a)

ustalenia zako'czenia sieci, telekomunikacyjnego urz#dzenia ko'cowego i u$ytkownika ko'cowego inicjuj#cego po"#czenie,

b)

ustalenia zako'czenia sieci, telekomunikacyjnego urz#dzenia ko'cowego i u$ytkownika ko'cowego, do którego kierowane jest po"#czenie,

c)

okre&lenia daty i godziny po"#czenia oraz czasu jego trwania,

d)

okre&lenia rodzaju po"#czenia telefonicznego,

e)

okre&lenia lokalizacji telekomunikacyjnego urz#dzenia ko'cowego u$ywanego w ruchomej publicznej sieci telefonicznej, dotycz#cej po"#czenia lub próby uzyskania po"#czenia;

2) rodzaje operatorów publicznej sieci telekomunikacyjnej lub dostawców publicznie dost%pnych us"ug telekomunikacyjnych obowi#zanych do zatrzymywania i przechowywania danych, o których mowa w pkt 1. § 2. U$yte w rozporz#dzeniu okre&lenia oznaczaj#: 1) czas CET - czas &rodkowoeuropejski;

1) Minister Infrastruktury kieruje dzia"em administracji rz#dowej - "#czno&), na podstawie § 1 ust. 2 pkt 3 rozporz#dzenia Prezesa Rady Ministrów z dnia 16 listopada 2007 r. w sprawie szczegó"owego zakresu dzia"ania Ministra Infrastruktury (Dz. U. Nr 216, poz. 1594). 2) Zmiany wymienionej ustawy zosta"y og"oszone w Dz. U. z 2004 r. Nr 273, poz. 2703, z 2005 r. Nr 163, poz. 1362 i Nr 267, poz. 2258, z 2006 r. Nr 12, poz. 66, Nr 104, poz. 708 i 711, Nr 170, poz. 1217, Nr 220, poz. 1600, Nr 235, poz. 1700 i Nr 249, poz. 1834, z 2007 r. Nr 23, poz. 137, Nr 50, poz. 331 i Nr 82, poz. 556 oraz z 2008 r. Nr 17, poz. 101.

2

2) numer IMSI - mi%dzynarodowy numer przydzielony do ka$dej karty identyfikuj#cej u$ytkownika w ruchomej publicznej sieci telefonicznej; 3) numer IMEI - indywidualny numer identyfikuj#cy telekomunikacyjne urz#dzenie ko'cowe u$ywane w ruchomej publicznej sieci telefonicznej; 4) MMC (Mobile Country Cod%) - identyfikator kraju, w którym znajduje si% ruchoma publiczna sie) telefoniczna; 5) MNC (Mobile Network Cod%) - identyfikator ruchomej publicznej sieci telefonicznej; 6) numer MSISDN - numer przydzielony abonentowi ruchomej publicznej sieci telefonicznej; 7) stacja BTS - urz#dzenie "#cz#ce telekomunikacyjne urz#dzenie ko'cowe u$ywane w ruchomej publicznej sieci telefonicznej z cz%&ci# sta"# tej sieci. § 3. W stacjonarnej publicznej sieci telefonicznej: 1) dane, o których mowa w § 1 pkt 1 lit. a, obejmuj#: a)

numer u$ytkownika ko'cowego inicjuj#cego po"#czenie,

b)

imi% i nazwisko u$ytkownika ko'cowego inicjuj#cego po"#czenie albo jego nazw%,

c)

adres u$ytkownika ko'cowego inicjuj#cego po"#czenie,

d)

miejsce zainstalowania telekomunikacyjnego urz#dzenia ko'cowego, z którego inicjowano po"#czenie;

2) dane, o których mowa w § 1 pkt 1 lit. b, obejmuj#: a)

numer u$ytkownika ko'cowego, do którego kierowane jest po"#czenie,

b)

numer u$ytkownika ko'cowego, do którego przekierowane zosta"o po"#czenie,

c)

imi% i nazwisko u$ytkownika ko'cowego, do którego kierowane jest po"#czenie albo jego nazw%,

d)

imi% i nazwisko u$ytkownika ko'cowego, do którego przekierowane zosta"o po"#czenie albo jego nazw%,

e)

adres u$ytkownika ko'cowego, do którego kierowane jest po"#czenie,

f)

adres u$ytkownika ko'cowego, do którego przekierowane zosta"o po"#czenie,

3

g)

miejsce zainstalowania telekomunikacyjnego urz#dzenia ko'cowego, do którego kierowane jest po"#czenie, h)

miejsce zainstalowania telekomunikacyjnego

urz#dzenia ko'cowego, do którego przekierowane zosta"o po"#czenie; 3) dane, o których mowa w § 1 pkt 1 lit. c, obejmuj#: a)

dat% i godzin% rozpocz%cia po"#czenia zgodnie z czasem CET, z dok"adno&ci# do 1 sekundy,

b)

czas trwania po"#czenia z dok"adno&ci# do 1 sekundy;

4) dane, o których mowa w § 1 pkt 1 lit. d, obejmuj# okre&lenie rodzaju us"ugi telekomunikacyjnej, z której skorzysta" u$ytkownik ko'cowy, a w szczególno&ci po"#czenia g"osowego, transmisji danych lub przes"ania wiadomo&ci tekstowych. § 4. W ruchomej publicznej sieci telefonicznej: 1) dane, o których mowa w § 1 pkt 1 lit. a, obejmuj#: a)

numer MSISDN u$ytkownika ko'cowego inicjuj#cego po"#czenie,

b)

imi% i nazwisko u$ytkownika ko'cowego inicjuj#cego po"#czenie lub jego nazw%,

c)

adres u$ytkownika ko'cowego inicjuj#cego po"#czenie, a w przypadku us"ugi przedp"aconej, dat% i godzin% pocz#tkowej aktywacji us"ugi przedp"aconej przez u$ytkownika ko'cowego inicjuj#cego po"#czenie, zgodnie z czasem CET, z dok"adno&ci# do 1 sekundy oraz wspó"rz%dne geograficzne lokalizacji stacji BTS, z której dokonano aktywacji,

d)

numer IMSI u$ytkownika ko'cowego inicjuj#cego po"#czenie,

e)

numer IMEI urz#dzenia ko'cowego inicjuj#cego po"#czenie;

2) dane, o których mowa w § 1 pkt 1 lit. b, obejmuj#: a)

numer MSISDN u$ytkownika ko'cowego, do którego kierowane jest po"#czenie,

b)

numer MSISDN u$ytkownika ko'cowego, do którego przekierowane zosta"o po"#czenie,

c)

imi% i nazwisko lub nazwa u$ytkownika ko'cowego, do którego kierowane jest po"#czenie,

4

d)

imi% i nazwisko lub nazwa u$ytkownika ko'cowego, do którego przekierowane zosta"o po"#czenie,

e)

adres u$ytkownika ko'cowego, do którego kierowane jest po"#czenie,

f)

adres u$ytkownika ko'cowego, do którego przekierowane zosta"o po"#czenie,

g)

numer IMSI u$ytkownika ko'cowego, do którego kierowane jest po"#czenie,

h) numer IMSI u$ytkownika ko'cowego, do którego przekierowane zosta"o po"#czenie, i)

numer IMEI urz#dzenia ko'cowego, do którego kierowane jest po"#czenie,

j) numer IMEI urz#dzenia ko'cowego, do którego przekierowane zosta"o po"#czenie, k) w przypadku us"ugi przedp"aconej dat% i godzin% pocz#tkowej aktywacji us"ugi przedp"aconej przez u$ytkownika ko'cowego, do którego kierowane jest po"#czenie lub do którego przekierowane zosta"o po"#czenie, zgodnie z czasem CET, z dok"adno&ci# do 1 sekundy oraz wspó"rz%dne geograficzne lokalizacji stacji BTS, z której dokonano aktywacji; 3) dane, o których mowa w § 1 pkt 1 lit. c, obejmuj#: a)

dat% i godzin% rozpocz%cia po"#czenia zgodnie z czasem CET, z dok"adno&ci# do 1 sekundy,

b)

czas trwania po"#czenia z dok"adno&ci# do 1 sekundy;

4) dane, o których mowa w § 1 pkt 1 lit. d, obejmuj# okre&lenie rodzaju us"ugi telekomunikacyjnej, z której skorzysta" u$ytkownik ko'cowy, a w szczególno&ci, po"#czenia g"osowego, transmisji danych, przes"ania krótkiej wiadomo&ci tekstowej, rozszerzonej wiadomo&ci tekstowej, wiadomo&ci multimedialnej; 5) dane, o których mowa w § 1 pkt 1 lit. e, obejmuj#: a) wspó"rz%dne geograficzne stacji BTS, w obszarze której znajdowa"o si% telekomunikacyjne urz#dzenie ko'cowe u$ytkownika ko'cowego inicjuj#cego po"#czenie w czasie inicjowania po"#czenia, a gdy u$ytkownik inicjuj#cy po"#czenie znajdowa" si% poza granicami kraju identyfikator kraju (MCC) i identyfikator ruchomej publicznej sieci telefonicznej (MNC), w której zainicjowano po"#czenie,

5

b) wspó"rz%dne geograficzne stacji BTS, w obszarze której znajdowa"o si% telekomunikacyjne urz#dzenie ko'cowe u$ywane przez u$ytkownika ko'cowego, do którego kierowane jest po"#czenie, w czasie rozpocz%cia odbioru tego po"#czenia, a gdy u$ytkownik ko'cowy wywo"ywany znajdowa" si% poza granicami kraju identyfikator kraju (MCC) i identyfikator ruchomej publicznej sieci telefonicznej (MNC), do której zosta"o skierowane po"#czenie. § 5. Dostawca publicznie dost%pnych us"ug telekomunikacyjnych &wiadczonych w stacjonarnej publicznej sieci telefonicznej i operator stacjonarnej publicznej sieci telefonicznej - do której pod"#czone jest urz#dzenie telekomunikacyjne u$ytkownika ko'cowego: 1) inicjuj#cego po"#czenie - zatrzymuje i przechowuje dane, o których mowa w § 3 pkt 1, pkt 2 lit. a,pkt3, pkt4; 2) do którego kierowane jest po"#czenie - zatrzymuje i przechowuje dane, o których mowa w § 3 pkt 1 lit. a, pkt 2 lit. a - c, e, g, pkt 3; 3) do którego przekierowane zosta"o po"#czenie - zatrzymuje dane, o których mowa w § 3 pkt 1 lit. a, pkt 2 lit. a, b, d, f, h, pkt 3. § 6. Dostawca publicznie dost%pnych us"ug telekomunikacyjnych &wiadczonych w publicznej ruchomej sieci telefonicznej i operator ruchomej publicznej sieci telefonicznej - do której pod"#czone jest urz#dzenie telekomunikacyjne u$ytkownika ko'cowego: 1) inicjuj#cego po"#czenie - zatrzymuje i przechowuje dane, o których mowa w § 4 pkt 1, pkt 2 lit. a, pkt 3, pkt 4, pkt 5 lit. a; 2) do którego kierowane jest po"#czenie - zatrzymuje i przechowuje dane, o których mowa w § 4 pkt 1 lit. a, pkt 2 lit. a -c, e, g, i, k, pkt 3, pkt 5 lit. b; 3) do którego przekierowane zosta"o po"#czenie - zatrzymuje dane, o których mowa w § 4 pkt 1 lit. a, pkt 2 lit. a, b, d, f, h, j, k, pkt 3. § 7. Rozporz#dzenie wchodzi w $ycie po up"ywie 30 dni od dnia og"oszenia.

MINISTER INFRASTRUKTURY W POROZUMIENIU

MINISTER SPRAW WEWN(TRZNYCH I ADMINISTRACJI

6

UZASADNIENIE

Projekt rozporz#dzenia Ministra Infrastruktury w sprawie szczegó"owego wykazu danych oraz rodzajów operatorów publicznej sieci telekomunikacyjnej lub dostawców publicznie dost%pnych us"ug telekomunikacyjnych obowi#zanych do ich zatrzymywania i przechowywania, stanowi wykonanie upowa$nienia zawartego w art. 180c ust. 2 ustawy z dnia 16 lipca 2004 r. Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800, z pó!n. zm.). Regulacja niniejsza wynika z konieczno&ci transpozycji przepisów dyrektywy 2006/24/WE Parlamentu Europejskiego i Rady z dnia 15 marca 2006 r. w sprawie zatrzymywania generowanych lub przetwarzanych danych w zwi#zku ze &wiadczeniem ogólnie dost%pnych us"ug "#czno&ci elektronicznej lub udost%pnianiem publicznych sieci "#czno&ci. Zgodnie z w/w Dyrektyw# operator publicznej sieci telekomunikacyjnej i dostawca publicznie dost%pnych us"ug telekomunikacyjnych obowi#zany jest do zatrzymywania i przechowywania przez okres od 6 do 24 miesi%cy niektórych danych generowanych w sieci telekomunikacyjnej dotycz#cych zarówno po"#cze' zrealizowanych, jak i nieudanych prób po"#cze'. W zwi#zku ze skorzystaniem przez Polsk% z odroczenia terminu transpozycji przepisów w/w Dyrektywy w zakresie retencji danych zwi#zanych z dost%pem do Internetu, telefoni# internetow# i internetow# poczt# elektroniczn#, przedmiotowa regulacja odnosi si% jedynie do tych przepisów dyrektywy, w których jest mowa o us"ugach telekomunikacyjnych realizowanych w stacjonarnych i ruchomych publicznych sieciach telefonicznych. Przedmiotowe

rozporz#dzenie

okre&la

szczegó"owy

wykaz

danych

obj%tych

obowi#zkiem zatrzymywania, przechowywania, ochrony i udost%pniania oraz rodzaje operatorów publicznej sieci telekomunikacyjnej lub dostawców publicznie dost%pnych us"ug telekomunikacyjnych obowi#zanych do ich zatrzymywania i przechowywania. Przedmiotowy projekt nie podlega notyfikacji zgodnie z trybem przewidzianym w przepisach dotycz#cych sposobu funkcjonowania krajowego systemu notyfikacji norm i aktów prawnych. Przedmiotowy projekt jest zgodny z prawem unijnym.

7

OCENA SKUTKÓW REGULACJI I. Podmioty, na które oddzia"uje rozporz&dzenie. Podmiotami, do których adresowane jest rozporz#dzenie s# operatorzy publicznych sieci telekomunikacyjnej i dostawcy publicznie dost%pnych us"ug telekomunikacyjnych oraz podmioty uprawnione, zgodnie z przepisami ustawy - Prawo telekomunikacyjne, do dost%pu do danych podlegaj#cych obowi#zkowemu zatrzymywaniu i przechowywaniu. II. Konsultacje spo"eczne. W ramach konsultacji spo"ecznych projekt b%dzie przedstawiony izbom zrzeszaj#cym przedsi%biorców telekomunikacyjnych. Zg"oszone uwagi zostan# wykorzystane w trakcie prac nad niniejszym projektem. III. Wp"yw na sektor finansów publicznych, w tym na bud%et pa#stwa i bud%et samorz&du terytorialnego. Wej&cie w $ycie rozporz#dzenia nie b%dzie mia"o wp"ywu na bud$et pa'stwa ani bud$et samorz#du terytorialnego. IV. Wp"yw regulacji na rynek pracy. Wej&cie w $ycie powy$szego rozporz#dzenia b%dzie mia"o wp"yw na rynek pracy. Wprowadzenie obowi#zku bezwzgl%dnego zatrzymywania danych przez operatorów publicznej

sieci

telekomunikacyjnej

i

dostawców

publicznie

dost%pnych

us"ug

telekomunikacyjnych b%dzie generowa) istotne obci#$enia finansowe po stronie w/w podmiotów. Z informacji zebranych podczas procesu negocjacji dyrektywy 2006/24/WE Parlamentu Europejskiego i Rady z dnia 15 marca 2006 r. w sprawie zatrzymywania generowanych lub przetwarzanych danych w zwi#zku ze &wiadczeniem ogólnie dost%pnych us"ug "#czno&ci elektronicznej lub udost%pnianiem publicznych sieci "#czno&ci wynika, $e : dostawcy publicznie dost%pnych us"ug telekomunikacyjnych realizowanych w stacjonarnej

publicznej

sieci

telefonicznej,

&wiadcz#cy

us"ug%

telekomunikacyjn#

u$ytkownikowi ko'cowemu i operatorzy stacjonarnej publicznej sieci telefonicznej, do której pod"#czone jest urz#dzenie telekomunikacyjne u$ytkownika ko'cowego, posiadaj#cy kilkadziesi#t tysi%cy abonentów lub zako'cze' sieci - ponios# koszty dodatkowe w wysoko&ci ok. 2 min z", w tym: na zapewnienie rejestrowania nieudanych prób po"#cze' ok. 1 min z", na rozbudow% systemów IT do przechowywania danych ok. 1 min z". Powy$sze wyliczenie nie

8

obejmuje kosztów eksploatacji urz#dze' do zatrzymywania i przechowywania danych oraz kosztów osobowych; dostawcy publicznie dost%pnych us"ug telekomunikacyjnych realizowanych w ruchomej publicznej sieci telefonicznej &wiadcz#cy us"ug% telekomunikacyjn# u$ytkownikowi ko'cowemu i operatorzy ruchomej publicznej sieci telefonicznej, do której pod"#czone jest urz#dzenie telekomunikacyjne u$ytkownika ko'cowego - ponios# koszty dodatkowe rz%du kilkudziesi%ciu min z", w tym na inwestycje zwi#zane z rozbudow# systemów zapisuj#cych ok. 3 min z", inwestycje zwi#zane ze zmian# systemów bilingowych ok. 2 min, inwestycje zwi#zane z rozbudow# sprz%tow# systemu gromadzenia dzienników zdarze' ok. 1 min. Najwi%kszym obci#$eniem jest konieczno&) gromadzenia informacji o nieudanych próbach po"#cze'. Aktualnie w ruchomej publicznej sieci telefonicznej po"#czenia niezrealizowane to a$ oko"o 65% wszystkich po"#cze'. Oznacza to trzykrotne zwi%kszenie ilo&ci przetwarzanych i przechowywanych

danych,

które

przez

dostawców

publicznie

dost%pnych

us"ug

telekomunikacyjnych nie s# do niczego wykorzystywane. Skutkuje to pojawieniem si% po ich stronie kosztu ok. 4,5 do 5 min z". Ponadto istotne b%d# tak$e koszty dostosowania systemów mediacyjnych do zmienionych formatów rekordów generowanych przez centrale.

V. Wp"yw regulacji na konkurencyjno') gospodarki i przedsi$biorczo'). Wej&cie w $ycie powy$szego rozporz#dzenia b%dzie mia"o wp"yw na konkurencyjno&) gospodarki z uwagi na dodatkowe koszty jakie ponios# operatorzy i dostawcy us"ug w zwi#zku z realizacj# obowi#zku zatrzymywania i przechowywania danych wskazanych w rozporz#dzeniu. Wprowadzone przepisy b%d# istotnie wp"ywa) na dzia"alno&) operatorów i dostawców us"ug posiadaj#cych mniej ni$ kilkadziesi#t tysi%cy zako'cze' sieci lub abonentów. VI. Wp"yw regulacji na sytuacj$ i rozwój regionalny. Wej&cie w $ycie powy$szego rozporz#dzenia nie b%dzie mia"o wp"ywu na sytuacj% i rozwój regionalny. VII. Zgodno') z prawem Unii Europejskiej. Przedmiot projektowanego aktu prawnego obj%ty jest zakresem prawa Unii Europejskiej i stanowi transpozycj% przepisów dyrektywy 2006/24/WE Parlamentu Europejskiego i Rady

z dnia 15 marca 2006 r. w sprawie zatrzymywania generowanych lub przetwarzanych danych w zwi#zku ze &wiadczeniem ogólnie dost%pnych us"ug "#czno&ci elektronicznej lub udost%pnianiem publicznych sieci "#czno&ci, do krajowego systemu prawnego.

11-10-tg

Projekt ROZPORZ!DZENIE MINISTRA INFRASTRUKTURY1) z dnia w sprawie wzoru formularza s"u%&cego do przekazywania przez przedsi$biorc$ telekomunikacyjnego Prezesowi Urz$du Komunikacji Elektronicznej informacji dotycz&cych udost$pniania danych Na podstawie art. 180g ust. 3 ustawy z dnia 16 lipca 2004 r. - Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800, z pó!n. zm.2)) zarz#dza si%, co nast%puje: § 1. Rozporz#dzenie okre&la wzór formularza s"u$#cego do przekazywania przez przedsi%biorc% telekomunikacyjnego Prezesowi Urz%du Komunikacji Elektronicznej informacji o: 1) liczbie przypadków, w których organom, o których mowa w art. 180a ust. 1 pkt 3 ustawy z dnia 16 lipca 2004 r. - Prawo telekomunikacyjne, zwanej dalej „ustaw#", udost%pniono dane zgodnie z przepisami ustawy; 2) czasie, jaki up"yn#" mi%dzy dat# zatrzymania danych a dat# z"o$enia przez podmioty, o których mowa w art. 180a ust. 1 pkt 3 ustawy, wniosku lub ustnego $#dania o udost%pnienie danych; 3) przypadkach, w których wniosek lub ustne $#danie, o których mowa w pkt 2, nie móg" by) zrealizowany. § 2. Wzór formularza, o którym mowa w § 1, stanowi za"#cznik do rozporz#dzenia. § 3. Rozporz#dzenie wchodzi w $ycie po up"ywie 14 dni od dnia og"oszenia.

MINISTER INFRASTRUKTURY

______________ 1)

Minister Infrastruktury kieruje dzia"em administracji rz#dowej - "#czno&), na podstawie § 1 ust. 2 pkt 3 rozporz#dzenia Prezesa Rady Ministrów z dnia 16 listopada 2007 r. w sprawie szczegó"owego zakresu dzia"ania Ministra Infrastruktury (Dz. U. Nr 216, poz. 1594). 2) Zmiany wymienionej ustawy zosta"y og"oszone w Dz. U. z 2004 r. Nr 273, poz. 2703, z 2005 r. Nr 163, poz. 1362 i Nr 267, poz. 2258, z 2006 r. Nr 12, poz. 66, Nr 104, poz. 708 i 711, Nr 170, poz. 1217, Nr 220, poz. 1600, Nr 235, poz. 1700 i Nr 249, poz. 1834, z 2007 r. Nr 23, poz. 137, Nr 50, poz. 331 i Nr 82, poz. 556 oraz z 2008 r. Nr 17, poz. 101.

UZASADNIENIE

Projekt rozporz#dzenia Ministra Infrastruktury w sprawie wzoru formularza s"u$#cego do przekazywania informacji dotycz#cych udost%pniania danych stanowi wykonanie upowa$nienia zawartego w art. 180g ust. 3 ustawy z dnia 16 lipca 2004 r. Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800 z pó!n. zm.), zwanego dalej „ustaw#". Regulacja niniejsza wynika z konieczno&ci transpozycji do polskiego prawa przepisów Dyrektywy 2006/24/WE Parlamentu Europejskiego i Rady z dnia 15 marca 2006 r. w sprawie zatrzymywania generowanych lub przetwarzanych danych w zwi#zku ze &wiadczeniem ogólnie dost%pnych us"ug "#czno&ci elektronicznej lub udost%pnianiem publicznych sieci "#czno&ci oraz zmieniaj#cej dyrektyw% 2002/58/WE, a w szczególno&ci art. 10 tej Dyrektywy, nak"adaj#cego na pa'stwa cz"onkowskie obowi#zek przekazywania corocznie Komisji Europejskiej statystyki na temat zatrzymywania danych generowanych lub przetwarzanych w ramach &wiadczenia ogólnie dost%pnych us"ug "#czno&ci elektronicznej lub udost%pniania sieci komunikacji publicznej. Statystyki takie powinny obejmowa): - przypadki, w których w"a&ciwym organom udzielone zosta"y informacje zgodnie z maj#cym zastosowanie prawem krajowym, - czas, jaki up"yn#" mi%dzy dat# zatrzymania danych a dat# wniosku o przekazanie danych z"o$onego przez w"a&ciwy organ, - przypadki, w których wnioski o dane nie mog"y zosta) zrealizowane. W przepisie art. 180g ust. 2 ustawy Prezes Urz%du Komunikacji Elektronicznej zosta" wskazany jako organ przekazuj#cy Komisji Europejskiej powy$sze informacje. Informacje te b%d# opracowywane w oparciu o informacje przekazywane Prezesowi przez operatorów publicznej sieci telekomunikacyjnej oraz dostawców publicznie dost%pnych us"ug telekomunikacyjnych. Przedmiotowe rozporz#dzenie okre&la wzór formularza s"u$#cego do przekazywania Prezesowi Urz%du Komunikacji Elektronicznej informacji o udost%pnianych danych przez operatorów publicznej sieci telekomunikacyjnej oraz dostawców publicznie dost%pnych us"ug telekomunikacyjnych. Przedmiotowy projekt nie podlega notyfikacji zgodnie z trybem przewidzianym w przepisach dotycz#cych sposobu funkcjonowania krajowego systemu notyfikacji norm i aktów prawnych. Przedmiotowy projekt jest zgodny z prawem unijnym.

OCENA SKUTKÓW REGULACJI I. Podmioty, na które oddzia"uje rozporz#dzenie Podmiotami, do których adresowane jest rozporz#dzenie s# operatorzy publicznej sieci telekomunikacyjnej i dostawcy publicznie dost%pnych us"ug telekomunikacyjnych oraz Prezes Urz%du Komunikacji Elektronicznej. II. Konsultacje spo"eczne W ramach konsultacji spo"ecznych projekt b%dzie przedstawiony izbom zrzeszaj#cym przedsi%biorców telekomunikacyjnych. Zg"oszone uwagi zostan# wykorzystane w trakcie prac nad niniejszym projektem. III. Wp"yw na sektor finansów publicznych, w tym na bud$et pa'stwa i bud$et samorz#du terytorialnego.

2

Wej&cie w $ycie rozporz#dzenia nie b%dzie mia"o wp"ywu na bud$et pa'stwa i bud$et samorz#du terytorialnego IV. Wp"yw regulacji na rynek pracy. Wej&cie w $ycie powy$szego rozporz#dzenia nie b%dzie mia"o wp"ywu na rynek pracy. V. Wp"yw regulacji na konkurencyjno&) gospodarki i przedsi%biorczo&). Wej&cie w $ycie powy$szego rozporz#dzenia nie b%dzie mia"o wp"ywu na konkurencyjno&) gospodarki.

VI. Wp"yw regulacji na sytuacj% i rozwój regionalny. Wej&cie w $ycie powy$szego rozporz#dzenia nie b%dzie mia"o wp"ywu na sytuacj% i rozwój regionalny. VII. Zgodno&) z prawem Unii Europejskiej. Przedmiot projektowanego aktu prawnego obj%ty jest zakresem prawa Unii Europejskiej. Projekt okre&la wzór formularza s"u$#cego do przekazywania informacji Prezesowi Urz%du Komunikacji Elektronicznej, które nast%pnie b%d# wykorzystywane przez Prezesa do sporz#dzenia informacji dla Komisji Europejskiej - zgodnie z art. 10 Dyrektywy 2006/24/WE Parlamentu Europejskiego i Rady z dnia 15 marca 2006 r. w sprawie zatrzymywania generowanych lub przetwarzanych danych w zwi#zku ze &wiadczeniem ogólnie dost%pnych us"ug "#czno&ci elektronicznej lub udost%pnianiem publicznych sieci "#czno&ci oraz zmieniaj#cej dyrektyw% 2002/5 8 /WE.

3

zniszczenia ze wzgl%du na up"yw terminu, o którym mowa wart. 180a ust. 1 pkt 2 ustawy z dnia 16 lipca 2004r. - Prawo telekomunikacyjne Inne3'

utraty

braku dost%pu2)

Udost%pniono dane

Sposób realizacji wniosku

Ogó"em

Nazwa podmiotu wnioskuj#cego o udost%pnienie danych

Liczba wniosków

X* 1 2 3 4

5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 >24

Czas, jaki up"yn#" mi%dzy dat# zatrzymania danych a dat# z"o$enia wniosku o ich udost%pnienie (w miesi#cach)

Informacja dotycz#ca udost%pniania danych za rok ....................................

Za"#cznik do rozporz#dzenia Ministra Infrastruktury z dnia. ........2008 r. (poz ..... )

1}

12-10-tg

Miejscowo&) i data sporz#dzenia informacji

4

Podpis osoby upowa$nionej do reprezentowania przedsi%biorcy telekomunikacyjnego

Obja&nienia: pole wype"nia si% w sytuacji, gdy brak jest mo$liwo&ci okre&lenia czasu, jaki up"yn#" mi%dzy dat# zatrzymania danych a dat# z"o$enia wniosku o ich udost%pnienie; 2) dotyczy wniosków o udost%pnienie danych, które nie s# dost%pne przedsi%biorcy telekomunikacyjnemu i w zwi#zku z tym nie podlegaj# obowi#zkowi zatrzymania na podstawie art. 180a ust. 1 pkt 1 ustawy z dnia 16 lipca 2004r. - Prawo telekomunikacyjne; ' nale$y wpisa) powód nieudost%pnienia danych.

1.

Lp .

Numer w rejestrze przedsi$biorców telekomunikacyjnych:

Nazwa przedsi$biorcy telekomunikacyjnego:

Nie udost%pniono danych z powodu

Razem

Projekt

ROZPORZ!DZENIE MINISTRA INFRASTRUKTURY z dnia w sprawie danych dotycz&cych infrastruktury telekomunikacyjnej eksploatowanej lub u%ywanej przez przedsi$biorc$, niezb$dnej do przygotowania systemów "&czno'ci na potrzeby obronne pa#stwa

Na podstawie art. 180f ust. 3 ustawy z dnia 16 lipca 2004 r. - Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800, z pó!n. zm.2)) zarz#dza si%, co nast%puje: § 1. Rozporz#dzenie okre&la: 1) szczegó"owy zakres danych dotycz#cych infrastruktury telekomunikacyjnej eksploatowanej lub u$ywanej przez przedsi%biorc% telekomunikacyjnego, niezb%dnej do przygotowania systemów "#czno&ci na potrzeby obronne pa'stwa, w tym systemu kierowania bezpiecze'stwem narodowym; 2) form% i tryb dostarczania danych, o których mowa w pkt 1, oraz ich aktualizacji. §2. 1. Dane, o których mowa w § 1 pkt 1, obejmuj# lokalizacj% infrastruktury telekomunikacyjnej eksploatowanej lub u$ywanej przez przedsi%biorc% telekomunikacyjnego oraz jej charakterystyk%. 2. Przedsi%biorca telekomunikacyjny dostarcza niezw"ocznie dane, o których mowa w ust. 1, na $#danie Prezesa Urz%du Komunikacji Elektronicznej, w formie wype"nionych formularzy. 3. Ustala si% wzory formularzy, o których mowa w ust. 2: 1) „Formularz 1 - Ogólne dane o infrastrukturze telekomunikacyjnej niezb%dnej do przygotowania systemów "#czno&ci na potrzeby obronne pa'stwa" - stanowi#cy za"#cznik nr 1 do rozporz#dzenia; 2) „Formularz 2 - Karta urz#dzenia telekomunikacyjnego" - stanowi#cy za"#cznik nr 2 do rozporz#dzenia. 4. Formularze, o których mowa w ust. 2, przedsi%biorca przekazuje na informatycznym no&niku danych, a w przypadku braku takiej mo$liwo&ci w formie papierowej, z zachowaniem przepisów ustawy z dnia 22 stycznia 1999 r. o ochronie informacji niejawnych (Dz. U. Nr 11, poz. 95, z pó!n. zm.).

1)

Minister Infrastruktury kieruje dzia"em administracji rz#dowej - "#czno&), na podstawie § 1 ust. 2 pkt 3 rozporz#dzenia Prezesa Rady Ministrów z dnia 16 listopada 2007 r. w sprawie szczegó"owego zakresu dzia"ania Ministra Infrastruktury (Dz. U. Nr 216, poz. 1594). 2)

Zmiany wymienionej ustawy zosta"y og"oszone w Dz. U. z 2004 r. Nr 273, poz. 2703, z 2005 r. Nr 163, poz. 1362 i Nr 267, poz. 2258, z 2006 r. Nr 12, poz. 66, Nr 104, poz. 708 i poz. 711, Nr 170, poz. 1217, Nr 220, poz. 1600, Nr 235, poz. 1700 i Nr 249, poz. 1834 z 2007 r. Nr 23, poz. 137, Nr 50, poz. 331 i Nr 82, poz. 556 oraz z 2008r. Nr 17, poz. 101.

2

§3. 1. Przedsi%biorca telekomunikacyjny obowi#zany jest do aktualizacji danych przekazanych do Prezesa Urz%du Komunikacji Elektronicznej, o których mowa w § 1 pkt 1. 2. Aktualizacji danych dokonuje si% w formie: 1) Formularza 1, o którym mowa w § 2 ust. 3 pkt 1; oraz 2) Formularza 2, o którym mowa w § 2 ust. 3 pkt 2 - dla urz#dzenia telekomunikacyjnego, którego dotycz# zmiany - w terminie 30 dni od dnia wyst#pienia zmiany w danych przekazanych do Prezesa Urz%du Komunikacji Elektronicznej.

§ 4. Rozporz#dzenie wchodzi w $ycie po up"ywie 14 dni od dnia og"oszenia

MINISTER INFRASTRUKTURY

3

UZASADNIENIE

Projekt rozporz#dzenia Ministra Infrastruktury w sprawie danych dotycz#cych infrastruktury telekomunikacyjnej eksploatowanej lub u$ywanej przez przedsi%biorc% stanowi wykonanie upowa$nienia zawartego w art. 180f ust. 3 ustawy z dnia 16 lipca 2004 r. Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800). Regulacja niniejsza zapewni uzyskanie danych niezb%dnych do realizacji przepisów rozporz#dzenia Rady Ministrów z dnia 3 sierpnia 2004 r. w sprawie przygotowania i wykorzystania systemów "#czno&ci na potrzeby obronne pa'stwa (Dz. U. nr 180, poz. 1855), zgodnie z którymi Prezes Urz%du Komunikacji Elektronicznej dokonuje analizy mo$liwo&ci przedsi%biorców telekomunikacyjnych w zakresie ich wykorzystania na potrzeby obronne pa'stwa oraz zapewnia utworzenie bazy danych o przedsi%biorcach telekomunikacyjnych, niezb%dnej do przygotowania i wykorzystania obronnych systemów "#czno&ci. Projektowane rozporz#dzenie umo$liwi pozyskiwanie uzyskanie przez Prezesa Urz%du Komunikacji Elektronicznej danych niezb%dnych do tworzenia takiej bazy oraz aktualizacji danych o wybranych elementach infrastruktury telekomunikacyjnej przedsi%biorców telekomunikacyjnych. Dotychczas nie by"o narz%dzia prawnego pozwalaj#cego skutecznie pozyskiwa) w/w dane. Wej&cie w $ycie przedmiotowego rozporz#dzenia umo$liwi Prezesowi Urz%du Komunikacji Elektronicznej w"a&ciwe wykonywanie zada' w zakresie obronno&ci. Przedmiotowe rozporz#dzenie okre&la zakres danych dotycz#cych infrastruktury telekomunikacyjnej eksploatowanej lub u$ywanej przez przedsi%biorc% oraz form%, tryb ich dostarczania i aktualizacji. Przedmiotowy projekt nie podlega notyfikacji zgodnie z trybem przewidzianym w przepisach dotycz#cych sposobu funkcjonowania krajowego systemu notyfikacji norm i aktów prawnych.

4

OCENA SKUTKÓW REGULACJI

I. Podmioty, na które oddzia"uje rozporz&dzenie. Podmiotami, do których adresowane jest rozporz#dzenie s# przedsi%biorcy telekomunikacyjni oraz Prezes Urz%du Komunikacji Elektronicznej. II. Konsultacje spo"eczne. W ramach konsultacji spo"ecznych projekt b%dzie przedstawiony izbom zrzeszaj#cym przedsi%biorców telekomunikacyjnych. Zg"oszone uwagi zostan# wykorzystane w trakcie prac nad niniejszym projektem.

III. Wp"yw na sektor fmansów publicznych, w tym na bud%et pa#stwa i bud%et samorz&du terytorialnego. Wej&cie w $ycie rozporz#dzenia nie b%dzie mia"o wp"ywu na bud$et pa'stwa, bud$et samorz#du terytorialnego IV. Wp"yw regulacji na rynek pracy. Wej&cie w $ycie powy$szego rozporz#dzenia nie b%dzie mia"o wp"ywu na rynek pracy. V.

Wp"yw regulacji na konkurencyjno&) gospodarki i przedsi%biorczo&).

Wej&cie w $ycie powy$szego rozporz#dzenia nie b%dzie mia"o wp"ywu na konkurencyjno&) wewn%trzn# i zewn%trzna gospodarki. VI. Wp"yw regulacji na sytuacj% i rozwój regionów. Wej&cie w $ycie powy$szego rozporz#dzenia nie b%dzie mia"o wp"ywu na sytuacj% i rozwój regionalny. VII. Zgodno&) z prawem Unii Europejskiej. Przedmiot projektowanego aktu prawnego nie jest obj%ty jest prawem Unii Europejskiej.

16-10-tg

Za#"czniki do rozporz"dzenia Ministra Infrastruktury z dnia ................. 2008 r. (Dz. U. Nr ..., poz. ... ) Za"#cznik nr 1

Formularz 1 Ogólne dane o infrastrukturze telekomunikacyjnej niezb!dnej do przygotowania systemów "#czno$ci na potrzeby obronne pa%stwa

1

Wprowadzenie danych

2

Aktualizacja danych

*

3 Wed#ug stanu na dzie% (dd mm rrrr)

Podstawowe dane o przedsi!biorcy telekomunikacyjnym Firma przedsi$biorcy lub nazwa innego podmiotu uprawnionego do wykonywania dzia#alno!ci gospodarczej na podstawie odr$bnych przepisów 4 Numer w rejestrze przedsi$biorców telekomunikacyjnych 5

Lokalizacja infrastruktury telekomunikacyjnej przedsi!biorcy telekomunikacyjnego i jej ogólna charakterystyka Lokalizacja urz"dze% telekomunikacyjnych kraj 6 województwo(a) 7

dolno!l"skie

powiaty

8

kujawsko-pomorskie

powiaty

9

lubelskie

powiaty

10 lubuskie

powiaty

11 #ódzkie

powiaty

12 ma#opolskie

powiaty

13 mazowieckie

powiaty

14 opolskie

powiaty

15 podkarpackie

powiaty

16 podlaskie

powiaty

17 pomorskie

powiaty

18 !l"skie

powiaty

19 !wi$tokrzyskie

powiaty

20 warmi%sko-mazurskie

powiaty

21 wielkopolskie

powiaty

22 zachodniopomorskie

powiaty

1/3

Liczba u&ywanych lub eksploatowanych urz"dze% telekomunikacyjnych: 23 spe#niaj"cych kryteria dotycz"ce wydzielenia kana#ów transmisyjnych oraz zasilania 24 obs#ugiwanych 25 podlegaj"cych obowi"zkowej ochronie 26

obj$tych umow" na dostosowanie do wspó#pracy z ruchomymi urz"dzeniami telekomunikacyjnymi Ministerstwa Obrony Narodowej

27

obj$tych umow" na dostosowanie do wspó#pracy z ruchomymi urz"dzeniami telekomunikacyjnymi Ministerstwa Spraw Wewn$trznych i Administracji

................................................................

....................................................................... Data i podpis osoby uprawnionej do reprezentowania przedsi$biorcy telekomunikacyjnego

Miejscowo!', data i podpis osoby wype#niaj"cej formularz

Obja$nienia sposobu wype"niania

* w formularzu nale'y uj#( dane dotycz#ce urz#dze% telekomunikacyjnych, które obj!te s# umow# na dostosowanie do wspó"pracy z ruchomymi urz#dzeniami telekomunikacyjnymi Ministerstwa Obrony Narodowej lub Ministerstwa Spraw Wewn!trznych i Administracji albo posiadaj# zasoby transmisyjne umo'liwiaj#ce wydzielenie minimum 4 kana"ów 2Mbit/sek oraz &ród"o zasilania z rezerw# mocy minimum 10kVA . Dla ka'dego z urz#dze% telekomunikacyjnych spe"niaj#cych te wymagania nale'y wype"ni( formularz 2 - Karta urz#dzenia telekomunikacyjnego i za"#czy( do formularza 1. Wska&nik

Nr pola

Opis

X

1

Wprowadzenie danych

Je&eli dane dotycz"ce infrastruktury telekomunikacyjnej dostarczane s" po raz pierwszy nale&y wpisa' znak , w przypadku aktualizacji danych pole pozostawi' niewype#nione.

2

Aktualizacja danych

Je&eli formularz jest dokumentem aktualizuj"cym dane o infrastrukturze telekomunikacyjnej nale&y wpisa' znak

3

Wed#ug stanu na dzie%

Nale&y wpisa' dat$ wype#nienia formularza, odpowiednio w pola dzie%, miesi"c, rok.

5

Numer w rejestrze przedsi$biorców telekomunikacyjnych

Nale&y wpisa' numer w rejestrze przedsi$biorców telekomunikacyjnych, prowadzonym przez Prezesa Urz$du Komunikacji Elektronicznej.

6

kraj

Nale&y wpisa' znak

7

dolno!l"skie

8

kujawsko-pomorskie

9

lubelskie

10

lubuskie

11

#ódzkie

12

ma#opolskie

13

mazowieckie

14

opolskie

X.

X je&eli przedsi$biorca u&ywa lub eksploatuje urz"dzenia telekomunikacyjne na obszarze ca#ego kraju.

Je&eli przedsi$biorca u&ywa lub eksploatuje urz"dzenia telekomunikacyjne we wszystkich powiatach województwa wpisa' znak

X przy nazwie województwa. Je&eli przedsi$biorca u&ywa lub eksploatuje urz"dzenia telekomunikacyjne tylko w niektórych 15

podkarpackie

16

podlaskie

17

pomorskie

18

!l"skie

19

!wi$tokrzyskie

20

warmi%sko-mazurskie

21

wielkopolskie

22

zachodniopomorskie

powiatach województwa w polu "powiaty" nale&y wpisa' nazwy powiatów, na terenie których znajduj" si$ te urz"dzenia.

2/3

23

Spe#niaj"cych kryteria dotycz"ce wydzielenia kana#ów transmisyjnych oraz zasilania

Nale&y wpisa' #"czn" liczb$ urz"dze% telekomunikacyjnych, które posiadaj" zasoby transmisyjne umo&liwiaj"ce wydzielenie minimum 4 kana#ów 2Mbit/sek oraz (ród#o zasilania z rezerw" mocy minimum 10kVA.

24

Obs#ugiwanych

Nale&y wpisa' liczb$ urz"dze% telekomunikacyjnych posiadaj"cych sta#" obs#ug$ przez ca#" dob$.

25

Podlegaj"cych obowi"zkowej ochronie

Nale&y wpisa' liczb$ urz"dze% telekomunikacyjnych, które zosta#y uj$te w ewidencji (prowadzonej przez w#a!ciwego wojewod$) obszarów, obiektów i urz"dze% podlegajacych obowi"zkowej ochronie - zgodnie z art. 5 ust. 5 ustawy z dnia 22 sierpnia 1997 r. o ochronie osób i mienia (Dz.U. z 2005 r. Nr 145, poz. 1221 z pó(n. zm.).

26

Obj$tych umow" na dostosowanie do wspó#pracy z Nale&y wpisa' liczb$ urz"dze% telekomunikacyjnych objetych umow" na dostosowanie do wspó#pracy z ruchomymi urz"dzeniam ruchomymi urz"dzeniami telekomunikacyjnymi telekomunikacyjnymi Ministerstwa Obrony Narodowej. Ministerstwa Obrony Narodowej

27

Obj$tych umow" na dostosowanie do wspó#pracy z Nale&y wpisa' liczb$ urz"dze% telekomunikacyjnych obj$tych umow" na dostosowanie do wspó#pracy z ruchomymi urz"dzeniam ruchomymi urz"dzeniami telekomunikacyjnymi telekomunikacyjnymi Ministerstwa Spraw Wewn$trznych i Administracji. Ministerstwa Spraw Wewn$trznych i Administracji

3/3

8

Za"#cznik nr 2

Formularz 2 Karta urz#dzenia telekomunikacyjnego

1

Wprowadzenie danych

2

Aktualizacja danych

3

Wed#ug stanu na dzie% (dd mm rrrr)

Podstawowe dane o przedsi!biorcy telekomunikacyjnym Firma przedsi$biorcy lub nazwa innego podmiotu uprawnionego do wykonywania dzia#alno!ci gospodarczej na podstawie odr$bnych przepisów 4 Numer w rejestrze przedsi$biorców telekomunikacyjnych 5

Dane o urz#dzeniu telekomunikacyjnym Nazwa urz"dzenia telekomunikacyjnego 6 Identyfikator urz"dzenia telekomunikacyjnego w systemie informatycznym przedsi$biorcy telekomunikacyjnego 7 Nadana klauzula tajno!ci dla informacji zawieraj"cych szczegó#owe dane o urz"dzeniu telekomunikacyjnym 8

zastrze&one

9

poufne

10

tajne

11

!ci!le tajne

Czy urz"dzenie telekomunikacyjne jest 12

obs#ugiwane

13

dzier&awione innemu przedsi$biorcy

14

dzier&awione od innego przedsi$biorcy

15

Data zako%czenia eksploatacji lub u&ywania urz"dzenia telekomunikacyjnego (dd mm rrrr)

Lokalizacja urz#dzenia telekomunikacyjnego Wspó#rz$dne geograficzne (w uk#adzie odniesienia WGS 84 , format pozycji hddd mm' ss,s'') d#ugo!' geograficzna

16

E

o

,

,

,,

szeroko!' geograficzna

17

N

o

,

,

,,

kraj

18

województwo

19

powiat

20

gmina

21

miejscowo!'

22

Adres

9 ulica

23

numer domu

24

numer lokalu

25

kod pocztowy

26

poczta

27

informacje dodatkowe

28

Charakterystyka

29

Charakterystyka urz"dzenia telekomunikacyjnego, cz$!' opisowa

Czy urz"dzenie telekomunikacyjne podlega obowi"zkowej ochronie ? 30 Czy do urz"dzenia telekomunikacyjnego jest mo&liwo!' dojazdu z drogi publicznej pojazdem transportowym o masie ca#kowitej minimum 10 ton ? 31 Czy w lokalizacji urz"dzenia telekomunikacyjnego jest mo&liwo!' rozwini$cia anten ? 32 Czy w lokalizacji urz"dzenia telekomunikacyjnego znajduje si$ maszt antenowy z mo&liwo!ci" zamontowania dodatkowych elementów antenowych ? 33 2 ? Czy istnieje mo&liwo!' wydzielenia w obiekcie, w którym znajduje si$ urz"dzenie telekomunikacyjne, oddzielnego pomieszczenia o powierzchni minimum 10 m

34 Czy urz"dzenie telekomunikacyjne obj$te jest umow" na dostosowanie do wspó#pracy z ruchomymi urz"dzeniami telekomunikacyjnymi: 35

Ministerstwa Obrony Narodowej

35

Ministerstwa Spraw Wewn$trznych i Administracji

Czy urz"dzenie telekomunikacyjne spe#nia wymagania w zakresie przygotowania przy#"czy energetycznych i teletechnicznych ? 37 Czy urz"dzenie telekomunikacyjne posiada przy#"cze energetyczne: 38

trójfazowe, rezerwa mocy minimum 15kVA

39

jednofazowe, rezerwa mocy minimum 10kVA

Czy urz"dzenie telekomunikacyjne posiada zasilenie awaryjne: 40

z sieci energetycznej, przy#"cze trójfazowe, rezerwa mocy minimum 10kVA

41

z agregatów pr"dotwórczych, rezerwa mocy minimum 10kVA

Czy urz"dzenie telekomunikacyjne ma zapewnione serwisowanie przez: 42

firm$ zewn$trzn"

43

w#asny personel techniczny

Jaki jest czas naprawy urz"dzenia telekomunikacyjnego w przypadku uszkodze%: 44

powoduj"cych ca#kowit" niesprawno!' urz"dzenia telekomunikacyjnego

45

powoduj"cych pogorszenie funkcjonalno!ci

Warunki pod"#czenia do urz#dzenia telekomunikacyjnego ruchomych urz#dze% telekomunikacyjnych

46

Procedura realizacji pod#"czenia ruchomych urz"dze% telekomunikacyjnych Ministerstwa Obrony Narodowej lub Ministerstwa Spraw Wewn$trznych i Administracji

................................................................ Miejscowo!', data i podpis osoby wype#niaj"cej formularz

....................................................................... Data i podpis osoby uprawnionej do reprezentowania przedsi$biorcy telekomunikacyjnego

10

Obja$nienia sposobu wype"niania Wska&nik

Opis

1

Wprowadzenie danych

Je&eli dane dotycz"ce urz"dzenia telekomunikacyjnego dostarczane s" po raz pierwszy nale&y wpisa' znak aktualizacji danych pole pozostawi' niewype#nione.

2

Aktualizacja danych

Je&eli formularz jest dokumentem aktualizuj"cym dane o urz"dzeniu telekomunikacyjnym nale&y wpisa' znak

3

Wed#ug stanu na dzie%

Nale&y wpisa' dat$ wype#nienia formularza, odpowiednio w pola dzie%, miesi"c, rok.

5

Numer w rejestrze przedsi$biorców telekomunikacyjnych

Nale&y wpisa' numer w rejestrze przedsi$biorców telekomunikacyjnych, prowadzonym przez Prezesa Urz$du Komunikacji Elektronicznej.

6

Nazwa urz"dzenia telekomunikacyjnego

Nale&y wpisa' pe#n" nazw$ urz"dzenia telekomunikacyjnego charakteryzuj"c" realizowane przez niego funkcje.

7

Identyfikator urz"dzenia telekomunikacyjnego w systemie informatycznym przedsi$biorcy telekomunikacyjnego

Nale&y wpisa' numer identyfikuj"cy urz"dzenie telekomunikacyjne w systemie informatycznym przedsi$biorcy telekomunikacyjnego.

8

Nadana klauzula tajno!ci dla informacji zawieraj"cych szczegó#owe dane o urz"dzeniu telekomunikacyjnym zastrze&one

9

Nadana klauzula tajno!ci dla informacji zawieraj"cych szczegó#owe dane o urz"dzeniu telekomunikacyjnym - poufne

10

Nadana klauzula tajno!ci dla informacji zawieraj"cych szczegó#owe dane o urz"dzeniu telekomunikacyjnym - tajne

11

Nadana klauzula tajno!ci dla informacji zawieraj"cych szczegó#owe dane o urz"dzeniu telekomunikacyjnym - !ci!le tajne

12

Czy urz"dzenie telekomunikacyjne jest obs#ugiwane ?

13

Czy urz"dzenie telekomunikacyjne jest dzier&awione innemu Nale&y wpisa' znak X je&eli urz"dzenie telekomunikacyjne jest dzier&awione innemu przedsi$biorcy. przedsi$biorcy ?

14

Czy urz"dzenie telekomunikacyjne jest dzier&awione od inego Nale&y wpisa' znak X je&eli urz"dzenie telekomunikacyjne jest dzier&awione od innego przedsi$biorcy telekomunikacyjnego. przedsi$biorcy ?

15

Data zako%czenia eksploatacji lub u&ywania urz"dzenia telekomunikacyjnego

Pole wype#nia si$ tylko w przypadku aktualizacji danych. Nale&y wpisa' dat$ zako%czenia u&ywania lub eksloatacji urz"dzenia telekomunikacyjnego odpowiednio w pola, dzie% - dd, miesi"c - mm, rok - rrrr.

16

d#ugo!' geograficzna

17

szeroko!' geograficzna

Dane nale&y przedstawi' w uk#adzie odniesienia WGS 84 , format pozycji hddd mm' ss,s'' (N 51 21' 28,7''). Miejsce pomiaru wej!cie g#ówne do obiektu budowlanego, w którym znajduje si$ urz"dzenie telekomunikacyjne, lub g#ówna brama wjazdowa. Pomiaru nale&y dokona' przy u&yciu GPS lub odczyta' z mapy w skali nie mniejszej ni& 1:25000. Zapis d#ugo!ci geograficznej wschodniej w przedziale od 14 stopni do 24 stopni 30 minut. Zapis szeroko!ci geograficznej pó#nocnej z przedzia#u od 49 stopni do 55 stopni 30 minut.

18

kraj

19

województwo

20

powiat

21

gmina

22

miejscowo!'

Nr pola

X , w przypadku

Nale&y wpisa' znak

X w pole odpowiadajace nadanej klauzuli tajno!ci.

Nale&y wpisa' znak

X je&eli urz"dzenie telekomunikacyjne jest obs#ugiwane.

X.

Miejsce gdzie znajduje si$ obiekt budowlany, w którym jest zainstalowane urz"dzenie telekomunikacyjne - dane nale&y wpisa' we w#a!ciwe pola. 23

ulica

24

numer domu

25

numer lokalu

26

kod pocztowy

11 27

poczta

28

informacje dodatkowe

Nale&y poda' informacje uzupe#niaj"ce w zakresie umo&liwiaj"cym zlokalizowanie urz"dzenia telekomunikacyjnego, szczególnie w przypadku jego ooddalenia od wskazanej w adresie miejscowo!ci (nazwa fizjograficzna lub numer dzia#ki).

29

Charakterystyka urz"dzenia telekomunikacyjnego, cz$!' opisowa

Jako za#"cznik do formularza nale&y sporz"dzi' charakterystyk$ urz"dzenia telekomunikacyjnego zawieraj"c" szczegó#owe dane techniczne i funkcjonalne oraz opis warunków dojazdu do obiektu, warunków zamocowania i rozwini$cia anten. Charakterystyk$ nale&y sporz"dzi' w formacie pdf lub na oddzielnym arkuszu papieru oraz oznaczy' nazw" przedsi$biorcy telekomunikacyjnego, nazw" urz"dzenia lub jego identyfikatorem w systemie informatycznym przedsi$biorcy.

30

Czy urz"dzenie telekomunikacyjne podlega obowi"zkowej ochronie ?

Nale&y wpisa' znak X je&eli urz"dzenie telekomunikacyjne zosta#o uj$te w ewidencji (prowadzonej przez w#a!ciwego wojewod$) obszarów, obiektów i urz"dze% podlegajacych obowi"zkowej ochronie - zgodnie z art. 5 ust. 5 ustawy z dnia 22 sierpnia 1997 r. o ochronie osób i mienia (Dz.U. z 2005 r. Nr 145, poz. 1221 z pó(n. zm.).

31

Czy do urz"dzenia telekomunikacyjnego jest mo&liwo!' dojazdu z drogi publicznej pojazdem transportowym o masie ca#kowitej minimum 10 ton ?

Nale&y wpisa' znak X je&eli do urz"dzenia telekomunikacyjnego jest mo&liwy dojazd z drogi publicznej dla pojazdów dwu!ladowych o masie ca#kowit$j minimum 10 ton, wysoko!ci 3,5 m, szeroko!ci 2,6 m, d#ugo!ci z przyczep" 11 m oraz promieniem skr$tu wi$kszym ni& 9 m.

32

Czy w lokalizacji urz"dzenia telekomunikacyjnego jest mo&liwo!' rozwini$cia anten ?

Nale&y wpisa' znak X je&eli w lokalizacji urz"dzenia telekomunikacyjnego jest mo&liwo!' rozwini$cia anten na polu o wymiarach 32 m x 32 m, o d#ugo!ci fidera antenowego 40 m i maksymalnej wysoko!ci masztu 24 m.

33

Czy w lokalizacji urz"dzenia telekomunikacyjnego znajduje si$ maszt antenowy z mo&liwo!ci" zamontowania dodatkowych Nale&y wpisa' znak X je&eli w lokalizacji urz"dzenia telekomunikacyjnego znajduje si$ maszt antenowy z mo&liwo!ci" zamontowania dodatkowych elementów antenowych. elementów antenowych ?

34

Czy istnieje mo&liwo!' wydzielenia w obiekcie, w którym znajduje si$ urz"dzenie telekomunikacyjne, oddzielnego pomieszczenia o powierzchni minimum 10 m2 ?

oddzielne pomieszczenie o powierzchni minimum 10 m2 (wysoko!' 2,5 m) oraz zainstalowa' urz"dzenia w standardowych szafach 19 calowych. Pomieszczenie powinno mie' doprowadzone zasilanie 220V 50Hz i wolny przepust kablowy.

35

Czy urz"dzenie telekomunikacyjne obj$te jest umow" na dostosowanie do wspó#pracy z ruchomymi urz"dzeniami telekomunikacyjnymi Ministerstwa Obrony Narodowej ?

Nale&y wpisa' znak X je&eli urz"dzenie telekomunikacyjne jest obj$t$ umow" na dostosowanie do wspó#pracy z ruchomymi urz"dzeniami telekomunikacyjnymi Ministerstwa Obrony Narodowej.

36

Czy urz"dzenie telekomunikacyjne obj$te jest umow" na dostosowanie do wspó#pracy z ruchomymi urz"dzeniami telekomunikacyjnymi Ministerstwa Spraw Wewn$trznych i Administracji ?

Nale&y wpisa' znak X je&eli urz"dzenie telekomunikacyjne jest obj$te umow" na dostosowanie do wspó#pracy z ruchomymi urz"dzeniami telekomunikacyjnymi Ministerstwa Spraw Wewn$trznych i Administracji.

Czy urz"dzenie telekomunikacyjne spe#nia wymagania w zakresie przygotowania przy#"czy energetycznych i teletechnicznych ?

Nale&y wpisa' znak X je&eli urz"dzenie telekomunikacyjne posiada: 1) przy"#cze energetyczne wyposa'one w: - 2 gniazda ABL-17 - 32 A (minimalna moc zasilania 2x5,0 kVA, napi$cie 230 +/- 5V, cz$stotliwo!' 50 +/- 1Hz, wykonane w obudowie IP 54 z szyn" Cu dla PE); - skrzynk$ rozdzielcz" IP 54; - szyn$ Cu 100x30x5mm; - 2 jednofazowe liczniki energii elektrycznej E12-W ; - ochronniki przepi$'; - przetwornic$ 48/24V (AC/DC) do zasilania konwerterów K0-2g TRANSBIT (przy braku gwarantowanej sieci 230V).

37

Nale&y wpisa' znak

X je&eli w obiekcie budowlanym, w którym znajduje si$ urz"dzenie telekomunikacyjne mo&na wydzieli'

2) przy"#cze teletechniczne zawieraj#ce: - 2 styki elektryczne (PS 2) 2Mb,120 Ohm; - 2 styki optyczne (CTOS 976) 2Mb ( !wiat#owód wielomodowy w oknie 1300nm, moc nadajnika 1,2mW, czu#o!' odbiornika 26dBm); - 2 konwertery K0-2g firmy TRANSBIT; - 2 z#"cza CTOS 976 z patchcordem !wiat#owodowym. Nale&y wpisa' znak X je&eli urz"dzenie telekomunikacyjne posiada przy#"cze energetyczne trójfazowe z rezerw" mocy minimum 15kVA.

38

Czy urz"dzenie telekomunikacyjne posiada przy#"cze energetyczne trójfazowe, rezerwa mocy minimum 15kVA ?

39

Czy urz"dzenie telekomunikacyjne posiada przy#"cze Nale&y wpisa' znak X je&eli urz"dzenie telekomunikacyjne posiada przy#"cze energetyczne jednofazowe z rezerw" mocy energetyczne jednofazowe, rezerwa mocy minimum 10kVA ? minimum 10kVA.

40

Czy urz"dzenie telekomunikacyjne posiada zasilanie awaryjne Nale&y wpisa' znak X je&eli urz"dzenie telekomunikacyjne posiada zasilanie awaryjne z sieci energetycznej - przy#"cze z sieci energetycznej - przy#"cze trójfazowe, rezerwa mocy trójfazowe z rezerw" mocy minimum 10kVA minimum 10kVA ?

41

Czy urz"dzenie telekomunikacyjne posiada zasilanie awaryjne z agregatów pr"dotwórczych, rezerwa mocy minimum 10kVA Nale&y wpisa' znak X je&eli urz"dzenie telekomunikacyjne posiada zasilanie awaryjne z agregatów pr"dotwórczych z rezerw" mocy minimum 10kVA. ?

42

Czy urz"dzenie telekomunikacyjne ma zapewnione serwisowanie przez firm$ zewn$trzn" ?

Nale&y wpisa' znak X je&eli urz"dzenie telekomunikacyjne ma zapewnione serwisowanie przez firm$ zewn$trzn".

43

Czy urz"dzenie telekomunikacyjne ma zapewnione serwisowanie przez w#asny personel techniczny ?

Nale&y wpisa' znak X je&eli urz"dzenie telekomunikacyjne ma zapewnione serwisowanie przez w#asny personel techniczny.

44

Jak jest czas naprawy urz"dzenia telekomunikacyjnego w Nale&y wpisa' czas naprawy w godzinach dla uszkodze% powoduj"cych ca#kowit" niesprawno!' urz"dzenia przypadku uszkodze% powoduj"cych ca#kowit" niesprawno!' telekomunikacyjnego lub przerw$ w dzia#aniu 25% funkcji podstawowych tego urz"dzenia. urz"dzenia telekomunikacyjnego ?

45

Jak jest czas naprawy urz"dzenia telekomunikacyjnego w przypadku uszkodze% powoduj"cych pogorszenie funkcjonalno!ci ?

Nale&y wpisa' czas naprawy w godzinach dla uszkodze% powoduj"cych pogorszenie funkcjonalno!ci lub wydajno!ci urz"dzenia telekomunikacyjnego.

46

Procedura realizacji pod#"czenia ruchomych urz"dze% telekomunikacyjnych Ministerstwa Obrony Narodowej lub Ministerstwa Spraw Wewn$trznych i Administracji

Jako za#"cznik do formularza nale&y sporz"dzi' procedur$ pod#"czenia ruchomych urz"dze% telekomunikacyjnych Ministerstwa Obrony Narodowej lub Ministerstwa Spraw Wewn$trznych i Administracji. Procedur$ nale&y sporz"dzi' w formacie pdf lub na oddzielnym arkuszu papieru oraz oznaczy' nazw" przedsi$biorcy telekomunikacyjnego, nazw" urz"dzenia lub jego identyfikatorem w systemie informatycznym przedsi$biorcy. W przypadku, gdy procedury pod#"czenia b$d" takie same dla grupy urz"dze% telekomunikacyjnych nale&y sporz"dzi' dla tej grupy urz"dze% jedn" procedur$ podaj"c nazwy i identyfikatory wszystkich urz"dze%, których procedura dotyczy.

Projekt ROZPORZ!DZENIE RADY MINISTRÓW z dnia ……….. 2008 r. w sprawie okre'lenia wymaga# technicznych i eksploatacyjnych dla interfejsów umo%liwiaj&cych wykonywanie przedsi$biorcom telekomunikacyjnym zada# i obowi&zków na rzecz obronno'ci, bezpiecze#stwa pa#stwa oraz bezpiecze#stwa i porz&dku publicznego

Na podstawie art. 182 ustawy z dnia 14 lipca 2004 r. - Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800, z póz. zm.1)) zarz#dza si%, co nast%puje: § 1. Rozporz#dzenie okre&la wymagania techniczne i eksploatacyjne dla interfejsów, o których mowa w art. 179 ust. 4a ustawy z dnia 14 lipca 2004 r. – Prawo telekomunikacyjne, zwane dalej „ustaw#”, umo$liwiaj#cych wykonywanie zada' i obowi#zków na rzecz obronno&ci, bezpiecze'stwa pa'stwa oraz bezpiecze'stwa i porz#dku publicznego, o których mowa w art. 179 ust. 3 i art. 180d ustawy. § 2. 1. Okre&lenia u$yte w rozporz#dzeniu oznaczaj#: 1) Interfejs HI – styk mi%dzy systemem operatora telefonii, a systemem uprawnionego podmiotu; 2) HI1 – styk administracyjny; 3) HI 2 – styk przesy"u danych skojarzonych; 4) HI 3 – styk przesy"u tre&ci przekazu; 5) CC – tre&) przekazu; 6) CS – [Circuit Switched] dane skojarzone; 7) CRI – [Call Related Information] informacja dotycz#ca po"#czenia; 8) PS – [Packed Switched] transmisja pakietowa; 9) LEMF - systemem uprawnionego podmiotu umo$liwiaj#cy dost%p do wybranych tre&ci przekazów telekomunikacyjnych; 10) ADMF - systemem operatora telefonii ruchomej umo$liwiaj#cy realizacj% dost%pu do wybranych tre&ci przekazów telekomunikacyjnych;

1)

Zmiany wymienionej ustawy zosta"y og"oszone w Dz. U. z 2004 r. Nr 273, poz. 2703, z 2005 r. Nr 163, poz. 1362 i Nr 267, poz. 2258, z 2006 r. Nr 12, poz. 66, Nr 104, poz. 708 i 711, Nr 170, poz. 1217, Nr 220, poz. 1600, Nr 235, poz. 1700 i Nr 249, poz. 834, z 2007 r. Nr 23, poz. 137, Nr 50, poz. 331 i Nr 82 poz. 556 oraz z 2008 r. Nr 17, poz. 101 i Nr ..., poz. ...

11) MSISDN - [Mobile Station International ISDN Number] miedzynarodowy numer abonenta sieci ISDN; 12) IMEI - [International Mobile Equipment Identity] miedzynarodowy numer identyfikacyjny terminala; 13) IMSI - [International Mobile Subscriber Identity] miedzynarodowy numer abonenta ruchomego IMSI; 14) LOGIN – nazwa u$ytkownika loguj#cego si% do sieci, u$ywana w procesie jego uwierzytelnienia; 15) IP – [Internet Protocol] protokó" internetowy; 16) ETSI – European Telekommunikations Standarts Institiute. 2. Poj%cia u$yte w rozporz#dzeniu s# to$same ze standardami 3GPP i ETSI. § 3. 1. Interfejs HI jest w ca"o&ci elektroniczny i zdalny. 2. S"u$y do dostarczania wybranych wyników przechwytywania w czasie rzeczywistym dla us"ug czasu rzeczywistego. Us"ugi, zawieraj#ce element zw"oki, takie jak us"ugi pocztowe mog# by) dostarczane z uwzgl%dnieniem opó!nienia w przekazywaniu wyników przechwytywania. 3. Interfejs jest dzielony na trzy styki HI-1, HI-2 oraz HI-3: 1) HI-1 – s"u$y do przesy"ania wiadomo&ci administracyjnych: aktywacji, deaktywacji, modyfikacji zlece' obj%cia monitoringiem konkretnego zako'czenia sieci. Styk Hi-1 umo$liwia obustronn# transmisj% sygna"ów; 2) HI-2 – s"u$y do przesy"u informacji skojarzonych z obj%tymi kontrol# operacyjn# przekazami telekomunikacyjnymi oraz tre&ci sms; 3) HI – 3 s"u$y do przekazu tre&ci monitorowanych przekazów. § 4. 1. Styk HI-1 powinien umo$liwia) bez udzia"u pracowników przedsi%biorcy funkcjonariuszy uprawnionych podmiotów, podmiot. 2. Szczegó"owy opis techniczny do rozporz#dzenia.

w"#czanie, modyfikacje i wy"#czanie obiektów telekomunikacyjnego przez uprawnionych z lokalizacji wskazanej przez uprawniony styku

HI-1

okre&la

za"#cznik

nr

1

§ 5. Je$eli przedsi%biorca telekomunikacyjny stosuje w ramach &wiadczonych us"ug mechanizmy szyfruj#ce, to obowi#zany jest udost%pnia) je podmiotom uprawnionym w formie rozszyfrowanej. § 6. Przekazywanie wyników przechwytywania odbywa si% przez "#cza sta"e. § 7. Uprawniony podmiot mo$e wyrazi) zgod% na dopuszczenie udzia"u uprawnionych pracowników przedsi%biorcy telekomunikacyjnego przy w"#czaniu, modyfikacji i wy"#czaniu obiektów. Zakres udzia"u pracowników operatora okre&la si% w formie porozumienia stron, wskazuj#c wymagania formalne co do sposobu dokumentowania czynno&ci wykonanych przez pracowników operatora i dokumentowania faktu dost%pu pracownika operatora do danych nale$#cych do uprawnionego podmiotu. Zawarcie porozumienia z jednym z uprawnionych podmiotów nie zwalnia operatora sieci telekomunikacyjnej od obowi#zku przygotowania styku HI-1 dla pozosta"ych uprawnionych podmiotów, w sposób okre&lony 2

w § 4. § 8. 1. W przypadku zawarcia porozumienia, o którym mowa w § 7, przedsi%biorcy telekomunikacyjnemu mog# by) przekazane wy"#cznie okre&lone kategorie informacji: 1) numer wniosku; 2) data zatwierdzenia; 3) organ zatwierdzaj#cy; 4) czas na jaki zosta"a zarz#dzona kontrola operacyjna; 5) kryterium wyboru; 6) numer stacji ko'cowej lub zako'czenia sieci. 2. Przekazywanie informacji nast%puje w formie elektronicznej przez uprawnione podmioty w sposób zapewniaj#cy bezpieczn# transmisj% i przechowywanie. 3. Porozumienie, o którym mowa w § 7, mo$e dopuszcza) przekazywanie zlecenia przez uprawnione podmioty przedsi%biorcy telekomunikacyjnemu, w formie dokumentacji papierowej. 4. W przypadku zawarcia porozumienia, o którym mowa w § 7, czas jaki up"ynie od momentu otrzymania zlecenia do momentu faktycznego, technicznego w"#czenia monitoringu przez pracowników operatora, nie mo$e by) d"u$szy ni$: 1) w godzinach 8:00-16:00 – 30 minut; 2) w godzinach 16:01 – 07.59 - 1 godzina. § 9. 1. Interfejs HI w ca"o&ci oparty jest na technologii IP. 2. W styku HI-3 dopuszcza si% stosowanie n-kapsulacji E1 do IP. 3. Szczegó"owe opisy techniczne styków HI-2 oraz HI-3 okre&laj# za"#czniki nr 24 do rozporz#dzenia. § 10. Komunikacja mi%dzy systemem monitoringu przedsi%biorcy telekomunikacyjnego a systemem monitoringu uprawnionego podmiotu odbywa si% z wykorzystaniem publicznych adresów IP i wskazanych portów. Nie stosuje si% adresów i numerów portów przydzielanych w sposób dynamiczny. § 11. Szyfrowanie styku z LEMF b%dzie realizowane poza interfejsem HI na poziomie warstwy fizycznej "#cza. Przedsi%biorca telekomunikacyjny zapewnia, na swój koszt, stworzenie warunków umo$liwiaj#cych podmiotom uprawnionym instalacj% oraz eksploatacj% urz#dze' szyfruj#cych w lokalizacji interfejsu, zapewnia te$ ich ochron% fizyczn# i ustala z uprawnionymi podmiotami warunki serwisowania tych urz#dze'. § 12. Interfejs danego systemu monitoringu przedsi%biorcy telekomunikacyjnego dost%pny jest w jednym punkcie styku (lokalizacji) dla wszystkich uprawnionych podmiotów. Na potrzeby systemu redundantnego tworzy si% zapasowy punkt styku. § 13. 1. Za harmonogram w"#czania i wy"#czania obserwacji odpowiada system monitoringu LEMF uprawnionego podmiotu. 2. Wysy"anie zlece' aktywacji ma miejsce w chwili rzeczywistego uruchamiania monitoringu. Dopuszcza si% mo$liwo&) wysy"ania zlece' aktywacji z wyprzedzeniem. Wyprzedzenie nale$y uzgodni) na etapie uzgadniania zasad wspó"pracy poprzez interfejs. Ka$de zlecenie aktywacji musi mie) okre&lony czas zako'czenia kontroli operacyjnej. 3. Odst%p czasu mi%dzy rozpocz%ciem a zako'czeniem kontroli operacyjnej nie mo$e przekroczy) &ci&le okre&lonej warto&ci wynikaj#cej z przepisów prawa.

3

4. Przesuni%cie chwili zako'czenia obserwacji ponad ten czas mo$liwe jest tylko za pomoc# zlecenia modyfikacji. Zmiana czasu rozpocz%cia monitoringu wymaga usuni%cia poprzedniego zlecenia i w"#czenia nowego. § 14. System monitoringu operatora przesy"a do systemu podmiotu uprawnionego informacj% o czasie faktycznego wykonania polecenia aktywacji/deaktywacji/modyfikacji, w przypadku b"%du w trakcie wykonywania polecenia, przesy"a informacj% o fakcie pojawienia si% b"%du lub braku mo$liwo&ci wykonania polecenia. § 15. Zlecenie modyfikacji czasu trwania kontroli operacyjnej dotyczy jedynie czasu jej wy"#czenia lub zmiany trybu online/offline. Zlecenie trybu online nie mo$e powodowa) przerwania rejestracji i transmisji offline dla danego obiektu. § 16. System monitoringu operatora nie dokonuje ingerencji i interpretacji dostarczanych tre&ci. Dla celów monitoringu online stosuje si% kompresj% mowy s"u$#c# optymalizacji wykorzystania istniej#cego pasma. § 17. System monitoringu operatora, ze wzgl%du na mo$liwe awarie, gromadzi tre&ci komunikatów i informacji z nimi zwi#zanych monitorowanych obiektów w buforze zapewniaj#cym ich przechowywanie przez co najmniej 72 godziny. Interfejs HI przekazuje je bez zb%dnej zw"oki do systemu monitoringu uprawnionego podmiotu. Po uzyskaniu potwierdzenia przekazania tre&ci komunikatów i informacji z nimi zwi#zanych, system operatora usuwa je ze swoich zasobów. § 18. Przedsi%biorca telekomunikacyjny wyposa$a swój system w urz#dzenie rejestruj#ce wszystkie dzia"ania podejmowane na styku HI-1. Rejestracja ta obejmuje polecenia aktywacji/deaktywacji/modyfikacji wydane przez akredytowanych w systemie przedsi%biorcy telekomunikacyjnego pracowników uprawnionego podmiotu lub operatora dla ka$dego LIID wraz z kryteriami wyboru i czasem trwania monitoringu. § 19. 1. W przypadku awarii urz#dzenia, o którym mowa w § 18, lub braku "#czno&ci pomi%dzy systemem operatora a tym urz#dzeniem, system operatora uniemo$liwia dokonanie wszelkiego rodzaju zmian na styku HI-1. 2. W przypadku opracowania procedury dokumentowania w formie papierowej czynno&ci wykonywanych w trakcie trwania awarii urz#dzenia, o którym mowa w § 18, wymogu okre&lonego w ust. 1 nie stosuje si%. § 20. Przedsi%biorca telekomunikacyjny jest obowi#zany do stworzenia szczególnych warunków ochrony urz#dzenia, o którym mowa w § 18, oraz przechowywanych w nim danych poprzez: 1) zapewnienie oddzielnego pomieszczenia posiadaj#cego dodatkow# ochron% fizyczn#; 2) wydzielony system zasilania awaryjnego; 3) dost%p tylko komisyjny; 4) uniemo$liwienie dokonania zatarcia lub modyfikacji informacji. § 21. W przypadku awarii elementów sieci operatora system wysy"a do systemów uprawnionych podmiotów informacj% o fakcie awarii wraz z okre&leniem zasi%gu awarii (numery central/stacji BTS obj%tych awari#) przesy"aj#c jednocze&nie do ka$dego z uprawnionych podmiotów informacje o numerach LIID obj%tych awari# , które znajduj# si% w jego dyspozycji. § 22. Po usuni%ciu awarii, system monitoringu operatora niezw"ocznie przesy"a informacje do systemu uprawnionego podmiotu o czasie trwania przerwy w przechwytywaniu 4

danych. § 23. Interfejs umo$liwia przesy"anie wiadomo&ci diagnostycznych pozwalaj#cych w szczególno&ci na stwierdzenie czy po"#czenie mi%dzy systemami jest aktywne. § 24. 1. Dane przekazywane za po&rednictwem interfejsów HI s# obligatoryjnie zabezpieczane zgodnie z wymaganiami okre&lonymi w ustawie z dnia 18 wrze&nia 2001 r. o podpisie elektronicznym (Dz. U. Nr 130, poz. 1450, z pó!n. zm.). 2. Wymóg zabezpieczenia, o którym mowa w ust. 1, przekazów dokonywanych za po&rednictwem styków HI-2 i HI-3 wchodzi w $ycie po up"ywie 24 miesi%cy od daty wej&cia w $ycie rozporz#dzenia. § 25. Mechanizm podpisów elektronicznych ma zapewni), $e $#dania, które steruj# uruchomieniem kontroli korespondencji b%d# wprowadzane i przesy"ane tylko przez uprawnione do tego osoby, oraz $e ka$de $#danie mo$na b%dzie jednoznacznie przypisa) zlecaj#cemu je u$ytkownikowi LEMF. § 26. 1. Formatem stosowanego podpisu elektronicznego $#da' HI jest CMS (Cryptographics Message Syntax) zdefiniowany w RFC 3852. Na potrzeby stosowania podpisu elektronicznego wykorzystywane s# certyfikaty X.509 w wersji 3 (z uwzgl%dnieniem wymaga' technicznych zawartych w rozporz#dzeniu wykonawczym do ustawy o podpisie elektronicznym) oraz infrastruktura klucza publicznego PKI. 2. Sposób i zakres informacji zabezpieczonych podpisem elektronicznym okre&la za"#cznik nr 5 rozporz#dzenia. § 27. Interfejs HI zapewnia w szczególno&ci nast%puj#ce kryteria wyboru identyfikuj#ce obiekty obserwacji w sieciach telekomunikacyjnych stosownie do rodzaju sieci: !"# MSISDN; $"# IMSI; %"# numer IMEI; &"# LOGIN; '"# adres IP; ("# adres MAC. § 28. Us"ugi obs"ugiwane przez interfejs HI1 w szczególno&ci obejmuj#: 1) GSM/UMTS CS - us"ugi oparte na komutacji "#czy: audio, fax, modem, sms, videopo"#czenia; 2) GSM/UMTS PS - us"ugi oparte na komutacji pakietów: technologia IP; 3) PWLAN - us"ug% bezprzewodowej sieci IP; 4) XDSL - szerokopasmowy stacjonarny dost%p do Internetu. § 29. Struktura interfejsu powinna pozwala) na dodanie nowych kryteriów w miar% rozwoju us"ug i mo$liwo&ci sieci w zakresie identyfikacji u$ytkowników.

5

§ 30. W celu identyfikacji obiektów monitorowanych w systemach przedsi%biorców telekomunikacyjnych wykorzystany jest numer LIID. § 31.W ka$dym przypadku numer LIID, dla danego kryterium wyboru, obejmuje tylko jedn# us"ug% do monitorowania. § 32. Liczba monitorowanych zako'cze' sieci dost%pnych dla ka$dego z uprawnionych podmiotów: 1) 0,05% pojemno&ci ka$dej centrali wchodz#cej w sk"ad sieci przedsi%biorcy, lub 2) 0,03% zako'cze' sieci przedsi%biorcy, w których wykonywana jest dzia"alno&) telekomunikacyjna podlegaj#ca obowi#zkowi wykonywania zada' - z tym, $e nie mo$e by) mniejsza ni$ trzy. § 33. Okre&lenie sk"adni numeru LIID: 1) pierwsze pole dla okre&lenia uprawnionego podmiotu; 2) pola 2 i 3 – od 00 do 17 - organ wydaj#cy zarz#dzenie/wniosek; 3) pola 4 - 6 – numer kolejny wniosku; 4) pole 7 – oznaczenie kwarta"u wydania wniosku; 5) pola 8 i 9 – rok wydania wniosku; 6) pola 10 i 11 – jednostka dedykuj#ca; 7) pole 12 – oznaczenie operatora; 8) pola 13 - 17 – numer kolejny w"#czenia. § 34. Komunikacja przesy"u danych: 1) interfejsy HI s"u$# do przesy"ania wiadomo&ci administracyjnych (HI1), informacji skojarzonych (HI2) i tre&ci monitorowanych przekazów (HI3); wykorzystuj# do tego szereg protoko"ów sieciowych ró$nych warstw, aby dostarczy) dane do okre&lonego miejsca przeznaczenia w sieci; 2) warstwa fizyczna i warstwa sieciowa jest wspólna dla wszystkich interfejsów HI; poszczególne interfejsy HI s# wspomagane przez protoko"y wy$szych warstw takich jak TCP, FTP czy ULIC; 3) urz#dzenia sieciowe na styku pomi%dzy systemami przedsi%biorcy telekomunikacyjnego i uprawnionego podmiotu oferuj# warstw% fizyczn# standardu Ethernet. do obs"ugi ka$dego z uprawnionych podmiotów przewidziany jest oddzielny interfejs Ethernet; 4) wybór protoko"u, dostosowanie przesy"anych informacji oraz szyfrowanie sygna"u na "#czach WAN le$y w gestii podmiotów uprawnionych, jedynym wymogiem jest, aby interfejs do operatora by" standardu Ethernet; 5) interfejsy HI (HI1, HI2, HI3) wykorzystuj# do przesy"ania danych w warstwie sieciowej protokó" minimum IPv4; dla wszystkich interfejsów HI stosowana jest adresacja publiczna IP zarówno po stronie przedsi%biorcy telekomunikacyjnego, jak równie$ uprawnionego podmiotu; na styku WAN do uprawnionych podmiotów wykorzystywana jest adresacja publiczna IP nadawana przez operatora, z mask# 29 bitów. § 35. Interfejs HA-B s"u$y do dostarczania przez przedsi%biorc% telekomunikacyjnego uprawnionym podmiotom danych, o których mowa w art. 180d ustawy.

6

§ 36. Interfejs jest w ca"o&ci elektroniczny i zdalny, udost%pnianie danych telekomunikacyjnych odbywa si% bez udzia"u pracowników podmiotu prowadz#cego dzia"alno&) telekomunikacyjn# lub przy niezb%dnym ich udziale, je$eli mo$liwo&) taka jest przewidziana w porozumieniu zawartym pomi%dzy uprawnionym podmiotem a tym przedsi%biorc#. § 37. Prawid"owe dzia"anie interfejsu zapewnia si% przez zastosowanie obiegu dokumentacji czynno&ci w formie elektronicznej. § 38. Komunikacja pomi%dzy uprawnionym podmiotem a interfejsem przedsi%biorcy telekomunikacyjnego odbywa si% za po&rednictwem "#cz sta"ych. § 39. Przedsi%biorca telekomunikacyjny wyposa$a swój system w urz#dzenie rejestruj#ce wszystkie dzia"ania podejmowane w systemie. Rejestracja ta obejmuje wszystkie zapytania z"o$one przez akredytowanych w systemie pracowników uprawnionego podmiotu lub operatora. § 40. 1. W przypadku awarii urz#dzenia, o którym mowa w § 39, system operatora odrzuca sk"adane przez uprawnionych pracowników zapytania wysy"aj#c jednocze&nie informacj% o fakcie awarii. 2. W przypadku opracowania procedury dokumentowania w formie papierowej czynno&ci wykonywanych w trakcie trwania awarii urz#dzenia, o którym mowa w § 39, wymogu okre&lonego w ust. 1 nie stosuje si%. § 41. Przedsi%biorca telekomunikacyjny jest obowi#zany do stworzenia szczególnych warunków ochrony urz#dzenia, o którym mowa w § 39, oraz przechowywanych w nim danych poprzez: 1) wydzielony system zasilania awaryjnego; 2) dost%p tylko komisyjny; 3) uniemo$liwienie dokonania zatarcia lub modyfikacji informacji. § 42. 1. Przedsi%biorca telekomunikacyjny obowi#zany jest do budowy Interfejsu HI A-B lub modyfikacji istniej#cych urz#dze' w sposób, który umo$liwi przesy"anie danych i sk"adanie zapyta' w formacie XML. Szczegó"owy opis stosowanego formatu okre&la za"#cznik nr 6. 2. Operatorzy, którzy stosuj# inny format ni$ okre&lony w za"#czniku nr 6 do rozporz#dzenia, mog# go dalej stosowa) przy spe"nieniu nast%puj#cych warunków: 1) przekazania podmiotom uprawnionym na swój koszt narz%dzia do konwersji danych do formatu okre&lonego w za"#czniku nr 6 do rozporz#dzenia; 2) zastosowanie przez operatora innego formatu, ni$ okre&lony w za"#czniku nr 6 do rozporz#dzenia, nie mo$e utrudnia) dost%pu uprawnionych podmiotów, do pe"nego katalogu danych, ni$ okre&lony w art. 180d ustawy; 3) szczegó"owe warunki organizacyjne i techniczne okre&lone s# w porozumieniu zawartym pomi%dzy przedsi%biorc# telekomunikacyjnym a uprawnionym podmiotem. 3. W przypadku przedsi%biorców telekomunikacyjnych, którzy zasi%giem dzia"ania nie wykraczaj# poza obszar jednego powiatu lub posiadaj# mniej ni$ 100 tys. zako'cze' sieci, dane o których mowa w art. 161 ustawy, mog# by) przekazywane uprawnionym

7

podmiotom na no&nikach teleinformatycznych w za"#czniku nr 6 do rozporz#dzenia.

w

sposób

inny

ni$

okre&lony

§ 43. Rozporz#dzenie wchodzi w $ycie po up"ywie 14 dni od dnia og"oszenia.

PREZES RADY MINISTRÓW

59-10-aa

8

UZASADNIENIE Rozporz#dzenie stanowi realizacj% upowa$nienia ustawowego zawartego w art. 182 ustawy z dnia 14 lipca 2004 r. – Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800, z pó!n. zm.), zgodnie z którym Rada Ministrów okre&li w drodze rozporz#dzenia wymagania techniczne i eksploatacyjne dla interfejsów, o których mowa w art. 179 ust. 4a ww. ustawy, umo$liwiaj#cych wykonywanie zada' i obowi#zków na rzecz obronno&ci, bezpiecze'stwa pa'stwa oraz bezpiecze'stwa i porz#dku publicznego, o którym mowa w art. 179 ust. 3 i w art. 180d tej$e ustawy. Kieruj#c si% zasad# minimalizacji nak"adów przedsi%biorcy telekomunikacyjnego i podmiotów uprawnionych, opracowano przedmiotowy akt prawny, wskazuj#cy wymagania techniczne i eksploatacyjne dla interfejsów jako jedn# z mo$liwo&ci wykonywania przez przedsi%biorców

telekomunikacyjnych

zada'

i

obowi#zków

na

rzecz

obronno&ci

i bezpiecze'stwa pa'stwa oraz bezpiecze'stwa i porz#dku publicznego. W celu realizacji obowi#zku okre&lonego w art. 5 ustawy z dnia 7 lipca 2005 r. o dzia!alno"ci lobbingowej w procesie stanowienia prawa (Dz. U. Nr 169, poz. 1414) projekt przedmiotowego aktu prawnego zostanie zamieszczony na stronach podmiotowych Kancelarii

Prezesa

Rady

Ministrów

oraz

Ministerstwa

Spraw

Wewn%trznych

i Administracji w Biuletynie Informacji Publicznej. Ze wzgl%du na konieczno&) rozstrzygni%cia potrzeby notyfikacji w &wietle ustawy z dnia 12 wrze&nia 2002 r. o normalizacji (Dz.U. Nr 169, poz. 1386) oraz rozporz#dzenia Rady Ministrów z dnia 23 grudnia 2002 r. w sprawie sposobu funkcjonowania krajowego systemu norm i aktów prawnych (Dz. U. Nr 239, poz. 2039 z pó!n. zm.) projekt rozporz#dzenia powinien by) przekazany ministrowi w"a&ciwemu do spraw gospodarki, jako krajowemu koordynatorowi systemu notyfikacji norm i aktów prawnych. Projekt nie jest obj%ty zakresem prawa Unii Europejskiej.

OCENA SKUTKÓW REGULACJI 1. Podmioty, na które oddzia"uj& projektowane regulacje. Do podmiotów, na które oddzia"uj# projektowane regulacje nale$#: )# przedsi%biorcy telekomunikacyjni wpisani do rejestru prowadzonego przez Urz#d Komunikacji Elektronicznej, )# organy administracji rz#dowej, )# uprawnione podmioty tj. Policja, Stra$ Graniczna, Agencja Bezpiecze'stwa Wewn%trznego, Centralne Biuro Antykorupcyjne, S"u$ba Kontrwywiadu Wojskowego, (andarmeria Wojskowa, organy kontroli skarbowej. 2. Konsultacje. W ramach konsultacji spo"ecznych planuje si% przekaza) projekt do: )# Krajowej Izby Gospodarczej Elektroniki i Telekomunikacji, )# Polskiej Izby Komunikacji Elektronicznej, )# Polskiej Izby Informatyki i Telekomunikacji. 3. Wp"yw regulacji na sektor finansów publicznych. Wej&cie w $ycie projektowanego rozporz#dzenia nie spowoduje dodatkowych skutków finansowych dla bud$etu pa'stwa i bud$etów jednostek samorz#du terytorialnego. 4. Wp"yw regulacji na rynek pracy. Przyj%cie projektowanej regulacji nie b%dzie oddzia"ywa) na rynek pracy. 5. Wp"yw regulacji na konkurencyjno') wewn$trzn& i zewn$trzn& gospodarki. Przyj%cie uregulowa' prawnych zaproponowanych w projekcie ustawy o zmianie ustawy – Prawo telekomunikacyjne oraz niektórych innych ustaw oraz w projekcie przedmiotowego rozporz#dzenia wp"ynie na realne obni$enie kosztów funkcjonowania przedsi%biorców telekomunikacyjnych w porównaniu z aktualnym stanem prawnym. Po pierwsze cz%&) kosztów przeniesiona jest na podmioty uprawnione, a porozumienia (umowy) kszta"tuj# faktyczny podzia" kosztów. W zwi#zku z powy$szym regulacje te b%d# dzia"a) stymuluj#co na rozwój przedsi%biorczo&ci telekomunikacyjnej. Proponowane regulacje nie maj# wp"ywu na konkurencyjno&) gospodarki w zakresie rynku telekomunikacyjnego. Przedsi%biorcy telekomunikacyjni oraz podmioty uprawnione w &wietle projektowanych przepisów Prawa telekomunikacyjnego mog# na podstawie odr%bnych umów okre&li), i$ warunki dost%pu i utrwalania zapewnia si% za pomoc# interfejsów zlokalizowanych w miejscach obejmowanych przez sie) przedsi%biorcy telekomunikacyjnego. Umowa mo$e okre&la) wspó"udzia" stron w kosztach zastosowania interfejsów. Bior#c pod uwag% autonomiczno&) woli stron przy kszta"towaniu zobowi#za' umownych nie ma praktycznych mo$liwo&ci wskazania kosztów 2

realizacji zapisów rozporz#dzenia. Rozporz#dzenie reguluje jednocze&nie wymagania techniczne i eksploatacyjne dla interfejsów umo$liwiaj#cych uzyskiwanie przez podmioty uprawnione danych, o których mowa w art. 180d projektowanej ustawy. Z uwagi na fakt, $e dane te b%d# niejednokrotnie obejmowa) tysi#ce pojedynczych rekordów. Konieczne jest aby dane te przekazywane by"y w postaci elektronicznej. Posta) elektroniczna przekazywanych danych niesie ze sob# wiele korzy&ci. S# to miedzy innymi, "atwo&) archiwizacji danych, "atwe przeszukiwanie i analiza danych (z wykorzystaniem systemów informatycznych), "atwo&) przesy"ania danych. Dlatego istnieje konieczno&) wskazania jednolitego dla wszystkich przedsi%biorców telekomunikacyjnych formatu danych, który móg"by by) wykorzystywany do tego celu. Dodatkowo powinny istnie) ogólnodost%pne narz%dzia umo$liwiaj#ce konwersje przesy"anych przez operatora danych do wymaganego formatu oraz pozwalaj#ce na tworzenie podmiotom uprawnionym aplikacji analizuj#cych dane otrzymane w tym formacie. Formatem spe"niaj#cym powy$sze wymagania jest XML. Jest on wspierany przez wiele systemów baz danych oraz istnieje wiele komercyjnych i darmowych narz%dzi do jego generowania, weryfikowania i analizy. Dokumenty XML pozwalaj# tak$e na szybkie zweryfikowanie ich poprawno&ci.

60-10-aa

3

Za"#czniki do rozporz#dzenia Rady Ministrów z dnia Za"#cznik nr 1 Specyfikacja techniczna styku HI-1 interfejsu HI 1. Rodzaje Wiadomo'ci HI1 Interfejs HI1 w swoich za"o$eniach s"u$y) ma do realizowania funkcji administracyjnych i jako taki przesy"a i obs"uguje wiadomo&ci p"yn#ce w obu kierunku mi%dzy LEMF a ADMF. Je&li chodzi o wiadomo&ci inicjowane przez LEMF (czyli wiadomo&ci w kierunku z LEMF do ADMF) to s# to g"ownie wiadomo&ci maj#ce na celu aktywacj%, modyfikacje lub deaktywacj% obserwacji. Mo$liwe jest równie$ generowanie zapyta' ze strony LEMF o list% obserwacji lub konkretn# obserwacj% w celu sprawdzenia i/lub dokonania porównania baz danych po stronie LEMF i ADMF. Je&li chodzi o wiadomo&ci inicjowane przez ADMF (czyli wiadomo&ci w kierunku z ADMF do LEMF) to mog# to by) w szczególno&ci informacje o pocz#tkach i ko'cach alarmów lub te$ notyfikacje pewnych zdarze'. W obu kierunkach mo$liwe jest wysy"anie wiadomo&ci testuj#cych maj#cych na celu sprawdzenie poprawnego funkcjonowania interfejsu HI1. 2. Kierunek z LEMF do ADMF

Szczegó"owe definicje okre&laj#ce ten ruch zawarte s# w specyfikacji ASN.1 Interfejsu HI1: H1LEMFOperations. Hello

Hello – jest wiadomo&ci# testow# umo$liwiaj#c# stronie LEMF sprawdzenie poprawno&ci dzia"ania interfejsu HI1. HELLO PARAMETR

TYP POLA DANYCH

OPIS

Version

ENUMERATED

wersja protoko"u (1)

Request

CHOICE

typ zapytania (1 – simpleRequest)

simpleRequest

CHOICE

rodzaj zapytania (1 - helloRequest)

Message

UTF8String

tekst

Aktywacja

Szczegó"owa definicja w UnsignedRequestDetail Activate – jest wiadomo&ci# przenosz#c# parametry umo$liwiaj#ce stronie ADMF za"o$enie $#danej przez LEMF obserwacji celu. ACTIVATE PARAMETR Version

OPIS ENUMERATED

wersja protoko"u (1)

Request

CHOICE

typ zapytania (2 – signedRequest)

Time

TimeStamp

godzina i data wystawienia zlecenia aktywacji

Command

CHOICE

typ polecenia (1- Activate)

Liid

OCTET STRING

format: LEAID+TARGET (SEQ), 17 znaków ASCII

Target

CHOICE

kryterium monitorowania i jego warto&) 1)

startTimestamp

TimeStamp

godzina i data aktywacji celu

stopTimestamp

TimeStamp

godzina i data dezaktywacji celu

service

CHOICE

rodzaj $#danej us"ugi 2)

monitoringType

ENUMERATED

aktywacja tylko dla IRI lub IRI+CC 3)

onlineMonitoring

BOOLEAN

forwardingAddress

PrintableString

1)

dla serwisu CircuitSwitchd wybór dodatkowego typu monitorowania online opcjonalnie (wyst%puje tylko dla service=CircuitSwitched); numer przekierowania dla voice online (sipURL)

target 1 – MSISDN 2 – IMSI 3 – IMEI 4 – login

2)

service 1 – CircuitSwitched 2 – PacketSwitched 3 – WIFI 4 – DSL

3)

monitoringType 1 – iri 2 - iriCC Dezaktywacja

Szczegó"owa definicja w UnsignedRequestDetail Deactivate – jest wiadomo&ci# przenosz#c# parametry umo$liwiaj#ce stronie ADMF wy"#czenie (deaktywacj%) $#danej przez LEMF obserwacji celu. MODIFICATE PARAMETR

OPIS

version

ENUMERATED

wersja protoko"u (1)

request

CHOICE

typ zapytania (2 – signedRequest)

time

TimeStamp

godzina i data wystawienia zlecenia aktywacji

Command

CHOICE

typ polecenia (2 – Deactivate)

liid

OCTET STRING

format: LEAID+TARGET (SEQ), 17 znaków ASCII

Modyfikacja

Szczegó"owa definicja w UnsignedRequestDetail Modificate – jest wiadomo&ci# przenosz#c# parametry umo$liwiaj#ce stronie ADMF modyfikacj% czasu zako'czenia $#danej przez LEMF obserwacji celu i/lub zmian% typu monitorowania na offline MODIFICATE PARAMETR

OPIS

version

ENUMERATED

wersja protoko"u (1)

request

CHOICE

typ zapytania (2 – signedRequest)

time

TimeStamp

godzina i data wystawienia zlecenia aktywacji

Command

CHOICE

typ polecenia (3 – Modificate)

liid

OCTET STRING

format: LEAID+TARGET (SEQ), 17 znaków ASCII

stopTimestamp

TimeStamp

godzina i data deaktywacji celu

service

CHOICE

rodzaj $#danej us"ugi (taki jak w wiadomo&ci Activate)

2

Action acknowledge

Odpowied! ze strony ADMF/DF na wiadomo&ci: Hello, Aktywacja, Dezaktywacja, Modyfikacja. ACTION_ACK PARAMETR

TYP POLA DANYCH

OPIS

version

ENUMERATED

wersja protoko"u (1)

respond

CHOICE

typ odpowiedzi (1 – generalRespond)

result

ENUMERATED

wynik operacji 4)

message

PrintableString

ten sam tekst co w hello

4)

result 1 – ok 2 – missing-parametr 3 – unknown-parametr 4 – unknown-parameter value 5 – incorrect-BER 6 – badSignature 7 – certificateExpired 10 – unknownError 11 – unsupportedService List

LIID-LIST – $#danie listy LIIDów monitorowanych lub oczekuj#cych w ADMF. LIID-LIST PARAMETR

TYP POLA DANYCH

version

ENUMERATED

wersja protoko"u (1)

request

CHOICE

typ zapytania (1 – simpleRequest)

simpleRequest

CHOICE

rodzaj zapytania (2 – list)

type

ENUMERATED

liid

OCTET STRING

zapytanie o konkretny LIID lub o wszystkie 5) opcjonalny (wyst%puje tylko dla type=2); format: LEAID+TARGET (SEQ), 17 znaków ASCII

5)

OPIS

type 1 – all 2 – specific List – Odpowied# (1)

LIID-LIST-DATA – odpowied! na LLID-LIST, gdzie type = 1. Pole status mo$e przyj#) tylko warto&ci 1, 2 lub 4. LIID-LIST-DATA PARAMETR

TYP POLA DANYCH

OPIS

version

ENUMERATED

wersja protoko"u (1)

respond

CHOICE

typ odpowiedzi (2 – listRespond)

liid

OCTET STRING

format: LEAID+TARGET (SEQ), 17 znaków ASCII

status

ENUMERATED

status LIID w ADMF 6)

3

message

UTF8String

wiadomo&) dodatkowa

liid

OCTET STRING

format: LEAID+TARGET (SEQ), 17 znaków ASCII

status

ENUMERATED

status LIID w ADMF 6)

message

UTF8String

wiadomo&) dodatkowa

… … … 6)

status 0 – notFound 1 – waiting 2 – cnActivated 3 – unknown 4 – deActivated List – Odpowied! (2)

LIID-LIST-DATA – odpowied! na LLID-LIST, gdzie type = 2. Pole status mo$e przyj#) wszystkie zdefiniowane warto&ci. LIID-LIST-DATA PARAMETR

TYP POLA DANYCH

OPIS

version

ENUMERATED

wersja protoko"u (1)

respond

CHOICE

typ odpowiedzi (2 – listRespond)

liid

OCTET STRING

format: LEAID+TARGET (SEQ), 17 znaków ASCII

status

ENUMERATED

status LIID w ADMF 6)

message

UTF8String

wiadomo&) dodatkowa

6)

status 0 – notFound 1 – waiting 2 – cnActivated 3 – unknown 4 – deActivated 3. Kierunek z ADMF do LEMF

Szczegó"owe definicje okre&laj#ce ten ruch zawarte s# w specyfikacji ASN.1 Interfejsu HI1: H1ADMFOperations. Hello

Hello – jest wiadomo&ci# testow# umo$liwiaj#c# stronie ADMF sprawdzenie poprawno&ci dzia"ania interfejsu HI1. HELLO PARAMETR

TYP POLA DANYCH

OPIS

version

ENUMERATED

wersja protoko"u (1)

Content

CHOICE

typ zapytania (1 –InfoIndicator)

4

InfoIndicatoor

CHOICE

rodzaj zapytania (1 - HelloRequest)

message

UTF8String

tekst

Alarm

Alarm – jest wiadomo&ci# umo$liwiaj#c# stronie ADMF poinformowanie LEMF o ró$nego rodzaju problemach, czasach wyst#pienia tych problemów oraz czasach ich usuni%cia ze wskazaniem na przyczyn%. ALARM PARAMETR

TYP POLA DANYCH

OPIS

version

ENUMERATED

wersja protoko"u (1)

content

CHOICE

typ zapytania (1 – InfoIndicator)

InfoIndicator

CHOICE

identity

INTEGER

alarmID

AlarmID

rodzaj zapytania (2 - AlarmIndicator) numer pozwalaj"cy na jednoznaczn" identyfikacje alarmu razem z timestamp-on AlarmID jest typu ENUMERATED. Numery opisuja przyczyn% alarmu 1)

description

PrintableString

Dodatkowy, opcjonalny opis b"%du, np. kod b"%du z MSC

timestamp

TimeStamp

Godzina i data wys"ania alarmu

Timestamp-on

TimeStamp

Czas wyst#pienia zdarzenia obj%tego alarmem

Timestamp-off

TimeStamp

Czas wyst#pienia zdarzenia odwrotnego do obj%tego alarmem

status

Typ AlarmStatus mówi o aktywno&ci alarmu i jest ENUMERATED (0-off, 1-on)

range-of-alarm

AlarmStatus Nature-of-TheIntercepted-call NetPart Type

targettype

ENUMERATED

liid

OCTET STRING

nature-of-alarm

Ten typ jest ENUMERATED i wskazuje na rodzaje b"%dnych transakcji2) Wskazuje na przyczyn% problemu po stronie CN. 0-whole, 2- part Wskazuje na konkretn# sesj% dla konkretnego LIID lub wszystkie obserwacje. 1-all, 2-specific format: LEAID+TARGET (SEQ), 17 znaków ASCII

cid

UTF8String

Zgodnie z HI2 wskazuje na konkretna sesj% lub rozmow%

cid-GPRS

OCTET STRING

Zgodnie z HI2 wskazanie na konkretna sesj%

1)

alarmID 0 - przepe"nienie bufora w kierunku LEMF (IRI i/lub CC tracone) 1 - problem z monitoringiem online 2 - problem z zapisywaniem danych HI3 (LEMF) 3 - problem z zapisywaniem danych HI2 (LEMF) 4 - problem z monitoringiem online (LEMF) 5 - brak lub przeci#$enie komunikacji z CN na interfejsie HI1 (SM operatora) 6 - brak lub przeci#$enie komunikacji z CN na interfejsie HI2 (SM operatora) 7 - brak lub przeci#$enie komunikacji z CN na interfejsie HI3 (SM operatora) 8 - brak lub przeci#$enie komunikacji z CN na interfejsie HI3 on-line (SM operatora) 9 - powa$ne uszkodzenie SM => konieczne sprawdzenie spójno&ci BD (SM operatora) 10 - zarz#dzanie obserwacjami prawid"owe, ale inne funkcje SM mog# nie dzia"a) (np. cz%&) obserwacji stracona) (SM operatora) 11 - obserwacja nie za"o$ona w CN a czas na ni# (LIID obowi#zkowy) (SM operatora) 12 - obserwacja nie usunieta z CN a czas na ni# (LIID obowi#zkowy) (SM operatora)

5

13 - po stronie CN LI ca"kowicie nie funkcjonowa"o, BD obserwacji odbudowane w CN (SM operatora) 14 - po stronie CN pewne funkcje LI nie dzia"a"y (SM operatora) 15 - informacja wprowadzana r%cznie: uszkodzenie w CN lub SM (SM operatora) 20 - informacja wprowadzana r%cznie o pracach planowych w systemie SM operatora (SM operatora) … 2)

nature-of-alarm 0 - the possible UUS content is sent through the HI2 or HI3 "data" interface - the possible call content is established through the HI3 "circuit" interface 1 - the SMS content is sent through the HI2 or HI3 "data" interface 2 - the UUS content is sent through the HI2 or HI3 "data" interface 3 - the possible call content call is established through the HI3 "circuit" interface - the possible data are sent through the HI3 "data" interface 4 - the data are sent through the HI3 "data" interface 5 - the data are sent through the HI3 "data" interface 6 - the possible call content call is established through the HI3 "circuit" interface - the possible data are sent through the HI3 "data" interface 11 - wIFI Notification

Notification – jest wiadomo&ci# umo$liwiaj#c# stronie ADMF poinformowanie LEMF o faktycznym czasie rozpocz%cia i zako'czeniu obserwacji w sieci operatora. NOTIFICATION PARAMETR

TYP POLA DANYCH

OPIS

version

ENUMERATED

wersja protoko"u (1)

content

CHOICE

typ zapytania (1 – InfoIndicator)

InfoIndicator

CHOICE

identity

INTEGER

notyficationID

NotyficationID

description

PrintableString

rodzaj zapytania (3 - NotificationIndicator) numer pozwalaj"cy (razem z timestamp-on) na jednoznaczn" identyfikacje notyfikacji Typ ENUMERATED: target-activated (0), target-deactivated (1), target-modificated (2),… Dodatkowy, opcjonalny opis notyfikacji

timestamp

TimeStamp

Godzina i data wys"ania notyfikacji

TimestampEvent

TimeStamp

Czas wyst#pienia zdarzenia, którego dotyczy powiadomienie

liid

OCTET STRING

format: LEAID+TARGET (SEQ), 17 znaków ASCII

Action acknowledge

Odpowied! ze strony LEMF na wiadomo&ci: Hello, Alarm, Notyfikacja. 6

ACTION_ACK PARAMETR

TYP POLA DANYCH

OPIS

version

ENUMERATED

wersja protoko"u (1)

respond

CHOICE

typ odpowiedzi (1 – generalRespond)

result

ENUMERATED

message

UTF8String

wynik operacji 4) Je&li odpowiada na Hello zwraca ten sam tekst który wys"any by" w wiadomo&ci hello

4)

result 1 – ok 2 – missing-parametr 3 – unknown-parametr 4 – unknown-parameter value 5 – incorrect-BER 6 – badSignature 7 – certificateExpired 10 – unknownError

Szczegó"owa definicja interfejsów HI. Specyfikacja ASN.1. Kodowanie BER.

1. HI1LEMFPDU HI1LEMFOperations DEFINITIONS AUTOMATIC TAGS ::= BEGIN IMPORTS LawfulInterceptionIdentifier, TimeStamp FROM UnsignedRequestDetail; HI1LEMFPDU ::= SEQUENCE { version [0] Version, content [1] Content, ... }

7

Version ::= ENUMERATED { version1 (1), ... } Content ::= CHOICE { request [1] Request, respond [2] Respond, ... } SignedRequest ::= SEQUENCE { version [1] SignedRequestVersion, signStandard [2] OBJECT IDENTIFIER, -- CryptographicMessageSyntax2004 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) cmsDERSignedRequest

[3] OCTET STRING,

-- cmsDERSignedRequest [3] ANY DEFINED BY signStandard ... } Request ::= CHOICE { simpleRequest [1] SimpleRequest, signedRequest [2] SignedRequest, ... } SimpleRequest ::= CHOICE { helloRequest [1] HelloRequest, listRequest [2] ListRequest, ... } SignedRequestVersion ::= ENUMERATED { v1 (0), ... } HelloRequest ::= SEQUENCE { message [1] UTF8String,

8

... } Respond ::= CHOICE { generalRespond [1] GeneralRespond, listRespond [2] ListRespond, ... } GeneralRespond ::= SEQUENCE { result [1] Result, message [2] UTF8String OPTIONAL, -- return Hello request message ... } Result ::= ENUMERATED { ok (1), missing-parameter (2), unknown-parameter (3), unknown-parameter-value (4), incorrect-BER (5), badSignature (6), certificateExpired (7), unknownError (10), unsupportedService (11), ... }CheckRespond ::= SEQUENCE { liid [1] LawfulInterceptionIdentifier, checkStatus [2] CheckStatus, message [3] UTF8String OPTIONAL, ... } CheckStatus ::= ENUMERATED { notFound (0), waiting (1),

-- za!o"one przez lemf, nie ma w cn (czeka na zatwierdzenie lub )

cnActivated (2), -- jest w cn unknown (3), deActivated (4), -- po deaktywowaniu w cn ...

9

} ListRequest ::= SEQUENCE { type [1] ListType, liid [2] LawfulInterceptionIdentifier OPTIONAL, ... } ListRespond ::= SET OF CheckRespond ListType ::= ENUMERATED { all (1), specific (2), ... } END

2. UnsignedRequestDetail UnsignedRequestDetail DEFINITIONS AUTOMATIC TAGS ::= BEGIN UnsignedRequestDetail ::= SEQUENCE { time [1] TimeStamp, command [2] Command, ... } Command ::= CHOICE { activate [1] Activate, deactivate [2] Deactivate, modificate [3] Modificate, ... } Activate ::= SEQUENCE { lawfulInterceptionIdentifier [1] LawfulInterceptionIdentifier, startTimestamp [2] TimeStamp, stopTimestap [3] TimeStamp,

10

service [4] Service, warrantID [5] UTF8String, ... } Modificate ::= SEQUENCE { lawfulInterceptionIdentifier [1] LawfulInterceptionIdentifier, stopTimestap [3] TimeStamp, service [4] Service, warrantID [5] UTF8String, -- w strukturze service dopuszczalna jest tylko zmiana tyou monitorowania z online na offlien ... } Deactivate ::= SEQUENCE { lawfulInterceptionIdentifier [1] LawfulInterceptionIdentifier, warrantID [5] UTF8String OPTIONAL, ... } Service ::= CHOICE { circuitSwitched [1] CircuitSwitched, packetSwitched [2] PacketSwitched, wifi [3] WIFI, xdsl [4] XDSL, ... }CircuitSwitched ::= SEQUENCE { target [1] Target, monitoringType [2] MonitoringType, onlineMonitoring [3] BOOLEAN, -- offline - zawsze, -- online - jak b#dzie ustawiony parametr forwardingAddress to oznacza online forwardingAddress [4] ForwardingAddress OPTIONAL, -- tylko jak ustawiony parametr nolineMonitoring = true stereo [5] Stereo, ... } Stereo ::= ENUMERATED { off (0),

11

on (1) } PacketSwitched ::= SEQUENCE { target [1] Target, monitoringType [2] MonitoringType, ... } WIFI ::= SEQUENCE { target [1] Target, ... } XDSL ::= SEQUENCE { target [1] Target, ... } Target ::= CHOICE { mSISDN [1] MSISDN, iMSI [2] IMSI, iMEI [3] IMEI, login [4] Login, ... } MSISDN ::= OCTET STRING (SIZE (1..9)) IMSI ::= OCTET STRING (SIZE (3..8)) IMEI ::= OCTET STRING (SIZE (8)) Login ::= OCTET STRING (SIZE (1..120)) ForwardingAddress ::= SEQUENCE { sipUrl [1] SIPURL, ... } SIPURL ::= UTF8String MonitoringType ::= ENUMERATED { iri (1),

12

iriCC (2), ... } LawfulInterceptionIdentifier ::= OCTET STRING (SIZE (1..25)) -- It is recommended to use ASCII characters in "a"…"z", "A"…"Z", "-", "_", ".", and "0"…"9". -- For subaddress option only "0"..."9" shall be used. -- 17 znakow numerycznych ASCII -- format: LEAID + TARGET(SEQ) -- TARGET - (15 znakow) nadawany sekwencyjnie dla kazdego LEAID -- LEAID -(2 znaki) 00 – LEMF operatora, 01 - ABW, 02 - Policja, 03 - CB$, 04 - SG, 05 CBA, 06 - SKW TimeStamp ::= CHOICE { -- The minimum resolution required is one second. -- "Resolution" is the smallest incremental change that can be measured for time and -- is expressed with a definite number of decimal digits or bits. localTime [0] LocalTimeStamp, utcTime [1] UTCTime } LocalTimeStamp ::= SEQUENCE { generalizedTime [0] GeneralizedTime, -- The minimum resolution required is one second. -- "Resolution" is the smallest incremental change that can be measured for time and -- is expressed with a definite number of decimal digits or bits. winterSummerIndication [1] ENUMERATED { notProvided(0), winterTime(1), summerTime(2), ... } } END

3. HI1ADMFPDU HI1ADMFOperations DEFINITIONS AUTOMATIC TAGS ::= BEGIN

13

IMPORTS LawfulInterceptionIdentifier, TimeStamp FROM UnsignedRequestDetail; HI1ADMFPDU ::= SEQUENCE { version [0] Version, content [1] Content } Version ::= ENUMERATED { version1 (1), ... } Content ::= CHOICE { info [0] InfoIndicator, acknowledge [1] Acknowledge, ... } InfoIndicator ::= CHOICE { helloRequest [1] HelloRequest, alarm

[2] AlarmIndicator,

notification [3] NotificationIndicator, ... } HelloRequest ::= SEQUENCE { message [1] UTF8String, ... } AlarmIndicator ::= SEQUENCE { identity [0] INTEGER,

-- numer pozwalaj%cy na jednoznaczn% identyfikacje alarmu

razem z timestamp-on alarmID

[1] AlarmID,

description [2] UTF8String OPTIONAL,

-- dodatkowe informacje, opis, kod b!#du (np. z

alarmu z MSC), tzw. powód timestamp

[3] TimeStamp,

-- czas wys!ania alarmu

14

timestamp-on [4] TimeStamp OPTIONAL,

-- czas wyst%pienia

alarmowanego zdarzenia timestamp-off [5] TimeStamp OPTIONAL,

-- czas wyst%pienia zdarzenia

odwrotnego do zdarzenia alarmowanego status [6] AlarmStatus OPTIONAL,

-- powstanie/ustanie alarmu

-- podobne nature-Of-The-intercepted-call z HI2 (je"eli b!%d globalny to wszystkie service) nature-of-alarm

[7] Nature-Of-The-intercepted-call OPTIONAL,

range-of-alarm [8] NetPartType OPTIONAL,

-- dotyczy ca!ej sieci CN czy tylko jej

cz#&ci (np.: tylko jeden GGSN, jedna centrala) targettype [9] TargetType OPTIONAL,

-- dotyczy konkretnego LIID lub konkretnej

sesji albo wszystkich obserwacji liid [10] LawfulInterceptionIdentifier OPTIONAL, cid [11] UTF8String OPTIONAL,

-- z HI2 (chodzi o wskazanie konkretnej rozmowy

lub sesji) cid-GPRS [12] GPRSCorrelationNumber OPTIONAL,

-- z HI2 (chodzi o wskazanie

konkretnej rozmowy lub sesji) ... } Nature-Of-The-intercepted-call ::= ENUMERATED { -- Nature of the intercepted "call": gSM-ISDN-PSTN-circuit-call(0), -- the possible UUS content is sent through the HI2 or HI3 "data" interface -- the possible call content call is established through the HI3 "circuit" interface gSM-SMS-Message(1), -- the SMS content is sent through the HI2 or HI3 "data" interface uUS4-Messages(2), -- the UUS content is sent through the HI2 or HI3 "data" interface tETRA-circuit-call(3), -- the possible call content call is established through the HI3 "circuit" interface -- the possible data are sent through the HI3 "data" interface teTRA-Packet-Data(4), -- the data are sent through the HI3 "data" interface gPRS-Packet-Data(5), -- the data are sent through the HI3 "data" interface uMTS-circuit-call(6), -- the possible call content call is established through the HI3 "circuit" interface -- the possible data are sent through the HI3 "data" interface wIFI (11), xDSL [12], ... } NotificationIndicator ::= SEQUENCE

15

{ identity [0] INTEGER,

-- numer pozwalaj%cy na jednoznaczn%

identyfikacje alarmu razem z timestamp-on notificationID [1] NotificationID, description [2] UTF8String OPTIONAL,

-- dodatkowe informacje, opis, kod b!#du

(np. z MSC), tzw. powód timestamp [3] TimeStamp,

-- czas wys!ania powiadomienia

timestampEvent [4] TimeStamp,

-- czas wyst%pienia zdarzenia, którego

dotyczy powiadomienie liid [5] LawfulInterceptionIdentifier OPTIONAL, ... } AlarmID ::= ENUMERATED { sm-buffer-overflow (0),

-- bufory wyj&ciowe w kierunku LEMF

przepe!nine => IRI i/lub CC tracone (operator) lemf-hi3-online-delivery-failure (1),

-- problem z monitoringiem online (LEMF)

lemf-hi3-delivery-failure (2),

-- problem z zapisywaniem danych HI3 (LEMF)

lemf-hi2-delivery-failure (3),

-- problem z zapisywaniem danych HI2 (LEMF)

lemf-hi1-delivery-failure (4),

-- problem z monitoringiem online (LEMF)

sm-hi1-failure (5),

-- brak lub przeci%"enie komunikacji z CN na

interfejsie HI1 (SM operatora) sm-hi2-failure (6),

-- brak lub przeci%"enie komunikacji z CN na

interfejsie HI2 (SM operatora) sm-hi3-failure (7),

-- brak lub przeci%"enie komunikacji z CN na

interfejsie HI3 (SM operatora) sm-hi3-online-failure (8),

-- brak lub przeci%"enie komunikacji z CN na

interfejsie HI3 (SM operatora) major-system-failure (9),

-- powa"ne uszkodzenie SM => konieczne

sprawdzenie spójno&ci BD (SM operatora) -- zarz%dzanie obserwacjami prawid!owe, ale inne funkcje SM mog% nie dzia!a' (np. cz#&' obserwacji stracona) (SM operatora) minor-system-failure (10), cn-activation-error (11),

-- obserwacja nie za!o"ona w CN a czas na ni%

(LIID obowi%zkowy) (SM operatora) cn-deactivation-error

(12),

-- obserwacja nie usunieta z CN a czas na ni%

(LIID obowi%zkowy) (SM operatora) major-cn-li-failure (13),

-- po stronie CN LI ca!kowicie nie funkcjonowa!o,

BD obserwacji odbudowane w CN (SM operatora) minor-cn-li-failure (14),

-- po stronie CN pewne funkcje LI nie dzia!a!y

(SM operatora) manual-system-failure (15),

-- informacja wprowadzana r#cznie: uszkodzenie w

CN lub SM (SM operatora) manual-system-maintenance (20),

-- informacja wprowadzana r#cznie o pracach

planowych w systemie SM operatora (SM operatora)

16

... } AlarmStatus ::= ENUMERATED { off (0), on (1), ... } NetPartType ::= ENUMERATED { whole (1), part (2), ... } TargetType ::= ENUMERATED { all (1), specific (2), ... } NotificationID ::= ENUMERATED { target-activated (0), target-deactivated (1), target-modificated (2), ... } Acknowledge ::= CHOICE { respond

[0] GeneralRespond,

... } GeneralRespond ::= SEQUENCE { result

[1] Result,

message

[2] UTF8String OPTIONAL,

... } Result ::= ENUMERATED {

17

ok (1), missing-parameter (2), unknown-parameter (3), unknown-parameter-value (4), incorrect-BER (5), badSignature (6), certificateExpired (7), unknownError (10), ... } GPRSCorrelationNumber ::= OCTET STRING (SIZE(8..20)) END

10/34si

18

Za#"cznik nr 2

Specyfikacja techniczna styku HI-2 interfejsu HI

1. Warstwa fizyczna

Warstwa fizyczna ma znaczenie lokalne pomi$dzy dwoma urz"dzeniami sieciowymi i ma znaczenie tylko na styku systemów miedzy operatorem a uprawnionym podmiotem. 2.Warstwa sieciowa

Dla ka°o podmiotu uprawnionego okre!lone s" dedykowane adresy publiczne IPv4 dla DF (HI2). S#u&by okre!laj" adresacj$ publiczn" IPv4 po swojej stronie. Adresy IP nie mog" by' takie same dla wszystkich operatorów w danym systemie LEMF, jak i nie mog" by' takie same dla uprawnionych podmiotów w danym systemie ADMF/DF. 3. Warstwa transportowa

Stosowany jest protokó# FTP (RFC 959), Po#"czenie jest nawi"zywane tylko w kierunku MF ) LEMF Wykorzystywany jest tylko tryb passive protoko#u FTP, Serwer FTP po stronie LEMF nas#uchuje na portach )#20 (data connection), )#21 (control connection), Protokól FTP zostaje ograniczony do nast$puj"cych komend: )#USER NAME (USER), )#PASSWORD (PASS), )#DATA PORT (PORT), )#PASSIVE (PASV), )#REPRESENTATION TYPE (TYPE) - ASCII Non-print, )#FILE STRUCTURE (STRU) - File, )#TRANSFER MODE (MODE) - Stream, )#STORE (STOR), )#RENAME FROM (RNFR), )#RENAME TO (RNTO), )#ABORT (ABOR), )#CHANGE WORKING DIRECTORY (CWD), )#PRINT WORKING DIRECTORY (PWD),

)#NOOP (NOOP), )#LOGOUT (QUIT). Nazwa przesy#anego pliku jest zmieniana na docelow" po udanym nagraniu; plik tymczasowy posiada dodatkowe rozszerzenie .tmp (LIID_seq.ext_tmp), Nazwa pliku po przes#aniu sk#ada si$ z LIID i numeru sekwencyjnego (LIID_seq.ext), Zawarto!' pliku czyli dane IRI kodowanie s" w formacie ASN.1/BER. 4. Warstwa aplikacyjna

Dla us#ug CS oraz PS interfejs zosta# opracowany na podstawie specyfikacji ETSI TS 101 671 wersja 2.13.1 (rozdzia#y 5.2, 8). W dokumencie znajduje si$ szczegó#owy opis interfejsu HI2 oraz jego definicje w ASN.1. Dla us#ug zawieraj"cych si$ w IPAccess (WiFi-WLAN, xDSL) interfejs w pe#ni zgodny jest ze specyfikacj" ETSI TS 102 232-1 wersja 2.2.1 oraz TS 102 232-3 wersja 2.1.1. W dokumencie znajduje si$ szczegó#owy opis specyfikacji interfejsu HI2 oraz jego definicje w ASN.1. Nie stosujemy mechanizmu ROSE tzn. przesy#ania danych IRI przy u&yciu protoko#ów transportowych, tj. TCP, UDP Dla wszystkich us#ug rekordy IRI przekazywane s" w plikach przy u&yciu protoko#u FTP. Przesy#any plik mo&e zawiera' wiele pojedy%czych rekordów IRI zakodowanych w standardzie ASN1/BER. Warto!ci parametrów IRI nale&y definiowa' w formatach zalecanych przez standardy telekomunikacyjne, które ich dotycz" (np. ISDN user part, DSS1, MAP czy IP) W przypadku interfejsu HI2 przez warstw$ aplikacyjn" nale&y rozumie' kodowanie zawarto!ci plików, a nie protokó# FTP u&yty do ich transportu. Interfejs nie wymaga stosowania podpisu elektronicznego. 4.1 Zmiany w stosunku do specyfikacji ETSI

Dla wszystkich obs#ugiwanych us#ug wprowadzono nowy typ PartyExtendedIdentity rozszerzaj"cy parametry IRI o dane personalne abonentów uczestnicz"cych w przekazie informacji. PartyInformation ::= SEQUENCE { ... partyExtendedIdentity [PRIVATE 1] PartyExtendedIdentity OPTIONAL, ... } PartyExtendedIdentity ::= SEQUENCE { subscriptionType [1] ENUMERATED { postpaid (0), prepaid (1), ... } OPTIONAL, activationDate [2] TimeStamp OPTIONAL, deactivationDate [3] TimeStamp OPTIONAL, 2

}

subscriber [4] Subscriber OPTIONAL, postalAddress [5] PostalAddress OPTIONAL, mailAddress [6] PostalAddress OPTIONAL, ...

Subscriber ::= CHOICE { company [1] Company, person [2] Person, ... } Company ::= SEQUENCE { name [0] UTF8String, regon [1] OCTET STRING (SIZE (5)), -- BCD coded 9 digits -- F digit not used ... } Person ::= SEQUENCE { firstName [0] UTF8String, surname [1] UTF8String, pesel [2] OCTET STRING (SIZE (6)) OPTIONAL, -- BCD coded 11 digits -- F digit not used passportNumber [3] OCTET STRING (SIZE (7..14)) OPTIONAL, -- ASCII coded ... } PostalAddress ::= SEQUENCE { street [1] UTF8String OPTIONAL, buildingNumber [2] OCTET STRING (SIZE (1..10)) OPTIONAL, -- ASCII coded: 10 char apartmentNumber [3] OCTET STRING (SIZE (1..10)) OPTIONAL, -- ASCII coded: 10 char postcode [4] OCTET STRING (SIZE (1..8)) OPTIONAL, city [5] UTF8String OPTIONAL, country [6] UTF8String OPTIONAL } 5. Us"ugi CS i PS

Niewykorzystywane parametry: )#iRISequence typu IRISequence w strukturze IRIsContent (brak mo&liwo!ci agregacji rekordów IRI w strukturze ASN.1) 3

)#ringingDuration w strukturze IRI-Parameters )#conversationDuration w strukturze IRI-Parameters (czas rozmowy mo&na wyznaczy' w inny sposób) )#callContentLinkInformation w strukturze IRI-Parameters (brak danej funkcjonalno!ci) )#cC-Link-Identifier w w strukturze IRI-Parameters )#national-Parameters )#network-Element-Identifier w strukurze Network-Identifier 6.Us"ugi IPAccess (WLAN, xDSL)

W przypadku wspomnianych us#ug specyfikacja zgodna jest w pe#ni ze standardami ETSI TS 102 232-1 oraz TS 102 232-3. Jedynym dodatkiem jest wyspecyfikowane ju& pole PartyExtendedIdentity. Szczegó"owa specyfikacja HI2 HI2Operations {itu-t(0) identified-organization(4) etsi(0) securityDomain(2) lawfulIntercept(2) hi2(1) version9(9)} DEFINITIONS IMPLICIT TAGS ::= BEGIN -- ============================= -- Object Identifier Definitions -- ============================= -- LawfulIntercept DomainId lawfulInterceptDomainId OBJECT IDENTIFIER ::= {itu-t(0) identified-organization(4) etsi(0) securityDomain(2) lawfulIntercept(2)} -- Security Subdomains hi2DomainId OBJECT IDENTIFIER ::= {lawfulInterceptDomainId hi2(1)} hi2OperationId OBJECT IDENTIFIER ::= {hi2DomainId version9(9)} IRIsContent ::= CHOICE { iRIContent IRIContent, iRISequence IRISequence -- NOT USED } IRISequence ::= SEQUENCE OF IRIContent -- NOT USED -- Aggregation of IRIContent is an optional feature.

4

-- It may be applied in cases when at a given point in time several IRI records are -- available for delivery to the same LEA destination. -- As a general rule, records created at any event shall be sent immediately and shall -- not held in the DF or MF in order to apply aggregation. -- When aggregation is not to be applied, IRIContent needs to be chosen. IRIContent ::= CHOICE { iRI-Begin-record [1] IRI-Parameters, -- At least one optional parameter must be included within the iRI-Begin-Record. iRI-End-record [2] IRI-Parameters, iRI-Continue-record [3] IRI-Parameters, -- At least one optional parameter must be included within the iRI-Continue-Record. iRI-Report-record [4] IRI-Parameters, -- At least one optional parameter must be included within the iRI-Report-Record. ... } IRI-Parameters ::= SEQUENCE { domainID [0] OBJECT IDENTIFIER (hi2OperationId) OPTIONAL, -- for the sending entity the inclusion of the Object Identifier is mandatory iRIversion [23] ENUMERATED { version2(2), ..., version3(3), version4(4), version5(5), version6(6), version7(7), lastVersion(8) } OPTIONAL, -- Optional parameter "iRIversion" (tag 23) is redundant starting from TS 101 671 v2.4.1 -- where to the object identifier "domainID" was introduced into IRI-Parameters. -- In order to keep backward compatibility, even when the version of the "domainID" -- parameter will be incremented it is recommended to always send to LEMF the same: -- enumeration value "lastVersion(8)". -- if not present, it means version 1 is handled lawfulInterceptionIdentifier [1] LawfulInterceptionIdentifier, -- This identifier is associated to the target. communicationIdentifier [2] CommunicationIdentifier,

5

-- used to uniquely identify an intercepted call. -- Called "callIdentifier" in Edition 1 of ES 201 671. timeStamp [3] TimeStamp, -- date and time of the event triggering the report. intercepted-Call-Direct [4] ENUMERATED { not-Available(0), originating-Target(1), -- In case of GPRS, this indicates that the PDP context activation, modification -- or deactivation is MS requested. terminating-Target(2), -- In case of GPRS, this indicates that the PDP context activation, modification -- or deactivation is network initiated. ... } OPTIONAL, intercepted-Call-State [5] Intercepted-Call-State OPTIONAL, ringingDuration [6] OCTET STRING (SIZE (3)) OPTIONAL, -- NOT USED -- Duration in seconds. BCD coded : HHMMSS conversationDuration [7] OCTET STRING (SIZE (3)) OPTIONAL, -- NOT USED -- Duration in seconds. BCD coded : HHMMSS locationOfTheTarget [8] Location OPTIONAL, -- location of the target subscriber partyInformation [9] SET SIZE (1..10) OF PartyInformation OPTIONAL, -- This parameter provides the concerned party (Originating, Terminating or forwarded -- party), the identity(ies) of the party and all the information provided by the party. callContentLinkInformation [10] SEQUENCE { cCLink1Characteristics [1] CallContentLinkCharacteristics OPTIONAL, -- Information concerning the Content of Communication Link Tx channel established -- toward the LEMF (or the sum signal channel, in case of mono mode). cCLink2Characteristics [2] CallContentLinkCharacteristics OPTIONAL, -- Information concerning the Content of Communication Link Rx channel established -- toward the LEMF. ... } OPTIONAL, -- NOT USED

6

release-Reason-Of-Intercepted-Call [11] OCTET STRING (SIZE (2)) OPTIONAL, -- Release cause coded in ITU-T Q.850 [31] format. -- This parameter indicates the reason why the intercepted call cannot be established or -- why the intercepted call has been released after the active phase. nature-Of-The-intercepted-call [12] ENUMERATED { -- Nature of the intercepted "call": gSM-ISDN-PSTN-circuit-call(0), -- the possible UUS content is sent through the HI2 or HI3 "data" interface -- the possible call content call is established through the HI3 "circuit" interface gSM-SMS-Message(1), -- the SMS content is sent through the HI2 or HI3 "data" interface uUS4-Messages(2), -- the UUS content is sent through the HI2 or HI3 "data" interface tETRA-circuit-call(3), -- the possible call content call is established through the HI3 "circuit" interface -- the possible data are sent through the HI3 "data" interface teTRA-Packet-Data(4), -- the data are sent through the HI3 "data" interface gPRS-Packet-Data(5), -- the data are sent through the HI3 "data" interface ..., uMTS-circuit-call(6) -- the possible call content call is established through the HI3 "circuit" interface -- the possible data are sent through the HI3 "data" interface } OPTIONAL, serverCenterAddress [13] PartyInformation OPTIONAL, -- e.g. in case of SMS message this parameter provides the address of the relevant -- server within the calling (if server is originating) or called -- (if server is terminating) party address parameters sMS [14] SMS-report OPTIONAL, -- this parameter provides the SMS content and associated information cC-Link-Identifier [15] CC-Link-Identifier OPTIONAL, -- NOT USED -- Depending on a network option, this parameter may be used to identify a CC link -- in case of multiparty calls. national-Parameters [16] National-Parameters OPTIONAL, -- NOT USED gPRSCorrelationNumber [18] GPRSCorrelationNumber OPTIONAL, gPRSevent [20] GPRSEvent OPTIONAL,

7

-- This information is used to provide particular action of the target -- such as attach/detach sgsnAddress [21] DataNodeAddress OPTIONAL, gPRSOperationErrorCode [22] GPRSOperationErrorCode OPTIONAL, ..., ggsnAddress [24] DataNodeAddress OPTIONAL, qOS [25] UmtsQos OPTIONAL, -- This parameter is duplicated from TS 133 108 [61]. networkIdentifier [26] Network-Identifier OPTIONAL, -- This parameter is duplicated from TS 133 108 [61]. sMSOriginatingAddress [27] DataNodeAddress OPTIONAL, -- This parameter is duplicated from TS 133 108 [61]. sMSTerminatingAddress [28] DataNodeAddress OPTIONAL, -- This parameter is duplicated from TS 133 108 [61]. iMSevent [29] IMSevent OPTIONAL, sIPMessage [30] OCTET STRING OPTIONAL, -- This parameter is duplicated from TS 133 108 [61]. servingSGSN-number [31] OCTET STRING (SIZE (1..20)) OPTIONAL, -- This parameter is duplicated from TS 133 108 [61]. servingSGSN-address [32] OCTET STRING (SIZE (5..17)) OPTIONAL, -- Octets are coded according to TS 123 003 -- This parameter is duplicated from TS 133 108 [61]. -- tARGETACTIVITYMONITOR [33] TARGETACTIVITYMONITOR OPTIONAL, -- to be included after publication of the AT-D specification -- Parameter is used in TS 101 909-20-1 [69] ldiEvent [34] LDIevent OPTIONAL, -- The "Location Dependent Interception" parameter is duplicated from TS 133 108 [61]. correlation [35] CorrelationValues OPTIONAL, -- This parameter is duplicated from TS 133 108 [61] national-HI2-ASN1parameters [255] National-HI2-ASN1parameters OPTIONAL } -- ==================

8

-- PARAMETERS FORMATS -- ================== CommunicationIdentifier ::= SEQUENCE { communication-Identity-Number [0] OCTET STRING (SIZE (1..8)) OPTIONAL, -- Temporary Identifier of an intercepted call to uniquely identify an intercepted call. -- This parameter is mandatory if there is associated -- information sent over HI3interface (CClink, data,..) or when -- CommunicationIdentifier is used for IRI other than IRI-Report-record -- This parameter was called "call-Identity-Number" in Edition 1 (v1.1.1) ES 201 671. -- The individual digits of the communication-Identity-Number shall be represented in -- ASCII format, e.g. "12345678" = 8 octets 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38. network-Identifier [1] Network-Identifier, ... } -- NOTE: The same "CommunicationIdentifier" value is sent : -- with the HI3 information for correlation purpose between the IRI and the information sent on -- the HI3 interfaces (CCLink, data, ..) with each IRI associated to a same intercepted call -- for correlation purpose between the different IRI. Network-Identifier ::= SEQUENCE { operator-Identifier [0] OCTET STRING (SIZE (1..5)), -- It is a notification of the NWO/AP/SvP in ASCII- characters. -- The parameter is mandatory. -- format: MNC + MVNO network-Element-Identifier [1] Network-Element-Identifier OPTIONAL, -- NOT USED ... } Network-Element-Identifier ::= CHOICE { e164-Format [1] OCTET STRING (SIZE (1..25)), -- E164 address of the node in international format. Coded in the same format as the -- calling party number parameter of the ISUP (parameter part: EN 300 356 [5]). x25-Format [2] OCTET STRING (SIZE (1..25)), -- X25 address iP-Format [3] OCTET STRING (SIZE (1..25)), -- IP address

9

dNS-Format [4] OCTET STRING (SIZE (1..25)), -- DNS address ..., iP-Address [5] IPAddress, ... } CC-Link-Identifier ::= OCTET STRING (SIZE (1..8)) -- Depending on a network option, this parameter may be used to identify a CClink -- in case of multiparty calls. -- The individual digits of the communication-Identity-Number shall be represented in -- ASCII format, e.g. "12345678" = 8 octets 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38. TimeStamp ::= CHOICE { -- The minimum resolution required is one second. -- "Resolution" is the smallest incremental change that can be measured for time and -- is expressed with a definite number of decimal digits or bits. localTime [0] LocalTimeStamp, utcTime [1] UTCTime } LocalTimeStamp ::= SEQUENCE { generalizedTime [0] GeneralizedTime, -- The minimum resolution required is one second. -- "Resolution" is the smallest incremental change that can be measured for time and -- is expressed with a definite number of decimal digits or bits. winterSummerIndication [1] ENUMERATED { notProvided(0), winterTime(1), summerTime(2), ... } } PartyInformation ::= SEQUENCE { party-Qualifier [0] ENUMERATED { originating-Party(0), -- In this case, the partyInformation parameter provides the identities related to -- the originating party and all information provided by this party.

10

-- This parameter provides also all the information concerning the redirecting -- party when a forwarded call reaches a target. terminating-Party(1), -- In this case, the partyInformation parameter provides the identities related to -- the terminating party and all information provided by this party. forwarded-to-Party(2), -- In this case, the partyInformation parameter provides the identities related to -- the forwarded to party and parties beyond this one and all information -- provided by this parties, including the call forwarding reason. gPRS-Target(3), ... }, partyIdentity [1] SEQUENCE { imei [1] OCTET STRING (SIZE (8)) OPTIONAL, -- See MAP format ETS 300 974 [32] tei [2] OCTET STRING (SIZE (1..15)) OPTIONAL, -- ISDN-based Terminal Equipment Identity imsi [3] OCTET STRING (SIZE (3..8)) OPTIONAL, -- See MAP format ETS 300 974 [32] International Mobile -- Station Identity E.212 number beginning with Mobile Country Code callingPartyNumber [4] CallingPartyNumber OPTIONAL, -- The calling party format is used to transmit the identity of a calling party calledPartyNumber [5] CalledPartyNumber OPTIONAL, -- The called party format is used to transmit the identity of a called party or -- a forwarded to party. msISDN [6] OCTET STRING (SIZE (1..9)) OPTIONAL, -- MSISDN of the target, encoded in the same format as the AddressString -- parameters defined in MAP format ETS 300 974 [32], clause 14.7.8. ..., e164-Format [7] OCTET STRING (SIZE (1..25)) OPTIONAL, -- E164 address of the node in international format. Coded in the same format as -- the calling party number parameter of the ISUP (parameter part: EN 300 356 [5]) sip-uri [8] OCTET STRING OPTIONAL, -- Session Initiation Protocol - Uniform Resource Identifier. See RFC 3261 [59]. -- This parameter is duplicated from TS 133 108 [61]. tel-url [9] OCTET STRING OPTIONAL

11

-- See "URLs for Telephone Calls", RFC 3966 [68]. -- This parameter is duplicated from TS 133 108 [61]. }, services-Information [2] Services-Information OPTIONAL, -- This parameter is used to transmit all the information concerning the -- complementary information associated to the basic call supplementary-Services-Information [3] Supplementary-Services OPTIONAL, -- This parameter is used to transmit all the information concerning the -- activation/invocation of supplementary services during a call or out-of call not -- provided by the previous parameters. services-Data-Information [4] Services-Data-Information OPTIONAL, -- This parameter is used to transmit all the information concerning the complementary -- information associated to the basic data call. partyExtendedIdentity [PRIVATE 1] PartyExtendedIdentity OPTIONAL, ... } PartyExtendedIdentity ::= SEQUENCE { subscriptionType [1] ENUMERATED { postpaid (0), prepaid

(1),

... } OPTIONAL, activationDate [2] TimeStamp OPTIONAL, deactivationDate [3] TimeStamp OPTIONAL, subscriber [4] Subscriber OPTIONAL, postalAddress [5] PostalAddress OPTIONAL, mailAddress [6] PostalAddress OPTIONAL, ... } Subscriber ::= CHOICE { company [1] Company, person [2] Person, ... } Company ::= SEQUENCE {

12

name [0] UTF8String, regon

[1] OCTET STRING (SIZE (5)),

-- BCD coded 9 digits -- F digit not used ... } Person ::= SEQUENCE { firstName [0] UTF8String, surname [1] UTF8String, pesel

[2] OCTET STRING (SIZE (6)) OPTIONAL,

-- BCD coded 11 digits -- F digit not used passportNumber [3] OCTET STRING (SIZE (7..14)) OPTIONAL, -- ASCII coded ... } PostalAddress ::= SEQUENCE { street [1] UTF8String OPTIONAL, buildingNumber [2] OCTET STRING (SIZE (1..10)) OPTIONAL, -- ASCII coded: 10 char apartmentNumber [3] OCTET STRING (SIZE (1..10)) OPTIONAL, -- ASCII coded: 10 char postcode [4] OCTET STRING (SIZE (1..8)) OPTIONAL, city [5] UTF8String OPTIONAL, country [6] UTF8String OPTIONAL } CallingPartyNumber ::= CHOICE { iSUP-Format [1] OCTET STRING (SIZE (1..25)), -- Encoded in the same format as the calling party number (parameter field) -- of the ISUP (see EN 300 356 [5]). dSS1-Format [2] OCTET STRING (SIZE (1..25)), -- Encoded in the format defined for the value part of the Calling party number -- information element of DSS1 protocol EN 300 403-1 [6]. -- The DSS1 Information element identifier and the DSS1 length are not included. ..., mAP-Format [3] OCTET STRING (SIZE (1..25)) -- Encoded as AddressString of the MAP protocol ETS 300 974 [32]. }

13

CalledPartyNumber ::= CHOICE { iSUP-Format [1] OCTET STRING (SIZE (1..25)), -- Encoded in the same format as the called party number (parameter field) -- of the ISUP (see EN 300 356 [5]). mAP-Format [2] OCTET STRING (SIZE (1..25)), -- Encoded as AddressString of the MAP protocol ETS 300 974 [32]. dSS1-Format [3] OCTET STRING (SIZE (1..25)), -- Encoded in the format defined for the value part of the Called party number information -- element of DSS1 protocol EN 300 403-1 [6]. -- The DSS1 Information element identifier and the DSS1 length are not included. ... } Location ::= SEQUENCE { e164-Number [1] OCTET STRING (SIZE (1..25)) OPTIONAL, -- Coded in the same format as the ISUP location number (parameter --field) of the ISUP (see EN 300 356 [5]). globalCellID [2] OCTET STRING (SIZE (5..7)) OPTIONAL, -- See MAP format (see ETS 300 974 [32]). -- Refers to Cell Global Identification defined in TS GSM 03.03. -- Octets are coded according to TS GSM 04.08. -- The internal structure is defined as follows: -- Mobile Country Code: 3 digits according to CCITT Rec E.212 -- 1 digit filler (1111) -- Mobile Network Code: 2 digits according to CCITT Rec E.212 -- Location Area Code: 2 octets according to TS GSM 04.08 -- Cell Identity: 2 octets (CI) according to TS GSM 04.08 tetraLocation [3] TetraLocation OPTIONAL, rAI [4] OCTET STRING (SIZE (6)) OPTIONAL, -- The Routeing Area Identifier (RAI) in the current SGSN is coded in accordance with -- TS 124 008 [41] without the Routing Area Identification IEI (only the -- last 6 octets are used). gsmLocation [5] GSMLocation OPTIONAL, umtsLocation [6] UMTSLocation OPTIONAL,

14

sAI [7] OCTET STRING (SIZE (7)) OPTIONAL, -- format: PLMN-ID 3 octets (no. 1-3), -- LAC 2 octets (no. 4-5), -- SAC 2 octets (no. 6-7) -- (according to 3GPP TS 125 431 [62]). oldRAI [8] OCTET STRING (SIZE (6)) OPTIONAL, -- the "Routeing Area Identifier" in the old SGSN is coded in accordance with -- TS 124 008 (41) without the Routing Area Identification IEI -- (only the last 6 octets are used). -- This parameter is duplicated from TS 133 108 [61]. TetraLocation ::= CHOICE { ms-Loc [1] SEQUENCE { mcc [1] INTEGER (0..1023), -- 10 bits EN 300 392-1 [40] mnc [2] INTEGER (0..16383), -- 14 bits EN 300 392-1 [40] lai [3] INTEGER (0..65535), -- 14 bits EN 300 392-1 [40] ci [4] INTEGER OPTIONAL }, -- (to be completed) ls-Loc [2] INTEGER -- (to be confirmed and completed) } GSMLocation ::= CHOICE { geoCoordinates [1] SEQUENCE { latitude [1] PrintableString (SIZE(7..10)), -- format: XDDMMSS.SS longitude [2] PrintableString (SIZE(8..11)), -- format: XDDDMMSS.SS mapDatum [3] MapDatum DEFAULT wGS84, ..., azimuth [4] INTEGER (0..359) OPTIONAL -- The azimuth is the bearing, relative to true north. }, -- format: XDDDMMSS.SS

15

-- X : N(orth), S(outh), E(ast), W(est) -- DD or DDD : degrees (numeric characters) -- MM : minutes (numeric characters) -- SS.SS : seconds, the second part (.SS) is optional -- Example: -- latitude short form N502312 -- longitude long form E1122312.18 utmCoordinates [2] SEQUENCE { utm-East [1] PrintableString (SIZE(10)), utm-North [2] PrintableString (SIZE(7)), -- Universal Transverse Mercator -- example utm-East 32U0439955 -- utm-North 5540736 mapDatum [3] MapDatum DEFAULT wGS84, ..., azimuth [4] INTEGER (0..359) OPTIONAL -- The azimuth is the bearing, relative to true north. }, utmRefCoordinates [3] SEQUENCE { utmref-string PrintableString (SIZE(13)), mapDatum MapDatum DEFAULT wGS84, ... }, -- example 32UPU91294045 wGS84Coordinates [4] OCTET STRING -- format is as defined in TS 101 109 [57]; polygon type of shape is not allowed. } MapDatum ::= ENUMERATED { wGS84, -- World Geodetic System 1984 wGS72, eD50, -- European Datum 50 ... } UMTSLocation ::= CHOICE

16

{ point [1] GA-Point, pointWithUnCertainty [2] GA-PointWithUnCertainty, polygon [3] GA-Polygon, ... } GeographicalCoordinates ::= SEQUENCE { latitudeSign ENUMERATED { north, south }, latitude INTEGER (0..8388607), longitude INTEGER (-8388608..8388607), ... } GA-Point ::= SEQUENCE { geographicalCoordinates GeographicalCoordinates, ... } GA-PointWithUnCertainty ::=SEQUENCE { geographicalCoordinates GeographicalCoordinates, uncertaintyCode INTEGER (0..127) } maxNrOfPoints INTEGER ::= 15 GA-Polygon ::= SEQUENCE (SIZE (1..maxNrOfPoints)) OF SEQUENCE { geographicalCoordinates GeographicalCoordinates, ... } CallContentLinkCharacteristics ::= SEQUENCE {

17

cCLink-State [1] CCLink-State OPTIONAL, -- current state of the CCLink release-Time [2] TimeStamp OPTIONAL, -- date and time of the release of the Call Content Link. release-Reason [3] OCTET STRING (SIZE(2)) OPTIONAL, -- Release cause coded in Q.850 [31] format. lEMF-Address [4] CalledPartyNumber OPTIONAL, -- Directory number used to route the call toward the LEMF. ... } CCLink-State ::= ENUMERATED { setUpInProcess(1), -- The set-up of the call is in process. callActive(2), callReleased(3), lack-of-resource(4), -- The lack-of-resource state is sent when a CC Link cannot -- be established because of lack of resource at the MF level. ... } Intercepted-Call-State ::= ENUMERATED { idle(1), -- When the intercept call is released, the state is IDLE and the reason is provided -- by the release-Reason-Of-Intercepted-Call parameter. setUpInProcess(2), -- The set-up of the call is in process. connected(3), -- The answer has been received. ... } Services-Information ::= SEQUENCE { iSUP-parameters [1] ISUP-parameters OPTIONAL, dSS1-parameters-codeset-0 [2] DSS1-parameters-codeset-0 OPTIONAL, ..., mAP-parameters [3] MAP-parameters OPTIONAL }

18

ISUP-parameters ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) -- Each "OCTET STRING" contains one additional ISUP parameter TLV coded not already defined in -- the previous parameters. The Tag value is the one given in EN 300 356 [5]. -- In version 1 of the present document "iSUP-parameters" is defined as mandatory. -- It might occur that no ISUP parameter is available. In that case in a version 1 -- implementation the value "zero" may be included in the first octet string of the SET. -- The Length and the Value are coded in accordance with the parameter definition in -- EN 300 356 [5]. Hereafter are listed the main parameters. -- However other parameters may be added: -- Transmission medium requirement: format defined in EN 300 356 [5]. -- This parameter can be provided with the "Party Information" of the "calling party". -- Transmission medium requirement prime: format defined in EN 300 356 [5]. -- This parameter can be provided with the "Party Information" of the "calling party". DSS1-parameters-codeset-0 ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) -- Each "OCTET STRING" contains one DSS1 parameter of the codeset-0. The parameter is coded as -- described in EN 300 403-1 [6] (The DSS1 Information element identifier and the DSS1 length -- are included). Hereafter are listed the main parameters -- (However other parameters may be added): -- Bearer capability: this parameter may be repeated. Format defined in EN 300 403-1 [6]. -- This parameter can be provided with the "Party Information" of the "calling party", -- "called party" or "forwarded to party". -- High Layer Compatibility: this parameter may be repeated. Format defined in EN 300 403-1 [6] -- This parameter can be provided with the "Party Information" of the "calling party", -- "called party" or "forwarded to party". -- Low Layer capability: this parameter may be repeated. Format defined in EN 300 403-1 [6]. -- This parameter can be provided with the "Party Information" of the "calling party", -- "called party" or "forwarded to party". MAP-parameters ::= SET SIZE (1..256) OF OCTET STRING (SIZE(1..256)) -- Each "OCTET STRING" contains one MAP parameter. The parameter is coded as described in -- ETS 300 974 [32] (The map-TS-Code is included). Supplementary-Services ::= SEQUENCE { standard-Supplementary-Services [1] Standard-Supplementary-Services OPTIONAL, non-Standard-Supplementary-Services [2] Non-Standard-Supplementary-Services OPTIONAL, other-Services [3] Other-Services OPTIONAL, ... }

19

Standard-Supplementary-Services ::= SEQUENCE { iSUP-SS-parameters [1] ISUP-SS-parameters OPTIONAL, dSS1-SS-parameters-codeset-0 [2] DSS1-SS-parameters-codeset-0 OPTIONAL, dSS1-SS-parameters-codeset-4 [3] DSS1-SS-parameters-codeset-4 OPTIONAL, dSS1-SS-parameters-codeset-5 [4] DSS1-SS-parameters-codeset-5 OPTIONAL, dSS1-SS-parameters-codeset-6 [5] DSS1-SS-parameters-codeset-6 OPTIONAL, dSS1-SS-parameters-codeset-7 [6] DSS1-SS-parameters-codeset-7 OPTIONAL, dSS1-SS-Invoke-components [7] DSS1-SS-Invoke-Components OPTIONAL, mAP-SS-Parameters [8] MAP-SS-Parameters OPTIONAL, mAP-SS-Invoke-Components [9] MAP-SS-Invoke-Components OPTIONAL, ... } Non-Standard-Supplementary-Services ::= SET SIZE (1..20) OF CHOICE { simpleIndication [1] SimpleIndication, sciData [2] SciDataMode, ... } Other-Services ::= SET SIZE (1..50) OF OCTET STRING (SIZE (1..256)) -- Reference manufacturer manuals. ISUP-SS-parameters ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) -- It must be noticed this parameter is retained for compatibility reasons. -- It is recommended not to use it in new work but to use ISUP-parameters parameter. -- Each "OCTET STRING" contains one additional ISUP parameter TLV coded not already defined in -- the previous parameters. The Tag value is the one given in EN 300 356 [5]. -- The Length and the Value are coded in accordance with the parameter definition in EN 300 356 [5]. -- Hereafter are listed the main parameters. However other parameters may be added: -- Connected Number: format defined in EN 300 356 [5]. -- This parameter can be provided with the "Party Information" of the -- "called party" or "forwarded to party". -- RedirectingNumber: format defined in EN 300 356 [5]. -- This parameter can be provided with the "Party Information" of the "originating party". -- Original Called Party Number: format defined in EN 300 356 [5]. -- This parameter can be provided with the "Party Information" of the "originating party". -- Redirection information: format defined in EN 300 356 [5]. -- This parameter can be provided with the "Party Information" of the -- "originating party", "forwarded to party" or/and "Terminating party".

20

-- Redirection Number: format defined in EN 300 356 [5]. -- This parameter can be provided with the "Party Information" of the -- "forwarded to party" or "Terminating party". -- Call diversion information: format defined in EN 300 356 [5]. -- This parameter can be provided with the "Party Information" of the -- "forwarded to party" or "Terminating party". -- Generic Number: format defined in EN 300 356 [5]. -- This parameter can be provided with the "Party Information" of the -- "calling party", "called party" or "forwarded to party". -- This parameters are used to transmit additional identities (additional, calling party -- number, additional called number, …). -- Generic Notification: format defined in EN 300 356 [5]. -- This parameter may be provided with the "Party Information" of the -- "calling party", "called party" or "forwarded to party". -- This parameters transmit the notification to the other part of the call of the supplementary -- services activated or invoked by a subscriber during the call. -- CUG Interlock Code: format defined in EN 300 356 [5]. -- This parameter can be provided with the "Party Information" of the "calling party". DSS1-SS-parameters-codeset-0 ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) -- Each "OCTET STRING" contains one DSS1 parameter of the codeset-0. The parameter is coded as -- described in EN 300 403-1 [6] (The DSS1 Information element identifier and the DSS1 length -- are included). Hereafter are listed the main parameters (However other parameters may be added): -- Calling Party Subaddress: format defined in EN 300 403-1 [6]. -- This parameter can be provided with the "Party Information" of the "calling party". -- Called Party Subaddress: format defined in EN 300 403-1 [6]. -- This parameter can be provided with the "Party Information" of the "calling party". -- Connected Subaddress: format defined in recommendation (see EN 300 097-1 [14]). -- This parameter can be provided with the "Party Information" of the -- "called party" or "forwarded to party". -- Connected Number: format defined in recommendation (see EN 300 097-1 [14]). -- This parameter can be provided with the "Party Information" of the -- "called party" or "forwarded to party". -- Keypad facility: format defined in EN 300 403-1 [6]. -- This parameter can be provided with the "Party Information" of the -- "calling party", "called party" or "forwarded to party". -- Called Party Number: format defined in EN 300 403-1 [6]. -- This parameter could be provided with the "Party Information" of the "calling party" -- when target is the originating party; it contains the dialled digits before modification -- at network level (e.g. IN interaction, translation, etc …). -- User-user: format defined in EN 300 286-1 [23]).

21

-- This parameter can be provided with the "Party Information" of the -- "calling party", "called party" or "forwarded to party". DSS1-SS-parameters-codeset-4 ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) -- Each "OCTET STRING" contains one DSS1 parameter of the codeset-4. The parameter is coded as -- described in the relevant recommendation. DSS1-SS-parameters-codeset-5 ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) -- Each "OCTET STRING" contains one DSS1 parameter of the codeset-5. The parameter is coded as -- described in the relevant national recommendation. DSS1-SS-parameters-codeset-6 ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) -- Each "OCTET STRING" contains one DSS1 parameter of the codeset-6. The parameter is coded as -- described in the relevant local network recommendation. DSS1-SS-parameters-codeset-7 ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) -- Each "octet string" contains one DSS1 parameter of the codeset-7. The parameter is coded as -- described in the relevant user specific recommendation. DSS1-SS-Invoke-Components ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) -- Each "octet string" contains one DSS1 Invoke or Return Result component. -- The invoke or return result component is coded as -- described in the relevant DSS1 supplementary service recommendation. -- Invoke or Return Result component (BeginCONF): EN 300 185-1 [19] -- Invoke or Return Result component (AddCONF): EN 300 185-1 [19] -- Invoke or Return Result component (SplitCONF): EN 300 185-1 [19] -- Invoke or Return Result component (DropCONF): EN 300 185-1 [19] -- Invoke or Return Result component (IsolateCONF): EN 300 185-1 [19] -- Invoke or Return Result component (ReattachCONF): EN 300 185-1 [19] -- Invoke or Return Result component (PartyDISC): EN 300 185-1 [19] -- Invoke or Return Result component (MCIDRequest): EN 300 130-1 [16] -- Invoke or Return Result component (Begin3PTY): EN 300 188-1 [20] -- Invoke or Return Result component (End3PTY): EN 300 188-1 [20] -- Invoke or Return Result component (ECTExecute): EN 300 369-1 [25] -- Invoke or Return Result component (ECTInform): EN 300 369-1 [25] -- Invoke or Return Result component (ECTLinkIdRequest): EN 300 369-1 [25] -- Invoke or Return Result component (ECTLoopTest): EN 300 369-1 [25] -- Invoke or Return Result component (ExplicitECTExecute): EN 300 369-1 [25] -- Invoke or Return Result component (ECT: RequestSubaddress): EN 300 369-1 [25] -- Invoke or Return Result component (ECT: SubaddressTransfer): EN 300 369-1 [25] -- Invoke or Return Result component (CF: ActivationDiversion): EN 300 207-1 [21] -- Invoke or Return Result component (CF: DeactivationDiversion): EN 300 207-1 [21]

22

-- Invoke or Return Result component (CF: ActivationStatusNotification): EN 300 207-1 [21] -- Invoke or Return Result component (CF: DeactivationStatusNotification): EN 300 207-1 [21] -- Invoke or Return Result component (CF: InterrogationDiversion): EN 300 207-1 [21] -- Invoke or Return Result component (CF: InterrogationServedUserNumber): EN 300 207-1 [21] -- Invoke or Return Result component (CF: DiversionInformation): EN 300 207-1 [21] -- Invoke or Return Result component (CF: CallDeflection): EN 300 207-1 [21] -- Invoke or Return Result component (CF: CallRerouteing): EN 300 207-1 [21] -- Invoke or Return Result component (CF: DivertingLegInformation1): EN 300 207-1 [21] -- Invoke or Return Result component (CF: DivertingLegInformation2): EN 300 207-1 [21] -- Invoke or Return Result component (CF: DivertingLegInformation3): EN 300 207-1 [21] -- other invoke or return result components ... MAP-SS-Invoke-Components ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) -- Each "octet string" contains one MAP Invoke or Return Result component. -- The invoke or return result component is coded as -- described in the relevant MAP supplementary service recommendation. MAP-SS-Parameters ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) -- Each "octet string" contains one MAP Parameter. The parameter is coded as -- described in the relevant MAP supplementary service recommendation. SimpleIndication ::= ENUMERATED { call-Waiting-Indication(0), -- The target has received a call waiting indication for this call add-conf-Indication(1), -- this call has been added to a conference call-on-hold-Indication(2), -- indication that this call is on hold retrieve-Indication(3), -- indication that this call has been retrieved suspend-Indication(4), -- indication that this call has been suspended resume-Indication(5), -- indication that this call has been resumed answer-Indication(6), -- indication that this call has been answered ... } SciDataMode ::= OCTET STRING (SIZE (1..256)) SMS-report ::= SEQUENCE

23

{ communicationIdentifier [1] CommunicationIdentifier, -- used to uniquely identify an intercepted call: the same used for the -- relevant IRI -- Called "callIdentifier" in Edition 1 (v.1.1.1) ES 201 671. timeStamp [2] TimeStamp, -- date and time of the report. The format is -- the one defined in case a) of the ASN.1 recommendation X.680 [33]. -- (year month day hour minutes seconds) sMS-Contents [3] SEQUENCE { initiator [1] ENUMERATED { -- party which sent the SMS target(0), server(1), undefined-party(2), ... }, transfer-status [2] ENUMERATED { succeed-transfer(0), --the transfer of the SMS message succeeds not-succeed-transfer(1), undefined(2), ... } OPTIONAL, other-message [3] ENUMERATED { -- In case of terminating call, indicates if the server will send other SMS. yes(0), no(1), undefined(2), ... } OPTIONAL, content [4] OCTET STRING (SIZE (1..270)) OPTIONAL, -- Encoded in the format defined for the SMS mobile. ... } }

24

LawfulInterceptionIdentifier ::= OCTET STRING (SIZE (1..25)) -- It is recommended to use ASCII characters in "a"…"z", "A"…"Z", "-", "_", ".", and "0"…"9". -- For subaddress option only "0"..."9" shall be used. -- 17 znakow numerycznych ASCII -- format: LEAID + TARGET(SEQ) -- TARGET - (15 znakow) nadawany sekwencyjnie dla kazdego LEAID -- LEAID -(2 znaki) 00 – LEMF operatora, 01 - ABW, 02 - Policja, 03 - CB$, 04 - SG, 05 CBA, 06 - SKW National-Parameters ::= SET SIZE (1..40) OF OCTET STRING (SIZE (1..256)) -- Content defined by national law. GPRSCorrelationNumber ::= OCTET STRING (SIZE(8..20)) GPRSEvent ::= ENUMERATED { pDPContextActivation(1), startOfInterceptionWithPDPContextActive(2), pDPContextDeactivation(4), gPRSAttach(5), gPRSDetach(6), cellOrRAUpdate(10), sMS(11), ..., pDPContextModification(13) } -- see TS 101 509 [42] Services-Data-Information ::= SEQUENCE { gPRS-parameters [1] GPRS-parameters OPTIONAL, ... } GPRS-parameters ::= SEQUENCE { pDP-address-allocated-to-the-target [1] DataNodeAddress OPTIONAL, aPN [2] OCTET STRING (SIZE(1..100)) OPTIONAL, pDP-type [3] OCTET STRING (SIZE(2)) OPTIONAL, ... } GPRSOperationErrorCode ::= OCTET STRING (SIZE(2)) -- Refer to TS 124 008 [41] for values (GMM cause or SM cause parameter).

25

DataNodeAddress ::= CHOICE { ipAddress [1] IPAddress, x25Address [2] X25Address, ... } IPAddress ::= SEQUENCE { iP-type [1] ENUMERATED { iPV4(0), iPV6(1), ... }, iP-value [2] IP-value, iP-assignment [3] ENUMERATED { static(1), -- The static coding shall be used to report a static address. dynamic(2), -- The dynamic coding shall be used to report a dynamically allocated address. notKnown(3), -- The notKnown coding shall be used to report other then static or dynamically -- allocated IP addresses. ... } OPTIONAL, ... } IP-value ::= CHOICE { iPBinaryAddress [1] OCTET STRING (SIZE(4..16)), iPTextAddress [2] IA5String (SIZE(7..45)), ... } X25Address ::= OCTET STRING (SIZE(1..25)) National-HI2-ASN1parameters ::= SEQUENCE { countryCode [1] PrintableString (SIZE (2)), -- Country Code according to ISO 3166-1 [67], -- the country to which the parameters inserted after the extension marker apply.

26

... -- In case a given country wants to use additional national parameters according to its law, -- these national parameters should be defined using the ASN.1 syntax and added after the -- extension marker (...). -- It is recommended that "version parameter" and "vendor identification parameter" are -- included in the national parameters definition. Vendor identifications can be -- retrieved from the IANA web site (see annex H). Besides, it is recommended to avoid -- using tags from 240 to 255 in a formal type definition. } UmtsQos ::= CHOICE { qosMobileRadio [1] OCTET STRING, -- The qosMobileRadio parameter shall be coded in accordance with the § 10.5.6.5 of -- document [9] without the Quality of service IEI and Length of -- quality of service IE (. That is, first -- two octets carrying 'Quality of service IEI' and 'Length of quality of service -- IE' shall be excluded). qosGn [2] OCTET STRING -- qosGn parameter shall be coded in accordance with § 7.7.34 of document [17] } IMSevent ::= ENUMERATED { unfilteredSIPmessage (1), -- This value indicates to LEMF that the whole SIP message is sent. ..., sIPheaderOnly (2) -- If warrant requires only IRI then specific content in a 'sIPMessage' -- (e.g. 'Message', etc.) has been deleted before sending it to LEMF. } LDIevent ::= ENUMERATED { targetEntersIA (1), targetLeavesIA (2), ... } CorrelationValues ::= CHOICE { iri-to-CC [0] IRI-to-CC-Correlation, -- correlates IRI to Content(s)

27

iri-to-iri [1] IRI-to-IRI-Correlation, -- correlates IRI to IRI both-IRI-CC [2] SEQUENCE { -- correlates IRI to IRI and IRI to Content(s) iri-CC [0] IRI-to-CC-Correlation, iri-IRI [1] IRI-to-IRI-Correlation } } IRI-to-CC-Correlation ::= SEQUENCE { -- correlates IRI to Content cc [0] SET OF OCTET STRING, -- correlates IRI to multiple CCs iri [1] OCTET STRING OPTIONAL -- correlates IRI to CC with signaling } IRI-to-IRI-Correlation ::= OCTET STRING -- correlates IRI to IRI

END -- of HI2Operations CS, PS

HI2Operations {itu-t(0) identified-organization(4) etsi(0) securityDomain(2) lawfulIntercept(2) hi2(1) version9(9)} DEFINITIONS IMPLICIT TAGS ::= BEGIN -- ============================= -- Object Identifier Definitions -- ============================= -- LawfulIntercept DomainId lawfulInterceptDomainId OBJECT IDENTIFIER ::= {itu-t(0) identified-organization(4) etsi(0) securityDomain(2) lawfulIntercept(2)} -- Security Subdomains hi2DomainId OBJECT IDENTIFIER ::= {lawfulInterceptDomainId hi2(1)}

28

hi2OperationId OBJECT IDENTIFIER ::= {hi2DomainId version9(9)} IRIsContent ::= CHOICE { iRIContent IRIContent, iRISequence IRISequence -- NOT USED } IRISequence ::= SEQUENCE OF IRIContent -- NOT USED -- Aggregation of IRIContent is an optional feature. -- It may be applied in cases when at a given point in time several IRI records are -- available for delivery to the same LEA destination. -- As a general rule, records created at any event shall be sent immediately and shall -- not held in the DF or MF in order to apply aggregation. -- When aggregation is not to be applied, IRIContent needs to be chosen. IRIContent ::= CHOICE { iRI-Begin-record [1] IRI-Parameters, -- At least one optional parameter must be included within the iRI-Begin-Record. iRI-End-record [2] IRI-Parameters, iRI-Continue-record [3] IRI-Parameters, -- At least one optional parameter must be included within the iRI-Continue-Record. iRI-Report-record [4] IRI-Parameters, -- At least one optional parameter must be included within the iRI-Report-Record. ... } IRI-Parameters ::= SEQUENCE { domainID [0] OBJECT IDENTIFIER (hi2OperationId) OPTIONAL, -- for the sending entity the inclusion of the Object Identifier is mandatory iRIversion [23] ENUMERATED { version2(2), ..., version3(3), version4(4), version5(5), version6(6), version7(7), lastVersion(8) } OPTIONAL, -- Optional parameter "iRIversion" (tag 23) is redundant starting from TS 101 671 v2.4.1 -- where to the object identifier "domainID" was introduced into IRI-Parameters.

29

-- In order to keep backward compatibility, even when the version of the "domainID" -- parameter will be incremented it is recommended to always send to LEMF the same: -- enumeration value "lastVersion(8)". -- if not present, it means version 1 is handled lawfulInterceptionIdentifier [1] LawfulInterceptionIdentifier, -- This identifier is associated to the target. communicationIdentifier [2] CommunicationIdentifier, -- used to uniquely identify an intercepted call. -- Called "callIdentifier" in Edition 1 of ES 201 671. timeStamp [3] TimeStamp, -- date and time of the event triggering the report. intercepted-Call-Direct [4] ENUMERATED { not-Available(0), originating-Target(1), -- In case of GPRS, this indicates that the PDP context activation, modification -- or deactivation is MS requested. terminating-Target(2), -- In case of GPRS, this indicates that the PDP context activation, modification -- or deactivation is network initiated. ... } OPTIONAL, intercepted-Call-State [5] Intercepted-Call-State OPTIONAL, ringingDuration [6] OCTET STRING (SIZE (3)) OPTIONAL, -- NOT USED -- Duration in seconds. BCD coded : HHMMSS conversationDuration [7] OCTET STRING (SIZE (3)) OPTIONAL, -- NOT USED -- Duration in seconds. BCD coded : HHMMSS locationOfTheTarget [8] Location OPTIONAL, -- location of the target subscriber partyInformation [9] SET SIZE (1..10) OF PartyInformation OPTIONAL, -- This parameter provides the concerned party (Originating, Terminating or forwarded -- party), the identity(ies) of the party and all the information provided by the party. callContentLinkInformation [10] SEQUENCE { cCLink1Characteristics [1] CallContentLinkCharacteristics OPTIONAL,

30

-- Information concerning the Content of Communication Link Tx channel established -- toward the LEMF (or the sum signal channel, in case of mono mode). cCLink2Characteristics [2] CallContentLinkCharacteristics OPTIONAL, -- Information concerning the Content of Communication Link Rx channel established -- toward the LEMF. ... } OPTIONAL, -- NOT USED release-Reason-Of-Intercepted-Call [11] OCTET STRING (SIZE (2)) OPTIONAL, -- Release cause coded in ITU-T Q.850 [31] format. -- This parameter indicates the reason why the intercepted call cannot be established or -- why the intercepted call has been released after the active phase. nature-Of-The-intercepted-call [12] ENUMERATED { -- Nature of the intercepted "call": gSM-ISDN-PSTN-circuit-call(0), -- the possible UUS content is sent through the HI2 or HI3 "data" interface -- the possible call content call is established through the HI3 "circuit" interface gSM-SMS-Message(1), -- the SMS content is sent through the HI2 or HI3 "data" interface uUS4-Messages(2), -- the UUS content is sent through the HI2 or HI3 "data" interface tETRA-circuit-call(3), -- the possible call content call is established through the HI3 "circuit" interface -- the possible data are sent through the HI3 "data" interface teTRA-Packet-Data(4), -- the data are sent through the HI3 "data" interface gPRS-Packet-Data(5), -- the data are sent through the HI3 "data" interface ..., uMTS-circuit-call(6) -- the possible call content call is established through the HI3 "circuit" interface -- the possible data are sent through the HI3 "data" interface } OPTIONAL, serverCenterAddress [13] PartyInformation OPTIONAL, -- e.g. in case of SMS message this parameter provides the address of the relevant -- server within the calling (if server is originating) or called -- (if server is terminating) party address parameters sMS [14] SMS-report OPTIONAL, -- this parameter provides the SMS content and associated information

31

cC-Link-Identifier [15] CC-Link-Identifier OPTIONAL, -- NOT USED -- Depending on a network option, this parameter may be used to identify a CC link -- in case of multiparty calls. national-Parameters [16] National-Parameters OPTIONAL, -- NOT USED gPRSCorrelationNumber [18] GPRSCorrelationNumber OPTIONAL, gPRSevent [20] GPRSEvent OPTIONAL, -- This information is used to provide particular action of the target -- such as attach/detach sgsnAddress [21] DataNodeAddress OPTIONAL, gPRSOperationErrorCode [22] GPRSOperationErrorCode OPTIONAL, ..., ggsnAddress [24] DataNodeAddress OPTIONAL, qOS [25] UmtsQos OPTIONAL, -- This parameter is duplicated from TS 133 108 [61]. networkIdentifier [26] Network-Identifier OPTIONAL, -- This parameter is duplicated from TS 133 108 [61]. sMSOriginatingAddress [27] DataNodeAddress OPTIONAL, -- This parameter is duplicated from TS 133 108 [61]. sMSTerminatingAddress [28] DataNodeAddress OPTIONAL, -- This parameter is duplicated from TS 133 108 [61]. iMSevent [29] IMSevent OPTIONAL, sIPMessage [30] OCTET STRING OPTIONAL, -- This parameter is duplicated from TS 133 108 [61]. servingSGSN-number [31] OCTET STRING (SIZE (1..20)) OPTIONAL, -- This parameter is duplicated from TS 133 108 [61]. servingSGSN-address [32] OCTET STRING (SIZE (5..17)) OPTIONAL, -- Octets are coded according to TS 123 003 -- This parameter is duplicated from TS 133 108 [61]. -- tARGETACTIVITYMONITOR [33] TARGETACTIVITYMONITOR OPTIONAL, -- to be included after publication of the AT-D specification -- Parameter is used in TS 101 909-20-1 [69] ldiEvent [34] LDIevent OPTIONAL,

32

-- The "Location Dependent Interception" parameter is duplicated from TS 133 108 [61]. correlation [35] CorrelationValues OPTIONAL, -- This parameter is duplicated from TS 133 108 [61] national-HI2-ASN1parameters [255] National-HI2-ASN1parameters OPTIONAL } -- ================== -- PARAMETERS FORMATS -- ================== CommunicationIdentifier ::= SEQUENCE { communication-Identity-Number [0] OCTET STRING (SIZE (1..8)) OPTIONAL, -- Temporary Identifier of an intercepted call to uniquely identify an intercepted call. -- This parameter is mandatory if there is associated -- information sent over HI3interface (CClink, data,..) or when -- CommunicationIdentifier is used for IRI other than IRI-Report-record -- This parameter was called "call-Identity-Number" in Edition 1 (v1.1.1) ES 201 671. -- The individual digits of the communication-Identity-Number shall be represented in -- ASCII format, e.g. "12345678" = 8 octets 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38. network-Identifier [1] Network-Identifier, ... } -- NOTE: The same "CommunicationIdentifier" value is sent : -- with the HI3 information for correlation purpose between the IRI and the information sent on -- the HI3 interfaces (CCLink, data, ..) with each IRI associated to a same intercepted call -- for correlation purpose between the different IRI. Network-Identifier ::= SEQUENCE { operator-Identifier [0] OCTET STRING (SIZE (1..5)), -- It is a notification of the NWO/AP/SvP in ASCII- characters. -- The parameter is mandatory. -- format: MNC + MVNO network-Element-Identifier [1] Network-Element-Identifier OPTIONAL, -- NOT USED ... } Network-Element-Identifier ::= CHOICE { e164-Format [1] OCTET STRING (SIZE (1..25)),

33

-- E164 address of the node in international format. Coded in the same format as the -- calling party number parameter of the ISUP (parameter part: EN 300 356 [5]). x25-Format [2] OCTET STRING (SIZE (1..25)), -- X25 address iP-Format [3] OCTET STRING (SIZE (1..25)), -- IP address dNS-Format [4] OCTET STRING (SIZE (1..25)), -- DNS address ..., iP-Address [5] IPAddress, ... } CC-Link-Identifier ::= OCTET STRING (SIZE (1..8)) -- Depending on a network option, this parameter may be used to identify a CClink -- in case of multiparty calls. -- The individual digits of the communication-Identity-Number shall be represented in -- ASCII format, e.g. "12345678" = 8 octets 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38. TimeStamp ::= CHOICE { -- The minimum resolution required is one second. -- "Resolution" is the smallest incremental change that can be measured for time and -- is expressed with a definite number of decimal digits or bits. localTime [0] LocalTimeStamp, utcTime [1] UTCTime } LocalTimeStamp ::= SEQUENCE { generalizedTime [0] GeneralizedTime, -- The minimum resolution required is one second. -- "Resolution" is the smallest incremental change that can be measured for time and -- is expressed with a definite number of decimal digits or bits. winterSummerIndication [1] ENUMERATED { notProvided(0), winterTime(1), summerTime(2), ... }

34

} PartyInformation ::= SEQUENCE { party-Qualifier [0] ENUMERATED { originating-Party(0), -- In this case, the partyInformation parameter provides the identities related to -- the originating party and all information provided by this party. -- This parameter provides also all the information concerning the redirecting -- party when a forwarded call reaches a target. terminating-Party(1), -- In this case, the partyInformation parameter provides the identities related to -- the terminating party and all information provided by this party. forwarded-to-Party(2), -- In this case, the partyInformation parameter provides the identities related to -- the forwarded to party and parties beyond this one and all information -- provided by this parties, including the call forwarding reason. gPRS-Target(3), ... }, partyIdentity [1] SEQUENCE { imei [1] OCTET STRING (SIZE (8)) OPTIONAL, -- See MAP format ETS 300 974 [32] tei [2] OCTET STRING (SIZE (1..15)) OPTIONAL, -- ISDN-based Terminal Equipment Identity imsi [3] OCTET STRING (SIZE (3..8)) OPTIONAL, -- See MAP format ETS 300 974 [32] International Mobile -- Station Identity E.212 number beginning with Mobile Country Code callingPartyNumber [4] CallingPartyNumber OPTIONAL, -- The calling party format is used to transmit the identity of a calling party calledPartyNumber [5] CalledPartyNumber OPTIONAL, -- The called party format is used to transmit the identity of a called party or -- a forwarded to party. msISDN [6] OCTET STRING (SIZE (1..9)) OPTIONAL, -- MSISDN of the target, encoded in the same format as the AddressString -- parameters defined in MAP format ETS 300 974 [32], clause 14.7.8. ...,

35

e164-Format [7] OCTET STRING (SIZE (1..25)) OPTIONAL, -- E164 address of the node in international format. Coded in the same format as -- the calling party number parameter of the ISUP (parameter part: EN 300 356 [5]) sip-uri [8] OCTET STRING OPTIONAL, -- Session Initiation Protocol - Uniform Resource Identifier. See RFC 3261 [59]. -- This parameter is duplicated from TS 133 108 [61]. tel-url [9] OCTET STRING OPTIONAL -- See "URLs for Telephone Calls", RFC 3966 [68]. -- This parameter is duplicated from TS 133 108 [61]. }, services-Information [2] Services-Information OPTIONAL, -- This parameter is used to transmit all the information concerning the -- complementary information associated to the basic call supplementary-Services-Information [3] Supplementary-Services OPTIONAL, -- This parameter is used to transmit all the information concerning the -- activation/invocation of supplementary services during a call or out-of call not -- provided by the previous parameters. services-Data-Information [4] Services-Data-Information OPTIONAL, -- This parameter is used to transmit all the information concerning the complementary -- information associated to the basic data call. partyExtendedIdentity [PRIVATE 1] PartyExtendedIdentity OPTIONAL, ... } PartyExtendedIdentity ::= SEQUENCE { subscriptionType [1] ENUMERATED { postpaid (0), prepaid

(1),

... } OPTIONAL, activationDate [2] TimeStamp OPTIONAL, deactivationDate [3] TimeStamp OPTIONAL, subscriber [4] Subscriber OPTIONAL, postalAddress [5] PostalAddress OPTIONAL, mailAddress [6] PostalAddress OPTIONAL, ... }

36

Subscriber ::= CHOICE { company [1] Company, person [2] Person, ... } Company ::= SEQUENCE { name [0] UTF8String, regon

[1] OCTET STRING (SIZE (5)),

-- BCD coded 9 digits -- F digit not used ... } Person ::= SEQUENCE { firstName [0] UTF8String, surname [1] UTF8String, pesel

[2] OCTET STRING (SIZE (6)) OPTIONAL,

-- BCD coded 11 digits -- F digit not used passportNumber [3] OCTET STRING (SIZE (7..14)) OPTIONAL, -- ASCII coded ... } PostalAddress ::= SEQUENCE { street [1] UTF8String OPTIONAL, buildingNumber [2] OCTET STRING (SIZE (1..10)) OPTIONAL, -- ASCII coded: 10 char apartmentNumber [3] OCTET STRING (SIZE (1..10)) OPTIONAL, -- ASCII coded: 10 char postcode [4] OCTET STRING (SIZE (1..8)) OPTIONAL, city [5] UTF8String OPTIONAL, country [6] UTF8String OPTIONAL } CallingPartyNumber ::= CHOICE { iSUP-Format [1] OCTET STRING (SIZE (1..25)), -- Encoded in the same format as the calling party number (parameter field) -- of the ISUP (see EN 300 356 [5]).

37

dSS1-Format [2] OCTET STRING (SIZE (1..25)), -- Encoded in the format defined for the value part of the Calling party number -- information element of DSS1 protocol EN 300 403-1 [6]. -- The DSS1 Information element identifier and the DSS1 length are not included. ..., mAP-Format [3] OCTET STRING (SIZE (1..25)) -- Encoded as AddressString of the MAP protocol ETS 300 974 [32]. } CalledPartyNumber ::= CHOICE { iSUP-Format [1] OCTET STRING (SIZE (1..25)), -- Encoded in the same format as the called party number (parameter field) -- of the ISUP (see EN 300 356 [5]). mAP-Format [2] OCTET STRING (SIZE (1..25)), -- Encoded as AddressString of the MAP protocol ETS 300 974 [32]. dSS1-Format [3] OCTET STRING (SIZE (1..25)), -- Encoded in the format defined for the value part of the Called party number information -- element of DSS1 protocol EN 300 403-1 [6]. -- The DSS1 Information element identifier and the DSS1 length are not included. ... } Location ::= SEQUENCE { e164-Number [1] OCTET STRING (SIZE (1..25)) OPTIONAL, -- Coded in the same format as the ISUP location number (parameter --field) of the ISUP (see EN 300 356 [5]). globalCellID [2] OCTET STRING (SIZE (5..7)) OPTIONAL, -- See MAP format (see ETS 300 974 [32]). -- Refers to Cell Global Identification defined in TS GSM 03.03. -- Octets are coded according to TS GSM 04.08. -- The internal structure is defined as follows: -- Mobile Country Code: 3 digits according to CCITT Rec E.212 -- 1 digit filler (1111) -- Mobile Network Code: 2 digits according to CCITT Rec E.212 -- Location Area Code: 2 octets according to TS GSM 04.08 -- Cell Identity: 2 octets (CI) according to TS GSM 04.08 tetraLocation [3] TetraLocation OPTIONAL,

38

rAI [4] OCTET STRING (SIZE (6)) OPTIONAL, -- The Routeing Area Identifier (RAI) in the current SGSN is coded in accordance with -- TS 124 008 [41] without the Routing Area Identification IEI (only the -- last 6 octets are used). gsmLocation [5] GSMLocation OPTIONAL, umtsLocation [6] UMTSLocation OPTIONAL, sAI [7] OCTET STRING (SIZE (7)) OPTIONAL, -- format: PLMN-ID 3 octets (no. 1-3), -- LAC 2 octets (no. 4-5), -- SAC 2 octets (no. 6-7) -- (according to 3GPP TS 125 431 [62]). oldRAI [8] OCTET STRING (SIZE (6)) OPTIONAL, -- the "Routeing Area Identifier" in the old SGSN is coded in accordance with -- TS 124 008 (41) without the Routing Area Identification IEI -- (only the last 6 octets are used). -- This parameter is duplicated from TS 133 108 [61]. TetraLocation ::= CHOICE { ms-Loc [1] SEQUENCE { mcc [1] INTEGER (0..1023), -- 10 bits EN 300 392-1 [40] mnc [2] INTEGER (0..16383), -- 14 bits EN 300 392-1 [40] lai [3] INTEGER (0..65535), -- 14 bits EN 300 392-1 [40] ci [4] INTEGER OPTIONAL }, -- (to be completed) ls-Loc [2] INTEGER -- (to be confirmed and completed) } GSMLocation ::= CHOICE { geoCoordinates [1] SEQUENCE { latitude [1] PrintableString (SIZE(7..10)), -- format: XDDMMSS.SS

39

longitude [2] PrintableString (SIZE(8..11)), -- format: XDDDMMSS.SS mapDatum [3] MapDatum DEFAULT wGS84, ..., azimuth [4] INTEGER (0..359) OPTIONAL -- The azimuth is the bearing, relative to true north. }, -- format: XDDDMMSS.SS -- X : N(orth), S(outh), E(ast), W(est) -- DD or DDD : degrees (numeric characters) -- MM : minutes (numeric characters) -- SS.SS : seconds, the second part (.SS) is optional -- Example: -- latitude short form N502312 -- longitude long form E1122312.18 utmCoordinates [2] SEQUENCE { utm-East [1] PrintableString (SIZE(10)), utm-North [2] PrintableString (SIZE(7)), -- Universal Transverse Mercator -- example utm-East 32U0439955 -- utm-North 5540736 mapDatum [3] MapDatum DEFAULT wGS84, ..., azimuth [4] INTEGER (0..359) OPTIONAL -- The azimuth is the bearing, relative to true north. }, utmRefCoordinates [3] SEQUENCE { utmref-string PrintableString (SIZE(13)), mapDatum MapDatum DEFAULT wGS84, ... }, -- example 32UPU91294045 wGS84Coordinates [4] OCTET STRING -- format is as defined in TS 101 109 [57]; polygon type of shape is not allowed. } MapDatum ::= ENUMERATED {

40

wGS84, -- World Geodetic System 1984 wGS72, eD50, -- European Datum 50 ... } UMTSLocation ::= CHOICE { point [1] GA-Point, pointWithUnCertainty [2] GA-PointWithUnCertainty, polygon [3] GA-Polygon, ... } GeographicalCoordinates ::= SEQUENCE { latitudeSign ENUMERATED { north, south }, latitude INTEGER (0..8388607), longitude INTEGER (-8388608..8388607), ... } GA-Point ::= SEQUENCE { geographicalCoordinates GeographicalCoordinates, ... } GA-PointWithUnCertainty ::=SEQUENCE { geographicalCoordinates GeographicalCoordinates, uncertaintyCode INTEGER (0..127) } maxNrOfPoints INTEGER ::= 15

41

GA-Polygon ::= SEQUENCE (SIZE (1..maxNrOfPoints)) OF SEQUENCE { geographicalCoordinates GeographicalCoordinates, ... } CallContentLinkCharacteristics ::= SEQUENCE { cCLink-State [1] CCLink-State OPTIONAL, -- current state of the CCLink release-Time [2] TimeStamp OPTIONAL, -- date and time of the release of the Call Content Link. release-Reason [3] OCTET STRING (SIZE(2)) OPTIONAL, -- Release cause coded in Q.850 [31] format. lEMF-Address [4] CalledPartyNumber OPTIONAL, -- Directory number used to route the call toward the LEMF. ... } CCLink-State ::= ENUMERATED { setUpInProcess(1), -- The set-up of the call is in process. callActive(2), callReleased(3), lack-of-resource(4), -- The lack-of-resource state is sent when a CC Link cannot -- be established because of lack of resource at the MF level. ... } Intercepted-Call-State ::= ENUMERATED { idle(1), -- When the intercept call is released, the state is IDLE and the reason is provided -- by the release-Reason-Of-Intercepted-Call parameter. setUpInProcess(2), -- The set-up of the call is in process. connected(3), -- The answer has been received. ... }

42

Services-Information ::= SEQUENCE { iSUP-parameters [1] ISUP-parameters OPTIONAL, dSS1-parameters-codeset-0 [2] DSS1-parameters-codeset-0 OPTIONAL, ..., mAP-parameters [3] MAP-parameters OPTIONAL } ISUP-parameters ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) -- Each "OCTET STRING" contains one additional ISUP parameter TLV coded not already defined in -- the previous parameters. The Tag value is the one given in EN 300 356 [5]. -- In version 1 of the present document "iSUP-parameters" is defined as mandatory. -- It might occur that no ISUP parameter is available. In that case in a version 1 -- implementation the value "zero" may be included in the first octet string of the SET. -- The Length and the Value are coded in accordance with the parameter definition in -- EN 300 356 [5]. Hereafter are listed the main parameters. -- However other parameters may be added: -- Transmission medium requirement: format defined in EN 300 356 [5]. -- This parameter can be provided with the "Party Information" of the "calling party". -- Transmission medium requirement prime: format defined in EN 300 356 [5]. -- This parameter can be provided with the "Party Information" of the "calling party". DSS1-parameters-codeset-0 ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) -- Each "OCTET STRING" contains one DSS1 parameter of the codeset-0. The parameter is coded as -- described in EN 300 403-1 [6] (The DSS1 Information element identifier and the DSS1 length -- are included). Hereafter are listed the main parameters -- (However other parameters may be added): -- Bearer capability: this parameter may be repeated. Format defined in EN 300 403-1 [6]. -- This parameter can be provided with the "Party Information" of the "calling party", -- "called party" or "forwarded to party". -- High Layer Compatibility: this parameter may be repeated. Format defined in EN 300 403-1 [6] -- This parameter can be provided with the "Party Information" of the "calling party", -- "called party" or "forwarded to party". -- Low Layer capability: this parameter may be repeated. Format defined in EN 300 403-1 [6]. -- This parameter can be provided with the "Party Information" of the "calling party", -- "called party" or "forwarded to party". MAP-parameters ::= SET SIZE (1..256) OF OCTET STRING (SIZE(1..256)) -- Each "OCTET STRING" contains one MAP parameter. The parameter is coded as described in

43

-- ETS 300 974 [32] (The map-TS-Code is included). Supplementary-Services ::= SEQUENCE { standard-Supplementary-Services [1] Standard-Supplementary-Services OPTIONAL, non-Standard-Supplementary-Services [2] Non-Standard-Supplementary-Services OPTIONAL, other-Services [3] Other-Services OPTIONAL, ... } Standard-Supplementary-Services ::= SEQUENCE { iSUP-SS-parameters [1] ISUP-SS-parameters OPTIONAL, dSS1-SS-parameters-codeset-0 [2] DSS1-SS-parameters-codeset-0 OPTIONAL, dSS1-SS-parameters-codeset-4 [3] DSS1-SS-parameters-codeset-4 OPTIONAL, dSS1-SS-parameters-codeset-5 [4] DSS1-SS-parameters-codeset-5 OPTIONAL, dSS1-SS-parameters-codeset-6 [5] DSS1-SS-parameters-codeset-6 OPTIONAL, dSS1-SS-parameters-codeset-7 [6] DSS1-SS-parameters-codeset-7 OPTIONAL, dSS1-SS-Invoke-components [7] DSS1-SS-Invoke-Components OPTIONAL, mAP-SS-Parameters [8] MAP-SS-Parameters OPTIONAL, mAP-SS-Invoke-Components [9] MAP-SS-Invoke-Components OPTIONAL, ... } Non-Standard-Supplementary-Services ::= SET SIZE (1..20) OF CHOICE { simpleIndication [1] SimpleIndication, sciData [2] SciDataMode, ... } Other-Services ::= SET SIZE (1..50) OF OCTET STRING (SIZE (1..256)) -- Reference manufacturer manuals. ISUP-SS-parameters ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) -- It must be noticed this parameter is retained for compatibility reasons. -- It is recommended not to use it in new work but to use ISUP-parameters parameter. -- Each "OCTET STRING" contains one additional ISUP parameter TLV coded not already defined in -- the previous parameters. The Tag value is the one given in EN 300 356 [5]. -- The Length and the Value are coded in accordance with the parameter definition in EN 300 356 [5]. -- Hereafter are listed the main parameters. However other parameters may be added: -- Connected Number: format defined in EN 300 356 [5]. -- This parameter can be provided with the "Party Information" of the -- "called party" or "forwarded to party".

44

-- RedirectingNumber: format defined in EN 300 356 [5]. -- This parameter can be provided with the "Party Information" of the "originating party". -- Original Called Party Number: format defined in EN 300 356 [5]. -- This parameter can be provided with the "Party Information" of the "originating party". -- Redirection information: format defined in EN 300 356 [5]. -- This parameter can be provided with the "Party Information" of the -- "originating party", "forwarded to party" or/and "Terminating party". -- Redirection Number: format defined in EN 300 356 [5]. -- This parameter can be provided with the "Party Information" of the -- "forwarded to party" or "Terminating party". -- Call diversion information: format defined in EN 300 356 [5]. -- This parameter can be provided with the "Party Information" of the -- "forwarded to party" or "Terminating party". -- Generic Number: format defined in EN 300 356 [5]. -- This parameter can be provided with the "Party Information" of the -- "calling party", "called party" or "forwarded to party". -- This parameters are used to transmit additional identities (additional, calling party -- number, additional called number, …). -- Generic Notification: format defined in EN 300 356 [5]. -- This parameter may be provided with the "Party Information" of the -- "calling party", "called party" or "forwarded to party". -- This parameters transmit the notification to the other part of the call of the supplementary -- services activated or invoked by a subscriber during the call. -- CUG Interlock Code: format defined in EN 300 356 [5]. -- This parameter can be provided with the "Party Information" of the "calling party". DSS1-SS-parameters-codeset-0 ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) -- Each "OCTET STRING" contains one DSS1 parameter of the codeset-0. The parameter is coded as -- described in EN 300 403-1 [6] (The DSS1 Information element identifier and the DSS1 length -- are included). Hereafter are listed the main parameters (However other parameters may be added): -- Calling Party Subaddress: format defined in EN 300 403-1 [6]. -- This parameter can be provided with the "Party Information" of the "calling party". -- Called Party Subaddress: format defined in EN 300 403-1 [6]. -- This parameter can be provided with the "Party Information" of the "calling party". -- Connected Subaddress: format defined in recommendation (see EN 300 097-1 [14]). -- This parameter can be provided with the "Party Information" of the -- "called party" or "forwarded to party". -- Connected Number: format defined in recommendation (see EN 300 097-1 [14]). -- This parameter can be provided with the "Party Information" of the -- "called party" or "forwarded to party".

45

-- Keypad facility: format defined in EN 300 403-1 [6]. -- This parameter can be provided with the "Party Information" of the -- "calling party", "called party" or "forwarded to party". -- Called Party Number: format defined in EN 300 403-1 [6]. -- This parameter could be provided with the "Party Information" of the "calling party" -- when target is the originating party; it contains the dialled digits before modification -- at network level (e.g. IN interaction, translation, etc …). -- User-user: format defined in EN 300 286-1 [23]). -- This parameter can be provided with the "Party Information" of the -- "calling party", "called party" or "forwarded to party". DSS1-SS-parameters-codeset-4 ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) -- Each "OCTET STRING" contains one DSS1 parameter of the codeset-4. The parameter is coded as -- described in the relevant recommendation. DSS1-SS-parameters-codeset-5 ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) -- Each "OCTET STRING" contains one DSS1 parameter of the codeset-5. The parameter is coded as -- described in the relevant national recommendation. DSS1-SS-parameters-codeset-6 ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) -- Each "OCTET STRING" contains one DSS1 parameter of the codeset-6. The parameter is coded as -- described in the relevant local network recommendation. DSS1-SS-parameters-codeset-7 ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) -- Each "octet string" contains one DSS1 parameter of the codeset-7. The parameter is coded as -- described in the relevant user specific recommendation. DSS1-SS-Invoke-Components ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) -- Each "octet string" contains one DSS1 Invoke or Return Result component. -- The invoke or return result component is coded as -- described in the relevant DSS1 supplementary service recommendation. -- Invoke or Return Result component (BeginCONF): EN 300 185-1 [19] -- Invoke or Return Result component (AddCONF): EN 300 185-1 [19] -- Invoke or Return Result component (SplitCONF): EN 300 185-1 [19] -- Invoke or Return Result component (DropCONF): EN 300 185-1 [19] -- Invoke or Return Result component (IsolateCONF): EN 300 185-1 [19] -- Invoke or Return Result component (ReattachCONF): EN 300 185-1 [19] -- Invoke or Return Result component (PartyDISC): EN 300 185-1 [19] -- Invoke or Return Result component (MCIDRequest): EN 300 130-1 [16] -- Invoke or Return Result component (Begin3PTY): EN 300 188-1 [20] -- Invoke or Return Result component (End3PTY): EN 300 188-1 [20]

46

-- Invoke or Return Result component (ECTExecute): EN 300 369-1 [25] -- Invoke or Return Result component (ECTInform): EN 300 369-1 [25] -- Invoke or Return Result component (ECTLinkIdRequest): EN 300 369-1 [25] -- Invoke or Return Result component (ECTLoopTest): EN 300 369-1 [25] -- Invoke or Return Result component (ExplicitECTExecute): EN 300 369-1 [25] -- Invoke or Return Result component (ECT: RequestSubaddress): EN 300 369-1 [25] -- Invoke or Return Result component (ECT: SubaddressTransfer): EN 300 369-1 [25] -- Invoke or Return Result component (CF: ActivationDiversion): EN 300 207-1 [21] -- Invoke or Return Result component (CF: DeactivationDiversion): EN 300 207-1 [21] -- Invoke or Return Result component (CF: ActivationStatusNotification): EN 300 207-1 [21] -- Invoke or Return Result component (CF: DeactivationStatusNotification): EN 300 207-1 [21] -- Invoke or Return Result component (CF: InterrogationDiversion): EN 300 207-1 [21] -- Invoke or Return Result component (CF: InterrogationServedUserNumber): EN 300 207-1 [21] -- Invoke or Return Result component (CF: DiversionInformation): EN 300 207-1 [21] -- Invoke or Return Result component (CF: CallDeflection): EN 300 207-1 [21] -- Invoke or Return Result component (CF: CallRerouteing): EN 300 207-1 [21] -- Invoke or Return Result component (CF: DivertingLegInformation1): EN 300 207-1 [21] -- Invoke or Return Result component (CF: DivertingLegInformation2): EN 300 207-1 [21] -- Invoke or Return Result component (CF: DivertingLegInformation3): EN 300 207-1 [21] -- other invoke or return result components ... MAP-SS-Invoke-Components ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) -- Each "octet string" contains one MAP Invoke or Return Result component. -- The invoke or return result component is coded as -- described in the relevant MAP supplementary service recommendation. MAP-SS-Parameters ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) -- Each "octet string" contains one MAP Parameter. The parameter is coded as -- described in the relevant MAP supplementary service recommendation. SimpleIndication ::= ENUMERATED { call-Waiting-Indication(0), -- The target has received a call waiting indication for this call add-conf-Indication(1), -- this call has been added to a conference call-on-hold-Indication(2), -- indication that this call is on hold retrieve-Indication(3), -- indication that this call has been retrieved suspend-Indication(4), -- indication that this call has been suspended resume-Indication(5),

47

-- indication that this call has been resumed answer-Indication(6), -- indication that this call has been answered ... } SciDataMode ::= OCTET STRING (SIZE (1..256)) SMS-report ::= SEQUENCE { communicationIdentifier [1] CommunicationIdentifier, -- used to uniquely identify an intercepted call: the same used for the -- relevant IRI -- Called "callIdentifier" in Edition 1 (v.1.1.1) ES 201 671. timeStamp [2] TimeStamp, -- date and time of the report. The format is -- the one defined in case a) of the ASN.1 recommendation X.680 [33]. -- (year month day hour minutes seconds) sMS-Contents [3] SEQUENCE { initiator [1] ENUMERATED { -- party which sent the SMS target(0), server(1), undefined-party(2), ... }, transfer-status [2] ENUMERATED { succeed-transfer(0), --the transfer of the SMS message succeeds not-succeed-transfer(1), undefined(2), ... } OPTIONAL, other-message [3] ENUMERATED { -- In case of terminating call, indicates if the server will send other SMS. yes(0), no(1), undefined(2),

48

... } OPTIONAL, content [4] OCTET STRING (SIZE (1..270)) OPTIONAL, -- Encoded in the format defined for the SMS mobile. ... } } LawfulInterceptionIdentifier ::= OCTET STRING (SIZE (1..25)) -- It is recommended to use ASCII characters in "a"…"z", "A"…"Z", "-", "_", ".", and "0"…"9". -- For subaddress option only "0"..."9" shall be used. -- 17 znakow numerycznych ASCII -- format: LEAID + TARGET(SEQ) -- TARGET - (15 znakow) nadawany sekwencyjnie dla kazdego LEAID -- LEAID -(2 znaki) 00 – LEMF operatora, 01 - ABW, 02 - Policja, 03 - CB$, 04 - SG, 05 CBA, 06 - SKW National-Parameters ::= SET SIZE (1..40) OF OCTET STRING (SIZE (1..256)) -- Content defined by national law. GPRSCorrelationNumber ::= OCTET STRING (SIZE(8..20)) GPRSEvent ::= ENUMERATED { pDPContextActivation(1), startOfInterceptionWithPDPContextActive(2), pDPContextDeactivation(4), gPRSAttach(5), gPRSDetach(6), cellOrRAUpdate(10), sMS(11), ..., pDPContextModification(13) } -- see TS 101 509 [42] Services-Data-Information ::= SEQUENCE { gPRS-parameters [1] GPRS-parameters OPTIONAL, ... } GPRS-parameters ::= SEQUENCE {

49

pDP-address-allocated-to-the-target [1] DataNodeAddress OPTIONAL, aPN [2] OCTET STRING (SIZE(1..100)) OPTIONAL, pDP-type [3] OCTET STRING (SIZE(2)) OPTIONAL, ... } GPRSOperationErrorCode ::= OCTET STRING (SIZE(2)) -- Refer to TS 124 008 [41] for values (GMM cause or SM cause parameter). DataNodeAddress ::= CHOICE { ipAddress [1] IPAddress, x25Address [2] X25Address, ... } IPAddress ::= SEQUENCE { iP-type [1] ENUMERATED { iPV4(0), iPV6(1), ... }, iP-value [2] IP-value, iP-assignment [3] ENUMERATED { static(1), -- The static coding shall be used to report a static address. dynamic(2), -- The dynamic coding shall be used to report a dynamically allocated address. notKnown(3), -- The notKnown coding shall be used to report other then static or dynamically -- allocated IP addresses. ... } OPTIONAL, ... } IP-value ::= CHOICE { iPBinaryAddress [1] OCTET STRING (SIZE(4..16)), iPTextAddress [2] IA5String (SIZE(7..45)), ...

50

} X25Address ::= OCTET STRING (SIZE(1..25)) National-HI2-ASN1parameters ::= SEQUENCE { countryCode [1] PrintableString (SIZE (2)), -- Country Code according to ISO 3166-1 [67], -- the country to which the parameters inserted after the extension marker apply. ... -- In case a given country wants to use additional national parameters according to its law, -- these national parameters should be defined using the ASN.1 syntax and added after the -- extension marker (...). -- It is recommended that "version parameter" and "vendor identification parameter" are -- included in the national parameters definition. Vendor identifications can be -- retrieved from the IANA web site (see annex H). Besides, it is recommended to avoid -- using tags from 240 to 255 in a formal type definition. } UmtsQos ::= CHOICE { qosMobileRadio [1] OCTET STRING, -- The qosMobileRadio parameter shall be coded in accordance with the § 10.5.6.5 of -- document [9] without the Quality of service IEI and Length of -- quality of service IE (. That is, first -- two octets carrying 'Quality of service IEI' and 'Length of quality of service -- IE' shall be excluded). qosGn [2] OCTET STRING -- qosGn parameter shall be coded in accordance with § 7.7.34 of document [17] } IMSevent ::= ENUMERATED { unfilteredSIPmessage (1), -- This value indicates to LEMF that the whole SIP message is sent. ..., sIPheaderOnly (2) -- If warrant requires only IRI then specific content in a 'sIPMessage' -- (e.g. 'Message', etc.) has been deleted before sending it to LEMF. } LDIevent ::= ENUMERATED {

51

targetEntersIA (1), targetLeavesIA (2), ... } CorrelationValues ::= CHOICE { iri-to-CC [0] IRI-to-CC-Correlation, -- correlates IRI to Content(s) iri-to-iri [1] IRI-to-IRI-Correlation, -- correlates IRI to IRI both-IRI-CC [2] SEQUENCE { -- correlates IRI to IRI and IRI to Content(s) iri-CC [0] IRI-to-CC-Correlation, iri-IRI [1] IRI-to-IRI-Correlation } } IRI-to-CC-Correlation ::= SEQUENCE { -- correlates IRI to Content cc [0] SET OF OCTET STRING, -- correlates IRI to multiple CCs iri [1] OCTET STRING OPTIONAL -- correlates IRI to CC with signaling } IRI-to-IRI-Correlation ::= OCTET STRING -- correlates IRI to IRI

END -- of HI2Operations

10/35si

52

Za#"cznik nr 3 Specyfikacja techniczna styku HI-3 interfejsu HI I. Struktura Interfejsu HI3 1.Warstwa fizyczna

Warstwa fizyczna ma znaczenie lokalne pomi$dzy dwoma urz"dzeniami sieciowymi i ma znaczenie tylko na styku systemów miedzy operatorem a uprawnionym podmiotem. 2. Warstwa sieciowa

Dla ka°o podmiotu uprawnionego okre!lone s" dedykowane adresy publiczne IPv4 dla DF (HI2). S#u&by okre!laj" adresacj$ publiczn" IPv4 po swojej stronie. Adresy IP nie mog" by' takie same dla wszystkich operatorów w danym systemie LEMF, jak i nie mog" by' takie same dla uprawnionych podmiotów w danym systemie ADMF/DF. 3. Warstwa transportowa 3.1 Circuit Switched (CS)

Interfejs b$dzie konstruowany w sposób umo&liwiaj"cy w przysz#o!ci wysy#anie 2 strumieni PCM (stereo) w przypadku voice. Interfejs umo&liwia wysy#anie 2 strumieni PCM w przypadku transmisji data i fax. 3.2 Offline

Pliki przesy#ane protoko#em FTP (podobnie jak w przypadku HI2). Po#"czenie jest nawi"zywane tylko w kierunku DF ) LEMF. Stosowany równie& dla sesji dla których za&"dano trybu online. Pliki audio powinny by' kodowane w formacie wave: PCM, 8 kHz, 16 bitów, mono. Nazwa pliku po przes#aniu sk#ada si$ z LIID i CIN (LIID_CIN.ext), Wysy#anie 2 strumieni audio w offline CS b$dzie rozró&niane po rozszerzeniu zgodnie z metod" A (2 – CC(MO), 4 – CC(MT), 6 - CC (MO+MT)). 3.3 Online

Tryb wykorzystywany na &"danie. Protokó#y SIP (RFC 3261), SDP, RTP. Wykrywamy czy jest to g#os. W przypadku g#osu kodowanie z mniejszym wymaganiem na pasmo (G.711A (PCMA) 8kHz). Kodowanie – PCM 64kb w przypadku przesy#ania danych lub faxu. 3.4 Packet Switched (PS)

Protokó# ULIC (TCP). Po#"czenie jest nawi"zywane tylko w kierunku MF ! LEMF. 3.5 IPAccess (WLAN, xDSL)

Protokó# TCP zgodnie z ETSI TS 102 232-1. Po#"czenie jest nawi"zywane tylko w kierunku MF ! LEMF

Warstwa aplikacyjna Opis

Rysunek 1: Schemat Operacji - Packet Switched (PS) W celu uzyskania jak najwi$kszej wydajno!ci, LEMF nie potwierdza odebrania PDU w warstwie aplikacyjnej. II. Szczegó#owa specyfikacja HI3 (PS only)

Umts-HI3-PS {itu-t(0) identified-organization(4) etsi(0) securityDomain(2) lawfulintercept(2) threeGPP(4) hi3(2) r6(6) version-3(3)} DEFINITIONS IMPLICIT TAGS ::= BEGIN -- Object Identifier Definitions -- Security DomainId lawfulInterceptDomainId OBJECT IDENTIFIER ::= {itu-t(0) identified-organization(4) etsi(0) securityDomain(2) lawfulIntercept(2)} -- Security Subdomains threeGPPSUBDomainId OBJECT IDENTIFIER ::= {lawfulInterceptDomainId threeGPP(4)} hi3DomainId OBJECT IDENTIFIER ::= {threeGPPSUBDomainId hi3(2) r6(6) version-3(3)}

2

CC-PDU ::= SEQUENCE { uLIC-header [1] ULIC-header, payload [2] OCTET STRING } ULIC-header ::= SEQUENCE { hi3DomainId [0] OBJECT IDENTIFIER, -- 3GPP HI3 Domain version [1] Version, lIID [2] LawfulInterceptionIdentifier OPTIONAL, correlation-Number [3] GPRSCorrelationNumber, timeStamp [4] TimeStamp OPTIONAL, sequence-number [5] INTEGER (0..65535), t-PDU-direction [6] TPDU-direction, ..., national-HI3-ASN1parameters [7] National-HI3-ASN1parameters OPTIONAL, -- encoded per national requirements ice-type [8] ICE-type OPTIONAL -- The ICE-type indicates the applicable Intercepting Control Element(see ref [19]) in which -- the T-PDU is intercepted. } Version ::= ENUMERATED { version1(1), ..., version3(3) } TPDU-direction ::= ENUMERATED { from-target (1), to-target (2), unknown (3) }

3

National-HI3-ASN1parameters ::= SEQUENCE { countryCode [1] PrintableString (SIZE (2)), -- Country Code according to ISO 3166-1 [39], -- the country to which the parameters inserted after the extension marker apply ... -- In case a given country wants to use additional national parameters according to its law, -- these national parameters should be defined using the ASN.1 syntax and added after the -- extension marker (...). -- It is recommended that "version parameter" and "vendor identification parameter" are -- included in the national parameters definition. Vendor identifications can be -- retrieved from IANA web site. } ICE-type ::= ENUMERATED { sgsn (1), ggsn (2), ... } LocalTimeStamp ::= SEQUENCE { generalizedTime [0] GeneralizedTime, -- The minimum resolution required is one second. -- "Resolution" is the smallest incremental change that can be measured for time and -- is expressed with a definite number of decimal digits or bits. winterSummerIndication [1] ENUMERATED { notProvided(0), winterTime(1), summerTime(2), ... } } TimeStamp ::= CHOICE { -- The minimum resolution required is one second. -- "Resolution" is the smallest incremental change that can be measured for time and -- is expressed with a definite number of decimal digits or bits. localTime [0] LocalTimeStamp,

4

utcTime [1] UTCTime } LawfulInterceptionIdentifier ::= OCTET STRING (SIZE (1..25)) -- It is recommended to use ASCII characters in "a"…"z", "A"…"Z", "-", "_", ".", and "0"…"9". -- For subaddress option only "0"..."9" shall be used. GPRSCorrelationNumber ::= OCTET STRING (SIZE(8..20)) END -- OF Umts-HI3-PS

IPAccess – WLAN, xDSL (HI2, HI3)

PS-PDU ::= SEQUENCE { pSHeader [1] PSHeader, payload [2] Payload } PSHeader ::= SEQUENCE { li-psDomainId [0] OBJECT IDENTIFIER, lawfulInterceptionIdentifier [1] LawfulInterceptionIdentifier, authorizationCountryCode [2] PrintableString (SIZE (2)) OPTIONAL, -- see clause 5.2.3 communicationIdentifier [3] CommunicationIdentifier, sequenceNumber [4] INTEGER (0..4294967295), timeStamp [5] GeneralizedTime OPTIONAL, -- see clause 5.2.6 ..., interceptionPointID [6] PrintableString (SIZE (1..8)) OPTIONAL, -- see clause 5.2.11 Payload ::= CHOICE { iRIPayloadSequence [0] SEQUENCE OF IRIPayload, cCPayloadSequence [1] SEQUENCE OF CCPayload, ... } CommunicationIdentifier ::= SEQUENCE { networkIdentifier [0] NetworkIdentifier, communicationIdentityNumber [1] INTEGER (0..4294967295) OPTIONAL, -- in case of transport of HI1 messages not required -- Mandatory for CC and IRI, with certain exceptions (see 5.2.4) deliveryCountryCode [2] PrintableString (SIZE (2)) OPTIONAL, -- see clause 5.2.4 ... } NetworkIdentifier ::= SEQUENCE { operatorIdentifier [0] OCTET STRING (SIZE(1..16)), networkElementIdentifier [1] OCTET STRING (SIZE(1..16)) OPTIONAL, ...,

5

eTSI671NEID [2] Network-Element-Identifier OPTIONAL -- For Network Element Identifier, use either OCTET STRING or ETSI671 definition }

IRIPayload ::= SEQUENCE { iRIType [0] IRIType OPTIONAL, -- See clause 5.2.10 timeStamp [1] GeneralizedTime OPTIONAL, -- For aggregated payloads (see clause 6.2.3) iRIContents [2] IRIContents, ... } IRIType ::= ENUMERATED { iRI-Begin(1), iRI-End(2), iRI-Continue(3), iRI-Report(4) } IRIContents ::= CHOICE -- Any of these choices may be commented out if they are not being used (see clause A.3) { undefinedIRI [0] OCTET STRING, emailIRI [1] EmailIRI, iPIRI [2] IPIRI, iPIRIOnly [3] IPIRIOnly, --NOT USED uMTSIRI [4] UMTSIRI, eTSI671IRI [5] ETSI671IRI, ..., l2IRI [6] L2IRI, l2IRIOnly [7] L2IRIOnly, tARGETACTIVITYMONITOR-1 [8] TS101909201.TARGETACTIVITYMONITOR-1, tARGETACTIVITYMONITOR-2 [9] TS101909202.TARGETACTIVITYMONITOR, pstnIsdnIRI [10] PstnIsdnIRI, iPMMIRI [11] IPMMIRI } UMTSIRI ::= CHOICE -- not used { iRI-Parameters [0] UmtsHI2Operations.IRI-Parameters, umtsIRIsContent [1] UmtsIRIsContent, ... } ETSI671IRI ::= CHOICE -- not used { iRI-Parameters [0] HI2Operations.IRI-Parameters, iRIsContent [1] IRIsContent, ... } IPIRI ::= SEQUENCE { iPIRIObjId [0] RELATIVE-OID, iPIRIContents [1] IPIRIContents, ...

6

} IPIRIContents ::= SEQUENCE { accessEventType [0] AccessEventType, targetUsername [1] OCTET STRING, -- in ASCII-characters internetAccessType [2] InternetAccessType, iPVersion [3] IPVersion, targetIPAddress [4] IPAddress OPTIONAL, -- IP address may not be available in case of failed logon attempts. -- If it is available, it must be sent. targetNetworkID [5] UTF8String (SIZE (1..20)) OPTIONAL, -- Target network ID (e.g. MAC address, PSTN number) targetCPEID [6] UTF8String (SIZE (1..128)) OPTIONAL, -- CPEID (e.g. Relay Agent info, computer name) targetLocation [7] UTF8String (SIZE (1..64)) OPTIONAL, -- When internetAccessType is Wireless LAN, this field should contain a string which -- uniquely identifies the wireless accesspoint within the SvP domain pOPPortNumber [8] INTEGER (0..4294967295) OPTIONAL, -- The POP port number used by the target. callBackNumber [9] UTF8String (SIZE (1..20)) OPTIONAL, -- The number used to call-back the target startTime [10] GeneralizedTime OPTIONAL, -- The start date-time of the session or lease endTime [11] GeneralizedTime OPTIONAL, -- The actual end date-time of the session or lease endReason [12] EndReason OPTIONAL, -- The reason for the session to end octetsReceived [13] INTEGER (0..18446744073709551615) OPTIONAL, -- The number of octets the target received octetsTransmitted [14] INTEGER (0..18446744073709551615) OPTIONAL, -- The number of octets the target transmitted rawAAAData [15] OCTET STRING OPTIONAL, -- Content of the raw AAA record ..., expectedEndTime [16] GeneralizedTime OPTIONAL, -- The expected end date-time of the session or lease pOPPhoneNumber [17] UTF8String (SIZE (1..20)) OPTIONAL, -- The phone number dialed by the target for dial-up pOPIdentifier [18] IPIRIIDType OPTIONAL, -- The identifier or name of the POP pOPIPAddress [19] IPAddress OPTIONAL -- The IP address of the POP partyExtendedIdentity [PRIVATE 1] PartyExtendedIdentity OPTIONAL, -- The same as in HI2 for CS and PS } AccessEventType ::= ENUMERATED { accessAttempt(0), -- A target requests access to the IAS accessAccept(1), -- IAS access is granted to the target, the session begins accessReject(2), -- IAS access is refused to the target accessFailed(3), -- The Access_attempt timed-out or failed otherwise sessionStart(4), -- A target starts using the IAS; not in use anymore from version 4(4). sessionEnd(5), -- A target stops using the IAS; not in use anymore from version 4(4). interimUpdate(6), -- Intermediate status report on service status or usage ..., startOfInterceptionWithSessionActive(7), -- LI is started on a target who already has an active session

7

accessEnd(8) -- A target stops using the IAS, the session ends. } InternetAccessType ::= ENUMERATED { undefined(0), dialUp(1), -- IAS via DialUp access xDSL(2), -- IAS via DSL access cableModem(3), -- IAS via Cable access lAN(4), -- IAS via LAN access ..., wirelessLAN(5) -- IAS via Wireless LAN access } IPVersion ::= ENUMERATED { iPV4(1), -- The IPv4 protocol is used iPV6(2) -- The IPv6 protocol is used } EndReason ::= ENUMERATED { undefined(0), regularLogoff(1), -- The target logged off connectionLoss(2), -- The connection was lost connectionTimeout(3), -- The connection timed-out leaseExpired(4), -- The DHCP lease expired ... } IPIRIIDType ::= CHOICE { printableIDType [0] UTF8String (SIZE (1..128)), -- For printable userIDs, such as the Radius username, phonenumbers macAddressType [1] OCTET STRING (SIZE (6)), -- For MAC address types, raw binary format as in RFC 2132 [15] ipAddressType [2] IPAddress, -- For IP address types ... }

IPIRIOnly ::= SEQUENCE { iPIRIOnlyObjId [0] RELATIVE-OID, iPInformation [1] IPInformation, protocolInformation [2] ProtocolInformation, iPAggregatedNbrOfPackets [3] INTEGER OPTIONAL, iPAggregatedNbrOfBytes [4] INTEGER OPTIONAL, ... partyExtendedIdentity [PRIVATE 1] PartyExtendedIdentity OPTIONAL, -- The same as in HI2 for CS and PS }

8

IPInformation ::= CHOICE { iPv4Information [0] IPv4Information, iPv6Information [1] IPv6Information } ProtocolInformation ::= CHOICE { none [0] NULL, -- No layer 4 protocol information is provided tCPInformation [1] TCPInformation, uDPInformation [2] UDPInformation, ... } IPv4Information ::= SEQUENCE { headerLength [0] OCTET STRING OPTIONAL, typeOfService [1] OCTET STRING OPTIONAL, totalLength [2] OCTET STRING (SIZE (2))OPTIONAL, identification [3] OCTET STRING (SIZE (2))OPTIONAL, fragment [4] OCTET STRING (SIZE (2))OPTIONAL, ttl [5] OCTET STRING OPTIONAL, protocol [6] OCTET STRING OPTIONAL, headerChecksum [7] OCTET STRING (SIZE (2))OPTIONAL, source [8] OCTET STRING (SIZE (4)), destination [9] OCTET STRING (SIZE (4)), options [10] OCTET STRING (SIZE (0..40))OPTIONAL } IPv6Information ::= SEQUENCE { trafficClass [0] OCTET STRING OPTIONAL, flowLabel [1] OCTET STRING (SIZE (20))OPTIONAL, payloadLength [2] OCTET STRING (SIZE (4))OPTIONAL, nextHeader [3] OCTET STRING OPTIONAL, hopLimit [4] OCTET STRING OPTIONAL, source [5] OCTET STRING (SIZE (16)), destination [6] OCTET STRING (SIZE (16)) } TCPInformation ::= SEQUENCE { sourcePort [0] OCTET STRING (SIZE (2))OPTIONAL, destinationPort [1] OCTET STRING (SIZE (2))OPTIONAL, sequenceNumber [2] OCTET STRING (SIZE (4))OPTIONAL, ackNumber [3] OCTET STRING (SIZE (4))OPTIONAL, dataOffset [4] BIT STRING (SIZE (4))OPTIONAL, -- First 4 bits controlBits [5] BIT STRING (SIZE (6))OPTIONAL, -- Last 6 bits windowSize [6] OCTET STRING (SIZE (2))OPTIONAL, checkSum [7] OCTET STRING (SIZE (2))OPTIONAL, urgentPointer [8] OCTET STRING (SIZE (2))OPTIONAL, options [9] OCTET STRING (SIZE (0..40))OPTIONAL } UDPInformation ::= SEQUENCE { sourcePort [0] OCTET STRING (SIZE (2))OPTIONAL, destinationPort [1] OCTET STRING (SIZE (2))OPTIONAL, length [2] OCTET STRING (SIZE (2))OPTIONAL, checkSum [3] OCTET STRING (SIZE (2))OPTIONAL }

9

CCPayload ::= SEQUENCE { payloadDirection [0] PayloadDirection OPTIONAL, timeStamp [1] GeneralizedTime OPTIONAL, -- For aggregated payloads (see clause 6.2.3) cCContents [2] CCContents, ..., microSecondTimeStamp [3] MicroSecondTimeStamp OPTIONAL -- For aggregated payloads (see clause 6.2.3) } PayloadDirection ::= ENUMERATED { fromTarget(0), toTarget(1), ..., indeterminate(2), -- Indication whether intercepted CC was travelling to or from the target -- or that the direction was indeterminate combined(3), -- Indication applicable to some services that the traffic is actually a combination -- of To and From notapplicable(4) -- Indication that direction of interceptable service does not make sense } CCContents ::= CHOICE -- Any of these choices may be commented out if they are not being used, see clause A.3 { undefinedCC [0] OCTET STRING, emailCC [1] EmailCC, iPCC [2] IPCC, uMTSCC [4] OCTET STRING, eTSI671CC [5] OCTET STRING, ..., l2CC [6] L2CC, tTRAFFIC-1 [7] TS101909201.TTRAFFIC, cTTRAFFIC-1 [8] TS101909201.CTTRAFFIC, tTRAFFIC-2 [9] TS101909202.TTRAFFIC, cTTRAFFIC-2 [10] TS101909202.CTTRAFFIC, pstnIsdnCC [11] PstnIsdnCC, iPMMCC [12] IPMMCC } MicroSecondTimeStamp ::= SEQUENCE { seconds [0] INTEGER (0..18446744073709551615), -- number of seconds since 1970-1-1 00:00Z also known as unix time epoch microSeconds [1] INTEGER (0..999999), ... } IPCC ::= SEQUENCE { iPCCObjId [0] RELATIVE-OID, iPCCContents [1] IPCCContents } IPCCContents ::= CHOICE { iPPackets [0] OCTET STRING, ... }

10

IV. HI3 (PS only)

Umts-HI3-PS {itu-t(0) identified-organization(4) etsi(0) securityDomain(2) lawfulintercept(2) threeGPP(4) hi3(2) r6(6) version-3(3)} DEFINITIONS IMPLICIT TAGS ::= BEGIN -- Object Identifier Definitions -- Security DomainId lawfulInterceptDomainId OBJECT IDENTIFIER ::= {itu-t(0) identified-organization(4) etsi(0) securityDomain(2) lawfulIntercept(2)} -- Security Subdomains threeGPPSUBDomainId OBJECT IDENTIFIER ::= {lawfulInterceptDomainId threeGPP(4)} hi3DomainId OBJECT IDENTIFIER ::= {threeGPPSUBDomainId hi3(2) r6(6) version-3(3)} CC-PDU ::= SEQUENCE { uLIC-header [1] ULIC-header, payload [2] OCTET STRING } ULIC-header ::= SEQUENCE { hi3DomainId [0] OBJECT IDENTIFIER, -- 3GPP HI3 Domain version [1] Version, lIID [2] LawfulInterceptionIdentifier OPTIONAL, correlation-Number [3] GPRSCorrelationNumber, timeStamp [4] TimeStamp OPTIONAL, sequence-number [5] INTEGER (0..65535), t-PDU-direction [6] TPDU-direction, ..., national-HI3-ASN1parameters [7] National-HI3-ASN1parameters OPTIONAL, -- encoded per national requirements ice-type [8] ICE-type OPTIONAL

11

-- The ICE-type indicates the applicable Intercepting Control Element(see ref [19]) in which -- the T-PDU is intercepted. } Version ::= ENUMERATED { version1(1), ..., version3(3) } TPDU-direction ::= ENUMERATED { from-target (1), to-target (2), unknown (3) } National-HI3-ASN1parameters ::= SEQUENCE { countryCode [1] PrintableString (SIZE (2)), -- Country Code according to ISO 3166-1 [39], -- the country to which the parameters inserted after the extension marker apply ... -- In case a given country wants to use additional national parameters according to its law, -- these national parameters should be defined using the ASN.1 syntax and added after the -- extension marker (...). -- It is recommended that "version parameter" and "vendor identification parameter" are -- included in the national parameters definition. Vendor identifications can be -- retrieved from IANA web site. } ICE-type ::= ENUMERATED { sgsn (1), ggsn (2), ... } LocalTimeStamp ::= SEQUENCE { generalizedTime [0] GeneralizedTime, -- The minimum resolution required is one second.

12

-- "Resolution" is the smallest incremental change that can be measured for time and -- is expressed with a definite number of decimal digits or bits. winterSummerIndication [1] ENUMERATED { notProvided(0), winterTime(1), summerTime(2), ... } } TimeStamp ::= CHOICE { -- The minimum resolution required is one second. -- "Resolution" is the smallest incremental change that can be measured for time and -- is expressed with a definite number of decimal digits or bits. localTime [0] LocalTimeStamp, utcTime [1] UTCTime } LawfulInterceptionIdentifier ::= OCTET STRING (SIZE (1..25)) -- It is recommended to use ASCII characters in "a"…"z", "A"…"Z", "-", "_", ".", and "0"…"9". -- For subaddress option only "0"..."9" shall be used. GPRSCorrelationNumber ::= OCTET STRING (SIZE(8..20)) END -- OF Umts-HI3-PS

10/36si

13

Za"#cznik nr 4 Specyfikacja techniczna styku HI-2 i 3 interfejsu HI w zakresie IPAccess (WLAN,WiFi, xDSL)

Aktywno&) abonenta powoduj#ca przesy" danych pakietowych w sieci operatora powoduje, $e system ADMF/DF wysy"a informacje skojarzone interfejsem HI2 oraz tre&) przekazu interfejsem HI3. Za korelacje informacji skojarzonych przekazu (HI2) z jego tre&ci# (HI3) odpowiada pole Communication Identity Number (CIN) umieszczone w strukturze ASN.1 interfejsu HI2 oraz HI3. CIN unikalny jest w ramach jednej sesji u$ytkownika. Przyklad abonent Jan Kowalski o numerze PESEL xxx przypisane ma trzy LIID w systemach LI: LIID1 – abonent Jan Kowalski o numerze 48501000000, us"uga monitorowana GSM/UMTS CS LIID2 – abonent Jan Kowalski o numerze 48501000000, us"uga monitorowana GSM/UMTS PS LIID3 – abonent Jan Kowalski o login-ie SDFG56DDSX, us"uga monitorowana xDSL

LEMF

ADMF/DF t0

HI1

LIID1 t1

forwardingAddres =48226220000 @sipgw .lemf.gov .pl

LIID2

t2

LIID3

HI1 destination data in LEMF:

HI2

GSM/UMTS CS

t3 lawfulInterceptionIdentifier =LIID1 communication -Identity -Number =CIN1 (rozpoczecie rozmowy do abonenta B )

t5

GSM/UMTS PS

lawfulInterceptionIdentifier =LIID2 gPRSCorrelationNumber =5 (PDP activation APN =internet )

t8

xDSL

t4 lawfulInterceptionIdentifier =LIID1 communication -Identity -Number =CIN1 (zakonczenie rozmowy z abonentem B )

t6

lawfulInterceptionIdentifier =LIID2 gPRSCorrelationNumber =6 (PDP activation APN =wap)

lawfulInterceptionIdentifier =LIID3 CIN=0 (Login to network )

t9

t7

lawfulInterceptionIdentifier =LIID 2 gPRSCorrelationNumber =5 (PDP deactivation APN =internet )

lawfulInterceptionIdentifier =LIID3 CIN=0 (Logout from network )

LIID1_seq11.1 LIID1_seq12.1

LIID2_seq1.1 LIID2_seq2.1 LIID2_seq3.1

LIID3_seq1.1 LIID3_seq2.1

HI3 GSM/UMTS CS online

t10 SIP/2.0/SDP/RTP stream 0 stream1 forwardingAddres =48226220000 @ sipgw.lemf.gov.pl SIP CALLID = LIID 1_CIN1

SIP/2.0/SDP/RTP

t11

GSM/UMTS CS t12

lawfulInterceptionIdentifier =LIID2 gPRSCorrelationNumber =5

GSM/UMTS PS xDSL

lawfulInterceptionIdentifier =LIID1 communication -Identity -Number =CIN1

t13

t14

lawfulInterceptionIdentifier =LIID3 CIN=0

LIID1_CIN1.2 (stream0 CC(MO)) LIID1_CIN1.4 (stream1 CC(MT))

ULIC protocol lawfulInterceptionIdentifier =LIID2 gPRSCorrelationNumber =6

IPCC

Rysunek 1: Przep"yw wiadomo'ci w interfejsach HI.

Przyk"adowy przep"yw wiadomo&ci w interfejsach HI, gdzie abonentowi za"o$ono monitorowanie trzech us"ug: CS z opcja online, PS oraz xDSL. t0 – za"o$enie dedykacji abonentowi X dla us"ugi GSM/UMTS CS z opcja online t1 – za"o$enie dedykacji abonentowi X dla us"ugi GSM/UMTS PS t2 - za"o$enie dedykacji abonentowi X dla us"ugi xDSL Po za"o$eniu i zaktywowaniu dedykacji w CN sieci operatora, dedykacje s# aktywne i w zale$no&ci od aktywno&ci abonenta pojawiaj# si% informacje skojarzone oraz sama tre&) przekazu. t3 – rozpocz%cie rozmowy t4 – zako'czenie rozmowy t5 – aktywowanie PDP kontekst do punktu dost%powego „Internet” t6 – aktywowanie drugiego PDP kontekst do punktu dost%powego „Wap” t7 – dezaktywacja PDP kontekstu do punktu dost%powego „Internet” t8 – zalogowanie si% do sieci dost%p xDSL t9 – wylogowanie si% z sieci dost%p xDSL Tre&) przekazu zostaje przes"ana zgodnie z informacjami skojarzonymi, z którymi s# powi#zane. t10 – zestawienie po"#czenia SIP do uprawnionego podmiotu z tre&ci# rozmowy w trybie online t11 – dodatkowo tre&) rozmowy przes"ania w trybie offline (stereo) t12 – tre&) przekazu (dane IP) generowane do punktu dost%powego „Internet” t13 - tre&) przekazu (dane IP) generowane do punktu dost%powego „Wap” t14 – tre&) przekazu (dane IP) przez xDSL Informacje skojarzone zosta"y dostarczone FTP w postaci plików o okre&lonych nazwach kojarzonych z zawarto&ci# do systemu LEMF. Tre&ci przekazu zosta"y dostarczone wykorzystuj#c ró$ne techniki przesy"u informacji w zale$no&ci rodzaju danych. PS-PDU ::= SEQUENCE { pSHeader [1] PSHeader, payload [2] Payload } PSHeader ::= SEQUENCE { li-psDomainId [0] OBJECT IDENTIFIER, lawfulInterceptionIdentifier [1] LawfulInterceptionIdentifier, authorizationCountryCode [2] PrintableString (SIZE (2)) OPTIONAL, -- see clause 5.2.3 communicationIdentifier [3] CommunicationIdentifier, sequenceNumber [4] INTEGER (0..4294967295), timeStamp [5] GeneralizedTime OPTIONAL, -- see clause 5.2.6 ..., interceptionPointID [6] PrintableString (SIZE (1..8)) OPTIONAL, -- see clause 5.2.11

2

Payload ::= CHOICE { iRIPayloadSequence [0] SEQUENCE OF IRIPayload, cCPayloadSequence [1] SEQUENCE OF CCPayload, ... } CommunicationIdentifier ::= SEQUENCE { networkIdentifier [0] NetworkIdentifier, communicationIdentityNumber [1] INTEGER (0..4294967295) OPTIONAL, -- in case of transport of HI1 messages not required -- Mandatory for CC and IRI, with certain exceptions (see 5.2.4) deliveryCountryCode [2] PrintableString (SIZE (2)) OPTIONAL, -- see clause 5.2.4 ... }

NetworkIdentifier ::= SEQUENCE { operatorIdentifier [0] OCTET STRING (SIZE(1..16)), networkElementIdentifier [1] OCTET STRING (SIZE(1..16)) OPTIONAL, ..., eTSI671NEID [2] Network-Element-Identifier OPTIONAL -- For Network Element Identifier, use either OCTET STRING or ETSI671 definition }

IRIPayload ::= SEQUENCE { iRIType [0] IRIType OPTIONAL, -- See clause 5.2.10 timeStamp [1] GeneralizedTime OPTIONAL, -- For aggregated payloads (see clause 6.2.3) iRIContents [2] IRIContents, ... } IRIType ::= ENUMERATED { iRI-Begin(1), iRI-End(2), iRI-Continue(3), iRI-Report(4) } IRIContents ::= CHOICE -- Any of these choices may be commented out if they are not being used (see clause A.3) { undefinedIRI [0] OCTET STRING, emailIRI [1] EmailIRI, iPIRI [2] IPIRI, iPIRIOnly [3] IPIRIOnly, --NOT USED uMTSIRI [4] UMTSIRI, eTSI671IRI [5] ETSI671IRI, ..., l2IRI [6] L2IRI, l2IRIOnly [7] L2IRIOnly, tARGETACTIVITYMONITOR-1 [8] TS101909201.TARGETACTIVITYMONITOR-1, tARGETACTIVITYMONITOR-2 [9] TS101909202.TARGETACTIVITYMONITOR, pstnIsdnIRI [10] PstnIsdnIRI,

3

iPMMIRI [11] IPMMIRI } UMTSIRI ::= CHOICE -- not used { iRI-Parameters [0] UmtsHI2Operations.IRI-Parameters, umtsIRIsContent [1] UmtsIRIsContent, ... } ETSI671IRI ::= CHOICE -- not used { iRI-Parameters [0] HI2Operations.IRI-Parameters, iRIsContent [1] IRIsContent, ... } IPIRI ::= SEQUENCE { iPIRIObjId [0] RELATIVE-OID, iPIRIContents [1] IPIRIContents, ... } IPIRIContents ::= SEQUENCE { accessEventType [0] AccessEventType, targetUsername [1] OCTET STRING, -- in ASCII-characters internetAccessType [2] InternetAccessType, iPVersion [3] IPVersion, targetIPAddress [4] IPAddress OPTIONAL, -- IP address may not be available in case of failed logon attempts. -- If it is available, it must be sent. targetNetworkID [5] UTF8String (SIZE (1..20)) OPTIONAL, -- Target network ID (e.g. MAC address, PSTN number) targetCPEID [6] UTF8String (SIZE (1..128)) OPTIONAL, -- CPEID (e.g. Relay Agent info, computer name) targetLocation [7] UTF8String (SIZE (1..64)) OPTIONAL, -- When internetAccessType is Wireless LAN, this field should contain a string which -- uniquely identifies the wireless accesspoint within the SvP domain pOPPortNumber [8] INTEGER (0..4294967295) OPTIONAL, -- The POP port number used by the target. callBackNumber [9] UTF8String (SIZE (1..20)) OPTIONAL, -- The number used to call-back the target startTime [10] GeneralizedTime OPTIONAL, -- The start date-time of the session or lease endTime [11] GeneralizedTime OPTIONAL, -- The actual end date-time of the session or lease endReason [12] EndReason OPTIONAL, -- The reason for the session to end octetsReceived [13] INTEGER (0..18446744073709551615) OPTIONAL, -- The number of octets the target received octetsTransmitted [14] INTEGER (0..18446744073709551615) OPTIONAL, -- The number of octets the target transmitted rawAAAData [15] OCTET STRING OPTIONAL, -- Content of the raw AAA record ..., expectedEndTime [16] GeneralizedTime OPTIONAL, -- The expected end date-time of the session or lease pOPPhoneNumber [17] UTF8String (SIZE (1..20)) OPTIONAL, -- The phone number dialed by the target for dial-up pOPIdentifier [18] IPIRIIDType OPTIONAL, -- The identifier or name of the POP

4

pOPIPAddress [19] IPAddress OPTIONAL -- The IP address of the POP partyExtendedIdentity [PRIVATE 1] PartyExtendedIdentity OPTIONAL, -- The same as in HI2 for CS and PS } AccessEventType ::= ENUMERATED { accessAttempt(0), -- A target requests access to the IAS accessAccept(1), -- IAS access is granted to the target, the session begins accessReject(2), -- IAS access is refused to the target accessFailed(3), -- The Access_attempt timed-out or failed otherwise sessionStart(4), -- A target starts using the IAS; not in use anymore from version 4(4). sessionEnd(5), -- A target stops using the IAS; not in use anymore from version 4(4). interimUpdate(6), -- Intermediate status report on service status or usage ..., startOfInterceptionWithSessionActive(7), -- LI is started on a target who already has an active session accessEnd(8) -- A target stops using the IAS, the session ends. } InternetAccessType ::= ENUMERATED { undefined(0), dialUp(1), -- IAS via DialUp access xDSL(2), -- IAS via DSL access cableModem(3), -- IAS via Cable access lAN(4), -- IAS via LAN access ..., wirelessLAN(5) -- IAS via Wireless LAN access } IPVersion ::= ENUMERATED { iPV4(1), -- The IPv4 protocol is used iPV6(2) -- The IPv6 protocol is used } EndReason ::= ENUMERATED { undefined(0), regularLogoff(1), -- The target logged off connectionLoss(2), -- The connection was lost connectionTimeout(3), -- The connection timed-out leaseExpired(4), -- The DHCP lease expired ... }

5

IPIRIIDType ::= CHOICE { printableIDType [0] UTF8String (SIZE (1..128)), -- For printable userIDs, such as the Radius username, phonenumbers macAddressType [1] OCTET STRING (SIZE (6)), -- For MAC address types, raw binary format as in RFC 2132 [15] ipAddressType [2] IPAddress, -- For IP address types ... }

IPIRIOnly ::= SEQUENCE { iPIRIOnlyObjId [0] RELATIVE-OID, iPInformation [1] IPInformation, protocolInformation [2] ProtocolInformation, iPAggregatedNbrOfPackets [3] INTEGER OPTIONAL, iPAggregatedNbrOfBytes [4] INTEGER OPTIONAL, ... partyExtendedIdentity [PRIVATE 1] PartyExtendedIdentity OPTIONAL, -- The same as in HI2 for CS and PS } IPInformation ::= CHOICE { iPv4Information [0] IPv4Information, iPv6Information [1] IPv6Information } ProtocolInformation ::= CHOICE { none [0] NULL, -- No layer 4 protocol information is provided tCPInformation [1] TCPInformation, uDPInformation [2] UDPInformation, ... } IPv4Information ::= SEQUENCE { headerLength [0] OCTET STRING OPTIONAL, typeOfService [1] OCTET STRING OPTIONAL, totalLength [2] OCTET STRING (SIZE (2))OPTIONAL, identification [3] OCTET STRING (SIZE (2))OPTIONAL, fragment [4] OCTET STRING (SIZE (2))OPTIONAL, ttl [5] OCTET STRING OPTIONAL, protocol [6] OCTET STRING OPTIONAL, headerChecksum [7] OCTET STRING (SIZE (2))OPTIONAL, source [8] OCTET STRING (SIZE (4)), destination [9] OCTET STRING (SIZE (4)), options [10] OCTET STRING (SIZE (0..40))OPTIONAL } IPv6Information ::= SEQUENCE { trafficClass [0] OCTET STRING OPTIONAL, flowLabel [1] OCTET STRING (SIZE (20))OPTIONAL, payloadLength [2] OCTET STRING (SIZE (4))OPTIONAL, nextHeader [3] OCTET STRING OPTIONAL, hopLimit [4] OCTET STRING OPTIONAL, source [5] OCTET STRING (SIZE (16)), destination [6] OCTET STRING (SIZE (16)) }

6

TCPInformation ::= SEQUENCE { sourcePort [0] OCTET STRING (SIZE (2))OPTIONAL, destinationPort [1] OCTET STRING (SIZE (2))OPTIONAL, sequenceNumber [2] OCTET STRING (SIZE (4))OPTIONAL, ackNumber [3] OCTET STRING (SIZE (4))OPTIONAL, dataOffset [4] BIT STRING (SIZE (4))OPTIONAL, -- First 4 bits controlBits [5] BIT STRING (SIZE (6))OPTIONAL, -- Last 6 bits windowSize [6] OCTET STRING (SIZE (2))OPTIONAL, checkSum [7] OCTET STRING (SIZE (2))OPTIONAL, urgentPointer [8] OCTET STRING (SIZE (2))OPTIONAL, options [9] OCTET STRING (SIZE (0..40))OPTIONAL } UDPInformation ::= SEQUENCE { sourcePort [0] OCTET STRING (SIZE (2))OPTIONAL, destinationPort [1] OCTET STRING (SIZE (2))OPTIONAL, length [2] OCTET STRING (SIZE (2))OPTIONAL, checkSum [3] OCTET STRING (SIZE (2))OPTIONAL }

CCPayload ::= SEQUENCE { payloadDirection [0] PayloadDirection OPTIONAL, timeStamp [1] GeneralizedTime OPTIONAL, -- For aggregated payloads (see clause 6.2.3) cCContents [2] CCContents, ..., microSecondTimeStamp [3] MicroSecondTimeStamp OPTIONAL -- For aggregated payloads (see clause 6.2.3) } PayloadDirection ::= ENUMERATED { fromTarget(0), toTarget(1), ..., indeterminate(2), -- Indication whether intercepted CC was travelling to or from the target -- or that the direction was indeterminate combined(3), -- Indication applicable to some services that the traffic is actually a combination -- of To and From notapplicable(4) -- Indication that direction of interceptable service does not make sense } CCContents ::= CHOICE -- Any of these choices may be commented out if they are not being used, see clause A.3 { undefinedCC [0] OCTET STRING, emailCC [1] EmailCC, iPCC [2] IPCC, uMTSCC [4] OCTET STRING, eTSI671CC [5] OCTET STRING, ..., l2CC [6] L2CC, tTRAFFIC-1 [7] TS101909201.TTRAFFIC, cTTRAFFIC-1 [8] TS101909201.CTTRAFFIC, tTRAFFIC-2 [9] TS101909202.TTRAFFIC, cTTRAFFIC-2 [10] TS101909202.CTTRAFFIC, pstnIsdnCC [11] PstnIsdnCC, iPMMCC [12] IPMMCC

7

} MicroSecondTimeStamp ::= SEQUENCE { seconds [0] INTEGER (0..18446744073709551615), -- number of seconds since 1970-1-1 00:00Z also known as unix time epoch microSeconds [1] INTEGER (0..999999), ... } IPCC ::= SEQUENCE { iPCCObjId [0] RELATIVE-OID, iPCCContents [1] IPCCContents } IPCCContents ::= CHOICE { iPPackets [0] OCTET STRING, ... }

10/37si 8

Za"#cznik nr 5 Koncepcja Podpisu Elektronicznego Wybrane $#dania HI1, po ich przygotowaniu w LEMF, s# podpisywane elektronicznie przez u$ytkownika LEMF. U$ytkownik do podpisu $#dania wykorzystuje swój indywidualny klucz prywatny oraz certyfikat X.509, który przyporz#dkowuje dane identyfikuj#ce u$ytkownika do jego klucza publicznego. Enkapsulowane $#danie HI1, wraz z podpisem elektronicznym jest przesy"ane do ADMF. By ADMF móg" sprawdzi) podpis elektroniczny $#dania HI1 z"o$ony przez u$ytkownika LEMF konieczne jest by obie strony: LEMF i ADMF, wykorzystywa"y ten sam format (sk"adnie) podpisu elektronicznego. Formatem tym jest CMS (Cryptographics Message Syntax) zdefiniowany w [RFC3852]. Podpisywanie $#dania HI1 przez u$ytkownika LEMF jest mo$liwe pod warunkiem posiadania przez niego indywidualnego klucza prywatnego oraz certyfikatu X.509. Równie$ ADMF musi posiada) pewn# wiedz% o certyfikatach u$ytkowników LEMF, by móc sprawdza) poprawno&) podpisów elektronicznych. Dla tego celu wykorzystuje si% infrastruktur% klucza publicznego PKI. Indywidualne certyfikaty X.509 u$ytkowników systemu LEMF s# wystawiane przez CA (urz#d ds. certyfikatów) w instytucji, która administruje i u$ytkuje dany system LEMF. Certyfikat tego CA jest jednocze&nie dost%pny w systemie ADMF administrowanego przez operatora. Zarz#dzanie certyfikatami X.509, listami CRL oraz infrastruktur# klucza publicznego PKI zosta"o opisane w osobnym punkcie. Poni$szy rysunek pogl#dowo przedstawia enkapsulowanie w HI1LEMFPDU struktury CMS zawieraj#cej tre&) $#dania HI1 oraz podpis, zakodowane z wykorzystaniem DER (cmsDERSignedRequest). HI1LEMFPDU Content Request

SignedRequest OCTET STRING struktura CMS zakodowana DER (cmsDERSignedRequest)

Rysunek 1: Enkapsulowanie podpisanego %&dania HI1 w Hi1LEMFPDU Poni$szy rysunek pogl#dowo przedstawia enkapsulowanie $#dania HI1 (Command) i jego podpisu (SignatureValue) w cmsDERSignedRequest:

OCTET STRING struktura CMS zakodowana DER (cmsDERSignedRequest)

ContetnInfo (SignedData)

EncapsulatedContentInfo Data UnsignedRequestDetail

Command

SignerInfo

SignatureValue

Rysunek 2: Enkapsulowanie %&dania HI1 i jego podpisu w strukturze CMS

Wykorzystywane standardy

[RFC3852] Housley, R., „Cryptographic Message Syntax (CMS)”, RFC 3852, July 2004. [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002. [RFC3279] Bassham, L., Polk, W., R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation Lists CRL Profile", RFC 3279, April 2002. [RFC3280] Housley, R., Polk, T, Ford, W., Solo, D., "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC3281] Farrell, S., Housley, R., "An Internet Attribute Certificate Profile for Authorization", RFC3281, April 2002. [RFC4055] Housley, R., Kaliski, B., Schaad, J., "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005. [RFC3447] Jonsson, J., Kaliski, B., "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. [RFC3126] Pinkas D., Ross J., Pope N. "Electronic Signature Formats for long term electronic signatures", RFC 3126, September 2001 2

Wiadomo'ci przesy"ane w Hi1, które wymagaj& podpisania

Nast%puj#ce $#dania, przesy"ane z LEMF do ADMF, mog# i musz# by) podpisane elektronicznie: )#activate, )#deactivate, )#modificate. (#dania te s# polami wyboru typu Command: Command ::= CHOICE { activate [1] Activate, deactivate [2] Deactivate, modificate [3] Modificate, ... } Pole command oraz pole time, które okre&la czas z"o$enia podpisu, wchodz# w sk"ad typu UnsignedRequestDetail: UnsignedRequestDetail ::= SEQUENCE { time [1] TimeStamp, command [3] Command, ... } Zawarto&) pola typu UnsignedRequestDetail wraz z podpisem tego pola jest zapisywane w strukturze CMS. Format podpisanego %&dania Hi1

Na potrzeby podpisu elektronicznego stosuje si% format Cryptographics Message Syntax (CMS) zdefiniowany w [RFC3852]. Struktura CMS jest identyfikowana przez nast%puj#cy OID: CryptographicMessageSyntax2004 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }. Struktura CMS zapisywana jest, z wykorzystaniem kodowania DER, w polu cmsDERSignedRequest typu SignedRequest: SignedRequest ::= SEQUENCE { version [1] SignedRequestVersion, signStandard [2] OBJECT IDENTIFIER, -- CryptographicMessageSyntax2004 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } cmsDERSignedRequest [3] OCTET STRING -- cmsDERSignedRequest [3] ANY DEFINED BY signStandard }

3

SignedRequestVersion ::= INTEGER { v1 (0) } W kolejnych punktach przybli$ono najwa$niejsze elementy struktury CMS. Pe"ny opis specyfikacji znajduje si% w [RFC3852]. Typ ContentInfo

Podstawowym typem dla CMS jest ContentInfo. Typ ten jest identyfikowany przez nast%puj#cy OID: id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) memberbody(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 } Typ ContentInfo zosta" zdefiniowany nast%puj#co: ContentInfo ::= SEQUENCE { contentType ContentType, content [0] EXPLICIT ANY DEFINED BY contentType } ContentType ::= OBJECT IDENTIFIER Pole contentType musi identyfikowa) typ SignedData, okre&lony przez nast%puj#cy identyfikator OID: id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } Typ ContentInfo zosta"o opisany w [RFC3852], pkt 3. Typ SignedData

Typ SignedData struktury CMS sk"ada si% z zawarto&ci dowolnego typu oraz podpisów elektronicznych tej zawarto&ci. Typ SignedData zosta" zdefiniowany nast%puj#co: SignedData ::= SEQUENCE { version CMSVersion, digestAlgorithms DigestAlgorithmIdentifiers, encapContentInfo EncapsulatedContentInfo, certificates [0] IMPLICIT CertificateSet OPTIONAL, crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, signerInfos SignerInfos } Pole digestAlgorithms zawiera zbiór identyfikatorów algorytmów funkcji skrótu. Wymagania dotycz#ce tych algorytmów zosta"y opisana w pkt. 0 Pole encapContentInfo zawiera tre&) $#dania Hi1, która wymaga podpisania. Pole certificates zawiera zbiór certyfikatów niezb%dnych do okre&lenia poprawno&ci podpisów znajduj#cych si% w polu signersInfos. Opcjonalne pole crls zawiera zbiór list uniewa$nionych i zawieszonych certyfikatów (ang. 4

Certificate Revocation List - CRL). Na potrzeby zarz#dzania certyfikatami i listami CRL wykorzystuje si% infrastruktur% klucza publicznego PKI. PKI oraz formaty certyfikatów i list CRL zosta"y opisane w osobnym punkcie. Pole signerInfos jest zbiorem podpisów elektronicznych. Typ SignedData zosta"o opisany w [RFC3852], pkt 5.1. EncapsulatedContentInfo

Typ EncapsulatedContentInfo zosta" zdefiniowany nast%puj#co: EncapsulatedContentInfo ::= SEQUENCE { eContentType ContentType, eContent [0] EXPLICIT OCTET STRING OPTIONAL } ContentType ::= OBJECT IDENTIFIER Pole eContentType musi identyfikowa) typ data: id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } Pole eContent zawiera $#danie HI1 przeznaczone do podpisania w postaci UnsignedRequestDetail. Typ EncapsulatedContentInfo zosta" opisany w [RFC3852], pkt 5.2 Typ SignerInfo

Typ SignerInfo zosta" zdefiniowany nast%puj#co: SignerInfo ::= SEQUENCE { version CMSVersion, sid SignerIdentifier, digestAlgorithm DigestAlgorithmIdentifier, signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, signatureAlgorithm SignatureAlgorithmIdentifier, signature SignatureValue, unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } Pole sid identyfikuje certyfikat podmiotu, który z"o$y" podpis. Zgodnie z [RFC3852], pkt 5.3 musz# zosta) zaimplementowane obie formy SignerIdentifier: issuerAndSerialNumber oraz subjectKeyIdentifier. Pole digestAlgorithm zawiera identyfikator zastosowanego algorytmu funkcji skrótu. Wymagania dotycz#ce algorytmów funkcji skrótu zosta"y opisana w pkt. 0 Pole signedAttrs zawiera zbiór atrybutów, które s# podpisywane. Zalecane jest, by wykorzystywany by" atrybut okre&laj#cy czas z"o$enia podpisu. Ponadto w polu tym zostanie zawarta informacja o rodzaju zobowi#zania (ang. commitment type) poprzez umieszczenie identyfikatora obiektu: commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 1 } wskazuj#cego, $e podpisuj#cy pracownik LEA stworzy", zaaprobowa" i wys"a" podpisan# wiadomo&) ([RFC3126], pkt 3.12.1). Pole signatureAlgorithm zawiera identyfikator zastosowanego algorytmu podpisu elektronicznego. Wymagania dotycz#ce algorytmów podpisów elektronicznych zosta"y opisane w pkt 0 Pole signature typu SignatureValue zawiera wyliczon# warto&) podpisu elektronicznego dla tre&ci 5

$#dania Hi1. Opcjonalne pole unsignedAttrs zawiera zbiór atrybutów, które nie s# podpisywane. Typ SignerInfo zosta" opisany w [RFC3852], pkt 5.3 Algorytmy kryptograficzne Algorytmy funkcji skrótu

Identyfikatory stosowanych algorytmów funkcji skrótu okre&lone s# w polu digestAlgorithms typu SignedData oraz w polu digestAlgorithm typu SignerInfo. Alogorytmy funkcji skrótu, które musz# by) obs"ugiwane przez ADMF w celu zapewnienia mo$liwo&ci wyliczenia skrótu na potrzeby sprawdzenia podpisu elektronicznego zosta"y wyspecyfikowane w tabeli poni$ej: lp . 1. 2.

Algorytm

Identyfikator obiektu OID

Dokument okre'laj&cy OID

SHA-1 (id-sha1) SHA-224 (id-sha224)

{ iso(1) identified-organization(3) oiw(14) secsig(3) algorithms(2) 26 } { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 4 } { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 1 } { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 2 } { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 3 } { iso(1) identifiedOrganization(3) teletrust(36) algorithm(3) hashAlgorithm(2) 1 }

[RFC3370] [RFC4055] [RFC4055]

3.

SHA-256 (id-sha256)

4.

SHA-384 (id-sha348)

5.

SHA-512 (id-sha512)

6.

RIPEMD-160 (idripemd160)

7.

RIPEMD-256 (idripemd256)

{ iso(1) identified-organization(3) teletrust(36) algorithm(3) hashAlgorithm(2) ripemd256(3) }

[RFC4055] [RFC4055] [RFC4055] http://homes.esat.kuleuven.be/~bosselae/r ipemd160.html http://www.teletrust.de/index.php?id=513 http://homes.esat.kuleuven.be/~bosselae/r ipemd160.html http://www.teletrust.de/index.php?id=513

ADMF mo$e posiada) zaimplementowan# obs"ug% dodatkowych algorytmów funkcji skrótu. LEMF na potrzeby podpisów elektronicznych powinien stosowa) algorytm funkcji skrótu SHA-512 (rozwi#zanie preferowane) lub inny algorytm z rodziny SHA-2 (SHA-384, SHA-256, SHA-224) lub algorytm RIPEMD-256. Ze wzgl%du na znane s"abo&ci, algorytmu SHA-1 nie powinien by) wykorzystywany przez LEMF. Algorytmy podpisu

Identyfikator stosowanego algorytmu podpisu jest okre&lony w polu signatureAlgorithm typu SignerInfo. Algorytmy podpisu, które musz# by) obs"ugiwane przez ADMF w celu zapewnienia mo$liwo&ci sprawdzenia podpisu zosta"y wyspecyfikowane w tabeli poni$ej:

6

lp .

Algorytm

Identyfikator obiektu OID

1.

RSA (rsaEncryptio n) DSA (id-dsa)

{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1} { iso(1) member-body(2) us(840) x9-57 (10040) x9cm(4) 1 }

2.

Dokument okre'laj&cy OID [RFC3370]

D"ugo'ci klucza [bity]

[RFC3370]

1024, 2048, 4096

1024, 2048, 4096

ADMF mo$e posiada) zaimplementowan# obs"ug% dodatkowych algorytmów podpisów. LEMF na potrzeby podpisów elektronicznych powinien stosowa) algorytm podpisu RSA lub DSA o d"ugo&ci klucza przynajmniej 2048 bitów (zalecany jest algorytm RSA lub DSA o d"ugo&ci klucza 4096 bitów). Sk"adanie podpisu

Podpis sk"adany jest indywidualnie, przez uprawnionego u$ytkownika systemu LEMF. U$ytkownik ten wyposa$ony jest w indywidualn#, imienn# kart% inteligentn# lub inny „komponent techniczny”. Karta inteligentna jest no&nikiem klucza prywatnego oraz certyfikatu X.509 tego u$ytkownika. Generowanie podpisu dla zadanej wiadomo&ci ($#dania Hi1) odbywa si% na karcie inteligentnej. Generowanie (wyliczanie) podpisu odbywa si% w sposób okre&lony w [RFC3852]. Ka$de $#danie HI1 z podpisem w formacie CMS (cmsDERSignedRequest) powinno zawiera) przynajmniej jeden poprawny podpis elektroniczny. Podpis ten powinien zawiera) certyfikaty X.509 i mo$e zawiera) listy CRL. LEMF musi zapewni), $e certyfikat u$ytkownika, który podpisuje $#danie jest wa$ny w chwili sk"adania podpisu elektronicznego. Sprawdzanie poprawno'ci podpisu

Sprawdzenie poprawno&ci podpisu $#dania w HI1 odbywa si% w ADMF i w sposób okre&lony w [RFC3852]. W szczególno&ci ADMF weryfikuje ca"# &cie$k% certyfikacji pomi%dzy certyfikatem u$ytkownika LEMF, który z"o$y" podpis i certyfikatem g"ównego urz%du ds. certyfikatów CA, który jest w LEA. Realizowane s# tylko te $#dania, które zawieraj# przynajmniej jeden poprawny podpis elektroniczny. Sprawdzenie podpisu polega na znalezieniu pierwszego poprawnego podpisu elektronicznego w strukturze CMS. Oznacza to w szczególno&ci, $e $#danie, które zawiera jeden niepoprawny podpis elektroniczny (np certyfikat u$ytkownika straci" wa$no&)) i jeden poprawny podpis elektroniczny zostanie obs"u$one. Poprawno&) podpisu elektronicznego sprawdzana jest przez ADMF tylko raz, po otrzymaniu podpisanego $#dania Hi1. (#dania w HI1 musz# by) podpisane przez u$ytkownika (certyfikat wystawiony na osob% fizyczn#). (#dania podpisane przez urz#d ds. certyfikatów nie s# realizowane. W przypadku braku mo$liwo&ci stwierdzenia poprawno&ci podpisu (np. z powodu braku certyfikatu) podpis jest uznawany za niepoprawny i $#danie HI1 nie jest obs"ugiwane.

10/38si 7

Za#"cznik nr 6 1.Struktura pliku z wykazem po"#cze% abonenta telefonii stacjonarnej Poni&ej zamieszczona zosta#a struktura pliku XML proponowana jako format danych, w którym przedsi$biorca telekomunikacyjny dostarcza' powinien dane o us#ugach telekomunikacyjnych realizowanych na rzecz abonenta sieci stacjonarnej. <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:simpleType name="t_numer"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]{1,18}"/> <xs:simpleType name="t_data"> <xs:restriction base="xs:dateTime"/> <xs:simpleType name="t_nazwa"> <xs:restriction base="xs:string"> <xs:maxLength value="50"/> <xs:simpleType name="t_adres"> <xs:restriction base="xs:string"> <xs:maxLength value="200"/> <xs:simpleType name="t_dlugosc"> <xs:restriction base="xs:nonNegativeInteger"/> <xs:simpleType name="t_operator"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]{4,5}"/> <xs:simpleType name="t_lista_rodzajow"> <xs:restriction base="xs:string"> <xs:pattern value="audio|data|sms|faks"/>

<xs:simpleType name="t_lista_uslug"> <xs:restriction base="xs:string"> <xs:pattern value="cfu|cfb|cfnr|konferencja"/> <xs:complexType name="t_usluga"> <xs:sequence> <xs:element name="nazwa_uslugi" type="t_lista_uslug" maxOccurs="unbounded"/> <xs:complexType name="t_polaczenie"> <xs:all> <xs:element name="lp" type="xs:positiveInteger"/> <xs:element name="nr_zrodlowy" type="t_numer"/> <xs:element name="nr_wybrany" type="t_numer"/> <xs:element name="nr_uzyskany" type="t_numer" minOccurs="0"/> <xs:element name="czas_start" type="t_data"/> <xs:element name="dlugosc" type="t_dlugosc" minOccurs="0"/> <xs:element name="rodzaj" type="t_lista_rodzajow" minOccurs="0"/> <xs:element name="idop" type="t_operator"/> <xs:element name="uslugi" type="t_usluga" minOccurs="0"/> <xs:element name="nazwa_odb" type="t_nazwa" minOccurs="0"/> <xs:element name="adres_odb" type="t_adres" minOccurs="0"/> <xs:element name="lok_odb" type="t_adres" minOccurs="0"/> <xs:complexType name="t_polaczenia"> <xs:sequence> <xs:element name="numer" type="t_numer"/> <xs:element name="okres_od" type="t_data"/> <xs:element name="okres_do" type="t_data"/> <xs:element name="nazwa" type="t_nazwa"/> <xs:element name="adres" type="t_adres"/> <xs:element name="lokalizacja" type="t_adres"/>

2

<xs:element name="polaczenie" type="t_polaczenie" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="polaczenia" type="t_polaczenia"/>

2.Struktura pliku z wykazem po"#cze% abonenta telefonii komórkowej w zakresie po"#cze% rozpoczynanych Poni&ej zamieszczona zosta#a struktura pliku XML proponowana jako format danych, w którym przedsi$biorca telekomunikacyjny dostarcza' powinien dane o us#ugach telekomunikacyjnych realizowanych na rzecz abonenta sieci komórkowej, w odniesieniu do po#"cze% rozpoczynanych. <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:simpleType name="t_numer"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]{1,18}"/> <xs:simpleType name="t_data"> <xs:restriction base="xs:dateTime"/> <xs:simpleType name="t_nazwa"> <xs:restriction base="xs:string"> <xs:maxLength value="50"/> <xs:simpleType name="t_adres"> <xs:restriction base="xs:string"> <xs:maxLength value="200"/> <xs:simpleType name="t_dlugosc"> <xs:restriction base="xs:nonNegativeInteger"/> <xs:simpleType name="t_operator"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]{4,5}"/> <xs:simpleType name="t_imei"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]{26}"/>

3

<xs:simpleType name="t_imsi"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]{15}"/> <xs:simpleType name="t_idkraj"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]{6}"/> <xs:simpleType name="t_wspolrzedne"> <xs:restriction base="xs:string"> <xs:maxLength value="50"/> <xs:simpleType name="t_lista_rodzajow"> <xs:restriction base="xs:string"> <xs:pattern value="audio|faks|csd|sms|ems|mms|video"/> <xs:simpleType name="t_lista_uslug"> <xs:restriction base="xs:string"> <xs:pattern value="cfu|cfb|cfnr|konferencja"/> <xs:complexType name="t_usluga"> <xs:sequence> <xs:element name="nazwa_uslugi" type="t_lista_uslug" maxOccurs="unbounded"/> <xs:complexType name="t_polaczenie"> <xs:all> <xs:element name="lp" type="xs:positiveInteger"/> <xs:element name="nr_zrodlowy" type="t_numer"/> <xs:element name="nr_imsi" type="t_imsi"/> <xs:element name="nr_imei" type="t_imei"/> <xs:element name="nr_wybrany" type="t_numer"/>

4

<xs:element name="nr_uzyskany" type="t_numer" minOccurs="0"/> <xs:element name="czas_start" type="t_data"/> <xs:element name="dlugosc" type="t_dlugosc" minOccurs="0"/> <xs:element name="rodzaj" type="t_lista_rodzajow" minOccurs="0"/> <xs:element name="idop" type="t_operator"/> <xs:element name="uslugi" type="t_usluga" minOccurs="0"/> <xs:element name="nazwa_odb" type="t_nazwa" minOccurs="0"/> <xs:element name="adres_odb" type="t_adres" minOccurs="0"/> <xs:element name="akt_odb" type="t_data" minOccurs="0"/> <xs:element name="komorka_akt_odb" type="t_wspolrzedne" minOccurs="0"/> <xs:element name="wspolrzedne_kom_odb" type="t_wspolrzedne" minOccurs="0"/> <xs:element name="idkraj_odb" type="t_idkraj" minOccurs="0"/> <xs:complexType name="t_polaczenia"> <xs:sequence> <xs:element name="numer" type="t_numer"/> <xs:element name="okres_od" type="t_data"/> <xs:element name="okres_do" type="t_data"/> <xs:element name="nazwa" type="t_nazwa" minOccurs="0"/> <xs:element name="adres" type="t_adres" minOccurs="0"/> <xs:element name="aktywacja" type="t_data" minOccurs="0"/> <xs:element name="komorka_aktywacji" type="t_wspolrzedne" minOccurs="0"/> <xs:element name="polaczenie" type="t_polaczenie" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="polaczenia" type="t_polaczenia"/>

3.Struktura pliku z wykazem po"#cze% abonenta telefonii komórkowej w zakresie po"#cze% zaka%czanych Poni&ej zamieszczona zosta#a struktura pliku XML proponowana jako format danych, w którym przedsi$biorca telekomunikacyjny dostarcza' powinien dane o us#ugach telekomunikacyjnych realizowanych na rzecz abonenta sieci komórkowej, w odniesieniu do po#"cze% rozpoczynanych.

5

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:simpleType name="t_numer"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]{1,18}"/> <xs:simpleType name="t_data"> <xs:restriction base="xs:dateTime"/> <xs:simpleType name="t_nazwa"> <xs:restriction base="xs:string"> <xs:maxLength value="50"/> <xs:simpleType name="t_adres"> <xs:restriction base="xs:string"> <xs:maxLength value="200"/> <xs:simpleType name="t_dlugosc"> <xs:restriction base="xs:nonNegativeInteger"/> <xs:simpleType name="t_operator"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]{4,5}"/> <xs:simpleType name="t_imei"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]{26}"/> <xs:simpleType name="t_imsi"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]{15}"/> <xs:simpleType name="t_msrn"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]{1,18}"/>

6

<xs:simpleType name="t_idkraj"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]{6}"/> <xs:simpleType name="t_wspolrzedne"> <xs:restriction base="xs:string"> <xs:maxLength value="50"/> <xs:simpleType name="t_lista_rodzajow"> <xs:restriction base="xs:string"> <xs:pattern value="audio|faks|csd|sms|ems|mms|video"/> <xs:simpleType name="t_lista_uslug"> <xs:restriction base="xs:string"> <xs:pattern value="cfu|cfb|cfnr|konferencja"/> <xs:complexType name="t_usluga"> <xs:sequence> <xs:element name="nazwa_uslugi" type="t_lista_uslug" maxOccurs="unbounded"/> <xs:complexType name="t_polaczenie"> <xs:all> <xs:element name="lp" type="xs:positiveInteger"/> <xs:element name="nr_zrodlowy" type="t_numer"/> <xs:element name="nr_imsi" type="t_imsi"/> <xs:element name="nr_imei" type="t_imei"/> <xs:element name="nr_wybrany" type="t_numer"/> <xs:element name="nr_uzyskany" type="t_numer" minOccurs="0"/> <xs:element name="czas_start" type="t_data"/> <xs:element name="dlugosc" type="t_dlugosc" minOccurs="0"/> <xs:element name="rodzaj" type="t_lista_rodzajow" minOccurs="0"/> <xs:element name="idop" type="t_operator"/>

7

<xs:element name="uslugi" type="t_usluga" minOccurs="0"/> <xs:element name="nazwa_odb" type="t_nazwa" minOccurs="0"/> <xs:element name="adres_odb" type="t_adres" minOccurs="0"/> <xs:element name="akt_odb" type="t_data" minOccurs="0"/> <xs:element name="komorka_akt_odb" type="t_wspolrzedne" minOccurs="0"/> <xs:element name="wspolrzedne_kom_odb" type="t_wspolrzedne" minOccurs="0"/> <xs:element name="idkraj_odb" type="t_idkraj" minOccurs="0"/> <xs:element name="msrn_odb" type="t_msrn" minOccurs="0"/> <xs:complexType name="t_polaczenia"> <xs:sequence> <xs:element name="numer" type="t_numer"/> <xs:element name="okres_od" type="t_data"/> <xs:element name="okres_do" type="t_data"/> <xs:element name="nazwa" type="t_nazwa" minOccurs="0"/> <xs:element name="adres" type="t_adres" minOccurs="0"/> <xs:element name="aktywacja" type="t_data" minOccurs="0"/> <xs:element name="komorka_aktywacji" type="t_wspolrzedne" minOccurs="0"/> <xs:element name="polaczenie" type="t_polaczenie" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="polaczenia" type="t_polaczenia"/>

4.Akronimy BS-[Billing System] system bilingowy, CDR-[Call Detailed Record] szczegó"owy rekord o po"aczeniu, CFB-[Call Forwarding on Busy] us"uga przekierowania po"aczenia w przypadku zajetosci, CFNR-[Call Forwarding on Replay] us"uga przekierowania po"aczenia w przypadku nie zg"aszania sie, CFU-[Call Forwarding Unconditional] us"uga bezwarunkowego przekierowania po"aczenia, HPLMN-[Home PLMN].macierzysta siec telefoni komórkowej, IGR-[Incoming Gateway Rekord] rekord generowany na wejsciu centrali granicznej, IMEI-[International Mobile Equipment Identity] miedzynarodowy numer identyfikacyjny terminala, IMSI-[International Mobile Subscriber Identity] miedzynarodowy numer abonenta ruchomego, IMSI, 8

MCC-[Mobile country code] unikalny numer identyfikujacy kraj, w którym dzia"a dana sie) telefonii bezprzewodowej, MNC-[Mobile network code] unikalny w obrebie danego kraju numer, identyfikujacy sie) telefonii bezprzewodowej, MOC-[Mobile Originating Call ] rekord generowany w centrali wyjsciowej MSC, MSISDN-[Mobile Station International ISDN Number] miedzynarodowy numer abonenta sieci ISDN, MTC-[Mobile Terminating Call] rekord generowany w centrali przyjsciowej MSC, OGR-[Outgoing Gateway Record].rekord generowany na wyjsciu centrali granicznej sieci wizytowanej do sieci macierzystej bilingowych miedzy systemami, PLMN-[Public Land Mobile Network] publiczna siec komórkowa, RGR-[Roaming Gateway Record] rekord generowany na wyjsciu centrali graniczne w przypadku po"#cze' skierowanych do abonenta przebywajacego w sieci wizytowanej, SMS-MO-[Short Message Service – Mobile Originating] rekord generowany w centrali MSC wyjsciowej, SMS-MT-[Short Message Service – Mobile Terminating] rekord generowany w centrali MSC przyjsciowej, TAP-[Transffered Account Procedure] procedura transferu informacji taryfikacyjnych.

10/39si

9

Projekt ROZPORZ)DZENIE MINISTRA SPRAWIEDLIWO*CI z dnia w sprawie sposobu technicznego przygotowania systemów i sieci s"u'#cych do przekazywania informacji - do gromadzenia danych, niestanowi#cych tre$ci rozmowy telefonicznej lub innego przekazu informacji oraz sposobów zabezpieczania danych informatycznych Na podstawie art. 218b ustawy z dnia 6 czerwca 1997 r. - Kodeks post$powania karnego (Dz. U. Nr 89, poz. 555, z pó(n. zm.1)) zarz"dza si$, co nast$puje: § 1. 1. Rozporz"dzenie okre!la: 1) sposób technicznego przygotowania systemów i sieci s#u&"cych do przekazywania informacji - do gromadzenia danych , o których mowa w art. 218 § 1 Kodeks post$powania karnego, niestanowi"cych tre!ci rozmowy telefonicznej lub innego przekazu informacji; 2) sposoby zabezpieczania danych informatycznych w urz"dzeniach zawieraj"cych te dane oraz w systemach i na no!nikach danych informatycznych, zwanych dalej ”no!nikami”, maj"c na uwadze konieczno!' zabezpieczenia tych danych przed ich utrat", zniekszta#ceniem lub nieuprawnionym ujawnieniem, zwanych dalej ”danymi zapisanymi”. 2. Ilekro' w rozporz"dzeniu jest mowa o: 1) "u&ytkowniku", rozumie si$ przez to u&ytkownika, w znaczeniu okre!lonym ustaw" z dnia 16 lipca 2004 r. - Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800, z pó(n. zm.2)); 2) "podmiocie uprawnionym", rozumie si$ przez to s"d lub prokuratora; 3) "podmiocie obowi"zanym", rozumie si$ przez to urz$dy, instytucje i podmioty prowadz"ce dzia#alno!' telekomunikacyjn", o których mowa w art. 218a § 1 Kodeks post$powania karnego. § 2. Przygotowanie systemów i sieci s#u&"cych do przekazywania informacji - do gromadzenia danych, o których mowa w § 1 ust. 1 pkt 1 polega na zapewnieniu przez podmiot obowi"zany technicznych mo&liwo!ci sporz"dzania wykazów tych danych , niezw#ocznie w ci"gu ca#ej doby. § 3. Podmiot obowi"zany gromadzi dane zwi"zane z przekazami informacji, przetwarzane przez ten podmiot w zwi"zku z prowadzon" dzia#alno!ci" telekomunikacyjn" lub stanowi"ce przedmiot !wiadczonych us#ug w zakresie przekazu informacji. § 4. 1. Zabezpieczenia danych zapisanych dokonuje si$ przy u&yciu !rodków technicznych, w sposób umo&liwiaj"cy ich pó(niejsze odtworzenie przy u&yciu urz"dze% odtwarzaj"cych. 2. Zabezpieczenia danych zapisanych dokonuje osoba upowa&niona przez podmiot obowi"zany, przy u&yciu !rodków technicznych podmiotu obowi"zanego, w urz"dzeniach zawieraj"cych te dane, w systemie lub na no!niku. 3. W przypadku zabezpieczenia danych zapisanych na no!niku, osoba dokonuj"ca tego zabezpieczenia zapisuje lub oznacza na tym no!niku: 1) sygnatur$ akt sprawy, w której czynno!' ta zosta#a zlecona; 2) swoje imi$, nazwisko i stanowisko s#u&bowe; 3) dane dotycz"ce podstawy zabezpieczenia; 4) czas dokonania zabezpieczenia. § 5. Z czynno!ci zabezpieczenia danych zapisanych osoba, o której mowa w § 4 ust. 2, sporz"dza notatk$, w której zamieszcza: 1) dat$ i miejsce sporz"dzenia notatki oraz sygnatur$ akt sprawy; 2) swoje imi$, nazwisko i stanowisko s#u&bowe; 3) dane dotycz"ce podstawy zabezpieczenia; 4) imi$ i nazwisko u&ytkownika systemu lub sieci albo nazw$ podmiotu b$d"cego u&ytkownikiem, w stosunku do którego zarz"dzono zabezpieczenie danych zapisanych; 5) czas dokonania zabezpieczenia danych zapisanych; 6) dane identyfikuj"ce miejsce zabezpieczenia danych zapisanych; 7) w miar$ potrzeby inne dane dotycz"ce dokonywanej czynno!ci.

2

1) 2) 3) 4) 5) 6)

§ 6. 1. Podmiot obowi"zany gromadzi dane o dokonanych zabezpieczeniach danych zapisanych. 2. Gromadzone dane, o których mowa w ust. 1, obejmuj": sygnatur$ akt sprawy i dat$ wydania postanowienia o zabezpieczeniu danych zapisanych; nazw$ podmiotu uprawnionego; dat$ dokonania zabezpieczenia; imi$ i nazwisko u&ytkownika systemu lub sieci albo nazw$ podmiotu b$d"cego u&ytkownikiem, w stosunku do którego zarz"dzono zabezpieczenie danych zapisanych; czas trwania zabezpieczenia, dane identyfikuj"ce miejsce zabezpieczenia danych zapisanych.

§ 7. Zabezpieczone dane zapisane przechowuje si$ w warunkach zabezpieczaj"cych przed ich utrat", zniekszta#ceniem lub nieuprawnionym ujawnieniem oraz zniszczeniem lub uszkodzeniem no!nika. § 8. Rozporz"dzenie wchodzi w &ycie z dniem ......................................... 2008 r.

Minister Sprawiedliwo!ci w porozumieniu Minister Infrastruktury Minister Obrony Narodowej Minister Spraw Wewn$trznych i Administracji

__________ Zmiany wymienionej ustawy zosta#y og#oszone w Dz. U. z 1999 r. Nr 83, poz. 931, z 2000 r. Nr 50, poz. 580, Nr 62, poz. 717, Nr 73, poz. 852 i Nr 93, poz. 1027, z 2001 r. Nr 98, poz. 1071 i Nr 106, poz. 1149, z 2002 r. Nr 74, poz. 676, z 2003 r. Nr 17, poz. 155, Nr 111, poz. 1061 i Nr 130, poz. 1188, z 2004 r. Nr 51, poz. 514, Nr 69, poz. 62, Nr 93, poz. 889, Nr 240, poz. 2405 i Nr 264, poz. 2641, z 2005 r. Nr 10, poz. 70, Nr 48, poz. 461, Nr 77, poz. 680, Nr 96, poz. 821, Nr 141, poz. 1181, Nr 143, poz. 1203, Nr 163, poz. 1363, Nr 169, poz. 1416 i Nr 178, poz. 1479, z 2006 r. Nr 15, poz. 118, Nr 66, poz. 467, Nr 95, poz. 659, Nr 104, poz. 708 i 711, Nr 141, poz. 1009 i 1013, Nr 167, poz. 1192 i Nr 226, poz. 1647 i 1648, z 2007 r. Nr 20, poz. 116, Nr 64, poz. 432, Nr 80, poz. 539, Nr 89, poz. 589, Nr 99, poz. 664, Nr 112, poz. 766 i Nr 123, poz. 849 oraz z 2008 r. Nr 100, poz. 648 i Nr 107, poz. 686. 2) Zmiany wymienionej ustawy zosta#y og#oszone w Dz. U. z 2004 r. Nr 273, poz. 2703, z 2005 r. Nr 163, poz. 1362 i Nr 267, poz. 2258, z 2006 r. Nr 12, poz. 66, Nr 104, poz. 708 i 711, Nr 170, poz. 217, Nr 220, poz. 1600, Nr 235, poz. 1700 i Nr 249, poz. 1834, z 2007 r. Nr 23, poz. 137, Nr 50, poz. 331 i Nr 82, poz. 556 oraz z 2008 r. Nr 17, poz. 101. 1)

3 Uzasadnienie

Projekt ustawy o zmianie ustawy - Prawo telekomunikacyjne oraz niektórych innych ustaw, w art. 5 projektu przewiduje nowelizacj$ art. 218 §1 i art. 218b ustawy z dnia 6 czerwca 1997 r. – Kodeks post$powania karnego (Dz. U. Nr 89, poz. 555, z pó(n. zm.), dalej kpk. Projektowane zmiany wskazanych wy&ej przepisów powoduj" konieczno!' zredagowania projektu aktu wykonawczego, uwzgl$dniaj"cego zmiany w siatce poj$ciowej, który zast"pi#yby aktualne rozporz"dzenie Ministra Sprawiedliwo!ci z dnia 28 kwietnia 2004 r. w sprawie sposobu technicznego przygotowania systemów i sieci s#u&"cych do przekazywania informacji - do gromadzenia wykazów po#"cze% telefonicznych i innych przekazów informacji oraz sposobów zabezpieczania danych informatycznych (Dz. U. Nr 100, poz. 1023.). Projekt nowego rozporz"dzenia Ministra Sprawiedliwo!ci w sprawie sposobu technicznego przygotowania systemów i sieci s#u&"cych do przekazywania informacji - do gromadzenia wykazów po#"cze% telefonicznych i innych przekazów informacji oraz sposobów zabezpieczania danych informatycznych, sprowadzono do zast"pienia tre!ci tych przepisów obowi"zuj"cych, które odnosz" si$ do poj$', które stan" si$ nieaktualne z chwil" wej!cia w &ycie projektowanych zmian ustawowych. Przepis § 1 ust 1 pkt 1 - za projektem art. 218b kpk umieszczono odes#anie do tre!ci art. 218 kpk; Przepis § 1 ust 2 pkt 1 - okre!lono poj$cie „no!ników danych informatycznych” oraz na nowo zdefiniowano poj$cie „danych zapisanych”; Przepis § 1 ust 2 pkt 1 - okre!lono poj$cie „u&ytkownika”; Przepis § 2 - zmiana, polegaj"ca na zast"pieniu terminu „no!nik informatyczny” terminem „no!nik”, stanowi konsekwencj$ projektowanego brzmienia przepisu § 1 ust 1 pkt 2; Przepis § 4 - zmiana, polegaj"ca na zast"pieniu terminu „no!nik informatyczny” terminem „no!nik”, stanowi konsekwencj$ projektowanego brzmienia przepisu § 1 ust 1 pkt 2. W pozosta#ej cz$!ci projekt rozporz"dzenia zawiera propozycje przepisów w brzmieniu obowi"zuj"cym.

4 Ocena skutków regulacji Podmioty na które oddzia"uje rozporz#dzenie. Projektowane rozporz"dzenia nie b$dzie oddzia#ywa' na s"dy powszechne. Zakres konsultacji. Przedmiotowy projekt zostanie przekazany do zaopiniowania (zakres konsultacji do ustalenia). Wp"yw aktu normatywnego na sektor finansów publicznych, w tym bud'et pa%stwa i bud'ety jednostek samorz#du terytorialnego . Wej!cie w &ycie projektowanego rozporz"dzenia nie powinno spowodowa' bezpo!redniego zwi$kszenia lub zmniejszenia dochodów bud&etu Pa%stwa. Wp"yw aktu normatywnego na rynek pracy, konkurencyjno$( gospodarki i przedsi!biorczo$(, w tym funkcjonowanie przedsi!biorstw oraz na sytuacj! i rozwój regionalny. Niniejsze rozporz"dzenie nie spowoduje skutków na rynku pracy, w sferze konkurencyjno!ci wewn$trznej i zewn$trznej gospodarki a tak&e pozostanie bez wp#ywu na rozwój regionalny. Wp#yw po!redni natomiast, mo&e wyst"pi' w wyniku podniesienia poziomu sprawno!ci dzia#ania s"dów powszechnych i wspó#pracy z organami instytucji wymiaru sprawiedliwo!ci w innych krajach. Zgodno$( projektu z prawem Unii Europejskiej. Rozporz"dzenie jest zgodne z prawem Unii Europejskiej. Projekt niniejszego rozporz"dzenia zostanie udost$pniony w Biuletynie Informacji Publicznej, stosownie do przepisów ustawy z dnia 7 lipca 2005 r. o dzia#alno!ci lobbingowej w procesie stanowienia prawa (Dz. U. Nr 169, poz. 1414).

15-10-tg

PROJEKT ROZPORZ!DZENIE RADY MINISTRÓW z dnia w sprawie trybu nieodp"atnego udost$pniania radiowych urz&dze# nadawczych lub nadawczo-odbiorczych stosowanych w s"u%bach radiokomunikacyjnych przez podmioty nieb$d&ce przedsi$biorcami telekomunikacyjnymi Na podstawie art. art. 177 ust. 6 ustawy z dnia 16 lipca 2004 r. - Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800, z pó!n. zm.1)) zarz#dza si%, co nast%puje: § 1. Rozporz#dzenie okre&la tryb nieodp"atnego udost%pniania radiowych urz#dze' nadawczych lub nadawczo-odbiorczych zwanych dalej "urz#dzeniami", stosowanych w s"u$bach radiokomunikacyjnych przez podmioty nieb%d#ce przedsi%biorcami telekomunikacyjnymi zwane dalej „podmiotami zobowi#zanymi”, podmiotom i s"u$bom wykonuj#cym zadania: w zakresie ratownictwa, niesienia pomocy ludno&ci, na rzecz obronno&ci, bezpiecze'stwa pa'stwa oraz bezpiecze'stwa i porz#dku publicznego, a tak$e podmiotom w"a&ciwymi w sprawach zarz#dzania kryzysowego, zwanym dalej „podmiotami uprawnionymi”. § 2. 1. Decyzj% o udost%pnieniu urz#dzenia wydaje wojewoda w"a&ciwy terytorialnie ze wzgl%du na miejsce zamieszkania lub siedzib% podmiotu zobowi#zanego, na wniosek uprawnionego podmiotu. 2. Przed wydaniem decyzji wojewoda mo$e zasi%gn#) opinii Prezesa Urz%du Komunikacji Elektronicznej. Prezes Urz%du Komunikacji Elektronicznej niezw"ocznie udziela informacji w zakresie posiadanych danych. 3. Decyzja, o której mowa w ust. 1, mo$e by) og"oszona ustnie, bez uzasadnienia, w ca"o&ci lub cz%&ci, je$eli wymagaj# tego wzgl%dy obronno&ci, bezpiecze'stwa pa'stwa oraz bezpiecze'stwa i porz#dku publicznego. § 3. Wniosek okre&lony w § 2 powinien zawiera): nazw% uprawnionego podmiotu, dane adresowe podmiotu zobowi#zanego, nazw% urz#dzenia, przewidywany czas udost%pnienia oraz podpis i piecz%) podmiotu uprawnionego. § 4. W wypadku wp"yni%cia kilku wniosków dotycz#cych tego samego urz#dzenia, decyzj% o jego udost%pnieniu podejmuje wojewoda, o którym mowa w § 2. § 5. Udost%pnienie urz#dzenia uprawnionym podmiotom nast%puje przy udziale podmiotu zobowi#zanego, chyba $e korzystanie z urz#dzenia bez udzia"u podmiotu zobowi#zanego uzasadnione jest szczególnymi okoliczno&ciami. § 6. Zako'czenie udost%pnienia urz#dzenia nast%puje bez zb%dnej zw"oki po ust#pieniu sytuacji szczególnych zagro$e' oraz stanów nadzwyczajnych. § 7. Podmiot uprawniony zwraca urz#dzenie w stanie nienaruszonym. W przypadku zniszczenia, uszkodzenia lub poniesienia dodatkowych kosztów eksploatacyjnych urz#dzenia podmiotowi zobowi#zanemu przys"uguje rekompensata na podstawie przepisów odr%bnych. § 8. Rozporz#dzenie wchodzi w $ycie po up"ywie 14 dni od dnia og"oszenia.

1)

Zmiany wymienionej ustawy zosta"y og"oszone w Dz. U. z 2004 r. Nr 273, poz. 2703, z 2005 r. Nr 163, poz. 1362 i Nr 267, poz. 2258, z 2006 r. Nr 12, poz. 66, Nr 104, poz. 708 i 711, Nr 170, poz. 1217, Nr 220, poz. 1600, Nr 235, poz. 1700 i Nr 249, poz. 1834, z 2007 r. Nr 23, poz. 137, Nr 50, poz. 331 i Nr 82, poz. 556 oraz z 2008 r. Nr 17, poz. 101.

UZASADNIENIE Przedmiotowe rozporz#dzenie jest wykonaniem upowa$nienia z art. 177 ust. 6 ustawy z dnia 16 lipca 2004 r. – Prawo telekomunikacyjne. Jego celem jest okre&lenie trybu, w jakim podmioty obowi#zane na podstawie tej ustawy udost%pniaj# urz#dzenia radiowe nadawcze i nadawczoodbiorcze podmiotom uprawnionym wykonuj#cym zadania: w zakresie ratownictwa, niesienia pomocy ludno&ci, na rzecz obronno&ci, bezpiecze'stwa pa'stwa oraz bezpiecze'stwa i porz#dku publicznego, a tak$e podmiotom w"a&ciwymi w sprawach zarz#dzania kryzysowego. Udost%pnianie urz#dze' odbywa si% na podstawie decyzji wojewody w"a&ciwego terytorialnie ze wzgl%du na miejsce zamieszkania lub siedzib% podmiotu zobowi#zanego do udost%pnienia, wydawanej na wniosek uprawnionego podmiotu.

OCENA SKUTKÓW REGULACJI Skutkiem regulacji zawartej w projekcie jest na"o$enie na podmioty nieb%d#ce przedsi%biorcami telekomunikacyjnymi, pos"uguj#ce si% radiowymi urz#dzeniami nadawczymi lub nadawczoodbiorczymi, stosowanymi w s"u$bach radiokomunikacyjnych, obowi#zku udost%pniania tych urz#dze' s"u$bom ustawowo odpowiedzialnym za bezpiecze'stwo pa'stwa oraz bezpiecze'stwo i porz#dek publiczny. Regulacja zobowi#zuje wojewodów do wydawania w uzasadnionych wypadkach decyzji administracyjnych w zakresie udost%pnienia tych urz#dze'. Zak"ada równie$ wspó"uczestniczenie Prezesa UKE w procesie opracowywania tych decyzji. Regulacja zawarta w rozporz#dzeniu nie b%dzie mia"a wp"ywu na rynek pracy, rozwój regionalny oraz konkurencyjno&) wewn%trzn# i zewn%trzn# gospodarki. Rozporz#dzenie nie spowoduje równie$ skutków finansowych dla bud$etu pa'stwa oraz bud$etów jednostek samorz#du terytorialnego. Projektowane rozporz#dzenie jest zgodne z prawem Unii Europejskiej. Projekt rozporz#dzenia nie podlega notyfikacji zgodnie z trybem przewidzianym w przepisach dotycz#cych sposobu funkcjonowania krajowego systemu notyfikacji norm i aktów prawnych oraz nie wymaga przedstawienia w"a&ciwym instytucjom i organom Unii Europejskiej lub Europejskiemu Bankowi Centralnemu.