기술 Q&A: UE가 CM-IDLE 상태일 때 N4 인터페이스의 BAR은 하향링크 패킷 버퍼링과 데이터 통지를 어떻게 제어하는가?
UE가 CM-IDLE에 진입해도 PDU 세션은 사라지지 않습니다. 그러나 이전에 하향링크 전달에 사용되던 N3 사용자 평면 경로는 더 이상 활성화되지 않을 수 있습니다. 이 시점에 외부 네트워크에서 새로운 데이터가 도착하면 패킷은 여전히 UPF에 도달할 수 있지만, CM-CONNECTED 상태에서처럼 N3를 통해 gNB로 즉시 전달될 수는 없습니다. 따라서 UPF는 패킷을 버퍼링해야 하는지, 몇 개의 패킷을 보관할 수 있는지, 얼마나 오랫동안 버퍼링 상태를 유지할 수 있는지, 그리고 하향링크 데이터가 도착했음을 제어 평면에 언제 통지해야 하는지를 결정해야 합니다.
N4 인터페이스의 PFCP 규칙 프레임워크 내에서 BAR(Buffering Action Rule)이 이러한 버퍼링 동작에 대한 규칙을 제공합니다. 그러나 BAR이 버퍼링 수행 여부를 독립적으로 결정하지는 않습니다. 버퍼링 동작은 FAR의 Apply Action에 의해 트리거되며, BAR은 해당 버퍼링이 어떻게 수행되어야 하는지를 정의합니다. 이러한 구분은 FAR과 BAR 간의 관계를 이해하는 데 기본이 됩니다.
BAR은 UPF가 패킷을 버퍼링하는 방법을 정의한다
UPF가 패킷을 수신하면 먼저 PDR을 사용하여 트래픽을 식별한 다음, 해당 PDR이 참조하는 FAR에 따라 다음 동작을 결정합니다. FAR이 정상 전달을 요구하면 UPF는 전달 매개변수에 따라 패킷을 전달합니다. FAR의 Apply Action에 BUFF가 포함되어 있으면 패킷은 목적지 인터페이스로 즉시 전송되지 않고 버퍼링 프로세스에 들어갑니다.
여기서 BAR이 관련성을 갖게 됩니다. FAR은 영향을 받는 패킷을 어떻게 버퍼링해야 하는지 UPF에 알려주는 BAR을 참조할 수 있습니다. 이 관계는 다음과 같이 요약할 수 있습니다:
PDR이 패킷을 식별 → FAR이 BUFF/NOCP를 선택 → BAR이 버퍼링 동작을 정의.
흔한 오해는 BUFF와 BAR을 같은 것처럼 취급하는 것입니다. 그렇지 않습니다. BUFF는 "이 패킷을 지금 버퍼링해야 하는가?"라는 질문에 답합니다. BAR은 "버퍼링이 선택된 후, 어떤 조건에서 패킷을 버퍼링해야 하는가?"라는 질문에 답합니다. 관련 BAR이나 UPF의 로컬 버퍼링 설정을 확인하지 않고 FAR의 BUFF만 보는 것은 사용자 평면 동작의 일부만 파악하는 것입니다.
NOCP도 이 시나리오와 일반적으로 연관됩니다. UPF가 하향링크 패킷을 버퍼링할 때, NOCP는 UPF가 하향링크 데이터가 도착했음을 제어 평면에 통지하도록 요구할 수 있으며, 이를 통해 SMF가 다음 제어 평면 절차를 시작할 수 있습니다. 따라서 버퍼링과 통지는 두 가지 조정된 작업으로 발생합니다: 사용자 평면이 일시적으로 패킷을 보관하는 동안 이벤트가 제어 평면에 보고됩니다.

