Comme nous en discutions dans notre précédent post, l’introduction des NAT dans les réseaux actuels, si elle a résolu, du moins temporairement, le problème de la pénurie d’adresses IPv4, a par la même occasion engendré de nouvelles contraintes techniques pour un certain type de trafic, et plus particulièrement, en ce qui nous intéresse ici, en téléphonie sur IP (ToIP ou Telephony over IP). La prise en compte de ces nouvelles contraintes se repose sur la détermination du type de NAT que le trafic doit traverser. En effet, par un manque de cadre et d’orientation lors de leurs conceptions, leurs implémentations s’avèrent très disparates. Ce post vous décrit les différentes méthodes existantes permettant leur classification.

Les organismes de standardisation, IETF en tête, ont régulièrement tenté d’apporter une réponse simple à cette question. Au travers de la première spécification de STUN (protocole dont il sera question plus tard dans un futur post), l’IETF a tenté de catégoriser ces équipements sous 4 appellations différentes :

• Full Cone NAT
• Restricted Cone NAT
• Port-Restricted Cone NAT
• Symmetric NAT

Nos lecteurs familiers avec les télécoms et le problème des NAT ont déjà dû voir ces termes plus d’une fois. Ces termes, s’ils sont encore souvent considéré comme faisant référence, s’avèrent néanmoins vagues et perturbent la compréhension de certains cas de figure sortant de leur cadre. Cette terminologie ne correspond en effet qu’à une partie des types de NAT qu’il est possible de rencontrer au sein des réseaux actuels, amalgamant du même fait plusieurs fonctionnalités inhérentes aux NAT (association, filtrage, port, …)

L’IETF, partant de ce constat, a établit une nouvelle spécification permettant une définition exacte d’un NAT quel que soit le cas de figure et quelle qu’en soit l’implémentation. En effet, en traitant chaque fonctionnalité indépendamment, ces nouvelles définitions permettent de considérer tous les cas, même les plus improbables. Seul inconvénient à cela, il n’existe plus de terminologie courte tel que définit précédemment. Tout cela est bien beau, mais comment peut-on désormais définir quel type de NAT nous sépare du reste du monde ? Afin de comprendre cette problématique, abordons tout d’abord les principaux points qui vont nous intéresser ici, à savoir les types d’associations et les types de filtrages différents.

Les associations

Un NAT effectue une traduction d’une adresse privée vers une adresse publique. Toutefois, si ce comportement reste le même quel que soit le NAT considéré, certains détails l’altèrent sensiblement d’un cas sur l’autre.

Lorsque le client (la source) souhaite contacter un des serveurs (les destinations) montrés en exemple dans la représentation schématique ci-dessus, le NAT dispose de trois différentes méthodes pour gérer la traduction.

• Indépendante du point de terminaison (endpoint independant)

L’association effectuée ne se fait que sur la base de l’adresse et le port d’émission (X:x), sans prendre en compte la destination. De ce fait, si la source ne change pas, l’association restera toujours identique. Si tout ou partie (soit adresse et/ou port) de la source se trouve altérée, une association différente devra être utilisée.

Synthétiquement : pour un couple (X:x) donné, (X1:x1) ? (X2:x2) ? (Yn:yn)

Un NAT se comportant de cette manière respecte les recommandations de l’IETF.

• Dépendante de l’adresse de terminaison (address dependant)

A l’opposé du cas précédent, le NAT considère la destination lorsqu’il choisit quelle association utiliser. De ce fait, la moindre modification dans l’adresse de destination (et uniquement l’adresse) imposera au NAT de créer une nouvelle association. Bien évidemment, tout changement dans la source impliquera aussi une modification de l’association.

Synthétiquement, pour un couple (X:x) donné, (X1:x1) ? (X2:x2) ? Y1 ? Y2

• Dépendante de l’adresse et du port de terminaison (address and port dependant)

