N22 — AMF ⇔ NSSF（Nnssf_NSSelection 参照点）¶

学習目標¶

このページを読み終えると、次のことができるようになります。

• N22が SBI（Service Based Interface） であり、N2(NGAP/SCTP)やN4(PFCP/UDP)とはProtocol/Transportが根本的に異なることを説明できる。
• N22の実体がNSSFの提供するサービス Nnssf_NSSelection（TS 29.531） であることを説明できる。
• AMFが自力でスライス選択を解決できないとき、NSSFへスライス選択支援を要求し、Allowed NSSAI や適切な AMF候補（AMF Set） を得る流れを説明できる。
• 「参照点N22」と「サービスNnssf_NSSelection」が同じものの2つの見方であることを説明できる。
• 4G(EPC)には標準化されたスライス選択の相当機能が無い（DECOR/eDECORが前身的発想）ことを説明できる（要確認）。

前提知識¶

先に以下を理解しておくとスムーズです。

• SBA / SBI と HTTP/2・TLS の位置づけ → Protocol辞典
• N22の両端のNF → AMF / NSSF
• ネットワークスライス・NSSAI・Allowed NSSAIの使われ方 → Network Slicing
• Interfaceと参照点の考え方 → Interface辞典

Why — なぜ必要なのか¶

UEがネットワークに登録する際、端末は「どのスライス（S-NSSAI）を使いたいか」を Requested NSSAI として提示します。AMFはこれを受け取り、加入情報や網構成と突き合わせて「この端末に実際に許可するスライス（Allowed NSSAI）」を決め、さらに「自分（このAMF）がそのスライス群を担当できる適切なAMFか」を判断しなければなりません。

しかし、スライス構成は網全体にまたがる情報（どのスライスがどのエリア・どのAMF Setで提供されるか等）であり、AMF単独では解決しきれない場合があります。そこで、スライス選択の元締めである NSSF に「この端末のRequested NSSAIと加入情報から、Allowed NSSAIと適切なAMFは何か?」と問い合わせる道が要ります。これがN22です。AMFはN22でNSSFにスライス選択の支援を求め、NSSFは網構成・加入情報から Allowed NSSAI や 候補AMF Set を返します。N22が無ければ（またはNSSF連携しなければ）、AMFはローカル構成の範囲でしかスライス選択できず、網規模のきめ細かいスライス選択・適切なAMF再選択ができません。

例え話: N22は、総合受付（AMF）が案内デスク（NSSF）に「この客はどの専門窓口＝スライスへ通すべき?」を問い合わせる回線です。受付は自分の手元情報だけで判断しきれないとき、この専用回線で案内デスクに尋ね、回答（Allowed NSSAIや担当窓口の割り当て）に従って客を通します。

Overview — 概要¶

N22は AMF ⇔ NSSF を結ぶ参照点です。ただしN22はSBI（Service Based Interface）である点が、N2(NGAP/SCTP)やN4(PFCP/UDP)と決定的に異なります。SBIとはNF同士がWeb API（HTTP）でサービスを呼び合う仕組みで、共通の転送として HTTP/2 + JSON（RESTful）over TLS を用います。

N22の実体は、NSSFが提供するサービス Nnssf_NSSelection（TS 29.531） です。AMFはこのサービスを呼び出して、Requested NSSAI・加入情報・網構成に基づく Allowed NSSAI や、適切な AMF Set/候補AMF の情報を取得します。スライス選択の判断ロジックそのものはNSSF側に集約され、AMFは支援要求と結果適用を担います。

Basic Concept — 初心者向け説明¶

N22を、総合受付と案内デスクの問い合わせに例えます。

あなたのスマホがネットワークに登録しようとすると、登録担当のAMFが動きます。UEは「このスライス（S-NSSAI）を使いたい」という希望（Requested NSSAI）を提示します。AMFはまず自分の手元情報（ローカル構成・加入情報）で「許可していいスライス（Allowed NSSAI）」を決めようとします。ところが、スライス構成は網全体の情報が絡むため、AMFだけでは決めきれないことがあります。

