BE1021396B1 - Ameliorations apportees au controle de qualite vocale - Google Patents

Abstract

L'invention décrite ici concerne un système terminal multimode comprenant au moins un réseau internet (540, 545), un réseau mobile (560), une plateforme (505) et un terminal multimode (575). La plateforme (505) et le terminal (575) peuvent tous deux être connectés à 5 l'un des réseaux internet (540, 545) et au réseau mobile (560). Un module de contrôle de qualité vocale (525) est prévu pour déterminer si la qualité vocale d'appel d'un appel établi vers le terminal (575) ou en provenance de celui-ci par l'intermédiaire du réseau internet (540, 545) respecte un niveau de qualité vocale minimale prédéterminée. Le transfert entre le réseau internet (540, 545) et le réseau mobile (560) est déclenché lorsque la qualité vocale de l'appel s'abaisse en dessous du niveau de qualité vocale minimale prédéterminée.

Description

AMÉLIORATIONS APPORTÉES AU CONTRÔLE DE QUALITÉ

VOCALE

La présente invention concerne des améliorations apportées au contrôle de qualité vocale et plus précisément, bien que non exclusivement, elle concerne la qualité d'appels vocaux pour le transfert entre des modes dans des systèmes de télécommunications multimodes.

Les communications vocales ont récemment connu des progrès rapides dans deux domaines parallèles. Le premier domaine est celui de la téléphonie cellulaire, qui a permis d'augmenter la mobilité des utilisateurs de téléphonie. Un second domaine, plus récent, est celui des communications utilisant le Protocole de Voix sur Internet (VoIP), dans lequel les communications vocales sont acheminées sur des réseaux IP. Bien que la téléphonie cellulaire et les communications VoIP aient toutes deux conduit à des avantages indéniables, leur développement parallèle a également conduit à certains inconvénients pour un utilisateur souhaitant les exploiter simultanément.

Des terminaux bimodes pouvant être connectés indépendamment à la fois à un réseau téléphonique public commuté (PSTN, Public Switched Telephone Network) et à des réseaux à protocole internet (IP), ont été développés. En particulier, on a développé des terminaux bimodes de ce type comprenant à la fois un émetteur-récepteur de téléphonie mobile permettant de connecter sans fil le terminal bimode à un réseau PSTN cellulaire, comme par exemple un réseau GSM (Système Global de Télécommunications pour les Mobiles), ou un système de télécommunications mobiles universel (UMTS), et un émetteur-récepteur de réseau local (LAN, Local Area Network) sans fil pour les connexions à un réseau IP par l'intermédiaire d'un réseau LAN sans fil. L'existence de ces terminaux bimodes, associée à la popularité croissante du VoIP, a conduit à l'apparition du concept de Convergence

Fixe-Mobile (FMC, Fixed-Mobile Convergence), proposant un système de communications unique englobant à la fois un réseau PSTN cellulaire et un réseau IP, de manière à ce que le terminal bimode puisse continuer de communiquer avec ce système de communication en utilisant l'une ou l'autre de ses connexions.

Le document WO-A-OO/79814 divulgue un système de communication de ce type comprenant à la fois un réseau PSTN et un réseau IP. Dans ce système de communications, un premier des réseaux comprend un registre de localisation nominal sur lequel est enregistré le terminal bimode, et le second réseau comprend un registre de localisation serveur. Lorsque le terminal bimode se connecte à ce second réseau, le registre de localisation serveur envoie au premier réseau les informations de localisation mises à jour.

Le document US-A-2005/0096024 divulgue un système de communication semblable à celui du document WO-A-OO/79814, dans lequel, lorsque le terminal bimode se connecte au réseau IP, le réseau IP doit transmettre son adresse IP à un registre de localisation du réseau PSTN.

Le document US-A-2009/0131045 divulgue un autre système de communication comprenant un réseau PSTN et un réseau IP. Dans ce système, les appels entrants destinés au terminal bimode sont toujours acheminés de force par l'intermédiaire du réseau IP. Si le terminal bimode n'est pas connecté au réseau IP à cet instant ils sont réacheminés du réseau IP au réseau PSTN. Bien que ce système ne nécessite plus l'envoi d'une mise à jour de la localisation du réseau IP au réseau PSTN chaque fois que le terminal bimode se connecte au réseau IP ou s'en déconnecte, une largeur de bande considérable est exigée entre les deux réseaux, notamment lorsque le terminal bimode n'est pas connecté au réseau IP. Dans ce cas, l'appel doit être transmis du réseau PSTN au réseau IP puis être renvoyé au réseau PSTN.

Le problème de transfert d'un appel en cours lorsqu'un terminal bimode passe d'un réseau IP à un réseau PSTN a cependant été décrit dans de nombreux documents, par exemple par le Projet de Partenariat de 3ème Génération (3GPP™) dans sa Spécification Technique 3GPP TS 23.206. Néanmoins, pour effectuer un transfert d'appel avec continuité de l'appel vocal, cette spécification technique exige également des ressources supplémentaires sous la forme d'un Sous-système Multimédia IP (IMS, IP Multimedia Subsystem).

Le document US-A-2006/0198360 divulgue un système de communication et un procédé de transfert d'un appel lorsqu'un terminal bimode passe d'un réseau IP à un réseau PSTN. Le réseau IP comprend alors un gestionnaire d'appel qui émet un appel de continuité vers le terminal bimode par l'intermédiaire du réseau PSTN si la connexion par l'intermédiaire du réseau IP est dégradée.

Le document EP-A-2018014 divulgue un système et un procédé de communications conformément auxquels un appel de continuité est émis par un combiné bimodes pouvant se connecter à la fois à un réseau IP et à un réseau fixe, soit manuellement, soit automatiquement, si la connexion par l'intermédiaire du réseau IP est dégradée. Un Autocommutateur Privé (PBX, Private Branch Exchange) est alors connecté au monde extérieur par l'intermédiaire d'un réseau Numérique à Intégration de Services (ISDN, Integrated Services Digital Network) et tous les appels sont acheminés par l'intermédiaire de ce denier. Lorsqu'un appel doit être transféré entre un réseau IP et un réseau fixe, le combiné déclenche une mise en attente du premier appel (l'appel en cours entre le combiné et un dispositif distant) en envoyant un message à l'autocommutateur. L'autocommutateur réexpédie le message au dispositif distant. Un deuxième appel est établi entre le combiné et l'autocommutateur au moyen d'un troisième appel qui est établi entre l'autocommutateur et le dispositif distant. Le premier appel est interrompu lorsque la connexion entre le combiné et le dispositif distant a été acheminée par l'intermédiaire des deuxième et troisième appels.

Les documents US-A-2006/0121902 et US-A-2008/0273505 divulguent également des systèmes et des procédés de communication permettant de transférer un appel lorsqu'un terminal bimode passe d'un réseau IP à un réseau PSTN.

La présente invention a donc pour but de fournir un système et un procédé destinés à déterminer un transfert entre des réseaux dans un système terminal multimode en fonction de la qualité vocale de l'appel sur l'un des réseaux.

Conformément à un premier aspect de la présente invention, celle-ci concerne un système de communication multimode comprenant au moins un réseau à protocole internet, au moins un réseau de télécommunications mobiles, une plateforme de télécommunications et au moins un terminal multimode, ladite plateforme de télécommunications et ledit au moins un terminal multimode pouvant tous deux être connectés audit au moins un réseau à protocole internet et audit réseau de télécommunications mobiles, ledit système comprenant : au moins un module de contrôle de continuité vocale destiné à assurer la continuité d'appel pour un appel mettant en jeu au moins un terminal multimode lorsqu'il est connecté audit au moins un réseau à protocole internet ; caractérisé en ce que ledit système comprend en outre au moins un module de contrôle de qualité vocale destiné à déterminer la qualité vocale de l'appel d'un appel mettant en jeu ledit au moins un terminal multimode lorsqu'il est connecté audit au moins un réseau à protocole internet ; et en ce que ledit au moins un module de contrôle de continuité vocale a pour fonction de déclencher un transfert entre ledit au moins un réseau à protocole internet et ledit au moins un réseau de télécommunications mobiles en fonction d'un niveau de qualité vocale minimale prédéterminée déterminé par ledit au moins un module de contrôle de qualité vocale. Le module de contrôle de continuité vocal est avantageusement constitué de deux composants résidant respectivement sur la plateforme de télécommunication et sur le terminal multimode et coopérant entré'eux. Le module de contrôle de qualité vocale est également avantageusement constitué de deux composants résidant respectivement sur la plateforme de télécommunication et sur le terminal multimode et coopérant entre eux.

