5G Core 사용자 평면을 트러블슈팅할 때 자주 나타나는 문제가 있습니다. UE는 정상적으로 등록되고 PDU Session도 설정되었으며, PDR은 트래픽을 올바르게 식별하고 FAR도 예상 경로로 패킷을 전달하지만 SMF에서 보이는 사용량 카운터는 변하지 않는 경우입니다. 과금 이벤트가 발생하지 않거나 할당량 제어가 예상한 시점에 반응하지 않을 수도 있습니다. 많은 경우 패킷 전달 자체는 정상입니다. 빠져 있는 것은 UPF에 사용자 평면 사용량을 어떻게 측정하고 그 결과를 언제 제어 평면으로 보고해야 하는지를 알려주는 메커니즘입니다. 그 메커니즘이 N4 인터페이스의 URR(Usage Reporting Rule)입니다.

URR은 패킷을 어디로 전달할지 결정하지 않으며 대역폭 제한을 직접 적용하지도 않습니다. 대신 UPF에 일치한 어떤 트래픽을 측정할지, 그 사용량을 어떻게 측정할지, 그리고 어떤 조건에서 측정 결과를 제어 평면으로 보고할지를 알려줍니다. 따라서 URR은 사용자 평면 트래픽을 단순히 전달되는 대상에서 측정 가능한 대상으로 바꿉니다. 실제 측정은 UPF가 수행하고, SMF는 PFCP를 통해 보고 조건을 설정하며, 생성된 Usage Report는 사용자 평면과 제어 평면 사이에 지속적인 피드백 루프를 형성합니다.

N4 규칙 프레임워크에서 URR은 어떤 문제를 해결하는가?

URR을 가장 쉽게 이해하는 방법은 PDR, FAR, QER과 역할을 구분하는 것입니다. UPF가 패킷을 수신하면 PDR이 먼저 해당 패킷이 어떤 트래픽에 속하는지 판단합니다. 분류가 끝나면 FAR이 패킷을 어떻게 처리하고 어디로 전달할지 결정합니다. QER은 필요한 QoS 처리를 적용합니다. URR은 다른 질문, 즉 이 트래픽이 실제로 얼마나 사용되었는가?에 답합니다.

주요 PFCP 규칙 유형은 다음과 같이 정리할 수 있습니다.

PDR: 이것은 어떤 트래픽인가?
FAR: 패킷을 어떻게 처리하고 어디로 전달해야 하는가?
QER: 이 트래픽에 어떤 QoS 처리를 적용해야 하는가?
URR: 이 트래픽이 얼마나 사용되었으며, 그 사용량을 언제 보고해야 하는가?

URR은 관련 PDR과 연결되어야 합니다. 이유는 간단합니다. 어떤 패킷이 해당 UE, 서비스 또는 트래픽 플로우에 속하는지 먼저 알지 못하면 UPF는 “사용자가 얼마나 사용했는가”를 의미 있게 측정할 수 없습니다. PDR이 트래픽을 식별하면 연결된 URR이 일치한 패킷의 사용량을 측정할 수 있습니다. 하나의 PDU Session에 여러 PDR이 있다면 서로 다른 URR을 사용해 더 세밀한 사용량 측정 관계를 구성할 수도 있습니다.

따라서 URR 트러블슈팅에서 첫 질문은 보통 “URR이 설정되었는가?”가 아니라 “측정 중인 트래픽과 일치하는 PDR은 무엇이며, 그 PDR이 참조하는 URR ID는 무엇인가?”입니다. 이 연결이 없거나 잘못되면 이후 측정과 보고 단계가 예상대로 동작할 수 없습니다.

URR은 UPF가 무엇을 측정할지 어떻게 정의하는가?

URR은 단순한 트래픽 카운터보다 훨씬 많은 정보를 담습니다. Create URR에서 먼저 정의되는 요소 중 하나가 Measurement Method이며, UPF에 어떤 종류의 사용량을 측정해야 하는지 알려줍니다. 서비스 요구사항에 따라 트래픽 볼륨, 시간 또는 이벤트를 기준으로 측정할 수 있습니다.

일반적인 패킷 데이터 서비스에서는 볼륨 기반 측정이 가장 관찰하기 쉽습니다. UPF는 업링크, 다운링크, 전체 트래픽 볼륨을 측정할 수 있고, Volume Measurement의 관련 필드는 어떤 통계를 포함할지 나타냅니다. 트래픽 볼륨은 바이트 단위로 누적되므로 URR은 설정에 따라 전체 사용량을 측정하거나 UL과 DL 트래픽을 구분할 수 있습니다.

