Nová generace národní referenční databáze přenesených … · Web viewAuthor Jan Tolar, Richard Malina Created Date 12/03/2013 06:53:00 Title Nová generace národní referenční

Nová generace národní referenční databáze přenesených čísel v prostředí mobilních sítíSpecifikace předmětu plnění

verze: 2.12.0.6 datum: 3.12.201327.9.2013

IDENTIFIKACE DOKUMENTUjméno projektu:

RNPDB-M NGRNPDB-M NGtitul dokumentu:

Nová generace národní referenční databáze přenesených čísel v prostředí mobilních sítíSpecifikace předmětu plnění

verze: 2.12.0.6

datum: 3.12.201327.9.2013

stran: 90

autor:Jan Tolar Jan Tolar, Richard Malina <[email protected]>Richard Malina <[email protected]>

Omezující podmínky pro zveřejněníTento dokument obsahuje informace důvěrného charakteru a je určen výhradně pověřeným pracovníkům APMS a jako takový nesmí být bez předchozího souhlasu autora kopírován nebo předán třetí fyzické nebo právnické osobě.

Upozornění

2 / 90

Všechny známky a názvy produktů uvedené v tomto materiálu jsou nebo mohou být registrované obchodní značky, obchodní značky nebo ochranné známky jejich vlastníků.

3 / 90

HISTORIE DOKUMENTUVerze

Datum Autor Popis

1.3 1. 8. 2006

Martin Čížek

Finální verze dokumentu stávající RNPDB-M

2.0 4. 4. 2013

Jan Tolar, Richard Malina

Úvodní verze dokumentu nové RNPDB-M NG

2.0.1

24. 4. 2013

Jan Tolar Oprava statusů v číselníku validačních zpráv (4.1.2.2); doplnění číselníku rekonciliačních zpráv (4.1.2.4);oprava v rozvržení pracovního dne pro vracení čísel a vypuštění generování číslovacího plánu (4.1.1); odstranění sekund v názvech souborů (6);doplnění aktivity Administrátora o Generování mimořádných výstupů (3.5.4); popis korektivních akcí Administrátora rozšířen a doplněn o omezující podmínku následné portace (3.5.4)

2.0.2

30.5.2013

Jan Tolar Doplněny chybové kódy kontroly příchozích zpráv (4.1.2.1);rozdělena aktivita administrátora Správa OpID a SPID (3.5.4);administrátor může stáhnout soubor číslovacího plánu za libovolného MO (3.5.4);diagram vazeb na interní systémy (8.)

2.0.3

28.6.2013

Jan Tolar Doplněna aktivita Systému „Konsolidace portačních plánů“;ChR1: Řešení nahrání portací se SP z doby před zahájením provozu (kapitola 9.1.3);ChR2: Řešení RETURNu k SP během konsolidace;ChR3: Řešení PORTBACKu během konsolidace;ChR4: Z migrace odstraněny 3. strany a uživatelské účty.

2.0.4

7.7.2013

Jan Tolar Doplněn základní popis funkcionality;kapitola Stahování souborů (4.2 a 4.3) do souladu s rozvržením pracovního dne;doplněny názvy souborů v kap. 9.1.3.

2.0.5

22.8.2013

Jan Tolar Definice reportů (kap. 7);zpětný přenos souborů na stávající prostředí (kap 9.2.2);změna okamžiku generování fixní resynchronizace;prodloužení okna pro mimořádné portace (kap. 4.1.1);oprava rozvržení pracovního dne pro rekonciliační zprávy.

2.0.6

3.10.2013

Jan Tolar Popis přístupových práv (kap. 3.6)Příjem RETURNů již od 12:00 R-2 (kap. 4.1.1)

4 / 90

Verze

Datum Autor Popis

Umožnění zpracování opožděných zpráv validace přijatých objednávek podle PublishDateTime.

2.1 3.12.2013

Jan Tolar Zapracování situace opravy portačního plánu po publikaciZapracování změn spojených s dotazovacím rozhraním

5 / 90

OBSAH1. Základní vymezení ............................................................6

1.1 Popis funkcionality ...................................................................61.2 Časový harmonogram ..............................................................71.3 Požadavky na součinnost .........................................................7

2. Použité zkratky a termíny .................................................83. Detailní technické vymezení .............................................9

3.1 Poskytovatel služeb ..................................................................93.1.1.1Postup zavedení nového poskytovatele služeb .........................93.1.1.2Postup zrušení poskytovatele služeb ........................................93.1.1.3Změna údajů poskytovatele služeb ..........................................93.1.1.4Viditelnost operací s SPID ......................................................10

3.2 Identifikátory .........................................................................113.2.1 OHS ID ...............................................................................113.2.2 OpID ...................................................................................113.2.3 IMSI prefix .........................................................................113.2.4 SPID ...................................................................................12

3.3 Role v systému .......................................................................123.4 Rozhraní systému ...................................................................133.5 Případy užití ...........................................................................14

3.5.1 Uživatel v roli MO ..............................................................143.5.2 Uživatel v roli SP ................................................................173.5.3 Uživatel v roli FO / Úřad ....................................................173.5.4 Uživatel v roli Administrátor ..............................................183.5.5 Systém (automatické aktivity) ...........................................23

3.6 Přístupová práva ....................................................................263.6.1 Práva k rozhraním ..............................................................263.6.2 Práva k funkcím .................................................................27

3.7 Číslovací plán .........................................................................293.7.1 Struktura ............................................................................293.7.2 Synchronizace s RDČ .........................................................30

4. Komunikační standardy OHS .........................................314.1 Publikace a zpracování portačních plánů ..............................31

4.1.1 Rozvržení pracovního dne ..................................................334.1.2 Validace a kontroly při zpracování ....................................34

4.1.2.1Obecné kontroly příchozích zpráv .........................................344.1.2.2Validace portačních objednávek ............................................354.1.2.3Validace portačních objednávek zadávaná v GUI ..................354.1.2.4Rekonciliace ...........................................................................36

4.2 Stažení konsolidovaného portačního plánu a mobilní resynchronizace ............................................................................364.3 Stažení dalších souborů .........................................................374.4 Zabezpečení komunikace .......................................................384.5 Rozhraní WebService .............................................................38

5. Formáty zpráv rozhraní OHS ..........................................395.1 XML zprávy transportní vrstvy ..............................................39

5.1.1 MNPMessage .....................................................................395.1.2 MNPMessageReply ............................................................39

5.2 Přijímané XML zprávy aplikační vrstvy .................................415.2.1 PortingOrderPublishCRDB ................................................41

6 / 90

5.2.2 ReturnNumberPublishCRDB .............................................425.3 Odesílané XML zprávy aplikační vrstvy .................................43

5.3.1 CRDBValidationResult .......................................................435.3.2 CRDBReconciliationResult .................................................435.3.3 ExtractFileInformation ......................................................44

6. Generované soubory .......................................................456.1 Konsolidovaný plán portací ....................................................456.2 Mobilní resynchronizace ........................................................466.3 Tabulka přiřazení SPID k OpID ..............................................476.4 Mobilní číslovací plány ...........................................................476.5 Fixní resynchronizace ............................................................48

7. Reporty a statistiky .........................................................497.1 Report počtu zpráv ................................................................497.2 Report počtu portací ..............................................................507.3 Report čerpání kvót dotazovacího rozhraní ...........................507.4 Report výpisu portací .............................................................517.5 Report detailního výpisu portací ............................................517.6 Report využití čísel ................................................................537.7 Reporty vytížení částí systému ..............................................54

8. Vazby na další systémy ...................................................558.1 Stávající RNPDB-M ................................................................55

8.1.1 Nutné úpravy stávající RNPDB-M ......................................558.2 RNPDB-F (včetně RDČ) .........................................................56

8.2.1 Nutné úpravy RDČ ...........................................................568.3 Geo backup ............................................................................568.4 Archivace ...............................................................................56

9. Inicializace, migrace dat a souběžný provoz ..................579.1 Úvodní naplnění databáze .....................................................57

9.1.1 Migrace dat z původní RNPDB-M ......................................579.1.2 Inicializace číslovacího plánu ............................................579.1.3 Nahrání portací se SP z doby před zahájením provozu .....57

9.2 Souběžný provoz ....................................................................599.2.1 Přenos dat ze stávajícího na nové prostředí ......................599.2.2 Zpětný přenos dat z nového na stávající prostředí ............599.2.3 Režim stávajícího systému RNPDB-M ................................599.2.4 Náběh zatížení nového systému .........................................60

9.3 Krizový scénář produkčního provozu .....................................6010. Ostatní vlastnosti systému ..............................................61

10.1 Garantovaná dostupnost .......................................................6110.2 Propustnost systému .............................................................6110.3 Logická architektura .............................................................6210.4 HW a SW prostředí ...............................................................6310.5 Požadavky pro přístup k Web GUI ........................................64

11. Otevřené otázky, předpoklady ........................................6512. Reference ........................................................................651. Základní vymezení ............................................................6

1.1 Popis funkcionality ...................................................................61.2 Časový harmonogram ..............................................................71.3 Požadavky na součinnost .........................................................7

2. Použité zkratky a termíny .................................................8

7 / 90

3. Detailní technické vymezení .............................................93.1 Poskytovatel služeb ..................................................................9

3.1.1.1Postup zavedení nového poskytovatele služeb .........................93.1.1.2Postup zrušení poskytovatele služeb ........................................93.1.1.3Změna údajů poskytovatele služeb ..........................................93.1.1.4Brand reseller ..........................................................................93.1.1.5Viditelnost operací s SPID ......................................................10

3.2 Identifikátory .........................................................................113.2.1 OHS ID ...............................................................................113.2.2 OpID ...................................................................................113.2.3 IMSI prefix .........................................................................113.2.4 SPID ...................................................................................12

3.3 Role v systému .......................................................................123.4 Rozhraní systému ...................................................................123.5 Případy užití ...........................................................................13

3.5.1 Uživatel v roli MO ..............................................................133.5.2 Uživatel v roli SP ................................................................163.5.3 Uživatel v roli 3. strana ......................................................163.5.4 Uživatel v roli Administrátor ..............................................173.5.5 Systém (automatické aktivity) ...........................................22

3.6 Přístupová práva ....................................................................253.7 Číslovací plán .........................................................................27

3.7.1 Struktura ............................................................................273.7.2 Synchronizace s RDČ .........................................................28

4. Komunikační standardy automatických rozhraní ..........294.1 Publikace a zpracování portačních plánů ..............................29

4.1.1 Rozvržení pracovního dne ..................................................314.1.2 Validace a kontroly při zpracování ....................................32

4.1.2.1Obecné kontroly příchozích zpráv .........................................324.1.2.2Validace portačních objednávek ............................................334.1.2.3Validace portačních objednávek zadávaná v GUI ..................334.1.2.4Rekonciliace ...........................................................................34

4.2 Stažení konsolidovaného portačního plánu a mobilní resynchronizace ............................................................................344.3 Stažení dalších souborů .........................................................354.4 Zabezpečení komunikace .......................................................364.5 Rozhraní WebService .............................................................36

5. Formáty zpráv rozhraní ..................................................375.1 XML zprávy transportní vrstvy ..............................................37

5.1.1 MNPMessage .....................................................................375.1.2 MNPMessageReply ............................................................38

5.2 Přijímané XML zprávy aplikační vrstvy .................................395.2.1 PortingOrderPublishCRDB ................................................395.2.2 ReturnNumberPublishCRDB .............................................40

5.3 Odesílané XML zprávy aplikační vrstvy .................................415.3.1 CRDBValidationResult .......................................................415.3.2 CRDBReconciliationResult .................................................415.3.3 ExtractFileInformation ......................................................42

6. Generované soubory .......................................................436.1 Konsolidovaný plán portací ....................................................436.2 Mobilní resynchronizace ........................................................44

8 / 90

6.3 Tabulka přiřazení SPID k OpID ..............................................456.4 Mobilní číslovací plány ...........................................................456.5 Fixní resynchronizace ............................................................46

7. Reporty a statistiky .........................................................477.1 Report počtu zpráv ................................................................477.2 Report počtu portací ..............................................................487.3 Report výpisu portací .............................................................487.4 Report detailního výpisu portací ............................................497.5 Report využití čísel ................................................................507.6 Reporty vytížení částí systému ..............................................51

8. Vazby na další systémy ...................................................528.1 Stávající RNPDB-M ................................................................52

8.1.1 Nutné úpravy stávající RNPDB-M ......................................528.2 RNPDB-F (včetně RDČ) .........................................................53

8.2.1 Nutné úpravy RDČ .............................................................538.3 Geo backup ............................................................................538.4 Archivace ...............................................................................54

9. Inicializace, migrace dat a souběžný provoz ..................559.1 Úvodní naplnění databáze .....................................................55

9.1.1 Migrace dat z původní RNPDB-M ......................................559.1.2 Inicializace číslovacího plánu ............................................559.1.3 Nahrání portací se SP z doby před zahájením provozu .....55

9.2 Souběžný provoz ....................................................................579.2.1 Přenos dat ze stávajícího na nové prostředí ......................579.2.2 Zpětný přenos dat z nového na stávající prostředí ............579.2.3 Režim stávajícího systému RNPDB-M ................................579.2.4 Náběh zatížení nového systému .........................................58

9.3 Krizový scénář produkčního provozu .....................................5810. Ostatní vlastnosti systému ..............................................59

10.1 Garantovaná dostupnost .......................................................5910.2 Propustnost systému .............................................................5910.3 Logická architektura .............................................................6010.4 HW a SW prostředí ...............................................................6110.5 Požadavky pro přístup k Web GUI ........................................62

11. Otevřené otázky, předpoklady ........................................6312. Reference ........................................................................63

9 / 90

1. Základní vymezení1.1 Popis funkcionalityHlavní cílem systému RNPDB-M je plnit úlohu národní referenční databáze přenesených čísel v prostředí mobilních sítích. Mobilní operátoři přispívají do systému informacemi o plánovaných portacích, systém tyto informace zpracovává a výstupy dává k dispozici ostatním subjektům na telekomunikačním trhu, které na základě odpovídající smlouvy s provozovatelem řešení mohou k těmto výstupům přistupovat a dále je zpracovávat tak, aby bylo zajištěno správné směrování v prostředí mobilních sítí.RNPDB-M NG bude náhradou stávajícího systému, který již neodpovídá aktuálním požadavkům plynoucí z Opatření Obecné Povahy č. OOP/10/10.2012-12 a také po technické stránce zastaral.Základní funkční vymezení systému RNPDB-M NG je následující:

mobilní operátor předá systému plán portací (seznam portovaných čísel spolu s dalšími identifikátory) jeden pracovní den předem pomocí manuálního nebo automatizovaného rozhraní,

systém ověří a spáruje přijaté plány portací a zapracuje je do referenční databáze přenesených čísel,

systém uchovává všechny přijaté plány portací a referenční databázi přenesených čísel včetně historie,

mobilní operátoři, případně i další externí pověřené subjekty mohou pomocí manuálního nebo automatizovaného rozhraní stahovat obraz referenční databáze přenesených mobilních čísel (aktuální platný nebo platný k zadanému datu) a konsolidované plány portací (k zadanému datu),

systém přebírá číslovací plán mobilních účastnických čísel a čísel služeb přidělených mobilním operátorům z RDČ (část systému RNPDB-F),

mobilní operátor může přidělit podrozsahy v číslovacím plánu svým poskytovatelům služeb,

systém zajišťuje, že neveřejné informace o poskytovatelích služeb (portace, přidělení podrozsahů) nejsou viditelné ostatním mobilním operátorům ani třetím stranám.

správce/administrátor systému, tedy CNPAC s.r.o., administruje pomocí manuálního rozhraní uživatele systému a jejich přístupová práva,

správce/administrátor je oprávněn provádět pomocí manuálního rozhraní mimořádné opravné zásahy do referenční databáze přenesených mobilních čísel (např. v případě nekonzistence databáze z důvodů chybně zadaných portačních plánů apod.) a tyto úpravy jsou systémem automaticky archivovány a uchovány,

vzhledem k tomu, že se jedná o národní referenční databázi, je použita technologie zajišťující odpovídající míru dostupnosti služby.

10 / 90

1.2 Časový harmonogramNásledující tabulka je časovým harmonogramem řešení. Shrnuje zároveň jednotlivé milníky, jejichž překročení ze strany Objednatelů (dále též „zadavatel“ nebo „MO“) může mít zásadní vliv na včasnou dodávku řešení a definuje tak požadavky na součinnost mobilních operátorů především při technické specifikaci vlastností řešení.

Milník odpovědnost

termín

Akceptace vymezení funkcionality systému operátory

MO 4. 2. 2013

Dodání požadavků externích rozhraní systému (specifikace/požadavky formátu)

MO 8. 2. 2013

Vznesení požadavků a připomínek k zadání NextSoft 8. 2. 2013

Vyjasnění zaslaných připomínek MO 13. 2. 2013

Předání funkční specifikace včetně specifikace externích rozhraní systému ke schválení

NextSoft 1. 3. 2013

Akceptace funkční specifikace včetně specifikace rozhraní

MO 8. 3. 2013

Dodání certifikátů pro testovací servery NextSoft/MO

1. 5. 2013

Dodání certifikátů pro produkční servery NextSoft/MO

1. 6. 2013

Připravenost systémů MO pro integrační testování

MO 1. 6. 2013

Připravenost aplikace pro integrační testování NextSoft 1. 6. 2013

Předání systému k funkčnímu testování NextSoft 1. 7. 2013

Migrace dat ze stávající RNPDB-M do RNPDB-M NG

NextSoft 31. 8. 2013

Spuštění systému RNPDB-M NG v souběžném provozu

NextSoft 1. 9. 2013

Ukončení souběžného provozu zastavení stávající RNPDB-M

NextSoft/MO

2. 11. 2013

Realizace projektu RNPDB-M NG bude zahájena ihned po obdržení objednávek zadavatele.

1.3 Požadavky na součinnostV rámci vytvoření specifikačního dokumentu, který bude akceptován všemi zúčastněnými stranami, požadujeme součinnost nezbytnou pro dosažení vzájemného konsenzu a dedikování zodpovědné osoby, která se bude zúčastňovat našich schůzek. Tyto schůzky se budou uskutečňovat pravidelně nebo dle potřeby a budou sloužit k vyjasňování problémů všech stran.Zhotovitel (dále též “dodavatel“ nebo „NextSoft“) se zavazuje, že v maximální možné míře při návrhu použije formáty a principy definované dokumentem [TMMNPspec] a zohlední požadavky, na kterých se zástupci mobilních operátorů shodnou.

