5G SA 단말은 어떤 네트워크 슬라이스를 선택하는가

S-NSSAI는 품질 등급이 아니라 slice 식별 정보다

3GPP TS 23.501은 S-NSSAI(Single Network Slice Selection Assistance Information)를 PLMN 안의 Network Slice를 식별하는 정보로 정의한다. S-NSSAI는 SST(Slice/Service Type)와 선택적 SD(Slice Differentiator)로 구성된다. SST는 해당 slice에 기대되는 동작 유형을 나타내며, 표준화된 값과 사업자별 값이 있을 수 있다. SD는 같은 SST 안에서 서로 다른 slice를 더 구분할 때 붙이는 선택적 값이다.

이 구조를 QoS 등급과 혼동하면 안 된다. S-NSSAI는 단말과 망이 어떤 논리적 slice 맥락을 말하는지 맞추는 식별 정보다. 반면 5QI, ARP, GFBR 같은 값은 PDU Session 안의 QoS Flow가 어떤 전달 처리를 받을지를 표현한다. 같은 S-NSSAI를 쓰는 세션에도 여러 QoS Flow가 존재할 수 있고, 같은 SST라고 해서 모든 사업자의 자원 배치나 품질 약속이 같아지는 것도 아니다.

따라서 “SST가 어떤 값이므로 지연이 얼마다”라고 바로 읽을 수 없다. 표준화된 SST는 예상 동작을 분류하는 공통 언어지만, 고객에게 제공되는 성능과 가용성은 실제 QoS 정책, 무선·전송·코어 자원, 애플리케이션 구간과 운영 조건이 함께 결정한다. 이 글의 선택 절차는 그런 종단간 보장이나 SLA를 증명하는 절차가 아니다.

네 가지 NSSAI는 서로 다른 질문에 답한다

NSSAI는 하나 이상의 S-NSSAI로 이뤄진 목록이다. 2026년 8월 현재 유지되는 3GPP Release 18 절차를 기준으로 보면 Configured, Requested, Allowed, Subscribed라는 네 용어는 다음처럼 구분된다. Release 19와 Release 20에도 기능 확장이 이어지고 있으므로 실제 제품은 사업자가 채택한 release와 feature set을 함께 확인해야 하지만, 네 목록의 역할을 서로 바꿔 읽어서는 안 된다.

Configured NSSAI는 “단말에 알려진 후보”에 가깝다. 이것이 USIM이나 단말에 들어 있다고 해서 이용 권한이 생기는 것은 아니다. Requested NSSAI는 UE가 등록 메시지에서 “이 목록을 사용하고 싶다”고 제시하는 값이다. UE는 이전에 받은 Allowed NSSAI, 해당 PLMN의 Configured NSSAI, 기본 구성과 URSP가 요구하는 S-NSSAI 등을 규격의 우선순위와 제약에 따라 반영한다.

Subscribed S-NSSAI는 가입자 데이터의 권한 근거다. UDM이 AMF에 제공하는 Access and Mobility Subscription Data에는 가입된 S-NSSAI와 기본 여부 같은 정보가 포함된다. Allowed NSSAI는 이 가입 정보에 현재 Registration Area와 access type에서 제공 가능한 slice, 망 정책과 NSSF 결과를 반영한 실행 가능한 허용 목록이다. 즉 Subscribed는 계약·provisioning의 관점이고 Allowed는 현재 등록 문맥의 관점이다.

Registration은 사용할 수 있는 slice 범위를 먼저 정한다

UE는 Initial Registration 또는 Mobility Registration Update에서 Requested NSSAI를 보낼 수 있다. NG-RAN은 이 정보와 자체 구성을 이용해 요청을 처리할 AMF를 선택하거나 기본 AMF로 전달한다. 처음 선택된 AMF가 요청한 slice를 모두 지원하지 않더라도, 필요한 정보를 NSSF에 질의해 적절한 AMF set이나 후보를 찾는 절차가 이어질 수 있다.

