 | |
| |
| Page 1: Technologie compatible iDirect: Introduction | |
| Page 2: TCP par satellite et fiabilité | |
| Page 3: Affaissement pluie et questions sur la performance | |
| Page 4: Services |
TCP/IP sur Satellite
Une difficulté importante rencontrée dans le soutien des applications TCP/IP sur satellite est la latence inhérente ou le retard des systèmes satellitaires. Parce que les satellites sont situés à 37.000 km au-dessus de la terre, le temps qu’il faut pour un signal de partir du sol vers le satellite et de retourner vers le sol est d’un peu plus de 1/4 de seconde. Le protocole TCP/IP a été conçu pour le transport garanti. Un serveur ou un PC envoyant des données débutera en envoyant quelques paquets et attendra ensuite un accusé de réception montrant que les données ont été reçues avant d’en envoyer plus. Si les données sont correctement reçues et reconnues, le dispositif d’envoi enverra plus de paquets à un rythme plus rapide. Il continuera à accélérer jusqu’à ce que les accusés de réception soient perdus. Cela dit au dispositif d’envoi quelle capacité de vitesse ou de bande passante les services de transport ont, et il enverra des données restantes à ce taux. Malheureusement, la latence satellite apparaît au dispositif TCP/IP expéditeur comme un circuit très lent ou encombré. Il s’attend à un accusé de réception dans un délai court et quand il ne l’obtient pas, il le renvoie. Les Fournisseurs de satellite ont contourné ce problème en utilisant des techniques d’accélération TCP parfois appelées ‘spoofing’. Ceci est basé sur les mêmes techniques qui ont été utilisées pour résoudre des problèmes similaires avec IBM SNA/SDLC et d’autres protocoles plus anciens dans le passé. Beaucoup de solutions satellitaires ont besoin d’un périphérique externe pour assurer une accélération TCP. Presque toutes les solutions existantes accélèrent le TCP dans une seule direction. Beaucoup de solutions sont basées sur le ‘spoofing’ du protocole TCP/IP. Le problème ici est qu’il n’y a pas de gestion bout-a-bout de la session TCP, donc si un paquet est abandonné à mi-parcours lors du transfert d’un gros fichier, le fichier doit être retransmis depuis le début. iDirect fournit une accélération TCP bidirectionnelle, construite dans le routeur satellite et l’équipement hub sur le site distant et sur l’équipement hub téléport. En outre, la transmission des données est suivie et tamponnée et des accusés de réception occasionnels sont envoyés de bout en bout de sorte que si une erreur se produit, seule la partie corrompue a besoin d’être retransmise.
Une autre question connexe est la configuration de Session TCP. Cela peut être vu en chargeant une page Web qui a des liens multiples dessus. Chacun de ces liens doivent passer par un processus de connexion/reconnaissance qui doit être exécuté de façon séquentiel et directement affecté par la latence satellite. iDirect fournit une accélération HTTP ou Web qui fonctionne dans les deux directions. Cela améliore considérablement la réponse Web en éliminant la nécessité pour les paquets d’accusé de réception de traverser la liaison par satellite. Cela a pour résultat le téléchargement facile et rapide des pages, comme si c’était une liaison terrestre.
Fiabilité et Affaissement Pluie
Tous ceux qui ont déjà utilisé les services de télévision vidéo DirecTV ou Dish Network sont conscients du fait que le service peut être dégradé ou perdu au cours d’une tempête. Cette interférence est particulièrement troublante pour le trafic IP. La technologie TCP/IP exige de très faibles taux d’erreur binaire (BER 10-9) pour fournir des données à pleine vitesse. Avec l’augmentation des taux d’erreur, les paquets doivent être retransmis, résultant en une réduction significative du débit. Sur un service de diffusion IP par satellite, lorsque le Taux de ‘Bit Error’ est dégradé à 10-7 BER, le débit IP chute à environ 5%. Les Fournisseurs satellite ont intégré une correction des erreurs en aval (FEC) qui fonctionne pour corriger les erreurs au cours de la retransmission. Le défi consiste à trouver un équilibre entre la surcharge de la technologie FEC et le gain en performance en atténuant les erreurs. De nos jours, la FEC la plus courante est appelée Reed Solomon Viterbi (RSV). Cette technologie FEC a été incorporée dans la plupart des chipsets utilisant DVB/MPEG pour fournir des données. La principale limitation du RSV, c’est que plus le niveau de fiabilité souhaité est élevé, plus le montant général FEC est positif, à grands frais pour l’efficacité de la bande passante.
Il s’agit d’une technologie récente et de loin supérieure appelée Turbo Product Codes (TPC) qui fonctionne en utilisant un processus itératif un peu comme un turbo sur un moteur de voiture. Il corrige quelques-unes des erreurs, puis envoie les données à travers le processus, tentant de corriger toute la corruption de paquets qui pourrait s’être produite lors de la transmission. Il fait cela en utilisant un minimum de FEC. Le ‘Turbo Product Coding’ réduit la quantité de puissance requise pour les antennes afin de transmettre des signaux vers un satellite, tout en maintenant de hautes performances de correction d’erreur. En conséquence, les clients peuvent utiliser des antennes plus petites moins chères, ce qui permet aux applications voix, données et Internet d’être prises en charge de façon plus rentable. Selon les experts de l’industrie, TPC offre les meilleures performances de codage d’une technologie commune FEC mise en œuvre à ce jour. Dans l’ingénierie des communications vous aurez rarement quelque chose gratuitement. Généralement la technologie qui améliore la fiabilité des informations se fait au prix de temps ou de bande passante. TPC est la technologie la plus proche de quelque chose ne vous demandant rien en retour.
iDirect est le premier fournisseur de technologie satellite à mettre en œuvre cette nouvelle technologie dans leurs produits, et c’est le seul (à ce moment) qui l’utilise dans les deux directions.
Remarque: Certains fournisseurs ont commencé à mettre en œuvre les Turbo Codes, qui ne sont pas la même chose que les Codes Produit et ne délivrent pas le même degré d’efficacité et de fiabilité. Il y a en fait deux implémentations différentes de Turbo Codes : Les ‘Turbo Convolutional Codes’ (ou TCC), et les ‘Turbo Product Codes ou TPC’. Selon les experts, la mise en œuvre la plus prometteuse est représentée par les Turbo Product Codes, ou TPC, car ils fournissent un avantage significatif en termes de fiabilité et de performances accrues. Les TCC limitent généralement le taux d’erreur possible maximum.
Avec la correction des erreurs en aval, la puissance de transmission VSAT est un facteur important pour les intempéries. Sur les transpondeurs satellites, c’est la puissance, pas la bande passante, qui est le facteur critique. Les fournisseurs de satellites ont des règles concernant la quantité d’énergie pouvant être dirigée vers le satellite. La plupart des VSAT ont un montant fixe de puissance qu’ils peuvent utiliser pour transmettre un signal. Alors que la météo se dégrade, il viendra un moment où la puissance d’émission sera insuffisante pour atteindre le transpondeur sans erreurs importantes qui se produisent, ce qui réduit considérablement le débit IP à l’endroit où elle peut échouer.
| Page 1: Technologie compatible iDirect: Introduction | |
| Page 2: TCP par satellite et fiabilité | |
| Page 3: Affaissement pluie et questions sur la performance | |
| Page 4: Services |
Reproduit avec la permission de Business Satellite Solutions, LLC | www.bcsatellite.com
Cliquez Pour Obtenir Votre Devis ou appelez-nous au 1-866-556-3176