11 / 90

Dodavatel se zavazuje nabídnout technickou podporu řešení a podporu Hardware společnosti CNPAC s.r.o., která bude v budoucnu pověřena správou a provozem Informačního systému.Zadavatel zajistí dodavateli v potřebném rozsahu přístup do místa instalace resp. provozu řešení. Zadavatel v místě instalace zajistí podmínky vyhovující pro provoz instalovaného řešení. Dodavatel požaduje součinnost zástupců MO při realizaci projektu RNPDB-M v termínech tak, jak je definováno časovým harmonogramem. Nedostatek součinnosti zásadně ohrožuje termín nasazení systému do produkčního provozu ke dni 1. 9. 2013.

12 / 90

2. Použité zkratky a termínyZkratka PopisCNO Curent Network Operator – Současný provozovatel čísla.

MO, kde je číslo v současnosti umístěno (portováno).CRDB Centrální referenční databáze. Synonymum pro RNPDB-

M.CSP Current Service Provider – Současný poskytovatel

služeb. SP, kde je číslo v současnosti umístěno (portováno).

CTID Contract Termination ID. Identifikátor generovaný DNO při zrušení smlouvy.

ČTÚ Český telekomunikační úřad

DNO Donor Network Operator – Opouštěný operátor. MO, od kterého je číslo portováno.

DSP Donor Service Provider – Opouštěný poskytovatel služeb. SP, od kterého je číslo portováno.

EM příznak Externally Managed – Indikátor u rozsahu v RDČ, že je na rozsah navázaná informace vně RDČ.

MCC/MNC Mobile Country Code / Mobile Network Code. Identifikace mobilní sítě, 5ciferný IMSI prefix. MCC má hodnotu 203 pro ČR, MNC.

MNP Mobile Number Portability – Přenositelnost čísel v mobilních sítích.

MO Mobile operator, mobilní operátor. Podnikatel zajišťující veřejnou mobilní komunikační síť.

OMO Other Mobile Operator. Operátor, který se neúčastní portace.

OpID Identifikátor operátora dle ČTÚ. Identifikátor má podobu 3ciferného čísla.

PAC Porting authorization Certicate. Unikátní identifikátor portační objednávky. Má podobu 11ciferného čísla.

RDČ Referenční databáze přidělení čísel a rozsahů

RH (NH) Range Holder, Number Holder – Držitel číselného rozsahu, čísla. MO, kterému je dle ČTU přiřazen rozsah čísel (dle RDČ).

RHSP Range Holder Service Provider – Poskytovatel služeb, který má přiřazen příslušný rozsah/podrozsah v RNPDB-M NG.

RNO Recipient Network Operator – Přejímající operátor. MO, ke kterému je číslo portováno.

RNPDB-M Referenční databáze přenesených čísel v mobilních sítích (stávající)

RNPDB-M NG

Referenční databáze přenesených čísel v mobilních sítích (nová generace)

RNPDB-F Referenční databáze přenesených čísel v pevných sítích

13 / 90

Zkratka PopisRSP Recipient Service Provider – Přejímající poskytovatel

služeb. SP, ke kterému je číslo portováno.SP Service Provider, poskytovatel služeb. Podnikatel

poskytující veřejně dostupnou službu elektronických komunikací. Mobilní operátor je současně i poskytovatelem služeb.

SPID Identifikátor poskytovatele služeb. Má podobu tříciferného čísla.

14 / 90

3. Detailní technické vymezení3.1 Poskytovatel služebNová verze systému RNPDB-M NG zavádí nový pojem: poskytovatel služeb (service provider) pro subjekty, které se účastní portačního procesu, ale nedisponují mobilní telefonní sítí. Tyto subjekty provádí veškeré operace se systémem RNPDB-M NG (a RNPDB-F) prostřednictvím mobilního operátora. V systému RNPDB-M jsou evidovány pod určeným SPID a jsou vždy přiřazeni k určitému mobilnímu operátorovi.Operátoři se shodli na tom, že dDo centrální databáze RNPDB-M se budou uvádět jen portace, kde se mění poskytovatel služby. Tzn. portace mezi tzv. brand resellery v rámci jednoho poskytovatele služby se do RNPDB-M nebudou zapisovat, což je v souladu [OOP10].

[3.1.1.1] Postup zavedení nového poskytovatele služebPoskytovatel služby, který disponuje rozsahem přiděleným od ČTÚ, požádá mobilního operátora o zavedení tohoto rozsahu do jeho mobilní sítě.Oslovený mobilní operátor:

v RNPDB-F provede zápis rozsahu do RDČ a jeho přiřazení ke svému OpID,

požádá administrátora RNPDB-M NG o přidělení nového SPID pro poskytovatele služeb a jeho přiřazení k OpID mobilního operátora v systému RNPDB-M NG,

v RNPDB-M NG nastaví viditelnost SPID ostatním mobilním operátorům,

vyčká na synchronizaci dat z RDČ do RNPDB-M NG, pokud to bude třeba,

v RNPDB-M NG přidělí rozsah k SPID.Pokud mobilní operátor přidělí v RDČ rozsah ke svému OpID, ale následně nepřidělí rozsah k SPID v RNPDB-M NG, nebude moci provádět portace čísel v tomto rozsahu od poskytovatele služeb. Rozsah zůstane pro systém RNPDB-M NG v držení mobilního operátora.

3.1.1.1[3.1.1.2] Postup zrušení poskytovatele služebPoskytovatele služeb nelze zcela zrušit, jakmile mu byl předělen rozsah čísel. Poskytovatel služeb, který ukončil svou činnost u určitého mobilního operátora, požádá tohoto mobilního operátora o zrušení přidělení rozsahu.Pokud existují rozsahy přidělené rušenému poskytovateli služeb a lze zajistit vrácení všech portovaných čísel, tak oOslovený mobilní operátor:

15 / 90

v RNPDB-M NG zajistí vrácení portovaných čísel v rozsazích přidělených poskytovateli služeb zpět vlastníkovi rozsahu (poskytovateli služeb),

v RNPDB-M NG zruší přiřazení všech rozsahů poskytovateli služeb, v RNPDB-F provede deaktivaci všech rozsahů, přidělených

poskytovateli služeb.Pokud existují rozsahy přidělené rušenému poskytovateli služeb, ale portovaná čísla v těchto rozsazích mají zůstat portovaná, nelze rozsahy deaktivovat.

3.1.1.2[3.1.1.3] Změna údajů poskytovatele služebZměna údajů o poskytovateli služeb je možná, nikoli však změna SPID či přiřazení SPID k OpID (od okamžiku přidělení rozsahu k SPID). Poskytovatel služeb, který požaduje změnu údajů, požádá svého mobilního operátora o provedení této změny v systému RNPDB-M NG.Oslovený mobilní operátor:

v RNPDB-M NG provede změnu údajů.Přidání dodatečných rozsahů, či odebírání rozsahů poskytovateli služeb bude postupováno obdobně jako dle kapitoly 3.1.1.1, resp. 3.1.1.2.

[3.1.1.4] Brand resellerOperátoři se shodli na tom, že do centrální databáze RNPDB-M se budou uvádět jen portace, kde se mění poskytovatel služby. Tzn. portace mezi tzv. brand resellery v rámci jednoho poskytovatele služby se do RNPDB-M nebudou zapisovat, což je v souladu [OOP10].

3.1.1.3[3.1.1.5] Viditelnost operací s SPIDU portační objednávky, která se týká určitého poskytovatele služeb, jsou SPID opouštěného a přejímajícího poskytovatele služeb implicitně viditelné pouze operátorovi, k jehož OpID je poskytovatel služeb přiřazen, pro ostatní subjekty je SPID nahrazeno přiřazeným OpID. Výjimku tvoří pouze poskytovatelé služeb, kteří jsou zároveň mobilními operátory (SPID = OpID), pro které skrývání neplatí a portační objednávky, které se jich týkají, jsou vždy viditelné v nezměněné podobě ostatním subjektům.Mobilní operátor, v jehož síti poskytovatel pracuje, může povolit viditelnost SPID i dalším vyjmenovaným operátorům v tzv. matici viditelnosti SPID.

16 / 90

3.2 IdentifikátoryNásledující kapitola popisuje význačné identifikátory použité v portačním procesu.

3.2.1 OHS IDIdentifikátor subjektu, který se aktivně účastní procesu přenášení mobilních čísel v roli MO. Má formát 2ciferného čísla a je přidělován administrátorem systému v rozsahu 11-99 (01 vyhrazeno pro RNPDB-M). Používá se jako prefix dalších identifikátorů generovaných účastníky portačních procesů (např. PAC, ID zpráv), k zajištění unikátnosti identifikátorů v distribuovaném systému.V současné době jsou vedeny tyto identifikátory:OHS ID

Subjekt (mobilní operátor)

01 CRDB (přiděleno CNPAC s. r. o.)

11 T-Mobile Czech Republic a.s.

12 Telefónica Czech Republic, a.s.

13 Vodafone Czech Republic a.s.

14 Air Telecom a.s.

3.2.2 OpIDOperator ID (OpID) je číselný identifikátor mobilního i fixního operátora, přidělovaný ČTÚ. Má tvar 3ciferného čísla.V současné době mají mobilní operátoři evidovány tyto identifikátory:OpID

Subjekt / mobilní operátor

205 T-Mobile Czech Republic a.s.

213 Vodafone Czech Republic a.s.

232 Telefónica Czech Republic, a.s.

262 Air Telecom a.s.

V budoucnu je možné, že jednomu mobilnímu operátorovi bude přiřazen více než jeden OpID. Více operátorů ale nemůže sdílet jeden OpID.

3.2.3 IMSI prefixŘetězec kódů MCC a MNC. MCC má pro ČR hodnotu 230, celý řetězec má pro mobilní operátory hodnoty uvedené v této tabulce:IMSIprefix


230 01 T-Mobile Czech Republic a.s.

230 02 Telefónica Czech Republic, a.s.

230 03 Vodafone Czech Republic a.s.

17 / 90

IMSIprefix


230 04 Air Telecom a.s.

Pokud má operátor přiřazeno více IMSI prefixů, platí, že k jednomu OpID je přiřazen právě jeden IMSI prefix.

3.2.4 SPIDIdentifikátor poskytovatele služeb má podobu 3ciferného čísla a je přidělovaný mobilními operátory poskytovatelům v koordinaci s administrátorem systému. Přičemž platí:

SPID přiděluje mobilní operátor v koordinaci s Administrátorem poskytovatelům služeb operujícím v jeho síti,

SPID je přidělováno postupně v rozmezí od 100 do 199, mimo tísňových čísel 112, 150, 155, 156, 158 a čísel přidělených stávajícím operátorům,

SPID patří k jedinému subjektu v roli poskytovatele služeb nebo mobilního operátora,

SPID poskytovatele služeb, který je zároveň mobilním operátorem je rovno OpID tohoto operátora, takové SPID leží mimo rozmezí uvedené výše,

poskytovatel služeb může mít přiděleno více SPID, SPID je přiřazeno k OpID mobilního operátora, pod kterým

poskytovatel poskytuje své služby, přičemž určitý SPID je přiřazen k právě jednomu OpID,

přiřazení SPID-OpID nelze po zavedení měnit, v případě potřeby je nutné přidělit novou hodnotu SPID.

3.3 Role v systémuSystém rozeznává následující role:Role PopisMO Mobilní operátor. Subjekt, který se aktivně účastní

portačního procesu jako opouštěný operátor (DNO), přejímající operátor (RNO), aktuální operátor (CNO), vlastník rozsahu (RH) či jiný mobilní operátor (OMO). Je identifikován pomocí OHS ID a jednoho či více OpID.

(SP) Poskytovatel služeb. Právní subjekt, který se účastní portačního procesu prostřednictvím jednoho či více mobilních operátorů jako opouštěný poskytovatel, přejímající poskytovatel, aktuální poskytovatel, či vlastník rozsahu. Je identifikován pomocí jednoho či více SPID.Poskytovatel služeb nemá v systému žádná oprávnění, veškeré operace provádí prostřednictvím mobilního operátora, v jehož síti poskytuje služby, proto ani v systému není pro něj zavedena role.

FO / úřad Fixní operátor nebo Úřad (dle OOP10). Subjekt, který využívá informace o portovaných číslech a má přístup k seznamu portovaných čísel a dalším výstupním souborům.

18 / 90

Role Popis3. strana Třetí strana. Subjekt, který nemá nárok na přístup

k výstupním souborům, ale využívá informace o portovaných číslech prostřednictvím dotazovacího rozhraní.Třetí strana. Subjekt, který využívá informace o portovaných číslech

Administrátor

Administrátor systému a provozovatel RNPDB-M NG. Provádí administraci uživatelů a subjektů, provádí mimořádné korektivní zásahy a má k dispozici veškeré obchodní, provozní i technické informace udržované v systému.

19 / 90

3.4 Rozhraní systémuAktéři provádějí své aktivity vždy prostřednictvím těchto rozhraní:Označení PopisWeb GUI Webové grafické uživatelské rozhraní přístupné pomocí

internetového prohlížeče uživatelům a administrátorovi systému.

Download UI

HTTPS rozhraní, které vystavuje výstupní soubory systému ke stažení uživatelem nebo automatickým systémem.

Web Service

Automatická webová služba na bázi SOAP přes HTTPS, používaná v komunikaci s automatickými systémy mobilních operátorů (OHS).

QI Web Service

Automatická webová služba na bázi SOAP přes HTTPS, používaná v komunikaci s automatickými systémy 3. stran. (specifikace je součástí [QIspec]).

Automat Automatická či plánovaná úloha prováděná systémem, není de facto rozhraní.

20 / 90

3.5 Případy užitíPovolené aktivity uživatelů výše uvedených rolí a systému jsou shrnuty v následujících kapitolách a mohou být dále omezovány přístupovými právy.

3.5.1 Uživatel v roli MOTato kapitola popisuje možné aktivity uživatele, který pracuje pod subjektem v roli MO (mobilní operátor).

uc Aktiv ity MO

MO

Stažení v ýstupních souborů

Stažení konsolidov aného plánu portací pro MO

Stažení mobilní resynchronizace pro MO

Stažení fixní resynchronizace

Reporty a statistiky

Publikace portační objednáv ky

Správ a číslovacího plánu dle SPID

Stažení číslov acího plánu dle OpID

Stažení číslov acího plánu dle SPID pro MO

Zobrazení historie portace čísla

Informace o zpracov ání portační

objednáv ky

Prohlížení aplikačních zpráv

Prohlížení tabulky přiřazení SPID k

OpID

Stažení tabulky přiřazení SPID a OpID

Nastav ování v iditelnosti SPID

ostatním MO

«include»

«include»

«include»«include»

«include»

«include»

Obrázek 1: Aktivity uživatele v roli MO

21 / 90

Aktivita Popis Rozhraní (priorita)

Publikace portační objednávky

MO publikuje objednávku na portaci mobilních čísel (portační plán) k jinému operátorovi, popřípadě jejich vrácení vlastníkovi rozsahu. Portační plány jsou publikovány vždy jednotlivě, dle čísla objednávky. Každý portační plán musí být vždy publikován jak opouštěným tak i přejímajícím operátorem. Systém automaticky zajistí kontrolu (validaci), porovnání (rekonsilaci) a konsolidaci portačních plánů.

Web Service (1)Web GUI (32)

Informace o zpracování portační objednávky

Získání informací o výsledku zpracování publikovaných portačních objednávek. Tato aktivita je k dispozici pro kontrolní účely při dohledávání chyb ve zpracování nebo jejich chybné publikaci. Mobilní operátor může na základě zadání čísla objednávky získat detailní informace o zpracování objednávky, ale pouze v případě, že byl účastníkem portace, definované touto objednávkou.

Web GUI (3)

Stažení výstupních souborů

Rozhraní pro stažení aktuálních i historických verzí souborů:

konsolidovaný plán portací pro MO, mobilní resynchronizace pro MO, fixní resynchronizace, tabulka přiřazení SPID a OpID, číslovací plán dle OpID, číslovací plán dle SPID.

Web GUI (3)

Stažení konsolidovného plánu portací pro MO

Získání souboru konsolidovaného plánu portací k určitému datu určeného pro konkrétního mobilního operátora (tj. obsahující SPID viditelná tomuto operátorovi). Viz kapitola 6.1.

Download UI (1)Web GUI (3)


Získání mobilního resynchronizačního souboru (tj. informace o portovaných číslech v mobilních sítích) k určitému datu určeného pro konkrétního mobilního operátora (tj. obsahující SPID viditelná tomuto operátorovi). Viz kapitola 6.2



Získání fixního resynchronizačního souboru k určitému datu. Tedy informace o portovaných číslech v pevných sítích. Resynchronizační data jsou jednou denně přebírána ze systému RNPDB-F NG a jsou převedena do stejného formátu jako data pro mobilní resynchronizaci. Viz kapitola 6.5.


22 / 90



Získání souboru obsahujícího obraz tabulky přiřazující SPID poskytovatelů služeb k OpID operátorů. Viz kapitola 6.3

Web GUI (3)

Stažení číslovacího plánu dle OpID

Získání všeobecného číslovacího plánu mobilních čísel, který obsahuje pouze identifikaci OpID. Viz kapitola 6.4

Web GUI (3)

Stažení číslovacího plánu dle SPID pro MO

Získání číslovacího plánu obsahujícího identifikaci poskytovatelů služeb (SPID) pro konkrétní MO. Jedná se o seznam výjimek, kdy rozsah je provozován jiným poskytovatelem. Viz kapitola 6.4

Web GUI (3)

Prohlížení tabulky přiřazení SPID k OpID

Zobrazení tabulky všech poskytovatelů služeb, jejich SPID a přiřazení k OpID mobilních operátorů.

Web GUI (3)

Nastavování viditelnosti SPID ostatním MO

Mobilní operátor může rozšířit viditelnosti SPID tak, že ve výstupních souborech, reportech a zasílaných zprávách pro určitého jiného operátora nebude dané SPID nahrazováno OpID a tím umožní vybraným ostatním mobilním operátorům sledovat operace, které se dotýkají poskytovatele služeb s daným SPID.

Web GUI (3)

Správa číslovacího plánu SPID

