Model Wymiany Danych dla Migracji Usług Hurtowych w ramach dostępu telekomunikacyjnego do sieci TP Wersja v 5.8 Status: zamrożony Data wdrożenia: 30-10-2009
Historia zmian Wersja Data modyfikacji 1.0 7.07.2008 Utworzenie dokumentu 2.0 16.07.2008 Merytoryczne 2.1 8.08.2008 Merytoryczne 2.2 14.08.2008 Merytoryczne 2.3 26.08.2008 Merytoryczne 2.4 8.09.2008 Merytoryczne 2.5 16.09.2008 Merytoryczne 2.6 22.09.2008 Merytoryczne 2.7 23.09.2008 Merytoryczne 2.8 23.09.2008 Merytoryczne 2.9 24.09.2008 Merytoryczne Opis 2.10 26.09.2008 Uzupełnienie w zakresie realizacji technicznej. Wyjaśnienia do pytań w formie komentarzy. 2.10a 29.09.2008. Korekta komunikatów i przykładów 3 29.09.2008 Merytoryczne 3.1 07.10.2008 Merytoryczne 3.2 08.10.2008 Przeniesienie zmian z wersji 2.10a, nie uwzględnionych w wersji 3.1. Poprawa i uzupełnienie komunikatów zgodnie z ustaleniami z telekonferencji. 4.0 08.10.2008 Merytoryczne 5.0 10.10.2008 Merytoryczne 5.1 14.10.2008 Merytoryczne 5.2 17.10.2008 Merytoryczne 5.3 29.10.2008 Merytoryczne dopisanie numeracji dla czterech nieopisanych kodów odrzuceń 5.4 3.12.2008 Doprecyzowanie zapisów w rozdziale 9 odnośnie dni na rozpatrzenie reklamcji. 5.5 4.12.2008 Uwzględnienie nowych wymagań biznesowych w specyfikacji komunikatów 5.6 5.12.2008 Uwzględnienie wymagań biznesowych po spotkaniu dotyczącym Modelu realizacji procesów 5.6 11.12.2008 6.01.2009. Zmiany w komunikacie ORDER-STATUS, korekta przykładów, korekta kodów, korekty edytorskie, komentarze, zmiana wymagalności pól struktury rekordu typu ADDRESS, dodanie nowej wartości słownikowej 2 w komunikacie SERVICE- QUERY-RESULT w polu QUERY-STATUS 2
Wersja Data modyfikacji Opis 5.6.1 9.01.2009 Zmiany merytoryczne we wprowadzeniu oraz doprecyzowanie zapisów przy opisach kroków procesów. Zmodyfikowano także rodzaje migracji w rozdziale 3. 5.6.2 11.01.2009 Uwzględnienie zmian wprowadzonych przez HLD- 0 (2) w komunikacie ORDER-MIGRATION- STATUS 5.6.3 12.01.2009 Uwzględnienie zmian biznesowych i informatycznych. 5.6.4 14.01.2009 Uwzględnie uwag biznesowych informatycznych 5.6.5 23.01.2009 Uzupełnienie komunikatu ORDER-MIGRATION- CANCEL o pole GENERATE-DATE 5.6.6 27.03.2009 Uzupełnienie procesu skłądania reklamacji oraz informacji niezbędnych dla realizacji procesu BSA na LLU 5.6.7 7.04.2009 Zmiana formatu dat w polach IMPLEMENTATION-DATE i STATUS-DATE. Dodanie typu usługi 8 NBSA usługa BSA w trybie Naked (usługa szerokopasmowa ATM). Doprecyzowanie znaczenia typu BSA w komunikatach. Usunięcie pól VERSION-ADSL, SPECIAL- VERSION-ID, OPTION-ADSL z komunikatu zamówienia jako niewykorzystywanych w procesie, zastąpionych polem wymaganym CODE. Dodanie parametrów technicznych BSA i NBSA tj. VP, VC, VP2PDU, ID interfejsu ATM. Usunięcie obligatoryjnych usług VAS ze specyfikacji usług zamawianych. 5.6.8 23.04.2009 Dodanie zgody abonenta na przetwarzanie danych osobowych w komunikacie SERVICE- QUERY zmiana zakresu godzinowego dla T0 z 8-16 na 23:59 5.6.9 27.04.2009 Uzupełniono p.9,2.1 Uzupełniono kody odrzuceń. 5.6.10 4.05.2009 usunięto punkt 3.1.5 celem uspójnienia zapisów z rozdziałem 3. Modyfikacja zapisów biznesowych w rozdziale drugim odnośnie T0 dla realizacji zamówień. Dodanie kodu nr 404 Niepoprawne PG/PPD, usunięcie kodu 295 5.7 5.05.2009 Podniesienie wersji po akceptacji dokumentu 5.7.1 22.05.2009 Modyfikacja procesu reklamacji 5.7.2 27.05.2009 Modyfikacja kodów odrzutu 5.8 18.09.2009 1. Dodanie rozdziału 6 Odpytanie o warunki dla NP. Mnodyfikacja zapisów merytorycznych dla rozdziału 7 i 9 w zakresie określenia KPI dla realizacji poszczególnych kroków procesu. Dodanie 6 BSA-BROADBAND TP powrót BSA w polu ORDER-TYPE. 2. Modyfikacja KPI dla realizacji procesów dla usługi NP. Dodanie kodów odrzutu dla weryfikacji formalnej. 3. Uwzględnienie uwag do dokumentu, poprawa KPI w opisie procesu realizacji dla Zamówień Migracji. 3
Spis Treści 1. Wprowadzenie... 8 2. Podstawowe dane konfiguracyjne - kanał e-mail... 10 2.1. Ustawienia techniczne systemów TP i Przedsiębiorcy telekomunikacyjnego... 10 2.2. Zasady bezpieczeństwa przesyłu danych... 11 2.3. Specyfikacja postaci wiadomości e-mail... 12 3. Typy danych... 14 3.1. Typy pól... 14 3.1.1. ADDRESS... 14 3.1.2. LOC-ADDRESS... 15 3.1.3. INT-ID... 15 3.1.4. ORDER-NUMBER... 16 3.2. Rodzaje migracji... 16 4. Słownik pojęć... 18 5. Odpytanie TP przez Przedsiębiorcę telekomunikacyjnego o aktywne usługi hurtowe na danym Łączu Abonenckim Aktywnym... 19 5.1. Zapytanie o aktywne usługi hurtowe... 19 5.1.1. Komunikat zapytania o aktywne usługi na danym Łączu Abonenckim... 19 5.1.2. Komunikat potwierdzenia przyjęcia komunikatu SERVICE-QUERY... 21 5.2. Informacja o zainstalowanych usługach na aktywnym łączu abonenckim... 22 5.2.1. Komunikat odpowiedzi na zapytanie o aktywne usługi na danym Łączu Abonenckim... 22 5.2.2. Komunikat potwierdzenia przyjęcia komunikatu SERVICE-QUERY-RESULT... 25 6. Weryfikacja wniosku abonenta dotyczącego przeniesienia przydzielonego numeru przy zmianie dostawcy usług. ( TP realizuje komunikację pomiędzy Operatorami)... 27 6.1. Odpytanie o warunki NP... 27 6.1.1. Komunikat odpytania o warunki NP.... 27 6.1.2. Komunikat potwierdzenia odpytania o warunki NP... 27 6.2. Potwierdzenie daty lub negatywna weryfikacja formalna... 27 6.2.1. Komunikat potwierdzenie daty lub negatywna weryfikacja formalna... 28 6.2.2. Komunikat potwierdzenia dostarczenia komunikatu potwierdzenia daty lub negatywnej weryfikacji formalnej... 28 6.3. Odpowiedź od Dawcy i Macierzystego... 28 6.3.1. Komunikat odpowiedzi od Dawcy i Macierzystego... 28 6.3.2. Komunikat potwierdzenia dostarczenia odpowiedzi od Dawcy i Macierzystego... 28 6.4. Potwierdzenie daty realizacji lub odrzucenie... 28 6.4.1. Komunikat potwierdzenie daty realizacji lub odrzucenie... 29 6.4.2. Komunikat potwierdzenia dostarczenia potwierdzenia daty realizacji lub odrzucenie... 29 7. Migracja Usługi Abonenckiej od Przedsiębiorcy telekomunikacyjnego korzystającego (Dawca) do innego Przedsiębiorcy telekomunikacyjnego (Biorca) ze zmianą Usługi Hurtowej... 30 7.1. Schemat migracji... 30 7.2. Opis kroków schematu... 31 7.3. Złożenie Zamówienia Migracji... 32 7.3.1. Proces po stronie Operatora Biorcy... 32 7.3.2. Opis kroków przesłania Zamówień Migracji... 33 4
7.3.3. Opis kroków przesłania grupy odpowiedzi na Zamówienia Migracji... 33 7.3.4. Komunikat Zamówień Migracji... 34 7.3.5. Komunikat potwierdzenia zamówień usług migracji... 41 7.4. Negatywna weryfikacja formalna TP... 42 7.4.1. Komunikat statusu... 43 7.4.2. Komunikat potwierdzenia statusu... 52 7.5. Przekazanie daty rezygnacji lub daty wykonania NP do Dawców... 54 7.5.1. Komunikat zgłoszenia Rezygnacji z usług u operatora Dawcy lub daty wykonania NP... 54 7.5.2. Komunikat potwierdzenia zgłoszenia rezygnacji z usług u operatora Dawcy lub daty wykonania NP... 59 7.6. Potwierdzenia realizacji zlecenia Zamówienia lub jego odrzucenie... 60 7.6.1. Komunikat akceptacji rezygnacji lub odrzucenia zlecenia migracji przez Dawców... 61 7.6.2. Komunikat potwierdzenia akceptacji rezygnacji lub odrzucenia zlecenia migracji przez Dawców... 65 7.7. Potwierdzenie do Biorcy oraz Dawcy/Dawców bądź odmowa realizacji Zamówienia Migracji wraz z datą realizacji... 66 7.7.1. Komunikat - informacja o dacie realizacji Zamówienia Migracji/odmowie realizacji zamówienia Migracji 66 7.7.2. Komunikat potwierdzenia dla komunikatu informacji o dacie realizacji Zamówienia Migracji/odmowie realizacji zamówienia Migracji... 67 7.8. Rezygnacja z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia Migracji... 67 7.8.1. Komunikat Rezygnacji z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia Migracji.. 67 7.8.2. Komunikat potwierdzenia Rezygnacji z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia Migracji... 69 7.9. Potwierdzenie do Biorcy, Dawcy/ów anulowania zamówienia migracji... 70 7.9.1. Komunikat statusu anulowania zamówienia migracji... 71 7.9.2. Komunikat potwierdzenia statusu anulowania zamówienia migracji... 71 7.10. Potwierdzenie od Dawcy i Macierzystego wykonania NP... 71 7.10.1. Komunikat potwierdzenia realizacji przez Dawcę i Macierzystego... 71 7.10.2. Komunikat potwierdzenia dostarczenia komunikatu potwierdzającego realizację przez Dawcę i Macierzystego... 71 7.11. Potwierdzenie realizacji Zamówienia Migracji... 71 7.11.1. Komunikat statusu wykonania zamówienia migracji... 72 7.11.2. Komunikat potwierdzenia statusu wykonania zamówienia migracji... 72 7.11.3. Potwierdzenie deinstalacji usługi dla Operaotra Dawcy... 72 8. Migracja usługi abonenckiej od Przedsiębiorcy telekomunikacyjnego korzystającego (Dawca) do innego Przedsiębiorcy telekomunikacyjnego (Biorca) bez zmiany usługi hurtowej;... 74 8.1. Złożenie Zamówienia Migracji... 74 8.1.1. Opis kroków przesyłania Zamówień Migracji... 75 8.1.2. Opis kroków przesłania odpowiedzi na Zamówienia Migracji... 75 8.1.3. Komunikat Zamówień Migracji... 76 8.1.4. Komunikat potwierdzenia zamówień usług MIGRACJA... 76 8.2. Negatywna weryfikacja formalna TP... 76 8.2.1. Komunikat Negatywnej Weryfikacji Formalnej (NWF)... 76 8.2.2. Komunikat potwierdzenia Negatywnej Weryfikacji Formalnej... 76 8.3. Przekazanie daty rezygnacji do Dawców... 76 8.3.1. Komunikat zgłoszenia Rezygnacji z usług u operatora Dawcy... 77 8.3.2. Komunikat potwierdzenia zgłoszenia rezygnacji z usług u operatora Dawcy... 77 8.4. Potwierdzenia realizacji zlecenia lub odrzucenie... 77 8.4.1. Komunikat akceptacji rezygnacji lub odrzucenia zlecenia migracji przez Dawców... 78 8.4.2. Komunikat potwierdzenia akceptacji rezygnacji lub odrzucenia zlecenia migracji przez Dawców... 78 8.5. Potwierdzenie bądź odmowa realizacji Zamówienia Migracji wraz z datą realizacji... 78 8.5.1. Komunikat - informacja o dacie realizacji Zamówienia Migracji/odmowie realizacji zamówienia Migracji 79 5
8.5.2. Komunikat potwierdzenia dla komunikatu informacji o dacie realizacji Zamówienia Migracji/odmowie realizacji zamówienia Migracji... 79 8.6. Rezygnacja z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia Migracji... 80 8.6.1. Komunikat Rezygnacja z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia Migracji. 80 8.6.2. Komunikat potwierdzenia Rezygnacji z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia Migracji... 80 8.7. Potwierdzenie do Biorcy, Dawcy/ów anulowania zamówienia migracji... 80 8.7.1. Komunikat statusu anulowania zamówienia migracji... 81 8.7.2. Komunikat potwierdzenia statusu anulowania zamówienia migracji... 81 8.8. Potwierdzenie realizacji Zamówienia Migracji... 81 8.8.1. Komunikat statusu wykonania zamówienia migracji... 82 8.8.2. Komunikat potwierdzenia statusu wykonania zamówienia migracji... 82 9. Migracja usługi abonenckiej z usługi hurtowej obecnie świadczonej na inną usługę hurtową bez zmiany Przedsiębiorcy telekomunikacyjnego... 83 9.1. Złożenie Zamówienia Migracji... 83 9.1.1. Komunikat Zamówień Migracji... 84 9.1.2. Komunikat potwierdzenia zamówień usług MIGRACJA... 84 9.2. Negatywna weryfikacja formalna... 84 9.2.1. Komunikat Negatywnej Weryfikacji Formalnej (NWF)... 85 9.2.2. Komunikat potwierdzenia Negatywnej Weryfikacji Formalnej... 85 9.3. Przekazanie daty rezygnacji lub daty wykonania NP do Dawców... 85 9.3.1. Komunikat zgłoszenia Rezygnacji z usług u operatora Dawcy lub daty wykonania NP... 85 9.3.2. Komunikat potwierdzenia zgłoszenia rezygnacji z usług u operatora Dawcy lub daty wykonania NP... 85 9.4. Potwierdzenie bądź odmowa realizacji Zamówienia Migracji wraz z datą realizacji... 85 9.4.1. Komunikat - informacja o dacie realizacji Zamówienia Migracji/odmowie realizacji zamówienia Migracji 86 9.4.2. Komunikat potwierdzenia Akceptacja/brak akceptacji daty realizacji Zamówienia Migracji... 86 9.5. Rezygnacja z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia Migracji... 86 9.5.1. Komunikat Rezygnacja z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia Migracji. 87 9.5.2. Komunikat potwierdzenia Rezygnacji z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia Migracji... 87 9.6. Potwierdzenie do Biorcy anulowania zamówienia Migracji... 87 9.6.1. Komunikat statusu anulowania zamówienia migracji... 88 9.6.2. Komunikat potwierdzenia statusu anulowania zamówienia migracji... 88 9.7. Potwierdzenie od Dawcy wykonania NP.... 88 9.7.1. Komunikat potwierdzenia realizacji przez Dawcę... 88 9.7.2. Komunikat potwierdzenia dostarczenia komunikatu potwierdzającego realizację przez Dawcę... 88 9.8. Potwierdzenie realizacji Zamówienia Migracji... 88 9.8.1. Komunikat statusu wykonania zamówienia migracji... 89 9.8.2. Komunikat potwierdzenia statusu wykonania zamówienia migracji... 89 10. Proces zgłaszania reklamacji... 90 10.1. Zgłaszenie reklamacji formalnej... 90 10.1.1. Komunikat zgłaszania reklamacji... 91 10.1.2. Komunikat potwierdzenia zgłoszenia reklamacji formalnej... 93 10.1.3. Komunikat odpowiedzi na zgłoszenie reklamacji formalnej... 94 10.1.4. Komunikat potwierdzenia odpowiedzi na zgłoszenie reklamacji formalnej... 98 10.2. Zgłoszenie reklamacji technicznej... 99 10.2.1. Komunikat zgłoszenia reklamacji technicznej... 100 10.2.2. Komunikat potwierdzenia zgłoszenia reklamacji technicznej... 100 10.2.3. Komunikat odpowiedzi na zgłoszenie reklamacji technicznej... 100 10.2.4. Komunikat potwierdzenia odpowiedzi na zgłoszenie reklamacji technicznej... 101 6
11. Specyfikacja komunikatów awaryjnych... 102 11.1. Komunikat ABORT... 102 12. Kody odrzuceń dla korelacji i przejść pomiędzy Operatorami... 104 12.1. Kody odrzuceń weryfikacja informatyczna... 104 12.2. Kody weryfikacji formalnej... 104 12.3. Kody weryfikacji formalnej Dawca- TP... 105 12.4. Kody odpowiedzi TP do Biorcy/Dawcy dotyczące weryfikacji formalnej i technicznej... 105 12.5. Kody związane z rezygnacją Abonenta otrzymaną od Dawcy/ Biorcy... 105 13. Kody odrzuceń dla informacji o usługach hurtowych... 106 14. Kody odrzuceń dla reklamacji... 107 14.1. Negatywna weryfikacja informatyczna w BNP - Kody odrzucenia reklamacji przez BNP... 107 14.2. Negatywny wynik rozpatrzenia Reklamacji - Kody odrzucenia reklamacji... 107 14.3. Wynik rozpatrzenia reklamacji... 107 14.4. Przedmiot Reklamacji... 107 7
1. Wprowadzenie Niniejszy dokument jest opisem Modelu Wymiany Danych (MWD) pomiędzy Telekomunikacją Polską S.A. (dalej zwaną TP) a Przedsiębiorcą telekomunikacyjnym dla Migracji Usług Hurtowych w ramach dostępu telekomunikacyjnego w ramach sieci TP, zgodnie z zakresem oraz wymaganiami Decyzji UKE w formie komunikacji elektronicznej. Celem niniejszego dokumentu jest określanie zasad wykonywania przez Strony postanowień Decyzji Prezesa UKE oraz uregulowanie kwestii pozostawionych do uzgodnienia Stronom w ramach procesu wdrażania Decyzji Prezesa UKE. W przypadku zmiany zasad współpracy Stron poprzez nową Decyzję Prezesa UKE lub umowę zawartą między Stronami, Strony niezwłocznie dokonają zmian w niniejszym dokumencie celem dostosowania go do wprowadzonych zmian. Modelowy przebieg komunikacji MWD z użyciem kanału e-mail przedstawia poniższy rysunek, na którym jest widoczny ogólny schemat dla poszczególnych rodzajów zleceń. Kolejność realizacji będzie określana poprzez numeracje strzałek. Serwer poczty e-mail Operatora Serwer poczty e-mail TP Operator System TP Migracja Usług Hurtowych w ramach dostępu telekomunikacyjnego w ramach sieci TP jest dedykowana dla Przedsiębiorców Telekomunikacyjnych, którzy mają obecnie podpisaną umowę o dostępie telekomunikacyjnym w zakresie Usług Hurtowych oraz podpisane porozumienie w zakresie Modelu Przejść Międzyoperatorskich. W ramach Oferty określającej warunki Migracji, TP świadczy na rzecz Przedsiębiorcy telekomunikacyjnego następujące usługi: Migrację Usługi Abonenckiej z Usługi Hurtowej obecnie świadczonej na inną Usługę Hurtową bez zmiany Przedsiębiorcy telekomunikacyjnego Migracja Usługi Abonenckiej od Przedsiębiorcy telekomunikacyjnego korzystającego (Dawca) do innego Przedsiębiorcy telekomunikacyjnego (Biorca) bez zmiany Usługi Hurtowej; Migracja Usługi Abonenckiej od Przedsiębiorcy telekomunikacyjnego korzystającego (Dawca) do innego Przedsiębiorcy telekomunikacyjnego (Biorca) ze zmianą Usługi Hurtowej; Migrację można ustanowić na wszystkich Łączach Abonenckich Aktywnych, na których świadczone są obecnie Usługi Hurtowe BSA, LLU, WLR, realizowane jest Przeniesienie Numeru 8
(NP) oraz w przypadku migracji na LLU także dla łączy na których jest świadczona Abonentowi głosowa usługa detaliczna TP. W przypadku usług detalicznych TP, TP jest traktowana na identycznych zasadach jak pozostali OA. W celu zapewnienia prawidłowej obsługi Przedsiębiorcy telekomunikacyjnego (Biorcy) w zakresie procesów posprzedażowych po dokonaniu migracji, Przedsiębiorca telekomunikacyjny (Biorca) powinien mieć podpisane odpowiednie umowy / modele wymiany danych, właściwe dla usług hurtowych, które podlegają migracji w ramach niniejszego Modelu. Migracja z dwóch Usług Abonenckich podlega realizacji, jeżeli Stroną Umów Abonenckich świadczonych w oparciu o Usługę Hurtową jest ten sam Abonent. Komunikacja w zakresie realizacji poniżej wskazanych procesów odbywa się drogą elektroniczną za pośrednictwem Komunikatów XML właściwych dla prawidłowego przebiegu procesów, a w szczególności: obsługi Zamówień na podstawie Modelu Przejść Międzyoperatorskich określającego warunki Migracji na Łączu Abonenckim Aktywnym, obsługi Zamówień rezygnacji Abonenta z Migracji składanych przez Dawcę/Biorcę do TP, obsługi zgłoszeń Przedsiębiorcy telekomunikacyjnego z tytułu reklamacji, i nieprawidłowości technicznych w realizacji usług objętych objętych procesem Migracji. Komunikacja opisana w niniejszym dokumencie pomiędzy TP, a Operatorem Macierzystym będzie prowadzona analogicznie jak między TP, a Operatorem Dawcą, różnicy podlega jedynie zawartość komunikatów przesyłanych między TP a Operatorem Dawcą i TP a Operatorem Macierzystym. Zmiana kanału komunikacyjnego (np. na WebService) nie będzie wymagała zmiany Modelu Wymiany Danych - sekwencje komunikatów i same komunikaty XML wymieniane w dowolnym kanale komunikacyjnym nie ulegają zmianie w związku ze zmianą kanału komunikacyjnego, a szczegóły techniczne dotyczące kanału będą uzgodnione i opisane w odrębnym dokumencie (załącznik techniczny). Każda ze Stron uczestniczących w wymianie komunikatów jest zobowiązana do przeprowadzenia testów wzajemnej komunikacji w ramach niniejszego Modelu, zgodnie ze scenariuszami testowymi. Pozytywne zakończenie testów warunkuje produkcyjne uruchomienie komunikacji elektronicznej między Stronami. 9
2. Podstawowe dane konfiguracyjne - kanał e-mail Wymiana danych pomiędzy TP i Przedsiębiorcą telekomunikacyjnym odbywać się będzie przy użyciu poczty e-mail. E-mail będzie przesyłany do dedykowanych skrzynek pocztowych. Każda ze Stron uczestniczących w wymianie komunikatów jest zobowiązana do zapewnienia własnej części infrastruktury niezbędnej do wymiany informacji. Pliki będą zapisane w stronie kodowej UTF-8. W celu umożliwienia kontroli postaci plików XML, TP przekaże Przedsiębiorcom telekomunikacyjnym schematy XSD pozwalające na parsowanie zawartości komunikatów przed ich wysłaniem. Za dzień roboczy uznaje się dzień powszedni, w godzinach roboczych 8:00 16:00. (Dotyczy wszystkich zgłoszeń i zamówień). W dni robocze w godzinach 00:00 23:59 dzień wpływu zgłoszeń i zamówień jest dniem zerowym. Zamówienia przesłane w dni wolne od pracy oraz w dni świąteczne są zaliczane na poczet następnego dnia roboczego - T0. Data realizacji migracji wskazana przez Biorcę lub Dawcę musi się mieścić w przedziale między 21 Dni Roboczych a 120 Dni Kalendarzowych i nie może przypadać na dzień świąteczny, ani wolny od pracy. Komunikaty, (czyli treść plików XML) będą wklejane do treści wiadomości e-mail, następnie email będzie kodowany PGP i przesyłany do dedykowanych skrzynek pocztowych, gdzie nastąpi dalsze procesowanie zawartych w komunikatach informacji. 2.1. Ustawienia techniczne systemów TP i Przedsiębiorcy telekomunikacyjnego Dla wiadomości przesyłanych od Przedsiębiorcy telekomunikacyjnego do TP, skrzynka pocztowa TP będzie miała adres: MPM_YY@telekomunikacja.pl W miejsce YY należy wstawić numer z rejestru Przedsiębiorców telekomunikacyjnych nadany przez UKE. Wiadomości przesyłane z XXXXX do TP będą wysyłane ze skrzynki pocztowej o adresie: XXXXX@xxx.xx Dla wiadomości przesyłanych z TP do Przedsiębiorcy telekomunikacyjnego, skrzynka pocztowa xxxxx będzie miała adres: XXXXX@xxx.xx Wiadomości przesyłane z TP do Przedsiębiorcy telekomunikacyjnego będą wysyłane ze skrzynki pocztowej o adresie: XXXXX@telekomunikacja.pl 10
Dla wiadomości testowych przesyłanych z XXXXX do TP, skrzynka pocztowa TP będzie miała adres: XXXXX@telekomunikacja.pl Wiadomości testowe przesyłane z XXXXX do TP będą wysyłane ze skrzynki pocztowej o adresie: XXXXX@xxx.xx Dla wiadomości testowych przesyłanych z TP do Przedsiębiorcy telekomunikacyjnego, skrzynka pocztowa Operatora będzie miała adres: XXXXX@xxx.xx Wiadomości testowe przesyłane z TP do XXXXX będą wysyłane ze skrzynki pocztowej o adresie: XXXXX@telekomunikacja.pl System TP wysyłający maile będzie prezentował się adresem IP: XX.XX.XX.XX. System Operatora wysyłający maile będzie prezentował się adresem IP: XX.XX.XX.XX. System TP wysyłający maile testowe będzie prezentował się adresem IP: XX.XX.XX.XX. System Operatora wysyłający maile testowe będzie prezentował się adresem IP: XX.XX.XX.XX. W przypadku konieczności zmiany adresów e-mail, do których jest przesyłana poczta lub, z których jest wysyłana poczta oraz zmiany adresów IP systemów wysyłających pocztę, Strony powiadomią siebie telefonicznie (na numer telefonu administratora systemu) oraz e-mailem (na adres administratora systemu) najdalej na 2 dni robocze przed planowaną zmianą. Niniejszy dokument w ramach prac zespołów roboczych, TP i Przedsiębiorcy telekomunikacyjnego będzie ulegał modyfikacji. Modyfikacje będą wykonywane w formie pisemnej i będą podlegały akceptacji przez Strony. 2.2. Zasady bezpieczeństwa przesyłu danych Każda wiadomość przesłana do TP będzie szyfrowana kluczem publicznym PGP TP. Każda wiadomość przesłana do Przedsiębiorcy telekomunikacyjnego będzie szyfrowana kluczem publicznym Przedsiębiorcy telekomunikacyjnego. Dopuszczalne jest szyfrowanie dwoma kluczami publicznymi - Przedsiębiorcy telekomunikacyjnego, do którego kierowany jest e-mail i własnym. Strony wymienią się kluczami publicznymi PGP służącymi do kodowania danych przesyłanych pomiędzy sobą już na etapie testów. O zmianach dotyczących kluczy publicznych strony będą się wzajemnie informować najdalej na dwa dni robocze przed planowaną zmianą. Strony będą przekazywać sobie klucze publiczne za pomocą e-maili, na adresy administratorów systemów obu stron. Przed zaszyfrowaniem wiadomość e-mail powinna zostać zapisana w formacie MIME. Wiadomość w formacie MIME składa się z nagłówków oraz właściwej zawartości (body, content). Szyfrowanie PGP wiadomości email, polega na stworzeniu nowej wiadomości, która zawiera niezmienione nagłówki z oryginału oraz zawartości, która jest zaszyfrowaną zawartością oryginału opatrzoną odpowiednim typem zawartości (content type). Wiadomość po zaszyfrowaniu musi być dalej poprawną wiadomością w formacie MIME. 11
Dokładny opis szyfrowania e-mail zawarty jest w dokumencie RFC2015 (http://rfc.net/rfc2015.html). Informacje dotyczące szyfrowania PGP zawarte są w dokumencie RFC2440 (http://rfc.net/rfc2440.html). Każda wiadomość wysłana od Przedsiębiorcy telekomunikacyjnego do TP będzie potwierdzana przez TP mailem, w którego treści będzie wklejony odpowiednio sformatowany komunikat XML zawierający potwierdzenie otrzymania Zamówienia Migracji od Przedsiębiorcy telekomunikacyjnego. Potwierdzenie to oznacza, że Zamówienie Migracji od Przedsiębiorcy telekomunikacyjnego dotarło w całości, dane zawarte w Zamówieniu Migracji są poprawne pod względem informatycznym oraz dostarczone w wymaganym czasie od daty generacji (potwierdzenie nie obejmuje innej weryfikacji formalnej danych). Podobnie każdy komunikat z TP do Przedsiębiorcy telekomunikacyjnego zostanie potwierdzony przez Przedsiębiorcę telekomunikacyjnego e-mail em, w którego treści będzie wklejony odpowiednio sformatowany komunikat XML zawierający potwierdzenie otrzymania komunikatu z TP. W przypadku, gdy otrzymany komunikat Zamówienia Migracji nie może być przyjęty z uwagi na błędy w zawartości (błędy informatyczne), strona, do której był skierowany komunikat wygeneruje potwierdzenie otrzymania komunikatu z błędami (kody błędów są ustalone rozdziale 12). Jeśli otrzymany komunikat nie może być obsłużony przez system informatyczny Przedsiębiorcy telekomunikacyjnego z powodu błędów krytycznych w strukturze wiadomości, awarii systemu, wyłączenia systemu na czas prac konserwacyjnych, wyłączenia kanału komunikacyjnego z powodu awarii po stronie Przedsiębiorcy telekomunikacyjnego itp., strona, do której był skierowany komunikat wygeneruje komunikat awaryjny ABORT na adres e-mail, z którego została przysłany nieobsłużony komunikat. W zależności od przyczyny odrzucenia przesyłki, strona, która wygenerowała przesyłkę jest zobowiązana do poprawienia błędów i powtórnego wysłania przesyłki lub uruchomienia komunikacji kanałem awaryjnym. Poprawiony komunikat powinien zawierać zaktualizowane informacje o dacie jego generacji i nowe, unikalne INTERACTION-ID. Formaty przesyłek oraz formaty potwierdzeń (zarówno pozytywnych jak i negatywnych) są opisane w tym dokumencie. Strony ustalają, że na podstawie rejestru przedsiębiorów telekomunikacyjnych UKE, TP będzie posiadała identyfikator liczbowy = 1. 2.3. Specyfikacja postaci wiadomości e-mail Każda wiadomość e-mail przesyłana na skrzynkę pocztową wymiany komunikatów będzie miała następującą postać: Tytuł wiadomości: id:[<ident Przedsiębiorcy telekomunikacyjnego wg UKE>][INTERACTION-ID]<nazwa typu komunikatu>[<xml>] Przykładowa postać komunikatu zamówień Migracji przesłanej od Przedsiębiorcy telekomunikacyjnego będzie następująca: Tytuł wiadomości: id:[99][123456]zamowienie-migracja[xml] Przykładowa postać potwierdzenia odbioru wiadomości zamówienia Migracji przesłanej od TP do Przedsiębiorcy telekomunikacyjnego będzie następująca: 12
Tytuł wiadomości: id:[1][123456]zamowienie-migracja-ack[xml] Identyfikator sesji (INTERACTION-ID) w przypadku komunikatów od Przedsiębiorcy telekomunikacyjnego do TP musi być unikalnym identyfikatorem wymiany danych w obrębie danego źródła komunikatu (Przedsiębiorcy telekomunikacyjnego Migracji). Identyfikator ten będzie liczbą całkowitą o długości maksymalnej 10 znaków [INT(10)]. Identyfikator nie musi zachowywać sekwencyjności numeracji. W przypadku komunikatów wysyłanych od TP do Przedsiębiorcy telekomunikacyjnego identyfikator sesji będzie unikalnym identyfikatorem wymiany danych w obrębie całej wymiany ze wszystkimi Przedsiębiorcami telekomunikacyjnymi. Identyfikator ten będzie liczbą całkowitą o długości maksymalnej 10 znaków [INT(10)]. Komunikaty ACK są technicznym potwierdzeniem odczytania komunikatu przez adresata wysyłanej informacji. 13
3. Typy danych Jeśli szczegółowy opis w specyfikacji komunikatów nie stanowi inaczej, przyjmuje się następującą interpretację typów danych: INT, INTEGER - liczba całkowita z zakresu od 0 do 32767, reprezentowana przez ciąg znaków INT(n) - liczba całkowita, nieujemna, reprezentowana przez ciąg n znaków DATE - data reprezentowana przez ciąg znaków w postaci RRRR-MM-DD GG:mm:SS, gdzie RRRR - rok (4 cyfry), MM - miesiąc (2 cyfry od 01 do 12), DD dzień (2 cyfry od 01 do 31), GG - godzina (2 cyfry od 00 do 23), mm - minuty (2 cyfry od 00 do 59), SS - sekundy (2 cyfry od 00 do 59) np. 2007-11-15 13:52:45 oznacza datę 15 listopada 2007 godz. 13:52:45. Dopuszcza się zapis daty w postaci RRRR-MM-DD - wówczas godzina nie jest znacząca, a systemy przyjmują godzinę 00:00:00. CHAR - jeden znak CHAR(512) - pole znakowe o długości 512 znaków W przypadku typów INT, zera wiodące są ignorowane przez systemy, dlatego jeśli np. w jednym komunikacie pole <INTERACTION-ID> będzie zawierało ciąg znaków "1234", a w kolejnym takim komunikacie pole <INTERACTION-ID> będzie zawierało ciąg znaków "00001234", to drugi komunikat zostanie odrzucony z powodu powtórzonego <INTERACTION-ID>. Struktura większości komunikatów została wstępnie przygotowana do obsługi wieloelementowych grup komunikatów, które mogą być w przyszłości wykorzystane do przekazywania grup komunikatów. W chwili obecnej przewiduje się przesyłanie wyłącznie komunikatów w postaci pojedynczych zleceń (zamówień, odpowiedzi, statusów, zgłoszeń itp.). Oznacza to, że pole SIZE nie będzie występowało w komunikatach, a pole ITEM zawsze będzie zawierało wartość "1". Obsługa wieloelementowych grup komunikatów określonych typów może zostać włączona po uprzednim uzgodnieniu między operatorami. 3.1. Typy pól 3.1.1. ADDRESS Format tagowy Pole zawierające podrzędne tagi zawierające składowe adresu o następującym układzie: ADDRESS Nazwa pola Typ Opis Czy wymagany? /CH AR(512) CITY-NAME CHAR(50) Miejscowość STREET-NAME CHAR(50) Ulica NIE BUILDING-NUMBER CHAR(8) Numer domu FLAT-NUMBER CHAR(8) Numer lokalu NIE POSTAL-CODE CHAR(6) Kod pocztowy POSTAL-NAME CHAR(100) Poczta (Uwaga! Wartości pól adresowych nie mogą zawierać przecinków) nadrzędny 14
Przykładowy fragment XML: <address> <city-name>warszawa</city-name> <street-name>woronicza</street-name> <building-number>17</building-number> <flat-number>34</flat-number> <postal-code>44-100</postal-code> <postal-name>warszawa</postal-name> </address> Pole Nr telefonu Abonenta jest wypełniane jeśli zamówienie dotyczy migracji usługi głosowej na tym numerze. W przypadku BSA dla zamówień dotyczących Migracji będzie podawane pole ID_usługi 3.1.2. LOC-ADDRESS Typ adresu lokalizacyjnego Wszystkie pola odnoszące się do danych adresowych PG/PPD będą posiadały następujący format tagowy: Format tagowy Pole zawierające podrzędne tagi zawierające składowe adresu lokalizacyjnego o następującym układzie: Nazwa pola Typ Opis Czy wymagany? ADDRESS / CHAR(51 2) CITY-NAME CHAR(50) Miejscowość STREET-NAME CHAR(50) Ulica PROPERTY-NUMBER CHAR(50) Numer nieruchomości (Uwaga! Wartości pól adresowych nie mogą zawierać przecinków) nadrzę dny Przykład: przy kaskadzie WLR takie dane nie są wymagane, natomiast przy LLU są konieczne Przykładowy fragment XML: <address> <city-name>warszawa</city-name> <street-name>woronicza</street-name> <property-number>17</property-number> </address> 3.1.3. INT-ID Typ identyfikatora interakcji może występować w 2 formatach. Stosowany format w komunikatach od operatorów zależy od ustaleń konfiguracyjnych. 15
W przypadku komunikatów tworzonych przez system do komunikacji z Operatorem, które nie są komunikatami typu ACK zawsze stosowany jest format liczbowy. Format stringowy: Pole o typie CHAR(40) Format liczbowy: Pole o typie INT(10) 3.1.4. ORDER-NUMBER Identyfikator zamówienia nadany przez operatora zgłaszającego zamówienie. Format stringowy: Pole o typie CHAR(15) w formacie XXXXXYYYYYYYYYY, gdzie pięć pierwszych cyfry XXXXX będzie identyfikować (kod) operatora/przedsiębiorcy nadany przez UKE, a kolejne dziesięć cyfr będzie oznaczać kolejny numer zamówienia danego operatora np. 000010000002323 3.2. Rodzaje migracji MIGRACJA_1 przejście z usługi na usługę bez zmiany operatora o MIGRACJA_1 z WLR na NP. o MIGRACJA_1 dla z WLR / WLR i BSA na LLU z NP. o MIGRACJA_1 dla z WLR / WLR i BSA na LLU bez NP. o MIGRACJA_1 z POTS/BSA na LLU współdzielone o MIGRACJA_1 z NBSA na LLU pełne bez NP o MIGRACJA_1 z NBSA na LLU współdzielone o MIGRACJA_1 przejście z usługi głosowej na NP MIGRACJA_2 przejście od operatora do operatora bez zmiany usługi (kaskada BSA na BSA, WLR na WLR, NP. na NP) MIGRACJA_3 przejście zmienia się zarówno operator, jak i usługa o MIGRACJA_3 z WLR / WLR i BSA na LLU z NP. o MIGRACJA_3 z WLR / WLR i BSA na LLU bez NP. o MIGRACJA_3 z WLR na NP o MIGRACJA_3 z POTS/BSA na LLU pełne z NP. o MIGRACJA_3 z POTS/BSA na LLU pełne bez NP. o MIGRACJA_3 z POTS/BSA na LLU współdzielone o MIGRACJA_3 z NBSA na LLU pełne bez NP o MIGRACJA_3 z NBSA na LLU współdzielone o MIGRACJA_3 z powroty z BSA do TP 16
o MIGRACJA_3 przejście z usługi głosowej na NP Dotychczasowa realizacji procesów MPM dla których usługa NP. jest jedną ze składowych zamówienia LLU, będzie realizowana zgodnie z procesem dla usługi LLU. 17
4. Słownik pojęć Biorca Przedsiębiorca telekomunikacyjny świadczący usługi stacjonarnej usługi telefonicznej z którym abonent zamierza podpisać umowę o świadczenie usług telekomunikacyjnych w zakresie usługi (BSA, LLU, WLR, NP) CHAR(n) Ciąg znaków o długości maksymalnej n (np. CHAR(512) pole znakowe gdzie można wstawić ciąg znaków o długości maksymalnej 512 znaków). Dawca Przedsiębiorca telekomunikacyjny aktualnie świadczący usługi na rzecz abonenta w ramach dostępu telekomunikacyjnego do sieci TP realizowanego na podstawie umów lub decyzji: BSA, LLU, WLR NP.? Date() Data reprezentowana przez ciąg znaków w postaci RRRR- MM-DD GG:mm:SS, gdzie RRRR - rok (4 cyfry), MM - miesiąc (2 cyfry od 01 do 12), DD dzień (2 cyfry od 01 do 31), GG - godzina (2 cyfry od 00 do 23), mm - minuty (2 cyfry od 00 do 59), SS - sekundy (2 cyfry od 00 do 59). W niektórych przypadkach dopuszcza się zapis daty w postaci RRRR-MM-DD - wówczas godzina nie jest znacząca, a systemy przyjmują godzinę 00:00:00. DR Wszystkie dni tygodnia za wyjątkiem sobót, niedziel oraz innych dni ustawowo wolnych od pracy na terenie RP. Godziny DR 23:59 00:00 Migracja Przejście usług hurtowych w ramach dostępu telekomunikacyjnego w ramach sieci TP dedykowana dla PT którzy mają obecnie podpisaną umowę o dostępie telekomunikacyjnym w zakresie usług hurtowych oraz podpisane porozumienie w zakresie Modelu Przejść Międzyoperatorskich. Migrację można ustanowić na wszystkich Łączach Abonenckich Aktywnych na których świadczone są obecnie usługi hurtowe BSA, LLU, WLR z możliwością zachowania numeru przez abonenta. Migrację TP realizuje w ramach regulowanych usług hurtowych BSA, LLU, WLR, MWD Model Wymiany Danych NBSA Aktywna usługa szerokopasmowa BSA na łączu na którym nie jest świadczona usługa telefoniczna POTS lub WLR NWF Negatywna Weryfikacja Formalna NWT Negatywne Warunki Techniczne Przedsiębiorca telekomunikacyjny RTPrzylacze TP ZT Przedsiębiorca lub inny podmiot uprawniony do wykonywania działalności gospodarczej na podstawie odrębnych przepisów, który wykonuje działalność gospodarczą polegającą na dostarczaniu sieci telekomunikacyjnych, udogodnień towarzyszących lub świadczeniu usług telekomunikacyjnych, przy czym przedsiębiorca telekomunikacyjny, uprawniony do: świadczenia usług telekomunikacyjnych, zwany jest dostawcą usług, dostarczania publicznych sieci telekomunikacyjnych lub udogodnień towarzyszących Realizacja Techniczna Przyłącza Telekomunikacja Polska S.A. Dokument Załącznik Teleadresowy 18
5. Odpytanie TP przez Przedsiębiorcę telekomunikacyjnego o aktywne usługi hurtowe na danym Łączu Abonenckim Aktywnym 5.1. Zapytanie o aktywne usługi hurtowe Każdy Przedsiębiorca Telekomunikacyjny, który ma podpisaną z TP umowę o połączeniu sieci, może wystąpić do TP z zapytaniem o usługi hurtowe świadczone na danym łączu oraz o obecnego dostawcę/dawców usług. W tym celu wysyła zapytanie do TP poprzez interfejs informatyczny (System do komunikacji z Operatorem) podając numer telefonu lub ID usługi oraz adres instalacji, którego dotyczy zapytanie. 5.1.1. Komunikat zapytania o aktywne usługi na danym Łączu Abonenckim Temat wiadomości: id:[subject-id][interaction-id]zapytanie-o-uslugi[xml] SERVICE-QUERY (Operator Biorca->BNP)<T_3_0> Komunikat zapytania o aktywne usługi na danym Łączu Abonenckim. Operator -> BNP Komunikat przesyłany kanałem elektronicznym. Nazwa pola Typ Opis Czy wymagany? MSG-HEADER Identyfikacja komunikatu INTERACTION-ID INT-ID Identyfikator interakcji SUBJECT-ID CHAR(40) Identyfikacja nadawcy komunikatu DEST-SUBJECT-ID CHAR(40) Identyfikacja odbiorcy komunikatu TEST-VER INT(1) Identyfikator komunikatu testowego 0 komunikat produkcyjny 1 komunikat testowy SERVICE-QUERY SIZE INT(10) Ilość zapytań w komunikacie elektronicznym SERVICE-OPER CHAR(10) Identyfikator UKE operatora, do którego kierowane są zapytania GENERATE-DATE DATE (RRRR- MM-DD GG:MM:SS ) Data generacji zapytań NIE Brak pola oznacza tryb pojedynczego zapytania nadrzędny 19
Nazwa pola Typ Opis Czy wymagany? SERVICE-QUERY- ELEMENT Może występować wielokrotnie (ilość rekordów zgodna z polem SIZE brak pola SIZE oznacza pojedyncze zapytanie) ITEM INT(12) Numer kolejny zapytania w komunikacie QUERY-ID CHAR(20) Identyfikator zapytania NUMBER CHAR(10) Numer telefonu Jeżeli pole SERVICE-ID jest puste SERVICE-ID CHAR(12) Identyfikator usługi Jeżeli pole NUMBER jest puste CLIENT-ADDRESS ADDRESS Adres lokalizacji łącza QUERY- AGREEMENT MSG INT(1) CHAR(1024 ) PT oświadcza, że posiada zgodę Abonenta na przetwarzania danych osobowych przez TP na potrzeby Odpytania o aktywne usługi świadczone na danym łączu oraz na ujawnienie przez TP informacji objętych tajemnicą telekomunikacyjną. Informacje dodatkowe (wartości dozwolone 0 - brak zgody 1 - zgoda ) NIE nadrzędny SERVICE- QUERY Przykładowy XML: <?xml version="1.0" encoding="utf-8"?> <cbnp-message xmlns="http://www.telekomunikacja.pl/cbnp/cbnp-xml-protocol/ver_3_0"> <msg-header> <interaction-id>123456</interaction-id> <subject-id>6</subject-id> <dest-subject-id>1</dest-subject-id> <test-ver>0</test-ver> </msg-header> <service-query> <size>1</size> <service-oper>1</service-oper> <generate-date>2006-08-22 08:00:00</generate-date> <service-query-element> <item>1</item> <query-id>sdfa123123</query> <number>322251527</number> <service-id></service-id> <client-address> <city-name>kozia Wólka</city-name> <street-name>mickiewicza</street-name> 20
<building-number>12</building-number> <flat-number>35</flat-number> <postal-code>00-345</postal-code> <postal-name>kozia Wólka</postal-name> </client-address> <msg>dodatkowe informacje </msg> </service-query-element> </service-query> </cbnp-message> 5.1.2. Komunikat potwierdzenia przyjęcia komunikatu SERVICE- QUERY Temat wiadomości: id:[subject-id][interaction-id]zapytanie-o-uslugi-ack[xml] SERVICE-QUERY-ACK (BNP->Operator Biorca)<T_3_0> Komunikat potwierdzenia przyjęcia komunikatu SERVICE-QUERY przesyłany synchronicznie. BNP -> Operator Komunikat przesyłany kanałem elektronicznym. Nazwa pola Typ Opis Czy wymagany? MSG-HEADER Identyfikacja komunikatu INTERACTION-ID INT-ID Identyfikator interakcji SUBJECT-ID CHAR(40) Identyfikacja nadawcy komunikatu DEST-SUBJECT-ID CHAR(40) Identyfikacja odbiorcy komunikatu TEST-VER INT(1) Identyfikator komunikatu testowego 0 komunikat produkcyjny 1 komunikat testowy SERVICE-QUERY- ACK ACCEPTANCE Informacja o akceptacji Może występować wielokrotnie (ilość rekordów zgodna z ilością elementów zapytania) ITEM INT(12) Numer kolejny potwierdzenia w komunikacie ACC-STATUS INT(1) Status przyjętego komunikatu w postaci cyfrowej: 0 OK, 1 - REJECTED REJECTION- REASON MSG INT(4) Powód odrzucenia Jeżeli ACC- STATUS = 1 CHAR(1024 ) Komunikat błędu NIE nadrzędny SERVICE- QUERY- ACK 21
Nazwa pola Typ Opis Czy wymagany? ACC-DATE DATE (RRRR- MM-DD GG:MM:SS ) Data wygenerowania potwierdzenia odbioru nadrzędny Przykładowy XML: <?xml version="1.0" encoding="utf-8"?> <cbnp-message xmlns="http://www.telekomunikacja.pl/cbnp/cbnp-xml-protocol/ver_3_0"> <msg-header> <interaction-id>123456</interaction-id> <subject-id>1</subject-id> <dest-subject-id>6</dest-subject-id> <test-ver>0</test-ver> </msg-header> <service-query-ack> <acceptance> <item>1</item> <acc-status>0</acc-status> <acc-date>2008-12-22 14:00:00</acc-date> </acceptance> </service-query-ack> </cbnp-message> 5.2. Informacja o zainstalowanych usługach na aktywnym łączu abonenckim TP w ciągu 2 DR udziela operatorowi informacji o tym, jakie usługi hurtowe są zainstalowane na danym numerze telefonu/id usługi oraz podaje PT, dla którego świadczona jest dana usługa. 5.2.1. Komunikat odpowiedzi na zapytanie o aktywne usługi na danym Łączu Abonenckim Temat wiadomości: id:[subject-id][interaction-id]odpowiedz-zapytanie-o-uslugi[xml] SERVICE-QUERY-RESULT (BNP->Operator Biorca)<T_3_0> Komunikat informacji o aktywnych usługach na danym Łączu Abonenckim. BNP->Operator Komunikat przesyłany kanałem elektronicznym. Nazwa pola Typ Opis Czy wymagany? MSG-HEADER Identyfikacja komunikatu INTERACTION-ID INT-ID Identyfikator interakcji SUBJECT-ID CHAR(40) Identyfikacja nadawcy komunikatu DEST-SUBJECT-ID CHAR(40) Identyfikacja odbiorcy komunikatu TEST-VER INT(1) Identyfikator komunikatu testowego 0 komunikat produkcyjny 1 komunikat testowy nadrzędny 22
Nazwa pola Typ Opis Czy wymagany? SERVICE-QUERY- RESULT SIZE INT(10) Ilość odpowiedzi w komunikacie elektronicznym GENERATE-DATE SERVICE-QUERY- RESULT-ELEMENT DATE (RRRR- MM-DD GG:MM:SS ) Data generacji odpowiedzi NIE Brak pola oznacza tryb pojedynczej odpowiedzi Może występować wielokrotnie (ilość rekordów zgodna z polem SIZE brak pola SIZE oznacza pojedynczą odpowiedź) ITEM INT(12) Numer kolejny odpowiedzi w komunikacie QUERY-ID CHAR(20) Identyfikator zapytania NUMBER CHAR(10) Numer telefonu Jeżeli pole SERVICE-ID jest puste SERVICE-ID CHAR(12) Identyfikator usługi Jeżeli pole NUMBER jest puste CLIENT-ADDRESS ADDRESS Adres lokalizacji łącza QUERY-STATUS INT(4) 0 OK. Zapytanie przyjęte 1 REJECTED - Zapytanie odrzucone 2 NO-RESULT - brak wyników MSG CHAR(1024 ) Informacje dodatkowe. NIE nadrzędny SERVICE- QUERY- RESULT 23
Nazwa pola Typ Opis Czy wymagany? SERVICE Informacja o usługach świdczonych dla numeru SERVICE-NAME INT(4) 1 WLR usługa WLR (usługa głosowa) 2 BSA usługa BSA (usługa szerokopasmowa ATM) 3 LLUP usługa LLU Pełny (usługa głosowa i szerokopasmowa) 4 LLUW - usługa LLU Współdzielony (usługa szerokopasmowa) 5 - rezerwa - VOICE usługa głosowa w TP (usługa głosowa) 6 - BSA BROADBAND TP usługa szerokopasmowa w TP (usługa szerokopasmowa) 7 NP usługa zachowania numeru 8 NBSA usługa BSA w trybie Naked (usługa szerokopasmowa ATM) OPER CHAR(10) Identyfikator UKE operatora dla którego aktualnie świadczona jest usługa wskazana w polu SERVICE-NAME Przykładowy XML: NIE Może wystepować wielokrotnie i tylko raz dla usług głosowych i raz dla usług szerokopasm owych. nadrzędny SERVICE- QUERY- RESULT- ELEMENT <?xml version="1.0" encoding="utf-8"?> <cbnp-message xmlns="http://www.telekomunikacja.pl/cbnp/cbnp-xml-protocol/ver_3_0"> <msg-header> <interaction-id>123456</interaction-id> <subject-id>1</subject-id> <dest-subject-id>6</dest-subject-id> <test-ver>0</test-ver> </msg-header> <service-query-result> <generate-date>2008-12-22 08:00:00</generate-date> <service-query-result-element> <item>1</item> <query-id>sdfa123123</query> <number>322251527</number> <service-number></service-number> <client-address> <city-name>kozia Wólka</city-name> <street-name>koziołka Matołka</street-name> <building-number>12</building-number> <flat-number>35</flat-number> <postal-code>00-345</postal-code> <postal-name>koziegłowy</postal-name> </client-address> <query-status>0</query-status> <msg>informacje dodatkowe</msg> <service> <service-name>1</service-name> <oper>10</oper> 24
</service> <service> <service-name>2</service-name> <oper>18</oper> </service> </service-query-result-element> </service-query-result> </cbnp-message> 5.2.2. Komunikat potwierdzenia przyjęcia komunikatu SERVICE- QUERY-RESULT Temat wiadomości: id:[subject-id][interaction-id]odpowiedz-zapytanie-o-uslugi- ACK[xml] SERVICE-QUERY-RESULT-ACK (Operator Biorca-BNP)<T_3_0> Komunikat potwierdzenia przyjęcia komunikatu SERVICE-QUERY-RESULT przesyłany synchronicznie. Operator -> BNP Komunikat przesyłany kanałem elektronicznym. Nazwa pola Typ Opis Czy wymagany? MSG-HEADER Identyfikacja komunikatu INTERACTION-ID INT-ID Identyfikator interakcji SUBJECT-ID CHAR(40) Identyfikacja nadawcy komunikatu DEST-SUBJECT-ID CHAR(40) Identyfikacja odbiorcy komunikatu TEST-VER INT(1) Identyfikator komunikatu testowego 0 komunikat produkcyjny 1 komunikat testowy SERVICE-QUERY- RESULT-ACK nadrzędny ACCEPTANCE Informacja o akceptacji SERVICE- QUERY- RESULT- ACK ITEM INT(12) Numer kolejny potwierdzenia w komunikacie ACC-STATUS INT(1) Status przyjętego komunikatu w postaci cyfrowej: 0 OK, 1 - REJECTED REJECTION- REASON MSG ACC-DATE INT(4) Powód odrzucenia Jeżeli ACC- STATUS = 1 CHAR(1024 ) DATE (RRRR- MM-DD GG:MM:SS ) Komunikat błędu Data wygenerowania potwierdzenia odbioru NIE 25
Przykładowy XML: <?xml version="1.0" encoding="utf-8"?> <cbnp-message xmlns="http://www.telekomunikacja.pl/cbnp/cbnp-xml-protocol/ver_3_0"> <msg-header> <interaction-id>123456</interaction-id> <subject-id>6</subject-id> <dest-subject-id>1</dest-subject-id> <test-ver>0</test-ver> </msg-header> <service-query-result-ack> <acceptance> <item>1</item> <acc-status>0</acc-status> <acc-date>2008-12-22 14:00:00</acc-date> </acceptance> </service-query-result-ack> </cbnp-message> 26
6. Weryfikacja wniosku abonenta dotyczącego przeniesienia przydzielonego numeru przy zmianie dostawcy usług. ( TP realizuje komunikację pomiędzy Operatorami) 6.1. Odpytanie o warunki NP. Operator Biorca składa drogą elektroniczną za pośrednictwem systemu BNP dedykowane zamówienie odpytania o warunki techniczne oraz datę dla realizacji przeniesienia numeru do innego Operatora. W zamówieniu znajduje się: Identyfikator Zamówienia odpytania (15-cyfrowy gdzie pięć pierwszych cyfr XXXXX będzie identyfikować (kod) operatora/przedsiębiorcy kolejne dziesięć cyfr będzie oznaczać kolejne zamówienie danego operatora tzw. ORDER-NUMBER) Numer abonencki (NUMBER) Rodzaj usługi (NP) poprzez wypełnienie sekcji NUMBER-PORTABILITY Dane klienta ( imię I nazwisko/ nazwa firmy) Adres instalacji, Operator Biorca ( Numer nadany przez UKE) Operator Dawca(Numer nadany przez UKE) Planowana data rozpoczęcia świadczenia usługi przez Biorcę na rzecz Abonenta (BEGIN- DATE). sposób rozwiązania umowy u Operatorów Dawców (DAY- natychmiastowy - oczekiwana przez klienta data przeniesienia, END zgodnie z regulaminem Dawcy, EOP na koniec umowy lojalnościowej)(cease-mode) konieczne jest wypełnienie sekcji CEASE i wskazanie w CEASE-TYPE = 5 VOICE usługa głosowa numer RN * Proces nie jest wymagany dla realizacji zamówień NP 6.1.1. Komunikat odpytania o warunki NP. ORDER-MIGRATION z opcjonalną sekcją wskazująca że komunikat jest tylko zapytaniem ( MODE = 2). Brak tej sekcji oznacza standardowe procesowanie zamówienia MPM. 6.1.2. Komunikat potwierdzenia odpytania o warunki NP. Potwierdzenie zapytania realizowane jest przez standardowy komunikat ORDER-MIGRATION-ACK 6.2. Potwierdzenie daty lub negatywna weryfikacja formalna TP w ciągu 1 DR dokonuje sprawdzenia komunikatu pod względem formalnym i jeżeli weryfikacja jest pozytywna wysyła komunikat do Operatora Dawcy i Operatora Macierzystego ( jeżeli jest inny niż Dawca) o potwierdzenie daty przejścia za pomocą ORDER-MIGRATION-TO-OPER w przypadku negatywnej weryfikacji formalnej TP prześle komunikat odmowy realizacji zamówienia odpytania wraz z podaniem przyczyny (dopisany na komunikacie zamówienia Operatora Biorcy). 27
6.2.1. Komunikat potwierdzenie daty lub negatywna weryfikacja formalna ORDER-MIGRATION-STATUS Potwierdzenie daty przesyłane jest do Biorcy komunikatem ORDER-MIGRATION-STATUS po wcześniejszym odebraniu komunikatów od Dawcy i Macierzystego. Odbywa się to za pomocą ORDER-MIGRATION-TO-OPER-ACC. Komunikat ten w trybie zapytania będzie posiadał dodatkową sekcję wskazującą na ten tryb (MODE). Realizacja negatywnej weryfikacji odbywa się poprzez przesłanie komunikatu ORDER- MIGRATION-STATUS (SERVICE-STAUS = 1 REJECTED ) 6.2.2. Komunikat potwierdzenia dostarczenia komunikatu potwierdzenia daty lub negatywnej weryfikacji formalnej. Potwierdzenie realizowane jest przez standardowy komunikat ORDER-MIGRATION-STATUS-ACK 6.3. Odpowiedź od Dawcy i Macierzystego Operator Dawca oraz Macierzysty mają 1 DR na potwierdzenie daty wykonania NP. Brak odpowiedzi przez Dawcę i Macierzystego ( jeżeli jest inny niż Dawca) w wyznaczonym terminie TP traktuje jako odpowiedź pozytywną. 6.3.1. Komunikat odpowiedzi od Dawcy i Macierzystego Komunikat zawiera dane przesłane przez Biorcę i dodatkowo: - Potwierdzenie realizacji przejścia przez Dawcę wraz z Datą możliwej realizacji. - przyczynę zmiany daty wymaganej - Potwierdzenie możliwości wykonania RN przez macierzystego ( jeżeli jest inny niż Dawca) - datę i godzinę przekazania komunikatu przez do TP ORDER-MIGRATION-TO-OPER-ACC 6.3.2. Komunikat potwierdzenia dostarczenia odpowiedzi od Dawcy i Macierzystego Potwierdzenie realizowane jest przez standardowy komunikat ORDER-MIGRATION-TO-OPER- ACC-ACK 6.4. Potwierdzenie daty realizacji lub odrzucenie W przypadku gdy Dawca lub Macierzysty ( jeżeli jest inny niż Dawca) odrzuci możliwość realizacji przejścia z podaniem powodu, TP przesyła komunikat do Operatora Biorcy z informacją o braku akceptacji i następuje zakończenie zamówienia z wynikiem negatywnym W przypadku gdy Dawca i/lub Macierzysty nie prześle komunikatu, lub prześle odpowiedź pozytywną, TP przesyła komunikat do Operatora Biorcy z informacji o potwierdzeniu daty realizacji. 28
6.4.1. Komunikat potwierdzenie daty realizacji lub odrzucenie Odpowiedź ORDER-MIGRATION-STATUS zawiera dane przesłane przez Biorcę i dodatkowo: - przyczyna weryfikacji negatywnej Dawcy lub Macierzystego - datę i godzinę przekazania komunikatu przez TP 6.4.2. Komunikat potwierdzenia dostarczenia potwierdzenia daty realizacji lub odrzucenie Potwierdzenie realizowane jest przez standardowy komunikat ORDER-MIGRATION- STATUS-ACK 29
7. Migracja Usługi Abonenckiej od Przedsiębiorcy telekomunikacyjnego korzystającego (Dawca) do innego Przedsiębiorcy telekomunikacyjnego (Biorca) ze zmianą Usługi Hurtowej 7.1. Schemat migracji 30
7.2. Opis kroków schematu 1) Abonent składa u Operatora Biorcy wniosek o nową usługę oraz rezygnację z aktualnych usług, która wymagana jest dla realizacji zamówienia. 2) a i b) W imieniu i z upoważnienia Abonenta Biorca przekazuje Operatorom Dawcom dokument Rezygnacji abonenta z aktualnych usług. Dla zgłoszeń dotyczących NP. nie obowiązku przekazania dokumentów, udostępnienie oryginału może wystąpić na rządanie. c) Po otrzymaniu potwierdzenia dostarczenia oświadczenia o rezygnacji do Operatora Dawcy/Dawców Biorca przesyła do TP zamówienie w formie elektronicznej na nowe usługi np. LLU z NP, ze wskazaniem usług z których abonent rezygnuje u innych operatorów. d) TP w sytuacji, gdy komunikat xml nie zawiera niezbędnych informacji o rezygnacji z wszystkich usług hurtowych na danym łączu, TP powiadamia o tym operatora Biorcę, tym samym zamówienie jest zamykane z odpowiednim statusem (odrzucenie z przyczyn formalnych). TP ma 1 DR dla zamówień dotyczących NP. lub 2 DR dla pozostałych zamówień Migracji na weryfikację, liczone od daty wpływu, gdzie dzień wpływu jest dniem zerowym. Przyczyny odrzuceń formalnych wypisane są w rozdziale 12. Odrzucenie z przyczyn formalnych jest możliwe również z innych powodów niż brak rezygnacji z usługi u Dawcy, zgodnie z załączonymi kodami odrzuceń dla NWF (rozdział 12). 3) TP wysyła komunikat do Operatorów Dawców wraz z przekazaniem daty rezygnacji lub trybu rozwiązania w przypadku NP. Komunikat jest wysyłany najpóźniej w ostatnim dniu weryfikacji (2DR). 4) a i b) Operatorzy Dawcy i Macierzysty w ciągu 6 DR dla zamówień dotyczących NP. lub 3 DR dla zamówień dotyczących Migracji od daty przesłania komunikatu (pkt.3) zobowiązani są do potwierdzenia realizacji zamówienia lub wskazują jeden z powodów odmowy realizacji zamówienia do TP. Operatorzy Dawcy mogą również zgłosić przesunięcie daty przełączenia w określonych granicach czasowych. Brak odpowiedzi w w/w terminie oznacza akceptację dla realizacji zgodnie z zamówieniem Biorcy. 5) a) TP potwierdza Operatorowi Biorcy realizację zlecenia wraz z datą realizacji bądź odmawia realizacji wskazując przyczynę i Operatora, który odmówił realizacji. b i c) Jednocześnie TP przesyła do Operatorów Dawców potwierdzenie daty zaprzestania świadczenia usług. 6) a, b i c) Biorca lub Dawcy, najpóźniej na 5 DR dla zamówień dotyczących NP. lub 10 DR dla pozostałych zamówień Migracji przed datą wymaganą, mogą przesłać rezygnację Abonenta wysyłając właściwy komunikat xml do TP. 7) a i b) TP informuje Operatorów Dawców o rezygnacji i anuluje zamówienie Migracji Operatora Biorcy. Rezygnacja skutkuje wstrzymaniem wypowiedzenia umów z klientem - utrzymaniem obecnych usług. 8) TP potwierdza Biorcy wykonanie anulowania zamówienia. 9) TP po zrealizowaniu zamówienia NP potwierdza Biorcy realizację zamówienia (dotyczy przypadku gdy TP nie jest stroną). 10) TP po zrealizowaniu zamówienia Migracji potwierdza Biorcy realizację zamówienia.