Développement d un service de messagerie sur une plateforme de service de nouvelles générations

Transcription

1 Cycle de formation des ingénieurs en Télécommunications Option : Réseaux et Services Mobiles RAPPORT DE PROJET DE FIN D ETUDES Thème : Développement d un service de messagerie sur une plateforme de service de nouvelles générations Elaboré par : Walid TRABELSI Encadrant (s) : Mr Sami TABBANE Mme Asma BEN LETAIFA Travail proposé et réalisé en collaboration avec Année universitaire : 2005/2006 i

2 Dédicaces A mes très chers parents Dont leurs mérites, leurs sacrifices, leurs qualités humaines m ont permis de vivre ce jour: Les mots me manquent pour exprimer toute la reconnaissance, la fierté et le profond amour que je vous porte pour les sacrifices qu ils ont consenti pour ma réussite, qu ils trouvent ici le témoignage de mon attachement ma reconnaissance, gratitude et respect, que dieu leur préservent bonne santé et longue vie. Tous mes sentiments de reconnaissance pour vous. A mes soeurs J espère atteint le seuil de vos espérances. Que ce travail soit l expression de ma profonde affection Je vous remercie pour le soutient moral et l encouragement que vous m avez accordés. Je vous souhaite tout le bonheur que vous méritez. En leur souhaitant un brillant avenir. A mes ami(e) s A tout ceux qui ont su m apporter aide et soutient aux moments propices, Je dédie ce travail, reconnaissant et remerciant chaleureusement. A tous mes enseignants Que je n oublierai jamais, pour la qualité de l enseignement qu ils ont bien voulu me prodiguer durant mes études afin de me donner une formation efficace. Je dédie Tous Walid TRABELSI ii

3 Avant Propos Ce travail a été effectué dans le cadre d un projet fin d études du cycle de formation d ingénieurs diplômés en télécommunications option Réseaux et Services Mobiles à l école supérieure de télécommunication de Tunis (Sup Com). Il a été réalisé au sein de l école. A ce titre, je tiens à exprimer ma profonde gratitude et mes sincères remerciements à mes deux encadreurs : Mr Sami TABBANE, professeur à Sup Com, et Mme Asma BEN LETAIFA, Ingénieur à Sup Com pour leur encadrement, leur disponibilité et les précieux conseils qu ils m ont prodigués tout au long de ce travail. Merci également au corps administratif et à tout le cadre enseignant de l école pour ne pas avoir épargné le moindre effort pour m informer et me documenter sur le plan théorique et pratique durant les trois années de ma formation à Sup Com. Mes vifs remerciements aux membres du jury pour l honneur qu ils me font en acceptant de juger ce travail. Du Fond du cœur, merci Walid TRABELSI ii

4 Listes des Abréviations 3GPP AIN API ATM CORBA CoS DPE EJB ETSI GCCS GPRS GPS GSM GUI H-OSA IN IP ISP ISV JAIN JCAT JCC JCP JSPA MG MGC MGCP MMS MSC NGN NRG Third-Generation Partnership Project Advanced Intelligent Network Application Programming Interface Asynchronous Transfer Mode Common Object Request Broker Architecture Class of Service Distributed Processing Environnement Enterprise JavaBeans European Telecommunications Standards Institute Generic Call Control Service General Packet Radio Service Global Positionning System Global System for Mobile Communication Graphic User Interface High Level Open Service Access Intelligent Network Internet Protocol Independent Service Provider Independent Software Vendors Java APIs for Interoperable Networks JAIN Coordination and Transaction JAIN Call Control Java Community Process Java Specification Participation Agreement Media Gateway Media Gateway Controller Media Gateway Controller Protocol Multimedia Message System Mobile Switching Centre Next Generation Network Network Ressource Gateway iii

5 OAM Operations, Administration and Maintenance OSA Open Service Access OSI Open System Interconnexion PNC Public Network Computing PSTN Public Switched Telephone Network QoS Quality of Service RTC Réseau Téléphonique Commuté SCE Service Creation Environnement SCF Service Capability Feature SCP Service Control Point SCS Service Capability Server SCSL Sun s Community Source code Licensing SDK Software Development Kit SG Signalling Gateway SIP Session Initiation Protocol SLA Service Level Agreement SLEE Service Logic Execution Environment SMS Short Message System SPA Service Provider APIs SS7 Signalisation System 7 SSP Signalisation Service point TDM Time Division Multiplexing UI User Interaction UL User Location UML Unified Modeling Language UMTS Universal Mobile Telecommunications System VASP Value Added Service Provider VPN Virtual Private Network WAP Wireless Application Protocol WDM Wave Division Multiplexing xdsl x Digital Subscriber Line XML extensible Markup Language iv

6 Table Des Matières Dédicaces...i Avant Propos...ii Listes des Abréviations...iii Table Des Matières...v Introduction Générale...1 Chapitre 1. Les Services des Réseaux de Nouvelle Génération...3 Introduction... 3 I. Architecture du réseau NGN La couche de transport La couche contrôle La Media Gateway (MG) Signalling Gateway (SG) Le serveur d appel ou Media Gateway Controller (MGC) La couche service... 6 II. Les services de la nouvelle génération Les caractéristiques des services NGN Les services spécifiques de NGN... 8 III. Architecture des services de la nouvelle génération Architecture en couches Interfaces des services ouvertes/api Intelligence du réseau distribué Conclusion Chapitre 2. Les Plateformes de Développement des Services 3G dans les Réseaux Radio Mobiles...15 Introduction I. Nouvelle Approche pour créer des services II. Les Plateformes de développement des services 3G JAIN: Java APIs for Interoperable Networks Initiative de JAIN Introduction Objectifs Architecture de la plateforme JAIN Topologie du réseau de JAIN Les Spécifications de JAIN Spécifications des Protocoles de JAIN Spécifications des Applications de JAIN OSA/Parlay Le Groupe Parlay Qu est ce qu OSA/Parlay? Architecture OSA/Parlay La structure des spécifications des APIs d OSA/Parlay III. Comparaison des deux plateformes : JAIN et OSA/Parlay JAIN v

7 1.1. Avantages Inconvénients OSA/Parlay Avantages IV. Choix de la plateforme OSA/Parlay Les raisons de choisir OSA/Parlay Les différentes Modèles d OSA/Parlay Modèle fonctionnel Modèle d affaire Conclusion Chapitre 3. Les Outils et les services nécessaires pour la création de l Application...35 Introduction I. Les Outils nécessaires à l application Network Ressource Gateway (NRG) La place de NRG dans OSA Ericsson High Level Open Service Access (H-OSA) Ericsson Network Resource Gateway NRG Software Development Kit (SDK) The NRG Framework Le cycle de vie d'un NRG Sevice Level Agreements (SLA) Obtenir l accès au service Ericsson NRG Simulator II. Les Services supportés par le NRG simulator Vue d ensemble Interaction d Utilisateur (User Interaction) Diagramme de Séquence Réception de Message Envoie de message avec erreur Envoie de message avec succès de réception Diagramme de Classe Classe d interface IpHosaUIManager Classe d interface IpAppHosaUIManager Localisation d Utilisateur (User Location) Diagramme de séquence Demande interactive de la localisation d utilisateur Demande du service avec erreur Demande périodique du service de localisation Diagramme de classe Classe d interface IpHosaUserLocation Classe d interface IpAppHosaUserLocation Conclusion Chapitre 4. Conception et Développement de l Application...55 Introduction I. Environnement utilisé pour le développement de l application Ericsson NRG Simulator vi

8 2. JDevelopper : Java II. Les étapes de développement de l application Envoie d un SMS Diagramme de séquence Description du fonctionnement du mécanisme d envoie d un SMS Localisation du Mobile Diagramme de séquence Description du fonctionnement du mécanisme de localisation du mobile Application Finale : Renvoie d un MMS Le diagramme de séquence Description du fonctionnement du mécanisme de l application finale III. Utilité de l application er Service : Demande des plus proches magasins par rapport à l endroit du mobile ème Service : Suivre la localisation d un autre mobile Conclusion Chapitre 5. Implémentation de l Application...71 Introduction I. Implémentation des différentes étapes de l application de messagerie er étape : Envoie d un SMS Interface développée sur JDevelopper (Java) Implémentation sur Ericsson NRG Simulator ème étape : Récupération de la localisation du mobile Interface développée sur JDevelopper (Java) Implémentation sur Ericsson NRG Simulator ème étape : Application finale Interface développée sur JDevelopper (Java) Implémentation sur Ericsson NRG Simulator II. Implémentation des services déduits de l application Implémentation du 1 er service : Demande des plus proches magasins par rapport à l endroit du mobile Implémentation du 2 ème service : Récupération de la localisation d un autre mobile avec autorisation d accès Conclusion Conclusion Générale...86 Bibliographie...87 vii

9 Liste des figures Figure 1.1: Architecture du réseau NGN...4 Figure 1.2: Exemples de services dans NGN...9 Figure 1.3: Contrôle de la nouvelle génération...12 Figure 1.4: Architecture en couches/ Interfaces des services ouvertes...13 Figure 2.1: La logique de service/ Séparation d infrastructure...16 Figure 2.2: Initiative de JAIN...18 Figure 2.3: Architecture de JAIN...19 Figure 2.4: Les APIs de JAIN...21 Figure 2.5: OSA/Parlay : Lien entre le réseau de télécommunication et les applications...24 Figure 2.6: Architecture OSA/Parlay...25 Figure 2.7: Le rapport entre les différentes composantes d OSA/Parlay...26 Figure 2.8: Interactions du Gateway d OSA/Paraly...27 Figure 2.9: Localisation possible des applications d OSA/Parlay...31 Figure 2.10: Les entités fonctionnelles d OSA/Parlay...32 Figure 2.11: Les entités d affaires dans OSA/Parlay...33 Figure 3.1: Le concept d OSA/Parlay...36 Figure 3.2: Le NRG fournissant un ensemble d'apis indépendant des réseaux fondamentaux...37 Figure 3.3: Vue d ensemble de SDK...38 Figure 3.4: Vue d ensemble du Framework...39 Figure 3.5: Diagramme de séquence de l Interaction du Framework, pour obtenir l accès au service...41 Figure 3.6: Vue de système du simulateur de NRG...42 Figure 3.7: Diagramme de séquence de réception d un message...44 Figure 3.8: Diagramme de séquence d envoie de message avec erreur...45 Figure 3.9: Diagramme de séquence d envoie de message avec succès de réception...46 Figure 3.10: Diagramme de séquence du service d interaction d utilisateur...47 Figure 3.11: Diagramme de séquence de la demande interactive de la localisation d utilisateur...50 Figure 3.12: Diagramme de séquence de la demande du service de localisation avec erreur...50 Figure 3.13: Diagramme de séquence de la demande périodique du service de localisation...51 Figure 3.14: Diagramme de séquence du service de localisation d utilisateur...52 Figure 4.1: Diagramme de séquence d envoie d un SMS...56 Figure 4.2: Diagramme de séquence de localisation du mobile...59 Figure 4.3: Diagramme de séquence de l application finale : Renvoie d un MMS...63 Figure 5.1: Interface de l application d envoie d un SMS...72 Figure 5.2: Résultat de l envoie d un SMS vue sur l interface Java...73 Figure 5.3: Résultat de l envoie d un SMS vue sur Ericsson NRG Simulator...73 Figure 5.4: Interface de l application de localisation de l utilisateur du mobile...74 Figure 5.5: Ajout du mobile et sa localisation sur la mappe d Ericsson NRG Simulator...75 Figure 5.6: Résultat de l application de la localisation du mobile vue sur l interface Java...76 Figure 5.7: Interface de l application finale du service de messagerie...77 Figure 5.8: Envoie d un SMS à partir de l émulateur mobile au service Figure 5.9: Récupération du MMS sur Ericsson NRG Simulator...79 Figure 5.10: Initialisation des composants du premier service...80 Figure 5.11: Résultat du premier service testé sur le simulateur...81 Figure 5.12: Initialisation des composants du deuxième service...82 Figure 5.13: Résultat du deuxième service testé sur le simulateur...83 Figure 5.14: Modification des composants du deuxième service...84 Figure 5.15: Résultat de la modification du deuxième service...84 viii

10 Introduction Générale Introduction Générale Traditionnellement, le développement des applications de télécommunication et les services étaient une partie du domaine d'opérateur de réseau, dont le personnel technique était intimement au courant des détails du réseau et des interfaces des propriétaires à l'équipement en service. Cependant, dans la dernière décennie, le monde des télécommunications a nettement changé, de sorte que naissent de nouveaux acteurs dits fournisseurs de service et/ou contenu chargés de produire de nouveaux services. Ainsi les opérateurs nécessitent de nouvelles plateformes de services permettant au créateur d'application de créer facilement et déployer rapidement des applications innovatrices. Ce besoin se traduit par le développement d interfaces de programmation d'application (APIs). Ces APIs fournissent des interfaces standards qui sont indépendantes de la technologie du réseau, offrent des services à valeur ajoutée faciles à utiliser et permettent à des applications d'accéder à la fonctionnalité du réseau de noyau. Ceci, désigné sous le nom de «Ouverture du réseau», permettra une large accessibilité à une grande communauté de réalisateurs. L ETSI (European Telecommunications Standards Institute), le groupe de Parlay et le 3GPP (Third Generation Partnership Project) ont collaboré pour définir conjointement une série d APIs standards connues comme l'accès ouvert de service (OSA) APIs. Les spécifications d'osa APIs normalisées sont structurées dans quinze parties. La conception et l'exécution de la cinquième partie «User Interaction (UI SCF)» et la sixième partie "Mobility SCF" seront considérées dans ce projet de fin d'études. Comme conséquence de cette collaboration, évoluent de nouveaux services rapides, rattachés aux services de messagerie, à des applications de commerce, à des applications basées sur la localisation, et des services de contrôle d'appel multiple, à des services portiques d'entreprise avancées, etc. Dans ce cadre intervient notre projet de fin d étude dont l'objectif est de développer une application de messagerie faisant intervenir des médias interactifs, manipulant des réseaux de nouvelles générations et offrant des interfaces flexibles développées en Java conformes à la conception OSA. Ce projet passe par les étapes suivantes : Une étude des réseaux de nouvelles générations NGN ainsi que les plateformes de développement des services. Une comparaison entre les plateformes qui aboutira au choix de l outil de développement de notre application. Enfin, une conception et un développement d un service de messagerie. Ce projet de fin d étude est constitué par cinq chapitres. Le premier chapitre introduit des concepts de base des réseaux NGN ainsi que l approche des nouveaux services. Le chapitre suivant présente une étude des plateformes de développement de services de 3 ème génération dans les réseaux mobiles et suite à une comparaison entre ces plateformes nous allons justifier le choix de retenir l une des plateformes pour notre travail. Le troisième chapitre montre tous Ingénieurs 2006 Trabelsi.Walid 1

11 Introduction Générale les outils nécessaires pour la création de notre application. Ensuite, un quatrième chapitre est consacré à la conception et au développement de l application présentant le détail de toutes les étapes de la réalisation ainsi que des exemples de services à développer à partir de notre application. Terminons par un cinquième chapitre, présentant les différentes implémentations de l application ainsi que les services créés mettant en œuvre l utilité de l application réalisée au cours du projet. Ingénieurs 2006 Trabelsi Walid 2

12 Chapitre 1 : Les services des réseaux de nouvelles générations Chapitre 1. Les Services des Réseaux de Nouvelle Génération Introduction L évolution progressive du monde des télécommunications vers des réseaux et des services de nouvelle génération est aujourd hui une tendance forte qui suscite l intérêt d une majorité d acteurs. Elle résulte de la conjonction d un ensemble de facteurs favorables comme les évolutions profondes du secteur des télécommunications, le développement de gammes de nouveaux services, et les progressions technologiques d envergure dans le domaine des réseaux de données. Il en résulte de ce contexte et afin de s adapter aux grandes tendances qui sont la recherche de souplesse d évolution de réseau, la distribution de l intelligence dans le réseau, et l ouverture à des services tiers, une évolution vers un nouveau modèle de réseaux et de services appelé NGN (Next Generation Networks) [1]. Les NGN sont basés sur une évolution progressive vers le «tout IP» et sont modélisés en couches indépendantes dialoguant via des interfaces ouvertes et normalisées. Les réseaux de télécommunications traditionnels évolueront vers un modèle ouvert, distribué, fortement basé sur le protocole IP et la transmission en mode paquet en général. Cette évolution technologique se fera de manière progressive pour les opérateurs et transparente pour les utilisateurs. Ce premier chapitre présentera une étude technologique afin de décrire et comprendre l ensemble des nouveaux concepts globalement désignés sous l appellation NGN. Il inclut aussi une synthèse des évolutions technologiques majeures et le détail des concepts des services liés au NGN. I. Architecture du réseau NGN Les réseaux de nouvelle génération peuvent être présentés comme un concept permettant de définir et déployer des réseaux évolutifs et favorisant pour les fournisseurs de services et les opérateurs la création et la gestion de services innovants. Les services doivent être évolutifs et accessibles indépendamment du réseau d accès utilisé. Le NGN est caractérisé par plusieurs éléments essentiels: Un coeur de réseau unique et mutualisé pour tous types d accès et de services. Une architecture du coeur de réseau en 3 couches : Transport, Contrôle et Services. Une évolution du transport en mode paquet (une convergence progressive vers le tout IP). Ingénieurs 2006 Trabelsi Walid 3

13 Chapitre 1 : Les services des réseaux de nouvelles générations Figure 1.1: Architecture du réseau NGN Des interfaces ouvertes et normalisées entre chaque couche, et notamment au niveau des couches contrôle et services afin de permettre la réalisation de services indépendants du réseau. Le support d applications multiples, multimédia, temps réel, en mobilité totale, adaptables à l utilisateur et aux capacités des réseaux d accès et des terminaux. La prise en compte de réseaux d accès multiples. La prise en compte de terminaux multiples. 1. La couche de transport La couche Transport gère l acheminement du trafic vers sa destination. Les principales évolutions du réseau de transport concernent les technologies de transmission et de commutation utilisées sur les liaisons qui interconnectent les réseaux d accès au coeur de réseau. La question qui se pose c est comment les backbones sont susceptibles d évoluer afin de supporter le très haut débit, et surtout le transport unifié de flux mixtes voix/donnée/multimédia avec la qualité de service adéquate. Tout d abord il faut distinguer entre le niveau réseau de transmission et le niveau réseau de commutation dans un «réseau de transport» (couche transport) Le réseau de transmission correspond au réseau physique de liens et de noeuds qui desservent une zone (un immeuble, une ville, une région, un pays ou un continent). Le réseau de commutation correspond à certains noeuds qui permettent d acheminer une communication à travers le réseau de transmission en fonction de sa destination. Dans les architectures traditionnelles, un opérateur possède (ou loue) un réseau de transmission sur lequel s appuient en général plusieurs réseaux de commutation, l un dédié à la commutation de la voix, l autre dédié à la commutation de données. L idée qui sous-tend Ingénieurs 2006 Trabelsi Walid 4