La présente invention peut plus particulièrement s'appliquer à des systèmes de communications qui fonctionnent en association avec une plateforme à convergence mobile-mobile (MMC, Mobile-to-Mobile Convergence). Dans un tel système, la qualité vocale peut être déterminée à la fois par la plateforme MMC et par un terminal multimode comportant une application MMC et pouvant être adapté en fonction d'exigences spécifiques d'un abonné ou d'un opérateur du système.

Le système comprend en outre un gestionnaire d'appel associé audit au moins un module de contrôle de continuité vocale, ledit gestionnaire d'appels ayant pour fonction de déclencher un transfert entre ledit au moins un réseau à protocole internet et ledit au moins réseau de télécommunications mobiles.

Le niveau prédéterminé de qualité vocale minimale peut être déterminé en fonction de la disponibilité du protocole internet, de la disponibilité du réseau de télécommunications mobiles et/ou d'un protocole de transport temps réel associé au trafic vocal d'un appel en cours qui est assuré par un module à protocole de commande de transport temps réel.

Le terme "disponibilité" tel qu'il est utilisé ici désigne l'aptitude à possibilité de détecter la présence du réseau concerné, la détermination du fait de savoir s'il est possible de se connecter au réseau concerné, et si le réseau concerné répond aux critères de fonctionnement dans le système, par exemple le fait de savoir si l'intensité du signal se situe à un niveau suffisant pour garantir une connexion satisfaisante.

Un module analyseur de protocole temps réel peut également fournir des données de protocole temps réel concernant le trafic vocal de l'appel, le niveau de qualité vocale minimale prédéterminée étant déterminé conformément au protocole temps réel. Une base de données contenant des données concernant au moins un utilisateur du système peut également être prévue, le niveau de qualité vocale minimale prédéterminée étant déterminé conformément auxdites données d'utilisateurs. Des données de terminaux multimodes concernant les terminaux associés au système peuvent également être utilisées pour déterminer la qualité vocale minimale prédéterminée.

Dans un mode de réalisation, la plateforme comprend un premier module de contrôle de qualité vocale et un premier module de contrôle de continuité vocale et le terminal multimode associé à la plateforme comprend un deuxième module de contrôle de qualité vocale et un deuxième module de contrôle de continuité vocale, ladite qualité vocale minimale prédétèrminée d'un appel en cours étant déterminée par au moins l'un desdits premier et deuxième modules de contrôle de qualité vocale et ledit transfert étant déclenché par au moins ledit premier module de contrôle de continuité vocale.

Conformément à un autre aspect de la présente invention, celle-ci concerne un terminal multimode destiné à être utilisé dans un système terminal multimode tel que celui décrit ci-dessus, dans lequel ledit terminal comprend un module de contrôle de qualité vocale comportant un gestionnaire de protocole internet destiné à détecter la disponibilité dudit au moins un réseau à protocole internet et à déterminer si la qualité vocale respecte ladite qualité vocale minimale prédéterminée associée audit au moins un réseau à protocole internet et à déclencher un transfert entre lesdits au moins un réseau à protocole internet et ledit réseau de télécommunications mobiles.

Il est préférable que le terminal multimode se connecte à un réseau à protocole internet de préférence à un réseau de télécommunications mobiles. Le terminal déclenche un transfert dudit réseau à protocole internet au réseau de télécommunications mobiles lorsque ladite qualité vocale du réseau IP s'abaisse en dessous d'une qualité vocale minimale prédéterminée, le transfert étant déclenché en fonction de la disponibilité du réseau à protocole internet et/ou de la disponibilité du réseau de télécommunications mobiles.

Il est préférable que le terminal multimode comprenne un module de contrôle de continuité vocale destiné à déclencher un transfert entre ledit au moins un réseau à protocole internet et ledit réseau de télécommunications mobiles lorsque ladite qualité vocale s'abaisse en dessous de ladite qualité vocale minimale prédéterminée. Le terminal multimode peut en outre comprendre un module à protocole de commande de transport temps réel constituant un protocole de commande de transport temps réel concernant le trafic vocal dudit appel et/ou un module analyseur de protocole temps réel fournissant des données de protocole temps réel concernant le trafic vocal dudit appel, ledit niveau de qualité vocale minimale prédéterminée étant déterminé conformément audit protocole de commande de transport temps réel et/ou audit protocole temps réel.

Conformément à un autre aspect de la présente invention, celle-ci concerne un procédé destiné à mettre en œuvre un transfert d'un appel vocal entre un réseau à protocole internet et un réseau de télécommunications mobiles dans un système terminal multimode, ledit système ayant au moins un réseau à protocole internet, au moins un réseau de télécommunications mobiles, une plateforme de télécommunications et au moins un terminal multimode, la plateforme de télécommunications et ledit au moins un terminal multimode pouvant tous deux être connectés audit au moins un réseau à protocole internet et audit au moins un réseau de télécommunications mobiles, ledit procédé comprenant les étapes consistant à : a) affecter un niveau de qualité vocale minimale prédéterminée à un appel vocal connecté audit au moins un réseau à protocole internet ; b) déterminer la qualité vocale de l'appel pour ledit au moins un réseau à protocole internet ; c) comparer ladite qualité vocale de l'appel déterminée audit niveau de qualité vocale minimale prédéterminée ; et d) déclencher un transfert dudit appel vocal entre ledit au moins un réseau à protocole internet et ledit au moins un réseau de télécommunications mobiles lorsque ladite qualité vocale de l'appel déterminée s'abaisse en dessous dudit niveau de qualité vocale minimale prédéterminée.

Il est préférable que l'étape d) consiste à déclencher un transfert en fonction de la couverture du réseau à protocole internet et/ou de la disponibilité du réseau de télécommunications mobiles. L'étape a) peut consister à affecter ledit niveau de qualité vocale minimale prédéterminée en fonction de l'une : de données d'utilisateurs ; de données de terminaux multimodes ; du trafic vocal à protocole temps réel ; et d'informations de protocole de commande de transport temps réel.

En outre, l'étape a) peut consister à établir un appel vocal par l'intermédiaire d'un réseau à protocole internet de préférence à un réseau de télécommunications mobiles.

Pour une meilleure compréhension de la présente invention, on se référera à présent à titre non limitatif d'exemple aux dessins annexés, dans lesquels : la figure 1 illustre un système de communications dans lequel un appel peut être transféré entre un réseau IP et un réseau GSM ; la figure 2 illustre l'acheminement d'un appel entrant par l'intermédiaire du réseau IP lorsque le terminal bimode est connecté au réseau IP dans le système de communications représenté sur la figure 1 ; la figure 3 illustre l'acheminement d'un appel entrant par l'intermédiaire du réseau PSTN vers le réseau bimodes lorsque le terminal bimode n'est pas connecté au réseau IP ou ne répond pas dans le système de communications représenté sur la figure 1 ; les figures 4a et 4b illustrent un réacheminement effectué par l'intermédiaire du réseau PSTN d'un appel en cours si la connexion du terminal bimode au réseau IP est dégradée ; la figure 5 illustre une architecture MMC conformément à la présente invention ; la figure 6 illustre une architecture de contrôle de qualité vocale de l'appel MMC conformément à la présente invention ; la figure 7 illustre un appel entrant destiné à un terminal bimode lorsque l'appel est acheminé via un réseau IP ; la figure 8 illustre un appel entrant destiné à un terminal bimode après transfert sur GSM ; la figure 9 illustre un appel sortant d'un terminal bimode par l'intermédiaire d'un réseau IP ; la figure 10 illustre un appel sortant d'un terminal bimode après transfert sur GSM ; la figure 11 est semblable à la figure 7 et illustre un ancrage ISUP évolué ; la figure 12 est semblable à la figure 8 et illustre l'ancrage ISUP et INAP.

