JP2013153316A - ネットワークシステム，オフロード装置，及びオフロードトラフィックの制御方法 - Google Patents

Abstract

【課題】コア網のトラフィック削減の向上を図る。
【解決手段】移動局が接続可能な複数の基地局とコア網のとの間に介在し、オフロードトラヒックをオフロード網との間で送受信するアンカポイントとして機能する一方で、アンカポイントと移動局が接続中の基地局との間でオフロードトラヒックを中継する中継ポイントとして機能するオフロード装置であって、移動局が自装置を介してオフロードトラヒックの通信を開始する場合に、アンカポイント情報を記憶する記憶装置と、通信の継続中に、移動局のハンドオーバによって他のオフロード装置が中継ポイントとなる場合に、他のオフロード装置にアンカポイント情報を送信する送信装置と、自装置が中継ポイントとして機能する場合に、他のオフロード装置から受信されたアンカポイント情報を用いてオフロード対象のトラヒックを中継し、通信の終了時には、アンカポイントの設定を解除する制御装置とを含む。
【選択図】図４Ａ

Description

本発明は、ネットワークシステム，オフロード装置，及びオフロードトラフィックの制御方法に関する。

ＬＴＥ／ＥＰＣ（Long term Evolution/Evolved Packet Core）は、第３世代携帯電話
網（3G mobile system）の次世代における移動通信システムとして、３ＧＰＰにて標準化されている。ＬＴＥ／ＥＰＣは、ＬＴＥ網（ＬＴＥに準拠した無線アクセス網：ｅＵＴＲＡＮと呼ばれる）と、コア網としてのＥＰＣ網（ＳＡＥ（System Architecture Evolution）とも呼ばれる）とを含む。ＥＰＣ網は、ＩＭＳ（IP Multimedia Subsystem）網を介してＩＰ（Internet Protocol）網（パケット網）に接続される。ＩＰ網は、例えば、ＩＳ
Ｐ（Internet Service Provider）網（インターネット）やイントラネットである。

移動局（モバイル端末：ＵＥ（User Equipment）と呼ばれる）は、ＬＴＥ網を介してＥＰＣ網に接続することができ、ＥＰＣ網及びＩＭＳ網を介してＩＰ網に接続される。そして、移動局は、ＩＰ網に接続された様々なサーバや端末装置にアクセスすることによって、様々なパケット通信サービス（例えば、Ｗｅｂサービス、VoIP（Voice over IP））を
享受することができる。

ＥＰＣ網は、ＭＭＥ（Mobility Management Entity），Ｓ−ＧＷ（Serving Gateway）
，Ｐ−ＧＷ（Packet Data Network Gateway），ＰＣＲＦ（Policy and Charging rule Function）のような複数のノードを有している。移動局は、Ｓ−ＧＷ及びＰ−ＧＷを介してＩＭＳ網に接続され、ＩＰ網にアクセス可能となる。

ところで、ＥＰＣ網におけるトラヒック削減を目的の一つとした、トラヒックオフロード技術がある。トラヒックオフロード技術では、移動局からのトラヒックがＳ−ＧＷやＰ−ＧＷを経由することなくＩＳＰ網へ到達するように、ＥＰＣ網にオフロード装置が設けられる。オフロード装置は、移動局（無線アクセス網）からのトラヒックに対するアンカポイントとして機能する。オフロード装置は、移動局からのトラヒックを、ＥＰＣ網と異なるオフロード用のネットワーク（オフロード網：例えば、ＩＰ網，ＭＰＬＳ（Multi Protocol Label Switching）網）へ転送する（オフロード）。オフロードされたトラヒックは、オフロード網を通じて目的のＩＰ網に到達する（接続される）。

特表２００４−５２３１４８号公報 特表２０１０−５４１３１２号公報

ＥＰＣ網におけるトラヒックのオフロードでは、移動局における通信回線設定時に、通信回線単位でオフロードのアンカポイントとなるオフロード装置が決定される。アンカポイントのオフロード装置は、移動局が接続する基地局の変更によって変更されない。すなわち、移動局の位置に関係なく、移動局からの全てのオフロードトラヒックは、アンカポイント（のオフロード装置）を経由する。これによって、移動局の移動を起因とする、移動局と目的のＩＰ網との通信の切断や途絶が回避される。

しかしながら、移動局の移動によって、移動局からのオフロードすべきトラヒックを受けるオフロード装置と、アンカポイントのオフロード装置とが異なる状態となった場合には、オフロード装置間にトラヒックが発生する。オフロード装置間のトラヒックに係る伝送距離は、アンカポイントのオフロード装置と移動局との距離が離れる程、長くなる。

また、例えば、現在の移動局の位置において、移動局からのトラヒックを受けるオフロード装置（アンカポイントのオフロード装置と異なる）が目的のＩＰ網へ向けたオフロードを実施することによってオフロード装置間のトラヒックの伝送距離を大幅に短縮できる状況であっても、トラヒックはアンカポイントのオフロード装置を経由する。このようなトラヒックは、ＥＰＣ網（コア網）の負荷増大、リソースの浪費を招来する虞があった。

本発明の一側面は、コア網のトラヒック削減の向上を図ることのできる技術を提供することを目的とする。

本発明の一側面は、移動局が接続可能な複数の基地局と、
前記複数の基地局を収容するコア網と、
前記複数の基地局と前記コア網との間に介在し、オフロード対象のトラヒックをオフロード網との間で送受信するアンカポイントとして機能する一方で、前記アンカポイントと前記移動局が接続中の前記複数の基地局の一つとの間で前記オフロード対象のトラヒックを中継する中継ポイントとして機能する複数のオフロード装置とを含み、
前記各オフロード装置は、
前記移動局が自装置を介してオフロード対象のトラヒックの通信を開始する場合に、自装置に係る前記トラヒックの回線情報，前記通信の識別情報，及び前記トラヒックのアンカポイントの位置情報を含むアンカポイント情報を記憶する記憶装置と、
前記通信の継続中に、前記移動局のハンドオーバによって他のオフロード装置が前記中継ポイントとなる場合に、前記他のオフロード装置に前記アンカポイント情報を送信する送信装置と、
自装置が前記中継ポイントとして機能する場合に、他のオフロード装置から受信された前記アンカポイント情報を用いてオフロード対象のトラヒックを中継し、前記通信の終了時には、前記アンカポイントの設定を解除する制御装置とを含む
ネットワークシステムである。

本発明の一側面によれば、コア網のトラフィック削減の向上を図ることができる。

