규격 표에서 PUT과 PATCH의 Description 문구는 원문 그대로 동일하다. 실제 차이는 Request Body 타입(NssaiAvailabilityInfo vs PatchDocument)으로만 구분된다.
또 Store 리소스만 {apiVersion} 대신 v1이 하드코딩돼 있는데 이것도 원문 그대로다.
3.3 Update — PUT (전체 교체/생성)
요청 NssaiAvailabilityInfo
속성
타입
P
개수
역할
supportedNssaiAvailabilityData
array(SupportedNssaiAvailabilityData)
M
1..N
AMF·5G-AN이 TA별로 지원하는 S-NSSAI
supportedFeatures
SupportedFeatures
O
0..1
선택 기능 협상 (이 버전은 정의된 기능 없음)
amfSetId
string
O
0..1
특정 AMF Set 정보일 때
응답 AuthorizedNssaiAvailabilityInfo (200 OK) — NSSF가 인정한 현재 최종 상태. 사업자 정책 결과가 여기 담긴다.
왜 JSON Patch? TS 29.501 §4.6.1.1.3.2: 부분 교체는 PATCH, 배열의 개별 요소를 고쳐야 하면 JSON Patch(RFC 6902) shall. Availability 정보는 TA 배열 → S-NSSAI 배열 구조라 한 TA의 S-NSSAI 하나만 바꾸려면 JSON Patch가 필요하다 (이 “이유”는 규격 직접 문장이 아니라 29.501 규칙을 적용한 해석).
구독 수정/연장 오퍼레이션은 없다 (POST/DELETE만). 만료되면 새로 구독해야 한다. NSSF는 같은 만료 시각을 여러 구독에 주지 않아야 한다(동시 재구독 몰림 방지). 응답에 expiry가 없으면 만료 없는 구독으로 간주.
콜백 주소를 넣는 이유: 알림은 NSSF가 HTTP 클라이언트, AMF가 서버가 되는 방향이라 NSSF가 어디로 보낼지 알아야 한다 (TS 29.501 §4.6.2.1).
Unsubscribe — DELETE .../subscriptions/{subscriptionId}, body 없음, 204.
Delete(대상 nfId, 가용성 정보 삭제)와 달리 알림 약속만 끊고 정보는 그대로.
Notify — POST {nfNssaiAvailabilityUri} (NSSF → AMF), 성공 204
속성 (NssfEventNotification)
P
역할
subscriptionId
M
어느 구독 때문에 온 알림인지 (구독 여러 개 + 같은 콜백 주소 대비)
authorizedNssaiAvailabilityData
M
구독한 모든 TA의 최신 가용성
⚠️ 배열은 “바뀐 것만”이 아니다. AMF는 이전에 받은 값을 이번 값으로 통째로 교체해야 한다.
3.8 시퀀스 한 장
sequenceDiagram
participant A1 as AMF-1 (구독자)
participant N as NSSF
participant A2 as AMF-2 (다른 AMF)
A1->>N: POST /subscriptions (콜백URI, taiList, event)
N-->>A1: 201 Created (subscriptionId, Location)
A2->>N: PUT/PATCH /nssai-availability/{nfId2}
N-->>A2: 200 OK (Authorized...)
N->>A1: POST {콜백URI} (subscriptionId, 최신 가용성 전체)
A1-->>N: 204 No Content
A1->>N: DELETE /subscriptions/{subscriptionId}
N-->>A1: 204 No Content
4. Nnssf_NSSelection (읽기·안내)
4.1 무엇을 돌려주나 (결과 3가지)
#
결과
필드
1
쓸 수 있는 슬라이스
Allowed NSSAI / Configured NSSAI
2
담당 AMF (지금 AMF가 처리 못할 때)
targetAmfSet / candidateAmfList
3
NRF 주소 (+ 선택 NSI ID)
nsiInformation(nrfId, nsiId)
저장값을 그대로 꺼내 주는 게 아니다. AMF가 보낸 단말 위치(TAI) + 가입/요청 S-NSSAI를 NSSF가 가진 정보와 맞춰 검증·선택·결정한다 (TS 23.501 §5.15.5.2.1 (B)).
가입 정보에 맞는 요청 S-NSSAI 가려냄 → NSI 선택 → target AMF Set/후보 AMF 결정 → 2장의 가용성 반영해 Allowed NSSAI 결정 → 설정에 따라 NRF 결정.
AMF가 항상 NSSF를 부르는 건 아니다. 등록 때 AMF 설정으로 직접 판단 가능하면 묻지 않고, 처리 불가일 때 묻는다. PDU 세션도 AMF가 NRF를 스스로 정할 수 없을 때만 묻는다.
4.2 호출되는 세 상황 (요청은 GET 하나)
GET {apiRoot}/nnssf-nsselection/v2/network-slice-information?{query} (apiVersion v2, OpenAPI 기준)
4.4 응답 AuthorizedNetworkSliceInfo (하나의 구조, 상황별로 채워지는 칸이 다름)
필드
P
의미
주로 쓰이는 상황
allowedNssaiList
C
쓸 수 있는 슬라이스
등록, UE-CU
configuredNssai
C
단말에 설정해 둘 슬라이스
등록, UE-CU
rejectedNssaiInPlmn
O
PLMN에서 거절된 S-NSSAI
등록
rejectedNssaiInTa
O
현재 TA에서 거절된 S-NSSAI
등록
targetAmfSet
O
넘겨줄 AMF Set
등록(재할당)
candidateAmfList
O
넘겨줄 후보 AMF 목록
등록(재할당)
nrfAmfSet
O
AMF Set의 후보 AMF를 찾을 NRF Discovery URI
등록(재할당)
nrfAmfSetNfMgtUri
C
같은 NRF의 NFManagement URI (nrfAmfSet이 있으면 포함 권장)
등록(재할당)
nrfAmfSetAccessTokenUri
O
같은 NRF의 AccessToken URI
등록(재할당)
nsiInformation
C
NRF 주소 + NSI ID
PDU 세션
supportedFeatures
C
선택 기능
-
Configured NSSAI를 같이 주는 조건: 요청에 Requested NSSAI가 없었거나 / 서빙 PLMN에서 유효하지 않은 값이 있었거나 / defaultConfiguredSnssaiInd가 true.
재할당 방법 2가지: ⓐ candidateAmfList 직접 제공, ⓑ targetAmfSet만 주고 AMF가 NRF(NFDiscovery)에 AMF Set으로 질의해 후보 획득. 새 AMF로는 등록 요청을 redirect (후보 리스트일 땐 AMF 간 direct signalling만).
nsiInformation: nrfId(M) = NRF NFDiscovery의 API URI, nsiId(O).
→ NSSF는 SMF를 알려주는 게 아니라 NRF를 알려준다. 이후 AMF가 그 NRF에 S-NSSAI + DNN (+ nsiId)로 SMF를 질의한다. (→ 3GPP NRF 정리 (TS 29.510 Rel-15) NFDiscovery)
nrfAmfSetNfMgtUri를 AMF가 어디에 쓰는지 규격에 명시된 문장은 찾지 못했다 (NFManagement가 NF 상태 구독을 제공하므로 “후보 AMF 상태 구독용”일 수 있다는 추정뿐). 단정 금지.
4.5 응답 코드
코드
의미
200 OK
정상. 조건에 맞는 슬라이스 정보가 없어도 200 + 빈 AuthorizedNetworkSliceInfo (에러 아님!)
수신 측(AMF) 필드가 비어 있다고 오류로 보면 안 된다. 각 필드는 C(조건부)/O(선택)다.
4.6 로밍 (V-NSSF ↔ H-NSSF)
로밍 가입자의 요청은 어느 절차든 먼저 방문망(VPLMN) NSSF가 받는다.
등록 / UE 구성 업데이트: V-NSSF가 홈망과 주고받지 않고 방문망 안에서 Allowed/Configured NSSAI와 홈 S-NSSAI 매핑(mappedHomeSnssai) 을 정한다 (매핑 값은 사업자 SLA 기반으로 V-NSSF에 관리자가 설정. 29.531은 설정 방법까지 다루지 않음).
PDU 세션 — roamingIndication으로 구분
roamingIndication
의미
V-NSSF → H-NSSF 조회
NON_ROAMING
로밍 아님
해당 없음
LOCAL_BREAKOUT
로밍, 방문망에서 PDU 세션 종단
없음 (방문망 NSSF만 호출)
HOME_ROUTED_ROAMING
로밍, 홈망 경유
있음 (옵션 1, V-NSSF에 홈 NRF 정보가 없을 때만)
왜 H-NSSF에 묻나? HR에서는 SMF가 홈망에 있어서, 방문망 AMF가 SMF를 찾으려면 홈망 NRF(hNRF) 를 알아야 한다. 홈 S-NSSAI는 질의에 넣는 값일 뿐, 받아오는 건 매핑이 아니라 hNRF(+NSI ID).
홈망 SMF 선택 방법 2가지는 사업자 SLA로 결정 (TS 23.502 §4.3.2.2.3.3): 옵션 1 = 양쪽 NSSF 사용, 옵션 2 = NSSF 없이 NRF끼리 (홈망에 NSSF가 없을 땐 AMF가 설정으로 hNRF를 알거나 옵션 2 사용).
다른 PLMN의 NSSF는 TS 23.003 규칙으로 자체 구성한 FQDN으로 찾는다 (29.531 §5.2.1).
HR PDU 세션 옵션 1 콜플로우 (TS 23.502 §4.3.2.2.3.3)
sequenceDiagram
participant AMF as AMF (VPLMN)
participant VN as V-NSSF
participant HN as H-NSSF
participant VR as V-NRF
participant HR as H-NRF
AMF->>VN: 1. GET (VPLMN S-NSSAI, HPLMN S-NSSAI, SUPI PLMN ID, TAI, HR 표시)
VN->>HN: 2. GET (홈 S-NSSAI) ※ 홈 NRF 정보가 없을 때만
HN-->>VN: 3. 200 (hNRF, [NSI ID])
VN-->>AMF: 4. 200 (3번 내용 그대로 전달)
AMF->>VR: 5. NF Discovery (PLMN ID, DNN, 홈 S-NSSAI)
VR->>HR: 6. Discovery (대리)
HR-->>VR: 7. SMF 정보
VR-->>AMF: 8. SMF 정보 전달
NSSF의 답은 Availability 하나만으로 만들지 않는다. 단말 요청·가입 정보·로컬 설정·RAN 능력·NWDAF 부하 정보 등 가용한 정보를 함께 쓴다 (TS 23.501 §5.15.5.2.1 (B)). 다만 Availability가 어긋나면 안내도 어긋나므로 구독/알림으로 최신화한다.