필요한 기능이 활성화되어 있다면 패킷 수도 측정에 포함할 수 있습니다. 예를 들어 Measurement Information의 MNOP 플래그는 UPF가 업링크, 다운링크, 전체 패킷 수를 측정하도록 요청할 수 있습니다. 이 경우 운영자는 전송된 바이트 수뿐 아니라 측정 구간 동안 처리된 패킷 수도 확인할 수 있습니다.

시간 기반 측정은 서비스 지속 시간에 초점을 둡니다. 설정에 따라 Time Threshold, Time Quota, Inactivity Detection Time, 적용되는 시간 측정 메커니즘 등의 파라미터를 사용할 수 있습니다. 이벤트 기반 측정은 특정 서비스 이벤트를 세고, 정의된 이벤트 수에 도달했을 때 보고할 수 있습니다.

따라서 Measurement Method는 URR의 가장 기본적인 질문인 “이 규칙에서 ‘사용량’은 무엇을 의미하는가?”에 답합니다. 이를 먼저 명확히 하지 않으면 PFCP 메시지를 분석할 때 Threshold, Quota, Reporting Trigger를 혼동하기 쉽습니다. 선택한 측정 방식은 UPF가 유지하는 카운터 유형, Usage Report 형식, 그리고 SMF가 결과를 해석하는 방식에 직접 영향을 줍니다.

Reporting Trigger가 UPF가 보고해야 하는 시점을 결정한다

측정 방식만으로는 충분하지 않습니다. 아무 보고 조건 없이 UPF가 카운터를 계속 누적하기만 하면 SMF가 결과를 받아야 할 시점이 정해지지 않습니다. 그래서 Reporting Trigger도 URR 메커니즘의 핵심 요소입니다.

이 트리거들은 네트워크 정책에 따라 조합할 수 있습니다. PERIO는 주기 보고에 사용할 수 있습니다. VOLTH는 볼륨 임계값에 도달하면 보고를 생성해야 함을 나타냅니다. TIMTH는 시간 임계값에 적용됩니다. START와 STOPT는 UPF가 트래픽 시작 또는 종료를 감지할 때 Usage Report를 트리거할 수 있습니다.

또 다른 트리거 그룹은 할당량 제어와 더 밀접합니다. VOLQU는 볼륨 할당량 조건, TIMQU는 시간 할당량 조건, EVEQU는 이벤트 할당량 조건과 관련됩니다. 할당량이 부여되었지만 가입자가 일정 시간 동안 사용자 평면 트래픽을 생성하지 않을 때는 Quota Holding Time도 사용할 수 있습니다.

특히 Threshold와 Quota를 구분하는 것이 중요합니다. 두 값은 PFCP에서 목적이 다르며 트레이스 분석 중 자주 혼동되기 때문입니다.

Threshold는 주로 측정 결과를 언제 보고해야 하는가에 관한 값이고, Quota는 사용 가능한 리소스가 얼마나 남아 있는가에 더 가깝습니다. PFCP 트레이스에서 VOLTH 또는 VOLQU가 설정된 것만 확인하고 엔지니어가 대응하는 Threshold나 Quota 파라미터를 살펴보지 않으면 실제 서비스 로직을 오해하기 쉽습니다.

예를 들어 VOLTH가 설정되어 있어도 대응하는 Volume Threshold가 올바르게 정의되지 않았다면 UPF에는 예상 보고를 트리거할 의미 있는 트래픽 경계가 없습니다.

UPF는 사용량 결과를 SMF에 어떻게 보내는가?

URR 메커니즘은 PFCP Session Report 절차를 통해 완전한 피드백 루프를 구성합니다. URR이 정의한 보고 조건이 충족되면 UPF는 SMF가 카운터를 조회할 때까지 기다릴 필요가 없으며, SMF로 PFCP Session Report Request를 보낼 수 있습니다.

Report Type이 메시지에 Usage Report가 포함되어 있음을 나타내면 SMF는 해당 이벤트를 사용자 사용량 보고로 식별할 수 있습니다. 분석에서 몇 가지 필드가 특히 중요합니다. URR ID는 어떤 규칙이 보고를 생성했는지 식별하고, UR-SEQN은 해당 URR의 Usage Report 순번을 식별합니다. Usage Report Trigger는 보고가 생성된 이유를 설명합니다.

실제 측정값은 Measurement Method에 대응하는 필드에 나타납니다. 볼륨 기반 측정에서는 Volume Measurement에 전체, 업링크, 다운링크 사용량 값이 포함될 수 있습니다. 시간 기반 측정에서는 Duration Measurement가 더 중요합니다. Start Time, End Time, Time of First Packet, Time of Last Packet 같은 필드는 보고가 포함하는 정확한 측정 구간을 판단하는 데도 도움이 됩니다.

