Network Slicing — ネットワークスライシング¶
学習目標¶
このページを読み終えると、次のことができるようになります。
- Why(なぜ Network Slicing が必要か)を、1つの物理ネットワークで超高速動画・超低遅延制御・大量IoT を同時に最適化するのは難しい、という用途別最適化の観点で説明できる。
- スライス(Network Slice) が、共通の物理インフラ上に構築された論理的に独立した仮想ネットワークであることを説明できる。
- S-NSSAI(Single NSSAI) が1スライスの識別子であり、SST(Slice/Service Type) と オプションの SD(Slice Differentiator) で構成されることを説明できる。
- NSSAI の4種類(Requested / Allowed / Configured / Subscribed)の違いと関係を区別して説明できる。
- NSSF(Network Slice Selection Function) の役割(AMFが自力で解決できない場合のスライス選択支援、NSSAIAvailability 管理)を説明できる。
- 登録時(UEが Requested NSSAI 提示 → AMFが Allowed NSSAI 決定)と、PDUセッション時(S-NSSAI+DNN でスライス内SMF/UPF選択)の2つのスライス選択タイミングを説明できる。
- eMBB / URLLC / mMTC という代表的な用途区分と、標準化 SST がそれに対応することを説明できる(具体値は TS 23.501 参照・要確認)。
- 4G(EPC) には標準化されたスライス概念が無く、DNN≒APN での分離や DECOR/eDECOR(専用コアネットワーク) が近い先行概念であることを対比できる。
前提知識¶
先に以下を理解しておくとスムーズです。まだの人は カリキュラム から始めてください。
- Registration(登録手続き)の理解(スライス選択は Registration の中で起きる。UEが Requested NSSAI を提示し、AMFが Allowed NSSAI を返す) → Initial Registration
- PDU Session の理解(PDUセッション確立時に S-NSSAI+DNN でスライス内のSMF/UPFが選ばれる) → PDU Session Establishment
- QoS の理解(スライスごとに異なる QoS/DNN を持ち得る。スライスと QoS は関連する) → QoS
- AMF の役割(スライス対応、Allowed NSSAI の決定・保持、NSSF への問い合わせ) → AMF
この章で学べること¶
本章は Network Slicing のコア(スライスの識別と選択) に焦点を絞ります。S-NSSAI(SST+SD) によるスライス識別、NSSAI の4種類、NSSF の役割、そして登録時・PDUセッション時のスライス選択を主題化します。
- Registration 手続きそのものは Initial Registration の主題です。本章では、その中で起きる スライス選択の詳細を主題化し、登録手順全体は registration へ誘導します。
- QoS の詳細(QoS Flow / 5QI / GBR / AMBR)は QoS へ誘導します。スライスごとに異なる QoS/DNN を持ち得る、という関連のみ本章で触れます。
- PDU Session 確立手順そのものは PDU Session Establishment へ誘導します。本章ではスライス選択の観点(S-NSSAI+DNN → スライス内NF選択)に限定します。
- NF Discovery / NRF の詳細、および無線側スライス(RAN slicing)の詳細は範囲外とし、概念のみ言及します(実装依存の部分を含む)。
Why — なぜ Network Slicing が必要か¶
Why(なぜ必要か)から始めます。 5G のネットワークには、要求特性がまったく異なるサービスが同時に乗ります。超高速動画(eMBB) は大きな帯域を必要とし、工場制御や自動運転(URLLC) はミリ秒単位の超低遅延と高信頼を必要とし、大量のIoTセンサ(mMTC) は1台あたりは小さいが膨大な数の同時接続を必要とします。
もしこれらを1つの同じネットワークで一律に扱うと、それぞれに最適な設計が両立できません。低遅延を極めれば大量接続向けの効率が犠牲になり、帯域を最大化すれば遅延保証が緩みます。そこで、共通の物理インフラの上に、用途ごとに最適化した論理的に独立した複数の仮想ネットワーク(スライス) を作り分けるのが Network Slicing(ネットワークスライシング) です。各スライスは、それぞれの用途に合わせた NF 構成・リソース・ポリシー(QoS/DNN 等)を持ち得ます。
例え話: 1本の道路に用途別のレーン/専用線を仮想的に引く
Network Slicing は、1本の広い道路(物理インフラ)に、用途別の仮想レーンを引くことに似ています。救急・緊急車両専用レーン(URLLC=低遅延・高信頼)、大型バス用レーン(eMBB=大帯域)、大量の自転車用レーン(mMTC=大量接続) を、同じ道路の上に論理的に分けて設けるイメージです。あるいは、1棟のマンション(物理インフラ)の中で、各戸(スライス)が独立した生活空間を持つのにも似ています。物理的には共通でも、論理的には独立し、それぞれ最適化されています。
Overview — 概要¶
Network Slicing の骨格は、スライスを識別する仕組み(S-NSSAI) と、どのスライスを使うか決める仕組み(NSSAI とスライス選択) の2つです。
- スライス(Network Slice) — 共通の物理インフラ上に構築された、論理的に独立した仮想ネットワーク。用途別(eMBB/URLLC/mMTC 等)に最適化される。
- S-NSSAI(Single NSSAI) — 1つのスライスを識別する識別子。SST(Slice/Service Type) + オプションの SD(Slice Differentiator) で構成される。
- NSSAI(Network Slice Selection Assistance Information) — S-NSSAI の集合。用途に応じて Requested / Allowed / Configured / Subscribed の4種類がある(下表)。
| NSSAI の種類 | 誰が持つ/決める | 意味 |
|---|---|---|
| Requested NSSAI | UE が提示 | UEが「このスライスを使いたい」と登録時に要求する S-NSSAI の集合 |
| Allowed NSSAI | ネットワーク(AMF)が決定 | ネットワークが許可し、Registration Accept で返す S-NSSAI の集合。UEはこの範囲内でスライスを使える |
| Configured NSSAI | UE に設定済 | UEにあらかじめ設定された(PLMN 単位の)S-NSSAI の集合 |
| Subscribed S-NSSAI | 加入者データ(UDM) | 加入契約で許可されている S-NSSAI(加入者ごと) |
代表的な 標準化 SST は用途に対応づけられています。
| 用途区分 | 意味 | 想定サービス例 |
|---|---|---|
| eMBB | enhanced Mobile Broadband(高速大容量) | 高精細動画、AR/VR |
| URLLC | Ultra-Reliable Low-Latency Communication(超高信頼・低遅延) | 工場制御、遠隔操作、自動運転 |
| mMTC / MIoT | massive Machine-Type Communication / Massive IoT(大量接続) | 大量のIoTセンサ、メータリング |
標準化 SST の具体値は要確認(架空値を書かない)
eMBB/URLLC/MIoT 等に対応する標準化 SST の具体的な数値は 3GPP TS 23.501 §5.15(Network Slicing、章番号要確認)に定義されていますが、本ページでは個々の SST 値・S-NSSAI の具体符号を断定しません(値は TS 23.501 を要確認。架空値は記載しない方針)。ここでは「用途区分と標準化 SST が対応する」という関係のみを示します。
スライス選択の要点は、「UEが要求(Requested)」→「ネットワークが許可(Allowed)」 という2段構えで、AMFが自力で決められないときに NSSF が支援する、という点です。
Basic Concept — 初心者向け説明¶
Network Slicing を理解するには、3つのキーワードを押さえます。
1. スライスとは(論理的に独立したネットワーク)¶
スライス(Network Slice) は、共通の物理設備の上に作られた、論理的に独立した1つのネットワークです。物理的には同じ基地局・同じサーバ群を使っていても、論理的には別々のネットワークとして振る舞い、用途ごとに最適化されます。マンションで例えれば、建物(物理)は1つでも、各戸(スライス)は独立した生活空間、というイメージです。
2. S-NSSAI とは(スライスの「背番号」=SST+SD)¶
S-NSSAI(Single NSSAI) は、1つのスライスに付けられた背番号(識別子) です。2つの部品からできています。
- SST(Slice/Service Type、スライス/サービス種別) — そのスライスがどんな用途かを表す(eMBB 向け・URLLC 向け・mMTC 向け 等に対応する標準化された値がある。具体値は要確認)。
- SD(Slice Differentiator、スライス識別補助) — 同じ SST の中でさらに区別するためのオプションの補助情報(例: 同じ eMBB でも顧客A用とB用を分ける等)。SD は任意で、無い S-NSSAI もあります。
つまり「SST で大分類、SD で細分類」という背番号です。
3. NSSAI の4種類(要求・許可・設定・加入)¶
NSSAI は S-NSSAI の集まりです。誰が持ち、いつ使うかで4種類に分かれます。やさしく言い換えると次の通りです。
- Requested NSSAI(要求) — UEが「これを使いたい」とネットワークにお願いするリスト。
- Allowed NSSAI(許可) — ネットワークが「これを使ってよい」と返すリスト(Registration Accept で通知)。
- Configured NSSAI(設定) — UEにあらかじめ設定されているリスト(何を要求すべきかの下地)。
- Subscribed S-NSSAI(加入) — 契約で許可されているスライス(加入者データとして UDM が持つ)。
レストランに例えると、Configured=手元のメニュー、Requested=注文、Subscribed=あなたのプランで頼めるもの、Allowed=店が「お作りできます」と確定した品、という関係です。
Architecture¶
Network Slicing に関わる要素と、それらを結ぶInterfaceです。共通の AMF が登録・スライス選択を取りまとめ、スライスごとに SMF/UPF などのNF群が用意され得る(配備はスライス設計・実装依存)、という典型構図を示します。
flowchart LR
UE(["UE
(Requested NSSAI 提示)"]) -- "N1 (NAS)" --> AMF["AMF
(スライス対応 / Allowed NSSAI 決定)"]
RAN["NG-RAN / gNB"] -- "N2 (NGAP): S-NSSAI" --> AMF
UE -.RRC.- RAN
AMF -- "N22 (Nnssf): NSSelection
(必要時のみ)" --> NSSF["NSSF
(スライス選択支援 / NSSAIAvailability)"]
AMF -. "NF発見 (概念)" .-> NRF["NRF
(スライス対応NF発見)"]
subgraph SliceA["スライスA (例: eMBB)"]
SMFa["SMF"] --> UPFa["UPF"]
end
subgraph SliceB["スライスB (例: URLLC)"]
SMFb["SMF"] --> UPFb["UPF"]
end
AMF -- "S-NSSAI 単位で選択" --> SMFa
AMF -- "S-NSSAI 単位で選択" --> SMFb
classDef core fill:#efe,stroke:#3a3,stroke-width:2px;
class AMF,NSSF core;
各要素の役割は次の通りです。
- UE — 使いたいスライスを Requested NSSAI として提示する(Configured NSSAI が下地)。
- AMF — スライス選択の司令塔。Requested NSSAI を Subscribed S-NSSAI / Configured NSSAI と照合し、Allowed NSSAI を決定・保持する。自力で解決できない場合は NSSF に問い合わせる。
- NSSF(Network Slice Selection Function) — AMFが自力で決められないときのスライス選択支援と、各TA(Tracking Area)で利用可能な NSSAI の管理(NSSAIAvailability)を担う。個別のNFページは無いため、NF辞典 の NSSF 行を参照。
- SMF / UPF — S-NSSAI 単位で選択され、そのスライス内の PDU セッション/ユーザプレーン転送を担う(PDUセッション確立時に選ばれる)。
- PCF — URSP(UE Route Selection Policy) をUEへ配布し、どのアプリ/トラフィックをどの S-NSSAI/DNN に載せるかをUE側で判断させる(詳細は PCF/URSP へ誘導)。
- NRF(NF Repository Function) — スライスに対応する NF を発見する(NF Discovery、概念のみ。詳細は範囲外)。
NF 配備トポロジは実装依存
「スライスごとに専用の SMF/UPF を置く」か「複数スライスで NF を共有する」かは、スライス設計・オペレータ構成に依存します(実装依存)。上図は理解のための典型例であり、実配備は異なり得ます。また NG-RAN はコアNFではありません(無線アクセス側)。
Interfaceの詳細は Interface辞典 を参照してください。
Network Function(登場NF)¶
Network Slicing に関わる主なNFの役割です。NSSF は個別ページが無いため NF辞典 の NSSF 行を参照します。NG-RAN は無線アクセス側であり、コアNFではありません。
| NF | この文脈での役割 | 保持/取得する情報 | 主なAPI/手続き | 障害時の影響 |
|---|---|---|---|---|
| AMF | スライス選択の主体。Requested NSSAI を照合し Allowed NSSAI を決定・保持。必要時 NSSF へ問い合わせ、条件によりAMF再選択 | UEコンテキスト、Allowed NSSAI、在圏(TAI)、対応 S-NSSAI | Namf(提供)/Nnssf(NSSelection) を消費 | スライス選択が成立せず登録・セッションが進まない |
| NSSF(NF辞典 参照) | AMFが自力で解決できない場合のスライス選択支援。各TAで利用可能な NSSAI 管理(NSSAIAvailability) | 各TAの利用可能 NSSAI、スライス選択ポリシー | Nnssf_NSSelection / Nnssf_NSSAIAvailability(N22、TS 23.501 §6.2.14。章番号要確認) | AMFがスライスを解決できず Allowed NSSAI が確定しない |
| SMF | S-NSSAI 単位で選択され、そのスライス内の PDU セッションを管理 | S-NSSAI、DNN、セッションコンテキスト | Nsmf_PDUSession | 該当スライスの PDU セッションが張れない |
| UPF | スライス内のユーザプレーン転送。S-NSSAI 単位で選ばれ得る | 転送ルール、スライス内セッション | PFCP(N4) | 該当スライスのデータ転送が不可 |
| PCF | URSP をUEへ配布し、アプリ→S-NSSAI/DNN の対応をUE側で判断させる | URSP、スライス経路ポリシー | Npcf(URSP 配布) | UE側の経路選択(どのスライスに載せるか)が既定動作に依存 |
| NRF(コアNF) | スライスに対応するNFの発見(NF Discovery、概念) | NFプロファイル(対応 S-NSSAI 等) | Nnrf_NFDiscovery | スライス対応NFの発見が滞る(詳細は範囲外) |
Interface / Protocol¶
この文脈で使う主なInterfaceとProtocolです。スライス情報がどの区間をどの形で流れるかを整理します。IE 名・オペレーション名の一部は版・実装依存のため要確認です。
| Interface | Protocol | Transport | 区間 | この文脈での用途 |
|---|---|---|---|---|
| N1 | NAS(5GMM) | (NGAP/N2 上でトンネル) | UE ⇔ AMF | Registration で Requested NSSAI(要求)/Allowed NSSAI(受諾)を搬送(TS 24.501) |
| N2 | NGAP | SCTP(port 38412) | gNB ⇔ AMF | S-NSSAI 情報を NG-RAN へ搬送(AMF選択・スライス対応。TS 38.413) |
| N22 | SBI(HTTP/2, TLS, JSON) | TCP/TLS | AMF ⇔ NSSF | Nnssf(NSSelection: スライス選択 / NSSAIAvailability: 各TAの利用可能 NSSAI 管理。TS 29.531。TS 23.501 §6.2.14) |
| N4 | PFCP | UDP(port 8805) | SMF ⇔ UPF | スライス内のユーザプレーン設定(S-NSSAI 単位のセッションに紐づく) |
| N7 | SBI(HTTP/2, TLS, JSON) | TCP/TLS | PCF ⇔ SMF/AMF | ポリシー(URSP 等、スライス経路ポリシーを含む) |
N22 と Nnssf の位置づけ
N22 は AMF と NSSF の間のInterfaceで、Nnssf サービス(NSSelection と NSSAIAvailability)を運びます。NSSelection は「この Requested NSSAI に対してどの Allowed NSSAI/どのAMFが適切か」を解決し、NSSAIAvailability は「どのTAでどの NSSAI が使えるか」を管理します。オペレーション名の細部・IE 名は版・実装依存で一部要確認です。参照は TS 23.501 §6.2.14(NSSF、章番号要確認)、TS 29.531(Nnssf)。
Protocolの詳細は Protocol辞典、Interface一覧は Interface辞典 を参照してください。
Procedure — Call Flow¶
このページの心臓部です。 スライス選択の流れを Mermaid の sequenceDiagram で示します。根拠は TS 23.502(登録・スライス選択手順)、TS 23.501 §5.15(Network Slicing)・§6.2.14(NSSF、章番号要確認)、TS 24.501(NAS の NSSAI)、TS 29.531(Nnssf)、TS 38.413(NGAP の S-NSSAI)です。スライス選択は多くの場合 Initial Registration の一部として起こるため、ここでは スライス選択に焦点を当てます(登録の全体手順は registration を参照)。
前提: スライス選択は Registration 手続きの中で起こる
UEの Requested NSSAI 提示から Allowed NSSAI 受諾までは、独立した手続きではなく Initial Registration の中で行われます。本図は、その中の スライス選択(Requested → Allowed、必要時 NSSF 問い合わせ) 部分を抜き出したものです。オペレーション名・順序は TS 23.502 準拠ですが、細部は版・実装依存で一部要確認です。
sequenceDiagram
autonumber
participant UE
participant RAN as NG-RAN / gNB
participant AMF
participant NSSF
participant UDM
participant SMF
Note over UE,RAN: RRC接続確立(無線側・概略)
UE->>RAN: Registration Request (NAS: Requested NSSAI)
Note right of RAN: TS 24.501。Requested NSSAI を含む
RAN->>AMF: Initial UE Message (NGAP) に NAS を載せる
Note right of RAN: 初期AMF selection(RANの概略)
AMF->>UDM: 加入者データ取得(Subscribed S-NSSAI)
UDM-->>AMF: Subscribed S-NSSAI
Note over AMF: Requested NSSAI を Subscribed / Configured と照合
opt AMFが自力で解決できない場合(条件付き)
AMF->>NSSF: Nnssf_NSSelection(Requested NSSAI / TAI 等)
NSSF-->>AMF: Allowed NSSAI / 適切なAMF情報
Note right of NSSF: N22 / TS 29.531 / TS 23.501 §6.2.14(要確認)
end
opt AMF再選択が必要な場合(条件付き)
Note over AMF: 適切なAMFへ再配置(AMF再選択)
end
AMF->>UE: Registration Accept (NAS: Allowed NSSAI)
UE->>AMF: Registration Complete (NAS)
Note over UE,AMF: 以降、Allowed NSSAI 内でスライスを使える
Note over UE,SMF: 【PDUセッション時】以降のスライス内NF選択(概要)
UE->>AMF: PDU Session Establishment Request (S-NSSAI + DNN)
Note right of AMF: S-NSSAI+DNN でスライス内 SMF を選択
AMF->>SMF: 選択したスライス内 SMF へ(→ スライス内 UPF 選択)
Note over AMF,SMF: 詳細は pdu-session を参照
ステップ解説(番号は上図に対応)¶
1-2. UE→(R)AN→AMF: UEが Registration Request に Requested NSSAI(使いたいスライスの集合)を載せて送り、gNBが Initial UE Message(NGAP) で AMF へ運ぶ(初期の AMF selection は RAN が実施)。 3-4. AMF↔UDM: AMFが加入者データを取得し、Subscribed S-NSSAI(契約で許可されたスライス)を得る。AMFは Requested NSSAI を Subscribed / Configured NSSAI と照合する。 5-6. (条件付き)AMF↔NSSF: AMFが自力でスライスを解決できない場合、Nnssf_NSSelection(N22)で NSSF に問い合わせ、Allowed NSSAI と(必要なら)適切なAMFの情報を得る(TS 29.531、TS 23.501 §6.2.14。章番号要確認)。 7. (条件付き)AMF再選択: 要求スライスを収容するのに現AMFが適切でない場合、適切なAMFへ再配置(AMF再選択) され得る(条件・構成依存)。 8-9. 登録受諾: AMF→UE Registration Accept で Allowed NSSAI を通知。UEは以降、この範囲内で複数の S-NSSAI(スライス)を使える。UE→AMF Registration Complete で完了。 10-12. (PDUセッション時)スライス内NF選択: UEが PDU Session Establishment Request に S-NSSAI + DNN を指定すると、AMFはそのスライス内の SMF を選択し、SMFがスライス内の UPF を選択する。詳細手順は PDU Session Establishment を参照。
NSSF 問い合わせ・AMF再選択は条件付き
NSSF への問い合わせ(ステップ5-6)と AMF再選択(ステップ7)は、AMFが自力で解決できるか、要求スライスを現AMFが収容できるか等の条件により省略・変化します。3GPP TS 23.502 の該当手順は多くの任意/条件付きステップを含むため、具体的な省略条件は個別に仕様確認が必要です(一部は要確認)。
参照: TS 23.501 §5.15(Network Slicing、章番号要確認)・§6.2.14(NSSF)、TS 23.502(スライス選択を伴う登録手順)、TS 24.501(NAS の NSSAI)、TS 29.531(Nnssf)、TS 38.413(NGAP の S-NSSAI)。
Signal Flow¶
スライス選択に関わる主要な「情報の器」を、方向ごとに整理します。IE 名・オペレーション名の一部は版・実装依存のため要確認です。
| 情報 | Protocol | 送信元→先 | 目的 | 主な中身(要確認あり) |
|---|---|---|---|---|
| Requested NSSAI | NAS(5GMM) | UE→AMF | 使いたいスライスの要求 | S-NSSAI の集合(各 S-NSSAI = SST[+SD]。IE 名要確認) |
| Subscribed S-NSSAI | SBI(Nudm) | UDM→AMF | 契約で許可されたスライス提供 | 加入 S-NSSAI(既定スライス指定を含み得る=要確認) |
| Nnssf_NSSelection | SBI(Nnssf, N22) | AMF→NSSF | スライス選択支援の要求/応答 | Requested NSSAI、TAI 等 →(応答)Allowed NSSAI、適切なAMF情報 |
| Allowed NSSAI | NAS(5GMM) | AMF→UE | 許可スライスの通知 | 許可された S-NSSAI の集合(Registration Accept 内。IE 名要確認) |
| S-NSSAI(N2) | NGAP | AMF→(NG-RAN) | 無線側へのスライス情報 | S-NSSAI(PDU Session リソース等に付随。IE 名要確認) |
Requested → Allowed が背骨
上表の背骨は、UEの Requested NSSAI(要求)→ AMFが Subscribed/Configured と照合し、必要時 NSSF に問い合わせ →Allowed NSSAI(許可)を返す、という流れです。NSSF 問い合わせ(Nnssf_NSSelection)は、AMFが自力で解決できない場合にこの流れの中間に挿入されます。各 IE の詳細・参照 Spec は Message辞典 を参照してください。
State Machine¶
スライスは、独立した重い状態機械を持つトピックではありません。ここでは、UE視点で NSSAI がどう確定していくか、および AMFのスライス選択の判断ロジックを図で示します(理解のための概念表現。根拠は TS 23.501 §5.15、章番号要確認)。
まず、UE視点の NSSAI 確定の流れです。
stateDiagram-v2
[*] --> Configured: Configured NSSAI 設定済(未登録)
Configured --> Requested: 登録時に Requested NSSAI を提示
Requested --> Allowed: Registration Accept で Allowed NSSAI 取得
Allowed --> InUse: Allowed 内の S-NSSAI で PDU セッション確立
InUse --> Allowed: セッション解放(Allowed は維持)
Allowed --> [*]: De-registration 等
- Configured — UEに Configured NSSAI が設定済だが、まだ登録していない状態。
- Requested — 登録時に Requested NSSAI を提示した状態。
- Allowed — Registration Accept で Allowed NSSAI を受け取り、使えるスライスが確定した状態。
- InUse — Allowed 内の S-NSSAI を使って PDU セッションを張り、実際にスライスを利用している状態。
次に、AMFがスライスを選ぶときの判断ロジック(flowchart)です。この判定に沿って Allowed NSSAI が決まります。
flowchart TD
A["Requested NSSAI を受信"] --> B{"Subscribed / Configured と
照合して解決できる?"}
B -- "はい" --> C["AMF が Allowed NSSAI を決定"]
B -- "いいえ(自力解決不可)" --> D["Nnssf_NSSelection で NSSF に問い合わせ"]
D --> E{"適切なAMFは現AMFか?"}
E -- "はい" --> C
E -- "いいえ" --> F["AMF再選択(適切なAMFへ再配置)"]
F --> C
C --> G["Registration Accept で Allowed NSSAI を返す"]
スライスは状態機械が薄いトピック
スライス自体は明示的な状態機械として大きく扱われないため、上の stateDiagram は UE視点の NSSAI 確定の理解のための概念表現です(状態名は要確認)。実運用上の分岐(NSSF 問い合わせ・AMF再選択)は下の判断ロジック(flowchart)が実態に近く、こちらを主に参照してください。
Packet Analysis (Wireshark)¶
Network Slicing を Wireshark で解析するときの要点です。スライス情報は主に NAS(N1)と NGAP(N2)に現れます。
主要 Display Filter¶
| Filter | 意味 | 見る区間 |
|---|---|---|
nas-5gs |
5GS NAS メッセージ全般(Requested/Allowed NSSAI を含む Registration) | N1 |
nas-5gs.mm |
5GS NAS MM(Registration Request/Accept 等) | N1 |
ngap |
NGAP メッセージ全般(S-NSSAI IE を含む) | N2 |
sctp.port == 38412 |
N2(NGAP) の SCTP ポート | N2 |
IE 名・値・フィールド位置は環境依存・要確認
NAS の Requested/Allowed NSSAI の IE 名、NGAP の S-NSSAI IE 名・格納位置は 3GPP の割当に基づきますが、Wireshark のバージョン・ディセクタ実装で表示や照合方法が異なる場合があります。本ページでは架空の数値・IE 名・SST 値を断定しません。具体的なフィールド名・値は要確認とし、実機では GUI のプロトコル階層表示で確認するのが確実です。
Decode の見どころ(主要IE)¶
- NAS Registration Request の Requested NSSAI — UEが要求するスライスの集合。各 S-NSSAI に SST(+任意の SD)が入る(IE 名要確認)。
- NAS Registration Accept の Allowed NSSAI — ネットワークが許可したスライスの集合。UEはこの範囲でスライスを使う(IE 名要確認)。
- NGAP の S-NSSAI IE — PDU Session Resource 設定等に付随して、対象スライスの S-NSSAI が NG-RAN へ運ばれる(IE 名・格納位置要確認)。
実際のpcapは環境依存(実装依存)
本ページのフィルタ・IE 名は解析の指針です。Open5GS や free5GC のテストベッドで、複数の S-NSSAI(SST/SD)を設定して登録・PDUセッションを行うと、NAS の Requested/Allowed NSSAI や NGAP の S-NSSAI を実際に観察できます(実装依存)。SST の具体値は各実装の設定に依存します。
Configuration¶
Network Slicing を成立させるための設定の構造レベルの要点です。具体値・ベンダー固有(Cisco 等)は実装依存であり、ここでは架空の値を書きません。
スライス識別・サポートの設定観点(AMF/NSSF 側)¶
- サポート S-NSSAI(SST/SD) — AMF や各TAでサポートする S-NSSAI のリスト。SST は用途区分(eMBB/URLLC/mMTC 等)に対応する標準化値を用いるが、具体値は TS 23.501 §5.15 を要確認(章番号要確認、架空値は使わない)。SD は必要に応じて付与。
- NSSAIAvailability — NSSF 側で「どのTAでどの NSSAI が使えるか」を構成(N22 経由でAMFと整合)。
- Configured NSSAI — UE側(またはプロビジョニング)に設定する既定の S-NSSAI 集合。
加入者スライスのプロビジョニング(UDM/UDR)¶
- Subscribed S-NSSAI — 加入者(SUPI)ごとに許可するスライス(既定スライスの指定を含み得る=要確認)を UDM/UDR に登録。
スライス別NF配備の設定観点¶
- スライス別 SMF/UPF — スライスごとに専用 NF を置くか共有するかは実装依存。NRF に各NFの対応 S-NSSAI を登録し、スライス対応NF発見を成立させる。
具体値・ベンダー固有は実装依存
設定キー名・階層・必須項目、SST/SD の具体値、スライス別NF配備の形は Open5GS / free5GC / 商用ベンダー(Cisco 等)で異なります。標準化 SST 値は TS 23.501 §5.15 を要確認とし、本ページでは架空の設定値・SST 値を記載しません(実装依存)。
Trouble Shooting¶
代表的なスライス関連トラブルの切り分けです(一般論)。Cause 値の詳細は Cause辞典 を参照してください。
| 症状 | 想定原因 | 確認ポイント | 関連ログ/Packet | 対処の方向性 |
|---|---|---|---|---|
| (a) Requested NSSAI が拒否される | 加入外スライス要求、当該TAで未サポート | Subscribed S-NSSAI、TAの NSSAIAvailability | Registration Reject/Accept(NAS)、AMFログ | 加入スライス・TAサポートとの整合を確認 |
| (b) Allowed NSSAI が空/期待より少ない | Subscribed と Requested の不一致、NSSF未解決 | Requested↔Subscribed↔Configured の照合結果 | NAS(Allowed NSSAI)、Nnssf、AMF/NSSFログ | 加入設定・NSSAIAvailability・NSSF連携を確認 |
| (c) スライス未サポートTAでの要求 | UEが在圏TAで未提供のスライスを要求 | NSSF の NSSAIAvailability、TA構成 | Nnssf(NSSAIAvailability)、AMF/NSSFログ | TAごとの提供スライス構成を確認 |
| (d) PDUセッションのスライス内NF選択失敗 | 該当 S-NSSAI 対応の SMF/UPF 未発見 | NRF の NFプロファイル(対応 S-NSSAI)、DNN整合 | Nnrf_NFDiscovery、SMF/AMFログ | スライス対応NFの登録・DNN/S-NSSAI整合を確認 |
| (e) NSSF が解決できない | NSSF未構成、NSSAIAvailability 不整合 | N22 疎通、NSSF構成 | Nnssf、AMF/NSSFログ | NSSF構成・N22疎通・NSSAIAvailability を確認 |
EPCとの比較¶
4G(EPC) 経験者が 5G へ橋渡しできるよう対比します。4G には 5G のような標準化された「スライス」概念はありません。近い先行概念として、DNN≒APN によるサービス分離と、DECOR/eDECOR(専用コアネットワーク) があります。
| 観点 | 4G / EPC | 5G / 5GC |
|---|---|---|
| スライス概念 | 標準化されたスライス概念は無い | Network Slice(S-NSSAI で標準化) |
| 近い先行概念 | DECOR / eDECOR(専用コアネットワーク=加入者種別ごとにコアを分ける) | S-NSSAI によるスライス(用途別に論理分割) |
| サービス分離の識別子 | APN(Access Point Name) | DNN(Data Network Name) + S-NSSAI |
| スライス選択NF | 無し(DECOR は MME 等での振り分け) | NSSF(Nnssf / NSSAIAvailability、N22) |
| 選択情報 | (加入者種別等での振り分け) | NSSAI(Requested/Allowed/Configured/Subscribed) |
DECOR/eDECOR は 5G スライシングの前身的位置づけ
4G の DECOR(Dedicated Core Network) および eDECOR(enhanced DECOR) は、加入者種別ごとに専用のコアネットワーク(MME 等)へ振り分ける仕組みで、5G の Network Slicing の前身的な位置づけと言えます。ただし DECOR/eDECOR は S-NSSAI のような標準化スライス識別や NSSF による選択支援を持たず、粒度・柔軟性・標準化度合いが5Gのスライスとは異なります。DECOR/eDECOR の詳細動作は要確認(本章では概念どまり)。また APN↔DNN はサービス/データ網の識別子として対応しますが、5G ではさらに S-NSSAI がスライスの軸として加わる点が本質的な違いです。
Release差分¶
Network Slicing 関連の主なトピックです。不確かなものは要確認とし、断定しません。
- Rel-15 — Network Slicing の基礎(S-NSSAI(SST/SD)/NSSAI(Requested/Allowed/Configured/Subscribed)/NSSF(Nnssf, N22) による登録時・PDUセッション時のスライス選択)が確立(TS 23.501 §5.15 の基礎、章番号要確認)。
- NSAC(Network Slice Admission Control) — スライス単位で登録UE数/PDUセッション数の上限を制御する拡張(Rel-16 以降とされるが、導入 Release・詳細動作は要確認)。概念のみ・詳細は要確認。
- Rel-17 / Rel-18(5G-Advanced) — スライス関連の拡張(スライス選択・課金・相互運用等)が継続(具体差分は要確認)。
Release差分は要確認
各 Release でスライシングにどの機能がどこまで織り込まれたか(特に NSAC の導入 Release・動作)は、対象 TS の版差分を個別に確認する必要があります。上記は概観であり、具体項目は要確認です。
3GPP Specification¶
| Spec | 章 | 内容 |
|---|---|---|
| TS 23.501 | §5.15 | Network Slicing(スライス概念、S-NSSAI、NSSAI 種別)(章番号要確認) |
| TS 23.501 | §6.2.14 | NSSF(Network Slice Selection Function)の定義(章番号要確認) |
| TS 23.502 | (登録手順各章) | スライス選択を伴う登録手順(章番号要確認) |
| TS 24.501 | (NAS 各章) | NAS 側の NSSAI(Requested/Allowed NSSAI 等)(章番号要確認) |
| TS 29.531 | — | Nnssf(NSSelection / NSSAIAvailability、N22 の SBI) |
| TS 38.413 | (NGAP 各章) | NGAP(N2)の S-NSSAI 搬送(章番号要確認) |
章番号の扱い
TS 23.501 §5.15(Network Slicing)・§6.2.14(NSSF)は本章の骨格として参照しています。ただし細かな枝番、TS 23.502 のスライス選択手順、TS 24.501 の NSSAI 各章、TS 38.413 の NGAP 個別章番号は版により異なる場合があり、一部は要確認です。標準化 SST の個々の値・S-NSSAI 符号、NSSAI/S-NSSAI の IE 名、Nnssf オペレーション名の細部も要確認とし、本ページでは値を断定しません。
FAQ¶
Q1. Network Slice(スライス)とは何か?
スライスは、共通の物理インフラ上に構築された論理的に独立した仮想ネットワークです。用途別(eMBB/URLLC/mMTC 等)に最適化され、それぞれ専用/共有の NF・リソース・ポリシー(QoS/DNN 等)を持ち得ます。物理は1つでも論理的には別ネットワークとして振る舞います。
Q2. S-NSSAI の SST と SD の違いは?
SST(Slice/Service Type) はスライスの用途種別(eMBB/URLLC/mMTC 等に対応する標準化値。具体値は要確認)を表す「大分類」です。SD(Slice Differentiator) は、同じ SST の中でさらに区別するためのオプションの補助情報(「細分類」)で、無い S-NSSAI もあります。S-NSSAI = SST[+SD] です。
Q3. Requested NSSAI と Allowed NSSAI の違いは?
Requested NSSAI は UEが登録時に「これを使いたい」と提示するスライス集合です。Allowed NSSAI は、ネットワーク(AMF)が Subscribed/Configured と照合し、必要時 NSSF に問い合わせて「これを使ってよい」と確定し、Registration Accept で返す集合です。UEは Allowed NSSAI の範囲内でスライスを使えます。
Q4. NSSF はいつ使われるのか?
AMFが自力でスライスを解決できない場合に使われます。AMFは Requested NSSAI を Subscribed/Configured と照合して自力で Allowed NSSAI を決められることが多いですが、決められない場合に Nnssf_NSSelection(N22)で NSSF に問い合わせ、Allowed NSSAI や適切なAMFの情報を得ます。NSSF は各TAの利用可能 NSSAI(NSSAIAvailability)も管理します。
Q5. 1つのUEは複数のスライスを同時に使えるか?
はい。UEは Allowed NSSAI に含まれる複数の S-NSSAI(スライス)を同時に使えます。各スライス上で PDU セッションを張り、用途ごとに異なるスライス(例: eMBB と URLLC)を並行して利用できます(同時利用数の上限等は構成依存・要確認)。
Q6. 4G にスライスはあるか?
4G には 5G のような標準化されたスライス概念はありません。近い先行概念として、APN によるサービス分離や、DECOR/eDECOR(専用コアネットワーク) があります。DECOR/eDECOR は 5G スライシングの前身的位置づけですが、S-NSSAI や NSSF を持たず、粒度・柔軟性・標準化度合いが異なります(詳細は要確認)。
Summary¶
- Network Slicing は、共通の物理インフラ上に論理的に独立した複数の仮想ネットワーク(スライス) を構築し、用途別(eMBB/URLLC/mMTC)に最適化する仕組み。
- スライスは S-NSSAI(SST[+SD]) で識別される。SST が用途種別(大分類、標準値は要確認)、SD が同一 SST 内の細分類(任意)。
- NSSAI は S-NSSAI の集合で、Requested(UE要求)/ Allowed(NW許可、Accept で返す)/ Configured(UE設定)/ Subscribed(加入) の4種類。
- スライス選択は2段構え。登録時に UEの Requested NSSAI → AMFが Subscribed/Configured と照合、必要時 NSSF(Nnssf, N22) に問い合わせ → Allowed NSSAI を返す(条件によりAMF再選択)。PDUセッション時に S-NSSAI+DNN でスライス内 SMF/UPF が選ばれる。
- URSP(PCF 配布) で、どのアプリ/トラフィックをどの S-NSSAI/DNN に載せるかをUEが判断する。
- 4G には標準化スライスは無く、DECOR/eDECOR(専用コア) が前身的概念(要確認)。
- 根拠は TS 23.501 §5.15(Network Slicing)・§6.2.14(NSSF)/ TS 23.502 / TS 24.501 / TS 29.531(Nnssf)/ TS 38.413(S-NSSAI)(章番号・SST 値・IE 名の一部は要確認)。
Practice — 理解度チェック・演習¶
理解度チェック¶
Q1. スライスを識別する識別子は何で、何から構成されるか?(解答)
S-NSSAI(Single NSSAI)。SST(Slice/Service Type、用途種別) + オプションの SD(Slice Differentiator、細分類) から構成される。SD は無い場合もある。
Q2. NSSAI の4種類を挙げ、それぞれ誰が持つ/決めるか?(解答)
Requested(UEが要求)/Allowed(AMFが決定し Accept で返す)/Configured(UEに設定済)/Subscribed(加入者データ=UDM)。
Q3. NSSF が使われるのはどんなときか?(解答)
AMFが自力でスライスを解決できないとき。AMFが Nnssf_NSSelection(N22)で問い合わせ、Allowed NSSAI/適切なAMF情報を得る。NSSF は NSSAIAvailability(各TAの利用可能 NSSAI)も管理する。
Q4. スライス選択が起きる2つのタイミングは?(解答)
(1) 登録時(Requested NSSAI → Allowed NSSAI の決定)、(2) PDUセッション確立時(S-NSSAI+DNN でスライス内 SMF/UPF を選択)。
Q5. 1つのUEは複数スライスを使えるか?(解答)
使える。Allowed NSSAI 内の複数の S-NSSAI を同時に利用できる(上限等は構成依存・要確認)。
演習¶
問: 次の「登録時スライス選択」の主要ステップを正しい順に並べ替えてください。
A. AMF が Registration Accept で Allowed NSSAI を返す
B. UE が Registration Request に Requested NSSAI を載せて送る
C. (条件付き)AMF が Nnssf_NSSelection で NSSF に問い合わせる
D. AMF が Requested NSSAI を Subscribed / Configured と照合する
E. (条件付き)AMF再選択(適切なAMFへ再配置)
F. AMF が UDM から Subscribed S-NSSAI を取得する
解答
B → F → D → C → E → A
- B: UEが Requested NSSAI を提示
- F: AMFが UDM から Subscribed S-NSSAI を取得
- D: Requested を Subscribed/Configured と照合
- C: (自力解決不可なら)NSSF へ Nnssf_NSSelection
- E: (必要なら)AMF再選択
- A: Registration Accept で Allowed NSSAI を返す
※ C と E は条件により省略される(状況・実装依存)。この選択は独立手続きではなく Initial Registration の中に織り込まれる。順序・分岐は一部要確認。
Next Step¶
理解を深めるための次の一歩です。
- 直接の上流: Initial Registration(スライス選択はこの手続きの中で起きる。Requested/Allowed NSSAI の搬送)
- 関連手順: PDU Session Establishment(S-NSSAI+DNN でスライス内 SMF/UPF が選ばれる)
- 関連トピック: QoS(スライスごとに異なる QoS/DNN を持ち得る)
- 関連NF: AMF(Allowed NSSAI 決定・保持)/ SMF(S-NSSAI 単位のセッション)/ UPF(スライス内転送)/ PCF(URSP でUE側経路)
- NSSF: NF辞典 の NSSF 行(Nnssf: NSSelection / NSSAIAvailability、N22、TS 23.501 §6.2.14)
- 関連Interface: N1 / N2 / N4 / N7
- 辞典: Message辞典 / Timer辞典 / Cause辞典 / Protocol辞典 / NF辞典 / Interface辞典