Umožní mobilnímu operátorovi definovat číslovací plán poskytovatele služby pro rozsahy/podrozsahy, které jsou zavedeny v rámci číslovacího plánu na OpID daného MO. Tento plán bude mít charakter výjimek, tzn., že bude zahrnovat pouze ty rozsahy/podrozsahy, které nejsou provozovány daným OpID, ale jiným SPID.Dále platí, že: operátor může přiřazovat k rozsahům

jen taková SPID, která jsou přiřazena k některému z jím vlastněných OpID,

SPID je možné přiřadit pouze k rozsahu, který patří stejnému OpID jako SPID,

rozsahy v číslovacím plánu SPID se nesmí překrývat,

v případě, že v rozsahu existuje platná portace, nebude systém povolovat vytvoření rozsahu, změnové operace s tímto rozsahem a nedovolí ani jeho zrušení.

Web GUI (3)

23 / 90



Rozhraní pro vyhledání a zobrazení všech zveřejněných portačních objednávek, které se týkají konkrétního MSISDN. V zobrazení se uplatní práva viditelnosti konkrétních SPID pro jednotlivé MO.

Web GUI (3)


Prohlížení zpráv zaslaných do systému mobilními operátory nebo systémem mobilním operátorům včetně informace o stavu jejich zpracování. Uživatel zadá přímo identifikátor zprávy nebo vybere zprávu ze seznamu na základě filtrovacích kritérií (datum a typ zprávy, popř., typ vloženého aplikačního objektu). MO má právo vidět pouze zprávy, které byly zaslány jemu nebo jím samým.

Web GUI (3)


Poskytuje on-line a offline generované reporty uvedené kapitole 6.5. Ty jsou generovány na základě vstupních kritérií s možností uložení výstupu ve formátu CSV, u dlouhotrvajících reportů s možností následného stažení offline.Pro generování offline reportů je vyžadováno zvláštní oprávnění. Offline report daného typu a pro určitého operátora je možné spustit současně pouze jednou. Ostatní uživatelé téhož operátora musí vyčkat jeho dokončení. Poznámka: V těchto výstupních informacích se uplatňují práva viditelnosti konkrétních SPID pro jednotlivé MO.

Web GUI (3)

3.5.2 Uživatel v roli SPRole poskytovatele služeb neumožní definovat žádné uživatele, kteří by mohli se systémem přímo nakládat. Namísto toho poskytovatel služeb, který není mobilním operátorem, provádí veškeré potřebné úkony prostřednictvím mobilního operátora, v jehož síti poskytuje své služby. Popis těchto úkonů nespadá do tohoto dokumentu.

[3.5.3] Uživatel v roli 3. stranaFO / ÚřadTato kapitola popisuje možné aktivity uživatele, který pracuje pod subjektem v roli třetí stranyfixního operátora (resp. Úřadu).

24 / 90

uc Aktiv ity 3. strany

3. Strana



Stažení mobilní resynchronizace pro

3. strany

Stažení konsolidov aného

plánu portací pro 3. strany


«include»

«include»

«include»

uc Aktiv ity FO / Úřadu

FO / Úřad




FO / Úřad

Stažení konsolidov aného plánu

portací pro FO / Úřad


«include»

«include»

«include»

Obrázek 2: Aktivity uživatele v roli FO / Úřad3. strany




konsolidovaný plán portací pro FO / Úřad3. strany,

mobilní resynchronizace pro FO / Úřad3. strany,

mobilní číslovací plán dle OpID.

Web GUI (3)

Stažení konsolidovného plánu portací pro FO / Úřad3. strany

Získání souboru konsolidovaného plánu portací k určitému datu určeného pro FO / Úřad3. strany (tj. neobsahující SPID). Viz kapitola 6.1.


25 / 90


Stažení mobilní resynchronizace pro FO / Úřad3. strany

Získání mobilního resynchronizačního souboru (tj. informace o portovaných číslech v mobilních sítích) k určitému datu určeného pro FO / Úřad3. strany (tj. neobsahující SPID). Viz kapitola 6.2.



Získání všeobecného číslovacího plánu mobilních čísel, který obsahuje pouze identifikaci OpID. Viz kapitola 6.4

Web GUI (3)


Rozhraní pro vyhledání a zobrazení všech zveřejněných portačních objednávek, které se týkají konkrétního MSISDN.

Web GUI (3)

3.5.3[3.5.4] Uživatel v roli AdministrátorTato kapitola popisuje aktivity vykonávané Administrátorem systému.

26 / 90

uc Aktiv ity Administrátora

Administrátor




plánu portací pro MO


MO

Prov ádění korektiv ních akcí



Archiv ace dat

Stornov ání portace

Oprav a portace


objednáv ky

Administrace

Administrace subjektů

Administrace uživ atelů

Administrace OpID a SPID




Správ a číslov acího plánu dle SPID

Administrace přístupov ých

práv


portací pro 3. strany


3. strany

Stažení tabulky přiřazení SPID a

OpID

Nastav ov ání v iditelnosti SPID

ostatním MO

Generov ání mimořádných

v ýstupů

(from Aktivity Systému)

Generov ání v ýstupních souborů

«include»

«include»


«include»


«include»

«include»

«include»


«include»

«include»

«include»

«include»

27 / 90

uc Aktiv ity Administrátora

Administrátor




plánu portací pro MO


MO

Prov ádění korektivních akcí



Archiv ace dat

Stornov ání portace

Oprav a portace


objednáv ky

Administrace

Administrace subj ektů

Administrace uživ atelů

Administrace OpID a SPID

Prohlížení aplikačních

zpráv



Správ a číslov acího plánu dle SPID

Administrace přístupov ých

práv




FO / Úřad

Stažení tabulky přiřazení SPID a

OpID

Nastav ov ání v iditelnosti SPID

ostatním MO

Generov ání mimořádných

výstupů

(from Aktivity Systému)

Generov ání v ýstupních

souborů

Konfigurace WS spojení s OHS

Administrace kv ót pro dotazov ací

rozhraní

Monitoring dotazov acího

rozhraní

Stav dotazov acího

rozhraní

«include»

«include»


«include»


«include»

«include»

«include»


«include»

«include»

«include»

«include»

«include»

«include»

«include»

Obrázek 3: Aktivity Administrátora


Provádění korektivních akcí

Administrátor může na vyžádání mobilního operátora provádět tyto korektivní operace nad dříve zadanými portačními objednávkami, pokud neexistuje následná portace stejného čísla:

storno, oprava.

V obou případech je třeba rozlišovat, zda dochází ke korekci před zveřejněním konsolidovaného portačního plánu nebo až poté.Pokud administrátor zadal korektivní akci před konsolidací portačních plánů (tj. do 17:00 v den před portací), bude portační objednávka vyřazena (resp. opravena) a

Web GUI (3)

28 / 90


v konsolidovaném plánu portací se neobjeví (resp. objeví opravená) a změny z ní (původně) vyplývající nebudou součástí mobilní resynchronizace.Pokud administrátor zadá korektivní akci později, není výše uvedené garantováno a portační objednávka bude nevratně chybně publikována v konsolidovaném plánu portací a v mobilní resynchronizaci. Ke zveřejnění korektivní akce dojde v nejbližším dalším konsolidovaném plánu portací a mobilní resynchronizaci.Administrátor může provést storno opravené objednávky, po zadání storna již není možné provádět žádné další korekce.

Stornování portace

Administrátor na žádost MO provede storno podané portační objednávky podle PAC.

Web GUI (3)

Oprava portace

Administrátor na žádost MO provádí opravy podané portační objednávky vytvořením opravné objednávky dle PAC.

Web GUI (3)

Informace o zpracování portační objednávky

Získání informací o výsledku zpracování publikovaných portačních objednávek. Tato aktivita je k dispozici pro kontrolní účely při dohledávání chyb ve zpracování nebo jejich chybné publikaci.

Web GUI (3)



konsolidovaný plán portací pro MO, mobilní resynchronizace pro MO, fixní resynchronizace, tabulka přiřazení SPID a OpID, číslovací plán dle OpID, číslovací plán dle SPID.

Web GUI (3)

Stažení konsolidovného plánu portací pro MO

Získání souboru konsolidovaného plánu portací k určitému datu určeného pro libovolného mobilního operátora (tj. obsahující SPID viditelná tomuto operátorovi). Viz kapitola 6.1.


Stažení konsolidovného plánu portací pro FO / Úřad3. strany

Získání souboru konsolidovaného plánu portací k určitému datu určeného pro FO / Úřad3. strany (tj. neobsahující SPID). Viz kapitola 6.1.


29 / 90



Získání mobilního resynchronizačního souboru (tj. informace o portovaných číslech v mobilních sítích) k určitému datu určeného pro libovolného mobilního operátora (tj. obsahující SPID viditelná tomuto operátorovi). Viz kapitola 6.2.


Stažení mobilní resynchronizace pro FO / Úřad3. strany

Získání mobilního resynchronizačního souboru (tj. informace o portovaných číslech v mobilních sítích) k určitému datu určeného pro FO / Úřad3. strany (tj. neobsahující SPID). Viz kapitola 6.2.



Získání fixního resynchronizačního souboru k určitému datu. Tedy informace o portovaných číslech v pevných sítích. Resynchronizační data jsou jednou denně přebírána ze systému RNPDB-F NG a jsou převedena do stejného formátu jako data pro mobilní resynchronizaci. Viz kapitola 6.5



Získání souboru obsahujícího obraz tabulky přiřazující SPID poskytovatelů služeb k OpID operátorů. Viz kapitola 6.3. Web GUI (3)


Získání všeobecného číslovacího plánu mobilních čísel, který obsahuje pouze identifikaci OpID.

Web GUI (3)

Stažení číslovacího plánu dle SPID pro MO

Získání číslovacího plánu obsahujícího identifikaci poskytovatelů služeb (SPID) pro konkrétní MO. Jedná se o seznam výjimek, kdy rozsah je provozován jiným poskytovatelem. Administrátor může zvolit, pro kterého MO bude soubor stahovat.

Web GUI (3)

30 / 90


Správa číslovacího plánu SPID

Umožní definovat číslovací plán poskytovatele služby (SPID) pro rozsahy, které jsou zavedeny v rámci číslovacího plánu na OpID daného MO. Tento plán bude mít charakter výjimek, tzn., že bude zahrnovat pouze ty rozsahy, které nejsou provozovány daným OpID, ale jiným SPID.Dále platí, že: administrátor může přiřazovat

k rozsahům SPID, kteréhokoliv mobilního operátora,

SPID je možné přiřadit pouze k rozsahu, který patří stejnému OpID jako SPID,

rozsahy v číslovacím plánu SPID se nesmí překrývat,

v případě, že v rozsahu existuje platná portace, nebude systém povolovat změnové operace s tímto rozsahem.

Web GUI (3)

Administrace Shrnuje administrativní úlohy jako je správa subjektů a uživatelů systému, jejich údajů, přístupových certifikátů, a oprávnění k částem systému, přiřazení OpID a SPID identifikátorů a viditelnosti SPID

Web GUI (1)

Administrace subjektů

Administrátor může přidávat a odebírat subjekty a měnit jejich data. Subjektem se rozumí smluvní entita užívající systém přímo v roli MO, nebo FO / Úřad3. strany.Subjekty v roli MO mají přidělen jediný OHS ID.

Web GUI (2)

Administrace uživatelů

Systém umožňuje k jednotlivým subjektům přidávat a odebírat konkrétní uživatele (identifikované klientským certifikátem), tzn. osoby a automatické systémy, které budou se systémem fyzicky pracovat.U osob bude systém udržovat jméno, telefon, e-mail a poznámku. Těmto osobám budou zasílány vybrané notifikace e-mailem, pokud bude uveden.

Web GUI (1)

31 / 90


Administrace práv

Subjektům a uživatelům systém umožňuje nastavit konkrétní práva k jednotlivým aktivitám dostupným v rámci systému (publikace portačních objednávek, stahování výstupních souborů apod.), u subjektů maximálně do výše práv, vyplývající z jejich role, u uživatelů do výše práv subjektu viz kapitola 3.6.

Web GUI (1)

Administrace OpID

Administrátor přiděluje identifikátory OpID subjektům v roli MO. Každému MO přidělí alespoň jeden OpID. Přidělení OpID může administrátor měnit pouze do okamžiku vzniku navázaných informací (přiřazení SPID, přijetí portační objednávky), vazba OpID na konkrétní subjekt se stává poté trvalou.

Web GUI (2)

Administrace SPID

Administrátor přiděluje identifikátory poskytovatelům služeb v roli SP alespoň jeden SPID.Dále administrátor nastaví (na základě žádosti mobilního operátora) vazbu poskytovatele služeb k OpID. Přičemž platí, že pokud jeden právní subjekt poskytovatele služeb využívá umístění ve více OpID, bude v rámci RNPDB-M NG figurovat pod více SPID (jednoznačná vazba SPID na OPID).O zavedení nového SPID do systému budou mobilní operátoři informováni strojově generovaným e-mailem, směřujícím na uživatele dotčeného mobilního operátora, které mají nastavený příznak požadující zasílání změn v tabulce OpID a SPID a uvedený e-mail. Tato notifikace je podmíněná a musí být iniciována tlačítkem v GUI. Bude vyzývat uživatele mobilního operátora ke stažení seznamu přiřazení pomocí GUI.Změnu přiřazení SPID a OpID může administrátor provést pouze do okamžiku přidělení rozsahu čísel k SPID (viz kapitola 3.5.1, aktivita Správa číslovacího plánu dle SPID), vazba SPID a OpID se stává poté trvalou.

Web GUI (2)

32 / 90


Nastavování viditelnosti SPID ostatním MO

Administrátor může na žádost MO, v jehož síti pracuje určitý poskytovatel služeb rozšířit viditelnosti SPID tak, že ve výstupních souborech a zasílaných zprávách pro určitého jiného operátora nebude dané SPID nahrazováno OpID a tím umožní vybraným ostatním mobilním operátorům sledovat operace, které se dotýkají poskytovatele služeb s daným SPID.

Web GUI (3)

Konfigurace WS spojení s OHS

Administrátor spravuje parametry připojení s OHS u subjektů typu MO. Může nastavit URL OHS a jméno a vydavatele serverového certifikátu OHS.

Web GUI (3)

Administrace kvót pro dotazovací rozhraní

Subjektům, které disponují právem k přístupu k RNPDB-M QI, administrátor může nastavit denní a měsíční kvóty na jednotlivé typy dotazů.(nová záložka v administraci subjektů)

Web GUI (3)


Rozhraní pro vyhledání a zobrazení všech zveřejněných portačních objednávek, které se týkají konkrétního MSISDN.

Web GUI (3)


Prohlížení zpráv zaslaných do systému mobilními operátory nebo systémem mobilním operátorům včetně informace o stavu jejich zpracování. Uživatel zadá přímo identifikátor zprávy nebo vybere zprávu ze seznamu na základě filtrovacích kritérií (datum a typ zprávy, popř., typ vloženého aplikačního objektu).

Web GUI (3)

Generování mimořádných výstupů

Ruční spuštění generátoru konkrétního výstupního souboru, který za normálních okolností generuje pravidelně Systém. Tato aktivita umožní tyto soubory vygenerovat v libovolnou dobu pro zadaný čas portačního okna a zahrnuje:

generování konsolidovaných plánů portací,

generování mobilních resynchronizací,

generování fixní resynchronizace.Viz kapitola 3.5.5 aktivita Generování výstupních souborů.

Web GUI (3)

33 / 90


Monitorování dotazovacího rozhraní

Zobrazení grafu aktuální odezvy (měřené z primární a záložní lokality) a grafu provedených dotazů za posledních 24 hodin.Monitorovací agent bude provádět nezávislé měření odezvy a výsledky bude zasílat do RNPDB-M NG. Pro příjem výsledků měření z agentů bude vytvořena nezávislá webová služba autentizovaná certifikátem agenta.

Web GUI (3)

Stav dotazovacího rozhraní

Provedení testovacího dotazu na dotazovací rozhraní po stisknutí tlačítka a zobrazení úspěšnosti či neúspěšnosti tohoto testu.

Web GUI (3)


Poskytuje on-line a offline generované reporty uvedené v kapitole 6.5. Ty jsou generovány na základě vstupních kritérií s možností uložení výstupu ve formátu CSV, u dlouhotrvajících reportů s možností následného stažení offline. Poznámka: Administrátor může zvolit, zda se v těchto výstupních informacích uplatní práva viditelnosti konkrétních SPID jako pro určitého MO.

Web GUI (3)

Archivace dat

Administrátor provádí pravidelnou archivaci dat, která jsou k archivaci určena. Jedná se o historické soubory konsolidovaných portačních plánů, resynchronizace a systémových logů, dále o záznamy v databázi jako jsou historické a aplikační zprávy. Dále viz kapitola 3.5.5, aktivita Zálohování a příprava dat k archivaci.Administrátor provádí archivaci pomocí manuálních či automatizovaných postupů.Administrátor provádí zálohování archivovaných dat.

N/A

34 / 90

3.5.4[3.5.5] Systém (automatické aktivity)Tato kapitola shrnuje automatické a plánované aktivity systému samotného.

35 / 90

uc Aktiv ity Systému

Systém

Rekonciliace portačních plánů

Zaslání notifikace MO

Validace portačních plánů

Zálohování a příprav a dat pro

archivaci

Integrace

Generov ání v ýstupních souborů

Generov ání konsolidov aných

plánů portací

Generov ání mobilních resynchronizací

Generov ání fixní resynchronizace

Přebírání fixní resynchronizace z

RNPDB-F

Synchronizace s RDČ

Synchronizace s původním RNPDB-M

v souběžném prov ozu

Generov ání mobilních

resynchronizací pro MO

Generov ání mobilních

resynchronizací pro 3. strany


plánů portací pro MO


plánů portací pro 3. strany

Sběr dat o vytížení systému

Konsolidace portačních plánů

«include»

«include»

«include»

«include»

«include»

«include»


«include»

«include»

«include»

«include»

«include»

uc Aktiv ity Systému

Systém




Zálohování a příprav a dat pro

archivaci

Integrace

Generování výstupních souborů

Generování konsolidovaných

plánů portací

Generování mobilních resynchronizací

Generování fixní resynchronizace

Přebírání fixní resynchronizace z

RNPDB-F


Synchronizace s původním RNPDB-M

v souběžném prov ozu

Generování mobilních

resynchronizací pro MO

Generování mobilních

