Qualifier un lien mobile backhaul avec la IEEE.1588v2 et G.8261

Problématique

Comme le Mobile Backhaul augmente la bande passante entre les équipements radio et le cœur de réseau, pour répondre à la demande, les anciens liens TDM sont remplacés par des liens Ethernet plus efficaces. Cependant, avec des réseaux PSN (à commutation de paquets) qui sont par nature asynchrones, la question qui se pose, est de savoir ce qui pourrait remplacer le vide engendré par la fréquence de précision et la synchronisation de phase requises par les stations de base mobiles et les autres applications temps-réel.

Plusieurs technologies telles que le protocole PTP IEEE 1588v2, l’Ethernet ITU-T G.8261 Synchrone et les horloges synchronisées sur GPS sont actuellement disponibles pour combler ce vide. Comme chaque technologie a ses forces et faiblesses et que des solutions incluraient une combinaison de ces technologies, la Synchronisation Mobile Backhaul est actuellement un sujet brûlant qui est examiné et débattu au sein des organismes de normalisation et des laboratoires prestataires de services du monde entier.

Cette note d’application fournit un guide concis sur ces nouvelles techniques de synchronisation avec l’accent mis sur le Protocole PTP IEEE 1588v2.

La théorie

Synchronization vs. Syntonisation

Deux horloges sont alignées en fréquence, ce que l’on appelle aussi syntonisation si la durée d’une seconde est la même sur les deux horloges, ce qui signifie que le temps mesuré par chaque horloge avance à la même vitesse. Deux horloges sont alignées en Heure du Jour/Phase et en Fréquence, ce que l’on appelle aussi synchronisation, si leur mesure de l’heure d’un événement est la même. La différence entre la synchronisation et la syntonisation (ou synchronisation de fréquence) est un concept important pour les technologies mobile backhaul, car comme décrit dans la prochaine section, certaines applications mobiles ne peuvent fonctionner qu’avec la syntonisation alors que d’autres requièrent une synchronisation totale.

Qu’est ce que le Mobile Backhaul et Pourquoi Nécessite t-il d’être Synchronisé ?

Le Mobile BackHaul (MBH) est le segment de transport qui relie les sites cellulaires aux centres de contrôle et de commutation mobiles. Les technologies MobileBackHaul ont évolué pour satisfaire l’explosion de la demande en services data ainsi que pour rationaliser le transport de la voix, de la data et pour contrôler le trafic dans un réseau tout IP.

Dans les réseaux 2G, les liaisons spécialisées TDM avec une connectivité T1/E1 étaient utilisées pour transporter de la voix/data. L’introduction de la 3G a vu la transition vers le transport ATM, tandis que les réseaux 4G/LTE rendent obligatoire un Réseau tout IP, d’où la perte de la référence d’horloge de la couche physique et l’introduction de réseaux par paquets asynchrones.

Protocole de synchronisation d’horloge Y.1588v2 – Réseaux mobile 3G LTE TDM ATM IP Ethernet

La synchronisation des stations de base en fréquence et en phase/heure est une exigence importante pour les technologies mobiles. Cela permet une transmission des appels en douceur entre les cellules voisines (pour éviter les appels dropés) et est vitale pour l’encodage RF. Les normes ont des exigences strictes en termes de synchronisation d’heure et de phase, par exemple la norme GSM prévoit une synchronisation de fréquence (syntonisation) de ± 50 ppb (parties par milliard) à la fois dans l’optique de la génération de fréquence et de la mise à l’heure de la base temps. La technologie LTE-TDD(TimeDivision duplex) prévoit une synchronisation de phase des cellules voisines de ±3µs ainsi qu’une syntonisation de fréquence. Le tableau ci-dessous résume les exigences normatives en termes de fréquence et de phase pour les différentes technologies mobiles.

Tableau 1 : Exigences de précision en Fréquence et en Phase

