CA2352988A1 - Protocole de lancement d'une application logicielle a distance et de reservation de ressources reseau avec qualite de service - Google Patents
Protocole de lancement d'une application logicielle a distance et de reservation de ressources reseau avec qualite de service Download PDFInfo
- Publication number
- CA2352988A1 CA2352988A1 CA002352988A CA2352988A CA2352988A1 CA 2352988 A1 CA2352988 A1 CA 2352988A1 CA 002352988 A CA002352988 A CA 002352988A CA 2352988 A CA2352988 A CA 2352988A CA 2352988 A1 CA2352988 A1 CA 2352988A1
- Authority
- CA
- Canada
- Prior art keywords
- network
- terminal
- service
- quality
- reservation
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
- H04L12/4608—LAN interconnection over ATM networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
- H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/803—Application aware
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/805—QOS or priority aware
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5629—Admission control
- H04L2012/563—Signalling, e.g. protocols, reference model
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/133—Protocols for remote procedure calls [RPC]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Quality & Reliability (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
L'invention concerne un protocole de lancement d'une application logicielle à distance et de réservation de res- sources réseau avec qualité de service entre un terminal appelant TA et un un terminal appelé T8. Il consiste à transmettre (A) à partir du terminal appelant TA vers le terminal appelé TB une re- quête de réservation de connexion par l'intermédiaire d'un ser- veur et d'une transmission par réseau non connecté et à établir (B), entre terminal appelant TA et terminal appelé TB, un pro- cessas de réservation de ressources réseau avec qualité de service par échange de messages par l'intermédiaire de la transmission pa r réseau non connecté. Sur acceptation de la réservation de ressources réseau par le serveur est établi (C), sur le même réseau physique support du réseau non connecté par l'intermédi- aire d'un réseau de commande RC, un réseau connecté entre le terminal appela nt TA et le terminal appelé TB. Le réseau connecté constitue la ressource réseau avec qualité de service pour exécuter l'application logicielle à distance entre terminal appelant TA et terminal appelé TB. Application à un réseau connecté, réseau ATM, et à un réseau non connecté, réseau IP.
Description
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
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
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 WO 01/26301 PCTlFR00102725
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 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 ;
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 .
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 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 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 WO O1/2G301 PCTlFR00/02725
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 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 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 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
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
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
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
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
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
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.
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.
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.
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 WO 01/26301 PCTlFR00102725 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é
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 é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 W~ 01/26301 PCTlFR00/02725 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 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 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 WO 01126301 PCTIF'R00102725 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.
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 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 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 WO 01126301 PCTIFR00l02725 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 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.
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 WO 01/26301 PCTlFR00102725 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é
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 é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 W~ 01/26301 PCTlFR00/02725 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 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 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 WO 01126301 PCTIF'R00102725 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.
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 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 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 WO 01126301 PCTIFR00l02725 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 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.
Claims (10)
1. Protocole de lancement d'une application logicielle à distance et de réservation de ressource réseau avec qualité de service, entre un terminal appelant et un terminal appelé, caractérisé 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é ;
- à établir, entre le terminal appelant et le terminal appelé, un processus de réservation de ressources réseau avec qualité de service, par échange de messages par l'intermédiaire de ladite transmission par réseau non connecté, et sur acceptation de ladite réservation de ressources réseau par ledit serveur, - à établir, sur le même réseau physique support du réseau non connecté, par l'intermédiaire d'un réseau de commande, un réseau connecté entre ledit terminal appelant et ledit terminal appelé, ledit réseau connecté constituant ladite ressource réseau avec qualité de service pour exécuter ladite application -logicielle à distance entre ledit terminal appelant et ledit terminal appelé.
- à 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é ;
- à établir, entre le terminal appelant et le terminal appelé, un processus de réservation de ressources réseau avec qualité de service, par échange de messages par l'intermédiaire de ladite transmission par réseau non connecté, et sur acceptation de ladite réservation de ressources réseau par ledit serveur, - à établir, sur le même réseau physique support du réseau non connecté, par l'intermédiaire d'un réseau de commande, un réseau connecté entre ledit terminal appelant et ledit terminal appelé, ledit réseau connecté constituant ladite ressource réseau avec qualité de service pour exécuter ladite application -logicielle à distance entre ledit terminal appelant et ledit terminal appelé.
2. Protocole selon la revendication 1, caractérisé
en ce que ledit serveur étant constitué par un serveur "web", lesdites étapes consistant à transmettre la requête de réservation de connexion et à établir entre le terminal appelant et le terminal appelé un processus de réservation de ressources réseau avec qualité de service consiste en l'envoi de messages HTML.
en ce que ledit serveur étant constitué par un serveur "web", lesdites étapes consistant à transmettre la requête de réservation de connexion et à établir entre le terminal appelant et le terminal appelé un processus de réservation de ressources réseau avec qualité de service consiste en l'envoi de messages HTML.
3. Protocole selon l'une des revendications 1 ou 2, caractérisé en ce que lesdites étapes consistant à
transmettre la requête de réservation de connexion et à
établir ledit processus de réservation de ressources réseau avec qualité de service consiste au moins :
- à transmettre dudit terminal appelant audit serveur une demande de connexion ; et, sur connexion dudit terminal appelant audit serveur, - à fournir audit terminal appelant une page d'entrée ;
- à charger dans ledit terminal appelant, à partir dudit serveur, un sous-programme de sélection de paramètres de qualité de service ;
- à établir, à partir dudit terminal appelant et dudit sous-programme de sélection, un choix de paramètres de qualité de service ;
- â transmettre, dudit terminal appelant audit serveur ledit choix de paramètres de qualité de service ;
- à établir, à partir du choix des paramètres de qualité
de service, la réservation des ressources de réseau connecté, constituant les ressources réseau avec qualité de service.
transmettre la requête de réservation de connexion et à
établir ledit processus de réservation de ressources réseau avec qualité de service consiste au moins :
- à transmettre dudit terminal appelant audit serveur une demande de connexion ; et, sur connexion dudit terminal appelant audit serveur, - à fournir audit terminal appelant une page d'entrée ;
- à charger dans ledit terminal appelant, à partir dudit serveur, un sous-programme de sélection de paramètres de qualité de service ;
- à établir, à partir dudit terminal appelant et dudit sous-programme de sélection, un choix de paramètres de qualité de service ;
- â transmettre, dudit terminal appelant audit serveur ledit choix de paramètres de qualité de service ;
- à établir, à partir du choix des paramètres de qualité
de service, la réservation des ressources de réseau connecté, constituant les ressources réseau avec qualité de service.
4. Protocole selon l'une des revendications 1, 2 ou 3, caractérisé en ce que, suite à l'établissement de la réservation des ressources de réseau connecté, celui-ci consiste en outre :
- à transmettre, à partir du terminal appelant, vers le terminal appelé, une requête d'exécution d'application, ladite requête d'exécution d'application comportant au moins un code d'identification du terminal appelant ;
- à établir, au niveau dudit terminal appelé, un processus de gestion de la requête d'exécution d'application.
- à transmettre, à partir du terminal appelant, vers le terminal appelé, une requête d'exécution d'application, ladite requête d'exécution d'application comportant au moins un code d'identification du terminal appelant ;
- à établir, au niveau dudit terminal appelé, un processus de gestion de la requête d'exécution d'application.
5. Protocole selon la revendication 4, caractérisé
en ce que ledit processus de gestion comporte :
- sur refus, par ledit terminal appelé, de la requête d'exécution de l'application, une étape de transmission, par l'intermédiaire dudit circuit non connecté, audit terminal appelant d'un message de rejet de ladite requête d'exécution d'application et d'incitation du terminal appelant à libérer ladite réservation de connexion ;
- sur acceptation par ledit terminal appelé de la requête d'exécution, une étape de transmission, par l'intermédiaire dudit circuit non connecté, audit terminal appelant d'un message d'acceptation de ladite requête d'exécution d'application et de lancement de cette application ;
- sur absence de réponse dudit terminal appelé pendant une durée prédéterminée, transmission, suite à cette durée déterminée par l'intermédiaire du circuit non connecté, vers ledit terminal appelant d'un message d'absence du terminal appelé.
en ce que ledit processus de gestion comporte :
- sur refus, par ledit terminal appelé, de la requête d'exécution de l'application, une étape de transmission, par l'intermédiaire dudit circuit non connecté, audit terminal appelant d'un message de rejet de ladite requête d'exécution d'application et d'incitation du terminal appelant à libérer ladite réservation de connexion ;
- sur acceptation par ledit terminal appelé de la requête d'exécution, une étape de transmission, par l'intermédiaire dudit circuit non connecté, audit terminal appelant d'un message d'acceptation de ladite requête d'exécution d'application et de lancement de cette application ;
- sur absence de réponse dudit terminal appelé pendant une durée prédéterminée, transmission, suite à cette durée déterminée par l'intermédiaire du circuit non connecté, vers ledit terminal appelant d'un message d'absence du terminal appelé.
6. Protocole selon l'une des revendications 2 à 5, caractérisé en ce que la requête de réservation de connexion et le sous-programme de sélection de paramètres de qualité de service sont constitués par des appliquettes en environnement JAVA.
7. Protocole selon la revendication 6, caractérisé
en ce que, pour une application logicielle constituée par une session de visioconférence, transmise par le réseau ATM, ledit sous-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, de multidiffusion.
en ce que, pour une application logicielle constituée par une session de visioconférence, transmise par le réseau ATM, ledit sous-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, de multidiffusion.
8. Protocole selon la revendication 7, caractérisé
en ce que ladite appliquette JAVA comporte une page écran affichée au niveau du terminal appelant comportant au moins deux boutons de sélection, un bouton de sélection "connexion"/"déconnexion" et un bouton de réglage du débit de transmission.
en ce que ladite appliquette JAVA comporte une page écran affichée au niveau du terminal appelant comportant au moins deux boutons de sélection, un bouton de sélection "connexion"/"déconnexion" et un bouton de réglage du débit de transmission.
9. Protocole selon la revendication 8, caractérisé
en ce que ledit bouton de sélection "connexion"/"déconnexion" est un bouton à fonction réattribuable, au bouton de sélection "connexion" étant alloué, 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.
en ce que ledit bouton de sélection "connexion"/"déconnexion" est un bouton à fonction réattribuable, au bouton de sélection "connexion" étant alloué, 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.
10. Protocole selon la revendication 8 ou 9, caractérisé en ce que ladite appliquette JAVA comporte en outre une page écran affichée au niveau dudit terminal appelé comportant deux boutons, un bouton d'acceptation et un bouton de refus de lancement de l'application.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR9912352A FR2799326B1 (fr) | 1999-10-04 | 1999-10-04 | Protocole de lancement d'une application logicielle a distance et de reservation de ressources reseau avec qualite de service |
| FR99/12352 | 1999-10-04 | ||
| PCT/FR2000/002725 WO2001026301A1 (fr) | 1999-10-04 | 2000-10-02 | Protocole de lancement d'une application logicielle a distance et de reservation de ressources reseau avec qualite de service |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2352988A1 true CA2352988A1 (fr) | 2001-04-12 |
Family
ID=9550547
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002352988A Abandoned CA2352988A1 (fr) | 1999-10-04 | 2000-10-02 | Protocole de lancement d'une application logicielle a distance et de reservation de ressources reseau avec qualite de service |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US7079526B1 (fr) |
| EP (1) | EP1135893A1 (fr) |
| JP (1) | JP4993832B2 (fr) |
| AU (1) | AU7670200A (fr) |
| CA (1) | CA2352988A1 (fr) |
| FR (1) | FR2799326B1 (fr) |
| WO (1) | WO2001026301A1 (fr) |
Families Citing this family (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FI20000138A (fi) * | 2000-01-24 | 2001-07-25 | Nokia Networks Oy | Palvelun laadun varaaminen langattomasa tietoliikennejärjestelmässä |
| DE10143795A1 (de) * | 2001-09-06 | 2003-04-03 | Deutsch Zentr Luft & Raumfahrt | Verfahren zur Ausführung von auf dem Internet-Protokoll (IP) basierten Anwendungen mit Dienstgüte in heterogenen Zugangsfunknetzen |
| CN1618203A (zh) | 2001-12-15 | 2005-05-18 | 汤姆森特许公司 | 视频会议带宽选择机制 |
| FR2835679B1 (fr) * | 2002-02-05 | 2005-03-11 | France Telecom | Procede de transport de flux multimedia |
| US20030236863A1 (en) * | 2002-06-25 | 2003-12-25 | Johnson Peter E. | Just-in-time multicasting |
| EP1396965A1 (fr) * | 2002-09-04 | 2004-03-10 | Siemens Aktiengesellschaft | Procédé et dispositif pour la transmission d'informations de qualité de service et d'adresse dans un système de communication bidirectionnelle |
| FR2852118B1 (fr) * | 2003-03-06 | 2005-06-03 | Gemplus Card Int | Procede de gestion du declenchement d'une application dans un terminal de service notamment dans un terminal de telecommunication |
| FR2858504A1 (fr) * | 2003-08-01 | 2005-02-04 | France Telecom | Procede et systeme de transmission de donnees a haut debit et a qualite de service predeterminee dans un reseau de telecommunications |
| FR2860371B1 (fr) * | 2003-09-30 | 2005-12-02 | France Telecom | Procede et dispositif de traitement d'une communication telephonique |
| NO20053478A (no) * | 2005-07-15 | 2006-12-11 | Tandberg Telecom As | Fremgangsmåte for øyeblikkelig planlegging av konferansesamtaler. |
| CA3045683C (fr) | 2006-11-02 | 2021-10-26 | Voip-Pal.Com, Inc. | Production de messages de routage pour des communications par voix sur ip |
| CA2670510C (fr) | 2006-11-29 | 2020-12-22 | Digifonica (International) Limited | Interception de communications voip et autres transmissions de donnees |
| WO2008116296A1 (fr) | 2007-03-26 | 2008-10-02 | Digifonica (International) Limited | Appel d'assistance d'urgence pour des systèmes de communication de voix sur ip |
| US8630234B2 (en) * | 2008-07-28 | 2014-01-14 | Digifonica (International) Limited | Mobile gateway |
| EP2478678B1 (fr) | 2009-09-17 | 2016-01-27 | Digifonica (International) Limited | Transmission ininterrompue de transmissions par protocole internet au cours de changement de points d'extrémité |
| US20110074912A1 (en) * | 2009-09-28 | 2011-03-31 | Mock Wayne E | Providing an Indication of a Videoconference by a Videoconferencing Device |
| US9668166B2 (en) * | 2013-02-05 | 2017-05-30 | Qualcomm Incorporated | Quality of service for web client based sessions |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2138627A1 (fr) * | 1993-12-23 | 1995-06-24 | Timothy L. Smokoff | Methode et systeme de lancement de programmes d'application sur un serveur d'applications |
| GB2310970A (en) * | 1996-03-05 | 1997-09-10 | Ibm | Voice mail on the Internet |
| US6751221B1 (en) * | 1996-10-04 | 2004-06-15 | Kabushiki Kaisha Toshiba | Data transmitting node and network inter-connection node suitable for home network environment |
| DE69816594T2 (de) * | 1997-02-20 | 2004-06-03 | Hewlett-Packard Co. (N.D.Ges.D.Staates Delaware), Palo Alto | Diensstelle zur lieferung von telekommunikationsdiensten |
| US6144671A (en) * | 1997-03-04 | 2000-11-07 | Nortel Networks Corporation | Call redirection methods in a packet based communications network |
| US6134589A (en) * | 1997-06-16 | 2000-10-17 | Telefonaktiebolaget Lm Ericsson | Dynamic quality control network routing |
| JP3680522B2 (ja) * | 1997-11-13 | 2005-08-10 | カシオ計算機株式会社 | コミュニケーションシステム、同システムに用いられる電話補助装置及び電話装置 |
| JPH11252154A (ja) * | 1997-12-03 | 1999-09-17 | Toshiba Corp | マルチメディア情報通信システムとその通信インタフェース装置 |
-
1999
- 1999-10-04 FR FR9912352A patent/FR2799326B1/fr not_active Expired - Fee Related
-
2000
- 2000-10-02 EP EP00966252A patent/EP1135893A1/fr not_active Ceased
- 2000-10-02 JP JP2001529144A patent/JP4993832B2/ja not_active Expired - Fee Related
- 2000-10-02 US US09/857,339 patent/US7079526B1/en not_active Expired - Lifetime
- 2000-10-02 WO PCT/FR2000/002725 patent/WO2001026301A1/fr not_active Application Discontinuation
- 2000-10-02 AU AU76702/00A patent/AU7670200A/en not_active Abandoned
- 2000-10-02 CA CA002352988A patent/CA2352988A1/fr not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| JP4993832B2 (ja) | 2012-08-08 |
| EP1135893A1 (fr) | 2001-09-26 |
| JP2003511768A (ja) | 2003-03-25 |
| US7079526B1 (en) | 2006-07-18 |
| FR2799326B1 (fr) | 2001-12-28 |
| AU7670200A (en) | 2001-05-10 |
| WO2001026301A1 (fr) | 2001-04-12 |
| FR2799326A1 (fr) | 2001-04-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2352988A1 (fr) | Protocole de lancement d'une application logicielle a distance et de reservation de ressources reseau avec qualite de service | |
| EP1665661B1 (fr) | Procede de differenciation de la qualite de service dans les reseaux de communication mobile en mode paquets | |
| CA2030685C (fr) | Procede de gestion des flux dans un reseau numerique de telecommunication a integration de services, a large bande, et reseau pour la mise en oeuvre de ce procede | |
| EP1964363B1 (fr) | Procédé de transfert de flux de communication | |
| EP0798944B1 (fr) | Réseau local d'accès à des mobiles | |
| EP1616450B1 (fr) | Procede de controle du transfert entre reseau umts et gsm d' une demande de service en telephonie mobile et dispositif de controle correspondant | |
| EP1517471A1 (fr) | Procédé de gestion d'un jeton dans un reseau de telecommunication | |
| EP1211886B1 (fr) | Dispositif de transfert d'un flux de données et procédé associé | |
| FR2977105A1 (fr) | Serveur d'application apte a controler une conference telephonique | |
| FR2858504A1 (fr) | Procede et systeme de transmission de donnees a haut debit et a qualite de service predeterminee dans un reseau de telecommunications | |
| EP1854272B1 (fr) | Terminal pour reseau de communication, adapte pour entrer en conference | |
| EP1936934A1 (fr) | Procédé de diffusion d'un flux depuis une plate-forme de service, produit programme d'ordinateur et plate-forme de service correspondants | |
| WO2004100492A1 (fr) | Procede et dispositif de synchronisation de flux de donnees | |
| EP1542424A1 (fr) | Système et procédé de partage de données entre des terminaux WAP | |
| FR3131815A1 (fr) | Procédé, dispositif et système de modification d’une infrastructure de communication | |
| FR2699034A1 (fr) | Installation de télécommunications à capacité visiophonique. | |
| WO2019207229A1 (fr) | Procédé et système de détection d'interruption de com-munications et de rétablissement automatique des communications | |
| WO2004016025A2 (fr) | Systeme de telecommunication, et serveur et terminal pour ce systeme | |
| FR2851386A1 (fr) | Systeme et procede d'acces a un reseau de donnees haut-debit par liaison haut-debit de type x-dsl | |
| FR2701793A1 (fr) | Réservation de débit dans un réseau à transfert temporel asynchrone. | |
| EP1195970A2 (fr) | Equipment de télécommunication permettant la migration du controle d'appel | |
| WO2007074308A1 (fr) | Procede et systeme de connexion a un service | |
| FR2870417A1 (fr) | Terminal de telecommunication pour reseau a integration de services rnis | |
| FR2870419A1 (fr) | Procede d'etablissement d'une communication par l'intermediaire d'un reseau rnis et installation de telecommunication correspondante | |
| FR2782221A1 (fr) | Plate-forme pedagogique reconfigurable de reseau commute, commutateur pedagogique et dispositif de support des fonctions materielles correspondants |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |