UMTS - protokół tunelowania GPRS
Generowanie protokołu GPRS Tunneling Protocol (GTP) było praktycznie niemożliwe, ale nie jest też pożądane, aby go udostępniać w nowym systemie, ale z drugiej strony jest całkiem zrozumiałe, że ulepszenia są również potrzebne, aby móc współdziałać ze światem starszego PS i funkcje wsparcia potrzebne dla najnowszego systemu.
Protokół tunelowania GPRS (GTP)
Protokół GTP jest przeznaczony do tunelowania i enkapsulacji jednostek danych i komunikatów sterujących w GPRS. Od czasu zaprojektowania go pod koniec lat 90., został wdrożony na dużą skalę i zebrano solidne doświadczenie.
GTP dla systemu Evolved 3GPP jest dostępny w dwóch wariantach, płaszczyźnie sterowania i użytkownika. GTP-C zarządza sygnalizacją płaszczyzny sterowania i jest to niezbędne oprócz protokołu transmisji danych o czystości użytkownika, GTP-U; nazywa się to płaszczyzną użytkownika. Aktualne wersje, odpowiednie dla EPS to GTPv1 US i GTPv2-C.
Cechą charakterystyczną GTP jest to, że obsługuje on separację ruchu w ramach swojego podstawowego posiadacza tunelu GTP, lub innymi słowy, możliwość grupowania ich razem i traktowania nośników. Końce tuneli GTP są identyfikowane przez TEID (identyfikatory punktu końcowego tunelu); są przypisane do poziomu lokalnego dla łącza w górę i łącza w dół przez jednostki równorzędne i zgłaszane poprzecznie między nimi. Identyfikatory TEID są używane na różnym poziomie szczegółowości przez konkretne przykładowe połączenie PDN na interfejsach S5 i S8 oraz EU na interfejsach S3 / S4 / S10 / S11.
Płaszczyzna kontrolna protokołu tunelowania GPRS
GTPv2-C jest używany w interfejsach sygnalizacyjnych EPC (w tym SGSN co najmniej Rel. 8). Na przykład -
- S3 (między SGSN i MME),
- S4 (między SGSN a obsługującym GW),
- S5 i S8 (między obsługującym GW i PDN GW),
- S10 (między dwoma MME) i
- S11 (między MME a Serving GW).
Odpowiada temu typowa jednostka danych protokołu GTPv2-C, jak pokazano na powyższym rysunku, konkretna część GTP jest poprzedzona nagłówkami IP i UDP, składa się z nagłówka GTPv2-C i części zawierającej informacje o zmiennej GTPv2-C w liczbie, długość i format, w zależności od rodzaju wiadomości. Ponieważ echo i powiadomienie o wersji protokołu nie są obsługiwane, informacje TEID nie są obecne. Wersja protokołu jest oczywiście mocno ustawiona na 2 w tej wersji protokołu.
GTP miał złożony, starszy mechanizm nagłówka rozszerzenia; nie jest używany w większości GTPv2-C. Typ wiadomości jest zdefiniowany w drugim bajcie (więc można zdefiniować maksymalnie 256 wiadomości dla przyszłych rozszerzeń). Poniższa tabela zawiera przegląd wiadomości aktualnie zdefiniowanych GTPv2-C. Długość wiadomości jest zakodowana w bajtach 3 i 4 (mierzona w bajtach i nie zawiera samych pierwszych czterech bajtów).
TEID to identyfikator punktu końcowego tunelu, pojedyncza wartość po stronie przeciwnej / odbiorczej; umożliwia multipleksowanie i de-multipleksowanie tuneli na jednym końcu, w bardzo częstych przypadkach przez tunel GTP należy rozróżnić.
Typ wiadomości | Wiadomość | Dodatkowe wyjaśnienie |
---|---|---|
0 | Zarezerwowany | Nigdy nie powinien być używany (celowo wyłączony z protokołu, aby wymusić jawne ustawienie) |
1/2 | Żądanie / odpowiedź echa | Służy do sprawdzania, czy wersja GTP jest obsługiwana przez węzeł wysyłający. |
3 | Wersja nieobsługiwana Wskazanie | Zawiera najnowszą wersję GTP obsługiwaną przez węzeł wysyłający. |
4/5 | Żądanie / odpowiedź o przekazaniu bezpośrednim | Używany do tunelowania komunikatu sygnalizacyjnego na interfejsie S101 w celu zoptymalizowanego przekazywania, między brakiem dostępu HRPD a MME |
6/7 | Żądanie powiadomienia / odpowiedź | Służy do powiadamiania o tunelowaniu na S101 między węzłem dostępowym HRPD a MME |
25/26 | Żądanie SRVCC PS do CS | Służy do wyzwalania i potwierdzania inicjacji SRVCC między SGSN / MME a serwerem MSC |
27/28 | SRVCC PS to CS pełne powiadomienie | Służy do wskazania i potwierdzenia zakończenia SRVCC między serwerem MSC a SGSN / MME |
32/33 | Utwórz żądanie sesji | Służy do ustanawiania łączności między dwoma węzłami |
34/35 | Zmodyfikuj żądanie okaziciela | Służy do modyfikowania właściwości pojedynczego lub wielu nośników, zawiera informacje o kontekście nośnika |
36/37 | Usuń żądanie sesji | Zrywa sesję kontrolną GTP |
38/39 | Żądanie zmiany powiadomienia | Służy do raportowania informacji o lokalizacji |
66/67 | Usuń polecenie / wskazanie błędu dla nośnika | Poinstruuj węzły, aby usunęły nośnik i potwierdzają z powrotem |
68/69 | Wskazanie polecenia / awarii zasobu nośnika | Służy do przydzielania lub modyfikowania zasobów |
73 | Wskaźnik zakończenia stronicowania | Wysyłane z SGW do MME lub SGSN |
95/96 | Utwórz żądanie / odpowiedź okaziciela | Poinstruuj węzły, aby zainstalowały nośniki i potwierdź z powrotem |
97/98 | Zaktualizuj żądanie okaziciela | Służy do informowania węzłów płaszczyzny sterowania z płaszczyzny użytkownika o zmianach nośnika |
Ulepszony GTPv1-U
Tylko niewielka, ale skuteczna poprawa została zastosowana w GTP-U i dlatego nie uznano za konieczne zwiększenie liczby wersji protokołu. Tak więc nadal oczekujemy GTPv1-U, ale przynajmniej jest to najnowszy Rel. 8.
Stos protokołów jest zasadniczo taki sam jak w przypadku GTPv2-C, z jedynie nazwami warstw i odpowiednio podstawionymi protokołami. Mechanizm nagłówka rozszerzenia pozostaje na miejscu; w razie potrzeby umożliwia wstawienie dwóch elementów.
Port źródłowy UDP wiadomości wyzwalającej (dwa oktety);
Numer PDCP PDU - dotyczy charakterystycznego transferu bez utraty; w takim przypadku pakiety danych muszą być numerowane w EPC (dwa oktety).
Ulepszenie polega na zdolności do przenoszenia „rynku końcowego” na płaszczyźnie użytkownika. Jest używany w procedurze przekazywania między eNodeB i wskazuje, że ścieżka jest aktywowana natychmiast po pakiecie danych, na przykład funkcja nie jest konieczna do pre-Rel.8, ponieważ GTP-U nie kończy się na dostępie radiowym węzeł (tj. nie w BS ani NodeB) istnieje tylko kilka wiadomości. GTPv1-U i są wymienione w powyższej tabeli.
Jest oczywiste, że w rzeczywistości bardzo ograniczony rodzaj sygnalizacji jest możliwy za pośrednictwem GTPv1-U (mechanizmy echa i etykietowanie końca). Jedyny komunikat, że przesyłane są rzeczywiste dane użytkownika, jest typu 255, tak zwany komunikat G-PDU; jedyną informacją, jaką przenosi, po nagłówku jest oryginalny pakiet danych od użytkownika lub zewnętrznego urządzenia PDN.
Nie wszystkie wystąpienia tuneli GTP-U są wymienione w architekturze referencyjnej (której celem było uchwycenie skojarzeń, które nie istniały już między węzłami sieci); możliwe są tymczasowe tunele -
Pomiędzy dwoma obsługującymi GW, mającymi zastosowanie do transferu opartego na S1, w przypadku gdy usługa jest przenoszona GW;
Między dwoma SGSN, odpowiada poprzedniemu przypadkowi, ale w starszej sieci PS;
Pomiędzy dwoma RNC, mającymi zastosowanie do relokacji RNC w sieci 3G PS (bez związku z EPC, jest tu wspomniane tylko dla kompletności).