FR2895192A1 - Procede pour empecher une delivrance simultanee de deux flux de multidiffusion, decodeur de protocole internet et multiplexeur d'acces de ligne d'abonne numerique - Google Patents
Procede pour empecher une delivrance simultanee de deux flux de multidiffusion, decodeur de protocole internet et multiplexeur d'acces de ligne d'abonne numerique Download PDFInfo
- Publication number
- FR2895192A1 FR2895192A1 FR0655638A FR0655638A FR2895192A1 FR 2895192 A1 FR2895192 A1 FR 2895192A1 FR 0655638 A FR0655638 A FR 0655638A FR 0655638 A FR0655638 A FR 0655638A FR 2895192 A1 FR2895192 A1 FR 2895192A1
- Authority
- FR
- France
- Prior art keywords
- stb
- multicast
- igmp
- channel
- message
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 63
- 238000012384 transportation and delivery Methods 0.000 title claims description 21
- 230000005540 biological transmission Effects 0.000 claims abstract description 27
- 230000004913 activation Effects 0.000 claims description 38
- 238000012795 verification Methods 0.000 claims description 20
- 238000007726 management method Methods 0.000 claims description 7
- 230000002159 abnormal effect Effects 0.000 abstract description 10
- 238000004891 communication Methods 0.000 abstract description 5
- 230000007257 malfunction Effects 0.000 description 25
- 230000004044 response Effects 0.000 description 4
- 230000002411 adverse Effects 0.000 description 2
- 238000012550 audit Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000003750 conditioning effect Effects 0.000 description 1
- 238000005520 cutting process Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000004064 dysfunction Effects 0.000 description 1
- 239000011888 foil Substances 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 230000033001 locomotion Effects 0.000 description 1
- 230000008447 perception Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Mobile Radio Communication Systems (AREA)
- Computer And Data Communications (AREA)
Abstract
Un procédé pour empêcher une délivrance simultanée de deux flux de multidiffusion comprend un processus de cessation de la transmission d'un flux de multidiffusion suite au fait qu'un décodeur de protocole Internet (IP STB) est activé ; la cessation de la transmission de flux de multidiffusion peut être initiée par l'IP STB ou par des entités de communication sur le côté du réseau. Le procédé proposé par la présente invention empêche une délivrance simultanée de deux flux de multidiffusion et élimine par conséquent des conséquences défavorables d'une délivrance simultanée de deux flux de multidiffusion incluant une perte de qualité d'image et même un redémarrage anormal d'un IP STB et par conséquent, le ressenti de l'utilisateur sera amélioré et la satisfaction de l'utilisateur sera augmentée de façon distincte. Un IP STB et un multiplexeur de ligne d'abonné numérique (DSLAM) pour la mise en oeuvre du procédé sont également proposés.
Description
PROCEDE POUR EMPECHER UNE DELIVRANCE SIMULTANEE DE DEUX FLUX DE
MULTIDIFFUSION, DECODEUR DE PROTOCOLE INTERNET ET MULTIPLEXEUR D'ACCES DE LIGNE D'ABONNE NUMERIQUE Domaine de la technologie La presente invention concerne la technologie de television par protocole Internet et plus particulierement, elle concerne un procede pour empecher une delivrance simultanee de deux flux de multidiffusion, un decodeur de protocole Internet (IP STB) et un multiplexeur d'acces de ligne d'abonne numerique (DSLAM). Arriere-plan de I'invention La television par protocole Internet (IPTV) est un nouveau media constitue par des services interactifs personnalises sur la base de la technologie Internet. La TV de diffusion (BTV) est le service tres basique dans un systeme IPTV et le service le plus a maturite de I'industrie. En ce qui concerne les diffusions de programme, les publicites de marque et les spots publicitaires, les operateurs etablissent habituellement un canal d'activation par defaut pour diffuser les diffusions de programme, les publicites de marque et les spots publicitaires de telle sorte que la diffusion de contenu par I'intermediaire du canal d'activation par defaut soit recue aussitot qu'un decodeur (STB) IP est mis en route. Le canal d'activation par defaut est habituellement *le sur le canal 1. La BTV est un service base sur multidiffusion et depend d'un protocole de routage de multidiffusion, d'un Protocole de Gestion de Groupe Internet (IGMP) et d'un protocole Proxy IGMP, etc. qui sont supportes par des dispositifs de reseau. Lorsqu'un systeme IPTV transmet des flux de programme de multidiffusion sur un reseau d'acces, des routeurs dans le reseau se conforment habituellement a un protocole de routage de multidiffusion et des dispositifs de reseau clans le reseau d'acces se conforment a un protocole Proxy IGMP. Un IP STB est un dispositif de terminal utilisateur clans un systeme IPTV et le stockage clans I'IP STB stocke habituellement une liste de canaux qui contient les adresses IP de multidiffusion, les numeros de port de multidiffusion et toutes autres informations rapportees aux canaux concernant les canaux qu'un utilisateur est autorise a visualiser. Lorsqu'un utilisateur est en train de recevoir un service BTV, son IP STB recherche tout d'abord I'adresse de multidiffusion et le numero de port de multidiffusion du canal que I'utilisateur veut regarder a partir de la liste de canaux conformement a ('instruction en provenance d'une telecommande puis I'IP STB compose un message de rapport IGMP conformement aux exigences du document RFC2236 et demande a rejoindre un groupe de multidiffusion correspondant et pour finir, I'IP STB reroit le flux de multidiffusion en provenance d'un reseau de source de service IPTV apres que des dispositifs de reseau de tous les niveaux ont realise un protocole Proxy IGMP. Lorsque I'utilisateur souhaite se commuter sur un autre canal, I'IP STB compose tout d'abord un message d'abandon d'IGMP conformement aux exigences de RFC2236 pour abandonner le groupe de multidiffusion courant et par consequent, la transmission du flux de multidiffusion du canal courant est cessee ; puis I'IP STB recherche I'adresse de multidiffusion et le port de multidiffusion du canal que I'utilisateur veut regarder a partir de la Piste de canaux et compose un message de rapport IGMP conformement aux exigences de RFC2236 afin de rejoindre un nouveau groupe de multidiffusion correspondant puis le flux de multidiffusion du nouveau canal est transmis a I' I P STB. Lorsque I'IP STB realise une commutation depuis un service de BTV sur un autre service, I'IP STB compose tout d'abord un message d'abandon d'IGMP conformement aux exigences de RFC2236 afin de quitter le groupe de multidiffusion courant et it s'ensuit que la transmission du flux de multidiffusion du canal courant est cessee ; ensuite, I'IP STB envoie un rapport correspondant conformement aux instructions en provenance de I'utilisateur pour obtenir un nouveau service.
Lorsqu'un IP STB selon ('art anterieur dolt titre redemarre du fait d'un dysfonctionnement (coupure soudaine de I'alimentation, pression erronee du bouton de mise en marche par la personne, etc.) pendant la mise en oeuvre d'un service BTV, la solution technique selon raft anterieur consiste a envoyer un message de rapport IGMP pour rejoindre le groupe de multidiffusion du canal d'activation par defaut du service BTV directement apres que I'IP STB est mis en route, peu importe si la transmission du flux de multidiffusion qui etait transmis lorsque le dysfonctionnement s'est produit a ete cessee. Juste a !Instant ota un tel dysfonctionnement se produit, I'IP STB ne peut pas envoyer un message d'abandon d'IGMP pour quitter le groupe de multidiffusion courant. Dans le meme temps, it y a une tres faible probabilite que le groupe de multidiffusion courant soit le canal d'activation par defaut et Ia probabilite est egale a 1/nombre total de programmes BTV qu'un utilisateur est autorise a regarder. Lorsque HP STB est mis en route et qu'iI envoie directement un message de rapport IGMP pour rejoindre le groupe de multidiffusion du canal d'activation par defaut, le flux de multidiffusion qui a ete transmis lorsque le dysfonctionnement s'est produit est habituellement toujours transmis a I'IP STB du fait que le multiplexeur d'acces de ligne d'abonne numerique (DSLAM) qui envoie le flux de multidiffusion sur VIP STB ne peut pas avoir connaissance de la situation de I'IP STB lorsque I'IP STB a ete en dysfonctionnement. Dans des applications pratiques, un DSLAM dolt envoyer une interrogation generate d'IGMP et une interrogation specifique de groupe pour s'assurer de si oui ou non un IP STB dans le groupe de multidiffusion courant est actif. RFC2236 definit que I'intervalle pour un message d'interrogation d'IGMP est de 125 secondes et que le temps de reponse maximum a un message d'interrogation d'IGMP est de 10 secondes. RFC2236 ne definit pas pendant combien de temps un dispositif devrait attendre apres qu'une interrogation generate est transmise puis ne transmet pas une interrogation specifique de groupe (Ia longueur de I'intervalle vane en fonction des dispositifs provenant de differents fabricants, habituellement une interrogation specifique de groupe est envoyee 20 secondes apres qu'un message d'interrogation d'IGMP est envoye) ou le nombre de foil d'envoi et la longueur d'intervalle d'interrogations specifiques de groupe (des dispositifs en provenance de differents fabricants presentent des reglages differents, habituellement une interrogation specifique de groupe est envoyee 2 fois selon un intervalle de 4 secondes). Si I'IP STB dysfonctionne apres que le DSLAM a envoys un message d'interrogation d'IGMP et avant que I'IP STB retourne un message de reponse correspondant, le DSLAM enverra le message d'interrogation d'IGMP une fois a nouveau et enverra en outre une interrogation specifique de groupe deux fois pour verifier si oui ou non le membre de groupe de multidiffusion qui dysfonctionne a quitte le groupe de multidiffusion ; ensuite, le DSLAM cessera Ia transmission du flux de multidiffusion qui est transmis a VIP STB lorsqu'il dysfonctionne. Ce qui revient a dire que si le VIP STB dysfonctionne apres que le DSLAM a envoys une interrogation generate et avant que I'IP STB retourne un rapport correspondant, la transmission du flux de multidiffusion qui est transmis sur I'IP STB Iorsque I'IP STB dysfonctionne se poursuivra pendant environ 144 secondes. Si I'IP STB dysfonctionne Iorsque le DSLAM envoie un message d'interrogation d'IGMP et que I'IP STB retourne un message de reponse correspondant, le DSLAM enverra un message d'interrogation d'IGMP deux fois a nouveau et en outre, enverra une interrogation specifique de groupe deux fois pour verifier si oui ou non le membre de groupe de multidiffusion qui dysfonctionne a quitte le groupe de multidiffusion ; ensuite, le DSLAM cessera la transmission du flux de multidiffusion qui est transmis sur VIP STB Iorsque I'IP STB dysfonctionne. Ce qui revient a dire que si VIP STB dysfonctionne Iorsque le DSLAM envoie un message d'interrogation d'IGMP et que VIP STB retourne un message de reponse correspondant, la transmission du flux de multidiffusion qui est transmis sur HP STB Iorsque I'IP STB dysfonctionne se poursuivra pendant environ 269 secondes. II peut titre conclu au vu de ce qui precede que lorsqu'un IP STB dysfonctionne, la transmission du flux de multidiffusion a I'IP STB se 30 poursuivra pendant environ 144 a 269 secondes. Qui plus est, Iorsqu'un dysfonctionnement se produit, un IP STB a besoin d'environ 20 secondes pour redemarrer, pour composer un message de rapport d'IGMP et pour demander de rejoindre le groupe de multidiffusion du canal d'activation par defaut, apres quoi le flux de multidiffusion du canal d'activation par defaut sera envoye sur I'IP STB. Bien evidemment, ceci generera la situation selon laquelle le flux de multidiffusion que HP STB etait en train de recevoir lorsque I'IP STB dysfonctionne et le flux de multidiffusion du canal d'activation par defaut sont delivres de fawn simultanee sur I'IP STB et la situation est appelee delivrance simultanee de deux flux de multidiffusion. Une delivrance simultanee de deux flux de multidiffusion dure habituellement de 124 a 249 secondes (ou de 119 a 254 secondes dans certains cas extremes). Une delivrance simultanee de deux flux de multidiffusion conduit a deux consequences nuisibles : en premier lieu, la bande passante totale de deux flux de multidiffusion excede habituellement la bande passante de fonctionnement de service assuree pour un utilisateur par un service IPTV, ce qui conduit a une perte de conditionnement de signal serieuse au niveau des flux de multidiffusion transmis sur I'IP STB, laquelle perte est refletee selon des mouvements geles et une mosai'que en second lieu, du fait qu'iI y a deux flux de multidiffusion transmis sur un IP STB de fawn simultanee, la performance de service de I'IP STB sera affectee, ce qui genere une lecture non continue de I'IP STB au moins et meme un redemarrage anormal de I'IP STB. Pour resumer, selon ran anterieur, deux flux de multidiffusion peuvent titre delivres a un IP STB simultanement pendant un temps long, ce qui degrade serieusement la qualite d'image et pout meme avoir pour effet que I'IP STB redemarre anormalement. Ceci aura une influence sur le ressenti de ('utilisateur selon un degre important et diminuera la satisfaction de ('utilisateur. Resume de ('invention La presente invention propose un procede permettant d'empecher une delivrance simultanee de deux flux de multidiffusion, cette simultaneite generant un dommage serieux on termes de qualite d'image et meme un redemarrage anormal d'un IP STB selon raft anterieur, ainsi qu'un IP STB et qu'un DSLAM pour la mise en oeuvre du procede. La solution technique selon la presente invention est realisee comme suit.
Un procede permettant d'empecher une delivrance simultanee de deux flux de multidiffusion inclut le processus consistant en ce que : une transmission d'un flux de multidiffusion sur un decodeur de protocole Internet (IP STB) cesse lorsque I'IP STB est active. Le processus de cessation d'une transmission d'un flux de multidiffusion sur un IP STB inclut le processus consistant en ce que : suite a sa mise en route, I'IP STB compose et envoie un message d'abandon d'IGMP sur la base d'une information stockee dans I'IP STB ; et suite a la reception du message d'abandon d'IGMP en provenance de I'IP STB, un DSLAM cesse la transmission du flux de multidiffusion correspondant au message d'abandon d'IGMP envoys par I'IP STB. L'information stockee dans I'IP STB inclut une adresse IP de multidiffusion, un numero de port de multidiffusion et une information de verification du canal que I'utilisateur etait en train de regarder lorsque I'IP STB a &Le coupe, et ('information est stockee dans une rnemoire vive non volatile (NVM) de I'IP STB. Le processus de cessation d'une transmission d'un flux de multidiffusion sur un IP STB inclut le processus consistant en ce que : lorsqu'un DSLAM a connaissance du fait que I'IP STB a accede avec succes a un reseau, le DSLAM demande si oui ou non it y a un flux de multidiffusion qui est transmis a I'IP STB et s'il y a un flux de multidiffusion qui est transmis a I'IP STB, le DSLAM cesse la transmission du flux de multidiffusion sur I'IP STB. Le processus de cessation d'une transmission d'un flux de multidiffusion sur un IP STB inclut le processus consistant en ce que suite au fait qu'un DSLAM recoit un message de rapport d'IGMP en provenance de I'IP STB, le DSLAM interroge si oui ou non it y a un flux de multidiffusion qui est en train d'etre transmis a I'IP STB et s'il y a un flux de multidiffusion, le DSLAM cesse la transmission du flux de multidiffusion sur I'IP STB par le DSLAM. Le procede inclut en outre le processus consistant en ce que : I'IP STB compose et envoie un message de rapport d'IGMP sur la base 5 d'un contenu d'une liste de canaux qui est stockee dans I'IP STB et rejoint un groupe de multidiffusion d'un canal d'activation par defaut. Le procede inclut en outre le processus consistant en ce que : conformement a une instruction d'utilisateur revue, realisation d'au moms rune des operations qui suivent : commutation de canaux, commutation 10 sur un service non BTV et coupure. L'operation realisee est une commutation de canaux et la commutation de canaux inclut le processus constitue par : ('envoi du message d'abandon d'IGMP pour quitter un groupe multidiffusion courant ; 15 Ia recherche d'une adresse IP de multidiffusion et d'un numero de port de multidiffusion d'un canal choisi par un utilisateur dans une liste de canaux ; et la composition d'un message de rapport d'IGMP sur la base de I'adresse IP de multidiffusion et du numero de port de multidiffusion trouves et 20 ('envoi du message de rapport d'IGMP pour rejoindre un nouveau groupe de multidiffusion. L'adresse IP de multidiffusion, le numero de port de multidiffusion et 'Information de verification stockes dans I'IP STB sont mis a jour a ('aide dune information correspondante du nouveau groupe de multidiffusion lorsque I'IP 25 STB rejoint le nouveau groupe de multidiffusion ; ou I'IP STB determine si oui ou non un canal choisi par ('utilisateur est le canal d'activation par defaut et si le canal choisi nest pas le canal d'activation par defaut, I'adresse IP de multidiffusion, le numero de port de multidiffusion et 'information de verification stockes clans I'IP STB sont mis a jour a 1'aide dune information 30 correspondante du nouveau groupe de multidiffusion ; sinon, ('information stockee clans I'IP STB n'a pas a titre mise a jour.
L'adresse IP de multidiffusion, le numero de port de multidiffusion et ('information de verification sont stockes clans un fichier d'information dans un systeme de fichiers de la NVM ou sont stockes dans un bloc dans le systeme de fichiers de la NVM.
L'information stockee dans I'IP STB est stockee dans une Iiste de canaux dans une memoire de I'IP STB, incluant des adresses IP de multidiffusion et des numeros de port de multidiffusion de tous les canaux qu'un utilisateur est autorise a regarder ; et le processus de composition et d'envoi du message d'abandon d'IGMP inclut les processus de composition et d'envoi de multiples messages d'abandon d'IGMP sur la base des adresses IP de multidiffusion et des numeros de port de multidiffusion de tous les canaux dans la liste de canaux tour a tour. La presente invention propose egalement un decodeur de protocole Internet (IP SIB), lequel decodeur est configure pour composer et envoyer un message d'abandon de protocole de gestion de groupe Internet (IGMP) sur la base dune information stockee suite au fait quill est mis en route, ('information stockee dans I'IP STB comprend une adresse IP de multidiffusion, un numero de port de multidiffusion et une information de verification du canal que I'utilisateur etait en train de regarder Iorsque I'IP STB a ete coupe, et ('information est stockee dans une memoire non volatile (NVM) de VIP STB. La presente invention propose egalement un DSLAM pour empecher une delivrance simultanee de deux flux de multidiffusion, lequel est configure pour cesser une transmission du flux de multidiffusion correspondant a un message d'abandon d'IGMP envoye par un IP STB suite a Ia reception d'un message d'abandon d'IGMP en provenance d'un IP STB. Par comparaison avec la pratique selon raft anterieur, le procede propose par la presente invention empeche une delivrance simultanee de deux flux de multidiffusion et eIimine par consequent des consequences defavorables resultant de la delivrance simultanee de deux flux de multidiffusion, incluant une perte de qualite d'image et meme un redemarrage anormal d'un IP STB et par consequent, les ressentis de I'utilisateur seront ameliores et la satisfaction de I'utilisateur sera augmentee de fawn distincte.
Breve description des dessins La figure 1 est un organigramme de fonctionnement d'IP STB d'un premier mode de realisation de la presente invention ; la figure 2 est un organigramme de fonctionnement d'IP STB d'un 5 second mode de realisation de la presente invention ; la figure 3 est un organigramme de fonctionnement d'IP STB d'un troisieme mode de realisation de la presente invention ; Ia figure 4 est un organigramme de fonctionnement d'IP STB d'un quatrieme mode de realisation de la presente invention ; et 10 la figure 5 est un organigramme de fonctionnement d'IP STB d'un cinquieme mode de realisation de la presente invention. Modes de realisation de I'invention Une description detaillee de la presente invention est fournie ci-apres par report aux dessins annexes et a des modes de realisation specifiques. 15 Selon les modes de realisation de la presente invention, !ors de la mise en route d'un IP STB, en premier lieu un message d'abandon d'IGMP est transmis de maniere a quitter le groupe de multidiffusion auquel I'IP STB appartenait lorsqu'un dysfonctionnement s'est produit de telle sorte qu'une delivrance simultanee de deux flux de multidiffusion est empechee a la racine. 20 La figure 1 est un organigramme de fonctionnement d'IP STB d'un premier mode de realisation de la presente invention. Comme represents sur la figure 1, lorsqu'un IP STB est mis en route (etape 100), I'IP STB compose et envoie en premier lieu un message d'abandon d'IGMP conformement a I'information qui est stockee dans I'IP STB (etape 101) afin d'abandonner le 25 groupe de multidiffusion auquel I'IP STB appartenait lorsqu'un dysfonctionnement s'est produit au niveau de I'IP STB. L'information stockee dans I'IP STB inclut I'adresse IP de multidiffusion et le numero de port de multidiffusion du groupe de multidiffusion du dernier canal choisi par I'utilisateur avant que I'IP STB ne soit coupe (ou mis hors fonctionnement tors 30 d'un dysfonctionnement). Suite a la reception du message d'abandon d'IGMP en provenance de I'IP STB, le DSLAM cesse la transmission du flux de multidiffusion correspondant au message d'abandon d'IGMP sur I'IP STB, ou le flux de multidiffusion est le flux de multidiffusion qui etait transmis a I'IP STB lorsqu'un dysfonctionnement s'est produit sur I'IP STB. Bien svidemment, lorsqu'un IP STB a tits coupe accidentellement, pendant la mise en oeuvre du service BTV, I'IP STB peut quitter en douceur le groupe de multidiffusion auquel I'IP STB appartenait lorsque I'IP STB a tits coupe par I'intermediaire du procede mentionne ci avant suite a sa mise en route. Apres cela, I'IP STB peut en outre composer un message de rapport d'IGMP sur la base du contenu de la liste de canaux qui est stockee dans I'IP STB et peut envoyer le message de rapport d'IGMP pour rejoindre le canal d'activation par defaut (stape 102). Ensuite, I'IP STB peut poursuivre avec des operations de suivi incluant une commutation de canal, une commutation sur un service non BTV ou une coupure conformement a des instructions d'utilisateur (etape 103). La figure 2 est un organigramme de fonctionnement d'IP STB d'un second mode de realisation de la presente invention. Habituellement, un IP STB est equips d'une memoire non volatile (NVM) dans laquelle un systeme de fichiers est instaurs et dans le systeme de fichiers, un fichier appele Savelnfo.txt (ou d'autres noms) est habituellement cree pour stocker une information. Au niveau d'applications pratiques, le fichier Savelnfo.txt peut titre utilise pour stocker I'adresse IP de multidiffusion, le numero de port de multidiffusion et !'information de verification du groupe de multidiffusion auquel I'IP STB appartient presentement. Comme represents sur la figure 2, suite a sa mise en route (etape 200), un IP STB verifie en premier lieu si oui ou non it y a un fichier appele Savelnfo.txt (etape 201) et s'iI y a un tel fichier, I'IP STB ouvre le fichier pour obtenir !'information dedans puis ferme le fichier Savelnfo.txt (etape 202). Lorsque !'information obtenue a passe avec succes une verification (etape 204), I'IP STB compose un message d'abandon d'IGMP sur la base de !'information conformement au format de message d'abandon d'IGMP defini par RFC2236 et envoie le message d'abandon d'IGMP (etape 205). S'il n'y a pas de fichier appele , un fichier devrait titre cree puis ferme (etape 203).
II s'ensuit que la transmission du flux de multidiffusion qui etait transmis sur I'IP STB lorsqu'un dysfonctionnement s'est produit est cessee et une delivrance simultanee de deux flux de multidiffusion selon !'art anterieur est empechee.
Lorsque le message d'abandon d'IGMP est envoys, I'IP STB compose un message de rapport d'IGMP sur la base de I'adresse IP de multidiffusion et de !'information de port de multidiffusion du canal d'activation par defaut dans la liste de canaux de I'IP STB et envoie le message de rapport d'IGMP de maniere a rejoindre le groupe de multidiffusion du canal d'activation par defaut (etape 206). Ensuite, I'IP STB ouvre le fichier Savelnfo.txt qui est stocks dans I'IP STB, scrit I'adresse IP de multidiffusion, le numero de port de multidiffusion et !'information de verification du canal d'activation par defaut a I'interieur du fichier Savelnfo.txt et ferme le fichier (etape 207). Ensuite, le flux de multidiffusion fourni par I'IP STB pour I'utilisateur est le programme de multidiffusion du canal d'activation par defaut. Pendant la mise en oeuvre du service de multidiffusion du canal d'activation par defaut, I'IP STB peut recevoir les trois instructions qui suivent : 1. une instruction de commutation de canal (commutation entre des services BTV) ; 2. une instruction de commutation de service (commutation entre un service BTV et un service non BTV fournis par I'IP STB) ; 3. une instruction de coupure. Pour les trois instructions mentionnes ci avant, I'IP STB peut realiser les processus de manipulation correspondants comme suit : Iorsqu'une instruction de commutation de canal est repue, I'IP STB realise un premier processus de manipulation qui inclut les stapes de : envoi d'un message d'abandon d'IGMP par I'IP STB pour quitter le groupe de multidiffusion courant (etape 208), recherche, conformsment a !'instruction en provenance dune telecommande, de I'adresse de multidiffusion et du numero de port de multidiffusion du canal correspondant a I'instruction en provenance de la Iiste de canaux stockee dans I'IP STB, composition d'un message de rapport d'IGMP sur la base de I'adresse de multidiffusion et du numero de port de multidiffusion obtenus et envoi du message de rapport d'IGMP (etape 209); puis ouverture du fichier Savelnfo.txt, mise a zero du contenu du fichier, ecriture dans le fichier Savelnfo.txt de I'adresse IP de multidiffusion, du numero de port de multidiffusion et de ('information de verification du canal apres la commutation et fermeture du fichier (etape 210). II peut titre conclu que ('information dans le fichier Savelnfo.txt devrait titre mise a jour a ('aide de I'adresse IP de multidiffusion, du numero de port de multidiffusion et de ('information de verification du nouveau canal chaque fois pendant une commutation de canal. La mise a jour du fichier Savelnfo.txt est importante. Bien evidemment, si le nouveau canal sur lequel I'IP STB se commute est le canal d'activation par defaut, le fichier Savelnfo.txt n'a pas besoin d'etre mis a jour. Lorsqu'une instruction de commutation de service est revue, I'IP STB realise un second processus de manipulation qui inclut les Mapes de : envoi d'un message d'abandon d'IGMP par I'IP STB (etape 211) lorsque I'IP STB se commute depuis un service BTV sur un service non BTV afin de quitter le groupe de multidiffusion courant et envoi d'un message correspondant conformement a ('instruction regue pour demander en requete un service non BTV (etape 212).
Lorsqu'une instruction de coupure est revue, I'IP STB realise un troisieme processus de manipulation qui inclut les etapes de : envoi d'un message d'abandon d'IGMP par I'IP STB pour quitter le groupe de multidiffusion courant (etape 213) et realisation du processus de coupure. Lorsque I'IP STB a termine une commutation de canal, it peut en outre recevoir une instruction de commutation de service (commutation depuis un service BTV sur un service non BTV) ou une instruction de coupure. Si une instruction de commutation de service est regue, I'IP STB realise le second processus de manipulation mentionne ci avant ; si une instruction de coupure est regue, I'IP STB realise le troisieme processus de manipulation mentionne ci avant. Lorsque I'IP STB a realise une commutation depuis un service BTV sur un service non BTV, it peut en outre recevoir une instruction de commutation depuis un service non BTV sur un service BTV ou une instruction de coupure. Si une instruction de commutation depuis un service non BTV sur un service BTV est revue, I'IP STB realise un processus similaire au premier processus de manipulation, processus selon lequel I'etape d'envoi d'un message d'abandon d'IGMP pour quitter le groupe de multidiffusion courant est omise si une instruction de coupure est revue, I'IP STB realise directement le processus de coupure.
Le processus represents sur la figure 2 est realise sur la base du fait quill y a un systeme de fichiers dans la NVM. Lorsqu'il n'y a pas de systeme de fichiers clans la NVM, I'adresse IP de multidiffusion et le numero de port de multidiffusion du groupe de multidiffusion courant peuvent titre stockes dans un bloc de I'IP STB, tel que selon un autre mode de realisation de la presente invention et !Information est stockee, lue et mise a jour par l'intermediaire de fonctions d'interface de fonctionnement de bloc. Qui plus est, selon le processus qui est represents sur la figure 2, lorsque I'adresse IP de multidiffusion, le numero de port de multidiffusion et !Information de verification sont stockes dans le fichier Savelnfo.txt, le canal d'activation par defaut et d'autres canaux sont consideres comme etant equivalents. De fait, si I'IP STB est en train de mettre en oeuvre le service BTV du canal d'activation par defaut lorsqu'un dysfonctionnement se produit et si HP STB rejoint le groupe de multidiffusion du canal d'activation par defaut suite a sa mise en route, conformement au principe de la multidiffusion, n'y aura pas deux flux de multidiffusion du canal d'activation par &taut transmis a I'IP STB de telle sorte quill nest pas necessaire de stocker I'adresse IP de multidiffusion, le numero de port de multidiffusion et ('information de verification du canal d'activation par defaut tors du processus de service d'un IP STB.
Par exemple, lorsque I'IP STB est mis en route et quill rejoint le groupe de multidiffusion du canal d'activation par defaut pour la premiere fois, I'etape d'ecriture de I'adresse IP de multidiffusion, du numero de port de multidiffusion et de !Information de verification du canal d'activation par defaut dans le fichier Savelnfo.txt (ou un bloc) peut titre omise. En outre, apres que I'IP STB a ete commute sur un autre canal et avant que I'adresse IP de multidiffusion, le numero de port de multidiffusion et !Information de verification du nouveau canal ne soient stockes clans le fichier Savelnfo.txt, une etape de determination de si oui ou non le canal de multidiffusion courant est le canal d'activation par defaut peut titre r&alisee et si le canal de multidiffusion courant est le canal d'activation par defaut, I'etape d'ecriture de I'adresse IP de multidiffusion, du numero de port de multidiffusion et de !Information deverification du canal d'activation par defaut dans le fichier SaveInfo.txt (ou un bloc) peut titre omise ; sinon, I'adresse IP de multidiffusion, le numero de port de multidiffusion et !Information de verification du nouveau canal seront &tits clans le fichier SaveInfo.txt (ou un bloc). Habituellement, une Iiste de canaux est stockee clans le stockage d'un IP STB et la liste de canaux stocke les adresses IP de multidiffusion, les numeros de port de multidiffusion et toute autre information de canal de tous les canaux qu'un utilisateur est autorise a regarder. Selon le processus represents sur la figure 2, un procede qui inclut une &tape de stockage dune information pertinente dans le systeme de fichiers dans la NVM est propose pour assurer qu'un message d'abandon d'IGMP est envoys avant un message de rapport d'IGMP, une autre solution est egalement proposee dans le cas ()CI n'y a pas de systeme de fichiers dans la NVM, en outre, un procede selon Iequel les adresses IP de multidiffusion, les numeros de ports de multidiffusion et ('information de verification du canal d'activation par defaut n'ont pas besoin d'etre stockes dans le fichier Savelnfo.txt est propose ; qui plus est, !Information de verification est prise en consideration egalement. Par consequent, le processus de fonctionnement de I'IP STB represents sur la figure 2 est efficace et stable. Bien evidemment, le processus represents sur la figure 2 stocke les adresses IP de multidiffusion, les numeros de port de multidiffusion et !Information de verification du canal tout en mettant en oeuvre un service BTV ; lorsqu'un IP STB redemarre apt-6s une coupure anormale, I'IP STB accede a ('information pertinente stockee pour composer un message d'abandon d'IGMP et envoie le message d'abandon d'IGMP avant d'envoyer un message de rapport d'IGMP de telle sorte qu'une delivrance simultanee de deux flux de multidiffusion est empechee.
La figure 3 est un organigramme de fonctionnement de I'IP STB d'un troisieme mode de realisation de la presente invention. Comme represents sur la figure 3, Iorsqu'un IP STB est mis en route selon une situation aleatoire (y compris une situation anormale), I'IP STB compose de multiples messages d'abandon d'IGMP dont chacun correspond a un canal que I'utilisateur est autorise a regarder conformement au contenu de la liste de canaux qui est stockee dans I'IP STB et envoie les messages d'abandon d'IGMP tour a tour (etape 301). Par I'intermediaire d'un tel procede, I'IP STB peut abandonner a son initiative le groupe de multidiffusion auquel it appartenait lorsqu'un dysfonctionnement s'est produit. Ensuite, I'IP STB compose un message de rapport d'IGMP sur la base de I'adresse IP de multidiffusion et de I'information de port de multidiffusion du canal d'activation par defaut dans sa propre Iiste de canaux et envoie le message de rapport d'IGMP et rejoint le groupe. de multidiffusion du canal d'activation par defaut (etape 302). Ensuite (etape 303), I'IP STB peut poursuivre avec des operations a suivre incluant une commutation de canal, une commutation sur un service non BTV ou une coupure, conformement a des instructions d'utilisateur. On peut voir que le processus represents sur la figure 3 parcourt la liste de canaux et assure que des messages d'abandon d'IGMP correspondants de tous les canaux que I'utilisateur est autorise a regarder seront envoyes tour a tour de telle sorte que la transmission du flux de multidiffusion qui se poursuit apres que le dysfonctionnement se produit sur I'IP STB puisse titre cessee. Si lion suppose qu'un utilisateur est autorise a regarder 100 canaux de multidiffusion, le temps qu'un IP STB consomme pour envoyer un message d'abandon d'IGMP correspondant a run des 100 canaux peut titre inferieur a une milliseconde. Compte tenu de la prise en consideration de la capacite d'un DSLAM et de la congestion du reseau, I'intervalle de message d'abandon d'IGMP peut titre etabli de maniere a valoir une milliseconde de telle sorte que tous les messages d'abandon d'IGMP puissent titre envoyes a I'interieur de 0,1 seconde apres que I'IP STB est mis en route et par consequent, un temps tres court est consomme pour que I'IP STB arrete la transmission du flux de multidiffusion qui se poursuit apres qu'un dysfonctionnement s'est produit sur I'IP STB. On peut voir au vu ce qui precede que selon les procedes representes sur les figures 1 a 3, un IP STB envoie un message d'abandon d'IGMP a son initiative pour empecher la delivrance simultanee de plusieurs flux de multidiffusion. De fait, les entites de communication sur le cote de reseau peuvent egalement cesser a leur initiative la transmission du flux de multidiffusion qui se poursuit apres qu'un dysfonctionnement s'est produit sur I'IP STB pour empecher une delivrance simultanee de plusieurs flux de multidiffusion. Les processus detailles sont representes sur la figure 4 et sur la figure 5. La figure 4 est un organigramme de fonctionnement d'IP STB d'un quatrieme mode de realisation de la presente invention. Comme represents sur la figure 4, lorsqu'un IP STB est mis en route dans une situation aleatoire (y compris une situation anormale), I'IP STB negocie avec un serveur d'acces large bande par I'intermediaire de protocoles pertinents et le serveur d'acces large bande alloue une adresse IP pour la communication de I'IP STB apres une negotiation couronnee de succes (etape 401); dans le meme temps, le serveur d'acces large bande peut egalement notifier un DSLAM par I'intermediaire d'un message ou de tout autre moyen du fait que I'IP STB a accede avec succes au reseau (etape 402). Suite a la reception de la notification en provenance du serveur d'acces large bande, le DSLAM interroge (etape 403) si oui ou non it y a un flux de multidiffusion qui est transmis presentement a I'IP STB et s'iI y a un flux de multidiffusion qui est transmis presentement a I'IP STB, le DSLAM cesse la transmission a I'IP STB (etape 404). Lorsque I'IP STB ne recoit plus un flux de multidiffusion en provenance du DSLAM, I'IP STB compose un message de rapport d'IGMP sur la base du contenu de la liste de canaux qui est stockee dans I'IP STB lui-meme et envoie le message de rapport d'IGMP afin de rejoindre le groupe de multidiffusion du canal d'activation par defaut (etape 405).
Bien svidemment, si le DSLAM determine qu'il n'y a pas de flux de multidiffusion qui est en train d'etre transmis a I'IP STB, le DSLAM peut poursuivre avec d'autres operations selon I'art anterieur. Dans ce cas, I'IP STB peut toujours composer et envoyer un message de rapport d'IGMP sur la base du contenu de la liste de canaux qui est stockee dans I'IP STB et peut rejoindre le groupe de multidiffusion du canal d'activation par defaut. La figure 5 est un organigramme de fonctionnement d'IP STB d'un cinquieme mode de realisation de la presente invention. Comme represents sur la figure 5, lorsqu'un IP STB est mis en route dans une situation aleatoire (y compris une situation anormale), I'IP STB negocie avec un serveur d'acces large bande par I'intermediaire de protocoles pertinents et le serveur d'acces large bande alloue une adresse IP pour la communication de I'IP STB apresune negociation couronnee de succes (etape 501); ensuite, I'IP STB compose un message de rapport d'IGMP sur la base du contenu de la liste de canaux qui est stockee dans I'IP STB et envoie le message de rapport d'IGMP, en demandant de rejoindre le groupe de multidiffusion du canal d'activation par defaut (etape 502). Suite a la reception du message de rapport d'IGMP en provenance de I'IP STB, le DSLAM demande (etape 503) si oui ou non it y a un flux de multidiffusion qui est en train d'etre transmis presentement a I'IP STB et s'iI y a un flux de multidiffusion qui est en train d'etre transmis presentement a I'IP STB, le DSLAM cesse la transmission sur I'IP STB (etape 504) et peut en outre refuser de permettre que I'IP STB rejoigne le groupe de multidiffusion du canal d'activation par defaut ; sinon, le DSLAM permet que I'IP STB rejoigne le groupe de multidiffusion du canal d'activation par defaut (etape 505). Lorsque I'IP STB ne recoit pas un quelconque flux de diffusion supplementaire en provenance du DSLAM, I'IP STB compose un message de rapport d'IGMP sur la base du contenu de la liste de canaux qui est stockee dans I'IP STB et envoie le message de rapport d'IGMP pour rejoindre le groupe de multidiffusion du canal d'activation par defaut. On peut voir sur la figure 4 et sur la figure 5 que lorsqu'un IP STB est mis en route apres une coupure anormale, un DSLAM sur le cote de reseau peut cesser a son initiative la transmission du flux de multidiffusion qui se poursuit apres qu'un dysfonctionnement s'est produit sur I'IP STB de telle sorte qu'une delivrance simultanee de deux flux de multidiffusion est empechee.
La presente invention peut egalement proposer un IP STB et un DSLAM pour mettre en oeuvre le procede mentionne ci avant. Pour resumer, le procede propose par Ies modes de realisation de la presente invention empeche une delivrance simultanee de deux flux de multidiffusion selon I'art anterieur et elimine par consequent des consequences defavorables d'une delivrance simultanee de deux flux de multidiffusion, incluant une perte de qualite d'image et meme un redemarrage anormal d'un IP STB et par consequent, les ressentis de I'utilisateur seront ameliores et la satisfaction de I'utilisateur sera augmentee de fawn distincte.
Glossaire • IP (<< Internet Protocol >>) : protocole de communication • IPTV (<< Internet Protocol Television >>) : television par protocole IP 20 • IP STB (<< Internet Protocol Set Top Box >>) : adjoint de poste de television servant de decodeur de protocole IP notamment pour les flux de type IPTV • DSLAM (<< Digital Subscriber Line Access Multiplexer >>) : Multiplexeur d'acces 25 de ligne d'abonne numerique • BTV (<< Broadcast Television ) : television de diffusion • IGMP (<< Internet Group Management Protocol >>) : Protocole de Gestion de 30 Groupe Internet • RFC2236 (<< Request for Comments 2236 >>) • NVM (<< Non Volatile Memory >) : Memoire non volatile
Claims (13)
1. Procede pour empecher une delivrance simultanee de deux flux de multidiffusion, caracterise en ce qu'il comprend : Ia cessation dune transmission d'un flux de multidiffusion sur un decodeur de protocole Internet (IP STB) lorsque I'IP STB est mis en route.
2. Procede selon la revendication 1, caracterise en ce que le processus de cessation dune transmission d'un flux de multidiffusion sur un IP STB comprend : suite au fait qu'il est mis en route, I'IP STB compose et envoie un message d'abandon de Protocole de Gestion de Groupe Internet (IGMP) sur 10 Ia base d'une information stockee dans I'IP STB ; et suite a la reception du message d'abandon d'IGMP en provenance de I'IP STB, un multiplexeur d'acces de ligne d'abonne numerique (DSLAM) cesse la transmission du flux de multidiffusion correspondant au message d'abandon d'IGMP envoye par I'IP STB. 15
3. Procede selon la revendication 2, caracterise en ce que ['information stockee dans I'IP STB comprend une adresse IP de multidiffusion, un numero de port de multidiffusion et une information de verification du canal que I'utilisateur est en train de regarder lorsque I'IP STB est coupe, et I'information est stockee dans une memoire non volatile (NVM) 20 de I'IP STB.
4. Procede selon la revendication 1, caracterise en ce que le processus de cessation d'une transmission d'un flux de multidiffusion sur un IP STB comprend Iorsqu'un DSLAM a connaissance du fait que I'IP STB a accede avec 25 succes a un reseau, ('interrogation, par le DSLAM, de si oui ou non it y a un flux de multidiffusion qui est en train d'etre transmis sur I'IP STB, et s'iI y a un flux de multidiffusion qui est en train d'etre transmis sur I'IP STB, la cessation de la transmission du flux de multidiffusion sur I'IP STB.
5. Procede selon la revendication 1, caracterise en ce que le processus de cessation d'une transmission d'un flux de multidiffusion sur un IP STB comprend : suite au fait qu'un DSLAM recoit un message de rapport d'IGMP en provenance de I'IP STB, !Interrogation, par le DSLAM, de si oui ou non it y a un flux de multidiffusion qui est en train d'etre transmis a I'IP STB, et s'il y a un flux de multidiffusion, la cessation dune transmission du flux de multidiffusion sur I'IP STB par le DSLAM.
6. Procede selon rune quelconque des revendications 2 a 5, 10 caracterise en ce qu'il comprend en outre : la composition et I'envoi d'un message de rapport d'IGMP par I'IP STB sur la base d'un contenu dune Iiste de canaux stockee clans I'IP STB et le fait de rejoindre un groupe de multidiffusion d'un canal d'activation par defaut.
7. Procede selon rune quelconque des revendications 2 a 5, 15 caracterise en ce quill comprend en outre : conformement a une instruction d'utilisateur recue, la realisation d'au moins rune des operations qui suivent : commutation de canaux, commutation sur un service non BTV et coupure.
8. Procede selon la revendication 7, caracterise en ce que 20 !'operation realisee est la commutation de canaux, et la commutation de canaux comprend : I'envoi du message d'abandon d'IGMP pour quitter un groupe de multidiffusion courant ; Ia recherche d'une adresse IP de multidiffusion et d'un numero de port 25 de multidiffusion d'un canal choisi par un utilisateur dans une Iiste de canaux ; et Ia composition d'un message de rapport d'IGMP sur la base de I'adresse IP de multidiffusion et du numero de port de multidiffusion trouves et I'envoie du message de rapport d'IGMP de maniere a rejoindre un nouveau 30 groupe de multidiffusion.
9. Procede selon la revendication 8, caracterise en ce que :I'adresse IP de multidiffusion, le numero de port de multidiffusion et !Information de verification stockes dans I'IP STB sont mis a jour a !'aide dune information correspondante du nouveau groupe de multidiffusion lorsque I'IP STB rejoint le nouveau groupe de multidiffusion ; ou I'IP STB determine si oui ou non un canal choisi par I'utilisateur est le canal d'activation par defaut et si le canal choisi nest pas le canal d'activation par defaut, I'adresse IP de multidiffusion, le numero de port de multidiffusion et I'information de verification stockes dans I'IP STB sont mis a jour a !'aide dune information correspondante du nouveau groupe de multidiffusion ; sinon, !Information stockee dans I'IP STB n'est pas mise a jour.
10. Procede selon la revendication 3, 8 ou 9, caracterise en ce que I'adresse IP de multidiffusion, le numero de port de multidiffusion et !Information de verification sont stockes dans un fichier d'information dans un systeme de fichiers de la NVM ou sont stockes dans un bloc dans le systeme de fichiers de la NVM.
11. Procede selon la revendication 2, caracterise en ce que : !Information stockee dans I'IP STB est stockee dans une liste de canaux dans une memoire de I'IP STB, incluant des adresses IP de multidiffusion et des numeros de port de multidiffusion de tous les canaux 20 qu'un utilisateur est autorise a regarder ; et le processus de composition et d'envoi du message d'abandon d'IGMP comprend la composition et ('envoi de multiples messages d'abandon d'IGMP sur la base des adresses IP de multidiffusion et des numeros de ports de multidiffusion de tous les canaux dans la liste de canaux tour a tour. 25
12. Decodeur de protocole Internet (IP STB), caracterise en ce quill est configure pour composer et envoyer un message d'abandon de Protocole de Gestion de Groupe Internet (IGMP) sur la base dune information stockee suite au fait qu'il est active, ou !Information stockee clans I'IP STB comprend une adresse de multidiffusion, un numero de port de multidiffusion et une 30 information de verification du canal que I'utilisateur est en train de regarder lorsque I'IP STB est coupe et !'information est stockee dans une memoire non volatile (NVM) de I'IP STB.
13. Multiplexeur d'acces de ligne d'abonne numerique (DSLAM) pour empecher une delivrance simultanee de deux flux de multidiffusion, caracterise en ce qu'il est configure pour cesser une transmission du flux de multidiffusion correspondant a un message d'abandon de Protocole de Gestion de Groupe Internet (IGMP) envoye par un decodeur de protocole Internet (IP STB) suite a la reception d'un message d'abandon d'IGMP en provenance de I'IP STB.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB2005101210046A CN100536467C (zh) | 2005-12-19 | 2005-12-19 | Ip机顶盒的工作方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2895192A1 true FR2895192A1 (fr) | 2007-06-22 |
| FR2895192B1 FR2895192B1 (fr) | 2011-05-27 |
Family
ID=37133779
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0655638A Active FR2895192B1 (fr) | 2005-12-19 | 2006-12-19 | Procede pour empecher une delivrance simultanee de deux flux de multidiffusion, decodeur de protocole internet et multiplexeur d'acces de ligne d'abonne numerique |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US7751395B2 (fr) |
| EP (3) | EP1965545B9 (fr) |
| CN (2) | CN100536467C (fr) |
| AT (1) | ATE542331T1 (fr) |
| ES (1) | ES2378468T3 (fr) |
| FR (1) | FR2895192B1 (fr) |
| WO (1) | WO2007071144A1 (fr) |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4765952B2 (ja) * | 2007-02-15 | 2011-09-07 | ソニー株式会社 | マルチキャスト配信システム、クライアント機器、上位ルータ制御装置、コンテンツの表示方法およびプログラム |
| JP4752786B2 (ja) * | 2007-02-15 | 2011-08-17 | ソニー株式会社 | マルチキャスト配信システムおよびマルチキャスト配信方法 |
| US20090022064A1 (en) * | 2007-07-18 | 2009-01-22 | Moshe Oron | Method and apparatus for monitoring multicast bandwidth to a user |
| KR100884061B1 (ko) | 2007-08-30 | 2009-02-19 | 한양대학교 산학협력단 | 멀티캐스트 전송 환경에서의 그룹 탈퇴 방법 및 이를지원하는 장치 |
| KR100895880B1 (ko) | 2007-08-30 | 2009-04-30 | 한양대학교 산학협력단 | 멀티캐스트 전송 환경에서의 그룹 탈퇴 방법 및 이를지원하는 호스트 장치 |
| CN100583997C (zh) * | 2007-10-19 | 2010-01-20 | 深圳华为通信技术有限公司 | 网络电视的业务启动方法、装置和系统以及网络电视终端 |
| BRPI0821104A2 (pt) * | 2007-11-30 | 2015-06-16 | Sharp Kk | Dispositivo de recepção de transmissão |
| CN101494548B (zh) * | 2009-03-02 | 2011-07-13 | 中兴通讯股份有限公司 | 减少网络电视组播断流时间的方法和装置 |
| US9059919B1 (en) * | 2011-03-28 | 2015-06-16 | Symantec Corporation | Systems and methods for preserving network settings for use in a pre-boot environment |
| WO2012103724A1 (fr) * | 2011-06-29 | 2012-08-09 | 华为技术有限公司 | Groupe de processus et procédé pour faire sortir d'un groupe de processus un membre de groupe anormal |
| CN103581708A (zh) | 2012-07-31 | 2014-02-12 | 中兴通讯股份有限公司 | 机顶盒开机广告播放的方法和系统 |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6983478B1 (en) * | 2000-02-01 | 2006-01-03 | Bellsouth Intellectual Property Corporation | Method and system for tracking network use |
| US20050028206A1 (en) * | 1998-06-04 | 2005-02-03 | Imagictv, Inc. | Digital interactive delivery system for TV/multimedia/internet |
| US6826612B1 (en) | 1999-12-21 | 2004-11-30 | Alcatel Canada Inc. | Method and apparatus for an improved internet group management protocol |
| US20020150094A1 (en) * | 2000-10-27 | 2002-10-17 | Matthew Cheng | Hierarchical level-based internet protocol multicasting |
| US20030145102A1 (en) * | 2002-01-29 | 2003-07-31 | Alcatel, Societe Anonyme | Facilitating improved reliability of internet group management protocol through the use of acknowledge messages |
| US7272652B1 (en) * | 2002-04-30 | 2007-09-18 | Alcatel Lucent | Facilitating accelerated processing of internet group management protocol messages |
| AU2003255246A1 (en) * | 2002-08-16 | 2004-03-03 | Thomson Licensing S.A. | Download optimization in the presence of multicast data |
| CN2583891Y (zh) * | 2002-09-29 | 2003-10-29 | 上海广电信息产业股份有限公司 | 使机顶盒具有记录第一次使用时间的装置 |
| US7254608B2 (en) * | 2002-10-31 | 2007-08-07 | Sun Microsystems, Inc. | Managing distribution of content using mobile agents in peer-topeer networks |
| US20040090970A1 (en) * | 2002-11-11 | 2004-05-13 | Sanchez Cheryl A. | Distribution of data flows to local loop subscribers by an access multiplexer |
| US7359939B2 (en) * | 2002-12-06 | 2008-04-15 | Alcatel Canada, Inc. | Fast service restoration for lost IGMP leave requests |
| US7228356B2 (en) * | 2002-12-12 | 2007-06-05 | Alcatel Canada Inc. | IGMP expedited leave triggered by MAC address |
| JP4684997B2 (ja) * | 2003-03-20 | 2011-05-18 | トムソン ライセンシング | 衛星信号を発見して配信するためにマルチキャストＩＰ及びＥｔｈｅｒｎｅｔを利用するシステム及び方法 |
| ES2279078T3 (es) * | 2003-06-24 | 2007-08-16 | Alcatel Lucent | Red de acceso a linea de abonado digital con un control mejorado de la autenticacion, autorizacion, contabilidad y configuracion para servicios de emision multiple. |
| SE0400825D0 (sv) * | 2004-03-30 | 2004-03-30 | Packetfront Sweden Ab | Anordning och förfarande |
| US20070044123A1 (en) * | 2005-08-16 | 2007-02-22 | Alcatel | System and method for smoothing channel changing in internet protocol television systems |
-
2005
- 2005-12-19 CN CNB2005101210046A patent/CN100536467C/zh not_active Expired - Fee Related
-
2006
- 2006-10-13 EP EP06804924A patent/EP1965545B9/fr active Active
- 2006-10-13 CN CN2006800122962A patent/CN101160831B/zh active Active
- 2006-10-13 EP EP12172420.7A patent/EP2530878B1/fr active Active
- 2006-10-13 AT AT06804924T patent/ATE542331T1/de active
- 2006-10-13 ES ES06804924T patent/ES2378468T3/es active Active
- 2006-10-13 WO PCT/CN2006/002698 patent/WO2007071144A1/fr active Application Filing
- 2006-10-13 EP EP12151055.6A patent/EP2458791B1/fr active Active
- 2006-12-19 US US11/612,806 patent/US7751395B2/en active Active
- 2006-12-19 FR FR0655638A patent/FR2895192B1/fr active Active
Also Published As
| Publication number | Publication date |
|---|---|
| EP1965545B1 (fr) | 2012-01-18 |
| WO2007071144A1 (fr) | 2007-06-28 |
| ATE542331T1 (de) | 2012-02-15 |
| EP2458791B1 (fr) | 2015-04-01 |
| EP1965545A4 (fr) | 2009-06-17 |
| EP2530878B1 (fr) | 2014-01-08 |
| EP2458791A3 (fr) | 2012-08-29 |
| CN100536467C (zh) | 2009-09-02 |
| CN1852311A (zh) | 2006-10-25 |
| EP2458791A2 (fr) | 2012-05-30 |
| US20070147373A1 (en) | 2007-06-28 |
| US7751395B2 (en) | 2010-07-06 |
| EP2530878A1 (fr) | 2012-12-05 |
| CN101160831A (zh) | 2008-04-09 |
| FR2895192B1 (fr) | 2011-05-27 |
| ES2378468T3 (es) | 2012-04-12 |
| EP1965545A1 (fr) | 2008-09-03 |
| EP1965545B9 (fr) | 2012-04-18 |
| CN101160831B (zh) | 2010-05-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR2895192A1 (fr) | Procede pour empecher une delivrance simultanee de deux flux de multidiffusion, decodeur de protocole internet et multiplexeur d'acces de ligne d'abonne numerique | |
| EP1964313B1 (fr) | Procédé de transmission de services de télévision numérique, passerelle et réseau correspondants | |
| US8424036B2 (en) | Targeted/addressable advertisement insertion into video streams delivered to users | |
| US10389776B2 (en) | Media streaming using hybrid P2P and client-server distribution of content | |
| FR2903268A1 (fr) | Procede de reception de services audio/video, terminal et systeme correspondants | |
| US20160182953A1 (en) | System and Method for Utilizing a Secured Service Provider Memory | |
| JP2007089170A (ja) | 放送された番組を記録するための装置 | |
| EP1746837A2 (fr) | Procédé de téléchargement de données précédées par des signaux d'annonce | |
| KR101416311B1 (ko) | 비디오-온-디맨드 세션을 복구하기 위한 방법 | |
| WO2008113948A1 (fr) | Procede d'enregistrement distribue d'un flux multimedia, dispositif, et produit programme d'ordinateur correspondant | |
| FR2933213A1 (fr) | Methode d'affichage d'interface utilisateur et methode d'emission correspondante | |
| FR2894753A1 (fr) | Methode de gestion du comportement d'une application interactive lors de la diffusion d'un programme selon la norme dvb-h | |
| JP2010081067A (ja) | 中継装置、中継方法、中継プログラム、受信装置、通信終了方法および通信終了プログラム | |
| WO2015011398A1 (fr) | Procede de synchronisation lors du traitement par un lecteur multimedia d'un contenu multimedia transmis par un service mbms | |
| FR2903561A1 (fr) | Terminal de communication mobile et procede de transmission d'informations de visionnage de diffusion de celui-ci. | |
| EP2854415B1 (fr) | Procédé de transmission dynamique de données d'information relatives à un programme audio et/ou vidéo | |
| EP4184922A1 (fr) | Procédé de gestion de l' accès à un contenu multimédia | |
| WO2019179855A1 (fr) | Procede de diffusion d'un contenu | |
| EP1912439B1 (fr) | Procédé de notification de changement de parametre d'emission et émetteur selon le procédé | |
| FR2966999A1 (fr) | Procede de communication pour la distribution hybride de donnees | |
| FR2981182A1 (fr) | Controle d'acces a des donnees d'un contenu chiffre | |
| FR3039021A1 (fr) | Procede de filtrage d’un catalogue multimedia recu par liaison satellite, dispositif de filtrage. | |
| FR2809838A1 (fr) | Procede de telechargement de donnees precedees par des signaux d'annonce | |
| WO2007049860A1 (fr) | Modem pour transmission de donnees et support d'enregistrement pour le stockage d'un programme |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 10 |
|
| PLFP | Fee payment |
Year of fee payment: 11 |
|
| PLFP | Fee payment |
Year of fee payment: 12 |
|
| PLFP | Fee payment |
Year of fee payment: 14 |
|
| PLFP | Fee payment |
Year of fee payment: 15 |
|
| PLFP | Fee payment |
Year of fee payment: 16 |
|
| PLFP | Fee payment |
Year of fee payment: 17 |
|
| PLFP | Fee payment |
Year of fee payment: 18 |