FR2718313A1

FR2718313A1 - Procédé et système de gestion de données utilisées par un logiciel d'application dans un réseau de télécommunications hétérogène.

Info

Publication number: FR2718313A1
Application number: FR9503833A
Authority: FR
Inventors: Ronstrom Mikael
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 1994-04-01
Filing date: 1995-03-31
Publication date: 1995-10-06
Anticipated expiration: 2015-03-31
Also published as: CA2186347A1; KR970702647A; US5826019A; CA2186347C; GB9620405D0; FR2718313B1; DK105496A; GB2302239B; WO1995027359A3; WO1995027359A2; KR100346342B1; GB2302239A; JPH10502221A

Abstract

L'invention concerne la gestion des données dans des réseaux de télécommunications. Des parties des données sont enregistrées dans des gestionnaires de données (DM) à un ensemble d'emplacements d'enregistrement de données répartis dans le réseau (600), indépendamment des modules d'application (AM). Un module d'application est exécuté pour définir un paramètre des données exigées pour l'exécution d'un logiciel d'application. Le gestionnaire de données qui supporte le module d'application recherche les données exigées dans les gestionnaires de données et identifie celui dans lequel les données exigées sont enregistrées. Ces dernières sont ensuite transférées vers le module d'application pour être utilisées pendant la poursuite de l'exécution du logiciel d'application. Applications aux réseaux de télécommunications hétérogènes.

Description

Cette invention concerne un réseau de télécommunications, et elle concerne plus particulièrement la gestion de données dans un réseau de télécommunications hétérogène.

Au cours des dernières années, de nouveaux concepts de réalisation de réseaux de télécommunications ont été développés, au-delà des réseaux de télécommunications commutés publics (ou "PSTN" pour "public switched telecommunications networks") traditionnels, ces concepts comprenant, de façon non limitative, des réseaux numériques à intégration de services ("RNIS"), des réseaux cellulaires, des réseaux intelligents et des réseaux de communication d'entreprise, que l'on appelle collectivement des "réseaux de services n . La combinaison de ces réseaux de services forme un réseau de télécommunications hétérogène, tel que celui représenté sur la figure 1, dans lequel les réseaux individuels, qui sont les zones hachurées, comprennent un ensemble de commutateurs représentés à l'intérieur.

En se référant de façon plus détaillée à la figure 1, on note qu'un PSTN local 100 comprend deux commutateurs téléphoniques, c'est-à-dire un commutateur D4 101 desservant un commutateur de service téléphonique mobile ("MTX") 102, chacun d'eux desservant des abonnés locaux ("SUB"). Le PSTN local 101 est connecté par le commutateur D4 101, par l'intermédiaire de jonctions 103, à un PSTN de transit 104 comprenant trois commutateurs téléphoniques, à savoir un commutateur 105 et des commutateurs D6 et D8, respectivement 106, 107, pour connecter des abonnés à d'autres commutateurs locaux. Le PSTN de transit 104 est connecté par le commutateur D8 107, par l'intermédiaire de jonctions 108, à un PSTN international 109, comprenant un commutateur 110. A titre d'illustration, ces réseaux 100, 104 et 109 se trouvent dans un premier pays 111.

Le PSTN international 109 relie le premier pays 111, par des jonctions 112, à un autre PSTN international 113 dans un second pays 114. Le PSTN international 113 comprend un commutateur D8 115 connecté aux jonctions 112, et un commutateur OPX 116. Le commutateur OPX 116 est connecté par des jonctions 117 à un RNIS national 118, comprenant deux commutateurs 119 et 120, le premier étant connecté aux jonctions 117, chacun de ces commutateurs desservant un ensemble d'abonnés. Le commutateur D8 115 est également connecté par des jonctions 121 à un PSTN national 122 comprenant trois commutateurs desservant des abonnés, parmi lesquels un commutateur 123 et des commutateurs D4 et D8, respectivement 124, 125, le commutateur
D8 étant connecté aux jonctions 121. Le commutateur 123 qui est connecté au commutateur D8 125 dessert des abonnés et il est également connecté par l'intermédiaire de jonctions 126 à un réseau privé 127 comprenant deux autocommutateurs privés ("PABX") 128, 129. Le PABX 128 est directement connecté aux jonctions 126 et il dessert des abonnés, ainsi que le PABX 129. Le commutateur D4 124 qui est connecté au commutateur D8 125 dessert des abonnés et il est connecté par des jonctions 130 à un réseau cellulaire ou mobile 131, comprenant un commutateur téléphonique de service mobile ("MTX") 132 desservant un groupe d'abonnés.

Tous les commutateurs qui connectent différents réseaux de services communiquent les uns avec les autres au moyen de convertisseurs de protocoles de réseaux, c'est-à-dire des passerelles, qui facilitent les communications entre les abonnés respectifs et d'autres abonnés dans le réseau.

Tous les commutateurs sont des systèmes de commutation à commande par programme enregistré qui sont des machines de calcul rapides, comprenant des processeurs centraux redondants pour la fiabilité, et des processeurs périphériques pour accroître la vitesse et l'efficacité.

Un bon exemple d'un tel commutateur est donné par l'équi pement de commutation de télécommunications à commande par programme enregistré du type fabriqué par Telefonaktiebolaget L M Ericsson et appelé commutateur AXE, dont une version antérieure est décrite dans l'article de Mats
Eklund et al., intitulé "AXE 10 System Description", publié dans Ericsson Review, n" 2, 1976. Le commutateur
AXE comprend deux parties principales : un équipement de commutation (appelé "APT"), et un ordinateur pour commander l'équipement de commutation (appelé "APZ"). Un autre exemple d'un tel commutateur de télécommunications à commande par programme enregistré est décrit dans le brevet des E.U.A. n" 4 322 843, délivré à H.J. Beuscher et al. De tels commutateurs comprennent habituellement tout le matériel nécessaire pour offrir un certain nombre de services de télécommunications différents. Ils peuvent être utilisés à titre de commutateurs de PSTN locaux, de commutateurs de transit pour des jonctions à longue distance, de PABX et de MTX, le tout essentiellement par l'installation d'un logiciel spécifique de commande par programme enregistré, pour leur donner la configuration correspondant aux fonctions spéciales exigées. Par exemple, le MTX 113 comprend un centre de commutation de service mobile ("MSC") pour commander l'interconnexion de diverses unités de commande de site de base de radiocommunication ("BSC"), et pour permettre le transfert de cellule en cellule d'abonnés mobiles, dans le réseau de radiocommunication. Le MSC comprend le commutateur AXE et un sous-système de téléphonie mobile ("MTS") qui remplit la fonction d'interconnexion entre l'AXE et les BSC. L'AXE a ainsi la configuration lui permettant de fonctionner en centre de commutation de service mobile.

Le probleme que l'on rencontre pour la communication dans un tel réseau de télécommunications hétérogène est en réalité triple. Premièrement, un abonné est limité à l'utilisation d'un équipement terminal spécifique à un point d'accès de réseau particulier, c'est-à-dire qu'il n'y a pas de mobilité d'abonné. Secondement, un terminal utilisé par un abonné est limité à l'utilisation à un point d'accès dans un réseau, c'est-à-dire qu'il n'y a pas de mobilité de terminal. Troisièmement, un abonné est limité à l'utilisation de services exigeant un équipement de terminal spécifique à un point d'accès de réseau particulier.

Pour résoudre ces problèmes, il est nécessaire de développer un concept de réalisation de réseau commun, qui est mis en oeuvre dans une architecture de réseau commun décrivant la façon selon laquelle des données et des éléments logiques doivent être répartis. La présente invention procure un procédé pour gérer des données utilisées par un logiciel d'application ayant un ensemble de modules d'application pouvant être exécutés dans des systèmes de commutation répartis dans l'ensemble d'un réseau de télécommunications hétérogène. Le procédé comprend l'enregistrement des données à un ensemble d'emplacements d'enregistrement de données, à chacun desquels est associé un gestionnaire de données, ces emplacements étant répartis dans le réseau de télécommunications indépendamment du logiciel d'application. Un premier module d'application est ensuite exécuté pour définir un paramètre des données exigées pendant l'exécution du logiciel d'application. Il en résulte qu'il est demandé à un premier gestionnaire de données de rechercher les données qui satisfont le paramètre, dans les emplacements d'enregistrement de données, et d'extraire les données de ceux-ci. Les données extraites sont ensuite écrites dans le premier module d'application, à partir du premier gestionnaire de données, pour être utilisées pendant la poursuite de l'exécution du logiciel d'application.

Un but de l'invention est de procurer la mobilité personnelle dans un réseau de télécommunications hétérogène, selon laquelle un abonné a la possibilité d'émettre et de recevoir des appels basés seulement sur son identité, indépendamment du terminal et du point d'accès au réseau. L'abonné peut également recevoir des services à partir d'un ou de plusieurs fournisseurs de services. Un autre but encore de l'invention est de procurer la mobilité de terminal, selon laquelle le terminal peut accéder à un réseau de télécommunications hétérogène à un nombre quelconque de points d'accès, du fait que le terminal et le réseau sont capables de s'identifier mutuellement de façon automatique. Un autre but encore de l'invention est de procurer la mobilité de service, selon laquelle un abonné a la possibilité d'utiliser tous ses services à un point d'accès quelconque dans le réseau de télécommunications hétérogène.

D'autres caractéristiques et avantages de l'invention seront mieux compris à la lecture de la description qui va suivre de modes de réalisation, donnés à titre d'exemples non limitatifs. La suite de la description se réfère aux dessins annexés, dans lesquels
La figure 1 est une illustration schématique d'un réseau de télécommunications hétérogène comprenant différents types de réseaux de services, dans lequel on peut mettre en oeuvre la présente invention;
La figure 2 est une illustration schématique d'un autre réseau de télécommunications hétérogène comprenant différents types de commutateurs ayant des modules d'application supportés par des modules de ressource;
La figure 3 est un schéma synoptique montrant un commutateur AXE ayant un logiciel d'application supporté par des modules de ressource, conformément à l'invention;
La figure 4 est un schéma synoptique de modules d'application pour différents commutateurs, supportés par des modules de ressource communs, conformément à l'invention;
La figure 5 est une illustration schématique d'un gestionnaire de données de module de ressource ("gestionnaire de données de RM") qui est destiné à supporter un transfert d'application dans différents commutateurs de télécommunications, conformément à l'invention;
La figure 6 est une illustration schématique d'un réseau cellulaire qui est supporté par un ensemble de gestionnaires de données de RM du type représenté sur la figure 5;
La figure 7 est une illustration schématique d'un procédé de communication entre deux gestionnaires de données de RM du type représenté sur la figure 5; et
La figure 8 est une illustration schématique d'une architecture de réseau commune représentée par des commutateurs dans deux réseaux régionaux, ayant des modules d'application qui sont supportés par des gestionnaires de données de RM conformes à l'invention.

Comme décrit ci-dessus, le réseau de télécommunications de la figure 1 comprend un certain nombre de commutateurs différents que l'on peut considérer comme des noeuds dans le réseau hétérogène, chacun d'eux faisant partie d'un réseau de services différent. La structure du logiciel des applications qui sont exécutées dans le matériel de chaque commutateur commandé par programme enregistré serait, par exemple, une combinaison spécifique de modules d'application ("AM") individuels pour accomplir certaines tâches ou pour procurer uen fonctionnalité spéciale. Dans l'architecture de réseau commune, on utilise le module d'application pour répartir la logique.

Ainsi, lorsqu'une tâche particulière doit être accomplie ou lorsqu'une fonctionnalité spéciale est exigée, le module d'application approprié est adressé et exécuté.