La présente invention sera décrite à propos de modes de réalisation particuliers et en référence à certains dessins bien que l'invention n'y soit pas limitée. Les dessins décrits sont représentés de manière schématique et ne sont pas limitatifs. Dans les dessins, la taille de certains des éléments peut être exagérée et ceux-ci peuvent ne pas être représentés à l'échelle à des fins d'illustration.

Les réseaux téléphoniques à commutation de circuits utilisent un protocole de signalisation désigné sous le nom de Système de Signalisation à Canal Commun #7 (plus généralement appelé SS7 ou C7). Sur le réseau téléphonique commuté public (PSTN), des points d'extrémité de signalisation envoient et reçoivent des messages de signalisation SS7. Il existe trois types de points d'extrémité de signalisation : un Point de Commutation de Service (SSP ou central de commutation) ; un Point de Transfert de Signal (STP, Signal Transfer Point) ; et un Point de Contrôle de Service (SCP, Service Control Point).

Dans les réseaux SS7, des messages de signalisation à Partie Utilisateur (ISUP) du Réseau Numérique à Intégration de Services (ISDN), sont utilisés pour établir, gérer et libérer des circuits de jonction qui acheminent des appels vocaux entre des centraux téléphoniques. Les messages ISUP acheminent également des informations d'identification de l'appelant (ID) telles que le numéro de téléphone et le nom d'un appelant. La partie ISUP est utilisée à la fois pour les appels ISDN et non ISDN entre centraux téléphoniques.

Des messages de signalisation de la Partie d'Application de Capacités de Transaction (TCAP, Transaction Capabilities Application Part) prennent en charge des services de téléphonie, tels que les appels gratuits (téléphone gratuit), les cartes d'appels, la portabilité des numéros locaux et l'itinérance mobile (sans fil) et des services d'authentification. Les services mobiles sont activés par des informations acheminées dans la Partie d'Application Mobile (MAP, Mobile Application Part) d'un message TCAP. Le protocole TCAP prend en charge l'échange d'informations non liées au circuit entre des points de signalisation utilisant le service sans connexion de la Partie de Contrôle de Connexion de Signalisation (SCCP, Signalling Connection Control Part).

Les réseaux du type Voix sur Protocole internet (VoIP) acheminent des informations SS7 sur IP en utilisant des protocoles définis par le groupe de travail relatif au Transport de Signalisation (SigTran) de l'IETF (Internet Engineering Task Force), organisation internationale responsable de la recommandation des normes internet. Les protocoles SigTran prennent en charge les exigences strictes de la signalisation SS7/C7 telles qu'elles sont définies par l'Union Internationale des Télécommunications.

Dans les réseaux de téléphonie sur IP, des informations de signalisation sont échangées entre les éléments fonctionnels suivants : la passerelle multimédia (MG, Media Gateway), le contrôleur de passerelle multimédia (MGC, Media Gateway Controller), et la passerelle de signalisation.

La passerelle multimédia constitue la terminaison des appels vocaux sur les jonctions inter-centraux provenant du réseau téléphonique public commuté, comprime et empaquète les données vocales, et délivre des paquets vocaux comprimés au réseau IP. Pour les appels vocaux provenant d'un réseau IP, la passerelle multimédia exécute ces fonctions dans l'ordre inverse. Pour des appels ISDN provenant du réseau PSTN, des informations de signalisation Q.931 sont transportées de la passerelle multimédia vers le contrôleur de passerelle multimédia pour le traitement des appels.

Le contrôleur de passerelle multimédia traite l'enregistrement et la gestion de ressources au niveau de la ou des passerelle(s) multimédia et échange des messages ISUP avec les centraux téléphoniques par l'intermédiaire d'une passerelle de signalisation. Comme les fabricants de contrôleurs de passerelles multimédia utilisent souvent des plates-formes informatiques prêtes à l'emploi, un contrôleur de passerelle multimédia est parfois désigné sous le nom de "commutateur logiciel " ("softswitch").

La passerelle de signalisation assure un interfonctionnement transparent de la signalisation entre des réseaux à commutation de circuits et IP et peut interrompre la signalisation SS7 ou convertir et relayer des messages par l'intermédiaire d'un réseau IP vers un contrôleur de passerelle multimédia ou une autre passerelle de signalisation. Du fait de leur rôle déterminant dans les réseaux vocaux intégrés, les passerelles de signalisation sont souvent déployées par groupes de deux ou plus pour garantir une disponibilité élevée.

Les passerelles multimédia, les passerelles de signalisation ou les contrôleurs de passerelles multimédia ("softswitch") peuvent être des dispositifs physiques distincts ou intégrés sous la forme d'une combinaison quelconque.

Bien que la présente invention soit décrite en référence à un terminal bimode pouvant être connecté à un réseau GSM ou IP, il est à noter que le terminal peut être connecté à plus de deux types de réseaux et peut donc comprendre un terminal multimode. En outre, le terme "terminal mobile" tel qu'il est utilisé ici doit être considéré comme couvrant les terminaux bimodes et les terminaux multimodes.

La figure 1 représente un système de communications 100 comprenant un réseau PSTN 110, un réseau IP 120, tel que l'internet, et un terminal bimode 260. Le terminal bimode 260 peut être un dispositif multimode approprié quelconque, par exemple un téléphone intelligent, une tablette ou tout autre dispositif portable disposant de la connectivité nécessaire. Bien que le terminal 260 soit décrit comme étant un terminal bimode, il est à noter qu'il peut s'agir d'un terminal multimode fonctionnant sur plus de deux modes.

Le réseau PSTN 110 est un réseau mobile terrestre public (PLMN, Public Land Mobile Network) comprenant un centre de commutation mobile (MSC, Mobile Switching Center) 140 connecté à un registre de localisation nominal (HLR, Home Location Register) 150, un SCP 160 et un STP 170. Il est à noter que bien que l'on n'ait représenté qu'un seul de ces éléments, ils peuvent être doublés à des fins de redondance, comme cela est couramment effectué dans ce domaine technique. Le réseau PSTN 110 comprend également des stations de base 175, 180, 185, chaque station de base assurant la couverture d'une cellule de téléphonie mobile.

Le réseau IP 120 comprend un serveur de routage 190 qui, dans ce mode de réalisation particulier, est un serveur de protocole d'ouverture de signal (SIP, Signal Initiation Protocol), et une passerelle MG 130 connectée à un contrôleur MGC 200. Ce contrôleur MGC 200 est identifié par un code de point de signalisation, de manière à ce qu'il puisse échanger des informations de signalisation d'appel par l'intermédiaire du point STP 170 en utilisant une signalisation SS7 ISUP. La passerelle MG 130 est connectée, par l'intermédiaire du réseau IP 120, à un routeur de réseau local sans fil (WLAN, Wireless LAN) 210 assurant la couverture d'un réseau local sans fil, et à un serveur de continuité des appels vocaux (VCC, Voice Call Continuity) 220. Le serveur VCC 220 possède une Table d'Appels en Cours (CPT, Call in Progress Table) 230. Tout comme le point STP 170, la passerelle MG 130 et le MGC 200 peuvent être doublés à des fins de redondance.

Dans ce mode de réalisation, le contrôleur MSC 140 et la passerelle MG 130 sont connectés par l'intermédiaire d'une jonction E1 ou T1 240. Dans cette jonction 240, un canal de signalisation SS7 ISUP 250 assure les communications de signalisation entre le point STP 170 et le contrôleur MGC 200. Le terminal bimode 260 comprend à la fois un émetteur-récepteur de téléphonie mobile, comme par exemple un émetteur-récepteur GSM, un émetteur-récepteur CDMA, un émetteur-récepteur PDC, un émetteur-récepteur PDMA, un émetteur-récepteur UMTS ou un émetteur-récepteur CDMA2000 et, dans ce mode de réalisation, un émetteur-récepteur WLAN, tel qu'un émetteur-récepteur de type IEEE 802.11 (Wi-Fi™), permettant au terminal bimode 260 de se connecter indépendamment à la fois au réseau PSTN 110 et au réseau IP 120.

