UMTS-GPRS 터널링 프로토콜
GPRS 터널링 프로토콜 (GTP)의 생성은 사실상 불가능했지만 새로운 시스템에 제공하는 것도 바람직하지 않지만, 다른 한편으로 상호 작용할 수 있도록 개선이 필요하다는 것은 이해가됩니다. 기존 PS의 세계와 원활하게 연결되고 최신 시스템에 필요한 기능을 지원합니다.
GPRS 터널링 프로토콜 (GTP)
GTP 프로토콜은 GPRS에서 데이터 단위 및 제어 메시지의 터널링 및 캡슐화를 위해 설계되었습니다. 1990 년대 후반 설계 이후 대규모로 배치되어 탄탄한 경험을 쌓았습니다.
Evolved 3GPP 시스템 용 GTP는 제어 및 사용자 평면의 두 가지 변형으로 제공됩니다. GTP-C는 제어 플레인 시그널링을 관리하며 사용자의 순도에 대한 데이터 전송 프로토콜 인 GTP-U에 추가로 필요합니다. 이를 사용자 평면이라고합니다. EPS에 적합한 현재 버전은 GTPv1 US 및 GTPv2-C입니다.
GTP의 특징은 기본 GTP 터널 홀더 내에서 트래픽 분리를 지원한다는 것입니다. 즉,이를 함께 그룹화하고 캐리어를 처리하는 기능입니다. GTP 터널의 끝은 TEID (터널 끝점 식별자)로 식별됩니다. 그들은 피어 엔티티에 의해 업 링크 및 다운 링크에 대한 로컬 레벨에 할당되고 그들 사이에서 가로로보고됩니다. TEID는 S5 및 S8의 특정 예제 PDN 연결과 S3 / S4 / S10 / S11 인터페이스의 EU에 의해 서로 다른 단위로 사용됩니다.
GPRS 터널링 프로토콜의 제어 플레인
GTPv2-C는 EPC 신호 인터페이스 (최소 Rel. 8의 SGSN 포함)에서 사용됩니다. 예를 들면-
- S3 (SGSN과 MME 사이),
- S4 (SGSN과 GW 제공 사이),
- S5 및 S8 (GW 및 PDN GW 제공 사이),
- S10 (두 MME 사이) 및
- S11 (MME와 GW 제공 사이).
이에 대응하여 위의 그림과 같은 일반적인 GTPv2-C 프로토콜 데이터 단위, 특정 부분 GTP 앞에 IP 및 UDP 헤더가 있으며, GTPv2-C 헤더와 숫자로 된 GTPv2-C 변수 정보를 포함하는 부분으로 구성되며, 메시지 유형에 따라 길이 및 형식. 에코 및 프로토콜 버전 알림이 지원되지 않으므로 TEID 정보가 없습니다. 이 버전의 프로토콜에서는 버전이 확실히 2로 설정되어 있습니다.
GTP에는 복잡한 레거시 확장 헤더 메커니즘이있었습니다. 대부분의 GTPv2-C에서는 사용되지 않습니다. 메시지 유형은 두 번째 바이트로 정의됩니다. 따라서 향후 확장을 위해 최대 256 개의 메시지를 정의 할 수 있습니다. 아래 표는 현재 정의 된 GTPv2-C 메시지의 개요를 제공합니다. 메시지 길이는 바이트 3과 4로 코딩됩니다 (바이트 단위로 측정되며 처음 4 바이트 자체는 포함하지 않음).
TEID는 터널 끝점의 ID이며 반대쪽 / 수신 측의 단일 값입니다. GTP 터널을 통해 매우 빈번한 경우 한쪽 끝에서 다중화 및 역 다중화 터널을 구분해야합니다.
| 메시지 유형 | 메시지 | 추가 설명 |
|---|---|---|
| 0 | 예약석 | 절대 사용하지 않아야 함 (명시적인 설정을 적용하기 위해 프로토콜에서 의도적으로 제외됨) |
| 1/2 | 에코 요청 / 응답 | 보내는 노드에서 GTP 버전을 지원하는지 확인하는 데 사용됩니다. |
| 삼 | 지원되지 않는 버전 표시 | 송신 노드를 지원하는 최신 GTP 버전을 포함합니다. |
| 4/5 | 직접 이체 요청 / 응답 | HRPD 액세스가 아닌 MME 간의 핸드 오버를 최적화하기 위해 S101 인터페이스의 터널링 신호 메시지에 사용됩니다. |
| 6/7 | 알림 요청 / 응답 | HRPD 액세스 노드와 MME 간 S101의 터널링 알림에 사용됩니다. |
| 25/26 | SRVCC PS-CS 요청 | SGSN / MME와 MSC 서버 간의 SRVCC 시작을 트리거하고 확인하는 데 사용됩니다. |
| 27/28 | SRVCC PS-CS 완료 알림 | MSC 서버와 SGSN / MME 간의 SRVCC 완료 표시 및 확인에 사용 |
| 32/33 | 세션 요청 생성 | 두 노드 간의 연결을 설정하는 데 사용됩니다. |
| 34/35 | 베어러 요청 수정 | 단일 또는 다중 베어러의 속성을 수정하는 데 사용되며 베어러 컨텍스트 정보를 포함합니다. |
| 36/37 | 세션 요청 삭제 | GTP 제어 세션 중단 |
| 38/39 | 변경 알림 요청 | 위치 정보보고에 사용 |
| 66/67 | 베어러 명령 / 실패 표시 삭제 | 베어러를 삭제하고 다시 확인하도록 노드에 지시 |
| 68/69 | 베어러 자원 명령 / 실패 표시 | 자원 할당 또는 수정에 사용 |
| 73 | 페이징 중지 표시 | SGW에서 MME 또는 SGSN으로 전송 |
| 95/96 | 베어러 요청 / 응답 생성 | 베어러를 설치하도록 노드에 지시하고 다시 확인 |
| 97/98 | 전달자 요청 업데이트 | 베어러 변경에 대해 사용자 플레인에서 컨트롤 플레인 노드에 알리는 데 사용됩니다. |
향상된 GTPv1-U
작지만 효과적인 개선 만 GTP-U에 적용되었으며,이를 위해 프로토콜 버전의 수를 강화할 필요가 없다고 간주되었습니다. 따라서 여전히 GTPv1-U를 기대하지만 최소한 가장 최근의 Rel입니다. 8.
프로토콜 스택은 기본적으로 GTPv2-C와 동일하며 레이어 이름과 그에 따라 프로토콜이 대체됩니다. 확장 헤더 메커니즘은 제자리에 유지됩니다. 필요한 경우 두 개의 요소를 삽입 할 수 있습니다.
트리거 메시지의 UDP 소스 포트 (두 옥텟)
PDCP PDU 번호-손실없는 특성 전송과 관련됨. 이 경우 데이터 패킷은 EPC (두 옥텟)에서 번호가 지정되어야합니다.
개선점은 사용자 평면에서 "최종 시장"을 전송하는 능력입니다. 이는 inter-eNodeB 핸드 오버 절차에서 사용되며 데이터 패킷 직후에 경로가 활성화된다는 표시를 제공합니다. 예를 들어 GTP-U가 무선 액세스에서 끝나지 않았기 때문에 Rel.8을 사전에 기능이 필요하지 않습니다. 노드 (즉, BS 또는 NodeB가 아님)는 몇 개의 메시지 만 존재합니다. GTPv1-U이며 위의 표에 나열되어 있습니다.
실제로 GTPv1-U (에코 메커니즘 및 엔드 라벨링)를 통해 매우 제한된 종류의 시그널링이 가능하다는 것이 분명합니다. 실제 사용자 데이터의 전송이 유형 255라는 유일한 메시지, 이른바 G-PDU 메시지; 헤더 이후에 전달되는 유일한 정보는 사용자 또는 외부 PDN 장비의 원본 데이터 패킷입니다.
GTP-U 터널의 모든 인스턴스가 참조 아키텍처에 나열되는 것은 아닙니다 (네트워크 노드간에 더 이상 존재하지 않는 연결을 캡처하기위한 목적). 임시 터널이 가능합니다-
서비스가 GW로 이동하는 경우 S1 기반 전송에 적용 가능한 두 개의 Serving GW 사이
두 SGSN 사이에서 이전 사례에 해당하지만 레거시 PS 네트워크에 있습니다.
3G PS 네트워크에서 RNC 재배치에 적용 할 수있는 두 RNC 사이 (EPC와는 무관하며 완전성을 위해 여기에 언급 됨)