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 等）を持ち得ます。

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種類がある（下表）。

代表的な 標準化 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＝店が「お作りできます」と確定した品、という関係です。

この4種がどう関係して Allowed に絞り込まれるかを1枚にすると次の通りです。UE側の2種（Configured/Requested）とネットワーク側の2種（Subscribed/Allowed）が、登録時に照合されて Allowed NSSAI に確定します。

flowchart LR
    subgraph UEside["UE 側が持つ"]
        direction TB
        CONF["Configured NSSAI
UEに設定済（下地）"]
        REQ["Requested NSSAI
今回「使いたい」要求"]
        CONF -->|"下地にして要求を組む"| REQ
    end
    subgraph NWside["ネットワーク側が持つ／決める"]
        direction TB
        SUB["Subscribed S-NSSAI
契約で許可（UDM）"]
        ALLOW["Allowed NSSAI
今回使ってよい（確定）"]
        SUB -->|"許可範囲を与える"| ALLOW
    end

    REQ ==>|"登録時に提示"| AMFcheck{"AMF が照合
（必要時 NSSF）"}
    SUB ==>|"照合材料"| AMFcheck
    AMFcheck ==>|"絞り込み結果"| ALLOW
    ALLOW ==>|"Registration Accept で通知"| USE["UE はこの範囲で
スライスを使う"]

    classDef ue fill:#efe,stroke:#3a3;
    classDef nw fill:#eef,stroke:#66a;
    classDef res fill:#fde,stroke:#c69,stroke-width:2px;
    class CONF,REQ ue;
    class SUB,ALLOW nw;
    class ALLOW res;

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、概念のみ。詳細は範囲外）。

Interfaceの詳細は Interface辞典 を参照してください。

Network Function（登場NF）¶

Network Slicing に関わる主なNFの役割です。NSSF は個別ページが無いため NF辞典 の NSSF 行を参照します。NG-RAN は無線アクセス側であり、コアNFではありません。

Interface / Protocol¶

この文脈で使う主なInterfaceとProtocolです。スライス情報がどの区間をどの形で流れるかを整理します。IE 名・オペレーション名の一部は版・実装依存のため要確認です。

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 を参照）。

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 を参照。

参照: 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 名・オペレーション名の一部は版・実装依存のため要確認です。

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 を返す"]

Packet Analysis (Wireshark)¶

Network Slicing を Wireshark で解析するときの要点です。スライス情報は主に NAS（N1）と NGAP（N2）に現れます。

主要 Display Filter¶

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 名・格納位置要確認）。

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発見を成立させる。

Trouble Shooting¶

代表的なスライス関連トラブルの切り分けです（一般論）。Cause 値の詳細は Cause辞典 を参照してください。

EPCとの比較¶

4G(EPC) 経験者が 5G へ橋渡しできるよう対比します。4G には 5G のような標準化された「スライス」概念はありません。近い先行概念として、DNN≒APN によるサービス分離と、DECOR/eDECOR（専用コアネットワーク） があります。

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） — スライス関連の拡張（スライス選択・課金・相互運用等）が継続（具体差分は要確認）。

3GPP Specification¶

FAQ¶

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 — 理解度チェック・演習¶

理解度チェック¶

演習¶

問: 次の「登録時スライス選択」の主要ステップを正しい順に並べ替えてください。

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 を取得する

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辞典