Le terminal bimode 260 comprend en outre un client SIP qui peut être mis en œuvre par un processeur de données programmable générique exécutant un programme informatique spécifique. Le terminal bimode 260 possède un identifiant unique qui est stocké dans le registre HLR 150 comme appartenant à un abonné à un service FMC.

Les figures 2 et 3 sont semblables à la figure 1 et illustrent l'acheminement d'un appel entrant 300 vers un terminal bimode 260. Sur la figure 2, la connexion est établie par l'intermédiaire du réseau IP 120 et sur la figure 3, la connexion n'utilise pas le réseau IP 120.

Lorsqu'un appel entrant 300 est reçu par l'intermédiaire du réseau PSTN 110, le contrôleur MSC 140 vérifie si l'identifiant unique associé au terminal bimode 260 est enregistré dans le registre HLR 150 comme appartenant à un abonné à ce service FMC. Si cela est le cas, le contrôleur MSC 140 renvoie l'appel au point SCP 160, qui applique un sous-programme de routage forcé par l'intermédiaire du point STP 170. Le point STP 170 envoie une demande de connexion par l'intermédiaire du canal de signalisation SS7 ISUP au contrôleur MGC 200 qui interroge ensuite le serveur de routage 190.

Si le terminal bimode 260 est connecté au réseau IP 120, son client SIP aura envoyé un message d'enregistrement au serveur de routage 190. Si le terminal bimode 260 est encore enregistré sur le serveur de routage 190 lorsque le contrôleur MGC 200 interroge le serveur de routage 190, le serveur de routage 190 transmet ainsi le message d'invitation SIP "Invite" au terminal bimode 260, et renvoie au contrôleur MGC 200 un message SIP "Trying" ("Essai"). S'il est disponible, le terminal bimode 260 répond alors au message SIP "Invite" du serveur de routage 190, tout d'abord par un message SIP "Trying", puis par des messages SIP "Ringing" ("Sonnerie") et/ou "Early Media" ("Début Multimédia") et "OK". Ces deux ou trois messages, par exemple "Ringing" et "OK" ou "Early Media" et "OK" se référant à deux messages, et "Ringing", "Early Media" et "OK" lorsqu'il s'agit de trois messages, sont transmis par le serveur de routage 190 au contrôleur MGC 200 en tant que réponse positive à sa requête. Le contrôleur MGC 200 les convertit et les retransmet au point STP 170 par l'intermédiaire du canal SS7 ISUP 250, en acceptant la demande de connexion provenant du point STP 170 et en établissant l'appel entrant, comme indiqué en 300, afin qu'il soit acheminé au terminal bimode 260 sous la forme d'un appel VoIP par l'intermédiaire du réseau IP 120 au terminal bimode 260 par l'intermédiaire du routeur WLAN 210.

Le contrôleur MGC 200 envoie également un message SIP d'accusé de réception "ACK" au serveur de routage 190, qui va le transmettre au terminal bimode 260. Si le terminal bimode 260 est occupé, il répond au message SIP "Invite" du serveur de routage 190 par un message SIP par un message "Busy" ("Occupé"), qui sera ensuite transmis au contrôleur MGC 200, celui-ci le convertissant en un message SS7 ISUP "REL" avec le code de cause de libération "Busy" pour le point STP 170. Le point STP 170 accuse alors réception du signal d'occupation à destination du contrôleur MGC 200 qui le convertit en un message SIP "ACK" pour le terminal bimode 260 par l'intermédiaire du serveur de routage 190.

Si le terminal bimode 260 n'est pas (ou n'est plus) enregistré sur le serveur de routage 190, le serveur de routage 190 renvoie, après son message SIP "Trying", une réponse négative à la requête provenant du contrôleur MGC 200, sous la forme d'un message SIP contenant un code d'échec. Le contrôleur MGC 200 répond alors à son tour à la demande de connexion par un message SS7 ISUP "REL". Le point STP 170 accuse alors réception de ce message par un message SS7 ISUP "RLC" destiné au MGC 200, qui le convertit en un message SIP "ACK" pour le serveur du routage 190.

Si le terminal bimode 260, bien que connecté au réseau IP 120, ne répond pas à des messages SIP "Invite" répétés envoyés par le serveur de routage 190, au-delà d'un temps limite, le serveur de routage 190 envoie un message SIP "Cancel" ("Annuler") au terminal bimode 260, et un message SIP "Request Timeout" ("Temps limite de la demande") au contrôleur MGC 200. Le contrôleur MGC 200 répond alors à la demande de connexion par un message SS7 ISUP "REL". Le point STP 170 accuse alors réception de celui-ci par un message SS7 ISUP "RLC" destiné au contrôleur MGC 200 qui le convertit en un message SIP "ACK" pour le serveur de routage 190. Dans les deux cas, l'appel entrant 300 est acheminé au terminal bimode 260 par l'intermédiaire du réseau PSTN 110, sans pénétrer dans le réseau IP 120, comme illustré en 300' sur la figure 3.

Une fois qu'il se produit un appel en cours 300 (figure 2) par l'intermédiaire du réseau IP 120 à destination du terminal bimode 260, le terminal bimode 260 surveille la qualité de la connexion, par exemple en surveillant les pertes de paquets, l'intensité du signal sans fil, la gigue courante et/ou la taille du tampon de gigue, etc., et lorsque la qualité de la connexion s'abaisse en dessous d'un seuil prédéterminé, un transfert peut être déclenché d'un réseau vers un autre, par exemple d'un réseau IP vers un réseau de télécommunications mobiles et inversement. Le transfert est décrit plus en détail ci-après et est propre à la plateforme, c'est-à-dire qu'il est commandé par la plateforme de télécommunications sur laquelle fonctionne le terminal bimode 260.

La figure 4a est semblable à la figure 2 et illustre une partie de la séquence de transfert. Si la connexion du terminal bimode 260 au réseau IP 120 est notablement dégradée, par exemple en raison du fait que le terminal bimode 260 se déplace en limite de portée du routeur WLAN 210, le client SIP du terminal bimode 260 déclenche un appel de continuité 400 par l'intermédiaire d'un réseau PSTN vers le serveur VCC 220, en utilisant un numéro de service VCC.

Ce numéro de service VCC peut être sélectionné dans une table de numéros de service VCC disponibles, dépendant de la position, qui peut être déterminée à partir de données de positionnement global et/ou de l'indicateur du réseau mobile (MNC, Mobile Network Code) et/ou de l'indicatif de pays mobile (MCC, Mobile Country Code) de la station de base 185 du réseau PLMN auquel est connecté le terminal bimode 260. Par conséquent, si cet indicatif MNC correspond à celui d'un réseau PLMN de "départ" ("Home") auquel est abonné le terminal bimode 260, le numéro de service VCC sélectionné est habituellement un numéro court spécifique. Cependant, si l'indicatif MNC et/ou l'indicatif MCC ne correspondent pas à un réseau PLMN de "départ", indiquant que le terminal bimode 260 est connecté par l'intermédiaire d'un réseau PLMN tiers, le numéro de service VCC sélectionné peut être un numéro générique, éventuellement un numéro gratuit, qui sera acheminé par l'intermédiaire d'une autre jonction VolP. Le numéro de service VCC peut même être un préfixe de pays différent si l'indicatif MCC diffère également de celui du réseau PLMN de "départ", indiquant que le terminal bimode 260 est en itinérance à l'étranger, cela rendant encore plus importante la sélection d'un numéro de service VCC peu coûteux. Bien que, dans le mode de réalisation illustré, l'appel de continuité 400 soit acheminé part l'intermédiaire du même réseau PSTN 110 que celui dont provient l'appel entrant 300, il peut donc être acheminé par l'intermédiaire d'un réseau téléphonique différent, et pénétrer dans le réseau IP par l'intermédiaire d'une passerelle multimédia différente.

Lorsque le serveur VCC 220 reçoit un appel de continuité 400 destiné à un numéro de service VCC de ce type et émanant d'un terminal bimode d'abonné 260, le serveur VCC 220 vérifie dans la table CPT 230 s'il existe un appel en cours 300 avec ce terminal bimode par l'intermédiaire du réseau IP 120. Si la réponse est positive, le serveur VCC 220 permute l'appel de continuité 400 avec le réseau IP de l'appel en cours 300, puis ferme le trajet du réseau IP. Comme illustré sur la figure 4b, cela met un terme au transfert de l'appel en cours 300 du réseau IP 120 au réseau PSTN 110.

