Une passerelle Radio over IP peut être en ligne, accessible et transmettre de l'audio, tandis que le chemin de communication global fonctionne toujours mal. Sur le terrain, les problèmes les plus difficiles ne sont généralement pas de savoir si la passerelle peut se connecter, mais où le retard est introduit, pourquoi la réponse PTT change entre les sites, ou pourquoi l'audio devient instable uniquement lorsque le WAN est occupé.

Ces défauts sont plus faciles à résoudre lorsque le système RoIP est traité comme une série de sections mesurables plutôt que comme une boîte noire de bout en bout. La mise sous tension de la radio, le traitement de la passerelle, le transport des paquets, la gestion du VPN, le tampon de gigue et le chemin RF distant peuvent chacun contribuer à leur propre retard ou point de défaillance.

Pour le déploiement, la question utile n'est donc pas simplement de savoir si la passerelle est configurée correctement. Mais si chaque section de la chaîne de communication a été mesurée, vérifiée et documentée.

1. Cartographiez le chemin RoIP avant de modifier les paramètres

Avant de modifier les paramètres de codec, les retards PTT ou les politiques de QoS, dessinez le chemin de communication réel utilisé par le projet. Incluez l'équipement radio et les périphériques réseau entre les deux extrémités.

Un chemin multi-sites typique peut être :

Radio → Passerelle RoIP → Commutateur LAN → Routeur → VPN/WAN → Routeur → Plateforme de répartition ou passerelle distante → Radio

La topologie exacte peut être plus compliquée. Un site distant peut utiliser la fibre comme connexion principale et la 4G/5G comme secours. Un centre de contrôle peut placer la plateforme RoIP derrière un pare-feu. Certains projets séparent également le trafic radio dans un VLAN dédié ou le routent via un VPN d'entreprise.

Ce qui importe lors de la mise en service, c'est de savoir où une section se termine et où la suivante commence.

Les points de test utiles incluent généralement :

• l'audio reçu par la radio entrant dans la passerelle ;

• l'audio émis par la passerelle entrant dans la radio ;

• la sortie PTT de la passerelle ;

• l'activation de l'émission radio ;

• les médias IP quittant la passerelle locale ;

• les médias IP arrivant au point final distant ;

• la sortie audio de la passerelle distante ;

• et l'émission RF finale entendue par la radio réceptrice.

Cette carte devient la base de chaque test ultérieur. Si un opérateur signale un audio retardé ou haché, l'ingénieur peut vérifier chaque section séparément au lieu de modifier plusieurs paramètres sans rapport en même temps.

Solution RoIP associée : Système de passerelle Radio Over IP

2. Établissez un budget de latence pour le chemin radio complet

Un simple résultat de ping ne décrit pas le temps de réponse RoIP. Ping montre principalement l'accessibilité du réseau et le délai d'aller-retour IP. L'opérateur radio expérimente une chaîne plus longue qui commence lorsque le PTT est demandé et se termine lorsque la parole utile atteint la radio distante.

Pour le dépannage, divisez le délai total en composants séparés :

Réponse RoIP totale = Traitement PTT + Traitement de la passerelle locale + Paquetisation + Transport IP + Tampon de gigue + Traitement distant + Mise sous tension de la radio + Délai du système RF

La contribution exacte de chaque composant dépend de l'équipement et du réseau. Le but d'un budget de latence n'est pas de forcer chaque projet à un nombre fixe. Mais d'identifier où le retard est réellement ajouté.

Séparez le délai réseau du délai radio

Supposons que le chemin WAN soit stable mais que les utilisateurs signalent toujours que la réponse PTT est lente. Réduire la latence du réseau peut ne pas résoudre le problème si la majeure partie du retard provient du temps de mise sous tension de la radio ou d'un tampon de gigue important.

L'inverse peut également se produire. La mise sous tension de la radio peut être rapide sur les deux sites, mais un chemin WAN ou VPN fortement chargé introduit un retard variable entre les passerelles.

Ces deux défauts nécessitent des actions correctives différentes, c'est pourquoi le délai total doit être divisé en sections mesurables.

Mesurez le même chemin dans différentes conditions

Enregistrez la latence lorsque le réseau est inactif, puis répétez le même test pendant le trafic commercial normal. Si possible, testez à nouveau pendant que le WAN est intentionnellement soumis à une charge contrôlée.

Une comparaison utile est :

• latence du réseau inactif ;

• latence de production normale ;

• latence en période de pointe ;

• et latence du lien de secours, si un WAN secondaire est utilisé.

Un lien acceptable au repos mais devenant incohérent pendant le trafic de production indique généralement un problème de capacité réseau, de file d'attente ou de qualité de chemin plutôt qu'un problème d'interface radio.

3. Mesurez le timing PTT-à-audio au lieu de deviner

Le timing PTT est souvent ajusté par essais et erreurs. Une méthode plus fiable consiste à mesurer plusieurs événements en séquence et à identifier exactement où commence l'audio utile.

Par exemple :

• T0 : la commande PTT distante est émise ;

• T1 : la sortie PTT de la passerelle change d'état ;

• T2 : la radio connectée passe en mode émission ;

• T3 : la porteuse RF est disponible ;

• T4 : la parole utile commence sur le canal RF.

La différence entre ces points fournit des informations bien plus utiles que de simplement décrire le système comme ayant une "latence PTT élevée".

Si le délai entre T0 et T1 est excessif, examinez la signalisation de contrôle ou le traitement de la passerelle. Si T1 se produit rapidement mais que T2 ou T3 est lent, l'équipement radio ou l'interface radio doit être vérifié. Si la porteuse RF est déjà établie mais que la parole arrive tard, examinez le chemin audio et le tamponnage des médias.

