Satelitarne sieci TCP/IP


Wstęp

Koncepcja satelitarnej sieci działającej zgodnie z protokołami TCP/IP jest na razie sprawą przyszłości. Większość komercyjnych przedsięwzięć budowy sieci transmisji danych opartych na satelitach LEO lub MEO skończyła się niepowodzeniami. Zrezygnowano również z włączenia segmentu satelitarnego do sieci komórkowej 3-ciej generacji IMT-2000.
Fakty te oddalają w czasie realizację satelitarnej sieci działającej zgodnie z protokołami TCP/IP. Jednak należy przypuszczać, że sieć taka powstanie, w bliższej lub dalszej przyszłości. Jeżeli powszechnym ma się stać mobilny dostęp do Internetu, to satelitarna sieć TCP/IP stanowiłaby logiczne uzupełnienie sieci naziemnej.
Z drugiej strony, historia może się potoczyć podobnie jak w przypadku telefonii komórkowej. Satelitarne sieci telefoniczne szybko przegrały batalię o klientów z naziemnymi sieciami komórkowymi...

Niezależnie od względów ekonomicznych, koncepcja satelitarnej sieci internetowej wydaje się bardzo interesująca od strony technicznej. Potwierdza to duża ilość publikacji z tej tematyki, które pojawiają się w ostatnich latach.


Porównanie konstelacji GEO i LEO/MEO

Można rozważać budowę satelitarnej sieci TCP/IP w oparciu o satelity GEO lub LEO/MEO. Obydwa rozwiązania mają swoje wady. Dla konstelacji GEO są to :

1. Duże opóźnienia w łączności ziemia-satelita. Czas transmisji sygnału z powierzchni Ziemi do satelity geostacjonarnego to co najmniej 120 ms.
2. Duża bitowa stopa błędów (BER), rzędu 10^-6. Dla porównania, w systemach kablowych BER przyjmuje wartości rzędu 10^-10 lub mniejsze.
3. Niepełne pokrycie powierzchni Ziemi. Sygnał z satelitów geostacjonarnych nie dociera do obszarów okołobiegunowych.

W przypadku satelitów LEO :

1. Satelity w ciągłym ruchu względem powierzchni Ziemi i względem samych siebie. Utrudnia to projektowanie łączy ISL i zapewnienie stałego pokrycia zasięgiem powierzchni Ziemi.
2. Opóźnienia są mniejsze niż w przypadku satelitów GEO (2 - 50 ms), ale zmieniają się w czasie. Wynika to z ruchu satelity względem punktu na powierzchni Ziemi, gdzie znajduje się obsługiwany terminal.
3. Bitowa stopa błędów jest mniejsza niż dla satelitów GEO, ale nadal duża - rzędu 10^-8.
4. "Shadowing" - satelity LEO, gdy znajdują się nisko nad horyzontem, mogą być zasłaniane przez budynki i inne przeszkody terenowe. Problem ten może występować nawet dla kątów elewacji satelitów równych kilkadziesiąt stopni.
5. Przełączenia - gdy satelita prowadzący transmisję z terminalem na powierzchni Ziemi znika za horyzontem, konieczne jest przekierowanie transmisji do następnego, nadlatującego za nim satelity.

Budowa konstelacji LEO wiąże się z rozwiązaniem bardziej skomplikowanych problemów technicznych. Jednak pozwala na uzyskanie zasięgu globalnego i zapewnia lepszą jakość transmisji (BER, opóźnienia). Jest to szczególnie istotne w przypadku usług czasu rzeczywistego, np. rozmów telefonicznych. Dlatego konstelacje LEO/MEO są częściej brane pod uwagę przy projektowaniu nowoczesnych sieci satelitarnych.


Budowa satelitarnej sieci TCP/IP

W bardziej szczegółowy sposób rozważane będą trzy kwestie związane z budową satelitarnych sieci TCP/IP :

• łącza międzysatelitarne ISL,
• pokrycie powierzchni Ziemi i przełączenia,
• implementacja protokołu TCP.

Łącza międzysatelitarne ISL (Inter Satellite Links)

Łącza satelitarne są konieczne, jeżeli rozważany jest routing pakietów IP i bezpośrednia transmisja danych między satelitami. Oczywiście wiąże się to z zastosowaniem aktywnych przekaźników na pokładach satelitów. Istnienie łączy ISL pozwala zredukować ruch telekomunikacyjny przechodzący przez naziemny segment sieci. Wiąże się też ściśle z istnieniem adapterów sieciowych (gateways). Dzięki łączom ISL możliwe jest :

• zmniejszenie i zrównoważenie ruchu telekomunikacyjnego obsługiwanego przez poszczególne adaptery sieciowe,
• zmniejszenie liczby samych adapterów,
• zabezpieczenie przed awariami poszczególnych adapterów.

