VI.3.1 - Une plate-forme polyvalente

	La plate-forme logicielle développée par la société Rapsodia Software possède toutes les potentialités nécessaires à la mise 
en place de tout service à valeur ajoutée. Cette plate-forme, n'est pas seulement un produit marketing désigné par SIMphonIC GSM ™ 
ASP (voir figure A3.1), mais regroupe des applications de bases qui seront complétées par de nouvelles applications spécifiques, relatives 
au nouveaux services à développer. La plate-forme de base est suffisamment évolutive et flexible pour faciliter le travail des développeurs.

  

Fig. A3.1 - Plate-forme SIMphonIC GSM ASP ™

La liste complète des services à valeur ajoutée est actuellement impossible à dresser, tant il se crée de nouveau services tous les jours 
(voir annexe 4). L'intérêt de la plate-forme, une fois les spécifications et fonctionnalités techniques du service établies, est de l'implémenter 
sur celle-ci au plus vite. C'est dans cet esprit que la plate-forme a été mise en place et nous verrons quels modules applicatifs interviennent 
(voir figure A3.2) et quels nouveaux développements sont nécessaires à la mise en place d'un nouveau service. Parmi les services à valeur 
ajoutée implémentés sur la plate-forme ASP, se trouvent :

-	Le " Mobile Banking " ou accès aux services bancaires liés aux comptes bancaires de l'abonné GSM : soldes, dernières opérations, 
virements… ;
-	L'accès aux serveurs d'actualités : news, sport, météo., trafic routier, bourse… ;
-	Les services de réservations : SNCF, compagnies aériennes, taxis… ;
-	La consultation du courrier électronique…

   

Fig. A3.2 - Services développés par Rapsodia Software

	La figure précédente fait apparaître clairement qu'à un service à valeur ajoutée est associée une application sur une plate-forme ASP 
donnée : le service de météo est associé au fournisseur de contenu 1 (Content Provider CP#1) et à l'application 7. A cette application implémentée 
côté serveur est associé une application dans la mémoire EEPROM de la carte SIM du téléphone mobile (cette application est appelée applet car 
elle est codée en langage Java card). La personnalisation des cartes SIM (voir annexe 1) consiste à télécharger à distance un jeux d'applets 
spécifiques aux services auxquels l'abonné a souscrit auprès de son opérateur. Ceci se voit clairement sur la figure A3.2 quand nous analysons
 les applets chargées dans les cartes SIM des 3 téléphones mobiles associés au réseau GSM n°1. Les téléchargement à distance des applets 
sur la carte SIM sont réalisés à partir d'une interface administrative spécifique : l' ALM, pour Application Loader & Manager. Notons qu'il 
existe 2 types d'interfaces d'administration:
-	administration des cartes SIM (ALM) ;
-	administration des menus associés à un service spécifique, tels que le menu d'une application bancaire (consultation des soldes 
bancaires, virement de compte à compte, commande de chéquier…) qui a fait l'objet de ce stage.
Seulement l'interfaçage des téléphones mobiles personnalisés par leurs applets et les différents fournisseurs de contenus requièrent une 
grande adaptabilité des ASP. Pour cela les ASP sont développés de manière totalement modulaire et impliquent de nombreux processus 
pour gérer les nombreuses sessions ouvertes. Dans le paragraphe suivant, nous détaillerons les processus entrant en jeu au sein de la 
plate-forme même et comment sont interfacés le réseau GSM et les fournisseurs de services via cette passerelle.

VI.3.2 - Architecture modulaire de la plate-forme

Lorsqu'une session est ouverte entre un terminal mobile et une source d'information (CP, pour Content Provider), le contexte de 
cette session doit être maintenu par un Session Handler (SH) car les processus associés à la transaction se trouvent généralement 
bloqués en attente de message court (SM, pour Short Message). Comme le montre la figure A3.2, une plate-forme peut supporter
 plusieurs applications. Chaque application est associée à des services spécifiques et est supportée par un environnement appelé 
SME (Short Message Entity). Une application est généralement utilisée par plusieurs terminaux mobiles à la fois 
(parfois de réseaux GSM hétérogènes) et donc associée à plusieurs sessions. Une application gère ainsi autant de SH 
que de sessions ouvertes. Pour assurer l'ordonnancement, la création, l'annihilation et l'archivage des contestes des SH,
 un processus est associé au SME et appelé Session Controller (SC). Chaque SME possède un SC pour superviser les
 SH (voir figure A3.3). L'interfaçage entre les réseaux GSM et les SH se fait par l'intermédiaire des Média Drivers (MD) 
