In questo articolo approfondiremo alcune tematiche relative alla comunicazione con un centro servizi, descrivendo uno dei protocolli più importanti per la comunicazione verso un centro servizi, cioè il protocollo EMI-UCP. Vedremo come è possibile scambiare informazioni con un SMSC e quali sono le operazioni possibili. Analizzeremo ancora più in dettaglio la struttura di un SMS per capire meglio quali informazioni possono essere estratte.

Aspetti generali

Nello scorso articolo abbiamo iniziato a descrivere alcuni concetti di base di un servizio di messaggistica basato su SMS, abbiamo visto che uno dei modi per inviare e ricevere SMS è scambiare informazioni con un centro servizi e sono stati elencati alcuni dei protocolli che possono essere usati per interagire con un SMSC, in questo articolo analizzeremo in dettaglio il protocollo EMI-UCP.

In un funzionamento normale, un client si connette ad un centro servizi e scambia con quest‘ultimo delle informazioni sotto forma di comandi e risposte; tali comandi vengono chiamati operazioni. Le risposte vengo, invece, utilizzate per conoscere l‘esito dell‘operazione richiesta.

E‘ possibile anche il percorso inverso dove è il centro servizi ad inviare delle operazioni al client e quest‘ultimo invia delle risposte, questo è il caso, ad esempio, della notifica dell‘arrivo di un nuovo messaggio. In questo articolo non tratteremo tutte le operazioni ammesse dal protocollo EMI-UCP ma solamente quelle più importanti.

Funzionalità 

Prima di addentrarci nell‘analisi del protocollo vero e proprio è opportuno fare alcune premesse di carattere generale che ci aiuteranno meglio a capire gli argomenti che tratteremo. Qui di seguito è riportata una figura che mette in evidenza come un generico client si connette ad un centro servizi. Normalmente il protocollo di rete su cui si appoggia EMI-UCP è il TCP/IP anche se è possibile utilizzare anche altri protocolli di rete.

Figura 1 – Comunicazione fra un SMT e il centro servizi

Il termine SMT sta per Short Message Terminal ed è rappresentato da un qualsiasi dispositivo in grado di comunicare con il centro servizi tramite il protocollo EMI-UCP.

Nella figura sopra riportata il centro servizi viene visto come una scatola nera che fornisce una serie di macro funzionalità  che vengono qui sotto elencate:

• Invio di un messaggio
• Ricezione di un messaggio
• Ricezione di notifiche

Tutti i comandi che vengono scambiati fra il client ed il server possono essere divisi in due gruppi, in funzione di chi invia il comando. Si parla quindi di:

• Comandi iniziati dal client
• Comandi iniziati dal server

In entrambi i casi, questi comandi portano a un‘azione che viene intrapresa dal server o dal client. Per ciascun comando inviato, l‘altro è obbligato ad inviare una risposta che può essere positiva, ed in questo caso di parla di ACK, o negativa cioè NACK.

Struttura di un messaggio EMI-UCP

Fino ad ora abbiamo parlato di messaggi senza però specificare cosa si intende. E‘ giunto il momento di addentrarci nella struttura di un messaggio e capire quali sono le parti fondamentali che lo compongono.
Nella figura 2 si evidenziano tre parti fondamentali:

Figura 2 – Struttura di un messaggio EMI-UCP

Queste tre parti sono racchiuse da due caratteri di controllo che sono rispettivamente:

stx (0x02)

etx (0x03)

In conclusione, quindi, il messaggio ha la seguente struttura:

stx 
// etx

E‘ importante sottolineare che tutti messaggi vengono codificati tramite opportune regole. In generale si utilizza una tabella di conversione che si basa su un alfabeto a 7bit. In rete sono disponibili tali tabelle che possono facilmente essere utilizzate per codificare opportunamente i messaggi. Inoltre, tutti i parametri che compongono un messaggio sono separati dal carattere /.

Analizziamo in dettaglio le parti che compongono la struttura del messaggio.

Header

L‘header di un messaggio è l‘intestazione che contiene molte informazioni utili che possono essere utilizzate per analizzare il tipo del messaggio. Di solito questa parte del messaggio non è mai visualizzata quando riceviamo un SMS, ma viene utilizzata dal nostro telefonino o dal centro servizi per estrarre delle informazioni utili sul contenuto informativo del messaggio, rappresentato dalla parte Data.
L‘header si compone di quattro parti, che devono essere sempre presenti :

Transaction Reference Number (TRN): E‘ il numero che rappresenta la transazione. E‘ molto utile per poter collegare la risposta all‘operazione richiesta.