Dans les réseaux 2G/3G, les stations de base ont satisfait à ces exigences en terme de précision de fréquence en récupérant leurs horloges à partir des connexions backhaul T1/E1 TDM. Mais avec la migration vers l’Ethernet backhaul, nous avons perdu cette possibilité. Comme alternative, les récepteurs GPS satellites peuvent être utilisés sur chaque site cellulaire pour récupérer la fréquence ainsi que la phase avec une grande précision, mais comme les récepteurs GPS nécessitent un placement extérieur et ont des coûts inhérents et des problèmes de sécurité, d’autres technologies telles que l’IEEE 1588v2 Precision Timing Protocol (PTP) et l’ITU-T G.8261 SyncE ont émergé comme des alternatives viables pour la synchronisation mobile backhaul. Le tableau ci-dessous présente un résumé des avantages et des inconvénients de chaque technologie.

Le choix des opérateurs pour l’une ou l’autre technologie dépendra de nombreux facteurs incluant la nécessité d’une syntonisation de fréquence ainsi que d’une synchronisation de phase. De plus, un mélange de technologies peuvent être déployées pour atteindre une synchronisation de bout-en-bout; par exemple avoir une PRC (Horloge Primaire de Référence) basée sur un GPS distribuant le chronométage via la 1588v2 aux tours cellulaires ; ou utiliser la SyncE pour la distribution de la fréquence et la 1588v2 pour la distribution de la ToD (Heure du Jour).

Après cet aperçu des différentes technologies de synchronisation disponibles, il est temps d’aborder le protocole 1588v2 PTP plus en détails.

 

Qu’est-ce que le Protocole IEEE 1588v2 PTP ?

Le protocole PTP s’appuie sur une méthode de distribution dans laquelle l’information de chronométrage est incluse dans les paquets échangés entre les horloges maîtresses et esclave(s) en utilisant les réseaux Ethernet existants. L’intérêt du protocole PTP est que les messages PTP sont transportés sur le même réseau comme le trafic voix et data habituel et ne requiert pas l’upgrade des éléments du réseau (NE) avec un hardware dédié pour supporter le protocole PTP. La grande horloge maître est la source ultime pour la synchronisation d’horloge avec les horloges esclaves en flux descendant qui récupèrent l’heure locale à partir des messages reçus.

Afin de récupérer l’horloge, le dispositif esclave doit être en mesure de compenser le retard de propagation et le décalage d’horloge entre le maître et l’esclave. Cela est réalisé en utilisant des horodatages contenus dans les messages Sync et de Follow up (en option) et un échange de message Delay Request/Delay Response.

1. Le maître commence l’échange en envoyant un message Sync à l’esclave. Le message contient l’heure t1 de l’envoi du message. L’esclave note l’heure t2 de la réception du message. Suivant les capacités hardware du maître, il se peut que l’heure d’envoi ne soit pas assez précise dans message Sync d’origine, donc il peut être suivi en option par un message de Follow-up contenant l’heure précise t1 de l’envoi du message Sync. Une horloge supportant les messagesSync et de Follow up est désignée comme une horloge à deux étapes (two-step clock), alors qu’une horloge supportant seulement les messages Sync est désignée comme une horloge à une étape (one-step clock).
   L’esclave envoie un message de Demande de Délai au maître et note l’heure d’envoi t3. A la réception de la Demande de Délai, le maître note l’heure T4 et intègre ces informations dans le message de Réponse de Délai.
2. L’esclave est maintenant armé de 4 horodatages. Le délai du réseau entre le maître et l’esclave est estimé en moyennant l’heure entre maître et esclave (t2-t1) et l’heure entre l’esclave et le maître (t4-t3). Il est important de noter que ce calcul suppose que les délais du réseau sont symétriques.
3. Le décalage temporel entre l’esclave et le maître est alors déterminé par la soustraction du délai à partir de la différence entre t1 et t2.
4. Avec les informations de Délai et de Décalage, l’esclave est capable d’aligner son horloge sur celle du maître.
5. Les éléments Sync, Follow up (en option), Delay_Req (Demande de Délai) and Delay_Resp (Réponse de Délai) sont échangés à plusieurs reprises tout au long de la durée de session 1588v2 pour compenser la dérive d’horloge.

Si la synchronisation de fréquence (sans synchronisation de phase) est nécessaire, alors seulement 2 horodatages peuvent être utilisés et la valeur de la variation dans l’horloge esclave est alignée sur le maître en comparant les horodatages des messages Sync. Si l’on désire la pleine fréquence et la pleine synchronisation de phase, alors 4 horodatages doivent être utilisés.