Łącza ISL są możliwe jedynie między satelitami krążącymi po orbitach o tej samej wysokości i inklinacji. W innym przypadku byłyby to łącza periodyczne - po pewnym czasie satelity znajdowałyby się zbyt daleko od siebie, nawet po drugiej stronie kuli ziemskiej.
Z tych samych powodów nie jest możliwe połączenie ISL między satelitami krążącymi po sąsiednich orbitach, ale w dwóch różnych kierunkach. Tym większe znaczenie ma wybór typu konstelacji ("star" lub "delta") - przedstawionych na rysunku poniżej (widok kuli ziemskiej od strony bieguna) :


Konstelacja Π - "star" (z lewej) i konstelacja 2Π - "delta" (inklinacja 90°, widok od strony bieguna)

Dla przypadku Π ("star"), możliwe są łącza ISL między satelitami na obu półkulach, ale nie między półkulami. W przypadku konstelacji 2Π ("delta"), nie można stworzyć łączy ISL między sąsiednimi orbitami, konieczne są "skoki" co dwie orbity. Konstelacja 2Π pozwala jednak na łącza ISL wokół całej kuli ziemskiej.
Schemat Π zastosowano w sieciach Iridium i Teledesic. Koncepcję 2Π wykorzystano w Globalstar, Celestri i Skybridge.

Wyróżnia się łącza ISL :

• intra-plane (intra-orbital) - łączące satelity na jednej orbicie
• inter-plane (inter-orbital) - łączące satelity poruszające się na różnych orbitach.

Pierwszy przypadek jest prostszy. Względna pozycja satelitów jest przez cały czas taka sama.
W drugim przypadku względna pozycja satelitów podlega ciągłym zmianom. Dlatego konieczne jest precyzyjne sterowanie antenami obsługującymi łącze ISL. Szczególnie krytyczny jest okres czasu, gdy satelity przelatują przez punkt skrzyżowań ich orbit. W krótkim odstępie czasu anteny łączy ISL muszą wykonać obrót o znaczny kąt (rysunek z prawej autorstwa Jerome Galtiera).



Pokrycie powierzchni Ziemi i problem przełączeń (handovers, handoffs)

Wyróżnia się dwa typy pokrycia powierzchni Ziemi wiązkami antenowymi satelitów :

• satellite-fixed - anteny satelitów obsługujące kanały uplink i downlink są sztywno umocowane. W związku tym, gdy satelita przelatuje nad powierzchnią Ziemi, obsługiwany przez niego obszar (footprint) przesuwa się razem z nim.
• earth-fixed - anteny satelitów "śledzą" obsługiwany obszar na powierzchni Ziemi. Co pewien okres czasu następuje przełączenie w całej konstelacji satelitarnej. Anteny danego satelity "przeskakują" do następnego obszaru. Poprzedni obszar jest przejmowany przez kolejnego satelitę.

Pojedynczy satelita LEO pozostaje w zasięgu danego punktu na powierzchni Ziemi nie dłużej niż przez 30 minut. Jego prędkość względem powierzchni Ziemi to 23 - 29 tys. km/h. Dlatego konieczne są częste przełączenia - przekierowania transmisji radiowej odbywającej się przez jednego satelitę na innego, najczęściej tego nadlatującego za nim.
Z tego powodu pokrycie typu satellite-fixed jest bardzo kłopotliwe - przełączenia są bardzo częste. Efektywniejsze, choć trudniejsze w realizacji jest pokrycie typu earth-fixed. W takim przypadku przełączenia w całej konstelacji odbywają się jednocześnie, w deterministycznie określonych momentach czasu.
Problem częstych przełączeń dotyczy oczywiście wszystkich sieci satelitarnych opartych na satelitach LEO, nie tylko sieci TCP/IP.

Konieczność przełączenia, intensywne opady deszczu lub "shadowing" mogą spowodować dłuższe przerwy w działaniu łącza Ziemia-satelita. Jest to oczywiście sytuacja wysoce niepożądana. Rozwiązaniem tej kwestii są techniki "multi-path" (diversity). Dany obszar na powierzchni Ziemi obsługiwany jest przez dwa lub więcej satelitów. Awaria lub niedostępność łącza z jednego satelity nie jest wtedy krytyczna, transmisja może być prowadzona przez innego satelitę. Technika "multi-path" została zaimplementowana w systemie Globalstar, Iridium niestety jej nie stosuje.



Implementacja protokołu TCP

TCP (Transmission Control Protocol) to protokół połączeniowy (connection-oriented) 4-tej warstwy modelu OSI/ISO implementowany zazwyczaj nad protokołem IP. Zawiera mechanizmy korekcji błędów (Error Control) i sterowania przepływem w sieci (Flow Control). Podstawowy standard TCP (RFC 793) został zaproponowany w roku 1981 przez Jona Postela i obowiązuje do dzisiaj. Później proponowano dodatkowe opcje protokołu, usprawniające jego działanie, również dla przypadku długich łączy, takich jak łącza satelitarne. Obecnie istnieje wiele wersji protokołu TCP (m.in. Tahoe, Reno, Vegas, SACK, Westwood). Zazwyczaj co najmniej kilka z nich jest implementowanych jednocześnie na danym komputerze bądź routerze.

