La Fibre
Fournisseurs d'accès à Internet mobile et 5G/4G fixe => 4G 5G Mobile => 
Technologie mobile 4G => Discussion démarrée par: renaud07 le 27 janvier 2017 à 18:03:22
-
Bonsoir,
Suite au message de Snickerss (https://lafibre.info/4g/crozon/msg410569/#msg410569), il m'est venu une question : D'après ce que je comprends, le trafic est transformé en IP à la sortie de l'enode, du coup comment est géré la partie voix qui est censé être en commutation de circuits avec un débit garanti et sans faille, même si saturation du reste ?
Car si je vois très bien comment ça peut fonctionner en ATM, E1 ou SDH, avec IP le seul protocole qui pourrait faire un peu la même chose c'est TCP, hors celui-ci est bien trop lent pour du temps réel. Du coup ça se passe comment ? On utilise UDP + QoS, comme en Voip classique ? Il y'a des VLAN (même si je ne pense pas que ça serve à grand-chose) ?
Dans ce cas le cœur de réseau est en tout IP ou c'est retransformé à l'arrivée ? En gros la partie CS ne subsiste qu'entre le mobile et l'enode ?
Merci d'avance.
-
Avec le temps, on a réussi à faire plein de choses over ethernet :D
La transformation des cœurs de réseaux fixe avec l'IMS et l'avènement du MPLS ont ouvert la voix pour la transformation des réseaux d'accès, et de leur réseau de transport.
Un peu de lecture, et si tu as encore des questions, nous essaierons d'y répondre
http://lteuniversity.com/get_trained/expert_opinion1/b/skrishnamurthy/archive/2013/04/01/why-ethernet-backhaul.aspx
Dans ce cas le cœur de réseau est en tout IP ou c'est retransformé à l'arrivée ?
- cœur de réseau IMS comme dans le fixe.
En gros la partie CS ne subsiste qu'entre le mobile et l'enode ?
- non, c'est logiquement scindé entre CS et PS jusqu'au cœur de réseau
On utilise UDP + QoS
- en VoLTE oui, pour 2G et 3G je dirais probablement (mais à vérifier car il y avait la fonction transcoder en 2G au moins dans le reseau d'accès)
- il y a des vlans qui permettent de séparer certains flux comme le user plan du contrôle plan, la supervision
-
Merci pour ta réponse.
Très complet cet article :)
Concernant ma question je crois avoir la réponse : CESoPSN. Je ne savais pas que ça avait été adapté pour Ethernet. Je pensais que c'était spécifique à l'ATM.
-
J'imagine qu'il faut des switchs/routeurs avec hardware spécifique, sinon est-ce que ça serait un bonne solution (le CESoPSN) pour améliorer la qualité de la VoIP si c'était utilisé sur le net en comparaison de la QoS basique ?
D'ailleurs, t'aurais pas un p'tit exemple de routeur qui gère ça ?
-
Le problème de la VoIP sur Internet, c'est plus le fait que personne n'accepte la QoS venant d'un eyeball ou d'une autre AS.
-
Le problème de la VoIP sur Internet, c'est plus le fait que personne n'accepte la QoS venant d'un eyeball ou d'une autre AS.
Ah je savais pas, mais ça ne m'étonne pas vraiment. Comme d'hab, tout le monde se fout du trafic du voisin.
Pour avoir de la Qos il faudrait que toutes les personne avec qui on discute soit abonnées au même FAI avec un VPN MPLS...
-
C'est pas que tout le monde se fiche du trafic du voisin c'est qu'il est difficile de truster le champ dscp d'un paquet arrivant d'on ne sait où.
Il est fréquent de dropper ce champ en entrée du réseau histoire d'être sûr.
-
Si les opérateurs permettait de prioriser un trafic en fonction du champ DSCP alors de nombreux opérateurs taguerait leur trafic en prioritaire...
Le seul opérateur que j'ai observé qui ne supprime pas les champ DSCP en entrée du réseau, c'est Adeli. Maintenant, je ne sais pas si ils sont utilisés.
-
Si les opérateurs permettait de prioriser un trafic en fonction du champ DSCP alors de nombreux opérateurs taguerait leur trafic en prioritaire...
Les routeurs ne sont pas assez intelligents pour différentier un paquet http priorisé d'un paquet SIP ou RTP ? Bon ça demande plus de ressources, mais à ce qui parait ce n'est plus un problème depuis quelques années.
-
Ca dépend de quel routeur on parle : en périphérie, c'est simple à faire, c'est traité en soft. En backbone, ça dépend car si certains traitements hardware peuvent être utilisés, on ne peut pas non traiter tous les scénarios. Les puces hards (ASIC) n'ont pas des ressources infinies en taille d'ACL.
Cela ne gêne pas le problème de fond : qui te dit que le trafic SIP reçu est légitime ? Ca serait une porte ouverte à un joli DDoS.
-
Cela ne gêne pas le problème de fond : qui te dit que le trafic SIP reçu est légitime ? Ca serait une porte ouverte à un joli DDoS.
C'est vrai que je n'avais pas pensé à ça.
-
Il est possible de jouer plus fin avec, une priorisation limitée en terme de trafic. Les équipements actuels savent faire ça.
Après pourquoi le faire pour la VoIP et pas pour le gaming ou le SSH ?
Sans parler de la neutralité du réseau qui est un peu entachée...
-
Il est possible de jouer plus fin avec, une priorisation limitée en terme de trafic. Les équipements actuels savent faire ça.
Après pourquoi le faire pour la VoIP et pas pour le gaming ou le SSH ?
Sans parler de la neutralité du réseau qui est un peu entachée...
Parce que la VoIP c'est de la voix ? Et qu'avoir des coupures sur ce genre de service est difficilement acceptable (appels d'urgence...) ? On peut faire le parallèle avec le RTC, y'a t-il des coupures dessus ? Non, le débit est garanti de bout-en-bout. Je ne vois pas pourquoi sous prétexte qu'elle change de média de transport, elle devrait être traitée comme un protocole classique.
Vu que maintenant tout est sur ip et non plus séparé, la téléphonie devrait être prioritaire sur la TV elle même prioritaire sur le reste.
Pour moi, y aurait soucis de neutralité si HTTP était prioritaire sur FTP par exemple. Pour ce qui est téléphonie et TV, je n'y vois aucun inconvénient, vu qu'à la base ces services ne sont pas issus d'internet et de part leur nature "critique", les prioriser sur le reste ne me choque pas.
-
Comment tu veut tagguer sans abus un flux RTP ou SIP traversant plusieurs AS?
C'est pour cela que la VoIP n'est garantie que sur un morceau d'AS (eyeball => serveur voip de l'ISP, VRF du VPN MPLS, etc ...).
-
Comment tu veut tagguer sans abus un flux RTP ou SIP traversant plusieurs AS?
C'est pour cela que la VoIP n'est garantie que sur un morceau d'AS (eyeball => serveur voip de l'ISP, VRF du VPN MPLS, etc ...).
Je ne vois pas où est la difficulté là dedans. Si un paquet est taggué au départ, c'est quoi le soucis pour qu'il reste tel-quel tout au long de son parcours ? Un routeur, de base, n’est pas censé modifier les paquets qu'il reçoit.
-
Je ne vois pas où est la difficulté là dedans. Si un paquet est taggué au départ, c'est quoi le soucis pour qu'il reste tel-quel tout au long de son parcours ? Un routeur, de base, n’est pas censé modifier les paquets qu'il reçoit.
Et 10 minutes après l'application de ce paramètres sur les routeurs, tu as 3/4 de la populations qui installera un pseudo-booster reconfigurant la stack IP pour èmettre un DSCP 46.
-
Et 10 minutes après l'application de ce paramètres sur les routeurs, tu as 3/4 de la populations qui installera un pseudo-booster reconfigurant la stack IP pour èmettre un DSCP 46.
Faudrait déjà que les 3/4 de la population sache ce qu'est un paquet IP et la notion de QoS...
Enfin bref, j'ai bien compris que ça ne se ferait jamais. Mais techniquement rien ne l'empêche. Hâte de voir à quoi ça va ressembler une fois que le monde entier sera passé au tout IP.
-
Faudrait déjà que les 3/4 de la population sache ce qu'est un paquet IP et la notion de QoS...
Ils n'ont pas besoin de le savoir ce que fait l'outil, juste de connaître les conséquences (ie Internet va plus vite (jusqu’à ce que la masse critique soit atteinte du moins)).
Regarde la propagation des logiciels de P2P il y a une dizaine d'année, la plupart des utilisateurs n'étaient pas des geeks.
Juste des gens qui suivaient un morceau de Howto trouvé quelque part (regarde dans le catalogue de ta bibliothèque, tu vas probablement trouver des bouquins le P2P pour les nuls circa 2005)