Attach後なぜ、近くのP-GWからインターネットに出られるのか

はじめに

海外でスマートフォンやIoTデバイスを使っているときでも、
なぜか通信はスムーズに動き、「近くからインターネットに出ている」ように感じることがあります。

しかし実際には、ローミング中の通信は単純にローカルのネットワークから直接インターネットに出ているわけではありません。

では、

• なぜ“近く”からインターネットに出られるのか
• どの時点でその出口は決まっているのか

本記事では、この疑問に対して Local Breakout（LBO） の仕組みを軸に解説します。

ポイントは以下の通りになります：

• UEの通信の出口（P-GW）は、Home OperatorのPolicyによって決まる
• P-GWの選定はAttach手続き（コントロールプレイン）の中で行われる
• その後、GTPセッション確立（データプレイン）によりS-GW〜P-GW間のトンネルが構築され、通信の出口が確定する

つまり、Local Breakoutは「あとから最適化されるもの」ではなく、
👉 Attach手続きの中で論理的に決まり、GTPセッション確立によって実体として確定する仕組みになります。

この記事を読むことで、Local Breakoutがどのような仕組みで動いているのかを、構造的に理解できるようになります。

まだ「Attach後なぜ、インターネットに出られるのか」をご覧いただいていない方は、
先にお読みいただくことで、UE（スマートフォンやIoTデバイス）がネットワーク通信できるまでの流れの理解がより深まります。

---

1. そもそもLocal Breakoutとは何か

ここでは、日本のキャリアを契約したスマートフォンやIoTデバイスを持って、欧州に渡航しているケースを例に考えます。

例えば、日本で契約したSIMをそのまま利用し、欧州でローミング接続している状況になります。

このとき、通信の経路には大きく2つのパターンがあります。

重要なポイント

ここで重要なのは次の点になります：

👉 どちらの場合でも、通信の出口はHome Operatorが制御していることになります。

つまり、

• Visited Networkが勝手にインターネットに出しているわけではない
• Home Operatorが「どこから出すか」を決めている

という構造になります。

この「出口の決定」がどのように行われているかが、Local Breakoutの本質になります。

---

2. Attach時に何が起きているか

以前の記事で解説した通り、UEがネットワークに接続するときには、

• ネットワークへのAttach
  （記事「ローミングの初回接続はなぜ遅いのか」で解説）
• Attach後のGTPセッションセットアップ
  （記事「Attach後なぜ、インターネットに出られるのか」で解説） という手順が行われます。

ここで重要になるのが、

👉 「どのようにして通信の出口（P-GW）が選択されるのか」

という点です。

この仕組みを理解するために、Attach時の動作をもう少し深く見ていきます。 まずは、これまでのおさらいとして全体の流れを整理します。

	通信	処理内容	補足	関連記事
1	UE → MME	Attach Request	ネットワーク接続開始	ローミングの初回接続はなぜ遅いのか で解説した範囲
2	MME → HSS	Subscriber認証	加入者情報取得
3	HSS → MME	APN / Policy情報を取得	Default / Allowed APN
4	UE → MME	PDN Connectivity Request	UEがAPNを指定	Attach後なぜ、インターネットに出られるのか で解説した範囲
5	MME → S-GW	Create Session Request	接続条件確定
6	S-GW → DNS	APN Resolution	APN + Serving Network
7	S-GW → P-GW	GTP Sessionの作成	インターネット出口確定

ここでは 「接続している場所（Visited Network）が判断材料になる」 例で接続先が分散される仕組みを見ていきましょう。

ゴールは、

• 日本にいるのか

• 欧州にいるのか
  などの情報から

  👉 「どのP-GWを使うべきか」のPolicyに反映する

です。

*PLMNについては通信事業者の識別子5〜6桁です （記事「ローミングの初回接続はなぜ遅いのか」で解説）

APNと加入者ポリシーの関係

