스마트폰에 이미 5G 아이콘이 표시되는데도 웹페이지가 열리지 않는 경우가 있습니다. 이때 가장 먼저 Registration 절차를 확인하는 경우가 많습니다. 5G-AKA가 완료되었는지, Registration Accept를 수신했는지, T3512가 만료되었는지를 살펴봅니다. 이런 항목이 모두 정상이어도 데이터 서비스는 여전히 동작하지 않을 수 있습니다.
많은 경우 문제는 Registration이 아니라 PDU Session에 있습니다. Registration은 “UE가 5GS에 등록할 수 있는가?”에 답하고, PDU Session Establishment는 그다음 질문인 “UE가 실제로 데이터 네트워크에 접속할 수 있는가?”에 답합니다. 이 글에서는 UE가 세션을 요청하는 단계부터 AMF의 SMF 선택, SMF의 가입자 및 정책 정보 조회, UPF 설정, 최종 N3 터널 완성까지 PDU Session Establishment 전체 절차를 순서대로 설명합니다.
UE가 5GS Registration을 완료하면 AMF에는 이미 사용자 식별 정보, 이동성, 보안 및 관련 가입자 컨텍스트가 존재합니다. 그러나 등록 성공이 곧 사용자 평면 경로가 생성되었다는 의미는 아닙니다. UE에는 아직 인터넷이나 기업 데이터 네트워크로 향하는 활성 경로가 없을 수 있습니다.
PDU Session Establishment는 UE를 “등록됨” 상태에서 “애플리케이션 트래픽을 전달할 수 있는” 상태로 전환합니다. UE가 세션을 요청하면 네트워크는 SMF와 UPF를 선택하고, DNN 및 S-NSSAI와 연관된 가입자 데이터를 가져오며, 세션 정책을 획득하고, UPF에 PFCP 규칙을 설치한 뒤 gNB와 협력해 N3 터널을 설정합니다. 절차가 끝나면 UE는 IP 주소, QoS 규칙, Data Network로 향하는 사용자 평면 경로를 갖게 됩니다.
이 절차를 하나의 독립된 NAS 메시지로만 보면 이해하기 어렵습니다. 실제로는 세션 관리, 정책 제어, 사용자 평면 자원 설정이라는 세 가지 작업이 함께 진행되며, 최종적으로 사용할 수 있는 PDU Session으로 통합됩니다.
PDU 세션과 5GS 등록의 기능적 경계
5GC에서 Registration과 PDU Session의 역할은 명확히 구분됩니다. Registration은 네트워크 등록을 설정하고, PDU Session은 데이터 연결을 설정합니다.
Registration은 UE가 5GS에 진입할 수 있는지를 결정합니다. AMF는 UE 식별 정보를 확인하고, 인증을 수행하며, NAS 보안을 설정하고, 이동성과 관련된 가입자 데이터를 가져오고, RM(Registration Management) 및 CM(Connection Management)에 필요한 컨텍스트를 생성합니다. 이 과정이 완료되면 UE와 코어 네트워크 사이의 관리 관계가 확립됩니다.
PDU Session은 실제 데이터 서비스와 연결됩니다. UE가 인터넷 접속, IMS 연결 또는 기업 사설망을 사용해야 한다면 Registration만으로는 충분하지 않습니다. 네트워크는 사용할 DNN, 적용할 S-NSSAI, 세션을 제어할 SMF, 사용자 평면을 담당할 UPF, 허용되는 QoS 및 대역폭 파라미터를 추가로 결정해야 합니다.
EPC와 비교하면 차이를 더 쉽게 이해할 수 있습니다. LTE는 PDN Connection과 EPS Bearer 개념을 사용합니다. 5GC에서는 이 모델이 PDU Session + QoS Flow로 대체됩니다. PDU Session이 설정된 뒤 네트워크는 LTE 방식의 Default EPS Bearer 대신 QoS 규칙과 QoS Flow 자원을 생성합니다.
또 하나 중요한 점은 PDU Session이 반드시 초기 Registration과 동시에 설정될 필요가 없다는 것입니다. UE는 Registration을 완료한 뒤 애플리케이션이 실제로 데이터 서비스를 요구할 때까지 PDU Session 없이 등록 상태를 유지할 수 있습니다. 예를 들어 단말은 전원이 켜질 때 등록되지만, 사용자가 30분 후 동영상 애플리케이션을 실행할 때 비로소 PDU Session이 생성될 수 있습니다.
이 차이는 트레이스 분석에서 특히 유용합니다. Registration이 정상적으로 완료되었지만 PDU Session Establishment가 완료되지 않았다면 5G-AKA, Registration Accept, T3512만 반복해서 확인해도 데이터 서비스 문제를 해결하기 어렵습니다. 조사 대상 절차가 잘못되었기 때문입니다.
PDU 세션 요청의 DNN, S-NSSAI 및 요청 유형
PDU Session Establishment는 UE가 보내는 NAS 메시지로 시작됩니다. PDU Session Establishment Request는 단순히 코어 네트워크에 “데이터 접속이 필요하다”고 알리는 메시지가 아닙니다. 요청에 포함된 정보 요소는 이후의 NF 선택과 세션 설정에 영향을 줍니다.
일반적인 초기 요청에는 PDU Session ID, Request Type, PDU Session Type, SSC Mode, DNN, S-NSSAI가 포함될 수 있습니다.
PDU Session ID는 동일한 UE에 속한 여러 세션을 구분합니다. 하나의 UE는 예를 들어 인터넷 접속용 세션과 기업 사설망용 세션처럼 여러 PDU Sessions를 동시에 유지할 수 있습니다. SUPI는 가입자를 식별하지만, 현재 처리 중인 개별 PDU Session까지 자체적으로 식별하지는 않습니다.
DNN은 UE가 접속하려는 Data Network를 식별합니다. 이동통신 사업자의 인터넷 접속, IMS, 기업 네트워크는 서로 다른 DNN을 사용할 수 있습니다. DNN은 이후 SMF 선택, UPF 선택, 정책 결정에도 관여합니다.
S-NSSAI는 세션을 특정 Network Slice와 연결합니다. AMF와 SMF는 요청된 슬라이스가 사용자의 가입 정보, 요청된 DNN, 실제 배치된 네트워크 기능과 일치하는지 확인해야 합니다.
Request Type은 요청의 상황을 나타냅니다. 새로운 PDU Session뿐 아니라 기존 세션, 접속 변경, 긴급 서비스 시나리오와 관련된 경우도 있습니다. 따라서 트레이스 분석에서 PDU Session Establishment Request가 보인다는 이유만으로 매번 동일한 상황이라고 해석해서는 안 됩니다.
가장 일반적인 경우는 Initial Request입니다. UE는 이미 Registration을 완료했고 특정 DNN을 위한 새로운 PDU Session을 생성합니다. SMF 선택, UDM 가입자 데이터 조회, PCF 정책 제어, UPF 자원 설정은 모두 이 세션 컨텍스트를 기준으로 진행됩니다.
AMF의 SMF 선택 및 SM Context 생성
UE의 NAS 세션 관리 메시지는 먼저 gNB에 도착한 뒤 NR-CGI, TAI 같은 접속 관련 정보와 함께 NGAP를 통해 AMF로 전달됩니다. gNB는 PDU Session 제어 결정을 내리지 않으며 NAS 정보를 코어 네트워크 쪽으로 전달하는 역할을 합니다.
요청을 수신한 AMF는 요청된 S-NSSAI와 DNN을 지원할 수 있는 SMF를 식별해야 합니다.
서비스 기반 5GC 아키텍처에서 AMF는 NF 검색을 위해 NRF를 사용할 수 있습니다. 검색 조건에는 대상 NF 유형, 필요한 Nsmf_PDUSession 서비스, S-NSSAI, DNN, Serving PLMN 등이 포함될 수 있습니다. NRF가 후보 SMF 인스턴스를 반환하면 AMF는 네트워크 정책에 따라 실제 서비스를 담당할 SMF를 선택합니다.
이어서 AMF는 SMF의 PDU Session 서비스를 호출해 SM Context를 생성합니다. 요청에는 SUPI, PDU Session ID, DNN, S-NSSAI 외에도 UE가 처음 보낸 PDU Session Establishment Request가 N1 SM information 형태로 포함됩니다.
이 시점부터 세션 제어의 중심은 AMF에서 SMF로 이동합니다. AMF는 계속해서 접속과 이동성을 관리하고 UE와 SMF 사이에서 N1 SM 시그널링을 전달하지만, PDU Session을 어떻게 생성할지, 어떤 UPF를 선택할지, 어떤 정책을 적용할지, 사용자 평면 규칙을 어떻게 설정할지는 SMF가 결정합니다.
장애 분석에서는 한 가지 실무적인 점을 고려해야 합니다. 상용 네트워크에서 보이는 NRF 트랜잭션 수가 참조 시그널링 다이어그램과 정확히 일치하지 않을 수 있습니다. NF 검색 결과가 캐시될 수 있고, 정적 설정이 사용될 수 있으며, SCP가 서비스 라우팅을 제공할 수도 있습니다. 중요한 것은 특정 NRF 질의가 트레이스에 있는지가 아니라 선택된 SMF가 필요한 DNN, S-NSSAI 및 서비스 기능을 실제로 지원하는지 여부입니다.
UDM 가입자 데이터 및 PCF 세션 정책 처리
SMF가 UE가 요청한 세션 유형을 파악했다고 해서 즉시 사용자 평면을 만들 수 있는 것은 아닙니다. 먼저 해당 가입자가 실제로 어떤 PDU Session을 설정할 권한이 있는지 확인해야 합니다.
일반적인 절차에서 SMF는 적절한 UDM을 찾고, 해당 SUPI와 PDU Session을 담당하는 SMF로 자신을 등록한 뒤 요청된 S-NSSAI와 DNN에 연관된 Session Management Subscription Data를 가져옵니다.
가입자 데이터에는 허용된 PDU Session Type, SSC Mode, Session-AMBR, 기본 QoS 관련 설정이 포함될 수 있습니다. 이러한 값은 가입자 수준에서 세션의 범위를 정합니다. 예를 들어 UE가 IPv4 PDU Session을 요청해도 SMF는 해당 DNN이 그 PDU Session Type을 허용하는지, 요청된 SSC Mode가 허용되는지를 확인해야 합니다.
SMF는 SM 가입자 데이터 변경을 구독할 수도 있습니다. 관련 세션 관리 가입 정보가 이후 UDM에서 변경되면 UDM은 등록된 Callback URI를 통해 현재 서비스를 담당하는 SMF에 알릴 수 있습니다.
배포 환경에서 동적 SM Policy Control을 사용한다면 SMF는 PCF를 선택하고 SM Policy Association을 설정합니다. SMF는 SUPI, PDU Session ID, DNN, S-NSSAI, UE 위치, 가입된 QoS 파라미터와 같은 컨텍스트를 제공합니다. PCF는 이후 승인된 세션 정책을 반환하며, 여기에는 Session-AMBR, 기본 QoS 및 기타 적용 가능한 정책 규칙이 포함될 수 있습니다.
이 단계는 세션 파라미터가 하나로 모이는 과정으로 볼 수 있습니다.
UE 서비스 요청 → UDM 가입 제한 → PCF 정책 승인 → SMF가 최종 세션 제어 파라미터 결정
이후 UPF에 설치되는 QoS 및 전달 규칙은 이러한 결과를 기반으로 합니다.
N4 세션 설정과 UPF 사용자 평면 규칙 설치
세션 파라미터가 결정되면 SMF는 요청된 DNN, S-NSSAI, UE 위치를 지원할 수 있는 UPF를 선택한 뒤 N4 인터페이스를 통해 PFCP Session을 설정합니다.
PFCP Session Establishment Request는 PDU Session Establishment 절차에서 매우 중요한 단계 중 하나입니다. 이 시점까지 네트워크는 주로 추상적인 서비스 요구사항을 처리해 왔습니다. N4 단계에서는 이러한 요구사항이 실제 사용자 패킷에 UPF가 적용할 수 있는 규칙으로 변환됩니다.
SMF는 UPF에 PDR, FAR, QER, URR 규칙을 설치할 수 있습니다.
PDR: UPF가 해당 PDU Session 또는 특정 트래픽 흐름에 속한 패킷을 어떻게 식별할지 정의합니다.
FAR: 일치하는 패킷을 전달, 폐기, 버퍼링하는 등 어떤 동작을 수행할지 정의합니다.
QER: UPF에서 필요한 QoS 제어를 적용합니다.
URR: 사용자 평면 사용량 측정 및 보고 요구사항을 정의합니다.
이 규칙들을 서로 무관한 네 가지 기능으로 보면 안 됩니다. 이들은 함께 UPF가 트래픽을 처리하는 방식을 정의합니다. PDR은 패킷 흐름을 식별하고 적용 가능한 FAR, QER, URR을 참조해 UPF가 패킷을 어디로 보내야 하는지, 어떤 QoS 제어를 적용해야 하는지, 사용량을 측정해야 하는지를 판단하게 합니다.
UPF가 PFCP Session Establishment를 수락하면 자신의 F-SEID와 생성한 사용자 평면 파라미터를 반환합니다. 그중 가장 중요한 결과 중 하나가 N3에서 사용하는 UPF 측 사용자 평면 주소와 TEID입니다.
하지만 이 시점에도 gNB가 N3 자원 할당을 아직 끝내지 않았을 수 있으므로 다운링크 경로가 완성되지 않을 수 있습니다. 따라서 PDU Session Establishment는 단 한 번의 PFCP 요청으로 끝나지 않으며 RAN이 사용자 평면 설정의 자기 부분을 완료해야 합니다.
N1/N2 시그널링으로 N3 터널과 QoS Flow 설정 완료
UPF 측 자원이 준비되면 SMF는 AMF를 통해 서로 다른 두 종류의 정보를 반환해야 합니다.
첫 번째는 N1 SM information이며 최종적으로 UE에 전달됩니다. 여기에는 PDU Session Establishment Accept와 함께 세션 설정 후 UE가 필요로 하는 PDU Session Type, SSC Mode, DNN, S-NSSAI, UE IP 주소, Session-AMBR, 기본 QoS Rule 등이 포함됩니다.
두 번째는 N2 SM information이며 gNB용 정보입니다. 어떤 PDU Session을 생성하는지, 어떤 QoS Flows가 포함되는지, N3에서 어떤 UPF IP 주소와 TEID를 사용할지를 RAN에 알려 줍니다.
AMF는 NGAP를 통해 gNB로 PDU Session Resource Setup Request를 전송합니다. gNB는 필요한 무선 및 N3 자원을 할당하고 PDU Session Establishment Accept를 UE로 전달합니다.
자원 설정 후 gNB는 자신의 N3 사용자 평면 주소와 TEID, 성공적으로 설정된 QoS Flows 정보가 포함된 PDU Session Resource Setup Response를 반환합니다.
여기에는 중요한 시점상의 차이가 있습니다. SMF가 처음 PFCP Session을 설정했을 때는 UPF 측 N3 정보는 이미 알고 있지만 최종 gNB 측 터널 정보는 아직 모를 수 있습니다. gNB가 N3 주소와 TEID를 반환하면 AMF가 이 정보를 SMF로 전달합니다. 이후 SMF는 PFCP Session Modification을 사용해 UPF의 해당 FAR을 갱신하고, 다운링크 패킷이 gNB 방향의 올바른 GTP-U 터널로 캡슐화되도록 합니다.
이 시점에서 업링크와 다운링크 사용자 평면 경로가 완성됩니다.
UE → gNB → N3 GTP-U → UPF → N6 → Data Network
Data Network → N6 → UPF → N3 GTP-U → gNB → UE
따라서 PDU Session Establishment Accept를 수신했다는 사실만으로 모든 사용자 평면 요소가 올바르다고 판단할 수는 없습니다. N3 터널 파라미터, PFCP Session Modification, 최종 UPF 규칙을 실제 패킷 전달 결과와 함께 검증해야 합니다.
PDU 세션 설정 시 시그널링 장애 분석
PDU Session Establishment에는 많은 네트워크 기능이 관여합니다. 첫 패킷부터 모든 메시지를 하나씩 비교하며 분석하면 빠르게 복잡해질 수 있습니다. 더 효율적인 방법은 절차를 여러 체크포인트로 나누고 장애 범위를 단계적으로 좁히는 것입니다.
세션 요청이 AMF에 정상적으로 도달하는지 확인
먼저 UE가 필요한 5GS Registration을 완료했는지 확인합니다. 그런 다음 PDU Session Establishment Request를 검사하고 PDU Session ID, Request Type, DNN, S-NSSAI, PDU Session Type, SSC Mode가 적절한지 확인합니다. 입력 단계부터 요청에 잘못된 파라미터가 포함되어 있다면 정상적인 SMF와 UPF도 원하는 세션을 만들 수 없습니다.
SMF가 유효한 SM Context를 생성하는지 확인
다음으로 AMF가 적절한 SMF를 선택하고 Create SM Context가 성공하는지 확인합니다. 목표는 단순히 트레이스에서 NRF 메시지를 찾는 것이 아니라 선택된 SMF가 필요한 DNN, S-NSSAI 및 서비스 기능을 지원하는지 확인하는 것입니다.
이어서 UDM이 반환한 SM 가입자 데이터가 요청된 PDU Session을 허용하는지, PCF 정책이 예상 QoS 설정과 일치하는지 확인합니다.
UPF 및 N3 자원이 완전한지 확인
제어 평면이 이미 PDU Session Establishment Accept를 반환했는데도 UE가 데이터를 전달할 수 없다면 분석 범위를 N4와 N3로 내려야 합니다.
다음 순서대로 확인합니다.
PFCP Session Establishment가 성공하고 UPF가 해당 세션을 생성했는지 확인합니다.
PDR, FAR, QER 및 기타 규칙이 예상 트래픽 방향과 일치하는지 확인합니다.
gNB가 N3 사용자 평면 IP 주소와 TEID를 정상적으로 반환했는지 확인합니다.
SMF가 PFCP Session Modification을 통해 gNB 터널 정보를 UPF에 갱신했는지 확인합니다.
예상한 TEID를 사용하는 GTP-U 패킷이 실제로 N3에 나타나는지 확인합니다.
UPF가 N6를 통해 대상 Data Network와 트래픽을 정상적으로 송수신할 수 있는지 확인합니다.
이 순서로 확인하면 전체 5GC를 하나의 구분되지 않는 장애 영역으로 보는 대신 문제를 NAS, SBI, N4, N3 또는 UPF 패킷 전달 단계까지 좁힐 수 있습니다.
자주 묻는 질문
UE가 5G 등록을 완료했는데도 인터넷에 접속하지 못하는 이유는 무엇입니까?
Registration은 UE와 5GC 사이의 접속, 식별, 보안, 이동성 컨텍스트를 설정하지만 사용자 데이터 경로를 자동으로 생성하지는 않습니다. UE가 인터넷이나 다른 Data Network에 접속하려면 SMF가 세션 파라미터, UPF 자원, N3 사용자 평면을 설정할 수 있도록 PDU Session이 추가로 필요합니다.
UE 전원을 켤 때 PDU Session은 항상 설정됩니까?
아닙니다. PDU Session은 Registration 전후에 설정될 수도 있고 UE가 실제 데이터 서비스를 필요로 할 때 나중에 시작될 수도 있습니다. 5GS에서는 UE가 활성 PDU Session 없이 등록 상태를 유지할 수 있으므로 Registration 완료와 PDU Session Establishment를 동일한 이벤트로 봐서는 안 됩니다.
PDU Session Establishment 성공이 UE의 인터넷 접속을 보장합니까?
아닙니다. NAS 계층에서 PDU Session Establishment Accept를 수신했다는 사실만으로 데이터 연결 성공을 입증할 수는 없습니다. 실제 사용자 트래픽은 gNB와 UPF 사이의 N3 터널, UPF의 PDR/FAR/QER 규칙, N6 연결, 대상 Data Network에도 의존합니다. UE가 IP 주소를 받았더라도 사용자 평면 전달이 잘못되어 있을 수 있습니다.
PFCP Session Establishment 이후 PFCP Session Modification이 발생하는 이유는 무엇입니까?
UPF에 초기 PFCP Session이 생성될 때 gNB가 아직 N3 자원 할당을 완료하지 않았을 수 있으므로 SMF가 최종 gNB 사용자 평면 IP 주소와 TEID를 아직 모를 수 있습니다. gNB가 PDU Session Resource Setup Response에서 이 값을 반환하면 SMF는 PFCP Session Modification을 통해 해당 UPF 규칙을 갱신해 다운링크 트래픽이 올바른 N3 GTP-U 터널로 전달되도록 합니다.
PDU Session의 QFI와 N4 인터페이스의 QER은 같은 개념입니까?
아닙니다. QFI는 5GS의 QoS Flow를 식별하고, QER은 SMF가 N4를 통해 UPF에 설정하는 QoS Enforcement Rule입니다. QER은 QoS 적용에 관여하며 필요한 경우 QFI와 연계될 수 있지만 QFI 자체가 QER인 것은 아니며 두 개념을 동일하게 취급해서는 안 됩니다.