14 Chapitre 1 : Les services des réseaux de nouvelles générations les NGN est de fusionner ces deux réseaux en un seul. Si l on visualise les technologies mises en jeu en s appuyant sur le modèle en couches OSI (Open System Interconnexion), la séparation entre réseau de transmission et réseau de commutation est très nette. Pour la mise en oeuvre de ces réseaux de transport «de nouvelle génération», on peut mettre en évidence deux évolutions majeures des réseaux de transport au niveau des réseaux de transmission et des réseaux de commutation. Concernent les réseaux de transmission, les techniques dominantes sont remises en cause. En effet, le multiplexage TDM (Time Division Multiplexing), utilisée en grande majorité dans les réseaux actuels, est une technique de transmission adaptée pour la commutation de circuits alors que la tendance actuelle est de migrer les réseaux de transmission actuels vers un réseau de transmission unique, neutre, voire favorable à la commutation de paquets et donc on assiste aujourd hui à des nombreux développements autour du multiplexage WDM ( Wave Division Multiplexing) et aussi à des plusieurs évolutions liées à l optique et au WDM. Concernent les réseaux de commutation, La tendance actuelle est donc de développer un réseau de commutation unique, s appuyant sur l actuel réseau de commutation de paquets, et qui permettrait de transporter tout type de trafic (voix, vidéo, donnée, etc.). Concernant la Commutation IP, La tendance actuelle est la migration d IPv4 à IPv6. Les principales améliorations de cette dernière version sont l amélioration du champ ToS renommée CoS pour Classe of Service, l intégration par défaut du protocole de sécurité IPsec (Internet Protocol Security), une nouvelle définition des adresses de diffusion, ainsi que l intégration par défaut et l amélioration des mécanismes de traitement de ces adresses au niveau des commutateurs. L objectif de ces différentes évolutions est de répondre à quatre impératifs : l adéquation aux nouveaux besoins de services, le support de très haut débit, une garantie de qualité de service, et une gestion optimisée du réseau de transport. 2. La couche contrôle Les évolutions au niveau de la couche contrôle sont majeures. Plusieurs nouveaux mécanismes et protocoles sont mises en jeu et donc une nouvelle architecture qui découle. La couche contrôle se compose de serveurs dits «softswitch» gérant d une part les mécanismes de contrôle d appel (pilotage de la couche transport, gestion des adresses), et d autre part l accès aux services (profils d abonnés, accès aux plates-formes de services à valeur ajoutée). Les entités fonctionnelles du coeur de réseau NGN sont les suivantes : 2.1. La Media Gateway (MG) Les Gateways ont un rôle essentiel : elles assurent non seulement l acheminement du trafic, mais aussi l inter fonctionnement avec les réseaux externes et avec les divers réseaux d accès. La Media Gateway est située au niveau du transport des flux média entre le réseau RTC et les réseaux en mode paquet, ou entre le coeur de réseau NGN et les réseaux d accès. Elle a pour rôle le codage et la mise en paquets du flux média reçu du RTC et vice-versa (conversion du trafic TDM IP). Et aussi la transmission, suivant les instructions du Media Gateway Controller (MGC), des flux média reçus de part et d'autre Signalling Gateway (SG) Ingénieurs 2006 Trabelsi Walid 5

15 Chapitre 1 : Les services des réseaux de nouvelles générations La fonction Signalling Gateway a pour rôle de convertir la signalisation échangée entre le réseau NGN et le réseau externe interconnecté selon un format compréhensible par les équipements chargés de la traiter, mais sans l interpréter (ce rôle étant dévolu au Media Gateway Controller). Notamment, elle assure l adaptation de la signalisation par rapport au protocole de transport utilisé. Cette fonction est souvent implémentée physiquement dans le même équipement que la Media Gateway, d où le fait que ce dernier terme est parfois employé abusivement pour recouvrir les deux fonctions MG + SG Le serveur d appel ou Media Gateway Controller (MGC) Dans un réseau NGN, c est le MGC qui possède «l'intelligence». Il gère : L échange des messages de signalisation transmise de part et d'autre avec les passerelles de signalisation, et l interprétation de cette signalisation. Le traitement des appels : dialogue avec les terminaux H.323, SIP, MGCP, communication avec les serveurs d application pour la fourniture des services. Le choix du MG de sortie selon l'adresse du destinataire, le type d'appel, la charge du réseau, etc. La réservation des ressources dans le MG et le contrôle des connexions internes au MG (commande des Media Gateways). Donc dans l architecture des réseaux NGN, le serveur d appel, aussi appelé Softswitch ou Media Gateway Controller (MGC) est le noeud central qui supporte l intelligence de communication. 3. La couche service Actuellement, les services sont dédiés à un type de réseau : services Réseau Intelligent sur le réseau téléphonique pour les terminaux téléphoniques (fixes ou mobiles), et services mail, web, news sur les réseaux IP. L apparition des nouveaux réseaux d accès, tels que l UMTS, le GPRS, l xdsl, l Ethernet longue distance, et la multiplication des terminaux communicants (téléphone mobile GPRS/ UMTS, PDA, ) et la convergence des coeurs de réseaux, poussent à une transformation de l architecture des plates-formes de services. Cette nouvelle architecture doit offrir la possibilité aux clients d accéder aux services, quelle que soit la nature des terminaux et le type de protocole utilisé pour accéder aux plates-formes de services, via un réseau de transport unifié, en mode paquet. Le service rendu doit être adapté aux besoins et aux moyens des clients. Deux modèles principaux et complémentaires émergent de ces besoins d évolution d architecture de la couche service. Une architecture centrée sur le «Softswitch», basée sur l interface de services normalisée du modèle OSA/Parlay et un modèle orienté «Web Services», basé sur les technologies et des protocoles issus du monde Internet. Ingénieurs 2006 Trabelsi Walid 6