Le dernier cas de figure reprend les concepts du cas précédent, mais renforce encore la règle appliquée en envisageant aussi le port de destination lors du choix de l’association. De ce fait, seule une requête à destination de l’exacte même destination (adresse et port) est susceptible de réutiliser une association créée précédemment.

Synthétiquement, pour un couple (X:x) donné, (X1:x1) ? (X2:x2) ? (Y1:y1) ? (Y2:y2)  

Le filtrage

Traité distinctement des associations, la notion de filtrage va se charger de définir le comportement du NAT lorsqu’une requête venant de l’extérieur tente de traverser l’équipement. Considérons la représentation ci-dessous :

De manière similaire à ce qui a été définit pour les associations, le filtrage est aussi régit par 3 comportements différents.

• Indépendant du point de terminaison (endpoint independant)

Le NAT ne filtre que les requêtes en provenance du réseau public n’ayant pas comme destination le client X. Toute requête à destination d’un autre client n’ayant pas créé d’association au niveau du NAT est refusée. Toutefois, n’importe quel serveur Y peut contacter X par cette association.

Ce type de filtrage est recommandé par l’IETF dans une optique de transparence.

• Dépendant de l’adresse (address dependant)

Le NAT applique ici un mécanisme de filtrage simple, n’autorisant le trafic entrant que pour des adresses ayant au préalable été contactées par le client. De ce fait, si X contact Y1, seul Y1 sera en mesure de contacter X en retour. Si Y2 souhaite contacter X, ce dernier doit auparavant contacter le serveur pour créer une règle auprès du NAT quel que soit le type d’association, les deux fonctionnalités étant parfaitement indépendantes !

Si la sécurité est essentielle au réseau considéré, l’IETF recommande ce type de filtrage.

• Dépendant de l’adresse et du port (address and port dependant)

Similaire au cas précédent, il est aisé de savoir la différence fondamentale qui intervient ici : le port par lequel le serveur émet sa requête est aussi vérifié par le NAT. De ce fait, si le client contact le serveur Y1 sur un port y1, et que ce dernier essaie de lui répondre à partir d’un autre port (y2 par exemple), le NAT refusera le trafic. Dans le même ordre d’idée, le serveur Y2 ne pourra pas contacter X sauf si ce dernier a créé une permission au niveau du NAT pour lui.

Leur détermination

En pratique, la plupart des NAT ne respecte pas les recommandations décrites précédemment. Pire encore, certains équipements, selon la situation à laquelle ils se trouvent confrontés, vont modifier leur comportement dynamiquement. Les deux aspects du NAT dont il est fait question ici vont permettre de prendre en considération une grande majorité des cas de figure, des moins restrictifs aux plus « sécurisés ».

Dans un souci de clarifier les connaissances relatives à la nomenclature cone, le tableau ci-après la définit en fonction de ces deux aspects :

La détermination de ces types de NAT dans la pratique s’effectue grâce au dialogue entre un client et un serveur STUN. Pas d’inquiétudes toutefois : il n’est pas nécessaire de connaître le protocole STUN pour être en mesure d’appréhender ce qui suit : en se reposant sur les concepts énoncés précédemment, il est parfaitement possible de comprendre les procédures décrites ci-après.

Le protocole STUN se prète particulièrement bien à cet exercice, puisque lors du déploiement d’un serveur STUN, celui-ci est configuré de manière à « écouter » sur deux adresses et deux ports différents, c’est-à-dire qu’il peut recevoir des requêtes sur toutes les combinaisons de ces composants. Les différents tests possibles à partir de ces informations sont les suivants :

• TEST 1 : Le client émet une requête à destination de an:pn et le serveur répond à partir de ce couple. Ce test peut donc être effectué plusieurs fois, en utilisant chaque fois un couple différent (a1:p1 ; a2:p2 ; a1:p2 ; a2:p1).
• TEST 2 : Le client émet une requête à destination de an:pn et le serveur répond à partir de son couple a3-n:p3-n.
• TEST 3 : Le client émet une requête à destination de an:pn et le serveur répond à partir de son couple an:p3-n.