resynchronizací pro FO / Úřad

Generování konsolidovaných

plánů portací pro MO

Generování konsolidovaných plánů




«include»

«include»

«include»

«include»

«include»

«include»


«include»

«include»

«include»

«include»

«include»

Obrázek 4: Aktivity Systému

36 / 90



Systémem jsou automaticky prováděny kontroly obsahu publikovaného plánu portací (Bližší popis validací se nachází v kapitole 4.1.2.2) Zamítají se plány obsahující chyby. Systém umožňuje operátorům zaslat novou verzi plánu, ve které budou případné chyby opraveny (a to pouze do té doby, dokud není plán platně zpracován).Dále systém umožňuje zaslání plánu se speciálním příznakem, který bude obsahovat termín portace nesplňující požadavek na publikaci jeden pracovní den předem. Takovýto požadavek slouží k mimořádné opravě neúspěšně publikovaného plánu, bude systémem zpracován v nejbližším možném termínu a v historii systému jednoznačně označen jako mimořádný opravný požadavek (systém ale neumožní takto zadat portaci, která by mohla být ještě zadána jako řádná – tento postup je hodnocen jako chyba).

Automat (1)


Porovnání platných a relevantních plánů portací od obou dotčených operátorů (plánů, které byly úspěšně validovány). Výsledkem kontroly je buď přijetí plánu jako platně publikovaného (pokud je ve shodě publikován oběma operátory) nebo jeho zamítnutí z důvodu chyby. Za obsahovou správnost plánu jsou odpovědni opouštěný i přejímající operátor (plán byl dohodnut mezi nimi pomocí distribuovaného objednávkového systému) a takové plány jsou systémem zpracovány (referenční databáze nesmí ohrozit proces portace dohodnutý pomocí distribuovaného objednávkového systému).

Automat (1)


Po úspěšné rekonciliaci portačních plánů systém připraví konsolidovaný plán portací, ve kterém zaznamená pro každé číslo/rozsah z rekonciliovaných portačních plánů informace o opouštěném/přejímajícím operátorovi (příp. poskytovateli služeb), provedenou operaci (portace/návrat čísla) a datum portace.Při navrácení čísla (RETURN) bude aplikace zjišťovat skutečné SPID vlastníka rozsahu, ke kterému se jednotlivá čísla obsažená ve

Automat (1)

37 / 90


zprávě, navrací.Při portaci čísla, při které se číslo dostane zpět k vlastníkovi rozsahu (PORT BACK), aplikace rozpozná nastalou situaci a označí číslo jako neportované, tj. neobjeví se v resynchronizaci a nebude blokovat nakládání s rozsahem v číslovacím plánu.


Notifikace klientů o události v systému. Bude realizována zasláním zprávy pomocí webové služby.Notifikace se zasílá:

jako oznámení výsledku validace (kontroly) portačního plánu operátorovi, který plán publikoval,

jako oznámení výsledku rekonciliace (porovnání) portačních plánů oběma dotčeným operátorům (tzn., zda se plány publikované oběma operátory shodují nebo neshodují, popř. v případě, že dorazil plán pouze od jednoho z dotčených operátorů),

jako upozornění všem mobilním operátorům, že byl vygenerován konsolidovaný portační plán (dokončení konsolidace).

WebService (1)

Generování výstupních souborů

Systém provádí pravidelné generování řady výstupních souborů:

konsolidované plány portací, mobilní resynchronizace, fixní resynchronizace.

Více viz kapitola 6.

Automat (1)

Generování konsolidovaných portačních plánů

Systém generuje konsolidované portační plány:

pro jednotlivé mobilní operátory a pro FO / Úřad3. strany.

Viz kapitola 6.1.

Automat (1)

Generování konsolidovaných portačních plánů pro MO

Systém generuje konsolidované portační plány pro každého mobilního operátora zvlášť. Každý ze souborů obsahuje informace o SPID poskytovatelů služeb pracujících v síti daného operátora a SPID, která byla danému operátorovi zviditelněna.

Automat (1)

38 / 90


Generování konsolidovaných portačních plánů pro FO / Úřad3. strany

Systém generuje konsolidovaný portační plán neobsahující žádné informace o SPID poskytovatelů služeb určený pro FO / Úřad3. strany.

Automat (1)

Generování mobilních resynchronizací

Systém generuje soubory mobilních resynchronizací:

pro jednotlivé mobilní operátory a pro FO / Úřad3. strany.

Viz kapitola 6.2.

Automat (1)

Generování mobilních resynchronizaci pro MO

Systém generuje soubor mobilní resynchronizace pro každého mobilního operátora zvlášť. Každý ze souborů obsahuje informace o SPID poskytovatelů služeb pracujících v síti daného operátora a SPID, která byla danému operátorovi zviditelněna.

Automat (1)

Generování mobilních resynchronizaci pro FO / Úřad3. strany

Systém generuje soubor mobilní resynchronizace neobsahující žádné informace o SPID poskytovatelů služeb určený pro FO / Úřad3. strany.

Automat (1)

Generování fixní resynchronizace

Systém bude transformovat soubor fixní resynchronizace do formátu RNPDB-M. Tento soubor je určen všem operátorům. Viz kapitola 6.5.

Automat (2)

Integrace Systém interaguje s dalšími systémy: stávající RNPDB-M (v souběžném

provozu) RNPDB-F

Automat (2)


Systém přebírá informace o číslovacím plánu ze systému RNPDB-F, jehož je RDČ součástí (viz kapitola 3.7.2).Systém validuje konzistenci zadaných informací v rámci číslovacího plánu dle SPID po synchronizaci s RDČ.

Automat (2)

Přebírání fixní resynchronizace z RNPDB-F

Systém bude přebírat aktuální textový soubor fixní resynchronizace ze systému RNPDB-F

Automat(2)

39 / 90


Synchronizace s původním RNPDB-M v souběžném provozu

Během souběžného provozu nové RNPDB-M NG se stávajícím RNPDB-M bude docházet k přebírání dat o uzavřených portačních objednávkách, které vznikly před 1. 9. 2013. Viz kapitola 9.2.Činnost synchronizace a souběžného provozu bude ukončena ke dni 2. 11. 2013.

Automat (3)


Systém sbírá průběžně ukazatele zatížení vyjmenovaných částí systému (CPU, paměť, disk, síť) v definovaných intervalech. Systém udržuje historii těchto údajů nejméně 1 měsíc zpětně a poskytuje je pro zobrazení ve formě reportu.

Automat (3)

Zálohování a příprava dat pro archivaci

Automatické zálohování systému bude prováděno každý den v době od 0:00 do 5:00 na externí médium.Součástí procesu zálohování bude i příprava dat k archivaci, tzn. odebrání provozních dat starších než 15 měsíců ze systému a jejich příprava pro zálohu na externí médium (archivaci provádí jednou měsíčně administrátor systému). V systému zůstane kompletní databáze portovaných čísel, archivovat se budou data událostí v systému, tj. soubory resynchronizace, konsolidovaný portační plán, data portačních zpráv, logy, apod.).Viz též kapitola 8.4.

Automat (3)

3.6 Přístupová právaAplikace řídí přístup uživatelů k jednotlivým funkcím podle přidělených práv. Maximální práva jednotlivých rolí jsou pevně daná v aplikaci v souladu s případy užití. Tato práva mohou být jednotlivým subjektům omezena. Následně mohou být práva jednotlivým uživatelům daného subjektu dále omezována.Práva jsou rozdělena na práva k rozhraním a práva k funkcím.

[3.6.1] Práva k rozhraním:Právo k rozhraní Popis MO FO

/ Úřad3. strana

3. strana

Přístup k Web GUI Přístup k webovému rozhraní pomocí webového prohlížeče.Určeno pro uživatele

X X -

40 / 90

Právo k rozhraní Popis MO FO / Úřad3. strana

3. strana

Přístup k WebService

Přístup k webové službě.Určeno pro OHS automaty

X - -

Přístup k WebService dotazovacího rozhraní

Přístup k webové službě dotazovacího rozhraníUrčeno pro automaty 3. stran

X X X

Přístup ke stahování souborů

Stahování souborů nezávisle na GUI.Určeno pro uživatele i stahovací automaty.

X X -

Spuštění dlouhotrvajících reportů

Přístup ke spuštění offline reportů (náročných reportů, jejichž vykonání řídí systém) a přístup k seznamu zadaných offline reportů.Určeno uživatelům.

X - -

3.6.1 Práva k funkcím:Právo k funkci Popis MO FO

/ Úřad3. strana

3. strana

Publikace portačních plánů

Zadání portačních objednávky pro portace i návrat čísla. Přes GUI i přes webovou službu

X - -

Správa číslovacího plánu dle SPID

Přístup ke GUI pro správu rozsahů přidělovaných SP.

X - -

Správa viditelnosti SPID

Přístup ke GUI nastavení viditelnosti SPID ostatním MO.

X - -

Stažení číslovacího plánu

Generování a stažení RDČ číslovacího plánu.Je třeba mít i právo k rozhraní „Přístup k souborům pro stažení“.

X X -

Stažení číslovacího plánu

Stažení číslovacího plánu rozsahů přidělených SP. Je

X - -

41 / 90

Právo k funkci Popis MO FO / Úřad3. strana

3. strana

dle SPID třeba mít i právo k rozhraní „Přístup k souborům pro stažení“.


Přístup ke GUI s výběrem souboru fixní resynchronizace ke stažení a následnému stažení souboru fixní resynchronizace.Je třeba mít i právo k rozhraní „Přístup k souborům pro stažení“.

X - -

Stažení konsolidovaného portačního plánu

Přístup ke GUI s výběrem souboru fixní resynchronizace ke stažení a následnému stažení souboru fixní resynchronizace.Je třeba mít i právo k rozhraní „Přístup k souborům pro stažení“.

X X -

Stažení mobilní resynchronizace

Přístup ke GUI s výběrem souboru mobilní resynchronizace ke stažení a následnému stažení souboru mobilní resynchronizace.Je třeba mít i právo k rozhraní „Přístup k souborům pro stažení“.

X X -

Získání historie čísla nebo rozsahu

Zobrazení všech portací a návratů k danému číslu v GUI.

X X -

Získání informací o portačním plánu

Zobrazení informací o stavu zpracování portační objednávky v GUI

X - -

Získání tabulky přiřazení SPID

Zobrazení aktuálního seznamu poskytovatelů služeb.Není třeba mít i právo k rozhraní „Přístup k souborům pro stažení“.

X - -

Zobrazení reportů Přístup ke generování reportů (vč. offline reportů)

X - -

Spuštění jednoduchého

Zadání dotazu na umístění X X X

42 / 90

Právo k funkci Popis MO FO / Úřad3. strana

3. strana

dotazu na umístění čísla

jednotlivého telefonního čísla.Je třeba mít i právo „Přístup k WebService dotazovacího rozhraní“

Spuštění hromadného dotazu na umístění čísla

Zadání hromadného dotazu na umístění seznamu telefonních čísel.Je třeba mít i právo „Přístup k WebService dotazovacího rozhraní“

X X X

43 / 90

3.7 Číslovací plánDo číslovacího plánu v RNPDB-M NG jsou zaznamenávány pouze informace relevantní pro mobilní operátory a to včetně historických dat.

3.7.1 StrukturaStruktura číslovacího plánu, ukládaného do RNPDB-M NG vychází ze struktury v RDČ. Data nepotřebná pro RNPDB-M NG nebudou přenášena. Číslovací plán RNPDB-M NG dle OpID bude v reálném čase zrcadlit aktuální číslovací plán z RDČ. Číslovací plán dle OpID bude obsahovat především:

MSISDN range – počátek a konec rozsahu, OpID – identifikátor mobilního operátora, který má přidělený rozsah

od ČTÚ nebo je v jeho síti rozsah umístěn poskytovatelem služeb, Validity – časová platnost záznamu (interval od-do)

Vedle toho vznikne zcela nová tabulka pro zápisy výjimek, týkající se poskytovatelů služeb. Obě tabulky spolu budou z výkonnostních důvodů provázány pomocí jednoznačného identifikátoru z RDČ.Tabulka výjimek bude obsahovat především:

RDČ reference – odkaz na záznam nadřazeného rozsahu v RDČ, MSISDN range – počátek a konec rozsahu, OpID – identifikátor mobilního operátora, v jehož síti je rozsah

umístěn nebo z jehož sítě je rozsah propůjčen, SPID – identifikátor provozovatele služeb, Validity – časová platnost záznamu (interval od – do).

44 / 90

3.7.2 Synchronizace s RDČZpůsob této on-line synchronizace RNPDB-M NG a RDČ ilustruje tento obrázek:

sd RDČ synchronizace

RDČ

Synchronizačnífronta RNPDB-F

JMS Bridge

Synchronizačnífronta RNPDB-M

NG

RNPBB-M NGRNPDB-M NGResync MDB

RNPDB-F

RNPDB-M NG

Legend Odstranění z fronty

Ostranění z fronty

SynchroEvent()

commit()

SynchroEvent Write()

commit()

Obrázek 5: Příklad RDČ synchronizace ve směru do RNPDB-M NGVazba mezi RNPDB-M NG a RDČ bude obousměrná. To znamená, že zatímco do RNPDB-M se z RDČ budou přenášet informace o přidělených rozsazích, zpět do RDČ se bude v reálném čase přenášet příznak o zablokování rozsahu z důvodu vzniku navázaných informací, které jsou udržovány v RNPDB-M NG (tzv. EM příznak). Nastavení EM příznaku značí, že v RNPDB-M NG existuje buď:

přidělení rozsahu/podrozsahu poskytovateli služeb nebo portace čísla z tohoto rozsahu.

Změnové operace s takovými rozsahy čísel, nebudou v RDČ povoleny.Informace o změnách v přidělení mobilních číselných rozsahů budou z RDČ propagovány do RNPDB-M NG bezprostředně po vlastní operaci v RDČ. Přenášená data budou transformována do formátu vyhovujícím RNPDB-M NG a filtrována dle aktuálního seznamu mobilních OpID. Stávající RDČ zůstane i nadále primárním a rozhodujícím zdrojem informací.

45 / 90

[4.] Komunikační standardy automatických rozhraníOHS

Detailních technický popis zpráv a komunikačních standardů je definovaný dokumentem [TMMNPspec].Hlavní principy komunikace při zasílání zpráv jsou následující: Pro přenos zpráv je použito asynchronního přenosu zpráv za použití

synchronního volání webové služby. Webová služba umožňuje zasílání zpráv transportní vrstvy

MNPMessage (obálka pro přenos zpráv aplikační vrstvy) a MNPMessageReply (zpráva potvrzující úspěšné přijetí zprávy MNPMessage).

Transportní vrstva opakovaně doručuje zprávy MNPMessage, dokud neobdrží potvrzení o přijetí pomocí zprávy MNPMessageReply, nebo dokud nevyprší platnost zprávy, nebo dokud webová služba neindikuje požadavek o přerušení zasílání zprávy.

Transportní vrstva opakovaně doručuje potvrzující zprávu MNPMessage, dokud nevyprší platnost zprávy, nebo dokud webová služba neindikuje požadavek o přerušení zasílání zprávy.

Zprávy aplikační vrstvy, reprezentující aplikační události a výsledky jejich zpracování, se předávají výhradně pomocí odpovídajících zpráv transportní vrstvy.

3.8[4.1] Publikace a zpracování portačních plánůNásledující tabulka shrnuje reakci systému na události v portačním procesu.Sledovaná metrika Garantovaná hodnotaPublikace portačních plánů

Výsledek validace (kontroly) portačního plánu bude notifikován publikujícímu operátorovi zasláním zprávy nejpozději do 60 minut od obdržení portačního plánu.


Výsledek rekonciliace (porovnání plánů od obou dotčených operátorů) bude zaslán nejpozději do 60 minut od validace obou plánů. V případě, že druhý plán nedorazí do 12:00, budou oba dotčení operátoři notifikováni zasláním zprávy nejpozději do 13:00.

Generování konsolidovaného portačního plánu

Konsolidovaný portační plán bude vygenerován každý pracovní den nejpozději v 18:00. Tato skutečnost bude notifikována mobilním operátorům zasláním zprávy v časovém intervalu od 17:00 do 19:00.

Generování mobilní resynchronizace

Resynchronizační soubory budou generovány v pracovní dny nejpozději do 18:00. Tato skutečnost bude notifikována mobilním operátorům zasláním zprávy v časovém intervalu od 17:00 do 19:00.

46 / 90

Doba limitů všech akcí v rámci časových oken bude konfigurovatelná (tzn., že se nepředpokládá jiné časové okno než 1 den, ale např. limit pro publikaci nebo čas generování výstupů bude konfigurovatelný).Následující diagram popisuje mechanizmus komunikace a formáty zpráv při publikaci portačních plánů, jejich validaci, rekonciliaci a konsolidaci.

sd Publikace a zpracov ání portačních plánů

DNO/RNO RNO/DNO

RNPDB-M NG

Publikace portačního plánu opouštěným nebo přejímajícím operátorem

Potvrzení při jetí systémemVýsledek validace portačního plánu (akceptace nebo zamítnutí). Do 60 minut.

Publikace portačního plánu

Potvrzení přijetí systémemVýsledek validace portačního plánu (akceptace nebo zamítnutí). Do 60 minut.

Výsledek rekonciliace. Max. 1 hodinu od validace.

loop Korekce

loop Korekce

MNP Message(PortingOrderPublish, ReturnNumberPublish)

MNP MessageReply() Validaceportačníhoplánu()

MNP Message(CRDBVal idationResult)

MNP MessageReply()

MNP Message(PortingOrderPublish, ReturnNumberPublish)

MNP MessageReply() Validaceportačníhoplánu()

MNP Message(CRDBValidationResult)

MNP MessageReply()

Rekonciliaceportacníchplánu()

MNP Message(CRDBReconsi liationResult)

MNP MessageReply()

MNP Message(CRDBReconsill iationResult)

MNP MessageReply()

Obrázek 6: Publikace a zpracování portačních plánů

47 / 90

3.8.1[4.1.1] Rozvržení pracovního dneProvozní hodiny systému jsou v pouze pracovní dny a to od 9:00 do 22:00. V tomto termínu je možno obecně zasílat zprávy do RNPDB-M a očekávat odeslání zprávy z RNPDB-M. Systém bude obsahovat informace o státních svátcích.Detailnější rozvrh chování centrální databáze popisuje následující tabulka:Období Popis9:00 – 12:00