16 Chapitre 1 : Les services des réseaux de nouvelles générations II. Les services de la nouvelle génération 1. Les caractéristiques des services NGN Bien qu'il soit difficile de prévoir ce que seront les prochaines applications, nous pouvons impliquer les types de caractéristiques de service et les possibilités qui seront importantes dans l'environnement de NGN en examinant les services courants liés à l'industrie tendent. Il est certainement vrai qu il y a un passage des réseaux basés sur le Time Division Multiplex (TDM) aux réseaux basés sur les cellules. Cela est faite en passant des réseaux avec le mode de commutation de circuit au mode de commutation de paquet. Cependant, ces changements des réseaux de transport sont simples par rapport aux changements que nous verrons au niveau de service. La poussée principale des fournisseurs de service traditionnels de réseau a été d'offrir au marché grand public basé sur le transport d'information entre les utilisateurs, avec de diverses possibilités à valeur ajoutée. Ces services ont tendu à impliquer des appels de voix à bande étroite, avec une simple connexion point à point par appel. Cependant, cette vue des services change rapidement pendant que les économies mondiales deviennent de plus en plus dépendantes sur l'information comme ressource de base. Tandis que les services existants demeureront une partie des offres de fournisseurs de service, les espérances des clients émigreront vers des multimédia à bande large plus avancés et des services intensifs de l'information. Les utilisateurs agitent l'un sur l'autre avec le réseau et puissent choisir parmi un éventail de Quality-of-Service (QoS) et de largeur de bande. À l'avenir, l'intelligence de réseau ne se reliera pas simplement à l'acheminement des connexions basés sur des consultations simples de base de données, mais peut prendre une signification beaucoup plus large (par exemple, gestion de session de multimédia, coordination des connexions multitechnology, gestion et les opérations intelligentes, sécurité avancée, véritables agents d'utilisateur et proxy agents). L'évolution courante des services de télécommunication se dirige à un monde où les fournisseurs de service auront la flexibilité de se concentrer sur le micro-marketing. Les décisions de leurs offres de service peuvent avoir autant à faire avec l'empaquetage (par exemple, évaluation, vente, et convenance), comme elles sont avec des services réels offerts. En tant que porteurs multiples, les fournisseurs de service, les fournisseurs d'équipement, et d'autres entités tous d'affaires deviennent impliqués en fournissant des services aux utilisateurs et les systèmes d'affaires deviendront de plus en plus importants. Le but primaire sera de permettre aux utilisateurs d'obtenir le contenu de l'information qu'ils veulent, dans tous les formats des médias, au-dessus de n'importe quels équipements, n'importe où, et en n'importe quel volume. Basé sur les tendances mentionnées ci-dessus, ce qui suit est un sommaire de plusieurs caractéristiques de service probablement à être importantes dans un environnement de NGN : Communications omniprésentes, en temps réel et multimédia - le seul espoir pour augmenter la fidélité, apparenté à communiquer chez la personne, Ingénieurs 2006 Trabelsi Walid 7

17 Chapitre 1 : Les services des réseaux de nouvelles générations est nécessaire pour l'accès à grande vitesse et le transport, n'importe où, et en n'importe quel volume. Davantage «intelligence personnelle» distribuée dans tout le réseau - ceci inclut les applications qui peuvent accéder aux profils personnels des utilisateurs (par exemple, préférences personnelles et inscription de l'information d'abonnement), pour apprendre de leur comportement a modelé, et exécute des fonctions spécifiques. Plus de «intelligence de réseau» distribuée dans tout le réseau - ceci inclut les applications auxquelles, permettez l'accès, et commandez les services de réseau, le contenu, et les ressources. Il peut également exécuter des fonctions spécifiques au nom d'un fournisseur de service ou de réseau (par exemple, «agents de gestion» des ressources de ce réseau de moniteur, rassembler des données d'utilisation, fournir le dépannage, ou sponsoriser nouveaux services/contenu d'autres fournisseurs). Plus de simplicité pour les utilisateurs - ceci protège les utilisateurs de la complexité du rassemblement, du traitement, de la personnalisation, et du transport de l'information. Il leur permet la facilité d'accès aux services de réseau et utilisent les services et le contenu du réseau, y compris des interfaces utilisateur qui tient compte des interactions normales entre les utilisateurs et le réseau. Il implique de fournir des contextes sensibles (options/aide/information) contrôlant d'une manière transparente des interactions parmi des services multiples fournissant des menus différents pour les services. Gestion personnelle des services - ceci implique la capacité des utilisateurs de contrôler leurs profils, information personnels de services de réseau de disposition individuel, utilisation de moniteur et information de facturation, d'adapter leurs interfaces utilisateur et la présentation et le comportement de leurs applications, et de les créer aux besoins du client. Gestion de l'information intelligente - ceci aide les utilisateurs à contrôler la surcharge de l'information en leur donnant la capacité de rechercher et filtrer le contenu de filtre, de contrôler des messages ou des données de n'importe quel milieu, et de contrôler l'information personnelle (par exemple, calendrier, liste de contact, etc.). 2. Les services spécifiques de NGN Heureusement, l'architecture de la nouvelle génération de service permettra un certain nombre de dispositifs principaux qui peuvent être particulièrement bénéficiaires à une grande sélection de services potentiels. Une variété de services [2], certains déjà disponible, d'autres toujours à l'étape conceptuelle, a été liée aux initiatives de NGN et aux candidats probables considérés pour des réalisations de NGN. Tandis que certains de ces services peuvent être offerts sur les plateformes existantes, d'autres tirent bénéfice de la commande avancée, de la gestion, et de signaler des possibilités de NGN. Bien que l'émergence et les nouveaux services soient susceptibles d'être les conducteurs les plus forts pour NGN, la plupart des bénéfices initiaux de NGN peuvent réellement résulter de l'empaquetage des services traditionnels. Ainsi, les services traditionnels empaquetés payeront le réseau, tandis que les services naissants rempliront de combustible la croissance. La plupart des services traditionnels se relient aux services d'accès, de transport, d'acheminement et de commutation basé sur les services de contrôle de session, de Ingénieurs 2006 Trabelsi Walid 8

18 Chapitre 1 : Les services des réseaux de nouvelles générations connectivité et des ressources, et aux divers services à valeur ajoutée. La volonté de NGN permet probablement un choix beaucoup plus large de types de service, incluant : Services spécialisés des ressources (par exemple, fourniture et gestion des transcodeurs, des ponts de communication de multimédia, des unités de conversion de médias, des unités d'identification de voix, etc.) Services de traitement et de stockage (par exemple, fourniture et gestion des unités de stockage de l'information pour la transmission de messages, les serveurs d'archivage, les serveurs terminaux, les plateformes d'os, etc.) Services de logiciel personnalisé (par exemple, appellation, sponsoriser, sécurité, autorisation, transactions, etc.). Services spécifiques à l'application (par exemple, applications d'affaires, applications d'e-commerce, jeux vidéo interactifs, etc.) Services contents de disposition qui fournissent ou sponsorisent le contenu de l'information (par exemple, formation électronique, services de poussée de l'information, etc.) Services réagissants réciproquement pour des interactions avec d'autres types d'applications, services, réseaux, protocoles, ou formats (par exemple, traduction). Les services de gestion à maintenir, actionner et contrôler des communications/réseaux informatiques et des services. Le schéma au dessous donne une description de plusieurs services que nous croyons actuellement seront les conducteurs importants dans l'environnement de NGN. Nous avons intentionnellement inclus une large gamme des services (par exemple, de la téléphonie de base de voix à des services plus futuristes tels que la réalité virtuelle distribuée) pour souligner que l'architecture de la nouvelle génération de service soutiendra une grande variété de services. Figure 1.2: Exemples de services dans NGN Ingénieurs 2006 Trabelsi Walid 9

19 Chapitre 1 : Les services des réseaux de nouvelles générations Téléphonie de voix : Le besoin probable de volonté de NGN de soutenir de divers services existants de téléphonie de voix (par exemple, appel en attente, renvoi d'appel, 3- chemin d'appel et divers dispositifs d'ain). Cependant, que NGN n'essaie pas de reproduire chaque service traditionnel de téléphonie de voix actuellement offert. Plutôt, il essayera probablement de soutenir seulement un petit pourcentage de ces services traditionnels, avec un premier foyer sur les dispositifs de téléphonie de voix commercialisable et les dispositifs exigés d'une perspective de normalisation. Services de données (connectivité) : Tient compte de l'établissement en temps réel de la connectivité entre les points terminaux, avec de divers dispositifs à valeur ajoutée (par exemple, largeur de bande, fiabilité de connexions et des connexions virtuels commutés résilients, et gestion de largeur de bande et contrôle d'admission d'appel). Services de multimédia : Permet aux parties multiples d'agir l'un sur l'autre en utilisant la voix, la vidéo, et/ou les données. Ceci permet aux clients de converser les uns avec les autres tout en montrant l'information visuelle. Il tient compte également du calcul de collaboration. Réseau privé virtuel (VPN :Virtuel Private Network) : La voix sur les VPN améliorent les possibilités de gestion de réseau d'inter location des entreprises en laissant des organismes géographiquement dispersés pour combiner leurs réseaux privés existants avec des parties du PSTN, de ce fait fournissant à des abonnés des possibilités uniformes. Les données VPN fournissent les dispositifs supplémentaires de sécurité et de gestion de réseau qui permettent aux clients d'employer un réseau partagé d'ip comme VPN. Public Network Computing (PNC) : Fournit des services de calcul pour des entreprises et des consommateurs. Par exemple, le fournisseur de réseau public pourrait fournir des capacités génériques de traitement et de mémoire (par exemple, pour accueillir une page Web, stockent et maintiennent des fichiers de données, ou exécutent une application de calcul). Le fournisseur de réseau public veut charger les utilisateurs pour le traitement et le stockage utilisés, mais n'aurait aucune connaissance du contenu spécifique d'application. Alternativement, le fournisseur de réseau public pourrait fournir aux applications spécifiques d'affaires (par exemple, planification de ressource d'entreprise (ERP), temps rapporté etc.) ou aux applications du consommateur (par exemple, réduction des impôts), l'ensemble ou une partie du traitement et stockage se produisant dans le réseau. Transmission de messages unifiée : Soutient la livraison de l'audio messagerie, de l' , du courrier de fax, et des pages par les interfaces communes. Par telles interfaces, les utilisateurs accéderont, comme soyez avisé de divers types de message (audio messagerie, , courrier de fax, etc.), indépendant des moyens de l'accès (c à d, câble ou téléphone portable, ordinateur, ou dispositif de données sans fil). Courtage de l'information : Implique d'annoncer, trouver, et fournir des informations pour relier les consommateurs aux fournisseurs. Par exemple, les consommateurs pourraient recevoir l'information basée sur des critères pré spécifiés ou basée sur des préférences et des modèles personnels de comportement. E-commerce : Permet à des consommateurs d'acheter des marchandises et des services électroniquement à travers le réseau. Ceci pourrait inclure, traiter les transactions, vérifier l'information de paiement, fournir la sécurité, et probablement le commerce (c.-à-d., les acheteurs et les vendeurs étant assortis qui négocient les «commerces» pour des Ingénieurs 2006 Trabelsi Walid 10

20 Chapitre 1 : Les services des réseaux de nouvelles générations marchandises ou des services). Les opérations bancaires à la maison et les achats à la maison entrent dans cette catégorie des services. Services des centraux d'appel : Un abonné pourrait placer un appel à un agent de centre d'appel en cliquant sur une page Web. L'appel pourrait être conduit à un agent approprié, qui pourrait être localisé n'importe où, même à la maison (c.-à-d., des centres d'appel virtuel Des appels de voix et les messages d' ont pu être alignés uniformément pour les agents. Les agents auraient l'accès électronique au client, au catalogue, aux actions, et à l'information de commande, qui pourrait être transmise dans les deux sens, entre le client et l'agent. Jeu interactif : offrent aux consommateurs une manière de se réunir en ligne et d'établir des sessions interactives de jeu (par exemple, jeux vidéo). Réalité virtuelle distribuée : Se rapporte aux représentations technologiquement produites des événements réels, des personnes, des endroits, des expériences, etc., dans lesquels les participants et les fournisseurs de l'expérience virtuelle sont physiquement distribués. Ces services exigent la coordination sophistiquée des ressources multiples et diverses. Home Manager : Avec l'arrivée de la gestion de réseau à la maison et les appareils intelligents, ces services ont pu surveiller et commander des systèmes de sécurité à la maison, des systèmes d'énergie, des parcs de divertissements à la maison, et d'autres appareils ménagers. III. Architecture des services de la nouvelle génération Beaucoup d'applications existantes ont été développées pour un type spécifique de transport. Pour des porteurs souhaitant soutenir un établi de limite des applications au-dessus d'un nombre limité de mécanismes de transport, cette stratégie est proportionnée. Cette approche pourrait même fournir une meilleure exécution, fiabilité, etc. puisque la plateforme est travaillée pour chaque combinaison spécifique d'application/transport. Cependant, à mesure que le nombre d'applications et de types de transport augmente, l'approche peut devenir tout à fait inefficace pour fournir les mécanismes spécialisés pour le contrôle de session, la contrôle de connectivité, le logiciel personnalisé, la signalisation, etc. Comme c est illustré dans la figure au dessous, un des buts primaires de NGN est de fournir un terrain commun, unifié, et l'environnement de contrôle flexible qui peut soutenir les types multiples des services et de types multiples d'excédent d'applications de gestion de transport. Cette section décrit trois caractéristiques critiques de cet environnement de contrôle de la nouvelle génération. Ingénieurs 2006 Trabelsi Walid 11

21 Chapitre 1 : Les services des réseaux de nouvelles générations Figure 1.3: Contrôle de la nouvelle génération 1. Architecture en couches Le concept de l'architecture en couche est central aux environnements de NGN. En premier lieu, NGN sépare proprement le service et le contrôle de session des éléments fondamentaux de transport. Ceci permet à des porteurs de choisir (pour leurs situations particulières) des éléments de transport indépendants du logiciel de gestion. Comme illustré dans la figure suivante, le contrôle de NGN peut alors être décomposé en contrôle de dispositif, contrôle de service et de session, et contrôle de connectivité. La séparation propre entre l'accès, le service, et le contrôle de session des communications dans la couche de service permet chacun des types de session d'être traité indépendamment des autres. Ainsi, des sessions multiples de service peuvent être commencées à partir d'une session simple d'accès. De même, des sessions de communications peuvent être traitées séparément de la session globale de service qu'elles font partie. D'une manière plus importante, ces séparations tiennent compte pour que des services soient développés indépendamment à partir des considérations fondamentales de transport et de connectivité. Ainsi, les développeurs de service ne devront plus savoir n'importe quoi au sujet du type de transport utilisé pour les services qu'ils développent. Ingénieurs 2006 Trabelsi Walid 12

22 Chapitre 1 : Les services des réseaux de nouvelles générations Figure 1.4: Architecture en couches/ Interfaces des services ouvertes 2. Interfaces des services ouvertes/api Le schéma au dessus montre également un autre attribut essentiel de l'architecture de la nouvelle génération de service (c.-à-d., sa confiance dans l'architecture et les interfaces ouvertes). En particulier, un environnement ouvert de développement basé sur une interface de programmation d'application (API) permettra à des fournisseurs de service, à de tiers créateurs d'application, et potentiellement à des utilisateurs de créer et présenter rapidement des applications. Ceci expédiera l'introduction de nouveaux services en donnant à des fournisseurs de service plus de contrôle du procédé et tiendra compte de la réutilisation des composants existants d'application. Il ouvrira également les occasions pour créer et fournir des services à une plus large assistance. Notre capacité d'offrir de nouveaux services sera seulement limitée par nos imaginations. 3. Intelligence du réseau distribué Dans un environnement de services NGN, la portée des services commercialisable peut être considérablement prolongée pour inclure une variété beaucoup plus riche de services et d'intelligence associée de réseau. L'environnement de traitement distribué de NGN (DPE : Distributed Processing Environment) désaccouplera cette intelligence des éléments physiques de réseau. Ainsi, l'intelligence du réseau peut être distribuée aux endroits les plus appropriés dans le réseau. Par exemple, l'intelligence du réseau pourrait résider sur les serveurs tout usage exécutant les composants requis pour un service particulier, sur les serveurs qui exécutent des fonctions spécifiques (par exemple, les points de commande de service [SCPs], les périphériques intelligents, et entretient des noeuds dans un environnement d'ain), ou sur des dispositifs de bord près du consommateur. Des possibilités fonctionnelles ne seront plus couplées aux éléments physiques de réseau. Ingénieurs 2006 Trabelsi Walid 13

23 Chapitre 1 : Les services des réseaux de nouvelles générations Conclusion Globalement, l évolution vers les NGN représente encore à ce jour un sujet relativement amont, notamment du point de vue des opérateurs que dans une moindre mesure des purs fournisseurs de services. Il ressort du présent premier chapitre que l évolution vers les NGN devient une nécessité pour créer et développer de nouveaux services. Cela explique une certaine frilosité des créateurs interrogés vis-à-vis des solutions NGN (vision orientée vers une «transition douce» plutôt qu une «révolution» des réseaux et services), c est pourquoi il y avait l apparition de nouvelles plateformes de développement de services des nouvelles générations de réseau mobile qui sera le deuxième chapitre de ce projet. Ingénieurs 2006 Trabelsi Walid 14

24 Chapitre 2 : Les plateformes de développement des services 3G dans les réseaux radio mobiles Chapitre 2. Les Plateformes de Développement des Services 3G dans les Réseaux Radio Mobiles Introduction La croissance du domaine de l'industrie de télécommunications a devenu aujourd'hui de plus en plus rapide. Ce développement est principalement dû à l'introduction de nouveaux services révolutionnaires. La transmission de données dans les téléphonies mobiles a causé un grand impact sur les manières de communication des personnes. Récemment, la signification du terme «service de télécommunications» s'est élargie. Les traditionnels services de téléphonie de la parole (fixe et mobile) deviennent insuffisants dans le domaine de télécommunications. Les nouveaux acteurs incluent les services de SMS, MMS, WAP, interaction d'utilisateur (par exemple opérations bancaires virtuelles, vote), micro paiement, et les services de localisation. Les gens sont plus disposés à utiliser leurs dispositifs (par exemple téléphones portables) pour traiter de nouvelles tâches. En outre, ils exigent pour de nouveaux services. Traditionnellement, le monde de télécommunications a été tout à fait hermétique. De nouveaux services sont déployés à l'intérieur des domaines de télécommunication par un nombre limité d'ingénieurs de télécommunication. Habituellement, les solutions ne sont pas portatives et sont développées à l'aide des outils hautement spécialisés. A nos jours, il y avait eu plusieurs changements de l'organisation entière du monde de télécommunication. Des nouvelles entreprises apparaissent dans ce domaine et par suite le nombre d ingénieurs augmente dans ce secteur qui résulte une amélioration des services. C est pourquoi ces entreprises sont très utiles dans le domaine de Télécom. En plus les opérateurs des réseaux mobiles ont besoin de ces nouvelles entités ainsi que l ouverture de leurs plateformes de services. Ces nouvelles sociétés ne possèdent pas toujours leur propre infrastructure (qui est déjà établie), mais développent leurs nouvelles manières à exister. Donc il y aura nécessaire d utiliser des interfaces de programmation d applications de l architecture ouverte d OSA (Open Service Access). Dans ce chapitre nous allons présenter les différents plateformes de services de nouvelles générations dans le secteur de télécommunication qui permettent la création et le développement des services dans les réseaux radio mobiles. En plus, nous prouvons les raisons pour lesquelles nous avons choisi la plateforme OSA/Parlay comme moyen pour développer notre application. I. Nouvelle Approche pour créer des services Récemment, il n'y avait aucune manière simple de permettre les fournisseurs de service à valeur ajoutée indépendants (VASPs), parfois désignés sous le nom des fournisseurs de service indépendants (ISPs), à offrir leurs services directement par le réseau de télécommunications [3]. Il s'est produit de temps en temps, mais le VASP a dû intégrer son système avec les systèmes internes de télécommunication (par exemple avec des points de Ingénieurs 2006 Trabelsi Walid 15

25 Chapitre 2 : Les plateformes de développement des services 3G dans les réseaux radio mobiles contrôle de service en cas de réseau intelligent). Ceci a négativement affecté la flexibilité de VASP en créant de nouveaux services. Maintenant, il est devenu évident qu'il n'était pas possible sans «l ouverture du réseau», c.-à-d. permettant des entités en dehors du domaine de l'opérateur de télécommunications commandant les ressources de l'opérateur. Bien sûr, à un certain degré limité et maniable. L'idée décrite ici est la «logique de service» qui a localisé les domaines de télécommunication extérieurs. Le vrai service est alors basé dans le système séparé et (de façon ou d'autre) emploie l'infrastructure de télécommunication. Ceci est décrit dans la figure au dessous. Figure 2.1: La logique de service/ Séparation d infrastructure Les fournisseurs de service à valeur ajoutée (VASP) résident à la partie supérieure de la figure. Ils offrent leurs services spécialisés aux utilisateurs de réseau de télécommunications (la partie inférieure de la figure). L'opérateur de télécommunication est maintenant employé comme genre de courtier. Pour employer l'infrastructure de l'opérateur, les VASPs utilisent un certain ensemble de dispositifs de base. Ces dispositifs montrent aux VASPs un modèle, qui représente certaines parties fonctionnelles de réseau de télécommunications. Par exemple, un tel dispositif peut donner l'occasion au VASP d'agir l'un sur l'autre avec des utilisateurs à fin d'obtenir l'accès aux bases de données de VASP ou localisent l'utilisateur (pour trouver le plus proche bureau, banque,..). Les avantages sont évidents : d'une part, les VASPs peuvent offrir leurs services dans un nouveau milieu, d'autre part, l'opérateur de télécommunication peut augmenter son revenu de l'utilisation de son infrastructure. Ingénieurs 2006 Trabelsi Walid 16

26 Chapitre 2 : Les plateformes de développement des services 3G dans les réseaux radio mobiles D'ailleurs, l'offre des services par les VASPs peut être trop coûteuse ou même impossible pour que l'opérateur se déploie. Ceci semble être chacun gagne le jeu. Néanmoins, l'inconvénient principal peut être la sécurité de l'infrastructure de l'opérateur. II. Les Plateformes de développement des services 3G La nouvelle approche pour développer les services de la prochaine génération pour les réseaux mobiles 3G est basée sur les plateformes de développements de services de nouvelles générations. Parmi ces plateformes, on trouve l approche JAIN et OSA/Parlay qui seront détaillée dans ce chapitre. Ces Plateformes sont basées sur des concepts d'ouverture du réseau de télécommunications dans lequel il y a un besoin accru de fournir des services de valeur ajouté aux clients des réseaux mobiles 3G. Ils permettront aussi l'approvisionnement d'une gamme étendue de services fusionnant des dispositifs de voix et de données. Elle offre les avantages potentiels aux actionnaires en permettant à des services d'application de faire une meilleure utilisation des fonctions de réseau. 1. JAIN: Java APIs for Interoperable Networks 1.1. Initiative de JAIN Introduction JAIN [4] est une plateforme de service des réseaux de nouvelles génération et c est une extension du noyau de la plateforme Java avec des APIs Java nécessaires au développement de services télécoms de prochaine génération. JAIN apportent aux réseaux intégrés la portabilité de service, la convergence, et fixent l'accès de réseau à la téléphonie et aux réseaux informatiques. En fournissant un nouveau niveau d'abstraction et les interfaces Java associé pour la création de service à travers le Public Switched Telephone Network (PSTN), packet (par exemple Internet Protocol (IP) ou Asynchronous Transfer Mode (ATM)) et les réseaux sans fil, la technologie JAIN permet l'intégration de l'internet et des protocoles du réseau intelligent (IN). Ceci désigné sous le nom des réseaux intégrés. En outre, en permettant aux applications de Java la sécurité d'accès aux ressources à l'intérieur du réseau, l'occasion est crée pour fournir des milliers de services plutôt que les douzaines actuellement disponibles. Ainsi, la technologie de JAIN a changé le marché de télécommunications basé sur les systèmes fermés de propriété industrielle en architecture de réseau simple où les services peuvent être rapidement créés et déployés. La technologie de JAIN est indiquée comme une extension de la communauté à la plateforme de Java. Le développement est effectué en vertu de l'accord de Sun s Java Specification Participation Agreement (JSPA), Java Community Process (JCP), and Sun s Community Source Code Licensing (SCSL) L'initiative de JAIN se compose de deux domaines du développement décrit sur la figure au dessous : les interfaces des protocoles : spécifient les environnements d exécution de services et les APIs de la couche protocolaire. Ingénieurs 2006 Trabelsi Walid 17

27 Chapitre 2 : Les plateformes de développement des services 3G dans les réseaux radio mobiles les spécifications des applications : spécifient les APIs exigés pour la création de service avec le Framework de Java accordé à travers toutes les spécifications des protocoles. Figure 2.2: Initiative de JAIN Objectifs L'objectif de l'initiative de JAIN est de créer des chaînes de valeur ouvertes allant des fournisseurs de service, des fournisseurs de télécommunication, et des fournisseurs d'équipement de réseau aux fabricants d équipements informatique de télécom. L'initiative de JAIN prend le marché de la télécommunications/internet de beaucoup de systèmes fermés de propriété industrielle à un environnement ouvert simple capable d'accueillir une grande variété de services. En ouvrant le réseau aux applications de Java, l'occasion est créée de fournir des milliers de services portatifs et intégrés plutôt que des douzaines actuellement disponibles. Java et les technologies de JAIN permettront à des porteurs d étendre les services et de les rendre plus riches en disposition. La technologie de JAIN rend la prochaine génération pour le développement des applications de télécommunication plus rapide, plus simple et moins cher par l'utilisation de la technologie de Java. L'architecture de la prochaine génération fournie par la technologie JAIN crée un nouveau champ pour déployer de nouveaux services. Ce modèle est mieux servi quand tous les niveaux de réseau participent : les compagnies de hardware, les fournisseurs d'équipement de réseau, les fournisseurs et les développeurs de service. Sur le marché de télécommunication Ingénieurs 2006 Trabelsi Walid 18

28 Chapitre 2 : Les plateformes de développement des services 3G dans les réseaux radio mobiles violemment concurrentiel, les porteurs qui embrassent ces possibilités de prochaine génération réussiront à travers leur capacité de créer de nouveaux services pour se différencier des concurrents moins agiles Architecture de la plateforme JAIN L'architecture de JAIN définit un ensemble d'outils de développement, un environnement de création de service, et un environnement d'exécution de la logique de service pour établir des services de prochaine génération pour le réseau PSTN, le réseau paquet (par exemple ATM et IP), et les réseaux sans fil. Plusieurs nouveaux systèmes peuvent être développés en utilisant l'architecture de JAIN et plusieurs abstractions de base de communications sont reportées et comme il est illustré dans la figure suivante: Couche réseau: Figure 2.3: Architecture de JAIN Télécommunications - réseaux intelligents (avancés) (AIN/IN) ou système de signalisation 7 (SS7) avec beaucoup de protocoles - ISUP, INAP, TCAP, etc. Sans fil - SS7 avec la couche de Mobile Application Part (MAP). Internet ou paquet -SIP, MGCP, MEGACO, H.323. Ingénieurs 2006 Trabelsi Walid 19

29 Chapitre 2 : Les plateformes de développement des services 3G dans les réseaux radio mobiles Couche de Signalisation: Télécommunication - point de service de signalisation (SSP) ou des commutateurs. Sans fil - Centres de Commutation Mobile (MSC). Internet - softswitchs ou agents d'appel, et contrôleurs de la passerelle des médias ou GK H.323. Couche de Service: Télécommunication - Les points de contrôle des services (SCP). Sans fil - n'importe quelle combinaison des contrôleurs de station de base (BSCs), des HLRs, des VLRs, et les MSCs.. Internet - Serveur d'application L architecture de JAIN inclut un environnement de création de service (SCE) pour des services de réseau de confiance de prochaine génération et les applications de non confiances de tiers. Les services de confiance (et les politiques) résident dans le noyau des réseaux publics. Les services de non confiances sont des services écrits par les tiers dont l'accès fonctionne dans le noyau des réseaux publics. Par une interface sécurisée de fournisseur de service, ces applications de tiers ont gardées la fiabilité ou l'intégrité de ces réseaux Topologie du réseau de JAIN La topologie du réseau de JAIN procure à des porteurs de déployer des services de réseau de prochaine génération à l'intérieur de dispositifs ou au bord du réseau intégré, qui compris n'importe quel dispositif d'utilisateur permis par la technologie de Java. En outre, le support de tous les protocoles nécessaires de téléphonie qui sont employés entre les différents éléments des réseaux IP ou IN est obligatoire. Un aspect principal de l'architecture composante de JAIN doit déplacer la couche de signalisation loin des commutateurs de propriété industrielle dans les serveurs ouverts de contrôle d'appel, également connus sous le nom Call Agents, Media Gateway Controllers, ou Softswitches. Signalant aussi que les protocoles employés pour établir et terminer des connexions de communication est le fil commun entre les commutateurs de télécommunications conventionnels et les softswitches. La capacité d'adapter les composants de signalisation entre les réseaux est primordiale au succès des porteurs et des fournisseurs de service de réseau. Le schéma au dessous est une représentation simplifiée où les APIs de JAIN sont définis dans une plateforme de communication. L'architecture de Softswitch portée ne traçant que les interfaces contrôle/session d'appel sur le protocole fondamental. Puisque les softswitches exécutent la signalisation sur des réseaux IP, la plupart sont équipées des protocoles fondamentaux avec SIP, MGCP, MEGACO ou H.323. Plusieurs softswitches incluent également les protocoles SS7 pour adresser des interfaces pour le réseau téléphonique existant. Ingénieurs 2006 Trabelsi Walid 20

30 Chapitre 2 : Les plateformes de développement des services 3G dans les réseaux radio mobiles Figure 2.4: Les APIs de JAIN L'initiative de JAIN offre les composantes clés pour établir des architectures ouvertes de softswitch et pour fournir la portabilité de service par une interface unifiée de Java pour développer et déployer des services de prochaine génération. Les APIs de Framework de JAIN est classé dans quatre catégories: Interfaces de connexion ou de protocoles Interfaces de contrôle ou de session d appel Interfaces logiques de services Accès des fournisseurs de services Il devrait souligner que les composants conformes de JAIN ne résident pas nécessairement sur un serveur simple (depuis le Getkeeper), Gateway controller, et la fonctionnalité de signalisation du Gateway est typiquement implémenté comme application à plusieurs niveaux et répartie sur tous les éléments de réseau de signalisation. Une telle approche fournit des avantages significatifs pour l'exécution, la fiabilité, la gestion, la réutilisation, et la flexibilité Les Spécifications de JAIN Les caractéristiques des APIs développées dans la plateforme JAIN sont appropriées à un des secteurs suivants [5]: Spécifications des protocoles : interfaces standard des protocoles de signalisation IP dans les réseaux filaire et sans fil Spécifications des applications : traitement large des APIs exigés pour la création de service avec un Framework de Java accordé à travers tous les protocoles supportés par les spécifications des APIs protocolaires. Ingénieurs 2006 Trabelsi Walid 21

31 Chapitre 2 : Les plateformes de développement des services 3G dans les réseaux radio mobiles Spécifications des Protocoles de JAIN Les spécifications des protocoles de JAIN sont concentrées sur la création des caractéristiques pour les APIs génériques pour livrer une signalisation SS7 avec la fonctionnalité du protocole IP (convergence) par le langage de programmation de Java. Actuellement, les spécifications suivantes des protocoles de JAIN sont accomplies ou en cours: TCAP permet d ajouter la fonctionnalité basée sur la transaction au réseau téléphonique existant. OAM - Operations, Administration, and Maintenance : fournissent une interface portative standard à un fournisseur de service pour disposer et maintenir des composants dans un réseau PSTN/IP. ISUP - fournit un API aux fonctions de signalisation qui sont nécessaires pour soutenir des applications commutées de voix et de données MAP - contrôlent la norme pour les communications mobiles (GSM). 3G MAP pour les applications mobile dans le domaine 3G. SIP - Session Initiation Protocol : utilisé pour établir et contrôler des sessions IP multimédia. SIP Lite est un API Java à niveau élevé qui permet aux créateurs d'application,qui ont le SIP en tant que leur protocole fondamental sans avoir le besoin de connaissance étendue du protocole SIP, de créer des applications. SIP Servlets définit une extension à niveau élevé API pour des serveurs SIP. SIMPLE Presence donne la puissance au protocole SIP pour fournir un service de présence. SIMPLE Instant Messaging donne la puissance au protocole SIP pour fournir des extensions pour la messagerie instantanée. ENUM définit une norme, interface de programmation d'application et une provision de E.164 des numéros de téléphone et leurs services spécifiques des Identifications des ressources uniformes (URI). MGCP - contrôle la voix et les médias à travers les Gateways de paquet. INAP - est un protocole de contrôle qui permet à des applications de communiquer entre diverses entités des nœuds fonctionnelles d'un réseau intelligent MEGACO - normalise l'interface entre l'entité de contrôle d'appel (MGC) et les entités traitant les medias (Media Gateway ou MG) H.323 permet de déplacer des multimédia bidirectionnels en temps réel (audio, vidéo, données, fax) à travers les réseaux paquet tout en maintenant la connectivité au PSTN Spécifications des Applications de JAIN Les spécifications des applications sont concentrées sur les facilités de développements établis sur la couche de protocole pour permettre le développement facile d'application utilisant la largeur des objets et des services de Java, tout en protégeant les réalisateurs des détails de protocole. Actuellement les caractéristiques suivantes de l'application API de JAIN sont en cours de développement: SLEE Service Logic Execution Environment : définit des interfaces et des conditions obligatoires pour des opérations avec les réseaux Internet Ingénieurs 2006 Trabelsi Walid 22

32 Chapitre 2 : Les plateformes de développement des services 3G dans les réseaux radio mobiles JCC JAIN Call Control : fournit aux applications un mécanisme cohérent pour se connecter par interface aux réseaux divergents fondamentaux JCAT JAIN Coordination and Transaction : inclut les équipements exigés pour des applications pour être appelé et retourner des résultats avant, pendant ou après les appels. SPA Service Provider APIs for the Parlay Specifications : définit les spécifications de Parlay qui fournira le mécanisme sécurisé d'accès aux possibilités de réseau. Common API documente et indique ces interfaces et ces classes de base commune pour éviter la duplication dans chacune des caractéristiques de JAIN et pour maintenir l'uniformité de ces interfaces et ces classes à travers ces JSRs. 2. OSA/Parlay 2.1. Le Groupe Parlay Le groupe Parlay a été fondé en 1998 par cinq compagnies : BT, Microsoft, Nortel Networks, Siemens, et Ulticom [6]. Le groupe a commencé par développer un ensemble d'interfaces de programmation d'application (APIs) ouvertes et normalisées à fin de faciliter le développement des services demandés dans les réseaux de télécommunication d'une façon plus rapide. Un but était de rendre le réseau indépendant pour réaliser la portabilité facile des applications entre les technologies de réseau et pour s'assurer que le réseau pourrait évoluer sans affecter les applications déjà existantes. Le travail du groupe de Parlay a eu comme conséquence un dégagement de spécifications dans un délai d'un an de l'établissement et le développement et l'entretien des APIs a continué avec le croissement des membres des compagnies participantes. Aujourd'hui il y a environ 65 compagnies qui forment le groupe de Parlay et ils représentent les deux les industries IT et de télécommunication. Le groupe, depuis l'établissement, a été produit et édité un certain nombre de spécifications pour des nouvelles constructions toute en maintenant la compatibilité. Le travail est également effectué pour augmenter les spécifications existantes et pour incorporer de nouvelles conditions basées sur la rétroaction de l'industrie. Le groupe de Parlay collabore avec d'autres organismes normalisés travaillant avec les caractéristiques semblables pour éviter le développement et l'édition des caractéristiques doubles ou ambiguës dans l'industrie. Un exemple de cette collaboration est le travail commun entre le groupe de Parlay, 3rd Generation Partnership Project (3GPP) et European Telecommunications Standards Institute (ETSI) [6] Qu est ce qu OSA/Parlay? Une interface de programmation d'application (API) fournit aux créateurs d'application les classes et les méthodes d'interface qui peuvent être employées pour appliquer certaine fonctionnalité à une application sans devoir mettre en application la logique fondamentale pour la fonctionnalité. OSA/Parlay [3] est un ensemble ouvert et normalisé d APIs conçues pour simplifier et accélérer la création de nouveaux services dans la télécommunication. Ingénieurs 2006 Trabelsi Walid 23

33 Chapitre 2 : Les plateformes de développement des services 3G dans les réseaux radio mobiles OSA/Parlay permet aux fournisseurs de service de développer des services de réseau à valeur ajoutée en employant les mêmes technologies utilisées pour le développement rapide d'application avec l'informatique répartie tel que Java et Web services. L'API est développé pour ouvrir le réseau et pour exposer la fonctionnalité du réseau comme logiciel personnalisé entre le réseau de télécommunication et les applications de service (figure 2.5). La logique d'application est ainsi séparée de la fonctionnalité de réseau pendant que des fournisseurs de service en dehors du domaine de réseau sont permis d'accéder à la fonctionnalité et au noyau des ressources de réseau d'une manière commandée sans compromettre la sécurité de réseau. Figure 2.5: OSA/Parlay : Lien entre le réseau de télécommunication et les applications Les interfaces d'osa/parlay sont conçues pour être comme une technologie et un réseau indépendant qui peuvent être employées pour les réseaux mobiles, fixes et les réseaux de la nouvelle génération. Des réalisations spécifiques de réseau et les protocoles fondamentaux sont rendues transparentes aux applications pour les protéger de la complexité du réseau. L'indépendance du réseau permet à écrire les applications qui peuvent fonctionner sur une variété de protocoles fondamentaux et il permet aux applications de communiquer d'un réseau à l'autre sans infliger l'exécution de l'application Une autre conséquence de l'indépendance de réseau est que les services peuvent être développés par des réalisateurs de logiciel habiles dans d'autres secteurs que la télécommunication. C'est possible puisque les réalisateurs ne sont pas exigés à avoir une connaissance profonde de la technologie du réseau de télécommunication pour pouvoir employer les APIs. Et par suite les réalisateurs peuvent se concentrer à implémenter des services plutôt que de se concentrer sur l'interopérabilité entre les différents fournisseurs du réseau. OSA/Parlay fournit également la flexibilité additionnelle dans le développement de service puisque les fournisseurs de service peuvent employer le même ensemble de classes d'interface et les méthodes pour des multiples plateformes, c.-à-d. en assumant les plateformes supportant l'api. Ingénieurs 2006 Trabelsi Walid 24

34 Chapitre 2 : Les plateformes de développement des services 3G dans les réseaux radio mobiles Pour assurer qu'osa/parlay peut être employé par une grande communauté de développeur, il est basé sur des normes ouvertes comme CORBA, UML, Java et Web services tels que le SAVON, XML et WSDL. OSA/Parlay en outre inclut le support de l'exécution dans une variété de langages de programmation, par exemple C, C++ et Java Architecture OSA/Parlay OSA/Parlay a pour but de permettre aux applications de demander des services fournis par le noyau du réseau de télécommunications. De sorte que les créateurs d'application ne se fondent pas sur les détails la sophistication particulière du réseau. Cette séparation des applications du réseau permet aux opérateurs de contrôler et commander des interfaces du réseau. Ainsi, on ne permet généralement pas à des applications d'affaires d'accéder au noyau du réseau directement, un tel accès est plutôt négociées par l'intermédiaire d'un Gateway de Parlay auquel les applications passent des demandes. Figure 2.6: Architecture OSA/Parlay L'architecture d OSA/Parlay définit trois types de composants : les Applications, le Service capability server (SCS), et le Framework. 1. Les Applications : couvrent toutes les applications d'affaires qui pourraient souhaiter employer les fonctionnalités de réseau. L'application peut être déployée sur un serveur d'application, qui peut être n'importe quel plateforme standard et se compose d'une ou plusieurs applications. 2. Les SCFs : Service Capabiblity Feature : ils présentent la fonctionnalité du réseau et fournissent le mécanisme par lequel les applications peuvent accéder à des possibilités fondamentales du réseau en appelant ses interfaces. Les SCFs peuvent être exécuté sur les Ingénieurs 2006 Trabelsi Walid 25

35 Chapitre 2 : Les plateformes de développement des services 3G dans les réseaux radio mobiles SCSs, qui sont les entités logiques qui mettent en application les APIs d'osa/parlay et agissent l'un sur l'autre directement avec le noyau des réseaux. 3. Le Framework : fournit les possibilités nécessaires au service pour être ouvert, bloqué et maniable. Il peut considérer en tant qu'un certain nombre de modules fonctionnels et il est indépendant de n'importe quel SCFs. Le Framework négocie entre le SCS et les applications, de sorte que la seule chose que l'application doit savoir où se trouve service, et quels dispositifs elle recherche. La communication entre l'application, le Framework et les SCFs font partie de la norme d'osa, tandis que la communication entre l'application et ses utilisateurs est en dehors de la portée d'osa. L'application demande un SCF fourni par le réseau. Le Framework contrôle la découverte et l'accès de service, et contrôle l'autorisation et l'authentification des applications d'employer le service. Ce schéma montre le rapport entre les composants d'osa/parlay et les écoulements principaux de demande et d'information parmi eux. Figure 2.7: Le rapport entre les différentes composantes d OSA/Parlay Pour expliquer comment ces composants interagir les uns avec les autres, il est nécessaire de regarder le processus complet d'affaires où un nouveau SCS est créé et une application commence à utiliser les possibilités offertes par ce SCS. Le scénario est dépeint sur le schéma au dessous. Supposez que le SCS met en application le SCF de contrôle d'appel. Deux étapes différentes peuvent alors être distinguées : Ingénieurs 2006 Trabelsi Walid 26

36 Chapitre 2 : Les plateformes de développement des services 3G dans les réseaux radio mobiles Figure 2.8: Interactions du Gateway d OSA/Paraly 1. Enregistrement : là où un nouveau SCF entre en contact avec le Framework pour l'enregistrement. Les conditions dans lesquelles on permet à l'application d'employer ce SCF sont configurées sur le Framework. 2. Établissement d'exécution de communication entre l'application et le SCS : là où l'application entre en contact d'abord avec le Framework. Deuxièmement, le Framework identifie l'application demandant le SCF, et alors l'application se sert de l'interface de découverte pour découvrir quelles réalisations de SCF remplissent ses conditions. Troisièmement, le Framework envoie les informations sur les conditions dans lesquelles l'application peut employer ce SCF, au SCS, qui crée un exemple de SCF. En conclusion, l'application peut l employer et il y aura implémentation du SCF de contrôle d'appel La structure des spécifications des APIs d OSA/Parlay Les spécifications d'osa/parlay [7] fournissent la documentation détaillée décrivant les interfaces que les développeurs doivent mettre en application. Les caractéristiques ellesmêmes fournissent des diagrammes de séquence et de classe, des diagrammes de transition d'état. Cela est faite en utilisant le language de modélisation unifié (Unified Modeling Language : UML) qui est une technologie indépendante. Le tableau suivant décrit toutes les SCF d OSA/Parlay : Part # SCF Description 1 Vue d ensemble Contient l'introduction et la méthodologie utilisée 2 Définition des données communes Définition de données génériques utilisée dans des autres parties 3 Framework Définit les possibilités d'infrastructure comme l'authentification, la découverte de SCF, l'enregistrement de SCF, la gestion de défaut, etc. 4 Call Control Définie la famille de contrôle d appel. Sous partie 1 Définitions communes de contrôle d appel Sous partie 2 Contrôle d appel générique Ingénieurs 2006 Trabelsi Walid 27

37 Chapitre 2 : Les plateformes de développement des services 3G dans les réseaux radio mobiles Sous partie 3 Contrôle d appel multi partie Sous partie 4 Contrôle d appel Multi média Sous partie 5 Contrôle d appel Conférence 5 User Interaction Rassemble l'information d'un utilisateur, envoi de message court, etc. 6 Mobility Permet d obtenir l information de localisation et le statut de l utilisateur. 7 Terminals Capabilities pour obtenir les possibilités du terminale de l'utilisateur. 8 Data Session Control Influence la session de données. 9 Generic Messaging pour envoyer, stocker et recevoir des messages manipulant les boites aux lettres des s. 10 Connectivity Pour provisionner la qualité de service QoS. Management 11 Account Management Pour accéder au compte d utilisateur. 12 Charging pour charger l'utilisateur pour l'usage de l'application ou des données. 13 Policy Management pour contrôler l'information de politique et pour commander l'accès aux services politique permis. 14 Availability and Presence Management pour la présence et la disponibilité des entités pour diverses formes de communication et des contextes dans ce qui sont disponibles Autant d'applications d'osa/paraly ont des caractéristiques asynchrones, les interactions entre une application et un SCF suivent le paradigme de demande/réponse. Ainsi OSA indique que chaque demande détermine l'adresse à laquelle la réponse peut être envoyée. Puis, une réponse asynchrone est envoyée à l'adresse indiquée de réponse, appelant une interface séparée. La réponse contient une identification qui la relie à la demande. III. Comparaison des deux plateformes : JAIN et OSA/Parlay JAIN et OSA/Parlay sont tous les deux des plateformes de services qui ont un objectif commun est de créer et développer des nouveaux services de la nouvelle génération. Ce pendant, chacun d elles a ses caractéristiques et ses spécifications en fournissant des avantages et des inconvénients que nous allons présenter dans cette partie à fin de justifier notre choix de la plateforme avec la quelle nous développons notre application. 1. JAIN 1.1. Avantages L initiative de JAIN présente plusieurs avantages dans les plus intéressant sont la portabilité de service, la convergence, et la sécurité d'accès aux réseaux Internet et téléphoniques. Ceci changera franchement la structure d'affaires courantes de ces réseaux comme suit: Portabilité de Service: (Write Once, Run Anywhere). Le développement de la technologie est actuellement contraint par les interfaces de propriété industrielle. Ceci augmente le coût de développement, le délai d'arrivée au marché, et les besoins d'entretien. Avec Ingénieurs 2006 Trabelsi Walid 28

38 Chapitre 2 : Les plateformes de développement des services 3G dans les réseaux radio mobiles l'initiative de JAIN, des interfaces de propriété industrielle sont remodelées aux interfaces uniformes de Java fournissant des applications véritablement portatives. Convergence du Réseau: (Réseaux Intégrés). En fournissant le service pour permettre à des applications et à des services de fonctionner sur le PSTN, le réseau paquet (par exemple IP ou ATM) et les réseaux sans fil, la technologie de JAIN accélère la convergence des réseaux. Comme demande des élévations finies de services IP, les nouvelles économies d'échelle sont possibles aussi bien qu'une gestion plus efficace et une plus grande intégration avec IT. La Sécurité d'accès au Réseau : (Par N'importe qui!) En permettant des applications résidant en dehors du réseau l accès directement aux ressources et aux dispositifs de réseau pour effectuer des actions ou des fonctions spécifiques, un nouvel environnement est créé pour les développeurs et les utilisateurs. L'occasion du marché pour des nouveaux services est énorme quand l'accès commandé est fourni à la fonctionnalité et à l'intelligence disponibles à l'intérieur des réseaux de télécommunications Inconvénients Malgré que la plateforme JAIN présente de majeurs avantages mais elle présente aussi des points négatifs dans les plus importants on trouve d abord que la plus part des spécifications nécessaires pour le développement sont en cours de développement et ne sont pas encore mûre pour les utiliser pour créer des services réseau mobile. En plus, les acteurs de la plateforme JAIN n ont pas pensé à développer des simulateurs qui permettent aux développeurs d applications de tester leurs résultats sans avoir recours à un vrai réseau de Télécom au contraire de la plateforme OSA/Parlay qui fournit aux développeurs des Gateway et des simulateurs de réseau pour tester les applications créés. 2. OSA/Parlay 2.1. Avantages Création rapide de service : OSA/Parlay est basé sur la même approche que les développeurs commerciaux de logiciel emploient en établissant des applications, par opposition aux environnements de propriété industrielle de création de service qui ont été répandus. Un avantage de ceci est qu'il est facile de développer des applications d OSA/Parlay à l'aide des outils de développement disponibles immédiatement pour des applications de Java telles que le J-Builder de Borland, ou d'ibm's Websphere studio. Un certain nombre de fournisseurs, tels que Ericsson et Open API Solutions, ont également des outils d'essai d OSA/Parlay, qui veut dire que si c'est possible d'examiner une application exécuté sur Linux ou Windows. Ericsson, IBM et Telenor ont couru des expériences, et ont constaté que l utilisation d OSA/Parlay accélère d une manière significative le temps pris pour développer des applications de communications en comparaison avec les outils traditionnels de création de service. Ingénieurs 2006 Trabelsi Walid 29

39 Chapitre 2 : Les plateformes de développement des services 3G dans les réseaux radio mobiles Présence des outils nécessaires au développement Les services déployés de la façon «verticale», c'est-à-dire, quand l'infrastructure est changée dans beaucoup de niveaux/couches, pourraient être, dû aux optimisations multiples, très efficaces. Mais elle serait également extrêmement lente, et il serait difficile deprolonger les services. C est pourquoi les fabricants de matériel ont déjà commencé à produire les Gateways qui peuvent être commandés par l'utilisation des APIs d OSA/Parlay. Par conséquent, un opérateur de télécommunication simple ne doit pas développer ses propres solutions. En outre, les premiers kits de développement de logiciel (SDKs) sont présentés (par exemple Appium GBox) aussi bien que des Gateways d OSA/Parlay (par exemple Ericsson Jambala) et des simulateurs de réseau (par exemple Ericsson NRG Simulator d OSA/Parlay). Il peut rendre le développement des services plus simple dans les domaines de télécommunication intérieurs d une façon plus robuste. L'indépendance du Réseau : Les APIs d OSA/Parlay ont été conçus, si c'est possible, pour être indépendants du réseau fondamental. Une application mobile de données n'a pas besoin de savoir quelle technologie est employée dans le réseau fondamental pour mettre en application des services de localisation. Le créateur d'application veut juste les coordonnées de localisation et l'exactitude de la difficulté. Ceci permet à une application de bien fonctionner sur différents réseaux, et la même application peut même être mise en communication à un réseau fixe. Encore, l'application n'est pas concernée comment l'information de localisation est déterminée, juste dans les données de localisation elle-même. Les considérations semblables s'appliquent à d'autres secteurs fonctionnels - tels qu'installer un appel, ou charger l'abonné par une quantité additionnelle pour le contenu. L'indépendance du Fournisseur : Une conséquence de l'indépendance de la technologie et du réseau des APIs d OSA/Parlay est qu'ils sont également indépendants des fournisseurs. Les fournisseurs de service tirent bénéfice d'avoir un ensemble simple d'apis qui sont soutenus sur les plateformes multiples des fabricants. Ceci fournit la flexibilité additionnelle dans le déploiement. Logiciels standard pour les développeurs d'application : L'utilisation de la technologie de logiciel standard a signifié que les réalisateurs de logiciel avec l'expérience de C++ et CORBA, ou le Java et l'ejb, peuvent facilement développer des applications en utilisant OSA/Parlay. Là sont estimés pour être autour 1,5 millions de réalisateurs de C et de Java dans le monde. C'est contrairement à la situation, par exemple, avec AIN, où de nouveaux services pourraient seulement être créés par des réalisateurs avec la formation très spécialisée. Third Party Independent Software Vendors (ISVs) : Un résultat de l'utilisation de la technologie de développement de logiciel standard est qu'il a créé une communauté grandissante des fournisseurs de logiciel " third party'" qui développent et vendent des applications et des services basés sur OSA/Parlay. Les réunions de groupe de Parlay comportent régulièrement un étalage, où les fournisseurs peuvent démontrer de nouvelles applications et services basés sur les APIs d OSA/Parlay. Ingénieurs 2006 Trabelsi Walid 30

40 Chapitre 2 : Les plateformes de développement des services 3G dans les réseaux radio mobiles IV. Choix de la plateforme OSA/Parlay 1. Les raisons de choisir OSA/Parlay OSA/Parlay est la plateforme que nous avons choisi pour réaliser notre application au cours de ce projet sous plusieurs raisons. D abord OSA/Parlay, est maintenant pratiquement la seule norme mûre et déjà être déployée. Cette norme, qui est également largement soutenue par les opérateurs principaux de télécommunications. La logique de service dans cette architecture est située ici dans le prétendu client application ou simplement l'application. L'application communique avec l'opérateur de télécommunication au moyen d'un protocole spécial, qui est réellement une interface de programmation d'application distribuée strictement définie. Cet API permet à l'opérateur de télécommunication de donner de l'accès restreint à son infrastructure pour des applications autorisées. En plus, l'api fournit un modèle spécial des processus de télécommunications, qui cache beaucoup d'aspects complexes d'architecture de systèmes de télécommunications. En plus le modèle est portatif, c à d les applications peuvent coopérer avec de divers réseaux de télécommunications (par exemple fixe, mobile, 2G, 3G, etc.). Une autre raison est que cette plateforme décrite ici a été principalement développé pour ouvrir les réseaux de télécommunication, il peut être aussi bien employé à l'intérieur ou à l extérieur du domaine de télécommunication. Les figures a) et b) comparent les deux cas. Figure 2.9: Localisation possible des applications d OSA/Parlay Donc en choisissant cette plateforme nous aurons l occasion de développer des applications sans avoir recours à un vrai domaine de télécommunication. Cela est possible du faite qu OSA/Parlay offre un simulateur de réseau mobile appelé OSA/Parlay Simulator dans le début et qui est amélioré par Ericsson pour se nommer Ericsson NRG Simulator. Et par conséquence ce simulateur sera un moyen à encourager les développeurs à choisir la plateforme OSA/Parlay pour créer de nouveaux services comme s ils travaillent dans un vrai domaine de télécommunication. Après la création des applications, exécutés avec succès sur le simulateur, elles peuvent être testé sur le vrai réseau de télécommunication. Et de cette façon le développement de nouveaux services sera plus rapide et d une façon sécurisée sans affecter les équipements du réseau. 2. Les différentes Modèles d OSA/Parlay Le modèle OSA/Parlay [3] peut être représenté dans deux modèles : modèle fonctionnel et modèle d affaire. Ingénieurs 2006 Trabelsi Walid 31

41 Chapitre 2 : Les plateformes de développement des services 3G dans les réseaux radio mobiles 2.1. Modèle fonctionnel Le modèle fonctionnel dans OSA/Parlay est composé de 4 composants, qui sont habituellement référés comme entités d OSA/Parlay. Toutes les entités sont montrées dans la figure suivante. Figure 2.10: Les entités fonctionnelles d OSA/Parlay Leur fonctionnalité est comme suit: SCF : cette entité est responsable de fournir une certaine partie de la fonctionnalité du réseau. La fonctionnalité assurée (Service Capability) est une partie étroite et séparée des possibilités du réseau, par exemple la fonctionnalité d'interaction d'utilisateur ou la fonctionnalité de contrôle d'appel. Framework : C'est le " coeur " des APIs d OSA/Parlay. Il rassemble un ou plusieurs SCFs et les présente à d'autres entités. De l'autre côté, le Framework est un endroit où les opérateurs d'entreprise souscrivent la fonctionnalité de réseau et les applications des clients obtiennent l'accès à SCFs. Opérateur d entreprise : Cette entité est responsable de souscrire une certaine fonctionnalité de réseau pour des applications des clients, et demander une qualité appropriée de service. Un opérateur d'entreprise n'emploie pas les SCFs elles-mêmes. Les applications des clients sont des entités qui emploient les SCFs au nom des opérateurs d'entreprise. Application des clients : C'est l'entité qui emploie les SCFs et se sert d'eux pour créer de nouveaux services à valeur ajoutée Modèle d affaire La figure 2.11 montre le modèle d'affaires utilisé dans OSA/Parlay. Une police ordinaire est employée pour noter des entités d'affaires, alors que les équivalents fonctionnels d OSA/Parlay sont écrits en italique. Ingénieurs 2006 Trabelsi Walid 32

42 Chapitre 2 : Les plateformes de développement des services 3G dans les réseaux radio mobiles Figure 2.11: Les entités d affaires dans OSA/Parlay Chaque entité dans la figure est une affaire séparée mais dans certains cas plusieurs entités peuvent être partie des affaires simples (par exemple fournisseur de service). Spécifiquement, toutes les entités peuvent faire partie du même porteur. Dans un tel cas une entité d'abonné de service peut ne pas être nécessaire du tout. Notons que dans ce contexte le terme service signifie " Service Capabiliby Feature (SCF)", c à d une partie de fonctionnalité fourni par des fournisseurs de service. Cette convention est largement répandue dans toutes les caractéristiques d OSA/Parlay. Cependant le terme service peut être employé dans la signification " service à valeur ajoutée " c à d le résultat du travail des applications des clients. Pour éviter l'ambiguïté le terme service ne sera pas employé dans la signification fournisseur de service, et l'acronyme " SCF " sera employé à la place. Les entités d'affaires sont décrites comme suit: Fournisseur de Service : fournit des services de bases de télécommunications (marchandises) aux consommateurs de service. Typiquement, ce sera un opérateur de réseau. Retailer : distribue les services pour les consommateurs de service selon des fournisseurs de service, des abonnés de service et ses propres politiques. Ceci sera exécuté par un opérateur de réseau ou un établissement identifié. Service d abonné : souscrit des services aux consommateurs de service. Typiquement, c'est un VASP, il peut être par exemple une compagnie, banque ou un établissement. Consommateur de service: Il utilise des services. Il peut être la filiale d inscription de service ou une compagnie relative d'un abonné de service, contient une logique d'affaires. Développeur d application : fournit des solutions IT aux consommateurs de services. Conclusion Dans ce chapitre nous avons présenté les plus importants plateformes de services qui sont considérés comme un résultat des changements des besoins des consommateurs des services de communications et qui augmente les opportunités aux opérateurs de réseau, les fournisseurs de service et les entreprises. Ces plateformes définissent la sécurité dans les réseaux et fournissent les interfaces de programmation d'application standard ouvertes (APIs). Ceci mène à une augmentation massive des services disponibles aux utilisateurs de Ingénieurs 2006 Trabelsi Walid 33

43 Chapitre 2 : Les plateformes de développement des services 3G dans les réseaux radio mobiles Télécom, à des services qui fonctionnent à travers des types de réseau, et à un chemin clair d'évolution pour des services des nouvelles générations. Ingénieurs 2006 Trabelsi Walid 34

44 Chapitre 3 : Les outils et les services nécessaires pour le développement de l application Chapitre 3. Les Outils et les services nécessaires pour la création de l Application Introduction L évolution progressive du monde des télécommunications vers des réseaux et des services de nouvelle génération est aujourd hui une tendance forte qui suscite l intérêt d une majorité d acteurs. Nous allons profiter de cette tendance pour créer un nouveau service de troisième génération en profitant de l existence des nouvelles plateformes de développement de services radio mobiles comme la plateforme OSA/Parlay qu on a choisie. La première application développée permet aux utilisateurs de téléphones mobiles de troisième génération de récupérer leur localisation dans à travers un MMS qui contient une mappe de la ville de Tunis sur laquelle se trouve l endroit du mobile, ensuite cette application est améliorée en fournissant aux utilisateurs deux modes de services. Le premier permet aux utilisateurs de chercher les deux les plus proches magasins (banques ou restaurants ) selon le choix de l utilisateur, par rapport à sa localisation en identifiant la ville (Tunis, Sfax, Sousse..) de la Tunisie dans laquelle se trouve l utilisateur, alors que le deuxième service permet à un utilisateur mobile de récupérer la localisation d un autre mobile bien sûr s il a l autorisation. L application de récupération de la localisation de l utilisateur mobile va être développée avec JDeveloper (programmation Java) et en suite elle sera testée sur le simulateur de réseau mobile : «Ericsson NRG Simulator». Dans le premier service de recherche des plus proches magasins, nous allons utiliser en plus l outil MySQL pour enregistrer les différentes localisations des magasins des différentes villes de la Tunisie dans une base de donnée alors que pour le deuxième service nous allons manipuler un fichier de configuration pour gérer l autorisation d accès. Dans ce chapitre nous allons détailler dans une première partie les outils nécessaires pour réaliser cette application avec le NRG Simulator [8] ainsi que ces différents composantes, et dans une deuxième étape nous décrivons toutes les services supportés par le NRG Simulator et nous nous focalisons uniquement sur ceux utilisés au développement de notre application. I. Les Outils nécessaires à l application 1. Network Ressource Gateway (NRG) 1.1. La place de NRG dans OSA Le concept OSA est constitué de trois couches dont la couche supérieure est la couche de service, au dessous de laquelle on trouve la couche de contrôle et la couche de connectivité. Les éléments du réseau de Télécom sont localisés dans les couches de contrôle et de connectivité alors que le NRG se trouve dans la couche de service. La couche de contrôle manipule la signalisation et la couche de connectivité gère le trafic. Le grand avantage de cette structure est que le NRG simplifie une grande partie des complexités de télécommunication de réseau en cachant les couches au-dessous et cela en fournissant une interface normalisée pour les développeurs des applications. Ainsi, diminuant la demande de Ingénieurs 2006 Trabelsi Walid 35

45 Chapitre 3 : Les outils et les services nécessaires pour le développement de l application la connaissance spécifique de réseau par les développeurs d'application et augmentant la portabilité des applications développées. Figure 3.1: Le concept d OSA/Parlay L opérateur utilise le NRG pour créer un lien entre l application et le réseau de Télécom Ericsson High Level Open Service Access (H-OSA) Le NRG a été développé par Ericsson en utilisant les APIs d'osa/parlay appelés High Level Open Service Access (H-OSA) [9]. Les H-OSA APIs sont des prolongements à OSA/Parlay avec des services et des fonctionnalités additionnels. Voici quelques exemples des dispositifs possibles qui peuvent être développés avec les services définis par H-OSA dans le NRG : Recever les messages de SMS et de MMS et envoyer des messages de SMS, MMS, WAP-push et en employant le service "Messaging". Chercher l' en employant le service "Message Retrieval ". Chercher l'information des téléphones mobiles en employant le service User Status de H-OSA. Manipuler les calendriers d'abonné en employant le service "PIM Calendar ". Manipuler les contacts d'abonné et les événements de calendrier en employant le service " PIM contact " Ericsson Network Resource Gateway La partie principale du produit de NRG est le SCS (Service Capability Server). Le SCS fournit des services de réseau aux applications d'une manière sécurisée et commande les éléments de réseau par des limites imposées, c'est-à-dire il agit en tant que Gate Keeper. Sous le SCS que le réseau de télécommunication emploie un éventail de protocoles de réseau pour mettre en application les services dans le réseau. Ingénieurs 2006 Trabelsi Walid 36

46 Chapitre 3 : Les outils et les services nécessaires pour le développement de l application Le NRG peut être vue comme un SCS puisque cette dernière est la partie de base du produit de NRG. Cependant le NRG inclut le SCS et le SDK et par suite on peut dire le NRG représentera le médiateur de SCS entre l'application et le réseau de télécommunication. Figure 3.2: Le NRG fournissant un ensemble d'apis indépendant des réseaux fondamentaux 1.4. NRG Software Development Kit (SDK) Le SDK [9] offre des bibliothèques nécessaires aux développeurs des applications JAVA à fin de simplifier le développement des applications utilisant les possibilités du NRG. En utilisant le NRG, les développeurs n ont besoin plus de la connaissance détaillée du réseau de télécommunication afin d'employer ses services et avec l'aide de SDK le besoin de connaissance détaillée de CORBA afin d'employer le NRG est aussi bien enlevé. Ceci est fait par un des dispositifs de ces bibliothèques, à savoir son abstraction de CORBA. L API SDK traduit simplement les appels de méthode de JAVA en CORBA et puis de nouveau dans JAVA encore une fois reçu du NRG comme il est montré dans la figure 3.3. Cette abstraction simplifie des efforts de développement et d'essai et diminue des délais pour le développement d'application. Le SDK offre encore plus que son abstraction de CORBA, les bibliothèques de SDK qui contiennent également la documentation étendue des classes applicables de H-OSA. Ingénieurs 2006 Trabelsi Walid 37

47 Chapitre 3 : Les outils et les services nécessaires pour le développement de l application Figure 3.3: Vue d ensemble de SDK 1.5. The NRG Framework Le Framework [10] est l entité qui permet l accès aux services du NRG. Sans lui nous ne pouvons pas employer aucun service du NRG. Ce qui est important est de savoir ce qui se produit entre l'application et le Framework. Le Framework est inclut dans le NRG comme une entité fonctionnelle fournissant une interface standard vers une application et par suite il peut également être considéré car un service de NRG. IL y a une différence principale qui rend le Framework unique dans ce contexte et c'est parce qu'il est fournit obligatoirement pour entourer les possibilités de services de NRG. Chaque autre service du NRG est facultatif mais le Framework doit être inclus. Par conséquent souvent les services sont seulement vus comme des services facultatifs inclus dans le NRG. L'interface du Framework est définie par OSA/Parlay, elle agit entre l'application et les services disponibles à l'intérieur du NRG. Quand une application veut employer un service du NRG l'application d'abord doit le demander du Framework. Le code d'interaction du Framework dans une application est l'un des parties qui regarde (dans la plupart des cas) la même chose. Il sera probablement possible de le coder dans une première application et alors pour tout les applications plus ultérieures réutilisent le même code Le cycle de vie d'un NRG Une application obtient les services de NRG dans sa phase de démarrage au moyen de les demander du Framework. Pendant la phase d'arrêt de l'application, n'importe quelle application va libérer tous ses services précédemment demandés. En plus l'application peut manipuler des transactions multiples. La vue d ensemble du cycle de durée de vie est la suivante : Obtenir l accès au Framework Obtenir l accès aux services nécessaires. Ingénieurs 2006 Trabelsi Walid 38

48 Chapitre 3 : Les outils et les services nécessaires pour le développement de l application Manipulation des transactions multiples (comme appels téléphoniques, messages..) en utilisant les services. Libérer les services utilisés Finir l accès au Framework Quand l'application fait une découverte de service, il est possible que l'application recevra des instances multiples du même type de service. En spécifiant les propriétés des services, la bonne instance d'un type de service peut être sélectionnée Sevice Level Agreements (SLA) Le Framework est un Gatekeeper entre l'application et les réseaux de télécommunication. L'application peut être située dans le domaine d'opérateur, aussi bien que quelque part dans l'internet. S il n y a pas d accord avec l'opérateur il n aura pas de permission d'employer les services du NRG. Ainsi il faut définir l'authentification et l'autorisation des données. Quand il y a un accord avec un opérateur, l'accord s'appellera Service Level Agreements (SLA). La manipulation des transactions peut être faite tant que le SLA n est pas expiré ou terminé (par l application ou l opérateur). La figure suivante montre l interaction entre le Framework, l application et les services. Figure 3.4: Vue d ensemble du Framework D'abord, l'application s'authentifie au Framework (et vice versa). Quand le Framework et l'application ont validé l'identité de chacun, l'application peut demander au Framework l'accès aux services en signant le SLA. Quand le SLA a été établi le Framework invite le service pour créer la gestion du service et alors le Framework renvoie la référence de la gestion de cycle de vie à l'application. L'application peut alors employer cette référence pour obtenir directement l'accès au service. Bien qu'un NRG puisse contenir plusieurs services, il ne signifie pas qu'une application est permise de les employer. L'opérateur indique dans le SLA qui entretient peut être consulté par lequel des applications. Ingénieurs 2006 Trabelsi Walid 39

49 Chapitre 3 : Les outils et les services nécessaires pour le développement de l application La relation entre l application et le service défini un SLA. Deux types de propriétés de SLA disponibles, sont les propriétés de bases fonctionnelles et les propriétés de bases de performances. L'application peut seulement agir dans les limites d'un SLA. Les propriétés de bases fonctionnelles sont les bases d un SLA. Le SLA énonce quelles valeurs des propriétés fonctionnelles peut être employer par une application. Les propriétés dans le SLA sont vérifiées au temps d'exécution et le NRG permettra seulement les actions dans les limites de l'accord Obtenir l accès au service Avant qu'une application puisse obtenir l'accès à un service, l'application doit s'authentifier vers le NRG. L'application doit suivre un certain ordre des actions qu'il doit effectuer avant qu'il puisse employer un certain service. Pour employer un service il faut suivre les actions principales suivantes: Obtenir l accès initial du Framework Authentifier l application à travers le Framework Découvert les services valables Sélection du service voulu utilisé Signer le SLA pour utiliser le service L'application a besoin d appeler au minimum 13 méthodes au total pour obtenir l'accès au premier service qu'il veut employer. Pour chaque service supplémentaire que l'application veut employer, elle a besoin des 5 méthodes d appel et réception par service supplémentaire. Étant donné que c'est souvent le même ordre des méthodes, un composant est disponible dans les bibliothèques de logiciel de SDK qui simplifie l'interaction avec le Framework, ce composant s'appelle le Framework Proxy. La figure suivante montre les opérations nécessaires pour obtenir un service. Ingénieurs 2006 Trabelsi Walid 40

50 Chapitre 3 : Les outils et les services nécessaires pour le développement de l application Figure 3.5: Diagramme de séquence de l Interaction du Framework, pour obtenir l accès au service 1.6. Ericsson NRG Simulator Le simulateur de NRG [8] constitue l élément essentiel puisque il va être utilisé pour tester l application développée. Il permet d émuler un noeud de NRG et les ressources fondamentales du réseau et son but est également de tester les applications dans l'absence d'un NRG actuel fonctionnant sur un vrai réseau de télécommunication. Le simulateur d Ericsson est manuel et qui possède une interface utilisateur graphique riche. Tout qui se produit dans le simulateur de NRG est commencé par l'interaction d'utilisateur. Voici quelques exemples qui montrent cela : Si une application demande d être notifié des messages SMS de certains numéros, Le simulateur NRG va envoyer un SMS à ce numéro que lorsque le téléphone mobile dans l interface utilisateur graphique l envoie. Les applications sont seulement notifiées des appels téléphoniques et derrière une gamme fixe de nombre. Si une application demande périodiquement la localisation d un mobile, Le Simulateur NRG renvoie chaque fois la nouvelle localisation uniquement lorsque l utilisateur Ingénieurs 2006 Trabelsi Walid 41

51 Chapitre 3 : Les outils et les services nécessaires pour le développement de l application commence le mouvement qui se traduit par le mouvement du téléphone mobile dans la mappe de l interface utilisateur graphique du simulateur. Si une application demande le statut du mobile, le simulateur NRG le renvoie que lorsque le téléphone change d état. Le bénéfice d utiliser le simulateur NRG est qu il permet de simuler d une façon simple de nouvelles applications des services de 3 ème génération sans avoir recours à un vrai réseau de Télécom à fin de tester ces applications dans une deuxième étape dans un vrai réseau de Télécom. Un autre avantage d'utiliser le simulateur de NRG est qu'il est meilleur pour la démo. Des événements réels sont favorisés par les téléphones dans l'interface utilisateur graphique qui donne une manière beaucoup plus normale de décrire des événements que regardant des notations d'événement. En outre le simulateur de NRG a une ressemblance plus exacte à la réalité parce qu'il donne un défaut plus approprié manipulant avec de vraies réponses de NRG basées sur des réseaux de Télécom simulés. L'utilisateur agit avec l'interface utilisateur graphique du simulateur de NRG pour tester ou démontrer les applications d'osa/parlay. Une fois déployée dans un vrai réseau d opérateur, ces applications communiquent avec un vrai noeud de NRG, qui communique alternativement avec des noeuds divers dans un réseau d'opérateur. Dans le simulateur, les noeuds de réseau sont simulés par le simulateur de réseau. Les périphériques tels que des téléphones sont simulés par l interface utilisateur graphique (GUI). D'un point de vue protocole, il est transparent à une application s'il communique avec un noeud réel de NRG, ou au simulateur de NRG. Figure 3.6: Vue de système du simulateur de NRG Ingénieurs 2006 Trabelsi Walid 42

52 Chapitre 3 : Les outils et les services nécessaires pour le développement de l application II. Les Services supportés par le NRG simulator 1. Vue d ensemble Le NRG gère les services supportés par H-OSA [9] qui introduit des extensions et des prolongements des services d OSA/Parlay. Les services sont : Framework : Il permet de faire l authentification et l autorisation à une application pour pouvoir accéder aux différents dispositifs possibles de services (SCF). Il permet également d établir l accord de service pour avoir le droit d accès aux services SCF qui seront enregistrés dans le Framework. Call Control : Il permet de manipuler et de créer des appels téléphoniques, il inclut aussi la fonctionnalité Multi-Party Call Control. User Interaction : Il fournit aux applications les possibilités pour envoyer les messages par l'intermédiaire de SMS, MMS, Wap-push et . En plus les applications peuvent également recevoir des messages par l'intermédiaire de SMS et MMS. User Location : Il permet aux applications de trouver des informations sur l endroit de l utilisateur du mobile. User Status : il permet aux applications les possibilités à demander et recevoir les informations sur le statut de connectivité et de disponibilité de l'abonné, les applications peuvent baser leur demande sur le MSISDN, le nom d utilisateur ou l adresse IP. Generic Messaging : Il fournit aux applications les possibilités à notifier des nouveaux messages et recherchez et supprimez les messages des boîtes aux lettres d'une application Personal Information Management (PIM) Contact : il permet de contrôler des adressbooks d abonnées. Donc nous avons présenté tous les services supportés par le NRG mais ce qui concerne notre application on a besoin seulement d utiliser les deux services suivants User Interaction et User Location qui sont nécessaires pour envoyer et recevoir des messages de types SMS et MMS ainsi que pour trouver la localisation de l utilisateur du mobile. C est la raison pour laquelle je vais bien détailler ces deux services. 2. Interaction d Utilisateur (User Interaction) Le service H-OSA User Interaction [11] fournit aux applications la possibilité d envoyer des messages à travers des SMS, MMS, Wap-push et . Les applications peuvent également recevoir des notifications des messages envoyés Diagramme de Séquence Réception de Message Ingénieurs 2006 Trabelsi Walid 43

53 Chapitre 3 : Les outils et les services nécessaires pour le développement de l application Figure 3.7: Diagramme de séquence de réception d un message 1 : L application enregistre la réception d un SMS. Il spécifie les adresses de callback et de terminaison. Le champ du code de service peut être employé pour stocker l identification de l application qui sera passé de nouveau à l application dans le reportnotification. 2 : AssignmentID, qui identifie uniquement la notification crée, est retourné. 3 : Si un SMS entrant assortit une notification stockée, ça sera envoyé à l application utilisant la référence de callback fournit dans la notification. L évènement rapporté qui contient l adresse d origine, l adresse de terminaison où le SMS a été reçu. L évènement rapporté contient également le code de service qui retourne la valeur de la chaîne (String value) qui est enregistré avec la notification. Il peut être utilisé par exemple pour identifier l application 4 : L application renvoie la référence de l interface UI (User Interaction) de l application. 5 : L implémentation de IpUI va être libéré après que la notification sera rapportée. C'est une déviation habituel dans le contexte d'osa, où l'application est responsable de libérer l'exemple d'ipui. Ingénieurs 2006 Trabelsi Walid 44

54 Chapitre 3 : Les outils et les services nécessaires pour le développement de l application 6 : L application demande la modification de la notification enregistrée. Elle spécifie l adresse de callback et l adresse de terminaison. Le code de service enregistre l identification de l application qui va être passé ensuite à l application dans le reportnotification. 7 : AssignmentID, qui identifie uniquement la notification crée, est retourné. 8 : L application demande au système la suppression de la notification crée Envoie de message avec erreur Le diagramme de séquence suivant montre comment une application demande le service User Interaction pour envoyer un message, la demande sera acceptée mais après lorsque la demande progresse dans le service découvert une erreur qui sera rapportée avec une méthode d erreur. Figure 3.8: Diagramme de séquence d envoie de message avec erreur 1 : L application demande au système à envoyer un message à un ou plusieurs utilisateurs. 2 : AssignmentID, qui identifie uniquement la notification crée, est retourné. 3 : Si l'application demande une réponse et la demande de message d'envoi n'était pas exécutée avec succès, ceci est rapporté avec un message d erreur «hosasendmessageerr». Quand le hosasendmessagereq s'adresse aux utilisateurs multiples, les résultats par utilisateur peuvent être retourné dans des messages multiples hosasendmessageres/ hosasendmessageerr Envoie de message avec succès de réception Le diagramme de séquence suivant montre comment une application demande le service User Interaction pour envoyer un message, la réception se fait avec succès. Ingénieurs 2006 Trabelsi Walid 45

55 Chapitre 3 : Les outils et les services nécessaires pour le développement de l application Figure 3.9: Diagramme de séquence d envoie de message avec succès de réception 1 : L application demande au système à envoyer un message à un ou plusieurs utilisateurs. 2 : AssignmentID, qui identifie uniquement la notification crée, est retourné. 3 : Si l'application demande une réponse et la demande de message d'envoi était exécutée avec succès, ceci est rapporté avec un message de hosasendmessageres. Quand le hosasendmessagereq s'adresse aux utilisateurs multiples, les résultats par utilisateur peuvent être retourné dans des messages multiples de hosasendmessageres / hosasendmessageerr. 4 : Si l'application demande une notification de la livraison et la livraison était exécutée avec ou sans succès, c'est rapporté avec un message de hosamessagedeliverynotification. Quand le hosasendmessagereq s'adresse aux utilisateurs multiples, des avis par utilisateur sont retournés dans les messages séparés de hosamessagedeliverynotification Diagramme de Classe Ingénieurs 2006 Trabelsi Walid 46

56 Chapitre 3 : Les outils et les services nécessaires pour le développement de l application Figure 3.10: Diagramme de séquence du service d interaction d utilisateur Classe d interface IpHosaUIManager Cette classe hérite de l interface «IpUIManager» qui permet la gestion de service pour le service d'interaction d'utilisateur de H-OSA et elle fournit les fonctions de gestion au service générique d'interaction d'utilisateur de H-OSA. hosasendmessagereq (appuimanager : in IpAppHosaUIManager, originatingaddress : in TpAddress, terminatingaddresslist : in TpHosaTerminatingAddressList, subject : in TpString, message : in TpHosaMessage, deliverytype : in TpHosaUIMessageDeliveryType, billingid : in TpString, responserequested : in TpUIResponseRequest, deliverynotificationrequested : in TpBoolean, deliverytime : in TpHosaDeliveryTime, validitytime : in TpDateAndTime) : TpAssignmentID La méthode hosasendmessagereq( ) Ingénieurs 2006 Trabelsi Walid 47

57 Chapitre 3 : Les outils et les services nécessaires pour le développement de l application Méthode hosasendmessagereq( ) : cette méthode envoie un message à(aux) l utilisateur(s). Paramètres - appuimanager : in IpAppHosaUIManager : Si ce paramètre est différent de la valeur NULL, elle indique une référence à l'interface d'application, qui est employée pour callbacks. Si sa valeur est NULL, l'interface d'application se transfère sur l'interface indiquée par l'intermédiaire de la méthode de setcallback (). - originatingaddress : in TpAddress : L adresse est utilisée pour représenter l émetteur du message - terminatingaddresslist : in TpHosaTerminatingAddressList : Une liste d'adresses des utilisateurs à qui le message sera envoyé. - subject : in TpString : spécifie le sujet de message. Utilisé sauf si le type du message le supporte. - message : in TpHosaMessage : Le message actuel qu on est besoin d envoyer. - deliverytype : in TpHosaUIMessageDeliveryType : Indique quelle méthode délivrée sera employée pour être livrer à l'utilisateur. - billingid : in TpString : Une identification de facturation qui peut être employé pour indiquer comment les coûts pour cette transaction seront chargés. - responserequested : in TpUIResponseRequest : Indique si une réponse est exigée du service d'interaction d'utilisateur. - deliverynotificationrequested : in TpBoolean : Indique si un avis de la livraison est exigé. - deliverytime : in TpHosaDeliveryTime : Indique si le message sera fourni immédiatement ou à une certaine heure indiquée. - validitytime : in TpDateAndTime : Indique le temps où le message garde sa validité. Quand le message n'est pas fourni avant le passage du temps de validité, le message est lâché par le système de transmission de messages Classe d interface IpAppHosaUIManager Cette classe hérite de l interface «IpAppUIManager» qui fournit aux applications les fonctions de callbacks pour le service service générique d'interaction d'utilisateur. hosasendmessageres (assignmentid : in TpAssignmentID, responselist : in TpHosaSendMessageReportSet) : void hosasendmessageerr (assignmentid : in TpAssignmentID, errorlist : in TpHosaSendMessageErrorSet) : void hosamessagedeliverynotification (assignmentid : in TpAssignmentID, timestamp : in TpDateAndTime, useraddress : in TpAddress, deliverystatus : in TpHosaUIMessageDeliveryStatus ) : void Les méthodes de l interface IpAppHosaUIManager Ingénieurs 2006 Trabelsi Walid 48

58 Chapitre 3 : Les outils et les services nécessaires pour le développement de l application Méthode hosasendmessageres() : Cette méthode asynchrone informe l application de l accomplissement de la méthode hosasendmessagereq(). Paramètres assignmentid : in TpAssignmentID : spécifie l ID assigné par l interface d interaction d utilisateur pour la demande d utiliser le service. responselist : in TpHosaSendMessageReportSet : Elle contient le rapport de statut des messages reçus avec succès pour un ou plusieurs utilisateurs. Méthode hosasendmessageerr() : Elle indique que la demande d envoie de message est n est pas assurée. Paramètres assignmentid : in TpAssignmentID : Idem. errorlist : in TpHosaSendMessageErrorSet : spécifie l'erreur qui a mené au l échec de la demande pour un utilisateur spécifique. Méthode hosamessagedeliverynotification( ) : Cette méthode indique à l application le succès de la livraison du message, pour un utilisateur spécifique qui a été envoyé avec la méthode hosasendmessagereq(). Cette réponse est appelée sauf si le paramètre «deliverynotificationrequested» est égal à "true". Paramètres assignmentid : in TpAssignmentID : Idem. timestamp : in TpDateAndTime : Il est reçu par le système de messagerie lorsqu il accepte le message. useraddress : in TpAddress : Indique l'utilisateur pour lequel l'avis de la livraison de message est envoyé. 3. Localisation d Utilisateur (User Location) Le service H-OSA User Location [12] fournit aux applications la possibilité de demander et recevoir des informations concernant la localisation ou l endroit d un ou plusieurs utilisateurs. Il supporte des extensions de paramètres spécifiques des API de OSA User Location Diagramme de séquence Demande interactive de la localisation d utilisateur Le diagramme de séquence suivant montre comment une application demande le rapport de localisation du service User Location. Ingénieurs 2006 Trabelsi Walid 49

59 Chapitre 3 : Les outils et les services nécessaires pour le développement de l application Figure 3.11: Diagramme de séquence de la demande interactive de la localisation d utilisateur 1 : Ce message est utilise pour demander la localisation d un ou plusieurs utilisateurs. 1.1 : SessionID, qui identifie uniquement la dernière demande, est retourné 2 : Ce message passe le résultat de la demande de localisation pour un ou plusieurs utilisateurs à travers les objets de callback Demande du service avec erreur Le diagramme de séquence suivant montre comment une application demande le rapport de localisation du service User Location. Mais quand la demande progresse, le service découvert une erreur et renvoie une méthode d erreur. Figure 3.12: Diagramme de séquence de la demande du service de localisation avec erreur 1 : Ce message est utilisé pour demander la localisation d un ou plusieurs utilisateurs. Ingénieurs 2006 Trabelsi Walid 50

60 Chapitre 3 : Les outils et les services nécessaires pour le développement de l application 1.1 : SessionID, qui identifie uniquement la dernière demande, est retourné 2 : Une erreur est produite au cours de la progression de la demande après que la demande était acceptée par l instance de service Demande périodique du service de localisation Le diagramme de séquence suivant montre comment une application demande le report de localisation périodiquement du service User Location. Figure 3.13: Diagramme de séquence de la demande périodique du service de localisation 1 : Ce message est employé pour commencer la localisation périodique rapporter pour un ou plusieurs utilisateurs. 1.1 : SessionID, qui identifie uniquement la dernière demande, est retourné. 2 : Ce message passe le résultat de la demande de localisation d un ou plusieurs utilisateurs à travers des objets de callback. Cela est répété dans des intervalles réguliers jusqu à l application termine le rapport de localisation périodique. 3 : Ce message passe le résultat de la demande de localisation d un ou plusieurs utilisateurs à travers des objets de callback. Ingénieurs 2006 Trabelsi Walid 51

61 Chapitre 3 : Les outils et les services nécessaires pour le développement de l application 4 : Ce message est utilisé pour stopper le report de localisation périodique Diagramme de classe Figure 3.14: Diagramme de séquence du service de localisation d utilisateur Classe d interface IpHosaUserLocation Cette classe hérite de l interface IpUserlocation qui permet la gestion du service de localisation d utilisateur qui fournit les fonctions de gestion. Le programmeur d application peut utiliser cette interface pour obtenir l endroit géographique des utilisateurs. hosaperiodiclocationreportingstartreq (applocation : in IpAppHosaUserLocation, users : in TpAddressSet, request : in TpHosaLocationRequest, reportinginterval : in TpDuration, timeinterval : in TpTimeInterval) : TpSessionID hosaextendedlocationreportreq (applocation : in IpAppHosaUserLocation, users : in TpAddressSet, request : in TpHosaLocationRequest) : TpSessionID Les méthodes de l interface IpHosaUser Location Méthode hosaperiodiclocationreportingstartreq() : Demande le rapport périodique de la localisation d un ou plusieurs utilisateurs. Paramètres applocation : in IpAppHosaUserLocation : spécifie l interface de l application pour les callbacks du service de localisation d utilisateur. users : in TpAddressSet : Indique l'utilisateur (s) pour lequel l'endroit sera rapporté. Ingénieurs 2006 Trabelsi Walid 52

62 Chapitre 3 : Les outils et les services nécessaires pour le développement de l application request : in TpHosaLocationRequest : Indique le type, l'exactitude, le temps de réponse et la priorité demandés d'endroit. reportinginterval : in TpDuration : spécifie l'intervalle demandé en secondes entre les rapports. timeinterval : in TpTimeInterval : Indique le temps de début et d'arrêt où les rapports périodiques de localisation seront envoyer à l'application. Méthode hosaextendedlocationreportreq() : Demande avancée de rapport sur l'endroit pour un ou plusieurs utilisateurs. Paramètres applocation : in IpAppHosaUserLocation : Idem. users : in TpAddressSet : Idem. request : in TpHosaLocationRequest : Idem Classe d interface IpAppHosaUserLocation Cette classe hérite de l interface IpAppUserLocation. L interface d application de localisation d utilisateur est implémentée par le développeur d application client et il est utilisé pour manipuler les réponses de demandes de localisation des utilisateurs. hosaextendedlocationreportres (assignmentid : in TpSessionID, locations : in TpHosaUserLocationExtendedSet) : void hosaperiodiclocationreport (assignmentid : in TpSessionID, locations : in TpHosaUserLocationExtendedSet) : void Les méthodes de l interface IpAppHosaUserLocation Méthode hosaextendedlocationreportres() : Un rapport contenant l'information prolongée d'endroit pour un ou plusieurs utilisateurs est fourni. Paramètres assignmentid : in TpSessionID : Indique l'identification de tâche de la demande du rapport prolongée de localisation. Locations : in TpHosaUserLocationExtendedSet : Spécifie la (les) localisation d un ou plusieurs utilisateurs. Méthode hosaperiodiclocationreport() : Un rapport contenant l'information périodique d'endroit pour un ou plusieurs utilisateurs est fourni. Paramètres assignmentid : in TpSessionID : Idem. locations : in TpHosaUserLocationExtendedSet : Idem. Ingénieurs 2006 Trabelsi Walid 53

63 Chapitre 3 : Les outils et les services nécessaires pour le développement de l application Conclusion Dans ce chapitre nous avons défini l approche que nous avons adoptée pour la mise en oeuvre de la plateforme OSA/Parlay. Nous avons détaillé les outils nécessaires qu on va les utiliser pour développer notre application ainsi que les deux services qui sont considérés comme des conséquences de l application. En plus nous avons vu toutes les services supportés par la plateforme OSA/Parlay en se focalisant sur les quelles on est besoin à utiliser pour notre projet. Ces services seront nécessaires pour la conception et le développement de l application qu on va l attaquer dans le chapitre suivant. Ingénieurs 2006 Trabelsi Walid 54

64 Chapitre 4 : Conception et développement de l application Chapitre 4. Conception et Développement de l Application Introduction L application que je désire développer au cours de ce projet de fin d études a pour but essentiel de créer un nouveau service de messagerie en se bénéficiant des applications multimédia utilisées dans les réseaux mobiles de 3 ème génération. Ce service permet aux utilisateurs du téléphone mobile de trouver leur localisation dans n importe quel région de la ville de Tunis. Donc le développement de l application consiste de trois étapes, d abord l utilisateur de téléphone mobile envoie un SMS au numéro service 2222, ensuite le service va chercher la localisation du mobile suivant la mappe du simulateur d Ericsson et enfin l application va renvoyer à l utilisateur un MMS contenant la mappe de la ville de Tunis sur laquelle se trouve la localisation du mobile. Cette application développée sera la base pour créer deux services de messagerie des téléphones mobiles des nouvelles générations. Le premier service permet aux utilisateurs de récupérer les deux plus proches magasins de la ville de Tunis par rapport à la localisation de l utilisateur de téléphone mobile, le deuxième consiste à récupérer la localisation d un autre mobile qui nous intéresse à suivre son déplacement, en garantissant la sécurité d accès au téléphone mobile. I. Environnement utilisé pour le développement de l application 1. Ericsson NRG Simulator Comme c est décrit dans le chapitre précédent, Le Simulateur d Ericsson [8] est le composant essentiel utilisé pour tester l application développée puisque il est considéré comme un Gateway de ressource du réseau de Télécom, donc il permet d ajouter des téléphones mobiles pour envoyer et recevoir des messages de types SMS et MMS ainsi que l intégration d une mappe pour sur laquelle nous trouvons la localisation initiale du mobile. Voir chapitre JDevelopper : Java Java possède un certain nombre de caractéristiques qui ont largement contribué à son énorme succès parmi ces caractéristiques nous pouvons citer qu il est indépendant de toute plate forme, il est orienté objet, c'est-à-dire chaque fichier source contient la définition d'une ou plusieurs classes qui sont utilisées les unes avec les autres pour former une application. Il est sûr puisque la sécurité est une partie intégrante du système d'exécution et du compilateur. Java est aussi le langage utilisé dans les différents packages de la plate forme OSA/Parlay en plus c est le langage utilisé pour inter réagir avec le simulateur d Ericsson. C est pourquoi Java est le langage utilisé pour le développement de notre application. Ingénieurs 2006 Trabelsi Walid 55

65 Chapitre 4 : Conception et développement de l application II. Les étapes de développement de l application 1. Envoie d un SMS La première étape de l application consiste à développer la méthode d envoie d un message SMS sous la plateforme OSA/Parlay ensuite la tester sur le simulateur NRG d Ericsson. Cette première application utilise le service de messagerie supporté par le NRG simulator et essentiellement le service H-OSA User Interaction [11] pour envoyer et recevoir des messages courts Diagramme de séquence Figure 4.1: Diagramme de séquence d envoie d un SMS Le diagramme suivant est composé de trois parties. Une première partie concernée à la connexion au Framework [10] à fin d obtenir le service User Interaction en créant les notifications nécessaires. Ensuite une partie qui décrit le mécanisme d envoie d un SMS et finalement la dernière partie montre la déconnexion du Framework en libérant toutes les ressources utilisées Description du fonctionnement du mécanisme d envoie d un SMS Dans la première partie du diagramme de séquence utilisé pour se connecter au Framework et demander le service d interaction d utilisateur, on trouve les étapes suivantes : Ingénieurs 2006 Trabelsi Walid 56

66 Chapitre 4 : Conception et développement de l application 1) À partir de l interface graphique de l utilisateur GUI qui permet d agir avec le simulateur NRG, on commence à charger la configuration qui fournit à l application des données spécifiques. Elle définit quels paramètres existent et comment le dossier de configuration devrait être analysé. 2) A partir de la classe Dispositif qui implémente la logique (c.-à-d. le comportement fonctionnel) de l'application, on demande l accès au service nécessaire (User Interaction) de la classe spécifique FWProxy du Framework qui est employé pour obtenir un ou plusieurs gestionnaires de service qui sont nécessaires à l'application. 3) Ensuite Les gestionnaires de services sont utilisés pour créer le processeur du SMS. Ce dernier agit avec le NRG, il emploie un gestionnaire de service «IpHosaUIManager» pour envoyer des demandes au NRG, et prolonge un adaptateur de gestion de service pour les callbacks «IpAppHosaUIManager» pour recevoir des réponses de callback. 4) Enfin il y aura un établissement des notifications nécessaires qui montre l accès avec succès au service. Maintenant, ce qui concerne la deuxième partie qui décrit le mécanisme d envoie d un SMS, on trouve les étapes suivantes : 1) A partir de l interface graphique on demande au Dispositif d envoyer un SMS, cela sera reporté au processeur d envoie d un SMS. La méthode d envoie d un SMS contient une signature qui la suivante : public void sendsms (String Sender, String Receiver, String MessageContent) Signature d envoie d un SMS 2) L application va provoquer la méthode «HosaSendMessageReq» pour envoyer le SMS. Cette méthode qui se trouve dans la classe SMSprocessor possède la signature suivante : Ingénieurs 2006 Trabelsi Walid 57