図１は、第１実施形態に係るネットワークシステムの構成例を示す。 図２は、オフロードＧＷ（ｏＧＷ）のハードウェア構成例を示す。 図３は、図２に示したＣＰＵが記憶装置に記憶されたプログラムを実行することによって実現されるｏＧＷの機能の説明図である。 図４Ａは、図３に示したＣＰＵが実現する機能の説明図である。 図４Ｂは、移動局の起動からオフロード通信開始までのシーケンス例を示す。 図４Ｃは、オフロード通信中における、Ｓ１ベースのハンドオーバのシーケンス例を示す。 図４Ｄは、オフロード通信中における、Ｘ２ベースのハンドオーバのシーケンス例を示す。 図５は、オフロード条件適用状態テーブルのデータ構造例を示す。 図６は、Uplink GTP-uパケット(S-GW宛）のデータ構造例を示す。 図７は、Downlink GTP-uパケット(eNB宛）のデータ構造例を示す。 図８は、uplink オフロードアンカポイント宛パケットのデータ構造例を示す。 図９は、アンカポイントからＷｅｂサイトへ伝送されるパケットのデータ構造例を示す。 図１０は、Ｗｅｂサイトからアンカポイントへ伝送されるパケットのデータ構造例を示す。 図１１は、downlink オフロード振り分けポイント宛パケットのデータ構造例を示す。 図１２は、振分ポイントでのBearer状態管理データのデータ構造例を示す。 図１３は、オフロードアンカポイントでのＴＯＦ中継状態管理データのデータ構造例を示す。 図１４は、Initial Context Setup Request メッセージの構成例を示す。 図１５は、Initial Context Setup Responseメッセージの構成例を示す。 図１６は、Handover Required メッセージの構成例を示す。 図１７は、Handover Request メッセージの構成例を示す。 図１８は、Handover Request Ack.メッセージの構成例を示す。 図１９は、Handover Commandメッセージの構成例を示す。 図２０は、UE Context Release Commandメッセージの構成例を示す。 図２１は、X2AP:.Handover Requestメッセージの構成例を示す。 図２２は、X2AP:.Handover Request Ack.メッセージの構成例を示す。 図２３は、X2AP:UE Context Releaseメッセージの構成例を示す。 図２４は、Path Switch Requestメッセージの構成例を示す。 図２５は、Path Switch Request Ack.メッセージの構成例を示す。 図２６は、uplink GTP-uパケット（S-GW宛）受信時の処理フロー例を示す。 図２７は、オフロードアップリンク宛のパケット受信時の処理フロー例を示す。 図２８は、オフロード網からのオフロードアンカポイント宛のパケット受信時の処理フロー例を示す。 図２９は、downlink オフロード振り分けポイント宛パケット受信時の処理フロー例を示す。 図３０は、Initial Contex Setup Request メッセージ傍受時の処理フロー例を示す。 図３０Ａは、オフロード用ＧＴＰ−ｕトンネル生成フロー（サブルーチン）の例を示す。 図３１は、Initial Context Setup Responseメッセージ傍受時の処理フロー例を示す。 図３２は、Handover Requiredメッセージ傍受時の処理フロー例を示す。 図３３は、Handover Requestメッセージ傍受時の処理フロー例を示す。 図３４は、Handover Request Ack.メッセージ傍受時の処理フロー例を示す。 図３５は、Handover Commandメッセージ傍受時の処理フロー例を示す。 図３５Ａは、オフロード用ＧＴＰ−ｕ切替処理フロー（サブルーチン）の例を示す。 図３６は、UE Context Release Commandメッセージ傍受時の処理フロー例を示す。 図３７は、X2AP: Handover Requestメッセージ傍受時の処理フロー例を示す。 図３８は、Path Switch Requestメッセージ傍受時の処理フロー例を示す。 図３９は、Path Switch Request Ack.メッセージ傍受時の処理フロー例を示す。 図４０は、X2AP: UE Context Releaseメッセージ傍受時の処理フロー例を示す。 図４１は、TCP Connection生成後のオフロード条件適用状態の例（Bearer状態データ)を示す。 図４２は、TCP Connection生成後のオフロード条件適用状態の例（中継状態管理データ）を示す。 図４３は、TCP Connection生成後のオフロード条件適用状態の例（オフロード条件適用状態データ）を示す。 図４４は、TCP Connection生成後のオフロード条件適用状態の例（トラヒックの流れ）を示す。 図４５は、S1-Based Handoverでのオフロード条件適用状態の引き継ぎの例（Bearer状態データ)を示す。 図４６は、S1-Based Handoverでのオフロード条件適用状態の引き継ぎの例（中継状態管理データ）を示す。 図４７は、S1-Based Handoverでのオフロード条件適用状態の引き継ぎの例（オフロード条件適用状態データ）を示す。 図４８は、S1-Based Handoverでのオフロード条件適用状態の引き継ぎの例（トラヒックの流れ）を示す。 図４９は、Handover完了後にTCP Connectionが維持された場合の、オフロード条件適用状態の例（Bearer状態データ)を示す。 図５０は、Handover完了後にTCP Connectionが維持された場合の、オフロード条件適用状態の例（オフロード条件適用状態データ）を示す。 図５０Ａは、Handover完了後にTCP Connectionが維持された場合の、オフロード条件適用状態の例（中継状態管理データ）を示す。 図５１は、Handover完了後にTCP Connectionが維持された場合の、オフロード条件適用状態の例（トラヒックの流れ）を示す。 図５２は、X2-Base Handoverでのオフロード条件適用状態の引き継ぎの例（Bearer状態データ)を示す。 図５３は、X2-Base Handoverでのオフロード条件適用状態の引き継ぎの例（中継状態管理データ）を示す。 図５４は、X2-Base Handoverでのオフロード条件適用状態の引き継ぎの例（オフロード条件適用状態データ）を示す。 図５５は、X2-Base Handoverでのオフロード条件適用状態の引き継ぎの例（トラヒックの流れ）を示す。 図５６は、Handover後の新TCP Connection生成後のオフロード条件適用状態の例（オフロード条件適用状態データ）を示す。 図５７は、Handover後の新TCP Connection生成後のオフロード条件適用状態の例（中継状態管理データ）を示す。 図５８は、Handover後の新TCP Connection生成後のオフロード条件適用状態の例（トラヒックの流れ）を示す。 図５８Ａは、Handover後の新TCP Connection生成後のオフロード条件適用状態の例（Bearer状態データ)を示す。 図５９は、Handover後のTCP Connection切断後のオフロード条件適用状態の例（オフロード条件適用状態データ）を示す。 図６０は、Handover後のTCP Connection切断後のオフロード条件適用状態の例（中継状態管理データ）を示す。 図６１は、Handover後のTCP Connection切断後のオフロード条件適用状態の例（トラヒックの流れ）を示す。 図６２は、Handover後のTCP Connection切断後のオフロード条件適用状態の例（Bearer状態データ)を示す。 図６３は、第２実施形態に係るネットワークシステムの構成例を示す。 図６４は、移動局を起動し、ＩＰＴＶ放送の視聴を開始し、Multicastパケット通信がオフロードされる場合のシーケンス例を示す。 図６５は、オフロード条件適用テーブル構成例（Multicast/UDP/IPTV）を示す。 図６６は、eNBから S-GWへ向かうGTP-uのパケット(IGMP-join,IGMP-leave)の構成例を示す。 図６７は、S-GWからeNBへ向かうGTP-uのパケット(IPTV放送配信）の構成例を示す。 図６８は、オフロード対象としたuplinkパケットを振分ポイントのoGWからアンカポイントのoGWへ伝達するときに利用するパケット(IGMP-join,IGMP-leave)の構成例である。 図６９は、オフロード対象としたuplinkパケット（IGMP-join, IGMP-leave)をアンカポイントのoGWからオフロードネットワークへ送信するときに利用するパケット(IGMP-join, IGMP-leaveの構成例を示す。 図７０は、IPTV局からオフロードネットワークを経由してオフロードアンカポイントへ到達するパケット（IPTV放送配信）の構成例を示す。 図７１は、オフロードアンカポイントのoGWから振分ポイントのoGWへ伝達するときに利用するパケット（IPTV放送配信）の構成例を示す。 図７２は、オフロードアンカポイントでのＴＯＦ中継状態管理データの構成例を示す。 図７３は、eNBからS-GWへ向かうuplink GTP-uパケット(IGMP-join/IGMP-leave)を振分ポイントのoGWが受信した場合の処理フロー例を示す。 図７４は、オフロードアンカポイントのoGWが振り分けポイントのoGWからオフロード対象のuplinkパケット(IGMP-join,IGMP-leave)を受信した場合の処理フロー例を示す。 図７５は、オフロードネットワークからオフロードアンカポイントのoGWがIPTV放送配信のMulticastパケットを受信した場合の処理フロー例である。 図７６は、Handover Commandメッセージ傍受時の処理フローの例を示す。 図７７は、X2AP: Handover Requestメッセージ傍受時の処理フローの例を示す。 図７８は、IPＴＶ放送視聴開始後のオフロード条件適用状態の例（Bearer状態管理データの設定例）を示す。 図７９は、IPＴＶ放送視聴開始後のオフロード条件適用状態の例（ＴＯＦ中継状態管理データの設定例）を示す。 図８０は、IPＴＶ放送視聴開始後のオフロード条件適用状態の例（オフロード条件適用状態データの設定例）を示す。 図８１は、IPＴＶ放送視聴開始後のオフロード条件適用状態の例（トラヒックの流れ）を示す。 図８２は、S1-base Handoverでのオフロード条件適用状態（IPTV放送視聴情報）の引き継ぎの例（Bearer状態管理データの設定例）を示す。 図８３は、S1-based Handoverでのオフロード条件適用状態（IPTV放送視聴情報）の引き継ぎの例（ＴＯＦ中継状態管理データの設定例）を示す。 図８４は、S1-based Handoverでのオフロード条件適用状態（IPTV放送視聴情報）の引き継ぎの例（オフロード条件適用状態データの設定例）を示す。 図８５は、S1-based Handoverでのオフロード条件適用状態（IPTV放送視聴情報）の引き継ぎの例（トラヒックの流れ）を示す。 図８６は、Handover完了時にＩＰＴＶ放送視聴を維持するオフロード条件適用状態の例（Bearer状態管理データの設定例）を示す。 図８７は、Handover完了時にＩＰＴＶ放送視聴を維持維持するオフロード条件適用状態の例（オフロード条件適用状態データの設定例）を示す。 図８８は、Handover完了時にＩＰＴＶ放送視聴を維持維持するオフロード条件適用状態の例（トラヒックの流れ）を示す。 図８９は、X2-based Handoverでのオフロード条件適用状態(IPTV放送視聴情報）の引き継ぎの例（Bearer状態管理データの設定例）を示す。 図８９Ａは、Handover完了時にＩＰＴＶ放送視聴を維持維持するオフロード条件適用状態の例（Bearer状態管理データの設定例）を示す。図-157は、図-154の状態でのＴＯＦ中継状態管理データの設定例である。 図９０は、X2-based Handoverでのオフロード条件適用状態(IPTV放送視聴情報）の引き継ぎの例（ＴＯＦ中継状態管理データの設定例）を示す。 図９１は、X2-based Handoverでのオフロード条件適用状態(IPTV放送視聴情報）の引き継ぎの例（オフロード条件適用状態データの設定例）を示す。 図９２は、X2-based Handoverでのオフロード条件適用状態(IPTV放送視聴情報）の引き継ぎの例（トラヒックの流れ）を示す。 図９３は、Handover後の新IPTV放送視聴開始後のオフロード条件適用状態の例（オフロード条件適用状態データの設定例）を示す。 図９４は、Handover後の新IPTV放送視聴開始後のオフロード条件適用状態の例（ＴＯＦ中継状態管理データの設定例）を示す。 図９５は、 Handover後の新IPTV放送視聴開始後のオフロード条件適用状態の例（トラヒックの流れ）を示す。 図９６は、Handover後の新IPTV放送視聴開始後のオフロード条件適用状態の例（Bearer状態管理データの設定例）を示す。 図９７は、Handover後の新IPTV放送視聴開始後のオフロード条件適用状態の例（オフロード条件適用状態データの設定例）を示す。 図９８は、Handover後の新IPTV放送視聴開始後のオフロード条件適用状態の例（ＴＯＦ中継状態管理データの設定例）を示す。 図９９は、 Handover後のIPTV放送視聴離脱後のオフロード条件適用状態の例（トラヒックの流れ）を示す。 図１００は、Handover後のIPTV放送視聴離脱後のオフロード条件適用状態の例（Bearer状態管理データの設定例）を示す。 図１０１は、ｏＧＷが記憶装置で保持するｅＮＢを収容するｏＧＷ情報の構成例を示す。

以下、図面を参照して本発明の実施形態について説明する。実施形態の構成は例示であり、本発明は実施形態の構成に限定されない。

〔第１実施形態〕
第１実施形態では、トラヒックオフロード対象のＴＣＰ（Transmission Control Protocol）通信について、ＴＣＰコネクション（TCP Connection:ＴＣＰセッションとも呼ばれる）毎に、ＴＣＰコネクションに係る通信を開始したオフロード装置を目的のパケット網とのアンカポイント装置として決定する。

また、“トラヒックオフロード対象のＴＣＰコネクション情報”と、その“オフロードアンカポイントの位置(オフロード装置）”とを管理する。そして、移動局（UE)の移動（
ハンドオーバ）に伴って、ハンドオーバ先のオフロード装置に対し、“トラヒックオフロード対象のＴＣＰコネクション情報”と、その“オフロードアンカポイントの位置(装置
）情報”とオフロードトラヒックの回線情報とを含むアンカポイント情報を伝える。これによって、ＴＣＰ通信をハンドオーバ先のオフロード装置でも維持する。その後、ＴＣＰコネクションの終了（切断）を契機として、当該ＴＣＰコネクションに係るパケット網とオフロードアンカポイントを解放する。

＜全体構成＞
図１は、第１実施形態に係るネットワークシステムの構成例を示す。図１において、ネットワークシステムは、大略して、ＬＴＥ網（ｅＵＴＲＡＮ）１０と、ＥＰＣ網２０と、ＩＭＳ網３０と、ＩＳＰ（Internet Service Provider）網(インターネット)４０と、オフ
ロード網５０（図１では、オフロード網５１，５２を例示）とを備えている。ＬＴＥ網１０は、無線アクセス網の一例であり、ＥＰＣ網２０はコア網の一例である。ＩＳＰ網４０は、パケット網の一例である。図１において、ＩＳＰ網４０には、Ｗｅｂサイト＃ａを提供するＷｅｂサーバ４１と、Ｗｅｂサイト＃ｂを提供するＷｅｂサーバ４２とが接続されている。但し、Ｗｅｂサーバ４１及び４２は、ＩＳＰ網４０に接続される通信相手（Correspondence node：サーバ及び端末装置）の例示である。サーバ及び端末装置の種類、サ
ービスは、ＴＣＰ通信を行うものであれば良い。

ＬＴＥ網１０は、“ｅＮｏｄｅＢ（ｅＮＢ）”と呼ばれるＬＴＥ準拠の基地局１１を含む。ＥＰＣ網２０は、コア網の例示である。ＥＰＣ網２０は、ｅＮＢの他に、第２世代（２Ｇ：例えばＧＳＭ），第３世代（３Ｇ：例えばＷ−ＣＤＭＡ），第３．５世代（ＨＳＰＡ）の３ＧＰＰの無線アクセス網を収容することができる。さらに、ＥＰＣ網２０は、ＣＤＭＡ２０００，ＷｉＦｉのようなｎｏｎ−３ＧＰＰの無線アクセス網を収容することもできる。無線アクセス網１０は、上記した各無線アクセス網を含む。移動局（ＵＥ）６０は、基地局１１と無線接続することで、ＥＰＣ網２０及びＩＳＰ網４０を経て、Ｗｅｂサーバ４１，４２のような通信相手にアクセスすることができる。移動局６０は、移動局６０の移動に応じて、接続先の基地局１１を変更し（ハンドオーバ）、通信相手との通信を継続することができる。

ＥＰＣ網２０は、制御用交換局（ＭＭＥ）２１（図４Ａ参照），Ｓ−ＧＷ２２，Ｐ−ＧＷ２３，ＰＣＲＦ（図示せず）のような様々なノードを含んでいる。ＭＭＥ２１は、ネットワーク制御のＣプレーン（Control Plane）を扱う。ＭＭＥ２１は、ベアラ（Bearer：
ユーザとパケット網との間のコネクション）の確立・解放や、移動局の位置登録やハンドオーバのような移動制御を行う。また、ＭＭＥ２１は、加入者情報が登録されたＨＳＳ（Home Subscriber Server:図示せず）と連携した移動局の認証を行う。

Ｓ−ＧＷ２２は、ユーザデータのパケットデータであるＵプレーン（User Plane）を扱う。Ｓ−ＧＷ２２は、３ＧＰＰ（ｅＮＢ，２Ｇ／３Ｇ）の無線アクセス網のアンカポイントとして機能し、Ｐ−ＧＷ２３との間でユーザパケットデータの中継処理を行う。
Ｐ−ＧＷ２３は、ＩＳＰ網４０のようなパケット網に対する接続ポイントとなる。Ｐ−ＧＷ２３は、移動局へのＩＰアドレスの払い出し、ベアラ確立時におけるパケット網への接続に関したユーザ認証を行う。さらに、Ｐ−ＧＷ２３は、ＰＣＲＦの指示に従うＱｏＳ（Quality of Service）制御，課金データ生成，及びＤＨＣＰサーバのような機能を有する。ＭＭＥ２１，Ｓ−ＧＷ２２，Ｐ−ＧＷ２３のような各ノードは、ＥＰＣ網２０に１以上配置される。

基地局１１（本実施形態では、ｅＮｏｄｅＢを例示する）は、“Ｓ１−ＭＭＥインタフェース”と呼ばれるＵプレーンのインタフェースによってＭＭＥ２１と接続される。また、基地局１１は、“Ｓ１−Ｕインタフェース”と呼ばれるインタフェースによってＳ−Ｇ
Ｗ２２と接続される。Ｓ−ＧＷ２２とＭＭＥ２１とは、“Ｓ１１インタフェース”と呼ばれるＣプレーンのインタフェースで接続される。Ｓ−ＧＷ２２とＰ−ＧＷ２３とは、“Ｓ５”と呼ばれるＵプレーンのインタフェース、及びＵプレーン用のインタフェースによって接続される。また、基地局１１間は、“Ｘ２インタフェース”と呼ばれるインタフェースによって接続される。

図１に示すＥＰＣ網２０は、さらに、オフロードトラヒックを制御するノードとして機能する、１以上のオフロード装置（以下、オフロードゲートウェイ（オフロードＧＷ：ｏＧＷ）と表記）７０を備えている。図１に示す例では、オフロードＧＷ７０の例示として、オフロードＧＷ＃１，オフロードＧＷ＃２，及びオフロードＧＷ＃３が図示されている。

オフロードＧＷ７０は、基地局１１とＳ−ＧＷ２２との間に配置される。オフロードＧＷ７０の設置数は、適宜決定可能である。例えば、オフロードＧＷ７０は、基地局１１毎に配置することができる。オフロードＧＷ７０は、基地局１１とＳ−ＧＷ２２との間で送受信されるＣプレーンのパケットを傍受する。そして、オフロードＧＷ７０は、基地局１１とＳ−ＧＷ２２間を流れるＵプレーンのトラヒックのうち、オフロード対象のトラヒック（オフロードトラヒック）を決定する。

アップリンク通信（移動局（基地局１１）→通信相手）のオフロードトラヒックにおけるＵプレーンデータ（ユーザパケット）は、オフロードＧＷ７０にて分岐し、オフロード網５０へ転送される。オフロード網５０へ転送されたトラヒックは、ＥＰＣ網２０（Ｓ−ＧＷ２２，Ｐ−ＧＷ２３）を経由することなくＩＳＰ網４０に接続され、最終的に目的の通信相手（例えばＷｅｂサーバ４１）に到達する。一方、オフロードＧＷ７０は、ダウンリンク通信（通信相手（オフロード網５０）→移動局６０（基地局１１））のオフロードトラヒックを、Ｓ−ＧＷ２２から基地局１１へのトラヒックに合流させる。

移動局６０は、移動によって、自身の接続先の基地局１１を切り替える（ハンドオーバ）。基地局１１間のハンドオーバによって、基地局１１からのアップリンクのトラヒックを受信するオフロードＧＷ７０が変更される。例えば、移動局６０と接続される基地局１１が基地局１１Ａから基地局１１Ｂに変更されることによって、オフロードＧＷ７０は、オフロードＧＷ＃ＡからオフロードＧＷ＃Ｂへ変更される。

＜オフロードＧＷ＞
図２は、オフロードＧＷ（ｏＧＷ）７０のハードウェア構成例を示す。図２において、ｏＧＷ７０は、複数の回線インタフェース７１と、回線インタフェース７１に接続されたパケット転送制御装置（パケット転送制御回路：パケット転送コントローラ）７２と、パケット転送制御装置７２に接続されたＣＰＵ（Central Processing Unit）７３及び記憶
装置７４とを備えている。

回線インタフェース７１は、オフロードＧＷ７０と基地局１１とを結ぶ回線，オフロードＧＷ７０とＳ−ＧＷ２２とを結ぶ回線，オフロードＧＷ７０とＭＭＥ２１とを結ぶ回線，及びオフロードＧＷ７０とオフロード網５０とを結ぶ回線を収容する。オフロードＧＷ７０には、オフロードＧＷ７０が収容する回線数に対応する１以上の回線インタフェース７１が設けられる。回線インタフェース７１は、汎用又は専用の半導体回路（ＬＳＩ，ＡＳＩＣなど）によって形成される。

パケット転送制御装置７２は、パケット転送処理を行う。すなわち、パケット転送制御装置７２は、ルーティングテーブルを有し、パケットの宛先アドレスに対応する出力ポートをルーティングテーブルから割り出し、出力ポートへ向けてパケットを送出する。パケ
ット転送制御装置７２は、汎用又は専用の半導体回路（ＬＳＩ，ＡＳＩＣ，プログラマブルロジックデバイス（ＰＬＤ）,ＤＳＰ（Digital Signal Processor）など）が搭載され
た回路チップとして形成されることができる。

ＣＰＵ７３は、パケット転送制御装置７２の制御を通じて、ｏＧＷ７０全体の動作を制御する。ＣＰＵ７３は、コントローラ（制御部）の一例であり、プロセッサの一例である。なお、ＣＰＵ７３の機能を司るコントローラは、専用又は汎用のハードウェアチップの適用によって実現されることができる。記憶装置７４は、ＲＯＭ（Read Only Memory），ＲＡＭ(Random Access Memory)，ＥＥＰＲＯＭ（Electrically Erasable Programmable Read-Only Memory）などの半導体メモリによって形成される。記憶装置７４は、ＣＰＵ７
３の作業領域，ＣＰＵ７３によって実行される各種のプログラムやプログラムの実行に際して使用されるデータの格納領域を提供する。

図３は、図２に示したＣＰＵ７３が記憶装置７４に記憶されたプログラムを実行することによって実現されるｏＧＷ７０の機能の説明図である。図３に示すように、ＣＰＵ７３がプログラムを実行することによって、ＣＰＵ７３は、振分ポイント（中継ポイント）７５及びアンカポイント７６として機能する。

振分ポイント（中継ポイント）７５としての機能は、Ｓ１ＡＰ傍受処理１７１，Ｘ２ＡＰ傍受処理１７２，合流処理１７３，振分処理１７４とを含む。記憶装置７４には、ベアラ状態管理データ１７５と、オフロード条件適用状態管理データ１７６とが記憶される。ベアラ状態管理データ及びオフロード条件適用状態管理データは、振分ポイント７５によって使用される。

アンカポイント７６としての機能は、ＴＯＦ(Tramc Omoad Function) ＮＡＰＴ（Network Address Port Translation）処理１７７を含み、記憶装置７４には、ＴＯＦ中継状態管理データ１７８が記憶される。ＴＯＦ中継状態管理データはアンカポイント７６によって使用される。

図４Ａは、図３に示したＣＰＵ７３が実現する機能の説明図である。図４Ａには、ソースｏＧＷであるオフロードＧＷ７０（＃Ａ）と、ターゲットｏＧＷであるオフロードＧＷ７０（＃Ｂ）とが示されている。

図４Ａにおいて、Ｓ１ＡＰ傍受処理１７１は、基地局１１とＳ−ＧＷ２２との間で送受信される、Ｓ１ＡＰ（S1 Application Protocol）に基づく制御パケットを傍受する。Ｓ
１ＡＰは、基地局１１（ｅＵＴＲＡＮ）とＭＭＥ２１（ＥＰＣ）との間のシグナリングサービスを提供するＣプレーンのプロトコルである。Ｓ１ＡＰが有する機能は、例えば、ベアラの確立，変更及び開放、ハンドオーバ制御及び待ち受け移動局への着信制御である。

Ｘ２ＡＰ傍受処理１７２は、基地局１１間で送受信される、Ｘ２ＡＰ（X2 Application
Protocol）に基づく制御パケットを傍受する。Ｘ２ＡＰは、 Ｘ２インタフェース上の基地局（ｅＮｏｄｅＢ）間のＣプレーンプロトコルであり、基地局１１間における負荷管理及びハンドオーバ調整を支援する。

振分処理１７４は、アップリンクのＧＴＰ−Ｕ（GPRS Tunneling Protocol for User Plane）トンネルを流れるトラヒックのうち、トラヒックオフロードの対象のトラヒックを、ＴＯＦ ＮＡＰＴ処理１７７に分岐させる。ＧＴＰ−Ｕは、基地局１１とＳ−ＧＷ２２との間のＩＰ伝送用プロトコルである。トラヒックは、ＧＴＰ−Ｕに基づいて基地局１１とＳ−ＧＷ２２との間に確立されたベアラ（ＧＴＰ−Ｕトンネル）を流れる。なお、ＴＥＩＤ（Tunnel Endpoint IDentifier）は、パケットのＧＴＰヘッダに設定される、ＧＴＰ
−Ｕトンネルの終端点の識別子である。

合流処理１７５は、ＴＯＦ ＮＡＰＴ処理１７７からのオフロードトラヒックを、ダウンリンクのＧＴＰ−Ｕトンネルを流れるＳ−ＧＷ２２からのトラヒックに合流させる。
アンカポイント７６のＴＯＦ ＮＡＰＴ処理１７７は、ＥＰＣ網２０とオフロード網５０
との間のＮＡＰＴ処理（オフロード対象のトラヒックに関するＩＰアドレス変換、ＴＣＰ／ＵＤＰポート変換）を行う。

本実施形態では、移動局６０と通信相手（Ｗｅｂサーバ４１を例示する）との間でオフロード対象のＴＣＰ通信が開始されたときのオフロードＧＷ７０が、振分ポイント及びアンカポイントとして設定される。例えば、図４Ａに示すように、基地局１１Ａに接続した移動局６０がＷｅｂサーバ４１（図１）とのＴＣＰ通信を開始したときに、当該ＴＣＰ通信のオフロード処理を実行したオフロードＧＷ＃Ａが、振分ポイント及びアンカポイントとして設定される。

振分ポイントの変更は、移動局６０の移動に伴うハンドオーバによって起こる。即ち、移動局６０のハンドオーバ先の基地局１１（ターゲット基地局）が、ハンドオーバ元の基地局１１（ソース基地局）と異なるオフロードＧＷ７０に収容されている場合に、振分ポイントが変更される。

本実施形態では、新たな振分ポイントとなるオフロードＧＷ７０（ターゲットｏＧＷ）に対して、元のオフロードＧＷ７０（ソースｏＧＷ）から、オフロード対象のトラヒックの利用回線情報と、トラヒックに係る通信の識別情報（本実施形態ではＴＣＰコネクション情報）と、アンカポイントの位置情報とが送信される。

ターゲットｏＧＷは、送信された情報を保持し、オフロード対象のトラヒックをアンカポイントへ転送したり、アンカポイントから受信されるトラヒックを基地局１１へ向けて転送したりするために使用する。これによって、通信（ＴＣＰ通信）の継続中は、ハンドオーバに拘らず、アンカポイントの設定（位置）を維持することができる。

一方で、ターゲットｏＧＷにて新たなオフロード対象のＴＣＰ通信が開始された場合には、当該ターゲットｏＧＷが当該ＴＣＰ通信におけるアンカポイントとなる。また、維持されていたＴＣＰ通信が終了した場合には、オフロードトラヒックに対するアンカポイントの設定が解除（廃棄（削除））される。

なお、ハンドオーバには、同一のＭＭＥ２１の管理範囲内で実施されるＸ２ベースドハンドオーバ（X2 based handover）と、異なるＭＭＥ２１間に跨って行われるＳ１ベース
ドハンドオーバ（S1 based handover）とがある。オフロードＧＷ７０の変更は、オフロ
ードＧＷ７０が基地局１１毎に設置されている場合、Ｘ２ベースドハンドオーバとＳ１ベースドハンドオーバとの双方について起こる。

以下、オフロードＧＷ７０のさらなる詳細について説明する。図４Ｂは、移動局の起動及びオフロード処理の例を示すシーケンス図である。図４Ｃは、Ｓ１ベースのハンドオーバの処理例を示すシーケンス図であり、図４Ｄは、Ｘ２ベースのハンドオーバの処理例を示すシーケンスである。各シーケンスの詳細は後述する。

＜オフロード条件適用状態データ＞
図５は、図４Ａに示したオフロード条件適用状態データ１７６を保持するオフロード条件適用状態テーブル１７６Ａのデータ構造例を示す。図５に示すように、オフロード条件適用状態テーブル１７６Ａは、ｏＧＷ内ＵＥ識別子と、利用社回線識別子（E RAB ID）と
、ＴＣＰコネクション情報と、オフロードアンカポイント情報とを含む１以上のレコードを格納する。

“ｏＧＷ内ＵＥ識別子”は、当該オフロードＧＷ(ｏＧＷ)で移動局（ＵＥ）６０を一意に識別する情報である。“利用者回線識別子”は、移動局６０内での回線を一意に識別する情報であり、移動局６０での回線識別子(E RAB ID)と同期する。“ＴＣＰコネクション情報”は、移動局６０と通信相手（例えばＷｅｂサイト＃１）との通信における、オフロード対象のＴＣＰ通信のコネクション情報である。図５の例では、ＴＣＰコネクション情報は、移動局の識別子，ＩＰアドレス，ＴＣＰポート番号を含む。

“オフロードアンカポイント情報”は、オフロード対象のＴＣＰ通信を開始した位置でのオフロードアンカポイントの位置情報である。図５の例では、オフロードアンカポイント情報は、オフロードトラヒックに係るＴＥＩＤ及びオフロードＧＷの識別子を含む。

＜パケット＞
図６は、基地局（ｅＮＢ）１１からＳ−ＧＷ２２へ向かう、アップリンクのＧＴＰ−Ｕパケット（ＵＬカプセル化パケット）のデータ構造例を示す。図６に示すように、ＧＴＰ−Ｕパケットは、ユーザデータ，ＴＣＰヘッダ，及びＩＰヘッダを有するＩＰパケットが、ＧＴＰ−Ｕヘッダ，ＵＤＰ＿Ｇ（User Datagram Protocol）ヘッダ及びＩＰ＿Ｇヘッダでカプセル化されている。さらに、カプセル化パケットにレイヤ２（Ｌ２）ヘッダ及びレイヤ１（Ｌ１）ヘッダが付与されている。

ＧＴＰ−Ｕ内のＩＰパケットの宛先ＩＰアドレスとして、目的のＷｅｂサーバのＩＰアドレスが設定されており、送信元ＩＰアドレスは、移動局６０のＩＰアドレスが設定されている。一方、ＩＰ＿Ｇヘッダの宛先ＩＰアドレスは、目的のＳ−ＧＷ２２のＩＰアドレスであり、送信元アドレスは、基地局１１のＩＰアドレスである。ＴＥＩＤとしては、ＧＴＰトンネルの終端点に位置するＳ−ＧＷ２２を示す値が設定される。

図７は、Ｓ−ＧＷ２２から基地局１１へ送信される、ダウンリンクのＧＴＰ−Ｕパケット（ＤＬカプセル化パケット）のデータ構造例を示す。図７に示す例では、ＩＰヘッダ及びＩＰ＿Ｇヘッダ中の送信先ＩＰアドレスと宛先ＩＰアドレスが、図６に示したＧＴＰ−Ｕパケットと逆になる。ＴＥＩＤは、目的の基地局１１内のトンネル終端点を指す。また、図７に示すデータ構造例は、オフロード網５０経由のパケットを振分ポイント１７２から基地局１１へ送信されるＧＴＰ−Ｕのパケットのデータ構造例でもある。

図８は、オフロード対象のアップリンクパケットを振分ポイントのオフロードＧＷ７０からアンカポイントのオフロードＧＷ７０へ伝達するときに利用するパケット（ＵＬアンカポイント向けパケット）の構成例（データ構造例）である。説明を簡単にするため、ＧＴＰ−Ｕを用いたパケットを例示している。オフロードＧＷ間を転送されるパケットは、ＧＴＰ−Ｕと異なるプロトコルに基づくパケットを適用可能である。

図９は、オフロード対象のアップリンクパケットをアンカポイントのオフロードＧＷ７０からＷｅｂサーバ４１（Ｗｅｂサイト＃ａ）へ送信するときに利用されるパケット（ＵＬオフロードパケット）の構成例である。図１０は、Ｗｅｂサーバ４１（Ｗｅｂサイト＃ａ）からオフロードネットワークを経由してオフロードアンカポイントのオフロードＧＷ７０へ到達するパケット（ＤＬオフロードパケット）の構成例である。図１１は、オフロードアンカポイントのオフロードＧＷ７０から振分ポイントのオフロードＧＷ７０へ情報を伝達するときに利用するパケット（ＤＬ振分ポイント向けパケット）の構成例である。説明を簡単にするため、ＧＴＰ−Ｕベースのパケットを例示する。

＜ベアラ状態管理データ＞
図１２は、ベアラ状態管理データ１７５の説明図である。本実施形態において、ベアラ状態管理データ１７５は、ベアラ利用者特定テーブル１７５Ａと、ベアラテーブル１７５Ｂとで管理される。但し、テーブル構成は例示である。

ベアラ利用者特定テーブル１７５Ａ（ベアラ利用者特定テーブル１７５ａ，１７５ｂ）は１連のテーブルである。ベアラ利用者特定テーブル１７５ｂの“オフロードＧＷ内ＵＥ識別子”は、ベアラ利用者特定テーブル１７５ａのオフロードＧＷ内ＵＥ識別子と同値であり、同一レコードであることを明示するために記載されている。

“オフロードＧＷ内ＵＥ識別子”は、当該オフロードＧＷ(ｏＧＷ)で移動局（ＵＥ）を一意に識別する情報を記憶する。同一の移動局に対して、オフロードＧＷ内ＵＥ識別子は、同一の移動局に対して、オフロード条件適用状態テーブル１７６Ａ（図５）と、ベアラ利用者特定テーブル１７５Ａとの双方に、同一の値を有するオフロードＧＷ内ＵＥ識別子が記憶される。

“ＭＭＥ内ＵＥ識別子”は、ＭＭＥ２１で付与された移動局６０の識別子(MME UE S1AP
ID)である。“ＭＭＥ装置識別子”は、ＭＭＥ内ＵＥ識別子を移動局６０に付与したＭＭＥ２１（ＭＭＥ装置）の識別子である。“ｅＮＢ内ＵＥ識別子(S1AP)”は、基地局１１（ｅＮＢ）で付与された移動局６０の識別子(eNB UE S1AP ID)である。

“ｅＮＢ内ＵＥ識別子(X2AP)”は、基地局１１で付与された移動局６０の識別子(eNB UE X2AP ID)である。“ｅＮＢ装置識別子”は、ｅＮＢ内ＵＥ識別子(S1AP)およびｅＮＢ内ＵＥ識別子(X2AP)を移動局６０に付与した基地局１１の識別子である。

“T-Target セル識別情報”は、ハンドオーバ先のオフロードＧＷ７０で受信されたハ
ンドオーバ元の基地局１１が選択したハンドオーバ先セル識別情報である。“T-Targetセル内ＵＥ識別情報”は、ハンドオーバ先のオフロードＧＷ７０で受信されたハンドオーバ先の基地局１１が選択したハンドオーバ先セル内の移動局６０の識別情報である。 “Target ID”は、ハンドオーバ元のオフロードＧＷ７０で受信されたハンドオーバ元の基地
局１１が選択したハンドオーバ先の基地局１１の識別子である。

“S-Target セル識別情報”は、ハンドオーバ元のオフロードＧＷ７０で受信されたハ
ンドオーバ元の基地局１１が選択したハンドオーバ先セル識別情報である。“S-Targetセル内ＵＥ識別情報”は、ハンドオーバ元のオフロードＧＷ７０で受信したハンドオーバ先の基地局１１が選択したハンドオーバ先セル内の移動局６０の識別情報である。

＜ベアラテーブル＞
図１２に示すベアラテーブル１７５Ｂは、以下のようなデータを有する。“オフロードＧＷ内ＵＥ識別子”は、オフロードＧＷ７０で移動局６０を一意に識別する情報である。ベアラテーブル１７５Ｂには、同一の移動局６０に関して、ベアラ利用者特定テーブル１７５Ａの“オフロードＧＷ内ＵＥ識別子”と同値が格納される。“利用者回線識別子”は、移動局６０内での回線を一意に識別する情報であり、移動局６０での回線識別子(E RAB
ID)と同期する。

“uplink回線割り付け情報”は、利用者回線識別子に対するＳ−ＧＷ２２へ向かうアップリンクパケットの宛先情報である。“downlink回線割り付け情報”は、利用者回線識別子に対する基地局１１へ向かうダウンリンクパケットの宛先情報である。“ＴＯＦ振分ポイント位置情報”は、オフロード網５０経由のパケットをオフロードアンカポイントのオフロードＧＷ７０から振分ポイントのオフロードＧＷ７０へ伝達するための宛先情報であ
る。振分ポイントのオフロードＧＷ７０は、この“ＴＯＦ振分ポイント位置情報”に基づいて、オフロードアンカポイントのオフロードＧＷ７０からのパケットを待ち受ける。

“ＴＯＦアンカポイント位置情報”は、オフロード対象のパケットを振分ポイントのオフロードＧＷ７０からオフロードアンカポイントのオフロードＧＷ７０へ伝達するための宛先情報である。振分ポイントのオフロードＧＷ７０は、この“ＴＯＦアンカポイント位置情報”に基づいて、オフロードアンカポイントのオフロードＧＷ７０へパケットを送信する。

＜ＴＯＦ中継状態管理データ＞
次に、オフロードアンカポイントでのＴＯＦ中継状態管理データ１７８の構成例について説明する。図１３は、ＴＯＦ中継状態管理データ１７８に含まれるＴＯＦ中継管理テーブル１７８ａと、ＴＯＦセッション管理テーブル（TOF Session管理テーブル）１７８ｂ
とのデータ構造例を示す。

図１３において、ＴＯＦ中継管理テーブル１７８ａにおける、“オフロードＧＷアンカ内ＵＥ識別子”は、オフロードＧＷ(ｏＧＷ)７０のアンカポイント内で移動局６０を一意に識別する情報である。“利用者回線識別子”は、移動局６０内での回線を一意に識別する情報であり、移動局６０での回線識別子(E RAB ID)と同期する。

“ＴＯＦアンカポイント位置”は、オフロード対象のパケットを振分ポイントのオフロードＧＷ７０からオフロードアンカポイントのオフロードＧＷ７０へ伝達するための宛先情報である。オフロードアンカポイントのオフロードＧＷ７０は、この“ＴＯＦアンカポイント位置”に基づいて、振分ポイントのオフロードＧＷ７０からのパケットを待ち受ける。

“ＴＯＦ振分ポイント位置”は、オフロード網５０経由のパケットをオフロードアンカポイントのオフロードＧＷ７０から振分ポイントのオフロードＧＷ７０へ伝達するための宛先情報である。オフロードアンカポイントのオフロードＧＷ７０は、この“ＴＯＦ振分ポイント位置”に基づいて、振分ポイントのオフロードＧＷ７０へパケットを送信する。

図１３において、ＴＯＦセッション管理テーブル１７８ｂは、以下の情報を有する。“オフロードＧＷアンカ内ＵＥ識別子”は、オフロードＧＷ(ｏＧＷ)７０のアンカポイント内で移動局６０を一意に識別する情報である。同一の移動局６０に関して、ＴＯＦ中継管理テーブル１７８ａに格納される“オフロードＧＷアンカ内ＵＥ識別子”と同値が格納される。

“利用者回線識別子”は、移動局６０内での回線を一意に識別する情報である。移動局６０での回線識別子(E RAB ID)と同期する。“ＵＥ ＴＣＰコネクション情報”として、
ＴＣＰ通信のセッション（Session）毎に、移動局６０側のＩＰアドレス及びポート番号
が記憶される。“ｏＧＷ ＴＣＰコネクション情報”は、ＴＣＰ通信のセッション毎に、
移動局６０側のＩＰアドレス及びポート番号に対応する、オフロードＧＷ７０側のＩＰアドレス及びポート番号が記憶される。“Session状態”として、ＴＣＰ通信のセッション
毎の通信状態(“接続中”,アップリンク（UL）切断確認待ち、ダウンリンク（DL）切断確認待ち）が記憶される。

＜メッセージ＞
次に、ノード間でやりとりされる主なメッセージのデータ構造例を示す。図１４は、端末装置６０の起動時に、ＭＭＥ２１から基地局１１へ送信される、Initial Context Setup Requestメッセージの構成例を示す。図１５は、Initial Context Setup Requestメッセ
ージの応答メッセージである、Initial Context Setup Responseメッセージの構成例を示す。Initial Context Setup Responseメッセージは、基地局１１からＭＭＥ２１へ送信される。

図１６は、移動局６０のＳ１ベースのハンドオーバ時に、移動局６０からソースＭＭＥ２１へ送信されるHandover Requiredメッセージの構成例を示す。図１７は、Ｓ１ベース
のハンドオーバ時に、ターゲットＭＭＥ２１からターゲット基地局１１へ送信されるHandover Requestメッセージの構成例を示す。図１８は、Handover Requestメッセージに応じてターゲット基地局１１からターゲットＭＭＥ２１へ返信されるHandover Request Ack.
メッセージの構成例を示す。

図１９は、ソースＭＭＥ２１からソース基地局（サービング基地局）１１へ送信されるHandover Commandメッセージの構成例を示す。図２０は、ソースＭＭＥ２１からソース基地局１１へ送信されるUE Context Release Commandメッセージの構成例を示す。

図２１は、Ｘ２ベースのハンドオーバにおいて、ソース基地局１１からターゲットオフロードＧＷ７０経由でターゲット基地局１１へ転送される、X2AP: Handover Requestメッセージの構成例を示す。図２２は、X2AP: Handover Requestメッセージの応答メッセージである、X2AP:Handover Request Ack.メッセージの構成例を示す。X2AP:Handover Request Ack.メッセージは、ターゲットｏＧＷ７０を介して、ターゲット基地局１１からソース基地局１１へ送信される。図２３は、X2AP: UE Context Releaseメッセージの構成例を示す。

図２４は、Ｘ２ベースのハンドオーバにおいてターゲット基地局１１からＭＭＥ２１へ送信されるPath Switch Request メッセージの構成例を示す。図２５は、Path Switch Request メッセージの応答として、ＭＭＥ２１からターゲット基地局１１へ送信されるPath
Switch Request Ack.メッセージを示す。

＜処理フロー＞
次に、オフロードＧＷ７０における処理フローについて説明する。以下の処理は、ＣＰＵ７３（図２）によって実行される。図２６は、基地局１１からＳ−ＧＷ２２へ向かうuplink GTP-Uパケット（図６）を振分ポイントのオフロードＧＷ７０が受信した場合の処
理フロー例を示す。

図２６において、最初に、ベアラテーブル１７５Ｂ（図１２Ｂ）のアップリンク回線割付情報が受信パケットのＴＥＩＤに一致するベアラテーブル１７５Ｂのレコードが取り出され、ｏＧＷ内ＵＥ識別子、及び利用者回線識別子が特定される（Ｓ１）。

次に、レコードがあるか否かが判定される（Ｓ２）。レコードがなければ、処理がＳ１１へ進み、受信パケット（ＧＴＰ−ｕ）がＳ−ＧＷ２２へ中継され、図２６の処理が終了する。これに対し、レコードがあれば、処理がＳ３へ進む。

レコードがある場合には、オフロード条件適用状態テーブル１７６Ａ（図５）から、ｏＧＷ内ＵＥ識別子、利用者回線識別子に対応し、且つＴＣＰコネクション情報が受信パケットのＴＣＰコネクション情報（ソースＩＰアドレス（ＳＡ），ソースポート番号（scr port））と一致するレコードが取り出される（Ｓ３）。

次に、レコードがあるか否かが判定される（Ｓ４）。レコードがあれば、処理がＳ５へ進み、レコードが無ければ、処理がＳ８へ進む。

Ｓ５では、ＧＴＰ−ｕユーザデータは、ＴＣＰの切断要求（flag＝fin）であるか否か
が判定される。このとき、切断要求であれば、処理がＳ６に進み、切断要求以外であれば、処理がＳ７に進む。

Ｓ６では、オフロード条件適用状態テーブル１７６Ａ（図５）から、ｏＧＷ内ＵＥ識別子、利用者回線識別子に対応し、且つＴＣＰコネクション情報が受信パケットのＴＣＰコネクション情報（ソースＩＰアドレス（ＳＡ），ソースポート番号（scr port））と一致するレコードが削除される。

Ｓ７では、受信パケット（ＧＴＰ−ｕ）のＧＴＰ−ｕヘッダのＴＥＩＤが、オフロード条件適用状態テーブル１７６Ａのオフロードアンカポイント情報へ書き換えられ、オフロードアンカポイント情報が示すアンカポイントへパケットが中継される。その後、図２６の処理が終了する。

Ｓ８では、ＧＴＰ−ｕユーザデータは、ＴＣＰの接続要求（flag=syn）か否かが判定される。このとき、接続要求以外であれば、処理がＳ１１へ進み、接続要求であれば、処理がＳ９へ進む。

Ｓ９では、受信パケットのＴＣＰコネクション情報を含むレコードが、オフロード条件適用状態テーブル１７６Ａに追加される。追加レコードのＴＣＰコネクション情報は、移動局６０のｏＧＷ内ＵＥ識別子、利用者回線識別子と対応付けられる。

Ｓ１０では、受信パケット（ＧＴＰ−ｕ）のＧＴＰ−ｕヘッダのＴＥＩＤがベアラテーブル１７５ＢのＴＯＦアンカポイント位置情報で書き換えられる。さらに、パケットが、ＴＯＦアンカポイント位置情報の示すアンカポイントへ中継され、図２６の処理が終了する。

図２７は、オフロードアンカポイントのオフロードＧＷ７０が振り分けポイントのオフロードＧＷ７０からオフロード対象のuplinkパケット（図８）を受信した場合の処理フロー例である。

図２７において、最初に、ＴＯＦ中継管理テーブル１７８ａ（図１３Ａ）におけるＴＯＦアンカポイント位置が受信パケットのＧＴＰ−ｕヘッダのＴＥＩＤと一致するレコードがＴＯＦ中継管理テーブル１７８ａから取り出され、ｏＧＷアンカ内ＵＥ識別子及び利用者回線識別子が特定される（Ｓ２１）。

次に、レコードがあるか否かが判定される（Ｓ２２）。レコードが無ければ、図２７の処理が終了する。これに対し、レコードがあれば、処理がＳ２３へ進む。

Ｓ２３では、受信パケットのＵＥ側ＴＣＰコネクション情報とＴＯＦセッション管理テーブル１７８ｂ（図１３）のｏＧＷアンカ内ＵＥ識別子、利用者回線識別子と対応し、且つＵＥ ＴＣＰコネクション情報が一致するＴＯＦセッション管理テーブル１７８ｂのレコードが取り出される。

次に、レコードがあるか否かが判定される。レコードがあれば、処理がＳ２８に進み、レコードが無ければ、処理がＳ２５に進む。

Ｓ２５では、ＧＴＰ−ｕユーザデータは、ＴＣＰの接続要求か否かが判定される。このとき、接続要求以外であれば、図２７の処理が終了する。これに対し、接続要求であれば、処理がＳ２６に進む。

Ｓ２６では、ｏＧＷ（アンカポイント）のＴＣＰ通信ポートが捕捉され、ｏＧＷアンカ内ＵＥ識別子及び利用者回線識別子と対応付けて、ＴＯＦセッション管理テーブル１７８ｂにレコードが追加される。アンカポイントのＴＣＰ通信ポートは、テーブル１７８ｂのｏＧＷ ＴＣＰコネクション情報として記憶される。

Ｓ２７では、ＧＴＰ−ｕカプセルからＧＴＰ−ｕユーザデータが取り出されてＴＣＰ／ＩＰパケットが得られる。続いて、ｏＧＷ側ＴＣＰコネクション情報でＴＣＰ／ＩＰパケットの送信側ＴＣＰコネクション情報が書き換えられる。そして、宛先へ向けてＴＣＰ／ＩＰパケットが送信される。その後、図２７の処理が終了する。

Ｓ２８では、ＧＴＰ−ｕユーザデータは、ＴＣＰの切断要求か否かが判定される。このとき、切断要求以外であれば、処理がＳ２７に進む。これに対し、切断要求であれば処理がＳ２９に進む。

Ｓ２９では、ＴＯＦセッション管理テーブル１７８ｂから取り出されたレコードのセッション状態が“ＵＬ切断確認待ち”か否かが判定される。このとき、ＵＬ切断確認待ちの状態であれば、ＴＯＦセッション管理テーブル１７８ｂから、取り出されたレコードが削除され（Ｓ３１）、図２７の処理が終了する。

これに対し、ＵＬ切断確認待ちでなければ、ＴＯＦセッション管理テーブル１７８ｂの一致したレコードのセッション状態に“ＤＬ切断確認待ち”を設定する（Ｓ３０）。その後、図２７の処理が終了する。

図２８は、オフロード網５０からオフロードアンカポイントのオフロードＧＷ７０がオフロードアンカポイント宛のパケットを受信した場合の処理フロー例を示す。図２８のＳ４１では、受信パケット（ＴＣＰ／ＩＰ）の宛先情報（dst情報）をｏＧＷ側ＴＣＰコネ
クション情報として取り出される（Ｓ４１）。

次に、ＴＯＦセッション管理テーブル１７８ｂのレコード内で、ＵＥ側ＴＣＰコネクション情報がｏＧＷ側ＴＣＰコネクション情報と一致するレコードが検索され、取り出される（Ｓ４２）。

次に、レコードがあるか否かが判定される（Ｓ４３）。レコードがなければ、図２８の処理が終了する。これに対し、レコードがあれば、処理がＳ４４に進む。

Ｓ４４では、受信パケットはＴＣＰの切断要求を示すか否かが判定される。このとき、切断要求であれば、処理がＳ４７に進む。切断要求以外であれば、処理がＳ４５に進む。

Ｓ４５では、ＴＣＰ／ＩＰパケットのｏＧＷ側ＴＣＰコネクション情報に対応するＵＥ側ＴＣＰコネクション情報でＴＣＰ／ＩＰパケットの宛先のＴＣＰコネクション情報を書き換える。さらに、ＧＴＰ−ｕカプセル化を行い、ＧＴＰ−ｕパケット（カプセル化パケット）を生成する。

Ｓ４６では、Ｓ４２で取り出したレコードに対応するＴＯＦ中継管理テーブル１７８ａのレコードのＴＯＦ ＤＬ−ＴＥＩＤ値（ＴＯＦ振分ポイント位置）を、ＧＴＰ−ｕパケ
ットのＴＥＩＤに設定する。そして、ＴＯＦ ＤＬ−ｏＧＷ値を宛先としてＧＴＰ−ｕパケットが送信される。その後、図２８の処理が終了する。

Ｓ４７では、ＴＯＦセッション管理テーブル１７８ｂから取り出されたレコードのセッ
ション状態が“ＤＬ切断確認待ち”か否かが判定される。このとき、セッション状態がＤＬ切断確認待ちであれば、ＴＯＦセッション管理テーブル１７８ｂから取り出されたレコードが削除される（Ｓ４９）。これに対し、セッション状態がＤＬ切断確認待ち以外であれば、ＴＯＦセッション管理テーブル１７８ｂにおいて一致するレコードのセッション状態に“ＵＬ切断確認待ち”が設定される。その後、図２８の処理が終了する。

図２９は、振分ポイントのオフロードＧＷ７０がオフロードアンカポイントのオフロードＧＷ７０から移動局宛のdownlinkパケットを受信した場合の処理フロー例である。

最初に、ベアラ管理状態データ１７５のベアラテーブル１７５ＢのＴＯＦ振分ポイント位置情報が受信パケットのＧＴＰ−ｕヘッダのＴＥＩＤと一致するレコードがベアラテーブル１７５Ｂから取り出される（Ｓ５１）。

次に、レコードがあるか否かが判定される（Ｓ５２）。レコードがなければ、図２９の処理が終了する。これに対し、レコードがあれば、受信パケットのＴＥＩＤが、Ｓ５１で取り出されたレコード中のダウンリンク回線割付情報で書き換えられる。そして、ダウンリンク回線割付情報に対応する基地局１１（ｅＮＢ）へパケットが送信される（Ｓ５３）。その後、図２９の処理が終了する。

図３０は、ＣＰＵ７３のＳ１ＡＰ傍受処理１７１によって実行される、Initial Context Setup Requestメッセージ(MME->eNB)の傍受時の処理フロー例を示す。最初に、ｏＧＷ
内ＵＥ識別子が捕捉される（Ｓ６１）。

次に、ｏＧＷ内ＵＥ識別子に対応付けて、Initial Context Setup Requestメッセージ
中の“MME UE S1AP ID”と “eNB UE S1AP ID”とをベアラ利用者特定テーブル１７５Ａ
のＭＭＥ内ＵＥ識別子、 ｅＮＢ内ＵＥ識別子（Ｓ１ＡＰ）に夫々登録する（Ｓ６２）。

続いて、ｏＧＷ内ＵＥ識別子に対応付けて、Initial Context Setup Requestメッセー
ジ中のアップリンク向け回線割付情報を利用者回線識別子（E RAB ID）毎に、ベアラテーブル１７５Ｂのアップリンク割付情報へ登録する（Ｓ６３）。

その後、オフロード用ＧＴＰ−ｕトンネルの生成処理が行われ（Ｓ６４）、図３０の処理が終了する。

図３０Ａは、図３０に示したＧＴＰ−ｕトンネルの生成処理（サブルーチン）の例を示す。サブルーチンの入力として、MME UE S1AP ID (ＭＭＥでのＵＥ識別子)とMMEID（ＭＭＥの装置ＩＤ）とが使用される。

図３０Ａにおいて、Ｓ６４ａでは、ＣＰＵ７３は、アンカポイントでのｏＧＷアンカ内ＵＥ識別子を捕捉する。以降の処理（Ｓ６４ｂ〜Ｓ６４ｅ）は、利用者のオフロード対象の利用者回線識別子毎に繰り返し実行される。

ＣＰＵ７３は、ＴＯＦアンカポイント位置を捕捉する（Ｓ６４ｂ）。続いて、ＣＰＵ７３は、ＴＯＦ振分ポイント位置を捕捉する（Ｓ６４ｃ）。次に、ＣＰＵ７３は、ＴＯＦ振分ポイント位置及びＴＯＦアンカポイント位置を、利用者回線識別子毎に、ＭＭＥ内ＵＥ識別子が対応するベアラテーブル１７５Ｂのレコードに、ＴＯＦ振分ポイント位置情報、ＴＯＦアンカポイント位置情報として記憶する（Ｓ６４ｄ）。

続いて、ＣＰＵ７３は、ｏＧＷアンカ内ＵＥ識別子、及び利用者回線識別子毎に、ＴＯＦ振分ポイント位置及びＴＯＦアンカポイント位置を、アンカポイントのＴＯＦ中継管理
テーブル１７８ａのレコード中の、ＴＯＦ振分ポイント位置、ＴＯＦアンカポイント位置として記憶する（Ｓ６４ｅ）。図３０Ａの処理フローによって、振分ポイントとオフロードアンカポイントのオフロードＧＷ間でオフロード対象パケットを伝達するためのリソースが生成される。

図３１は、ＣＰＵ７３のＳ１ＡＰ傍受処理１７１によって実行される、Initial Context Setup Responseメッセージ(eNB->MME)の傍受時の処理フロー例を示す。最初に、Initial Context Setup Responseメッセージ中の“MME UE S1AP ID”でベアラ利用者特定テーブル１７５ＡのＭＭＥ内ＵＥ識別子を検索し、対応するレコードを確定する（Ｓ７１）。

次に、Initial Context Setup Responseメッセージ中のダウンリンク向け回線割付情報を、利用者回線識別子（E RAB ID）毎に、ベアラテーブル１７５Ｂのダウンリンク割付情報に設定する。その後、図３１の処理が終了する。

図３２は、Ｓ１ベースのハンドオーバ時にＣＰＵ７３のＳ１ＡＰ傍受処理１７１によって実行される、Handover Requiredメッセージ(source eNB->Source MME)の傍受時の処理
フロー例を示す。

最初に、Handover Requiredメッセージ中の“MME UE S1AP ID”でベアラ利用者特定テ
ーブル１７５ＡのＭＭＥ内ＵＥ識別子を検索し、対応するレコードを確定する（Ｓ８１）。

次に、Handover Requiredメッセージ中の“Target ID”，“Source to Target Transparent Container”内のセル識別情報を、ベアラ利用者特定テーブル１７５Ａにおける対応レコードの“Target ID”、“S-Targetセル識別情報”に設定する（Ｓ８２）。その後、
図３２の処理が終了する。

図３３は、Ｓ１ベースのハンドオーバ時にＣＰＵ７３のＳ１ＡＰ傍受処理１７１によって実行される、Handover Requestメッセージ（target MME -> target eNB）の傍受時の処理フローを示す。

図３３に示すＳ８３では、ＣＰＵ７３は、ｏＧＷ内ＵＥ識別子を捕捉する。続いて、Ｓ８３ａでは、ＣＰＵ７３は、ｏＧＷ内ＵＥ識別子対応に、Handover Requestメッセージ中の“MME UE S1AP ID”及び“Source to Target Transparent Container”内の“Call ID
”情報をベアラ利用者特定テーブル１７５ＡのＭＭＥ内ＵＥ識別子、T-Targetセル位置情報へ登録する。

次に、Ｓ８３ｂでは、ＣＰＵ７３は、ｏＧＷ内ＵＥ識別子対応に、Handover Request
メッセージ中のアップリンク向け回線割付情報を利用者回線識別子毎にベアラテーブル１７５Ｂに登録する。

その後、オフロード用ＧＴＰ−ｕトンネル生成処理が実行される（Ｓ６４）。その後、図３３の処理が終了する。

図３４は、Ｓ１ベースのハンドオーバ時にＣＰＵ７３のＳ１ＡＰ傍受処理１７１によって実行される、Handover Request Ack.メッセージ(target eNB -> target MME) の傍受時の処理フロー例を示す。

最初に、Handover Request Ack.メッセージ中の“MME UE S1AP ID”でベアラ利用者特
定テーブル１７５ＡのＭＭＥ内ＵＥ識別子を検索し、対応するレコードを確定する（Ｓ８
５）。

次に、Handover Request Ack.メッセージ中の“eNB UE S1AP ID”，“Target to Source Transparent Container”内のセル内ＵＥ識別情報を、ベアラ利用者特定テーブル１７
５ＡにおけるｅＮＢ内ＵＥ識別子、T-C-セル内ＵＥ識別情報として、Ｓ８５で確定したレコードに記憶する（Ｓ８６）。

次に、Handover Request Ack.メッセージ中のダウンリンク向け回線割付情報を、利用
者回線識別子毎に、ベアラテーブル１７６Ｂのダウンリンク回線割付情報に設定する（Ｓ８７）。その後、図３４の処理が終了する。

図３５は、Ｓ１ベースのハンドオーバ時にＣＰＵ７３のＳ１ＡＰ傍受処理１７１によって実行される、Handover Commandメッセージ(source MME -> source eNB)の傍受時の処理フロー例を示す。

最初に、ＣＰＵ７３は、Handover Commandメッセージ中の“MME UE S1AP ID”でベアラ利用者特定テーブル１７５ＡのＭＭＥ内ＵＥ識別子を検索し、対応するレコードを確定するとともに、ｏＧＷ内ＵＥ識別子を確定する（Ｓ９１）。

次に、ＣＰＵ７３は、Handover Commandメッセージ中の“Target to Source Transparent Container”内のセル内ＵＥ識別情報をベアラ利用者特定テーブル１７５ＡのS-Targetセル内ＵＥ識別情報に設定する（Ｓ９２）。

次に、ＣＰＵ７３は、確定されたレコードのTarget IDで示される基地局１１を収容す
るターゲットオフロードＧＷ７０を特定する（Ｓ９３）。

次に、ＣＰＵ７３は、ベアラ利用者特定テーブル１７５Ａの“Target ID”，“S-Targetセル識別情報”，“S-Targetセル内ＵＥ識別情報”と、ターゲットオフロードＧＷ７０
におけるベアラ利用者特定テーブル１７５Ａの“eNB装置識別子”，“T-Targetセル識別
情報”，“T-Targetセル内ＵＥ識別情報”が一致するレコードを確定する。また、ＣＰＵ７３は、ターゲットｏＧＷ内ＵＥ識別子を確定する（Ｓ９４）。

次に、ＣＰＵ７３は、ｏＧＷ内ＵＥ識別子に対応する、オフロード条件適用状態テーブル１７６Ａ中の、“利用者回線識別子”，“ＴＣＰコネクション情報”，“オフロードアンカポイント情報”を、ターゲットオフロードＧＷ７０のｏＧＷ内ＵＥ識別子に対応する
“利用者回線識別子”，“ＴＣＰコネクション情報”，“オフロードアンカポイント情
報”として、オフロード条件適用状態テーブル１７６Ａにレコードを追加する（Ｓ９５）。

次に、ＣＰＵ７３は、オフロード用ＧＴＰ−ｕ切換処理を行う（Ｓ９６）。その後、図３４の処理が終了する。

図３５Ａは、図３５に示したオフロード用ＧＴＰ−ｕ切換処理のサブルーチンの処理フレー例を示す。図３５Ａに示すＳ９６ａ〜Ｓ９６ｃの処理は、ターゲットｏＧＷのＵＥ対応のオフロード条件適用状態テーブル１７６Ａの全レコードについて繰り返し実行される。

Ｓ９６ａでは、ＣＰＵ７３は、ターゲットオフロードＧＷ７０のベアラテーブル１７５Ｂから基地局１１への利用者回線識別子対応のＴＯＦ振分ポイント位置情報を取り出す。

Ｓ９６ｂでは、ＣＰＵ７３は、オフロードアンカポイント情報で示すアンカポイントのオフロードＧＷ７０を特定する。

次に、ＣＰＵ７３は、アンカポイントオフロードＧＷ７０におけるアンカポイントのＴＯＦ中継管理テーブル１７５ａに格納されたＴＯＦアンカポイント位置情報がオフロードアンカポイントと一致するレコードのＴＯＦ振分ポイント位置にＴＯＦ振分ポイント位置情報を設定する（Ｓ９６ｃ）。その後、図３５Ａの処理が終了する。

図３５Ａの処理によって、移動局６０のハンドオーバに伴い、オフロードアンカポイントのオフロードＧＷ７０がオフロード網５０から受信したパケットの送信先をハンドオーバ先の振分ポイントのオフロードＧＷ７０へ切り替えることができる。

図３６は、Ｓ１ベースのハンドオーバ時にＣＰＵ７３のＳ１ＡＰ傍受処理１７１によって実行される、UE Context Release Commandメッセージ(source MME -> source eNB)の傍受時のフロー例を示す。

最初に、ＣＰＵ７３は、UE Context Release Commandメッセージ中の“MME UE S1AP ID”でベアラ利用者特定テーブル１７５ＡのＭＭＥ内ＵＥ識別子を検索し、対応するレコードを確定するとともに、ｏＧＷ内ＵＥ識別子を確定する（Ｓ１０１）。

次に、ＣＰＵ７３は、自ｏＧＷアンカポイントのＴＯＦ中継状態管理テーブル１７８ａにおける、“ＴＯＦ振分ポイント位置”及び“ＴＯＦアンカポイント位置”の組が、ｏＧＷ内ＵＥ識別子に対応するベアラテーブル１７５Ｂの“ＴＯＦ振分ポイント位置情報”及び“ＴＯＦアンカポイント位置情報”の組と一致する、自ｏＧＷアンカポイントのＴＯＦ中継管理テーブル１７８ａのレコードを削除する（Ｓ１０２）。

次に、ＣＰＵ７３は、ｏＧＷ内ＵＥ識別子に対応するオフロード条件適用状態テーブル１７６Ａのレコードを削除する（Ｓ１０３）。

次に、ＣＰＵ７３は、ｏＧＷ内ＵＥ識別子に対応する、ベアラ利用者特定テーブル１７５Ａ及びベアラテーブル１７５Ｂのレコードを削除する（Ｓ１０４）。その後、図３６の処理が終了する。

図３７は、Ｘ２ベースのハンドオーバ時にＣＰＵ７３のＸ２ＡＰ傍受処理１７２によって実行される、X2AP: Handover Requestメッセージ(source eNB -> target eNB)の傍受時の処理フローの例を示す。

最初に、ＣＰＵ７３は、Handover Request の送信元の基地局１１が、自ｏＧＷが収容
する基地局１１か否かを判定する（Ｓ１１１）。基地局１１が自ｏＧＷに収容されている場合には、処理がＳ１１９に進む。これに対し、基地局１１が他のｏＧＷに収容されている場合には、処理がＳ１１２に進む。

Ｓ１１２では、ＣＰＵ７３は、ｏＧＷ内ＵＥ識別子を捕捉する。
続いて、ＣＰＵ７３は、Handover Request 内の“MME UE S1AP ID”をｏＧＷ内ＵＥ識
別子と対応付ける。さらに、ＣＰＵ７３は、“MME UE S1AP ID”をベアラ利用者テーブル１７５ＡのＭＭＥ内ＵＥ識別子として登録する（Ｓ１１３）。

次に、ＣＰＵ７３は、Handover Request 内のアップリンク回線割付情報をｏＧＷ内Ｕ
Ｅ識別子と対応付ける。さらに、ＣＰＵ７３は、利用者回線識別子毎に、ベアラテーブル１７５Ｂのアップリンク回線割付情報に登録する（Ｓ１１４）。

次に、ＣＰＵ７３は、オフロード用ＧＴＰ−ｕトンネル生成処理（図３０Ａ）を行う（Ｓ１１５）。

次に、ＣＰＵ７３は、送信元の基地局１１を収容するソースオフロードＧＷ７０を特定する（Ｓ１１６）。

次に、ＣＰＵ７３は、ベアラ利用者特定テーブル１７５ＡのＭＭＥ内ＵＥ識別子と、ソースオフロードＧＷ７０のベアラ利用者特定テーブル１７５ＡのＭＭＥ内ＵＥ識別子とが一致するレコードを確定する。これによって、ソースオフロードＧＷ内ＵＥ識別子が確定される（Ｓ１１７）。

次に、ＣＰＵ７３は、ソースオフロードＧＷ７０のｏＧＷ内ＵＥ識別子に対応する、オフロード条件適用状態テーブル１７６Ａにおける、利用者回線識別子，ＴＣＰコネクション情報，オフロードアンカポイント情報を、ターゲットオフロードＧＷ７０のｏＧＷ内ＵＥ識別子に対応する、オフロード条件適用状態テーブル１７６Ａの、利用者回線識別子，ＴＣＰコネクション情報，及びオフロードアンカポイント情報として、追加する（Ｓ１１８）。

Ｓ１１９では、ＣＰＵ７３は、Handover Requestメッセージ中の“MME UE S1AP ID”でベアラ利用者特定テーブル１７５ＡのＭＭＥ内ＵＥ識別子を検索し、対応するレコードを確定する。

Ｓ１２０では、ＣＰＵ７３は、Handover Requestメッセージ中の“Old eNB UE X2AP ID”情報を、ベアラ利用者特定テーブル１７５Ａの“ｅＮＢ内ＵＥ識別子（X2AP）”に記録する。その後、図３７の処理が終了する。

図３８は、Ｘ２ベースのハンドオーバ時にＣＰＵ７３のＸ２ＡＰ傍受処理１７２によって実行される、Path Switch Requestメッセージ(target eNB -> MME)の傍受時の処理フローの例を示す。

図３８において、Ｓ１３１では、ＣＰＵ７３は、Path Switch Requestメッセージ中のMME UE S1AP IDでベアラ利用者特定テーブル１７５ＡのＭＭＥ内ＵＥ識別子を検索し、対
応するレコードを確定する。

次のＳ１３２では、ＣＰＵ７３は、Path Switch Requestメッセージ中のダウンリンク
回線割付情報を、利用者回線識別子毎に、ベアラテーブル１７５Ｂのダウンリンク回線割付情報へ設定する。その後、オフロード用のＧＴＰ−ｕ切替処理が実行される（Ｓ９６：図３５Ａ参照）。

図３９は、Ｘ２ベースのハンドオーバ時にＣＰＵ７３のＸ２ＡＰ傍受処理１７２によって実行される、Path Switch Request Ack.メッセージ(MME -> Target eNB)の傍受時の処
理フロー例を示す。

図３９における、Ｓ１３５では、ＣＰＵ７３は、Path Switch Request Ack.メッセージ中のMME UE S1AP IDでベアラ利用者特定テーブル１７５ＡのＭＭＥ内ＵＥ識別子を検索し、対応するレコードを確定する。

次のＳ１３６では、ＣＰＵ７３は、Path Switch Request Ack.メッセージ中のアップリンク回線割付情報を、利用者回線識別子毎に、ベアラテーブル１７５Ｂのアップリンク回
線割付情報へ設定する。その後、図３９の処理が終了する。

図４０は、Ｘ２ベースのハンドオーバ時にＣＰＵ７３のＸ２ＡＰ傍受処理１７２によって実行される、X2AP: UE Context Releaseメッセージ(target eNB -> source eNB)の傍受時の処理フロー例を示す。

図４０において、Ｓ１２１では、ＣＰＵ７３は、UE Context Release の送信元の基地
局１１が当該オフロードＧＷ７０が収容する基地局か否かを判定する。このとき、当該オフロードＧＷ７０によって収容された基地局であれば、図４０の処理が終了する。

これに対し、基地局１１が他のオフロードＧＷ７０によって収容された基地局であれば、ＣＰＵ７３は、UE Context Release 中の“Old eNB UE X2AP ID”でベアラ利用者特定
テーブル１７５ＡのｅＮＢ内ＵＥ識別子（X2AP）を検索し、対応するレコードを確定するとともに、ｏＧＷ内ＵＥ識別子を確定する（Ｓ１２２）。

次のＳ１２３では、ＣＰＵ７３は、ｏＧＷ内ＵＥ識別子に対応するオフロード条件適用状態テーブル１７６Ａのレコードを削除する。次のＳ１２４では、ＣＰＵ７３は、ｏＧＷ内ＵＥ識別子に対応するベアラ利用者特定テーブル１７５Ａ及びベアラテーブル１７５Ｂのレコードを削除する。その後、図４０の処理が終了する。

＜ｏＧＷ収容表＞
図１０１は、ｏＧＷ７０が記憶装置７４で保持するｅＮＢ１１を収容するｏＧＷ情報の構成例を示す。ｏＧＷ７０のＣＰＵ７３は、図５７に示すｅＮＢ収容表を用いて（参照して）、ｅＮＢ１１を収容するｏＧＷ７０を割り出すことができる。ｅＮＢ収容表は、例えば、ｏＧＷ７０において、移動局６０のハンドオーバによって、振分ポイントとなるｏＧＷ７０を特定するために使用される。

＜動作例＞
以下、図面を参照して、第１実施形態の動作例を説明する。

＜＜動作例１：ＴＣＰコネクション生成＞＞
最初に、移動局６０が起動して、オフロード対象のＴＣＰ通信がオフロードされるまでの動作について説明する。

[動作１−１]
図４Ｂのシーケンスにおいて、移動局６０（ＵＥ＃ｘ）が起動すると、アタッチ手順を行う。すなわち、移動局は、基地局１１へ接続要求メッセージである、Attach Requestメッセージを送信する（図４Ｂ＜１＞）。Attach Requestメッセージは、基地局１１（ｅＮＢ＃１）経由でＭＭＥ２１（ＭＭＥ＃１）へ送信される。

ＭＭＥ２１は、Ｓ−ＧＷ（ＳＧＷ）２２（S-GW#1）にCreate Session Requestメッセージを送る（図４Ｂ＜２＞）。ＭＭＥ２１は、Ｓ−ＧＷ２２からCreate Session Response
メッセージを受信する（図４Ｂ＜３＞）。

［動作１−２］
Ｓ−ＧＷ２２からCreate Session Responseメッセージを受信したＭＭＥ２１は、Initial Context Setup Requestメッセージ（図１４）を生成し、基地局１１へ送る（図４Ｂ＜４＞）。オフロードＧＷ（ｏＧＷ）７０は、Initial Context Setup Requestメッセージ
を傍受する（図４Ｂ＜５＞）。

すなわち、オフロードＧＷは、図３０及び図３０Ａに示した処理を実行する。図３０に示す処理によって、ベアラ利用者特定テーブル１７５Ａ及びベアラテーブル１７５Ｂに対し、ｏＧＷ内ＵＥ識別子（8000）、ＭＭＥ内ＵＥ識別子（MME＃1 UE S1AP ID#x）、ＭＭ
Ｅ装置識別子(MME#1)、ｅＮＢ内ＵＥ識別子(eNB UE S1AP ID#x)、ｅＮＢ装置識別子(eNB#1)、利用者回線識別子(1,2)、uplink回線割付情報(1:TEID#SGW-u1, SGW#1, 2: TEID#SGW-u2, SGW#1)、ＴＯＦ振分ポイント位置情報(1:オフロード非適用 2: TOF DL-TEID#1)、Ｔ
ＯＦアンカポイント位置情報(TOF UL-TEID#1, oGW#1)が登録され、確定される（図４１に示すテーブル１７５Ａ及び１７５Ｂを参照）。

また、図３０Ａに示す処理によって、オフロードＧＷ７０内の振分ポイント７５とアンカポイント７６との間にオフロード用のＧＴＰ−ｕトンネルが確立される。

［動作１−３］
また、オフロードＧＷ７０のＣＰＵ７３によって、ＴＯＦ中継管理テーブル１７８ａの記憶内容が、図４２に示す状態となる。すなわち、ＴＯＦ中継管理テーブル１７８ａにおいて、ｏＧＷアンカ内ＵＥ識別子、利用者回線識別子、ＴＯＦアンカポイント位置、ＴＯＦ振分ポイント位置が確定する。

［動作１−４］
Initial Context Setup Requestメッセージを受信した基地局１１は、応答メッセージ
であるInitial Context Setup Responseメッセージ(図１５)を送信する（図４Ｂ＜６＞）。オフロードＧＷ７０は、Initial Context Setup Responseメッセージを傍受し（図４Ｂ＜７＞）、図３１に示した処理を実行する。これによって、ベアラテーブル１７５Ｂに対し、downlink回線割付情報（1: eNB-TEID#1, eNB#1, 2: eNB-TEID#2, eNB#1）が登録され、確定する（図４１参照）。

［動作１−５］
続いて、図４Ｂのシーケンスにおいて、移動局６０がＷｅｂサイトとの接続を開始すると（図４Ｂ＜８＞）、基地局１１（eNB#1）から、ＧＴＰ−ｕパケット（図５）がＳ−Ｇ
Ｗ２２（S-GW#1）へ向けて送信される（図４Ｂ＜９＞）。すると、オフロードＧＷ７０（oGW#1）は、ＧＴＰ−ｕパケットを受信し、図２６に示した処理を行う。このとき、図２
６におけるＳ１〜Ｓ４及びＳ８〜Ｓ１０の処理が実行される。

［動作１−６］
図２６のＳ９の処理によって、オフロード条件適用状態テーブル１７６ＡにｏＧＷ内ＵＥ識別子および利用者回線識別子に対応する、ＴＣＰコネクション情報及びオフロードアンカポイント情報が記憶される（図４３のテーブル１７６Ａを参照）。

［動作１−７］
図２６のＳ１０の処理によって、図８に示したオフロードアンカポイント向けのパケットが生成され、振分ポイントのオフロードＧＷ７０からアンカポイントのオフロードＧＷ７０へパケットが送信される。ここでは、オフロードＧＷ７０（oGW#1）内において、振
分ポイント７５からアンカポイント７６へパケットが転送される。

[動作１−８]
アンカポイント７６では、図２７に示した処理が実行される。ここでは、Ｓ２１〜Ｓ２７の処理が実行され、ＴＣＰ／ＩＰパケット（図９）がＷｅｂサイトへ向けてオフロード網５０へ送信される（図４Ｂ＜１１＞）。

Ｓ２６の処理によって、ＴＯＦセッション管理テーブル１７８ｂには、ｏＧＷアンカ内
ＵＥ識別子、利用者回線識別子に対応する、ＵＥ ＴＣＰコネクション情報、ｏＧＷ Ｔ
ＣＰコネクション情報、セッション状態が記憶される（図４２参照）。

[動作１−９]
ＴＣＰ／ＩＰパケットがオフロード網５０を経由してＷｅｂサイトに到達すると、Ｗｅｂサイトからオフロード網５０を経由して、ダウンリンクパケット（図１０）が、オフロードＧＷ７０（oGW＃1）のアンカポイント７６へ到達する（図４Ｂ＜１２＞）。アンカポイント７６では、パケット受信により、図２８に示す処理（Ｓ４１〜Ｓ４６）を行う。

[動作１−１０]
続いて、オフロードアンカポイントのオフロードＧＷ７０（oGW#1：アンカポイント７
６）から、振分ポイントのオフロードＧＷ７０（GW#1：振分ポイント７５）へ図１１に示したパケットが送信されると（図４Ｂ＜１３＞）、振分ポイント７５（oGW#1）は、パケ
ットを受信し、図２９に示した処理（Ｓ５１〜Ｓ５３）を行い、基地局１１（eNB#1）へ
向けて、図７に示したパケットを送信する（図４Ｂ＜１４＞）。これによって、図４４に示すようなオフロード網５０経由でのＴＣＰ通信が確立する。

[動作１−１１]
移動局６０（以下、ＵＥ＃ｘとも表記）からＷｅｂサイトへ向かうアップリンクデータは、以下のようにして伝達される。すなわち、ｅＮＢ＃１で受信されたＵＥ＃ｘからのデータ（図４Ｂ＜１５＞）は、基地局１１（eNB#1）からＳ−ＧＷ＃１宛にＧＴＰ−ｕパケ
ット（図６）で送信される（図４Ｂ＜１６＞）。振分ポイント７５（oGW#1）は、図６の
パケットを受信すると図２６の処理（振分処理１７４を含む）を行い、図８に示すパケットをアンカポイント７６（oGW#1）へ送る（図４Ｂ＜１７＞）。アンカポイント７６（oGW#1）は、図８に示すパケットを受けると図２７の処理を行い、図９のパケットをオフロード網５０経由でＷｅｂサイトへ送信する（図４Ｂ＜１８＞）。

[動作１−１２]
Ｗｅｂサイトから移動局（UE#x）へ向かうデータは、以下のようにして伝達される。すなわち、データは、Ｗｅｂサイトからオフロードのアンカポイント７６（oGW#1）宛に、
図１０に示すパケットが送信される（図４Ｂ＜１９＞）。アンカポイント７６（oGW#1）
は、図１０のパケットを受信すると、図２８の処理を行い、図１１のパケットを振分ポイント７５（oGW#1）へ送信する（図４Ｂ＜２０＞）。振分ポイント７５（oGW#1）は、図１１のパケットを受けると図２９の処理（合流処理１７３を含む）を行い、図７のパケットをｅＮＢ＃１へ送る（図４Ｂ＜２１＞）。ｅＮＢ＃１はデータをＵＥ＃ｘへ送る（図４Ｂ＜２２＞）。

＜＜動作例２：Ｓ１ベースのハンドオーバに対するＴＣＰコネクションの維持＞＞
次に、移動局６０（UE#x）でのＴＣＰ通信を維持しつつ、移動局６０の移動に伴い、ハンドオーバ元の基地局１１（“Source eNB”とも表記）からハンドオーバ先の基地局１１（“Target eNB”とも表記）へハンドオーバするまでの動作について、図４ＣのＳ１ベースのハンドオーバ手順を示すシーケンスに従って説明する。

[動作２−１]
ＵＥ＃ｘの移動に伴いSource eNB(eNB#1)がＳ１ベースのハンドオーバを開始すると、Source eNB(eNB#1)から、ハンドオーバ元のＭＭＥ２１（以下、“source MME(MME#1)”と
表記）へHandover Requiredメッセージ（図１６）が送信される（図４Ｃ＜１＞）。する
と、ハンドオーバ元のオフロードＧＷ（以下、“Source oGW(oGW#1)”と表記）は、Handover Requiredメッセージを傍受し（図４Ｃ＜２＞）、図３２に示した処理（Ｓ８１及びＳ８２）を行う。

[動作２−２]
図４５は、S1-Based Handover でのオフロード条件適用状態の引継の例を示す。図３２の処理によって、Source oGW(oGW#1)のベアラ利用者特定テーブル１７５ｂに、Handover Requiredメッセージ中のハンドオーバ先の基地局１１の識別子“Target ID＝eNB#2”,及
びハンドオーバ先のセル識別情報“S-Targetセル識別情報＝Cell ID#x”が登録され、確
定する。

[動作２−３]
source MME(MME#1)は、ハンドオーバ先のＭＭＥ２１（以下、“Target MME(MME#2)”とも表記）へ、Forward Relocation Requestメッセージを送る（図４Ｃ＜３＞）。すると、Target MME(MME#2)は、Target eNB#2へHandover Requestメッセージ（図１７）を送信す
る（図４Ｃ＜４＞）。ハンドオーバ先のオフロードＧＷ７０（以下 “Target oGW(oGW#2)”とも表記）は、Handover Requestメッセージを傍受し（図４Ｃ＜５＞）、図３３及び
図３０Ａに示した処理を実行する。

[動作２−４]
Handover Requestメッセージの傍受によって、図４５に示すように、Target oGW(oGW#2)は、ベアラ利用者特定テーブル１７５Ａ´（テーブル１７５ａ´及び１７５ｂ´）に、
ｏＧＷ内ＵＥ識別子、ＭＭＥ内ＵＥ識別子、ＭＭＥ装置識別子、ｅＮＢ装置識別子、利用者回線識別子、uplink回線割付情報、ＴＯＦ振分ポイント位置情報、ＴＯＦアンカポイント位置情報、T -targetセル識別情報を記憶し、確定させる。

[動作２−５]
また、Target oGW(oGW#2)は、図４６に示すように、ＴＯＦ中継管理テーブル１７８ａ
´に、ｏＧＷアンカ内ＵＥ識別子、利用者回線識別子、ＴＯＦアンカポイント位置、ＴＯＦ振分ポイント位置を記憶し、確定させる。

[動作２−６]
続いて、Target eNB（eNB#2)がTarget MME(MME#2)へHandover Request Ack.メッセージ（図１８）を送る（図４Ｃ＜６＞）。すると、Target oGW(oGW#2)は、Handover Request Ack.メッセージを傍受し、図３４の処理を行う（図４Ｃ＜７＞）。

[動作２−７]
図３４の処理によって、Target oGW(oGW#2)は、図４５に示すように、ベアラテーブル
１７５Ｂ´にdownlink回線割付情報を記憶し、確定させる。また、Target oGW(oGW#2)は
、Bearer利用者特定テーブル１７５ｂ´に、Handover Request Ack.メッセージから得たT-Targetセル内ＵＥ識別情報を記憶し、確定させる。

[動作２−８]
Handover Request Ack.メッセージを受信したTarget MME(MME#2)は、Forward Relocation Response メッセージをSource MME(MME#1)へ送る（図４Ｃ＜８＞）。すると、Source MME(MME#1)は、Target eNB(eNB#1)に対し、Handover Commandメッセージ（図１９）を送
信する（図４Ｃ＜９＞）。このとき、Source oGW(oGW#1)は、Handover Commandメッセー
ジを傍受し（図４Ｃ＜１０＞）、図３５及び図３５Ａの処理を行う。

[動作２−９]
図３５及び図３５Ａの処理によって、Source oGW(oGW#1)は、ベアラ利用者特定テーブ
ル１７５ｂに、S-Targetセル内ＵＥ識別情報を登録し、確定させる（図４５参照）。これによって、Source oGW(oGW#1)のベアラ利用者特定テーブル１７５ＡのTarget ID，S-Targ
etセル識別情報，S-Targetセル内ＵＥ識別情報と、Target oGW (oGW#2)のベアラ利用者特定テーブル１７５Ａ´のeNB装置識別子,T-Targetセル識別情報,T-Targetセル内ＵＥ識別
情報とが一致する。従って、移動局６０（ＵＥ＃ｘ）に対するSource oGW(oGW#1)のｏＧ
Ｗ内ＵＥ識別子(8000)とTarget oGW(oGW#2)のｏＧＷ内ＵＥ識別子(8102)のとを対応付け
することができる。

[動作２−１０]
図３５のＳ９５の処理によって、ｏＧＷ＃１は、ｏＧＷ＃２との連携において、図４７に示すように、ｏＧＷ＃１のオフロード条件適用状態テーブル１７６ＡにおけるｏＧＷ内ＵＥ識別子(8000)に対応する利用者回線識別子、ＴＣＰコネクション情報、オフロードアンカポイント情報のコピーを、ｏＧＷ＃２におけるＵＥ＃ｘのｏＧＷ内ＵＥ識別子(8102)に対応付けて、ｏＧＷ＃２のオフロード条件適用状態テーブル１７６Ａ´に登録する。これによって、ｏＧＷ＃１及びｏＧＷ＃２は、オフロード対象のトラヒック毎にオフロードアンカポイント情報を知ることができる。

[動作２−１１]
また、ｏＧＷ＃１は、テーブル１７８ａ´（図４６）の記憶内容に基づき、ｏＧＷ＃１のアンカポイント７６における、オフロードアンカポイント情報(TOF UL-TEID#1)に対応
するＴＯＦ振分ポイント位置を、ｏＧＷ＃２のＴＯＦ振分ポイント位置情報(TOF DL-TEID#2)へ切り替える（図４６参照）。

これによって、図４８のように、ＵＥの移動に伴うS1-Based Handoverにおいて、ＴＣ
Ｐコネクションは、維持されたままで、ＵＥ＃ｘ→eNB#2→振分ポイント７５（oGW#2）→アンカポイント７６（oGW#1）→Ｗｅｂサイトの経路へ移行する。

なお、図４Ｃにおいて、Target eNBは、Handover Request に対する処理が終了すると
、完了メッセージであるHandover NotifyをTarget MMEへ送る。これによって、ダウンリ
ンクデータの宛先ｅＮＢが、Source eNBからTarget eNBに切り替わる。

［動作２−１２］
動作例２の終了後における、ｅＮＢ＃２が受信するＵＥ＃ｘからのデータ（図４＜１１＞）は、以下のようにしてＷｅｂサイトへ伝達される。すなわち、ｅＮＢ＃２からＳ−ＧＷ＃２へ向けて、ＧＴＰ−ｕパケット（図６）が送信される（図４＜１２＞）。振分ポイント７５（oGW#2）は、パケットを受けると図２６の処理（振分処理１７４を含む）を行
い、図８に示すパケットをアンカポイント７６（oGW#1）へ送る（図４＜１３＞）。アン
カポイント７６（oGW#1）は、図８に示すパケットを受けると、図２７の処理を行い、図
９のパケットをオフロード網５０経由でＷｅｂサイトへ送信する（図４＜１４＞）。

[動作２−１３]
これに対し、ＷｅｂサイトからＵＥ＃ｘへ向かうデータは、以下のようにして伝達される。すなわち、Ｗｅｂサイトからのダウンリンクデータは、オフロード網５０経由で、アンカポイント７６（oGW#1）宛に、図１０に示すパケットで送信される（図４＜１５＞）
。アンカポイント７６（oGW#1）は、図１０に示すパケットを受信すると、図２８の処理
を行い、図１１のパケットを振分ポイント７５（oGW#2）へ送信する（図４＜１６＞）。
振分ポイント７５（oGW#2）は、図１１に示すパケットを受けると図２９に示した処理（
合流処理１７３を含む）を行い、図７のパケットをｅＮＢ＃２へ送る（図４＜１７＞）。ｅＮＢ＃２は、ダウンリンクデータをＵＥ＃ｘに送る（図４＜１８＞）。

［動作２−１４］
Source MME(MME#1)は、Source eNB(eNB#1)に対し、ＵＥ＃ｘのために確保したリソース
を解放するために、UE Context Release Commandメッセージ（図２０） を送信する（図
４Ｃ＜１９＞）。すると、Source oGW(oGW#1)は、UE Context Release Commandメッセー
ジを傍受し（図４Ｃ＜２０＞）、図３６に示した処理を行う。

[動作２−１５]
図３６に示すＳ１０１〜Ｓ１０４の処理によって、Source oGW(oGW#1)におけるｏＧＷ
内ＵＥ識別子(8000)に対応するレコードが削除される。すなわち、ベアラ利用者特定テーブル１７５Ａ，ベアラテーブル１７５Ｂ，オフロード条件適用状態テーブルの対応レコードが削除される（図４９及び，図５０参照）。そして、Source oGW(oGW#1)の振分ポイン
ト７５のリソースが解放される。なお、図５０Ａは、ハンドオーバ完了後の、オフロード条件適用状態の例を示す。

これによって、図５１に示すように、ＴＣＰコネクションに対して、Source oGW(oGW#1)のアンカポイント７６のリソースは、ＴＣＰ通信を維持するために保持される。

＜＜動作例３：：Ｘ２ベースのハンドオーバに対するＴＣＰコネクションの維持＞＞
次に、ＵＥ＃ｘでのＴＣＰ通信を維持しつつ、ＵＥ＃ｘの移動に伴い、Source eNBからTarget eNBへハンドオーバするまでの動作について、図４Ｄに示すシーケンスに従って説明する。

[動作３−１]
ＵＥ＃ｘの移動に伴いSource eNB(eNB#1)がＸ２ベースのハンドオーバを開始すると、Source eNB(eNB#1)からTarget eNB (eNB#2)へ、X2AP: Handover Requestメッセージ（図２１）が送信される（図４Ｄ＜１＞）。Source oGW(oGW#1)は、X2AP: Handover Requestメ
ッセージを傍受し（図４Ｄ＜２＞）、図３７に示した処理（Ｓ１１１，Ｓ１１９，Ｓ１２０）を行う。

[動作３−２]
図３７に示した処理によって、Source oGW(oGW#1)は、ベアラ利用者特定テーブル１７
５Ａ（図５２参照）のｅＮＢ内ＵＥ識別子(X2AP)を確定する。

[動作３−３]
Target oGW(oGW#2)は、X2AP: Handover Requestメッセージを傍受し（図４Ｄ＜３＞）
、図３７に示した処理（Ｓ１１１〜Ｓ１１８）及び図３０Ａに示したオフロード用ＧＴＰ−ｕトンネル生成処理を行う。

[動作３−４]
Ｓ１１１〜Ｓ１１８の処理によって、Target oGW(oGW#2)において、図５２に示すよう
に、ｏＧＷ内ＵＥ識別子、ＭＭＥ内ＵＥ識別子、ＭＭＥ装置識別子、ｅＮＢ装置識別子、利用者回線識別子、uplink回線割付情報、ＴＯＦ振分ポイント位置情報、ＴＯＦアンカポイント位置情報が確定し、ベアラ利用者特定テーブル１７５Ａ´及びベアラテーブル１７５Ｂ´に記憶される。

[動作３−５]
また、Target oGW(oGW#2)において、図５３に示すように、ｏＧＷアンカ内ＵＥ識別子
、利用者回線識別子、ＴＯＦアンカポイント位置、ＴＯＦ振分ポイント位置が確定し、ＴＯＦ中継管理テーブル１７８ａ´に記憶される。

[動作３−６]
上記したように、Target oGW(oGW#2)のベアラ利用者特定テーブル１７５Ａ´において
ＭＭＥ内ＵＥ識別子が確定する。このとき、図５２に示すように、ｏＧＷ＃１のベアラ利用者特定テーブル１７５ＡのＭＭＥ内ＵＥ識別子とｏＧＷ#2のベアラ利用者特定テーブル１７５Ａ´のＭＭＥ内ＵＥ識別子とは一致する。これによって、ＵＥ＃ｘに対するｏＧＷ＃１のｏＧＷ内ＵＥ識別子(8000)とｏＧＷ＃２のｏＧＷ内ＵＥ識別子(8102)のとの対応付けができる。

［動作３−７］
図５４に示すように、ｏＧＷ＃１のｏＧＷ内ＵＥ識別子(8000)に対応するオフロード条件適用状態テーブル１７６Ａの利用者回線識別子、ＴＣＰコネクション情報、及びオフロードアンカポイント情報のコピーが、ｏＧＷ＃１からｏＧＷ＃２に渡される。ｏＧＷ＃２は、コピーをｏＧＷ＃２のオフロード条件適用状態テーブル１７６Ａ´に記憶する。これによって、ｏＧＷ＃２は、オフロード対象のトラヒック毎にオフロードアンカポイント情報を知ることができる。

［動作３−８］
その後、Target eNB(eNB#2)からX2AP: Handover Request Ack.メッセージが送信され、ｏＧＷ＃２，ｏＧＷ＃１を経由してSource eNB(eNB#1)に届く（図４Ｄ＜４＞）。その後
、オフロード網５０，ＰＧＷ２３からのダウンリンクデータは、Source eNB(eNB#1)，ｏ
ＧＷ＃１，ｏＧＷ＃２，Target eNB(eNB#2)を経由してＵＥ＃ｘへ到達する（図４Ｄ＜５
＞）。ＵＥ＃ｘからのアップリンクデータは、Target eNB(eNB#2)及びｏＧＷ＃２経由で
、オフロード網５０（ＰＧＷ２３）へ送信される（図４Ｄ＜６＞）。

[動作３−９]
続いて、Target eNB(eNB#2)は、Path Switch Requestメッセージ（図２４）を ＭＭＥ(MME#1)に送信する（図４Ｄ＜７＞）。Target oGW(oGW#2)は、Path Switch Requestメッセージを傍受し（図４Ｄ＜８＞）、図３８及び図３５Ａの処理を行う。

[動作３−１０]
図３８及び図３５Ａの処理によって、ｏＧＷ＃２のＴＯＦ中継管理テーブル１７８ａ´に記憶されたＴＯＦ振分ポイント位置がｏＧＷ＃１に渡され、ｏＧＷ＃１のＴＯＦ中継管理テーブル１７８ａのＴＯＦポイント位置として設定される（図３５ＡのＳ９６ｃ）。これによって、Source oGW(oGW#1)におけるＴＯＦ振分ポイント位置がｏＧＷ＃２のＴＯＦ
振分ポイント位置(TOF DL-TEID#2)に切り替えられる。

［動作３−１１］
その後、ＭＭＥ(MME#1)がTarget eNB(eNB#2)に対し、Path Switch Request Ack.メッセージ（図２５）を送信する（図４Ｄ＜８＞）。すると、Target eNB(eNB#2)は、Path Switch Request Ack.メッセージを傍受し、図３９に示す処理（Ｓ１３５，Ｓ１３６）を行う
（図４Ｄ＜９＞）。

[動作３−１２]
図３９に示す処理によって、Target oGW(oGW#2)のベアラテーブル１７５Ｂ´において
、ｏＧＷ内ＵＥ識別子(8102)に対応するuplink回線割付情報がＳ−ＧＷ＃１からＳ−ＧＷ＃２へ切り替えられる（図５２参照）。

これによって、図５５に示すように、ＵＥ＃ｘの移動に伴うＸ２ベースのハンドオーバにおいて、ＴＣＰコネクションは、維持されたまま、ＵＥ＃ｘ→eNB#2→振分ポイント（oGW#2）→アンカポイント(oGW#1)→Ｗｅｂサイトの経路へ移行する。

［動作３−１３］
動作例３によって、ＵＥ＃ｘからＷｅｂサイトへ向かうアップリンクデータは、以下のようにして伝達される。すなわち、ｅＮＢ＃２で受信されるＵＥ＃ｘからのアップリンクデータ（図４Ｄ＜９＞）は、Ｓ−ＧＷ＃１宛のＧＴＰ−ｕパケット（図６）で送信される（図４Ｄ＜１０＞）。振分ポイント７５（oGW#2）は、図６のパケットを受けると図２６
の処理を行い、図８に示すパケットをアンカポイント７６（oGW#1）へ送る（図４Ｄ＜１
１＞）。アンカポイント７６（oGW#1）は、図８のパケットを受けると図２７の処理を行
い、図９のパケットをＷｅｂサイトへ送信する（図４Ｄ＜１２＞）。

[動作３−１４]
一方、ＷｅｂサイトからＵＥへ向かうダウンリンクデータは、以下のようにして伝達される。すなわち、Ｗｅｂサイトからアンカポイント７６（oGW#1）宛に、図１０のパケッ
トが送信される（図４Ｄ＜１３＞）。アンカポイント７６（oGW#1）は、図１０のパケッ
トを受信すると、図２８の処理を行い、図１１のパケットを振分ポイント７５（oGW#2）
へ送信する（図４Ｄ＜１４＞）。振分ポイント７５（oGW#2）は、図１１のパケットを受
けると図２９の処理を行い、図７のパケットをｅＮＢ＃２へ送る（図４Ｄ＜１５＞）。ｅＮＢ＃２は、ダウンリンクデータをＵＥ＃ｘに送る（図４Ｄ＜１６＞）。

[動作３−１５]
その後、図４Ｄには図示しないが、Target eNB(eNB#2）がSource eNB(eNB#1)へX2AP: UE Context Releaseメッセージを送信する。すると、Source oGW(oGW#1)は、X2AP: UE Context Releaseメッセージを傍受し、図４０に示す処理（Ｓ１２１〜Ｓ１２４）を行う。これによって、Source oGW(oGW#1)のｏＧＷ内ＵＥ識別子(8000)に対応するレコードが、ベ
アラ利用者特定テーブル１７５Ａ，ベアラテーブル１７５Ｂから削除されるとともに（図４９参照）、オフロード条件適用状態テーブル１７６Ａから削除される（図５０参照）。そして、Source oGW(oGW#1)の振分ポイント７５のリソースが解放される。このようにし
て、図５１に示したように、ＴＣＰコネクションに対して、Source oGW(oGW#1)のアンカ
ポイント７６のリソースは、ＴＣＰ通信を維持するために保持される。

＜＜動作例４：ハンドオーバ後の新ＴＣＰコネクション生成＞＞
次に、ＵＥ＃ｘがＴＣＰコネクションを維持した状態で、ハンドオーバ後に、新ＴＣＰコネクションを生成する場合について説明する。

［動作４−１］
ＵＥ＃ｘがＷｅｂサイトとの新しい接続を開始すると、Target eNB(eNB#2)からＴＣＰ
の接続要求（syn）を含むＧＴＰ−ｕパケット（図６）がTarget S-GW(S-GW#2)へ向けて送信される。すると、Target oGW(oGW#2)は、ＧＴＰ−ｕパケットを受信し、図２６に示し
た処理を行う。この処理の結果、図８に示すパケットが、オフロードアンカポイント（ｏＧＷ＃２のアンカポイント７６）へ送信される。

[動作４−２]
Target oGW(oGW#2)のオフロード条件適用状態テーブル１７６Ａ´に対し、ｏＧＷ内Ｕ
Ｅ識別子及び利用者回線識別子に対応する、新たなＴＣＰコネクション情報とそのオフロードアンカポイント情報とが記憶される（図５６参照）。

[動作４−３]
続いて、Target oGW(oGW#2)の振分ポイント７５からTarget oGW(oGW#2)のアンカポイント７６へ向けて送信されたパケット（図８）をアンカポイント７６（oGW#2）が受信する
と、図２７に示した処理が実行され、図９に示すパケットがオフロード網５０経由でＷｅｂサイトへ送信される。

[動作４−４]
Target oGW(oGW#2)のＴＯＦセッション管理テーブル１７８ｂ´には、ｏＧＷアンカ内
ＵＥ識別子（8102）、利用者回線識別子（2）に対応するUE TCPコネクション情報、oGW TCPコネクション情報、及びセッション状態が記憶される（図５７参照）。

[動作４−５]
続いて、図９に示したパケットがオフロード網５０を経由してＷｅｂサイトに到達すると、Ｗｅｂサイトからオフロード網５０を経由して、図１０に示したパケットが、アンカポイント７６（oGW#2）へ到達する。アンカポイント７６（oGW#2）は、図１０に示したパケットを受信し、図２８に示した処理を行う。

[動作４−６]
続いて、アンカポイント７６（oGW#2）から、振分ポイント７５（oGW#2）へ図１１に示したパケットが送信される。このパケットを受信した振分ポイント７５（oGW#2）は、図
２９に示した処理を行い、Target eNB(eNB#2)へ向けて図７のパケットを送信する。これ
によって、図５８に示すように、オフロード網５０経由での新たなＴＣＰ通信が確立する。なお、図５８Ａは、新ＴＣＰコネクション確立後のベアラ状態データを示す。

[動作４−７]
維持されたＴＣＰ通信に係るＵＥ＃ｘ−Ｗｅｂサイト間のアップリンクデータ及びダウンリンクデータの伝送経路及びｏＧＷ＃１，ｏＧＷ＃２での処理は、動作例２や３の場合と変わらないので説明を省略する。

これに対し、新ＴＣＰコネクションのＵＥ＃ｘからＷｅｂサイトへ向かうアップリンクデータは、以下のようにして伝送される。すなわち、アップリンクデータは、ｅＮＢ＃２からＳ−ＧＷ＃２宛にＧＴＰ−ｕパケット（図６）で送信される。振分ポイント７５（oGW#2）は、図６に示したパケットを受けると図２６に示した処理を行い、図８に示したパ
ケットをアンカポイント７６（oGW#2）へ送る。アンカポイント７６（oGW#2）は、図８に示したパケットを受けると図２７の処理を行い、図９に示したパケットをＷｅｂサイトへ送信する。

一方、新ＴＣＰコネクションのＷｅｂサイトからＵＥ＃ｘへ向かうダウンリンクデータは、以下のようにして伝送される。すなわち、ダウンリンクデータは、Ｗｅｂサイトからアンカポイント７６（oGW#2）宛に、図１０に示したパケットで送信される。アンカポイ
ント７６（oGW#2）は、図１０に示したパケットを受信すると、図２８の処理を行い、図
１１に示したパケットを振分ポイント７５（oGW#2）へ送信する。振分ポイント７５（oGW#2）は、図１１のパケットを受けると図２９の処理を行い、図７のパケットをｅＮＢ＃２へ送る。そして、ダウンリンクデータは、ｅＮＢ＃２からＵＥ＃ｘへ送信される。

このように、ハンドオーバ後に生成された新たなＴＣＰコネクション（ＴＣＰセッション）のオフロードアンカポイントは、その生成時にＵＥ＃ｘが接続しているｅＮＢとＳ−ＧＷとの間に介在するｏＧＷ７０のアンカポイント７６に設定される。

＜＜動作例５：ハンドオーバ後のＴＣＰコネクション切断＞＞
ＵＥ＃ｘがＴＣＰコネクションを維持した状態で、ハンドオーバ後にＴＣＰコネクションを切断する場合について説明する。

[動作５−１]
ＵＥ＃ｘがＷｅｂサイトとのＴＣＰコネクションを切断すると、Target eNB(eNB#2)よ
りＴＣＰの切断要求（fin）を含むＧＴＰ−ｕパケット（図６）が、Target S-GW(S-GW#2)
へ向けて送信される。Target oGW(oGW#2)は、ＧＴＰ−ｕパケットを受信し、図２６に示
す処理を行い、図８に示すパケットをアンカポイント７６（oGW#1）へ送信する。

[動作５−２]
図２６に示す処理（Ｓ５，Ｓ６）によって、図５９に示すように、Target OGW(oGW#2)
のオフロード条件適用状態テーブル１７６Ａ´からＴＣＰコネクションに対応するレコード（ｏＧＷ内ＵＥ識別子，利用者回線識別子，ＴＣＰコネクション情報，オフロードアンカポイント情報）が削除される。

[動作５−３]
続いて、Target oGW(oGW#2)の振分ポイント７５からSource oGW(oGW#１)のアンカポイ
ント７６へ向けて図８に示すパケットが送信される。アンカポイント７６（oGW#1）が、
図８に示すパケットを受信すると、図２７に示す処理を行い、図９に示すパケットをＷｅｂサイトへ向けて送信する。

[動作５−４]
図２７に示す処理（Ｓ２８〜Ｓ３０）によって、図６０に示すように、Source oGW(oGW#１)のアンカポイント７６におけるＴＯＦセッション管理テーブル１７８ｂの対応レコードのセッション状態として、“ＤＬ切断確認待ち”が記憶される。

[動作５−５]
図９に示したパケットがオフロード網５０を経由してＷｅｂサイトに到達すると、Ｗｅｂサイトからオフロード網５０を経由して、図１０に示したパケットが、アンカポイント７６（oGW#１）に到達する。アンカポイント７６（oGW#１）は、図１０に示したパケットを受信すると、図２８に示した処理（Ｓ４４，Ｓ４７，Ｓ４９）を行う。

これにより、図６０に示したように、Source oGW(oGW#１)のＴＯＦセッション管理テーブル１７８ｂの対応するレコードが削除される。また、上記レコードの削除によって、ＴＯＦセッション管理テーブル１７８ｂから、Source oGW(GW#1)のアンカポイント７６を通過する、ｏＧＷアンカ内ＵＥ識別子対応の全てのＴＣＰコネクションが切断されたことをＣＰＵ７３は認識することができる。これに伴い、ＣＰＵ７３は、SourceoGW(oGW#1)のｏＧＷ内ＵＥ識別子(8000)に対応するＴＯＦ中継管理テーブル１７８ａのレコードを削除し、ｏＧＷアンカ内ＵＥ識別子対応のオフロードリソースを解放する。

[動作５−６]
続いて、アンカポイント７６（oGW#１）から、振分ポイント７５（oGW#2）へ図１１に
示したパケットが送信されると、振分ポイント７５（oGW#2）は、当該パケットを受信し
、図２９に示した処理を行い、Target eNB(eNB#2)へ向けて図７に示したパケットを送信
する。これによって、ＴＣＰコネクションの切断確認がＵＥ＃ｘへ到達する。このようにして、図６１に示すように、ＴＣＰコネクションに対する経路が削除される。但し、新ＴＣＰコネクションに対する経路は維持される。

[動作５−７]
新ＴＣＰコネクションに係るアップリンク及びダウンリンクの経路は、新ＴＣＰコネクションの確立時から変更がないので説明を省略する。ＴＣＰコネクションは切断によって経路が消滅する。なお、図６２は、ＴＣＰコネクション切断後のベアラ状態データを示す。

＜第１実施形態の作用効果＞
第１実施形態によれば、ターゲットｏＧＷがハンドオーバを契機として、ソースｏＧＷ
から利用回線情報、ＴＣＰコネクション情報（通信の識別情報の一例），及びオフロードアンカポイント位置情報を受信し、これらの情報を用いて振分ポイント（中継ポイント）として機能する。これによって、継続中のＴＣＰ通信を維持することができる。一方で、通信の終了時には、アンカポイントに係る情報を削除することで、アンカポイントを解除することができる。また、新たなＴＣＰコネクションの生成時には、自装置がアンカポイントになることができる。

このようにして、新たなＴＣＰコネクションが、最初に設定されたオフロードアンカポイントを経由して確立されることを回避することができる。これによって、例えば、図１において、移動局６０が基地局１１Ｄに接続している状態において、Ｗｅｂサイト＃ｂとの新たなＴＣＰコネクションをオフロード網５０経由で確立することができる。この場合、従来では、オフロードＧＷ＃ＣからオフロードＧＷ＃Ａまでのオフロードトラヒックが必要であったが、このようなオフロードトラヒックを削減できることになる。よって、ＥＰＣ網２０（コア網：モバイル伝達網）におけるオフロードトラヒックの効率的な削減により、トラフィック削減の向上を図り、ＥＰＣ網２０の負荷を軽減し、リソースの有効活用を図ることができる。

〔第２実施形態〕
次に、第２実施形態について説明する。第２実施形態は、第１実施形態と共通点を有するので、共通点については説明を省略し、主として相違点について説明する。第１実施形態がＴＣＰコネクションを扱っていたのに対し、第２実施形態ではＵＤＰを扱う点で相違する。

＜ネットワーク構成＞
図６３は、第２実施形態のネットワーク構成例を示す。第１実施形態（図１）との相違点は、Ｗｅｂサイトを提供するＷｅｂサーバ４１，４２の代わりに、ＩＰＴＶ局として機能するコンテンツ配信サーバ４１Ａ，４１Ｂが配置されていることである。

図６３において、移動局６０が最初に基地局１１Ａ（アクセス開始位置＃Ａ）との接続を行い、ＩＰＴＶ局＃ｍとの通信をオフロード網５０（５１）を介して行っていると仮定する。その後、移動局６０の移動によって、通信を継続しつつ基地局１１Ｃ（移動先Ｃ）へハンドオーバしたと仮定する。そして、ＩＰＴＶ局＃ｎとの通信を開始すると仮定する。

この場合、アクセス開始位置＃Ａで開始したセッション＃１があるため、移動先＃ＣでＩＰＴＶ局（コンテンツ配信サーバ）４１Ｂとの通信用のセッション＃２もセッション＃１について決定したオフロードアンカポイント（ｏＧＷ＃Ａ）を通過する。このため、通信経路が長くなるだけでなく、ＩＰ移動伝達ネットワーク(ＥＰＣ網２０)内の通信経路も長くなり、ＥＰＣ網２０のトラヒックの削減効果を低いものとしていた。

換言すれば、オフロードアンカポイントは、最初に接続されたオフロードＧＷ７０（ｏＧＷ＃Ａ）に設定されているため、オフロードＧＷ７０（ｏＧＷ＃Ｃ）とｏＧＷ＃Ａとのトラヒックが発生する。さらに、ｏＧＷ＃ＣとＩＰＴＶ局＃ｎとの最短経路が図６３中の経路Ｘであっても、オフロードトラヒックはｏＧＷ＃Ａを経由する。このため、図６３中の経路Ｙのような引き延ばされた経路となっていた。第２実施形態は、このような問題を解決する。

すなわち、第２実施形態では、トラヒックオフロード対象としたマルチキャスト（Multicast）通信について、Multicast通信毎に、通信を開始したオフロード装置（ｏＧＷ）をＩＳＰ網（インターネット）とのアンカポイント装置とし、「トラヒックオフロード対象
のMulticast視聴情報とそのオフロードアンカポイントの位置(装置）」を管理する。さらに、移動局（ＵＥ)の移動に伴い、ハンドオーバ先のオフロード装置へ「トラヒックオフ
ロード対象のMulticast視聴情報とそのオフロードアンカポイントの位置(装置）」を伝える。これによって、Multicast視聴からの離脱(通信の終了を示すメッセージ）を契機として、そのMulticast通信のインターネットとのオフロードアンカポイントを解放する。

＜オフロードＧＷ（ｏＧＷ）の構成＞
図６３に示すオフロードＧＷ７０の構成として、図２，図３，図４Ａを用いて説明したオフロードＧＷ７０の構成を適用することができる。このため、詳細な説明は省略する。また、Ｓ１ベースのハンドオーバのシーケンス（図４Ｃ），及びＸ２ベースのハンドオーバのシーケンス（図４Ｃ）も共通である。

但し、図４Ｂ及び図４Ｃにおける、通信相手“Ｗｅｂサイト”は、第２実施形態では“ＩＰＴＶ局”である。ＵＥ→Ｗｅｂサイトへのアップリンクデータ（payload）は、第２
実施形態ではIGMP-join又はIGMP-leaveである。一方、第２実施形態におけるＩＰＴＶ局
→ＵＥへのダウンリンクデータ（payload）は、ＵＤＰ／ＩＰでＩＰマルチキャストされ
る放送コンテンツデータである。

図６４は、第２実施形態における、移動局６０の起動からオフロード通信開始までのシーケンスを示す。第１実施形態（図４Ｂ）との大きな相違は、ＩＰＴＶ局からのダウンリンクデータがＵＤＰで配信されることである。詳細な手順は後述する。

＜オフロード条件適用状態データ＞
図６５は、図４Ａに示したオフロード条件適用状態データ１７６を保持するオフロード条件適用状態テーブル２７６Ａのデータ構造例を示す。図６５に示すように、オフロード条件適用状態テーブル２７６Ａは、ｏＧＷ内ＵＥ識別子と、利用社回線識別子（E RAB ID）と、Multicast視聴情報と、オフロードアンカポイント情報とを含む１以上のレコード
を格納する。

“ｏＧＷ内ＵＥ識別子”は、当該オフロードＧＷ(ｏＧＷ)で移動端末（ＵＥ）６０を一意に識別する情報である。“利用者回線識別子”は、移動端末６０内での回線を一意に識別する情報であり、移動端末６０での回線識別子(E RAB ID)と同期する。“Multicast視
聴情報”として、移動局（ＵＥ）６０がＩＰＴＶ局から得るコンテンツに関して、オフロード対象とされたマルチキャストアドレス（Multicast Address）を記憶する。“オフロ
ードアンカポイント情報”は、オフロード対象のMulticast Addressでの視聴を開始した
位置でのオフロードアンカポイントの位置情報である。

＜パケット＞
図６６は、ｅＮＢ１１からＳ−ＧＷ２１へ向かうＧＴＰ−ｕパケット(IGMP（Internet Group Management Protocol）-join, IGMP-leave)のデータ構造例を示す。ＩＧＭＰは、ＩＰマルチキャストでパケットの配信を受けるホストのグループを制御するためのプロトコルでる。IGMP-joinは、ホストのグループ参加要求であり、IGMP-leaveはグループから
の離脱要求である。

図６７は、Ｓ−ＧＷ２１からｅＮＢ１１へ向かうＧＴＰ−ｕのパケット(ＩＰＴＶ放送
配信）のデータ構造例を示す。また、図６７は、オフロード網５０経由のパケットを振分ポイントのｏＧＷ７０からｅＮＢ１１へ送信する場合のＧＴＰ−ｕのパケットの構成例でもある。

図６８は、オフロード対象のuplinkパケットを振分ポイントのｏＧＷ７０からアンカポ
イントのｏＧＷ７０へ伝達するときに利用するパケット(IGMP-join,IGMP-leave)のデータ構造例である。説明を簡単にするため、ＧＴＰ−ｕをベースとしている。

図６９は、オフロード対象のuplinkパケット（IGMP-join, IGMP-leave)をアンカポイントのｏＧＷ７０からオフロード網５０へ送信するときに利用するパケット(IGMP-join, IGMP-leaveのデータ構造例を示す。

図７０は、ＩＰＴＶ局からオフロード網５０を経由してオフロードアンカポイントへ到達するパケット（ＩＰＴＶ放送配信）のデータ構造例を示す。図７１は、オフロードアンカポイントのｏＧＷ７０から振分ポイントのｏＧＷ７０へデータを伝達するときに利用するパケット（IPTV放送配信）のデータ構造例を示す。説明を簡単にするため、ＧＴＰ−ｕをベースとしている。

＜ベアラ状態管理データ＞
第２実施形態でも、各ｏＧＷ７０は、ベアラ状態管理データ１７５として、ベアラ利用者特定テーブル１７５Ａ（１７５ａ，１７５ｂ）と、ベアラテーブル１７５Ｂとを有している。両テーブル１７５Ａ，１７５Ｂのデータ構造は、第１実施形態（図１２）と同じであるため説明を省略する。

図７２は、第２実施形態における、オフロードアンカポイントでのＴＯＦ中継状態管理データ１７８のデータ構造例を示す。図７２に示すＴＯＦ中継管理テーブル２７８ａのデータ構造は、第１実施形態のＴＯＦ中継管理テーブル１７８ａ（図１２）と同じである。このため、説明を省略する。

図７２に示したＴＯＦセッション管理テーブル２７８ｂは、第１実施形態のＴＯＦセッション管理テーブル１７８ｂと異なり、以下の構造を有している。すなわち、“ｏＧＷアンカ内ＵＥ識別子”は、ｏＧＷ７０のアンカポイント内でＵＥ６０を一意に識別する情報を格納する。同一のＵＥ６０に関して、ＴＯＦ中継管理テーブル２７８ａに記憶されるｏＧＷアンカ内ＵＥ識別子と同値が格納される。

“利用者回線識別子”は、ＵＥ６０内での回線を一意に識別する情報を記憶する。ＵＥ６０での回線識別子(E RAB ID)と同期する。“Multicast視聴情報”として、ＵＥ６０で
のMulticast視聴毎のMulticast 視聴情報（例えば、Multicast Address）が記憶される。

＜メッセージ＞
第２実施形態では、第１実施形態で説明したInitial Context Setup Requestメッセー
ジ（図１４），Initiall Context Setup Responseメッセージ（図１５），Handover Requiredメッセージ（図１６）を適用可能である。また、第２実施形態は、第１実施形態におけるHandover Requestメッセージ（図１７），Handover Request Ack.メッセージ（図１
８）を適用可能である。また、第２実施形態は、第１実施形態における、Handover Commandメッセージ（図１９），UE Context Release Commandメッセージ（図２０）を適用可能である。また、第２実施形態は、第１実施形態における、X2AP:Handover Requestメッセ
ージ（図２１），X2AP:Handover Request Ack.メッセージ(図２２)，X2AP:UE Context Releaseメッセージ（図２３）を適用可能である。さらに、第２実施形態では、第１実施形
態におけるPath Switch Requestメッセージ（図２４）， Path Switch Request Ack.メッセージ（図２５）を適用可能である。

＜処理フロー＞
次に、第２実施形態におけるｏＧＷ７０における処理フローについて説明する。以下の処理は、ＣＰＵ７３（図２）によって実行される。図７３は、ｅＮＢ１１からＳ−ＧＷ２
２へ向かうuplink GTP-uパケット(IGMP-join/IGMP-leave：図６６)を振分ポイントのｏ
ＧＷ７０が受信した場合の処理フロー例を示す。

図７３において、Ｓ２０１，Ｓ２０２の処理は、第１実施形態（図２６）のＳ１，Ｓ２と同じ処理である。Ｓ２０２において、レコードがなければ、処理がＳ２１１へ進み、受信パケット（ＧＴＰ−ｕ）がＳ−ＧＷ２２へ中継され、図７３の処理が終了する。これに対し、レコードがあれば、処理がＳ２０３へ進む。

Ｓ２０３では、ＣＰＵ７３は、オフロード条件適用状態テーブル２７６Ａ（図６５）から、ｏＧＷ内ＵＥ識別子、利用者回線識別子に対応し、且つMulticast視聴情報が受信パ
ケットのグループアドレス（Group Address）情報と一致するレコードを取り出す。

Ｓ２０４では、ＣＰＵ７３は、レコードがあるか否かを判定する。レコードがあれば、処理がＳ２０５へ進み、レコードが無ければ、処理がＳ２０８へ進む。

Ｓ２０５では、ＣＰＵ７３は、ＧＴＰ−ｕユーザデータがIGMP-leave（離脱要求）か否かを判定する。このとき、ＧＴＰ−ｕユーザデータがIGMP-leave（離脱要求）であれば処理がＳ２０６に進み、IGMP-join（参加要求）であれば、処理がＳ２０７に進む。

Ｓ２０６では、ＣＰＵ７３は、オフロード条件適用状態テーブル１７６Ａ（図５）から、ｏＧＷ内ＵＥ識別子、利用者回線識別子に対応し、且つMulticast視聴情報が受信パケ
ットのグループアドレス（Group Address）情報と一致するレコードを削除する。

Ｓ２０７では、受信パケット（ＧＴＰ−ｕ）のＧＴＰ−ｕヘッダのＴＥＩＤが、オフロード条件適用状態テーブル２７６Ａのオフロードアンカポイント情報へ書き換え、オフロードアンカポイント情報が示すアンカポイントへパケットを中継する。その後、図７３の処理が終了する。

Ｓ２０８では、ＣＰＵ７３は、ＧＴＰ−ｕユーザデータがIGMP-join（参加要求）か否
かを判定する。このとき、ＧＴＰ−ｕユーザデータがIGMP-join（参加要求）であれば処
理がＳ２０９に進み、IGMP-leave（離脱要求）であれば、処理がＳ２１１に進む。

Ｓ２０９では、ＣＰＵ７３は、受信パケットのグループアドレスを含むレコードを、対応するｏＧＷ内ＵＥ識別子、利用者回線識別子とともに、オフロード条件適用状態テーブル２７６Ａに追加する。

Ｓ２１０では、ＣＰＵ７３は、受信パケット（ＧＴＰ−ｕ）のＧＴＰ−ｕヘッダのＴＥＩＤをベアラテーブル１７５Ｂ（図１２）のＴＯＦアンカポイント位置情報で書き換える。さらに、ＣＰＵ７３は、パケットをＴＯＦアンカポイント位置情報の示すアンカポイントへ中継する。その後、図７３の処理が終了する。

図７４は、オフロードアンカポイントのｏＧＷ７０が振り分けポイントのｏＧＷ７０からオフロード対象のuplinkパケット(IGMP-join,IGMP-leave)を受信した場合の処理フロー例を示す。

図７４において、Ｓ２２１，Ｓ２２２の処理は、第１実施形態（図２７）におけるＳ２１，Ｓ２２と同様の処理である。Ｓ２２２において、レコードが無ければ、図７４の処理が終了する。これに対し、レコードがあれば、処理がＳ２２３へ進む。

Ｓ２２３では、ＣＰＵ７３は、受信パケットのグループアドレスとＴＯＦセッション管
理テーブル２７８ｂ（図７２）のｏＧＷアンカ内ＵＥ識別子，利用者回線識別子，Multicast視聴情報が一致するＴＯＦセッション管理テーブル２７８ｂのレコードを取り出す。

Ｓ２２４では、ＣＰＵ７３は、レコードがあるか否かを判定する。レコードがあれば、処理がＳ２２８に進み、レコードが無ければ、処理がＳ２２５に進む。

Ｓ２２５では、ＣＰＵ７３は、ＧＴＰ−ｕユーザデータがIGMP-join（参加要求）か否
かを判定する。このとき、ＧＴＰ−ｕユーザデータがIGMP-join（参加要求）であれば処
理がＳ２２６に進み、IGMP-leave（離脱要求）であれば、処理がＳ２２７に進む。

Ｓ２２６では、ＣＰＵ７３は、ｏＧＷ（アンカポイント）のＴＣＰ通信ポートを捕捉し、ｏＧＷアンカ内ＵＥ識別子及び利用者回線識別子と対応付けたレコードを、ＴＯＦセッション管理テーブル２７８ｂに追加する。このとき、アンカポイントのＴＣＰ通信ポートは、Multicast視聴情報として記憶される。

Ｓ２２７では、ＣＰＵ７３は、ＧＴＰ−ｕカプセルからＧＴＰ−ｕユーザデータを取り出すことによって、ＩＧＭＰパケットを得る。続いて、ｏＧＷ７０のオフロード網のＩＰアドレスでＩＧＭＰパケットのソースアドレス（ＳＡ）情報を書き換える。そして、ＣＰＵ７３は、宛先へ向けてＩＧＭＰパケットを送信し、図７４の処理を終了する。

Ｓ２２８では、ＣＰＵ７３は、ＧＴＰ−ｕユーザデータがIGMP-leave（離脱要求）か否かを判定する。このとき、ＧＴＰ−ｕユーザデータがIGMP-leave（離脱要求）であれば処理がＳ２２９に進み、IGMP-join（参加要求）であれば、処理がＳ２２７に進む。

Ｓ２２９では、ＣＰＵ７３は、ＴＯＦセッション管理テーブル２７８ｂから取り出されたレコードを削除し、図７４の処理を終了する。

図７５は、オフロード網５０からオフロードアンカポイントのｏＧＷ７０がＩＰＴＶ放送配信のMulticastパケットを受信した場合の処理フロー例を示す。

図７５において、Ｓ２４１では、ＣＰＵ７３は、受信パケット（ＵＤＰ／ＩＰ）の宛先アドレス情報（ＤＡ情報）をｏＧＷ側Multicast配信情報として取り出す。

次のＳ２４２では、ＣＰＵ７３は、ＴＯＦセッション管理テーブル２７８ｂ内で、Multicast視聴情報値がｏＧＷ側Multicast配信情報と一致するレコードを検索し、取り出す。

次のＳ２４３では、ＣＰＵ７３は、レコードがあるか否かを判定する。レコードがなければ、図７５の処理が終了する。これに対し、レコードがあれば、処理がＳ２４４に進む。

Ｓ２４４では、ＣＰＵ７３は、受信パケット（ＵＤＰ／ＩＰ）のＧＴＰ−ｕカプセル化を行い、ＧＴＰ−ｕパケット（カプセル化パケット）を生成する。

Ｓ２４５では、ＣＰＵ７３は、Ｓ２４２で取り出したレコードに対応するＴＯＦ中継管理テーブル２７８ａのレコードのＴＯＦ ＤＬ−ＴＥＩＤ値（ＴＯＦ振分ポイント位置）
を、ＧＴＰ−ｕパケットのＴＥＩＤに設定する。そして、ＣＰＵ７３は、ＴＯＦ ＤＬ−ｏＧＷ値を宛先としてＧＴＰ−ｕパケットを送信する。Ｓ２４５の処理は、Multicast視
聴情報値がｏＧＷ側Multicast配信情報と一致するレコードが無くなるまで繰り返される
。その後、図７５の処理が終了する。

第２実施形態において、振分ポイントのｏＧＷ７０がオフロードアンカポイントのｏＧＷ７０からＵＥ６０宛のdownlinkパケットを受信した場合の処理フローは、第１実施形態（図２９）と同じであるため、説明を省略する。

また、第２実施形態において、Initial Context Setup Requestメッセージ(MME->eNB)
を傍受したときの処理フロー，及びInitial Context Setup Responseメッセージ(eNB->MME)を傍受したときの処理フロー，及びオフロード用ＧＴＰ−ｕトンネル生成処理は、第１実施形態の例示（図３０，図３１，図３０Ａ）を適用することができる。このため説明を省略する。

また、第２実施形態において、Handover Requiredメッセージ(source eNB->Source MME)を傍受したときの処理フロー， Handover Requestメッセージ(tartget MME -> target eNB)を傍受したときの処理フロー，及びHandover Request Ack.メッセージ(tartget eNB -> target MME)を傍受したときの処理フロー，は、第１実施形態の例示（図３２，図３３
）を適用することができる。このため説明を省略する。

図７６は、第２実施形態における、Handover Commandメッセージ(source MME -> source eNB)を傍受したときの処理フローの例を示す。図７６において、Ｓ２９１〜Ｓ２９４の処理は、第１実施形態（図３５）におけるＳ９１〜Ｓ９５の処理と同じであるので説明を省略する。Ｓ２９５では、ＣＰＵ７３は、ｏＧＷ内ＵＥ識別子に対応する、オフロード条件適用状態テーブル２７６Ａ中の、“利用者回線識別子”，“ＴＣＰコネクション情報”，“オフロードアンカポイント情報”を、ターゲットｏＧＷ７０のｏＧＷ内ＵＥ識別子に対応する “利用者回線識別子”，“ＴＣＰコネクション情報”，“オフロードアンカポ
イント情報”として、ターゲットｏＧＷ７０のオフロード条件適用状態テーブル２７６Ａにレコードを追加する。Ｓ２９６の処理は、第１実施形態のＳ９６（オフロード用ＧＴＰ−ｕ切替処理：図３５Ａ）と同様であるので、説明を省略する。Ｓ２９６の終了後、図７６の処理が終了する。

第２実施形態において、UE Context Relese Command(source MME -> source eNB)を傍
受したときの処理フロー，及びX2AP: UE Context Releaseメッセージ(target eNB -> source eNB)を傍受したときの処理フローは、第１実施形態の例示（図３６，図４０）を適用することができる。このため、説明を省略する。

図７７は、第２実施形態における、X2AP: Handover Requestメッセージ(source eNB ->
target eNB)を傍受したときの処理フローの例を示す。図７７において、Ｓ３０１〜Ｓ３０７，Ｓ３０９及びＳ３１０の処理は、第１実施形態（図３７）におけるＳ１１１〜Ｓ３０７，Ｓ１１９及びＳ１２０の処理と同じである。このため、説明を省略する。

Ｓ３０８では、ＣＰＵ７３は、Source oGW７０のｏＧＷ内ＵＥ識別子に対応する、オフロード条件適用状態テーブル２７６Ａにおける、利用者回線識別子，Multicast視聴情報
，オフロードアンカポイント情報のコピーを含むレコードを、Target oGW７０のオフロード条件適用状態テーブル２７６Ａに、ｏＧＷ内ＵＥ識別子と対応付けて追加する。その後、図７７の処理が終了する。

さらに、第２実施形態において、Path Switch Requestメッセージ(target eNB -> MME)を傍受したときの処理フロー，及びPath Switch Request Ack.メッセージ(MME -> Target
eNB)を傍受したときの処理フローは、第１実施形態の例示（図３８，図３９）を適用す
ることができる。このため、説明を省略する。

＜動作例＞
以下、図面を参照して、第２実施形態の動作例を説明する。

＜＜動作例６：ＩＰＴＶ放送の視聴開始＞＞
最初に、移動端末（ＵＥ）６０が起動して、オフロード対象のＩＰＴＶ放送の配信がオフロードされるまでの動作について、図６４のシーケンスを用いて説明する。

[動作６−１]
図６４において、移動端末６０（ＵＥ＃ｘ）が起動すると、ＵＥ＃ｘは、ｅＮＢ１１（ｅＮＢ＃１）へ、Attach Requestメッセージを送信する（図６４＜１＞）。Attach Requestメッセージは、ｅＮＢ＃１経由でＭＭＥ２１（ＭＭＥ＃１）へ到達する。

ＭＭＥ２１は、Ｓ−ＧＷ（ＳＧＷ）２２（S-GW#1）にCreate Session Requestメッセージを送る（図６４＜２＞）。ＭＭＥ２１は、Ｓ−ＧＷ２２からCreate Session Response
メッセージを受信する（図６４＜３＞）。

［動作６−２］
Ｓ−ＧＷ２２からCreate Session Responseメッセージを受信したＭＭＥ２１は、Initial Context Setup Requestメッセージ（図１４）を生成し、ｅＮＢ１１へ送る（図６４＜４＞）。ｏＧＷ７０は、Initial Context Setup Requestメッセージを傍受する（図６４
＜５＞）。すなわち、ｏＧＷ７０は、図３０及び図３０Ａに示した処理を実行する。

図３０に示す処理によって、ベアラ利用者特定テーブル１７５Ａ及びベアラテーブル１７５Ｂに対し、ｏＧＷ内ＵＥ識別子（8000）、ＭＭＥ内ＵＥ識別子（MME＃1 UE S1AP ID#x）、ＭＭＥ装置識別子(MME#1)、ｅＮＢ内ＵＥ識別子(eNB UE S1AP ID#x)、ｅＮＢ装置識別子(eNB#1)、利用者回線識別子(1,2)、uplink回線割付情報(1:TEID#SGW-u1, SGW#1, 2: TEID#SGW-u2, SGW#1)、ＴＯＦ振分ポイント位置情報(1:オフロード非適用 2: TOF DL-TEID#1)、ＴＯＦアンカポイント位置情報(TOF UL-TEID#1, oGW#1)が登録され、確定される（図４１に示すテーブル１７５Ａ及び１７５Ｂを参照）。また、図３０Ａに示す処理によって、ｏＧＷ７０内の振分ポイント７５とアンカポイント７６との間にオフロード用のＧＴＰ−ｕトンネルが確立される。

［動作６−３］
また、ｏＧＷ７０のＣＰＵ７３によって、ＴＯＦ中継管理テーブル２７８ａの記憶内容が、図７９に示す状態となる。すなわち、ＴＯＦ中継管理テーブル２７８ａにおいて、ｏＧＷアンカ内ＵＥ識別子、利用者回線識別子、ＴＯＦアンカポイント位置、ＴＯＦ振分ポイント位置が確定する。

［動作６−４］
Initial Context Setup Requestメッセージを受信したｅＮＢ１１は、応答メッセージ
であるInitial Context Setup Responseメッセージ(図１５)を送信する（図６４＜６＞）。ｏＧＷ７０は、Initial Context Setup Responseメッセージを傍受し（図６４＜７＞）、図３１に示した処理を実行する。これによって、ベアラテーブル１７５Ｂに対し、downlink回線割付情報（1: eNB-TEID#1, eNB#1, 2: eNB-TEID#2, eNB#1）が登録され、確定する（図７８参照）。

［動作６−５］
続いて、図６４のシーケンスにおいて、ＵＥ６０がＩＰＴＶ局との接続を開始すると（図６４＜８＞）、ｅＮＢ１１（eNB#1）から、ＵＥ６０のアップリンクデータを含むＧＴ
Ｐ−ｕパケット（図６６：IGMP-joinパケット）がＳ−ＧＷ２２（S-GW#1）へ向けて送信
される（図６４＜９＞）。すると、ｏＧＷ７０（oGW#1）は、IGMP-joinパケットを受信し
、図７３に示した処理を行う。このとき、図７３におけるＳ２０１〜Ｓ２０４及びＳ２０８〜Ｓ２１０の処理が実行される。

［動作６−６］
図７３におけるＳ２０９の処理によって、オフロード条件適用状態テーブル２７６Ａに対し、ｏＧＷ内ＵＥ識別子および利用者回線識別子に対応する、Multicast視聴情報及び
オフロードアンカポイント情報が記憶される（図８０のテーブル２７６Ａを参照）。

［動作６−７］
図７３におけるＳ２１０の処理によって、図６８に示したオフロードアンカポイント向けのＧＴＰ−ｕ（IGMP-join）パケットが生成され、振分ポイントのｏＧＷ７０からアン
カポイントのｏＧＷ７０へ送信される。ここでは、ｏＧＷ７０（oGW#1）内において、振
分ポイント７５からアンカポイント７６へパケットが転送される。

[動作６−８]
アンカポイント７６では、図７４に示した処理が実行される。ここでは、Ｓ２２１〜Ｓ２２７の処理が実行され、IGMP-joinパケット（図６９）がオフロード網５０へ送信され
る（図６４＜１１＞）。Ｓ２２６の処理によって、ＴＯＦセッション管理テーブル２７８ｂには、ｏＧＷアンカ内ＵＥ識別子、利用者回線識別子に対応する、Multicast視聴情報
が記憶される（図７９参照）。

[動作６−９]
IGMP-joinパケットがオフロード網５０を経由してＩＰＴＶ局（コンテンツ配信サーバ
）に到達すると、ＩＰＴＶ局からオフロード網５０を経由して、ダウンリンクパケット（図７０）が、ｏＧＷ７０（oGW＃1）のアンカポイント７６へ到達する（図６４＜１２＞）。アンカポイント７６では、パケット受信により、図７５に示す処理が行われる。

[動作６−１０]
続いて、オフロードアンカポイントのｏＧＷ７０（oGW#1：アンカポイント７６）から
、振分ポイントのオフロードＧＷ７０（oGW#1：振分ポイント７５）へ図７１に示したパ
ケットが送信されると（図６４＜１３＞）、振分ポイント７５（oGW#1）は、パケットを
受信し、図２９に示した処理（Ｓ５１〜Ｓ５３）を行い、基地局１１（eNB#1）へ向けて
、図６７に示したパケットを送信する（図６４＜１４＞）。そして、ダウンリンクデータ（ＩＰＴＶ放送コンテンツ）が、ＵＥ６０に到達する（図６４＜１５＞）。これによって、図８１で示すようなオフロード網５０経由のMulticast視聴が確立し、ＵＥ６０のユー
ザは、ＩＰＴＶ局から配信された放送コンテンツを視聴することができる。

[動作６−１１]
ＵＥ６０（ＵＥ＃ｘ）からＩＰＴＶ局へ向かうデータ（IGMP-join）は、以下のように
して伝達される。すなわち、ｅＮＢ１１（ｅＮＢ＃１）で受信されたＵＥ＃ｘからのデータ（参加要求）は、基地局１１（eNB#1）からＳ−ＧＷ＃１宛にＧＴＰ−ｕパケット（IGMP-join）で送信される。振分ポイント７５（oGW#1）は、ＧＴＰ−ｕパケット（IGMP-join）のパケットを受信すると、図７３の処理（振分処理１７４を含む）を行い、図６８に示すパケットをアンカポイント７６（oGW#1）へ送る。アンカポイント７６（oGW#1）は、図６８に示すパケットを受けると図７４の処理を行い、図６９のIGMP-joinパケットをオフ
ロード網５０経由でＩＰＴＶ局へ送信する。

[動作６−１２]
これに対し、IPTV局からＵＥ＃ｘへ向かうデータ（放送コンテンツ）は、以下のようにして配信される。すなわち、IPTV局からアンカポイント７６（oGW#1）宛に、図７０のパ
ケットが送信さる。アンカポイント７６（oGW#1）は、図７０のパケットを受信すると、
図７５の処理を行い、図７１のパケットを振分ポイント７５（oGW#1）へ送信する。振分
ポイント７５（oGW#1）は、図７１のパケットを受けると図２９の処理を行い、図６７の
パケットをｅＮＢ＃１へ送る。ｅＮＢ＃１は、放送コンテンツデータをＵＥ＃ｘへ送る。

＜＜動作例７：Ｓ１ベースのハンドオーバに対するＩＰＴＶ放送維持＞＞
次に、ＵＥ６０（ＵＥ＃ｘ）でのＩＰＴＶ放送の視聴を維持しつつ、ＵＥ＃ｘの移動に伴い、Source eNBからTarget eNBへハンドオーバするまでの動作について、図４ＣのＳ１ベースのハンドオーバ手順を示すシーケンスに従って説明する。

[動作７−１]
ＵＥ＃ｘの移動に伴いSource eNB(eNB#1)がＳ１ベースのハンドオーバを開始すると、Source eNB(eNB#1)から、ハンドオーバ元のＭＭＥ２１（以下、“source MME(MME#1)”と
表記）へHandover Requiredメッセージ（図１６）が送信される（図４Ｃ＜１＞）。する
と、Source oGW(oGW#1)は、Handover Requiredメッセージを傍受し（図４Ｃ＜２＞）、図３２に示した処理（Ｓ８１及びＳ８２）を行う。

[動作７−２]
図８２は、S1-Based Handover でのオフロード条件適用状態の引継の例を示す。図３２の処理によって、Source oGW(oGW#1)のベアラ利用者特定テーブル１７５ｂに、Handover Requiredメッセージ中のハンドオーバ先のｅＮＢ１１（Target eNB#2）の識別子“Target
ID＝eNB#2”,及びハンドオーバ先のセル識別情報“S-Targetセル識別情報＝Cell ID#x”が登録され、確定する。

[動作７−３]
source MME(MME#1)は、Target MME(MME#2)へ、Forward Relocation Requestメッセージを送る（図４Ｃ＜３＞）。すると、Target MME(MME#2)は、Target eNB#2へHandover Requestメッセージ（図１７）を送信する（図４Ｃ＜４＞）。Target oGW(oGW#2)は、Handover
Requestメッセージを傍受し（図４Ｃ＜５＞）、図３３及び図３０Ａに示した処理を実行する。

[動作７−４]
Handover Requestメッセージの傍受によって、図８２に示すように、Target oGW(oGW#2)は、ベアラ利用者特定テーブル１７５Ａ´（テーブル１７５ａ´及び１７５ｂ´）に、
ｏＧＷ内ＵＥ識別子、ＭＭＥ内ＵＥ識別子、ＭＭＥ装置識別子、ｅＮＢ装置識別子、利用者回線識別子、uplink回線割付情報、ＴＯＦ振分ポイント位置情報、ＴＯＦアンカポイント位置情報、T -targetセル識別情報を記憶し、確定させる。

[動作７−５]
また、Target oGW(oGW#2)は、図８３に示すように、ＴＯＦ中継管理テーブル２７８ａ
´に、ｏＧＷアンカ内ＵＥ識別子、利用者回線識別子、ＴＯＦアンカポイント位置、ＴＯＦ振分ポイント位置を記憶し、確定させる。

[動作７−６]
続いて、Target eNB（eNB#2)がTarget MME(MME#2)へHandover Request Ack.メッセージ（図１８）を送る（図４Ｃ＜６＞）。すると、Target oGW(oGW#2)は、Handover Request Ack.メッセージを傍受し、図３４の処理を行う（図４Ｃ＜７＞）。

[動作７−７]
図３４の処理によって、Target oGW(oGW#2)は、図８２に示すように、ベアラテーブル
１７５Ｂ´にdownlink回線割付情報を記憶し、確定させる。また、Target oGW(oGW#2)は
、Bearer利用者特定テーブル１７５Ａ´に、Handover Request Ack.メッセージから得たT-Targetセル内ＵＥ識別情報を記憶し、確定させる。

[動作７−８]
Handover Request Ack.メッセージを受信したTarget MME(MME#2)は、Forward Relocation Response メッセージをSource MME(MME#1)へ送る（図４Ｃ＜８＞）。すると、Source MME(MME#1)は、Target eNB(eNB#1)に対し、Handover Commandメッセージ（図１９）を送
信する（図４Ｃ＜９＞）。このとき、Source oGW(oGW#1)は、Handover Commandメッセー
ジを傍受し（図４Ｃ＜１０＞）、図７６の処理を行う。

[動作７−９]
図７６の処理によって、Source oGW(oGW#1)は、ベアラ利用者特定テーブル１７５Ａに
、S-Targetセル内ＵＥ識別情報を登録し、確定させる（図８２参照）。これによって、Source oGW(oGW#1)のベアラ利用者特定テーブル１７５ＡのTarget ID，S-Targetセル識別情報，S-Targetセル内ＵＥ識別情報と、Target oGW (oGW#2)のベアラ利用者特定テーブル１７５Ａ´のeNB装置識別子,T-Targetセル識別情報,T-Targetセル内ＵＥ識別情報とが一致
する。従って、移動端末６０（ＵＥ＃ｘ）に対するSource oGW(oGW#1)のｏＧＷ内ＵＥ識
別子(8000)とTarget oGW(oGW#2)のｏＧＷ内ＵＥ識別子(8102)のとを対応付けすることが
できる。

[動作７−１０]
図７６のＳ２９５の処理によって、ｏＧＷ＃１は、ｏＧＷ＃２との連携において、図８４に示すように、ｏＧＷ＃１のオフロード条件適用状態テーブル１７６ＡにおけるｏＧＷ内ＵＥ識別子(8000)に対応する利用者回線識別子、ＴＣＰコネクション情報、オフロードアンカポイント情報のコピーを、ｏＧＷ＃２におけるＵＥ＃ｘのｏＧＷ内ＵＥ識別子(8102)に対応付けて、ｏＧＷ＃２のオフロード条件適用状態テーブル１７６Ａ´に登録する。これによって、ｏＧＷ＃１及びｏＧＷ＃２は、オフロード対象のトラヒック毎にオフロードアンカポイント情報を知ることができる。

[動作７−１１]
また、ｏＧＷ＃１は、テーブル２７８ａ´（図８３）の記憶内容に基づき、ｏＧＷ＃１のアンカポイント７６における、オフロードアンカポイント情報(TOF UL-TEID#1)に対応
するＴＯＦ振分ポイント位置を、ｏＧＷ＃２のＴＯＦ振分ポイント位置情報(TOF DL-TEID#2)へ切り替える（図８３参照）。

これによって、図８５のように、ＵＥ＃ｘの移動に伴うS1-Based Handoverにおいて、
ＩＰＴＶ放送視聴は維持されたままで、ＵＥ＃ｘ→eNB#2→振分ポイント７５（oGW#2）→アンカポイント７６（oGW#1）→ＩＰＴＶ放送局の経路へ移行する。

［動作７−１２］
動作７−１１の終了後における、ｅＮＢ＃２が受信するＵＥ＃ｘからのデータ（IGMP-join）は以下のようにしてＩＰＴＶ局へ伝達される。すなわち、ｅＮＢ＃２からＳ−ＧＷ
＃２へ向けて、ＧＴＰ−ｕパケット（IGMP-join）が送信される。振分ポイント７５（oGW#2）は、パケットを受けると図７３の処理を行い、図６８に示すパケットをアンカポイント７６（oGW#1）へ送る。アンカポイント７６（oGW#1）は、図６８に示すパケットを受けると、図７４の処理を行い、図６９のパケットをオフロード網５０経由でＩＰＴＶ局へ送信する。

[動作７−１３]
これに対し、ＩＰＴＶ局からＵＥ＃ｘへ向かうデータは、以下のようにして伝達される。すなわち、ＩＰＴＶ局からのダウンリンクデータ（放送コンテンツ）は、オフロード網５０経由で、アンカポイント７６（oGW#1）宛に、図７０に示すパケットで送信される。
アンカポイント７６（oGW#1）は、図７０に示すパケットを受信すると、図７５の処理を
行い、図７１のパケットを振分ポイント７５（oGW#2）へ送信する。振分ポイント７５（oGW#2）は、図７１に示すパケットを受けると図２９に示した処理（合流処理１７３を含む）を行い、図６７のパケットをｅＮＢ＃２へ送る。ｅＮＢ＃２は、ダウンリンクデータをＵＥ＃ｘに送る。

［動作７−１４］
Source MME(MME#1)は、Source eNB(eNB#1)に対し、UE Context Release Commandメッセージ（図２０） を送信する（図４Ｃ＜１９＞）。すると、Source oGW(oGW#1)は、UE Context Release Commandメッセージを傍受し（図４Ｃ＜２０＞）、図３６に示した処理を行う。

[動作７−１５]
図３６に示すＳ１０１〜Ｓ１０４の処理によって、Source oGW(oGW#1)におけるｏＧＷ
内ＵＥ識別子(8000)に対応するレコードが削除される。すなわち、ベアラ利用者特定テーブル１７５Ａ，ベアラテーブル１７５Ｂ，オフロード条件適用状態テーブルの対応レコードが削除される（図８６及び，図８７参照）。そして、Source oGW(oGW#1)の振分ポイン
ト７５のリソースが解放される。なお、図８９Ａは、ハンドオーバ完了後の、オフロード条件適用状態の例を示す。

これによって、図８８に示すように、ＩＰＴＶ放送の視聴に対して、Source oGW(oGW#1)のアンカポイント７６のリソースは、ＩＰＴＶ放送の視聴を維持するために保持される
。

＜＜動作例８：Ｘ２ベースのハンドオーバに対するＴＣＰコネクションの維持＞＞
次に、ＵＥ＃ｘでのＴＣＰ通信を維持しつつ、ＵＥ＃ｘの移動に伴い、Source eNBからTarget eNBへハンドオーバするまでの動作について、図４Ｄに示すシーケンスに従って説明する。

[動作８−１]
ＵＥ＃ｘの移動に伴いSource eNB(eNB#1)がＸ２ベースのハンドオーバを開始すると、Source eNB(eNB#1)からTarget eNB (eNB#2)へ、X2AP: Handover Requestメッセージ（図２１）が送信される（図４Ｄ＜１＞）。Source oGW(oGW#1)は、X2AP: Handover Requestメ
ッセージを傍受し（図４Ｄ＜２＞）、図７７に示した処理（Ｓ３０１，Ｓ３０９，Ｓ３１０）を行う。

[動作８−２]
図７７に示した処理によって、Source oGW(oGW#1)は、ベアラ利用者特定テーブル１７
５Ａ（図８９参照）のｅＮＢ内ＵＥ識別子(X2AP)を確定する。

[動作８−３]
Target oGW(oGW#2)は、X2AP: Handover Requestメッセージを傍受し（図４Ｄ＜３＞）
、図７７に示した処理（Ｓ３０１〜Ｓ３０８）及び図３０Ａに示したオフロード用ＧＴＰ−ｕトンネル生成処理を行う。

[動作８−４]
Ｓ３０１〜Ｓ３０８の処理によって、Target oGW(oGW#2)において、図８９に示すよう
に、ｏＧＷ内ＵＥ識別子、ＭＭＥ内ＵＥ識別子、ＭＭＥ装置識別子、ｅＮＢ装置識別子、利用者回線識別子、uplink回線割付情報、ＴＯＦ振分ポイント位置情報、ＴＯＦアンカポイント位置情報が確定し、ベアラ利用者特定テーブル１７５Ａ´及びベアラテーブル１７５Ｂ´に記憶される。

[動作８−５]
また、Target oGW(oGW#2)において、図９０に示すように、ｏＧＷアンカ内ＵＥ識別子
、利用者回線識別子、ＴＯＦアンカポイント位置、ＴＯＦ振分ポイント位置が確定し、ＴＯＦ中継管理テーブル２７８ａ´に記憶される。

[動作８−６]
上記したように、Target oGW(oGW#2)のベアラ利用者特定テーブル１７５Ａ´において
ＭＭＥ内ＵＥ識別子が確定する。このとき、図８９に示すように、ｏＧＷ＃１のベアラ利用者特定テーブル１７５ＡのＭＭＥ内ＵＥ識別子とｏＧＷ＃２のベアラ利用者特定テーブル１７５Ａ´のＭＭＥ内ＵＥ識別子とは一致する。これによって、ＵＥ＃ｘに対するｏＧＷ＃１のｏＧＷ内ＵＥ識別子(8000)とｏＧＷ＃２のｏＧＷ内ＵＥ識別子(8102)のとの対応付けができる。

［動作８−７］
図９１に示すように、ｏＧＷ＃１のｏＧＷ内ＵＥ識別子(8000)に対応するオフロード条件適用状態テーブル１７６Ａの利用者回線識別子、Multicast視聴情報、及びオフロード
アンカポイント情報のコピーが、ｏＧＷ＃１からｏＧＷ＃２に渡される。ｏＧＷ＃２は、コピーをｏＧＷ＃２のオフロード条件適用状態テーブル１７６Ａ´に記憶する。これによって、ｏＧＷ＃２は、オフロード対象のトラヒック毎にオフロードアンカポイント情報を知ることができる。

［動作８−８］
その後、Target eNB(eNB#2)からX2AP: Handover Request Ack.メッセージが送信され、ｏＧＷ＃２，ｏＧＷ＃１を経由してSource eNB(eNB#1)に届く（図４Ｄ＜４＞）。その後
、オフロード網５０，ＰＧＷ２３からのダウンリンクデータは、Source eNB(eNB#1)，ｏ
ＧＷ＃１，ｏＧＷ＃２，Target eNB(eNB#2)を経由してＵＥ＃ｘへ到達する（図４Ｄ＜５
＞）。ＵＥ＃ｘからのアップリンクデータは、Target eNB(eNB#2)及びｏＧＷ＃２経由で
、オフロード網５０（ＰＧＷ２３）へ送信される（図４Ｄ＜６＞）。

[動作８−９]
続いて、Target eNB(eNB#2)は、Path Switch Requestメッセージ（図２４）を ＭＭＥ(MME#1)に送信する（図４Ｄ＜７＞）。Target oGW(oGW#2)は、Path Switch Requestメッセージを傍受し（図４Ｄ＜８＞）、図３８及び図３５Ａの処理を行う。

[動作８−１０]
図３８及び図３５Ａの処理によって、ｏＧＷ＃２のＴＯＦ中継管理テーブル１７８ａ´に記憶されたＴＯＦ振分ポイント位置がｏＧＷ＃１に渡され、ｏＧＷ＃１のＴＯＦ中継管理テーブル１７８ａのＴＯＦポイント位置として設定される（図３５ＡのＳ９６ｃ）。これによって、Source oGW(oGW#1)におけるＴＯＦ振分ポイント位置がｏＧＷ＃２のＴＯＦ
振分ポイント位置(TOF DL-TEID#2)に切り替えられる。

［動作８−１１］
その後、ＭＭＥ(MME#1)がTarget eNB(eNB#2)に対し、Path Switch Request Ack.メッセージ（図２５）を送信する（図４Ｄ＜８＞）。すると、Target eNB(eNB#2)は、Path Switch Request Ack.メッセージを傍受し、図３９に示す処理（Ｓ１３５，Ｓ１３６）を行う
（図４Ｄ＜９＞）。

[動作８−１２]
図３９に示す処理によって、Target oGW(oGW#2)のベアラテーブル１７５Ｂ´において
、ｏＧＷ内ＵＥ識別子(8102)に対応するuplink回線割付情報がＳ−ＧＷ＃１からＳ−ＧＷ＃２へ切り替えられる（図８９参照）。

これによって、図９２に示すように、ＵＥ＃ｘの移動に伴うＸ２ベースのハンドオーバにおいて、ＩＰＴＶ視聴が維持されたまま、ＵＥ＃ｘ→eNB#2→振分ポイント（oGW#2）→アンカポイント(oGW#1)→ＩＰＴＶ局の経路へ移行する。

［動作８−１３］
動作例３によって、ＵＥ＃ｘからＷｅｂサイトへ向かうアップリンクデータ（IGMP-join又はIPMG-leave）は、以下のようにして伝達される。すなわち、ｅＮＢ＃２で受信され
るＵＥ＃ｘからのアップリンクデータ（参加又は離脱要求）は、Ｓ−ＧＷ＃１宛のＧＴＰ−ｕパケット（IGMP-join又はIPMG-leave）で送信される。振分ポイント７５（oGW#2）は、図６６のパケットを受けると図７３の処理を行い、図６８に示すパケットをアンカポイント７６（oGW#1）へ送る。アンカポイント７６（oGW#1）は、図６８のパケットを受けると図７４の処理を行い、図６９のパケットをＩＰＴＶ局へ送信する。

[動作８−１４]
一方、ＩＰＴＶ局からＵＥ＃ｘへ向かうダウンリンクデータ（放送コンテンツ）は、以下のようにして伝達される。すなわち、ＩＰＴＶ局からアンカポイント７６（oGW#1）宛
に、図７０のパケットが送信される。アンカポイント７６（oGW#1）は、図７０のパケッ
トを受信すると、図７５の処理を行い、図７１のパケットを振分ポイント７５（oGW#2）
へ送信する（図４Ｄ＜１４＞）。振分ポイント７５（oGW#2）は、図７１のパケットを受
けると図２９の処理を行い、図６７のパケットをｅＮＢ＃２へ送る（図４Ｄ＜１５＞）。ｅＮＢ＃２は、ダウンリンクデータをＵＥ＃ｘに送る（図４Ｄ＜１６＞）。

[動作８−１５]
その後、図４Ｄには図示しないが、Target eNB(eNB#2）がSource eNB(eNB#1)へX2AP: UE Context Releaseメッセージを送信する。すると、Source oGW(oGW#1)は、X2AP: UE Context Releaseメッセージを傍受し、図４０に示す処理（Ｓ１２１〜Ｓ１２４）を行う。これによって、Source oGW(oGW#1)のｏＧＷ内ＵＥ識別子(8000)に対応するレコードが、ベ
アラ利用者特定テーブル１７５Ａ，ベアラテーブル１７５Ｂから削除されるとともに（図４９参照）、オフロード条件適用状態テーブル１７６Ａから削除される（図５０参照）。そして、Source oGW(oGW#1)の振分ポイント７５のリソースが解放される。このようにし
て、図５１に示したように、ＩＰＴＶ視聴に対して、Source oGW(oGW#1)のアンカポイン
ト７６のリソースは、ＩＰＴＶ視聴を維持するために保持される。

＜＜動作例９：ハンドオーバ後の新ＩＰＴＶ視聴開始＞＞
次に、ＵＥ＃ｘがＩＰＴＶ視聴を維持した状態で、ハンドオーバ後に、新ＩＰＴＶ放送の視聴を開始する場合について説明する。

［動作９−１］
ＵＥ＃ｘが新たなＩＰＴＶ放送の視聴を開始すると、Target eNB(eNB#2)からＧＴＰ−
ｕパケット（IGMP-join）がTarget S-GW(S-GW#2)へ向けて送信される。すると、Target oGW(oGW#2)は、ＧＴＰ−ｕパケット（IGMP-join）を受信し、図７３に示した処理を行う。この処理の結果、図６８に示すパケットが、Target oGW(oGW#2)の振分ポイント７５からTarget oGW(oGW#2)のアンカポイント７６へ向けて送信される。

[動作９−２]
Target oGW(oGW#2)のオフロード条件適用状態テーブル１７６Ａ´に対し、ｏＧＷ内Ｕ
Ｅ識別子及び利用者回線識別子に対応する、新たなMulticast視聴情報とそのオフロード
アンカポイント情報とが記憶される（図９３参照）。

[動作９−３]
続いて、アンカポイント７６（oGW#2）が、図６８に示したパケットを受信すると、図
７４に示した処理が実行され、図６９に示すパケットがオフロード網５０経由でＩＰＴＶ局へ送信される。

[動作９−４]
Target oGW(oGW#2)のＴＯＦセッション管理テーブル２７８ｂ´には、ｏＧＷアンカ内
ＵＥ識別子（8102）、利用者回線識別子（2）に対応するMulticast視聴情報が記憶される（図９４参照）。

[動作９−５]
続いて、図６９に示したパケットがオフロード網５０を経由してＩＰＴＶ局（視聴を維持しているＩＰＴＶ局（コンテンツ配信サーバ）と同じでも異なっていても良い）に到達する。すると、ＩＰＴＶ局からオフロード網５０を経由して、図７０に示したパケットが、アンカポイント７６（oGW#2）へ到達する。アンカポイント７６（oGW#2）は、図７０に示したパケットを受信し、図７５に示した処理を行う。

[動作９−６]
続いて、アンカポイント７６（oGW#2）から、振分ポイント７５（oGW#2）へ図７１に示したパケットが送信される。このパケットを受信した振分ポイント７５（oGW#2）は、図
２９に示した処理を行い、Target eNB(eNB#2)へ向けて図６７のパケットを送信する。こ
れによって、図９５に示すように、オフロード網５０経由での新たなＩＰＴＶ放送の視聴が開始される。なお、図９６は、新たなＩＰＴＶ放送の視聴開始後のベアラ状態データを示す。

[動作９−７]
維持されたＩＰＴＶ視聴に係るＵＥ＃ｘ−ＩＰＴＶ局間のアップリンクデータ及びダウンリンクデータの伝送経路及びｏＧＷ＃１，ｏＧＷ＃２での処理は、動作例７や８の場合と変わらないので説明を省略する。

これに対し、新たなＩＰＴＶ放送視聴に関して、ＵＥ＃ｘからＩＰＴＶ局へ向かうアップリンクデータ（IGMP）は、以下のようにして伝送される。すなわち、アップリンクデータは、ｅＮＢ＃２からＳ−ＧＷ＃２宛にＧＴＰ−ｕパケット（IGMP-join 又はIGMP-leave）で送信される。振分ポイント７５（oGW#2）は、図６６に示したパケットを受けると図
７３に示した処理を行い、図６８に示したパケットをアンカポイント７６（oGW#2）へ送
る。アンカポイント７６（oGW#2）は、図６８に示したパケットを受けると図７４の処理
を行い、図６９に示したパケットをＩＰＴＶ局へ送信する。

一方、新たなＩＰＴＶ放送視聴に係るＩＰＴＶ局からＵＥ＃ｘへ向かうダウンリンクデータ（放送コンテンツ）は、以下のようにして伝送される。すなわち、ダウンリンクデータは、ＩＰＴＶ局からアンカポイント７６（oGW#2）宛に、図７０に示したパケットで送
信される。アンカポイント７６（oGW#2）は、図７０に示したパケットを受信すると、図
７５の処理を行い、図７１に示したパケットを振分ポイント７５（oGW#2）へ送信する。
振分ポイント７５（oGW#2）は、図７１のパケットを受けると図２９の処理を行い、図６
７のパケットをｅＮＢ＃２へ送る。そして、ダウンリンクデータ（放送コンテンツ）は、ｅＮＢ＃２からＵＥ＃ｘへ送信される。

このように、ハンドオーバ後に生成された新たなＩＰＴＶ視聴に係るオフロードアンカポイントは、その開始時にＵＥ＃ｘが接続しているｅＮＢとＳ−ＧＷとの間に介在するｏＧＷのアンカポイント７６に設定される。

＜＜動作例１０：ハンドオーバ後のＩＰＴＶ放送視聴離脱＞＞
ＵＥ＃ｘがＩＰＴＶ放送の視聴を維持した状態で、ハンドオーバ後に当該視聴状態から離脱する場合について説明する。

[動作１０−１]
ＵＥ＃ｘがＩＰＴＶ放送の視聴を停止（ＩＰＴＶ放送視聴離脱）すると、Target eNB(eNB#2)よりIGMP-leaveのＧＴＰ−ｕパケット（図６６）が、Target S-GW(S-GW#2)へ向けて送信される。Target oGW(oGW#2)は、ＧＴＰ−ｕパケット（IGMP-leave）を受信し、図７
３に示す処理を行い、図６８に示すパケットをアンカポイント７６（oGW#1）へ送信する
。

[動作１０−２]
図７３に示す処理（Ｓ２０５，Ｓ２０６）によって、図９７に示すように、Target OGW(oGW#2)のオフロード条件適用状態テーブル１７６Ａ´からIPTV放送視聴に対応するレコ
ード（ｏＧＷ内ＵＥ識別子，利用者回線識別子，Multicast視聴情報，オフロードアンカ
ポイント情報）が削除される。

[動作１０−３]
続いて、Target oGW(oGW#2)の振分ポイント７５からSource oGW(oGW#１)のアンカポイ
ント７６へ向けて図６８に示すパケットが送信される。アンカポイント７６（oGW#1）が
、図６８に示すパケットを受信すると、図７４に示す処理を行い、図６９に示すパケットをＩＰＴＶ局へ向けて送信する。

[動作１０−４]
図７４に示す処理（Ｓ２２８，Ｓ２２９）によって、図９８に示すように、Source oGW(oGW#１)のアンカポイント７６におけるＴＯＦセッション管理テーブル２７８ｂの対応レコードが削除される。また、ＴＯＦ中継管理テーブル２７８ａの対応レコードも削除される。

[動作１０−５]
図６９に示したパケットがオフロード網５０を経由してＩＰＴＶ局に到達すると、ＩＰＴＶ局からオフロード網５０を経由して、図７０に示したパケットが、アンカポイント７６（oGW#１）に到達する。アンカポイント７６（oGW#１）は、図７０に示したパケットを受信すると、図７５に示した処理を行う。この時点でＵＥ＃ｘは、マルチキャストグループから離脱している。このため、マルチキャストパケットのＵＥ＃ｘに対する配信は実施されない。

これにより、図９９に示すように、ＩＰＴＶ放送視聴に対する経路が削除される。但し、新たなＩＰＴＶ放送視聴に対する経路は維持される。

[動作１０−６]
新たなＩＰＴＶ放送視聴に係るアップリンク及びダウンリンクの経路は、新ＴＣＰコネクションの確立時から変更がないので説明を省略する。なお、図１００は、ＩＰＴＶ放送
離脱後のベアラ状態データを示す。

＜第２実施形態の作用効果＞
第２実施形態によれば、ｏＧＷ７０が振分ポイント７５とアンカポイント７６とを有し、ハンドオーバを契機として、Target oGWがオフロードアンカポイントの情報と、維持
されるＩＰＴＶ放送の視聴情報（Multicast視聴情報）とを保持する。これによって、新
たなＩＰＴＶ放送の視聴開始時に、自ｏＧＷをオフロードアンカポイントとしたＩＰＴＶ放送の視聴（Multicastパケットの受信経路確立）が可能となる。また、IGMP-leave(離脱要求)を、適正にオフロードアンカポイントのｏＧＷ７０へ伝達することができる。

このようにして、Multicast配信サービスの享受開始において、新たなMulticastパケットの配信経路が、最初に設定されたオフロードアンカポイントを経由して確立されることを回避することができる。

これによって、例えば、図６３において、移動端末６０が基地局１１Ｃに接続している状態において、ＩＧＭＰ局＃ｎ（サーバ４１Ｂ）からのMulticastパケットの配信経路を
、オフロード網５１ではなくオフロード網５２経由で確立することができる。この場合、オフロードＧＷ＃ＣからオフロードＧＷ＃Ａまでのトラヒックが削減される。よって、ＥＰＣ網２０（コア網：モバイル伝達網）におけるオフロード用のトラヒックの削減により、トラフィック削減の向上を図り、ＥＰＣ網２０への負荷を軽減し、リソースの有効活用を図ることができる。

＜その他＞
（付記１） 移動局が接続可能な複数の基地局と、
前記複数の基地局を収容するコア網と、
前記複数の基地局と前記コア網との間に介在し、オフロード対象のトラヒックをオフロード網との間で送受信するアンカポイントとして機能する一方で、前記アンカポイントと前記移動局が接続中の前記複数の基地局の一つとの間で前記オフロード対象のトラヒックを中継する中継ポイントとして機能する複数のオフロード装置とを含み、
前記各オフロード装置は、
前記移動局が自装置を介してオフロード対象のトラヒックの通信を開始する場合に、自装置に係る前記トラヒックの回線情報，前記通信の識別情報，及び前記トラヒックのアンカポイントの位置情報を含むアンカポイント情報を記憶する記憶装置と、
前記通信の継続中に、前記移動局のハンドオーバによって他のオフロード装置が前記中継ポイントとなる場合に、前記他のオフロード装置に前記アンカポイント情報を送信する送信装置と、
自装置が前記中継ポイントとして機能する場合に、他のオフロード装置から受信された前記アンカポイント情報を用いてオフロード対象のトラヒックを中継し、前記通信の終了時には、前記アンカポイントの設定を解除する制御装置とを含む
ネットワークシステム。（１）

（付記２） 移動局が接続可能な複数の基地局と、前記複数の基地局を収容するコア網のとの間に介在し、オフロード対象のトラヒックをオフロード網との間で送受信するアンカポイントとして機能する一方で、前記アンカポイントと前記移動局が接続中の前記複数の基地局の一つとの間で前記オフロード対象のトラヒックを中継する中継ポイントとして機能するオフロード装置であって、
前記移動局が自装置を介してオフロード対象のトラヒックの通信を開始する場合に、自装置に係る前記トラヒックの回線情報，前記通信の識別情報，及び前記トラヒックのアンカポイントの位置情報を含むアンカポイント情報を記憶する記憶装置と、
前記通信の継続中に、前記移動局のハンドオーバによって他のオフロード装置が前記中
継ポイントとなる場合に、前記他のオフロード装置に前記アンカポイント情報を送信する送信装置と、
自装置が前記中継ポイントとして機能する場合に、他のオフロード装置から受信された前記アンカポイント情報を用いてオフロード対象のトラヒックを中継し、前記通信の終了時には、前記アンカポイントの設定を解除する制御装置とを含む
オフロード装置。（２）

（付記３） 前記制御装置は、前記通信の継続中に、オフロード対象のトラフィックに係る新たな通信が開始される場合には、自装置が前記新たな通信のアンカポイントとなるための前記アンカポイント情報を前記記憶装置に記憶する
付記２に記載のオフロード装置。（３）

（付記４） 前記通信がＴＣＰ通信である
付記２に記載のオフロード装置。

（付記５） 前記通信が、ＩＰマルチキャスト通信である
付記２に記載のオフロード装置。

（付記６） 移動局が接続可能な複数の基地局と、
前記複数の基地局を収容するコア網と、
前記複数の基地局と前記コア網との間に介在し、オフロード対象のトラヒックをオフロード網との間で送受信するアンカポイントとして機能する一方で、前記アンカポイントと前記移動局が接続中の前記複数の基地局の一つとの間で前記オフロード対象のトラヒックを中継する中継ポイントとして機能する複数のオフロード装置とを含むネットワークシステムにおいて、
前記各オフロード装置が、
前記移動局が自装置を介してオフロード対象のトラヒックの通信を開始する場合に、自装置に係る前記トラヒックの回線情報，前記通信の識別情報，及び前記トラヒックのアンカポイントの位置情報を含むアンカポイント情報を記憶装置に記憶し、
前記通信の継続中に、前記移動局のハンドオーバによって他のオフロード装置が前記中継ポイントとなる場合に、前記他のオフロード装置に前記アンカポイント情報を送信し、
自装置が前記中継ポイントとして機能する場合に、他のオフロード装置から受信された前記アンカポイント情報を用いてオフロード対象のトラヒックを中継し、前記通信の終了時には、前記アンカポイントの設定を解除する
ことを含むオフロードトラフィックの制御方法。（４）

１１・・・基地局
２０・・・ＥＰＣ網（コア網）
２２・・・Ｓ−ＧＷ（ゲートウェイ）
６０・・・移動局
７０・・・オフロードＧＷ（オフロード装置）
７１・・・回線インタフェース
７３・・・ＣＰＵ
７４・・・記憶装置

Claims (4)

1. 移動局が接続可能な複数の基地局と、
   前記複数の基地局を収容するコア網とと、
   前記複数の基地局と前記コア網との間に介在し、オフロード対象のトラヒックをオフロード網との間で送受信するアンカポイントとして機能する一方で、前記アンカポイントと前記移動局が接続中の前記複数の基地局の一つとの間で前記オフロード対象のトラヒックを中継する中継ポイントとして機能する複数のオフロード装置とを含み、
   前記各オフロード装置は、
   前記移動局が自装置を介してオフロード対象のトラヒックの通信を開始する場合に、自装置に係る前記トラヒックの回線情報，前記通信の識別情報，及び前記トラヒックのアンカポイントの位置情報を含むアンカポイント情報を記憶する記憶装置と、
   前記通信の継続中に、前記移動局のハンドオーバによって他のオフロード装置が前記中継ポイントとなる場合に、前記他のオフロード装置に前記アンカポイント情報を送信する送信装置と、
   自装置が前記中継ポイントとして機能する場合に、他のオフロード装置から受信された前記アンカポイント情報を用いてオフロード対象のトラヒックを中継し、前記通信の終了時には、前記アンカポイントの設定を解除する制御装置とを含む
   ネットワークシステム。
2. 移動局が接続可能な複数の基地局と、前記複数の基地局を収容するコア網との間に介在し、オフロード対象のトラヒックをオフロード網との間で送受信するアンカポイントとして機能する一方で、前記アンカポイントと前記移動局が接続中の前記複数の基地局の一つとの間で前記オフロード対象のトラヒックを中継する中継ポイントとして機能するオフロード装置であって、
   前記移動局が自装置を介してオフロード対象のトラヒックの通信を開始する場合に、自装置に係る前記トラヒックの回線情報，前記通信の識別情報，及び前記トラヒックのアンカポイントの位置情報を含むアンカポイント情報を記憶する記憶装置と、
   前記通信の継続中に、前記移動局のハンドオーバによって他のオフロード装置が前記中継ポイントとなる場合に、前記他のオフロード装置に前記アンカポイント情報を送信する送信装置と、
   自装置が前記中継ポイントとして機能する場合に、他のオフロード装置から受信された前記アンカポイント情報を用いてオフロード対象のトラヒックを中継し、前記通信の終了時には、前記アンカポイントの設定を解除する制御装置とを含む
   オフロード装置。
3. 前記制御装置は、前記通信の継続中に、オフロード対象のトラフィックに係る新たな通信が開始される場合には、自装置が前記新たな通信のアンカポイントとなるための前記アンカポイント情報を前記記憶装置に記憶する
   請求項２に記載のオフロード装置。
4. 移動局が接続可能な複数の基地局と、
   前記複数の基地局を収容するコア網と、
   前記複数の基地局と前記コア網との間に介在し、オフロード対象のトラヒックをオフロード網との間で送受信するアンカポイントとして機能する一方で、前記アンカポイントと前記移動局が接続中の前記複数の基地局の一つとの間で前記オフロード対象のトラヒックを中継する中継ポイントとして機能する複数のオフロード装置とを含むネットワークシステムにおいて、
   前記各オフロード装置が、
   前記移動局が自装置を介してオフロード対象のトラヒックの通信を開始する場合に、
   自装置に係る前記トラヒックの回線情報，前記通信の識別情報，及び前記トラヒックのアンカポイントの位置情報を含むアンカポイント情報を記憶装置に記憶し、
   前記通信の継続中に、前記移動局のハンドオーバによって他のオフロード装置が前記中継ポイントとなる場合に、前記他のオフロード装置に前記アンカポイント情報を送信し、
   自装置が前記中継ポイントとして機能する場合に、他のオフロード装置から受信された前記アンカポイント情報を用いてオフロード対象のトラヒックを中継し、前記通信の終了時には、前記アンカポイントの設定を解除する
   ことを含むオフロードトラフィックの制御方法。

Images