příjem1 řádných portačních plánů (PortingOrderPublishCRDB a ReturnNumberPublishCRDB) na následující pracovní den

9:00 – 13:00

odesílání CRDBValidationResult jako reakce na příjem portačních plánů (do 60 minut od přijetí)

9:00 – 14:00

odesílání výsledků rekonciliace řádných portačních plánů CRDBReconciliationResult (do 60 minut od validace)

12:00 – 13:00

rozesílání upozornění, že byl publikován portační plán pouze jedním operátorem (CRDBReconciliationResult)

12:00 –16:00

příjem mimořádných portačních plánů (PortingOrderPublishCRDB a ReturnNumberPublishCRDB) na následující pracovní den, např. v reakci na upozornění CRDBReconciliationResult;příjem řádných portačních plánů pro vracení čísel (ReturnNumberPublishCRDB) na druhý následující pracovní den;odmítání řádných portačních plánů (PortingOrderPublishCRDB) na následující pracovní den

16:00 – 22:00

příjem řádných portačních plánů pro vracení čísel (ReturnNumberPublishCRDB) na druhý následující pracovní den, ostatní řádné i mimořádné portační plány na následující pracovní den jsou odmítány.

12:00 – 17:00

odesílání CRDBValidationResult jako reakce na příjem mimořádných portačních plánů (do 60 minut).

12:00 – 17:00

odesílání výsledků rekonciliace mimořádných portačních plánů CRDBReconciliationResult (do 60 minut od validace)

16:30 (–17:30 )

generování fixní resynchronizace

17:00 (– 18:00)

spuštění konsolidace portačních plánů a generování souborů konsolidovaných portačních plánů a mobilní resynchronizace

1 přijetí zprávy může být umožněno i mimo uvedené okno, pokud došlo ke zpoždění při doručování a datum a čas publikace splňuje podmínky přijetí objednávky viz kap. 4.1.2.2.

48 / 90

Období Popis16:30 – 19:00

rozesílání notifikace o vygenerovaných souborech mobilním operátorům pomocí zprávy ExtractFileInformation

17:00+ – 22:00

stahování souborů konsolidovaných portačních plánů a mobilních resynchronizací.

19:00 – 22:00

procesní rezerva na řešení mimořádných stavů

22:00 – 9:00

mimoprovozní hodiny (zálohování, archivace, administrace prostředí)

22:00 – 9:00

stahování souborů, prohlížení dostupnost WebGUI, Download UI a Web Service možná, ale negarantovaná

3.8.2[4.1.2] Validace a kontroly při zpracováníV této kapitole jsou popsány vybrané validace systému RNPDB-M NG.

3.8.2.1[4.1.2.1] Obecné kontroly příchozích zprávKód chyby je vracen jako Status v synchronní odpovědi v elementu Response. Status

Popis

0 OK, přijetí zprávy proběhlo v pořádku

-1 Chyba, přijetí zprávy neproběhlo v pořádku, opakujte později

-2 Odmítnuto, nejsou provozní hodiny aplikace, opakujte později

-3 Neautorizováno, zprávu nemáte právo posílat, zpráva skartována

-4 Trvalá chyba, takovou zprávu nelze zpracovat, neopakujte.

Detail chyby je obsažen v synchronní odpovědi v elementu Reason (ReasonCode, ReasonMessage), případně je generována zpráva směrem k odesílateli s detailním Status a Error (ErrorCode, ErrorMessage):Popis chyby Synchronn

í odpověďStatus (ReasonCode)

Asynchronní odpověď[MNPMessageReply]Status(ErrorCode)

Vše v pořádku 0 ACCEPT

Obecná (interní) chyba -1 (9990-9999)

[N/A]

Nejsou provozní hodiny -2 (9100) REJECT (NON_WORKING_TIME)

49 / 90

Popis chyby Synchronní odpověďStatus (ReasonCode)

Asynchronní odpověď[MNPMessageReply]Status(ErrorCode)

Uživatel nebyl autentizován (chybí certifikát)

-3 (9101) [N/A]

Uživatel nebyl autentizován (neexistuje v DB)

-3 (9102) [N/A]

Uživatel nebyl autorizován (nemá příslušná práva)

-3 (9103) [N/A]

OHS ID odesílatele neodpovídá přihlášenému uživateli

-3 (9104) [N/A]

Id zprávy není jedinečné -4 (9107) [N/A]

Chybný formát těla zprávy (chybí informační objekt)

-4 (9112) REJECT (INVALID_FORMAT)

Chybný formát těla zprávy (informačního objektu)


Neznámý typ těla zprávy (informačního objektu)


Přijatá zpráva je duplikát již přijaté zprávy

0 (9120) ACCEPT

50 / 90

3.8.2.2[4.1.2.2] Validace portačních objednávekKód chyby je vracen pomocí zprávy CRDBValidationResult v elementech Status a Reason (ReasonCode, ReasonMessage).Popis validace Status Reaso

nCodeObecná chyba REJECT 1000

Neplatný identifikátor plánu – PACId je již zpracováno (konsolidováno) REJECT 1001

Neplatné datum a čas portace s ohledem na datum a čas publikace2 (řádná portace nemá uvedené datum a čas publikace do 12:00 pracovního dne před portací, mimořádná 12:00 – 16:00 pracovního dne před portací)

REJECT 1002

Neplatné OHS ID pro DNO, CNO, RNO nebo RH, nebo neplatné SPID pro RSP nebo DSP REJECT 1003

Publikující operátor není opouštěným ani přejímajícím operátorem REJECT 1004

Řádná portace zadaná jako mimořádná REJECT 1005

Pro číslo již existuje portace na týž den REJECT 1006

Číslo z rozsahu, který není zaveden v RDČ pro mobilní síť nebo z rozsahu, kde nejsou portovatelná čísla (tj. začínající 1xx, 2xx, 3xx, 4xx nebo 5xx).

REJECT 1007

Neplatný DNO/CNO pro dané číslo nebo rozsah REJECT 1008

Neplatný RH pro dané číslo nebo rozsah při návratu čísla REJECT 1009

Portační objednávka nebyla přijata ve vyhrazeném časovém okně (tj. pro portace čísel 9:00 – 16:00 DP-1, a pro navrácení čísla 12:00 DP-2 – 16:00 DP-1)

REJECT 1010

Neplatné datum a čas publikace operátorem (je více než 2 pracovní dny staré nebo je v budoucnosti)

REJECT 1011

3.8.2.3[4.1.2.3] Validace portačních objednávek zadávaná v GUI

Webový formulář pro zadávání portačních objednávek ručně provádí následující kontroly a zjištěné nedostatky vypisuje na obrazovku:.

2 „datum a čas publikace“ je datum přijaté v elementu <PublishDateTime> zprávy PortingOrderPublishCRDB a ReturnNumberPublishCRDB

51 / 90

PAC není ve správném formátu (!= 11 znaků) p řejímající a opouštěný operátor nejsou různí n eplatné datum c hybějící čísla/rozsahy c hybně zadaná čísla/rozsahy (chybná délka MSISDN, nečíselné

znaky) o bjednávka obsahuje chybu dle 4.1.2.2 Popis validace PAC není ve správném formátu (!= 11 znaků) Přejímající a opouštěný operátor nejsou různí Neplatné datum Chybějící čísla/rozsahy Chybně zadaná čísla/rozsahy (chybná délka MSISDN,

nečíselné znaky) Objednávka obsahuje chybu dle 4.1.2.2

52 / 90

[4.1.2.4] RekonciliacePo rekonciliaci se posílá zpráva CRDBReconciliationResult obsahující kód dle tabulky v elementech Status a Reason (ReasonCode, ReasonMessage):Popis validace Status ReasonC

odeRNO, DNO, typ operace, datum portace i seznam čísel v obou publikovaných plánech je shodný

ACCEPT 0

RNO, DNO, typ operace, datum portace nebo seznam čísel v obou publikovaných plánech je různý

REJECT 1101

Jeden z operátorů nezaslal portační plán do určeného času (do konsolidace portačních plánů)

REJECT 1102

Jeden z operátorů nezaslal portační plán do určeného času (do konce okna pro příjem portačních plánů)

WARNING 2101

3.9[4.2] Stažení konsolidovaného portačního plánu a mobilní resynchronizace

Následující diagram popisuje mechanizmus komunikace a formáty zpráv při stahování konsolidovaného portačního plánu (resp. mobilní resynchronizace).

53 / 90

sd Generov ani a stahov ání konsolidovaných portačních plánů

MO

RNPDB-M NG

3. strana

Posílá se do 19:00.

Automatická úloha, která se spouští v 17:00 a trvá max. do 18:00.

par konzumenti portačních plánů

[MO]

[3. strana]

Konsolidace portačníchplánů()

Generování konsolidovanýchportačních plánů()

MNP Message(ExtractFileInformation)

MNP MessageReply()

Download konsolidovaného portačního plánu s SPID pro MO()

«HTTPS»

Download konsolidovaného plánu bez SPID()

«HTTPS»

sd Generov ani a stahov ání konsolidov aných portačních plánů

MO

RNPDB-M NG

FO / Úřad

Posílá se do 19:00.

Automatická úloha, která se spouští v 17:00 a trvá max. do 18:00.

par konzumenti portačních plánů

[MO]

[FO / Úřad]

Konsolidace portačníchplánů()

Generování konsolidovanýchportačních plánů()

MNP Message(ExtractFileInformation)

MNP MessageReply()

Download konsolidovaného portačního plánu s SPID pro MO()

«HTTPS»

Download konsolidovaného plánu bez SPID()

«HTTPS»

Obrázek 7: Stažení konsolidovaného plánu portacíKonsolidovaný portační plán a mobilní resynchronizace budou vygenerovány každý pracovní den nejpozději v 18:00 a bude obsahovat seznam všech portací/vracení/mimořádných oprav, které mají proběhnout následující pracovním den, resp. stav k následujícímu pracovnímu dni. Mobilní operátoři budou současně do 19:00 notifikováni zasláním zpráv o tom, že jsou soubory připraveny ke stažení.Stažení souborů bude probíhat těmito způsoby:

buď pomoci Download GUI, kde systém nabídne soubor ke stažení na základě výběru,

nebo přímo pomocí automatického rozhraní (HTTPS download), kde uživatel/systém stáhne soubor buď na URL, které obdržel ve zprávě ExtractFileInformation nebo na známém URL:https://rnpdbm.cnpac.cz/rnpdbm/download?file_name=<jméno souboru>,kde jméno souboru, obsah a formát konsolidovaného portačního plánu je popsán v kapitole 6.1.

Historické soubory konsolidovaného portačního plánu a mobilní resynchronizace budou v systému uchovávány po dobu 15 měsíců, pak budou archivovány na externí médium

3.10[4.3] Stažení dalších souborůSystém pravidelně či na požádání generuje další níže uvedené soubory a umožňuje jejich získání oprávněným registrovaným uživatelům:

54 / 90

fixní resynchronizace, tabulka přiřazení SPID k OpID (na požádání), mobilní číslovací plán (na požádání).

Následující diagram zobrazuje příklad vytváření a stahování fixních resynchronizačních souborů mobilními operátory:

sd Generovani a stahov ání fixních resynchronizačních souborů

MO

RNPDB-M NG

Automatická úloha, fixni resynchronizace bude k dispozici do 3:00.

par konzumenti resynchronizačních souborů

[MO]

Generováníresynchronizačníchsouborů()

Download fixní resynchronizace()

«HTTPS»

Obrázek 8: Stažení fixní resynchronizaceSoubory fixní resynchronizace budou vygenerovány každý provozní den tak, aby byly k dispozici nejpozději od 18:00 ke stažení. Budou obsahovat stav platný k následujícímu pracovnímu dni.Soubory fixní resynchronizace jsou přebírány z RNPDB-F a transformovány do formátu shodného s mobilní resynchronizací.Stažení souborů bude probíhat těmito způsoby:

buď pomoci Download GUI, kde systém nabídne příslušné soubory ke stažení na základě výběru,

nebo přímo pomocí automatického rozhraní (HTTPS download), kde uživatel/systém stáhne soubor na určeném URL:https://rnpdbm.cnpac.cz/rnpdbm/download?file_name=<jméno souboru>.

Detailní popis formátů a názvů souborů je uveden v kapitole 6.

Historické soubory budou v systému uchovávány po dobu 15 měsíců, pak budou archivovány na externí médium.

55 / 90

3.11[4.4] Zabezpečení komunikaceKomunikace mezi RNPDB-M a ostatními subjekty bude probíhat přes veřejný Internet prostřednictvím zabezpečeného protokolu HTTPS. Bude použita autentizace uživatelů/systémů prostřednictvím klientských certifikátů vydaných jednou ze schválených veřejných certifikačních autorit. Aplikace eviduje klientské certifikáty uživatelů a systémů (jejich subjekty a vydavatele) v databázi a používá je pro identifikaci konkrétních klientů a autorizaci požadavků proti přiděleným přístupovým právům. Při odchozí komunikaci aplikace ověřuje serverový certifikát protějšku.Všechny použité certifikáty musí být platné, nesmí být umístěny na seznam zneplatněných certifikátů a musí být použity v souladu s povoleným způsobem užití klíče (tj. pro uživatele jako klientské, a pro systémy jako serverové i klientské); serverové certifikáty musí být vydány pro DNS jméno serveru určené pro komunikaci.Následující tabulka shrnuje základní bezpečnostní parametry komunikace, které musí být splněny všemi zúčastněnými partnery (RNPDB-M NG, MO, FO, Úřad, třetí strany).Parametr Požadovaná podporaUznávané certifikační autority (seznam může být rozšířen o další CA, pokud se na tom mobilní operátoři shodnou)

RNPDB-M NG bude od počátku podporovat tyto CA:

vydávající kvalifikované certifikáty (I. CA, Postsignum, eIdentity),

světové veřejné (VeriSign, Thawte, RapidSSL),

interní (CA Telefónica, TMCZ CA, GTS Cyber Trust),

další CA, na kterých se MO shodnou.Aby mohla být CA přidána do seznamu, musí splňovat základní technické, bezpečnostní a funkční parametry:

publikovat závaznou Certifikační Politiku (platný URI odkaz je součástí každého vystaveného certifikátu),

poskytnout certifikát CA, vydávat certifikáty s délkou klíčů a

algoritmy níže, pravidelně publikovat seznam

zneplatněných certifikátů (CRL) na veřejně dostupném URL.

Délka klíče 2048 bitů (preferováno)1024 bitů (minimum)

Algoritmus podpisu SHA-2 (preferováno)SHA-1 (minimum, povoleno pro serverové a CA certifikáty)

56 / 90

Parametr Požadovaná podporaRevokace certifikátů Systém RNPDB-M NG bude pravidelně

stahovat CRL vydávaná uznávanými certifikačními autoritami z veřejně dostupných URL a kontrolovat, zda nebyla odvolána platnost certifikátu.

3.12[4.5] Rozhraní WebServiceKaždá ze stran, účastnící se komunikace pomocí rozhraní WebService (tzn., všichni mobilní operátoři a systém RNPDB-M) musí implementovat dále definované rozhraní webové služby, aby byla zajištěna možnost kontaktovat každou z dotčených stran zasláním relevantní zprávy (tzn., operátoři předávají zprávy RNPDB-M pomocí webové služby RNPDB-M a naopak, RNPDB-M předává zprávy operátorům pomocí jejich vlastních webových služeb).Popis rozhraní je součástí dokumentu [TMMNPspec] včetně WSDL a XSD.

57 / 90

4.[5.] Formáty zpráv rozhraní OHS4.1[5.1] XML zprávy transportní vrstvy4.1.1[5.1.1] MNPMessageZpráva MNPMessage je transportní obálkou pro ostatní XML zprávy, ty jsou pak součástí této zprávy (jako element InformationObject). Platný popis a XML schéma jsou součástí dokumentu [TMMNPspec].V rámci systému RNPDB-M je zpráva MNPMessage použita pro přenos následujících zpráv:

PortingOrderPublishCRDB ReturnNumberPublishCRDB CRDBValidationResult CRDBReconciliationResult ExtractFileInformation

Následující diagram popisuje strukturu zprávy:

Obrázek 9: Zpráva MNPMessage

58 / 90

4.1.2[5.1.2] MNPMessageReplyZpráva MNPMessageReply je odpovědí na zprávu MNPMessage (nemá tedy zprávu MNPMessage jako obálku). Jejím účelem je potvrdit odesílateli zprávy MNPMessage, že jeho zpráva byla úspěšně přijata, příjemce rozumí její struktuře a provede její zpracování. Platný popis a XML schéma jsou součástí dokumentu [TMMNPspec].

Obrázek 10: Zpráva MNPMessageReply

59 / 90

4.2[5.2] Přijímané XML zprávy aplikační vrstvy4.2.1[5.2.1] PortingOrderPublishCRDBTuto zprávu používá klient pro notifikaci systému RNPDB-M o portaci jednoho čí více MSISDN. Platný popis a XML schéma jsou součástí dokumentu [TMMNPspec]. Následující diagram popisuje strukturu zprávy.

Obrázek 11: Zpráva PortingOrderPublishCRDB

60 / 90

4.2.2[5.2.2] ReturnNumberPublishCRDBTuto zprávu používá klient pro notifikaci systému RNPDB-M o vrácení jednoho či více MSISDN vlastníkovi příslušného rozsahu. Platný popis a XML schéma jsou součástí dokumentu [TMMNPspec]. Následující diagram popisuje strukturu zprávy.

Obrázek 12: Zpráva ReturnNumberPublishCRDB

61 / 90

4.3[5.3] Odesílané XML zprávy aplikační vrstvy4.3.1[5.3.1] CRDBValidationResult Tato zpráva je určena pro notifikaci klientů systému RNPDB-M výsledku validace portačního plánu. Platný popis a XML schéma jsou součástí dokumentu [TMMNPspec]. Následující diagram popisuje strukturu zprávy.

Obrázek 13: Zpráva CRDBValidationResult

4.3.2[5.3.2] CRDBReconciliationResult Tato zpráva je určena pro notifikaci klientů systému RNPDB-M o celkovém nebo dílčím výsledku rekonciliace portačních plánů čísel. Platný popis a XML schéma jsou součástí dokumentu [TMMNPspec]. Následující diagram popisuje strukturu zprávy.

Obrázek 14: Zpráva CRDBReconciliationResult

62 / 90