67 Chapitre 4 : Conception et développement de l application public int hosasendmessagereq( IpAppHosaUIManager appuimanager, TpAddress originatingaddress, TpHosaTerminatingAddressList terminatingaddresslist, String subject, TpHosaMessage message, TpHosaUIMessageDeliveryType deliverytype, String billingid, int responserequested, boolean deliverynotificationrequested, TpHosaDeliveryTime deliverytime, String validitytime) throws TpCommonExceptions, P_INVALID_SESSION_ID,.. ) Signature de la méthode «HosaSendMessageReq» 3) Comme résultat de la méthode «HosaSendMessageReq», L application reçoit du NRG soit «HosaSendMessageRes» ou «HosaSendMessageErr» dépendant du succès ou non de la demande. Les méthodes de callbacks de «HosaSendMessageReq» sont les suivantes : public void hosasendmessageres( int anassignmentid, TpHosaSendMessageReport[] aresponselist) {... } public void hosasendmessageerr( int anassignmentid, TpHosaSendMessageError[] anerrorlist) {... } Les méthodes de callbacks de «HosaSendMessageReq» Finalement, la dernière étape qui permet de se déconnecter du Framework et de libérer toutes les ressources utilisées contient les mécanismes suivants : 1) À partir de l interface graphique GUI, on demande au Dispositif de terminer l application. 2) Le processeur est débarrassé en stoppant tous les notifications. 3) Les gestionnaires de service sont libérés. 4) L'accès au Framework est terminé et des ressources internes sont disposées. Ingénieurs 2006 Trabelsi Walid 58