まず、P-GWの選択において前提となるのが、APNと加入者ポリシーの関係です。 "3"の過程で、Home NetworkのHSSからMMEに対して以下の情報が通知されます：

• Default APN
• Allowed APN（利用可能なAPN）

その後、“4”のPDN Connectivity Requestにおいて、UEは接続したいAPNを指定します。

ここで重要になるのは：

👉 UEが要求したAPNがAllowed APNに含まれているかどうか

です。

• 含まれている場合 → そのAPNで接続処理が進む
• 含まれていない場合 → 接続拒否（PDN Connectivity Reject）
• APN指定がない場合 → Default APNが適用される

つまりこの段階で、

👉 「どのAPNを使うか」

が確定します。

実際の接続先P-GWの特定

次に、決定されたAPNをもとに、実際の接続先P-GWの特定が行われます。

"5"のCreate Session Requestにおいて、MMEはS-GWに対して以下の情報を通知します：

• 使用するAPN
• 加入者情報（IMSIなど）
• Serving Network（Visited PLMN） これを受け取ったS-GWは、接続先P-GWを特定するためにDNSクエリを発行します。

このときのクエリは：

👉 APN + Serving Network（Visited PLMN）

をもとに構成されます。

例：iot.jupiter5.net + 23415（UKのServing Network）

このDNSクエリは、Home Network側のDNSに送信され、Home Network側のポリシーに基づいて適切なP-GWのアドレスが返されます。

Home DNSは単なる名前解決ではなく、

• APN
• 接続しているServing Network（Visited PLMN）
  といった情報をもとに、 適切なP-GWが返されるように設計されています

例えば：

• 欧州のPLMNからの接続 → 欧州近傍のP-GW
• 北米のPLMNからの接続 → 北米のP-GW
  といった形で、地理的に最適なP-GWが選択されます。

その結果、

👉 接続先のP-GWが決定される

という流れになります。

補足：より高度な制御について

本記事では、説明をシンプルにするために

👉 APN + Serving Network に基づいてP-GWが選択される構成

を前提としています。

一方で、実際の商用ネットワークでは、より高度な制御が行われる場合があります。

例えば：

• 加入者単位（IMSI単位）で接続先を分岐する
• 同一APNでも異なるリージョンへ接続させる

これらは、

• Control Planeでのポリシー制御
• DNSや内部ロジックとの連携
  といった追加要素により実現されます。 さらに、Serving Network側のMMEがこれらのポリシーに従って動作する実装であるかどうかも考慮する必要があります。

このような複雑さや接続性の課題を回避するために、GTP Proxyを用いた構成が採用される場合もあります。

GTP ProxyはHome Network事業者側に配置され、S-GWとP-GWの間を仲介することで、

👉 Home Network側でポリシー制御を完結させる

という役割を持ちます。

いずれの方式も追加要素が多く、構成が複雑になるため、本記事では扱いません。

---

3. 実務視点での影響

ここが実は一番重要になります。

IPアドレスはP-GWごとに異なる

• P-GWごとにIP Poolが異なる
• 同じSIMでも接続先によってIPが変わる

👉 インターネットから見た“場所”が変わることになります。

---

Geoベースのサービスへの影響

• CDNの配信先
• アクセス制御
• コンテンツ制限

例：

• 日本から接続しているのに海外IPになる
• AWSリージョン選択がズレる

---

IoT設計への影響

ここはIoTで非常に重要になります。

• Webhookの設計
• エンドポイントの配置
• レイテンシ設計

👉 「どこから出るか」を前提に設計しないと事故につながることになります。

典型例：

• 遠いリージョンにデータ送信して遅延増大
• Firewallで想定外のIPがブロックされる

---

まとめ

• UEのインターネット出口はAttach時に決まる
• P-GWはHome OperatorのPolicyにより選択される
• Location情報もその判断材料になる
• P-GWの分散配置によりLocal Breakoutが実現される
• この設計はパフォーマンスとサービス挙動に大きく影響する

---