そのときAMFは、スライス選択の案内デスクであるNSSFに問い合わせます。NSSFは網のスライス構成表と加入者情報を照らし合わせ、Allowed NSSAI（許可スライス一覧）や、必要なら「その客はこちらの窓口＝別のAMFへ」という担当割り当て（候補AMF Set）を返します。AMFはこの回答に従い、場合によっては適切なAMFへ処理を引き継ぎます（AMF再選択）。

このNSSFへの問い合わせは、専用の電話回線（N2やN4のような専用プロトコル）ではなく、社内Webシステム（HTTP）でリクエストを投げて回答をもらうイメージです。これが SBI（Service Based Interface）＝NF同士がWeb API（HTTP/2）で会話する仕組みです。要求も応答も、人間に読みやすい JSON という書式でやり取りされます。

Protocol / Transport¶

Architecture¶

N22がAMFとNSSFを結び、AMFがN1でUE（Requested NSSAI）と、N8でUDM（加入NSSAI）とも連携する文脈を示します。

flowchart LR
  UE["UE"]
  AMF["AMF"]
  NSSF["NSSF (スライス選択支援)"]
  UDM["UDM"]

  UE -. "N1 (Requested NSSAI)" .- AMF
  AMF == "N22 (Nnssf_NSSelection)" ==> NSSF
  AMF -. "N8 (加入NSSAI)" .-> UDM

  classDef ctrl fill:#efe,stroke:#3a3,stroke-width:2px;
  class AMF,NSSF ctrl;

図の読み方: UEはN1でRequested NSSAI（使いたいスライス希望）をAMFへ提示します。AMFはこれと、N8経由でUDMから得た加入NSSAI（許可されうるスライス）を突き合わせ、Allowed NSSAIを決めようとします。ローカルで解決しきれないときに、太い線(==>)のN22でNSSFへスライス選択支援を要求し、NSSFがAllowed NSSAIや候補AMFを返します。N22は「スライス選択を決めるための問い合わせ」の回線である点に注目してください。

利用Procedure¶

N22は主に Registration（登録） 手続きの中で、AMFがスライス選択を自力で解決できないときに使われます。

• スライス選択支援の要求（Registration中）: UEのRequested NSSAIと加入情報（加入NSSAI）をAMFが突き合わせ、Allowed NSSAIの決定やサービングAMFの適否をローカルで確定できない場合、AMFが Nnssf_NSSelection_Get（概念上のオペレーション、名称・方式は要確認）でNSSFへ支援を要求する。
• 結果の取得と適用: NSSFはRequested NSSAI・加入情報・網構成から Allowed NSSAI や適切な AMF Set/候補AMF を返す。AMFはこれをUEへの登録応答に反映し、必要に応じて AMF再選択（別のAMFへの処理引き継ぎ）を行う。
• 網スライス可用性の連携（付随）: NSSFはAMF等から網のスライス可用性情報の更新・通知を受け取り、選択判断に用いる場合がある（詳細・方向は要確認）。

このNSSF連携は条件付きで、AMFが自力でスライス選択を解決できるときには行われません（構成依存）。

手順の詳細な流れ（メッセージシーケンス、条件、NSSAIの各種IE、AMF再選択のトリガー等）は Network Slicing の記述に集約されています。スライス選択の細部はそちらを参照してください。

主なMessage¶

N22はSBIなので、メッセージはHTTPメソッド + リソース操作の形を取ります（NGAPのようなprocedureCodeではなくRESTful操作）。代表的なサービスオペレーションは次のとおりです。

HTTP操作の対応は概念整理です: 上表の「HTTP操作」は理解のための対応づけであり、各オペレーションの正確なメソッド・リソースURI・呼び出し方向はTS 29.531のOpenAPI定義に従います。厳密なメソッド割り当て・オペレーション名は要確認とします。各メッセージの詳細は Message辞典 を参照してください。

Packet Analysis (Wireshark)¶

N22はSBIなので、キャプチャ上は HTTP/2 として観測されます（NGAP/SCTPのようなL4専用プロトコルは現れません）。

Decodeの見どころ:

• N22は TLSで暗号化されます。中身（HTTP/2ヘッダやJSONボディ）を見るには復号鍵（TLSセッションキー等）が必要です。鍵が無ければ tls の暗号化ペイロードとしてしか見えません。
• 復号できれば、HTTP/2の ヘッダ（:method、:path に .../nnssf-nsselection/... を含むリソースパス）でオペレーションを識別できます（パス表記は要確認）。
• ボディは JSON（Requested NSSAI、Allowed NSSAI、候補AMF情報等）で、人間に読みやすい構造で入っています。
• N2のNGAP（バイナリ、SCTP上）と違い、N22はWeb的（HTTP/JSON）である点が観察の要です。SCTP固有のフィルタ（sctp.port 等）は使いません。

EPCとの比較¶

• 4Gでは: 5Gのような標準化されたネットワークスライス選択（NSSF/N22相当）の機能はありません。UEを特定のコアネットワーク（専用ノード群）へ振り分ける発想としては DECOR / eDECOR（Dedicated Core Network） が前身的に存在しましたが、5Gスライス選択とは仕組みが異なります（対応関係は要確認）。
• 5Gでは: スライス選択を担う専用NFとして NSSF が導入され、AMFがスライス選択を自力解決できないときに N22（Nnssf_NSSelection） で支援を求める枠組みが SBI化された形で標準化されました（TS 29.531）。

ネットワークスライシングは5Gで本格導入された概念です。4GのDECOR/eDECORは「専用コアへの振り分け」という点で発想の一部を共有しますが、5Gのスライス選択（NSSAI/NSSF/N22）とは別物として扱うのが安全です（要確認）。

3GPP Specification¶

• 3GPP TS 29.531 — Nnssf_NSSelection サービス（ネットワークスライス選択、N22）。個別章番号は要確認
• 3GPP TS 29.500 / TS 29.501 — SBI framework（技術規約 / 設計原則・OpenAPI）。個別章番号は要確認
• 3GPP TS 23.501 §4 — システムアーキテクチャと参照点（N22の定義）／ §5.15 — ネットワークスライシング（NSSAI/Allowed NSSAI等）。章番号は要確認
• 3GPP TS 33.501 — SBIのセキュリティ（TLS等）。個別章番号は要確認

注記（要確認）: N22の実体が Nnssf_NSSelection（TS 29.531）であること、SBI共通framework が TS 29.500/29.501 系であること、参照点N22とサービスNnssfが同じ連携の2つの見方であることは、3GPPアーキテクチャの一般的整理です。各サービスオペレーション名・正確なリソースURI・HTTPメソッド割り当て・S-NSSAI/SSTの具体値・章番号の枝番は Release により差異があるため個別には要確認とします。

Summary¶

• N22は AMF ⇔ NSSF を結ぶ参照点だが、SBI（Service Based Interface）である点がN2(NGAP/SCTP)・N4(PFCP/UDP)と根本的に異なる。
• Protocolは HTTP/2 + JSON（RESTful）over TLS、実体はNSSFのサービス Nnssf_NSSelection（TS 29.531）。
• AMFが自力でスライス選択（Allowed NSSAI決定・サービングAMF適否）を解決できないとき、N22で NSSFへスライス選択支援を要求し、Allowed NSSAI や適切な AMF Set/候補AMF を得る。
• 参照点N22 = サービスNnssf_NSSelection は同じAMF⇔NSSF連携の2つの見方（本サイトの参照点／サービスの二重性の考え方は NSSF と共通）。
• 4Gには標準化されたスライス選択の相当機能はなく（DECOR/eDECORが前身的発想、要確認）、5Gで NSSF/N22 として SBI化された形で導入された。

Next Step¶

• NSSF — N22の相手側。ネットワークスライス選択支援の中枢
• AMF — N22を利用してAllowed NSSAI・候補AMFを取得し、必要ならAMF再選択を行うNF
• Network Slicing — NSSAI/Allowed NSSAI・スライス選択手順の詳細（集約先）
• N8 — AMFがUDMから加入NSSAI等の加入情報を取得する参照点
• Interface辞典 — N11/N12 ほか参照点の確認