68 Chapitre 4 : Conception et développement de l application 2. Localisation du Mobile La deuxième étape consiste à développer une méthode de localisation du téléphone mobile de l utilisateur et l afficher sur la mappe. Cette application utilise le service Information Kit supporté par le simulateur NRG et essentiellement H-OSA User Location [12] enregistré dans le NRG Framework Diagramme de séquence Figure 4.2: Diagramme de séquence de localisation du mobile De la même façon, ce diagramme est composé de trois parties. Une première partie concernée à la connexion au Framework à fin d obtenir le service User Location en créant les notifications nécessaires. Ensuite une partie qui décrit le mécanisme localisation d un mobile et finalement la dernière partie montre la déconnexion du Framework en libérant toutes les ressources utilisées Description du fonctionnement du mécanisme de localisation du mobile Ce qui concerne la première et la troisième partie, elles sont identiques à celle décrit dans le diagramme de séquence d envoie d un SMS sauf que le service demandé n est plus User Interaction mais plus c est le service User Location. Donc nous allons détailler la deuxième Ingénieurs 2006 Trabelsi Walid 59

69 Chapitre 4 : Conception et développement de l application partie qui décrit le mécanisme de recherche de la localisation d un utilisateur de téléphone mobile. Les étapes de ce mécanisme sont les suivant : 1) À partir de l interface graphique GUI on utilise la méthode «Refresh» pour demander de la classe Dispositif la localisation du mobile qui sera reporté processus de localisation. 2) Le processus de localisation invoque la méthode «extendedlocationreportreq» pour s adapter à l approche du processus de localisation donné par OSA/Parlay. Voici la signature de la demande de la localisation : public void requestlocation(string User) {.. itsulmanager.extendedlocationreportreq(this, user, request); } Signature de la méthode «requestlocation» L argument this est utilisé comme un callback renvoyé par le NRG pour retourner les reports de localisation. La localisation de téléphone mobile est faite par la méthode GPS qui est utilisé dans les réseaux mobile. Dans le NRG simulator, nous utilisons la valeur NETWORK pour indiquer la méthode de localisation et l exactitude sera de l ordre de 100 mètres. Cette déclaration se résume dans la méthode «locationmethod» : { TpAddress[] users = new TpAddress[aUserList.length]; for (int i = 0; i!= users.length; i++) { users[i] = createtpaddress(auserlist[i]); } TpLocationResponseTime responsetime = new TpLocationResponseTime( TpLocationResponseIndicator. P_M_DELAY_TOLERANT, -1); // timer value, not applicable float accuracy = 100f; // en mètre boolean altituderequested = false; String locationmethod = "NETWORK"; TpLocationRequest request = new TpLocationRequest(accuracy, responsetime, altituderequested, TpLocationType.P_M_CURRENT, TpLocationPriority.P_M_NORMAL, locationmethod); Déclaration de la méthode «locationmethod» Ingénieurs 2006 Trabelsi Walid 60

70 Chapitre 4 : Conception et développement de l application 3) Ensuite le NRG va renvoyer la réponse de la localisation par la méthode «extendedlocationreporterr» en cas d erreur ou «extendedlocationreportres» en cas de succès de la demande et nous récupérons par suite la latitude et la longitude de l endroit de l utilisateur mobile. La déclaration de cette dernière est la suivante : public void extendedlocationreportres( int anassignmentid, TpUserLocationExtended[] reports) { for (int i = 0; i!= reports.length; i++) { String user = reports[i].userid.addrstring; if (reports[i].statuscode == TpMobilityError.P_M_OK) { float latitude = reports[i]. Locations[0].GeographicalPosition. Latitude; float longtitude = reports[i]. Locations[0].GeographicalPosition. Longitude; itsparent.locationreceived(user, latitude, longtitude); }}} Déclaration de la méthode «extendedlocationreportres» 4) Enfin en recevant une réponse des coordonnées (la latitude et la longitude) de la localisation de l utilisateur, la nouvelle localisation du mobile sera affichée sur la mappe de l interface de l utilisateur. 3. Application Finale : Renvoie d un MMS L application finale est composée de trois parties. D abord, nous envoyons un SMS à un numéro de service spécifique, ensuite l application va récupérer la localisation de l utilisateur du téléphone mobile et enfin l application va retourner un MMS contenant une mappe de la ville de Tunis sur laquelle se trouve l endroit du mobile. Donc cette application va utiliser les deux applications précédents avec l addition de l envoie d un MMS qui ne diffère pas beaucoup de celle d un SMS sauf qu il ne s agit pas simplement d un champ de texte mais plu stot il faut ajouter un autre champ contenant des données multimédia comme des images ou des sons. Donc à fin de développer cette application, on est besoin d utiliser les deux services supporté par le NRG et qui sont testés dans les deux applications précédents : H-OSA User Interaction pour l envoie d un SMS et la réception d un MMS et H-OSA User Location pour chercher la localisation de l utilisateur du téléphone mobile. Ingénieurs 2006 Trabelsi Walid 61

