Note: Descriptions are shown in the official language in which they were submitted.
CA 02352988 2001-05-30
WO OiJ26301 PCT/FR00/02725
t
Protocole de lancement d'une application logicielle
à distance et de réservation de ressources réseau
avec qualité de service
Avec l'avènement de l'échange d'informations de
toute nature, par l'intermédiaire des réseaux de
transmission, le problème de la configuration, de
l'occupation et de l'utilisation rationnelle de ces
derniers est devenu d'une importance majeure, afin
d'assurer une transmission de ces informations dans des
conditions satisfaisantes.
D'une manière générale, la transmission de ces
informations peut être effectuée, par l'intermédiaire de
ces réseaux, en mode connecté ou en rnode non connecté.
Lors d'une transmission en mode connecté, une
entité appelante ne peut émettre d'informations vers une
entité appelée sans avoir, au préalable, demandé à cette
dernière la permission de lui transmettre des blocs
d'informations. Le processus de transmission en mode
connecté implique donc la mise en oeuvre-d'un établissement
de la connexion, succession de connexions multiples, d'un
échange des blocs d'informations puis de la libération de
la connexion. C'est le cas, par exemple, de la
communication par le réseau téléphonique commuté, RTC, ou
par le réseau numérique à intégration de services RNIS.
Lors,d'une transmission en mode non connecté, les
informations sont transmises par routage vers une entité
lointaine qui peut se trouver en état d'activité ou de
non-activité. En cas de non-activité, cette dernière est
remplacée par une boîte à lettres. Pour un tel mode de
transmission, les caractéristiques des blocs de données
CA 02352988 2001-05-30
WO 01/26301 PCTIFR00102725
2
transmises doivent être connues et à chaque transmission
il est nécessaire de préciser les in~'ormations de contrôle
qui seront nécessaires pour que ces données transmises, et
les informations véhiculées par ces dernières, arrivent à
destination. En particulier, l'a.dresse de l'entité
lointaine, réceptrice, et de l'entité émettrice, doivent
dans ce but être insérées dans le bloc de données
transmises. C'est 1e cas en particulier de la transmission
de messagerie électronique, de fichiers et d'applications
t0 pour lesquelles la communication en temps réel n'est pas
nécessaire.
A l'heure actuelle, les travaux publiés sur le
thème de la programmation, et la. configuration, des
réseaux connectés ont essentiellement concerné les
processus de programmation et de configuration avec
signalisation. On rappelle, en particulier, que ces
processus avec signalisation consistent, essentiellement,
à transporter les commandes de connexion, encore appelées
signalisation, par l'intermédiaire d'un réseau de
signalisation dit réseau sémaphore.
Plus récemment, les Universités de Kansas et de Columbia
(New York) aux Etats-Unis d°Amérique ont publié des
travaux relatifs à la réservation de bande passante dans
un réseau de transmission à l'aide du protocole de
réservation de ressources GSMP, pour Generis Switch
Management Protocol.
Parmi ces travaux, on peut citer les .articles ci-après
I) "Realizing the MPEG-~ Multimedia Delivery Framework",
IEEE Network Magazine pp.35-45, Novembre/décembre
1998. Special Issue on Transmission and Distribution
CA 02352988 2001-05-30
WO 01/26301 PCTlFR00102725
3
of Digital Video, publié par J.F. HUARD, A.A. LAZAR,
K.S. LIM et G:S. TSELIKIS
2) "A Programmable Transport Architecture with QOS
Guarantee", IEEE Communication:> Magazine, Vo1.36,
No.lO, pp. 54-62, octobre 1998 publié par J.F. HUARD
et A.A. LAZAR ;
3) "The IEEE p:I520 Standards Initiative for Programmable
Network Interfaces", IEEE Communications Magazine,
Vo1.36, No.lO, pp. 64-70, octobre 1998, publié par
J. BISWAS, A.A. LAZAR, J.F. HUARD, K.S. LIM,
S. MAHJOUB, L.F. PAU, M. SUZUKI, S. TORTENSSON, W.WANG
et S. WEINSTEIN ;
4 ) "Programming Telecommunication Networks", IEEE Network
Magazine pp. 8-18, septembre/octobre 1997, publié par
t5 A.A.LAZAR.
En outre, des procédures de demande
d'établissement d'une connexion à travers un réseau par
l'intermédiaire d'un navigateur "web" ont fait l'objet de
travaux. Parmi ceux-ci, on peut citer .
5) l'article intitulé "Session Co.ntrol for Broadband
Multimed.ia Services using the HTTP Protocol", ATM
Forum, février 1997, publië par GbTA LEIJONHUFVUD
Ericsson Telecom AB.
Enfin, les procédures RMI (Remote Method Invocation) et
HTML (Hyper Text Marked Language) sont connues en
environnement JAVA pour lancer des applications dans une
architecture client-serveur sur un réseau non connecté.
Les procédures mentionnées précédemment donnent
satisfaction, mais elles doivent utiliser le même réseau
pour assurer la transmission des flux d'informations de
l'application. A titre d'exemple, il n'existe pas dans les
CA 02352988 2001-05-30
WO 01126301 PCT/FR00/02725
4
procédures précitées de moyens d'indiquér vers le réseau
utilisé la valeur et le type de qualité de service requis.
En outre, dans les procédures précitées, il n'existe a
priori aucun couplage permettant d'assurer le lancement
d'une connexion d'un réseau connecté, ni a fortiori une
application, ce dernier étant distinct et indépendant du
réseau non connecté.
La présente invention a pour objet de remédier aux
inconvénients et limitations des procédures de l'art
lo antérieur pa r la mise en oeuvre d'un protocole de lancement
d' une application logicielle à distance et de réservation
de ressources réseau avec quàlité de service, un terminal
appelant étant ainsi mis en mesure de lancer une
application à distance sur un terminal appelé lorsque ces
terminaux sont reliés sur un réseau connecté.
Un autre objet de la présente invention est en
outre la mise en oeuvre d'un protocole de lancement d'une
application logicielle à distance et de réservation de
ressources réseau avec qualité de service dans lequel,
préalablement au lancement effectif de l'application, le
terminal appelant a effectué, par réservation, des
connexions à partir d'un réseau non connecté.
Un autre objet de la présente invention est
également; après réalisation de la connexion par le réseau
connectë entre le terminal appelant et le terminal appelé,
la mise en oeuvre d'un protocole permettant la mise en
oeuvre d'une communication avec un débit à qualité de
service garanti sur le réseau connecté.
Un autre objet de la présente invention est enfin
ia mise en Qeuvre d'un protocole de lancement d'une
application logicielle à distance et de réservation de
CA 02352988 2001-05-30
WO 01126301 PCTJFR00/02725
ressources rêseau avec qualité de service plus
particulièrement destiné à la gestion de communications
visiophoniques à partir d'un méme ensemble intégré au
niveau du terminal appelant.
5 Le protocole de lancement d'une application
logicielle à distance et de réservation de ressources
réseau avec qualité de service entre un terminal appelant
et un terminal appelé, objet de la présente invention, est
remarquable en ce qu'il consiste à transmettre, à partir
du terminal appelant vers le terminal appelé, une requéte
de réservation de connexion, par l'intermédiaire d'un
serveur et d'une transmission par réseau non connecté et à
établir, entre le terminal appelant et le terminal appelé,
un processus de réservation de ressources réseau avec
IS qualité de service, par échange de messages par
l'intermédiaire de la transmission par le réseau non
connecté. Sur acceptation de la réservation de ressources
réseau par le serveur est établi, sur le même réseau
physique support du réseau izon connecté, par
l'intermédiaire d'un réseau de commande, un réseau
connecté entre le terminal appelant et le terminal appelé:
Le réseau connecté constitue la ressource réseau avec
qualité de service pour exécuter l'application logicielle
à distance entre le terminal appelant et le terminal
appelé .
Le protocole objet de la présente invention est
destiné à la mise en ceuvre à di~~tance d'applications
logicielles de tout type avec réservation dé qualité de
service, mais il est plus particulièrement destiné à des
applications de visioconférence pour lesquelles la gestion
CA 02352988 2001-05-30
WO O1/2G301 PCTlFR00/02725
6
de l'occupation de bande passante des réseaux connectés en
assurant l'exécution est primordiale..
Le protocole objet de la présente invention sera
maintenant exposé dans la description ci-après en liaison
avec les figures en facilitant la compréhension dans
lesquelles .
- la figure la représente, sous la forme d'un
organigramme fonctionnel, les étapes; de mise en oeuvre du
protocole objet de la présente invention ;
- la figure lb représente un mode de réalisation
particulier préférentiel du protocole objet de la présente
invention dans le cas où Ie réseau non connecté est le
réseau IP, pour Internet Protoco~~, et où le réseau
connecté est le réseau ATM ;
- la figure lc représente à titre illustratif
l'architecture relative des réseaux connecté et non
connecté dans le mode de réalisation de la figure lb ;
- la figure 2 représente, à titre d'exemple
illustratif, un détail de mise en oeuvre du protocole objet
de la présente invention, dans un mode de mise en ceuvre
préférentiel dans lequel les messages de requête de
réservation de connexion et de processus de réservation
sont établis en environnement JAVA ;
- les figures 3a et 3b représentent des pages
écrans affichées par le moniteur du terminal appelant
respectivement du terminal appelé dans le cas d'une
application de visioconférence.
Le protocole de lancement d'une application
logicielle à distance et de réservation de ressources
réseau avec qualité de service, objet de la présente
CA 02352988 2001-05-30
WO 01/26301 PCT/FR00/02725
7
invention, sera maintenant décrit en liaison avec la
figure la et les figures suivantes.
D'une manière générale, on indique que le
protocole objet de la présente invention est destiné à
être mis en ceuvre entre un terminal appelant, noté TA, et
un terminal appelé, noté TB. Bien entendu, le terminal
appelant et le terminal appelé sont équipés des ressources
nécessaires afin d'échanger des messages d'informations
sous forme de fichiers et de préférence sous forme de
pages écrans permettant l'instauration d'un dialogue
interactif entre le terminal appelant TA et le terminal
appelé TB.
En référence à la figure la, on indique que, suite
à une étape de début dans laquelle le terminal appelant TA
et le terminal appelé TB sont nécessairement physiquement
interconnectés à un réseau susceptible de mettre en
communication ces derniers, le terminal appelé TB étant
fonctionnellement indépendant du terminal appelant TA, le
protocole objet de la présente invention consiste, à
l'étape A, à transmettre à partir du terminal appelant TA
vers le terminal appelë TB une requête de réservation de
connexion, cette requête étant notée RR~ et étant
transmise par l'intermédiaire d'un serveur S et d'une
transmission par un réseau non connecté. De par la
transmission de cette requête par réseau non connecté,
cette transmission implique les conditions de transmission
précédemment mentionnées dans la description, relativement
à la transmission de données ou de messages d'information
sur le réseau non connecté.
Suite à l'étape A précitée, le protocole objet de
la présente invention consiste, en une étape B, à établir
CA 02352988 2001-05-30
WO 01/26301 PCT/FROO102725
8
entre le terminal appelant TA et le terminal appelé TB, un
processus de réservation de ressources réseau avec qualité
de service. D'une manière générale, on indique que ce
processus de rëservation perme t à l'utilisateur du
terminal TA de définir certains paramètres relatifs aux
ressources réseau avec qualité de service, ainsi qu'il
sera décrit ultérieurement dans la df=scription.
Conformément à un aspect remarquable du protocole
objet de la présente invention, on indique que le
processus de réservation est établi par échange de
messages par l'intermédiaire du serveur et de la
transmission par réseau non connecté précédemment
mentionné relativement à l'étape A.
Sur acceptation de la réservation de ressources
i5 réseau par le serveur, le terminal appelé précité ou
l'utilisateur de ce dernier étant susceptible d'accepter
l'exécution de l'application, le protocole objet de la
présente invention consiste, à l'étape C, à établir, de
préférence sur le même réseau physique support du réseau
non connecté, par l'intermédiaire d'un réseau de commande
RC, un réseau connecté entre le terminal appelant TA et le
terminal appelé TB. On rappelle ainsi que, lorsque le
réseau connecté est établi, la transmission de messages
d'information entre le terminal appelant TA et le terminal
appelé TB satisfait aux conditions préalablement
mentionnées dans la description relativement à la
transmission de messages d'information sur un réseau
connecté.
Ainsi, le réseau connecté constitue la ressource
réseau avec qualité de service permettant d'exécuter
CA 02352988 2001-05-30
WO OI/26301 PCTIFR00/02725
9
1°application logicielle à distance entre, le' terminal
appelant et le terminal appelé.
D'une manière générale, on indique que pour
réaliser la mise en ceuvre du protocole objet de la
présente invention, il est nécessaire que le réseau
connecté destiné à transporter les flux d'informations
avec qualitë de service soit commandé de manière externe,
la notion de commands externe couvrant à la fois la mise
en oeuvre d'un réseau de commande, le réseau RC, permettant
de configurer les connexions successives du réseau
connecté ou, le cas échéant, d'un système de traduction
entre les messages transmis par lE: réseau non connecté
afin d'effectuer la réservation des ressources et une
signalisation existante telle que définie précédemment
is dans la description.
Différents modes de réalisation spécifiques seront
maintenant décrits en liaison avec les figures lb et lc,
lesquelles visent à définir une architecture
préférentielle des systèmes de réseaux connectés,
respectivement de réseaux non connectés mis en oeuvre pour
assurer la conduite du protocole de lancement d'une
application logicielle à distance et de réservation de
ressources réseau avec qualité de service conforme à
l'objet de la présente invention.
D'une manière générale, en référence à la figure
lb, on indique que les étapes consistant à transmettre la
requête de réservation de connexion Rr~ et à établir entre-
le terminal appelant et le terminal appelé un processus de
réservation de ressources réseau avec qualité de service
sont de préférence réalisées à partir du serveur.
CA 02352988 2001-05-30
WO O1J26301 PCT/FR00102725
De même, en référence à la figure lc, on indique
que de manière particulièrement avantageuse, le serveur
peut être constitué par un serveur "web". Dans ces
conditions, les étapes consistant à transmettre la requête
5 de réservation de connexion et à établir entre le terminal
appelant TA et le terminal appele'=_ TB un processus de
réservation de ressources réseau avec qualité de service
peut consister alors en l'envoi de messages HTML, pour
Hyper Text Marked Language.
10 En référence aux figures lb et lc, on indique que
dans ce mode de réalisation préférentiel, le protocole
objet de la présente invention permet de contrôler des
liens d'un réseau ATM à partir d'un réseau IP, le réseau
ATM constituant le réseau connecté et le réseau IP le
is réseau non connecté.
Ainsi que représenté en figure lb, on indique qué
des terminaux, terminal appelant TA et terminal appelé TB,
disposent bien entendu d'une carte d'interconnexion en
réseau de type IP et d'une cartE: d'interconnexion en
réseau de type ATM, afin d'effectuer le transport des flux
d'informations à qualité de service ou, le cas échéant, dé
disposer des deux piles de protocole sur la méme carte
d'interconnexion ATM ainsi qu'il est représenté sur la
figure lb.
Dans ce cas, les deux réseaux, réseau IP non
connecté et réseau ATM connecté, sont constitués sur le
même support physique. En particulier, les applications
IP, c'est-à-dire les messages HTN~L ou analogue, sont
transportées sur une émulation d'un .réseau local LAN, pour
Local Area Network, et les messages ATM peuvent être
CA 02352988 2001-05-30
WO 01/26301 PCTlFR00102725
I1
transmis dans la machine directement ou après la couche
d'adaptation AAZ.
Ainsi, en référence à la figure lb, on indique que
les deux piles de protocole sont supportées par le mëme
support physique.
En rëférence à la figure lc, lorsque la connexion
vers un serveur, tel qu'en particulier un serveur "web",
est établie à partir du terminal appelant TA, le dialogue
peut s°établir entre le terminal appelant précité et le
l0 serveur par l'intermédiaire du protocole HTTP d'un
navigateur "web" pour le transfert des messages et le cas
échéant de programmes, sous-programmes d'exécution ainsi
qu'il sera dêcrit ultérieurement dans la description.
Ensuite, le serveur peut alors lancer des ordres de
connexion, ainsi que représenté sur la figure lc, les
ordres de connexion étant lancés à un réseau de commande
par l'intermédiaire d'un protocole IP CORBA, le réseau de
commande comportant un BUS CORBA. vers des stations
génératrices de liens ATM. On indique que, de manière non
limitative, en référence à la figure lc, la configuration
du réseau ATM est réalisée à partir d'une plate-forme de
programmation répartie, toute autre solution telle que la
signalisation par un agent tiers pouvant être également
envisagée.
En référence à la figure 1c, on indique que, pour
réaliser les connexions sur le réseau ATM, c'est-à-dire
pour configurer le réseau connecté ainsi que représenté
sur la figure précitée, le protocole utilisé entre le
réseau de commande précédemment mentionné RC et le réseau
ATM, constituant en fait le réseau de transport de
l'application avec qualité de service, peut être réalisé
CA 02352988 2001-05-30
WO 01/26301 PCTIFR00102725
12
par l'intermédiaire d'un protocole GSMP, pour Generic
Switch Management Protocol.
On comprend ainsi qu'au niveau du réseau connecté
constituant le réseau de transport précité, ce réseau peut
être constitué en différents sous-z-éseaux, sous-réseau 1,
sous-réseau 2, de manière non lim_Ltative, les liens ATM
entre terminal appelant TA et terminal appelé TB
permettant bien entendu de réaliser l'interconnexion de
ces derniers en des lieux quelconques.
Une description plus détaillée d'un exemple
spécifique de mise en ceuvre du protocole objet de la
présente invention, dans le cas où le réseau non connecté
est un réseau TP et où le serveur est un serveur "web" par
exemple, sera maintenant donnée en liaison avec la figure
2 .
Ainsi que représenté sur la figure précitée, les
étapes consistant à transmettre la requête de réservation
de connexion et à établir 1e processus de réservation de
ressources réseau avec qualité de service, c'est-à-dire
les étapes représentées en figure la aux points A, B,
peuvent consister au moins à transmettre 1) du terminal
appelant TA au serveur "web" une demande de connexion et,
sur connexion du terminal appelant TA au serveur précité,
à fournir 2) au terminal appelant TA une page d'entrée. La
fourniture d'une page d'entrée au terminal appelant TA
n'est pas décrite en détail figure 2, car une telle
opération est une opération classique, lors d'un accès par
un terminal à un serveur, selon le protocole de
transmission par réseau IP.
3o Suite à la fourniture de la page d'entrée, le
protocole objet de la présente invention consiste en une
CA 02352988 2001-05-30
WO 01/26301 PCT/FROOI02725
13
étape 3) dans laquelle le terminal appelant procède à un
téléchargement dans les mémoires constitutives de ce
dernier à partir du serveur, et en particulier du serveur
"web", d'un sous-programme de sélection de paramètres de
S qualité de service. Ainsi, le terminal appelant, à partir
de ce sous-programme, sera en mesure, par l' intermédiaire
du guidage de l'utilisateur de ce terminal appelant, de
sélectionner les paramètres de transmission des
informations relatives à l'application à exécuter.
L'étape 3) précitée est alors suivie d'une étape
3a) représentée par une flèche en boucle fermée au niveau
du terminal appelant TA consistant à établir, à partir du
terminal appelant précité et du sous-programme de
sélection, un choix de paramètres de qualité de service.
Les étapes 3) et 3a) précédemment mentionnées sont
alors suivies d'une étape 4) consistant, après avoir saisi
les paramètres de la communication et de qualité de
service désirés, à transmettre du terminal appelant TA au
serveur, serveur "web", le choix des paramètres de qualité
de service retenu.
Suite à l'étape 4), il est alors possible
d'établir, à partir du choix des paramètres de qualité de
service retenu, la réservation des ressources de réseau
connecté constituant les ressources :réseau avec qualité de
service précédemment mentionnées dans la description. La
réservation des ressources précitée est établie à partir
du serveur, serveur "web", vers le réseau ATM précédemment
décrit en liaison avec les figures lb et lc par
l'intermédiaire du réseau de commandE~ RC.
3o Ainsi, à la fin de l'étape 4), le réseau de
commande RC établit une réservation de ressources sur le
CA 02352988 2001-05-30
W~ 01/26301 PCTlFR00/02725
14
réseau ATM entre le terminal appelant TA et le terminal
appelé TB.
Suite à l'établissement de la réservation des
ressources de réseau connecté, le protocole objet de la
présente invention peut consister avantageusement à
transmettre, en une étape 5a), à partir du terminal
appelant TA vers le terminal appelé TB; une requête
d'exécution d'application, cette requête d'exécution
d'application comportant au moins un cade d'identification
du terminal appelant TA. On comprend bien sûr que l' étape
de transmission de la requête d'exécution d'application
peut alors être réalisée sur le réseau non connecté bien
que la réservation des ressources de réseau connecté ait
effectivement été effectuée et le réseau connecté ait
ainsi été établi. D'une manière générale, on indique que
la requête d'exécution d'application comporte au moins un
code d'identification du terminal appelant TA. Suite à
l'étape 5a) précitée, le protocole objet de la présente
invention consiste, en une étape 5b), à établir au niveau
du terminal appelé TB un processus de gestion de la
requête d'exécution d'application. Sur la figure 2, pour
cette raison, le processus de gestion réalisé à l'étape
5b) est représenté par ùne boucle fermée au niveau du
terminal TB.
Dans un mode de réalisation particulier
préférentiel non limitatif, le ;processus de gestion
représenté à l'étape 5b) peut comporter avantageusement;
sur refus par le terminal appelé TB de la requête
d'exécution de l'application, une étape de transmission
par l'intermédiaire du circuit non connecté vers le
terminal appelant TA d'un message d.e rejet de la requête
CA 02352988 2001-05-30
WO 01/26301 PCT/FR00/02?25
d'exécution d'application et d'incitation du terminal
appelant TA à libérer la réservation de connexion. Sur la
figure 2, on indique que l'étapE= de transmission du
message de rej et de la requête d' exécution est référencée
s 5c).
Au contraire, sur acceptation par le terminal
appelé TB de la requête d'exécution, une étape de
transmission par l'intermédiaire du circuit non connecté
au terminal appelant d'un message d'acceptation de la
10 requête d'exécution d'application et de lancement de cette
application est réalisée. Sur la figure 2, l'étape
précitée de transmission d'un message d'acceptation de la
requête d'exécution d'application est notée 5dy.
Au contraire, en l'absence de réponse du terminal
is appelé TB pendant une durée prédéterminée, absence de
réponse à la requête d'exécution d'application, le
protocble objet de la présente invention consiste à
effectuer la transmission, en une étape Se), suite à la
durée prédéterminée précitée par l'intermédiaire du
circuit connecté vers le terminal appelant TA d'un message
d'absence du terminal appelé TB. D'une manière générale,
on indique que sur la figure 2, les étapes 5c), 5d) et Se)
sont globalement désignées par réponse de visio, visio
désignant de manière générique une application dédiée à la
visioconférence ainsi qu'il sera décrit ultérieurement
dans la description.
Le protocole de lancement d'une application
logicielle à distance et de.,réservatian de ressources
réseau avec qualité de service, .objet de la présente
invention, peut être mis en ceuvre, en ce qui concerne la
requête de réservation de connexion et le sous-programme
CA 02352988 2001-05-30
WO 01126301 PCT/FR00/02725
16
de sélection de paramètres de qualité de service, au moyen
de sous-programmes, désignés communément par appliquettes
ou encore applets en environnement JAVA.
Dans ces conditions, on indique que l'étape de
téléchargement dans le terminal appelant à partir du
serveur d' un sous-programme de sélection de paramètres de
qualité de service, peut consister avantageusement en le
chargement d'une appliquette JAVA.
Enfin, lors de la fin de l'exécution de
l'application, c'est-à-dire lors de la fin de la
transmission de messages d'information par le réseau ATM,
le terminal appelant TA et le terminal appelé TB terminent
leur application localement de manière semblable à la
terminaison d'un appel téléphonique classique par exemple
i5 ou d'une communication sur le réseau RNIS.
Suite à la terminaison de cette communication, le
terminal appelant TA, lequel a établi la connexion, est
alors incité à effectuer une opération de déconnexion
permettant en fait de libérer à l'étape 7) les ressources
auprès du serveur "web" précité du réseau ATM. La gestion
de l'ensemble est donc complète, le réseau ATM étant alors
totalement libéré et prêt pour une nouvelle
reconfiguration ultérieure.
Une description plus détaillée d'éléments
spécifiques du protocole, objet de la présente invention,
lorsque l'application est dédiée à une application de
visioconférence, sera maintenant donnée en liaison avec
les figures 3a et 3b.
Dans une telle situation, on comprend que les
informations vidéo relatives à la visioconférence sont
transmises par le réseau ATM et que dans ce but, le sous
CA 02352988 2001-05-30
WO 01126301 PCTIF'R00102725
17
programme de sélection de paramètres de qualité de service
constitué par une appliquette JAVA permet le choix des
paramètres d'abonné, de bande passante et de
multidiffusion pour Multicast. En ce qui concerne la mise
en oeuvre et la transmission d'appliquettes JAVA, on
préférera le mécanisme RMI, pour Remote Method Invocation,
créé par la société JAVASOFT, en raison de l'inadaptation
du protocole RPC, pour Remote Procedure Code, des systèmes
objet distribués. Ce mécanisme RMI a pour objectif .
- de supporter l'invocation distantes des objets JAVA ;
- d'intégrer le modèle objet distribué dans
l'environnement JAVA de façon naturelle tout en gardant
la sémantique objet du langage ;
- de rendre simple le développement d'applications
distribuées ;
de préserver la sécurité et la sûreté fournies par
l'environnement JAVA précité.
On indique que le mécanisme RMI précité fait appel
aux notions client/serveur valables pour un appel. Le
mécanisme RMI permet en fait d'invoquer à distance un
objet JAVA, ce qui permet de satisfaire à deux des trois
points critiques mentionnés précédemment, à savoir .
- la dépendance de la mise en oeuvre de ce mécanisme, ce
mécanisme RMI utilisant en fait l'adresse IP pour
retrouver le serveur RMI distant ;
- en outre, un service de visioconférence impose, au
niveau de chaque terminal, terminal appelant TA et
terminal appelé TB, que le terminal appelé TB soit sous
tension et connecté et qu'un serveur RMI existe en
tâche de fond sur chacun des terminaux précités.
CA 02352988 2001-05-30
WO 01/26301 PCT/FR00/02725
38
Au cours d'une communication, le terminal appelant
TA est à la fois client et serveur RMI, et le terminal
appelé TB est serveur RMI, même si :Le cade est le même sur
chacun des terminaux précités. Dans ces conditions, le
service de visioconférence précédemment mentionné n'est
donc pas complètement indépendant du terminal mais il a
l'avantage d'être sécurisé car les seules actions
possibles sur chaque terminal distant sont celles définies
dans l'interface côté serveur.
Afin de mettre en ouvre le service de
visioconférence précité, il est toutefois nécessaire de
prëvenir le terminal appelé TB de la requête d'exécution
d'application précédemment mentionnée dans la description.
Dans le cadre de la mise en oeuvre du protocole,
objet de la présente invention, en esnvironnement JAVA, une
solution satisfaisante consiste à introduire, au niveau du
terminal appelé, une boîte de dialogue JAVA invoquée à
distance.
Dans ces conditions, les mêmes références
chiffrées correspondant aux étapes de mise en oeuvre du
protocole objet de la présente invention telles que
représenté en figure 2 maintenant dédiëes à une
application de visioconférence, les étapes successives
correspondantes sont données ci-après .
1 ) le terminal appelant TA se connecte au serveur "web"
de ressources
2) une page HTML est fournie par ce dernier au terminal
appelant TA. Le serveur "web" contient les
informations nëcessaires au service. Il assure la
correspondance entre le nom et l'adresse IP du
CA 02352988 2001-05-30
WO 01126301 PCT/FROO102725
19
terminal appelant TA de manière similaire aux listes
de diffusion dans les courriers électroniques ;
3? le terminal appelant TA télécharge l'appliquette
JAVA, laquelle permet de choisir les paramètres de
communication tels que abonné B, bande passante,
multidiffusion pour multicast ainsi que mentionné
précêdemment, cette liste n'étant pas limitative.
L'appliquette JAVA précitée, ainsi que représenté en
figure 3a, comporte une page écran affichëe au niveau
du terminal appelant TA et comportant au moins deux
boutons de sélection, un bouton de sélection
"Connexion"/"Déconnexion" ainsi qu'un bouton de
réglage du débit voulu pour assurer la transmission
des données de visioconférence. Les autres paramètres
peuvent servir pour la commande externe. Le bouton de
réglage de débit est désigné par "Débit Kb°' sur la
figure 3a.
De manière particulièrement avantageuse, on indique
que le bouton de sélection "Connexion"/ "Déconnexion"
est un bouton à fonction réattribuable. Selon un
aspect particulièrement avantageux, au bouton de
sêlection "Connexion" est allouée, suite à la
réservation de ressources de réseau avec qualitë de
service, une fonction de synchronisation entre la
commande externe du réseau et le lancement de
l'application de visioconférence. Un tel mode
opératoire permet une synchronisation entre la
commande externe de.réseau et Ie lancement proprement
dit de l'application de visioconférence car elle
évite ainsi de lancer l'applicat:ion précitée avant la
réservation des ressources du réseau ATM sans
CA 02352988 2001-05-30
WO 01/26301 PCTlFR00102725
lesquelles l'application ne peut bien entendu
fonctionner.
4) L'appui sur le bouton "Connexion" à l'étape 4)
déclenche le retour vers le serveur "web" de l' ordre
5 d'établissement de la connexion. Dans ces conditions,
le serveur "web" passe l'ordre de réservation au
réseau de commande RC et ce dernier établit une
réservation de ressources ATM entre le terminal
appelant TA et le terminal appelé TB par allocation
10 d'un chemin virtuel VP, pour Virtual Path, et d'un
canal virtuel VC, pour V.i.rtual Channel, par terminal
après calcul de l'opératio:n de routage. Dans
l'exemple précité, la gestion du réseau est
distribuée en référence à la figure lc à l'aide du
15 protocole CORBA afin d'obtenir une meilleure
efficacité lors de la commande des commutateurs
assurant la connexion pour constituer le réseau
connecté.
Sa) lors de l'étape considérée, l'appliquette JAVA
20 précédemment mentionnée comporte en outre une page
écran affichée au niveau du terrninàl appelé TB. Cette
page écran comportant deux boutons, un bouton
d'acceptation, noté "Accepté", et un bouton de refus
de lancement de l'application, bouton noté "refusé".
L'action réalisée à l'étape 5a) précitée met ainsi en
attente le terminal appelant avec un message du type
"Appel en cours" et prévient de cette manière le
terminal appelë TB d'une demande de visioconférence
par l'intermédiaire de la boite de dialogue, le cas
échéant combinée à une sonnerie, cette boîte de
dialogue lui indiquant l'ident:i.té du demandeur. Sur
CA 02352988 2001-05-30
WO 01126301 PCTIFR00l02725
21
la figure 3b, on indique que le mot "Visio" désigne
l'application de visioconfrence de manire
gnrique, "Karnak" dsignant arbitrairement
l'identit du terminal appelant:. La bote de dialogue
prcite telle que reprsente en figure 3b peut
avantageusement tre constitue par une application
JAVA lance au moyen du mcanisme RMI prcit et
permet ainsi au terminal appel TB de rpondre au
terminal appelant TA en fonction de sa dcision. On
comprend bien sr que dans de telles conditions, la
dcision est prise par l'ut_Llisateur du terminal
appel TB.
La gestion de l'acceptation ou du refus peut alors
tre ralise selon plusieurs choix l'aide des deux
boutons prcdemment mentionns en liaison avec la
figure 3b, boutons d'acceptation ou de refus.
L'utilisateur du terminal appel peut ainsi raliser
les actions suivantes .
a) il peut refuser la visioconfrence demande par
24 appui sur le bouton "Refus", cette action ayant
pour effet de retourner alors un code permettant
d'indiquer au demandeur que son correspondant ne
dsire pas la visioconfrence et que l'utilisateur
du terminal appelant TA a en charge de librer ies
ressources prcdemment rserves. C'est l'tape
Sc) de la figure 2.
b) Le terminal appel peut accepter la
visioconfrence demande par appui sur le bouton
"Accept", le code retour correspondant tant
renvoy et les applications de visioconfrence
tant alors lances simultanment sur les deux
CA 02352988 2001-05-30
WO 01/26301 PCT/FR00/02725
22
terminaux, terminal appelant, terminal appelé, au
moyen du mécanisme RMI. C'est l'étape 5d) de la
figure 2.
c) Le terminal appelé TB est connecté, mais il ne
répond pas après la fin d'un module retardateur
"timer" dont la durée peut ëtre fixée de I5 à 20
secondes par exemple. Dans de telles conditions,
on indique alors l'absence de l'utilisateur du
terminal appelé TB au tefminal appelant TA. Le
timer précité peut avantageusement ëtre déclenché
au niveau du terminal appel~~ TB lors du lancement
de la boite de dialogue JAVP~. C'est l'étape 5e) de
la figure 2.
6) Lors de la fin de la communication, c'est-à-dire lors
IS de la fin de l'application de visioconférence, les
deux abonnés utilisateurs de:> terminaux, terminal
appelé TA et terminal appelé TB, terminent leur
application localement comme au téléphone par
exemple. Le terminal appelant qui a établi la
connexion doit alors terminer celle-ci par un appui
sur le bouton "Déconnexion" ;
L'appui par l'utilisateur au niveau du terminal
appelant TA sur le bouton "Déconnexion" dont la
fonction n'a pas été réattribuée permet alors de
libérer les ressources après ia fin de la
visioconférence et de la fin de la communication. Le
mécanisme de déconnexion peut alors être similaire à
celui de la connexion mais avec l'ordre de libérer
les ressources au lieu de les réserver.