4.3.3[5.3.3] ExtractFileInformationTato zpráva je určena pro notifikaci klientů systému RNPDB-M o tom, že je připraven soubor ke stažení (např. konsolidovaný portační plán). Je zasílána systémem pro všechny vygenerované soubory a rozlišuje mezi typy souborů, kterých se týká. Platný popis a XML schéma jsou součástí dokumentu [TMMNPspec]. Následující diagram popisuje strukturu zprávy.

Obrázek 15: Zpráva ExtractFileInformation

63 / 90

5.[6.] Generované souboryNásledující kapitoly popisují formát a obsah souborů generovaných systémem pravidelně či na vyžádání v GUI. Formát souborů je jednotný CSV, kde:

oddělovačem je znak středníku (;), první řádek souboru obsahuje hlavičku s označením jednotlivých

polí, pro non-ASCII znaky se používá kódování UTF-8, řádky jsou ukončeny znakem LF (0x0A).

Soubory může oprávněný uživatel či automat stáhnout buď pomocí webového rozhraní výběrem ze seznamu, nebo na jednotném URL:https://rnpdbm.cnpac.cz/rnpdbm/download?file_name=<jméno souboru>,kde jména souborů popisovaných v následujících kapitolách jsou odvozena od času a případně od identifikátoru mobilního operátora:

<YYYY_MM_DD_HH_MM> - je datum a čas, pro který byl soubor vytvořen,

<OHS_ID> - je identifikace operátora, pro kterého je soubor určen.

5.1[6.1] Konsolidovaný plán portacíKonsolidovaný plán portací je textový soubor, obsahující:

standardně zadané portační objednávky na následující pracovní den, mimořádně zadané portační objednávky, které byly operátory

zadány ve dnu generování, korektivní akce administrátora (storno/oprava), které byly zadány

ve dnu generování.Systém generuje zvláštní soubory pro jednotlivé mobilní operátory a zvlášť soubor pro třetí stranyostatní. Informace o poskytovateli služby na daném čísle je viditelná pouze mobilnímu operátorovi, pod kterým je poskytovatel evidován nebo pro kterého byla nastavena viditelnost poskytovatele služeb; pro ostatní operátory a třetí strany je SPID nahrazeno OPID mobilního operátora. Číslo portované mezi poskytovateli služeb jednoho mobilního operátora bude zařazeno pouze do souboru tohoto operátora a též operátora, pro kterého byla nastavena viditelnost přejímajícího poskytovatele služeb. Číslo portované mezi poskytovateli služeb jednoho mobilního operátora vypadne ze souborů pro jiné operátory a pro ostatní třetí strany.V případě, že číslo bylo součástí korektivní akce administátora, která nastala po publikaci portačního plánu, je zařazen speciální opravný záznam s operací 9.Jméno souboru: mob_portplan_<YYYY_MM_DD_HH_MM>_<OHS_ID>.csv pro MO,

resp: mob_portplan_<YYYY_MM_DD_HH_MM>.csv, pro soubor určený pro ostatní třetí strany.

Pro každé portované MSISDN nebo PABx rozsah bude v souboru jeden řádek ve následujícím formátu:

pro jednotlivé MSISDN:MSISDN;;DSPID;RSPID;OperationID;PortingDateTime

64 / 90

pro PABx rozsahy:RangeFrom;RangeTo;DSPID;RSPID;OperationID;PortingDateTime

Význam polí je následující: MSISDN – telefonní číslo MSISDN (v lokální formátu, tj. např.

602123456), RangeFrom – počáteční číslo PABx rozsahu (první číslo rozsahu,

v lokálním formátu), RangeTo – koncové číslo PABx rozsahu (poslední číslo rozsahu,

v lokálním formátu), DSPID – v souboru pro určitého mobilního operátora je to

identifikátor opouštěného poskytovatele služeb (popř. současného SP při „return“), pokud se jedná o poskytovatele služeb viditelného danému mobilnímu operátorovi (SPID); v souboru pro jiného mobilního operátora či ostatní pro třetí strany zde bude uveden identifikátor mobilního operátora přiřazeného opouštěnému poskytovateli (OpID); v případě opravy po publikaci zde bude uveden RSPID původní portační operace,

RSPID – v souboru pro určitého mobilního operátora je to identifikátor přejímajícího poskytovatele služeb (popř. vlastníka rozsahu při „return“), pokud se jedná o poskytovatele služeb viditelného danému mobilnímu operátorovi (SPID); v souboru pro jiného mobilního operátora či pro třetí stranyostatní zde bude uveden identifikátor mobilního operátora přiřazeného přejímajícímu poskytovateli (OpID),

OperationID – identifikátor operace: 1 – portace MSISDN, 2 – return MSISDN, 3 – portace PABx, 4 – return PABx, 5 – mimořádná portace MSISDN, 6 – mimořádný return MSISDN, 7 – mimořádná portace PABx, 8 – mimořádný return PABx, 9 – port revert, port fix (u oprav po publikaci),

PortingDateTime – datum a čas portace/navrácení (v ISO formátu <YYYY>-<MM>-<DD>T<hh>:<mm>:<ss>+<zzzz>, kde <zzzz> je časový posun oproti GMT včetně letního času, tj. 0100 pro zimní a 0200 pro letní čas).

5.2[6.2] Mobilní resynchronizaceMobilní resynchronizace je textový soubor, obsahující kompletní seznam všech portovaných čísel a rozsahů včetně jejich aktuálního provozovatele. Resynchronizace obsahuje pouze ta čísla, která jsou skutečně zportovaná, tzn. pokud je číslo portováno zpět či navráceno vlastíkovi rozsahu, z resynchronizace vypadne.Systém generuje zvláštní soubory pro jednotlivé mobilní operátory a zvlášť soubor pro třetí stranyostatní. Informace o poskytovateli služby na daném čísle je viditelná pouze mobilnímu operátorovi, pod kterým je poskytovatel evidován nebo pro kterého byla nastavena viditelnost poskytovatele služeb; pro ostatní operátory a třetí strany je SPID nahrazeno OPID mobilního operátora. Číslo portované k poskytovateli služeb mobilního operátora, který je vlastníkem rozsahu, vypadne ze

65 / 90

souborů pro jiné mobilní operátory a pro ostatníjiné operátory a pro třetí strany.Platnost resynchronizace je dána dnem, pro který je vygenerována.Jméno souboru: mob_resync_<YYYY_MM_DD_HH_MM>_< OHS_ID>.csv pro MO,

resp: mob_resync_<YYYY_MM_DD_HH_MM>.csv, pro třetí stranyostatní.

Pro každé portované MSISDN nebo PABx rozsah bude v souboru jeden řádek, ve následujícím formátu:

pro jednotlivé MSISDN:MSISDN;;RSPID;ValidFrom

pro PABx rozsahy:RangeFrom;RangeTo;RSPID;ValidFrom

Význam jednotlivých polí je následující: MSISDN – telefonní číslo MSISDN (v lokální formátu, tj. např.

602123456) RangeFrom – počáteční číslo PABx rozsahu (první číslo rozsahu,

v lokální formátu) RangeTo – koncové číslo PABx rozsahu (poslední číslo rozsahu,

v lokální formátu) RSPID – v souboru pro určitého mobilního operátora je to

identifikátor aktuálního poskytovatele služeb přidělený mobilním operátorem, pokud se jedná o poskytovatele služeb viditelného danému mobilnímu operátorovi (SPID); v souboru pro jiného mobilního operátora či pro třetí stranyostatní zde bude místo toho uveden identifikátor mobilního operátora přiřazeného aktuálnímu poskytovateli služeb (OpID),

ValidFrom – datum a čas poslední portace, tzn. doba, od které tento záznam platí (v ISO formátu <YYYY>-<MM>-<DD>T<hh>:<mm>:<ss>+<zzzz>, kde <zzzz> je časový posun oproti GMT včetně letního času, tj. 0100 pro zimní a 0200 pro letní čas).

5.3[6.3] Tabulka přiřazení SPID k OpIDSoubor s tabulkou přiřazení SPID a OpID obsahuje soupis všech SPID a údaj o jejich přiřazeném OpID k okamžiku generování souboru. Soubor bude obsahovat i implicitní přiřazení SPID mobilního operátora, které je shodné s OpID.Jméno souboru: mob_spid_table_<YYYY_MM_DD_HH_MM>.csvPro každé SPID bude v souboru jeden řádek, v následujícím formátu:SPID;OpID;IMSIprefix;OHSID;SPName

Význam jednotlivých polí je následující: SPID – identifikátor poskytovatele služeb, OpID – identifikátor mobilního operátora, v jehož síti poskytovatel

poskytuje služby, IMSIprefix – identifikátor sítě kód MCC+MMC, OHSID – identifikátor OHS mobilního operátora, v jehož síti

poskytovatel poskytuje služby, SPName – jméno poskytovatele služeb.

66 / 90

5.4[6.4] Mobilní číslovací plányMobilní číslovací plán je soubor obsahující data o vlastnících mobilních rozsahů platná k okamžiku generování souboru. Obsahuje data přebíraná z RDČ obohacená o příznak, zda je na daný rozsah provozován jiným poskytovatelem služeb či obsahuje portovaná čísla (s takovými rozsahy nelze provádět určité operace).Systém generuje na požádání zvláštní soubory pro jednotlivé mobilní operátory (obsahující výjimky viditelné danému operátorovi) a zvlášť soubor pouze s OpID: číslovací plán dle SPID pro MO,

obsahuje všechny aktivní rozsahy operátorem přidělené jak sobě jako poskytovateli služby, tak i ostatním poskytovatelům v jeho síti nebo jemu viditelné.Jméno souboru: mob_numbering_plan_<YYYY_MM_DD_HH_MM>_< OHS_ID>.csvPro každý rozsah bude v souboru jeden řádek, v následujícím formátu:RangeFrom;RangeTo;OpID;SPID;ValidFrom;Managed

číslovací plán dle OpIDobsahuje všechny aktivní rozsahy přidělené některému z mobilních operátorů.Jméno souboru: mob_numbering_plan_<YYYY_MM_DD_HH_MM>.csvPro každý rozsah bude v souboru jeden řádek, v následujícím formátu:RangeFrom;RangeTo;OpID;ValidFrom;Managed

Význam jednotlivých polí je následující: RangeFrom, RangeTo – počátek a konec rozsahu MSISDN (v lokální

formátu, tj. např. 602123456), OpID – identifikátor mobilního operátora, kterému je rozsah

přiřazen, SPID – identifikátor poskytovatele služeb, kterému je rozsah

přiřazen, ValidFrom – datum a čas od kdy tento záznam platí (v ISO formátu

<YYYY>-<MM>-<DD>T<hh>:<mm>:<ss>+<zzzz>, kde <zzzz> je časový posun oproti GMT včetně letního času, tj. 0100 pro zimní a 0200 pro letní čas),

Managed – rozsah obsahuje portovaná čísla nebo je provozován jiný poskytovatelem služeb (Y/N).

5.5[6.5] Fixní resynchronizaceFixní resynchronizace je soubor primárně poskytovaný Referenční databází portovaných čísel v pevných sítích (RNPDB-F). RNPDB-M tento soubor přebírá a formátuje do tvaru shodného s mobilní resynchronizací..Jméno souboru: fix_resync_<YYYY_MM_DD_HH_MM>.csvPro každé portované telefonní číslo nebo PABx rozsah bude v souboru jeden řádek, ve následujícím formátu:

pro jednotlivé telefonní číslo:MSISDN;;CNO;ValidFrom

pro PABx rozsahy:RangeFrom;RangeTo;CNO;ValidFrom

67 / 90

Význam jednotlivých polí je následující: MSISDN – telefonní číslo MSISDN (v lokální formátu, tj. např.

602123456) RangeFrom – počáteční číslo PABx rozsahu (první číslo rozsahu,

v lokální formátu) RangeTo – koncové číslo PABx rozsahu (poslední číslo rozsahu,

v lokální formátu) CNO – identifikátor aktuálního fixního operátora (OpID), ValidFrom – datum a čas poslední portace, tzn. doba, od které tento

záznam platí (v ISO formátu <YYYY>-<MM>-<DD>T<hh>:<mm>:<ss>+<zzzz>, kde <zzzz> je časový posun oproti GMT včetně letního času, tj. 0100 pro zimní a 0200 pro letní čas).

68 / 90

6.[7.] Reporty a statistikyAplikace umožňuje vytvářet níže uvedené on-line a offline generované reporty. Ty jsou generovány na základě vstupních kritérií s možností uložení výstupu ve formátu CSV, u dlouhotrvajících reportů, resp. u reportů, které produkují obsáhlé soubory s možností následného stažení offline.Aplikace bude umožňovat vytvářet tyto reporty:

report počtu všech zpráv vůči jednotlivým operátorům za určené období,

report počtu všech portací vůči jednotlivým operátorům za určené období,

report čerpání kvót dotazovacího rozhraní, report výpisu všech portací za určené období pro jednoho operátora

(offline), report detailního výpisu všech portací za určené období pro jednoho

operátora (offline), report využití čísel pro jednoho operátora (offline), reporty vytížení částí systému (CPU, paměť, disk, síť) za určené

časovém období.Offline reporty budou zpracovány podle potřeby případně až v hodinách, kdy systém není zatížen úlohami s vyšší důležitostí a prioritní odezvou jako je vyřizování zpráv, zpracování portačních objednávek nebo vytváření výstupních souborů. Výsledky offline reportů budou k dispozici ke stažení na zvláštní stránce, kde lze sledovat i stav zpracování a další informace o zadaných offline reportů. Výsledek zpracovaného offline reportu může získat kdokoli s oprávněním k rozhraní „Spuštění dlouhotrvajících reportů“ od stejného operátora. Administrátor má přístup ke všem vygenerovaným offline reportům.Všechny reporty, které obsahují informace o poskytovatelích připojení (SPID), jsou připraveny pro konkrétního mobilního operátora a jsou aplikována pravidla viditelnosti SPID platná pro mobilního operátora, který si report vyžádal. V případě administrátora lze před zadáním reportu ke zpracování vybrat, pro kterého MO report bude připraven.Jméno souboru je odvozeno od zadaného časového období a u reportů, kde dochází k anonymizaci informací o cizích SPID i dle OHS ID operátora, pro kterého je report připraven:

<YYYY_MM_DD>_<YYYY_MM_DD> - období, pro které byl report vytvořen.

<OHS_ID> - je identifikace operátora, pro kterého je soubor určen.

6.1[7.1] Report počtu zprávReport počtu zpráv vytvoří statistiku komunikace RNPDB-M s jednotlivými OHS.Vstupní parametry:

datum od – do: časové období, ve kterém došlo k přijetí/odeslání zprávy.

Výstup:

69 / 90

Report obsahuje seznam všech subjektů v roli mobilní operátor a pro každý řádek statistiku počtu zpráv vůči tomuto operátorovi. Jsou započítány všechny zprávy včetně opakovaných pokusů o doručení, vstupní zprávy obsahující opakované a opravné objednávky včetně objednávek mimořádných. Objednávky portací vzniklé na základě validních zpráv typu PortingOrderPublishCRDB a ReturnNumberPublishCRDB jsou ve zvláštním sloupci.Report je seřazen dle OHS ID mobilních operátorů.

Jméno souboru:report_msg_stats_<YYYY_MM_DD>_<YYYY_MM_DD>.csv

Struktura záznamu:OHSId;OperatorName;MsgInCount;MsgOutCount;MsgReplyOutCount;MsgReplyInC

ount;ValidOrderCount

kde: OHSId – OHS ID mobilního operátora, OperatorName – jméno mobilního operátora, MsgInCount – počet přijatých zpráv od mobilního operátora, MsgOutCount – počet odeslaných zpráv pro mobilního operátora, MsgReplyOutCount – počet odeslaných odpovědí na přijaté zprávy

pro MO, MsgReplyInCount – počet přijatých odpovědí na odeslané zprávy od

MO, ValidOrderCount – počet platných portačních plánů

(PortIn+PortOut) v přijatých zprávách.

6.2[7.2] Report počtu portacíReport počtu portací vytvoří statistiku portačních objednávek pro jednotlivé mobilní operátory.Vstupní parametry:

datum od – do: časové období, ve kterém došlo k portaci či návratu čísla.

Výstup:Report obsahuje seznam všech subjektů v roli mobilní operátor a pro každý řádek statistiku počtu portací a navrácení čísel (viz níže) v daném období pro všechny OpID tohoto mobilního operátora. Portace zpět k vlastníkovi rozsahu jsou počítány jako prosté portace. Report je seřazen dle OHS ID mobilních operátorů.

Jméno souboru:report_port_stats_<YYYY_MM_DD>_<YYYY_MM_DD>.csv

Struktura záznamu:OHSId;OperatorName;PortInCount;PortOutCount;ReturnInCount;ReturnOutCount

70 / 90

kde: OHSId – OHS ID mobilního operátora, OperatorName – jméno mobilního operátora, PortOutCount – počet čísel (příp. rozsahů) portovaných k jinému

operátorovi, PortInCount – počet čísel (příp. rozsahů) portovaných od jiného

operátora, ReturnOutCount – počet čísel (příp. rozsahů) vrácených jinému

operátorovi, ReturnInCount – počet čísel (příp. rozsahů) vrácených od jiného

operátora.

6.3[7.3] Report čerpání kvót dotazovacího rozhraníReport čerpání kvót vytvoří statistiku dotazů do dotazovacího rozhraní pro jednotlivé subjekty.Vstupní parametry:

datum od – do: časové období, ve kterém byl dotaz proveden.Výstup:

Report obsahuje seznam všech subjektů a pro každého statistiku počtu dotazů provedených v daném období. Report je seřazen dle názvu subjektů.

Jméno souboru:report_qi_stats_<YYYY_MM_DD>_<YYYY_MM_DD>.csv

Struktura záznamu:SubjectName;SimpleQueryCount;BulkQueryCount;BulkNumbersCount

kde: SubjectName – jméno subjektu, SimpleQueryCount – počet jednoduchých dotazů na umístění čísla, BulkQueryCount – počet hromadných dotazů na umístění čísla, BulkNumbersCount – počet čísel v hromadných dotazech na umístění

čísla.

6.4 Report výpisu portacíReport výpisu portací vytvoří seznam platných portačních objednávek pro určeného mobilního operátora a vypíše základní detaily o portaci.Vstupní parametry:

datum od – do: časové období, ve kterém došlo k portaci či návratu čísla,