71 Chapitre 4 : Conception et développement de l application 3.1. Le diagramme de séquence Le diagramme de séquence de l application finale illustré dans la figure au dessous se compose de cinq étapes. La première et la dernière étape sont utilisées comme dans les deux applications précédentes pour la connexion et la déconnexion du Framework, la demande et la libération des deux nécessaires services H- OSA User Interaction et H-OSA User Location. Les trois étapes restantes représentent le noyau de l application qui consiste d envoyer un SMS au numéro de service dans une première étape, ensuite la récupération de la localisation de l utilisateur de téléphone mobile et enfin le renvoie du MMS contenant une mappe dans laquelle se trouve l endroit du mobile. Ingénieurs 2006 Trabelsi Walid 62

72 Chapitre 4 : Conception et développement de l application Figure 4.3: Diagramme de séquence de l application finale : Renvoie d un MMS Ingénieurs 2006 Trabelsi Walid 63

73 Chapitre 4 : Conception et développement de l application 3.2. Description du fonctionnement du mécanisme de l application finale Ce qui concerne l envoie du SMS et la recherche de la localisation du mobile sont détaillés dans les paragraphes suivantes. Donc nous allons nous intéresser ici à l explication du mécanisme d envoie d un MMS et les modifications que nous allons apportés par rapport à l envoie d un SMS. Un MMS peut contenir du texte seulement, ou hors d'une combinaison de différents types multimédia comme le texte, les images et l'audio. La méthode de «hosasendmessagereq» doit soutenir les deux scénarios. Lorsque l application notifie l arrivée d un SMS assuré par la méthode «reportnotification», d abord il y aura recherche de la localisation du mobile décrit dans la deuxième étape, ensuite il faut ajouter des contenus multimédia assuré par la méthode «addtextmedia». Le contenu d un MMS est assuré par la classe «MMSMessageContent» qui décrit comment on ajout des données multimédia dans un message. Ces derniers doivent contenir des entêtes spécifiques comme «Content-Type» qui définit le type de média qui spécifie le type de donnée utilisé et «Content-ID» qui identifie les entités utilisées. Donc pour assurer la composition des différents parties dans le message, on ajout le morceau de code suivant : FileDataSource fds = new FileDataSource(aFilename); MimetypesFileTypeMap map = new MimetypesFileTypeMap(); MimeBodyPart mbp = new MimeBodyPart(); mbp.setdatahandler(new DataHandler(fds)); mbp.setheader("content-type", map.getcontenttype(afilename)); mbp.setheader("content-transfer-encoding", "base64"); mbp.setcontentid("cont" + getcount()); addbodypart(mbp); Composition d un message à parties multiples Le «FileDataSource» peut rechercher le type de fichier fourni. Ce type est nécessaire pour placer le «content-type» exigé. Le réglage de ce «Contenu-Type» (par exemple image/jpeg) est fait au moyen de la méthode «setheader». Pour placer l'identification de contenu «Content-ID» qui identifie uniquement une partie, la méthode «setcontentid» de convenance est employé. Cette application d'exemple emploie le paramètre «CONT» avec un nombre apposé. Le nombre apposé est le nombre des parties supplémentaires ajoutées (recherché par la méthode de «getcount»). Comme dans le mécanisme d'envoie d'un SMS, la méthode de hosasendmessagereq est très flexible et devient plus complexe pour l'envoie d'un MMS. La seule différence avec envoyer un SMS est le type de message (ici MMS) et le message (maintenant elle contient un message à parties multiples). Donc la signature de la méthode d envoie d un MMS devient : Ingénieurs 2006 Trabelsi Walid 64

