Procédé et serveur de notification d'un appel dans un réseau.

Arrière-plan de l'invention L'invention se situe dans le domaine des services de communication intégrés fixes mobiles.

Elle permet de notifier à un terminal mobile d'un utilisateur l'existence d'un appel en cours d'établissement sur un terminal fixe propre à ce même utilisateur. On connaît principalement deux méthodes pour notifier à un terminal mobile l'arrivée d'un appel sur un terminal fixe.

La première de ces méthodes utilise le protocole SMS (Short Message Service).

De façon connue, le SMS est un mécanisme "store and forward" permettant de stocker un message dans le réseau (en l'occurrence dans un SMSC (Short Message Service Center)) lorsque le destinataire n'est pas disponible.

Le protocole SMS est un protocole asynchrone, non prévu pour le temps réel, à la fois en raison de l'architecture du réseau et des clients SMS installés dans les terminaux.

En conséquence, la notification SMS précitée nécessite plusieurs secondes.

La deuxième méthode connue repose sur le protocole I M (I nstant Messaging) en mode session. Selon cette méthode, un serveur SI P (Session I nitiation

Protocol) associé à la logique de service établit une session d'I nstant Messaging avec le terminal mobile.

Une fois la session établie, il peut envoyer le message de notification au mobile en envoyant un message, en mode session. De façon connue, le mode d'I nstant Messaging en mode session nécessite d'établir au préalable une session, à la fois dans le plan de la signalisation SI P (échange de messages I NVI TE/ ACK/ 200 OK) et dans le plan média, par exemple au moyen du protocole MSRP.

En pratique, la notification selon le protocole SI P en mode session nécessite une quarantaine de messages. Elle est donc lente à

mettre en œuvre et monopolise une session en permanence dans le réseau et dans les terminaux.

Pour plus d'informations sur la complexité de la mise en œuvre de l'I nstant Messaging en mode session, l'homme du métier pourra se reporter à la spécification de référence 3GPP TS 24.227 au paragraphe A.4.2.1.

Objet et résumé de l'invention

Selon un premier aspect, l'invention concerne un procédé de transmission comportant :

- une étape de création d'un canal de signalisation permanent vers au moins un terminal mobile d'un utilisateur ;

- une étape de détection d'un appel en cours d'établissement vers un terminal fixe de cet utilisateur ; et - sur détection de cet appel, une étape d'envoi d'un message de notification dans le canal de signalisation en dehors d'un contexte de session.

Corrélativement, l'invention concerne un serveur comportant :

- des moyens de création d'un canal de signalisation permanent entre au moins un terminal mobile ;

- des moyens de détection d'un appel en cours d'établissement vers un terminal fixe de cet utilisateur ; et

- des moyens d'envoi d'un message de notification dans le canal de signalisation en dehors d'un contexte de session. Conformément à l'invention, on utilise un canal de signalisation permanent vers le terminal mobile, la notification d'un appel en cours d'établissement sur le terminal fixe se faisant par l'envoi d'un message dans ce canal de signalisation en dehors de tout contexte de session. Autrement dit, cette notification se fait en mode "pager". En conséquence, la notification se fait en quasi-temps réel sur le terminal mobile.

De façon avantageuse, le procédé de notification selon l'invention ne mobilise pas une session de service en permanence dans le réseau et dans les terminaux.

Dans un mode particulier de réalisation, le canal de signalisation permanent est établi entre le terminal mobile et un réseau I MS (I P Multimedia Subsystem).

Dans un mode particulier de réalisation de l'invention, le canal de signalisation précité est un canal de signalisation SI P, le lien d'utilisation permanent étant établi par un message SI P REGI STER.

Dans un mode particulier de réalisation de l'invention, le message de notification est un message SI P de type SI P MESSAGE.

Dans une variante de l'invention, le message de notification est un message SI P de type SI P NOTI FY. Dans ce cas, les terminaux mobiles souhaitant recevoir la notification doivent souscrire à l'application d'une notification par l'intermédiaire d'un message de type SI P SUBSCRI BE.

Dans un mode particulier de réalisation de l'invention, le procédé comporte une étape préliminaire de positionnement de critères de déclenchement permettant de superviser l'appel en cours d'établissement sur le terminal fixe.

Cette étape préliminaire permet avantageusement d'aiguiller la signalisation des messages arrivant sur le terminal fixe vers un serveur hébergeant la logique de service, ce serveur notifiant le terminal mobile. Dans un mode particulier de réalisation, les différentes étapes du procédé de transmission sont déterminées par des instructions de programmes d'ordinateurs.

En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un serveur ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de transmission tel que mentionné ci-dessus.

Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.

L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.

Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.

D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type I nternet.

Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.

Dans une variante de réalisation, on peut aussi dénotifier le terminal mobile, dans le canal de signalisation, et en dehors de tout contexte de session, pour lui indiquer que l'appel a été pris par le terminal fixe ou par un autre terminal mobile.

Brève description des dessins

D'autres caractéristiques et avantages de la présente invention ressorti ront de la description faite ci-dessous, en référence aux dessins et aux annexes qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :

- la figure 1 représente, dans son environnement, un serveur selon l'invention dans un mode particulier de réalisation de l'invention ;

- la figure 2 représente l'établissement des couches de signalisation dans un mode particulier de réalisation de l'invention ; - la figure 3 représente, sous forme d'organigramme, les principales étapes d'un procédé de transmission selon l'invention dans un mode particulier de réalisation ; et

- les figures 4A et 4B représentent des échanges de messages dans deux variantes de réalisation de l'invention. Les Annexes A et B donnent des exemples de messages de notification utilisés dans les deux variantes précitées de l'invention.

Description détaillée d'un mode de réalisation

La figu re 1 représente un serveur 10 conforme à l'invention dans son environnement. Ce serveur 10 comporte l'architecture matérielle d'un ordinateur conventionnel. I l comporte en particulier un processeur 11 , une mémoire morte de type ROM 12, une mémoire vive de type RAM 13 et des moyens de communication 14.

La mémoire morte de type 12 contient un programme d'ordinateur conforme à l'invention pour la mise en œuvre du procédé de transmission dont les principales étapes sont données à l'organigramme de la figure 3.

A la figure 1 , on a référencé 200 un réseau I MS.

Dans le mode de réalisation décrit ici, le serveur 10 est relié au réseau I MS 200 par une interface I SC (I P Multimedia Subsystem Service Control I nterface).

De façon connue, le réseau I MS 200 comporte principalement trois serveurs de contrôle de la signalisation SI P, à savoir :

- un serveur I -CSCF référencé 21 ; - un serveur P-CSCF référencé 24 ; et

- un serveur S-CSCF référencé 22.

Le réseau I MS 200 comporte également une entité HLR (Home Location Register) référencée 23.

Dans l'exemple de la figure 1 , on référencé respectivement 300 et 400 un réseau mobile et un réseau fixe.

De façon connue, l'interface entre chacun de ces réseaux mobile 300, fixe 400 et le réseau I MS 200 est de type Mw.

A la figure 1 , on a référencé 41 le terminal fixe d'un utilisateur "bob", connecté au réseau fixe 400 et 31 un terminal mobile de l'utilisateur "bob" connecté au réseau mobile 300.

On supposera

- que l'adresse SI P du terminal mobile 31 est bobjTToblJ ^β lMππsJLçQIIl ;

- que l'adresse SI P du terminal fixe 41 est bob fixed@ims.ft.com; et

- que l'adresse SI P du serveur 10 selon l'invention est serveur10@ims.ft..com

Dans l'exemple de réalisation décrit ici, le serveur 10 est apte à accéder à une base de données 15 qui associe les adresses du terminal fixe 41 et du terminal mobile 31 de l'utilisateur bob.

En référence à la figu re 2, nous allons maintenant décrire l'établissement des couches de signalisation en dessous du protocole SI P dans cet exemple de réalisation.

Lorsque le terminal mobile 31 est allumé et dans un état de repos, il doit, pour se connecter à I ¹ I MS, établir un "PDP context" pour la signalisation SI P.

Afin d'établir ce PDP context, il doit au préalable effectuer une connexion au réseau mobile 300.

Dans l'exemple décrit ici, on supposera que le réseau mobile 300 est conforme à la norme UMTS, et on référence respectivement 310 et 320 le réseau d'accès UTRAN et le réseau cœur.

Dans cet exemple de réalisation, le terminal mobile 31 effectue une connexion RRC (Radio Resource Control Protocol), référencée C1 , selon la norme 3GPP TS 25.331 paragraphe 8.1.3. Pour ce faire, le mobile 31 envoie un message "RRC Connection

Request" au composant RNC et reçoit en retour un message "RRC Connection Setup".

Le mobile passe alors dans l'état "CELL_DCH" et émet, vers l'entité RNC, un message RRC Connection Complète. Une fois la connexion RRC établie, le terminal mobile 31 initialise une procédure d'attachement GPRS référencée C2, dite "GPRS Attached Procédure", conforme à la norme 3GPP TS 23.060 paragraphe 6.5 afin d'accéder au service et au réseau GPRS.

Pour ce faire, le terminal mobile envoie un message "GMM Attached Request" vers le réseau paquet cœur 320 de l'UMTS 300, en l'occurrence vers l'entité SGSCN, et reçoit en retour le message "GMM Attached Accept".

Le mobile 31 envoie alors le message "GMM Attached Complète" terminant ainsi la procédure d'attachement au GPRS.

Ensuite, le terminal 31 active un PDP context selon la norme 3GPP TS 23.060 paragraphe 9.2 afin de pouvoir véhiculer la signalisation SI P.

L'activation du PDP context est symbolisée par la référence C3 de la figure 2.

Pour ce faire, le terminal mobile envoie un message "Activate

PDP Context Request" vers l'entité GGSN (via le SGSN) du réseau paquet cœur 320, en demandant dans le paramètre "Requested QOS" une qualité de service pour la signalisation "Signaling I ndication" conformément à la norme 3GPP TS 23.207.

Le terminal mobile 31 reçoit ainsi, dans le réseau radio et le réseau paquet, un traitement préférentiel permettant de garantir un temps de transfert minimum.

Le terminal mobile reçoit en retour le message "Activate PDP Context Accept".

Le terminal mobile 31 est alors dans un état "GPRS Attached Always On" ainsi qu'en mode "PDP context Always On".

Le lien de signalisation permanent établi entre le terminal mobile 10 et le réseau I MS est référencé 100 à la figure 1. Le mode "I MS Registration Performed" est effectué par l'envoi d'un message SI P Register par le terminal 31 vers l'I MS 200, représenté de façon symbolique par la double flèche référencée C4.

En référence à la figu re 3, nous allons maintenant décrire les principales étapes du procédé de transmission selon l'invention mis en œuvre par le serveur 10.

Au cours d'une étape préliminaire E10, le serveur 22 positionne, dans le réseau I MS 200, des critères de déclenchement permettant de superviser les appels à destination du terminal fixe 41.

Ces critères de déclenchement sont définis dans la spécification 3GPP TS 23.228.

Ce positionnement a pour conséquence que les messages SI P I NVITE générés dans le cas d'un appel au terminal fixe 41 provoquent un déclenchement, ces messages SI P I NVITE étant remontés par le serveur 22 au niveau du serveur 10 conforme à l'invention. L'étape E10 de positionnement est suivie par l'étape E20 de création du canal permanent 100 déjà décrite.

On supposera qu'au cours d'une étape Eξ30, le serveur 10 détecte un message SI P I NVITE sur l'interface I SC.

Consécutivement à cette détection, le serveur 10 interroge, au cours d'une étape E40, la base de données 15 qui contient la liste des terminaux mobiles 31 associés au terminal fixe 41.

La base de données 15 peut notamment être de type LDAP et interrogée selon les procédés connus de l'homme du métier.

L'application obtient, de la base de données 15, la liste des numéros téléphoniques mobiles associés à la ligne fixe et qu'il convient de notifier.

Dans l'exemple de réalisation décrit ici, le procédé de transmission selon l'invention comporte une étape E50 au cours de laquelle le serveur 10 détermine si une temporisation doit être respectée avant la notification. Si tel est le cas, cette temporisation est effectuée au cours d'une étape E60.

La notification proprement dite est effectuée au cours d'une étape E70 par l'envoi d'un message de notification dans le canal de signalisation 100 établi à l'étape E20. Nous allons maintenant décrire, en référence aux f igu res 4A et

4 B, des échanges de messages conformes à deux variantes de réalisation de l'invention.

A la figure 1 , on représente tout d'abord, dans la partie droite de la figure, l'établissement du canal SI P permanent qui se fait par l'envoi d'un message d'enregistrement REGI STER du terminal mobile 31 vers l'entité S-CSCF 22 de ce terminal mobile, ce message d'enregistrement étant relayé par cette entité 22 vers le serveur 10 conforme à l'invention.

De façon connue, ces messages sont acquittés par des messages de type 200 OK. Une fois le canal 100 de signalisation SI P établi, on considère qu'un terminal appelant 50 émet un appel 51 vers son réseau 500, cet appel 51 étant relayé par une passerelle 510 adaptée à générer un message SI P I NVI TE vers l'entité S-CSCF 22 du terminal fixe 41.

Sur réception de ce message I NVITE, l'entité S-CSCF 22 du terminal fixe 41 relaie le message I NVITE à destination du serveur 10.

Ce message I NVITE est reçu et détecté par le serveur 10 au cours de l'étape E30 du procédé de notification déjà décrit.

Dans l'exemple décrit ici, le serveur 10 relaie ce message I NVI TE vers le client fixe 41 , afin de le faire sonner. Puis, au cours de l'étape E70 de notification, le serveur 10 selon l'invention envoie le message SI P Message à destination de l'entité 22 S- CSCF du terminal mobile 31 , ce message étant relayé par l'entité 22 à destination du terminal mobile 31 ainsi notifié.

Ces messages SI P Message sont acquittés par des messages de type 200 OK.

Le message de notification SI P dans cette première variante de réalisation est donné à titre d'exemple à l'Annexe A.

La f igu re 4 B représente l'échange de messages dans une deuxième variante de réalisation de l'invention. Dans cette variante de réalisation, on utilise le message SI P

NOTI FY pour notifier le terminal mobile 31.

L'enregistrement préalable du mobile 31 (message SI P REGI STER) est encore nécessaire.

Le message SI P SUBSCRI BE contient alors le paramètre "Event" permettant, conformément au RFC 3265, de préciser qu'il s'agit d'une souscription à l'application selon l'invention. La méthode SUBSCRI BE contient également l'adresse SI P du serveur d'application

(serveur10@ims.ft.com).

Dans cette deuxième variante de réalisation, il n'est plus nécessaire de consulter la base de données 15 pour connaître la liste des terminaux mobiles à notifier, ceux-ci étant connus grâce à la souscription précitée.

Tout comme dans la variante précédente, un appel entrant sur le terminal fixe 41 est relayé par l'I MS 200 vers le serveur d'application 10 selon l'invention (message SI P I NVITE), les critères de déclenchement adéquats ayant été positionnés.

Le serveur d'application 10 selon l'invention fait sonner le terminal fixe 41 et notifie, par le message SI P NOTI FY, les mobiles 31 qui se sont au préalable enregistrés. Ce message NOTI FY est donné à titre d'exemple à l'Annexe B.

I I contient la référence de l'application, le numéro du terminal fixe appelé ainsi que le numéro de l'appelant 50.

Dans la description précédente, seul un terminal mobile 31 de l'utilisateur Bob a été notifié. En variante, plusieurs terminaux mobiles peuvent être notifiés.

ANNEXE A

MESSAGE sip:bob_mobile1@ims.ft.com SI P/2.0 From: sip: serveur10@ims.ft.com To: sip:bob_mobile1@ims.ft.com CaII-I D: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 100

ANNEXE B

MESSAGE sip:bob_mobile1@ims.ft.com SI P/2.0

To: < sip:bob_mobile1@ims.ft.com> ;tag= 78923

From: < sip:serveur10@ims.ft.com> ;tag=4442 CaII-Id: 1349882@1.2.3.4

CSeq: 20 NOTI FY

Contact: < sip:bob@serveur10.com>

Event: notification-immédiate-convergente

Subscription-State: active

Content-Type: application/notification-immédiate-convergente

Content-Length: 100

Appel-fixe: yes

Rxed-Phone- Account :sip:bob_f ixed@ims.ft.com

Caller-I D: 0296123456