En se référant à la figure 2, on voit une illustration schématique d'un autre réseau de télécommunications hétérogène 200, qui est plus petit. Le réseau 200 comprend trois types de commutateurs différents : des commutateurs A, B et C, 201-202, qui peuvent être par exemple respectivement un commutateur de RNIS, un commutateur de PSTN et un commutateur de MTX, similaires aux commutateurs dans les réseaux de services de la figure 1, par exemple le RNIS 118, le PSTN 122 et le réseau mobile 131. La structure du logiciel pour chaque commutateur a une fonction spécifique et comporte un logiciel d'application comprenant une collection différente de modules d'application. Par exemple, les commutateurs 201-203 comprennent les modules d'application suivants, de façon non limitative
Commutateur A (RNIS) 201 AM-1 et AM-2
Commutateur B (PSTN) 202 AM-1, AM-3 et AM-4
Commutateur C (MTX) 203 AM-1 et AM-4
Dans cet exemple, le module d'application AM-1 est le seul qui soit commun à plus d'un commutateur. Les modules d'application dans chaque commutateur communiquent les uns avec les autres par l'intermédiaire de protocoles AM/AM internes 204, et ils communiquent dans le réseau par l'intermédiaire de protocoles AM/AM externes 205, comme décrit de façon plus détaillée dans la demande de brevet des E.U.A. N" 07/723166, déposée le 28 juin 1991 au nom des inventeurs Sune Ramström et al. (on l'appellera ciaprès la "demande de Ramström"), et cédée à Telefonaktiebolaget L M Ericsson.

Chaque module d'application est supporté par des outils, ou modules de ressource ("RM"), que le module d'application sélectionne et utilise de façon spécifique pour contribuer à l'accomplissement de tâches ou pour fournir une fonctionnalité spéciale. Les modules de ressource fournissent une plate-forme pour supporter la conception de chaque module d'application. Par exemple, le module d'application AM-3 est supporté par une plate-forme comprenant des modules de ressource RM-2 et RM-3, et le module d'application AM-4 est supporté par une plate-forme comprenant des modules de ressource RM-3 et RM-4. Les modules d'application communiquent avec les modules de ressource, et les modules de ressource communiquent les uns avec les autres, au moyen de protocoles définis, portant respectivement les références 206 et 207. Le protocole AM-RM 206 pour la communication entre le module d'application et le module de ressource est structuré sous la forme d'une interface de système, c'est-à-dire que les deux éléments de la communication sont contenus dans le même environnement ou dans un système de commande commun.

Les protocoles AM/AM 204 assurent la communication entre pairs, tandis que les protocoles AM/RM 206 sont orientés "client vers serveur". L'interface d'utilisateur pour un module de ressource peut consister en signaux PLEX ou en autres messages de logiciel, et l'interface est décrite dans une spécification d'interface. Un module de ressource a une interface identique avec tous les modules d'application et de ressource, ce qui empêche un module de ressource d'émettre des signaux spécifiques quelconques. Pour assister un module d'application dans l'accomplissement d'une tâche, un module de ressource peut appeler les services d'autres modules de ressource et il peut communiquer conformément à des protocoles RM/RM 207 définis.

Cette architecture est également décrite de façon plus complète dans la demande de brevet de Ramström.

Chaque module de ressource a une fonction définie et limitée qui permet à une grande variété de modules d'application d'utiliser le même module de ressource. Par exemple, le module de ressource RM-2 est un
Gestionnaire de Transactions qui offre un service similaire à celui qui est offert par la partie de transfert de message ("MTP") du système de signalisation C7 externe, mais en conformité avec le protocole AM/AM interne 204 qui est spécifié entre les modules d'application AM-1 et AM-2.

Le Gestionnaire de Transactions RM-2 garantit le transfert sûr de messages, sans tenter de comprendre leur signification. Le module de ressource RM-1 est un Gestionnaire de
Numéros d'Abonnés ("SNB") qui est destiné à coordonner l'attribution de numéros d'identification d'abonnés. Si le module d'application AM-1 dans le commutateur de PSTN 202 reçoit un ordre lui demandant de définir un numéro d'abonné particulier, il émettra une demande vers le
Gestionnaire de SNB RM-1 qui contrôlera le module d'application AM-1 dans le commutateur de RNIS 201, pour déterminer si le numéro est disponible. Dans l'affirmative, le
Gestionnaire de SNB RM-1 attribuera le numéro à l'abonné et il informera du résultat le module d'application AM-1 dans le commutateur de PSTN 202. Le module de ressource
RM-4 est un Gestionnaire de Signalisation qui supporte l'émission/réception de messages, par exemple de messages
CCITT n" 7, qui sont échangés avec d'autres commutateurs.

Ainsi, le module d'application AM-4 dans le commutateur de
PSTN 202 et le commutateur de MTX 203 sont supportés par le même Gestionnaire de Signalisation RM-4 pour communiquer avec d'autres commutateurs. Le module de ressource RM-5 est un Gestionnaire de Processus qui est destiné à enregistrer le nombre de modules d'application qui interviennent dans le traitement d'un seul appel à l'intérieur d'un commutateur. Le Gestionnaire de Processus
RM-5 attribue un numéro de référence spécifique à un appel qui est traité dans le commutateur de PSTN 202, et il enregistre les modules d'application qui participent au traitement. Le Gestionnaire de SNB RM-1, le Gestionnaire de Transactions RM-2, le Gestionnaire de Signalisation
RM-4 et le Gestionnaire de Processus RM-5 sont des exemples de modules de ressource qui procurent une fonction spécifique supportant une variété de modules d'application différents. D'autres modules de ressource seront décrits ci-dessous de façon plus détaillée.

On peut également décrire le commutateur AXE comme une combinaison de modules d'application supportés par une plate-forme de modules de ressource comme ceux que l'on vient de décrire. La figure 3 est un schéma synoptique montrant un commutateur AXE 301 ayant un logiciel d'application 302 supporté par des modules de ressource.

Le logiciel d'application ("APT") 302 contient une sélection de modules d'application, chacun d'eux mettant en oeuvre les fonctions logiques du commutateur AXE 301, comme par exemple le sous-système de service d'abonné ("SUS"), le sous-système de commande de trafic ("TCS"), et le sous-système de taxation ("CHS"). Les fonctions "physi que s" et orientées système du commutateur AXE 301 sont mises en oeuvre dans les modules de ressource RM-1, RM-2 et RM-3 305-307, que l'on désigne collectivement par "API" 303, au Niveau Système 2. Chaque module de ressource comprend un ou plusieurs sous-systèmes qui consistent à leur tour en blocs fonctionnels. Par exemple, le module de ressource RM-1 comprend un sous-système 308 qui consiste en blocs fonctionnels 309, 310, 311. Les modules de ressource peuvent également consister en blocs fonctionnels sans un sous-système. Par exemple, le module de ressource RM-3 comprend seulement deux blocs fonctionnels 312, 313 qui ne font pas partie d'un sous-système. Chaque module de ressource a une fonction définie et limitée, ce qui permet à une grande variété de modules d'application d'utiliser un module de ressource, dans le cadre d'une plate-forme pour chacun d'eux.

