UE가 동영상 앱을 실행하면 실제 사용자 트래픽은 데이터 네트워크에 도달하기 전에 gNB에서 UPF로 이동해야 합니다. 제어 평면은 PDU Session을 설정하고 주소를 할당하며 전달 규칙을 설치하지만, 5G 액세스망과 코어망의 사용자 평면을 통해 사용자 IP 패킷을 실제로 운반하는 프로토콜은 GTP-U입니다. GTP-U를 이해하려면 단순히 ‘UDP 포트 2152’와 ‘TEID’를 기억하는 것만으로는 부족합니다. 5G에서는 하나의 N3 터널이 여러 QoS Flow를 운반할 수 있으며, 경로 감시, 알 수 없는 터널 처리, 이동성 이벤트 이후 사용자 평면 경로 정리에도 GTP-U 관리 메시지가 사용됩니다. 프로토콜 스택, 터널, TEID, QFI, 관리 절차를 하나의 완전한 사용자 평면 경로로 보면 5G 트래픽이 실제로 어떻게 UPF까지 도달하는지 훨씬 쉽게 이해할 수 있습니다.

GTP-U는 5G 아키텍처의 어디에 위치할까?

GTP-U는 GPRS Tunnelling Protocol for the User Plane의 약자입니다. 5G 사용자 평면 아키텍처에서는 주로 상위 계층의 사용자 트래픽을 캡슐화하여 사용자 평면 노드 사이에서 전달하는 데 사용됩니다.

5G Core 관점에서 GTP-U를 가장 흔히 사용하는 두 인터페이스는 N3와 N9입니다. N3는 gNB와 UPF를 연결하고 무선 액세스 네트워크와 5G Core 사이에서 사용자 트래픽을 운반합니다. N9는 UPF 사이에서 사용됩니다. RAN 내부에서는 gNB 사이의 Xn-U에서도 GTP-U를 사용할 수 있습니다.

이는 5G 제어 평면 아키텍처와 상당히 다릅니다. AMF와 SMF 같은 네트워크 기능은 주로 HTTP/2에 의존하는 서비스 기반 인터페이스를 사용하지만, 사용자 평면 경로는 가입자의 실제 트래픽을 운반하기 위해 계속 GTP-U를 사용합니다. 5G가 Service-Based Architecture로 전환됐다고 해서 사용자 평면 자체가 HTTP로 바뀐 것은 아닙니다.

GTP-U는 UDP 위에서 동작하며 계속 UDP 포트 2152를 사용합니다. 사용자의 애플리케이션 패킷에서 아래 계층 방향으로 프로토콜 스택을 보면 구조를 다음과 같이 이해할 수 있습니다.

애플리케이션 트래픽은 먼저 TCP 또는 UDP 패킷이 되고, 이어서 UE에 속한 IP 패킷이 됩니다. 5G 사용자 평면에 들어가면 이 원래 사용자 패킷이 GTP-U 안에 캡슐화됩니다. 그 다음 GTP-U 종단점 사이에서 전송하기 위해 외부 UDP 헤더, 외부 IP 헤더, 하위 계층의 Ethernet 프레임이 추가됩니다.

따라서 패킷 캡처에는 서로 다른 두 세트의 IP 주소가 나타날 수 있습니다. 내부 IP 주소는 UE와 데이터 네트워크의 애플리케이션 서버 간 통신을 나타내고, 외부 IP 주소는 gNB와 UPF 같은 GTP-U 터널 종단점 사이에서 사용됩니다. N3 트래픽을 문제 해결할 때 내부 IP 헤더와 외부 IP 헤더를 혼동하는 것은 흔한 실수입니다.

GTP Path, Tunnel, TEID의 차이는 무엇일까?

GTP Path, GTP Tunnel, Tunnel Endpoint, TEID는 서로 밀접한 용어이지만 GTP-U 전송 모델의 서로 다른 계층을 설명합니다.

GTP Path는 두 GTP 터널 종단점 사이의 비연결형 통신 경로로 볼 수 있습니다. gNB와 UPF가 IP 네트워크를 통해 GTP-U 패킷을 주고받을 수 있다면 두 종단점 사이에 GTP Path가 존재합니다. 여러 GTP-U 터널이 같은 Path를 공유할 수 있습니다.

GTP Tunnel은 더 구체적인 논리적 사용자 평면 터널을 의미합니다. GTP-U 터널은 TEID, IP 주소, UDP 전송 정보의 조합으로 식별하며, 터널 종단점 자체는 노드의 IP 주소와 UDP 포트로 식별합니다.

