FR2970137A1 - Gestion des equipements utilisateurs ayant la meme identite publique par un serveur d'application dans un reseau ims - Google Patents

Abstract

Ce serveur d'application comporte : - des moyens d'obtention aptes à obtenir (E20) des informations (INF1) sur au moins un premier équipement utilisateur (UE1) comportant une identité publique (IMPU) donnée, consécutivement à l'enregistrement (E10) ou au désenregistrement de ce premier équipement utilisateur (UE1) en cœur de réseau IMS ; et - des moyens d'envoi aptes à envoyer à au moins un autre équipement utilisateur (UE2) enregistré en cœur de réseau IMS avec la même identité publique (IMPU), des données (D1) comportant au moins une partie de ces informations (INF1) et une indication (IE1) sur un état (E1) du premier équipement utilisateur (UE1) dans le réseau.

Description

Arrière-plan de l'invention

L'invention se situe dans le domaine des réseaux de télécommunication de type IMSDPMultimedia Subsystem) tel que défini parks3GPP(ThindGenenation Partnership Project). 10 L'un des objectifs de l'IMS est de permettre à un utilisateur d'accéder à différents services quel que soit son type de connectivité IP. Les réseaux IMS, initialement conçus pour les réseaux mobiles, tendent à se développer sur des réseaux d'accès fixes de type ADSL (Asymmetric Digital Subscriber Line), ou FTTH (Fiber To The Home), ou sur des réseaux câblés notamment» 15 Les architectures IMS pour les réseaux fixes ont en particulier été déployées pour la commercialisation d'offres dites « Mu!bp!ay» permettant à un utilisateur d'dc[éderà différents services du réseau IMS, et notamment à des services d'accès au réseau Internet, de voix sur IP (VoIP) et de télévision sur internet (IPTV), via une passerelle domestique. 20 Afin de diversifier leur offre, les opérateurs de télécommunication proposent des terminaux complémentaires aux téléphones fixes, ces terminaux complémentaires étant équipés d'un !ogiciel de voix sur IP (VoIP) utilisant le même identifiant public IMPU que celui de la passerelle domestique et un identifiant privé IMPI pouvant être ou non le même que celui de la passerelle domestique» 25 L'invention propose une solution pour enrichir les possibilités d'usage des différents terminaux partageant la même identité publique IMPU.

Objet et résumé de l'invention

30 Plus précisément, et selon un premier aspect, l'invention concerne un serveur d'application dans un /,»seoo IMS, ce serveur comportant: ae` moyens cb!~Lcn{ion aptes à r-tenir des info-mittons au moins .uuort ou a ! 'onu MS; et 35 2 - desmoyænsd'envnapLesà envoyer à au moins un autre équipement utilisateur enregistré en coeur de réseau IMS avec la même identité publique, des données comportant au moins une partie de ces informations et une indication sur un état du premier équipement utilisateur dans le réseau. ~ Corrélativement, l'invention vise aussi un procédé de gestion de terminaux mis en oeuvre par un serveur d'application dans un réseau IMS, ce procédé comportant: - une étape d'obtention d'informations sur au moins un premier équipement utilisateur comportant une identité publique donnée, consécutivement à l'enregistrement ou au désenregistrement du premier équipement utilisateur en coeur de réseau IMS; et 10 - une étape d'envoi, à au moins un autre équipement utilisateur enregistré en coeur de réseau IMS ayant la même identité publique, de données comportant au moins une partie desdites informations et une indication sur un état du premier équipement utilisateur dans le réseau. D'une façon générale, l'invention concerne ainsi un serveur d'application apte à 15 informer des équipements utilisateurs de la présence et de l'état des autres équipements utilisateurs ayant la même identité publique IMPU. Selon un deuxième aspect, l'invention vise aussi un équipement utilisateur comportant des moyens pour s'enregistrer en coeur de réseau IMS avec une identité publique, cet équipement comportant : 20 - des moyens de réception de données émises par un serveur d'application du réseau, ces données comportant des informations sur au moins un autre équipement utilisateur ayant la même identité publique et une indication sur un état de cet autre équipement utilisateur dans le réseau ; et - des moyens de traitement de ces données en vue de leur restitution par une 25 interface homme-machine d'un terminal utilisateur. Corrélativement, l'invention vise aussi un procédé de traitement de données mis en oeuvre par un équipement utilisateur enregistré en coeur de réseau IMS avec une identité publique, ce procédé comportant : - une étape de réception de ces données, celles-ci ayant été émises par un 30 serveur d'application du réseau, ces donn.' comportant au moins des informations sur un autre rient utiii5amL.r a/ant la pi m1i:mutité publique et une indication sur un état de [eLæ,'^` 'uipemeM utilisateur dans le ; et - une Lori nt de cm cbr n vue de leu! iimtimn par une i:~c.[src hommc .~~ dx~ ~unn.r nc /us~luL / ~

