Brevet FR2821704A1 — publié le 20020906

La présente invention concerne un dispositif permettant aux applications Internet et aux logiciels informatiques des ordinateurs ou des terminaux de télécommunication de solliciter à la demande le débit et la qualité de service des connexions de transmission nécessaires pour supporter les applications multimédia. Ces dernières comportent plusieurs composants média synchronisés de type audio, vidéo et données. La présente invention permet de garantir et de surveiller la qualité des connexions établies pendant toute la durée de connexions demandée par les utilisateurs. La présente invention est particulièrement adaptée aux logiciels informatiques utilisateurs des interfaces WINSOCK2 (marque déposée) des systèmes opératoires de WINDOWS (marque déposée) tels que WINDOWS 95 (marque déposée), WINDOWS NT4.0 (marque déposée), WINDOWS 98 (marque déposée), WINDOWS 2000 (marque déposée), WINDOWS Millenium (marque déposée) et des interfaces SOCKET des systèmes opératoires d'UNIX (marque déposée) et de LINUX (marque déposée). Elle est également adaptée aux terminaux de télécommunication dédiés aux services tels que la vidéo téléphonie ou la vidéo conférence. Les applications multimédia Internet n'ont pas de possibilité traditionnellement de solliciter à la demande le débit et la qualité de service de transmission pour que les composants média de type audio, vidéo et données soient transmis avec la qualité requise par les utilisateurs. Les réseaux Internet utilisent le mode de transport IP qui exclut la possibilité de supporter la demande de débit et la qualité de service de transmission à la demande. Le dispositif selon l'invention s'appuie sur la technologie de transport dite de mode de transfert asynchrone (MTA). Le mode de transport MTA permet d'offrir le débit et la qualité de service de bout en bout et à la demande entre deux ou plusieurs terminaux multimédia à travers les moyens de signalisation Q. 2931 ou UNI3. 1 normalisés par l'Union Internationale des Télécommunications et par le Forum de MTA. Le dispositif selon l'invention permet de remédier à cet inconvénient en ouvrant une interface de commandes entre les logiciels d'application multimédia Internet et les fonctions de transport garantissant le débit et la qualité de service demandés par l'utilisateur. Le but de l'invention est donc de définir un dispositif d'interfaçage entre les applications multimédia Internet et les logiciels informatiques suivant les protocoles d'interface définis ci-dessous par l'invention. Les dessins annexés illustrent le dispositif d'interface de l'invention : La figure 1 représente l'architecture générale des réseaux cibles visés par l'invention. Elle comporte d'un côté les ordinateurs ou les terminaux de télécommunication (OTT) raccordés aux réseaux Internet ou de télécommunication à travers un ou plusieurs multiplexeurs ou concentrateurs (MUX/CONC) lesquels se raccordent aux brasseurs ou commutateurs MTA (BR/COM). Les réseaux Internet ou de télécommunication comportent plusieurs serveurs d'Appel (SERVAP) jouant les rôles de contrôleurs de qualité de service des connexions. La figure 2 représente le dispositif d'interface entre les applications multimédia Internet et la fonction de transport (FT) permettant de supporter les demandes de débit de transmission et de la qualité de service à la demande. La fonction de transport (FT) s'interface avec les fonctions d'un agent d'appel (AA) et les fonctions d'un serveur de connexion de la couche d'adaptation du mode de transfert asynchrone (SCAAL). En référence à ces dessins, le dispositif de l'invention comporte trois interfaces : Une interface entre les applications multimédia Internet et la fonction de transport (FT) (1). Cette interface possède trois types de commandes. Les commandes d'enregistrement, les commandes d'appel et les commandes de connexion. Une interface entre la fonction de transport (FT) et l'agent d'appel (AA) (2). Cette interface possède les primitives suivantes : SETUP-REQ, SETUP-IND, SETUP-CONF, CONNECT, RELEASE-REQ, RELEASE-CONF. Une interface entre la fonction de transport (FT) et le serveur de connexion AAL (SCAAL) (3). Cette interface possède les primitives de connexion suivantes : BINDVCC, UNBINDVCC, AAL-ESTABLISH-Request, AAL-ESTABLISH-Indication, AAL-ESTABLISH-Confirm, AAL-DATA-Request, AAL-DATAIndication, AAL-UNITDATA-Request, AAL-UNITDATA-Indication, ALL-RELEASE-Request, AAL-RELEASE-Indication, AAL-RELEASEConfirm. Dans la forme de réalisation selon la figure 1, la demande de débit et de la qualité de service pour une connexion donnée est traitée par l'ordinateur ou le terminal de télécommunication. Cette demande est transmise aux serveurs d'appels au moyen des protocoles de signalisation transportés par une connexion virtuelle MTA ou par une connexion virtuelle de type TCP sur IP. Les serveurs d'appels traitent alors la demande de connexions formulée par le terminal demandeur vers un ou plusieurs terminaux demandés. L'établissement des connexions entre les terminaux est réalisé par les commandes d'établissement de connexion entre les serveurs d'appels et les commutateurs MTA. Les ordinateurs ou les terminaux de télécommunication font partie du plan de numérotage qui peut être IP version 4, IP version 6, NSAP ou E. 164. Dans la réalisation selon la figure 2, pour un ordinateur ou un terminal de télécommunication plusieurs applications multimédia Internet peuvent exister et jouer le rôle de client et/ou de serveur. Ces applications multimédia Internet utilisent les interfaces offertes par la fonction de transport (FT) (1) pour demander le débit et la qualité de service requis par leurs composants média vidéo, audio ou données. L'interface (1) de la figure 2, comporte trois séries de commandes : les commandes d'enregistrement, les commandes d'appels supportées par l'agent d'appels (AA) et les commandes de connexion supportées par le serveur de connexion AAL (SCAAL). Dans la réalisation des commandes d'enregistrement, les applications multimédia Internet s'enregistrent auprès de la fonction de transport (FT) soit en tant qu'agent d'appel de type demandeur (AMIDR), soit en tant qu'agent d'appel de type demandé (AMIDE). L'application multimédia Internet demandée (AMIDE) s'enregistre pour un ou plusieurs services, chacun défini par un code PORT, définis pour les applications des réseaux Internet. Les agents d'appels demandeur et demandé sont reconnus et adressables suivant le plan de numérotage IP version 4, IP version 6, NSAP ou E. 164. Dans la réalisation des commandes d'appels, une application multimédia Internet demandeur (AMIDR) formule une commande d'appel pour une connexion vers une application multimédia Internet demandée (AMIDE) identifiée par son code PORT en utilisant la primitive SETUP-REQ de l'interface (2) avec les paramètres associés suivants : la référence d'appel et la référence de connexion connues de l'application multimédia Internet demandeur (AMIDR), l'adresse de l'ordinateur ou du terminal de télécommunication demandeur DR (ADRDR), l'adresse de l'ordinateur ou du terminal de télécommunication demandé (ADRDE), le port local de l'application multimédia Internet demandeur (PORTDR), le port local de l'application multimédia Internet demandée (PORTDE), le débit et la qualité de service supportés par le mode de transfert asynchrone, le mode de transport de la couche d'adaptation AAL qui peut être de type sécurisé ou non sécurisé. La fonction de transport (FT) de l'ordinateur ou du terminal de télécommunication demandé (DE) reçoit de son agent d'appel (AA) un indicateur d'appel à travers une primitive SETUP-IND de l'interface (2) signalant une demande d'appel pour une connexion venant d'une application multimédia Internet demandeur d'adresse ADRDR et de port PORTDR. Si l'application multimédia Internet demandée (AMIDE) accepte la connexion, elle transmet une commande d'appel vers la fonction de transport (FT) qui génère la primitive CONNECT de l'interface (2) vers l'application multimédia Internet demandeur (AMIDR) et invoque une commande de connexion vers la fonction de transport (FT) qui génère une primitive BINDVCC de l'interface (3) vers son serveur de connexion AAL local (SCAALDE). si l'application multimédia Internet demandée (AMIDE) n'accepte pas la connexion, elle transmet une commande d'appel vers la fonction de transport FT qui génère la primitive RELEASE-REQ de l'interface (2) vers l'application multimédia Internet demandeur (AMIDR), auquel cas l'appel pour cette connexion se termine. L'acceptation de la connexion par l'application multimédia Internet demandée (AMIDE) est signalée par une indication SETUP-CONF du côté de l'ordinateur ou du terminal de télécommunication demandeur (DR) auquel cas l'application multimédia Internet demandeur (AMIDR) invoque une commande de connexion vers la fonction de transport (FT) qui génère une primitive BINDVCC de l'interface (3) vers son serveur de connexion AAL local (SCAALDR). Dans la réalisation de la primitive BINDVCC de l'interface (3), les paramètres suivants sont obligatoires : les références de l'appel et de la connexion AAL, le type de AAL, les références de la connexion virtuelle MTA (VPCI, VCI), les débits et la qualité de service négociés pendant la phase d'appel. Dans le cas où la connexion établie nécessite un mode de transport sécurisé contre les pertes de cellules MTA ou les trames AAL, la fonction de transport (FT) invoque vers le serveur de connexion AAL les primitives AAL-ESTABLISHRequest, AAL-ESTABLISH-Indication et AAL-ESTABLISH-Confirm de l'interface (3) définis par les recommandations Q. 2130 et Q. 2140 de l'Union Internationale des Télécommunications. Les serveurs de connexion AAL négocient alors l'établissement du mode de transport sécurisé en utilisant les protocoles SSCF et SSCOP définis par les recommandations Q. 2110, Q. 2130 et Q. 2140 de l'Union Internationale des Télécommunications. Pendant la phase de transfert des données entre les applications multimédia Internet demandeur et demandé, suite à la phase d'établissement des connexions illustrée ci-dessus, les primitives DATA-Request et DATA-Indication de l'interface (3) sont utilisées dans le cas du mode de transport sécurisé et les primitives UNITDATA-Request et UNITDATA-Indication de l'interface (3) sont utilisées dans le cas du mode de transport non sécurisé. L'indication de relâchement de connexion et d'appel est signalée par le signal RELEASE-IND de l'interface (2) -,, .,. > -,., - ;.,...,', : généré par l'agent d'appel vers la fonction de transport (FT) et les applications multimédia Internet impliquées dans l'appel. Dans le cas du mode de transport sécurisé la fonction de Transport (FT) invoque les primitives AALRELEASE-Request, AAL-RELEASE-Indication et AAL-RELEASEConfirm de l'interface (3) vers son serveur de connexion AAL local, pour relâcher le mode de transport sécurisé. Finalement, la fonction de transport (FT) génère la primitive UNBINDVCC de l'interface (3) vers son serveur de connexion AAL local, pour relâcher les ressources MTA locales allouées lors de l'opération BINDVCC. Dans la réalisation de la primitive UNBINDVCC de l'interface (3), les paramètres suivants sont obligatoires : les références de l'appel et de la connexion AAL. Le dispositif de l'invention est particulièrement destiné aux applications de type abonnement aux films ou séquences vidéo à la demande entre un utilisateur et un serveur de film vidéo ; aux applications de diffusion des programmes de télévision numérique entre une station de télévision et une zone géographique visée par la station ; aux applications de type vidéo et audio interactif et interpersonnel entre deux ou plusieurs personnes ; aux applications de jeux interactifs entre plusieurs joueurs sur les réseaux Internet nécessitant un temps de réaction très court. Sous le système d'exploitation WINDOWS (marque déposée), les applications multimédia Internet utilisent les interfaces WINSOCK2 (marque déposée). En implémentant les fonctions de transport (FT) selon l'invention comme protocole de transport de base de WINSOCK2 (marque déposée), les applications multimédia Internet peuvent alors bénéficier des moyens pour demander le débit et la qualité de service à la demande au mode de transfert asynchrone. Cette réalisation est illustrée par la figure 3 dans le cas où la fonction de transport (FT) s'interface directement avec les programmes de service WS2-32. DLL. Elle peut être implémentée par la variante illustrée par la figure 4, où la fonction de transport (FT) s'interface avec les programmes de service WS2-32. DLL via le protocole de transport intermédiaire LSP. DLL. REVENDICATIONS (l) Dispositif permettant aux applications Internet et aux logiciels informatiques des ordinateurs ou des terminaux de télécommunication de solliciter à la demande le débit et la qualité de service de transmission de bout en bout nécessaires pour supporter les applications multimédia Internet caractérisé en ce qu'il comporte une interface entre les applications multimédia Internet et les fonctions de transport supportant les primitives de demande d'appel pour une connexion MTA et les primitives de serveur de connexion de la couche d'adaptation AAL. (2) Dispositif selon la revendication 1 caractérisé en ce qu'il comporte trois interfaces, une interface entre les applications multimédia Internet et la fonction de Transport (FT) (1), une interface entre la fonction de transport (FT) et l'agent d'appel (AA) (2), une interface entre la fonction de transport (FT) et le serveur de connexion AAL (SCAAL) (3). (3) Dispositif selon la revendication 1 et la revendication 2 caractérisé en ce que l'interface (1) de la figure 2, comporte trois séries de commandes : les commandes d'enregistrement, les commandes d'appels et les commandes de connexion AAL. (4) Dispositif selon la revendication 3 caractérisé en ce que l'interface des commandes de connexion AAL permet d'établir des connexions de transport sécurisé ou non sécurisé contre les pertes des cellules MTA ou des trames AAL. (5) Dispositif selon la revendication 1, la revendication 2, la revendication 3 et la revendication 4, caractérisé en ce qu'il est utilisable, selon les figures 3 et 4, par les logiciels informatiques utilisateurs des interfaces WINSOCK2 (marque déposée), des systèmes d'exploitation de WINDOWS (marque déposée) tels que WINDOW 95 (marque déposée), WINDOWS NT4.0 (marque déposée), WINDOWS 98 (marque déposée), WINDOWS 2000 (marque déposée), WINDOWS Millenium (marque déposée) et des interfaces SOCKET des systèmes opératoires d'UNIX (marque déposée) et de LINUX (marque déposée). (6) Dispositif selon la revendication 1, la revendication 2, la revendication 3, la revendication 4 et la revendication 5 caractérisé en ce qu'il est particulièrement destiné aux applications de type diffusion sélective des films ou de séquences vidéo à la demande entre un utilisateur et un serveur de films vidéo ; aux applications de diffusion des programmes de télévision numérique entre une station de télévision et une zone géographique visée par la station ; aux applications de type vidéo et audio interactif et interpersonnel entre deux ou plusieurs personnes ; aux applications de jeux interactifs entre plusieurs joueurs sur les réseaux Internet nécessitant un temps de réaction très court.