なぜ5GCのSBIはHTTP/2によるサービス呼び出しを中心に構成されているのか？

5Gコアがサービスベースアーキテクチャを採用したことで、ネットワーク機能間の関係は大きく変わりました。AMF、SMF、UDM、PCF、NSSF、AUSFなどの機能は、固定されたポイントツーポイントのプロトコルインターフェースでメッセージを交換するだけではありません。各NFが自らの機能をサービスとして公開し、必要に応じて他のネットワーク機能が利用する形になっています。

このモデルでは、あるNFが別のNFからリソースを取得したり、新しいコンテキストを作成したり、既存リソースを更新したり、不要になったリソースを削除したりできます。通信パターンは自然に 要求 → リソース操作 → 応答 という形になります。HTTPメソッド、URI、ステータスコード、JSONは、このようなサービス間のやり取りを表現する実用的な手段です。

簡略化したSBIプロトコルスタックは次のように表せます。

アプリケーション/JSON → HTTP/2 → TCP → IP → Ethernet

JSONはアプリケーションデータの表現方法を定義します。HTTP/2は要求と応答を整理して伝送します。TCPは信頼性のある配送を提供し、IPはアドレス指定とルーティングを担当し、Ethernetは基盤ネットワーク上でフレームを運びます。

これはN2、N3、N4などのインターフェースとは大きく異なります。N2はNGAP、N4はPFCP、ユーザープレーンでは一般にGTP-Uが使用されます。サービスベースインターフェースでは、サービス通信の伝送基盤としてHTTP/2が使われます。これは単なるプロトコル置換ではありません。5GCの設計思想が、あらかじめ定義されたインターフェースメッセージの交換から、サービスの呼び出しへと変わったことを示しています。

たとえば、AMFが加入者のアクセス管理サブスクリプションデータを必要とする場合、AMFは NFコンシューマ として動作し、NFプロデューサ として動作するUDMにリソースを要求します。コンシューマ側が主に知る必要があるのは、どのリソースへアクセスするか、どの操作を実行するか、そしてどのような結果が返るかです。個々のサービス手順ごとに完全に別の伝送方式を設計する必要はありません。

HTTP/2には、この環境に適した非常に実用的な利点もあります。複数のサービス要求が1本のTCP接続を共有できます。ネットワーク機能間のSBI通信は頻繁に発生するため、API呼び出しのたびに新しいTCP接続を確立すると、不要な接続管理オーバーヘッドが生じます。

HTTP/2はHTTP/1.1と比べてどのような伝送上の問題を解決するのか？

HTTP/2はHTTP/1.1のアプリケーションモデル全体を置き換えたわけではありません。GETやPOSTなどのメソッドは引き続き存在し、基本的な要求・応答モデルも同じです。大きく変わったのは、データの整理方法と伝送方法です。

5GCにとって重要なのはWebページの読み込みを高速化することではありません。本当の価値は、ネットワーク機能間で大量に発生する同時API呼び出しに対して、HTTP/2がより効率的な接続モデルを提供する点にあります。

1本の接続で複数のStreamを運べる

HTTP/1.1は持続的接続をサポートしていますが、1本の接続内での同時処理には依然として制約があります。従来の多くの構成では、並列性を高めるために複数のTCP接続を開き、その分だけクライアント側とサーバー側の両方で接続管理の負荷が増えていました。

HTTP/2は多重化を導入しています。1本のTCP接続内に複数の独立したStreamを同時に存在させることができます。前のトランザクションが完全に終わるまで次の通信を待つ必要はありません。複数のStreamに属するFrameを同じ接続上で交互に送信できます。

5GC SBI環境では、AMFが別のNFとの間にHTTP/2接続を確立した後、その接続は1回に1つのAPI要求しか処理できないわけではありません。複数のサービス操作がそれぞれ異なるStreamを使用し、各Streamが独自の要求と応答を運ぶことができます。

TCP接続の本数が少なければ接続管理のオーバーヘッドも減るため、5Gコアのネットワーク機能間で頻繁に発生するサービス通信に適しています。

HTTPメッセージはバイナリFrameとして伝送される

HTTP/1.xは基本的にテキスト指向です。要求行、ヘッダー、メッセージ本文は明確なテキスト構造として表現されます。HTTP/2は伝送フォーマットを変更し、プロトコル情報をバイナリFrameで運びます。

HTTPヘッダーは通常HEADERS Frameで運ばれ、実際のアプリケーションペイロードはDATA Frameで運ぶことができます。受信側はFrameヘッダーに含まれる情報、特にStream Identifierを使って、そのFrameがどのStreamに属するかを判断し、完全なHTTPメッセージを再構成します。