Dans un mode particulier de réalisation, l'état d'un premier équipement utilisateur communiqué par le serveur d'application selon l'invention à un deuxième équipement utilisateur comporte au moins une indication parmi: - une indication de présence du premier équipement utilisateur ~ - la date et/ou l'heure dudit enregistrement ou dudit désenrcgistrement; - une localisation géographique du premier équipement utilisateur; et - un état d'occupation du premier équipement utilisateur. Dans un mode particulier de réalisation, les données reçues par un équipement utilisateur comportent le nombre de sessions en cours initiées par l'ensemble des 10 équipements utilisateurs ayant l'identité publique et le nombre maximum autorisé de ces sessions. L'invention permet ainsi à un équipement utilisateur de déterminer si les autres équipements utilisateurs ayant la même identité publique IMPU que la sienne sont enregistrés ou non en coeur de réseau et si ces équipements sont en situation de 15 nomadisme ou non. L'utilisateur d'un herminal peut ainsi décider de ne pas répondre à un appel entrant s'il est informé qu'un autre utilisateur possédant un autre barminal enregistré en coeur de réseau IMS est susceptible de prendre l'appel. Dans ce mode de réalisation, la restitution de ces données peut par exemple être 20 une sonnerie stridente ou insistante si l'équipement utilisateur est le seul terminal enregistré en coeur de réseau et par conséquent le seul à pouvant prendre un appel entrant. L'invention permet aussi à un utilisateur d'éviter d'initier un appel sortant voué à l'échec lorsque le nombre maximum de session pour cette identité publique a été atteint. 25 On rappelle en effet que chaque terminal SIP est indépendant dans un réseau IMS et qu'il n'existe pas, dans l'état actuel de la technique, de mécanisme permettant au coeur de réseau d'informer tous les équipements utilisateurs ayant une identité IMPU donnée que tous les canaux sont utilisés pour cette identité publique. D'un point de vue de l'usage, lorsque tous les canaux sont occupés pour une identité publique IMPU, la 30 demande d'appel en excès est routée en coeur de réseau IMS, et le réseau génère un code de réponse SIP 403 Forbidden, traduit en signal d'occupation ou en message à l'utilisateur. Dans un mode parLicu[ed~ r'Jsct~ /, ! -d'~~p!~obon *]O0 l'invention i1- Ir t moins un des 35 Ler, ~ SIP y~ogi~ix~~ iWiqde IMPU 4

