{{위키데이터 속성 추적}}
{{IP스택}}
'''GTP'''' (GTP 프라임 또는 GTPP)는 [[GSM]] 및 [[UMTS]] 네트워크에서 사용되는 [[인터넷 프로토콜|IP]] 기반 프로토콜이다. [[사용자 데이터그램 프로토콜|UDP]] 또는 [[전송 제어 프로토콜|TCP]]와 함께 사용할 수 있다. GTP'는 [[GPRS 터널링 프로토콜|GTP]] (GTP-C, GTP-U)와 동일한 메시지 구조를 사용하지만 대부분 별도의 프로토콜로 간주한다. GTP'는 등록된 UDP / TCP 포트 3386을 사용한다.

GTP'는 GSM 또는 UMTS 네트워크의 "과금 데이터 장비"(CDF)에서 "과금 게이트웨이 장비"(CGF)로 과금 데이터를 전달하는 데 사용될 수 있다. 대부분의 경우 이는 GGSN과 같은 많은 개별 네트워크 요소에서 중앙 집중식 컴퓨터로 전송된 다음 과금 데이터를 네트워크 운영자의 청구 센터로 보다 편리하게 전달한다.

GTP'는 3GPP GPRS 코어 네트워크 정의 내 Ga 인터페이스에서 사용된다.

GTP'는 3GPP TS 32.295 "GTP의 시그널링 플레인만 부분적으로 재사용한다"고 인용하지만 GTP의 측면을 재사용한다.<ref>3GPP TS 32.295</ref> GTP'는 CGF 또는 SGSN / GGSN 실패 시 CDR의 손실 또는 중복을 피하기 위해 동기화 프로토콜뿐만 아니라 다른 헤더, 추가 메시지, 필드 값을 정의한다. 전달 된 CDR은 3GPP 표준을 따르는 경우 ASN.1 로 인코딩된다.

== 헤더 ==
GTP의 v1 및 v2 헤더에는 다음 필드가 포함되어 있다.
{| class="wikitable"
! width="4%" | +
! colspan="3" width="9%" | 비트 0-2
! colspan="1" width="3%" | 삼
! colspan="1" width="3%" | 4
! colspan="1" width="3%" | 5
! colspan="1" width="3%" | 6
! colspan="1" width="3%" | 7
! colspan="8" width="6" | 8-15
! colspan="16" width="24%" | 16-31
! colspan="16" width="24%" | 32-47
|-
! 0
| colspan="3" | 버전
| colspan="1" | PT [0]
| colspan="3" | 나중을 위해 남겨둔 비트
| colspan="1" | HDR 렌
| colspan="8" | 메시지 유형
| colspan="16" | 길이
| colspan="16" | 시퀀스 번호
|}

; 버전
: GTP' [[네트워크 패킷|패킷]]의 첫 번째 헤더 필드는 3 비트 버전 필드이다. GTP' v2의 경우이 값은 2이다 (따라서 GTP' v2라고 부름).
; 프로토콜 유형 (PT)
: GTP'(값 0)와 GTP (값 1)를 구별하는 1 비트 값
; 나중을 위해 남겨둔 비트
: 3 비트 예약 필드 (1이어야 함)
; 헤더 길이 (Hdr len)
: GTP 버전 0의 경우 1 비트 값은 20 바이트 헤더 (값 0) ( GTP 기준 ) 또는이 6 바이트 헤더를 사용하는지 여부를 나타낸다. 이 비트는 후속 GTP 버전에 대해 설정되지 않아야하며 (값 0), 이들은 항상 6 바이트 여야하므로 헤더 길이를 나타내지 않는다.
; 메시지 유형
: 메시지 유형을 나타내는 8 비트 필드이다. 가능한 값 :

{| class="wikitable"
! 메시지 유형
! 기술
|-
| 1
| 에코 요청
|-
| 2
| 에코 응답
|-
| 삼
| 지원되지 않는 버전
|-
| 4
| 노드 활성화 요청
|-
| 5
| 노드 작동 응답
|-
| 6
| 리디렉션 요청
|-
| 7
| 리디렉션 응답
|-
| 240
| 데이터 레코드 전송 요청
|-
| 241
| 데이터 레코드 전송 응답
|}

; 길이
: GTP'에 의해 캡슐화되는 패킷의 길이를 나타내는 16 비트 필드 (GTP'헤더 자체는 포함하지 않음).
; 시퀀스 번호
: 이 패킷을 고유하게 식별하고 손실 또는 복제를 감지 할 수 있는 16 비트 필드

== 메시지 유형 ==
GTP'는 지원되지 않는 GTP 버전, 에코 요청 및 에코 응답 메시지를 사용하지만 다음 메시지를 추가한다.