74 Chapitre 4 : Conception et développement de l application protected void sendmms(string asender, String areceiver, byte[] amessagecontent, String amessagesubject) La méthode d envoie d un MMS Le paramètre «amessagecontent» est déclaré byte, parce que les parties multipes contiennent des données binaires (des images). Quelques paramètres de la méthode d envoie de MMS sont converties en paramètres de la méthode «hosasendmessagereq» comme par exemple :... TpHosaUIMessageDeliveryType deliverytype = TpHosaUIMessageDeliveryType.P_HUI_MMS;... TpHosaMessage message = new TpHosaMessage(); message.binarydata(amessagecontent);... Les changements de paramètres Le paraùmètre «deliverytype» doit être placé à P_HUI_MMS, pour s'assurer que le message est envoyé comme MMS. Le diagramme de séquence prouve que l'invocation d'envoie d'un MMS "sendmms" a lieu quand le contenu de MMS est ajouté à la classe «MMSMessageContent». La rangée de "byte" est recherchée de la classe «MMSMessageContent» au moyen de la méthode «getbinarycontent» : itsmmsprocessor.sendmms(... messagecontent.getbinarycontent()...); L invocation d envoie de MMS Dans la classe «MMSMessageContent» nous allons ajouter une méthode appelée «getbinarycontent». Cette méthode renvoie toutes les parties multiples complètes comme un type "byte", ainsi elle peut être employée avec la méthode d'envoie de MMS. Ingénieurs 2006 Trabelsi Walid 65

75 Chapitre 4 : Conception et développement de l application public byte[] getbinarycontent() {... ByteArrayOutputStream bytearraybuffer = new ByteArrayOutputStream(); // Le type du contenu est demandé // et il est ajouté à la sortie. String contenttype = "Content-Type: " + this.getcontenttype() + "\r\n\r\n"; bytearraybuffer.write(contenttype.getbytes()); bytearraybuffer.flush(); writeto(bytearraybuffer); return bytearraybuffer.tobytearray();... } Déclaration de la méthode «getbinarycontent» III. Utilité de l application L utilité de l application développée se voit dans les services qu on peut tirer comme des conséquences de cette application. En effet, nous pouvons créer plusieurs services selon les besoins des utilisateurs. Parmi ces services, nous avons crée deux services dont le premier consiste à récupérer la localisation des plus proches magasins (banques, agences,..), selon le choix de l utilisateur, par rapport à l endroit du mobile. Le deuxième service permet de suivre la localisation d un autre mobile dans son déplacement en assurant la sécurité d accès à un autre mobile er Service : Demande des plus proches magasins par rapport à l endroit du mobile Un premier service, défini comme une conséquence de l application développée permet aux utilisateurs des téléphones mobiles des nouvelles générations de trouver les deux plus proches magasins (banques, restaurants, agences ) par rapport à leur localisation en identifiant la ville (Tunis, Sfax, Sousse ) auquel se trouve l utilisateur. Dans ce service, nous avons besoin d utiliser une base de donnée dans laquelle nous allons enregistrer toutes les Altitudes (les latitudes et les longitudes) possibles des différents magasins dans une région bien déterminée de la Tunisie. Après la création de la base de donnée, il faut que cette dernière soit connecter à l interface de développement pour récupérer toutes les informations de la base de donnée et l utilisée en programmation. Pour réaliser la connexion, nous ajoutons le code suivant : Ingénieurs 2006 Trabelsi Walid 66

76 Chapitre 4 : Conception et développement de l application public void connexion{ Connection con=null; try{ Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); } catch (ClassNotFoundException e){ } //connection a la base de données float latitude,longitude; try { String DBurl = "jdbc:odbc:basexlt"; con = DriverManager.getConnection(DBurl); } catch (java.sql.sqlexception e) { ; } catch(exception e) { e.printstacktrace(); } System.out.print(con.toString()); } try{ ResultSet rs; Statement stmt=con.createstatement(); rs=stmt.executequery("select * from table;"); ; La méthode de connexion à la base de donnée Après la connexion à la base, nous aurons alors toutes les altitudes (les latitudes et les longitudes) des différents magasins, en récupérant la localisation du mobile, nous pouvons alors calculer la distance séparant l utilisateur de chaque magasin. Et par suite nous prenons en considération les deux distances les plus minimums et qui vont correspondre aux deux plus proches magasins, ensuite leurs localisations sera affiché avec la localisation du mobile sur la mappe du message MMS. Ingénieurs 2006 Trabelsi Walid 67

77 Chapitre 4 : Conception et développement de l application public void locationreceived(string user, float userlatitude, float userlongitude) { try { ImageIcon phone = Configuration.INSTANCE.getImage("phone.png"); int wp = phone.geticonwidth(); int hp = phone.geticonheight();. Float x,y,d; // base de donnée try{ ResultSet rs; Statement stmt=con.createstatement(); rs=stmt.executequery("select * from table2;"); // parcours de la base de donnée while (rs.next()){ x=rs.getfloat("latitude"); y=rs.getfloat("longitude"); d= sqr(userlatitude-x) + sqr( userlongitude-y)//distance } Recherche la distance entre l utilisateur et les magasins 2. 2 ème Service : Suivre la localisation d un autre mobile Une deuxième conséquence de l application développée consiste à créer un autre service permettant à l utilisateur de téléphone mobile de la nouvelle génération de récupérer, à chaque instant, la localisation d un autre mobile qui lui intéresse. Par exemple si un patron d une entreprise a besoin de trouver la place de son employeur qui est entrain de distribuer les dans un camion. Pour ce service il faut bien assurer la notion de sécurité puisqu il ne faut pas que n importe quel utilisateur de téléphone mobile puisse récupérer la localisation de n importe quel autre utilisateur. Pour cela nous pouvons utiliser deux solutions, soit nous créons une base de donnée dans laquelle nous aurons des relations spécifiques entre les différents utilisateurs, soit nous manipulons un fichier de configuration de l application en ajoutant toutes les modifications nécessaires à fin d assurer l authentification des utilisateurs qui peuvent bénéficier de ce service. D abord tous les utilisateurs seront enregistrés dans le fichier de configuration sous la forme suivante : Subsciber.Authorized.Number, donc ils seront tous différenciés par leur numéro de téléphone mobile (Number), nous ajoutons aussi dans le fichier le numéro de service : Ensuite nous développons sur JDevelopper la classe «Configuration» qui va manipuler le fichier. On a besoin de déclarer les méthodes «load», «loadstring», «loadsubscriber», et «loaduser» dans cette classe pour avoir charger les paramètres du fichier de configuration. Nous allons récupérer les informations concernant tous les utilisateurs ainsi que le numéro de service : Ingénieurs 2006 Trabelsi Walid 68

78 Chapitre 4 : Conception et développement de l application public void load(object asource) throws IOException { super.load(asource); itssubscriber = loadsubscriber("subscriber"); itsservicenumber = loadservicenumber("servicenumber"); } private String loadstring(string aparm) { String s = getproperty(aparm); if (s == null) { throw new NotFoundException(aParm); } return s; } private Subscriber loadsubscriber(string aparm) { Subscriber subscriber = new Subscriber(); subscriber.useraccess = loaduser(aparm + ".Authorized"); return subscriber; } private String[] loaduser(string aparm) { List friends = new ArrayList(); for (int i = 0;; i++) { try { friends.add(loadstring(aparm + "." + i)); } catch (NotFoundException e) { break; }} return (String[]) UserAccess.toArray(new String[0]); } Déclaration des méthodes de chargement des paramètres du fichier de configuration de la classe «Configuration» A fin de tester si l utilisateur de téléphone mobile a le droit d utiliser le service de récupération de localisation d un autre mobile, il faut ajouter la classe «Subscriber» qui a pour but de trouver la relation entre les utilisateurs et s ils ont l autorisation d utiliser le service. Ingénieurs 2006 Trabelsi Walid 69

79 Chapitre 4 : Conception et développement de l application public static class Subscriber { public String phonenumber; public String[] UserAccess; public Integer assignmentid; public boolean hasaccess(string auser) { boolean result = false; for (int i = 0; i < UserAccess.length; i++) { if (UserAccess[i].equals(aUser)) { result = true; }} return result;}} Déclaration de la classe «Subscriber» Après la création de la classe «Configuration», il ne reste qu à ajouter des modifications au niveau du corps de programme pour assurer l autorisation d utiliser le service par l utilisateur mobile qui va demander la localisation d un autre mobile selon sa numéro écrite sur le contenu du message SMS. protected void smsreceived(string asender, String areceiver, String amessagecontent) { For (int i=0; i<useraccess.length;i++) String user(i)=configuration.instance.getproperty("subscriber.authorized.i"); if((configuration.instance.getsubscriber().hasaccess(asender))&&( asender.equals(user(0)))) { usersender=user(0); if (amessagecontent.equals(user(1))) {usernum =user(1) ;itslocationprocessor.requestlocation(user(1));} else if.. if (Configuration.INSTANCE.getSubscriber().hasAccess(usernum)){ itsmmsprocessor.sendmms(configuration.instance.getproperty("servi cenumber"), user, messagecontent.getbinarycontent(), "Localisation de "+usernum); } else {itssmsprocessor.sendsms(configuration.instance.getproperty("serv icenumber. phone.0"), user, "Sorry, you don't have the right to recover this location"); } } Conclusion Déclaration de la méthode «smsreceived» Maintenant que nous avons défini l environnement de travail choisi et les différentes étapes de développement de notre application ainsi que les services qu on peut les créer, nous pouvons passer à la réalisation et l implémentation des différents mécanismes et différents scénarios de développement. C est ce que nous allons présenter dans le chapitre suivant. Ingénieurs 2006 Trabelsi Walid 70

80 Chapitre 5 : Implémentation de l application Chapitre 5. Implémentation de l Application Introduction Maintenant que la conception est achevée, nous arrivons à la phase de l implémentation ainsi que le test et l évaluation de l application développée. Pour ce faire, nous avons développé une interface graphique sous JDevelopper de chaque étape de développement de l application pour pouvoir déduire les remarques et les conclusions qui permettront de perfectionner certains points, ensuite nous réalisons le test de chaque étape sous le simulateur NRG d Ericsson à fin d assurer la bonne progression de développement. Ainsi la première partie de ce chapitre présentera les étapes de l implémentation de l application. Nous passerons dans la deuxième partie à l évaluation des deux services qu on peut créer à partir de l application développée en les testant sous le simulateur ainsi que les recommandations et les perspectives qui peuvent être prises en compte pour une éventuelle amélioration des performances. I. Implémentation des différentes étapes de l application de messagerie 1. 1er étape : Envoie d un SMS 1.1. Interface développée sur JDevelopper (Java) A fin de tester l application d envoie d un SMS, l interface suivante a été développé avec JDevelopper. Elle contient trois champs de texte et quatre boutons. Ce qui concerne les champs de texte sont répartis comme suit : dans la première on trouve une description d utilisation de cette application, le champ suivant est une zone réservée pour entrer le message qu on désire envoyer et enfin un champ pour regarder la trace du résultat du simulateur. Ce qui concerne les boutons, on a deux boutons nécessaires pour le NRG Framework nommés «start» et «stop», dont le premier permet la connexion au NRG Framework du simulateur et pour obtenir le service désiré en signant un SLA. Et le deuxième permet de se déconnecter du NRG Framework et de disposer de toutes les ressources utilisées. Les deux boutons restants, nommés «sendsms» et «NewSMS», sont utilisés pour envoyer un message dans une première étape et d envoyer un nouveau message dans les étapes suivantes. Voir figure au dessous. Ingénieurs 2006 Trabelsi Walid 71

81 Chapitre 5 : Implémentation de l application Figure 5.1: Interface de l application d envoie d un SMS 1.2. Implémentation sur Ericsson NRG Simulator Pour tester l application développée en Java, il faut utiliser le simulateur d Ericsson et suivre les étapes suivantes : 1) on ajout un mobile dans le simulateur sous le numéro 8282 qui est choisi dans la configuration de l application et qui peut être modifié selon notre choix. 2) On click sur le bouton «start» de l interface développé pour assurer le connexion au NRG Framework et obtenir le service de User Interaction. La trace du simulateur sur l interface est celle de la figure : 3) On écrit le message désiré dans le champ réservé à l envoie d un SMS et puis on click sur le bouton «sendsms». La trace du simulateur va changer s est montré dans le figure et dans le simulateur on s aperçoit de l arrivée d un nouveau message. 4) Si on désire envoyer un autre message, on click sur le bouton «NewSMS» et on entre de nouveau un message et on click sur le bouton «sendsms». 5) Enfin pour terminer l application, on click sur le bouton «stop» pour se déconnecter du NRG Framework et se libérer de toutes les ressources utilisées. Ingénieurs 2006 Trabelsi Walid 72