Ainsi, un réseau de télécommunications hétérogène pourrait comprendre un ensemble de commutateurs AXE séparés, ou n'importe quel autre type de commutateur commandé par programme enregistré, ayant une configuration prévue pour fournir différents services de réseau, par exemple RNIS, PSTN ou MTX, par l'utilisation de différents modules d'application, chacun d'eux étant supporté par une plate-forme de modules de ressource identifiée de façon spécifique. Un mode de réalisation d'un tel réseau est représenté en 400 sur la figure 4 et est décrit de façon plus spécifique dans la demande de Ramström. Le réseau 400 comprend des modules d'application de RNIS 401, des modules d'application de PSTN 402 et des modules d'application de MTX 403, tous supportés par un groupe de modules de ressource organisés en un réseau, qui sont désignés de façon générale par la référence 404. Par exemple, le module de ressource de Gestionnaire de Connexions 405 et le module de ressource de Gestionnaire de Transactions 406 font partie du réseau de modules de ressource et procurent les fonctions essentielles de communication et de connexion entre les modules d'application 401-403 et avec ceuxci. L'entrée de ligne d'abonné 411 et l'entrée de jonction 412 sont associées à chacun des modules comprenant le module de ressource de Gestionnaire de Connexions 405 et le Gestionnaire de Transactions 406. De plus, on voit un module de ressource de Gestionnaire de Taxation 407 qui remplit des fonctions de taxation qui sont communes à deux, ou plus, des modules d'application 401-403. Un module de ressource de Gestionnaire d'E/S 410 procure des fonctions d'entrée/sortie, tandis qu'un module de ressource de Gestionnaire de Statistiques 417 procure des fonctions d'enregistrement de trafic et d'autres fonctions de mesure et de gestion d'ordre statistique. Un module de ressource de Gestionnaire de Code de Fonction de Module d'Application 418 accomplit la gestion de code de fonction, tandis qu'un module de ressource de Gestionnaire "Forlopp" 419 procure des fonctions de redémarrage "Forlopp" (redémarrage de la commutation numérique aux endroits où des erreurs sont apparues et empêchent le processus du commutateur de se poursuivre) qui sont nécessaires dans l'un quelconque des modules d'application, ou éventuellement dans le système considéré globalement. Un module de ressource de Gestionnaire d'Opérations et de Maintenance 421 procure les fonctions habituelles d'opérations et de maintenance. Un module de ressource de Gestionnaire de Données d'Abonnés 422 gère des données associées à des abonnés individuels qui sont communes à deux ou plus des modules d'application 401-403, comprenant un Gestionnaire de Numéros d'Abonnés 425 et un module de ressource de Gestionnaire de Services d'Abonnés 426. Un module de ressource de Gestionnaire d'Evénements Liés au Temps 423 procure des services associés au contrôle de certaines fonctions orientées vers le temps dans le système, tandis qu'un module de ressource de
Gestionnaire d'Itinéraires 424 procure des fonctions de gestion d'itinéraires dans le réseau. Le module de ressource 427 représente de nombreuses autres fonctions, comme l'émission/réception de messages par l'emploi de types particuliers de signalisation, la gestion de la charge et la gestion de l'information de sortie, qui pourraient être incorporées dans des modules de ressource en fonction des besoins, pour offrir les fonctions de services à deux modules d'application, ou plus.

Pour introduire la mobilité personnelle , de terminal et de service dans un réseau de télécommunications hétérogène, il est nécessaire de développer un concept de réalisation de réseau commun qui est mis en oeuvre dans une architecture de réseau commun qui assure la distribution de fonctions logiques et de données, comme décrit ci-dessus. Alors que des modules d'application sont utilisés dans le réseau pour distribuer la logique, les modules de ressource sont utilisés pour distribuer les données. Les données à distribuer comprennent tout ce qui est nécessaire pour assurer l'ensemble des trois mobilités, comprenant, de façon non limitative, des données liées à l'utilisateur et au terminal. Ainsi, l'utilisateur a un numéro de téléphone personnel associé à des services individuels et des caractéristiques spéciales, qui sont reconnus indépendamment de l'endroit auquel il accède au réseau hétérogène. Il en résulte que le réseau reconnaît immédiatement l'utilisateur lorsque ce dernier compose le numéro ou le code spécifique. Une telle configuration facilite la réorientation d'un ensemble complet de services d'abonnés, sur la base d'une instruction d'utilisateur qui est émise à un nouvel emplacement, et elle permet, entre autres, la mise en oeuvre de numéros de téléphone personnels ("PNR") pour des abonnés, indépendamment de l'emplacement physique de l'abonné. Une jn,rorOnte~caracte'ris- t-ivue de l'invention consiste en ce que les données qui sont distribuées aux modules de ressource doivent être indépendantes des modules d'application, dans la mesure où des programmeurs chargés du développement de modules d'application peuvent les écrire et les réviser en ne sachant rien de la structure de données particulière. La base de données répartie est en réalité cachée au programmeur de développement d'application qui travaille sur le commutateur.

Les exigences clés pour créer une architecture commune pour atteindre la mobilité comprennent, de façon non limitative, les actions suivantes. Premièrement, on introduit dans le réseau la livraison d'appel commune, des configurations de travail en coopération, et des appels de service. On appelle "livraison d'appel" la partie de l'établissement d'appel pendant laquelle le port d'accès au réseau de l'abonné demandé est identifié. Initialement, le demandeur connaît l'identité du demandé, mais l'adresse est inconnue. Un exemple de livraison d'appel consiste dans l'interrogation d'une fonction d'emplacement d'origine dans un réseau cellulaire comprenant une fonction de commande de service pour obtenir l'adresse courante de l'utilisateur appelé. Du fait que le mécanisme de livraison d'appel doit supporterdifférents réseaux de services, par exemple des réseaux PSTN, NRIS et cellulaire, des configurations de travail en coopération entre des fournisseurs de différents réseaux de services, et des noeuds dans le même réseau, sont également exigées. On réalise de telles configurations en distribuant des données de service dans le réseau en fonction des besoins.

