Allegato 10

Procedure di passaggio dei clienti di operatori

di rete fissa che utilizzano reti FTTH di
operatori Wholesale diversi da TIM

Specifiche di Interfaccia
OLO–OLO

(Processo di NP)

1
Sommario
SOMMARIO..........................................................................................................................................................................2
1 SCOPO.........................................................................................................................................................................3
2 DELIVERY....................................................................................................................................................................4
2.1 SCHEMA ARCHITETTURALE............................................................................................................................4
2.1.1 SOMMARIO EVENTI.........................................................................................................................................4
2.1.2 SEQUENCE DIAGRAMS.................................................................................................................................4
2.1.3 DETTAGLI TRANSAZIONALI.........................................................................................................................5
2.1.4 POLITICHE DI RETRY RECIPIENT...............................................................................................................5
2.1.5 POLITICHE DI RETRY DELL’OPERATORE DONOR................................................................................6
2.1.6 GESTIONE WORKFLOW.................................................................................................................................6
2.2 INTERAZIONI OPERATORE RECIPIENT–OPERATORE DONOR.............................................................7
2.2.1 MESSAGGI INVIATI DALL’OPERATORE RECIPIENT ALL’OPERATORE DONOR..........................7
2.2.2 MESSAGGI INVIATI DALL’OPERATORE DONOR ALL’OPERATORE RECIPIENT..........................7
2.2.3 COMUNICAZIONI SINCRONE........................................................................................................................7
2.2.3.1 ACK/NACK SINCRONO DI PRESA IN CARICO (N12)..............................................................................7
2.2.4 WSDL DEI WEB SERVICES...........................................................................................................................7
2.2.5 CAUSALI DI SCARTO FORNITE DAL DONOR..........................................................................................8

2
1 Scopo
Lo scopo del documento è descrivere il dettaglio dell’interfaccia tra l’Operatore Recipient e l’Operatore Donor
per le comunicazioni relative alla NP delle numerazioni da portare associate all’accesso da migrare delle
procedure di passaggio dei clienti di operatori di rete fissa che utilizzano reti FTTH di operatori Wholesale
diversi da TIM (di seguito per brevità processo di NP).

Il documento descrive per le numerazioni oggetto di portabilità:

 Mimica di comunicazione fra il Gateway degli Operatori Recipient e il Gateway dell’Operatore

Donor;
 Transazioni fra il Gateway degli Operatori Recipient e il Gateway dell’Operatore Donor
 Contenuto dei messaggi sincroni e asincroni delle comunicazioni fra il Gateway degli Operatori
Recipient e il Gateway dell’Operatore Donor.

3
2 Delivery
2.1 Schema Architetturale

2.1.1 Sommario eventi

La comunicazione bidirezionale tra il Gateway dell’Operatore Recipient e il Gateway dell’Operatore Donor
delle numerazioni è basata sui seguenti metodi, relativi a web service esposti dall’Operatore Donor e
dall’Operatore Recipient.

Metodo Funzione Eventi Operatore

Operatore che
che riceve la
invia la notifica
notifica
OLO_NPRequest Notifiche dal Recipient Operatore Operatore
vs il Donor: Recipient Donor
Richiesta
preventiva di NP - Notifica
vs Donor preventiva di NP
Richiesta - Notifica richiesta
esecutiva di NP vs esecuzione NP
Donor o KO - Notifica KO
migrazione migrazione

OLO_NPNotificatio Invio dell’eventuale Notifiche dal Donor vs il Operatore Operatore

n KO sulla Recipient: Donor Recipient
comunicazione - Notifica KO sulla
preventiva di NP richiesta di NP

2.1.2 Sequence diagrams

Di seguito è descritta ad alto livello l’interazione tra il Gateway dell’Operatore Recipient e il Gateway
dell’Operatore Donor:

- A seguito della notifica di accettazione e comunicazione DAC ricevuta dal Recipient sul processo di
migrazione FTTH, il Recipient invoca il WS OLO_NPRequest esposto dall’Operatore Donor per
inviare la richiesta preventiva di NP.
- L’operatore Donor effettua i relativi controlli sulle numerazioni e nel caso identifichi una o più
numerazioni non appartenenti al Donor ne dà evidenza al Recipient invocando il WS
OLO_NPNotification
- A seguito della notifica di espletamento OK ricevuta dal Recipient sul processo di migrazione FTTH, il
Recipient invoca il WS OLO_NPRequest esposto dall’Operatore Donor per inviare la richiesta
esecutiva di NP.
- A seguito della notifica di espletamento KO ricevuta dal Recipient sul processo di migrazione FTTH, il
Recipient invoca il WS OLO_NPRequest esposto dall’Operatore Donor per inviare la richiesta di KO
migrazione.
Tutti i messaggi sono caratterizzati da un esito sincrono di ACK/NACK basato sul WSDL/XSD di validazione,
in entrambe le direzioni
La figura seguente mostra i metodi utilizzati nel processo di migrazione ed il loro verso.

4
 Operatore Operatore
Recipient Donor

OLO_NPRequest
Richieste Preventiva di NP
Ack/Nack
OLO_NPNotification
Notifica di KO
Ack/Nack
OLO_NPRequest
Richieste Esecutiva di NP
Ack/Nack
OLO_NPRequest
Richieste KO di migrazione
Ack/Nack

Figura 1: Gestione NP

2.1.3 Dettagli transazionali

I principi transazionali tra il Gateway dell’Operatore Recipient e il gateway dell’Operatore Donor ono descritti
di seguito:

 Le interfacce descritte nel presente documento sono di tipo XML/SOAP.

 I sistemi coinvolti esportano un web service conforme alle specifiche SOAP.
 Il protocollo di comunicazione è HTTPS.
 I web service saranno certificati da una Certificate Authority riconosciuta.
 A meno di problemi di raggiungibilità, il sistema chiamato risponde sempre al chiamante con un
messaggio sincrono di ACK/NACK, effettuando una validazione formale del messaggio basata sul
WSDL/XSD condiviso e sulle logiche sincrone implementate a livello di servizio.
 Saranno controllati in modalità sincrona su tutti i campi:
o Nome dei TAG XML
o Formato e dimensione dei dati scambiati
o Molteplicità
o Liste di valori ammesse
o Regole di obbligatiorietà
o Coerenza con lo stato del Work Order
 Per quanto riguarda gli attributi opzionali, nel caso la valorizzazione non sia prevista dal sistema
origine, il TAG potrebbe non essere veicolato sull’XML. Un’eventuale lista di valori ammessa sarà
applicabile solo in caso di tag presente.
 L’encoding utilizzato negli xml generati da tutti i sistemi è UTF-8.

2.1.4 Politiche di retry Recipient

Sui sistemi del Gateway dell’Operatore Recipient sono previste le seguenti logiche di gestione dei retry:
- Retry automatico:
o da attuare in caso di mancata ricezione dell’esito sincrono della chiamata allo scadere di un
timeout (es. sistema non raggiungibile)
o il messaggio re-inviato sarà identico al messaggio originale, in particolare in termini di
ID_NOTIFICA
- Retry per NACK (KO formale/tecnico):
o da attuare nel caso di NACK sincroni originati da una mancata validazione del messaggio dal
punto di vista dei controlli formali sui campi

5
 o il messaggio re-inviato sarà modificato in termini di contenuto informativo sulla base del KO
ricevuto, e sarà contraddistinto da un nuovo ID_NOTIFICA.

2.1.5 Politiche di retry dell’Operatore Donor