Puisque deux terminologies ont été décrites ci-dessus, il paraît logique qu’il existe au moins deux procédures différentes permettant de classifier les types de NAT. Il en existe en fait 3 qui nous intéressent vraiment dans le cadre des télécoms : la classification Classic STUN (RFC 3489), la classification BEHAVE (RFC 4787) et une classification particulière, spécifique à la voix sur IP. Chacune de ces procédures se repose sur les tests ci-dessus.

• Classic STUN (RFC 3489)

Cette méthode amalgame la notion d’association et de filtrage, ce qui se retrouve au sein de la procédure : chaque fois qu’un type de NAT est découvert à la suite d’un test, celui-ci définit les deux aspects en un passage. Les résultats sont par conséquents lacunaires, plusieurs combinaisons n’apparaissant pas (et ne pouvant pas apparaître sur la base de ces tests).

• BEHAVE (RFC 4787)

Cette procédure s’avère moins rapide, puisqu’elle requière un minimum de deux passages, mais offre de bien meilleurs résultats, couvrant l’intégralité des combinaisons association/filtrage. Les tests demeurent les mêmes, à la seule différence que seuls le premier test est utilisé dans le cadre de la détection de l’association.

• Spécifique à la VoIP

Ce dernier cas simplifie grandement les procédures ci-dessus. En effet, la VoIP ne nécessite pas une connaissance poussée du filtrage auquel le NAT procède. Sa principale considération concerne le type d’association. En effet, un client VoIP souhaite en être en mesure d’apprendre son adresse publique de manière à la transmettre à son destinataire. Le filtrage n’a qu’un rôle secondaire ici. De ce fait, un client souhaite savoir si son association est de type indépendante ou dépendante (quelle que soit la dépendance).

Une association indépendante signifie que le client pourra se reposer sur l’usage d’un simple serveur STUN pour apprendre son adresse publique alors qu’une association dépendante l’obligera à se servir d’un serveur relai.

Maintenant que le problème est posé, rendez-vous prochainement pour aborder les premières descriptions de solutions de traversée de NAT !

Le projet WebRTC vient d’annoncer la disponibilité dans Chrome d’une première implémentation de l’API WebRTC. Ce projet s’intègre dans la récente initiative RTCWeb visant à intégrer des fonctions de communication temps-réel dans les navigateurs Web. Nous profitons de cette occasion pour présenter les objectifs et l’architecture générale de RTCWeb.

Objectifs de RTCweb

Les fonctions offertes par le navigateur Web sont de plus en plus étendues et lui permettent de déborder de son rôle historique d’affichage de pages Web pour devenir un véritable environnement d’exécution d’applications riches. Cette tendance a ainsi été popularisée par des services tels que GMail et la suite Google Apps.