TEID, 즉 Tunnel Endpoint Identifier는 GTP-U에서 가장 중요한 필드 중 하나입니다. GTPv1-U 기본 헤더에서 TEID는 4바이트 길이입니다. GTP-U 패킷이 수신 노드에 도착하면 수신 측은 TEID와 로컬 터널 컨텍스트를 함께 사용해 해당 패킷이 어느 사용자 평면 터널에 속하는지, 어떤 PDU Session 또는 전달 컨텍스트가 처리해야 하는지를 판단합니다.

이 때문에 TEID를 단독으로 해석해서는 안 됩니다. 동일한 숫자의 TEID 값이 서로 다른 터널 컨텍스트에서 나타날 수 있습니다. 패킷이 서로 다른 GTP 종단점이나 서로 다른 방향에 속한다면 반드시 같은 터널의 일부인 것은 아닙니다.

페이로드 자체를 볼 때 알아두면 좋은 용어가 두 가지 더 있습니다. T-PDU는 원래의 상위 계층 사용자 데이터이고, G-PDU는 T-PDU에 GTP-U 헤더가 추가된 데이터 단위입니다. 따라서 N3를 통해 전달되는 것은 UE의 원래 IP 패킷만이 아니라 GTP-U로 캡슐화된 G-PDU입니다.

GTP-U는 사용자 데이터 운반에만 한정되지 않습니다. 자체 관리 메시지도 갖고 있습니다. 따라서 패킷 캡처에서 UDP 포트 2152가 보인다고 해서 그 패킷이 자동으로 사용자 애플리케이션 트래픽이라는 뜻은 아닙니다. Echo Request, Echo Response, Error Indication, End Marker 등 GTP-U 메시지도 같은 프로토콜 체계를 사용합니다.

TEID가 있는데도 5G에 QFI가 필요한 이유는 무엇일까?

GTP-U를 4G 관점에서 먼저 배우면 TEID만 식별하면 베어러를 식별할 수 있다고 생각하기 쉽습니다. 하지만 5G에서는 그런 이해만으로는 충분하지 않습니다.

4G QoS 아키텍처는 EPS Bearers를 기반으로 합니다. 서로 다른 베어러는 각자의 사용자 평면 전송 컨텍스트와 GTP-U 터널을 가지므로, 터널과 TEID를 통해 서로 다른 베어러 트래픽을 자연스럽게 구분할 수 있습니다.

5G에서는 QoS 모델이 PDU Session + QoS Flow로 바뀝니다. 하나의 PDU Session에는 하나 이상의 QoS Flow가 포함될 수 있고, 하나의 DRB도 하나 이상의 QoS Flow를 운반할 수 있습니다. 하지만 N3는 같은 PDU Session 안의 각 QoS Flow마다 별도의 GTP-U 터널을 만들지는 않습니다.

즉 TEID는 PDU Session과 연결된 GTP-U 터널을 식별할 수 있지만, 여러 QoS Flow가 여전히 같은 터널을 공유할 수 있습니다.

그러면 또 다른 질문이 생깁니다. 수신 노드는 개별 패킷이 어느 QoS Flow에 속하는지 어떻게 알 수 있을까요?

그 주요 이유 중 하나가 PDU Session Container 확장 헤더입니다. 5G는 이 GTP-U 확장 헤더를 사용해 PDU Session과 관련된 사용자 평면 정보를 전달하며, 여기에는 QFI, 즉 QoS Flow Identifier도 포함됩니다.

QFI는 QoS Flow를 식별하는 6비트 식별자입니다. 따라서 5G N3 트래픽을 분석할 때 TEID와 QFI는 서로 다른 두 수준의 식별자로 이해할 수 있습니다.

TEID는 GTP-U 터널 또는 PDU Session 컨텍스트를 식별하고, QFI는 그 터널 안에서 전달되는 특정 QoS Flow를 식별합니다.

다운링크 PDU Session Container에는 RQI와 PPI 같은 정보도 포함될 수 있습니다. RQI는 Reflective QoS 관련 시그널링에 사용되고, PPI는 Paging Policy Differentiation과 관련되어 동일한 PDU Session 안의 트래픽 유형별로 다른 페이징 처리를 지원할 수 있습니다.

GTP-U 기본 헤더의 E 비트는 뒤에 Extension Header가 이어지는지를 나타냅니다. 따라서 모든 GTP-U 패킷이 동일한 확장 헤더를 가지는 것은 아닙니다. PDU Session Container의 포함 여부는 해당 패킷과 수행되는 기능에 따라 달라집니다.

