Auteur Sujet: 2G/3G : Commutation de circuits et collecte IP (Lu 5251 fois)

renaud07 · « **le:** 27 janvier 2017 à 18:03:22 »

Bonsoir,

Suite au message de Snickerss , 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.

eruditus · « **Réponse #1 le:** 27 janvier 2017 à 19:05:51 »

Avec le temps, on a réussi à faire plein de choses over ethernet

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

renaud07 · « **Réponse #2 le:** 27 janvier 2017 à 19:42:58 »

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.

renaud07 · « **Réponse #3 le:** 30 janvier 2017 à 03:20:28 »

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 ?

thenico · « **Réponse #4 le:** 30 janvier 2017 à 06:25:03 »

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.

renaud07 · « **Réponse #5 le:** 30 janvier 2017 à 17:04:32 »

Citation de: thenico le 30 janvier 2017 à 06:25:03

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...

BadMax · « **Réponse #6 le:** 30 janvier 2017 à 17:59:42 »

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.

vivien · « **Réponse #7 le:** 30 janvier 2017 à 19:26:05 »

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.

renaud07 · « **Réponse #8 le:** 31 janvier 2017 à 02:48:44 »

Citation de: vivien le 30 janvier 2017 à 19:26:05

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.

BadMax · « **Réponse #9 le:** 31 janvier 2017 à 10:18:32 »

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.

renaud07 · « **Réponse #10 le:** 31 janvier 2017 à 17:56:40 »

Citation de: BadMax le 31 janvier 2017 à 10:18:32

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.

vivien · « **Réponse #11 le:** 31 janvier 2017 à 19:22:38 »

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...