Podstawowy mechanizm protokołu zakłada konieczność potwierdzenia przez odbiorcę wszystkich otrzymanych segmentów TCP. Nadawca wysyła pewną porcję danych - jej wielkość jest określona przez parametr "advertised window". Gdy nadejdzie potwierdzenie od odbiorcy, nadawca może wysłać następną porcję danych. Gdy odbiorca sygnalizuje błędy lub nie wyśle potwierdzenia, następuje retransmisja wszystkich danych, począwszy od pierwszego niepotwierdzonego segmentu. Krytyczny jest tutaj tzw. "Round Trip Time" - czas, w jakim dane podróżują przez sieć od nadawcy do odbiorcy i z powrotem.



Schemat segmentu TCP (z RFC 793)

Później zaproponowane mechanizmy (RFC 2581) pozwalają na bardziej wyrafinowane sterowanie przepływem danych :

• slow start - w początkowej fazie transmisji następuje wolne testowanie łącza, tak, aby uniknąć przeciążeń w sieci. Kolejno wysyłany jest 1 segment danych, po jego potwierdzeniu 2 segmenty, potem 4, 8, 16, itd. - szybkość transmisji wzrasta wykładniczo.
  
  
• congestion avoidance - gdy transmisja za pomocą algorytmu "slow start" osiągnie szybkość określoną parametrem "ssthresh", wzrost szybkości transmisji zmienia się na liniowy : np. 16 segmentów, 17 segmentów, 18, 19, itd. Parametr "ssthresh", określa pewien poziom nasycenia szybkości transmisji.
  
  
• fast retransmit - odbiorca może wskazać nadawcy konkretne numery segmentów, które zostały uszkodzone lub zgubione. Dokonuje tego za pomocą tzw. selektywnych potwierdzeń (Selective Acknowledgement).
  
  
• fast recovery - po zagubieniu w sieci pojedynczego segmentu ponowna transmisja może być rozpoczęta z szybkością określoną przez "ssthresh", a nie według algorytmu "slow start".

Należy dodać, że algorytmy "slow start" i "congestion avoidance" nie pozwalają zwiększyć szybkości transmisji powyżej wartości określonej przez "advertised window".


Przy implementacji protokołu TCP do łącz Ziemia-satelita lub satelita-satelita należy być świadomym następujących kwestii :

1. Ograniczony rozmiar okna "advertised window"
   W segmencie TCP, pole określające rozmiar okna "advertised window" ma 16 bitów. W związku z tym, maksymalny rozmiar tego okna to 64 kB (2¹⁶ B). Dla łączy z satelitami geostacjonarnymi, czas "Round Trip Time" (minimalny czas, który mija od wysłania danych do otrzymania potwierdzenia) może wynosić 0.5 sekundy lub więcej. Wtedy faktyczna szybkość transmisji tej sesji TCP nie może przekroczyć wartości równej 64 kB / 0.5 s = 128 kB/s, nawet, jeżeli dostępna przepustowość łącza jest większa.
   Rozwiązaniem tego problemu jest opcja "Window Scale". Dzięki niej możliwe jest zwiększenie okna wielokrotnie względem jego maksimum 64 kB.
   
   
2. Wznowienie transmisji po utracie pakietów
   Algorytm "fast recovery" pozwala wznowić transmisję z szybkością określoną przez "ssthresh" po utracie pojedynczego segmentu. Jednak w transmisji satelitarnej, bitowa stopa błędów jest duża (rzędu 10^-8 - 10^-6) i często zdarza się, że błędnych jest więcej niż jeden segment. Wtedy protokół TCP narzuca retransmisję według wolnego algorytmu "slow start". W przypadku długich łączy satelitarnych, czas osiągnięcia na powrót wysokiej szybkości transmisji może być duży. Skutkiem tego jest ogólny spadek jakości usługi satelitarnej transmisji danych.
   Wyjściem z tego problemu jest rozwinięcie mechanizmu potwierdzeń selektywnych i uogólnienie algorytmów "fast retransmit" i "fast recovery" na przypadek utraty kilku segmentów.
   
   
3. Pomiar "Round Trip Time"
   W protokole TCP, nadawca musi znać dokładną wartość czasu "Round Trip Time", aby wiedzieć kiedy retransmitować zagubione segmenty. Długość łącz Ziemia-satelita LEO oraz łącz ISL zmienia się podczas ruchu satelitów na ich orbitach. W związku z tym konieczny jest pomiar czasu "Round Trip Time" na bieżąco.
   Kwestię tę rozwiązuje algorytm "Timestamps", pozwalający na pomiar czasu transmisji prawie każdego segmentu.

Rozwiązania trzech powyższych kwestii omówione są dokładnie w dokumencie RFC 1323.





Strona główna