AMF는 UDM에서 Subscribed S-NSSAIs를 가져와 UE의 요청과 대조한다. 필요하면 NSSF에 현재 Tracking Area에서의 slice 가용성, 허용 가능한 S-NSSAI, 이를 지원하는 AMF 정보를 질의한다. AMF는 가입 정보, 현재 영역과 access, 로컬 정책, NSSF 결과와 인증·권한 확인 결과를 반영해 Allowed NSSAI를 UE에 통지한다. 허용되지 않은 항목에는 Rejected S-NSSAI와 원인·적용 범위가 함께 전달될 수 있다.

여기서 NSSF를 “앱마다 최적 slice를 실시간 선택해 주는 중앙 두뇌”로 표현하면 과장이다. NSSF는 Network Slice selection과 AMF selection을 지원하지만, 앱 트래픽을 어느 PDU Session에 바인딩할지는 UE의 URSP 평가와 세션 절차로 이어진다. AMF 역시 사용자 평면 패킷을 직접 분류하지 않는다.

Allowed NSSAI를 받았다는 사실도 곧바로 데이터 경로가 생겼다는 뜻은 아니다. 등록은 사용할 수 있는 slice 범위를 만든다. 실제 데이터 통신에는 특정 S-NSSAI와 DNN 등의 속성을 가진 PDU Session이 이미 있거나 새로 성공적으로 수립돼야 한다.

대체 설명 첫 단계에서는 UE의 Requested NSSAI를 AMF가 가입 정보와 현재 망 가용성에 대조해 Allowed NSSAI를 정한다. 두 번째 단계에서는 UE가 URSP의 traffic descriptor와 Route Selection Descriptor를 평가해 기존 PDU Session을 고르거나 새 세션을 요청하며, AMF·SMF·UPF의 세션 절차가 뒤따른다. 이는 설명용 흐름이며 실제 3GPP 메시지 시퀀스나 장비 토폴로지가 아니다.

• A1. 후보와 요청UE가 Configured NSSAI, 이전 허용 정보와 정책 필요를 바탕으로 Requested NSSAI를 구성한다.
• A2. 가입·가용성 대조AMF가 UDM의 Subscribed S-NSSAIs를 확인하고 필요하면 NSSF에 현재 영역의 slice·AMF 선택 정보를 질의한다.
• A3. 등록 결과AMF가 Allowed NSSAI와 필요한 Rejected 정보를 UE에 통지한다. 이 단계는 앱별 데이터 경로를 아직 만들지 않는다.
• B1. 트래픽 감지UE가 새 앱 또는 트래픽을 URSP의 우선순위 높은 rule부터 traffic descriptor와 대조한다.
• B2. 경로 후보 평가일치한 rule의 Route Selection Descriptor를 순서대로 검사하고 S-NSSAI가 Allowed 범위인지, DNN·access 등 조건이 유효한지 본다.
• B3. 기존 세션 우선 확인RSD 조건을 모두 만족하는 기존 PDU Session이 있으면 그 세션에 트래픽을 연결한다.
• B4. 새 세션 요청맞는 세션이 없으면 UE가 RSD의 S-NSSAI·DNN·PDU Session type·SSC mode 등을 이용해 새 PDU Session을 요청한다.
• B5. 망의 세션 처리AMF가 S-NSSAI와 DNN 등을 이용해 SMF를 선택하고, SMF가 가입·정책을 확인해 UPF를 선택·제어한 뒤에야 사용자 평면 경로가 완성된다.

URSP는 앱의 요구와 세션 경로 사이의 정책표다

3GPP TS 23.503의 URSP rule에는 rule precedence, Traffic Descriptor, 하나 이상의 Route Selection Descriptor(RSD)가 들어간다. Traffic Descriptor는 어떤 트래픽에 rule을 적용할지를 식별한다. Application Descriptor의 OSId와 OSAppId, IP tuple, destination domain, DNN, non-IP descriptor, connection capabilities 같은 요소를 사용할 수 있다.

Application Descriptor가 있다는 말은 모든 앱 개발자에게 S-NSSAI를 직접 선택하는 공통 API가 열린다는 뜻이 아니다. 3GPP는 OS와 앱 식별자의 구조를 정의하지만 앱이 category를 OS에 알리는 구체적인 방식과 상용 단말의 공개 API는 규격 범위 밖에 둔다. 실제로는 OS가 앱과 트래픽을 식별하고 modem의 5GS·URSP 기능과 연계할 수 있어야 하며, 사업자의 policy provisioning도 그 식별자와 맞아야 한다.

