Les solutions de virtualisation de fonctions réseaux – connue sous l’acronyme NFV[1] en anglais – sont aujourd’hui matures et ont démontré leurs avantages : réduction des temps de lancement de nouveaux services et optimisation des CAPEX et OPEX. Dès lors, la question qui se pose aux opérateurs n’est plus « faut-il virtualiser ? », mais « à quel moment et suivant quelle approche ? ».
La virtualisation de fonctions réseaux suppose un investissement conséquent dans l’infrastructure puisque les fonctions logicielles virtualisées nécessitent de nouveaux serveurs, virtualisés eux aussi (IaaS), dont l’opérateur ne dispose peut-être pas ou pas en quantité suffisante.
Pour basculer vers le NFV, l’opérateur se posera trois questions clés.
1. La virtualisation peut-elle répondre à mes enjeux ?
L’intérêt de la virtualisation de fonctions réseaux dépend à la fois du type de fonction considéré et de la nature des dépenses d’investissement que l’opérateur doit réaliser pour transformer son réseau et développer son business. On distingue 3 cas de figure avec des contextes plus ou moins déclencheurs.
Premier cas de figure, l’opérateur est confronté à la nécessité de renouveler, de mettre à jour ou encore d’acquérir des fonctions essentielles et coûteuses qui nécessitent donc d’importantes dépenses d’investissement:
- soit parce que des logiciels majeurs comme l’EPC[2] ou de l’IMS[3], deviennent obsolètes et ne bénéficient plus d’un support du vendeur ;
- soit parce que l’opérateur doit augmenter leur capacité ;
L’opérateur ne peut pas se permettre d’investir massivement dans une technologie sans avenir. La virtualisation s’impose à lui.
soit encore parce que l’opérateur a identifié un besoin business et souhaite se positionner dans les meilleurs délais sur un nouveau relais de croissance : par exemple, le lancement de la VoLTE.
Dans ces trois cas, le moment est venu pour l’opérateur d’investir dans des fonctions réseaux virtualisées.
Deuxième situation pour l’opérateur : certaines de ses fonctions réseaux moins coûteuses, comme les fonctions AAA ou DNS, deviennent obsolètes ou atteignent leur pleine capacité. Pour limiter ses dépenses d’investissement, l’opérateur peut choisir de renouveler ces fonctions à l’identique sur sa technologie actuelle et différer d’1 ou 2 ans son investissement dans des logiciels et des serveurs virtualisés.
Cependant, si l’opérateur dispose déjà de l’infrastructure apte à accueillir les fonctions virtualisées, peut-être l’opportunité s’offre-t-elle à lui d’accélérer sa transition vers la virtualisation.
Dans tous les cas où l’opérateur a investi récemment dans ses logiciels réseaux, et en l’absence de facteurs déclencheurs tels que décrit ci-dessus, le passage à la virtualisation ne se justifie pas à court terme.
2. Virtualiser les réseaux en suivant quelle méthodologie ?
Une fois qu’il a identifié des situations propices à la virtualisation, l’opérateur doit structurer sa démarche sur le moyen terme. Il n’existe pas d’approche de la virtualisation standard applicable partout dans le monde. Chaque opérateur a ses spécificités de marché, ses ambitions de business, ses contraintes budgétaires et opérationnelles qu’il convient d’étudier en détail suivant une méthodologie rigoureuse.
Conduire la transformation d’un réseau revient à construire un schéma directeur sur plusieurs années comprenant principalement :
- Un état de l’art du réseau de l’opérateur, incluant l’identification des fonctions candidates à la virtualisation.
- Un plan de transformation donnant une vision globale du réseau à terme et une feuille de route détaillée.
- Une évaluation budgétaire avec une priorisation des investissements.
- Une analyse de rentabilité et d’optimisation des CAPEX et des OPEX.
- Un cadre de gouvernance du programme.
Ce schéma directeur permet à l‘opérateur de prioriser ses choix et ses investissements au regard de ses objectifs stratégiques et de planifier ses budgets.
3. Comment bâtir mon infrastructure as a service (IaaS) ?
L’infrastructure hébergeant les fonctions réseaux virtualisées est étroitement liée à la stratégie cloud de l’opérateur, c’est-à-dire à sa stratégie de migration vers une infrastructure virtualisée (IaaS) ainsi qu’à sa stratégie de convergence télécom/IT.
Deux options s’offrent à l’opérateur pour bâtir l’infrastructure IaaS sur laquelle seront déployées des fonctions virtualisées.
L’infrastructure du fournisseur de la fonction réseau
Soit il adopte une infrastructure fournie par le vendeur de la fonction réseau. C’est alors le fournisseur qui conçoit, construit et déploie la solution intégrant le hardware et le software. Dans ce cas, l’opérateur peut choisir de déléguer à ce vendeur certaines responsabilités, comme :
- le déploiement de bout en bout de la solution,
- les opérations et maintenance de la solution.
Cette option le décharge d’investissements conséquents en ingénierie et limite ses risques opérationnels. L’inconvénient c’est l’enfermement propriétaire : il sera très difficile pour l’opérateur de faire déployer sur ces infrastructures des fonctions proposées par les vendeurs concurrents. Même s’il sélectionne plusieurs fournisseurs pour conserver une certaine indépendance, il risque de retomber dans le fonctionnement en silo auquel il cherche à échapper en virtualisant. Il fera peut-être des économies de CAPEX à court terme mais risque d’être financièrement perdant sur le moyen terme.
Une infrastructure open source
Soit il fait le choix de bâtir sa propre infrastructure sur la base de briques Open Source. Alors, c’est l’opérateur qui fait l’ingénierie de la solution, choisit ses composants hardware et coordonne les déploiements des fonctions qu’il a sélectionnées avec chaque fournisseur.
Plus de problème d’enfermement propriétaire, mais des prérequis qui ne sont pas à la portée de tous. En effet, l’opérateur doit disposer des ressources nécessaires à la mise en œuvre de ce modèle : un budget conséquent, des équipes d’ingénierie aptes à concevoir l’infrastructure et à définir un modèle opérationnel solide avec des matrices de responsabilités claires, des équipes d’exploitation intégrant des experts réseaux et des experts IT.
Définir quoi, comment et quand virtualiser demande d’une part de structurer la transformation des réseaux dans la durée à l’aide d’un schéma directeur, et d’autre part de définir l’infrastructure qui va héberger les fonctions.
La sélection des fonctions à virtualiser et leur séquencement se fera selon différents critères dont l’obsolescence, les besoins capacitaires, ou encore le lancement d’un nouveau service, et la durée d’investissement.
Le choix de l’infrastructure dépendra de l’ambition stratégique de l’opérateur d’évoluer à plus ou moins long terme vers l’IaaS et la convergence télécom/IT. Deux autres paramètres guideront aussi ses choix: sa capacité budgétaire et le modèle opérationnel cible le plus adapté à sa situation.
[1] Network Function Virtualization
[2] Evolved Packet Core
[3] IP Multimedia System