qui sont attribués à chaque serveur de messages courts (SMSC, pour Short Message Service Center, voir annexe 2). 
L'interfaçage entre les sources d'information (CP) et les SH se fait via l' Application Controller (AC) associé à l'application. 
Un SME peut contenir plusieurs AC, chacun étant corrélé à un ensemble de SH. Mais souvent, un SME n'est associé qu'à un 
seul AC. Un ASP désigne un SME au sens large et une plate-forme peut en héberger plusieurs. Pour savoir quels SH
 appartiennent à quel AC, le SC tient à jour une table de correspondance.

  

Fig. A3.3 - Architecture système de l'ASP

VI.3.3 - Architecture Système associée

	La plate-forme a été développée dans un environnement UNIX afin de gérer le grand nombre de sessions 
(processus SH) ouvertes simultanément par les téléphones mobiles. Les téléphones mobiles peuvent appartenir à des
 réseaux d'opérateurs GSM (PLMN, pour Public Land Mobile Network) différents. Ainsi, une même plate-forme peut
 être connectée à plusieurs réseaux d'opérateurs GSM, d'opérateurs différents. A chaque session ouverte entre un téléphone 
mobile et un fournisseur de contenu sont associés plusieurs processus : le Session Handler (SH), le Média Driver (MD), 
l'Application Controller (AC), le Session Controller… comme le montre la figure A3.4. Seulement un problème de routage
 apparaît lorsqu'une session est initiée par un téléphone mobile. En effet, le mobile envoie sa requête, sous forme de messages
 courts, au SMSC qui les retransmet au MD associé. Seulement le MD doit dispatcher la requête vers le bon SME. Comme
 la requête comporte le numéro de SME, le MD fait appel au Router (Routing Server) pour connaître le port d'entrée TCP/IP
 associé au SME sur la plate-forme. Ensuite, la requête est transmise au SC, associé à ce SME, qui se charge de la traiter.

  

Fig. A3.4 - Architecture Système de l'ASP

Un SME, associé à son port TCP/IP, constitue donc un serveur applicatif. La plate-forme regroupe plusieurs serveurs qui
 physiquement pourrons être répartis sur plusieurs machines ou une seule selon la charge offerte (nombre maximum de sessions 
simultanées que peut supporter la machine). A cette plate-forme logicielle correspondent des éléments physiques distincts 
abordés dans le paragraphe suivant.