• Length (LEN): Rappresenta il numero totale di caratteri IRA compresi fra stx ed etx
• O/R: O indica un‘operazione mentre R indica una risposta
• Operation Type (OT): indica il numero dell‘operazione

Data

E‘ il contenuto informativo del messaggio e dipende dal tipo di operazione come vedremo più avanti.

Checksum

E‘ la sequenza di controllo finale ottenuta sommando opportunamente tutti i byte che compongono l‘header ed il campo data, compresi i separatori.

Controllo del Flusso

Un aspetto molto importate è come controllare il flusso dei dati che vengono scambiati fra il centro servizi e il terminale SMT. In altre parole è importante capire quanti comandi si possono inviare simultaneamente ad un centro servizi. In generale vengono supportate due modalità  di scambio dei messaggi:

Il primo è indicato come stop-and-wait: viene inviato un comando e si attende la risposta del centro servizi, cioè non è possibile inviare un altro comando prima che venga ricevuta la risposta relativa al comando precedente.
La seconda modalità  supportata è indicata come windowing. In questo caso si definisce una window size cioè il numero di comandi che possono essere inviati prima che venga ricevuta la risposta. In questa modalità  il parametro TRN assume un ruolo fondamentale per determinare se il comando inviato supera il numero di comandi ammissibili, cioè se è fuori dalla window size.

Operazioni

Abbiamo detto che il client ed il server si scambiano una serie di comandi dette operazioni. Ora vediamo quali sono tali comandi e che struttura hanno.

Il protocollo EMI-UCP prevede di dividere le operazioni in serie. Nel seguito di questo articolo analizzeremo alcune operazioni della serie 50, 60. Queste due serie inglobano alcune delle funzionalità  più importanti per l‘invio e la ricezione di Short Message e per l‘autenticazione/gestione della sessione.

Serie 50 – Operazione 51

Una delle operazioni più importanti di questa serie è la 51 tramite la quale è possibile inviare uno Short Message. Questa operazione viene chiamata Submit Message e può essere usata sia per l‘invio di un messaggio di testo sia per l‘invio di un messaggio binario.
Alcuni parametri di tale operazione sono obbligatori mentre altri sono opzionali, tra i parametri obbligatori ricordiamo:

• AdC: Rappresenta il numero di telefono del destinatario
• OadC: Rappresenta il numero di telefono del mittente
• MT: Rappresenta il Message Type, cioè il tipo di messaggio che vogliamo inviare. Nel nostro caso essendo un messaggio di testo MT deve essere uguale a 3.

Vi sono molti altri parametri che possono essere aggiunti all‘operazione, che però sono opzionali e che non tratteremo. A questo punto supponiamo di voler inviare al numero di telefono 00391234 il messaggio ciao e che il mittente sia il numero 0011111. Tenendo conto di quanto detto fino ad ora la stringa sarà  di questo tipo:

00/00073/O/51/00391234/0011111/////////////////3//6369616F/////////////B3

<  Header >  <  Adc  >                               

Tutti gli altri campi essendo opzionali sono stati lasciati vuoti.

Analizzando il messaggio notiamo subito che i primi quattro parametri rappresentano l‘header. In questo caso per il TRN abbiamo scelto 00.
00073 rappresenta la lunghezza complessiva del messaggio, mentre O sta indicare che richiediamo un‘operazione e 51 è proprio il codice dell‘operazione richiesta.
Notiamo che il testo ciao è stato convertito in formato numerico utilizzando la tabella di conversione basata su una codifica del messaggio a 7bit. Infatti, utilizzando tale tabella otteniamo che:

c = 63, i = 69, a = 61, o = 6F

E‘ importante sottolineare che, nella codifica dei messaggi, esiste un alfabeto di default che deve essere supportato obbligatoriamente, mentre esistono alfabeti addizionali che sono opzionali.
E infine abbiamo il Checksum B3, calcolato sommando tutti i byte del messaggio precedente e facendo delle opportune operazioni sul valore ottenuto.

Come detto, per ogni operazione è necessario inviare una risposta. In questo caso è il centro servizi che deve inviare una risposta che indica se l‘operazione è stata accettata o meno. Nel caso di risposta positiva il messaggio avrà  una struttura di questo tipo:

00/xxxx/R/51/A//AdC:timestamp/Checksum

Nel caso specifico la risposta è:

00/00041/R/51/A//00391234:231006210550/C0

La A (ACK) dopo il codice 51 indica che l‘operazione richiesta è stata accettata correttamente.
In caso di risposta negativa il messaggio ha una struttura di questo tipo:

00/xxxx/R/51/N/EC/System message/Checksum

Nel caso specifico la risposta da parte del centro servizi è:

00/00043/R/51/N/02/00391234:231006210734/35

La N sta per NACK, quindi, questo significa o che il formato del messaggio è sbagliato oppure si sono verificati degli errori. In questo caso il codice di errore (EC) riportato nel messaggio di risposta ci aiuta a capire il motivo per cui la nostra operazione è stata rifiutata.

In entrambi i casi è possibile notare che il parametro TRN, nella risposta, è uguale a quello dell‘operazione a cui la risposta si riferisce. Questo è molto utile per poter abbinare la risposta all‘operazione richiesta.

Nell‘operazione 51 è il client che richiede l‘operazione e quindi è sua responsabilità  costruire in maniera corretta il messaggio EMI-UCP.

Serie 50 – Operazione 52

Tramite questa operazione il centro servizi comunica al terminale SMT l‘arrivo di un nuovo messaggio. Anche per questa operazione vi sono numerosi parametri, non tutti sono obbligatori. In questo caso è il centro servizi ad iniziare l‘operazione e quindi è suo compito costruire il messaggio EMI-UCP con gli opportuni parametri richiesti.

Come al solito analizziamo unicamente i parametri obbligatori che vengono riportati qui sotto:

• AdC: Rappresenta il numero di telefono del destinatario;
• OadC: Rappresenta il numero di telefono del mittente;
• MT: Rappresenta il Message Type, cioè il tipo di messaggio che vogliamo inviare. Nel nostro caso essendo un messaggio di testo MT deve essere uguale a 3;
• SCTS: Rappresenta il timestamp del centro servizi ed ha il formato DDMMYY.

Nel caso in cui arrivi un messaggio destinato al numero 01234 e come mittente 001111 e con testo ciao, il messaggio avrà  una struttura di questo tipo:

00/00082/O/52/01234/0011111/////////////311299235959////3//6369616F/////////////92

<  Header  >                <   SCTS    >    

Nel caso in cui il messaggio venga accettato correttamente, la risposta, che il client dovrà  fornire, deve essere del tipo:

00/xxxx/R/52/A///95

Nel caso, invece di risposta negativa questa avrà  una struttura del tipo:

00/xxxxx/R/52/N/EC//CS

Serie 60

Prima di richiedere qualsiasi operazione è necessario che il client sia autenticato cioè fornisca delle credenziali in maniera che il centro servizi lo possa riconoscere. L‘autenticazione si basa sulla coppia userid e password. L‘operazione, tramite la quale, avviene l‘autenticazione è la 60. In questo caso è il client che inizia l‘operazione e che ha il compito, quindi, di generare correttamente il messaggio EMI-UCP.
Come al solito ci sono dei parametri opzionali ed alcuni obbligatori:

• Oadc: rappresenta un numero di telefono o un IP (opportunamente codificato);
• STYP (Sub Type Operation): nel nostro caso il valore è 1, che sta ad indicare l‘apertura di una nuova sessione;
• PWD: Password codificata con le tabelle IRA;
• VERS: Numero di versione che deve essere impostato al valore 0100.

Da quanto detto, nel caso di userid uguale a 1111 e password 0000, la struttura del messaggio è di questo tipo:

00/00047/O/60/1111/6/5/1/30303030//0100//////AD

Nel messaggio precedente sono stati aggiunti alcuni parametri opzionali che vengono descritti qui di seguito:

• OTON (Originator Type of Number) pari a 6 nel nostro caso
• ONPI (Originator Number Plan Id) pari a 5

Nel caso in cui le nostre credenziali vengano accettate la riposta fornita dal centro servizi sarà  del tipo:

00/00019/R/60/A//6D

Nel caso in cui, invece, l‘autenticazione non sia andata a buon fine, la risposta conterrà  un NACK ed avrà  una struttura del tipo:

00/00022/R/60/N/01//04

Conclusioni

In questo articolo abbiamo analizzato le basi del protocollo EMI-UCP e le sue operazioni fondamentali e con queste nozioni è già  possibile rendersi conto di come sia abbastanza semplice scrivere un piccolo programma Java che comunichi con un centro servizi. Per chi volesse “avventurarsi” nel mondo della messaggistica, è possibile scaricare un simulatore (http://www.logicacmg.com/Telecoms/350234314) che si comporta come un vero centro servizi ed iniziare in questo modo a fare alcune prove.

Riferimenti

[1] www.logica.com

[2] http://www.dreamfabric.com/sms/default_alphabet.html