Des appels de service commun, c'est-à-dire des communications entre un abonné et un réseau de services, sont également distribués dans le réseau. Secondement, il est nécessaire d'introduire les moyens ou la base de données exigés pour adresser des appels à des utilisateurs qui peuvent utiliser plusieurs terminaux connectés par fil ou sans fil, et auxquels il est nécessaire d'accéder par différents réseaux de services. De tels moyens ou bases de données doivent traiter l'identité des utilisateurs indépendamment des différentes identités d'abonnement, des différentes identités de terminal et des différentes adresses de port d'accès des utilisateurs. Troisièmement, il est nécessaire d'introduire une configuration TMOS de type standard pour améliorer le support pour la gestion de services et de réseaux, et pour respecter les normes OSI, c'est-à-dire interconnexion de systèmes ouverts, pour assurer la compatibilité avec d'autres systèmes de gestion. Quatrièmement, il est nécessaire d'intégrer dans le réseau l'accès par fil et l'accès sans fil, en incorporant un noeud de commutation capable de prendre en charge les deux. Un plus haut degré d'indépendance entre les parties de point d'accès et de réseau de services du système est nécessaire, pour pouvoir assurer plus simplement la conformité avec de futures normes de réseaux en ce qui concerne l'accès.

Cette transparence de la distribution entraîne de nombreux avantages. Premièrement, des concepteurs d'applications peuvent enregistrer n'importe quelles données exigées, sans se préoccuper de la manière selon laquelle on accédera ultérieurement aux données. Secondement, la transparence facilite la réalisation de nouveaux modules de ressource de base de données, et le changement des protocoles de signalisation entre eux. Troisièmement, le module de ressource de Gestionnaire de Statistiques (417, figure 4) peut être utilisé pour déplacer des données de façon dynamique dans le réseau, dans le but d'améliorer les performances du réseau de services en permettant le développement d'une base de données commune pour toutes les plates-formes de système. Quatrièmement, la transparence de la distribution facilite le chargement rapide de noeuds du réseau, en quelques minutes, au lieu de plusieurs heures ou plusieurs jours. Cinquièmement, la transparence de la distribution permet d'obtenir des réseaux ayant une fiabilité encore plus élevée. Enfin, sixièmement, la transparence de la distribution permet de connecter des services d'abonnés éloignés ("RSS") à plus d'un commutateur, augmentant ainsi la fiabilité.

Pour parvenir à ces mobilités et pour bénéficier des avantages présentés au paragraphe précédent, les modules de ressource dans le réseau contiennent une fonction de système d'exploitation pour la distribution des données. Ceci est accompli par un gestionnaire de données ("DM") de module de ressource, qui est représenté de façon générale en 500 sur la figure 5. Le gestionnaire de données de module de ressource 500 comprend un gestionnaire de transactions 501, un gestionnaire de reprise 502, un gestionnaire de communication 503, un gestionnaire de répertoire 504, et un gestionnaire de base de données locale 505, qui communiquent tous avec un programmateur réparti 506. Le gestionnaire de données de module de ressource 500 communique avec un module d'application (non représenté) par l'intermédiaire du programmateur réparti 506, comme indiqué par la flèche bidirectionnelle 507, conformément au protocole AM/RM approprié. Ce gestionnaire de données de module de ressource 500 pourrait être, par exemple, le module de ressource 427 représenté sur la figure 4, qui supporte les modules d'application 401-403.

Lorsqu'un module d'application déclenche des demandes de lecture et d'actualisation de base de données, par l'intermédiaire du programmateur réparti 506, la demande est tout d'abord émise vers la base de données locale. Si les données auxquelles on s'intéresse ne sont pas enregistrées dans la base de données locale, le programmateur réparti 506 traite la demande d'une manière ensemble de gestionnaires de données de module de ressource, similaires au gestionnaire de données de module de ressource 500 décrit ci-dessus. Une partie du réseau cellulaire est représentée en 600 et elle comprend un centre de commutation de service mobile ("MSC") 601, un registre d'emplacement initial ("HLR") 602 et un point de commande de service ("SCP") 603. Dans cette illustration, le concepteur d'application a distribué la logique en incorporant des modules d'application 604, 605, 606 respectivement dans le MSC 601, le HLR 602 et le SCP 603.

Le concepteur installe la fonctionnalité à l'endroit où elle est le plus nécessaire dans le réseau. Les modules d'application 605 pour le HLR 602 comprennent un logiciel d'application qui procure une fonction de réseau pour conserver les données, la logique, l'activité et l'emplacement des abonnés, c'est-à-dire la fonction d'emplacement initial ("HLF") qui est représentée dans ce module. Le module d'application 606 pour le SCP 603 contient un logiciel d'application qui procure une fonction de réseau qui maintient dans l'état de service certaines données et une certaine logique pour des abonnés. Les modules d'application 604-606 communiquent de la manière habituelle par signalisation C7, comme indiqué.

Le réseau cellulaire 600 comprend en outre des
Gestionnaires de Données de Module de Ressource 607, 608, 609 qui sont nécessaires pour communiquer respectivement avec les modules d'application 604, 605 et 606, par l'intermédiaire des protocoles AM/RM représentés sous la forme de flèches bidirectionnelles entre eux. Les gestionnaires de données sont communs à tous les modules d'applications, et ils sont connectés dans un réseau de transmission de données par l'intermédiaire de liaisons rapides ("HSL"), comme indiqué au moyen de gestionnaires de communication similaires au gestionnaire de communication 503 qui est représenté sur la figure 5. Les Gestionnaires de
Données de Module de Ressource doivent être connectés par des liaisons rapides pour maintenir les performances de la base de données répartie. Le comportement d'une telle base de données répartie est très similaire à celui d'une base de données centralisée avec calcul réparti. Une base de données répartie est accessible à partir de tous les emplacements ou les noeuds dans le réseau qui comprennent un Gestionnaire de Données de Module de Ressource. Par conséquent, si un concepteur incorpore une logique dans le
MSC 601, le Gestionnaire de Données de Module de Ressource 607 accomplira une lecture de données et une actualisation de données, même s'il s'agit d'une opération à distance.