Les fonctions multimédias et de communications interactives ont jusqu’à récemment été rendues possibles uniquement par l’utilisation de plugins propriétaires tels que Flash Player (les objets de type ActiveX, Java ou autres n’ayant eu qu’un succès très limité dans ce cadre) qui a permis notamment le développement massif de la vidéo Web avec des services comme YouTube. Il devient maintenant possible de téléphoner à partir d’une page Web intégrant une applet Flash (voir par exemple http://call.nexcom.fr).

Le développement de la technologie HTML5 qui intègre une multitude de nouvelles fonctions permet maintenant de standardiser ces fonctionnalités. Ainsi les services de diffusions vidéo (Youtube par exemple) ou de partage de documents (tel Slideshare) sont engagés dans une logique de remplacement de fonctions auparavant développées en Flash par du HTML5. Ces fonctions restent pour l’instant relativement simples et sans interactions complexes mais l’évolution rapide des standards permet maintenant d’envisager le développement d’applications Web plus sophistiquées.

L’initiative RTCWeb (Real Time Collaboration on the Web) vise ainsi à standardiser l’infrastructure implémentée au sein des navigateurs Web permettant d’établir des communications audio et vidéo, directes, interactives et en temps-réel, entre des utilisateurs Web.

Cet effort se déroule au sein de deux groupes de travail:

• à l’IETF dans le cadre du RTCWeb Working Group pour la définition des formats et protocoles utilisés pour la communication entre navigateurs
• au W3C dans le cadre du Web Real-Time Communications Working Group pour la définition des APIs mises à disposition des applications Web

Ces deux groupes ont démarré depuis peu et de nombreux points restent ouverts et sujets à (vives) discussions, le sujet intéressant les plus grands acteurs de l’Internet (Google, Cisco, Mozilla, Apple, Skype …). Ainsi, nous décrivons par la suite les grands principes de RTCWeb sans rentrer dans les détails techniques susceptibles d’évoluer. Nous reviendrons plus tard sur ces derniers ainsi que l’API WebRTC avec de nouveaux articles quand ces points seront plus aboutis.

Architecture générale RTCWeb

RTCWeb ne vise pas à intégrer dans le navigateur des services de haut niveau de type softphone. L’idée est plutôt de spécifier les primitives nécessaires à la mise en oeuvre de tels service en conjonction avec des serveurs externes. En particulier, l’objectif est de permettre à ce qu’une application Javascript intégrée au sein d’une page Web et s’exécutant dans un navigateur standard puisse établir une communication utilisant des canaux audio, vidéos et de données et ce, sans contrainte sur le type de service fourni par l’application Web.

Un service de type softphone pourra ainsi être fourni par une application Javascript implémentant un widget téléphone et mettant en oeuvre un protocole de signalisation basé par exemple sur les WebSockets. Cette application utilisera les primitives RTCWeb pour capturer les flux audio et vidéo de la webcam, les encoder et les transmettre au correspondant.

Le schéma suivant illustre une utilisation typique de RTCWeb. Il est important de noter qu’il existe un lien media direct entre navigateurs et basé sur les protocoles définis au sein de RTCWeb. En revanche la signalisation emprunte un chemin qui peut être plus complexe et utilise des protocoles qui peuvent être propriétaires. Dans cet exemple, la signalisation utilise la connexion HTTP/Web Sockets entre le navigateur et le serveur Web et est spécifique à l’application Web délivrée par le serveur et s’exécutant au sein du navigateur. S’il y a un besoin d’interopabilité, la communication entre serveurs Web sera purement du ressort applicatif et pourra utiliser un protocole standard tel que SIP.

Il reste maintenant à définir les détails de ces différentes primitives et protocoles. Les discussions portent en particulier sur les points suivants:

• format des flux: quels sont les codecs offerts par le navigateur ? Doit-on spécifier une liste de codecs communs et toujours disponibles ?
• transport des données média: de nombreuses discussions portent sur le choix de RTP/SRTP, SRTP doit-il être imposé ou disponible en option ? Pour la gestion de la connectivité, ICE sera probablement utilisé.
• session de contrôle: doit-on réutiliser un protocole tel que SIP ou XMPP ou laisser cette partie sous le contrôle de l’application. Un consensus s’est dégagé sur cette dernière possibilité afin d’être le plus ouvert et flexible possible, il est ainsi probable que l’on verra apparaître des librairies Javascript implémentant SIP ou des protocoles simplifiés propriétaires. Dans tous les cas, quel modèle utiliser pour la négociation des formats média (SDP, autre …) ?

Le prochain article de cette série sera consacré à l’étude de l’API WebRTC, qui permet à l’application Javascript d’accéder à toutes ces primitives et de construire ainsi une application tirant parti de ces nouvelles fonctions HTML5.

LTE (Long Term Evolution) constitue l’évolution 4G des réseaux de télécommunications mobiles et offrira notamment des débits mobiles beaucoup plus élevés que les réseaux actuels. Le réseau EPS (il convient de parler plutôt de réseau EPS, Evolved Packet System, le terme LTE désignant plutôt l’interface radio entre le mobile et le réseau mobile 4G) présente la particularité par rapport aux précédents réseaux mobiles 2G/3G de ne fournir qu’un service PS (Packet Service) de données alors que les réseaux 2G/3G offrent à la fois des services de type CS (Circuit Service) pour la voix et de type PS pour les données

Le réseau EPS ne propose ainsi que l’accès aux réseaux de données PDN (Packet Data Network) et tous les services devront ainsi être ainsi être conçus au dessus d’IP y compris les services traditionnels tels que la voix ou les SMS. Cela constitue donc une évolution majeure et les opérateurs devront déployer de nouveaux systèmes afin de continuer de fournir un service de voix sur les réseaux mobiles 4G. Pour cela, plusieurs solutions ont été imaginées.

CSFB (Circuit Switched FallBack)

Cette première solution consiste tout simplement à continuer d’utiliser le réseau 2G/3G pour le service téléphonique et à réserver le réseau 4G pour le service de transmission de données. Avec ce principe, le terminal mobile est connecté soit au réseau actuel GSM/UMTS soit au réseau LTE selon l’application qu’il utilise. Un échange de signalisation entre d’une part le coeur de réseau NSS (Network Sub System) et d’autre part le coeur de réseau EPC (Evolved Packet Core) du réseau 4G est alors nécessaire afin que le mobile puisse basculer vers le réseau 2G/3G lorsqu’étant connecté au réseau LTE, il reçoit ou désire émettre un appel téléphonique. S’il souhaite conserver ses communications données en cours, il est également nécessaire de basculer le mode PS établi avec le réseau 4G vers le mode PS sur le réseau 2G/3G.

Cette solution offre l’avantage de se baser sur des technologies existantes et éprouvées mais présente cependant plusieurs inconvénients:

• le temps de bascule entre les réseaux 4G et 2G/3G est significatif (de l’ordre de quelques secondes en moyenne) ce qui, en terme d’expérience utilisateur, n’est guère satisfaisant et l’on voit mal les premiers utilisateurs de LTE, probablement assez technophiles et dotés de smartphones les plus récents, accepter une telle régression.
• les transferts de données sont également perturbés durant la bascule ce qui, à l’heure des téléphones multitâches avec de nombreuses applications s’exécutant en tâche de fond, devra s’effectuer le plus rapidement possible afin de limiter l’impact en terme d’usage
• ce modèle s’intègre mal avec des perpectives de développements de nouveaux services en isolant la voix sur des anciennes technologies sans possibilité d’évolution. Il serait ainsi impossible par exemple, de proposer des services combinant voix et données en tirant profit du débit 4G (conférence, collaboration, jeux …).

Il s’agit là des principaux écueils du CSFB qui souffre en outre d’autres insuffisances (mauvaise intégration avec de potentielles femtocells LTE, mauvaise occupation de la bande radio …).

En résumé, le CSFB offre l’avantage de permettre une réutilisation complète de l’infrastructure existante (réseau, services, systèmes de facturation ..) en ne nécessitant que quelques mises à jours mineures. Cependant il s’agit là d’une solution permettant plus de prolonger la vie du réseau 2G/3G existant que de tirer profit de l’introduction de la 4G, ce qui risque de réduire fortement l’intérêt de déployer cette nouvelle technologie.

Un mécanisme assez similaire consiste à se connecter à la fois aux réseaux 2G/3G et 4G, mais de façon simultanée afin d’éviter la phase de bascule radio. Cette approche, connue sous le nom de SVLTE (Simultaneous Voice and LTE), a également le mérite de ne pas nécessiter de modifications dans le réseau mais conduit à une plus grande complexité du téléphone ainsi qu’une consommation énergétique accrue. Des terminaux utilisant ce système sont déjà disponibles en CDMA/LTE (pas encore en GSM/UMTS/LTE).

L’un des problèmes les plus fréquemment rencontrés lors du déploiement d’un système VoIP est celui de la traversée de NAT. Bien que le principe du NAT en lui-même soit relativement simple, les conséquences sur les protocoles de VoIP sont assez complexes et il n’existe malheureusement pas de solutions simples et universelles pour y remédier. Dans cette série d’articles, nous décrirons les difficultés rencontrées lors d’un déploiement VoIP en présence de NAT ainsi que les différentes solutions, que ce soit dans les équipements disponibles du commerce ou dans les spécifications récentes et non encore mises en pratique. Dans ce premier article, nous allons examiner ce qu’est le NAT, les raisons de l’introduction de ce mécanisme et son principe général de fonctionnement.

Les origines du mécanisme de NAT (Network Address Translation) sont intimement liées avec la démocratisation des accès à Internet au cours des années 1990. Ce réseau global se repose en effet sur l’utilisation de IPv4 (Internet Protocol version 4) qui, lorsqu’il a été défini au début des années 80, n’avait jamais envisagé une telle expansion. Il faut en effet comprendre que tout équipement souhaitant communiquer au sein d’un réseau (et par conséquent, Internet aussi), doit impérativement disposer d’une adresse IP unique, tout comme une habitation afin de pouvoir recevoir du courrier par exemple. Alors que cette dernière se repose sur le nom de rue, ville, code postal …, IPv4 code ses adresses sur 32 bits, ce qui permet de disposer d’un peu plus de 4 milliards d’adresses différentes. Au début d’Internet, ce nombre paraissant plus que suffisant et l’on ne pensait pas manquer d’adresses disponibles.

Cependant avec l’explosion des demandes d’accès, que ce soit par des particuliers ou des entreprises (pouvant utiliser parfois quelques dizaines, centaines, voire plus, d’adresses) ainsi qu’une méthode d’attribution ayant conduit à des gaspillages importants, il est apparu, dès le début des années 90, qu’un épuisement était inévitable à moyen terme.

Afin de retarder autant que possible cet épuisement total, les acteurs de d’Internet ont dû rechercher des solutions. La solution logique, en préparation depuis de nombreuses années, est de transposer l’ensemble du réseau sur une révision du protocole : IPv6. Toutefois, la mise en place d’une telle évolution allait prendre un temps considérable (à tel point que cette transition est à peine initiée à l’heure actuelle !). Une solution temporaire, plus immédiate, a été trouvée au travers de l’établissement de plages d’adresses réservées, dites privées :

• Classe A : 10.0.0.0 /8, soit 24 bits adressables (16’777’215 adresses disponibles).
• Classe B : 172.16.0.0 /12, soit 20 bits adressables (1’048’575 adresses disponibles).
• Classe C : 192.168.0.0 /16, soit 16 bits adressables (65’535 adresses disponibles).

Elles sont nommées privées car elles ne sont pas utilisables en dehors des réseaux de terminaison, que ce soit chez les particuliers ou les entreprises. Cette définition implique que ces adresses ne sont en aucun cas routables globalement, c’est-à-dire qu’aucune communication n’est possible entre un équipement doté d’une adresse privée et un autre situé sur le réseau Internet public. L’usage de ces adresses permet de s’adapter à tous les cas de figures, allant de la multinationale (utilisant par exemple la classe A) aux SOHO (Small Offices, Home Offices, utilisant par exemple la classe C, mieux adaptée à leurs besoins).

Cette méthode permettait certes de réduire la consommation d’adresses IPv4 (une unique adresse étant utilisée pour un groupe de machine), mais il demeurait un problème majeur en l’état : il n’était pas possible pour un réseau privé de communiquer sur le réseau public, et inversement.

Il a donc fallu à nouveau trouver une solution à ce problème : le concept est excellent, mais cette limitation n’était pas acceptable en pratique. Les acteurs de l’Internet ont par conséquent imaginé un équipement frontalier qui serait en mesure d’appliquer une translation entre l’adresse privée et l’adresse public afin de permettre aux équipements internes de communiquer globalement. Ce concept est aujourd’hui caractérisé par les NAT (Network Address Translators, nom donné au équipements, à distinguer selon le contexte du nom de la technologie).

Par conséquent, ces entités vont permettre à un groupe d’équipements internes ou privés de partager la ou les adresses publiques associées avec le NAT. Ces mécanismes vont transformer les informations contenues dans les entêtes réseaux (couche Internet et Transport du modèle TCP/IP) afin de les faire correspondre aux informations du côté public du NAT, comme le montre l’exemple ci-dessous.

Grâce à ce nouvel équipement réseau, généralement implémenté comme une fonction d’un MoDem/routeur ADSL (Box, etc.), il est désormais, et depuis de nombreuses années maintenant, possible de communiquer à partir de pratiquement tout équipement disposant des capacités suffisantes.

Idéals sur le papier, du moins temporairement, ces NAT ne sont toutefois pas exempts de défauts. En effet, si leur principe reste globalement toujours le même (transformer un couple adresse/port privée en un équivalent public, et inversement), les différentes implémentations du mécanisme ont engendré un nombre de contraintes non négligeables, en particulier pour les protocoles et applications tentant de relier directement deux terminaux entre eux, ce qui est souvent le cas pour les protocoles de voix sur IP. Les NAT ne se préoccupent en effet que des informations réseaux de routage et transport (TCP/UDP/IP …), et ignorent totalement les données applicatives utilisées par ces protocoles afin d’établir leurs communications. Le problème est que ces données contiennent parfois des adresses IP privées qui ne sont alors pas exploitables par les correspondants situés en dehors du réseau privé. Cela conduit alors inévitablement à des problèmes dans l’établissement des appels (échec global, appel établi mais sans canal audio …, perte de messages de signalisation …).

Dans cette série d’articles relatifs à la traversée de NAT, nous aborderons cette problématique et présenterons les différents mécanismes permettant d’y apporter des solutions. Dans ce but, il est nécessaire de déterminer au préalable et de manière précise à quel type de NAT un utilisateur est confronté. Ces deux points (détermination et résolution) seront traités dans nos prochains articles.

Avec le déploiement de la 3G et l’arrivée de smartphones aux capacités étendues, la mutation des réseaux mobiles s’est accélérée. Le mobile est maintenant au centre de nombreux usages et bénéficiera bientôt du haut débit des réseaux LTE/4G. Il importe alors de cerner tous les enjeux de ces évolutions et d’appréhender dans leur ensemble les nombreuses technologies mises en œuvre.
Le FAFIEC a ainsi retenu NEXCOM Systems comme partenaire dans le cadre de son action collective Les Technologies des Réseaux Mobiles.

A travers cette action collective, NEXCOM Systems propose un cursus complet, allant des fondamentaux à l’expertise, sous la forme d’une série de 8 formations :

• Introduction à la communication cellulaire
• Télécommunications cellulaires : l’évolution des réseaux cellulaires
• Télécommunications cellulaires : GSM, GPRS et EDGE
• Télécommunications cellulaires : 3G ou UMTS
• Télécommunications cellulaires : évolution de l’UMTS/3G+
• Télécommunications cellulaires : la génération suivante – la LTE/4G
• La convergence des réseaux : architecture WIFI-WIMAX
• La convergence des réseaux : convergence des systèmes

Pour tout organisme affilié au FAFIEC, il est possible :

• de bénéficier d’une prise en charge à hauteur de 100% par le FAFIEC dans le cadre de cette action collective.
• de pouvoir organiser ces cursus au sein de vos locaux à un niveau national : cette offre n’est plus limitée à une région de France !

De plus, dans le cadre de sessions intra-entreprises, nous vous proposons d’adapter ces formations en prenant en compte les besoins spécifiques de vos équipes. N’hésitez pas à nous contacter pour obtenir plus d’informations à ce sujet !

Le pôle de compétitivité Images & Réseaux organise des formations sur des thématiques au coeur des enjeux de demain. Dans ce cadre, NEXCOM Systems a animé la formation « LTE et plateformes de services » le 16 Novembre 2011 à Brest. Le programme était le suivant:

Les réseaux fixes

• Réseau d’accès ADSL: Box, DSLAM, BAS
• Réseau d’accès FTTH: OLT, ONU/ONT
• Réseau d’agrégation Ethernet
• Coeur de réseau MPLS-VPN

Les réseaux mobiles

• 2G: GSM/GPRS
• 3G: UMTS, HSPA, Femtocell
• NGN R4
• 4G: LTE/SAE

La convergence des architectures de réseaux

• Le pourquoi de l’IMS
• Les enjeux
• Exemples de convergence chez les opérateurs

L’architecture IMS

• Les équipements et les fonctions: CSCFs, HSS, MRF, AS
• Les données utilisateurs: Identités, Profil
• Exemple de scénario d’appel (vue fonctionnelle): call-flow VoLTE (IMS+LTE/SAE)
• Interaction entre le réseau LTE/SAE et IMS: la fonction PCC et le contrôle du Bearer
• Les interconnexions avec les réseaux existants (IP, RTC)
• Acteurs et solutions constructeurs

L’architecture de services – illustration de services

• Les services téléphoniques dans l’IMS (TAS)
• La suite de services RCS (IM, presence …)
• Telco 2.0: la convergence Telco/Web 2.0 – exemples de services
• Les environnements  de développement d’applications
• Exemples & démonstrations de services convergents (notification d’appel sur TV, …)

Le livre Architecture des réseaux de mobiles, écrit par André Pérez, formateur chez NEXCOM Systems, vient d’être publié aux éditions Hermès – Lavoisier.

Résumé Cet ouvrage présente les évolutions de l’architecture des réseaux de mobiles (téléphonie et transmission de données) et propose une synthèse des différentes technologies 2G, 3G, HSDPA, HSUPA, HSPA+ et 4G. Les évolutions sont dictées par l’augmentation du débit de la transmission de données sur l’interface radioélectrique entre le réseau et les mobiles. Le service téléphonique a évolué vers une architecture qui permet une séparation des fonctions de transport du trafic téléphonique sur IP et de traitement de la signalisation. L’architecture NGN met en oeuvre ce principe, dans un premier temps, dans le coeur des réseaux de mobiles. L’architecture IMS généralise ce concept en introduisant la voix sur IP au niveau du mobile. Architecture des réseaux de mobiles s’adresse aux étudiants en réseaux et télécommunications (école d’ingénieurs) et aux opérateurs et industriels désirant avoir un panorama synthétique des réseaux de mobiles et acquérir ainsi rapidement les concepts technologiques.

En partenariat avec le pôle de compétitivité Images et Réseaux et la plateforme Imagin’Lab, nous animons une journée de formation sur les enjeux de l’IMS le 18 Novembre 2010 à Rennes.

Le programme complet est disponible sur ce lien.

Vous souhaitez comprendre ce qui se cache derrière la multitude d’acronymes qui fleurissent dans le monde des télécommunications (IMS, IPv6, RCS, FTTH, IPBX, IPTV …) et appréhender le fonctionnement général des nouveaux équipements présents dans nos poches et à notre domicile (smartphone, téléphone IP, box ADSL …) ?

Nous vous proposons une nouvelle formation qui vous permettra d’acquérir le vocabulaire essentiel de ces évolutions et d’identifier les différents types de réseaux télécom, ainsi que leurs rôles et places dans les offres des opérateurs.

Le 3 février 2011, l’IANA a annoncé avoir distribué les tous derniers blocs d’adresses IPv4. Le 8 juin 2011 a eu lieu la première journée mondiale IPv6. Cette journée sponsorisée par l’Internet Society a pour but d’inciter les acteurs de l’industrie numérique à soutenir IPv6 et à préparer leurs infrastructures pour la transition vers ce nouveau protocole.

Annoncé depuis longtemps et sans cesse retardé, le déploiement d’IPv6 est maintenant inéluctable et il est essentiel de s’y préparer sereinement et efficacement.

Nous vous proposons une nouvelle formation IPv6 : théorie et pratique en INTER-entreprise dans nos locaux parisiens. Elle peut être aussi organisée dans vos locaux en mode INTRA.