Open Services Architecture

Pour les articles homonymes, voir OSA.

L' Open Services Architecture (OSA) peut se traduire en architecture de système ouvert, fait partie du réseau de télécommunications mobile de 3^e génération 3GPP ou de l'UMTS. OSA décrit comment les services sont architecturés dans un réseau UMTS. Les normes pour OSA sont éditées par ETSI et 3GPP. L'API pour OSA s'appelle Parlay, (ou Parlay/OSA ou OSA/Parlay) comme l'API sont développés conjointement en collaboration par 3GPP, ETSI, et le groupe Parlay. Ces API peuvent être librement téléchargées sur leur site Web en lien externe.

L'objectif de ces produits est de permettre l'utilisation d'une interface de programmation (API) ouverte et indépendante de la technologie dans les réseaux de télécommunication. OSA/Parlay donnera la possibilité aux opérateurs de réseaux, ainsi qu'aux prestataires de services et aux développeurs de logiciels indépendants de proposer des produits et services exploitant et combinant la fonctionnalité avancée des réseaux d'aujourd'hui et de demain.

OSA/Parlay et sa souplesse d'emploi permettent de déployer des services supplémentaires et des nouveaux services normalisés mais également des extensions et des services propres à chaque opérateur. Leurs mises en œuvre peuvent être centralisées via une passerelle, distribuées sur plusieurs plateformes ou bien une combinaison des deux. Par ailleurs, OSA/Parlay permet le niveau de sécurité nécessaire pour que le cœur de réseau puisse être ouvert aux fournisseurs d'applications externes à l'opérateur mobile.

Les composants

La passerelle

Le rôle de la Gateway (passerelle) OSA/Parlay est de créer une couche d’isolation entre le réseau et les environnements d’exécution de services et propose les fonctionnalités suivantes :

• Une mise en œuvre générique et transparente de services permettant l’interconnexion sur tous types de protocoles (réseau SS7, Wap, SMS, SIP…). Le protocole spécifique au réseau France Telecom : l’ « INAP FT » fait partie des protocoles que la Gateway sait interfacer.

• Une API standardisée (CORBA ou SOAP) permettant la remontée des événements réseau et la commande des éléments de réseau à partir de serveurs d’application internes à l’opérateur ou externes.

• Un framework (utilisant le protocole OSA) permettant la souscription de serveurs d’application à des instances de services selon des profils gérables par l’opérateur,

• Un routage vers les applications en fonction d’un code de service et des adresses (partielles ou complètes) des demandés et demandeurs

Application Server d’Appium

La Gateway forme donc une « couche d’isolation réseau » en offrant une interface standardisée aux environnements d’exécution des services. Le serveur d’application quant à lui, prend en charge l’exécution des services en leur offrant :

• des mécanismes de redondance,
• des mécanismes de sécurité d’accès (pour les web services),
• des mécanismes de contrôle et de répartition de charge
• des outils d’administration et d’exploitation.

L’architecture du serveur d’application permet une extension linéaire de ses capacités.

De nombreuses bibliothèques (en supplément de celles d’OSA/Parlay) sont disponibles pour interagir avec des éléments externes : LDAP, SMS, Web, WAP ou serveurs VXML.

SCF (Service Capability Feature)

Le dialogue entre la Gateway et le serveur d’application est réalisé au travers du protocole standardisé OSA/Parlay. OSA/Parlay se présente sous la forme de « services » ou SCF (Service Capability Feature) offert par la Gateway. Il existe un certain nombre de ces SCF, chacun ayant un rôle bien déterminé ; en voici une liste non exhaustive :

• Framework : il peut être considéré comme un « tiers » de confiance entre les applications et les autres services proposés par la Gateway. Dans un premier temps les SCF s’enregistrent auprès du Framework pour l’informer de leur présence. Lorsque qu’une application demande à pouvoir accéder à l’un de ces services, il doit tout d’abord s’authentifier auprès du Framework qui l’autorisera (après négociation) ou pas à accéder au service souhaité ou pas.

• Call Control : se décompose en plusieurs services :
• Generic Call Control (GCC) permet l’accès aux fonctionnalités de gestion basique d’appel telles que la redirection d’un appel, la notification d’évènements (occupation, non réponses, …). Une application peut aussi bien contrôler les appels faits par un abonné ou bien en lancer de nouveaux.
• Multi-Party Call Control (MPCC) est une extension de la GCC API. Elle permet de gérer des appels entre deux ou plusieurs abonnés. De nouvelles connexions vers d’autres abonnés peuvent être créées en cours d’appel.
• Multi-Media Call Control (MMCC)
• Conference Call Control (CCC)
• User Interaction (UI) permet d’avoir une interaction avec l’utilisateur au travers d’échanges de messages vocaux, SMS, MMS, …
• Mobility
• Terminal Capabilities donne accès aux capacités du terminal via le WAP.
• Data Session Control généralement utilisée pour contrôler l’établissement de sessions GPRS et gérer la facturation par rapport au volume de données échangées.
• Generic Messaging
• Account Management permet à l’application d’avoir accès aux données d’un compte utilisateur de manière sécurisée.
• Charging
• Presence and Availability Management
• User Location (UL) permet aux applications d’obtenir la localisation géographique des utilisateurs.
• User Status (US)

Voir aussi

• CAMEL
• IP Multimedia Subsystem

Liens externes

• Download APIs
• The joint 3GPP/ETSI/Parlay work group

• Portail des télécommunications