Du fait que le Gestionnaire de Données de Module de
Ressource 607 utilise une interface à liaison rapide, le retard sera court même dans des situations de trafic élevé. Si les fonctions sont incorporées dans le registre d'emplacement initial HLR 602, l'accès à la base de données s'effectue par l'intermédiaire du protocole AM/AM, pour commander la fonction à partir du MSC 601. Ensuite, le HLR 602 utilise son propre Gestionnaire de Données de
Module de Ressource 608 pour accomplir des tâches spécifiques. De façon correspondante, si un concepteur incorpore une logique dans la fonction de commande de service SCF 606, l'accès à la base de données s'effectue par l'intermédiaire du protocole AM/AM, pour commander la fonction à partir du MSC 601. Du fait que les modules d'application peuvent tous être situés dans un seul noeud physique, la configuration du réseau est définie de façon dynamique pour s'adapter à la situation de trafic spécifique.

Un système d'application de gestion cellulaire ("CMAS") 610 utilise son propre Gestionnaire de Données de
Module de Ressource 611 pour actualiser des données et pour créer de façon dynamique de nouvelles copies de données pour différents noeuds dans l'ensemble du réseau, pour obtenir de meilleures performances. Le CMAS 610 utilise une régulation adaptative, c'est-à-dire l'aptitude à changer de façon dynamique sous l'effet de l'apparition de différentes conditions, pour améliorer les performances du réseau. Une passerelle fonctionnelle est réalisée par l'intermédiaire d'un module d'application 612 qui a besoin de déterminer, d'un point de vue logique, si les données considérées appartiennent au réseau local ou à un autre réseau de services. Le module d'application 612 est supporté par un Gestionnaire de Données de Module de
Ressource 613 connectant le réseau local au reste du réseau de transmission de données, par l'intermédiaire d'une autre liaison rapide HSL 614. Si les données n'appartiennent pas au réseau local, le module d'application de passerelle fonctionnelle 612 émettra une demande vers le réseau dans lequel les données sont enregistrées, au moyen du Gestionnaire de Données de Module de Ressource 613. Le module d'application de passerelle fonctionnelle 612 communique avec d'autres bases de données au moyen des protocoles normalisés.

Dans l'architecture de réseau commune, les données sont classées en données internes pour le module d'application ("données de module d'application") ou en données globales. Les données de module d'application internes sont soit des données traitées, par exemple des données spécifiques pour un appel, soit des données objets, c'est-à-dire des données semi-permanentes. Les données objets de module d'application internes peuvent être prises en charge, par exemple, par le sous-système de base de données ("DBS") du commutateur AXE, et elles ne sont pas lisibles à partir de l'extérieur du module d'application. Les données globales sont ce qui est accessible par un module d'application dans un noeud quelconque. Comme indiqué ci-dessus, les données globales doivent être maintenues indépendantes des données de module d'application, qui sont associées aux modules d'applica tion. Les données d'abonnés dans un MTX sont un exemple de données globales.

En se référant de façon plus spécifique à la figure 7, on note que des modules d'application AM-1 et
AM-2 dans deux réseaux de services respectifs 701 et 702, sont supportés chacun par un Gestionnaire de Données de
Module de Ressource, respectivement 703 et 704, similaire au Gestionnaire de Données de Module de Ressource 500 représenté sur la figure 5. Ces Gestionnaires de Données de Module de Ressource 703, 704 manipulent des données globales entre des réseaux de services, d'une manière similaire au gestionnaire d'itinéraires et au gestionnaire
SNB dans un réseau AXE. Le Gestionnaire de Données de
Module de Ressource 703 lit, écrit, insère et supprime des données qui sont globales et accessibles par un module d'application dans un noeud quelconque. Par exemple, le
Gestionnaire de Données de Module de Ressource 703 enregistre des données d'abonnés comprenant globalement, sans limitation, la libre numérotation dans les réseaux RNIS ou
PSTN. Plus précisément, lorsque le module d'application
AM-1 demande au Gestionnaire de Données de Module de
Ressource 703 de telles données d'abonnés globales, comme représenté à l'étape (1), le Gestionnaire de Données de
Module de Ressource 703 effectue tout d'abord une recherche dans sa propre base de données locale. Si les données d'abonnés globales ne sont pas trouvées de façon interne, le Gestionnaire de Données de Module de Ressource 703 effectue une recherche dans d'autres Gestionnaires de
Données de Module de Ressource dans l'ensemble du réseau de télécommunications, comprenant le Gestionnaire de
Données de Module de Ressource 704 qui supporte le module d'application AM-2, comme représenté à l'étape (2).

Lorsque les données d'abonnés globales sont trouvées, par exemple dans le Gestionnaire de Données de Module de
Ressource 704, les données sont émises vers le Gestion naire de Données de Module de Ressource 703 qui transmet les données au module d'application AM-1.

En se référant à la figure 8, on voit un exemple d'une architecture de réseau commune pour un réseau de bases de données réparties conformément à la présente invention. Deux réseaux régionaux, à savoir le réseau
Région SW 801 et le réseau Région US 802, sont représentés à titre d'exemple de parties d'un réseau global qui sont liées par des commutateurs, par l'intermédiaire de passerelles. Dans cet exemple, les PSTN internationaux 803 et 804 comprennent des modules d'application et des Gestionnaires de Données de Module de Ressource comme décrit cidessus, et ils sont supportés par des passerelles correspondantes 805 et 806, comprenant également des modules d'application et des Gestionnaires de Données de Module de
Ressource. Les modules d'application des PSTN internationaux 803, 804 sont connectés par des jonctions 807, et tous les Gestionnaires de Données de Module de Ressource communiquent par l'intermédiaire de liaisons rapides HSL 808.

Un réseau interne de Gestionnaire de Données de
Module de Ressource est lié par des passerelles internes à d'autres réseaux internes, et il est également lié directement à un PSTN international, comme représenté sur la figure 8, dans laquelle un réseau interne ST 809 est lié au PSTN international 805 et un réseau interne TX 810 est lié au PSTN international 806. Chaque réseau interne 809, 810 comprend un ensemble de commutateurs dans différents réseaux de services, comme décrit ci-dessus et représenté respectivement par les références 811 et 812, tous deux étant supportés par des passerelles internes correspondantes, respectivement 813 et 814. Les réseaux internes 811, 812 et leurs passerelles internes correspondantes 813, 814 comprennent tous des modules d'application et des
Gestionnaires de Données de Module de Ressource, comme représenté. Les modules d'application des réseaux internes 811, 812 sont connectés par l'intermédiaire de jonctions respectives 815 et 816 aux modules d'application des PSTN internationaux correspondants, respectivement 803 et 804.