Utilisez la radio réelle lors du réglage du temps d'avance

Le temps d'avance PTT doit être adapté à la radio ou au répéteur connecté. Différents équipements peuvent nécessiter des intervalles différents entre l'activation du PTT et l'audio utile.

Une valeur copiée d'un autre projet peut sembler fonctionner mais produire une parole écourtée ou un retard inutile.

Le même principe s'applique au temps de relâchement. Si le PTT est relâché avant que l'audio final ne quitte la radio, la dernière syllabe peut être coupée. S'il est maintenu trop longtemps, le canal reste occupé après la fin de la parole.

L'objectif n'est pas le délai le plus court possible. L'objectif est le timing le plus court qui produit encore des transmissions complètes et reproductibles avec l'équipement radio réel.

4. Vérifiez la QoS en cas de congestion, pas à partir des écrans de configuration

La QoS doit être prouvée par le comportement du trafic plutôt que supposée à partir d'une page de configuration.

Une passerelle peut marquer correctement le trafic en temps réel tandis qu'un commutateur intermédiaire, un pare-feu, un périphérique VPN ou un service WAN modifie ou ignore ce marquage. La configuration peut donc sembler correcte aux deux extrémités tandis que le trafic RoIP est toujours en compétition avec les données en vrac en cas de congestion.

Un test pratique consiste à observer le chemin RoIP sous charge contrôlée.

Le test peut être effectué par étapes :

1. Établissez un appel radio normal et enregistrez la latence, la gigue et la perte de paquets.

2. Introduisez du trafic de fond sur le même chemin WAN.

3. Répétez les tests PTT et audio.

4. Vérifiez si les marquages de paquets restent inchangés le long de la route.

5. Inspectez les files d'attente du routeur ou du pare-feu où la congestion se produit.

6. Comparez le résultat avec la référence du réseau inactif.

Si le chemin RoIP reste stable tandis que le trafic de fond augmente, la politique réseau fait son travail. Si la parole commence à se dégrader ou si la latence varie fortement, examinez la bande passante disponible et le comportement des files d'attente avant de modifier les paramètres audio de la passerelle ou de la radio.

La QoS ne peut pas remplacer une bande passante suffisante

Le traitement prioritaire aide le trafic en temps réel en cas de contention, mais il ne crée pas de capacité qui n'existe pas. Un lien WAN en saturation permanente a toujours besoin d'une solution de bande passante ou d'ingénierie de trafic.

Ceci est particulièrement important dans les réseaux où RoIP partage la même connexion avec la vidéosurveillance, la synchronisation de fichiers, les applications bureautiques ou d'autres services à fort volume.

Vérifiez les liaisons de secours séparément

Si un projet utilise la 4G/5G ou une autre connexion secondaire, ne supposez pas que le comportement QoS du WAN principal s'applique également au chemin de secours.

La route de secours peut avoir des caractéristiques de latence, de gigue, de perte de paquets ou des politiques de trafic différentes. Elle doit donc être mesurée comme un chemin de communication distinct.

5. Localisez le défaut par segment

Modifier plusieurs paramètres de passerelle à la fois rend le dépannage plus difficile car le défaut d'origine disparaît dans les modifications de configuration. Une meilleure méthode consiste à isoler le chemin et à déterminer quelle section présente d'abord le problème.

Utilisez les sections connues comme bonnes pour restreindre la recherche

Si l'audio local radio-vers-passerelle a déjà été vérifié, n'ajustez pas cette interface de manière répétée tout en enquêtant sur un problème WAN. Conservez chaque section vérifiée inchangée et passez au point de test suivant.

La même méthode fonctionne dans le sens opposé. Si RTP ou d'autres médias IP atteignent la passerelle distante sans perte de paquets mais que la sortie RF est mauvaise, l'ajustement réseau est peu susceptible de corriger le problème.

Les tests basés sur les segments sont particulièrement utiles dans les systèmes multi-sites car le même modèle de passerelle peut fonctionner correctement sur plusieurs sites tandis qu'un site se comporte différemment. Comparer les points de mesure entre un site bon et un site mauvais peut rapidement identifier si la différence se situe dans l'interface radio, le chemin WAN ou le réseau local.

6. Enregistrez une référence de déploiement avant la remise

Un système RoIP est plus facile à maintenir lorsque les valeurs de travail finales sont enregistrées avant la remise. Sans référence, un remplacement ultérieur de routeur, un changement de radio ou une mise à niveau logicielle peuvent laisser les techniciens incertains de savoir si les paramètres actuels sont originaux ou ont déjà été modifiés.

L'enregistrement de déploiement doit contenir les valeurs utiles pour la comparaison, pas chaque page de la configuration de l'équipement.

Les mesures doivent être enregistrées à partir du chemin de production réel plutôt que copiées d'une configuration de laboratoire. Dans la mesure du possible, conservez à la fois les valeurs de fonctionnement normales et les résultats enregistrés lors des tests de réseau chargé ou de basculement.

Cette référence devient utile chaque fois qu'un composant change. Si un nouveau routeur augmente la latence, une radio de remplacement nécessite un temps d'avance PTT différent, ou un nouveau service WAN introduit une gigue plus élevée, l'équipe de maintenance dispose d'un état de fonctionnement antérieur pour comparaison.

Par conséquent, le déploiement d'une passerelle Radio over IP n'est pas terminé lorsque les appareils affichent un état en ligne. Il est terminé lorsque le chemin de communication a été mesuré section par section, que le timing PTT a été vérifié avec l'équipement radio réel, que le comportement du réseau a été testé sous charge et que les valeurs de travail finales ont été enregistrées pour un dépannage futur.