【入門編】 NGAPにおけるInitial UE MessageとPDU Session Resource Setup Requestのパケットフロー – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

こんにちは!ネットワーク・ガジェットライターの私です。

最新のスマートフォンを手に入れて「わあ、5Gってやっぱり速いなぁ!」と感動した経験はありませんか?一瞬で動画が読み込まれ、オンラインゲームもサクサク。でも、その裏側で、あなたのスマホと基地局、そして見えないコアネットワークの間で、どれほどドラマチックなパケットのやり取りが行われているか、気になったことはありませんか?

今回は、そんなモバイル通信の裏舞台、特に5Gの頭脳であるコアネットワーク(5GC)と基地局(gNB)の間で交わされる「NGAP(Next Generation Application Protocol)」という言葉にスポットライトを当てます。

「また難しそうな横文字が出てきたぞ……」と思いましたよね?大丈夫です!一歩ずつ、身近な例えを交えながら優しく紐解いていきましょう。

—

5G通信の裏側を覗く:そもそもNGAPってなに?

私たちがスマホで「YouTubeを見よう!」とタップした瞬間、スマホから電波に乗って基地局(5Gでは gNB と呼びます)へデータが飛びます。しかし、基地局だけではインターネットの世界へデータを送り出すことはできません。基地局の背後には、通信の認証やデータのルーティングを行う「中枢司令室」が存在します。この司令室の名前をAMF(Access and Mobility Management Function)と言います。

この基地局(gNB)と司令室(AMF)が会話するための共通言語こそが、今回主役となるNGAPです。

難しく考えず、こうイメージしてください。

  • スマホユーザー = 荷物を送りたいお客さん
  • gNB(基地局) = 街の郵便局の窓口
  • AMF(コアネットワーク司令室) = 全国の配送網を管理する中央本局

お客さん(スマホ)が窓口(基地局)に来たとき、窓口の人は中央本局(AMF)へ「新しいお客さんが来ました!荷物を送りたいそうです!」と連絡帳を回しますよね。この連絡帳のやり取りを、まさにパケットの世界で再現しているのがNGAPなんです。

—

パケットフローの全貌:Initial UE Message から始まるドラマ

スマホが電源を入れて電波を掴み、実際にデータ通信(PDUセッション)を始めるまでには、いくつかのステップを踏む必要があります。今回はその中でも、非常に重要でドラマチックな2つのメッセージの流れを見ていきましょう。

1. Initial UE Message(初期メッセージ:お客さんが窓口にやってきた!)
2. PDU Session Resource Setup Request(PDUセッションリソース設定要求:中央本局からの指示書)

この2つが、どのようにネットワークの空を駆け巡っているのか、順番に追っていきますね。

—

ステップ1:Initial UE Message(第一声は「はじめまして」)

スマホがRRC接続(無線区間のつながり)を確立したあと、基地局(gNB)はコアネットワーク(AMF)に対して、「ねぇ、うちのエリアに新しいスマホ(UE)がやってきたよ!」と最初の報告を投げます。これが Initial UE Message です。

郵便局の窓口係が、中央本局のコンピュータに「新規顧客登録」の第一報を入力する瞬間をイメージしてください。この中には、「このスマホのID(SUCI/GUTIなど)」や「スマホがやりたいことの要件」などが詰め込まれています。

このときのNGAPメッセージの雰囲気を、少し擬似的な構造で覗いてみましょう。実務や検証でログを眺めるとき、こんな風に中身がパースされて見えてきます。

{
  "NGAP-PDU": {
    "initiatingMessage": {
      "procedureCode": 15, // InitialUEmessaegを表すプロシージャコード
      "criticality": "reject",
      "value": {
        "InitialUE-Message": [
          {
            "id": "RAN-UE-NGAP-ID",
            "value": 12345 // 基地局側でこのスマホを識別するID
          },
          {
            "id": "NAS-PDU",
            "value": "0x7e0041..." // スマホとコア間だけでやり取りされる秘密の暗号(NASメッセージ)
          },
          {
            "id": "UserLocationInformation",
            "value": "TAC: 0x0001, CellID: 0x0000001" // 今どの基地局のどのエリアにいるか
          }
        ]
      }
    }
  }
}

このメッセージを受け取ったAMF(中央本局)は、「よし、このユーザーの認証と、データの通り道(PDUセッション)の準備を始めよう!」と腰を上げます。

—

ステップ2:PDU Session Resource Setup Request(いよいよ通信の水道管を通す)

