La Fibre
Forum : => La Fibre FTTH (Fiber To The Home) => 
Technologie Gpon / Le futur: XGS-PON et NG-PON2 => Discussion démarrée par: BadMax le 18 mai 2013 à 14:56:04
-
Précise bien que 300 Kb/s correspond à la consommation Internet, pas IP; les "services gérés" sont en plus.
Déjà la télé de rattrapage (VoD gratuite donc accessible au plus grand nombre) doit pas mal augmenter le débit IP (enfin j'imagine).
Si de nouveaux usages apparaissaient, la moyenne de 300 Kb/s pourrait exploser.
Tout à fait. Je faisais cette moyenne quand j'étais non-dégroupé chez Club-Internet.
Maintenant chez Free, tous les soirs y'a au moins 2Mb/s (ma femme regarde Buffy sur une chaine ADSL) qui grimpe à 5Mb quand son enregistrement de "Brothers&Sisters" démarre (sur une autre chaine ADSL). Me reste un petit 2Mb pour surfer.... Mais vu l'état du Transit de Free, je vois à peine la différence en fait....
Edit: exemples
(http://baddy.free.fr/img/freebox.png)
(http://baddy.free.fr/img/freeboxhd.png)
-
Non, quand tu fais un traceroute, tu vois le nom des NRO traversés (c'est du niveau 3).
Exact, merci.
Maintenant chez Free, tous les soirs y'a au moins 2Mb/s (ma femme regarde Buffy sur une chaine ADSL) qui grimpe à 5Mb quand son enregistrement de "Brothers&Sisters" démarre (sur une autre chaine ADSL). Me reste un petit 2Mb pour surfer.... Mais vu l'état du Transit de Free, je vois à peine la différence en fait....
Enfin tes 2+3M de TV c'est pas vraiment compté pareil (flux multicast).
-
Enfin tes 2+3M de TV c'est pas vraiment compté pareil (flux multicast).
Sur l'arbre GPON, du coup, si, ça va compter :)
-
Non, en Gpon SI 10 personnes s’abonnent a TF1, un seul flux est envoyé.
La contention en Gpon n'est pas l'arbre en 2,5 Gb/s mais l'OLT (qui regroupe plusieurs arbres avec chacun 2,5 Gb/s) sur un lien 1 Gb/s.
-
TF1, pourquoi toujours TF1.
BadMax ne parlait pas de TF1. TF1 ne diffuse pas les aventures de la "guerrière du peuple".
Il y a quelque chose comme 400 chaines TV chez Free.
-
C'est quand même celle où tu as le plus de chance d'avoir plusieurs personnes à utiliser le flux multicast en GPON.
-
TF1, pourquoi toujours TF1.
BadMax ne parlait pas de TF1. TF1 ne diffuse pas les aventures de la "guerrière du peuple".
Il y a quelque chose comme 400 chaines TV chez Free.
C'est quand même celle où tu as le plus de chance d'avoir plusieurs personnes à utiliser le flux multicast en GPON.
D'après une définition que j'ai trouvé https://sites.google.com/site/amitsciscozone/home/gpon/gpon-vlans-and-gem-ports (https://sites.google.com/site/amitsciscozone/home/gpon/gpon-vlans-and-gem-ports), j'ai un peu du mal à comprendre le multicast sur GPON.
Il y aurait donc un canal séparé pour cela mais comment ce canal est-il alimenté ? Tout le monde voit le flux des autres ?
-
Autre question: comment gérer le multicast en multi-opérateur ?
-
Déjà comme ils font du PPPoE ca va limiter l'utilité du multicast. Mais c'est une bonne question.
-
Orange n'est pas le seul en PPPoE sur le FTTH ?
(DHCP option 82 pour les autres)
-
Euh du coup, on envoit le flux TV dans le PPPoE ? En gros ça revient donc à de l'unicast.... bonjour la charge sur l'arbre !
-
Pour moi on peut toujours utiliser ce "débit moyen par abonné", mais avoir un taux de contention adapté aux usages d'aujourd'hui comme tu le dis. En d'autres termes, s'assurer d'avoir assez de marge pour ne pas avoir de saturation.
C'est bien, tu donnes toi-même des arguments pour te répondre.
Arrêtez-moi si je me trompe mais NC c'est :
* 50M partagés pour une poche d'abonnés 30M NC et ByTel
* 200M partagés pour une poche d'abonnés 100M NC et ByTel
* 400M partagés pour une poche d'abonnés 200M NC et 100M ByTel
Et tu me dis que 2,5G pour des abonnés à 1G c'est pas bon ?
Attention : 2,5G moins les chaines TV.
Avec beaucoup de chaines différentes, ce n'est pas forcèment négligeable.
-
La totalité des flux TV est envoyée sur l'arbre PON ou seulement celles regardées ? La logique voudrait qu'on envoie seulement les flux demandés, ce qui limiterait pas mal le débit.
-
Euh du coup, on envoit le flux TV dans le PPPoE ? En gros ça revient donc à de l'unicast.... bonjour la charge sur l'arbre !
Chez Orange la télé arrive par un VLAN séparé (841).
-
Mais ce Vlan est dans la session PPPoE ? Donc ça fait autant de flux à l'intérieur de l'arbre que d'abonné qui regardent la TV ?
-
La totalité des flux TV est envoyée sur l'arbre PON ou seulement celles regardées ? La logique voudrait qu'on envoie seulement les flux demandés, ce qui limiterait pas mal le débit.
Bien sûr, il n'est pas question d'envoyer 400 flux TV à 64 abonnés, ce serait de la folie furieuse. Je n'ai pas voulu laisser entendre cela.
Je voulais seulement dire qu'en plus de TF1, il y a environ 399 chaines chez Free, donc le fait de regarder la télé normale n'est pas négligeable du tout. Alors que sur un NRA/NRO c'est relativement moins important.
-
La totalité des flux TV est envoyée sur l'arbre PON ou seulement celles regardées ? La logique voudrait qu'on envoie seulement les flux demandés, ce qui limiterait pas mal le débit.
On envoi uniquement les chaînes demandées par des clients et si plusieurs clients demandent la même chaîne,c'est mutualisé (effectivement ce n'était pas possible au début du Gpon)
Un peu comme un DSLAM : Seul les chaînes regardées vont sur le lien 1 Gb/s du DSLAM et elles sont mutualisées.
-
Mais ce Vlan est dans la session PPPoE ? Donc ça fait autant de flux à l'intérieur de l'arbre que d'abonné qui regardent la TV ?
Non ce n'est pas le PPPoE qui transporte le VLAN ID.
Le GPON transporte du 802.1q (Ethernet), et l'OLT est configuré avec plusieurs VLAN qui ont des rôles différents et dont le mode d'encapsulation va être différent suivant les cas. Typiquement on pourrà avoir l'encapsulation suivante :
Pour la Data on aura :
GPON/802.1q/PPPoE/IP
Pour la Télé on aura :
GPON/802.1q/IP
-
Pour la Data on aura :
GPON/802.1q/PPPoE/IP
Quel est l'intérêt d'utiliser le PPPoE? Ca rajoute une couche supplèmentaire qui me semble assez inutile. Ne peut-on pas mettre directement de l'IP over Ethernet?
Leon.
-
Je ne sais plus qui avait avancé que le PPPoE permettrait de vendre plus facilement une "option 5" sur le FTTH.
-
Quel est l'intérêt d'utiliser le PPPoE? Ca rajoute une couche supplèmentaire qui me semble assez inutile. Ne peut-on pas mettre directement de l'IP over Ethernet?
Leon.
au pif: c'est pour des raisons de sécurité, provisioning et gestion des @ IP et aussi sans doute uniformité avec le DSL des systèmes et des gens qui gèrent tout ça. (j'ai entendu dire je sais plus ou les soucis de provisionner des IP sur le GPON).
-
La TV par GPON était possible en utilisant une 3ème longeur d'onde
Une composante WDM est présente dans les PON puisque le signal descendant (ou downstream) est à 1,49 μm et le signal montant (ou upstream) à 1,3 μm. Il existe également une option avec un triplexeur en réception à l'ONT pour la diffusion de vidéo sur un canal analogique à 1,55 μm. Néanmoins cette option semble de plus en plus être abandonnée au profit de la vidéo sur IP, ce qui permet de supprimer les composants analogiques les plus coûteux. En effet ce type de transmission nécessite une bonne linéarité (puissance optique / fréquence) des composants optoélectroniques
pour permettre, je pense, justement le "multicast" a l'instar du câble (même si c'était un canal analogique) sur le flux descendant, qui l'interdit à cause du chiffrement, et être compatible également avec le matériel des opérateurs cablés lors de la transition FTTx -> FTTH
Pour moi, dans l'arbre GPON, chaque chaîne regardée par un client est l'équivalent d'un flux unicast qui s'ajoute au reste. Je ne comprends pas sinon comment c'est possible de "mutualiser" le signal optique. Le voisin B qui regarde aussi France5 (et pas TF1) voit le flux du voisin A mais ne peut le déchiffrer.
-
On envoi uniquement les chaînes demandées par des clients et si plusieurs clients demandent la même chaîne,c'est mutualisé (effectivement ce n'était pas possible au début du Gpon)
Pour moi, dans l'arbre GPON, chaque chaîne regardée par un client est l'équivalent d'un flux unicast qui s'ajoute au reste. Je ne comprends pas sinon comment c'est possible de "mutualiser" le signal optique. Le voisin B qui regarde aussi France5 (et pas TF1) voit le flux du voisin A mais ne peut le déchiffrer.
Tout comme Snickerss, je me posais la question de savoir si lorsque mon voisin regarde la même chaîne que moi, le flux est envoyé 2 fois à chacun, ou est mutualisé.
Pour l'instant, je ne suis pas beaucoup plus avancé :P
-
pour permettre, je pense, justement le "multicast" a l'instar du câble (même si c'était un canal analogique) sur le flux descendant, qui l'interdit à cause du chiffrement, et être compatible également avec le matériel des opérateurs cablés lors de la transition FTTx -> FTTH
Attention à ne pas confondre broadcast et multicast. Le broadcast, c'est envoyer tout à tout le monde. C'est le réseau câblé actuel. Le multicast, c'est envoyer la même chose à plusieurs personnes, mais uniquement aux personnes qui le demandent.
Pour moi, dans l'arbre GPON, chaque chaîne regardée par un client est l'équivalent d'un flux unicast qui s'ajoute au reste. Je ne comprends pas sinon comment c'est possible de "mutualiser" le signal optique. Le voisin B qui regarde aussi France5 (et pas TF1) voit le flux du voisin A mais ne peut le déchiffrer.
Ca n'est pas de l'unicast, mais du multicast, à priori.
Le GPON peut clairement supporter le multicast, et heureusement, vu qu'il est destiné en grande partie à remplacer le câble. Il y a un mécanisme permettant à l'ensemble d'un arbre GPON (l'OLT + les ONTs) de se comporter comme un switch Ethernet qui supporterai le multicast. Du coup, si 2 clients regardent TF1 HD sur le même arbre, le signal n'est envoyé qu'une seule fois. Si sur ce même arbre, un 3ieme client ne regarde rien, son ONT ignore le flux multicast TF1 HD, et ne le transmet donc pas au décodeur. Et si personne ne regarde TF1 HD sur l'arbre, alors le signal n'est pas envoyé dans l'arbre.
Leon.
-
au pif: c'est pour des raisons de sécurité, provisioning et gestion des @ IP et aussi sans doute uniformité avec le DSL des systèmes et des gens qui gèrent tout ça. (j'ai entendu dire je sais plus ou les soucis de provisionner des IP sur le GPON).
Ils n'ont pas été jusqu'à utiliser de l'ATM en GPON par uniformité avec l'ADSL. ;)
-
sur le flux descendant, qui l'interdit à cause du chiffrement, et être compatible également avec le matériel des opérateurs cablés lors de la transition FTTx -> FTTH
Donc tu es en train de suggérer que sur un Wifi protégé (WPA, WPA2), à cause du chiffrement, il n'y a pas de broadcast ni de multicast? ;)
-
Attention à ne pas confondre broadcast et multicast. Le broadcast, c'est envoyer tout à tout le monde. C'est le réseau câblé actuel.
Sur le câble, les chaînes sont protégées par un chiffrement dont la clé primaire est enfermée dans la puce d'une carte à puce sécurisée, non?
C'est une forme de multicast.
-
Non, ce que tu décris n'est pas du multicast. Le principe du multicast, c'est de n'envoyer un flux qu'à ceux qui le demandent, et donc en corollaire de ne pas envoyer un signal à celui qui ne le demande pas. Toi qui aime bien les termes précis, le terme "multicast" désigne uniquement la partie "transport d'information", pas le cryptage de la chaine dont tu parles ici. Le câble, c'est du broadcast, et non du multicast, même si tout le monde n'a pas les droits, les moyens de décrypter tous les flux.
Le multicast sur du coax, ça existe mais c'est très rare, je ne crois pas que Numéricâble s'y soit mis (nécessite un parc 100% équipé de décodeurs modernes). Le multicast sur coax permet d'économiser des canaux : les chaines qui n'intéressent pas grand monde ne sont envoyées dans un arbre que si quelqu'un sur l'arbre demande la chaine.
Leon.
-
En GPON, le flux "multicast" va quand même être reçu par tout le monde, même si il ne sera pas décodé par tous. C'est quand même du multicast ?
-
Non, ce que tu décris n'est pas du multicast. Le principe du multicast, c'est de n'envoyer un flux qu'à ceux qui le demandent, et donc en corollaire de ne pas envoyer un signal à celui qui ne le demande pas. Toi qui aime bien les termes précis, le terme "multicast" désigne uniquement la partie "transport d'information", pas le cryptage de la chaine dont tu parles ici. Le câble, c'est du broadcast, et non du multicast, même si tout le monde n'a pas les droits, les moyens de décrypter tous les flux.
À ce compte là, ni EPON/GPON, ni Wifi, ni Ethernet coaxial, ni Ethernet RJ45 avec un hub, ni Ethernet RJ45, avec un switch basique, enfin aucun système basé sur la diffusion, qui envoie tout à tout le monde, ne supportent le multicast.
-
En GPON, le flux "multicast" va quand même être reçu par tout le monde, même si il ne sera pas décodé par tous. C'est quand même du multicast ?
L'unicast aussi est reçu par tout le monde, même si tout le monde n'a pas la clé AES.
Est-ce quand même de l'unicast?
-
Héhé :)
Donc on peut dire que le *cast ne dépend pas de qui reçoit le flux chiffré mais de qui sait le déchiffrer ?
-
Le multicast est souvent mis en oeuvre par du broadcast. C'est juste une histoire de niveau auquel on regarde les choses.
pour le GPON et la TV: ne peut t'on pas chiffrer que par VLAN ?
Si j'ai bien compris le chiffrage dans le GPON, ca se fait dans le payload uniquement (GEM). Donc on peut envisager de ne crypter que les payload 'privés' (qui ne seront decryptables que par un seul ONT donc) et pas ceux qui concernent le broadcast des chaines TV. C'est un peu 'too much' de crypter tout le flux ou d'avoir plusieurs cryptages differents en fonction de ce qui passe.
Enfin je présume qu'ils ont prévu le coup, ca serait idiot de balancer X fois la meme chaine quand meme... ou pas car apres c'est peut-etre un choix d'opérateur par rapport aux couts des equipements actuels (OLTet ONT) comparés a la surcapacité actuelle des fibres déployées...
-
Donc tu es en train de suggérer que sur un Wifi protégé (WEP, WPA, WPA2), à cause du chiffrement, il n'y a pas de broadcast ni de multicast? ;)
Je suis le même raisonnement que Snickerss. Si chaque client dispose de sa propre clé de chiffrement, ne permettant de ne recevoir que le flux qui lui est destiné, comment peut-on mettre en œuvre du multicast ?
Le multicast serait pris en charge dès la couche liaison (ex : Wifi), et donc que 2 clients possédant une clé différente, pourrait s'inscrire au même multicast ? ???
Ou alors, comme le propose kgersen, seul le VLAN relatif à Internet est chiffré, mais celui relatif aux flux TV. La transmission du VLAN en clair permettant alors la mise en œuvre du multicast.
J'ai tout à apprendre sur le fonctionnement du multicast ;)
-
Qu'est-ce que tu appelles "couche liaison"?
-
Dans ton exemple de Wifi protégé (WEP, WPA, WPA2), je considérais que la touche liaison était celle sur laquelle s'applique le chiffrement.
Et qu'au dessus (couche transport), c'était IP.
Mais je n'ai peut-être pas été assez rigoureux.
-
Donc tu es en train de suggérer que sur un Wifi protégé (WEP, WPA, WPA2), à cause du chiffrement, il n'y a pas de broadcast ni de multicast? ;)
en wep, tout le monde (tout les clients, bien sur, pas les autres, encore que wep n'est plus vraiment une protection) utilise la même clé, et je crois que cette clé de chiffrement est la même en unicast et en multicast (et donc broadcast)
en wpa,wpa2/rsn, chaque client possède sa propre clé de pair (ptk) plus une clé de groupe (gtk), partagé par tout les clients
-
Le multicast sur du coax, ça existe mais c'est très rare, je ne crois pas que Numéricâble s'y soit mis (nécessite un parc 100% équipé de décodeurs modernes). Le multicast sur coax permet d'économiser des canaux : les chaines qui n'intéressent pas grand monde ne sont envoyées dans un arbre que si quelqu'un sur l'arbre demande la chaine.
Bonjour, le "Multicast" sur le câble (son nom est SDV pour Switched Digital Video) est utilisé pour des chaînes à faible audience sur le réseau Numericable depuis mars 2011.
La Bbox fibre a été le premier décodeur compatible (c'était nécessaire pour augmenter le nombre de chaînes et limiter les différences avec la Bbox ADSL, qui a plus de chaînes - encore aujourd'hui - que la Bbox fibre sur le réseau Numericable)
Aujourd'hui les box Numericable sont compatible (sauf des anciens modèles) et de nombreuses chaînes à faible audience sont passées en SDV.
Techniquement, cela utilise les EQAM et les canaux installés pour la VoD. Par contre, si plusieurs abonnés regardent le même programme, la chaîne n'est émise qu'une seule fois, comme en multicast. Si aucun abonné ne regarde, on libère la ressource qui peut être utilisée alors par d'autre chaîne SDV ou de la VoD.
(https://lafibre.info/images/altice_cable/201105_SDV-Cisco-GC.jpg)
Afin d'éviter qu'un abonné laisse son décodeur allumé sur une chaine SDV et conserve la ressource plusieurs jours, un message après plusieurs heures pour demander si la personne regarde le programme. En absence d'appui sur le bouton ok, on considère que personne ne regarde la chaîne et le flux est coupé, les ressources libérées.
=> SDV (Switched Digital Video) chez Numericable: des chaînes en plus (https://lafibre.info/numericable-fttla/sdv/)
-
Je comprends, mais je ne crois pas que le terme "multicast" soit idéal; je préfère
- diffusion conditionnelle
- ou bien simili-IGMP
Qu'est-ce qui empêche un autre abonné de regarder ce même flux s'en "s'abonner"?
-
Dans ton exemple de Wifi protégé (WEP, WPA, WPA2), je considérais que la touche liaison était celle sur laquelle s'applique le chiffrement.
Et qu'au dessus (couche transport), c'était IP.
Mais je n'ai peut-être pas été assez rigoureux.
C'est une simple incompréhension de vocabulaire.
Wifi implèmente une couche simili-Ethernet qui est chiffrée. C'est un peu comme IPsec, mais on ne met pas de l'IP dans de l'IP, on met de l'IP (ou autre) dans des trames Wifi.
Pour résumer, WPA c'est une sorte de VPN.
-
Voila ce qu'en dit l'ITU, mais c'est très indigeste :
ITU G.984.3 : (http://www.itu.int/rec/T-REC-G.984.3/fr)
"Note that multicast can be supported by using Port-IDs that are configured to belong to multiple ONUs on the PON. The mandatory method of supporting multicast services over GEM uses a single Port-ID for all streams, while the optional method uses multiple Port-IDs. ONU's multicast capabilities are discovered by the OLT via the OMCI interface."
ITU G.984.4 : (http://www.itu.int/rec/T-REC-G.984.4/fr)
"6.4 Support of multicast connection
Multicast traffic can be supported in a G-PON network. While a port-ID is assigned to a single UNI
in a unicast connection, a port-ID is shared by multiple UNIs in multiple ONTs in a multicast connection.
The multicast connection set-up process is the same as the unicast connection set-up process. It is
the responsibility of the OLT to manage the members of a multicast group and control the multicast connection
in ONTs.
In the downstream direction, a multicast connection is useful for bandwidth savings. On the other
hand, in the upstream direction, it is impossible to support the multicast connection with a shared port-ID
because the OLT cannot reassemble segmented GEM packets correctly when it receives several GEM packets
with same port-ID from different ONTs. Therefore, upstream traffic associated with a multicast service must be
sent to the OLT over a separate unicast connection."
[...]
"Multicast interworking GEM modes of operation
The default multicast operation of the PON is where all the multicast content streams are placed in
one PON layer connection (GEM port). This connection is then specified in the first entry of the
multicast address table. This single entry also specifies an all-inclusive IP multicast address range
(e.g., 224.0.0.0 to 239.255.255.255). The ONT then filters the traffic based on either Ethernet MAC
addresses or IP addresses. The GEM port network CTP ME contains the GEM port-ID that supports
all multicast connections.
An optional multicast operation is where groups of one or more multicast content streams are
carried over individual PON layer connections, i.e., on separate GEM ports, but terminate on a
single multicast GEM interworking termination point. In this case, the OLT sets as many table
entries as desired for the multicast control system. The ONT can initially filter groups based on
PON layer address (GEM port). In a subsequent step, the ONT can also filter based on higher-layer
addresses. In this case, the OLT need create only one instance of the GEM port network CTP ME.
Though this GEM port network CTP ME cites only one GEM port-ID, the ONT should regard this
ME as the representative of all multicast GEM connections served by the multicast GEM
interworking TP. The traffic descriptors, priority queues, and performance management features for
all multicast connections are integrated into the single GEM port network CTP ME.
Several multicast GEM interworking termination points can exist, each linked to separate bridge
ports or mappers to serve different communities of interest in a complex ONU."
-
ici c'est plus facile a comprendre : https://sites.google.com/site/amitsciscozone/home/gpon/gpon-vlans-and-gem-ports
enfin ca depend du mal de tete au moment de la lecture :p
-
Ce que j'en est compris, c'est qu'il y a deux modes pour faire du multicast sur du GPON.
Le premier utilisé par défaut, n'utilise qu'un GEM Port-ID pour tout le trafic multicast. Ce qui veut dire que même ceux qui n'en sont pas destinataires peuvent le lire.
Le deuxième optionnel, pour lequel l'OLT associe un GEM Port-ID pour chaque groupe multicast (IGMP) qu'il gère. Seul les ONT sur lesquels il y a un abonné au groupe multicast sont associés au GEM Pot-ID est traitent les trames qui lui sont destinées. Si tant est qu'une clé soit négociée pour chaque GEM Port-ID ce qui n'est pas claire, seul les membres peuvent en voir le contenue.
-
Bonjour, le "Multicast" sur le câble (son nom est SDV pour Switched Digital Video) est utilisé pour des chaînes à faible audience sur le réseau Numericable depuis mars 2011.
La Bbox fibre a été le premier décodeur compatible (c'était nécessaire pour augmenter le nombre de chaînes et limiter les différences avec la Bbox ADSL, qui a plus de chaînes - encore aujourd'hui - que la Bbox fibre sur le réseau Numericable)
Aujourd'hui les box Numericable sont compatible (sauf des anciens modèles) et de nombreuses chaînes à faible audience sont passées en SDV.
Techniquement, cela utilise les EQAM et les canaux installés pour la VoD. Par contre, si plusieurs abonnés regardent le même programme, la chaîne n'est émise qu'une seule fois, comme en multicast. Si aucun abonné ne regarde, on libère la ressource qui peut être utilisée alors par d'autre chaîne SDV ou de la VoD.
(https://lafibre.info/images/altice_cable/201105_SDV-Cisco-GC.jpg)
Afin d'éviter qu'un abonné laisse son décodeur allumé sur une chaine SDV et conserve la ressource plusieurs jours, un message après plusieurs heures pour demander si la personne regarde le programme. En absence d'appui sur le bouton ok, on considère que personne ne regarde la chaîne et le flux est coupé, les ressources libérées.
=> SDV (Switched Digital Video) chez Numericable: des chaînes en plus (https://lafibre.info/numericable-fttla/sdv/)
Désolé de déterrer ce sujet, quoique très interessant.
Une question à ce propos : quelle était la technologie employée par Bouygues sur ses offres THD en FTTla ? de l'IPTV en SDV comme indiqué ou un mélange entre le DVB-C et l'IPTV ?
J'ai toujours pensé que l'offre TV entière de Bouygues THD sur ce réseau était uniquement en IPTV, ce dernier ne louant que l'usage du câble pour la DOCSIS et non le DVB ?
-
Sur un arbre Gpon la diffusion d'une chaine s'apparente en effet a du broadcast : dans le sens ou si 1 ONT demande le flux, tout les autres ONT de l'arbre les reçoivent aussi.
Néanmoins, recevoir un flux ne veut pas dire qu'on peut le déchiffrer, ça c'est le rôle du CAS et de la STB.
-
Désolé de déterrer ce sujet, quoique très interessant.
Une question à ce propos : quelle était la technologie employée par Bouygues sur ses offres THD en FTTla ? de l'IPTV en SDV comme indiqué ou un mélange entre le DVB-C et l'IPTV ?
J'ai toujours pensé que l'offre TV entière de Bouygues THD sur ce réseau était uniquement en IPTV, ce dernier ne louant que l'usage du câble pour la DOCSIS et non le DVB ?
C'était (et c'est toujours le cas pour les abonnés encore présents) un mix de DVB-C et de SDV, comme sur le réseau SFR (Bouygues reprenait la majeure partie des chaînes DVB-C de Numericable). C'est d'ailleurs un avantage pour car les flux TV n'ont aucun impact sur la vitesse de connexion.
-
C'était (et c'est toujours le cas pour les abonnés encore présents) un mix de DVB-C et de SDV, comme sur le réseau SFR (Bouygues reprenait la majeure partie des chaînes DVB-C de Numericable). C'est d'ailleurs un avantage pour car les flux TV n'ont aucun impact sur la vitesse de connexion.
OK !
Donc sur les offres actuelles de SFR THD en FTTLa, les 8 tuners du Zive/TVHD4k ne sont pas exploitables pour les chaines en IPTV/SDV j'imagine ?
Parmi les particularités de la Box Zive, citons notamment la présence de 8 tuners TV qui permettront de gérer de multiples chaînes simultanèment au sein du foyer. La Box Zive permettra ainsi de "regarder en même temps un flux live en 4K/UHD en gardant un œil sur une autre chaîne grâce au Picture in Picture, et d’enregistrer deux autres flux" selon SFR.
http://www.ariase.com/fr/news/lancement-box-zive-sfr-article-3939.html
-
Si, cela fonctionne quand même ;)
-
Si, cela fonctionne quand même ;)
Je pensais que tous ces tuners, c'était justement car on est sur du broadcast en DVBC.
Mais pour les chaines IPTV, ils envoient vraiment 8 flux différents pour un même client ?
-
Les chaînes SDV ne sont envoyées qu'une fois (si plusieurs clients la regardent, elle n'est envoyée qu'une seule fois).
Mais précise ce que tu veux faire (note : les chaînes SDV sont des chaînes de faible audience).
-
Les chaînes SDV ne sont envoyées qu'une fois (si plusieurs clients la regardent, elle n'est envoyée qu'une seule fois).
Mais précise ce que tu veux faire (note : les chaînes SDV sont des chaînes de faible audience).
Merci pour la précision.
Je me demandais justement pourquoi Numéricable n’associait pas les deux technologies. Ils ne m'ont pas visiblement pas attendus ! :D
-
Merci pour la précision.
Je me demandais justement pourquoi Numéricable n’associait pas les deux technologies. Ils ne m'ont pas visiblement pas attendus ! :D
non, et depuis des années....