そのため、WiresharkでHTTP/2をキャプチャしても、HTTPテキストがひとかたまりで表示されるとは限りません。代わりに、HEADERS、DATA、その他のFrameタイプが連続して見えることが多くなります。

繰り返し使うヘッダーを毎回すべて送る必要はない

SBI APIトラフィックではHTTPヘッダーが繰り返し現れます。すべての要求が毎回同じヘッダーフィールドを完全な形で送信すると、重複オーバーヘッドはすぐに大きくなります。

HTTP/2はヘッダー圧縮にHPACKを使用します。簡単に言えば、両端がヘッダーテーブルを保持し、頻繁に繰り返されるフィールドを全文ではなくインデックスで表せるようにします。

ヘッダーの繰り返しが多いほど、圧縮の効果も高まります。ネットワーク機能が似たAPIを繰り返し呼び出す場合、メソッド、パス、共通ヘッダーなどのフィールドが何度も現れるため、HPACKは冗長な伝送を減らすうえで特に有効です。

HTTP/2にはServer Pushも定義されている

HTTP/2にはServer Pushの仕組みがあり、PUSH_PROMISE Frameが定義されています。これにより、クライアントが関連リソースを1つずつ明示的に要求する前に、サーバー側から先行して提供できます。

ただし、5GC SBIを理解するうえでServer Pushが最重要というわけではありません。実際のSBI分析では、接続の再利用、多重化、Stream、Frame、ヘッダー圧縮、APIの要求・応答モデルの方がはるかに重要です。

Connection、Stream、Message、Frameはどう理解すればよいか？

HTTP/2で混乱しやすい点の1つは、Connection、Stream、Message、Frameという用語が同時に出てくることです。それぞれを個別に暗記するより、階層関係として理解する方がはるかに簡単です。

Connection は基盤となるTCP接続です。TCPセッションが確立されると、その接続上でHTTP/2トラフィックが運ばれます。

Stream はConnection内部にある論理的な双方向チャネルです。各Streamには固有の整数IDがあります。1本のTCP接続内に複数のStreamを同時に存在させられることが、HTTP/2多重化の基礎です。

Message は論理的なHTTP要求または応答を表します。たとえばAMFがUDMへGET要求Messageを送信し、UDMが対応する応答Messageを返します。

Frame はHTTP/2が実際の伝送に使用する、より小さな単位です。1つのMessageは1つ以上のFrameで構成されます。代表例は次のとおりです。

• HEADERS Frame：HTTPヘッダー情報を運びます。

• DATA Frame：アプリケーションペイロードデータを運びます。

• その他のFrameタイプ：接続管理、フロー制御、その他のHTTP/2機能を支えます。

この関係は次のようにまとめられます。

1つのConnectionには複数のStreamsが含まれます。Streamは要求と応答のMessagesを運び、各Messageは1つ以上のFramesで構成されます。

HTTP/2のFrameヘッダーには、Length、Type、Flags、予約ビット、Stream Identifierなどのフィールドがあります。特にStream Identifierは、そのFrameがどの論理Streamに属するかを受信側に示すため重要です。

複数のStreamsのFramesが交互に到着しても、受信側はStream IDを使って正しいデータを関連付け、再構成できます。これが、HTTP/2が1本のTCP接続上で複数の同時トランザクションを効率よく運べる中核の仕組みです。

5Gコアのエンジニアにとって、この概念はパケット解析時に特に重要です。キャプチャ上でパケットが隣り合っているという理由だけでSBIトラフィックを同一の処理と見なしてはいけません。Stream ID、URI、HTTPメソッド、応答ステータスを合わせて判断する必要があります。

JSONとRESTful APIはどのように5GCの機能をリソース化するのか？

HTTP/2が答えるのは サービス通信をどのように効率よく運ぶか という問題です。5GC SBIのアプリケーションモデルを実際に定義しているのは、RESTful APIとリソース指向設計の組み合わせです。

RESTはアーキテクチャスタイルです。基本的な考え方の1つは、業務オブジェクトをリソースとして表現し、各リソースに一意のURIを割り当て、HTTPメソッドでそのリソースを操作することです。

5GCにおける「リソース」は、Webサイトで扱うようなオブジェクトに限定されません。加入者データ、SM Context、PDU Sessionに関係するオブジェクト、あるいはネットワーク機能が保持するその他の状態を表すことができます。

