< Retour aux articles

Publié le 20 juillet 2015

Nous avons évoqué, dans un post précédent, le déploiement de la voix sur LTE par les opérateurs de téléphonie mobile comme une réponse à la concurrence de la voix sur IP et nous avions évoqué certaines précautions à prendre pour pratiquer un déploiement « dérisqué ». Nous voudrions rajouter deux ou trois éléments qu’il nous semble utile de prendre en compte pour un déploiement optimisé.

La 3GPP (3rd Generation Partnership Project) a défini l’identifiant de niveau de qualité de service (QCI*) ; cet indicateur est fourni au nœud d’accès radio lors de l’établissement d’un nouveau « tuyau » (bearer), lui permettant de connaitre la qualité minimale qu’il devra garantir pour tout paquet de donnée transitant par ce « tuyau ». A chaque « bearer » correspond un QCI pour le réseau utilisé, en fonction des paramètres de contrôle des paquets acheminés : poids annoncé, seuil d’admission, configuration du protocole des couches de liaison. La 3GPP a défini 9 possibilités avec des Qualités de Services différentes et des taux de débit garantis** en fonction de leurs utilisations. Par exemple, le QCI 3 présentera des paramètres adaptés au transport de jeux en ligne alors que pour transporter de la voix, du chargement vidéo et du jeu interactif sur un même tuyau il conviendra d’adopter le QCI 7 pour optimiser son investissement***. C’est au moment du choix du « bearer » et de sa QoS associée que l’opérateur va décider des services à faire passer dans ce tuyau : en conséquence, tous les services qui passeront dans le tuyau défini auront la même qualité de service garanti. Généralement, les opérateurs ne déploient pas les 9 classes de QoS recommandées (le déploiement de chaque classe ayant un coût très élevé), mais définissent une classe par défaut et en ajoute une ou deux autres pour des besoins particuliers, le tuyau par défaut servira essentiellement à faire passer de la signalisation (demande de service) et permettra d’établir les bearers dédiés pour différents services ; ainsi on fera toujours passer la VoLTE sur un bearer spécifique. La question à se poser en premier lieu est celle de connaître précisément les services associés à la VoLTE qui doivent passer dans ce même tuyau : par exemple, est-ce que le jeu en ligne (qui a des contraintes très fortes en termes de qualité de services), ou la vidéo, vont être mis sur le même tuyau que la VoLTE ou sur un tuyau différent ? Si l’opérateur n’utilisent pas toutes les classes recommandées par la 3GPP, va-t-il faire des regroupements de services dans une même classe et laquelle ( ?), le risque des regroupements étant bien sûr d’altérer la qualité de la voix sur LTE. Il y a donc un calcul de rentabilité à faire en fonction de l’analyse qualitative des besoins estimés. La qualité de la voix dans les réseaux LTE est de plus en plus exigée et il s’agit de vérifier combien d’appels vocaux simultanés peuvent être gérés. La réponse passe par le SPS (Semi Persistent Scheduling****). En résumé, pour envoyer un paquet de données sur le réseau, une demande est générée au réseau qui indique en retour où peut être envoyé le paquet, l’opération se répétant en permanence pour chaque paquet ; dans le cas de la voix, un échange vocal générant un certain nombre de paquets pendant une durée minimale, au-delà du volume de communications parallèles qui peut être maintenu, les autres communications seront rejetées ou placées en attente. Il est donc important d’avoir une étude fine du contrôle d’admission (combien de calls peuvent être acceptés en parallèle ?). Un autre élément, à intégrer dans le raisonnement, est la faible consommation électrique de la VoLTE native sur les appareils, contrairement à différentes formes de voix sur IP. Au final, les études menées montrent des disparités importantes dans la qualité des réseaux opérateurs, du fait des fonctionnalités déployées ou non.

*QCI: QoS Class Identifier

**Guaranteed Bit Rate (GBR) or non-Guaranteed Bit Rate (non-GBR)  ***http://en.wikipedia.org/wiki/QoS_Class_Identifier

**** http://lteuniversity.com/get_trained/expert_opinion1/b/mmcarthy/archive/2013/12/04/semi-persistent-scheduling-sps.aspx

8