GTP'

GTP' (GTP prime) jest protokołem opartym na protokole IP używanym w sieciach GSM i UMTS . Może być używany z UDP lub TCP . GTP' używa tej samej struktury wiadomości co GTP (GTP-C, GTP-U), ale jest to w dużej mierze odrębny protokół. GTP” używa zarejestrowanego portu UDP/TCP 3386.

GTP' może być wykorzystany do przenoszenia danych dotyczących ładowania z „funkcji ładowania danych” (CDF) sieci GSM lub UMTS do „funkcji bramki ładującej” (CGF). W większości przypadków powinno to oznaczać przejście z wielu pojedynczych elementów sieci, takich jak numery GGSN, do scentralizowanego komputera, który następnie wygodniej dostarcza dane dotyczące ładowania do centrum rozliczeniowego operatora sieci.

GTP” jest używany w interfejsie Ga w ramach definicji sieci rdzeniowej 3GPP GPRS .

GTP” ponownie wykorzystuje aspekty GTP, chociaż cytując 3GPP TS 32.295, „tylko płaszczyzna sygnalizacyjna GTP jest częściowo ponownie wykorzystywana”. GTP' definiuje inny nagłówek, dodatkowe komunikaty, wartości pól, a także protokół synchronizacji, aby uniknąć utraty lub zduplikowania CDR w przypadku awarii CGF lub SGSN / GGSN . Przeniesione CDR, jeśli są zgodne ze standardami 3GPP, są zakodowane w ASN.1 .

nagłówek

Nagłówki GTP v1 i v2 zawierają następujące pola

+	Bity 0-2			3	4	5	6	7	8-15								16-31																32-47
0	Wersja			PT [0]	Skryty			długość hdr	Typ wiadomości								Długość																Numer sekwencji

Wersja

Pierwszym polem nagłówka w pakiecie GTP jest 3-bitowe pole wersji. Dla GTP' v2 ma to wartość 2 (stąd nazwa GTP' v2).

Typ protokołu (PT)

1-bitowa wartość, która odróżnia GTP' (wartość 0) od GTP (wartość 1).

Zarezerwowane

3-bitowe zarezerwowane pole (musi być jedynkami).

Długość nagłówka (Hdr len)

1-bitowa wartość, która dla GTP w wersji 0 wskazuje, czy używany jest 20-bajtowy nagłówek (wartość 0) (zgodnie z GTP ) lub ten 6-bajtowy nagłówek. Ten bit musi być wyłączony (wartość 0) dla kolejnych wersji GTP' iw tych nie wskazuje długości nagłówka, ponieważ zawsze musi to być 6 bajtów.

Typ komunikatu

8-bitowe pole określające typ komunikatu. Możliwa wartość:

Typ wiadomości	Opis
1	Żądanie echa
2	Odpowiedź echa
3	Wersja nieobsługiwana
4	Żądanie aktywnego węzła
5	Odpowiedź aktywnego węzła
6	Żądanie przekierowania
7	Odpowiedź przekierowania
240	Żądanie przeniesienia rekordu danych
241	Odpowiedź na transfer rekordu danych

Długość

16-bitowe pole określające długość pakietu hermetyzowanego przez GTP' (nie licząc samego nagłówka GTP').

Sequence Number

16-bitowe pole, które jednoznacznie identyfikuje ten pakiet i umożliwia wykrycie utraty lub zduplikowania

Typy wiadomości

GTP' używa niezmienionych komunikatów GTP Version Not Supported, Echo Request i Echo Response, ale dodaje następujące komunikaty

• Żądanie aktywnego węzła
• Odpowiedź aktywnego węzła
• Żądanie przekierowania
• Odpowiedź przekierowania
• Żądanie przeniesienia rekordu danych
• Odpowiedź na transfer rekordu danych

Żądanie/odpowiedź aktywnego węzła