가장 전형적인 BAR 시나리오는 UE가 CM-IDLE에 진입한 후 발생한다
BAR의 역할은 UE가 CM-CONNECTED에서 CM-IDLE로 전환할 때 가장 이해하기 쉽습니다. UE가 이미 등록과 PDU 세션 설정을 완료했다고 가정합니다. 연결되어 있는 동안 N3 사용자 평면 경로가 사용 가능하고 UPF는 하향링크 패킷을 gNB로 직접 전달할 수 있습니다.
일정 기간 비활성 상태가 지나면 액세스 측에서 연결을 해제하고 UE는 CM-IDLE에 진입합니다. PDU 세션은 그대로 유지되지만, 이전에 활성화되었던 N3 사용자 평면 전달 경로는 더 이상 즉시 사용할 수 없습니다. 외부 서버는 이러한 상태 변화를 반드시 인지하지 못하므로, 새로운 하향링크 IP 패킷이 N6를 통해 UPF에 계속 도달할 수 있습니다.
이로 인해 핵심 문제가 발생합니다: UPF가 데이터를 수신했지만 현재 UE로 전달하는 데 사용할 수 있는 N3 경로가 없습니다.
이 단계에서 SMF는 N4를 통해 사용자 평면 규칙을 업데이트하여 관련 FAR이 즉시 전달에서 버퍼링 동작으로 변경되도록 합니다. 일반적인 경우 Apply Action에서 BUFF와 NOCP가 활성화되고, FORW는 더 이상 현재 하향링크 동작으로 사용되지 않습니다. 새로운 하향링크 패킷이 도착하면 UPF는 적용 가능한 버퍼링 정책에 따라 패킷을 보관하고 하향링크 데이터 도착을 SMF에 보고합니다.
통지를 수신한 후 SMF는 AMF와 협력하여 해당되는 경우 페이징을 포함하여 UE가 다시 도달 가능해지도록 필요한 절차를 시작할 수 있습니다. UE가 사용자 평면 트래픽을 전달할 수 있는 상태로 돌아가고 N3 경로가 복원되면 SMF는 UPF 규칙을 다시 업데이트하여 하향링크 처리가 버퍼링에서 전달로 전환됩니다. 버퍼링된 패킷은 그런 다음 UE로 계속 전달될 수 있습니다.
따라서 BAR은 단순한 정적 메모리 할당 규칙이 아닙니다. 진정한 목적은 하향링크 패킷이 이미 도착했지만 즉시 전달이 아직 불가능한 일시적 기간을 사용자 평면이 연결하도록 돕는 것입니다.
주요 BAR 매개변수가 버퍼링의 경계를 정의한다
버퍼링은 무기한 계속될 수 없습니다. 도달 불가능한 UE를 위해 UPF가 무제한의 하향링크 데이터를 보관하도록 허용하면 사용자 평면 메모리가 불필요하게 소모될 수 있습니다. 따라서 BAR은 버퍼링 동작에 경계를 제공합니다. PFCP 절차와 UPF 기능에 따라 여기에는 BAR ID, 패킷 수 제한, 버퍼링 지속 시간, 통지 지연 매개변수가 포함될 수 있습니다.
BAR ID
BAR ID는 PFCP 세션 내에서 버퍼링 규칙을 고유하게 식별하며, 관련 FAR이 올바른 BAR을 참조할 수 있도록 합니다. 문제 해결 중에 Create BAR만 보이는 것은 해당 규칙이 분석 중인 트래픽에 영향을 미친다는 것을 증명하지 못합니다. 해당 FAR도 확인하여 실제로 어떤 BAR ID를 참조하는지 확인해야 합니다.
권장 버퍼링 패킷 수
권장 버퍼링 패킷 수는 적용 가능한 트래픽에 대해 UPF가 버퍼링하도록 권고되는 패킷 수를 나타냅니다. 권장 제한을 초과하면 추가 패킷은 폐기될 수 있습니다. 이 매개변수는 버퍼링 시간이 아닌 버퍼링 용량 경계를 제어합니다.
이 필드의 표시 여부는 UPF 기능 지원에 따라 달라집니다. PFCP 트레이스에 필드가 보이지 않는다고 해서 그것만으로 버퍼링 제어가 누락되었음을 증명하지는 않습니다. 분석에서는 UPF가 관련 기능을 지원하는지, 그리고 대신 로컬 버퍼링 매개변수가 사용되고 있는지도 고려해야 합니다.
DL 버퍼링 지속 시간
DL 버퍼링 지속 시간은 적용 가능한 절차에 따라 하향링크 패킷이 UPF에 계속 버퍼링될 수 있는 기간을 정의합니다. 이는 중요한 설계 원칙을 반영합니다: 버퍼링은 사용자 평면 전달이 복원되는 동안의 일시적 메커니즘으로 의도된 것이며, 영구적인 패킷 저장이 아닙니다.
UE가 장기간 도달 불가능한 상태로 남아 있으면 버퍼링 프로세스에는 정의된 종료 조건이 필요합니다. 그렇지 않으면 사용자 평면 리소스가 무기한 점유될 수 있습니다.
하향링크 데이터 통지 지연
지원되는 절차와 기능 조합에서 하향링크 데이터 통지 지연은 UPF가 첫 번째 하향링크 패킷을 수신한 후 제어 평면에 통지하기 전에 대기하는 시간을 제어할 수 있습니다. 이 매개변수는 패킷을 버퍼링해야 하는지 여부가 아니라 통지가 언제 전송되는지에 영향을 미칩니다.
따라서 그 동작은 매개변수 이름만으로 추론하기보다는 특정 PFCP 절차, 네트워크 구현, UPF 기능의 맥락에서 해석되어야 합니다.