RSD는 일치한 트래픽이 사용할 경로 조건을 담는다. Network Slice Selection 항목의 S-NSSAI, DNN Selection, SSC Mode Selection, PDU Session Type Selection, Preferred Access Type과 Multi-Access Preference 등이 대표적이다. 하나의 rule에 여러 RSD가 우선순위 순으로 들어갈 수 있고, 한 RSD 안에도 대체 가능한 값 목록이 있을 수 있다.

UE는 새 앱 트래픽을 감지하면 precedence가 높은 URSP rule부터 Traffic Descriptor를 대조한다. 일치한 rule에서 유효한 RSD를 찾고, 그 RSD의 모든 조건을 만족하는 기존 PDU Session이 있는지 먼저 확인한다. 맞는 세션이 여러 개라면 어느 것을 택할지는 UE 구현의 영역이다. 기존 세션이 없으면 RSD에서 정한 S-NSSAI, DNN, PDU Session type, SSC mode 등을 사용해 새 PDU Session을 요청한다.

URSP가 앱의 요청을 그대로 승인하는 것은 아니다. 앱이나 OS가 connection capability 같은 선호를 표현할 수는 있지만, provisioned URSP rule을 임의로 바꾸거나 그 rule에 적힌 PDU Session 속성을 덮어쓸 수는 없다. 선택한 S-NSSAI는 Allowed NSSAI와 정합돼야 하고, DNN과 세션 속성도 가입·망 정책·현재 access 조건을 통과해야 한다.

PCF의 정책 전달과 SMF·UPF 제어는 다른 층이다

URSP는 UE policy의 일부다. 3GPP TS 23.503과 TS 23.502의 UE Configuration Update 절차에서 PCF는 URSP를 포함한 UE Policy Container를 AMF에 보낸다. AMF는 이를 N1 메시지로 UE에 투명하게 전달한다. UE의 응답도 AMF를 거쳐 PCF로 돌아간다. AMF는 이 정책 내용을 앱별로 다시 해석하거나 수정하는 주체가 아니다.

네트워크에서 signalled URSP가 제공되면 단말의 preconfigured policy보다 우선한다. signalled rule이 없을 때는 USIM에 사전 구성된 URSP와 ME에 저장된 정책 사이에도 규격이 정한 우선순위가 적용된다. 다만 USIM에 rule이 있다는 사실과 가입자가 해당 slice를 구독한다는 사실은 별개다. policy 저장 위치와 UDM의 subscription authorization을 혼동해서는 안 된다.

UE가 새 PDU Session Establishment Request를 보내면 세션 제어 단계가 시작된다. AMF는 요청의 S-NSSAI와 DNN, 가입 관련 정보를 이용해 적절한 SMF를 선택한다. SMF는 세션 관리 가입 데이터와 정책을 확인하고, 필요한 UPF를 선택한 뒤 N4 규칙을 설치해 사용자 평면을 제어한다. 따라서 “PCF가 URSP를 내려주면 곧바로 특정 UPF로 패킷이 간다”는 설명은 중간 절차를 생략한 것이다.

독자용으로 단순화하면 PCF는 단말이 적용할 경로 정책을 제공하고, UE는 그 정책으로 세션 후보를 고르며, AMF는 등록·이동성과 SMF 연결을, SMF는 PDU Session과 UPF 제어를, UPF는 사용자 평면 실행을 맡는다. 실제 규격에는 roaming, home-routed session, NSSF 분기, 정책 갱신, 인증, 다중 access 같은 세부 절차가 더 있다. 이 단순화는 역할 관계를 설명하기 위한 것이며 메시지 순서를 대체하지 않는다.

표준 지원과 상용 단말의 노출은 같은 말이 아니다