AMFがユーザーの認証を無事にパスさせると、今度は基地局(gNB)に対して、「よし、このユーザーのために、インターネットへ抜ける専用の水道管(PDUセッション)のバルブを開けてくれ!」と指示を出します。

これが PDU Session Resource Setup Request です。

現実世界に例えるなら、新しく引っ越してきた住人に対して、水道局の本部(AMF)から現場の作業員(gNB)へ「〇〇号室の水道メーターとパイプをつないで、水を使えるようにしてあげてね」と届く正式な工事発注書のようなものです。

このパケットの中には、私たちが普段YouTubeやWebブラウジングで使う「IPアドレス」を割り当てるための情報や、どのくらいの通信速度(QoS)を保証すべきかといった設定がぎっしり詰まっています。

こちらも、設定やパケット解析でよく目にするパラメーターのイメージを見てみましょう。

{
  "NGAP-PDU": {
    "initiatingMessage": {
      "procedureCode": 29, // PDU Session Resource Setup を表すコード
      "criticality": "reject",
      "value": {
        "PDUSessionResourceSetupRequest": [
          {
            "id": "AMF-UE-NGAP-ID",
            "value": 98765 // コア側が管理するID
          },
          {
            "id": "RAN-UE-NGAP-ID",
            "value": 12345 // 基地局側が管理するID
          },
          {
            "id": "PDUSessionResourceSetupListSUReq",
            "value": {
              "pduSessionId": 1, // ユーザーの何番目のセッションか(通常最初は1)
              "pduSessionResourceSetupRequestTransfer": {
                "transportLayerInformation": {
                  "gTP-TEID": "0x0000000A", // データをカプセル化するためのトンネルID
                  "transportLayerAddress": "192.168.100.10" // 基地局のUPF向けIPアドレス
                },
                "pduSessionType": "ipv4", // IPのバージョン
                "qosFlowSetupRequestList": [
                  {
                    "qosFlowIdentifier": 9, // QoSの種別(ベストエフォートやVoIPなど)
                    "qosFlowLevelQoSParameters": {
                      "arp": {
                        "priorityLevel": 15 // 優先度
                      }
                    }
                  }
                ]
              }
            }
          }
        ]
      }
    }
  }
}

この「工事発注書」を受け取った基地局(gNB)は、「了解!無線区間(スマホと基地局の間)の電波の設定と、コアネットワーク側へのトンネルを開通させるぜ!」と動き出し、完了したら PDU Session Resource Setup Response をAMFに送り返します。

この往復が終わった瞬間、晴れてスマホは「5Gの高速インターネットの世界」へ飛び出すことができるようになるのです。

—

現場のエンジニアが知っておくべき「ちょっとしたコツ」

ここまで読んで、「なんだかパケットのやり取りって、しっかり役割分担されていて美しいな」と感じていただけたのではないでしょうか。

最後に、私たちエンジニアがオープンソースの5Gコア(Open5GSやfree5GCなど)や実際のキャリア網の検証でNGAPのパケット(WiresharkなどでキャプチャしたSCTPパケット)を眺めるときに、役立つちょっとしたコツをお伝えします。

1. SCTPレイヤーに注目する
NGAPは、TCPではなくSCTP(Stream Control Transmission Protocol)という信頼性の高いプロトコルの上に乗っています。もし「接続が確立しないな」と悩んだら、NGAPの中身を見る前に、まずはSCTPのアソシエーション(ハンドシェイク)が綺麗に結ばれているかをWiresharkのフィルター(sctp)で確認するのが鉄則です。
2. Procedure Codeを覚えると一瞬でわかる
パケット解析の画面を開いたら、まずは Procedure Code を見ましょう。

  • 15 が来たら Initial UE Message だな
  • 29 が来たら PDU Session Setup だな

とパッと判断できるようになると、トラブルシューティングのスピードが劇的に上がります。

—

まとめ

今回は、モバイル通信の進化を支えるNGAPの世界から、Initial UE Message と PDU Session Resource Setup Request のパケットフローを紐解いてみました。

一見すると難解なシグナリングのやり取りも、「スマホというお客さんが窓口に来て、中央本局と基地局が書類をやり取りして通信の水道管を通している」という現実世界の比喩に置き換えると、ぐっと身近に感じられたのではないでしょうか。

ネットワークやインフラの世界は、こうした一つひとつの丁寧な「お辞儀と確認の連続」で成り立っています。この記事が、あなたのネットワーク学習のワクワクする第一歩となれば、ライターとしてこれ以上の喜びはありません。

それでは、また次回の深掘り記事でお会いしましょう!パケットの旅を楽しんでくださいね。

コメント

タイトルとURLをコピーしました