Les Dysfonctionnements PTP et Réseau

Comme vous pouvez le comprendre en suivant ce mécanisme de récupération d’horloge, l’asymétrie du réseau (différence de délai entre le chemin d’envoi et le chemin de réception) et la PDV (Packet Delay Variation) sont des éléments critiques pour la précision de l’horloge récupérée.

L’algorithme PTP utilise comme hypothèse principale que le délai entre le maître et l’esclave est équivalent à la moitié du délai aller-retour (round trip delay), mais si l’asymétrie du réseau est introduite dans la couche physique lorsque les messages PTP ne voyagent pas via les chemins d’envoi et de réception, la précision de la récupération d’horloge sera impactée. Le réseau doit être conçu pour minimiser de telles différences, ou si la valeur d’asymétrie est connue, l’algorithme PTP peut corriger cela.

Une chaîne d’éléments du réseau (NE) entre le maître et l’esclave avec une charge variable sur le réseau et différents délais d’attente et de traitement peut provoquer des variations de délai dans les messages PTP. Parce que l’algorithme PTP suppose un délai constant sur le réseau, les changements dans l’heure d’arrivée des paquets sont problématiques pour l’esclave. Il ne sait pas faire la différence entre la variation dans le délai des paquets et une dérive temporelle du maître. Le plus souvent, des algorithmes spécifiques sont implémentés dans l’esclave pour filtrer autant que possible la PDV. Dans une moindre mesure, les pertes de paquets, les erreurs de paquets, ou les paquets dupliqués sont aussi des dysfonctionnements courants du trafic qui peuvent affecter le PTP.

Combien de dysfonctionnements du réseau sont tolérables et comment affectent-ils la stabilité de l’horloge ? Ce sont des sujets actuellement à l’étude à l’ITU, et qui renforcent la nécessité de tester le PTP dans des conditions réalistes avant le vrai déploiement.

Le Profil Télécom

Le profil Télécom défini dans la norme ITU-T G.8265.1 rassemble les meilleures pratiques et paramètres dans l’architecture PTP afin de sécuriser la synchronisation de fréquence dans un environnement « carrier-grade ». L’ITU travaille actuellement sur la norme ITU-T G.8275.1 pour définir un profil PTP pour la distribution de l’Heure/Phase même si elle n’est pas encore ratifiée au moment de la diffusion de ce papier.

Le profil Télécom a été défini pour les réseaux télécoms dans lesquels aucun support de synchronisation n’est disponible à partir du réseau en dehors des messages échangés entre le maître et l’esclave et est applicable à la synchronisation mobile backhaul, les points-clé sur le profil Télécom sont décrits ci-dessous:

• Transport PTP: les messages PTP sont définis comment étant transportés sur l’IPv4 et le port UDP, souvent le VLAN sera utilisé à des fins de priorisation et de séparation du trafic.
• Unicast vs. Multicast: bien que les mécanismes PTP à la fois unicast et multicast soient supportés, le profil Télécom utilise la transmission unicast. L’esclave a besoin d’être provisionné avec l’adresse unicast du maître et de demande de service.
• Domaines: un numéro de domaine est défini par la norme G.8265.1 dans une plage allant de 4 à 23, le numéro de domaine inclus dans les messages maître/esclave est utilisé pour isoler les différentes paires de communication PTP maître-esclave partageant le réseau.
• Un-sens vs. Deux-sens: l’échange de message PTP dans les deux sens de l’esclave vers le maître et du maître vers l’esclave est défini dans la norme 1588v2, cependant le profil Télécom permet une communication dans un sens où seulement les messages Sync (et de Follow up en option) du maître vers l’esclave sont inclus, dans la mesure où la livraison de fréquence ne nécessite pas l’utilisation du mécanisme Demande de Délai/Réponse de Délai.
• Une-étape vs. Deux-étapes: Une horloge maître à deux étapes utilise un message Sync avec horodatage provisoire, suivi d’un message de Follow-up avec un horodatage précis, alors qu’une horloge maître à une seule étape utilise seulement un message Sync avec un horodatage précis. Dans la mesure où le fonctionnement en une ou deux étapes est principalement une fonction liée aux capacités hardware de l’horloge maître, les deux sont autorisés dans le profil télécom, et l’horloge esclave doit être capable d’accepter les deux.
• Valeurs Sync/Follow-up: Le profil définit un débit minimum d’ 1 Sync/Follow-up par 16 secondes jusqu’à un débit maximum de 128 par seconde.
• Valeurs Delay_Req/Delay_Resp: Le profil définit un débit minimum d’1 Delay_Req/Delay_Resp par 16 secondes à un débit maximum de 128 par seconde.
• Valeur Annonce: Le profil définit une valeur minimum d’1 message d’annonce par 16 secondes à une valeur maximum de 8 par seconde avec un minimum d’un message par 2 secondes. Le message d’annonce est envoyé par le maître pour indiquer son niveau de qualité à l’esclave.
• Valeur message de Signalisation: Non définie, sera basée sur la l’expiration de la demande de service. Les messages de signalisation sont utilisés pour demander des services à partir du maître.

