일반적인 5G 사용자 평면 장애 상황은 처음에는 혼란스러울 수 있습니다. PDU Session이 정상적으로 설정되고, UE가 IP 주소를 받고, PDR이 예상 트래픽과 일치하며, FAR에는 FORW가 포함되고 패킷도 실제로 흐르기 시작합니다. 그런데도 사용자는 비디오 버퍼링, 예상보다 낮은 다운로드 속도, 또는 한 방향에서만 동작하는 트래픽을 경험할 수 있습니다.
이런 경우 PDR과 FAR만 확인해서는 원인을 찾지 못할 수 있습니다. 문제는 트래픽이 식별되었는지 또는 패킷이 어디로 전달되었는지가 아니라 전달이 허용된 후 UPF가 어떤 QoS 정책을 적용했는지에 있을 수 있습니다. N4 인터페이스의 PFCP 규칙 체계에서 QER(QoS Enforcement Rule, QoS 적용 규칙) 은 UPF에서 이러한 QoS 정책을 적용하는 역할을 합니다. 트래픽 통과 여부를 제어하고, uplink/downlink 속도를 제한하고, 트래픽을 QoS Flow와 연결하며, 전송 계층 마킹을 적용할 수 있습니다. 따라서 사용자 평면 전체 동작을 이해하려면 PDR, FAR, QER을 함께 봐야 합니다.
PDR과 FAR이 정상인데도 QER이 필요한 이유는 무엇일까?
QER을 가장 쉽게 이해하는 방법은 UPF의 각 규칙이 담당하는 역할을 나누어 보는 것입니다.
PDR은 먼저 “이 트래픽은 무엇인가?”라는 질문에 답합니다. PDI, UE IP 주소, F-TEID, SDF Filter 등의 조건으로 패킷을 탐지하고 분류합니다. 트래픽이 식별되면 FAR은 “이 패킷을 어떻게 처리하고 어디로 전달할 것인가?”를 결정합니다.
하지만 패킷 전달이 허용되었다고 해서 제한 없이 전달할 수 있다는 의미는 아닙니다. 네트워크가 여전히 속도, 게이팅, QoS Flow 연결 또는 전송 계층 마킹을 제어해야 한다면 UPF는 연결된 QER을 적용해야 합니다.
따라서 일반적인 처리 순서는 다음처럼 단순화할 수 있습니다.
PDR이 트래픽을 식별 → FAR이 전달 동작을 결정 → QER이 QoS 정책을 적용.
이 규칙들은 서로를 대체하지 않고 함께 동작합니다. 패킷이 PDR과 정확히 일치하고 FAR에 의해 허용되더라도 QER이 정의한 속도 제한이나 게이팅 조건의 영향을 받을 수 있습니다. QER이 없다면 UPF는 패킷을 전달해야 한다는 사실은 알 수 있지만, QoS 관점에서 그 트래픽을 어떻게 다룰지 설명하는 동일한 수준의 정책 정보를 갖지 못합니다.
QER은 언제 설치되고 왜 나중에 갱신될 수 있을까?
QER은 일반적으로 PDU Session의 사용자 평면 규칙 일부로 PFCP Session Establishment 동안 SMF에서 UPF로 프로비저닝됩니다. UPF가 트래픽을 관찰한 후 독립적으로 생성하는 QoS 규칙이 아닙니다. 제어 평면이 적용할 QoS 동작을 결정하고 UPF가 그 결과 규칙을 실행합니다.
QER은 세션 전체 수명 동안 반드시 동일하게 유지되는 것은 아닙니다. 서비스가 동작하는 동안 정책이 바뀌면 SMF는 PFCP Session Modification을 통해 기존 QER을 갱신할 수 있습니다. 가입 정책, 애플리케이션 정책 또는 기타 제어 평면 판단의 변화로 새로운 속도 제한, 다른 Gate 상태, 변경된 QoS Flow 연결 또는 다른 QoS 파라미터가 적용될 수 있습니다.
따라서 장애 분석은 초기 Create QER에서 끝나면 안 됩니다. 세션이 한동안 동작한 뒤 QoS 문제가 발생했다면 이후 Update QER 정보도 확인하고 초기 값과 비교해야 합니다.
제어 평면 관점에서 SMF가 사용하는 QoS 정책은 로컬 설정이나 PCF와 연관된 정책 정보에서 올 수 있습니다. 정책이 N4 인터페이스에 도달하면 UPF가 적용할 수 있는 PFCP 규칙으로 표현됩니다. 서비스 설계에 따라 QoS 적용은 PDU Session 수준, QoS Flow 수준 또는 더 구체적인 SDF나 애플리케이션 트래픽에 적용될 수 있습니다.
세션이 정상처럼 보여도 Gate Status가 트래픽을 차단할 수 있는 이유는 무엇일까?
Gate Status는 트래픽 통과 여부를 즉시 바꿀 수 있기 때문에 QER에서 가장 직접적인 파라미터 중 하나입니다.
uplink와 downlink Gate 상태는 독립적으로 제어할 수 있습니다. Gate가 OPEN이면 해당 방향의 트래픽이 계속 통과할 수 있고, CLOSED이면 QoS 적용 규칙에 의해 해당 방향 트래픽이 차단됩니다.
일반적인 장애 분석 흐름은 다음과 같습니다.
PDU Session이 정상적으로 설정됨;
UE가 IP 주소를 받음;
PDR이 정확히 일치함;
FAR에 FORW가 포함됨;
하지만 애플리케이션 트래픽은 여전히 동작하지 않음.
이때 연결된 QER의 UL Gate와 DL Gate를 확인해야 합니다. 두 방향은 별도로 제어되므로 한쪽 Gate는 OPEN이고 다른 쪽은 CLOSED일 수 있습니다. 그 결과 UE가 downlink는 수신하지만 uplink는 정상적으로 전송하지 못하거나 그 반대인 단방향 사용자 평면 장애처럼 보일 수 있습니다.
이 때문에 QER은 단순한 설명용 QoS 속성이 아니라 실제 적용 규칙입니다. 그 설정은 특정 트래픽이 UPF를 계속 통과할 수 있는지를 직접 결정합니다.
MBR, GBR, Packet Rate는 무엇을 제어할까?
Gate Status는 “트래픽이 통과할 수 있는가?”에 답합니다. 속도 관련 파라미터는 “얼마나 많은 트래픽이 어떤 속도로 통과할 수 있는가?”에 답합니다. QER은 비트레이트와 패킷 속도 모두를 기준으로 제한을 적용할 수 있습니다.
최대 비트레이트(MBR)
MBR은 일치한 트래픽의 최대 비트레이트를 정의하며 uplink/downlink별로 따로 설정할 수 있습니다. 5GC 환경에서는 규칙 설계에 따라 세션 수준 제한, 특정 QoS Flow 또는 더 구체적인 트래픽 흐름에 해당할 수 있습니다.
사용자가 서비스에 정상 접속할 수 있지만 처리량이 매번 비슷한 상한선 근처에서 멈춘다면 연결된 QER의 MBR은 확인할 가치가 있는 파라미터입니다.
MBR은 무선 측 용량과 혼동하기 쉽습니다. 좋은 무선 상태와 충분한 전송 대역폭이 있어도 애플리케이션이 전체 물리 용량을 사용할 수 있다는 보장은 없습니다. UPF가 더 낮은 MBR을 적용하도록 설정되어 있다면 사용자 평면 처리량은 계속 그 제한을 받습니다. 따라서 낮은 처리량을 분석할 때는 무선 성능뿐 아니라 N4 QoS 규칙도 확인해야 합니다.
보장 비트레이트(GBR)
GBR은 정의된 수준의 자원 보장이 필요한 트래픽에 적용되는 보장 비트레이트를 나타냅니다. uplink/downlink별로 각각 지정할 수도 있습니다.
GBR은 실시간 음성, 비디오 또는 기타 QoS 민감 애플리케이션처럼 더 예측 가능한 성능이 필요한 서비스에서 중요할 수 있습니다. 하나의 숫자로만 해석해서는 안 되며 해당 QoS Flow와 전체 QoS 정책도 함께 고려해야 합니다.
개념적으로 MBR은 허용 속도의 상한을 정의하고 GBR은 서비스 정책에 따른 보장 속도 요구사항을 나타냅니다.
패킷 속도(Packet Rate)
일부 트래픽은 비트레이트만으로 충분히 설명되지 않습니다. QER에는 지정된 시간 동안 허용되는 패킷 수를 제한하는 Packet Rate 파라미터도 포함될 수 있습니다.
이는 DNS 트랜잭션, IoT 킵얼라이브, 시그널링 형태의 트래픽처럼 작은 패킷을 많이 생성하는 워크로드에서 중요할 수 있습니다. 전체 비트레이트는 비교적 낮지만 초당 패킷 수가 높아질 수 있습니다. 이런 경우 MBR만 확인해서는 관찰된 QoS 동작을 설명하지 못할 수 있습니다.
Packet Rate 제한에 도달하면 전체 대역폭 사용량은 크지 않아 보여도 사용자는 지연 증가, 느린 응답, 요청 실패를 경험할 수 있습니다.
QER에서 QFI, Flow Level Marking, PPI는 어떤 역할을 할까?
QER은 단순한 속도 제한 규칙이 아닙니다. Gate Status, MBR, GBR 외에도 QoS Flow 식별과 패킷 처리에 관련된 파라미터를 담을 수 있습니다. 이 파라미터들이 함께 사용자 평면에서 트래픽을 어떻게 처리할지 결정합니다.
QoS Flow Identifier(QFI)
QFI는 QoS Flow를 식별합니다. 하나의 PDU Session에는 여러 QoS Flows가 포함될 수 있어 서로 다른 서비스 트래픽에 서로 다른 QoS 처리를 적용할 수 있습니다.
사용자 평면 관점에서 QFI는 패킷이 어느 QoS Flow와 연결되어 있는지 식별합니다. QER에서는 이 식별자를 사용해 관련 QoS 적용 동작을 해당 QoS Flow와 연결할 수 있습니다.
규칙에 연결된 QFI가 의도한 서비스 설계와 맞지 않으면 속도 파라미터 자체가 올바르게 보여도 트래픽이 예상하지 못한 QoS Flow와 연결될 수 있습니다. 그 결과 서비스가 설계된 것과 다른 자원 처리를 받을 수 있습니다.
DL Flow Level Marking
QER은 UPF에 downlink 트래픽에 flow-level marking을 적용하도록 지시할 수 있습니다. 예를 들어 IP 전송 네트워크에 사용할 DSCP 값을 설정할 수 있습니다.
이 마킹은 패킷이 어떤 5G QoS Flow에 속하는지 결정하지 않습니다. 대신 IP 전송 네트워크에 들어간 후 패킷이 어떻게 식별되고 처리되는지에 영향을 줍니다.
전송 계층 마킹이 잘못되면 5G QoS 자체는 올바르게 설정되어 있어도 하위 전송 네트워크가 패킷을 의도하지 않은 우선순위로 처리할 수 있습니다.
Paging Policy Indicator(PPI)
PPI는 downlink 트래픽의 페이징 정책 처리와 관련됩니다. QER은 페이징이 관련된 적절한 전달 시나리오에서 서로 다른 트래픽을 다르게 처리하도록 페이징 정책 관련 정보를 제공할 수 있습니다.
현재 활성 사용자 평면 상태가 아닌 UE의 경우 서로 다른 downlink 트래픽 유형은 페이징에 미치는 영향이 다를 수 있습니다. PPI는 이러한 차등 처리의 일부로 사용할 수 있는 정보를 제공합니다.
Averaging Window
속도 적용은 항상 하나의 패킷을 순간적으로 관찰한 결과만으로 결정할 수 있는 것은 아닙니다. Averaging Window는 비트레이트 관련 동작을 평가하는 시간 창을 정의합니다.
짧은 창은 버스트 트래픽에 더 빠르게 반응하고, 긴 창은 더 부드러운 평균을 만들며 짧은 버스트를 다르게 허용할 수 있습니다. 따라서 QER 분석은 QER ID와 MBR만 봐서는 안 됩니다. 최종 QoS 동작은 여러 파라미터의 조합에 따라 달라질 수 있습니다.
PFCP 메시지로 QER이 예상대로 동작하는지 어떻게 확인할까?
QER을 분석하는 가장 유용한 방법은 모든 정보 요소를 외우는 것이 아니라 PFCP 규칙을 실제 서비스 증상과 연결하는 것입니다.
예를 들어 Create QER에는 다음이 포함될 수 있습니다.
QER ID = 1;
UL Gate = OPEN;
DL Gate = OPEN;
UL MBR = 100000 kbps;
DL MBR = 150000 kbps.
이 값들은 예시일 뿐이지만 중요한 점을 보여 줍니다. Gate가 OPEN이라고 해서 QoS 제한이 없다는 뜻은 아닙니다. 트래픽은 통과가 허용되어도 여전히 MBR 적용을 받을 수 있습니다.
실용적인 장애 분석 절차는 다음 단계로 진행할 수 있습니다.
먼저 PDR을 식별합니다. 영향받는 트래픽과 실제로 일치하는 PDR을 확인합니다. 잘못된 PDR을 선택하면 예상한 QER이 정확히 적용되지 않습니다.
PDR이 참조하는 QER ID를 확인합니다. 맥락 없이 PFCP 세션의 모든 QER을 확인하지 말고 먼저 분석 대상 트래픽과 실제 연결된 QER을 식별합니다.
Create QER와 Update QER를 확인합니다. 현재 유효한 규칙이 이후 PFCP Session Modification에서 변경되었는지 확인합니다. QoS 문제는 초기 세션 설정이 아니라 나중 업데이트에서 발생할 수 있습니다.
Gate Status를 확인합니다. uplink와 downlink Gate 상태를 각각 확인합니다. 한 방향 Gate만 닫혀도 단방향 서비스 장애가 발생할 수 있습니다.
MBR, GBR, Packet Rate를 확인합니다. 설정된 제한을 관찰된 처리량 또는 패킷 동작과 비교합니다. 특히 서비스가 반복적으로 특정 고정 속도 근처에서 멈추는 경우 중요합니다.
QFI와 기타 QoS 파라미터를 확인합니다. 의도한 QoS Flow, 마킹, 페이징 관련 설정이 서비스 설계와 일치하는지 확인합니다.
규칙을 실제 사용자 평면 트래픽과 비교합니다. PFCP는 UPF가 무엇을 적용해야 하는지 보여 주고, 처리량 테스트와 패킷 캡처는 실제로 무엇이 일어났는지 보여 줍니다. 두 결과의 차이는 매우 유용한 장애 분석 단서가 됩니다.
이 방법은 하나의 QER 필드를 따로 해석하는 것보다 더 신뢰할 수 있습니다. PFCP 시그널링은 UPF가 적용해야 하는 내용을 보여 주고, 사용자 평면 테스트는 실제로 관찰된 결과를 보여 줍니다. 이 두 관점을 비교하는 것이 QER이 의도대로 동작하는지 판단하는 핵심입니다.
FAQ
QER과 FAR의 가장 큰 차이는 무엇일까?
FAR은 주로 일치한 패킷을 어떻게 처리하고 어디로 전달할지 결정하며 FORW, DROP, BUFF 같은 동작을 포함합니다. QER은 게이팅, 속도 제한, QoS Flow 연결, 전송 계층 마킹 같은 QoS 관련 동작을 적용합니다. 둘 다 일반적으로 PDR이 트래픽을 식별한 후 동작합니다. 간단히 말하면 FAR은 패킷을 어디로 어떻게 전달할지결정하고 QER은 그 트래픽에 어떤 QoS 처리를 적용할지결정합니다.
Gate Status가 OPEN인데도 사용자 처리량이 낮을 수 있는 이유는 무엇일까?
OPEN은 해당 방향의 트래픽이 통과할 수 있다는 뜻일 뿐 다른 QoS 제한을 제거하지 않습니다. MBR, GBR, Packet Rate와 연결된 QoS Flow를 계속 확인해야 합니다. MBR이 사용 가능한 무선 또는 전송 용량보다 낮게 설정되어 있으면 두 Gate가 모두 OPEN이어도 처리량은 제한될 수 있습니다.
QER은 PFCP Session Establishment 중에만 생성할 수 있을까?
아닙니다. QER은 PFCP Session Establishment 중에 생성할 수 있고 이후 PFCP Session Modification으로 수정할 수 있습니다. 세션이 이미 동작 중인 상태에서 QoS 동작이 바뀌었다면 초기 Create QER만 보지 말고 이후 Update QER를 확인해야 합니다.
QFI와 QER은 같은 것일까?
아닙니다. QFI는 QoS Flow의 식별자이고 QER은 UPF가 적용하는 QoS 규칙입니다. QER은 QFI 정보를 포함하거나 참조하여 특정 QoS 처리를 해당 QoS Flow와 연결할 수 있습니다. QFI는 어떤 QoS Flow 가 관련되는지 식별하고 QER은 트래픽에 QoS 제어를 어떻게 적용할지정의합니다.
PDR이 일치하고 FAR이 전달을 허용하는데도 트래픽이 실패할 수 있는 이유는 무엇일까?
사용자 평면 처리가 반드시 FAR에서 끝나는 것은 아니기 때문입니다. 전달이 허용된 뒤에도 연결된 QER이 Gate Status, MBR, GBR, Packet Rate 또는 기타 QoS 제약을 적용할 수 있습니다. 따라서 장애 분석에서는 PDR, FAR, QER을 하나의 연속된 처리 체인으로 봐야 합니다. 어느 단계에서든 불일치가 있으면 최종 서비스 결과에 영향을 줄 수 있습니다.