operátor (pouze pro Administrátora): OHS ID opouštěného či přejímajícího operátora.

Výstup:Report obsahuje seznam všech portačních objednávek pro zadané

období, ve kterých figuruje některý z OpIDů určeného mobilního operátora buď v pozici opouštěného či přejímajícího operátora. Jsou zahrnuty všechny platné portační operace (tj. portace čísla, zpětná portace čísla a návrat čísla)

71 / 90

Report je seřazen dle data portace, PAC a telefonních čísel.Jméno souboru:

report_port_list_<YYYY_MM_DD>_<YYYY_MM_DD>_<OHSID>.csvStruktura záznamu:

pro jednotlivé MSISDN:MSISDN;;PACId;Operation;NumMSISDNinPAC;PortingDate;OrderCreationDate;DO

pID;ROpID;DSPID;RSPID;RHOpID;RHSPID;Active;GUI pro PABx rozsahy:

RangeFrom;RangeTo;…

kde: MSISDN – telefonní číslo MSISDN (v lokální formátu, tj. např.

602123456), RangeFrom – počátek portovaného rozsahu (viz MSISDN), RangeTo – konec portovaného rozsahu (viz MSISDN), PACId – PAC, Operation – operace (‘P’ – portace, ‘B’ – zpětná portace, ‘R’ –

návrat), NumMSISDNinPAC – počet telefonních čísel ke stejnému PACId, PortingDate – datum a čas portace (v ISO formátu <YYYY>-<MM>-

<DD>T<hh>:<mm>:<ss>+<zzzz>), OrderCreationDate – datum vytvoření konsolidované objednávky, DOpID – OpID opouštěného operátora, ROpID – OpID přejímajícího operátora, DSPID – SPID opouštěného poskytovatele služeb, pokud má být

mobilnímu operátorovi viditelný; pro jiného mobilního operátora OpID, kde je SP přiřazen,

RSPID – SPID přejímajícího poskytovatele služeb, pokud má být mobilnímu operátorovi viditelný; pro jiného mobilního operátora OpID, kde je SP přiřazen,

RHOpID – OpID vlastníka rozsahu, RHSPID – SPID vlastníka rozsahu, pokud je číslo v rozsahu

přiděleném SP a pokud má být mobilnímu operátorovi viditelný; pro jiného mobilního operátora OpID, kde je SP přiřazen

Active – indikace (‚Y‘/‘N‘), že číslo je ke konci zadaného období stále portované (tj. není dosud vráceno nebo portováno zpět, nebo bylo vráceno nebo portováno zpět až po skončení zadaného období); pro operace zpětné portace a návratu čísla vždy ‘N’,

GUI – indikace (‘G’), že alespoň 1 portační objednávka tohoto PAC byla zadána ručně přes GUI (pokud jsou takové informace k dispozici v DB a nebyly dosud přesunuty do archivu).

6.5[7.4] Report detailního výpisu portacíReport detailního výpisu portací vytvoří seznam portačních objednávek pro určeného mobilního operátora a doplní další převážně časové informace popisující proces zadání portační objednávky.Vstupní parametry:

72 / 90

datum od – do: časové období, ve kterém došlo k portaci či návratu čísla,

operátor (pouze pro Administrátora): OHS ID opouštěného či přejímajícího operátor.

Výstup:Report obsahuje seznam všech portačních objednávek pro zadané

období, ve kterých figuruje některý z OpIDů určeného mobilního operátora buď na straně opouštěného či přejímajícího operátora. Jsou zahrnuty všechny platné portační operace (tj. portace čísla, zpětná portace čísla a návrat čísla)

Report je seřazen dle data portace, PAC a telefonních čísel.Jméno souboru:

report_port_list_detail_<YYYY_MM_DD>_<YYYY_MM_DD>_< OHS_ID>.csvStruktura záznamu:

pro jednotlivé MSISDN:MSISDN;;PACId;Operation;NumMSISDNinPAC;PortingDate;OrderCreationDate;DO

pID;ROpID;DSPID;RSPID;RHOpID;RHSPID;DMessageDate;RMessageDate;DExMessageDate;RExMessageDate

pro PABx rozsahy:RangeFrom;RangeTo;PACId;…


602123456), RangeFrom – počátek portovaného rozsahu (viz MSISDN), RangeTo – konec portovaného rozsahu (viz MSISDN), PACId – PAC, Operation – operace (‘P’ – portace, ‘B’ – zpětná portace, ‘R’ –

návrat), NumMSISDNinPAC – počet telefonních čísel ke stejnému PACId, PortingDate – datum a čas portace (v ISO formátu <YYYY>-<MM>-

<DD>T<hh>:<mm>:<ss>+<zzzz>), OrderCreationDate – datum vytvoření konsolidované objednávky, DOpID – OpID opouštěného operátora, ROpID – OpID přejímajícího operátora, DSPID – SPID opouštěného poskytovatele služeb, , pokud má být


RSPID – SPID přejímajícího poskytovatele služeb, , pokud má být mobilnímu operátorovi viditelný; pro jiného mobilního operátora OpID, kde je SP přiřazen,


přiděleném SP, a pokud má být mobilnímu operátorovi viditelný; pro jiného mobilního operátoraostatní OpID, kde je SP přiřazen

DMessageDate – datum a čas podání zprávy s řádným portačním plánem opouštěným operátorem, přesněji datum úspěšného doručení asynchronní odpovědi zpět operátorovi; v případě většího počtu takových zpráv je to čas první zprávy,

RMessageDate – datum a čas podání zprávy s řádným portačním plánem přejímajícím operátorem, přesněji datum úspěšného

73 / 90

doručení asynchronní odpovědi zpět operátorovi; v případě většího počtu takových zpráv je to čas první zprávy,

DExMessageDate – datum a čas podání zprávy s mimořádným portačním plánem opouštěným operátorem, přesněji datum úspěšného doručení asynchronní odpovědi zpět operátorovi; v případě většího počtu takových zpráv je to čas poslední zprávy,

RExMessageDate – datum a čas podání zprávy s řádným portačním plánem přejímajícím operátorem, přesněji datum úspěšného doručení asynchronní odpovědi zpět operátorovi; v případě většího počtu takových zpráv je to čas poslední zprávy.

6.6[7.5] Report využití číselReport využití čísla vytvoří seznam portovaných čísel v zadaném období a dohledá další informace o nich, které popisují portační cyklus daného čísla a dobu strávenou v portovaném stavu.Vstupní parametry:

datum od – do: časové období, ve kterém musí být číslo portované, aby bylo číslo zahrnuto do reportu. Tj. bylo portováno před začátkem období a případně vráceno po začátku období, nebo portováno v průběhu zadaného časového období.

operátor (pouze pro Administrátora): opouštěný či přejímající operátor.

Výstup:Report obsahuje seznam všech telefonních čísel (a rozsahů čísel),

která byla v zadaném období portována u jiného operátora než u vlastníka rozsahu. Report zahrnuje pouze platné portace k okamžiku generování, tzn., že nejsou zahrnuty portace stornované administrátorem, ani původní záznamy následně opravené administrátorem. Pro každé telefonní číslo jsou dohledány další informace o portaci, následné portaci či návratu (viz níže).Pokud bylo telefonní číslo v zadaném období portováno u více než jednoho operátora příp. poskytovatele služeb, bude report obsahovat příslušný počet záznamů tohoto čísla.Report je seřazen dle telefonních čísel a data portace.Jméno souboru:

report_number_usage_<YYYY_MM_DD>_<YYYY_MM_DD>_<OHS_ID>.csvStruktura záznamu:

pro jednotlivá MSISDN:MSISDN;;PACId;Operation;NumMSISDNinPAC;PortingDate;OrderCreationDate;

DOpID;ROpID;DSPID;RSPID;RHOpID;RHSPID;NextPortingDate;NextReturnDate;DaysPorted

pro PABx rozsahy:RangeFrom;RangeTo;…


602123456), RangeFrom – počátek portovaného rozsahu (viz MSISDN), RangeTo – konec portovaného rozsahu (viz MSISDN), PACId – PAC,

74 / 90

Operation – operace (‘P’ – portace, ‘B’ – zpětná portace, ‘R’ – návrat),

NumMSISDNinPAC – počet telefonních čísel ke stejnému PACId, PortingDate – datum a čas portace (v ISO formátu <YYYY>-<MM>-

<DD>T<hh>:<mm>:<ss>+<zzzz>), OrderCreationDate – datum vytvoření konsolidované objednávky, DOpID – OpID opouštěného operátora, ROpID – OpID přejímajícího operátora, DSPID – SPID opouštěného poskytovatele služeb, pokud má být


RSPID – SPID přejímajícího poskytovatele služeb, pokud má být mobilnímu operátorovi viditelný; pro jiného mobilního operátora OpID, kde je SP přiřazen,


přiděleném SP a pokud má být mobilnímu operátorovi viditelný; pro jiného mobilního operátora OpID, kde je SP přiřazen

NextPortingDate – datum a čas následné portace (v ISO formátu <YYYY>-<MM>-<DD>T<hh>:<mm>:<ss>+<zzzz>),

NextReturnDate – datum a čas vrácení čísla (v ISO formátu <YYYY>-<MM>-<DD>T<hh>:<mm>:<ss>+<zzzz>),

DaysPorted – počet dní, po které bylo číslo portováno u ROpID (příp. RSPID).

6.7[7.6] Reporty vytížení částí systémuReporty vytížení systému je sada reportů popisující využití jednotlivých počítačových komponent a rozhraní.

využití CPU, využití paměti, využití I/O, využití diskových svazků využítí síťových rozhraní

Jednotlivé ukazatele jsou získávány v nezměněné podobě z nástroje SAR a detailní význam jednotlivých polí a jejich použití lze vyčíst z dokumentace tohoto nástroje. Všechny reporty mají tuto společnou částHostname;Timestamp;Interval; …

Hostname – jméno počítače (uzlu), ze kterého měření pochází, Timestamp – datum a čas pořízení časového snímku, Interval – délka časového snímku; přibližně odpovídá intervalu mezi

časovými snímky, ale nemusí to být pravidlem, … – další údaje viz dokumentace k SAR.

75 / 90

7.[8.] Vazby na další systémySystém RNPDB-M NG bude komunikovat s těmito dalšími interními a externími systémy:

Stávající RNPDB-M, RNPDB-F (včetně RDČ), geo backup, archivace.

cmp Interní systémy

RNPDB-M NG

RNPDB-M (stávaj ící)

RNPDB-F

fixní resynchronizace

«NFS»

fixní resynchronizace

«NFS»

číslovací plán

«JMS»info o využití rozsahu

«JMS»

proxy

«AJP

» portační plány

«NFS

»

výstupní soubory

«NFS

»Obrázek 16: Vazby interních systémů

7.1[8.1] Stávající RNPDB-MPřed zahájením produkčního provozu a po dobu souběžného provozu budou ze stávající RNPDB-M migrována data o portačních objednávkách zadaných před 1. 9. 2013.Portační objednávky zadané před 1. 9. 2013 budou zpracovány ve stávajícím systému RNPDB-M a uzavřené budou průběžně přenášeny do RNPDB-M NG. Detaily tohoto procesu viz kapitola 9.2.1.Výstupní soubory vytvářené na RNPDB-M NG budou průběžně přenášeny zpět na stávající prostředí. Detaily tohoto procesu viz kapitola 9.2.2.

7.1.1[8.1.1] Nutné úpravy stávající RNPDB-MVe stávající aplikaci RNPDB-M se nepředpokládají změny, které by znamenaly testování a nasazení nové verze aplikace. Změny, které budou provedeny na stávajícím, prostředí budou administrativního charakteru.

založení nové pravidelné exportní úlohy (viz níže).Vzhledem k tomu, že soubor konsolidovaných portačních plánů neobsahuje všechny údaje potřebné v novém systému (především soubor neobsahuje PAC), bude nutné vytvořit na stávajícím RNPDB-M automatizovanou exportní úlohu, která bude procházet tabulku konsolidovaných portačních plánů, ze které bude vybírat nově vytvořené

76 / 90

záznamy a změněné záznamy. Rozlišení nových a změněných záznamů úloha provede podle časových razítek, které tato tabulka již obsahuje. Tato úloha bude naplánována tak, aby následovala po skončení úlohy konsolidace portačních plánů.

7.2[8.2] RNPDB-F (včetně RDČ)RNPDB-M NG bude využívat služeb Centrální databáze přenesených čísel fixních operátorů (RNPDB-F) a Referenční databáze čísel (RDČ), která je provozována v rámci RNPDB-F takto:

přebírání fixní resynchronizace z RNPDB-F, za účelem konverze formátu,

přebírání číslovacího plánu z RDČ, za účelem validace vlastníka rozsahu u portačních plánů,

předávání informace o využití rozsahu v RNPDB-M NG zpět do RDČ, za účelem zamezení konfliktního nakládání s rozsahem v RDČ.

RNPDB-M NG bude pravidelně přebírat soubor fixní resynchronizace z RNPDB-F a transformovat jej do podoby odpovídající mobilní resynchronizaci (viz kapitola 6.5).Ze systému RNPDB-F (část RDČ) bude provedena úvodní inicializace číslovacího plánu RNPDB-M NG (viz kapitola 9.1.2) a též jeho průběžná synchronizace oběma směry (viz kapitola 3.7.2).

7.2.1[8.2.1] Nutné úpravy RDČSystém RNPDB-F (především jeho RDČ část) bude rozšířen o mechanizmy nutné pro on-line synchronizaci číslovacího plánu s RNPDB-M NG. Jejich součástí bude zavedení příznaku EM (Externally Managed) k záznamům o přidělených rozsazích, který bude indikovat, že na uvedeném rozsahu je mimo systém RDČ navázaná informace, která brání plnému nakládání s rozsahem v RDČ. Aby mohlo být v RDČ s rozsahem nakládáno, musí být nejprve vázaná informace zrušena a EM příznak uvolněn.Změny v RNPDB-F jsou shrnuty v následujících bodech:

rozšíření tabulky přidělených rozsahů o EM příznak a jeho inicializace,

rozšíření validací RDČ operací o test EM příznaku, vytvoření mechanismu zachycení změn přidělených rozsahů a jejich

odesílání do RNPDB-M NG, vystavení rozhraní pro zpětnou aktualizaci EM příznaku., nová funkce „Vynucení RDČ exportu“ přístupná pouze

administrátorovi, která bude způsobem, popsaným v kapitole 3.7.2 iniciovat plnou synchronizaci RDČ do RNPDB-M NG.

Výše uvedené úpravy budou provedeny tak, aby vliv na portační proces pevných čísel z pohledu fixních operátorů byl nepozorovatelný.Pro zajištění správného fungování centrálních aplikací pro správu portací mobilních i fixních čísel je nezbytné, aby nasazení verze RNPDB-F s implementovanými výše popsanými změnami proběhlo paralelně a v součinnosti s nasazením RNPDB-M NG.

77 / 90

[8.3] Geo backupZásadní data a nastavení aplikace a operačního systému budou pravidelně přenášena do sekundární lokality a uschovávána pro případ zničení či jiné ztráty dat v primární lokalitě.Budou využity stávající zálohovací a přenosové mechanizmy použité u dalších aplikací provozovaných CNPAC, které budou rozšířeny o nové prostředí RNPDB-M NG.Pro přenos dat do záložní lokality se používá šifrovaná komunikace na bázi SSH a RSYNC protokolů. Vlastní přenos probíhá v mimoprovozních hodinách.

[8.4] ArchivaceData určená k archivaci budou exportována do souborů, odstraněna z databáze a souborového systému a přenesena do sekundární lokality, kde budou skladována a zálohována. Jedná se o historické soubory konsolidovaných portačních plánů, resynchronizace a systémových logů, dále o záznamy v databázi jako jsou historické a aplikační zprávy starší 15 měsíců. V systému zůstává kompletní databáze portovaných čísel, která archivaci nepodléhá.Přípravu dat pro archivaci provádí v režii Administrátora pravidelně systém RNPDB-M NG, přenos do sekundární lokality je následně prováděn zabezpečeným kanálem automatizovanými úlohami. Celý proces bude spouštěn jednou měsíčně mimo provozní dobu aplikace.

78 / 90

8.[9.] Inicializace, migrace dat a souběžný provoz

8.1[9.1] Úvodní naplnění databáze8.1.1[9.1.1] Migrace dat z původní RNPDB-MÚvodní migrace dat ze stávajícího řešení proběhne manuálně v mimoprovozních hodinách dne 31. 8. 2013. Pokud budou v tomto produkčním prostředí data, pocházející z předchozího testovacího provozu proběhne jejich smazání. Předpokládáme, že migraci budeme realizovat do prázdné databáze.Předmětem migrace bude:

seznam subjektů (operátorů), konsolidované portační plány

Předmětem migrace nebude: subjekty typu fixní operátor a 3. stranaúřad a jejich uživatelé, uživatelé subjektů typu mobilní operátor kromě automatů, portační plány publikované operátory (budou přesunuty do archivu), příchozí a odchozí zprávy a odpovědi (budou přesunuty do archivu), historické výstupní soubory (budou přesunuty do archivu), číslovací plán (bude nahrazen novým přebíraným z RDČ), opravná pravidla fixní resynchronizace (nepoužívají se).

V důsledku dosavadní oddělené správy číslovacího rozsahu nezávislé na správě rozsahů v RDČ, existují portace, které předcházejí datum aktivace příslušného aktivního rozsahu v RDČ. U takových portací nelze definovat vlastníka rozsahu (NRH) k okamžiku portace.

8.1.2[9.1.2] Inicializace číslovacího plánuInicializace číslovacího plánu proběhne jednorázově. Proces se zaměří výhradně na data, relevantní pro mobilní operátory. Další změny budou do RNPDB-M přenášeny průběžně a inkrementálně tak, jak je popsáno v kapitole 3.7.2.

8.1.3[9.1.3] Nahrání portací se SP z doby před zahájením provozuPortace s poskytovateli služeb, které operátoři zaznamenali před uvedením aplikace RNPDB-M NG do provozu, budou ručně dávkově a opakovaně nahrány do centrální databáze.Operátoři zašlou administrátorovi systému seznam takových portačních objednávek pro úvodní migraci dat a dále dle potřeby přírůstky v průběhu souběžného provozu v případě dokončení relevantní portace ve stávajícím systému nebo na pravidelné bázi.Administrátor provede nahrání souboru během úvodní migrace dat a na konci souběžného provozu. V průběhu souběžného provozu bude docházet k publikaci neúplných údajů v konsolidovaném portačním plánu a v resynchronizačním souboru pro dobíhající portace s SP.Soubory v této kapitole jsou jednotné CSV soubory s hlavičkou (viz kap 6).Formát souboru portačních objednávek (porting_plan_<OHSID>.csv):