たとえば、ある加入者のアクセス管理サブスクリプションデータには特定のURIを割り当て、セッション管理サブスクリプションデータには別のURIを使うことができます。コンシューマ側から見ると、処理は単に次のようなものではなくなります。

「特定のUDMシグナリング手順を呼び出す。」

代わりに次の形になります。

特定のリソースに対してGET、POST、PUT/PATCH、DELETEのいずれかを実行する。

HTTPメソッドがリソースへの操作内容を定義する

代表的な操作は次のように理解できます。

• GET：リソースを取得または読み出します。

• POST：リソースを作成する、または定義済みの操作を呼び出します。

• PUT / PATCH：既存のリソースを更新します。

• DELETE：リソースを削除します。

サーバーは要求を処理した後、結果を示すHTTPステータスコードを返します。

200は一般に処理成功とデータ返却を示します。201は通常、リソースが正常に作成されたことを示します。204は、応答本文を返さずに処理が成功したことを示す場合があります。4xxは主に要求、リソース、認可の問題を示し、5xxは一般にサーバー側の処理問題を示します。

これらのステータスコードは5GCのトラブルシューティングで非常に有用です。HTTP/2接続が確立しているからといって、サービス操作そのものが成功したとは限りません。要求されたURI、HTTPメソッド、NFプロデューサが返したステータスコードを確認する必要があります。

JSONが実際の業務データを運ぶ

SBIのアプリケーションペイロードは一般にJSONで表現されます。JSONはキーと値の構造を基盤とする軽量なデータ交換形式で、文字列、数値、真偽値、配列、オブジェクト、入れ子構造などを表現できます。

つまり、HTTP/2のDATA Frameがペイロードを運び、そのFrameの中にあるJSONがアプリケーションデータの実際の意味を定義します。

エンジニアリングの観点では、HTTP/2とJSONを同じプロトコル層として扱ってはいけません。HTTP/2は伝送を整理し、JSONはアプリケーションデータを表し、RESTful APIはリソースとその操作を定義します。

5GC SBIのリソースURIはどのような構造か？

リソースという考え方を理解すれば、SBI URIの構造もはるかに分かりやすくなります。リソースパスは任意に決められるものではなく、構造化された階層に従います。

代表的な形式は次のように表せます。

{apiRoot}/{apiName}/{apiVersion}/{apiSpecificResourceUriPart}

各部分には固有の役割があります。

• apiRoot：サービスへアクセスするためのルートアドレスで、通常は http(s)://host(:port) の形式です。

• apiName：ネットワーク機能が公開する特定のSBI APIまたはサービス名です。

• apiVersion：APIのバージョンです。例：v1。

• apiSpecificResourceUriPart：特定のリソースまたは操作を識別するパスです。

たとえば、アクセス管理サブスクリプションデータとセッション管理サブスクリプションデータはどちらもUDMから提供される可能性がありますが、それぞれ異なるリソースパスを使用します。URIを見ることで、コンシューマがどのリソースを要求しているのかを明確に特定できます。

SMFのPDU Sessionサービスも同じ基本思想に従います。異なるSM ContextsやPDU Session関連リソースはそれぞれ固有のURIを持ち、作成、取得、変更、解放にはそれぞれ適切なHTTPメソッドが使用されます。

このリソース指向設計は、SBIインターフェースの捉え方を変えます。「Message A → Message B」のような従来型の順序だけを暗記するのではなく、SBIのやり取りを次のように分析できます。

サービス → リソース → メソッド → URI → ステータスコード → JSON本文

要求メッセージ名と応答メッセージ名を対応させる従来の通信プロトコルの考え方だけで5GC SBIを見ると、アーキテクチャが断片的に感じられることがあります。APIベースのリソースモデルとして見れば、ロジックははるかに明確です。

WiresharkでSBIトランザクションをどのように追跡すべきか？

HTTP/2の概念を理解したら、次は実際のパケット解析に適用します。1本のTCP接続に複数のHTTP/2 Streamsを同時に載せられるため、送信元IPと宛先IPだけでフィルタしても、無関係な複数のSBIトランザクションが同じキャプチャ内に混在することがあります。

実用的な方法は、まずNFコンシューマとNFプロデューサのIPアドレスを特定し、次に該当するStream IDを使って解析範囲を絞ることです。

たとえば、特定の要求がStream ID 1を使用している場合、サーバーアドレスとそのStream IDを組み合わせることで、対応する要求・応答トランザクションに属するFramesだけを分離できます。

トラフィックを絞り込んだ後は、次の情報に注目します。

• Stream ID：Framesが同じ論理Streamに属しているか確認します。

