5G 네트워크에서 흔한 장애 상황은 처음에는 단순해 보입니다. UE 등록은 성공하고 PDU Session도 설정되며 IP 주소도 정상적으로 할당되지만, 웹 접속이 되지 않고 기본적인 Ping 트래픽조차 통과하지 않습니다. 패킷 캡처에서는 N3를 통해 트래픽이 UPF에 도착하는 것이 보이지만 예상 경로로 나가는 대응 패킷이 없을 수 있습니다. 문제 분석이 AMF 시그널링과 PDU Session 설정 결과에만 머무르면 실제 원인을 분리하기 어렵습니다.
PDU Session이 성공적으로 설정되었다고 해서 사용자 평면 전달 경로가 자동으로 동작하는 것은 아닙니다. UPF는 패킷을 수신한 뒤 먼저 PDR로 트래픽을 식별하고, 이어서 연결된 FAR(Forwarding Action Rule, 전달 동작 규칙) 을 적용해 다음 동작을 결정합니다. 즉, 패킷을 전달할지, 폐기할지, 버퍼링할지, 복제할지를 정합니다. FAR은 목적지 인터페이스와 외부 GTP-U 터널 헤더를 생성해야 하는지도 정의할 수 있습니다.
장애 분석 관점에서 이 구분은 중요합니다. PDR은 “이 패킷은 어떤 세션과 어떤 트래픽 흐름에 속하는가?”에 답하고, FAR은 “패킷을 식별한 뒤 UPF는 무엇을 해야 하는가?” 에 답합니다. 제어 평면 절차는 정상으로 보이지만 사용자 트래픽이 계속 실패한다면 N4 인터페이스의 FAR이 중요한 점검 지점이 됩니다.
왜 PDU Session 설정 성공만으로 사용자 평면 연결을 보장할 수 없을까?
PDU Session Establishment 절차가 완료되었다는 것은 필요한 제어 평면 세션 자원이 초기화되었다는 의미일 뿐입니다. 실제 애플리케이션 트래픽은 여전히 gNB, N3, UPF, N6로 구성된 전체 사용자 평면 경로에 의존합니다.
일반적인 Internet PDU Session에서 업링크 트래픽은 UE에서 gNB로 이동하고 GTP-U 터널로 캡슐화된 뒤 N3를 통해 UPF에 도달합니다. UPF는 적용되는 외부 터널 헤더를 제거하고 트래픽을 식별한 다음 원본 패킷을 데이터 네트워크 방향으로 전달해야 합니다. 다운링크에서는 반대로 트래픽이 N6에서 UPF로 들어오고, UPF가 대응하는 PDU Session을 식별한 뒤 gNB 사용자 평면 터널 정보를 얻고 필요한 GTP-U 외부 헤더를 추가하여 N3를 통해 gNB로 패킷을 전송합니다.
이 전달 동작은 PDU Session이 생성되었다는 이유만으로 자동 제공되지 않습니다. SMF는 N4를 통해 적절한 PFCP 규칙을 UPF에 프로비저닝해야 합니다. PDR은 일치하는 트래픽을 식별하고 FAR은 분류 후 적용할 전달 동작을 정의합니다. 올바른 사용자 평면 처리를 위해 두 규칙 유형이 모두 필요합니다.
모든 제어 평면 시그널링이 정상처럼 보이지만 서비스가 여전히 사용할 수 없다면 문제를 두 가지 핵심 질문으로 나눌 수 있습니다.
PDR이 현재 트래픽을 정확하게 식별하는가?
패킷 식별 후 연결된 FAR에 올바른 처리 및 전달 파라미터가 들어 있는가?
PDR과 FAR의 관계에 집중하는 것이 PDU Session 설정 절차 전체를 처음부터 반복해서 검토하는 것보다 더 효율적인 경우가 많습니다.
FAR은 실제로 UPF에 무엇을 하라고 지시할까?
FAR은 PFCP 프레임워크의 전달 규칙입니다. SMF가 N4를 통해 UPF에 프로비저닝하며, PDR이 참조하는 FAR ID를 통해 트래픽과 연결됩니다. 패킷이 해당 PDR과 일치하면 UPF는 참조된 FAR이 정의한 처리 동작을 실행합니다.
FAR에는 여러 Information Element가 포함될 수 있습니다. 사용자 평면 장애 분석에서는 다음 필드가 특히 중요합니다.
| FAR 파라미터 | 주요 기능 |
|---|---|
| FAR ID | FAR 인스턴스를 고유하게 식별하여 PDR이 올바른 전달 규칙을 참조할 수 있게 함 |
| Apply Action | 전달, 폐기, 버퍼링, 복제를 포함한 기본 패킷 동작을 정의 |
| Forwarding Parameters | 전달이 필요할 때 사용하는 목적지, Network Instance, 터널 캡슐화 및 기타 파라미터를 정의 |
| Duplicating Parameters | 트래픽 복제가 활성화된 경우 복제된 패킷 사본을 어떻게 전달할지 정의 |
| BAR ID | 패킷 버퍼링 동작을 제어하는 Buffering Action Rule을 참조 |
실제 운용에서는 Apply Action과 Forwarding Parameters가 가장 혼동되기 쉬운 두 요소입니다. Apply Action은 “어떤 동작을 수행해야 하는가?”에 답하고, Forwarding Parameters는 “패킷을 전달한다면 어떻게, 어디로 보내야 하는가?”
에 답합니다. Apply Action에서 FORW 플래그를 확인했다고 해서 다운링크 경로가 완성되었다는 뜻은 아닙니다. Destination Interface, Network Instance, Outer Header Creation 정보와 기타 관련 전달 파라미터도 정확해야 합니다.
Apply Action은 첫 번째 패킷 처리 단계를 어떻게 결정할까?
Apply Action은 UPF가 일치한 패킷에 적용할 기본 동작을 지시하는 비트 플래그 집합으로 표현됩니다. 이 플래그들은 단순히 상호 배타적인 선택지가 아니며 PFCP 세션과 서비스 시나리오의 맥락에서 해석해야 합니다.
DROP: 일치한 패킷을 폐기합니다.
FORW: 적용 가능한 Forwarding Parameters에 따라 패킷을 전달합니다.
BUFF: 패킷을 즉시 전달하지 않고 버퍼링합니다.
NOCP: 버퍼링이 필요한 다운링크 데이터가 도착했을 때 제어 평면에 알리기 위해 버퍼링 시나리오에서 사용합니다.
DUPL: 패킷의 별도 복제본을 만들고 Duplicating Parameters에 따라 그 복제본을 처리합니다.
왜 BUFF와 NOCP가 필요할까?
대표적인 경우는 UE가 idle 상태이고 즉시 사용할 수 있는 다운링크 사용자 평면 경로가 없을 때입니다. 다운링크 트래픽이 이미 UPF에 도착했더라도 아직 UE에 전달할 수 없을 수 있습니다. UPF는 패킷을 버퍼링하고, 필요한 경우 연결된 제어 평면 알림 동작을 사용해 페이징이나 사용자 평면 경로 복구 같은 후속 절차를 시작할 수 있습니다.
BUFF는 버퍼링이 필요하다는 것만 나타냅니다. 실제 버퍼링 처리 방식은 BAR과 연관되므로 장애 분석에서 BUFF 플래그만 봐서는 안 됩니다.
왜 DUPL은 단순히 “패킷을 한 번 더 전달하는 것”이 아닐까?
DUPL은 독립된 패킷 복제본을 만듭니다. 원본 패킷은 정상 처리 경로를 계속 따르고, 복제본은 Duplicating Parameters에 의해 별도로 제어됩니다. 복제본은 다른 Destination Interface, 외부 헤더 설정, Transport Level Marking 또는 Forwarding Policy를 사용할 수 있습니다.
따라서 미러링되거나 복제된 트래픽이 원래 서비스 트래픽과 같은 경로를 따른다고 자동으로 가정해서는 안 됩니다. 복제 파라미터를 별도로 확인해야 합니다.
Forwarding Parameters는 실제 패킷 목적지를 어떻게 결정할까?
Apply Action에 FORW가 포함되면 Forwarding Parameters가 실제 전달 경로를 결정합니다. 사용자 평면 장애를 분석할 때 특히 중요한 필드가 몇 가지 있습니다.
Destination Interface
Destination Interface는 처리 후 UPF가 패킷을 보내야 하는 논리 인터페이스를 정의합니다. 일반적인 다운링크 시나리오에서는 Access로 설정되며, 이는 패킷을 gNB 방향으로 전달한다는 뜻입니다. 업링크 트래픽은 일반적으로 Core 방향으로 전달됩니다.
Destination Interface가 잘못되면 찾기 어려운 장애가 생길 수 있습니다. PDR은 정상적으로 일치하지만 패킷이 잘못된 논리 인터페이스로 보내지고, 제어 평면에는 명확한 오류가 나타나지 않을 수 있습니다.
Network Instance
Network Instance는 전달에 사용하는 논리적 네트워크 컨텍스트를 식별합니다. 여러 DNN, 슬라이스 또는 데이터 네트워크를 사용하면서 트래픽 분리가 필요한 환경에서 특히 중요합니다.
N6 연결이나 사설 네트워크 서비스를 분석할 때 물리적 도달성만 확인해서는 충분하지 않습니다. FAR의 Network Instance도 대응하는 UPF 설정과 일치해야 합니다. 불일치가 있으면 트래픽이 예상된 네트워크 컨텍스트로 라우팅되지 않을 수 있습니다.
Outer Header Creation
Outer Header Creation은 N3 다운링크 전달의 핵심 파라미터 중 하나입니다. N6에서 UPF로 들어오는 패킷에는 원래 UE 페이로드가 포함되어 있습니다. 이 패킷을 N3를 통해 gNB로 보내기 전에 UPF는 필요한 GTP-U/UDP/IP 외부 캡슐화를 추가해야 합니다.
Outer Header Creation은 이 작업에 필요한 gNB 사용자 평면 주소, N3 터널 TEID, 외부 헤더 유형 정보를 제공합니다.
다운링크 트래픽이 UPF까지 도달하지만 N3에 대응 패킷이 나타나지 않는 많은 경우는 FAR의 이 부분에 정보가 누락되었거나 잘못된 데서 발생합니다. 예를 들어 잘못된 TEID 또는 gNB 주소가 원인일 수 있습니다.
기타 Forwarding Parameters
Forwarding Parameters에는 Redirect Information, Transport Level Marking, Forwarding Policy, Header Enrichment, Linked Traffic Endpoint ID, Proxying, Destination Interface Type 등 선택적 정보가 포함될 수도 있습니다.
Transport Level Marking은 전달 패킷에 필요한 DSCP 마킹을 적용하는 데 사용할 수 있습니다. Forwarding Policy는 UPF에 로컬로 설정된 전달 정책을 참조할 수 있습니다. Header Enrichment는 해당 서비스에서 추가 헤더 처리를 지원합니다. 모든 FAR이 이 Information Element를 전부 포함하는 것은 아니며 실제 내용은 PFCP 시그널링과 서비스 요구사항에 따라 달라집니다.
왜 세션 설정 후 다운링크 FAR이 갱신될 수 있을까?
초기 PDU Session Establishment 절차에서 SMF는 UPF에 첫 PDR과 FAR을 생성할 수 있습니다. 그러나 이 시점에 gNB가 다운링크 N3 사용자 평면 자원 할당을 아직 완료하지 않았을 수 있습니다. 따라서 최종 터널 TEID와 gNB 사용자 평면 주소가 SMF에 아직 제공되지 않을 수 있습니다.
gNB가 해당 자원을 할당하고 관련 N3 사용자 평면 정보가 SMF에 제공되면 SMF는 PFCP Session Modification 을 전송해 UPF의 기존 FAR을 필요한 다운링크 터널 파라미터로 갱신할 수 있습니다.
갱신된 다운링크 FAR에는 다음과 같은 핵심 전달 정보가 포함될 수 있습니다.
Destination Interface = Access, 액세스 방향으로 전달함을 의미;
적용되는 Network Instance;
Outer Header Creation = GTP-U/UDP/IPv4 또는 기타 적용 가능한 외부 헤더 유형;
gNB N3 사용자 평면 IP 주소와 할당된 터널 TEID.
따라서 장애 분석은 PFCP Session Establishment Request만 확인하고 끝내서는 안 됩니다. 초기 FAR에는 기본 전달 동작만 포함되고, 실제 N3 다운링크 터널을 구성하는 데 필요한 정보는 이후 PFCP Session Modification을 통해 추가될 수 있습니다.
이 후속 갱신을 분석에서 놓치면 정상적인 단계별 규칙 프로비저닝 과정을 FAR 설정 누락 또는 불완전으로 잘못 판단하기 쉽습니다.
FAR은 다운링크 트래픽을 N3 터널로 어떻게 다시 보낼까?
전체 다운링크 패킷 경로를 따라가면 FAR의 역할을 더 쉽게 이해할 수 있습니다.
외부 서버에서 온 패킷이 N6를 통해 UPF에 도착합니다. UPF는 PDR을 사용해 트래픽을 식별하고 올바른 PDU Session과 연결한 다음 해당 PDR이 참조하는 FAR을 읽습니다.
Apply Action에 FORW가 포함되어 있으면 UPF는 Forwarding Parameters를 평가합니다. Destination Interface가 Access로 설정되어 있으면 패킷을 무선 액세스 방향으로 보내야 한다는 의미입니다. Outer Header Creation에는 GTP-U 외부 헤더를 구성하는 데 필요한 gNB 터널 주소와 TEID가 들어 있습니다. 이후 UPF는 원본 패킷을 캡슐화하고 N3를 통해 gNB로 보냅니다.
전체 경로는 다음과 같이 요약할 수 있습니다.
다운링크 패킷이 N6에 도착 → PDR이 UE 트래픽을 식별 → FAR이 FORW 적용 → UPF가 gNB N3 터널 파라미터 획득 → UPF가 GTP-U 외부 헤더 생성 → 패킷을 N3를 통해 gNB로 전송.
이 과정은 FAR과 GTP-U의 차이도 보여 줍니다. GTP-U는 사용자 데이터를 운반하는 터널링 프로토콜이고 FAR은 UPF의 의사결정 규칙으로 외부 터널 헤더를 생성할지, 어떤 터널 정보를 사용할지, 어떤 논리 인터페이스로 패킷을 보낼지를 제어합니다.
N3 패킷 캡처에서 잘못된 TEID가 보이는 것은 따라서 겉으로 드러난 증상일 뿐입니다. 분석은 제어 평면으로 거슬러 올라가야 합니다. gNB가 올바른 사용자 평면 정보를 할당했는가? SMF가 그 정보를 정확히 받았는가? 이후 N4 갱신을 통해 적절한 FAR에 기록되었는가?
설정된 PDU Session에 데이터 연결이 없을 때 FAR을 어떻게 활용해 장애를 분석할까?
UE 등록이 정상이고 PDU Session도 설정되었지만 서비스가 계속 동작하지 않는다면 전체 등록 절차를 처음부터 반복하기보다 UPF의 실제 패킷 처리 순서에 따라 장애를 분석할 수 있습니다.
실용적인 FAR 점검 순서는 다음과 같습니다.
패킷이 UPF에 도달하는지 확인합니다. N3 또는 N6에 패킷이 도착하지 않는다면 문제는 FAR 이전 구간에 있으므로 UE, gNB 또는 전송 경로를 먼저 점검해야 합니다.
PDR이 패킷과 일치하는지 확인합니다. 관련 PDR이 먼저 패킷을 식별하지 않으면 FAR이 처리할 트래픽이 없습니다.
PDR이 참조하는 FAR ID를 확인합니다. 정상적으로 일치한 패킷이 잘못된 전달 규칙과 연결되지 않았는지 확인합니다.
Apply Action을 확인합니다. 설정 동작이 FORW, DROP, BUFF 또는 적용 가능한 플래그 조합인지 확인합니다.
Destination Interface와 Network Instance를 확인합니다. 패킷이 올바른 논리 방향과 네트워크 컨텍스트로 전송되는지 확인합니다.
Outer Header Creation을 확인합니다. N3 다운링크 트래픽의 경우 gNB 주소, TEID, 외부 헤더 유형을 확인합니다.
PFCP Session Modification 메시지를 확인합니다. 초기 Create FAR만 확인하지 말고 gNB 터널 정보가 이후 UPF에 갱신되었는지 확인합니다.
N3와 N6 패킷 캡처를 교차 확인합니다. PFCP 규칙이 예상하는 동작과 UPF가 실제 전송한 패킷을 비교합니다.
이 접근 방식의 가장 큰 장점은 제어 평면 규칙과 사용자 평면 패킷 캡처가 서로를 검증할 수 있다는 점입니다. PFCP 시그널링은 UPF가 패킷을 어떻게 전달 해야 하는지 보여 주고, N3와 N6 캡처는 UPF가 실제로 무엇을 했는지 보여 줍니다.
두 관점이 일치하지 않으면 장애 범위는 일반적으로 세 영역으로 좁힐 수 있습니다. 잘못된 N4 규칙 프로비저닝, 잘못된 UPF 규칙 실행 또는 사용자 평면 전송 경로 문제입니다. 명확한 방향 없이 전체 5G Core를 조사하는 것보다 훨씬 효율적입니다.
FAQ
FAR과 PDR의 가장 큰 차이는 무엇일까?
PDR은 패킷 탐지와 분류를 수행하며 패킷이 어떤 세션과 트래픽 흐름에 속하는지 판단합니다. FAR은 일치 후 어떤 처리를 할지, 패킷을 어떻게 처리하고 어디로 전달할지를 정의합니다. PDR은 FAR ID를 통해 해당 FAR을 참조합니다.
Apply Action에 FORW가 포함되어도 전달이 실패할 수 있는 이유는 무엇일까?
FORW는 전달을 수행해야 한다는 것만 나타냅니다. 성공적인 전달은 연결된 Forwarding Parameters에도 달려 있습니다. Destination Interface, Network Instance 또는 Outer Header Creation 정보가 잘못되면 패킷이 예상 목적지에 도달하지 못할 수 있습니다. 잘못된 N3 TEID나 gNB 사용자 평면 주소가 대표적인 예입니다.
첫 PFCP Session Establishment의 FAR에 완전한 N3 터널 정보가 없을 수 있는 이유는 무엇일까?
PDU Session 설정은 여러 단계로 진행됩니다. 초기 PFCP 세션이 만들어질 때 gNB가 최종 다운링크 N3 사용자 평면 자원을 아직 할당하지 않았을 수 있습니다. gNB 터널 주소와 TEID가 준비되면 SMF는 PFCP Session Modification으로 FAR을 갱신할 수 있습니다. 따라서 장애 분석에서는 초기 설정 메시지뿐 아니라 이후 N4 교환도 추적해야 합니다.
Outer Header Creation과 PDR Outer Header Removal은 어떤 관계일까?
두 기능은 터널 처리의 반대 방향에 적용됩니다. N3에서 들어오는 업링크 트래픽에는 Outer Header Removal을 사용해 해당 GTP-U 외부 헤더를 제거합니다. UPF에서 N3 방향으로 나가는 다운링크 트래픽에는 FAR의 Outer Header Creation이 새로운 GTP-U 외부 헤더를 만들기 위한 정보를 제공합니다. 두 기능을 통해 사용자 평면 터널의 양방향 캡슐화와 디캡슐화를 지원합니다.
N3의 TEID가 잘못되었다면 GTP-U만 집중해서 분석해야 할까?
아닙니다. N3 패킷 캡처는 현재 사용 중인 TEID가 잘못되었다는 사실만 보여 줍니다. 터널 정보는 gNB에서 생성되고 SMF에서 처리된 뒤 N4를 통해 FAR에 프로비저닝됩니다. 실제 원인을 찾으려면 gNB의 자원 할당, SMF가 받은 정보, PFCP Session Modification에서 수행된 FAR 갱신까지 추적해야 합니다.