N3 사용자 패킷은 실제로 어떤 과정을 거칠까?

앞의 개념은 실제 업링크 패킷 흐름에 적용해 보면 훨씬 쉽게 이해할 수 있습니다.

UE가 온라인 동영상 서비스에 접속한다고 가정해 보겠습니다. UE는 먼저 애플리케이션 트래픽을 생성하고, 이 트래픽은 TCP 또는 UDP로 전달된 뒤 일반적인 IP 패킷 안에 들어갑니다. 이 내부 IP 헤더에서 출발지 주소는 UE에 할당된 IP 주소이고, 목적지 주소는 인터넷의 애플리케이션 서버 주소입니다.

패킷이 gNB에 도착하면 gNB는 UE의 IP 패킷을 UPF로 그대로 전달하지 않습니다. 대신 현재 PDU Session의 사용자 평면 컨텍스트를 기준으로 GTP-U 캡슐화를 적용합니다.

GTP-U 헤더에는 해당 TEID가 들어갑니다. 특정 QoS Flow를 식별해야 하는 패킷이라면 PDU Session Container에 QFI도 포함할 수 있습니다. 이후 gNB는 목적지 포트가 2152인 UDP 헤더를 추가하고, 그 다음 외부 IP 헤더를 추가합니다.

이 시점에서 외부 IP 주소는 더 이상 UE와 인터넷 사이의 통신을 나타내지 않습니다. 대신 gNB N3 인터페이스와 UPF N3 인터페이스 사이의 전송 관계를 나타냅니다.

패킷이 UPF에 도착하면 반대 과정이 수행됩니다. UPF는 외부 전송 정보를 기준으로 패킷을 받고, TEID를 읽어 올바른 사용자 평면 터널 컨텍스트를 찾습니다. 필요한 경우 QFI와 기타 확장 정보를 처리하고 GTP-U 캡슐화를 제거한 뒤 원래의 UE IP 패킷을 데이터 네트워크 방향으로 전달합니다.

Wireshark나 다른 패킷 분석 도구로 N3 트래픽을 점검할 때는 바깥쪽에서 안쪽으로 확인하는 방법이 유용합니다. 먼저 외부 gNB와 UPF의 IP 주소를 확인하고, 이어서 UDP 포트 2152, TEID, 존재할 경우 PDU Session Container와 QFI를 확인한 다음, 마지막으로 사용자의 내부 IP, TCP 또는 UDP, 애플리케이션 계층 트래픽을 살펴봅니다.

이 방법은 애플리케이션 패킷부터 분석하는 것보다 효과적인 경우가 많습니다. 많은 N3 장애가 사용자 애플리케이션 자체보다 터널 컨텍스트, TEID 또는 종단점 문제에서 발생하기 때문입니다.

GTP-U에는 왜 자체 관리 메시지가 필요할까?

GTP-U는 사용자 평면 프로토콜이지만 G-PDU 사용자 데이터 메시지에만 한정되지 않습니다. 사용자 평면 전송이 정상적으로 유지되도록 돕는 경로 관리 및 터널 관리 메시지도 정의합니다.

Echo Request와 Echo Response로 경로 가용성을 확인한다

Echo Request는 GTP Path와 상대 GTP 노드가 도달 가능하고 정상 동작하는지 확인하는 데 사용됩니다. 상대 노드는 Echo Response로 응답합니다.

이 메시지들은 두 GTP 종단점 사이의 기본 연결 상태를 확인합니다. gNB가 UPF로부터 Echo Response를 반복해서 받지 못한다면 문제는 더 이상 하나의 UE나 하나의 PDU Session에만 한정되지 않을 수 있으며, GTP Path 자체나 상대 노드의 문제를 의미할 수 있습니다.

GTP-U는 Supported Extension Headers Notification 메시지도 정의합니다. 이를 통해 노드는 자신이 지원하는 GTP 확장 헤더를 상대에게 알릴 수 있습니다. PDU Session Container와 같은 확장 헤더에 5G 사용자 평면 기능이 의존할 때 중요합니다.

Error Indication은 알 수 없는 TEID를 처리한다

GTP 종단점이 G-PDU를 수신했지만 받은 TEID에 대응하는 로컬 EPS Bearer 또는 PDU Session 컨텍스트를 찾지 못하고 TEID가 0이 아니라면, 상대에게 Error Indication을 보낼 수 있습니다.