PFCP 트레이스에서 완전한 BAR 매개변수가 누락되는 경우가 있는 이유는 무엇인가?
이는 BAR을 분석할 때 가장 오해하기 쉬운 지점 중 하나입니다. 버퍼링할 패킷 수, 버퍼링 지속 시간 및 기타 버퍼링 매개변수가 항상 N4를 통해 동적으로 프로비저닝되어야 하는 것은 아닙니다. 운영자나 장비 공급업체는 UPF에 로컬로 버퍼링 정책을 구성할 수도 있습니다.
이러한 구현에서는 SMF가 FAR 동작만 동적으로 변경하면 될 수 있습니다. 예를 들어, UE가 CM-IDLE에 진입한 후 SMF는 PFCP 세션 수정을 사용하여 관련 FAR을 BUFF/NOCP로 업데이트할 수 있습니다. UPF가 버퍼링 동작을 확인하면 로컬로 구성된 패킷 수 및 지속 시간 제한을 적용할 수 있습니다.
따라서 트레이스에서 다음과 같은 관찰이 자동으로 비정상인 것은 아닙니다:
FAR이 BUFF를 요청하지만 PFCP 메시지에 엔지니어가 기대하는 완전한 BAR 매개변수가 포함되어 있지 않다.
최소한 두 가지 추가 질문을 확인해야 합니다: UPF가 로컬로 구성된 버퍼링 값을 사용하고 있는지, 그리고 UPF가 관련 BAR 매개변수의 동적 프로비저닝을 지원하는지 여부입니다. 그렇지 않으면 구현 차이가 SMF의 누락된 규칙으로 오인될 수 있습니다.
로컬 구성은 실용적인 이점도 있을 수 있습니다. 일부 N4 시그널링을 줄이고 UPF 구현 간의 기능 차이를 수용할 수 있습니다. 절충점은 버퍼링 동작의 일부가 단일 PFCP 트레이스에서 더 이상 완전히 보이지 않으므로, 멀티벤더 문제 해결에는 시그널링 분석과 UPF의 로컬 구성 검사가 모두 필요할 수 있다는 것입니다.
CM-IDLE에서 하향링크 데이터가 도착할 때 PFCP 흐름은 어떻게 이해해야 하는가?
BAR은 분리된 정보 요소로 분석하기보다는 전체 절차 안에 다시 배치할 때 이해하기 쉽습니다.
UE가 CM-CONNECTED 상태에 있는 동안 N3 경로가 사용 가능하고 UPF는 정상적인 FAR에 따라 하향링크 패킷을 전달합니다. 일정 기간 비활성 상태가 지나면 액세스 측 연결이 해제됩니다. SMF가 사용자 평면 연결 상태가 변경되었음을 알게 되면 PFCP 세션 수정을 사용하여 관련 UPF 규칙을 업데이트합니다.
중요한 점은 PDU 세션이 삭제되지 않았다는 것입니다. 대신 현재 하향링크 사용자 평면 경로가 즉시 전달을 위해 일시적으로 사용 불가능한 상태입니다. 따라서 관련 FAR은 BUFF와 필요한 제어 평면 통지 동작을 활성화하여 버퍼링 동작으로 전환할 수 있으며, BAR 또는 로컬 UPF 구성이 자세한 버퍼링 조건을 제공합니다.
이후 인터넷 서버나 애플리케이션이 새로운 하향링크 데이터를 전송하면 패킷이 먼저 UPF에 도착합니다. UPF는 PDR을 사용하여 트래픽을 식별한 다음 연결된 FAR을 적용합니다. 현재 동작이 더 이상 FORW가 아니므로 패킷이 버퍼링됩니다. 동시에 UPF는 PFCP 보고 메커니즘을 통해 하향링크 데이터 도착을 SMF에 보고합니다.
그런 다음 SMF는 AMF 측 절차와 협력하여 UE가 다시 도달 가능해지고 사용자 평면 경로가 재설정될 수 있도록 합니다. N3 전달이 다시 사용 가능해지면 N4의 FAR이 정상 전달로 다시 업데이트되고 UPF는 하향링크 트래픽을 UE로 계속 전달할 수 있습니다.
전체 논리는 다음과 같이 요약할 수 있습니다:
UE가 CM-IDLE 진입 → N3 일시적 사용 불가 → SMF가 FAR/BAR 업데이트 → 하향링크 데이터가 UPF에 도달 → UPF가 버퍼링 및 보고 → 제어 평면이 UE 도달 가능성 복원 → N3 복원 → FAR이 전달로 복귀.
따라서 BAR은 데이터가 이미 도착했지만 전달 경로가 아직 복귀하지 않은 기간 동안 사용자 평면 동작을 제어합니다.