La plage de valeurs des messages de Sync et de Demande de Délai (Delay_req) autorisé dans le profil télécom est très étendue, c’est à l’esclave de demander la valeur la plus efficace basée sur la qualité de l’oscillateur local, sur les objectifs de performance d’horloge ainsi que sur l’importance des dysfonctionnements réseau (PDV, congestion,delay) rencontrés.

Aides à la Synchronisation 1588v2: Boundary et Transparent Clocks

Même si la 1588v2 est actuellement déployée dans le monde entier pour la distribution de la fréquence, il est couramment admis que la technologie n’est pas adaptée pour la distribution de phase/ToD en présence de dysfonctionnements réseau tels que la PDV ou l’asymétrie. C’est le sujet du travail en cours sur la norme ITU-T G.8275.1. Alors qu’aucune décision n’a été prise à l’écriture de ce papier, la distribution de Phase et de ToD nécessitera probablement l’utilisation d’éléments intermédiaires spécialisés comme les Transparent clocks ou les Boundary clocks.

Boundary Clock

La Boundary Clock (BC) est un dispositif multiport. D’un côté, elle agit comme un esclave ordinaire et elle récupère l’horloge à partir du maître, d’un autre côté elle sert de maître aux horloges esclave ordinaires. Elle agit comme un régénérateur PTP au milieu du réseau et est conçue pour éliminer la gigue des paquets PTP en flux montant afin de fournir une horloge stable aux esclaves en flux descendant.

Transparent Clock

La Transparent Clock (TC) est un switch multipoint qui n’est ni une horloge maître, ni une horloge esclave, mais un élément qui transmet les paquets PTP tout en modifiant les horodatages dans les messages Sync et Delay pour tenir compte des retards encourus entre la réception et la transmission des messages au sein du switch (heure résidentiel). L’horloge esclave utilise le champ de correction ajouté par la transparent clock dans son algorithme pour compenser la variation de retard qui a été ajoutée au sein du switch.

L’ajout d’une BC ou d’une TC dans un réseau aidera sans aucun doute dans la précision de la récupération d’horloge mais l’accumulation de ces dispositifs dans la chaîne, ou l’introduction d’éléments spécialisés non PTP au sein du réseau restera un problème. Quels que soient les choix d’implémentation, tester le réseau avant et pendant le fonctionnement du PTP est un pré-requis. La section qui suit décrira l’objectif de performance d’horloge et les méthodes de mesure

Méthodologies de Test et Normes PTP

La caractérisation des paramètres réseau par paquets et des limites correspondantes est toujours un sujet de recherche en cours pour l’ITU et le MEF. Vous trouverez ci-dessous une liste de normes d’intérêt dans ce domaine:

• La norme ITU-T G.8260 fournit des définitions et la terminologie pour la synchronisation des réseaux par paquets
• L’ITU-T G.8261, les aspects de minutage et de synchronisation dans les réseaux par paquets
• L’ITU-T G.8261.1, les limites réseau de la variation de retard de paquets applicable aux méthodes basées sur les paquets (Synchronisation de fréquence)
• L’ITU-T G.8265, l’architecture et les prérequis pour la livraison de la fréquence basée sur les paquets
• L’ITU-T G.8265.1, le profil télécom PTP pour la synchronisation de fréquence
• L’ITU-T G.8271.1, les aspects de synchronisation d’heure et de phase des réseaux par paquets
• La MEF 22.1, les prérequis de l’Agrément d’Implémentation du Mobile Backhaul Phase 2 pour l’implémentation du Carrier Ethernet pour le Mobile Backhaul

Comme décrit dans les sections précédentes, la précision de la synchronisation d’horloge PTP 1588v2 est affectée par les dysfonctionnements réseau de PDV et d’asymétrie du réseau. La PDV et l’asymétrie sont créées par de nombreux facteurs incluant : le nombre de NE sur les chemins du maître vers l’esclave et de l’esclave vers le maître, le traffic pattern et la charge sur le réseau, ainsi que les mécanismes de priorisation du trafic et de traffic shaping appliqués dans le réseau. Il est donc très difficile de réaliser un modèle et de connaître à l’avance la sévérité et la répartition des dysfonctionnements du réseau. Le test sur le terrain de ces paramètres est un élément essentiel nécessaire pour l’établissement de la confiance dans le déploiement.

Le PTP peut se diviser en deux phases :

• Test fonctionnel pour établir l’interopérabilité protocolaire et de provisionnement des éléments PTP
• Test de la performance du réseau pour établir la précision de l’horloge récupérée.

Test du Protocole

La norme du profil Télécom ITU-T G.8265.1 rétrécit le champ des valeurs et des paramètres acceptables pour l’interopérabilité PTP maître et esclaves, mais la validation de l’interfonctionnement dans le réseau opérationnel est souhaitée.

Les paramètres suivants doivent être provisionnés et/ou correctement négociés:

• Livraison de messages unicast ou multicast
• Négociation des valeurs de Messages Sync et Delay_Request et accès aux services
• Sélection de la meilleure horloge maître
• Vérification de l’ID de l’horloge
• Attribution de numéro de domaine
• Provisionnement du VLAN CoS

Test de la Performance de la Fréquence

La performance de la fréquence de l’horloge esclave est testée par rapport aux limites de gigue et de wander spécifiées dans la norme ITU-T G.823 pour l’E1/E3 et dans la norme G.824 pour le DS1/DS3. Les masques définissent les valeurs tolérables de gigue et de wander; le masque de l’Horloge de l’Equipement (EC) est habituellement utilisé pour définir les performances pass/fail de l’horloge esclave 1588v2 récupérée.

L’évaluation du wander est réalisée en mesurant l’erreur d’intervalle de temps (TIE) et en calculant la MTIE et le TDEV. La MTIE (en nanosecondes) correspond à l’Erreur d’Intervalle de Temps Maximum. Elle mesure la variation maximum de retard de l’horloge récupérée par l’esclave comparée à l’horloge de référence. Le TDEV correspond à l’Ecart de Temps(en nanosecondes) de l’horloge esclave en fonction du temps d’intégration. Il fournit les informations à propos du contenu spectral du bruit de phase du signal.

Test de la Performance de Phase

La performance de la précision de synchronisation de phase de l’esclave est mesurée en analysant le signal 1 pps (pulse par seconde) à partir de l’horloge récupérée et en mesurant son écart par rapport au signal de référence. Les limites de précision sont définies par la technologie mobile testée (Cf. tableau 1). Par exemple la technologie LTE-TDD requiert une précision de ± 3 µs.

Test de Conformité des Appels de Service MEF 22.1

La norme MEF 22.1 définit une nouvelle classe de service de “Très Haute Priorité” pour la synchronisation du trafic MBH. La conformité aux paramètres MEF doit être testée sur le réseau; vous trouverez ci-dessous un résumé des objectifs de performance. Veuillez noter que la conformité des autres classes de services est également importante à établir, étant donnés que la synchronisation MBH et le trafic de données partagent le même chemin. Les outils suivant la norme ITU-T Y.1564 peuvent être utilisés pour cette objectif.

Produits recommandés