PACId;MSISDN;DOpID;ROpID;DSPID;RSPID;PortingDateTime

79 / 90

Význam polí je následující: PACId – PAC ID portační objednávky, které se záznam týká MSISDN – telefonní číslo MSISDN (v lokální formátu, tj. např.

602123456) DOpID – identifikátor opouštěného mobilního operátora ROpID – identifikátor přejímajícího mobilního operátora DSPID – identifikátor opouštěného poskytovatele služeb (doplní

opouštěný MO) RSPID – identifikátor přejímajícího poskytovatele služeb (doplní

přejímající MO) PortingDateTime – datum a čas portace/navrácení (v ISO formátu

<YYYY>-<MM>-<DD>T<hh>:<mm>:<ss>+<zzzz>, kde <zzzz> je časový posun oproti GMT včetně letního času, tj. 0100 pro zimní a 0200 pro letní čas).

Soubor obsahuje pouze záznamy obsahující portace (vracení čísel není podporováno), kde proces portace započal před 1. 9. 2013 a nemohly být kompletně publikovány stávajícím portačním procesem, neboť se týkají poskytovatelů služeb. Soubor může obsahovat záznamy pro více portačních dní.Rozeznáváme tyto situace:a) V případě, kdy došlo k portaci mezi různými MO tj.:

1. mezi mobilním operátorem a poskytovatelem služeb jiného MO nebo,2. k portaci mezi poskytovateli služeb různých mobilních operátorů,

je tato portace evidována stávajícím systémem jako portace mezi mobilními operátory. Taková portace bude součástí migrace dat z původního systému RNPDB-M (viz kap. 9.1.1), avšak SPID poskytovatele služeb v systému u portace chybí.

b) V případě, kdy došlo k portaci v rámci jednoho MO tj.:1. mezi mobilním operátorem a poskytovatelem služeb v jeho síti nebo,2. mezi poskytovateli služeb v rámci jednoho mobilního operátora,

portace není evidována, není součástí migrace dat z původního systému a v systému chybí celá. Mobilní operátor musí přidělit jedinečné PAC ID pro tuto portaci.

Zpracování dávky od operátora musí zohlednit všechny tyto situace:a) Pokud skript nalezne uvedené PAC ID (situace a), dohledá portaci

daného čísla/rozsahu v konsolidovaném plánu portací, a provede doplnění SPID opouštěného resp. přejímajícího poskytovatele služeb podle údajů v souboru. V situaci a2) systém dostane informaci o opouštěném a přejímajícím poskytovateli ve dvou dávkách od obou mobilních operátorů. DSPID bude vyplněn v dávce od opouštěného mobilního operátora a RSPID bude vyplněn v dávce od přejímajícího mobilního operátora.

b) Pokud skript uvedené PAC ID nenalezne (situace b), vytvoří nový záznam v konsolidovaném plánu portací.

Prerekvizitou zpracování souborů s portacemi je založení poskytovatele služeb v RNPDB-M NG a rozsahů, které jsou poskytovateli přiděleny. Tyto soubory je nutné doručit před zahájením migrace dat. Soubory budou administrátorem manuálně zkontrolovány na formální správnost.Formát souboru poskytovatelů služeb (service_provider_<OHSID>.csv):

SPID;OpID;SPName

80 / 90

Formát souboru rozsahů přidělených poskytovatelům služeb (assigned_number_sp_<OHSID>.csv):

RangeStart;RangeEnd;SPID;EffectiveDateTime

Význam polí je následující: SPID – identifikátor poskytovatele služeb, OpID – identifikátor mobilního operátora, SPName – jméno poskytovatele služeb, RangeStart – počátek přiděleného rozsahu, RangeEnd – konec přiděleného rozsahu. EffectiveDateTime – datum a čas počátku platnosti rozsahu (v ISO

formátu <YYYY>-<MM>-<DD>T<hh>:<mm>:<ss>+<zzzz>, kde <zzzz> je časový posun oproti GMT včetně letního času, tj. 0100 pro zimní a 0200 pro letní čas). Musí být pozdější než počátek platnosti nadrozsahu a dřívější než datum první portace v daném rozsahu.

Pozn: Pokud nelze zajistit časovou podmínku u EffectiveDateTime je nutné zvolit datum EffectiveDateTime alespoň pozdější než počátek platnosti nadrozsahu. V takovém případě nebude možné určit vlastníka rozsahu (NRH SPID) k datu portace.

81 / 90

8.2[9.2] Souběžný provozV době od 1. 9. 2013 do 2. 11. 2013 bude souběžně pracovat stávající i nové řešení RNPDB-M. Po dobu souběžného provozu bude na každodenní bázi zajištěn přenos uzavřených portačních objednávek ze stávajícího do nového řešení.

8.2.1[9.2.1] Přenos dat ze stávajícího na nové prostředíZa tímto účelem bude vytvořena nová exportní úloha, která bude spouštěna na stávajícím prostředí mimo provozní hodiny tak, aby navazovala na konsolidaci portačních plánů. Následně bude exportní soubor přenesen na nové prostředí a importován do databáze RNPDB-M NG. Vzhledem k delším časovým lhůtám ve stávajícím prostředí, se tímto portační plán ze starého prostředí dostane do nového prostředí ještě před dnem portace a bude publikován spolu s novými portacemi následující den i v novém prostředí. V den před portací může administrátor provést nahrání souborů portací se SP, pokud mu byly doručeny.

8.2.2[9.2.2] Zpětný přenos dat z nového na stávající prostředíVýstupní soubory konsolidovaného mobilního portačního plánu a mobilní resynchronizace pro 3. osoby bude vždy po vytvoření na RNPDB-M NG přenesen na stávající prostředí a nahradí soubory stejného data. Při přenosu bude:

změněn název souboru, odstraněna hlavička, změněny konce řádek na CRLF (0x0A,0x0D), původní soubor bude odložen stranou.

Stávající prostředí v DP-2 v 22:00 vytvoří soubory pro datum portace DP, které ovšem v zápětí skryje, aby nebyly předčasně staženy. Následně v DP-1 v 18:00 nové prostředí soubor nahradí souborem, který již obsahuje portace podle nového procesu. Původní i nové soubory budou dostupné ke stažení přes GUI stávající RNPDB-M.Je nutné zajistit na straně konzumentů těchto souborů, že ke stahování souborů ze stávajícího prostředí nebude docházet dříve než v DP-1 v 18:00.

8.2.3[9.2.3] Režim stávajícího systému RNPDB-MPředpokládáme, že od 1. 9. 2013 budou všichni operátoři zadávat objednávky do nově vytvořeného systému RNPDBM-NG. Stávající aplikace bude od toho okamžiku pracovat v normálním režimu, kdy se ale nepředpokládá zadávání nových dat, ale jen doběhnutí objednávek, jejichž proces započal v době před 1. 9. 2013. Stávající RNPDB-M aplikace nemá žádné prostředky pro kontrolu, že zaslaná objednávka se váže k procesu podle starého či nového OOP. Rozhodnutí, zda portační objednávka bude zaslána do stávajícího či nového prostředí leží na zadávajících operátorech.

82 / 90

Stávajícím systém RNPDB-M bude do cca 2. 11. 2013 ponechán v provozu v plném rozsahu tj. včetně těchto funkcí:

přijímání zpráv od operátorů, odesílání zpráv směrem k operátorům, možnost stahovat výstupní soubory, webové rozhraní, zálohování a archivace.

Generování výstupních souborů (mobilních portačních plánů a mobilní resynchronizace) bude nahrazeno zpětným přenosem výstupních souborů z RNPDB-M NG viz kapitola 9.2.2, Generování (přebírání) fixní resynchronizace na stávajícím prostředí bude zastaveno z důvodů změn v časování portačního procesu v RNPDB-F.

8.2.4[9.2.4] Náběh zatížení nového systémuOperátoři zajistí pozvolný náběh zatížení nového systému RNPDB-M NG podle tohoto harmonogramu:Týden zatížení (port-in/out)1. týden 200/200

objednávek/denně2. týden 500/500

objednávek/denně3. týden 800/800

objednávek/denně4. - 7. týden 1000/1000

objednávek/denněod 8. týdne plná kapacita

K celkovému vypnutí staré aplikace dojde 2. 11. 2013. Od tohoto okamžiku bude v provozu pouze nová verze aplikace. Data stávající aplikace budou archivována a prostředí bude po určité době demontováno.

8.3[9.3] Krizový scénář produkčního provozuV případě, že se v průběhu testů nebo i po nasazení do produkčního provozu ukáže, že po 1. 9. 2013 nebude z nějakého důvodu nový systém RNPDB-M NG schopný plnit svou funkci nebo některý z mobilních operátorů nebude schopný provozovat svůj objednávkový systém tak, aby celý komunikační proces jak mezi mobilními operátory, tak vůči centrální databázi, plnil svou úlohu, mobilní operátoři se shodnou buď:

na dočasném odpojení nefunkčního objednávkového systému mobilního operátora - pokud bude jen jeden nebo

posunutí termínu spuštění (v 2týdenních krocích) – pokud nebude funkční objednávkový systém 2 či více operátorů a toto se zjistí před spuštěním do ostrého provozu nebo

na dočasném návratu k původnímu systému RNPDB-M v případě problémů nového systému RNPDB-M NG či problémů na straně 2 a více operátorů po spuštění do ostrého provozu.

Toto rozhodnutí bude učiněno nejpozději týden před plánovaným spuštěním (23.8.2013).

83 / 90

V případě návratu k původnímu systému bude z pohledu RNPDB-M postupováno následovně:

stávající systém RNPDB-M bude ponechán v provozu po nezbytně nutnou dobu,

operátoři budou zasílat portační objednávky sdružené v dávkách na denní bázi v Excel souboru e-mailem, následné nahrání objednávek do systému bude prováděno ručně,

generování konsolidovaných plánů portací a resynchronizace bude prováděno ručně na následující pracovní den (nikoli na den poté),

před odstavením nového systému budou: otevřené portační objednávky zadané podle nového procesu do

nového systému přeneseny na stávající systém a budou zpracovány dle původního procesu,

uzavřené portační objednávky zadané podle nového procesu do nového systému, budou přeneseny na stávající systém a zařazeny do výstupních souborů stávajícího systému,

portační objednávky, které se týkají poskytovatelů služeb, budou při přenosu na stávající systém transformovány na portace mezi mobilními operátory (SPID nahrazen OpID).

Při opětovném nasazení nového systému bude postupováno v souladu s kapitolou 9.1, s přihlédnutím na možná data vzniklá v novém systému (registrace subjektů, poskytovatelů služeb, přiřazení rozsahů v číslovacím plánu, portací k/od poskytovatelů služeb).

84 / 90

9.[10.] Ostatní vlastnosti systému9.1[10.1] Garantovaná dostupnostDostupnost systému v provozních a neprovozních hodinách shrnuje následující tabulka.Sledovaná metrika Garantovaná hodnotaProvozní hodiny Provozní hodiny aplikace budou v pracovní dny

od 9:00 od 22:00 (ve smyslu otevření komunikačních rozhraní).

Dostupnost systému v provozních hodinách

Architektura infrastruktury musí umožňovat vysokou dostupnost v míře 99% (měřeno týdně)

Dostupnost systému mino provozní hodiny

Mimo provozní hodiny není garantovaná dostupnost systému, mohou probíhat rutinní i jednorázové automatické úlohy (zálohování, archivace).

9.2[10.2] Propustnost systémuSystém bude navržen a otestován na níže uvedenou garantovanou kapacitu:Sledovaná metrika Garantovaná hodnotaDatová kapacita Celková kapacita systému musí být

dimenzována na 10 let užívání. Při maximálním využití 80 000 000 portací/vracení.

Kapacita uživatelské báze

Předpokládané využití systému: maximálně 10 subjektů v roli MO maximálně 50 subjektů v roli FO / Úřad3.

strana maximálně 500 uživatelů

(identifikovaných klientským certifikátem)

Výkon Kapacita systému bude dostačovat k obsloužení následujícího maximálního celkového počtu portačních objednávek během jednoho dne (všichni MO dohromady):

30 000 přenesení čísla denně 10 000 navrácení čísla denně

Špičkový výkon Výkonnost systému bude dostačovat k obsloužení špičkového provozu při zadání následujícího počtu portačních objednávek během jedné minuty (všichni MO dohromady):

500 přenesení čísla za minutu 167 navrácení čísla za minutu

Odezva Odezva systému na požadavek rozhraní webové služby bude maximálně 300 ms pro 95 % požadavků.

85 / 90

Sledovaná metrika Garantovaná hodnotaZatížitelnost 5 současných zápisů každým z uživatelů v roli

mobilní operátor.

9.3[10.3] Logická architekturaNový systém bude tvořen následujícími komponentami: Relační databáze

Datový model RNPDB-M NG implementovaný v osvědčené PostgreSQL,

JMS fronty budou perzistované do samostatné databáze. Java EE aplikace

Využívající aplikační server Jboss AS 7 včetně JMS serveru HornetQ,

RNPDB-M NG engine zahrnující nezbytnou funkcionalitu popsanou specifikačním dokumentem,

RDČ Extension engine obsahující rozšíření RDČ implementované v RNPDB-M NG, týkající se rozsahů přidělených čísel,

Synchronizační služby zastřešující obousměrný přenos dat souvisejících s rozsahy přidělených čísel mezi RDČ a RNPDB-M NG,

Uživatelské rozhraní, které se dále dělí na: Automatické rozhraní pro externí systémy (webová služba a

rozhraní pro stahování souborů), Manuální grafické rozhraní pro administrátora aplikace, Manuální grafické rozhraní pro uživatele systému.

Struktura systému je ilustrována níže viz Obrázek 17.:

86 / 90

Obrázek 17: Logická architektura systému

9.4[10.4] HW a SW prostředíSpecifikace použitého hardwarového a softwarového prostředí použitého pro novou generaci RNPDB-M shrnuje následující tabulka:Skupina Jméno Množst

víKonfigurace

Produkční prostředí

Aplikační server

2 HW: HP ProLiant DL360e G8 (1U) 1x CPU Quad-Core Intel Xeon

E52407 12 GB RAM (3 x 4 GB) 2 x 500 GB SAS disk 6G SATA DVD/RW optický disk Dynamic Smart Array B320i ILO4

SW: CentOS RedHat Cluster Suite Apache http Server 2 JBoss Application Server 7 PostgreSQL 8.4

87 / 90

Skupina Jméno Množství

Konfigurace

Diskové pole 1

HP P2000 G3 SAS MSA (Dual Controller)

Interní disky 4 x HP 300 GB 10K

Síťová infrastruktura

Firewall 1 Cisco ASA 5510 (bude použit stávající)

Přepínač 1 HP ProCurve switch 1410-24G (bude použit stávající)

Testovací prostředí

Aplikační server 1

HW: HP ProLiant DL360e G8 (1U) 1x CPU Quad-Core Intel Xeon

E52407 12 GB RAM (3 x 4 GB) 2 x 500 GB SAS disk 6G SATA DVD/RW optický disk Dynamic Smart Array B320i ILO4

SW: CentOS Apache HTTP Server 2 JBoss Application Server 7 PostgreSQL 8.4

Poznámka: Rack, LCD do racku/klávesnice, USB/PS2 přepínač a jiné

příslušenství nebude vyžadováno, protože se využije stávajících, umístěných v hostingovém centru provozovatele,

Server pro geografickou zálohu není vyžadován, protože se počítá s využitím stávajícího serveru.

88 / 90

Stávajícítestovacíinstance

Server RNPDBM-T

Stávajícíprodukční

instance

Testovacíinstance

Produkčníinstance

Server RNPDBM-2

SdílenéDiskové

pole

Server RNPDBM-1

Internet

Firewall

Externí uživatel

Switch

Server RNPDBM-T

ServerRNPDB-BACKUP

Server RNPDBM-2

SdílenéDiskové

pole

Server RNPDBM-1

Obrázek 18: Zapojení HW

9.5[10.5] Požadavky pro přístup k Web GUIParametr PožadavekPožadavek na operační systém

Windows Vista, nebo novější Linux openssl v 0.9.8 a novější Mac OS X 10.5

Požadavky na verzi internetového prohlížeče

Firefox 3.6 nebo 7 a vyšší, Chrome 14 a vyšší, IE8 a vyšší, Safari 5.1 a vyšší.

Požadavky na nastavení internetového prohlížeče

povolen JavaScript, povoleny session cookies, povoleno SSL 3.0, povoleno TLS 1.2.

89 / 90

10.[11.] Otevřené otázky, předpokladyID NázevP1 Subjekt v roli MO provozuje jediný OHS a má jediné OHS ID.

P2 IMSI prefix je vázán k OpID tak, že určitému OpID odpovídá právě jeden IMSI prefix.

P3 Ve zprávách PortingOrderPublishCRDB apod. uváděny OpID namísto dosavadních OHS Id.

P4 Do centrální databáze RNPDB-M se budou uvádět jen portace, kde se mění poskytovatel služby. Tzn. portace mezi brand resellery se do RNPDB-M nebudou zapisovat, což je v souladu [OOP10].

11.[12.] ReferenceID Název[TMMNPspec]

T-Mobile specification of distributed interfaces for Mobile Number Portability in the Czech Republic 3.x

Specifikace rozhraní distribuovaného objednávkového systému MNP

[OOP10] Opatření obecné povahy č. OOP/10/10.2012-12, kterým se stanoví technické a organizační podmínky pro realizaci přenositelnosti telefonních čísel a zásady pro účtování ceny mezi podnikateli v souvislosti s přenositelností telefonních čísel.

Legislativní rámec nového procesu přenositelnosti.

[QIspec] Dotazovací rozhraní RNPDB-MSpecifikace předmětu plnění

Specifikace zvláštního rozhraní pro dotazy na umístění čísla určené pro 3. strany.

90 / 90

Documents

Nová generace národní referenční databáze přenesených … · Web viewAuthor Jan Tolar, Richard Malina Created Date 12/03/2013 06:53:00 Title Nová generace národní referenční