Les Gestionnaires de Données de Module de Ressource qui supportent le réseau international 811 et la passerelle interne 813 sont connectés par l'intermédiaire de liaisons rapides HSL 817 au Gestionnaire de Données de Module de
Ressource supportant la passerelle internationale 805. Les
Gestionnaires de Données de Module de Ressource supportant le réseau interne 812 et la passerelle interne 814 sont connectés par l'intermédiaire de liaisons rapides HSL 818 au Gestionnaire de Données de Module de Ressource qui supporte la passerelle internationale 806. Les liaisons de données rapides HSL 808, 817, 818 forment le réseau global de bases de données procurant l'ensemble des trois mobilités conformément à la présente invention. Il faut noter que cet exemple montrant un réseau de bases de données entre des régions, peut être étendu à travers une hiérarchie de sous-régions communiquant par des sous-passerelles, avant la connexion à un réseau de services local, comme le PSTN local 100, le réseau privé 126 et le réseau mobile 131 représentés sur la figure 1.

Il faut également noter dans la description cidessus que toutes les données classées comme des données globales sont enregistrées dans les Gestionnaires de Données de Module de Ressource constituant ce réseau de bases de données réparties. Un modèle décrivant précisément l'endroit auquel les données globales doivent être enregistrées dans ce réseau de bases de données réparties, est appliqué à un modèle d'architecture. Il est nécessaire que le modèle permette la mise en oeuvre d'algorithmes efficaces pour lire et actualiser des données globales, mais permette également au réseau de bases de données de croître rapidement en taille, en complexité et en fonctionnalité, dans des tolérances de coût raisonnables.

Un tel module connu de l'homme de l'art est constitué par la base de données répartie partiellement informée ("PIDDB"), qui peut être utilisée dans les Gestionnaires de Données de Module de Ressource sans affecter les modules d'application. Le modèle de PIDDB est décrit de façon plus détaillée dans un document intitulé "Partially
Informed Distributed Databases : Conceptual Framework and
Knowledge Model", Technical Report Number 80, par Mark
Blakely, daté de décembre 1986.

Comme on peut le voir d'après la description précédente de la base de données répartie de la présente invention, le système présent propose de nombreux avantages et caractéristiques permettant la mobilité dans un réseau de télécommunications hétérogène. On considère donc que le fonctionnement et la structure de la présente invention ressortiront de la description qui précède. Bien que l'on ait indiqué que le procédé, l'appareil et le système représentés et décrits étaient préférés, il est évident que divers changements et modifications peuvent leur être apportés, sans sortir de l'esprit et du cadre de l'invention, définis dans les revendications annexées.

Claims

REVENDICATIONS

1. Procédé pour la gestion de données utilisées par un logiciel d'application ayant un ensemble de modules d'application pouvant être exécutés dans des systèmes de commutation répartis à travers l'ensemble d'un réseau de télécommunications hétérogène, caractérisé en ce qu'il comprend les étapes suivantes : on enregistre des parties des données dans des gestionnaires de données (DM, 500) à un ensemble d'emplacements d'enregistrement de données répartis dans le réseau de télécommunications, indépendamment des modules d'application (AM, AM-1, AM-2 ..., 401403), chacun d'eux étant supporté par un gestionnaire de données (DM, 500); on exécute un module d'application (AM,

AM-1, AM-2, ..., 401-403) pour définir les données exigées pendant l'exécution du logiciel d'application; on demande au gestionnaire de données (DM, 500) supportant le module d'application de rechercher les données exigées dans les gestionnaires de données se trouvant aux emplacements d'enregistrement de données; on recherche les données exigées dans les gestionnaires de données (DM, 500) pour identifier le gestionnaire de données dans lequel les données exigées sont enregistrées; et on extrait les données exigées du gestionnaire de données identifié et on écrit dans le module d'application (AM, AM-1, AM-2, 401-403) les données extraites du gestionnaire de données identifié, pour l'utilisation pendant la poursuite de l'exécution du logiciel d'application.

2. Procédé pour la gestion de données utilisées par un logiciel d'application ayant un ensemble de modules d'application pouvant être exécutés dans des systèmes de commutation répartis à travers l'ensemble d'un réseau de télécommunications hétérogène, caractérisé en ce qu'il comprend les étapes suivantes : on enregistre des parties des données dans des gestionnaires de données (DM, 500) à un ensemble d'emplacements d'enregistrement de données répartis dans le réseau de télécommunications, indépendamment des modules d'application (AM, AM-1, AM-2, ..., 401403), chacun d'eux étant supporté par un gestionnaire de données (DM, 500); on exécute un module d'application pour définir les données qui doivent être actualisées pendant l'exécution du logiciel d'application; on demande au gestionnaire de données (DM, 500) supportant le module d'application (AM, AM-1, AM-2, ..., 401-403) de rechercher les données exigées dans les gestionnaires de données aux emplacements d'enregistrement de données; on recherche les données exigées dans les gestionnaires de données (DM, 500) pour identifier le gestionnaire de données dans lequel les données exigées sont enregistrées; et on actualise les données exigées dans le gestionnaire de données (DM, 500) identifié et on enregistre les données actualisées dans le gestionnaire de données identifié, pour l'utilisation pendant la poursuite de l'exécution du logiciel d'application.