82 Chapitre 5 : Implémentation de l application Figure 5.2: Résultat de l envoie d un SMS vue sur l interface Java Figure 5.3: Résultat de l envoie d un SMS vue sur Ericsson NRG Simulator Ingénieurs 2006 Trabelsi Walid 73

83 Chapitre 5 : Implémentation de l application 2. 2ème étape : Récupération de la localisation du mobile 2.1. Interface développée sur JDevelopper (Java) A fin de créer l application de la récupération de la localisation du mobile, l interface suivante a été développée avec JDevelopper. Elle contient deux champs de texte et trois boutons. Ce qui concerne les champs de texte sont répartis comme suit : un premier champ réservé pour la description d utilisation de cette application alors que le deuxième champ est une zone réservée pour regarder la trace du résultat du simulateur. Ce qui concerne les boutons, on a deux boutons nécessaires pour le NRG Framework nommés «start» et «stop», dont le premier permet la connexion au NRG Framework du simulateur et pour obtenir le service désiré en signant un SLA. Et le deuxième permet de se déconnecter du NRG Framework et de disposer de toutes les ressources utilisées. Le troisième bouton, nommé «Refresh», est utilisé pour récupérer la localisation de l utilisateur du mobile. Donc chaque fois que le mobile change de localisation dans la mappe du simulateur, en cliquant sur le bouton «Refresh» on peut récupérer la nouvelle localisation du mobile sur la mappe de l interface développé sur JBuilder. Voir la figure au dessous. Figure 5.4: Interface de l application de localisation de l utilisateur du mobile Ingénieurs 2006 Trabelsi Walid 74

84 Chapitre 5 : Implémentation de l application 2.2. Implémentation sur Ericsson NRG Simulator A fin de bien simuler le développement de l application de localisation du mobile, il faut la tester sur le simulateur NRG d Ericsson en suivant les étapes suivantes : 1) On ajout un mobile dans le simulateur sous le numéro qui est choisi dans la configuration de l application et qui peut être modifié selon notre choix. 2) On ajout la mappe sur le simulateur pour voir la localisation initiale du mobile dans le simulateur Figure 5.5: Ajout du mobile et sa localisation sur la mappe d Ericsson NRG Simulator 3) On click sur le bouton «start» de l interface développé pour assurer le connexion au NRG Framework et obtenir le service de User Interaction. On aura la trace du simulateur sur l interface. 4) Ensuite on click sur le bouton «Refresh» pour voir la localisation sur la mappe de la ville de Tunis qui se trouve sur l interface de l application développé. Ingénieurs 2006 Trabelsi Walid 75

85 Chapitre 5 : Implémentation de l application Figure 5.6: Résultat de l application de la localisation du mobile vue sur l interface Java 5) Si on change la position du mobile sur la mappe du simulateur, on appuie de nouveau sur le bouton «Refresh» et on récupère la nouvelle localisation du mobile sur la mappe de l interface. 6) Enfin pour terminer l application, on click sur le bouton «stop» pour se déconnecter du NRG Framework et se libérer de toutes les ressources utilisées. 3. 3ème étape : Application finale 3.1. Interface développée sur JDevelopper (Java) L interface développée pour l application finale du service de messagerie est représentée dans la figure au dessous. Elle contient deux champs de textes, un pour la description de l utilisation de cette application et l autre est concerné pour la trace du résultat de l application. Dans l interface on trouve aussi deux boutons nommés «start» et «stop». Le premier est utilisé pour démarrer l application en se connectant au Framework pour demander Ingénieurs 2006 Trabelsi Walid 76

86 Chapitre 5 : Implémentation de l application les deux services User Interaction et User Location. Le deuxième permet de se déconnecter du Framework en libérant toutes les ressources utilisées. Figure 5.7: Interface de l application finale du service de messagerie 3.2. Implémentation sur Ericsson NRG Simulator Pour s assurer du résultat du développement de l application avec succès, il faut la tester sur le Ericsson NRG Simulator en suivant les étapes suivantes : 1) On ajoute un mobile sur le simulateur sous n importe quel numéro composé de huit chiffres comme il est choisi dans la configuration, on ajoute aussi la mappe du simulateur pour voyer la localisation initiale du mobile. 2) On click, dans l interface développé en Java, sur le bouton «start» pour démarrer l application 3) sur l émulateur mobile, on envoie un SMS au service 2222 comme il est illustré dans la figure suivante : Ingénieurs 2006 Trabelsi Walid 77

87 Chapitre 5 : Implémentation de l application Figure 5.8: Envoie d un SMS à partir de l émulateur mobile au service ) En envoyant ce SMS, l application va retourner un MMS contenant la mappe de la ville de Tunis sur laquelle on trouve l endroit du mobile. Ingénieurs 2006 Trabelsi Walid 78

88 Chapitre 5 : Implémentation de l application Figure 5.9: Récupération du MMS sur Ericsson NRG Simulator II. Implémentation des services déduits de l application 1. Implémentation du 1 er service : Demande des plus proches magasins par rapport à l endroit du mobile Pour tester la création de ce premier service, on aura la même interface développée avec JDevelopper pour l application finale en introduisant les modifications nécessaires dans le corps des classes et les méthodes de programmation. Prenant par exemple l ajout de la méthode de connexion à la base de données qui contiennent les latitudes et les longitudes des différents magasins dans les différentes villes de la Tunisie ainsi que la méthode recherche des deux plus proches magasins par rapport à l endroit de l utilisateur de téléphone mobile. Ensuite on va assurer le fonctionnement de ce service sur Ericsson NRG Simulator en suivant les étapes suivantes : 1) Dans l interface développée avec JDevelopper, on click sur le bouton «start» pour se connecter au Framework et commencer l application. 2) On ajout un mobile en précisant son localisation sur la mappe du simulateur comme c est illustré dans la figure suivante : Ingénieurs 2006 Trabelsi Walid 79

89 Chapitre 5 : Implémentation de l application Figure 5.10: Initialisation des composants du premier service 3) On envoie le SMS au numéro de service 2222 et dans la zone texte du contenu du SMS on écrit le nom de la ville (Tunis, Sfax, Sousse,..) auquel se trouve le mobile, on ajoute en plus le symbole + suivi du nom du magasin (Banque, Agence,..) qu on souhaite récupérer (voir figure 5.10). Le service va retourner un MMS contenant la mappe de la ville demandée sur laquelle on a la localisation des deux plus proches magasins ainsi que celle de l utilisateur mobile. 4) Si on modifie l endroit du mobile dans le simulateur ou on modifie le nom du magasin ou le nom de la ville auquel l utilisateur mobile se trouve, et on demande de nouveau le service en lui envoyant un nouveau SMS, on aura un nouveau résultat dans le message MMS avec différentes localisations des deux nouvelles magasins les plus proches dans une mappe de la ville correspondante. La figure au dessous montre deux résultats différents pour ce service, une pour la quelle on demande de récupérer les deux agences les plus proches par rapport au endroit de l utilisateur mobile dans la ville de Tunis «Tunis+Agence» alors que le deuxième correspond à la demande des deux banques les plus proches dans la ville de Sfax «Sfax+Banque». Ingénieurs 2006 Trabelsi Walid 80

90 Chapitre 5 : Implémentation de l application Figure 5.11: Résultat du premier service testé sur le simulateur 2. Implémentation du 2 ème service : Récupération de la localisation d un autre mobile avec autorisation d accès L implémentation de ce service nécessite la modification de l application au niveau de la configuration d un fichier contenant par exemple les informations des utilisateurs ainsi que le numéro de service. A fin de tester ce service sur le NRG simulator, on réalise ces étapes suivantes : 1) Dans l interface développée avec JDevelopper, on click sur le bouton «start» pour se connecter au Framework et commencer l application. 2) On ajout deux téléphones mobiles sur le simulateur sous les numéros et 10456, on ouvre aussi la mappe pour visualiser la localisation des deux mobiles comme c est illustré dans la figure au dessous. Ingénieurs 2006 Trabelsi Walid 81

91 Chapitre 5 : Implémentation de l application Figure 5.12: Initialisation des composants du deuxième service 3) Ensuite on envoie un SMS au numéro de service 2222 et on insère dans le contenu de SMS le numéro de mobile qu on désire récupérer sa localisation. Dans l exemple qu on pris le numéro de téléphone mobile qu on veut trouer son endroit est demandé par l utilisateur de téléphone mobile Si ce numéro parait dans le fichier de configuration et qu il a la permission d être récupéré par le téléphone mobile 10123, et par suite on vérifie l autorisation d accès, le service va retourner un MMS contenant la mappe sur laquelle se trouve la localisation du téléphone mobile Ce résultat est illustré dans la figure au dessous : Ingénieurs 2006 Trabelsi Walid 82

92 Chapitre 5 : Implémentation de l application Figure 5.13: Résultat du deuxième service testé sur le simulateur 4 ) Maintenant si on veut assurer le bon fonctionnement de l autorisation d accès au service, on modifie le numéro de téléphone mobile par Dans le fichier de configuration le téléphone mobile n a pas le droit de récupérer l endroit de téléphone mobile Donc si le mobile demande au numéro de service 2222 la localisation du mobile le service va retourner un SMS contenant le message suivant Désolé, vous n avez pas le doit de récupérer la localisation de ce mobile. La modification des composants du deuxième service et le résultat de la modification sur le simulateur sont illustrés dans les deux figures au dessous. Ingénieurs 2006 Trabelsi Walid 83

93 Chapitre 5 : Implémentation de l application Figure 5.14: Modification des composants du deuxième service Figure 5.15: Résultat de la modification du deuxième service Ingénieurs 2006 Trabelsi Walid 84

94 Chapitre 5 : Implémentation de l application Conclusion Ce dernier chapitre a été consacré pour la réalisation et l implémentation des tests des différentes étapes de développement permettant de présenter une évaluation primaire de l application en attendant son exploitation réelle. Après l étude, la conception, le développement, et l implémentation des premiers constats, nous atteignons la fin de notre projet. Toutefois, d autres points à étudier peuvent apparaître lors d une installation réelle de l application. En effet, la solution doit s adapter avec l environnement dans lequel elle sera implémentée. Ingénieurs 2006 Trabelsi Walid 85

95 Conclusion Générale Conclusion Générale Les réseaux radio mobiles des générations futures offrent un environnement de développement ouvert grâce à la portabilité des applications et à leur ouverture avec les plateformes de fournisseurs de services et de contenu. L objectif principal de ce projet de fin d études était de développer un nouveau service de messagerie pour les réseaux de nouvelles générations. Dans ce but, nous avons commencé tout d abord par une étude générale des services du réseau de prochaine génération NGN en introduisant son architecture et ses principales caractéristiques. Puis, nous nous sommes intéressés à une étude plus détaillée de l architecture des services de la nouvelle génération en décrivant les spécifications ainsi que les interfaces des services ouverts. Ensuite, nous nous sommes intéressés à l étude des plateformes de développement des services 3G dans les réseaux radio mobiles en introduisant la nouvelle approche de création des services. Nous avons décrit l architecture et les caractéristiques des deux plateformes JAIN et OSA/Parlay. Ensuite, suite à une comparaison, nous avons justifié le choix adopté pour le développement de notre travail. Une fois le choix de la plateforme de développement déterminé, nous avons détaillé tous les outils nécessaires à la création de l application ainsi que les services supportés par la plateforme choisie en nous focalisant sur ceux utiles à la réalisation de l application. Interviennent ensuite les phases de conception et de développement de l application de messagerie. Toutes les étapes de réalisations sont décrites et permettent de montrer comment bénéficier de cette application pour la création de services à valeur ajoutée : Recherche des deux plus proches magasins par rapport à l endroit de l utilisateur de téléphone mobile, Suivi de la localisation d un autre mobile. Terminons enfin par une étude des résultats en implémentant des interfaces développées sur JDevelopper de toutes les étapes de la création de l application, ajoutant les différents tests réalisés sur le simulateur NRG d Ericsson qui viennent valider les services créés au cours du projet. A l issue de ce travail, nous voulons insister sur l importance des concepts de la nouvelle approche de la création des services dans les réseaux de prochaine génération. L apport de ces concepts est clair à travers les résultats obtenus au cours de ce projet de fin d études en créant des services sans avoir recours à un vrai réseau de télécommunication. Dans ce projet, nous nous sommes intéressés seulement à des zones géographiques réduites à la phase de récupération des localisations des utilisateurs des téléphones mobiles ainsi que la localisation des magasins. Ce travail reste donc ouvert à l extension en considérant des zones géographiques plus grandes et en affectant une mise à jour de l apparition de nouveaux magasins, cela nécessite une base de donnée très riche contenant toutes les informations sur les altitudes des différents régions de la Tunisie ainsi que les magasins introduites. Ingénieurs 2006 Trabelsi Walid 86

96 Bibliographie [1] Etude technique, économique et réglementaire de l évolution vers les réseaux de nouvelle génération (NGN, Next Generation Networks). Etude réalisée par le cabinet Arcome pour le compte de l'autorité de régulation des télécommunications. [2] Joseph C. Crimi : Next Generation Network (NGN) Services, A Telcordia Technologies [3] Zygmunt Lozinski Open Service Access (OSA), Application Programming Interface (API) Parlay/OSA - a New Way to Create Wireless Services Parlay Group [4] D.Tait, J. de Keijzer, and R. Goedman, "JAIN: A New Approach to Services in Communication Networks" IEEE Communications Magazine, January 2000 [5] JAIN initiative [6] [7] Open Service Access; API. Part 1 Overview: ETSI Standard ES , ETSI/The Parlay Group, [8] Ericsson NRG Simulator: Available from: < [9] Ericsson H-OSA Interface Specification Overview, 1/ /FAM [10] Ericsson H-OSA Interface Specification Framework 2/ /FAM [11] Ericsson H-OSA Interface Specification User Interaction, 11/ /FAM [12] Ericsson H-OSA Interface Specification Mobility Management, User Location, 15/ /FAM Ingénieurs 2006 Trabelsi Walid 87