Komunikaty Node Alive służą do informowania innych komponentów sieci, że węzeł uruchomił usługę. Żądanie jest wysyłane od początku węzła, dzięki czemu zapewnia szybszą metodę ponownego włączenia usługi niż odpytywanie za pomocą Echo Request/Response. Ta wiadomość może być również wykorzystana do poinformowania o powrocie innych węzłów oraz (w GTP w wersji 2) do poinformowania o adresie IPv6 CGF.

Żądanie/odpowiedź przekierowania

Komunikaty przekierowania służą do:

1. przekierować przepływ CDR z CDF ( SGSN / GGSN ) do innego CGF, gdy nadawca jest usuwany z eksploatacji (z powodu konserwacji/awarii).
2. poinformować, że CGF utracił połączenie z systemem położonym niżej

W obu przypadkach CDF otrzymuje więcej informacji o zbliżającej się lub natychmiastowej awarii, niż miałoby to miejsce w przypadku odpytywania CDF przy użyciu komunikatów Echo Request.

Ta wiadomość zawiera szczegóły dotyczące przyczyny i opcjonalnie adres(y) alternatywnego CGF.

Żądanie/odpowiedź na przesłanie rekordu danych

Komunikaty Data Record Transfer służą do niezawodnego transportu CDR-ów z punktu ich wygenerowania ( SGSN / GGSN ) do pamięci nieulotnej w CGF.

Żądanie przeniesienia rekordu danych

Każdy komunikat Żądania przeniesienia rekordu danych może zawierać komunikat jednego z czterech typów:

1. Wyślij pakiet rekordów danych — ta wiadomość zawiera zero lub więcej CDR. CDR mogą być zakodowane w ASN.1 przy użyciu BER lub rzadziej PER .
2. Wyślij prawdopodobnie zduplikowany pakiet rekordów danych — ta wiadomość zawiera jeden lub więcej CDR, a ta wiadomość została wcześniej wysłana do innego CGF.
3. Anuluj pakiet rekordów danych — ten komunikat nakazuje CGF usunięcie jednego lub więcej pakietów rekordów danych z „prawdopodobnie zduplikowanej” oczekującej kolejki CGF.
4. Zwolnij pakiet rekordów danych — ten komunikat nakazuje CGF zapisanie zawartości jednego lub więcej pakietów rekordów danych z oczekującej kolejki CGF „prawdopodobnie zduplikowanej”.

Istnieje mechanizm pozwalający uniknąć utraty lub zapisania duplikatów CDR. Jest to opisane bardziej szczegółowo w 3GPP TS 32.295. Podstawowym założeniem jest to, że każdy pakiet jest sekwencjonowany i jeśli nie zostanie potwierdzony indywidualnie, zostanie wysłany ponownie, dopóki nie zostanie potwierdzony przez jakikolwiek CGF. Normalne pakiety zapisu danych są natychmiast zapisywane w pamięci nieulotnej (np. na dysku), ale ponownie wysłane pakiety są oznaczane jako „prawdopodobnie zduplikowane” i trafiają do specjalnej kolejki, która nie jest natychmiast zapisywana w pamięci nieulotnej — następuje drugie potwierdzenie z CDF wymagany.

Zdolność do wysłania Żądania Przesłania Zapisu Danych zawierającego zero CDR jest wykorzystywana jako test do wykrycia sukcesu lub niepowodzenia CGF, który ma już zapisane rekordy przypisane do tego numeru sekwencyjnego i jest ważną częścią powyższego mechanizmu.

Odpowiedź na transfer rekordu danych

Odpowiedź na Przekazanie Rekordu Danych potwierdza otrzymanie jednego lub więcej komunikatów o Przeniesieniu Rekordu Danych; odpowiedzi mogą być grupowane ze względu na wydajność, ale muszą być wysyłane częściej niż limit czasu wysyłania CDF.

Potwierdzenie zawiera przyczynę i może być odrzuceniem zawartych zapisów.

Linki zewnętrzne

• Bezpośredni dostęp do numerowanych specyfikacji 3GPP
• Funkcja bramki ładującej typu open source (CGF)