VI.3.4 - Architecture physique de la plate-forme

	Globalement, la plate-forme est un agrégat de multiples serveurs (d'autant plus que le nombre de sessions à traiter et
 d'interconnexions avec l'extérieur est grand, car les capacités d'un serveur unique seraient alors dépassées). La plate-forme 
est interconnectée à de nombreux autres serveurs par des liens TCP/IP ou X25, chaque serveur assurant une fonction spécifique.
 Citons les principaux :
-	l' interface WEB, ou IHM (Interface Homme-Machine) sera générée par un serveur WEB de type Apache exploitant 
en temps réel les paramètres du AC (Application Controller) présentés par la figure A3.4 ;
-	les données relatives au client seront stockées dans le serveur de base de données du fournisseur de contenu ;
-	les données relatives aux cartes SIM seront stockées dans un serveur de base de données également (de type Oracle 8i ou 
Postgres) dans le cas de l'interface d'administration et de chargement des applets Over The Air, associée à l'ASP ALM;
-	les données relatives aux menus s'affichant sur le terminal mobile seront également stockées sur un serveur de base de 
données de type Postgres dans le cas du projet SMART, associé à l'ASP SMART ;
-	le serveur de sécurité (voir annexe 7) ;
-	la plate-forme, elle-même, constitue un serveur (ou plusieurs) ;

Du point de vue physique, plusieurs serveurs peuvent être placés sur la même machine (il suffit de leur attribuer un port TCP différent 
et de disposer d'une mémoire RAM conséquente), comme le montre la figure A3.5 :

  

Fig. A3.5 - Architecture physique de la plate-forme

	Cette figure met en lumière les principaux clients interrogeant les serveurs par le biais d'interfaces WEB spécifiques 
(telles que l'interface d'administration des menus bancaires développée pour l'ASP SMART, objet de ce stage) ou des SMSC.
 Pour développer une interface WEB ou un MD, il est indispensable de connaître le fonctionnement d'ensemble de la plate-forme, 
d'où l'intérêt d'en étudier chaque élément.

VI.3.5 - Description des éléments principaux de la plate-forme

	Le Content Provider (CP) constitue la source d'information avec laquelle l'utilisateur du terminal mobile souhaite dialoguer 
via la plate-forme logicielle. Il peut s'agir d'un serveur bancaire, dans le cas d'une application de transactions bancaires, d'un serveur de
news, de bulletins météorologiques… Les informations (messages) qu'il fournit à la plate-forme sont transmises de bout en bout sur IP 
ou X25 de manière sécurisée.

	Le SMSC (Short Message Service Center), décrit en annexe 2, assure le transfert de bout en bout des messages courts
 (SM, pour Short Messages) entre le Média Driver (MD) et l'applet de la carte SIM destinataire pour un réseau GSM donné
 (voir figure A3.2). Il permet notamment de stocker les messages courts issus ou à destination du mobile. Le service de messages courts 
(SMS, pour Short Message Service) de GSM (recommandation ETSI 3.40) permet au terminal mobile et à une entité extérieure au réseau 
GSM (PLMN) de communiquer par SM. Cette entité externe est désignée par SME pour Short Message Entity. Dans le cas de la
 figure A3.1, il s'agit de la plate-forme logicielle mais il pourrait également s'agir d'un micro-ordinateur (fixe) ou d'un autre terminal mobile.

	La carte SIM pro-active (voir annexe 1) peut traiter les SM qu'elle reçoit de la plate-forme logicielle et initier des 
commandes pro-actives afin d'émettre des SM également. Elle permet par exemple à l'utilisateur de sélectionner un item dans 
un menu affiché sur l'écran du terminal mobile et d'envoyer un SM associé à ce choix vers la plate-forme. Notons qu'avant 
d'atteindre la carte SIM, un SM transite par l'équipement mobile qui relève, au passage, l'identifiant du SM. Cet identifiant 
joue un rôle essentiel car il contient, entre autres, la classe du message court. Distinguons 4 classes de messages courts 
dans la table suivante :

  

Table des classes de messages courts

	Le Media Driver (MD) assure l'émission des messages courts (SM) issus des Session Handlers, la réception des 
SM provenant du SMSC associé (dans ce cas les SM ne sont pas transmis au SH mais au SC qui les supervise) et l'archivage 
des messages courts émis et reçus dans l' archiveur de messages courts (MAFF, pour media driver Message Archiver Flat Files). 
Pour réceptionner les messages courts et les distribuer au bon SME, le MD utilise le Router qui optimise le routage des SM entrants 
et sortant entre le MD et l'environnement SME. Un MD est associé à un SMSC unique. Le MD concatène et ré-assemble également
 les messages courts reçus par le SMSC ou émis par la plate-forme respectivement.

	Le Session Handler (SH) crée un contexte de communication entre un client (un téléphone mobile et sa carte SIM, représentée
 par son numéro de téléphone MISDN) et un serveur (l'application d'un AC, représenté par son numéro de port). Plusieurs SH coopérant 
avec leurs AC relatifs sont traités par le même SC. Chaque session gérée par le SH et initiée côté serveur (AC ou SC) ou côté client 
(équipement mobile ou carte SIM) est archivée dans l' archiveur de sessions (SAFF pour session Handler Session Archiver Flat Files).

	Le Session Controller (SC) traite les SH et supervise une table de tous les services offerts par le SME. Il ordonnance 
(scheduling) les processus SH selon leur priorité et leur date de début prévue. Un seul SC est implémenté par environnement SME.
 Lorsqu'un message court est émis par un terminal mobile (MO-SM, pour Mobile Originated - Short Message), le SC le dispatche 
vers le bon SH selon le MSISDN et l'identifiant de l'AC (numéro de port) transmis par le message court. Le SC assure également
 du contrôle de flux en limitant le nombre de sessions en parallèle (le nombre de SH) par service et pour tout le SME auquel il appartient. 
Si le SMSC ou le SC sont temporairement indisponibles ou connaissent des problèmes de connexion, ils s'échangent des messages de 
contrôle pour éviter toute congestion. Une plate-forme ASP est ainsi capable de recevoir et émettre environ 200 messages par seconde 
et de gérer 500 sessions simultanées.

	L'Application Controller (AC) renseigne le SC sur les caractéristiques de chaque service de l'application et contrôle les
 échanges avec les interfaces homme-machine (IHM) ou serveurs externes des CP. De plus il agit comme scheduler afin de partager
 l'accès aux ressources (Bases de données…) et il enregistre les statistiques d'activité des différents services de l'application. Un ou 
plusieurs AC sont dédiés à un même SME.

	Le Router assure 2 fonctions. Pour les SM réceptionnés par la plate-forme, le Router lit l'en-tête TP-DA (Transport Protocol -
 Destination Address) des SM et fournit au MD le numéro de l'environnement SME auquel le SM est destiné. Pour les SM émis par la
 plate-forme, le Router lit l'en-tête des SM et fournit au MD l'adresse de destination (MSISDN) du SM.

	Le Serveur d'évènements (sevent) est un automate d'alerte qui détermine dans quel état de disponibilité se trouve la
 plate-forme et quels évènements y occurrent. Toutes les informations nécessaires à la gestion des alertes sont stockées 
quotidiennement et chaque heure dans 2 types de fichiers (EVEFF, pour EVEnt Flat Files et AVAFF, pour AVAilability Flat Files).
 Le serveur d'évènements travaille en collaboration avec tous les modules de l'ASP (SH, SC, AC, Router…) et extérieurs (MD) :
 il est au cœur du monitoring de l'ASP. Celui-ci décide, selon la configuration souhaitée par l'administrateur de la plate-forme, si 
des messages d'alerte doivent être générés. Ces messages sont envoyés soit par e-mail (aux adresses spécifiées par l'administrateur),
 soit par trap SNMP (au serveur SNMP choisi par l'administrateur). Plusieurs types d'évènements sont susceptibles de déclencher
 un message d'alerte : un démarrage ou arrêt (notifié ou constaté) de processus, une connexion ou déconnexion. Tous ces évènements
 sont enregistrés dans les fichiers MAFF et SAFF, qui collectent les données. Par exemple, si un message court est perdu, le MD le 
détecte et le notifie au serveur d'évènements qui envoie un message à l'abonné ou à l'opérateur pour le lui signaler. De plus, le serveur
 d'évènements enregistre cet événement dans le MAFF associé à l'application gérant le message court.

	L' Archiveur de messages courts (MAFF) enregistre tous les états des messages initiés côté client et côté serveur et
 construit les fichiers d'archivage maff.hh. De tels fichiers sont construit quotidiennement et chaque heure pour chaque MD. Chaque
 état ou événement associé à un message court est formaté en une ligne dans le fichier maff.hh. Cette ligne contient la date d'ouverture
 de la session, la référence du SM (donnée par le MD pour chaque message), le MISDN (en format international du style 
33.6.70.05.xxxx où 33 désigne le pays, 6 un réseau radio-mobile, 70 le PLMN, 05 le HLR et les 4 derniers chiffres le numéro
 de l'abonné dans ce HLR), le numéro de port de l'applet (en hexadécimal) de la carte SIM, la direction (SM émis ou reçu), 
le nom de la plate-forme ASP, le numéro de téléphone du SME (format international), le numéro de port du service de l'AC 
(en hexadécimal), un identificateur de session, l'état du message et d'autres paramètres. Le MAFF est donc utilisé pour facturer
 les SM au client.

L'Archiveur de sessions (SAFF) enregistre tous les états des sessions ouvertes et construit les fichiers d'archivage saff.hh. De tels
 fichiers sont construit quotidiennement et chaque heure pour chaque SME. Chaque état ou événement associé à une session est
 formaté en une ligne dans le fichier saff.hh. Cette ligne contient la date d'ouverture de la session, l'état de la session, l'identificateur
 de session, le MISDN (format international), le numéro de port de l'applet (en hexadécimal) de la carte SIM, le nom de l'application 
(SME), le tag d'origine d'initiation de la session (s pour côté serveur et m pour côté client ou terminal mobile), la date et l'heure 
d'exécution de la session, la priorité de la session, le nom du MD, le dernier état de la session, la durée de la session si elle est en
 court, les éventuels codes d'erreur…