PDU 세션은 한동안 정상적으로 동작하고 있을 수 있습니다. UE는 이미 IP 주소를 보유하고 있고, N3 사용자 평면 경로가 활성화되어 있으며, 애플리케이션 트래픽도 예상대로 흐릅니다. 이후 서비스 조건이 바뀌면서 기존에 허용된 데이터 속도를 낮춰야 하거나, 특정 QoS Flow에 다른 5QI가 필요해지거나, 네트워크가 세션의 최대 속도를 10 Mbps로 제한할 수 있습니다.
이 경우 5GC는 전체 PDU 세션을 해제한 뒤 다시 구축할 필요가 없습니다. 기존 세션은 활성 상태를 유지하면서 영향을 받는 QoS 규칙, QoS Flow 파라미터 또는 사용자 평면 적용 정책만 갱신할 수 있습니다. 이것이 PDU Session Modification의 역할입니다.
PDU Session Establishment와의 차이는 명확합니다. 세션 설정은 이전에 존재하지 않던 세션을 만들고, 세션 수정은 이미 활성화된 세션을 변경합니다. 따라서 핵심은 SMF가 어떻게 선택되었는지나 UPF가 처음 어떻게 생성되었는지가 아니라, 무엇이 변경을 유발했는지, SMF가 새 정책을 어떻게 얻는지, UE와 gNB가 무엇을 갱신해야 하는지, 그리고 새 QoS 정책이 실제로 UPF에서 적용되는지입니다.
PDU 세션 수정의 범위
PDU Session Modification에는 중요한 전제 조건이 있습니다. 대상 PDU 세션이 이미 존재해야 합니다. UE, SMF, PCF 및 관련 RAN 컨텍스트는 이미 해당 세션과 연계되어 있으며, 사용자 평면도 일반적으로 정상 동작 중입니다.
수정 절차의 목적은 세션을 활성 상태로 유지하면서 파라미터를 변경하는 것입니다. QoS는 가장 일반적인 사례 중 하나입니다. 기존 QoS Flow에 다른 5QI, MBR, MFBR 또는 다른 승인 파라미터가 필요할 수 있습니다. 정책 변경으로 인해 UPF에서 이미 적용 중인 속도 제어를 갱신해야 할 수도 있습니다.
QoS 수정은 단순히 NAS 필드 하나를 바꾸는 것으로 이해해서는 안 됩니다. 한 번의 QoS 갱신이 시스템의 서로 다른 세 부분에 영향을 줄 수 있습니다.
UE 측: UE는 새로운 QoS Rule 또는 QoS Flow 파라미터를 수신해야 합니다.
RAN 측: gNB는 해당 PDU Session Resource 또는 QoS Flow 리소스를 수정해야 할 수 있습니다.
UPF 측: 사용자 평면 적용 방식이 바뀌는 경우 관련 PFCP 규칙을 N4를 통해 갱신해야 합니다.
따라서 PDU Session Modification은 활성 세션에 대한 온라인 재구성으로 보는 것이 가장 적절합니다. 세션 식별자는 그대로 유지되며, 수정은 기존 PDU Session ID와 그에 연결된 QoS Flow들에 적용됩니다.
또 하나 중요한 경계가 있습니다. PDU Session Modification은 기존 QoS Flow를 갱신할 수 있을 뿐 아니라, 적용 가능한 서비스 시나리오에서는 동일한 PDU 세션 안에 새로운 QoS Flow를 설정하는 데에도 사용할 수 있습니다. 예를 들어 애플리케이션 기반 VoNR 통화 정책으로 인해 특정 QoS 특성을 가진 추가 Flow가 필요할 수 있습니다. 다만 여기서는 새 Flow를 만드는 것이 아니라 기존 QoS Flow의 파라미터를 수정하는 것에 초점을 둡니다.
세션 수정의 주요 트리거
PDU Session Establishment와의 큰 차이 중 하나는 UE만이 유일한 트리거가 아니라는 점입니다. 활성 PDU 세션은 UE 요청, 네트워크 정책 변경, 가입 데이터 갱신 또는 무선 환경 변화로 인해 재구성될 수 있습니다.
일반적인 트리거는 다음 다섯 가지 범주로 나눌 수 있습니다.
UE 트리거: UE가 PDU Session Modification Request를 보내 QoS 또는 관련 세션 변경을 요청합니다.
PCF 트리거: 정책 제어가 변경됩니다. 예를 들어 사용량 임계값에 도달해 네트워크가 허용 속도를 낮추거나, 애플리케이션 정책이 다른 QoS를 요구하는 경우입니다.
UDM 트리거: 가입자 등급 또는 가입된 QoS 프로파일 갱신과 같이 세션 관리 가입 데이터가 변경됩니다.
SMF 트리거: SMF가 로컬 정책, 네트워크 설정 또는 현재 세션 상태에 따라 세션을 재구성하기로 결정합니다.
RAN 관련 트리거: gNB가 무선 또는 리소스 상태를 보고한 뒤 SMF가 세션 파라미터를 수정해야 한다고 판단합니다.
이러한 트리거는 결국 SMF로 모입니다. SMF가 PDU 세션 제어 컨텍스트를 보유하고 있으며, 새로운 서비스 또는 정책 요구 사항을 UE, RAN, UPF가 적용할 수 있는 파라미터로 변환하기 때문입니다.
PDU Session Modification을 문제 해결할 때 첫 단계부터 PDU Session Modification Command를 기준으로 뒤쪽 메시지만 따라가서는 안 됩니다. 더 유용한 방법은 변경을 일으킨 최초의 제어 이벤트를 찾는 것입니다. 첫 이벤트가 UE Modification Request이면 UE가 시작한 절차입니다. PCF가 Notification URI를 통해 새 정책을 SMF에 전달했다면 정책 기반 변경입니다. UDM 가입 데이터 갱신이 먼저 나타났다면 가입 정보 변경 경로를 따라 조사해야 합니다.
UE가 시작하는 PDU 세션 수정
UE가 시작하는 절차는 애플리케이션이 다른 QoS를 필요로 하는 경우로 보면 가장 이해하기 쉽습니다.
UE가 현재 PDU Session ID 5를 사용하고 있고, QoS Flows 중 하나가 여전히 기존 설정을 사용한다고 가정합니다. 애플리케이션에 새로운 서비스 요구 사항이 생기면 UE는 PDU Session Modification Request를 전송해 다른 QoS 파라미터를 요청합니다.
NAS 메시지는 먼저 gNB를 거쳐 AMF로 전달됩니다. 이후 AMF는 SMF의 기존 SM Context를 갱신합니다. 서비스 기반 인터페이스에서 AMF는 다음을 사용합니다.
POST /nsmf-pdusession/v1/sm-contexts/{smContextRef}/modify
이는 Create SM Context와 다릅니다. SM Context는 이미 존재하며, 네트워크는 기존 세션 컨텍스트를 갱신하는 것입니다.
UE 요청에는 Requested QoS Rules, Requested QoS Flow Descriptions 및 관련 Packet Filters가 포함될 수 있습니다. 요청을 받은 SMF는 네트워크가 해당 변경을 승인할 수 있는지 판단해야 합니다. 세션에 동적 정책 제어가 사용되는 경우 SMF는 서비스 요청을 PCF에도 보내 승인을 받습니다.
예를 들어 UE가 특정 Flow에 대해 5QI 8을 요청하면, SMF는 PCF SM Policy Control 서비스를 호출해 현재 Policy Association을 수정할 수 있습니다. PCF는 가입자 정책, 서비스 규칙, 현재 네트워크 상태를 평가한 뒤 실제로 승인되는 QoS 파라미터를 반환합니다.
중요한 차이가 있습니다. UE가 요청한 QoS가 최종적으로 실제 적용되는 QoS와 반드시 같지는 않습니다. UE는 서비스 요구 사항을 제시하고, 최종 파라미터는 SMF와 PCF의 승인을 받아야 합니다.
승인된 파라미터가 결정되면 SMF는 두 종류의 정보를 생성합니다.
N1 SM: 새로운 QoS 관련 파라미터를 UE로 전달하는 PDU Session Modification Command.
N2 SM: PDU Session Resource Modify 절차에 사용되는 정보로, gNB에 해당 QoS Flow 리소스를 수정하도록 지시합니다.
AMF는 NGAP을 통해 N2 정보를 gNB에 전달하고, N1에 포함된 PDU Session Modification Command를 UE로 전달합니다.
gNB가 관련 리소스를 조정한 뒤 PDU Session Resource Modify Response를 반환합니다. UE가 새 파라미터를 받아들이면 NAS를 통해 PDU Session Modification Complete를 전송합니다.
SMF가 관련 실행 결과를 수신한 뒤에야 새 세션 파라미터가 정책 승인 단계에서 실제 액세스 측과 UE 측 적용 단계로 넘어갔음을 확인할 수 있습니다.
PCF가 시작하는 네트워크 측 QoS 수정
네트워크 측 수정은 다른 흐름을 따릅니다. UE가 새로운 QoS를 요청한 것이 아니라 정책 제어 계층에서 변경이 시작됩니다.
사용량 임계값 사례를 생각해 보겠습니다. 사용자는 이미 활성 PDU 세션을 가지고 지속적으로 데이터를 전송하고 있습니다. PCF는 세션이 사용량 정보를 보고하거나 모니터링하도록 요구합니다. 누적 사용량이 설정된 임계값에 도달하면 정책을 통해 세션 또는 관련 QoS Flow의 최대 속도를 10 Mbps로 낮출 수 있습니다.
이후 PCF는 SM Policy Association이 설정될 때 등록된 Notification URI를 통해 SMF에 알립니다. 이 알림에는 갱신된 MBR 및 해당 Policy Control Trigger와 같은 새로운 SM Policy Decision이 포함됩니다.
SMF 관점에서 이는 새로운 세션을 만드는 것이 아닙니다. 여전히 유효하고 활성 상태인 PDU 세션을 수정하는 것입니다.
새 속도를 UPF에서 적용해야 한다면 SMF는 N4를 통해 PFCP Session Modification Request를 보냅니다. 예를 들어 해당 QER의 MBR을 10 Mbps로 변경할 수 있습니다. UPF가 이 수정을 받아들여야 새 속도 제한이 사용자 평면에서 실제로 적용됩니다.
“Modification”이라는 표현의 다음 두 가지 사용을 혼동해서는 안 됩니다.
PDU Session Modification: 활성 PDU 세션을 수정하는 전체 5GS 절차.
PFCP Session Modification: SMF가 N4를 통해 UPF의 사용자 평면 규칙을 갱신하는 구체적인 제어 절차.
두 절차는 서로 다른 계층에서 동작합니다. PDU Session Modification에 PFCP Session Modification이 포함될 수는 있지만, PFCP 수정 메시지 하나가 존재한다고 해서 전체 PDU 세션 수정이 끝났다는 뜻은 아닙니다.
UPF가 새 QER을 적용하기 시작한 이후에도 SMF는 RAN과 UE를 추가로 갱신해야 할 수 있습니다. N1/N2 정보가 AMF를 통해 전달되고, gNB는 PDU Session Resource Modify Request를, UE는 PDU Session Modification Command를 받습니다.
gNB가 무선 리소스 갱신을 완료하고 UE가 새 QoS 파라미터를 받아들이면 양쪽에서 실행 결과를 반환합니다. 그러면 SMF는 성공 결과를 PCF에 보고할 수 있고, 정책 시스템은 QoS 정책 결정이 단순히 정책 결정으로 저장된 것이 아니라 실제로 적용되었음을 알 수 있습니다.
N1, N2, N4 간의 연동 수정
PDU Session Modification에서 가장 혼동하기 쉬운 부분 중 하나는 동일한 QoS 변경이 NAS, NGAP, PFCP에서 동시에 수정 절차를 발생시킬 수 있다는 점입니다.
세 경로를 분리해 보면 논리가 훨씬 명확해집니다.
N1이 UE 세션 파라미터를 갱신
N1 SM은 UE와 SMF 사이에서 세션 관리 정보를 전달합니다. 네트워크가 세션 수정을 결정하면 SMF는 AMF를 통해 UE에 PDU Session Modification Command를 보냅니다.
UE는 로컬 PDU 세션 파라미터를 갱신하고 PDU Session Modification Complete로 수락을 확인합니다.
N2가 RAN 리소스를 갱신
QoS Flow와 연관된 무선 리소스를 변경해야 하는 경우 SMF는 해당 N2 SM 정보를 생성해 AMF를 통해 gNB로 전달합니다. gNB는 PDU Session Resource Modify 절차를 사용해 관련 QoS Flow 리소스를 수정하고, 해당되는 경우 성공적으로 수정된 QFI를 포함한 결과를 반환합니다.
N4가 UPF 적용 규칙을 갱신
변경이 사용자 평면 포워딩 또는 QoS 적용에 영향을 주는 경우 SMF는 PFCP Session Modification을 통해 관련 UPF 규칙을 갱신합니다.
속도 제한 변경에는 QER 갱신이 필요할 수 있습니다. 다른 정책 변경이 PDR, FAR 또는 다른 사용자 평면 규칙에 영향을 줄 수도 있습니다. 어떤 규칙을 수정할지는 서비스와 제어 정책에 따라 달라지며, PDU Session Modification이 모든 PFCP 규칙을 다시 작성해야 한다는 뜻은 아닙니다.
완전한 QoS 변경은 다음과 같이 정리할 수 있습니다.
정책 / UE 요청
→ SMF가 세션 파라미터 재계산
→ N4가 UPF 적용 규칙 갱신
→ N2가 gNB 리소스 갱신
→ N1이 UE 파라미터 갱신
→ 각 측이 결과 확인
정확한 메시지 순서는 트리거와 변경되는 파라미터에 따라 달라질 수 있습니다. 문제 해결 과정에서 모든 시나리오가 동일한 메시지 순서를 가져야 한다고 가정하는 것은 유용하지 않습니다. 더 중요한 것은 변경이 필요한 모든 실행 지점이 실제로 새 파라미터를 수신하고 적용했는지 확인하는 것입니다.
수정 완료 및 시그널링 문제 해결
PDU Session Modification 문제에는 세션 설정 실패와 다른 특징이 있습니다. PDU 세션이 활성 상태를 유지하고 사용자가 계속 데이터를 전송할 수 있어도, 최종 QoS가 의도한 정책과 일치하지 않을 수 있습니다.
예를 들어 정책이 속도를 10 Mbps로 낮추도록 요구하고 PCF가 이미 새로운 정책 결정을 내렸지만, 실제 처리량 테스트에서는 훨씬 높은 속도가 나타날 수 있습니다. PDU 세션이 계속 존재한다는 사실만으로 수정 성공을 입증할 수는 없습니다. 새 파라미터가 어느 지점에서 더 이상 적용되지 않았는지 확인해야 합니다.
실제 문제 해결에는 다음 점검 항목을 사용할 수 있습니다.
트리거 식별: 첫 이벤트가 UE Modification Request, PCF Notification, UDM 데이터 변경 또는 SMF/RAN 측 이벤트인지 확인합니다.
SMF 결정 확인: SMF가 요청을 수락했는지, PCF가 예상한 정책 결정을 반환했는지 확인합니다.
N4 적용 확인: UPF가 새 QoS를 적용해야 하는 경우 PFCP Session Modification이 성공했고 관련 QER 파라미터가 실제로 변경되었는지 확인합니다.
N2 실행 확인: gNB가 PDU Session Resource Modify Request를 수신하고 성공적으로 수정된 QoS Flows를 반환했는지 확인합니다.
N1 확인 절차 점검: UE가 PDU Session Modification Command를 수신하고 PDU Session Modification Complete를 반환했는지 확인합니다.
서비스 결과 검증: 실제 트래픽이 갱신된 속도, QoS 또는 서비스 정책을 따르는지 확인합니다.
PCF가 이미 10 Mbps를 승인했는데 UPF의 QER이 여전히 이전 MBR을 가지고 있다면 SMF-N4 경로를 집중적으로 조사해야 합니다. UPF가 새 속도를 적용하고 있지만 gNB의 QoS Flow가 여전히 이전 파라미터를 사용하는 경우 N2 Resource Modify 절차를 더 확인해야 합니다. 네트워크 측에서 필요한 변경을 모두 완료했는데 UE가 Modification Complete를 반환하지 않는다면 NAS 측에서 새 QoS 규칙이 수락되었는지 확인해야 합니다.
메시지 이름 하나도 혼동을 일으킬 수 있습니다. 일부 절차도에서는 UE 확인 단계를 “PDU Session Modification Command Ack”라고 표현합니다. 하지만 5GSM NAS 시그널링에서 UE가 PDU Session Modification Command를 수락한 후 실제로 보내는 메시지는 PDU Session Modification Complete입니다. 따라서 패킷 분석에서는 실제 NAS Message Type을 기준으로 해야 합니다.
이러한 계층별 문제 해결 방식은 Registration Request부터 다시 조사하는 것보다 훨씬 효과적입니다. PDU 세션은 이미 존재합니다. 문제는 활성 세션이 새 정책에 맞게 일관되게 갱신되지 않았다는 것입니다. 따라서 장애 범위는 현재 SM Context, 정책, QoS Flow 및 사용자 평면 적용에 집중해야 합니다.
자주 묻는 질문
PDU Session Modification이 UE의 IP 주소를 다시 할당합니까?
일반적인 QoS 수정은 전체 세션을 다시 구축하는 대신 기존 PDU 세션과 그 QoS Flows를 갱신합니다. 다른 세션 속성이 바뀌는지는 구체적인 시나리오에 따라 다르지만, 5QI나 MBR 같은 파라미터만 변경하는 경우 이를 또 다른 PDU Session Establishment 절차로 봐서는 안 됩니다.
PDU Session Modification은 항상 UE가 시작합니까?
아닙니다. UE는 PDU Session Modification Request로 수정을 요청할 수 있지만, PCF 정책 변경, UDM 가입 데이터 갱신, SMF 로컬 결정 또는 RAN 관련 이벤트도 네트워크 측 수정을 트리거할 수 있습니다. 일반적으로 SMF가 UE, RAN, UPF 간에 필요한 갱신을 조정합니다.
PDU Session Modification과 PFCP Session Modification의 차이는 무엇입니까?
PDU Session Modification은 활성 세션을 수정하는 전체 5GS 절차로, UE, RAN, SMF, PCF 및 사용자 평면이 관여할 수 있습니다. PFCP Session Modification은 SMF와 UPF 사이의 N4 인터페이스에서 구체적으로 수행되며 UPF의 실제 사용자 평면 규칙을 변경합니다. 후자는 전자의 일부가 될 수 있지만 두 절차는 동일하지 않습니다.
QER이 이미 갱신되었다면 왜 gNB와 UE도 수정해야 합니까?
QER은 UPF에서 QoS 적용을 제어하지만 QoS Flow는 UPF에서만 정의되는 것이 아닙니다. UE에는 새로운 QoS Rule 또는 QoS Flow 설명이 필요할 수 있고, RAN은 해당 무선 리소스를 조정해야 할 수 있습니다. 따라서 일부 QoS 수정에서는 N1, N2, N4 간의 일관성이 필요합니다. UPF만 갱신했다고 해서 전체 PDU Session Modification 절차가 완료된 것은 아닙니다.
PDU Session Modification으로 새로운 QoS Flow를 추가할 수 있습니까?
가능합니다. PDU Session Modification은 기존 QoS Flow의 파라미터를 갱신할 수 있으며, 적용 가능한 시나리오에서는 같은 PDU 세션 안에 새로운 QoS Flow를 설정하는 데에도 사용할 수 있습니다. 예를 들어 애플리케이션 기반 VoNR 서비스에 특정 5QI를 가진 추가 QoS Flow가 필요할 수 있습니다. 이 시나리오는 기존 Flow를 단순히 갱신하는 경우와 서비스 컨텍스트가 다르므로 별도로 분석하는 것이 적절합니다.