BAR 문제 해결은 동작, 버퍼링, 통지, 복구의 4단계를 따라야 한다
BAR 관련 문제는 명시적인 "BAR 오류"로 나타나는 경우가 거의 없습니다. 더 자주 증상은 UE가 유휴 상태에 진입한 후 첫 번째 하향링크 트래픽이 비정상적으로 동작하는 것입니다. 애플리케이션이 활성 상태에서는 정상적으로 작동하지만, 비활성 기간 후 다음 메시지가 눈에 띄는 지연과 함께 도착할 수 있습니다. 다른 경우에는 UE가 성공적으로 페이징되고 재연결되었지만 처음 몇 개의 하향링크 패킷이 이미 손실된 경우도 있습니다.
이러한 문제는 네 단계로 분석할 수 있습니다.
1단계: FAR이 실제로 버퍼링 모드에 진입했는지 확인
관련 하향링크 PDR이 참조하는 FAR부터 시작하여 UE가 CM-IDLE에 진입한 후 예상되는 PFCP 세션 수정이 발생했는지 확인합니다. Apply Action이 정상적인 FORW 동작에서 시나리오에 기대되는 BUFF 및 통지 동작으로 변경되었는지 확인합니다.
FAR이 더 이상 사용할 수 없는 사용자 평면 경로로 패킷을 전달하려고 계속 시도한다면, 문제는 주로 BAR 문제가 아닙니다.
2단계: UPF가 적용 중인 버퍼링 규칙 확인
FAR이 참조하는 BAR ID를 확인한 다음 해당 Create BAR 또는 Update BAR 매개변수를 검사합니다. PFCP 트레이스에 완전한 버퍼링 매개변수가 포함되어 있지 않으면 UPF의 로컬 버퍼링 구성과 지원되는 기능을 계속 확인합니다.
패킷 수 제한이 너무 작으면 UE가 다시 도달 가능해지기 전에 첫 번째 하향링크 패킷 중 일부가 폐기될 수 있습니다. 관찰된 버퍼링 동작이 기대와 크게 다르면 BAR 연관 자체도 검증해야 합니다.
3단계: UPF가 하향링크 데이터 도착을 보고했는지 확인
패킷을 버퍼링하는 것만으로는 UE와의 통신이 복원되지 않습니다. 제어 평면이 새로운 하향링크 데이터가 도착했음을 인지하지 못하면 후속 페이징 또는 사용자 평면 복구 절차가 시작되지 않습니다. 따라서 트레이스에서 적절한 PFCP 세션 보고와 SMF의 올바른 처리를 확인해야 합니다.
패킷이 이미 UPF에 버퍼링되어 있지만 제어 평면 절차가 뒤따르지 않으면 문제 해결은 BAR 매개변수에서 UPF-SMF 보고 경로와 후속 SMF 절차로 이동해야 합니다.
4단계: 사용자 평면 복구 후 전달이 재개되는지 확인
UE가 다시 도달 가능해진 후 SMF가 N4 규칙을 올바르게 업데이트하여 하향링크 FAR이 버퍼링에서 정상 전달로 전환되고 필요한 N3 전달 매개변수가 복원되는지 확인합니다.
페이징이 성공하고 UE가 복귀했지만 FAR이 BUFF에 남아 있으면 시스템은 UE가 도달 가능한 상태인데도 패킷이 UPF에 계속 남아 있는 상태에 들어갈 수 있습니다. 따라서 BAR 문제 해결은 사용자 평면 전달 경로가 완전히 복원될 때까지 계속되어야 합니다.
BAR의 핵심 가치
PFCP 규칙 프레임워크 내에서 BAR은 PDR과 FAR처럼 정상적으로 전달되는 모든 패킷에 동일한 방식으로 참여하지 않습니다. 그 중요성은 특정하지만 중요한 상황에서 가장 두드러집니다: 세션은 여전히 존재하지만 현재 사용자 평면 경로가 새로 도착한 하향링크 데이터를 즉시 전달할 수 없는 경우.
FAR이 패킷 처리 동작을 FORW에서 BUFF로 변경하고, BAR이 버퍼링 경계를 정의하며, UPF가 일시적으로 패킷을 보관하고 도착을 보고하며, SMF와 AMF 같은 제어 평면 기능이 UE 도달 가능성 복원을 조정합니다. 이러한 메커니즘이 함께 일시적 전달 불가능에서 활성 사용자 평면 경로로의 전환을 연결합니다.
따라서 BAR은 "Buffering Action Rule = 패킷 버퍼링 규칙"으로만 이해해서는 안 됩니다. 더 유용한 해석은: BAR은 사용자 평면 전달 경로가 일시적으로 사용 불가능한 동안 이미 도착한 하향링크 패킷을 어떻게 관리할지 UPF에 알려줍니다. BAR을 CM-IDLE, FAR BUFF/NOCP, PFCP 세션 보고, 후속 페이징 및 사용자 평면 복구 절차와 함께 보면 N4 인터페이스에서의 역할이 훨씬 더 명확해집니다.
자주 묻는 질문
FAR에서 BAR과 BUFF의 차이점은 무엇인가?
BUFF는 FAR의 Apply Action으로, 일치하는 패킷을 즉시 전달하는 대신 버퍼링해야 함을 나타냅니다. BAR은 패킷 수 제한, 버퍼링 지속 시간 또는 기타 적용 가능한 조건과 같이 해당 버퍼링이 어떻게 수행되어야 하는지를 정의합니다. 간단히 말해 FAR은 버퍼링이 필요하다는 것을 결정하고, BAR은 버퍼링이 어떻게 수행되는지를 정의합니다.
BAR은 FAR과 독립적으로 동작할 수 있는가?
BAR을 독립적인 패킷 매칭 규칙으로 취급해서는 안 됩니다. 패킷은 먼저 PDR에 의해 매칭되고, PDR은 관련 FAR을 참조합니다. 해당 FAR이 버퍼링을 요구하고 적용 가능한 BAR을 참조하면 BAR 매개변수가 해당 패킷의 버퍼링 방식을 제어하는 데 사용됩니다.
UE가 CM-IDLE에 진입할 때 하향링크 패킷이 단순히 폐기되지 않는 이유는 무엇인가?
CM-IDLE은 PDU 세션이 삭제되었음을 의미하지 않습니다. 외부 애플리케이션은 사용자 평면 전달 경로가 일시적으로만 사용 불가능한 동안 데이터를 계속 전송할 수 있습니다. 단기 버퍼링은 제어 평면이 UE 도달 가능성을 복원하는 동안 하향링크 트래픽의 일부를 보관할 수 있게 하여 애플리케이션 연속성 중단을 줄이는 데 도움이 됩니다.
권장 버퍼링 패킷 수가 없다는 것이 BAR이 잘못 구성되었음을 의미하는가?
반드시 그렇지는 않습니다. 이 매개변수의 표시 여부는 PFCP 절차, UPF 기능 및 구현에 따라 다릅니다. 패킷 수 제한 및 기타 버퍼링 동작은 UPF에 로컬로 구성될 수도 있으므로 기능 지원, BAR 연관 및 장치 측 버퍼링 구성을 확인해야 합니다.
UPF가 하향링크 패킷을 버퍼링했는데도 UE가 여전히 데이터를 수신하지 못하는 이유는 무엇인가?
버퍼링은 절차의 일부일 뿐입니다. UPF는 하향링크 데이터 도착을 SMF에 보고해야 하고, 제어 평면은 UE 도달 가능성을 복원하는 데 필요한 절차를 시작해야 하며, SMF는 사용자 평면 경로가 다시 사용 가능해지면 FAR과 N3 전달 매개변수를 업데이트해야 합니다. 이러한 단계 중 하나라도 실패하면 패킷이 버퍼링된 상태로 남거나 결국 폐기될 수 있습니다.