* 노드 활성화 요청
* 노드 작동 응답
* 리디렉션 요청
* 리디렉션 응답
* 데이터 레코드 전송 요청
* 데이터 레코드 전송 응답

=== 노드 작동 요청 / 응답 ===
Node Alive 메시지는 노드가 서비스를 시작했음을 다른 네트워크 구성 요소에 알리는 데 사용된다. 요청은 노드 시작에서 전송되므로 에코 요청 / 응답을 사용하는 [[폴링 (컴퓨터 과학)|폴링]] 보다 서비스를 다시 활성화하는 더 빠른 방법을 제공한다. 이 메시지는 다른 노드가 서비스로 돌아 오는 것을 알리고 (GTP 버전 2에서) CGF의 [[IPv6]] 주소를 알리는 데 사용될 수 있다.

=== 리디렉션 요청 / 응답 ===
리디렉션 메시지는 다음 용도로 사용된다.

# 발신자가 서비스에서 제거 될 때 (유지 보수 / 실패) CDF ( SGSN / GGSN )에서 다른 CGF로 CDR의 흐름을 전환한다.
# CGF가 다운 스트림 시스템과의 연결이 끊어 졌음을 알려준다.

두 경우 모두 CDF에 에코 요청 메시지를 사용하여 CDF가 폴링 한 경우보다 임박하거나 즉각적인 실패에 대한 자세한 정보가 CDF에 제공된다.

이 메시지에는 원인에 대한 세부 정보와 선택적으로 대체 CGF의 주소가 포함된다.

=== 데이터 레코드 전송 요청 / 응답 ===
데이터 레코드 전송 메시지는 CDR을 생성 지점 ( SGSN / GGSN )에서 CGF의 비 휘발성 저장소로 안정적으로 전송하는 데 사용된다.

==== 데이터 레코드 전송 요청 ====
각 데이터 레코드 전송 요청 메시지는 다음 네 가지 유형 중 하나의 메시지를 포함 할 수 있다.

# 데이터 레코드 패킷 보내기-이 메시지에는 0 개 이상의 CDR이 포함됩니다. CDR은 BER 또는 덜 일반적으로 PER을 사용하여 ASN.1 로 인코딩 될 수 있다.
# 중복 된 데이터 레코드 패킷 보내기-이 메시지에는 하나 이상의 CDR이 포함되어 있으며 이 메시지는 이전에 다른 CGF로 전송된다.
# 데이터 레코드 패킷 취소-이 메시지는 CGF가 "가능한 복제 된"보류 큐에서 하나 이상의 데이터 레코드 패킷을 제거하도록 CGF에 지시한다.
# Release Data Record Packet-이 메시지는 CGF에 "복제 된"보류 큐에서 하나 이상의 데이터 레코드 패킷의 내용을 쓰도록 CGF에 지시한다.

중복 CDR을 잃어 버리거나 쓰지 않도록하는 메커니즘이 있는데 이것은 3GPP TS 32.295에 자세히 설명되어 있다. 기본 전제는 모든 패킷이 시퀀싱되고 개별적으로 승인되지 않은 경우 CGF가 승인 할 때까지 재전송된다이다. 일반 데이터 레코드 패킷은 즉시 비 휘발성 저장소 (예 : 디스크)에 기록되지만 재전송 된 패킷은 "가능한 복제 됨"으로 표시되고 비 휘발성 저장소에 즉시 기록되지 않는 특수 대기열에 들어가며 CDF의 두 번째 확인이 필요하다.

제로 CDR을 포함하는 데이터 레코드 전송 요청을 전송하는 기능은 CGF가 해당 시퀀스 번호에 이미 기록 된 레코드를 작성했는지 여부를 감지하는 테스트로 사용되며 위 메커니즘의 중요한 부분이다.

==== 데이터 레코드 전송 응답 ====
데이터 레코드 전송 응답은 하나 이상의 데이터 레코드 전송 메시지 수신을 확인한다. 응답은 효율성을 이유로 그룹화 될 수 있지만 전송 CDF 시간 초과보다 더 자주 전송되어야한다.

ACK에는 cause가 포함되며 포함된 레코드를 거부 할 수 있다.

== 참고 문헌 ==
<references />

== 외부 링크 ==
* [https://web.archive.org/web/20081030112056/http://www.3gpp.org/specs/numbering.htm 번호가 매겨진 3GPP 사양에 직접 액세스]
* [http://code.google.com/p/open-cgf/ 오픈 소스 과금 게이트웨이 기능 (CGF)]

[[분류:통신 시설]]
[[분류:3GPP 표준]]
[[분류:이동 통신 표준]]