Bien que l'on n'ait illustré que des exemples d'appels entrants destinés au terminal bimode 260, il est à noter que le terminal bimode 260 peut lui-même également émettre des appels sortants, à la fois par l'intermédiaire de ses émetteurs-récepteurs de téléphonie mobile et sans fil. En effet, le transfert d'appel illustré sur les figures 4a et 4b peut être réalisé indépendamment du fait que l'appel en cours 300 soit un appel entrant ou un appel sortant. Il est également à noter que bien que seuls des appels établis entre le terminal bimode 260 et l'abonné du réseau PSTN aient été illustrés, le terminal bimode 260 peut également émettre et recevoir des appels vers et en provenance d'abonnés d'un réseau IP.

Bien que, dans ce mode de réalisation particulier de l'invention, on n'ait décrit qu'un transfert déclenché par un client, le transfert peut également être réalisé par le serveur VCC dans le cas d'un appel de continuité allant du contrôleur MGC au terminal bimode, suite à une instruction obtenue par l'intermédiaire d'informations de signalisation transmises par le serveur VCC. On notera également que bien que le contrôleur MG 130 et le contrôleur MGC 200 soient illustrés ici comme étant deux entités distinctes, ils peuvent être combinés en une seule unité.

On notera également que bien que la présente invention concerne principalement des appels vocaux, d'autres services mobiles, tels que les messages de texte et la messagerie vocale, peuvent également être accessibles à la fois par l'intermédiaire du réseau PSTN 110 et du réseau IP 120.

La figure 5 illustre un schéma fonctionnel d'un système de communications 500 conforme à la présente invention. L'architecture 500 comprend une architecture MMC 505, un réseau fixe 510 et un serveur MSC/HLR 515. La convergence MMC est un dérivé de la convergence FMC conformément à laquelle un terminal bimode fonctionne à l'aide de logiciels et de matériels spécialisés pour connecter des appels vocaux et d'autres applications par transmission de voix sur WLAN (VoWLAN) et/ou au moyen d'un service cellulaire. Un réseau local sans fil WLAN est utilisé pour acheminer des appels par l'intermédiaire de l'internet et utilise un réseau porteur sans fil si le réseau WLAN n'est pas présent. Elle diffère de la convergence FMC en ce qu'une classification est utilisée de manière à ce que les connexions au réseau WLAN constituent la connexion principale et que le réseau porteur sans fil constitue la connexion secondaire.

Il est à noter que la présente invention n'est pas limitée au réseau WLAN et qu'il peut s'agir d'un réseau 3G, EDGE ou de tout autre réseau IP. Le terme Wi-Fi tel qu'il est utilisé ici désigne une connexion à un réseau IP approprié quelconque, parmi lesquels des réseau 3G, EDGE, VoWLAN, etc. L'architecture 505 comprend un cœur SI P 520 connecté au serveur MMC VCC et de contrôle de qualité vocale (VQC, Voice Quality Control) 525. Il est prévu des première et seconde passerelles MG 530, 535 qui permettent d'établir des connexions au réseau fixe 510 et au serveur MSC/HLR 515 depuis le cœur SIP 520. Le serveur MMC VCC et VQC 525 peut être connecté à une zone Wi-Fi publique (zone publique) 540 et à une zone Wi-Fi contrôlée (points d'accès sans fil) 545.

Le réseau fixe 510 est connecté à un premier réseau PSTN 550 et le serveur MSC/HLR 515 est connecté à un second réseau PSTN 555. Les premier et second réseaux PSTN 550, 555 peuvent être connectés l'un à l'autre ou, dans un mode de réalisation, peuvent être un même réseau PSTN. Le serveur MSC/HLR 515 est également connecté à un réseau d'accès radio mobile (RAN, Radio Access Network) 560 par l'intermédiaire d'un serveur MSC/HLR mobile 565. Le serveur MSC/HLR 515 est également connecté à un système de messagerie vocale mobile 570.

Un terminal bimode 575 peut être connecté à la zone publique 540, à des points d'accès sans fil 545 et au réseau mobile RAN 560. Le terminal bimode 575, qui peut par exemple être le combiné d'un téléphone intelligent, comporte une application cliente MMC qui commande la connexion au réseau de manière à ce que les zones Wi-Fi, la zone publique 540 et les points d'accès sans fil 545 soient prioritaires, le réseau RAN mobile 560 n'étant utilisé que lorsque le Wi-Fi n'est pas disponible. L'architecture MMC 510 prend en charge la qualité vocale d'appel la plus élevée possible sur le réseau le mieux adapté en fonction de la disponibilité. L'architecture 505 comporte deux éléments principaux, à savoir une plateforme MMC correspondant au cœur SIP 520 et le serveur MMC VCC et VQC525, et un client MMC (non représenté) qui est installé sur le terminal bimode 575.

La technologie actuelle mise en œuvre sur les combinés de téléphones intelligents en association avec les performances du Wi-Fi, la qualité vocale de l'appel (VCQ) permise par les appels Wi-Fi (VoIP via Wi-Fi) est supérieure à la qualité moyenne des appels GSM. Un codée à haute définition sur le client MMC autorise cette VCQ élevée, comme cela sera décrit plus en détail ci-après. Conformément à la présente invention, lorsque la VCQ Wi-Fi d'un appel Wi-Fi s'abaisse en dessous de la qualité d'un appel GSM moyen, un transfert est déclenché entre l'appel Wi-Fi et un réseau cellulaire GSM.

La figure 6 illustre un système 600 de contrôle VCQ MMC. Le système 600 comprend une plateforme MMC 610 comportant un module de continuité des appels vocaux (VCC) 615, un module de contrôle de la qualité vocale (VQC) 620 et un module gestionnaire d'appels 625. Le module VCC 615 commande le processus de transfert entre le Wi-Fi et le GSM. Le module VQC 620 analyse la qualité vocale sur la base du trafic vocal à protocole temps réel (RTP, Real-Time

Protocol) et du protocole de commande de transport temps réel (RTCP, Real-Time Transport Control Protocol).

Le protocole RTP définit un paquet normalisé permettant de délivrer de l'audio et de la vidéo par l'intermédiaire de réseaux IP et est utilisé dans tous les systèmes de communications utilisant l'envoi en flux continu de données multimédia, parmi lesquels les applications de téléphonie et de visioconférence et les fonctionnalités de messagerie vocale instantanée basées sur le Web. Le protocole RTP est utilisé en association avec le protocole RTCP. Alors que le protocole RTP achemine des flux multimédia, comme par exemple de l'audio et de la vidéo, le protocole RTCP est utilisé pour surveiller les statistiques de transmission et la qualité de service (QoS, Quality of Service) et aider à synchroniser de multiples flux. De plus, le protocole RTP est l'un des fondements techniques du VoIP et est souvent utilisé en association avec le protocole de signalisation pour établir des connexions à travers le réseau.

Le module gestionnaire d'appels 625 communique avec des premier et second contrôleurs de frontières entre sessions (SBC, Session Border Controller) 630, 640. Le premier SBC 630 forme une interface avec la jonction SIP (non représentée) et le second SBC 640 forme une interface avec une pile SIP 670 dans un terminal bimode 650, comme cela sera décrit plus en détail ci-après. Une première passerelle MG 635 forme également une interface avec le SBC 630 et permet d'établir des communications à destination d'un réseau PSTN et d'un opérateur de réseau mobile (MNO, Mobile Network Operator) (aucun d'eux n'étant représenté). La première passerelle MG 635 gère également le transfert d'appels GSM. Un internet public 645 est disponible entre la plateforme MMC 610 et le terminal bimode 650.