• HEADERS：HTTPメソッド、Path、その他のヘッダーフィールドを確認します。

• DATA：トランザクションがJSONアプリケーションペイロードを運んでいるか確認します。

• ステータスコード：NFプロデューサが要求をどのように処理したかを示します。

• URI：アクセス対象のサービス、APIバージョン、リソースを特定します。

トラブルシューティングは伝送層から始めて上位へ進めると効率的です。まずTCP接続が確立していることを確認します。TCPが使えなければ、HTTP/2やRESTful API通信の土台がありません。

次にHTTP/2層に正常なHEADERS FrameとDATA Frameが存在することを確認し、Stream IDで正しいトランザクションに関連付けます。

続いて、HTTPメソッドとURIが想定する操作に一致しているか確認します。SBIの問題の多くはネットワーク接続そのものではなく、リソースパスの誤り、APIバージョンの不一致、HTTPメソッドの誤りなどが原因です。

その後、HTTPステータスコードを確認します。4xx応答であれば、要求構文、存在しないリソース、認可、アプリケーションパラメータを調べます。5xx応答であれば、NFプロデューサ内部の処理問題を強く疑います。

HTTP要求が正しく届けられたことを確認してから、JSONペイロードの詳細を解析します。

SBIのトラブルシューティング手順全体は次のようにまとめられます。

TCP → HTTP/2接続 → Stream → HEADERS → メソッド/URI → DATA/JSON → ステータスコード

この手順を使えば、最初は非常に「インターネット的」に見える5GCプロトコルも、慣れた階層型の技術課題として整理できます。下位層では接続性、中間層ではHTTP/2の伝送動作、上位層ではAPIリソースと業務データを確認します。障害境界を特定しやすくなります。

より広い5GCアーキテクチャの観点では、SBIがHTTP/2を使う理由は単にHTTP/1.1より新しいからではありません。5GコアがNFの機能をサービスとして編成するため、頻繁なAPI呼び出し、同時サービス通信、リソース指向アクセスを効率よく支えられる通信モデルが必要だからです。

HTTP/2はConnections、Streams、Framesを提供します。多重化により接続利用効率が上がり、HPACKが繰り返しヘッダーのオーバーヘッドを減らし、バイナリフレーミングが構造化された伝送形式を提供します。JSONはアプリケーションデータを運び、RESTful APIはリソースとそれに対する操作を定義します。これらが組み合わさって、5GCサービスベースインターフェースの完全な通信モデルを構成します。

よくある質問

HTTP/2とRESTful APIは同じものか？

いいえ。HTTP/2はConnections、Streams、Framesなどの仕組みを定義するHTTP伝送プロトコルです。RESTは、アプリケーションオブジェクトをリソースとして表現し、そのリソースへURIとHTTPメソッドでアクセスする方法を定めるAPIアーキテクチャスタイルです。5GC SBIではHTTP/2上でRESTful形式のAPIを使用します。

Stream ID 0で通常のSBIアプリケーション要求を運べるか？

いいえ。Stream ID 0にはプロトコルレベルで特別な役割があり、通常のアプリケーションStreamには使用されません。実際のSBI要求を分析する場合は、業務トランザクションに割り当てられた0以外のStream IDを確認します。

SBIのapiRootにはIPアドレスを含める必要があるか？

必ずしも必要ではありません。apiRootの論理形式は http(s)://host(:port) です。hostはネットワークアーキテクチャとサービスディスカバリの仕組みに従って対象のサービスエンドポイントを示します。URIを分析するときは、apiRootとapiName、apiVersion、リソース固有パスを分けて考えると理解しやすくなります。

HTTP/2がバイナリフレーミングを使うのに、なぜDATA Frame内にJSONが見えるのか？

バイナリフレーミングとは、HTTP/2がプロトコルデータをどのように整理して伝送するかを示すものです。アプリケーション層のペイロード自体までバイナリ形式である必要はありません。DATA FrameはJSONを運ぶことができます。JSONが5GCのアプリケーションフィールドを定義し、HTTP/2がそのペイロードを適切なStreamに載せて伝送します。

HTTP 200応答があれば5GC手順全体の成功を証明できるか？

いいえ。HTTP 200は、その時点で特定のHTTP要求が正常に処理されたことを示すだけです。完全な5GC手順では、複数のネットワーク機能間で複数のサービス呼び出しが行われる場合があります。エンドツーエンドの手順全体が成功したと判断するには、URI、JSON内容、前後のシグナリングシーケンスも合わせて確認する必要があります。