Usage Report를 수신했다고 해서 반드시 절차가 끝나는 것은 아닙니다. 서비스 로직에 따라 SMF는 PFCP Session Modification을 보내 URR을 업데이트할 수 있습니다. 예를 들어 보고 임계값을 변경하고, 새 할당량을 부여하거나, 다음 보고 조건을 수정할 수 있습니다.

전체 URR 흐름은 다음과 같이 요약할 수 있습니다.

SMF가 URR 설정 → UPF가 일치한 트래픽 측정 → Reporting Trigger 조건 충족 → UPF가 Usage Report 전송 → SMF가 사용량 결과 처리 → 필요 시 URR 업데이트.

따라서 사용량 보고는 UPF가 단순히 카운터 값을 올리는 작업이 아닙니다. 제어 평면이 측정 정책을 정의하고, 사용자 평면이 측정을 수행하며, 결과가 지속적으로 제어 평면으로 피드백되는 동적 과정입니다. 어느 단계에서든 문제가 생기면 사용량 값이 부정확해지거나 보고가 누락될 수 있습니다.

Volume Threshold는 실제 Usage Report를 어떻게 트리거하는가?

구체적인 트래픽 상황에 대입하면 URR 로직을 더 쉽게 이해할 수 있습니다. SMF가 PFCP Session Establishment 중 URR을 만들고, 특정 PDR이 일치시킨 트래픽에 대해 볼륨 기반 측정을 사용하도록 UPF에 지시한다고 가정합니다. Reporting Trigger로 VOLTH를 활성화합니다.

Volume Threshold가 TOVOL 10240바이트로 설정되어 있다고 해서 사용자가 최대 10240바이트만 사용할 수 있다는 뜻은 아닙니다. 의미는 다음과 같습니다. 측정된 업링크와 다운링크의 총 볼륨이 이 임계값에 도달하면 UPF가 Usage Report를 생성해야 한다.

UE가 트래픽을 생성하기 시작하면 UPF는 패킷을 정상적으로 전달하면서 URR에 정의된 사용량 카운터도 누적합니다. 누적 볼륨이 보고 임계값에 도달하면 UPF는 PFCP Session Report Request를 보냅니다. Usage Report는 VOLTH를 트리거 이유로 식별하고, Volume Measurement에는 실제 전체 사용량과 해당 업링크·다운링크 값이 포함됩니다.

최종 보고값이 정확히 10240바이트에서 멈출 필요는 없습니다. UPF는 실제 패킷을 처리하면서 임계값을 평가하며, 하나의 완전한 패킷 때문에 누적 사용량이 임계값 아래에서 바로 위로 넘어갈 수 있습니다. 따라서 Usage Report 값이 설정된 Threshold보다 약간 높아도 모순이 아닙니다.

URR 동작을 분석할 때 여기서 중요한 원칙을 얻을 수 있습니다. Threshold는 보고 경계이지 측정값을 정확한 숫자로 잘라내는 메커니즘이 아닙니다. 동시에 Quota가 설정되어 있다면 할당량 소진이 추가 제어 동작을 트리거할 수 있지만, 이는 단순 임계값 기반 보고와 혼동하지 말고 별도의 제어 경로로 분석해야 합니다.

URR 트러블슈팅은 연결, 측정, 트리거, 보고의 네 단계로 진행해야 한다

URR 문제는 사용자 평면 서비스 자체가 완전히 정상으로 보일 수 있어 알아차리기 어렵습니다. UE는 네트워크에 접속하고 PDR도 올바르게 일치하며 FAR도 패킷을 계속 전달하지만, 백엔드에 보이는 사용량 카운터가 틀리거나 Usage Report가 생성되지 않거나, 임계값 도달 뒤 예상한 제어 평면 이벤트가 발생하지 않을 수 있습니다.

따라서 URR 트러블슈팅은 “사용자가 네트워크에 접속할 수 있는가?”라는 질문으로 시작해서는 안 됩니다. 전체 사용량 측정 체인을 따라가야 합니다.

먼저 PDR과 URR의 연결을 확인한다

실제로 트래픽과 일치하는 PDR을 찾은 다음 연결된 URR ID를 확인합니다. 하나의 PFCP Session에는 여러 PDR과 여러 URR이 있을 수 있습니다. 잘못된 URR을 분석하면 그 URR의 모든 파라미터가 올바르게 보여도 현재 사용량 결과를 설명할 수 없습니다.

