Model Wymiany Danych dla Migracji Usług Hurtowych w ramach dostępu telekomunikacyjnego do sieci TP Wersja 5.9 Status: zamroŝony Planowana Data wdroŝenia: 2011-03-31 Model Wymiany Danych 5.9 1
Historia zmian Wersja Data modyfikacji 1.0 7.07.2008 Utworzenie dokumentu Opis 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 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, nieuwzglę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 reklamacji. 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 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ędnienie uwag biznesowych informatycznych Model Wymiany Danych 5.9 2
Wersja Data modyfikacji 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ładania 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 Opis 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 Dodanie rozdziału 6 Odpytanie o warunki dla NP. 1. Modyfikacja 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. 5.9 18.11.2010 1. Aktualizacja dokument pod kątem poprawnej zawartości komunikatów dotyczących zmiany wartości pola dla atrybutów z zawiera wyłączenie cyfr na zawiera znaki liczbowe. zawiera wyłączenie cyfr na zawiera znaki liczbowe. Zmiana wymagalności pola ROUTING-NUMBER na JeŜeli NP-TYPE = 1,2 2. Uproszczenie zapisu dotyczącego skrzynek e-mail do komunikacji produkcyjnej i testów. Aktualizacja linków dla RFC dostępnych w Internecie (stare linki nie działają) Dodanie taga <query-agreement> w przykładzie zapytania o usługi. Aktualizacja wymagań dla pola <number-type>, <number-count>, <number-lo> dla zamówienia migracji. Usunięcie z przykładu zamówienia WLR WLR, <cease-type>6. Uzupełnienie wymagalności pola <produkt-id> dla <order-type> 2 i 8 w komunikacie statusu migracji. Zmiana opisu wymagań dla <attr-value> dla LLU średnica w mm do dwóch miejsc po przecinku Usunięcie <size>1</size> z przykładów (gdy <size>1 pole nie występuje). Uspójnienie nazw BRADBAND-TP oraz BSA-BRAODBAND na nazwę BRAODBAND dla <order-type>, <cease-type>, <product-id>, <service-name> Uzupełnienie przykładów komunikatów XML Model Wymiany Danych 5.9 3
Wersja Data modyfikacji 5.9 18.11.2010 3. Zmiana pola TYPE na MODE w komunikacie akceptacji migracji od operatora ORDER-MIGRATION-TO-OPER-ACC 4. Uściślenie nazewnictwa LLU w rodzajach migracji (LLUP i LLUW) 5. Przeniesienie komunikatów do jednego rozdziału, aktualizacja odwołań do komunikatów w całym dokumencie. 6. Usystematyzowanie kodów odrzuceń - kody weryfikacji formalnej Dostawcy - podział kodów Macierzysty, Dawca - kody odpowiedzi po weryfikacji technicznej 7. W komunikatach <order-migration>, <order-migration-to-oper> wymagalność <service-specyfication> ustawiona na NIE Tylko, jeŝeli <service-type> <> 9 Opis W komunikatach <order-migration> wymagane, <vas-type> ; <vas-value> gdy VAS-TYPE=2, 3, 22 W komunikatach <order-migration-status> wymagalność <line-attr> ustawia się na, jeŝeli określono <produkt-id>. MoŜe występować wielokrotnie W komunikatach <order-migration-status> pole <sernice-id> jest wymagane zawsze, gdy powstaje nowa usługa szerokopasmowa BSA, LLUP, LLUW, BROADBAND, NBSA. Nowy czytelny zapis tego wymagania [, JeŜeli (CEASE-TYPE = 2, 6, 8) lub (SERVICE-TYPE = 9) lub (ORDER-TYPE = 2,3,4,6,8 i SERVICE-STATUS = 4) ] 8. Dodanie dla zamówienia migracji dodatkowej wartości dla sekcji <order-type> 5 - VOICE usługa głosowa 9. Dla <order-migration-status> i <rejected-service> usuwamy słowa rezerwa z 3 - rezerwa - "LLUP" - usługa LLU Pełny (usługa głosowa i szerokopasmowa) 4 - rezerwa - "LLUW" - usługa LLU 10. W komunikacie ORDER-MIGRATION dodano pole BARCODE dla zgodności z MWD-LLU 11. Uzupełniono odwołanie do RFC4880 (http://www.ietf.org/rfc/rfc4880.txt). Dodane w przykładzie dla reklamacji wymaganego pola <client-name> 12. Uszczegółowienie opisu dla pola <test-ver> 13. Wprowadzenie wymagalności <test-ver> dla ORDER-MIGRATION-STATUS Ujednolicenie ograniczeń dla pól ITEM i SIZE do INT(10) 14. W przykładach poprawiono zamknięcia tagów <query-id> z </query> na </queryid> 15. Podział kodów odrzuceń dla ABORT i ACK 16. Aktualizacja dokumentu o procesy zwrotu numeru do operatora macierzystego, zmiana numeru RN, reklamacje NP. 17. Usunięcie opisu w akapitach 8,9 do niezbędnego minimum 18. Zmiany kodów odrzuceń w p. 12. Model Wymiany Danych 5.9 4
Spis Treści 1. Wprowadzenie... 9 2. Podstawowe dane konfiguracyjne - kanał e-mail... 11 2.1. Ustawienia techniczne systemów TP i Przedsiębiorcy telekomunikacyjnego... 11 2.2. Zasady bezpieczeństwa przesyłu danych... 12 2.3. Specyfikacja postaci wiadomości e-mail... 13 3. Typy danych... 15 3.1. Typy pól... 15 3.1.1. ADDRESS... 15 3.1.2. LOC-ADDRESS... 16 3.1.3. INT-ID... 16 3.1.4. ORDER-NUMBER... 17 3.2. Rodzaje migracji... 17 4. Słownik pojęć... 19 5. Zapytanie TP przez Przedsiębiorcę telekomunikacyjnego o aktywne usługi hurtowe na danym Łączu Abonenckim Aktywnym... 20 5.1. Zapytanie o aktywne usługi hurtowe... 20 5.1.1. Komunikat zapytania o aktywne usługi na danym Łączu Abonenckim... 20 5.1.2. Komunikat potwierdzenia przyjęcia 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 SERVICE-QUERY-RESULT... 23 6. Proces przeniesienia numeru przy zmianie dostawcy usług Number Portability ( TP realizuje komunikację pomiędzy Operatorami)... 24 6.1. Rozdział ten opisuje procesy NP. realizowane w Bazie Numerów Przeniesionych przy pomocy komunikatów migracyjnych w zakresie:... 24 6.2. Zapytanie o techniczne warunki realizacji NP... 24 6.2.1. Komunikat zapytania o warunki NP... 25 6.2.2. Komunikat potwierdzenia zapytania o warunki NP.... 25 6.3. Potwierdzenie daty lub negatywna weryfikacja formalna... 25 6.3.1. Komunikat potwierdzenie daty lub negatywna weryfikacja formalna... 25 6.3.2. Komunikat potwierdzenia dostarczenia komunikatu potwierdzenia daty lub negatywnej weryfikacji formalnej... 26 6.4. Odpowiedź od Dawcy i Macierzystego... 26 6.4.1. Komunikat odpowiedzi od Dawcy i Macierzystego... 26 6.4.2. Komunikat potwierdzenia dostarczenia odpowiedzi od Dawcy i Macierzystego... 26 6.5. Potwierdzenie daty realizacji lub odrzucenie... 26 6.5.1. Komunikat - potwierdzenie daty realizacji lub odrzucenie... 26 Komunikat potwierdzenia dostarczenia ORDER-MIGRATION-STATUS... 26 6.5.2. 26 6.6. Zamówienie przeniesienia numeru... 27 6.7. Zwrot Numeru do Operatora Macierzystego,... 29 6.8. Zmiana Numeru Rutingowego w Sieci Operatora Biorcy,... 30 6.9. Anulowanie Operatora Biorcy/Dawcy/Macierzystego zamówienia przeniesienia numeru,... 30 Model Wymiany Danych 5.9 5
7. Migracja Usługi Abonenckiej od Przedsiębiorcy telekomunikacyjnego korzystającego (Dawca) do innego Przedsiębiorcy telekomunikacyjnego (Biorca) ze zmianą Usługi Hurtowej... 31 7.1. Schemat migracji... 31 7.2. Opis kroków schematu... 32 7.3. ZłoŜenie Zamówienia Migracji... 32 7.3.1. Proces po stronie Operatora Biorcy... 34 7.3.2. Opis kroków przesłania Zamówień Migracji... 35 7.3.3. Opis kroków przesłania grupy odpowiedzi na Zamówienia Migracji... 35 7.3.4. Komunikat Zamówień Migracji... 36 7.3.5. Komunikat potwierdzenia zamówień usług migracji... 37 7.4. Negatywna weryfikacja formalna TP... 38 7.4.1. Komunikat statusu... 38 7.4.2. Komunikat potwierdzenia statusu... 44 7.5. Przekazanie daty rezygnacji lub daty wykonania NP do Dawców... 44 7.5.1. Komunikat zgłoszenia Rezygnacji z usług u operatora Dawcy lub daty wykonania NP... 45 7.5.2. Komunikat potwierdzenia zgłoszenia rezygnacji z usług u operatora Dawcy lub daty wykonania NP... 46 7.6. Potwierdzenia realizacji zlecenia Zamówienia lub jego odrzucenie... 47 7.6.1. Komunikat akceptacji rezygnacji lub odrzucenia zlecenia migracji przez Dawców... 48 7.6.2. Komunikat potwierdzenia akceptacji rezygnacji lub odrzucenia zlecenia migracji przez Dawców... 49 7.7. Potwierdzenie do Biorcy oraz Dawcy/Dawców bądź odmowa realizacji Zamówienia Migracji wraz z datą realizacji... 50 7.7.1. Komunikat - informacja o dacie realizacji Zamówienia Migracji/odmowie realizacji zamówienia Migracji 50 7.7.2. Komunikat potwierdzenia dla komunikatu informacji o dacie realizacji Zamówienia Migracji/odmowie realizacji zamówienia Migracji... 51 7.8. Rezygnacja z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia Migracji... 51 7.8.1. Komunikat Rezygnacji z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia Migracji.. 51 7.8.2. Komunikat potwierdzenia Rezygnacji z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia Migracji... 52 7.9. Potwierdzenie do Biorcy, Dawcy/ów anulowania zamówienia migracji... 53 7.9.1. Komunikat statusu anulowania zamówienia migracji... 53 7.9.2. Komunikat potwierdzenia statusu anulowania zamówienia migracji... 53 7.10. Potwierdzenie od Dawcy i Macierzystego wykonania NP... 53 7.10.1. Komunikat potwierdzenia realizacji przez Dawcę i Macierzystego... 54 7.10.2. Komunikat potwierdzenia dostarczenia komunikatu potwierdzającego realizację przez Dawcę i Macierzystego... 54 7.11. Potwierdzenie realizacji Zamówienia Migracji... 54 7.11.1. Komunikat statusu wykonania zamówienia migracji... 55 7.11.2. Komunikat potwierdzenia statusu wykonania zamówienia migracji... 55 7.11.3. Potwierdzenie deinstalacji usługi dla Operatora Dawcy... 55 8. Migracja usługi abonenckiej od Przedsiębiorcy telekomunikacyjnego korzystającego (Dawca) do innego Przedsiębiorcy telekomunikacyjnego (Biorca) bez zmiany usługi hurtowej;... 57 9. Migracja usługi abonenckiej z usługi hurtowej obecnie świadczonej na inną usługę hurtową bez zmiany Przedsiębiorcy telekomunikacyjnego... 58 9.1. ZłoŜenie Zamówienia Migracji... 58 9.1.1. Komunikat Zamówień Migracji... 58 10. Proces zgłaszania reklamacji... 59 10.1. Zgłoszenie reklamacji formalnej... 59 10.1.1. Komunikat zgłaszania reklamacji... 60 10.1.2. Komunikat potwierdzenia zgłoszenia reklamacji formalnej... 60 10.1.3. Komunikat zapytania o informacje dodatkowe w procesie reklamacji.... 61 Model Wymiany Danych 5.9 6
10.1.4. Potwierdzenie ACK dla zapytania o informacje dodatkowe... 62 10.1.5. Komunikat odpowiedzi na zapytanie o informacje dodatkowe w procesie reklamacji.... 62 10.1.6. Potwierdzenie ACK dla odpowiedzi na zapytanie o informacje dodatkowe... 63 10.1.7. Komunikat odpowiedzi na zgłoszenie reklamacji formalnej... 63 10.1.8. Komunikat potwierdzenia odpowiedzi na zgłoszenie reklamacji formalnej... 65 10.2. Zgłoszenie reklamacji technicznej... 66 10.2.1. Komunikat zgłoszenia reklamacji technicznej... 66 10.2.2. Komunikat potwierdzenia zgłoszenia reklamacji technicznej... 67 10.2.3. Komunikat odpowiedzi na zgłoszenie reklamacji technicznej... 67 10.2.4. Komunikat zapytania do biorcy dawcy i macierzystego celem wyjaśnienia przyczyny niezrealizowania lub błędnej realizacji zamówienia NP... 67 10.2.5. Zwrotna odpowiedź Dawcy, Biorcy, Macierzystego na dodatkowe zapytanie... 67 10.2.6. Komunikat potwierdzenia odpowiedzi na zgłoszenie reklamacji technicznej... 68 11. Specyfikacja komunikatów... 69 11.1. Specyfikacja komunikatów dla zapytań... 69 11.1.1. SERVICE-QUERY Komunikat zapytania o aktywne usługi na danym Łączu Abonenckim... 69 11.1.2. SERVICE-QUERY-ACK Komunikat potwierdzenia przyjęcia komunikatu SERVICE-QUERY... 70 11.1.3. SERVICE-QUERY-RESULT Komunikat odpowiedzi na zapytanie o aktywne usługi na danym Łączu Abonenckim... 71 11.1.4. SERVICE-QUERY-RESULT-ACK Komunikat potwierdzenia przyjęcia komunikatu SERVICE-QUERY- RESULT... 73 11.2. Specyfikacja komunikatów dla zamówień migracji... 74 11.2.1. ORDER-MIGRATION Komunikat Zamówień Migracji... 74 11.2.2. ORDER-MIGRATION-ACK Komunikat potwierdzenia zamówień usług migracji... 80 11.2.3. ORDER-MIGRATION-STATUS Komunikat statusu... 81 11.2.4. Lista atrybutów... 87 11.2.5. ORDER-MIGRATION-STATUS-ACK Komunikat potwierdzenia statusu... 89 11.2.6. ORDER-MIGRATION-TO-OPER Komunikat zgłoszenia Rezygnacji z usług u operatora Dawcy lub daty wykonania NP... 90 11.2.7. ORDER-MIGRATION-TO-OPER-ACK Komunikat potwierdzenia zgłoszenia rezygnacji z usług u operatora Dawcy lub daty wykonania NP... 94 11.2.8. ORDER-MIGRATION-TO-OPER-ACC Komunikat akceptacji rezygnacji lub odrzucenia zlecenia migracji przez Dawców... 95 11.2.9. ORDER-MIGRATION-TO-OPER-ACC-ACK Komunikat potwierdzenia akceptacji rezygnacji lub odrzucenia zlecenia migracji przez Dawców... 97 11.2.10. ORDER-MIGRATION-CANCEL Komunikat Rezygnacji z Zamówienia Migracji z powodu odstąpienia Abonenta od zamówienia Migracji... 98 11.2.11. ORDER-MIGRATION-CANCEL-ACK Komunikat potwierdzenia Rezygnacji z Zamówienia Migracji... 99 11.3. Specyfikacja komunikatów dla reklamacji MPM... 100 11.3.1. COMPLAIN-MIGRATION-TO-SERVICE-PACKAGE Komunikat zgłaszania reklamacji... 100 11.3.2. COMPLAIN-MIGRATION-TO-SERVICE-PACKAGE-ACK Komunikat potwierdzenia zgłoszenia reklamacji formalnej... 102 11.3.3. COMPLAIN-MIGRATION-TO-OPER (BNP-Operator MPM)<T 3 0>... 103 11.3.4. COMPLAIN-MIGRATION-TO-OPER-ACK (Operator MPM- BNP)<T 3 0>... 105 11.3.5. COMPLAIN-MIGRATION-TO-OPER-ACC (Operator MPM-BNP)<T 3 0>... 106 11.3.6. COMPLAIN-MIGRATION-TO-OPER-ACC-ACK (BNP-Operator MPM)<T 3 0>... 107 11.3.7. COMPLAIN-MIGRATION-TO-SERVICE-REPLY-PACKAGE Komunikat odpowiedzi na zgłoszenie reklamacji formalnej... 108 11.3.8. COMPLAIN-MIGRATION-TO-SERVICE-REPLY-PACKAGE-ACK Komunikat potwierdzenia odpowiedzi na zgłoszenie reklamacji formalnej... 110 11.4. Specyfikacja komunikatów awaryjnych... 112 11.4.1. Komunikat ABORT... 112 12. Kody odrzuceń dla korelacji i przejść pomiędzy Operatorami... 114 12.1. Kody odrzuceń weryfikacja informatyczna...błąd! Nie zdefiniowano zakładki. Model Wymiany Danych 5.9 7
12.2. Kody odpowiedzi weryfikacji formalnej Dostawcy...Błąd! Nie zdefiniowano zakładki. 12.3. Kody odrzucenia rezygnacji przez Macierzystego...Błąd! Nie zdefiniowano zakładki. 12.4. Kody odrzucenia rezygnacji przez Dawcę...Błąd! Nie zdefiniowano zakładki. 12.5. Kody odpowiedzi Dostawcy do Biorcy/Dawcy/Macierzystego dotyczące weryfikacji technicznej...błąd! Nie zdefiniowano zakładki. 12.6. Kody związane z rezygnacją Abonenta otrzymaną od Dawcy/ Biorcy...Błąd! Nie zdefiniowano zakładki. 13. Kody odrzuceń dla informacji o usługach hurtowych... 117 14. Kody odrzuceń dla reklamacji... 118 14.1. Negatywna weryfikacja informatyczna w BNP - Kody odrzucenia reklamacji przez BNP... 118 14.2. Negatywny wynik rozpatrzenia Reklamacji - Kody odrzucenia reklamacji... 118 14.3. Wynik rozpatrzenia reklamacji... 118 14.4. Przedmiot Reklamacji... 118 Model Wymiany Danych 5.9 8
1. Wprowadzenie Niniejszy dokument jest opisem Modelu Wymiany Danych (MWD) dla Migracji Usług Hurtowych w ramach dostępu telekomunikacyjnego do sieci TP zawartym pomiędzy: Telekomunikacją Polską S.A. (dalej zwaną TP) a Przedsiębiorcą telekomunikacyjnym. Dokument ten jest realizacją zakresu i wymagań zgodnie z Decyzją UKE o elektronicznej komunikacji między operatorami. 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ń. Serwer poczty e-mail Operatora Serwer poczty e-mail TP Operator System TP Migracja Usług Hurtowych w ramach dostępu telekomunikacyjnego w 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 oparte na dokumencie Model 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; Model Wymiany Danych 5.9 9
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 (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 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ą tego kanału, 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. Model Wymiany Danych 5.9 10
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. W specyficznych przypadkach np. usługa NP, wskazany zakres dat moŝe być inny. Szczegółowy opis zamieszczono w dalszej części Dokumentu. 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 pomiędzy Operatorem a TP, skrzynka pocztowa TP będzie miała adres: MPM_XX@telekomunikacja.pl W miejsce XX naleŝy wstawić numer z rejestru przedsiębiorców telekomunikacyjnych nadany przez UKE. skrzynka pocztowa Operatora będzie miała adres: XXXXX@xxx.xx. Dla celów testów międzyoperatorskich prowadzonych przed wdroŝeniem komunikacji na produkcję skrzynka pocztowa TP będzie miała adres: WLR.test@telekomunikacja.pl skrzynka pocztowa Operatora będzie miała adres: YYYYY@xxx.xx 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. Model Wymiany Danych 5.9 11
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 operatora będzie szyfrowana jego kluczem publicznym PGP. 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. Dokładny opis szyfrowania email zawarty jest w dokumencie RFC2015 (www.ietf.org/rfc/rfc2015.txt). Informacje dotyczące szyfrowania PGP zawarte są w dokumencie RFC2440 (www.ietf.org/rfc/rfc2440.txt) oraz w dokumencie RFC4880 (http://www.ietf.org/rfc/rfc4880.txt). 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. Model Wymiany Danych 5.9 12
Formaty przesyłek oraz formaty potwierdzeń (zarówno pozytywnych jak i negatywnych) są opisane w tym dokumencie. Strony ustalają, Ŝe na podstawie rejestru przedsiębiorcó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 dedykowaną skrzynkę pocztową 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] Ogólny opis struktury komunikatu ORDER-MIGRATION Jak kaŝdy komunikat XML opisywany w tym dokumencie składa się z sekcji nagłówkowej opisującej nadawcę, odbiorcę komunikatu oraz unikalny numer interakcji. W dalszej jego części znajduje się sekcja ORDER-MIGRATION opisująca ilość elementarnych zamówień w komunikacie i datę jego generacji. Kolejne rekordy ORDER-MIGRATION ELEMENT stanowią specyfikację poszczególnych zamówień składanych przez OA. Istotą tej części komunikatu jest podział na sekcję ogólną dotyczącą Abonenta, dla którego ma być świadczona usługa. Znajdują się tam dane tele-adresowe, numer telefonu bądź ID usługi szerokopasmowej. W dalszej kolejności znajdują się sekcje CEASE i ORDER. Pozwalają one odpowiednio wskazać, z jakiej usługi Abonent rezygnuje i jaką nową usługę zamawia. Zaznaczyć naleŝy w tym miejscu, iŝ Number Portability jako prawo Abonenta wydzielone zostało w osobnej sekcji, aby rozdzielić NP. od usług hurtowych. Tak sekcja CEASE jak i ORDER moŝe wystąpić maksymalnie dwa razy, raz dla przypadku usługi głosowej raz dla usługi szerokopasmowej. Podział taki pozwala na dowolne zamawianie migrowanych usług. W sekcji CEASE dla usługi głosowej znaleźć się moŝe rezygnacja z głosu w TP lub rezygnacja z WLR. Podobnie CEASE dla usług szerokopasmowych moŝe zawierać rezygnację z BSA jak i rezygnację z usługi szerokopasmowej świadczonej w TP. Dzięki takiej konstrukcji komunikatu niewymagane są dedykowane komunikaty dla rezygnacji z usług świadczonych przez TP i tym samym niebędące de-facto w zakresie migracji. Sekcja ORDER wskazuje na typ zamawianej usługi, na obecnym etapie dotyczy ona usługi LLU w wersji pełnej i współdzielonej, WLR oraz BSA/NBSA. Model Wymiany Danych 5.9 13
W związku z tym, iŝ proces NP jest objęty innymi regulacjami UKE zostanie opisany oddzielnie w dedykowanych akapitach tego dokumentu. Przykładowa postać potwierdzenia odbioru wiadomości zamówienia Migracji przesłanej od TP do Przedsiębiorcy telekomunikacyjnego będzie następująca: 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. Model Wymiany Danych 5.9 14
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 Model Wymiany Danych 5.9 15
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> 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ł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. 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) Model Wymiany Danych 5.9 16
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 z WLR na LLUP z NP o MIGRACJA_1 z WLR na LLUP (bez NP) o MIGRACJA_1 z WLR i BSA na LLUP z NP o MIGRACJA_1 z WLR i BSA na LLUP (bez NP) o MIGRACJA_1 z BSA na LLUW (POTS bez zmian) o MIGRACJA_1 z NBSA na LLUP (bez NP) o MIGRACJA_1 z NBSA na LLUW o MIGRACJA_1 zmiana RN M-NP-RN MIGRACJA_2 przejście od operatora do operatora bez zmiany usługi o MIGRACJA_2 Zmiana operatora BSA (migracja z BSA na BSA) o MIGRACJA_2 Zmiana operatora WLR (migracja z WLR na WLR) o MIGRACJA_2 Zmiana operatora NBSA (migracja z NBSA na NBSA) o MIGRACJA_2 Zmiana operatora NP (migracja z NP na NP) MIGRACJA_3 przejście zmienia się zarówno operator, jak i usługa o MIGRACJA_3 z WLR na NP o MIGRACJA_3 z WLR na LLUP z NP o MIGRACJA_3 z WLR na LLUP bez NP o MIGRACJA_3 z WLR + BSA na LLUP z NP o MIGRACJA_3 z WLR + BSA na LLUP bez NP o MIGRACJA_3 z POTS + BSA na LLUP z NP (Voice + BSA na LLUP z NP) o MIGRACJA_3 z POTS + BSA na LLUP (bez NP) (Voice + BSA na LLUP) o MIGRACJA_3 z BSA na LLUW (POTS bez zmian) o MIGRACJA_3 z NBSA na LLUP bez NP o MIGRACJA_3 z NBSA na LLUW Model Wymiany Danych 5.9 17
o o o o MIGRACJA_3 powrót z BSA do TP (BSA na BROADBAND) MIGRACJA_3 powrót z NBSA do TP (NBSA na BROADBAND) MIGRACJA_3 przejście z usługi głosowej na NP (Voice na NP) MIGRACJA_3 zwrot numeru NP C-NP Dotychczasowa realizacji procesów MPM, dla których usługa NP jest jedną ze składowych zamówienia LLUP, będzie realizowana zgodnie z procesem dla usługi LLUP. Model Wymiany Danych 5.9 18
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 Model Wymiany Danych 5.9 19
5. Zapytanie 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] Model Wymiany Danych 5.9 20
SERVICE-QUERY (Operator Biorca->BNP)<T_3_0> Komunikat został opisany w punkcie 11.1.1 SERVICE-QUERY Komunikat zapytania o aktywne usługi na danym Łączu Abonenckim. Operator -> BNP Komunikat przesyłany kanałem elektronicznym. 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> <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-id> <number>322251527</number> <service-id></service-id> <client-address> <city-name>kozia Wólka</city-name> <street-name>mickiewicza</street-name> <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> <query-agreement>1</query-agreement> <msg>dodatkowe informacje </msg> </service-query-element> </service-query> </cbnp-message> 5.1.2. Komunikat potwierdzenia przyjęcia 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 został opisany w punkcie 11.2.2 SERVICE-QUERY-ACK Komunikat potwierdzenia przyjęcia komunikatu SERVICE-QUERY. BNP -> Operator Komunikat przesyłany kanałem elektronicznym. 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> Model Wymiany Danych 5.9 21
<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 został opisany w punkcie 11.1.3 SERVICE-QUERY-RESULT Komunikat odpowiedzi na zapytanie o aktywne usługi na danym Łączu Abonenckim. BNP->Operator Komunikat przesyłany kanałem elektronicznym. 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-result> <generate-date>2008-12-22 08:00:00</generate-date> <service-query-result-element> <item>1</item> <query-id>sdfa123123</query-id> <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> </service> <service> <service-name>2</service-name> <oper>18</oper> </service> </service-query-result-element> </service-query-result> </cbnp-message> Model Wymiany Danych 5.9 22
5.2.2. Komunikat potwierdzenia przyjęcia 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 został opisany w punkcie 11.1.4 SERVICE-QUERY-RESULT-ACK Komunikat potwierdzenia przyjęcia komunikatu SERVICE-QUERY-RESULT. Operator -> BNP Komunikat przesyłany kanałem elektronicznym. 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> Model Wymiany Danych 5.9 23
6. Proces przeniesienia numeru przy zmianie dostawcy usług Number Portability (TP realizuje komunikację pomiędzy Operatorami) 6.1. Rozdział ten opisuje procesy NP realizowane w Bazie Numerów Przeniesionych przy pomocy komunikatów migracyjnych w zakresie: Odpytanie o warunki technicznej realizacji NP Realizacja NP Zwrot Numeru do Operatora Macierzystego, Zmiana Numeru Rutingowego w Sieci Operatora Biorcy, Anulowanie Operatora Biorcy/Dawcy/Macierzystego zamówienia przeniesienia numeru, Komunikaty migracji posiadają wydzieloną sekcję NP i w dalszej części tego rozdziału analizowana będzie jedynie ta sekcja z pominięciem części ORDER i CEASE chyba, Ŝe dany podrozdział będzie wymagał inaczej. Procesy NP w modelu migracji zawarte są w następujących typach migracji: Zapytanie o techniczne warunki realizacji NP WLR -> NP WLR na NP (zamówienie) WLRiBSA -> LLUPzNP - WLR z BSA na LLU Pełny z NP WLR -> LLUPzNP WLR na LLU Pełny z NP WLR -> LLUWzNP - WLR na LLU Współdzielony z NP POTSiBSA -> LLUPzNP - Usługa głos. TP z BSA na LLU Pełny z NP VOICE -> NP Usługa głos. na NP (zamówienie) - M-NP-RN - Zmiana RN - C-NP - Zwrot numeru NP. - - Listonosz pośredniczenie w komunikacji pomięzy OA (Zapytanie o techniczne warunki realizacji NP. i VOICE -> NP ) Dla wszystkich wskazanych powyŝej typów migracji zastosowanie ma proces anulowania zamówienia z uwzględnieniem opisanych dalej ograniczeń. NaleŜy zaznaczyć, iŝ przewidziana jest moŝliwość realizacji zamówienia NP nawet w przypadku, kiedy TP nie jest stroną w zamówieniu. Funkcjonalność ta dostępna jest jedynie dla przedsiębiorców telekomunikacyjnych współpracujących z TP w ramach niniejszego modelu. Procesy realizacji NP w zaleŝności od typu migracji mogą róŝnić się czasem realizacji kolejnych kroków w procesie zamówienia. Ograniczenia te wynikają z powiązania zamówienia NP z innymi produktami hurtowymi, które mają bezpośredni wpływ na czas reakcji systemu BNP. 6.2. Zapytanie o techniczne warunki realizacji NP Operator Biorca składa drogą elektroniczną za pośrednictwem systemu BNP dedykowane zamówienie zapytania o warunki techniczne oraz datę dla realizacji przeniesienia numeru do jego Model Wymiany Danych 5.9 24
sieci. Zapytanie to z punktu widzenia komunikatów XML róŝni się od właściwego zamówienia przeniesienia numeru jedynie w sekcji MODE, gdzie dla zapytania pole to przyjmuje wartość 2. W zapytaniu znajdują się: Identyfikator zapytania (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.2.1. Komunikat zapytania o warunki NP. ORDER-MIGRATION z sekcją wskazująca, Ŝe komunikat jest tylko zapytaniem (MODE = 2). 6.2.2. Komunikat potwierdzenia zapytania o warunki NP. Potwierdzenie zapytania realizowane jest przez standardowy komunikat ORDER-MIGRATION-ACK 6.3. 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). 6.3.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 = 2). Model Wymiany Danych 5.9 25
Realizacja negatywnej weryfikacji odbywa się poprzez przesłanie komunikatu ORDER- MIGRATION-STATUS (SERVICE-STAUS = 1 REJECTED) 6.3.2. Komunikat potwierdzenia dostarczenia komunikatu potwierdzenia daty lub negatywnej weryfikacji formalnej. Potwierdzenie realizowane jest przez standardowy komunikat ORDER-MIGRATION-STATUS-ACK 6.4. 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.4.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.4.2. Komunikat potwierdzenia dostarczenia odpowiedzi od Dawcy i Macierzystego Potwierdzenie realizowane jest przez standardowy komunikat ORDER-MIGRATION-TO-OPER- ACC-ACK 6.5. 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. 6.5.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.5.2. Komunikat potwierdzenia dostarczenia ORDER- MIGRATION-STATUS Potwierdzenie realizowane jest przez standardowy komunikat ORDER-MIGRATION- STATUS-ACK Model Wymiany Danych 5.9 26