Dans le terminal bimode 650, un émetteur-récepteur Wi-Fi 655 et un émetteur-récepteur GSM 680 sont prévus. L'émetteur-récepteur Wi-Fi 655 est connecté à un module VCC 660, à un module VQC 665 et à la pile SIP 670. Le module VCC 660 correspond au module VCC 615 de la plateforme MMC 610. Le module VQC 665 analyse la qualité vocale sur la base de la couverture RTCP et Wi-Fi. La pile SIP 670 est optimisée en fonction de la plateforme MMC 610 particulière à laquelle est associé le terminal bimode 650, et peut être connectée en Wi-Fi, comme indiqué par l'émetteur-récepteur 675, pour fournir une signalisation SIP (SIP SIG) au contrôleur SBC 640 associé à la plateforme MMC 610. Bien que l'émetteur-récepteur Wi-Fi 655 et que l'émetteur-récepteur Wi-Fi 675 soient représentés sous la forme de deux modules distincts, il est à noter qu'ils peuvent être mis en œuvre sous la forme d'un module émetteur-récepteur unique.

De plus, bien que l'émetteur-récepteur 675 soit représenté sur la figure 6 comme étant situé à l'extérieur du terminai mobile 650 pour plus de clarté, il est à noter qu'il est néanmoins situé à l'intérieur du corps du terminal mobile 650.