Sul Gateway dell’Operatore Donor sono previste le seguenti logiche di gestione dei retry:
- Retry automatico:
o da attuare in caso di mancata ricezione dell’esito sincrono della chiamata allo scadere di un
timeout (es. sistema non raggiungibile)
o il messaggio re-inviato sarà identico al messaggio originale, in particolare in termini di
ID_NOTIFICA
- Retry per NACK (KO formale/tecnico):
o da attuare nel caso di NACK sincroni originati da una mancata validazione del messaggio dal
punto di vista dei controlli formali sui campi
o il messaggio re-inviato sarà modificato in termini di contenuto informativo sulla base del KO
ricevuto, e sarà contraddistinto da un nuovo ID_NOTIFICA.

2.1.6 Gestione Workflow

Di seguito è dettagliato il diagramma a stati relativo alla interazione tra Operatore Recipient e Operatore
Donor per la gestione del processo di NP.

Stato iniziale/finale

NP Set UP

Stato intermedio

T1 Transizioni di stato

T4 T2
Espletato KO Inviato Acquisito KO

T3

Espletato OK

Figura 2–Macchina a stati Recipient

Transizion Stato Stato Arrivo Eventi di Sorgente Nome Metodo

e /Riciclo Partenza Transizione/Attesa

T1 NP Set Up Inviato Richiesta Preventiva OLO Recipient OLO_NPRequest

NP

T2 Inviato Acquisito KO Notifica di KO OLO Donor OLO_NPNotification

T3 Inviato Espletato OK Notifica Esecutiva OLO Recipient OLO_NPRequest

NP

T4 Inviato Espletato KO Notifica KO OLO Recipient OLO_NPRequest

migrazione

6
2.2 Interazioni Operatore Recipient–Operatore Donor
I messaggi presentano una struttura comune per tutti gli Operatori Donor e Recipient.

2.2.1 Messaggi inviati dall’Operatore Recipient all’Operatore Donor

I messaggi inviati dall’Operatore Recipient all’Operatore Donor sono quelli indicati nell’Allegto 4
(Comunicazione N11 vs il Donor) e di seguito riportati.
 Messaggio di richiesta preventiva NP:
o OLO_NPRequest (TIPO_NOTIFICA=’01)’

 Messaggio di richiesta esecuzione NP:

o OLO_NPRequest (TIPO_NOTIFICA=’02)’

 Messaggio di richiesta annullamento NP:

o OLO_NPRequest (TIPO_NOTIFICA=’03)’

Tali messaggi sono veicolati attraverso il Web Service OLO_NPRequest messo a disposizione dall’Operatore
Donor ed invocato dall’Operatore Recipient. Di seguito viene riportato il tracciato record del Web Service
OLO_NPRequest.
Il tracciato comprensivo di tutti i campi è riportato nell’allegato 4 al par. 5.4.1

2.2.2 Messaggi inviati dall’Operatore Donor all’Operatore Recipient

I messaggi inviati dall’Operatore Donor all’Operatore Recipient sono quelli indicati nell’Allegto 4
(Comunicazione N13 vs il Recipient) e di seguito riportati.
 Messaggio di KO NP:
o OLO_NPNotification

Tali messaggi sono veicolati attraverso il Web Service OLO_NPNotification messo a disposizione
dall’Operatore Recipient ed invocato dall’Operatore Donor. Di seguito viene riportato il tracciato record del
Web Service OLO_NPNotification.
Il tracciato comprensivo di tutti i campi è riportato nell’allegato 4 al par. 5.4.2

2.2.3 Comunicazioni sincrone

Di seguito sono riportate le altre tipologie di notifiche scambiate tra tutti gli operatori che partecipano al
processo di gestione NP contestuale alla migrazione dell’accesso FTTH.

2.2.3.1ACK/NACK sincrono di presa in carico (N12)

Il tracciato comprensivo di tutti i campi è riportato nell’allegato 4 al par. 5.5.1

2.2.4 WSDL dei Web Services

Nel file allegato è riportato il WSDL che descrive i metodi OLO_NPRequest e OLO_NPNotification.

7
 O2OFibra.wsdl
O2OFibra.zip

2.2.5 Causali di scarto fornite dal Donor

Le causali di scarto del porcesso di NP sono riportate nell’allegato 5.