| 앞선 Part 13에서 NAS/AS 보안과 키 계층을 봤다면, 이제 UE는 단순히 “5G망에 붙었다”에서 한 단계 더 나아가야 합니다. 같은 5G망이라도 스마트폰 데이터, 산업용 단말, 초저지연 제어, 사설망 서비스가 모두 같은 코어망 정책을 쓰지는 않습니다. 이때 등장하는 개념이 Network Slicing입니다. 이번 글에서는 NSSAI, S-NSSAI, SST, SD가 Registration과 PDU Session Establishment에서 어떻게 보이는지 로그 흐름에 가깝게 정리합니다. |
작성 기준: 2026-05-12 · 3GPP TS 23.501/23.502/24.501/23.003/38.331 기준으로 학습용 설명을 덧붙였습니다.
핵심 요약
| 한 줄로 잡으면 Network Slicing은 “UE가 어떤 서비스용 5GC 경로를 사용할지”를 정하는 절차이고, 그 선택 정보가 NAS Registration과 PDU Session Establishment 메시지 안에서 NSSAI, S-NSSAI라는 이름으로 오갑니다. |
1. Network Slicing이 필요한 이유
LTE에서는 APN 단위로 서비스망을 나누는 설명이 비교적 익숙했습니다.
5G에서는 그보다 한 단계 더 구조화된 방식으로, 같은 기지국과 같은 5GC 인프라를 쓰더라도 서비스별로 제어 평면, 사용자 평면, 정책, 과금, 품질 목표를 다르게 가져갈 수 있도록 Network Slice 개념을 사용합니다.
예를 들어 일반 스마트폰 인터넷 트래픽은 대역폭과 평균 품질이 중요합니다.
반면 공장 자동화나 원격 제어 서비스는 지연과 신뢰성이 더 중요할 수 있습니다.
또 대규모 IoT 단말은 단말 수와 전력 효율, 신호 부하가 더 중요한 기준이 됩니다.
이 요구사항을 모두 같은 정책으로 처리하면 운영이 거칠어집니다.
| 실무적으로는 “Slice가 있으니 무조건 무선 구간에서 전용 자원이 생긴다”라고 이해하면 위험합니다. Slice는 E2E 논리망을 식별하고 선택하기 위한 틀이며, 실제 무선 자원 분리·우선순위·보장은 사업자 정책, RAN 구현, QoS 설정, 코어망 구성까지 같이 봐야 합니다. |
2. S-NSSAI, SST, SD, NSSAI 용어 정리
Slice를 공부할 때 가장 먼저 헷갈리는 부분은 이름입니다.
NSSAI와 S-NSSAI가 비슷하게 생겼기 때문입니다.
간단히 말하면 S-NSSAI는 Slice 하나를 가리키는 식별자이고, NSSAI는 S-NSSAI들의 목록입니다.
| 용어 | 의미 | 로그에서 볼 때의 감각 |
| S-NSSAI | Single Network Slice Selection Assistance Information. 하나의 Network Slice를 식별하기 위한 정보입니다. | “이 PDU Session은 어느 Slice로 갈 것인가?”를 볼 때 핵심 필드입니다. |
| SST | Slice/Service Type. Slice가 기대하는 서비스 특성의 큰 분류입니다. | eMBB, URLLC, MIoT, V2X 같은 서비스 타입 구분으로 이해하면 쉽습니다. |
| SD | Slice Differentiator. 같은 SST 안에서 사업자나 서비스별로 더 세분화하기 위한 선택 정보입니다. | 같은 eMBB라도 기업 고객, 사설망, 특정 상품군을 나눌 때 사용될 수 있습니다. |
| NSSAI | Network Slice Selection Assistance Information. 하나 이상의 S-NSSAI 목록입니다. | UE가 요청하거나 네트워크가 허용하는 Slice 후보 목록처럼 보입니다. |
| DNN | Data Network Name. LTE의 APN과 비슷한 위치에서 데이터망을 구분합니다. | PDU Session에서 S-NSSAI와 함께 SMF/UPF/정책 선택에 영향을 줍니다. |
| S-NSSAI를 실제로 읽는 법 S-NSSAI = SST + optional SD로 보면 됩니다. 예를 들어 SST가 eMBB 계열이고 SD가 특정 기업 고객용 값을 가진다면, “일반 eMBB가 아니라 그 고객에게 할당된 eMBB Slice”처럼 구분할 수 있습니다. |
SST 대표 분류
| SST 예시 | 대표 서비스 이미지 | 주의할 점 |
| eMBB | 고속 데이터, 영상, 일반 모바일 브로드밴드 | 대역폭 중심으로 생각하기 쉽지만 실제 QoS는 5QI/ARP/정책과 같이 봐야 합니다. |
| URLLC | 초저지연·고신뢰 제어, 산업 자동화 | Slice 이름만 URLLC라고 해서 RAN 지연 보장이 자동으로 끝나는 것은 아닙니다. |
| MIoT | 대량 IoT 단말, 센서 네트워크 | 접속 빈도, 시그널링 부하, 전력 절감 정책이 중요해집니다. |
| V2X | 차량 통신, 교통 인프라 연동 | 지역성, 이동성, 정책 제어가 함께 맞아야 의미가 있습니다. |
3. Configured/Requested/Allowed/Rejected NSSAI
NSSAI는 하나의 고정된 목록만 있는 것이 아닙니다.
UE가 가지고 있는 설정, UE가 요청하는 목록, 네트워크가 최종 허용하는 목록이 단계별로 나뉩니다.
이 차이를 이해하지 못하면 로그에서 “분명 UE는 Slice를 요청했는데 왜 세션이 안 붙지?” 같은 상황을 해석하기 어렵습니다.
| 구분 | 어디서 의미가 큰가 | 설명 |
| Configured NSSAI | UE 설정/가입자 정보 | UE가 사용할 수 있도록 사전에 구성된 Slice 정보입니다. USIM/단말 설정/네트워크 제공 정보와 연결됩니다. |
| Requested NSSAI | Registration Request | UE가 이번 등록에서 사용하고 싶다고 네트워크에 전달하는 Slice 목록입니다. |
| Allowed NSSAI | Registration Accept | 네트워크가 현재 PLMN/TA/가입자 조건에서 허용한 Slice 목록입니다. |
| Rejected NSSAI | Registration Accept 또는 reject 관련 정보 | 요청했지만 허용되지 않은 Slice와 그 원인을 분석할 때 봅니다. |
| Default Configured NSSAI | UE 초기 설정 | 명시적 설정이 없거나 초기 동작에서 사용할 수 있는 기본 Slice 후보로 이해하면 됩니다. |
4. Registration 절차에서 Slice가 선택되는 흐름
UE가 5G망에 등록할 때, NAS Registration Request 안에는 필요에 따라 Requested NSSAI가 포함될 수 있습니다.
UE 입장에서는 “내가 이번에 사용하려는 Slice 후보는 이것입니다”라고 알리는 셈입니다.
네트워크는 이 정보를 그대로 받아들이지 않습니다.
가입자 정보, 현재 PLMN, Tracking Area, 로밍 여부, 사업자 정책, Slice 가용성 등을 보고 최종적으로 Allowed NSSAI를 결정합니다.
이 과정에서 AMF가 단독으로 판단하는 것처럼 보일 때도 있지만, 실제 구조에서는 UDM의 가입자 데이터, NSSF의 Slice 선택 기능, NRF 기반 NF discovery, PCF 정책 등이 함께 얽힐 수 있습니다.
Registration 기준 흐름
- UE는 PLMN을 선택하고 RRC/NAS 초기 접속을 시작합니다.
- UE가 Registration Request를 보내며 필요한 경우 Requested NSSAI를 포함합니다.
- gNB는 NAS 메시지를 AMF로 전달합니다. RAN이 Slice 정보를 참고할 수 있는 구성도 있지만, 최종 가입자 허용 판단은 5GC 쪽에서 이뤄집니다.
- AMF는 가입자 정보와 Slice selection 정보를 확인합니다. 필요하면 NSSF를 통해 허용 가능한 Slice와 적절한 AMF set 관련 정보를 얻습니다.
- 네트워크는 Registration Accept에서 Allowed NSSAI를 내려줄 수 있습니다.
- 허용되지 않은 Slice가 있으면 Rejected NSSAI나 이후 PDU Session Reject 원인으로 드러납니다.
| 로그에서 자주 보이는 오해 Registration Request에 Requested NSSAI가 보였다고 해서 그 Slice가 최종 사용된 것은 아닙니다. 실제로는 Registration Accept의 Allowed NSSAI와 PDU Session Establishment 단계의 S-NSSAI를 같이 확인해야 합니다. |
5. PDU Session Establishment와 S-NSSAI + DNN
Registration이 “이 UE가 현재 어떤 Slice 후보를 사용할 수 있는가”를 정리하는 단계라면, PDU Session Establishment는 “실제 데이터 세션을 어느 Slice와 어느 데이터망으로 붙일 것인가”를 결정하는 단계입니다.
이때 핵심 조합은 S-NSSAI + DNN입니다. 같은 Slice라도 DNN이 다르면 다른 데이터망으로 나갈 수 있고, 같은 DNN이라도 Slice가 다르면 다른 SMF/UPF/정책으로 처리될 수 있습니다.
| 입력 정보 | 선택에 영향을 주는 대상 | 확인 포인트 |
| S-NSSAI | Slice 인스턴스, AMF/SMF 후보, 정책 영역 | Allowed NSSAI 안에 포함된 S-NSSAI인지 확인합니다. |
| DNN | 데이터망, UPF 경로, IP 주소 할당 정책 | 가입자에게 해당 DNN 사용 권한이 있는지 확인합니다. |
| Subscription Data | 허용 Slice, 허용 DNN, 기본값 | UDM/UDR 쪽 가입자 프로파일과 실제 UE 요청이 맞는지 봅니다. |
| Policy | QoS, 과금, 접속 제한 | PCF 정책이나 SMF local policy가 세션 수락을 막지 않는지 봅니다. |
| Location/TA | Slice availability | 현재 Tracking Area에서 해당 Slice가 제공되는지 확인합니다. |
실제 장애 분석에서 중요한 질문
Slice 장애는 단순히 “NSSAI가 맞는가?”로 끝나지 않습니다. 아래 질문을 같이 던져야 합니다.
- UE가 요청한 S-NSSAI가 가입자에게 허용되어 있는가?
- 해당 S-NSSAI가 현재 PLMN/TA에서 제공되는가?
- DNN이 해당 Slice와 연결되어 있는가?
- SMF discovery가 해당 S-NSSAI/DNN 조건으로 성공했는가?
- UPF 선택, IP allocation, policy association까지 정상 진행됐는가?
6. RAN 관점의 Slice: gNB는 무엇을 알고 무엇을 보장하지 않는가
Network Slicing을 말하면 흔히 “기지국에서 Slice별로 자원을 딱 나눠 주는 것”을 먼저 떠올립니다.
하지만 표준 절차를 로그로 보면 시작점은 대개 NAS Registration과 PDU Session 쪽입니다.
gNB는 UE의 NAS 메시지를 AMF로 전달하고, NGAP/RRC/무선 베어러 설정을 통해 Slice 관련 컨텍스트를 일부 다룰 수 있습니다.
다만 이것이 곧바로 “무선 PRB가 Slice별로 고정 분할된다”는 뜻은 아닙니다.
RAN slicing을 실제로 어떻게 구현할지는 벤더 기능, 사업자 정책, QoS Flow, 5QI, ARP, 스케줄러 정책, admission control과 함께 결정됩니다.
그래서 Slice 분석은 반드시 QoS 분석과 분리해서 보면 안 됩니다.
| 관점 | Slice와의 관계 | 분석 팁 |
| RRC | UE capability, NAS 전달, 일부 S-NSSAI 관련 IE와 연결될 수 있습니다. | RRC만 보고 Slice 성공/실패를 단정하지 않습니다. |
| NGAP | AMF와 gNB 사이에서 UE context, PDU session resource setup, QoS Flow 정보를 전달합니다. | NGAP PDU Session Resource Setup 쪽에서 S-NSSAI/QoS 연계를 확인합니다. |
| PDCP/SDAP | QoS Flow와 DRB 매핑으로 사용자 데이터 처리 경로가 구체화됩니다. | Part 7~9의 QoS Flow/DRB 매핑과 같이 봐야 합니다. |
| Scheduler | 구현과 정책에 따라 Slice별 우선순위나 자원 관리가 들어갈 수 있습니다. | 표준 메시지만으로 실제 스케줄링 보장 수준을 알기 어렵습니다. |
7. Roaming에서 Mapped S-NSSAI가 나오는 이유
로밍 상황에서는 HPLMN과 VPLMN이 같은 Slice 식별 체계를 쓰지 않을 수 있습니다.
가입자는 홈망 기준 Slice를 가지고 있지만, 방문망에서는 그에 대응하는 Slice를 별도 값으로 운영할 수 있습니다.
이때 Mapped S-NSSAI 개념이 등장합니다.
쉽게 말하면 “홈망의 이 Slice는 방문망에서는 저 Slice에 매핑해서 쓰자”라는 번역표에 가깝습니다.
로밍 로그에서 S-NSSAI가 기대와 다르게 보일 때는, 실제 값이 틀린 것인지 아니면 mapped value를 보고 있는 것인지 구분해야 합니다.
| 로밍 분석 포인트 HPLMN S-NSSAI, VPLMN S-NSSAI, mapped S-NSSAI, allowed NSSAI for roaming을 분리해서 봐야 합니다. 특히 PDU Session Establishment Accept에서 내려오는 값과 Registration Accept의 allowed/mapped 정보를 같이 보는 것이 좋습니다. |
8. Slice 관련 실패 원인
Slice 장애는 단말, RAN, AMF, NSSF, UDM, SMF, UPF, PCF 중 어디에서든 시작될 수 있습니다.
그래서 메시지 하나만 보고 결론을 내리기보다, “어느 단계에서 어떤 값이 바뀌었는지”를 따라가는 방식이 안전합니다.
| 증상 | 가능한 원인 | 먼저 확인할 로그 |
| Registration은 성공하지만 원하는 Slice가 없음 | Requested NSSAI 미포함, subscription 불일치, TA에서 Slice 미제공, NSSF 결과 불일치 | Registration Request / Registration Accept / Allowed NSSAI / Rejected NSSAI |
| PDU Session Establishment Reject | S-NSSAI+DNN 조합 미허용, SMF discovery 실패, DNN 미가입, policy 제한 | PDU Session Establishment Request/Reject, SMF selection log, UDM subscription |
| 로밍에서만 실패 | Mapped S-NSSAI 설정 누락, VPLMN Slice availability 문제, 로밍 계약/정책 불일치 | Registration Accept의 mapped 정보, roaming subscription, NSSF response |
| 세션은 성공하지만 품질이 기대와 다름 | Slice 선택은 성공했지만 QoS Flow/5QI/ARP/스케줄러 정책이 기대와 다름 | PDU Session Resource Setup, QoS Rules, SDAP mapping, RAN scheduler counters |
| 특정 지역에서만 Slice 사용 불가 | TA 또는 cell 단위 Slice availability 설정 차이, AMF set/NSSF 구성 차이 | TAI, AMF selection, NSSF allowed NSSAI, gNB/AMF config |
| 장애 원인을 빠르게 좁히는 기준 Registration Accept에 Allowed NSSAI가 없다면 Mobility Management/가입자/Slice availability 쪽부터 보고, Allowed NSSAI는 있는데 PDU Session만 실패하면 Session Management/SMF/DNN/Policy 쪽부터 보는 것이 보통 더 빠릅니다. |
9. 로그 분석 시 확인 포인트
아래 순서대로 보면 Slice 관련 문제를 비교적 깔끔하게 따라갈 수 있습니다.
특히 UE 로그, AMF 로그, SMF 로그를 동시에 볼 수 있다면 S-NSSAI 값이 어디서 바뀌는지 확인하는 것이 핵심입니다.
1) UE/NAS 로그
- Registration Request에 Requested NSSAI가 포함되어 있는지
- Registration Accept의 Allowed NSSAI가 기대한 S-NSSAI를 포함하는지
- Rejected NSSAI와 cause가 있는지
- PDU Session Establishment Request의 S-NSSAI와 DNN 조합이 맞는지
- PDU Session Establishment Accept/Reject에서 최종 세션 정보와 cause를 확인
2) AMF/NSSF/UDM 로그
- AMF가 UE subscription data를 어떤 값으로 받았는지
- NSSF query/response에서 allowed NSSAI와 AMF set 정보가 어떻게 나왔는지
- 현재 TAI에서 해당 Slice가 available로 판단되었는지
- 로밍이면 mapped S-NSSAI가 정상 적용되었는지
3) SMF/UPF/PCF 로그
- S-NSSAI+DNN 조건으로 SMF selection 또는 SMF handling이 정상인지
- UDM의 session management subscription이 DNN/S-NSSAI를 허용하는지
- PCF policy association이 실패하지 않는지
- UPF selection과 N4 session setup이 정상인지
- QoS Rule, QoS Flow, 5QI, ARP가 기대한 정책과 일치하는지
[Slice 분석용 최소 체크 예시]
1. Registration Request
- Requested NSSAI = ?
2. Registration Accept
- Allowed NSSAI = ?
- Rejected NSSAI = ?
3. PDU Session Establishment Request
- S-NSSAI = ?
- DNN = ?
4. PDU Session Establishment Accept / Reject
- selected/accepted S-NSSAI = ?
- cause = ?
5. Core internal log
- UDM subscription match?
- NSSF allowed NSSAI result?
- SMF discovery result?
- PCF/UPF setup result?
FAQ
Q1. Network Slice와 DNN은 같은 개념인가요?
아닙니다. Slice는 서비스 특성이나 논리망 선택을 위한 개념이고, DNN은 데이터망 이름입니다. 실제 PDU Session에서는 S-NSSAI와 DNN 조합을 함께 봐야 합니다.
Q2. UE가 Requested NSSAI를 보내면 반드시 그 Slice를 사용할 수 있나요?
아닙니다. UE는 요청할 수 있지만, 최종 허용 여부는 가입자 정보, 현재 위치, PLMN, NSSF/AMF 판단, 사업자 정책에 따라 결정됩니다.
Q3. Allowed NSSAI가 있으면 PDU Session도 무조건 성공하나요?
그렇지 않습니다. Allowed NSSAI는 등록 관점에서 허용된 Slice 목록입니다. PDU Session은 추가로 DNN, SMF 선택, 가입자 세션 정보, 정책, UPF 자원까지 맞아야 성공합니다.
Q4. S-NSSAI는 어떤 필드로 구성되나요?
S-NSSAI는 SST와 선택적인 SD로 구성됩니다. SST는 Slice/Service Type이고, SD는 같은 SST 안에서 더 세부적인 Slice를 구분하는 값입니다.
Q5. Slice를 쓰면 무선 자원이 자동으로 보장되나요?
자동 보장으로 보면 안 됩니다. Slice 선택과 무선 자원 보장은 연결될 수 있지만, 실제 보장은 QoS Flow, 5QI, ARP, RAN scheduler, admission control, 사업자 정책에 달려 있습니다.
Q6. 로밍에서 Mapped S-NSSAI는 왜 필요한가요?
홈망과 방문망이 같은 Slice 식별 값을 쓰지 않을 수 있기 때문입니다. 홈망의 S-NSSAI를 방문망에서 대응되는 S-NSSAI로 매핑하기 위해 사용됩니다.
Q7. Slice 장애를 볼 때 가장 먼저 봐야 하는 메시지는 무엇인가요?
Registration Request의 Requested NSSAI, Registration Accept의 Allowed/Rejected NSSAI, 그리고 PDU Session Establishment Request의 S-NSSAI+DNN을 먼저 봅니다.
Q8. eMBB, URLLC, MIoT는 반드시 서로 다른 코어망 장비를 쓰나요?
반드시 그렇지는 않습니다. 논리적으로 분리될 수 있지만 실제 배치는 사업자 설계에 따라 공유 NF를 쓰거나 전용 NF를 둘 수 있습니다.
3GPP 공식 참고자료
아래 문서는 본문 작성 시 기준으로 삼은 3GPP 공식 Specification 페이지입니다.
실제 구현이나 릴리스별 세부 동작은 사용 중인 Release와 벤더 구현 문서를 함께 확인하는 것이 좋습니다.
- 3GPP TS 23.501 - System architecture for the 5G System (5GS)
- 3GPP TS 23.502 - Procedures for the 5G System (5GS)
- 3GPP TS 24.501 - Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3
- 3GPP TS 23.003 - Numbering, addressing and identification
- 3GPP TS 38.331 - NR; Radio Resource Control (RRC); Protocol specification
다음 편으로 이어간다면 Part 15에서는 5G NR Dual Connectivity, EN-DC/NR-DC, SCG, Split Bearer 흐름을 다루기 좋습니다.
Network Slicing이 “어떤 서비스 경로를 쓸 것인가”라면, Dual Connectivity는 “무선 구간에서 여러 노드를 어떻게 함께 쓸 것인가”와 연결됩니다.
'Wireless > Protocol' 카테고리의 다른 글
| [Protocol] 5G NR Fundamental - Part 16 (0) | 2026.05.31 |
|---|---|
| [Protocol] 5G NR Fundamental - Part 15 (0) | 2026.05.28 |
| [Protocol] 5G NR Fundamental - Part 13 (0) | 2026.05.26 |
| [Protocol] 5G NR Fundamental - Part 12 (0) | 2026.05.25 |
| [Protocol] 5G NR Fundamental - Part 11 (0) | 2026.05.24 |