La qualité VCQ est gérée par des composants MMC intégrés afin d'assurer une qualité vocale d'appel optimale de bout en bout. Conformément à la présente invention, ceci est obtenu par le module VQC 620 et le module VCC 615 sur la plateforme MMC 610 et par le module VQC 665 et le module VCC 660 sur le terminal bimode 650. Les modules VQC 620, 665 vérifient des indicateurs de qualité vocale d'appel pour la totalité des appels vocaux de type IP en cours. Ces vérifications peuvent comprendre : 1) des échanges corrects d'informations de signalisation SIP ; 2) la présence d'un trafic RTP, c'est-à-dire d'un protocole RTP acheminant un trafic VoIP ; 3) le retard de bout en bout des paquets IP ; 4) la gigue de retard, c'est-à-dire les variations du retard d es paquets IP ; 5) les pertes de paquets IP, c'est-à-dire la perte d'informations RTP ; 6) le niveau de couverture Wi-Fi (cela comprenant la disponibilité, l'accès, l'intensité du signal, etc.) ; et 7) le niveau de couverture du réseau GSM (cela comprenant la disponibilité, l'accès, etc.).

Les modules VCC 615 et 660 réalisent ensemble le transfert d'un appel qui est en cours vers un autre réseau lorsque cela est nécessaire. Le transfert s'exécute en tâche de fond et est transparent vis-à-vis de l'abonné ou de l'utilisateur du terminal bimode 650.

Le terminal bimode 650 peut déclencher un processus d'émission d'appels de qualité Wi-Fi chaque fois qu'il se connecte à un point d'accès Wi-Fi. Cela dépendra du fait que le terminal bimode 650 est ou non déjà connecté à un appel Wi-Fi, du fait que les préférences de l'abonné le permettent ou non, etc. Lors de ce processus, le terminal bimode 650 vérifie la qualité VCQ, une fois qu'il s'est connecté en Wi-Fi, en lançant un appel de test vocal. Cet appel de test est émis en tâche de fond et l'abonné ou l'utilisateur du terminal bimode 650 n'est pas conscient du fait que celui-ci est effectué, si une qualité minimale prédéterminée n'est pas atteinte lors de l'appel de test, le combiné bimodes 650 n'est pas autorisé à traiter les appels en Wi-Fi.

Sur la base de données historiques, la plateforme MMC 610 est en mesure de prédire les instants où il est nécessaire de déclencher un transfert d'appel afin d'éviter toute perturbation de la qualité VCQ pour l'abonné ou l'utilisateur du terminal bimode 650. Cette prédiction se fonde sur un algorithme qui intègre un mélange de paramètres agissant sur la qualité ainsi que des variables externes liées à l'abonné, comme par exemple le matériel du terminal, les logiciels et le point d'accès Wi-Fi. Les conditions permettant le déclenchement d'un transfert sont déterminées en fonction du fournisseur de services MMC, pendant la mise en route du service, et/ou par un curseur prévu sur le terminal bimode 650, qui est actionné par l'utilisateur et prévu pour ajuster la sensibilité. Ces conditions peuvent être définies conformément à des préférences personnelles ou à des conditions de commercialisation spécifiques.

Comme décrit ci-dessus, un processus de transfert transparent revêt une importance primordiale pour le service MMC est exigé pour l'optimisation des coûts, c'est-à-dire que lorsque l'appel Wi-Fi est plus rentable qu'un appel GSM, il est nécessaire de préserver la qualité vocale de l'appel en Wi-Fi et d'assurer la continuité de l'appel vocal au-delà de la portée du point d'accès Wi-Fi. Le processus de transfert transparent sera déclenché soit par le terminal bimode, soit par le serveur VCC MMC et sera mis en œuvre sans intervention de l'abonné ou de l'utilisateur du terminal mobile.

La figure 7 est semblable à la figure 5 et des références numériques identiques sont utilisées pour désigner des composants identiques. Sur la figure 7, on a représenté un utilisateur 580 établissant un appel. Il est à noter que l'utilisateur peut être un autre terminal bimode, un téléphone fixe ou un téléphone mobile. Un appel Wi-Fi entrant est illustré par une ligne en trait mixte passant entre l'utilisateur 580 et le terminal bimode 575. L'appel émis se connecte au réseau PSTN 555 et est retransmis vers le module MSC/HLR 515 où il est acheminé à travers la passerelle multimédia 530 vers le cœur SIP 520, pour atteindre le serveur VQC 525, et à travers la zone Wi-Fi publique 540 jusqu'au terminal bimode 575. Le serveur VQC 525 détermine que la qualité vocale de l'appel dans la zone Wi-Fi publique 540 respecte le niveau minimal prédéterminé et retransmet l'appel vers le terminal bimode par l'intermédiaire de la zone Wi-Fi publique 540. Le terminal bimode 575 est donc connecté à un appel VoIP destiné à l'utilisateur 580.

La figure 8 est semblable à la figure 7 et illustre un appel Wi-Fi entrant après transfert. D'une manière semblable à la figure 7, l'appel Wi-Fi entrant est illustré par une ligne en traits mixtes passant entre l'utilisateur 580 et le terminal bimode 575. Cependant, dans ce cas, l'appel atteint le serveur VQC 525 mais la qualité vocale de l'appel dans la zone Wi-Fi publique 540 ne respecte pas le niveau minimal prédéterminé. Il en résulte que le serveur VQC 525 réachemine l'appel à travers le cœur SIP 520, qui le renvoie à travers la passerelle multimédia 530, vers le module MSC/HLR 515 et sur le réseau RAN mobile 560, afin qu'il soit transmis au terminal bimode 575 par l'intermédiaire d'un réseau GSM. L'appel VoIP devient donc un appel GSM et le terminal bimode 575 n'est plus connecté à la zone Wi-Fi publique 540.

Les figures 9 et 10 sont semblables aux figures 7 et 8 et illustrent respectivement des appels sortants avant et après transfert. Sur la figure 9, le terminal bimode 575 émet un appel Wi-Fi conformément au protocole MMC. L'appel Wi-Fi respecte la qualité d'appel minimale et est acheminé vers le serveur VQC 525, au cœur SIP 520, à travers la première passerelle MG 530, vers le réseau fixe 510 et, par l'intermédiaire du réseau PSTN 550, jusqu'à l'utilisateur 580, comme indiqué par une ligne en trait mixte.

Sur la figure 10, l'appel sortant est acheminé par l'intermédiaire du réseau RAN mobile 560 au module MSC/HLR 515 par l'intermédiaire de la passerelle multimédia 515, du cœur SIP 520, jusqu'au serveur VQC 525. Comme l'appel ne respecte pas le niveau minimal du Wi-Fi, il est renvoyé au cœur SIP 520, à travers la première passerelle MG 530, vers le réseau fixe 510, jusqu'au réseau PSTN 550 et à l'utilisateur 580, comme illustré par une ligne en trait mixte.

Le transfert entre les réseaux a été décrit en référence aux figures 4a et 4b ci-dessus.

La fonctionnalité de transfert du Wi-Fi au GSM est prise en charge par des jonctions vocales ISUP auxquelles se connecte la première passerelle MG 635 (figure 6) de la plateforme MMC 610. La fonctionnalité de transfert du GSM vers le Wi-Fi est plus évoluée et peut être prise en charge par un réseau GSM relié à la plateforme MMC à laquelle des appels mobiles sont en fait "ancrés" dans la plateforme vocale. Cela signifie que la plateforme 610 est informée de tous les appels mobiles en cours sur le réseau GSM relié. L'ancrage d'appels mobiles à la plateforme vocale MMC peut être activé par un ancrage physique de tous les appels mobiles en cours pour acception de tous les appels mobiles entrants et par renvoi de ceux-ci au module MSC ou par réalisation de l'ancrage au moyen d'une signalisation SS7 plus évoluée. Dans le premier cas, l'ancrage peut être obtenu en utilisant des jonctions vocales ISUP classiques existantes mais comme tous les appels mobiles doivent être acheminés par l'intermédiaire de la plateforme vocale MMC, les coûts d'infrastructure peuvent être notablement accrus. Dans le second cas, l'ancrage est obtenu par intégration de plates-formes de réseaux intelligents (IN, Intelligent Network) qui prennent en charge la partie application des réseaux intelligents (INAP, Intelligent Network Application Part) du protocole de signalisation qui permet un traitement évolué des appels mobiles.

Le réseau IN est une architecture de réseau pouvant être utilisée simultanément pour des réseaux de télécommunications fixes et mobiles. Il se fonde sur le protocole SS7 entre des centraux de commutation téléphoniques et d'autres nœuds du réseau appartenant à des opérateurs de réseaux. Cette architecture permet aux opérateurs de se différencier les uns des autres en offrant des services à valeur ajoutée en plus des services de télécommunications classiques, par exemple, des services PSTN, RNIS et GSM. L'intelligence est constituée par des nœuds du réseau se trouvant sur la couche de service du cœur de réseau, qui est différente de la couche de commutation du cœur de réseau. Les nœuds IN sont généralement la propriété des opérateurs de télécommunications. La partie INAP est un protocole de signalisation qui fait partie de la suite de protocoles SS7 et constitue généralement une couche située au-dessus de la partie TCAP. On peut considérer qu'il est logique de contrôler les services de télécommunications ayant migré de points de commutation traditionnels vers des plates-formes informatiques indépendantes des services.

La figure 11 est semblable aux figures 9 et 10 et illustre un ancrage effectué en utilisant des jonctions vocales ISUP classiques existantes. Un appel émanant de l'utilisateur fixe ou mobile 580 est ici connecté au réseau PSTN 555 et transite vers le module MSC/HLR 515. Depuis le module MSC/HLR 515, l'appel transite à travers la seconde passerelle MG 535, vers le cœur SIP 520. L'appel est renvoyé au module MSC/HLR 515 en raison du fait que le terminal bimode 575 n'est pas disponible sur un réseau IP, c'est-à-dire en Wi-Fi. L'appel est ancré par l'intermédiaire de deux trajets d'appels sur la jonction vocale et est connecté au réseau RAN mobile 560 et au terminal bimode 575 en GSM. Le trajet de l'appel est illustré par la ligne en trait discontinu. Une fois que le terminal bimode 575 devient disponible en Wi-Fi, le transfert du GSM au Wi-Fi est déclenché, sous réserve que les exigences de qualité minimale des appels soient satisfaites.

La figure 12 est semblable aux figures 9 et 10 et comprend des modules d'architecture IN 590, 595 respectivement associés aux modules MSC/HLR 515 et au cœur SIP 520. Une intégration IN est ici exigée entre les modules d'architecture IN 590 et 595, comme indiqué par une ligne en trait discontinu. Une signalisation INAP SS7 est assurée par l'intermédiaire de l'intégration IN. Lorsqu'un appel est émis depuis l'utilisateur fixe ou mobile 580, il est établi par l'intermédiaire d'une mise en œuvre ISUP et INAP SS7 et par l'intermédiaire d'une intégration IN, comme illustré par une ligne en pointillés. Étant donné que le terminal bimode 575 n'est pas connecté en Wi-Fi, la signalisation de l'appel est renvoyée au module MSC/HLR 515 et se connecte par l'intermédiaire du terminal bimode 575 de la manière déjà décrite ci-dessus en référence à la figure 11. Le trajet de l'appel est illustré par la ligne en trait mixte, comme précédemment.

Comme décrit ci-dessus, le contrôle VQC est utilisé pour déclencher un transfert entre un réseau IP et un réseau GSM ou autre réseau en fonction d'un niveau minimal de VCQ prédéterminé. Ce niveau minimal de VCQ peut être établi en utilisant des indicateurs de VCQ, comme décrit précédemment. Cependant, les indicateurs de VCQ peuvent également être établis conformément à des préférences de l'abonné (de l'utilisateur), par exemple le coût, une qualité VCQ acceptable inférieure au niveau recommandé, le type de terminal, le nombre de terminaux à la disposition de l'utilisateur, la position du terminal ou des terminaux et leur disponibilité.

Comme décrit ci-dessus, en tant que partie de l'architecture MMC, un module VQC est prévu à la fois sur la plateforme et sur le terminal multimode. Pour le transfert d'un appel vocal d'un réseau IP à un autre réseau, le module VQC faisant soit partie du terminal multimode, soit partie de la plateforme MMC, comme décrit précédemment, détermine si la qualité vocale de l'appel est inférieure à un niveau de qualité vocale de l'appel minimale prédéterminée exigé pour une connexion à un réseau IP. Dans certains cas, les deux modules VQC peuvent réaliser ensemble la détermination du fait que la qualité vocale de l'appel s'est abaissée en dessous d'un niveau de qualité vocale de l'appel minimale prédéterminée.

Ayant déterminé que le niveau de qualité vocale de l'appel était inférieur au minimum prédéterminé fixé conformément aux préférences de l'utilisateur et/ou du fournisseur du système, un transfert est déclenché par le module VCC se trouvant soit sur la plateforme, soit sur le terminal multimode. Dans certains cas, les deux modules VCC peuvent déclencher ensemble un transfert d'appel. Le gestionnaire d'appels de la plateforme établit un nouveau trajet d'appel tout en conservant le trajet d'appel existant. Un transfert est effectué lorsque le nouveau trajet d'appel a été établi, et l'ancien trajet d'appel est interrompu une fois que le transfert s'est achevé. Ce transfert est transparent vis-à-vis de l'utilisateur du terminal multimode.

Lorsqu'il est déterminé que le transfert d'un appel existant est nécessaire, le serveur, par exemple la plateforme MMC, contacte le client, par exemple le terminal multimode, pour l'informer du fait qu'un transfert est nécessaire. Le client répond qu'il est heureux d'effectuer le transfert sur la base de l'environnement proche, par exemple lorsque aucun autre réseau IP n'est disponible à proximité, auquel le client peut se connecter. Une fois que le serveur a reçu un accusé de réception du client, le gestionnaire d'appels reçoit l'instruction d'établir un nouveau trajet d'appels tout en conservant l'ancien trajet d'appel et d'effectuer un transfert une fois que le nouveau trajet d'appel a été établi, puis d'interrompre l'ancien trajet d'appel, comme décrit ci-dessus.

Il est à noter que la présente invention n'est pas limitée aux modes de réalisation particuliers décrits ci-dessus, mais qu'elle couvre de nombreuses variantes et/ou de nombreux ajouts.

Claims (22)

1. REVENDICATIONS

   1. Système de communication multimode (500) comprenant au moins un réseau à protocole internet (540, 545), au moins un réseau de télécommunications mobiles (560), une plateforme de télécommunications (505 ; 610) et au moins un terminal multimode (575 ; 650), lesdites deux plates-formes de télécommunications (505 ; 610) et ledit au moins un terminal multimode (575 ; 650) pouvant être connectés audit au moins un réseau à protocole internet (540, 545 ; 645) et audit réseau de télécommunications mobiles (560), ledit système comprenant : au moins un module de contrôle de continuité vocale (615, 660) destiné à assurer la continuité d'appel pour un appel mettant en jeu ledit au moins un terminal multimode (650) lorsqu'il est connecté audit au moins un réseau à protocole internet (540, 545 ; 645); caractérisé en ce que ledit système (500) comprend en outre au moins un module de contrôle de qualité vocale (620, 665) pour déterminer la qualité vocale de l'appel d'un appel mettant en jeu ledit au moins un terminal multimode (575 ; 650) lorsqu'il est connecté audit au moins un réseau à protocole internet (540, 545 ; 645); et en ce que ledit au moins un module de contrôle de continuité vocale (620, 665) a pour fonction de déclencher un transfert entre ledit au moins un réseau à protocole internet (550, 545 ; 645) et ledit au moins un réseau de télécommunications mobiles (560) en fonction d'un niveau de qualité vocale minimal prédéterminée déterminé par ledit au moins un module de contrôle de qualité vocale (620, 665).
2. 2. Système selon la revendication 1, comprenant en outre un gestionnaire d'appels (625) associé audit au moins un module de contrôle de continuité vocale (620, 665), ledit gestionnaire d'appels (625) ayant pour fonction de déclencher un transfert entre ledit au moins un réseau à protocole internet (550, 545 ; 645) et ledit au moins un réseau de télécommunications mobiles (560).
3. 3. Système selon la revendication 1 ou 2, dans lequel le transfert est déclenché en fonction de la disponibilité du réseau à protocole internet.
4. 4. Système selon l'une quelconque des revendications précédentes, dans lequel le transfert est déclenché en fonction de la disponibilité du réseau de télécommunications mobiles.
5. 5. Système selon l'une quelconque des revendications précédentes, comprenant en outre un module à protocole de commande de transport temps réel fournissant un protocole de commande de transport temps réel relatif au trafic vocal dudit appel, ledit niveau de qualité vocale minimale prédéterminée étant déterminé conformément audit protocole de transport temps réel.
6. 6. Système selon l'une quelconque des revendications précédentes, comprenant en outre un module analyseur de protocole temps réel fournissant des données de protocole temps réel relatives au trafic vocal dudit appel, ledit niveau de qualité vocale minimale prédéterminée étant déterminé conformément audit protocole transport temps réel.
7. 7. Système selon l'une quelconque des revendications précédentes, comprenant en outre une base de données (515) pour stocker des données relatives à au moins un utilisateur du système, ledit niveau de qualité vocale minimale prédéterminée étant déterminé conformément auxdites données d'utilisateurs.
8. 8. Système selon l'une quelconque des revendications précédentes, comprenant en outre un registre de localisation (515) destiné à stocker des données de terminaux relatives à des terminaux multimodes (575 ; 650) associés audit système (500), ladite qualité vocale minimale prédéterminée étant déterminée conformément auxdites données de terminaux.
9. 9. Système selon l'une quelconque des revendications précédentes, dans lequel ladite plateforme de télécommunications (610) comprend un premier module de contrôle de qualité vocale (620) et un premier module de contrôle de continuité vocale (615) et ledit terminal multimode (650) comprend un second module de contrôle de qualité vocale minimale (665) et un second module de contrôle de continuité vocale (660), ladite qualité vocale minimale prédéterminée d'un appel en cours étant déterminée par au moins l'un desdits premier et second modules de contrôle de qualité vocale (620, 665) et ledit transfert étant déclenché par au moins ledit premier module de contrôle de continuité vocale (615).
10. 10. Système selon la revendication 9, dans lequel ledit second module de contrôle de qualité vocale (665) comprend un gestionnaire de protocole internet destiné à détecter la disponibilité dudit au moins un réseau à protocole internet (540, 545 ; 645) et à déterminer si la qualité vocale respecte ladite qualité vocale minimale prédéterminée associée audit au moins un réseau à protocole internet (540, 545 ; 645).
11. 11. Terminal multimode (575; 650) destiné à être utilisé dans un système terminal multimode (500) selon l'une quelconque des revendications précédentes, ledit terminal multimode (575 ; 650) comprenant un module de contrôle de qualité vocale (665) comprenant un gestionnaire de protocole internet destiné à détecter la disponibilité dudit au moins un réseau à protocole internet (540, 545 ; 645) et à déterminer si la qualité vocale respecte ladite qualité vocale minimale prédéterminée associée audit au moins un réseau à protocole internet (540, 545 ; 645).
12. 12. Terminal multimode selon la revendication 10, dans lequel un transfert est déclenché en fonction de la disponibilité d'un réseau à protocole internet.
13. 13. Terminal multimode selon la revendication 10 ou 11, dans lequel un transfert est déclenché en fonction de la disponibilité d'un réseau de télécommunications mobiles.
14. 14. Terminal multimode selon l'une quelconque des revendications 10 à 12, comprenant en outre un module de contrôle de continuité vocale (660) destiné à déclencher un transfert entre ledit au moins un réseau à protocole internet (540, 545 ; 645) et ledit réseau de télécommunications mobiles (560) lorsque ladite qualité vocale s'abaisse en dessous de ladite qualité vocale minimale prédéterminée.
15. 15. Terminal multimode selon l'une quelconque des revendications 10 à 13, dans lequel ledit terminal multimode se connecte à un réseau à protocole internet (540, 545 ; 645) de préférence à un réseau de télécommunications mobiles (560).
16. 16. Terminal multimode selon l'une quelconque des revendications 10 à 14, comprenant en outre un module à protocole de commande de transport temps réel fournissant un protocole de commande de transport temps réel relatif au trafic dudit appel, ledit niveau de qualité vocale minimale prédéterminée étant déterminé conformément audit protocole de commande de transport temps réel.
17. 17. Terminal multimode selon l'une quelconque des revendications 10 à 15, comprenant en outre un module analyseur de protocole temps réel fournissant des données de protocole temps réel relatives au trafic vocal dudit appel, ledit niveau de qualité vocale minimale prédéterminée étant déterminé conformément audit protocole temps réel.
18. 18. Procédé d'exécution du transfert d'un appel vocal entre un réseau à protocole internet (540, 545 ; 645) et un réseau de télécommunications mobiles (560) dans un système terminal multimode (500), ledit système ayant au moins un réseau à protocole internet (540, 545 ; 645), au moins un réseau de télécommunications mobiles (560), une plateforme de télécommunications (505 ; 610) et au moins un terminal multimode (575 ; 650), ladite plateforme de télécommunications (505 ; 610) et ledit au moins un terminal multimode (575 ; 650) pouvant tous deux être connectés audit au moins un réseau à protocole internet (540, 545 ; 650) et audit au moins un réseau de télécommunications mobiles (560), ledit procédé comprenant les étapes consistant à : a) affecter un niveau de qualité vocale minimale prédéterminée à un appel vocal connecté audit au moins un réseau à protocole internet (540, 545 ; 645) ; b) déterminer une qualité vocale de l'appel pour ledit au moins un réseau à protocole internet (540, 545 ; 645) ; c) comparer ladite qualité vocale de l'appel déterminée audit niveau de qualité vocale minimale prédéterminée ; et d) déclencher un transfert dudit appel vocal entre ledit au moins un réseau à protocole internet (540, 545 ; 645) et ledit au moins un réseau de télécommunications mobiles (560) lorsque ladite qualité vocale de l'appel déterminée s'abaisse en dessous dudit niveau de qualité vocale minimale prédéterminée.
19. 19. Procédé selon la revendication 17, dans lequel l'étape d) comprend le déclenchement d'un transfert en fonction de la disponibilité d'un réseau à protocole internet.
20. 20. Procédé selon la revendication 17 ou 18, dans lequel l'étape d) comprend le déclenchement d'un transfert en fonction de la disponibilité d'un réseau de télécommunications mobiles.
21. 21. Procédé selon l'une quelconque des revendications 17 à 19, dans lequel l'étape a) consiste à affecter ledit niveau de qualité vocale minimale prédéterminée conformément à l'un : de données d'utilisateurs ; de données de terminaux multimodes ; du trafic vocal à protocole temps réel ; et d'informations de protocole de commande de transport temps réel.
22. 22. Procédé selon l'une quelconque des revendications 17 à 20, dans lequel l'étape a) comprend l'établissement d'un appel vocal par l'intermédiaire d'un réseau à protocole internet (540, 545 ; 645) de préférence à un réseau de télécommunications mobiles (560).