concernée, les données précitées étant envoyées à tous les autres terminaux consécutivement à cette détection. Chaque équipement utilisateur est ainsi informé en temps réel et de façon dynamique des événements (enregistrement, désenregistrement, occupation, passage en ~ mode nomadisme, sortie du mode nomadisme, ...) affectant les autres équipements utilisateurs qui partagent son identité publique IMPU. Les informations obtenues par le serveur d'application selon l'invention consécubvennenLà l'enregistrement ou au désenregistrement d'un équipement utilisateur en coeur de réseau IMS peuvent notamment comprendre au moins une information 10 parmi : - ildenLKé publique IMPU de cet équipement utilisateur ; - une adresse de joignabilité de cet équipement utilisateur comprenant par exemple son adresse IP, un numéro de port et, un protocole de transport (UDP, T[P,TL5,...); 15 -un paramètre de priorité q de cet équipement utilisateur conforme à la norme RFC3261; et - un identifiant SIP décrivant le type et éventuellement un contexte d'utilisation de cet équipement utilisateur. On rappelle que le paramètre q peut prendre une valeur réelle entre 0 (priorité 20 minimale) et 1 (priorité maximale) ; les terminaux ayant la même priorité q sonnent de manière simultanée sur un appel entrant. Les terminaux ayant une valeur q différente sonnent de manière séquentielle selon l'ordre de cette priorité. Lorsque le paramètre q n'est pas défini, le coeur de réseau considère qu'il s'agit d'une priorité minimale. Dans un mode particulier de réalisation, le serveur d'application selon l'invention 25 comporte des moyens pour enregistrer une souscription du premier équipement utilisateur et une souscription de l'autre équipement utilisateur à un service de notification. Dans ce mode de réalisation : - les moyens d'obtention du serveur d'application sont aptes à recevoir les infurmaUono précitées dans un message SIP de publication émis par le premier 30 équipennentuLi~!sa~cur ; et - les mocîis de communication sont aptes à communiquer ces données dans un message SIP de notification envdyé à l'autre équipement uti1isd.teur. ec des données sur 35 Dans un mode particulier de réalisation, les moyens d'obtention du serveur d'application selon l'invention reçoivent les informations sur les équipements utilisateur directement de ces équipements, par exemple dans un message de iypeSIP PUBLISH. Dans un autre mode particulier de réalisation, les moyens d'obtention du serveur d'application selon l'invention reçoivent les informations sur les équipements utilisateur dans un message SIP reçu d'un serveur S-CSCF du réseau. Ce message SIP peut par exemple être un message qui encapsule les requêtes d'enregistrement envoyées par le premier équipement utilisateur au serveur S-CSCF, conformément au mécanisme Third Party Registration.

Ce mécanisme est plus fiable que le mécanisme de publication mentionné précédemment. Dans un mode particulier de réalisation, l'équipement utilisateur est un terminal SIP, ses moyens de traitement étant aptes à restituer les données sur une interface homme-machine de ce terminal.

L'équipement utilisateur selon l'invention peut être constitué par une passerelle domestique. Les moyens de traitement de cette passerelle peuvent être conçus pour convertir les données reçues du server d'application selon un protocole de signalisation téléphonique eLà transmettre les données ainsi converties à un terminal connecté à la passerelle en vue de leur restitution sur une interface homme machine de ce terminal.

Ce protocole de signalisation téléphonique peut par exemple être le protocole V23. Ce mode de réalisation permet avantageusement de remonter les données sur des terminaux non SIP et en particulier sur des téléphones analogiques ou DECT. Par conséquent, l'invention vise aussi un terminal connecté à une passerelle domestique et comportant : - des moyens pour recevoir de cette passerelle, selon un protocole de signalisation téléphonique, des données comportant des informations sur au moins un autre équipement utilisateur ayant la même identité publique que la passerelle et une indication sur un état de cet autre équipement utilisateur dans le réseau ; et des moyens de restitution de ces données sur une interface homme-machine du terminal. Corrélativement, l'invention vise aussi un procédé d'alerte mis en oeuvre par un terminal connecté à une passerelle domestique, ce procédé comportant : - une o'ne de repUon. cn prOvernxee de Ceiic ;assava!~o, nelon un p!okzcoüe oisnUon dasdom~`~u7 rsnror d ~ ~ ~n!o.mo~ions sur mnixs un axi~c em/ipun.x! o~i!ie{ux avnn~ b o'~m~ ~dr/t '!inu~ nop !a c.~n `/\` ~~ n 6 - une étape de restitution de ces données sur une interface homme machine du terminal. Le serveur d'application selon l'invention peut éventuellement mettre en oeuvre les fonctions d'un serveur d'application de type Originating ou de type Terminating. ~ Dans un mode particulier de réalisation, les différentes étapes des procédés de gestion de terminaux, de traitement de données et d'alerte 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 oeuvre par un 10 ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé 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 15 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 20 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 disc) 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 25 optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particu!ierté!échangé sur un réseau de type Internet. 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. 30 Brève description des dessins D'autres c présente invention x u~ u~f'e/ 35 '^cn;~cdc r~a[~yi!n'/ d:~ovvu de Lo:icamc~,'" !imi\ai'i Sui~, 1 Ien~~ : 7 - la figure 1 représente de façon schématique des équipements conformes à l'invention, dans leur environnement - les figures 2A, 2B et 2C représentent schématiquement l'architecture matérielle d'un serveur d'application, d'un équipement utilisateur et d'un terminal selon

- les figures 3 et 4 représentent un premier mode de réalisation de l'invention ; et - la figure 5 représente représente un deuxième mode de réalisation de l'invention.

10 Description détaillée de l'invention

La figure 1 illustre un réseau dans lequel l'invention peut être utilisée. Sur cette figure, on a représenté une passerelle domestique HGW offrant un service de voix sur IP à partir d'un téléphone domestique TEL, constitué dans cet 15 exemple par un téléphone conforme à la norme V23. La passerelle domestique HGW se connecte via un réseau d'accès RA, par exemple de type ADSL, au travers d'un premier équipement réseau de type DSLAM, celui-ci étant lui-même connecté à un réseau de collecte R[, par exemple de type ATM ou Giga Ethernet ce qui lui permet d'atteindre un réseau opérateur RO à travers un 20 premier routeur R1. Le réseau opérateur RO, de type bæckbnneIP permet d'atteindre, au travers un deuxième routeur R2, le point d'entrée du réseau IMS. De façon connue, le point d'entrée d'un réseau IMS est une entité dite « de bordure », référencée EB sur la figure 1, celle-ci pouvant être constituée par : 25 un équipement SBC (Session BorderContnn!!er) ; - un serveur P-CSCF ; - un équipement remplissant à la fois les fonctions d'un équipement SEC et celles d'un serveur P-CSCF. Le réseau IMS comporte notamment les entités fonctionnelles P-CSCF, I-CSCF, S-30 CSCF, SLF, H5S, et DNS ENUM connues de l'homme du métier% Dans l'exemple décrit ici le réseau IMS est interconnecté à un serveur d'app!irot/on ASConformeà l'invention auprès duquel les terminaux SIP en coe' peuvent souscrire pour accéder à un service de nnt fir-en selon !lnvenJ 8 Dans l'exemple de la figure 1, un premier terminal mobile secondaire SJPde voix sur IP (softphone VoIP) UE1 est connecté à la passerelle domestique HGW par une liaison sans fil WiFi et utilise la même identité publique IMPU que la passerelle HGW. La passerelle HGW se comporte en modem routeur pour le terminal SIP UE1. ~ Dans l'exemple décrit ici, un terminal SIP mobile UE 2 est connecté en WiFi à un hot spot HS connecté au réseau de l'opérateur. En référence à la figure 2A, on a représenté l'architecture matérielle d'un serveur d'application AS conforme à un mode de réalisation de l'invention. Dans le mode de réalisation décrit ici, ce serveur AS a l'architecture matérielle 10 d'un ordinateur. Il comporte notamment un processeur 11, une mémoire vive de type RAM 12, une mémoire morte de type ROM 13, des moyens de communication 14, et une pile SIP 15. La mémoire morte de type ROM 13 constitue un support d'enregistrement conforme à l'invention. Ce support d'enregistrement est lisible par le processeur 11 et il 15 mémorise un programme d'ordinateur PGAS comprenant des instructions pour mettre en oeuvre un procédé de gestion de terminaux et dont les principales étapes sont représentées sous forme d'organigramme dans deux modes de réalisation aux figures 3 à 5. En référence à la figure 2B, on a représenté l'architecture matérielle d'un 20 équipement utilisateur UE conforme à un mode de réalisation de l'invention. Dans le mode de réalisation décrit ici, cet équipement a l'architecture matérielle d'un ordinateur. Il comporte notamment un processeur 11, une mémoire vive de type RAM 12, une mémoire morte de type ROM 13, des moyens de communication 14, des moyens d'affichage 16, et une pile SIP 15. Il comporte également des moyens 17 de 25 communication conformes au protocole V23. La mémoire morte de type ROM 13 constitue un support d'enregistrement conforme à l'invention. Ce support d'enregistrement est lisible par le processeur 11 et il mémorise un programme d'ordinateur PGUE comprenant des instructions pour mettre en oeuvre un procédé de traitement de données et dont les principales étapes sont 30 représentées sous forme d'orgænig/o:nxe dans deux modes de réo!isotio/i aux figures 3 à S. En référence à la figure 2C, terminal TEL no cno: un n 'architecture matérielle d'un [x`venon. mæ n~~mo.u' v ,omn)Unicuuon 35 9 moyens d'affichage 16. Il comporte également des moyens 17 de communication conformes au protocole V23. La mémoire morte de type ROM 13 constitue un support d'enregistrement conformeb l'invention. Ce support d'enregistrement est lisible par le processeur 11 et il 5 mémorise un programme d'ordinateur PGTEL comprenant des instructions pour mettre en oeuvre un procédé d'alerte dont les principales étapes sont représentées sous forme d'organigramme dans deux modes de réalisation aux figures 3 à 5. La figure 3 représente une procédure d'enregistrement des équipements utilisateurs HGW, UE1 eiUE2 décrits précédemment en référence à la figure 1. IO Au cours d'une étape générale E10, après le démarrage de la passerelle HGW, cette passerelle domestique effectue un enregistrement initial en coeur de réseau IMS auprès du serveur S-CSCF. Cette procédure est connue de l'homme du métier. Elle comprend notamment l'envoi d'une première requête d'enregistrement SIP REGISTER sans matériel d'authentification, à laquelle le serveur S-CSCF répond par une réponse 401 15 Nonce. La passerelle HGW émet ensuite un deuxième message SIP REGISTER comportant le matériel d'authentification, par exemple selon le protocole MD5 HTTP Digest. On suppose que le de coeur de réseau IMS accepte l'enregistrement pour une durée de 3600 secondes. Cette deuxième requête d'enregistrement comporte des informations INFl sur la 20 passerelle HGW, à savoir, dans cet exemple : - son identité publique IMPU, autrement connue sous l'acronyme A0R (address of record) ; - son adresse de joignabilité, constituée par son adresse IP, un numéro de port et, un protocole de transport (UDP,T[P,TLS,...) ; 25 -un paramètre de priorité qconforme à la norme RFC3261, de priorité maximale égale à 1; et - un identifiant SIP décrivant le type et éventuellement le contexte d'utilisation de la passerelle HGW. Dans ce mode de /énlisa!ion, lorsque l'enregistrement de la passerelle HGW est 30 accepté en coeur de réseau, !eserveur S-05CFencapsu!e la requête d'enregistrement SIP et la relaye, au cours d'une étape E20, vers le serveur d'application AS conformément au mécanisnneThivd Party negistration. Sen/£xr daN~!ico;~oo AS ~ in6i ou cOurs da E2O les u/ ~n puss,r~K~ ! au Sen/k, Uc noüV!, on au cours d'une ~iq~~ L-D (~~rsouci 35 10 simplification, le passage par le S-CSCF de ces échanges n'est pas représenté), par l'envoi d'un message SIP 5U8S[RlBEte! que défini dans le document RFC3265. Dans le mode de réalisation décrit ici, ce service est associé à un nouvel événement Event Package, permettant à tout équipement ayant souscrit à ce service de recevoir des 5 informations concernant les autres équipements utilisateur partageant son identité publique IMM.). On suppose que le serveur d'application AS enregistre la souscription de la passerelle HGW eLy répond favorablement par l'envoi d'une réponse 200 DK. Il fournit en paramètre de cette réponse un paramètre EXPIRES de durée de renouvellement, égal 10 dans cet exemple à 24H, ce paramètre devant être pris en compte comme de façon connue pour émettre des requêtes subséquentes de souscription au service selon l'invention. Puis, le serveur d'application AS envoie immédiatement, au cours d'une étape E40, un message SIP de notification de type NOTIFY comportant des données Dl au 15 sens de l'invention, pour informer la passerelle qu'il n'y a pas d'autre équipement utilisateur enregistré en coeur de réseau IMS avec la même identité publique IMPU. Dans le mode de réalisation décrit ici, les données Dl sont converties et transmises au téléphone TEL via le protocole V23 au cours d'une étape E50. Les données converties DC1 sont restituées sur l'interface homme-machine du 20 téléphone TEL au cours d'une étape E60. On suppose maintenant que le softphone PC UE1 s'enregistre de façon initiale en coeur de réseau IMS (étape E1O), la requête SIP d'enregistrement étant relayée au serveur d'application AS (étape E20) selon le mécanisme Third Party Registration, comme décrit précédemment pour la passerelle HGW. 25 Le serveur d'application envoie immédiatement un message SIP NOTIFY de notification à destination de la passerelle domestique HGW pour l'informer de la présence du softphone PC UE18t pour lui communiquer les données Dl de ce softphone obtenues à partir des informations INF1 contenues dans la requête d'enregistrement émise par le softphone, encapsulée et relayée au serveur d'application AS comme décrit 30 pnécédann`ent. Dans l'exemple décrit ici, ces données Dl comportent - une indication de présencadoSoftphor - ^/E1 ;

ukph (/na/ol\ ; et w! xr LVo _ ~o(Lp!m//~ |.oS8ncommunication. 35 11 Ces données Dl sont converties par la passerelle HGVV et transmises au téléphone TEL (étape E50) pour restitution sur l'interface homme-machine de ce terminal. On suppose que le softphone PC UE1 souscrit au service de notification selon ~ l'invention (étape E30), cette souscription étant acceptée par le serveur d'application AS et acquittée positivement par l'envoi d'une réponse 200 0K. Le serveur d'application AS notifie (étape E40) instantanément le softphone PC et lui communique les données Dl sur cette passerelle HGVY. Dans l'exemple décrit ici, ces données Dl comportent une indication de présence de la passerelle GW, la date et 10 l'heure d'enregistrement de la passerelle HGW, la priorité q de cette passerelle, la localisation géographique de la passerelle HGW (maison); et une indication selon laquelle la passerelle HGW n'est pas en communication. On suppose que le terminal mobile UE2 est démarré et qu'il s'enregistre en coeur de réseau (étape E10) à travers le hotspot H8, les informations INF1 sur ce terminal 15 étant relayées (étape E20) au serveur AS par le mécanisme Third Party Registration. Les deux autres équipements utilisateur partageant la même identité publique IMPU et ayant souscrit au service de notification selon l'invention (passerelle HGVV; softphone PC UE1) sont instantanément notifiés (étapes E40) de l'enregistrement du terminal mobile UE2- Dans l'exemple de réalisation décrit ici, les messages de notification 20 comportent des données DI selon laquelle le terminal mobile UE2 est nomade, en plus des autres informations décrites précédemment. Ces données sont restituées (étape E60) directement en ce qui concerne le softphone PC UE1 et après conversion (étape E50) au protocole V23 pour le téléphone TEL connecté derrière la passerelle HGW. On suppose que le téléphone mobile souscrit au service de notification selon 25 l'invention (étape E30) et qu'il est notifié (étape E40) des données DI relatives à la passerelle HGW et au softphone PC UE1. Ces données sur restituées sur l'interface homme-machine du terminal mobile UE2 au cours d'une étape E60. Ces données permettent notamment à l'utilisateur du h2rminal mobile UEZen situation de nomadisme de connaître l'état de présence et d'occupation du softphone PC UE1 et de la passerelle 30 HGW. Sur la figure 3, on a représenté des étapes Ell d'enregistrements subséquents demandés, dans cet ordre, par le softphone PC UE1,herm/n!mobile UE2 et la pas, c[elle HGVV. Chacune dc ces demandes dene-:is!/ex/o/~~ es~ 'r|ay~e vers i~ scrv._ur d'application i 20) selon le mécan 'Ihlrd Pat!, Ir n. 12 Dans le mode de réalisation décrit ici, le serveur d'application AS ne notifie pas les équipements utilisateurs UE1, UE2, HGW de ces demandes subséquentes puisqu'elles ne sont pas représentatives d'un changement de présence ou d'occupation. On suppose que le terminal UE2 demande explicitement à ne plus souscrire au 5 service de notification selon l'invention au cours d'une étape E70, puis qu'il se désenregistre (étape E80) du coeur de réseau IMS par l'envoi d'une requête SIP REGISTER dans laquelle le paramètre EXPIRES est mis à zéro. Cette requête est relayée au cours d'une étape E20 vers le serveur d'application AS qui est ainsi informé de ce désenregistrement. 10 Les deux autres équipements utilisateur partageant la même identité publique IMPU et pour lesquels la souscription au service de notification selon l'invention (passerelle HGVV; softphone PC UE1) est toujours active sont instantanément notifiés (étapes E40) du désennegistvementdu terminal mobile UE2. Un indicateur représentatif de ce déscnregsihsmantesi restitué (étape E60) par 15 le softphone PC UE1. L'indicateur est converti par la passerelle HGW au format V23 (étape E50) et restitué par le téléphone TEL connecté derrière la passerelle HGW (étape

On suppose que la passerelle HGW et que le softphone PC UE1 renouvellent leurs souscriptions auprès du serveur AS par l'envoi de requêtes SIP SUBSCRIBE de 20 souscription subséquentes au cours d'étapes E31 et que ces demandes sont acceptées et acquittées positivement. Dans le mode de réalisation décrit ici, le serveur AS répond à ces demandes de souscription subséquentes par l'envoi de messages de notification (étapes E40) comportant les données no!ativeSà tous les équipements utilisateurs partageant l'identité 25 publique IMPU, et ces données sont restituées (étapes E60) sur l'écran des terminaux UE2, TEL. En référence à la figure 4, on suppose que le softphone PC UE1 initie un appel sortant vers un terminal UE3 par l'envoi d'une requête INVITE au cours d'une étape E100. Cette requête est relayée par le serveur S-CSCF vers le serveur d'application AS au 30 cours d'une étape E110, car, dans cet exemple, le serveur d'application AS met en oeuvre les services téléphoniques Originating. Duns ?e rrn 1 Irufiun déc(t.1-ç ic Id- ,!'application AS vérin, u cours pa E!2O emunts mnmmn itnscnbiu nomo/ 35 13 Dans cet exemple, on suppose que le nombre maximum précité est égal à et qull n\/a pas d'appel en cours. Porconséquent, !'nppel initié par le softphone PC UE1 est autorisé et un flux média est établi de façon standard entre l'appelant UE1 et l'appelé UE3 (étape générale E130). La signalisation nécessaire à l'établissement de ce flux est 5 connue de l'homme du métier et n'est pas représentée ici. Le serveur d'application AS selon l'invention notifie instantanément la passerelle HGW au cours d'une étape E40 pour lui indiquer que le softphone PC UE1 est en communication et que le réseau IMS n'est plus en mesure d'accepter de nouveaux appels initiés par des équipements partageant l'identité publique IMPU, le nombre maximal de 0 sessions simultanées ayant été atteint. La passerelle HGW convertit ces données au format V23 (étape E50) pour restitution par le téléphone TEL (étape E60). Bien entendu, dès que la session se termine, le serveur d'application AS notifie la passerelle HGW et un indicateur approprié est restitué sur le terminal TEL. 15 La figure 5 représente un autre mode de réalisation de l'invention, dans lequel il n'est pas fait usage du mëCanismeThirU Party Registration. Dans ce mode de réalisation, les équipements utilisateurs HGW, UE1 émettent (étape E210), une fois enregistrés en coeur de réseau {MS, une requête SIP PUBLISH de publication au serveur d'application AS. 20 Le serveur d'application AS enregistre ainsi la présence des équipements utilisateurs et acquitte positivement la requête (étape E220) par l'envoi d'une réponse 200 OK. Les équipements utilisateur souscrivent au service selon l'invention comme décrit en référence au premier mode de réalisation par l'envoi de messages de souscription 25 (étapes E30). Comme dans le premier mode de réalisation, le serveur AS selon l'invention notifie (étapes E40\ chaque équipement de l'enregistrement et du désenrgistrement en coeur de réseau IMS des équipements utilisateur ayant la même identité publique IMPU. Ces messages de notification comportent des données Dl sur ces équipements qui ~0 peuvent être restituées (étape E60) sur les interfaces homme-machine des terminaux.

Claims (5)

1. REVENDICATIONS1. Serveur d'application (AS) dans un réseau IMS REVENDICATIONS1. Serveur d'application (AS) dans un réseau IMS comportant: des moyens d'obtention aptes à obtenir (E20) des informations (INFl) sur au moins un premier équipement utilisateur (UE1) comportant une identité publique (IMPU) donnée, consécutivement à l'enregistrement (E10) ou au désenregistrement dudit premier équipement uti!isateur(UE1) en coeur de réseau IMS; et - des moyens d'envoi aptes à envoyer à au moins un autre équipement utilisateur (UE2) enregistré en coeur de réseau IMS avec la même identité publique (IMPU), des données (Dl) comportant au moins une partie desdites informations (INFl) et une indication (IE1) sur un état (El) dudit un moins un premier équipement utilisateur (UE1) dans le réseau.
2. 2. Serveur d'application (AS) selon la revendication 1, caractérisé en ce qu'il comporte: - des moyens pour enregistrer (E30) une souscription du premier équipement ub!isabeur(UE1) et une souscription dudit au moins autre équipement uti!isateur(UE2) à un service de notification, et en ce que : - lesdits moyens d'obtention sont aptes à recevoir lesdites informations (INFl) dans un message SIP de publication émis par ledit premier équipement utilisateur (UE1); et en ce que : - lesdits moyens de communication sont aptes à communiquer lesdites données (D1) dans un message SIP de notification envoyé audit au moins un autre équipement utilisateur (UE2).
3. 3. Serveur d'application selon la revendication 1, caractérisé en ce que lesdits moyens d'obtention sont aptes à recevoir lesdites informations (INFl) dans un message SIP reçu d'un serveur S-CSCF dudit réseau.
4. 4. Serveur d'application selon la revendication 3, caractérisé en ce que ledit message SIP encapsule une requête d'enregistrement envoyée par ledit premier équipement utilisateur (UE1) audit serveur S'CSCP, conformément au mécanisme Third 5, _nxn:Un~ 35 15 6. Serveur d'application selon l'une des revendications 1 à 5, caractérisé en ce que lesdites informations (INF1) sur ledit au moins un premier équipement utilisateur (UE1) comprennent au moins une information choisie parmi:
5. 5 - ladite identité publique (IMPU); - une adresse dejoignob/!ité dudit premier équipement utilisateur ; -un paramètre de priorité q dudit premier équipement utilisateur conforme à la norme RF[3261; et - un identifiant SIP décrivant le type et éventuellement un contexte d'utilisation 10 dudit premier équipement utilisateur. 7. Serveur d'application selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ledit état (El) dudit au moins un premier équipement utilisateur comporte au moins une indication parmi: 15 - une indication de présence dudit premier équipement utilisateur - la priorité dudit premier équipement utilisateur; -!a date et/ou!'heure dudit enregistrement ou dudit désenregistrement; - une localisation géographique dudit premier équipement utilisateur; et - un état d'occupation dudit premier équipement utilisateur. 20 8. Serveur d'application selon l'une quelconque des revendications 1 à 7, caractérisé en ce que lesdites données (Dl) comportent en outre le nombre de sessions en cours initiées par l'ensemble des équipements utilisateurs ayant ladite identité publique et le nombre maximum autorisé de ces sessions. 25 9. Serveur d'application selon l'une quelconque des revendications 1 à 8, caractérisé en ce qu'il comporte des moyens pour détecter un changement d'un dit état affectant au moins un des terminaux SIP enregistrés en coeur de réseau SIP avec ladite idenUté publique (IMPU), lesdites données étant envoyées à tous les autres terminaux con,écuUvennent à ladite détection. 10. Pro -1' de gestion de terminaux mis en oeuvre par un serveur d'application (AS)dans~ unc vUlsa~~.r (UE1) 16 l'enregistrement ou au désenregistrement dudit premier équipement utilisateur (UE1) en coeur de réseau IMS; et - une étape d'envoi, à au moins un autre équipement utilisateur enregistré en coeur de réseau IMS ayant la même identité publique, de données (Dl) comportant au moins une partie desdites informations et une indication sur un état dudit un moins un premier équipement utilisateur dans le réseau. 11. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme dhrdinateur/PGAS\ comprenant des instructions pour l'exécution des étapes 10 du procédé de gestion d'appels selon la revendication 10. 12. Programme d'ordinateur (PGAS) comportant des instructions pour l'exécution des étapes du procédé de gestion de terminaux selon la revendication 10 lorsque ledit programme est exécuté par un ordinateur. 15 13. Equipement utilisateur (HGW, UE2) comportant des moyens pour s'enregistrer en coeur de réseau IMS avec une identité publique (IMPU) donnée, caractérisé en ce qu'il comporte : - des moyens de réception de données (Dl) émises par un serveur d'application 20 dudit réseau, ces données (Dl) comportant des informations sur au moins un autre équipement uti!isateur(UE1) ayant la même identité publique (IMPU) et une indication sur un état (E1) dudit au moins un autre équipement utilisateur dans le réseau ; - des moyens de traitement (E60) desdites données (Dl) en vue de leur restitution par une interface homme-machine d'un terminal utilisateur (TEL, UE2). 25 14. Equipement utilisateur (HGW) selon la revendication 13 constitué par une passerelle domestique (HGW), caractérisé en ce que lesdits moyens de traitement sont aptes à convertir lesdites données (Dl) selon un protocole de signalisation téléphonique et à transmettre (E5O) les données converties (DC1) à un terminal (TEL) connecté à 30 ladite passerelle en vue de leur rcsu tut an (E60) sur une interface homme machine dudit terminal. ,cation 13 coniitu,:2 par un ioiiexlcnt- so'Tt aptes 3 5 17 16. Terminal (TEL) connecté à une passerelle domestique (HGW), caractérisé en ce qu'il comporte : - des moyens pour recevoir de ladite passerelle (HCW), selon un protocole de ~ signalisation téléphonique, des données (DC1) comportant des informations sur au moins un autre équipement utilisateur (UE1) ayant la même identité publique (IMPU) que ladite passerelle et une indication sur un état (El) dudit au moins un autre équipement utilisateur (UE1) dans le réseau ; et - des moyens de restitution desdites données (DC1) sur une interface homme 10 machine dudit terminal. 17. Procédé de traitement de données (Dl) mis en oeuvre par un équipement utilisateur (HGW, UE2) enregistré en coeur de réseau IMS avec une identité publique (IMPU) donnée, caractérisé en ce qu'il comporte : 15 - une étape de réception desdites données (Dl), celles-ci ayant été émises par un serveur d'application (AS) dudit réseau, ces données (Dl) comportant au moins des informations sur un autre équipement utilisateur (UE1) ayant la même identité publique (IMPU) et une indication sur un état (El) dudit au moins un autre équipement utilisateur (UE1) dans le réseau ; et 20 - une étape de traitement desdites données (Dl) en vue de leur restitution par une interface homme-machine d'un terminal utilisateur (TEL, UE2). 18. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur (PGUE) comprenant des instructions pour l'exécution des étapes 25 du procédé de traitement selon la revendication 17. 19. Programme d'ordinateur (PGUE) comportant des instructions pour l'exécution des étapes du procédé de traitement selon la revendication 17 lorsque ledit programme est exécuté par un ordinateur. 20. P/ocbde d'alerte mis en oeuvre par un terminal (TEL) connecté à une passerelle dome,* ue (HG'!A!'), caractérisé én ce qu'il comporte : unE d~ pDon en pov~nanca d~ hdiu possere!e (HGW), scbx un oioco!~ du s/g~uhahon te!cp!~cni~:e~a~ dunrccu (3[\) com~u'La./i ou n~u/ns dcs a/r uo ou!/c c~x/~~emuni oh~iwie:r (UE7~ ayuni !n mÜnc ~en~ii .!~ 30 35 18 (IMPU) que ladite passerelle et une indication sur un état (El) dudit au moins un autre équipement utilisateur (UE1) dans le réseau ; et une étape de restitution desdites données (D[1) sur une interface homme machine dudit terminal. 21.Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur (PGTEL) comprenant des instructions pour l'exécution des étapes du procédé d'alerte selon la revendication 20. 10 22. Programme d'ordinateur (PGTEL) comportant des instructions pour l'exécution des étapes du procédé d'alerte selon la revendication 20 lorsque ledit programme est exécuté par un ordinateur.