3. Procédé pour la gestion de données utilisées par un logiciel d'application ayant un ensemble de modules d'application pouvant être exécutés dans des systèmes de commutation répartis à travers l'ensemble d'un réseau de télécommunications hétérogène, caractérisé en ce qu'il comprend les étapes suivantes : on enregistre des parties des données dans des gestionnaires de données (DM, 500) à un ensemble d'emplacements d'enregistrement de données répartis dans le réseau de télécommunications, indépendamment des modules d'application (AM, AM-1, AM-2, ..., 401403), chacun d'eux étant supporté par un gestionnaire de données (DM, 500); on exécute un module d'application (AM,

AM-1, AM-2, ..., 401-403) pour définir les données qui doivent être enregistrées à titre de sauvegarde pendant l'exécution du logiciel d'application; on demande au gestionnaire de données (DM, 500) supportant le module d'application (AM, AM-1, AM- 2, ..., 401-403) de rechercher les données exigées dans les gestionnaires de données se trouvant aux emplacements d'enregistrement de données; on recherche les données exigées dans les gestionnaires de données (DM, 500) pour identifier le gestionnaire de données dans lequel les données exigées sont enregistrées; et on sauvegarde les données exigées dans le gestionnaire de données identifié, pour l'utilisation pendant la poursuite de l'exécution du logiciel d'application.

4. Procédé selon l'une quelconque des revendications 1, 2 ou 3, caractérisé en ce que l'étape de recherche comprend en outre les étapes qui consistent à effectuer tout d'abord la recherche dans le gestionnaire de données (DM, 500) de support, et ensuite dans les autres gestionnaires de données, pour identifier le gestionnaire de données dans lequel les données exigées sont enregistrées.

5. Système pour la gestion de données utilisées par un logiciel d'application ayant un ensemble de modules d'application pouvant être exécutés dans des systèmes de commutation répartis dans l'ensemble d'un réseau de télécommunications hétérogène, caractérisé en ce qu'il comprend : un ensemble de gestionnaires de données (DM, 500) enregistrant des parties des données à un ensemble d'emplacements d'enregistrement de données répartis dans le réseau de télécommunications, indépendamment des modules d'application (AM, AM-1, AM-2, ..., 401-403), chacun d'eux étant supporté par un gestionnaire de données; des moyens pour définir les données exigées pendant l'exécution du logiciel d'application et pour demander au gestionnaire de données (DM, 500) supportant le module d'application (AM, AM-1, AM-2, 401-403) de rechercher les données exigées dans les gestionnaires de données aux emplacements d'enregistrement de données; et des moyens qui fonctionnent sous la dépendance du gestionnaire de données de support de façon à rechercher les données exigées dans les gestionnaires de données (AM, AM-1, AM-2, ... 401-403), pour identifier le gestionnaire de données dans lequel les données exigées sont enregistrées, pour l'utilisation pendant la poursuite de l'exécution du logiciel d'application.

6. Système selon la revendication 5, caractérisé en ce que les moyens de recherche comprennent une liaison de données rapide (HSL).

7. Système selon la revendication 5, caractérisé en ce qu'il comprend en outre des moyens pour extraire les données exigées du gestionnaire de données (DM, 500) identifié et pour écrire dans le module d'application (AM,

AM-1, AM-2, ... 401-403) les données extraites du gestionnaires de données identifié, pour l'utilisation pendant la poursuite de l'exécution du logiciel d'application.

8. Système selon la revendication 7, caractérisé en ce que les moyens d'extraction comprennent une liaison de données rapide (HSL).

9. Système selon la revendication 5, caractérisé en ce qu'il comprendenatedes moyens pcl- actalter les données exigées dans le gestionnaire de données (DM, 500) identifié, et pour enregistrer les données actualisées dans le gestionnaire de données identifié, pour l'utilisation pendant la poursuite de l'exécution du logiciel d'application.

10. Système selon la revendication 5, caractérisé en ce qu'il comprend en outre des moyens pour sauvegarder les données exigées dans le gestionnaire de données (DM, 500) identifié, et pour enregistrer les données sauvegardées dans le gestionnaire de données identifié, pour l'utilisation pendant la poursuite de l'exécution du logiciel d'application.

11. Gestionnaire de données destiné à supporter des modules d'appplication dans un logiciel d'application pouvant être exécuté dans des systèmes de commutation se trouvant dans un réseau de télécommunications hétérogène, caractérisé en ce qu'il comprend : des moyens programmateurs (506) qui réagissent à une demande provenant du module d'application (AM, AM-1, AM-2, ... 401-403), concernant des données dans une base de données répartie indépendamment du logiciel d'application dans l'ensemble du réseau de télécommunications, pour commander des communications entre le module d'application et le gestionnaire de données, conformément à un protocole défini; des moyens de gestion de base de données (505) qui fonctionnent sous la dépendance des moyens programmateurs (506) de façon à enregistrer et à extraire des données d'une partie de la base de données située localement dans le réseau de télécommunications; des moyens de gestion de répertoire (504) qui fonctionnent sous la dépendance des moyens programmateurs (506) de façon à identifier d'autres gestionnaires de données enregistrant la partie restante de la base de données répartie, à d'autres emplacements dans le réseau de télécommunications; et des moyens de communication (503) qui fonctionnent sous la dépendance des moyens programmateurs (506) et des moyens de gestion de répertoire (504) de façon à rechercher les données dans les autres gestionnaires de données et à extraire les données de ces derniers, pour l'utilisation pendant l'exécution du logiciel d'application.

12. Système selon la revendication 10, caractérisé en ce que les moyens de communication comprennent une liaison de données rapide (HSL) pour rechercher les données dans les autres gestionnaires de données et pour extraire les données de ces derniers.

13. Système selon la revendication 10, caractérisé en ce que les moyens de communication (503) comprennent des moyens pour extraire les données des autres gestionnaires de données, et les moyens programmateurs (506) comprennent des moyens pour écrire dans le module d'application les données extraites provenant des moyens de communication, pour l'utilisation pendant la poursuite de l'exécution du logiciel d'application.

14. Système selon la revendication 10, caractérisé en outre en ce qu'il comprend des moyens de transaction (501) qui fonctionnent sous la dépendance des moyens programmateurs (506) de façon à actualiser les données dans les autres gestionnaires de données, par l'intermédiaire des moyens de communication (503), et à enregistrer les données actualisées dans un gestionnaire de données sélectionné quelconque parmi les gestionnaires de données.

15. Système selon la revendication 10, caractérisé en ce qu'il comprend en outre des moyens de reprise (502) qui fonctionnent sous la dépendance des moyens programmateurs (506) pour sauvegarder les données dans les autres gestionnaires de données et pour enregistrer les données sauvegardées dans un gestionnaire de données sélectionné quelconque parmi les gestionnaires de données.