일반적인 문제는 PDR의 매칭 조건이 바뀌었는데도 URR이 이전 PDR ID에 계속 연결되어 있는 경우입니다. 이 경우 측정 대상 자체가 실제 트래픽에서 벗어나 있습니다.

다음으로 Measurement Method와 방향을 확인한다

URR이 Volume, Duration, Event 중 어떤 측정으로 설정되어 있는지 확인합니다. 볼륨 기반 측정을 사용한다면 Total, UL, DL 또는 패킷 수도 측정하는지 확인합니다.

업링크와 다운링크 통계가 예상과 맞지 않을 때 이 단계는 특히 중요합니다. 겉보기에는 오류처럼 보여도 URR은 한 방향만 측정하고 테스트 트래픽은 반대 방향으로 흐르기 때문에 기대한 카운터가 변하지 않는 경우가 있습니다.

Reporting Trigger와 대응하는 Threshold를 확인한다

UPF가 보고를 생성하지 않으면 제어 평면이 실제로 어떤 트리거를 요청했는지 확인합니다. 적절한 Volume Threshold 없이 VOLTH를 설정하거나, PERIO가 활성화되지 않았는데 주기 보고를 기대하면 의도한 서비스 동작과 다른 결과가 나올 수 있습니다.

마찬가지로 시간 기반 보고도 하나의 트리거 플래그만 따로 보지 말고 관련 시간 측정 파라미터와 모니터링 조건을 함께 해석해야 합니다.

마지막으로 PFCP Session Report를 추적한다

트리거 조건이 충족되면 UPF가 예상한 Usage Report를 보내는지 확인합니다. 현재 PFCP Session과 대조해 Report Type, URR ID, UR-SEQN, Usage Report Trigger를 확인합니다.

UPF가 이미 보고를 생성했지만 새로운 할당량, 임계값 또는 후속 제어 동작이 나타나지 않는다면 UPF 카운터에 계속 집중하기보다 SMF와 이후 제어 평면 로직으로 트러블슈팅 범위를 옮겨야 합니다.

문제가 QoS 적용 전후의 측정과 관련된다면 Measurement Information과 Usage Information의 관련 플래그도 확인해야 합니다. URR은 하나의 고립된 숫자가 아닙니다. 측정 시간 구간, 측정되는 트래픽, 그리고 측정이 수행되는 처리 단계 모두가 최종 사용량 값을 어떻게 해석해야 하는지에 영향을 줍니다.

“사용량이 맞지 않는다”는 많은 사례는 UPF 카운터 자체의 오류가 아니라 실제 측정 범위와 기대한 과금·집계 범위가 서로 맞지 않아서 발생합니다.

URR은 사용자 평면 트래픽을 제어 평면이 측정할 수 있는 정보로 바꾼다

PDR, FAR, QER은 주로 UPF 내부에서 패킷을 어떻게 식별하고 전달하며 QoS 처리를 적용할지 설명합니다. URR은 여기에 또 하나의 필수 기능을 더합니다. 제어 평면이 실제로 소비된 사용자 평면 트래픽 양을 알 수 있게 하는 것입니다.

URR은 Measurement Method로 측정 범위를 정의하고 Reporting Trigger로 보고가 필요한 시점을 정하며, Threshold, Quota, Monitoring Time 같은 파라미터로 사용량 측정의 여러 단계를 제어합니다. 필요한 조건이 충족되면 UPF는 PFCP Usage Report로 결과를 SMF에 보내고, 제어 평면은 필요에 따라 URR을 업데이트하거나 다른 정책 동작을 수행할 수 있습니다.

따라서 URR을 가장 실용적으로 이해하는 방법은 수십 개의 Information Element를 외우는 것이 아니라 하나의 완전한 체인을 따라가는 것입니다.

PDR이 측정할 트래픽 선택 → URR이 측정 방식 정의 → UPF가 사용량을 지속적으로 측정 → Reporting Trigger가 보고 시점 결정 → Usage Report가 결과를 SMF에 반환 → SMF가 필요에 따라 제어 정책 업데이트.

이 체인을 이해하면 Volume Threshold, Volume Quota, Measurement Period, Monitoring Time, 여러 Reporting Trigger가 서로 고립된 PFCP 필드처럼 보이지 않습니다. 이들은 하나의 5G 사용량 측정·보고 메커니즘 안에 있는 서로 다른 제어 지점입니다.

사용량 기반 과금, 실시간 할당량 관리, 또는 소비량에 따른 정책 조정이 필요한 서비스에서 이 메커니즘은 5G 사용자 평면이 트래픽 전달뿐 아니라 측정 가능하고 제어 가능하도록 만드는 기반을 제공합니다.

자주 묻는 질문