이 메시지는 송신 노드가 수신 측에서 더 이상 인식하지 못하는 사용자 평면 터널로 데이터를 보내고 있다는 사실을 알려줍니다.

문제 해결 과정에서 Error Indication 메시지가 반복해서 나타난다면 먼저 양쪽 종단점의 TEID 상태가 일치하는지, PDU Session 업데이트나 이동성 절차 또는 사용자 평면 경로 변경으로 인해 양쪽 상태가 어긋나지 않았는지를 확인해야 합니다.

End Marker는 사용자 평면 경로 전환을 마무리한다

End Marker는 일반적으로 이동성과 사용자 평면 경로 전환과 관련됩니다. 이는 기존 GTP-U 경로에서 마지막 G-PDU가 전송됐으며 이후 사용자 트래픽은 더 이상 그 이전 경로를 따라가서는 안 된다는 뜻입니다.

예를 들어 UE가 소스 gNB에서 타깃 gNB로 이동하면 코어 네트워크의 사용자 평면 경로도 바뀔 수 있습니다. 트래픽이 계속 기존 경로를 따라가면 이전 경로와 새 경로가 겹쳐 패킷 순서 문제나 전달 문제를 일으킬 수 있습니다.

따라서 End Marker는 단순한 ‘터널 삭제’ 알림이 아닙니다. 기존 사용자 평면 경로의 경계 표시처럼 동작해 수신 측에 그 경로의 마지막 패킷이 이미 전달됐음을 알려줍니다.

이러한 메커니즘을 함께 보면 GTP-U의 역할이 훨씬 분명해집니다. GTP-U는 사용자 IP 패킷 앞에 TEID만 추가하는 프로토콜이 아닙니다. 네트워크 상태 변화에 따라 식별하고 감시하며 관리하고 갱신할 수 있는 완전한 사용자 평면 터널링 프레임워크를 제공합니다.

따라서 5G GTP-U의 실무적인 문제 해결 순서는 먼저 GTP 종단점과 Path가 정상인지 확인하고, 다음으로 TEID와 Tunnel 컨텍스트를 검증하며, 필요한 경우 PDU Session Container와 QFI를 확인한 뒤 마지막으로 원래 사용자 트래픽 쪽으로 안쪽을 분석하는 것입니다. 이동성 또는 경로 업데이트 중 문제가 발생한다면 Error Indication과 End Marker 메시지도 함께 살펴봐야 합니다.

이 순서로 분석하면 많은 UDP 2152 패킷이 보이는 N3 패킷 캡처를 계층별로 재구성 가능한 사용자 평면 전달 경로로 이해할 수 있습니다.

자주 묻는 질문

UDP 포트 2152의 모든 패킷이 사용자 트래픽을 운반할까?

아닙니다. G-PDU 메시지는 GTP-U와 UDP 포트 2152를 통해 사용자 평면 데이터를 운반하지만, Echo Request, Echo Response, Error Indication, End Marker, Supported Extension Headers Notification 같은 GTP-U 관리 메시지도 같은 프로토콜 체계를 사용합니다. 패킷이 실제로 무엇을 의미하는지 확인하려면 GTP-U Message Type을 확인해야 합니다.

TEID는 전체 5G 네트워크에서 전역적으로 유일해야 할까?

아닙니다. TEID를 네트워크 전체에서 전역적으로 유일한 식별자로 취급해서는 안 됩니다. GTP-U 터널 식별에는 터널 종단점, IP 주소, 전송 정보, 방향도 함께 영향을 줍니다. 따라서 문제 해결 시 TEID 값만 비교하지 말고 전체 터널 컨텍스트를 확인해야 합니다.

모든 5G GTP-U 패킷에 PDU Session Container가 포함될까?

아닙니다. PDU Session Container는 GTP-U 확장 헤더이며, 포함 여부는 패킷과 수행되는 기능에 따라 달라집니다. GTP-U 기본 헤더의 E 비트는 추가 Extension Header가 뒤따르는지 나타내므로 모든 N3 패킷이 동일한 헤더 구조를 갖는 것은 아닙니다.

End Marker는 전체 PDU Session이 해제됐다는 뜻일까?

반드시 그렇지는 않습니다. End Marker는 주로 특정 GTP-U 사용자 평면 경로의 트래픽이 끝났음을 나타내며, 이동성 이벤트 이후 경로 전환 과정에서 흔히 볼 수 있습니다. 이는 해당 경로의 트래픽 종료를 표시하는 것이지 전체 PDU Session 해제 절차를 의미하는 것은 아닙니다.