표준의 UE는 단일 소프트웨어가 아니다. OS의 앱·트래픽 식별, modem의 NAS·PDU Session·URSP 처리, USIM 또는 ME의 preconfiguration, 가입 데이터와 사업자 provisioning이 맞물린다. 단말 capability가 관련 5GS 기능을 지원하고 policy를 저장·평가할 수 있어야 하며, OS는 그 결과에 맞게 트래픽을 올바른 네트워크 인터페이스나 PDU Session에 바인딩해야 한다.

USIM은 preconfigured URSP를 보관하는 한 위치가 될 수 있지만, USIM만 바꾼다고 모든 단말에서 동일한 동작이 보장되지는 않는다. modem firmware가 필요한 NAS와 policy 기능을 처리해야 하고, OS가 앱 식별과 routing을 통합해야 한다. 반대로 modem이 규격 기능을 지원해도 사업자가 가입 권한, Configured NSSAI, URSP, DNN과 망 측 구성을 제공하지 않으면 해당 서비스는 성립하지 않는다.

3GPP 규격 지원을 소비자용 설정 화면이나 앱 개발자용 공개 API 지원과 동일시해서도 안 된다. 표준은 UE 동작과 policy 정보 요소를 정의하지만, 특정 OS가 일반 앱에 어떤 API를 공개하는지, 어떤 단말 모델이 어느 사업자 설정에서 기능을 활성화하는지는 제품·사업자별 현재 근거로 확인해야 한다. 공식 근거 없이 “모든 5G SA 스마트폰이 앱별 slice를 고를 수 있다”고 일반화할 수 없다.

사용할 수 없을 때의 결과는 하나가 아니다

slice를 사용할 수 없다는 상황부터 구분해야 한다. 등록 단계에서 Requested S-NSSAI가 가입돼 있지 않거나 현재 영역에서 제공되지 않으면 AMF는 이를 Allowed NSSAI에 넣지 않고 Rejected S-NSSAI와 원인을 줄 수 있다. 원인과 적용 범위가 PLMN인지 Registration Area인지 등에 따라 UE가 다시 요청할 수 있는 조건도 달라진다.

등록은 됐지만 특정 RSD의 조건을 만족하는 기존 PDU Session이 없을 수도 있다. 이때 UE는 새 세션을 요청한다. 망이 그 PDU Session을 거절하면 UE는 URSP에 남아 있는 다른 값, 다음 RSD 또는 다음으로 일치하는 rule을 규격 조건에 따라 평가할 수 있다. 대체 후보가 없다면 해당 트래픽은 연결되지 않을 수 있다.

일반 인터넷 같은 기본 경로로 돌아가는 것도 자동 보편 규칙이 아니다. 모든 트래픽에 일치하는 `match-all` rule과 유효한 기본 DNN·S-NSSAI 경로가 provision돼 있다면 그 경로를 사용할 수 있다. 반대로 정책이 특정 앱의 전용 경로만 허용하거나 대체 RSD가 없으면 거절이 맞는 동작일 수 있다. fallback, reject, 기본 경로 사용은 상품 의도가 아니라 실제 URSP와 가입·망 정책에 의해 구분해야 한다.

이 차이는 고객 설명에도 중요하다. “slice가 안 되면 알아서 일반망으로 간다”는 문구는 보안·업무 분리 의도가 있는 B2B 서비스에는 위험할 수 있다. 반대로 소비자 앱에서 무조건 연결을 끊는 동작도 서비스 설계와 다를 수 있다. 사업자는 어떤 원인에 어떤 대체 경로를 허용하고 사용자에게 무엇을 알릴지 명시해야 한다. 이는 선택 절차를 넘어선 상품·운영 설계이며, 이번 글은 보편적 정답을 가정하지 않는다.

두 가지 조건부 예시

개인방송 앱을 쓰는 B2C 이용자를 가정해 보자. 사업자가 특정 장소와 시간에 업로드용 서비스를 설계했고, 이용자의 가입 정보에 해당 S-NSSAI와 DNN 권한이 들어 있으며, 현재 영역의 Allowed NSSAI에도 그 slice가 포함돼 있어야 한다. OS가 방송 앱 또는 해당 업로드 트래픽을 Traffic Descriptor와 맞춰 식별하고, URSP의 RSD가 기존 세션 또는 새 PDU Session으로 연결해야 한다. 단말·modem 지원과 RAN·전송·코어·애플리케이션 용량까지 준비돼야 이용자가 차이를 체감할 수 있다. 이는 가능한 선택 흐름의 예이며 현재 상용 성공이나 수익 성과를 주장하지 않는다.

