WO2011121236A1 - Procede et dispositif de notification d'un terminal dans un reseau - Google Patents

Procede et dispositif de notification d'un terminal dans un reseau Download PDF

Info

Publication number
WO2011121236A1
WO2011121236A1 PCT/FR2011/050709 FR2011050709W WO2011121236A1 WO 2011121236 A1 WO2011121236 A1 WO 2011121236A1 FR 2011050709 W FR2011050709 W FR 2011050709W WO 2011121236 A1 WO2011121236 A1 WO 2011121236A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
notification
stun
service
network
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.)
Ceased
Application number
PCT/FR2011/050709
Other languages
English (en)
Inventor
Erwan Le Ber
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of WO2011121236A1 publication Critical patent/WO2011121236A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H04L61/2575—NAT traversal using address mapping retrieval, e.g. simple traversal of user datagram protocol through session traversal utilities for NAT [STUN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H04L61/2578—NAT traversal without involvement of the NAT server
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/544—Remote

Definitions

  • the present invention relates to a method and a device for notifying a terminal in a network. It applies, in particular, to the notification of terminals present in a private network that are connected to an Internet gateway.
  • Notifications allow applications running on terminals in a private network to receive data from a server on the public network.
  • Query notifications allow applications to be notified when the data changes. This feature is particularly useful for applications that provide information caching from a database, such as an application of the Web ("Web"), and which must be notified if the source data changes.
  • Web Web
  • the notification request specifies the notification options, including the name of the service, the message text, and the timeout value to the server. Notifications are delivered through a queue that can be queried by applications to detect available notifications.
  • notification subscriptions are longer than the processes that initialize them. This is because an application can create a subscription to notifications and then terminate.
  • the subscription remains valid, and notification occurs if the data is changed within the specified timeout specified at the time of subscription creation.
  • a notification is identified by the executed query, the notification options, and the message text, and can be canceled by setting the timeout value to 0.
  • Notifications are sent once. For continuous notification of data changes, a new subscription must be created by running the query again after each notification is processed.
  • An address translation function (or NAT for Network Address Translation) allows the passage of the private network to the public network.
  • home gateway for example a "box”
  • home gateway for example a "box”
  • this function is not controlled on all the residential gateways of the market, in particular to be set to day.
  • the present invention aims to remedy these disadvantages.
  • the present invention aims at a method of notifying a terminal on a network by services hosted on service platforms, characterized in that it comprises:
  • a step of mutualizing a STUN link function between service clients hosted by said terminal by communicating the same public connection information of the STUN link function to the platforms hosting the services, in order to notify several service providers of this terminal with the same function of STUN binding and
  • a step of notification by an operator network by transmitting notifications of the services to a single point of entry of the operator network to said terminal, said entry point corresponding to the public connection information and implementing said shared STUN link function for the services.
  • the mutualization step includes a STUN link request step during which the terminal sends a STUN link request to a notification manager, a response step, during which the notification manager transmits a STUN link response to the terminal and a transmission step, during which the terminal transmits to a service platform, said public connection information including address identifiers on the network, port maintained open by the Notification and Service Manager.
  • the service platform transmits to the notification manager a relay message identifying the address on the network, the port kept open and a message to be relayed.
  • the service platform thus implements a single access to the different services of the terminal.
  • the notification manager hosts a STUN server function that allows it to contact the terminal.
  • the impact of the use of STUN is minimized for all services having a need to reach a terminal at the customer's location at any time.
  • pooling a "binding" STUN binding function the size of all the equipment crossed is reduced because the STUN protocol has a very heavy traffic profile for firewalls in particular.
  • a platform of services needing to join a terminal passes through the notification manager and the terminal port maintained by said notification manager.
  • the service platform thus implements a single access to the different services of the terminal.
  • a message is implemented, the content of which is the information to be transmitted to the terminal or a wake-up message from the terminal enabling the terminal to configure itself for an exchange of messages.
  • the present invention aims at a device for notifying a terminal on a network by services hosted on service platforms, characterized in that it comprises:
  • a means for pooling a STUN link function between service clients hosted by said terminal by communicating the same public connection information of the STUN link function to the platforms hosting the services, in order to notify several service clients of this terminal with the same function of STUN binding and
  • a means for notification by an operator network by transmitting service notifications to a single point of entry of the operator network to said terminal, said entry point corresponding to the public connection information and implementing said shared STUN link function for the services.
  • the present invention aims a server adapted to implement the notification method object of the present invention, as succinctly described above.
  • the present invention is directed to a computer program loadable into a computer system, said program containing instructions enabling the implementation of the method which is the subject of the present invention, as briefly described above.
  • the present invention aims at a support for information readable by a computer or a microprocessor, removable or not, retaining instructions of a computer program, characterized in that it allows the implementation of the method object of the present invention as succinctly set forth above.
  • FIG. 1 represents, schematically, a network architecture implementing a first embodiment of the computer network object of the present invention
  • FIG. 2 represents, in the form of a logic diagram, the steps implemented by elements illustrated in FIG. 1, in a first embodiment of the method that is the subject of the present invention
  • FIG. 3 schematically shows communications between network components and a terminal for an application of the present invention to a notification of a decoder.
  • STUN is a client-server protocol of the IETF (RFC 3489) allowing a client, in particular a UDP client (acronym for "User Datagram Protocol" for user datagram protocol), located behind a NAT router, or multiple NATs, to discover its public IP address, the type of NAT router behind which it is and the Internet port associated with the NAT router to a particular local port.
  • UDP client ancronym for "User Datagram Protocol" for user datagram protocol
  • This information is exchanged to correctly exchange UDP data with the outside of a network implementing the NAT. Indeed, during the establishment of a session, customers exchange messages specifying the IP address and the port to use to transmit data.
  • STUN located on the public side of a NAT router, allows the client to discover his public IP address and thus transmit correct information, and not his private address, which would not allow him to receive data. Note that STUN does not work with symmetric NATs and that a STUN server listens, in principle, port 3478.
  • This non-adhering protocol to the Internet gateway requires instantiating the exchanges for each service, which represents an impact on the sizing.
  • FIG. 1 shows a computer network 10, a gateway 15, a private network 75, a terminal 20, a service platform 25 comprising servers 30 and 35 provided with 40 and 45, a notification manager (“notification enabler") 55 comprising a server STUN 60 and firewalls 65 and 70, another service platform 50.
  • notification enabler a notification manager
  • the computer network 10 is, typically, the Internet network.
  • the gateway 15 is, typically, a home gateway ("home gateway"), commonly called “box”.
  • the terminal 20 is, typically a telephony device, a set-top box (NAS) (acronym for "Network Attached Storage” for storage attached to the network).
  • the service platform 25 implements services, for example multimedia, hosted by the servers 30 and 35.
  • the notification manager 55 manages the notifications so that the communications between the terminal 20 and the service platform 25. are efficient, not very complex and use few resources.
  • the implementation of a particular embodiment of the method that is the subject of the present invention in the particular embodiment of the device that is the subject of the present invention illustrated in FIG. 1 comprises, first of all, a step of link request 205 during which the terminal 20 transmits to the notification manager 55, a binding request ("binding request").
  • the notification manager 55 sends a link response to the terminal 20.
  • steps are known in the STUN protocol and serve to maintain an open port on the public interface of the gateway 15 so that the client 20 is reachable from service platforms 25 and 50.
  • the terminal 20 transmits to the service platform 25 public connection information including address identifiers on the network, port maintained open and service.
  • the STUN protocol is a NAT transition solution, just like UPnP IGD, a hosted solution without a residential gateway.
  • the STUN protocol is implemented and the notification manager 55 is informed of the use of this STUN protocol to the detriment of the UPnP IGD protocol, to implement the present invention.
  • the use of the STUN notification manager is indicated to cause a relay message to be sent to the notification manager, rather than to a direct contact.
  • the service platform 25 transmits to the other service platforms 50 a relay message identifying the IP address, the port maintained open and containing the message to be relayed.
  • the other service platforms 50 relay this message to the notification manager 55.
  • the notification manager 55 transmits a light relay message, subset of the relay message 220, to the terminal 20.
  • an architecture and a protocol are defined for sharing a single "binding" STUN per terminal in order to notify several service clients of the same terminal, by adding a manager of notifications in the operator network. This creates a single point of entry to each terminal such as the terminal 20.
  • the notification manager hosts the STUN server function which allows it to subsequently contact the terminal 20 because it is allowed to use the NAT rule created by the STUN binding.
  • the service platform 25 that needs to reach a terminal 20 goes through the notification manager 55, which here has a relay function.
  • This service platform 25 is informed of the public contact address of the terminal 20 by means of another message defined by the service of the terminal requesting an exchange of data with the service platform.
  • the notification manager makes it possible to transfer a message from the service platform 25 to the terminal 20 by reusing the STUN binding.
  • the client wake-up notification in which the transferred message is an alarm clock for a more consequent exchange.
  • the header "To" contains the IP address and the port on which to send the message.
  • the "Content Length" header allows the notification manager to check the integrity of the message.
  • the "Service" header identifies the software client to which the remainder of the incoming message is transferred to the terminal 20.
  • FIG. 3 gives an example for the notification on television decoders.
  • the STUN server 60 exchanges with the STUN client 110 the link requests and responses 140 (see steps 205 and 210).
  • the client STUN 110 which mutualizes a link function between clients 115 to 130 of services hosted by the terminal 20, makes it possible to notify several service clients of this terminal with the same function.
  • the STUN client 110 transmits the messages 145 to the clients 115 to 130 according to the service headers of these messages.
  • An ACS function 150, the Tr-069 130 and the UDP connection request 160 illustrate an example of use of the invention (applied to device management).
  • An example of a concrete application of the invention is the deployment of convergent internet television offers involving numerous notifications of other services (after-sales service, configuration, call notification, recording programming, updating of television program, ...)

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Le procédé de notification d'un terminal sur un réseau comporte : une étape de mutualisation d'une fonction de liaison entre clients de services hébergés par ledit terminal, afin de notifier plusieurs clients de service de ce terminal avec la même fonction; et une étape de notification par un réseau d'opérateur mettant en œuvre un point d'entrée unique vers ledit terminal, ledit point d'entrée mettant en œuvre ladite fonction de liaison. Dans des modes de réalisation, au cours de l'étape de notification, la plate-forme de services transmet à un gestionnaire de notifications un message relais identifiant l'adresse sur le réseau, un port maintenu ouvert par le gestionnaire de notifications et un message à relayer.

Description

Procédé et dispositif de notification d'un terminal dans un réseau
La présente invention concerne un procédé et un dispositif de notification d'un terminal dans un réseau. Elle s'applique, en particulier, à la notification de terminaux présents dans un réseau privé qui sont connectés à une passerelle Internet.
Les notifications permettent aux applications fonctionnant sur des terminaux d'un réseau privé de recevoir des données d'un serveur présent sur le réseau public. Les notifications de requêtes permettent aux applications d'être notifiées en cas de modification des données. Cette fonctionnalité est particulièrement utile pour les applications qui fournissent un cache d'informations à partir d'une base de données, par exemple une application de la toile (« Web »), et qui doivent être notifiées en cas de modification des données sources.
La demande de notification spécifie les options de notification, notamment le nom du service, le texte du message et la valeur du délai d'attente au serveur. Les notifications sont remises par l'intermédiaire d'une file d'attente qui peut être interrogée par les applications pour détecter les notifications disponibles.
La durée de vie des abonnements aux notifications est supérieure à celle des processus qui les initialisent. Cela s'explique par le fait qu'une application peut créer un abonnement aux notifications, puis se terminer. L'abonnement reste valide, et la notification a lieu si les données sont modifiées dans le délai d'attente imparti spécifié au moment de la création de l'abonnement. Une notification est identifiée par la requête exécutée, les options de notification et le texte du message, et peut être annulée en attribuant la valeur 0 au délai d'attente.
Les notifications sont envoyées une seule fois. Pour une notification continue des modifications de données, un nouvel abonnement doit être créé en exécutant à nouveau la requête une fois chaque notification traitée.
Une fonction de translation d'adresse (ou NAT pour « Network Address Translation ») permet de faire le passage du réseau privé vers le réseau publique. Il existe plusieurs types de fonction de translation d'adresse. Pour chaque type, une règle est créée quand un message est émis vers l'extérieur, cette règle ayant une certaine durée de vie. La distinction entre ces types de fonction se situe au niveau des règles permettant à un message de rentrer dans le réseau privé à la suite d'un message sortant :
- dans le type « Full Cone NAT », on ne met en œuvre aucune règle de filtrage sur la source du paquet entrant sur le réseau privé,
- dans le type « Restricted Cone NAT », pour rentrer sur le réseau privé, un message doit provenir de l'adresse de destination IP (acronyme de « internet Protocol ») du message qui a créé la règle et
- dans le type « Port Restricted Cone NAT », pour rentrer sur le réseau privé, un message doit provenir de l'adresse IP et du port destination du message qui a créé la règle.
Aujourd'hui, la mise en œuvre de la fonction de translation d'adresse nécessite : . - une fonction dans la passerelle Internet ou
- une fonction par service mis en œuvre conjointement par les terminaux présents sur le réseau privé (« clients ») et par des plates-formes de services présents sur le réseau public (« serveurs »).
Héberger ia fonction dans la passerelle résidentielle ou domestique (« home gateway »), par exemple une « box », présente l'inconvénient que cette fonction n'est pas maîtrisée sur l'ensemble des passerelles résidentielles du marché, notamment pour être mises à jour.
On connaît aussi un protocole non adhérent à la passerelle Internet, c'est-à-dire qui ne dépend pas de cette passerelle. Ce protocole nécessite d'instancier les échanges pour chaque service, ce qui représente un impact sur le dimensionnement. Cette solution, connue sous le nom de « STUN » (acronyme de « Session Traversai Utilities for NAT rfc 5389 » pour utilitaires de traversée de session pour NAT rfc 5389) met en œuvre une fonction de liaison (ou « binding ») qui consiste en un échange de requêtes et de réponses pour maintenir un port ouvert sur l'interface publique de la passerelle domestique afin qu'elle soit joignable depuis des plate-formes de services. Cette solution nécessite une fonction de liaison, appelée « binding », par service.
Ainsi, les solutions connues dans l'art antérieur sont complexes et/ou onéreuses en termes de ressources.
La présente invention vise à remédier à ces inconvénients.
A cet effet, selon un premier aspect, ia présente invention vise un procédé de notification d'un terminal sur un réseau par des services hébergés sur des plateformes de services, caractérisé en ce qu'il comporte :
- une étape de mutualisation d'une fonction de liaison STUN entre clients de services hébergés par ledit terminal par communication d'une même information de connexion publique de la fonction de liaison STUN aux plateformes hébergeant les services, afin de notifier plusieurs clients de services de ce terminal avec la même fonction de liaison STUN et
- une étape de notification par un réseau d'opérateur par transmission de notifications des services vers un point d'entrée unique du réseau d'opérateur vers ledit terminal, ledit point d'entrée correspondant à l'information de connexion publique et mettant en œuvre ladite fonction de liaison STUN mutualisée pour les services.
Grâce à ces dispositions, on s'affranchit des contraintes liées au passage d'un réseau privé à un réseau public, sans adhérence à la passerelle internet et de manière scalable, ou adaptable, pour l'opérateur.
Selon des caractéristiques particulières, l'étape de mutualisation comporte une étape de requête de liaison STUN au cours de laquelle le terminal émet une requête de liaison STUN à destination d'un gestionnaire de notifications, une étape de réponse, au cours de laquelle, le gestionnaire de notifications émet une réponse de liaison STUN à destination du terminal et une étape de transmission, au cours de laquelle le terminal transmet à une plate-forme de services, ladite information de connexion publique comportant des identifiants d'adresse sur le réseau, de port maintenu ouvert par le gestionnaire de notifications et de service. On bénéficie ainsi, par exemple, des avantages de la fonction de binding STUN. Ainsi, la plate-forme de services est informée de l'adresse publique de contact du terminal par le biais d'un message défini par le service du terminal requérant un échange de données avec ia plateforme de service.
. Selon des caractéristiques particulières, au cours de l'étape de notification, la plateforme de services transmet au gestionnaire de notifications un message relais identifiant l'adresse sur le réseau, le port maintenu ouvert et un message à relayer.
La plate-forme de services met ainsi en œuvre un accès unique aux différents services du terminal.
Selon des caractéristiques particulières, le gestionnaire de notifications héberge une fonction de serveur STUN qui lui permet de contacter le terminal.
Grâce à la mise en œuvre de la présente invention, on minimise l'impact de l'utilisation de STUN pour tous les services ayant un besoin de joindre à tout moment un terminal chez le client. En mutualisant une fonction de liaison « binding » STUN, on réduit le dimensionnement de tous les équipements traversés car le protocole STUN présente un profil de trafic très lourd pour les coupe-feux notamment.
Selon des caractéristiques particulières, une plate-forme de services ayant besoin de joindre un terminal passe par le gestionnaire de notifications et le port du terminal maintenu ouvert par ledit gestionnaire de notifications. La plate-forme de services met ainsi en œuvre un accès unique aux différents services du terminal.
Selon des caractéristiques particulières, au cours de l'étape de notification, on met en œuvre un message dont le contenu est l'information à transmettre au terminal ou un message de réveil du terminal permettant au terminal de se configurer pour un échange de messages.
Selon un deuxième aspect, la présente invention vise un dispositif de notification d'un terminal sur un réseau par des services hébergés sur des plateformes de services, caractérisé en ce qu'il comporte :
- un moyen de mutualisation d'une fonction de liaison STUN entre clients de services hébergés par ledit terminal par communication d'une même information de connexion publique de la fonction de liaison STUN aux plateformes hébergeant les services, afin de notifier plusieurs clients de services de ce terminal avec la même fonction de liaison STUN et
- un moyen de notification par un réseau d'opérateur par transmission de notifications des services vers un point d'entrée unique du réseau d'opérateur vers ledit terminal, ledit point d'entrée correspondant à l'information de connexion publique et mettant en œuvre ladite fonction de liaison STUN mutualisée pour les services.
Selon un troisième aspect, la présente invention vise un serveur adapté à mettre en œuvre le procédé de notification objet de la présente invention, tel que succinctement exposé ci- dessus.
Selon un quatrième aspect, ia présente invention vise un programme d'ordinateur chargeable dans un système informatique, ledit programme contenant des instructions permettant la mise en œuvre du procédé objet de la présente invention, tel que succinctement exposé ci- dessus.
Selon un cinquième aspect, la présente invention vise un support d'informations lisibles par un ordinateur ou un microprocesseur, amovible ou non, conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en œuvre du procédé objet de la présente invention, tel que succinctement exposé ci-dessus.
Les avantages, buts et caractéristiques de ce dispositif, de ce serveur, de ce programme d'ordinateur et de ce support d'information étant similaires à ceux du procédé objet de la présente invention, tel que succinctement exposés ci-dessus, ils ne sont pas rappelés ici.
D'autres avantages, buts et caractéristiques de la présente invention ressortiront de la description qui va suivre faite, dans un but explicatif et nullement limitatif, en regard des dessins annexés, dans lesquels :
- la figure 1 représente, schématiquement, une architecture de réseau mettant en œuvre un premier mode de réalisation du réseau informatique objet de la présente invention,
- la figure 2 représente, sous forme d'un logigramme, des étapes mises en œuvre par des éléments illustrés en figure 1, dans un premier mode de réalisation du procédé objet de la présente invention,
- la figure 3 représente, schématiquement, des communications entre des composants du réseau et d'un terminai, pour une application de ia présente invention à une notification d'un décodeur.
Avant de décrire les figures, on rappelle que STUN est un protocole client-serveur de l'IETF (RFC 3489) permettant à un client, notamment un client UDP (acronyme de « User Datagram Protocol » pour protocole de datagramme utilisateur), situé derrière un routeur NAT, ou de multiples NATs, de découvrir son adresse IP publique, le type de routeur NAT derrière lequel il est et le port Internet associé par le routeur NAT à un port local particulier. Ces informations sont échangées pour échanger correctement des données UDP avec l'extérieur d'un réseau mettant en œuvre le NAT. En effet, lors de l'établissement d'une session, les clients s'échangent des messages précisant l'adresse IP et le port à utiliser pour transmettre des données. L'utilisation d'un serveur STUN, situé du côté public d'un routeur NAT, permet au client de découvrir son adresse IP publique et de transmettre ainsi des informations correctes, et non son adresse privée, qui ne lui permettrait pas de recevoir des données. On note que STUN ne fonctionne pas avec les NATs symétriques et qu'un serveur STUN écoute, en principe, ie port 3478.
Ce protocole non adhérant à la passerelle Internet nécessite d'instancier les échanges pour chaque service, ce qui représente un impact sur le dimensionnement. On parle du « binding » STUN qui consiste à un échange de requêtes et réponses pour maintenir un port ouvert sur l'interface publique de la passerelle domestique afin que le client soit joignable depuis des plateformes de services.
On observe, en figure 1, un réseau informatique 10, une passerelle 15, un réseau privé 75, un terminal 20, une plate-forme de services 25 comportant des serveurs 30 et 35 munis de coupe-feu (« firewall ») 40 et 45, un gestionnaire de notifications (« Notification enabler ») 55 comportant un serveur STUN 60 et des coupe-feu 65 et 70, une autre plate-forme de services 50.
Le réseau informatique 10 est, typiquement, le réseau Internet. La passerelle 15 est, typiquement, une passerelle domestique (« home gateway »), couramment appelée « box ». Le terminal 20 est, typiquement un dispositif de téléphonie, un décodeur (« set-top box ») un NAS (acronyme de « Network Attached Storage » pour stockage attaché au réseau). La plate-forme de services 25 met en œuvre des services, par exemple multimédia, hébergés par les serveurs 30 et 35. Le gestionnaire de notification 55 gère les notifications afin que les communications entre le terminal 20 et la plate-forme de service 25. soient efficaces, peu complexes et utilisent peu de ressources.
Comme illustré en figure 2, la mise en œuvre d'un mode de réalisation particulier du procédé objet de la présente invention dans le mode de réalisation particulier du dispositif objet de la présente invention illustré en figure 1 comporte, d'abord, une étape de requête de liaison 205 au cours de laquelle le terminal 20 émet à destination du gestionnaire de notifications 55, une requête de liaison (« binding request »).
Au cours d'une étape 210, le gestionnaire de notifications 55 émet une réponse de liaison à destination du terminal 20. Ces étapes sont connues dans le protocole STUN et servent à maintenir un port ouvert sur l'interface publique de la passerelle 15 afin que le client 20 soit joignable depuis des plate-formes de services 25 et 50.
Au cours d'une étape 215, le terminal .20 transmet à la plate-forme de services 25 une information de connexion publique comportant des identifiants d'adresse sur le réseau, de port maintenu ouvert et de service.
Le protocole STUN est une solution de passage de NAT, au même titre que UPnP IGD, solution hébergée sans passerelle résidentielle. Préférentiellement, on met en œuvre le protocole STUN et on informe le gestionnaire de notifications 55 de l'utilisation de ce protocole STUN au détriment du protocole UPnP IGD, pour mettre en œuvre la présente invention. Ainsi, lors de la remonté de l'information concernant l'adresse IP et le port de connexion, on indique l'usage du gestionnaire de notifications STUN pour provoquer l'envoi d'un message relais vers le gestionnaire de notifications, plutôt qu'un contact direct.
Au cours d'une étape 220, la plate-forme de services 25 transmet aux autres plateformes de service 50 un message relais identifiant l'adresse IP, le port maintenu ouvert et contenant le message à relayer. Au cours de la même étape 220, les autres plate-formes de services 50 relaient ce message au gestionnaire de notifications 55.
Au cours d'une étape 225, le gestionnaire de notification 55 transmet un message relais léger, sous-ensemble du message relais 220, au terminal 20.
Enfin, au cours d'une étape 230, le terminal 20 et la plate-forme de services 25 échangent des données.
Ainsi, dans ce mode de réalisation, en s'appuyant sur le protocole STUN, on définit une architecture et un protocole permettant de mutualiser un seul "binding" STUN par terminal afin de notifier plusieurs clients de service d'un même terminal, en rajoutant un gestionnaire de notifications dans le réseau de l'opérateur. On crée ainsi un point d'entrée unique vers chaque terminal tel que le terminal 20.
Le gestionnaire de notifications héberge la fonction de serveur STUN qui lui permet de contacter, par la suite, le terminal 20, car il est autorisé à utiliser la règle NAT créée par le binding STUN.
La plate-forme de services 25 ayant besoin de joindre un terminal 20 passe par le gestionnaire de notifications 55, qui a ici une fonction de relais. Cette plate-forme de services 25 est informée de l'adresse publique de contact du terminal 20 par ie biais d'un autre message défini par le service du terminal requérant un échange de données avec la plate-forme de service.
Le gestionnaire de notifications permet de transférer un message depuis la plateforme de service 25 vers le terminal 20 en réutilisant le binding STUN.
On note qu'il y a deux cas d'usage :
- la notification simple, dans lequel l'information est dans le message transféré et
- la notification de réveil de client, dans lequel le message transféré est un réveil pour un échange plus conséquent.
On donne, ci-dessous, un exemple de contenu sur le message relai transmis au cours de l'étape 220.
RELAY MESSAGE
To : @IP_CPE : Nated Port
Content length : XXX
Service : [Karma, Call_Notif, PVR, EPG,...]
Service message
Service message L'entête (« header ») « To » contient l'adresse IP et le port sur lequel envoyer le message.
L'entête « Content Length » permet au gestionnaire de notifications de vérifier l'intégrité du message.
L'entête « Service » permet d'identifier le client logiciel à qui transférer le reste du message en arrivée sur le terminal 20.
La figure 3 donne un exemple pour la notification sur des décodeurs de télévision. Le serveur STUN 60 échange avec un client STUN 110 les requêtes et réponses 140 de liaison (voir étapes 205 et 210). Le client STUN 110 qui mutualise une fonction de liaison entre clients 115 à 130 de services hébergés par le terminal 20, permet de notifier plusieurs clients de service de ce terminal avec la même fonction. Le client STUN 110 transmet les messages 145 aux clients 115 à 130 en fonction des entêtes de service de ces messages.
Une fonction ACS 150, le Tr-069 130 et la requête de connexion UDP 160 illustrent un exemple d'utilisation de l'invention (appliquée à la gestion de dispositifs (« device managment »).
Grâce à ce mode de réalisation, on minimise l'impact de l'utilisation de STUN pour tous les services ayant un besoin de joindre à tout moment un terminal chez le client. En mutuaiisant un binding STUN, on réduit le dimensionnement de tous les équipements traversés, car STUN présente un profil de trafic très lourd pour les firewalls notamment.
Un exemple d'application concrète de l'invention est le déploiement des offres de télévision internet convergentes impliquant de nombreuses notifications d'autres services (SAV; Configuration, Notification d'appel, programmation d'enregistrement, mise à jour de programme de télévision, ...)

Claims

REVENDICATIONS
1 , Procédé de notification d'un terminal sur/un réseau par des services hébergés sur des plateformes de services, caractérisé en ce qu'il comporte :
- une étape de mutualisation d'une fonction de liaison STUN entre clients de services hébergés par ledit terminal, par communication d'une même information de connexion publique de la fonction de liaison STUN aux plateformes hébergeant les services, afin de notifier plusieurs clients de services de ce terminal avec la même fonction de liaison STUN et
- une étape de notification par un réseau d'opérateur par transmission de notifications des services vers un point d'entrée unique du réseau d'opérateur vers ledit terminal, ledit point d'entrée correspondant à l'information de connexion publique et mettant en œuvre ladite fonction de liaison STUN mutualisée pour les services.
2. Procédé selon la revendication 1 , dans lequel l'étape de mutualisation comporte une étape de requête de liaison STUN au cours de laquelle le terminal émet une requête de liaison STUN à destination d'un gestionnaire de notifications, une étape de réponse, au cours de laquelle, le gestionnaire de notifications émet une réponse de liaison STUN à destination du terminal et une étape de transmission, au cours de laquelle le terminal transmet à une plate-forme de services, ladite information de connexion publique comportant des identifiants d'adresse sur le réseau, de port maintenu ouvert par le gestionnaire de notifications et de service.
3. Procédé seion la revendication 2, dans lequel, au cours de l'étape de notification, la plate-forme de services transmet au gestionnaire de notifications un message relais identifiant l'adresse sur le réseau, le port maintenu ouvert et un message à relayer.
4. Procédé selon l'une quelconque des revendications 2 ou 3, dans lequel le gestionnaire de notifications héberge une fonction de serveur STUN qui lui permet de contacter ie terminal.
5. Procédé selon l'une quelconque des revendications 2 à 4, dans lequel une plateforme de services ayant besoin de joindre un terminai passe par le gestionnaire de notifications et le port du terminal maintenu ouvert par ledit gestionnaire de notifications.
6. Procédé selon l'une quelconque des revendications 1 à 5, dans lequel, au cours de l'étape de notification, on met en oeuvre un message dont le contenu est l'information à transmettre au terminal ou un message de réveil du terminal permettant au terminal de se configurer pour un échange de messages.
7. Dispositif de notification d'un terminal sur un réseau par des services hébergés sur des plateformes de services, caractérisé en ce qu'il comporte :
- un moyen de mutualisation d'une fonction de liaison STUN entre clients de services hébergés par ledit terminal par communication d'une même information de connexion publique de la fonction de liaison STUN aux plateformes hébergeant les services, afin de notifier plusieurs clients de services de ce terminal avec la même fonction de liaison STUN et - un moyen de notification par un réseau d'opérateur par transmission de notifications des services vers un point d'entrée unique du réseau d'opérateur vers ledit terminai, ledit point d'entrée correspondant à l'information de connexion publique et mettant en œuvre ladite fonction de liaison STUN mutualisée pour ies services.
8. Serveur, caractérisé en ce qu'il est adapté à mettre en œuvre le procédé de notification selon l'une quelconque des revendications 1 à 6.
9. Programme d'ordinateur chargeable dans un système informatique, ledit programme contenant des instructions permettant la mise en œuvre du procédé selon l'une quelconque des revendications 1 à 6.
10. Support d'informations lisibles par un ordinateur ou un microprocesseur, amovible ou non, conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en œuvre du procédé selon l'une quelconque des revendications 1 à 6.
PCT/FR2011/050709 2010-03-31 2011-03-30 Procede et dispositif de notification d'un terminal dans un reseau Ceased WO2011121236A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1052421 2010-03-31
FR1052421 2010-03-31

Publications (1)

Publication Number Publication Date
WO2011121236A1 true WO2011121236A1 (fr) 2011-10-06

Family

ID=43016870

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2011/050709 Ceased WO2011121236A1 (fr) 2010-03-31 2011-03-30 Procede et dispositif de notification d'un terminal dans un reseau

Country Status (1)

Country Link
WO (1) WO2011121236A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113839849A (zh) * 2021-09-22 2021-12-24 天津津航计算技术研究所 一种基于stun的虚拟专用网络架设方法

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
"TR-069 CPE WAN Management Protocol v1.1 Issue 1 Amentment 2", BROADBAND FORUM TECHNICAL REPORT,, no. 1 amendment 2, 1 December 2007 (2007-12-01), pages 1 - 138, XP002493850 *
ANONYMOUS: "Using STUN with the RTC Client API", 5 January 2010 (2010-01-05), pages 1 - 5, XP055003285, Retrieved from the Internet <URL:http://msdn.microsoft.com/en-us/library/ee480771%28d=printer,v=winembedded.60%29.aspx> [retrieved on 20110720] *
ROSENBERG CISCO R MAHY P MATTHEWS UNAFFILIATED D WING CISCO J: "Session Traversal Utilities for NAT (STUN); rfc5389.txt", SESSION TRAVERSAL UTILITIES FOR NAT (STUN); RFC5389.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARD, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, 1 October 2008 (2008-10-01), XP015060362 *
THOMAS KING: ""JSTUN" - Java Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translation (NAT)", 22 May 2009 (2009-05-22), pages 1 - 2, XP055003286, Retrieved from the Internet <URL:http://jstun.javawi.de/> [retrieved on 20110720] *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113839849A (zh) * 2021-09-22 2021-12-24 天津津航计算技术研究所 一种基于stun的虚拟专用网络架设方法

Similar Documents

Publication Publication Date Title
FR2925247A1 (fr) Controle de l&#39;interfac d&#39;emission d&#39;un message de reponse sip
EP2051477B1 (fr) Procédé de traversée d&#39;équipement de traduction d&#39;adresses pour messages de signalisation SIP par utilisation temporaire du protocole de transport TCP
JP2020528189A (ja) プロキシを用いてセキュアデバイスとアンセキュアデバイスとの間を通信するシステム及び方法
CN101473597A (zh) 远程访问通用即插即用装置的方法和系统
EP1782608A1 (fr) Procede et systeme de localisation d&#39;utilisateurs pour les services bases sur les protocoles sip ou h.323 avec attribution d&#39;adresse ip dynamique.
WO2009125158A2 (fr) Procede de routage d&#39;un paquet de donnees dans un reseau et dispositif associe
EP3476108B1 (fr) Procédé, programme d&#39;ordinateur et dispositif de fourniture d&#39;une adresse par un dispositif à gérer d&#39;un réseau
EP2210396B1 (fr) Système d&#39;interconnexion entre au moins un appareil de communication et au moins un système d&#39;information distant et procédé d&#39;interconnexion
EP4132177A1 (fr) Procédé d&#39;acheminement de données d&#39;une session initialisée entre un terminal et un serveur
EP2055082A1 (fr) Procédé de gestion d&#39;une session de transfert sécurisée au travers d&#39;un dispositif de translation d&#39;adresse, serveur et programme d&#39;ordinateur correspondants
FR3058015A1 (fr) Procede de controle dynamique et interactif d&#39;une passerelle residentielle connectee a un reseau de communication, dispositif et programme d&#39;ordinateur correspondants
WO2011121236A1 (fr) Procede et dispositif de notification d&#39;un terminal dans un reseau
FR3023093A1 (fr) Procede d&#39;autorisation d&#39;etablissement d&#39;un flux pair a pair dans un reseau de telecommunications mobile
WO2015059128A1 (fr) Protocole de sélection d&#39;élément de réacheminement pour un réseau et dispositif cpe correspondant
EP3619908A1 (fr) Technique d&#39;exécution d&#39;un service dans un réseau local à travers un réseau de communication étendu
EP3235217B1 (fr) Procédé d&#39;échanges de données entre deux navigateurs internet, équipement de routage, terminal, programme d&#39;ordinateur et support d&#39;informations corespondants
US20030177125A1 (en) Enhanced residential gateway and associated methods
EP2801178B1 (fr) Procédé dynamique de détermination d&#39;une liste de services dans un réseau sip
FR3061385A1 (fr) Dispositif d&#39;acces securise
WO2015181484A1 (fr) Technique d&#39;obtention d&#39;une politique de routage de requêtes émises par un module logiciel s&#39;exécutant sur un dispositif client
FR3157755A1 (fr) Procédé de fourniture à une application d’un accès à une fonction d’un système d’exploitation d’un terminal
FR3051615A1 (fr) Gestion d&#39;equipements a distance
EP1929700B1 (fr) Procede d&#39;envoi de messages depuis un premier reseau vers un second reseau
FR3157769A1 (fr) Procédé d’accès à un service par un dispositif de communication via au moins un réseau de communication
WO2008065294A1 (fr) Procede de transmission d&#39;informations fonctionnelles, equipement de terminaison, signaux et produit programme d&#39;ordinateur correspondants

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11720139

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11720139

Country of ref document: EP

Kind code of ref document: A1