【文献】
Ericsson, ST-Ericsson, Qualcomm Incorporated,Single-scenario approach allowing IP-mobility extensions to rel-11[online], 3GPP TSG-SA WG2#98 S2-132604,<URL:http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_98_Valencia/Docs/S2-132604.zip>
(58)【調査した分野】(Int.Cl.,DB名)
【背景技術】
【0002】
従来のネットワーク (NW : Network)は、経路制御とパケット転送が一体で搭載されており、入力されてきたパケットのヘッダを見て、スイッチが転送先を自身で決定し、次のスイッチに転送する。このような転送方式では、各ネットワーク機器が自律的に通信を行なえるという特徴があり、経路制御を分散的に行なうというのは、耐障害性の高いネットワークを実現するTCP/IPネットワークの基本である。しかし、ネットワーク全体を俯瞰した柔軟な経路制御ができず、経路制御を行うためにネットワーク機器ごとに設定を施さなければならないという手間も生じる。
【0003】
従来のネットワーク機器では、レイヤー構造に転送制御を行なっていた。L2スイッチではMACアドレス、ルータはIPアドレス、ファイアウォールはTCP/UDPのポート番号などを元に各機器が転送制御を行っている。
【0004】
これに対してOpenFlow[非特許文献1]で用いられているフロー制御では、こうした各レイヤーのアドレスや識別子すべてを見てトラフィックを特定してアクションを実施する。アクションはユニキャスト、マルチキャスト、帯域制御、廃棄、負荷分散、障害回復、仮想ポートの転送制御などがある。また、OpenFlowでは専用コントローラーが経路制御を行ない、スイッチ側のパケット転送を一元的に制御するという中央集権型のアーキテクチャとなっている。経路制御を行なうOpenFlowのコントローラーは、負荷が集中させないようフロー単位で経路を最適化したり、障害時にはいち早く通信が回復するよう、経路を動的に変更する。そのため、既存のMAC/IPアドレスなどに加えて、物理ポートやレイヤ4のプロトコルなど、さまざまな制御情報を元にした「フローテーブル」を作成し、これをスイッチに伝搬する。
【0005】
モバイルコアネットワークシステムでは、常時移動する移動端末の接続位置を常に管理する方式が従来から知られている[非特許文献2]。
【0006】
従来技術の通信システムによる移動管理方法の構成図を
図14に示す。単一の移動管理制御装置(MME)701には複数の無線基地局(eNodeB)702が接続され、それぞれの無線基地局(eNodeB)702には、複数の無線端末が接続する。移動管理制御装置(MME)701は加入者情報データベース装置(HSS)703と接続する。また、無線基地局(eNodeB)702とS-GW(Serving Gateway)704が接続し実際のUプレーン(User plane)処理を行う。
【0007】
移動網のCプレーン(Control plane)処理については安価な汎用サーバ装置を利用して機能を実現し、スケールアウト技術、仮想化サーバ内の機能間のIF統合・機能の整理・統合による制御処理の効率化が検討されている。つまり、Cプレーン処理は汎用ハードウェア上で動作することによるスケールアウト、さらに既存機能の単純なソフト化だけでなく、ソフト化と同時に装置間IFを不要とするよう機能間の統合が検討されている。
【0008】
また、移動網のUプレーンについては現状ではGTP-U(GPRS (General Packet Radio Service) Tunneling Protocol for User Plane)処理は専用の装置/ソフトウェアで実現されており、GTP-CやGTP-Uの連携動作には専用の装置内IFが必要なため、Cプレーン同様に単純なスケールアウトはできない。つまり、装置ごと/装置内のIFで実現したものを仮想化サーバと連携する方向で検討されているが、ベンダや制御対象機能が変わるとIFが変わるため制御できない。
【発明を実施するための形態】
【0022】
本発明は、ネットワークの制御機能及び転送機能におけるCプレーン(経路制御)処理とUプレーン(パケット転送)処理を完全に分離するアーキテクチャを備えた通信方式及び通信システムの発明である。
【0023】
つまり本発明では、Cプレーン処理はサーバハードウェアを仮想化し、汎用サーバソフトウェア上で実現している。また、UプレーンはSDN(Software-Defined Networking )相当の低機能な転送フロースイッチ網で実現している。さらに、CプレーンとUプレーン間の連携機能をコントローラが行い、制御機能から受信した制御内容に必要な処理と対象装置を決定して、フローテーブルを更新することで、これまでのNW (Network)と同等の機能を維持しながら、新たなサービス追加に対応できるようにした。
【0024】
すなわち、本発明の通信システム1では
図1に示すように、Cプレーン処理2、Uプレーン処理3を完全に分離し、汎用転送ハード10に備わる複数のフロースイッチ11をコントローラ21を介して制御するアーキテクチャを採用し、かつCプレーン処理機能2については固定網と移動網の制御機能及び経路計算をすべて汎用的なハードウェアを用いた仮想化サーバ上で実現する。
【0025】
なお、サーバ仮想化(server virtualization)とは、周知のように、1台の物理的なサーバコンピュータを複数台の仮想的なコンピュータに分割し、それぞれに別のOSやアプリケーションソフトを動作させる技術である。これにより、プロセッサやメモリ、ディスクをまとめて仮想的に複数の領域に分割し、それぞれがあたかも1台のコンピュータであるかのように振る舞い、異なるOSやアプリケーションを同時に実行できる。また、物理的に複数のコンピュータを用意する場合に比べ、物理的資源の管理にかかる手間が省け、資源配分を需要に応じて柔軟に配分することができるという利点がある。
【0026】
したがって、サービス制御機能22、ネットワーク制御機能23は共通の汎用サーバハードウェア24,25上で動作し、必要な制御情報を仮想化サーバ間で交換し、必要なUプレーン処理をコントローラ21に指示することでサービス・機能を実現する。
【0027】
これによって、固定網と移動網との間で異なる機能は仮想化サーバ上で独立に実現し、物理的なサーバリソース及び転送リソースを共有し、必要なリソースを適宜割り当てて利用することが可能となる。従って、複数網間でCプレーン・Uプレーンのリソース利用効率の向上を図ることができる。
【0028】
上記のアーキテクチャによって、Cプレーン処理とUプレーン処理が分離して独立にリソース割り当てが可能となるため、いずれか一方がボトルネックとなることがなくなり、C/Uプレーンを独立にスケールアウトすることができる。
【0029】
また、固定網と移動網との間でそれぞれ専用の装置を利用せず、共通のハードウェアを利用して制御ソフトウェアの違いだけで、個々のサービスを実現することで、固定網及び移動網のリソース効率化を実現することができる。
【0030】
次に、本発明の第1実施例の通信システムを
図2を参照して説明する。
【0031】
図2に示すように、Cプレーン処理は汎用サーバで実現し、Uプレーンは汎用フロースイッチで実現する。なお、図中のサーバリソース4が汎用サーバ群であり、転送リソース5がネットワーク上で分散配置された汎用フロースイッチ群である。また、サービス制御系リソース6は固定・移動の転送系が共通化されている。
【0032】
さらに、本実施例では、サーバリソース(汎用サーバ群)の上に各制御機能を専用ハードを用いずに各制御機能間で共通のサーバリソースから必要なリソースを割り当てる。
【0033】
サーバリソース4、転送リソース5ともに個々の機能・サービスに特化した専用ハードウェアを使うのではなく、固定/移動の固有の機能やサービスに必要なソフトウェアを汎用サーバ上で動作させて個々のサービスに必要な機能を実現して、転送リソース5も固定・移動のサービスに必要なルーティング・スイッチング処理設定を共通の汎用ハードウェアにコントローラ21を介して投入することで、固定・移動系のサービスをサーバリソース4及び転送リソース5を共有しながら実現することができる。
【0034】
つまり、Cプレーン、サーバ処理を汎用サーバ化し、サービス/NW制御リソースに割り当てる。さらに、移動管理、トンネル制御、AAA、加入者DB等のNW制御機能は仮想化サーバ上で集中処理し、固定・移動で共通な機能は同一制御サーバを利用するとともに、QoS、DHCP、NAT、プロシキ、SIP等のサービス制御機能(セッション制御等)を固定・移動で共通化してサーバリソース利用効率を向上することができる。
【0035】
また、転送面は共通技術を利用して固定・移動のサービスに必要な転送リソースを動的に割り当て、固定・移動で共通の転送技術(共通転送網70)によりリソースを共用することで転送リソースの有効利用を図ることができる。
【0036】
このように本実施例においては、前述の特徴に基づき、固定サービスについては、必要となるIMS(IP Multimedia Subsystem )、トンネル制御、AAA(Authentication(認証)、Authorization(認可)、Accounting(アカウンティング))、加入者管理を汎用サーバリソース4から必要な分だけ固定系サービスに割り当て、そのうえで上記の機能を仮想化サーバベースで実現する。さらに、制御信号が適切に仮想化サーバにルーティングされるように制御信号用のフロースイッチング情報を必要な転送リソース5にコントローラ21を介して設定する。
【0037】
また、ユーザがネットワークに接続し、仮想IMS、AAAサーバとの認証を完了するとこの結果に基づいて、IMS, AAA等の制御サーバはコントローラ21にユーザパケットを適切にルーティングするためのフロー制御を要求する。
【0038】
これを受けて、コントローラ21を介して固定系サービスに必要なPPP、VoIPのパケットを適切なSIPサーバや他のネットワークにルーティングするためのフロー制御情報を必要な転送リソース5に追加することで、インターネットアクセス、音声サービスを実現する。
【0039】
移動サービスについても同様に移動サービスに必要となる移動管理、トンネル制御、AAA、加入者DBなどの制御サーバをサーバリソース4から必要なリソースを確保して、汎用サーバ上に仮想化サーバとして立ち上げる。さらに、制御信号が適切に仮想化サーバにルーティングされるように制御信号用のフロースイッチング情報を必要な転送リソース5にコントローラ21を介して設定する。
【0040】
また、移動端末がモバイルネットワークに接続、移動、通信する際には制御信号が上記サーバに送信され、その結果をもとにコントローラ21を介して汎用スイッチにユーザデータが適切にインターネットや相手端末に届くようにコントローラ21を介して制御する。
【0041】
これを受けて、コントローラ21が関係する転送リソース5を確保し、必要なフロー制御情報を投入することで、移動管理、ハンドオーバ、ベアラ制御を実現することができる。
【0042】
上記の構成により、固定・移動で共通なコントロールIFを介したC/Uプレーン分離型構成による独立なスケールアウトが可能となる。
【0043】
従来の3GPPのアーキテクチャではxGWのCプレーン及びUプレーンのリソースが一体実装されることで両者のバランスを柔軟に変更できないという課題があった。
【0044】
しかし、上記のように、本発明により、Cプレーン処理2は汎用サーバで実現し、Uプレーン3は汎用フロースイッチで実現するため、両者独立にスケールアウトが可能となる。また、サーバリソース4、転送リソース5が仮想化され、固定・移動機能に共通化されていることで、各固定・移動NW (Network)の加入者に単一の網で需要に応じて必要最低限のリソースを柔軟に割り当てることができる。これにより、サービスを提供できるためリソース利用効率を従来よりも向上させることができる。
【0045】
次に、本発明の第2実施例を
図3を参照して説明する。
【0046】
第2実施例では固定網と移動網における制御・転送プレーン技術を共通化したアーキテクチャの詳細を説明する。
【0047】
図3に示すように、第2実施例では固定網40と移動網50において共通の制御PF(platform )110と転送プレーン120を持つため制御信号プロトコルのインタワーク機能をソフトウェアで実現し、汎用ハードウェア上の共通プラットホーム上で実現可能となる。つまり、「エッジ制御」、「回線」、「変換GW」、「HSS」、「MME」、「EPC制御」等を共通制御PF110で行い、「エッジ」、「EPC」の転送を共通転送プレーン120にて行う。このように、技術を共通化することで各網固有機能・IFが不要になるとともに、インタワークもパラメータ間の重畳/変換で実現できるため連係機能を小規模に抑えることができる。これにより、専用装置が不要となりコストの低減につながる。
【0048】
また、共通転送プレーン120は共通転送網70全体をカバーするため固定網40及び移動網50のUプレーンプロトコル処理を行わず、汎用フロースイッチの機能で実現可能な必要最低限の処理が制御PF110から転送プレーン120に指示される。
【0049】
上記実施例のように本発明を適用することで、固定網40及び移動網50の連携機能をCプレーンのソフトウェア部分に閉じることができるため、従来に比べて連携に必要となる専用装置が不要となり、汎用サーバと汎用スイッチが利用できるためコストの低減につながる。このため、移動網40と固定網50の連携サービスの安価な実現が可能となる。さらに、技術を共通化することで各網固有機能・IFが不要になるとともに、インタワークもパラメータ間の重畳/変換で実現できるため連携機能を小規模に抑えることができる。
【0050】
これに対して
図4に示すような従来のWiFiオフロードのアーキテクチャでは、固定網40と移動網50との間で、認証・制御信号、Uプレーンパケットのプロトコル変換が必要となり、固定網40と移動網50の両NW (Network)のプロトコルに対応した変換GW(gateway)が必要となる。つまり、固定網の制御・移動網の制御機能すべてに対応し、かつ両機能をインタワーク(プロトコル変換、セッション状態管理連携)するGWが必要となる。このため、変換GW装置が複雑化し、高性能なハードウェア上に多くの機能が必要となり、かつ専用のハードウェアとなり高価になりやすい。
【0051】
このように、従来、固定網40と移動網50は各網の要件を満たす技術を利用して構成されてきたため、WiFiオフロードのように固定・移動の連携する場合、移動・固定両方の網の機能要件に対応したGWを配備する必要があり、中間のGW装置は高機能になりやすいという課題があった。
【0052】
しかし、上記のように本実施例によれば、双方の網に共通の技術を用いてその中で各網に必要な機能を構築することで、より簡易に連携機能が実現できるため、より少ない機能でWiFiオフロード機能を実現することができる。
【0053】
次に、本発明の第3実施例を説明する。
【0054】
第3実施例では固定網と移動網における制御・転送プレーン技術を共通化したWiFiオフロードの詳細な接続構成を説明する。
【0055】
図5に示すように、第3実施例ではSaMoGで必要となっているEAP-SIM/AKA認証処理及び移動認証サーバ接続はすべて汎用サーバ61上の共通制御プラットホーム上で実現される。
【0056】
各機能をソフトウェアベースで実現し、SaMoGとしての連携制御を行う機能を配備することで、WiFi接続する端末82の認証とアドレス割り当て、及びサービスへの通信路を設定する。この処理はすべて汎用サーバ61上のソフトウェア処理で行い、接続完了後のPDN(public data network:公衆データ網 )62へのスイッチング部分のみをコントローラ21を介して汎用フロースイッチ群(汎用スイッチ網(共通転送網)70)に指示することでWiFiを介した移動網サービスへの接続が実現される。
【0057】
このように本実施形態のNW (Network)構成法で実現した場合、固定網40を構成する複数のL2スイッチ(L2SW)41が配備されたL2レイヤの処理でPPP/PPPoE/GTP相当の機能を維持しつつ、汎用スイッチの利用によって安価にUプレーン機能を実現することができる。さらに、高機能処理(Cプレーン)は装置間IFを排除して仮想化サーバ内で集中処理することにより、共通転送網70(固定網40,移動網50)での状態管理を排除することができる。
【0058】
これに対して従来のSaMoGのアーキテクチャでは、
図6に示すように、複数の装置間で認証及びトンネル制御機能が分散しており、状態管理の制御を装置間で連携して実施している。
【0059】
すなわち、従来の移動固定連携アーキテクチャではWiFiで固定網40等から移動網50に接続するためには、EAP-SIM/AKAプロトコル終端と移動網50の認証サーバ接続、DHCPによるアドレス払い出し、GTPによる移動網との接続、および上記3つの機能の連携動作が装置内で必要となり、変換GW機能で多くの機能・処理を実施する必要がある。
【0060】
次に、本発明の第4実施例を説明する。
【0061】
第4実施例では、本発明を適用した上記実施形態におけるNW (Network)構成法を説明する。
【0062】
図7に示すように、第4実施例では、移動制御はGTP機能を転送レイヤの相当機能で代替してハンドオーバ等を実現する。例えば、タグベースのスイッチング等である。固定制御は制御面やISP(Internet Service Provider)ごとにVLANを構成する。
【0063】
すなわち、本実施例では、汎用スイッチ71(例えばVLAN Switch )を複数配備した汎用フロースイッチ網70(共通転送網)上にPPPoE、GTPトンネル相当の機能をフロー制御(VLANタグ制御等)により実現する。これによって、PPPoEやGTPのプロトコルヘッダ処理を簡略化しGW装置(BRAS、S/P-GW)のUプレーン処理負荷を低減する。
【0064】
また、本実施例では、固定端末81及び移動端末82はまず汎用サーバ61上の認証サーバ(LAC-RADIUS、MME・HSS)と通信し認証処理を行う。この際認証信号はあらかじめ、汎用スイッチ網(共通転送網70)において適切なサーバにルーティングされるようフロー制御情報(VLANタグ制御情報等)を投入しておく。
【0065】
次に、汎用サーバ61内の振り分け制御サーバ、MME・S/P-GWのGTP-C処理が、端末と適切なサービス網(ISP等)を接続するために必要なフロー制御を決定し、コントローラ(図示せず)に指示する。これには、端末ごとにサービスに接続するためのパスを制御するためにVLANタグ等を割り当てて用いることができる。
【0066】
このようにCプレーンとUプレーンを分離し、Cプレーンを集中制御して、Uプレーン処理を共通的に処理することにより、NW (Network)制御でハンドオーバを実現することで、セッション管理の信号量や、スループットの向上につながる可能性がある。
【0067】
これに対して従来の固定網及び移動網におけるインターネット接続と移動網の移動制御処理においては、移動端末の制御はS/P-GW-eNodeB間でGTPトンネルを生成し、端末の移動に合わせてEPSベアラコンテキストを更新してハンドオーバを行い、固定端末の制御はPPPoE、L2TP、PPPを組み合わせてNTE振り分けを実現している。
【0068】
すなわち、
図8に示すように、固定網40では固定端末81のインターネット接続のため、BRAS装置42まで各家庭からPPPoEトンネル接続45を行い、BRAS装置42がLAC-RADIUS43と連携動作して契約者の契約ISP63を判定する。このISP63が接続するNTE44に対してL2TP46で接続してL2の経路を構築し、各家庭が契約したISP63へ直接PPP接続することで、インターネットアクセスを実現している。
【0069】
また、移動端末82のインターネット接続のため、移動網50ではPDNと呼ばれるサービス網(ISP)62はP-GW51と接続する。移動端末82とPGW51間はGTPトンネル52によって接続し、端末の移動に合わせて信号をMME、S/P-GW間で送受信することでトンネル通信経路を適宜切り替えることでハンドオーバを実現している。この際、各移動端末82が利用しているGTPトンネル等の情報をCプレーンで認識するための情報がEPSベアラコンテキスト53と呼ばれ、MME、S/P-GWで管理してトンネル接続の状態を管理している。
【0070】
次に、本発明の本発明の第5実施例を説明する。
【0071】
第5実施例では、本発明を適用した上記実施形態における移動トンネル制御(ハンドオーバ等)について説明する。
【0072】
具体的に
図9を参照して、本発明を適用し、移動制御(ハンドオーバ等)を汎用サーバ、汎用スイッチ網上で実現する際の適用方式について説明する。
【0073】
汎用サーバ61上にMME64、S/P-GW65,66のGTP制御部分をソフトウェアとして配備し、これらと制御情報を交換し、汎用フロースイッチ網(共通転送網)70の汎用スイッチ71を制御するコントローラ21も配備する。
【0074】
移動端末82のISP網などのサービス網への接続ために、MME、S/P-GW(C)サーバ上でEPSベアラコンテキスト67を生成し、EPSベアラコンテキスト67を汎用ベアラ情報68に変換し、その情報をもとにコントローラ21へ指示することで汎用フロースイッチ網70上に通信路が設定される。このときの汎用ベアラ情報68としては、「ベアラID」、「L2タグ」、「無線ベアラID」、「端末IPアドレス」、「S1端点MAC」、「フレーム優先度」等がある。
【0075】
このベアラは汎用スイッチ上ではL2タグ情報をキーとして制御し、L2タグをベースとして各移動端末82に向けてパケットを転送する。つまり、汎用ベアラ情報68の「L2タグ」、「S1端点MAC」、「フレーム優先度」を主に使用してコントローラ21への制御指示を行う。
【0076】
移動端末82が別のeNodeBに移動すると、移動先のeNodeBが端末の移動を認識し、MME、S/P-GW間でS1端点のIPアドレス、すなわち移動先のeNodeBのIPアドレスを更新し、コントローラ21に対してフロー制御の更新を要求する。これを受けて、セッション情報変換処理を行い、当該IPアドレスに該当するMACアドレスを特定し、コントローラ21は移動前後に関係するスイッチ群に対してフローテーブルの更新をOpenflow等の汎用IFを介して実施する。
【0077】
上記第5実施例では、コントローラ21上でEPSベアラコンテキスト67を汎用ベアラ情報68に変換して汎用フロースイッチ網(共通転送網)70に指示することにより、既存技術GTPの機能を汎用スイッチの基本的な機能で代替することでコントローラ21が送信する信号を抑えることができる。
【0078】
これに対して従来技術の一例としては、
図10に示すように、GTP-U機能(GTP拡張209)を汎用スイッチ207上に実装し、ベアラ制御する方式(既存研究(エリクソン論文))が知られている。
【0079】
上記エリクソン論文に記載された技術では、汎用サーバ201上のMME202、S/P-GW(C)203,204をベースとして、コントローラ206を介して拡張したスイッチ群(207,222)にGTP-Uパケットの制御を行うよう専用の制御IFを介して指示する。このため、制御サーバ側のEPSベアラコンテキスト210は現在のEPCと共通の情報が使用でき、GTPトンネルID(TEID)をベースに移動端末82の通信路を識別し、制御することができる。EPSベアラコンテキスト205の情報としては、「ベアラID」、「GTPトンネルID」、「無線ベアラID」、「端末IPアドレス」、「S1端点のIPアドレス」、「QCI」等がある。
【0080】
しかし、上記方式では、汎用スイッチ207が具備する基本機能だけでは実現できず、拡張機能222を付加して移動体向けに拡張したスイッチが必要となるため、汎用スイッチ207よりも高機能化するためコストが上昇してしまう点が課題となる。
【0081】
次に、本実施形態の通信システムにおいて端末がハンドオーバを実施した場合の処理の流れを
図11を参照して説明する。なお、ここでは、端末がハンドオーバを実施したときの処理の流れを示す。また、eNodeB(evolved NodeB :基地局)をeNBと称する。
【0082】
UE(User Equipment :端末)301はMACアドレスがMAC1であるSource eNB(302)に接続しており、そのGTPトンネルIDはTEID1でTEID1の端点のアドレスはIP1であるとする。これをコントローラ(307)において、TEID1をL2タグ1に変換し、IP1をSource eNB(302)のMACアドレス(MAC1)に変換し、QCIをフレーム優先度に変換する。
【0083】
この変換データをもとに、フローが通過する汎用スイッチ群(図中は汎用スイッチ305)にはタグ1、宛先/送信元MACアドレスをマッチングルールとして、そのパケットに対するアクション(タグの付与/削除、どの物理ポートへ送信する)等のフロー制御ルールが設定されているものとする。
【0084】
UE(301)が移動して、Target eNB(303)に接続すると、UE(301)からTarget eNB(303)にハンドオーバ実施コマンドが送られ(S401)、Source eNB(302)からTarget eNB(303)にEPSベアラコンテキストが引き継がれる(S402)。
【0085】
この後、UE(301)からの上りデータトラヒックはTarget eNB(303)を介して汎用スイッチ網(305)を通り、インターネット等に送られる(S403,S404)。
【0086】
一方で、UE(301)への下りトラヒックはベアラの切り替えが必要となる。そこで、Target eNB(303)はTEID1のGTPトンネルがIP2のeNBに切り替わったことをMME(Mobility Management Entity)(304)に通知し(S405)、MME(304)はそれをS/P-GW(C)(306)に通知して各制御サーバのEPSベアラコンテキストを更新する(S406)。
【0087】
これが完了すると当該のEPSベアラコンテキスト情報を含むGTPフロー更新要求がコントローラ(307)に送信される(S407)。コントローラ(307)ではTEIDとIPアドレスの情報から、割り当てられたタグ情報を抽出し、汎用スイッチ群(305)に対してIPアドレスを更新するとともにIPアドレスに対応するMACアドレスを設定して、古いフロー制御情報を削除し、新しいマッチングルールとアクションの更新を要求する(S408)。
【0088】
これが完了するとコントローラ(307)からP-GW(C)(306)にGTPフローの更新が完了したことを通知し(S409)、ハンドオーバに伴うパス切り替えが完了したことがMME(304)を介してTarget eNB(303)に通知される(S410)。
【0089】
上記が完了すると下りトラヒックの経路が切り替わり、ハンドオーバ手続きが完了する。
【0090】
次に、
図12を参照して従来の通信システムにおいて端末がハンドオーバを実施するときの処理の流れを詳細に説明する。
【0091】
UE(311)はアドレスがIP1のSource eNB(312)に接続しており、そのGTPトンネルIDはTEID1でTEID1の端点のアドレスはIP1であるとする。コントローラ(317)はTEID1に対応したGTPヘッダ情報を汎用スイッチ(315)に送信し、仮想ポートを使ったGTPヘッダの付与。宛先eNBへパケットを転送するための物理ポートを設定しているものとする。
【0092】
UE(311)が移動して、Target eNB(313)に接続するとUE(311)からTarget eNB(313)にハンドオーバ実施コマンドが送られ(S501)、Source eNB(312)からTarget eNB(313)にEPSベアラコンテキストが引き継がれる(S502)。この後、UE(311)からの上りデータトラヒックはTarget eNB(313)を介して汎用スイッチ網(315)を通り、インターネット等に送られる(S503,S504)。
【0093】
一方で、UE(311)への下りトラヒックはベアラの切り替えが必要となる。そこで、Target eNB(313)はTEID1のGTPトンネルがIP2のeNBに切り替わったことをMME(314)に通知し(S505)、MME(314)はそれをS/P-GW(C)(316)に通知して各制御サーバのEPSベアラコンテキストを更新する(S506)。
【0094】
これが完了すると当該のEPSベアラコンテキスト情報を含むGTPフロー更新要求がコントローラ(317)に送信される(S507)。指定されたEPSベアラの情報からコントローラ(317)は関係する汎用スイッチ(315)内のフローテーブルとGTPカプセル化テーブルの更新・追加・削除を行う(S508,S509)。
【0095】
これが完了すると,GTPフロー制御更新完了をP-GW(C)(316)に通知し(S510)、パス切り替え完了をMME(314)経由でTarget eNB(313)に送信し(S511)、パスの切り替えが完了する。
【0096】
以上により、ハンドオーバ処理が完了する。
【0097】
次に、
図13を参照して、上記
図11を参照して説明した本実施形態の通信システムにおけるコントローラ307と汎用スイッチ305との間のコマンド発生数と、上記
図12を参照して説明した従来例の通信システムにおけるコントローラ317と汎用スイッチ315との間のコマンド発生数の詳細を説明する。
【0098】
図13において縦軸は1時間当たりのコマンド発生数を表す。また、(a)〜(l)のそれぞれが表すのは次の通りである。(a):Attach、(b):Detach、(c):位置登録(X-GW変更なし)、(d):位置登録(X-GW変更あり)、(e):ハンドオーバ(X-GW変更なし)、(f):ハンドオーバ(X-GW変更あり)、(g):PDNコネクション(追加)、(h):PDNコネクション(削除)、(i):PCRF起動のQoS設定、(j):網起動による無線リソース解放、(k):端末起動による無線リソース取得、(l):網起動による無線リソース取得。
【0099】
従来例の通信システムにおいては、(a)〜(l)のそれぞれの1時間当たりのコマンド数は、(a):0.2、(b):0.2、(c):8、(d):0.02、(e):20、(f):0.2、(g):0.2、(h):0.2、(i):0.2、(j):75、(k):20、(l):10であった。
【0100】
これに対して、本実施形態の通信システムにおいては、(a)〜(l)のそれぞれの1時間当たりのコマンド数は、(a):0.1、(b):0.1、(c):4、(d):0.01、(e):10、(f):0.1、(g):0.1、(h):0.1、(i):0.1、(j):60、(k):10、(l):5であった。
【0101】
このように本実施形態によれば、コントローラ307と汎用スイッチ305との間の1時間当たりのコマンド発生数は、従来例よりも約22%も減少している。
【0102】
上記のように本実施形態の通信システムによれば、ネットワークの制御機能及び転送機能におけるCプレーン、Uプレーン処理を完全に分離する構成をとり、Cプレーン処理の制御機能から受信した制御内容に応じて、必要な処理、対象装置を決定して、フローテーブルを更新しUプレーンの経路を設定しているので、従来の課題を解決することができる。