B2B 공장의 관리형 단말에서 영상 검사 앱을 기업용 slice와 전용 DNN에 연결하는 경우도 생각할 수 있다. 기업 가입 정보와 단말 provisioning, 공장 영역의 slice 가용성, 앱 식별자와 URSP가 먼저 일치해야 한다. Allowed NSSAI 안의 S-NSSAI를 사용해 기존 기업용 PDU Session을 찾거나 새 세션을 수립하고, SMF가 적절한 UPF와 정책을 적용해야 트래픽이 기업 데이터망으로 간다. 대체 경로가 보안 정책에 맞지 않으면 일반 인터넷 fallback을 두지 않고 연결을 거절하도록 설계할 수도 있다. 이것 역시 조건부 구조 예시이며 실제 공장의 품질 보장이나 상용 성과를 뜻하지 않는다.

두 사례에서 Network Slice 선택은 고객 체감의 시작점일 뿐이다. 선택이 성공해도 모든 구간의 성능과 SLA가 자동으로 보장되지는 않는다. 반대로 선택 절차가 모호하면 아무리 좋은 무선·코어 자원이 있어도 원하는 앱 트래픽이 그 경로에 들어가지 못한다. 종단간 보장과 운영 책임은 별도의 주제지만, 최소한 “누가 어떤 조건으로 어느 세션을 쓰게 하는가”가 먼저 명확해야 한다.

핵심 요약

• S-NSSAI의 SST와 선택적 SD는 Network Slice를 식별하며 5QI 같은 QoS 등급이 아니다.
• Configured NSSAI는 단말의 후보 구성, Requested NSSAI는 UE의 등록 요청, Subscribed S-NSSAI는 가입 권한, Allowed NSSAI는 현재 등록 문맥에서 망이 허용한 목록이다.
• Registration은 사용할 수 있는 slice 범위를 정한다. 앱 트래픽 경로는 그다음 URSP 평가와 PDU Session 수립에서 정해진다.
• URSP는 Traffic Descriptor로 트래픽을 식별하고 RSD의 S-NSSAI·DNN·세션 조건으로 기존 PDU Session을 찾거나 새 세션을 요청하게 한다.
• PCF의 UE policy는 AMF를 거쳐 UE에 투명 전달된다. AMF의 SMF 선택과 SMF의 UPF 선택·제어는 세션 수립 단계에서 이어진다.
• OS·modem·USIM/ME 구성, 가입 권한, 단말 capability와 사업자 provisioning이 함께 맞아야 한다. 표준 지원은 소비자 설정이나 공개 앱 API 지원을 자동 의미하지 않는다.
• fallback, reject, 기본 경로 사용은 Rejected 원인과 URSP의 대체 RSD·rule, 가입·망 정책에 따라 달라지며 하나의 보편 동작으로 일반화할 수 없다.

출처 및 참고자료

• 3GPP TS 23.501, System architecture for the 5G System
• 3GPP TS 23.502, Procedures for the 5G System
• 3GPP TS 23.503, Policy and charging control framework for the 5G System
• ETSI TS 123 501 V18.12.0, 3GPP Release 18 배포본
• ETSI TS 123 502 V18.14.0, 3GPP Release 18 배포본
• ETSI TS 123 503 V18.12.0, 3GPP Release 18 배포본
• GSMA NG.141, Guidelines for URSP
• GSMA TS.62, UE Requirements related to network slicing using URSP

이미지 설명: 스마트폰의 여러 앱 트래픽이 권한·정책을 상징하는 투명한 관문을 지난 뒤 하나의 논리 경로와 세션으로 이어지는 모습을 표현한 독창적 개념 이미지다. 실제 3GPP 메시지 시퀀스, Network Function 배치, 장비 토폴로지 또는 품질 보장을 나타내지 않는다.