JP6747761B2 - 通信システム及び方法 - Google Patents

Description

本発明は、移動通信事業者ネットワーク／固定通信事業者ネットワークにおいてエッジコンピューティングサービスを提供する為の通信システムに関する。

将来、第５世代移動体通信システム(５Ｇ)の普及が期待されている。５Ｇの要件として低遅延/広帯域/高信頼通信が考えられており、その実現方式の一つとしてエッジコンピューティング技術が検討されている（非特許文献１参照）。エッジコンピューティングでは、従来はインターネット上に配備されたアプリケーション/ユーザデータを通信事業者ネットワークのアクセス近傍のエッジサーバに配備することで、端末〜アプリケーション間の通信距離の短縮化による低遅延通信と上位ネットワーク階梯の帯域削減による広帯域通信を実現する。

エッジコンピューティングの一例として、ＬＴＥ（Long Term Evolution）モバイル通信において、通常であればユーザ端末（ＵＥ：User Equipment）から中継ネットワークおよびコアネットワーク装置（ＥＰＣ：Evolved Packet Core）を介してインターネット上のクラウドサーバにアクセスさせるところを、基地局直上など中継ネットワークの途中で通信ベアラを終端させ、モバイル端末〜エッジサーバ間で通信させることが提案されている（非特許文献２及び３参照）。

これを実現するためには以下の技術を組み合わせる必要がある。
（１）ユーザ端末からの、通常であればコアネットワーク装置へ転送される通信パケットを中継ネットワークの途中で経路変更させ、コアネットワーク装置より手前のエッジサーバと疎通させる技術（Ｌｏｃａｌ Ｂｒｅａｋｏｕｔ）
（２）ユーザ（または特定アプリケーション）に対して、最適（例えば物理的に最も近い等）なエッジサーバを選択・通知する技術。
（３）上記（１）や（２）の処理を、既存ユーザ端末に大きな変更や負荷をかけずに実現するための技術

Y. C. Hu, 他4名, "Mobile Edge Computing - A key technology toward 5G", ISBN No. 979-10-92620-08-5, ETSI White Paper No.11, Sept. 2015. "Mobile-Edge Computing - Introductory Technical White Paper", ETSI, 2014年9月 "Local Breakout for Ultra-Low Latency Communications", 3GPP TSG-RAN WG3 #93, 22-26 August 2016 "Local IP Access and Selected IP Traffic Offload (LIPA-SIPTO)", 3GPP TR 23.829, Release 10 3 V10.0.1, 2011-10 Konstantions Samdanis, 他2名, "Traffic Offload Enhancements for eUTRAN", IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 14, NO. 3, THIRD QUARTER 2012 C. Contavalli, 他3名, "Client Subnet in DNS Queries", IETF RFC7871, 2017年1月, [online], [平成29年6月29日検索], インターネット<URL:https://tools.ietf.org/html/rfc7871>

上記（１）に関する従来の技術としては、ＬＩＰＡ（Local IP Access）やＳＩＰＴＯ（Selected IP Traffic Offload）がある（非特許文献４及び５参照）。

ＬＩＰＡは、ＮＡＴ（Network Address Translation）機能搭載のＨｏｍｅ ｅＮｏｄｅＢにより個人宅内やオフィス向けローカルネットワークのトラヒックをコアネットワークへ転送せずオフロードする技術である。しかし、ＬＩＰＡでは、装置設置個所近傍における固定的利用しかできないという課題がある。

また、ＳＩＰＴＯは、接続先ネットワークの識別子であるＡＰＮ(Access Point Name)や送受信パケットに含まれるデータ（５−ｔｕｐｌｅ等）を使用し、接続するサーバを選択する技術である。本来ＳＩＰＴＯはWi-Fiなど狭カバレッジのサービスをモバイルネットワークとの接続点であるローカルゲートウェイにルーティングすることを目的に設計されている為、ハンドオーバを含む広範囲エリアにわたる移動を伴っての利用には適していない。また、ステート管理は行われない為、障害発生時の耐障害性は低く、５Ｇの特徴である高信頼通信も実現困難である。なお、上記の「５−ｔｕｐｌｅ」とは、送信元／先ＩＰアドレス、送信元／先ポート番号、プロトコル番号の組である。

上記（２）に関する従来の技術としては、問い合わせ先ＤＮＳ（Domain Name System）に対して問い合わせ元のＩＰアドレス・サブネット情報等を伝達する技術がある（非特許文献６参照）。この技術では、権威ＤＮＳサーバに対するある同一の名前問い合わせに対して、問い合わせ元のＩＰアドレスによって異なるＩＰアドレスを返答できるようにすることにより、問い合わせ元端末にとって最適な（例：物理的距離の近い）コンテンツキャッシュサーバを利用させることができる。しかし、当該技術は、国レベルの粒度でのキャッシュサーバ割当（日本国内のユーザに対しては東京エリアのサーバを利用させる、等）には適しているが、ＩＰアドレスによってエリアを特定できない場合は有効でない為、市町村レベル、モバイル基地局カバーエリアレベルでのエッジサーバ割り当てには適さないという課題がある。

上記（３）に関する技術としては、通信事業者ネットワークからユーザ端末に対してネットワーク状態情報／エッジコンピューティングサービス提供可否情報等を提供するＡＰＩ（Application Programming Interface）を設け、エッジコンピューティングサービスを利用する為のエッジサーバをユーザ端末側からアクティブに探索させる方式が考えられる。しかし、新規のＡＰＩを定義・実装するなど、端末や基地局に大きな変更が必要である。また、端末に利用可能エッジサーバを探索させる為、端末に負荷がかかる。そして、モバイル端末／ＩｏＴ端末にとって、計算負荷や通信負荷の増大はバッテリー問題などデメリットとなる。

本発明は上記事情に鑑みてなされたものであり、その目的とするところは、従来技術およびそれらの単純な組み合わせでは解決できなかったエッジコンピューティングサービスの提供が可能な通信システム及び方法を提供することにある。

上記目的を達成するために、本願発明は、複数のネットワーク装置を備えるとともにそれぞれ何れかのネットワーク装置に接続した複数のエッジサーバを備えアクセスネットワークを介してユーザ端末を収容する中継ネットワークと、中継ネットワークと接続した外部ネットワークとを有する通信ネットワークにおいて、前記ユーザ端末の通信フローを前記中継ネットワークの途中でローカルブレークアウトさせて前記ユーザ端末と前記エッジサーバとの間で通信させるよう前記ネットワーク装置にルーティング指示を送信する管理ノードを備えたことを特徴とする。

より具体的には、前記中継ネットワークでは前記ユーザ端末の通信フローに係るパケットは前記ネットワーク装置間でカプセル化されて転送され、前記管理ノードは、前記ネットワーク装置及び前記エッジサーバの位置情報を含む前記中継ネットワークの構成情報を保持するネットワーク構成情報記憶部と、前記ユーザ端末の位置情報を取得するユーザ端末位置情報取得手段と、前記ネットワーク装置からネットワーク装置の状態情報を取得するネットワーク装置状態情報取得手段と、前記エッジサーバのリソース情報を取得するリソース情報取得手段と、前記ネットワーク構成情報、ユーザ端末の位置情報、ネットワーク装置の状態情報、及びエッジサーバのリソース情報の何れか又は任意の組み合わせに基づき、ユーザ端末の通信フローに割り当てるエッジサーバを算出する計算手段と、前記計算手段により算出された割当情報に基づき前記中継ネットワーク内の前記ネットワーク装置に対してカプセルヘッダの書き換え及びルーティングのルール設定を指示するルーティング指示手段とを備え、前記ネットワーク装置は、前記管理ノードからの指示情報に基づきルーティング処理を行うとともにカプセルヘッダを書き換える振り分け手段を備えたことを特徴とする。

本発明によれば、前述の従来技術およびそれらの単純な組み合わせでは解決できなかった、エッジコンピューティングサービスの提供が可能となる。また、本発明の構成・方法によれば、通常優先されるエッジサーバが故障・輻輳などによって使用不能となった場合に、ユーザ通信をバックアップのエッジサーバに誘導し、サービス提供を継続することができる。

本発明の通信の概要を示すネットワーク構成図 一実施形態に係る通信システムの全体構成図 管理ノードの機能ブロック図 ユーザ情報受付部で取得するデータの一例 管理系情報収集部で保持するデータの一例 ネットワーク構成情報ＤＢの保持データの一例 計算部の処理フロー ネットワーク装置の機能ブロック図 カプセルヘッダの書き換え処理の一例を説明する図 エッジサーバの機能ブロック図 実施例１に係る通信フロー 実施例２に係る通信フロー 実施例３に係る通信フロー 実施例３’に係る通信フロー

まず本発明に係る通信システムの概要について図１を参照して説明する。図１は本発明に係る通信システムの概要を示すネットワーク構成図である。

図１に示すように、ユーザ端末１は通信事業者ネットワーク２に収容されている。また通信事業者ネットワーク２はインターネット３に接続されている。通信事業者ネットワーク２は固定通信ネットワークであっても移動通信ネットワークであってもよい。インターネット３にはサーバ４が配置されており、このサーバ４にはユーザ端末１に対してサービスを提供するアプリケーション５が構成されている。通信事業者ネットワーク２にはエッジサーバ６が収容されている。

本発明では、ユーザ端末（または特定アプリケーション）１の通信フローごとにエッジサーバ６の割り当てを計算する計算部を備えた管理ノード７を提案する。エッジサーバ割り当て計算においては、通信事業者ネットワーク２を構成するネットワーク装置（図１では図示省略）やエッジサーバ６の輻輳・故障情報も加味される。

前記管理ノード７は、通信事業者ネットワーク２を構成するネットワーク装置群に対して、特定ユーザの特定アプリケーションに係る通信トラヒックの転送経路変更を指示する機能を備える。また、ネットワーク装置は、管理ノード７からの経路変更指示に従い、特定の通信に係るパケットの通信経路を変更する機能を備える。具体的には、通信事業者ネットワーク２内に形成されるトンネル８の経路を、インターネット３ではなくエッジサーバ６に向けて変更する機能を有する。エッジサーバ６にはサーバ４のアプリケーション５と同機能のアプリケーション９が構成されており、必要に応じて、サーバ４のアプリケーション５からデータやステータスの移行や同期処理が行われる。管理ノード７により通信経路変更指示の契機は、例えば、サーバ４からの通知による。

このような構成により、前述の従来技術およびそれらの単純な組み合わせでは解決できなかった、エッジコンピューティングサービスの提供が可能となる。また、本提案の構成・方法によれば、通常優先されるエッジサーバ６が故障・輻輳などによって使用不能となった場合に、ユーザ通信をバックアップのエッジサーバ６に誘導し、サービス提供を継続することができる。

以下に、本発明の一実施の形態に係る通信システムについて図面を参照して説明する。図２は本実施の形態に係る通信システムの全体構成図である。

本実施の形態に係る通信システムは、図２に示すように、ユーザ端末１と、アクセスネットワーク１０と、中継ネットワーク２０と、ＩＰネットワーク３０と、ポータルサーバ４０と、管理ノード５０とを含んで構成される。通信事業者ネットワークはアクセスネットワーク１０と中継ネットワーク２０を含んで構成される。

中継ネットワーク２０は、加入者のユーザ端末１に通信サービスを提供するためのネットワーク装置２１とエッジサーバ２５を含んで構成される。エッジサーバ２５は何れかのネットワーク装置２１に接続（収容）されている。ネットワーク装置２１自身がエッジサーバ２５を備えることもできる。なお、図２等では、必要に応じて、複数のネットワーク装置２１を個別に識別可能にするために参照符号の後ろに「−１１」などの枝番を付した。他の装置についても同様である。

ネットワーク装置２１は、通信事業者ネットワークにおいてユーザ端末１に通信サービスを提供するにあたって当該通信に係る通信パケットを外部ネットワークであるＩＰネットワーク３０に中継する機能を有する装置を意味する。

ネットワーク装置２１は、例えば通信事業者ネットワークが移動体通信ネットワークであるＬＴＥネットワークの場合、ｅＮｏｄｅＢ、モバイルバックホールを構成する装置、Ｓ−ＧＷ（Serving-Gateway）やＰ−ＧＷ（PDN(Packet Data Network)-Gateway）などＥＰＣを構成する装置のうちユーザデータ通信パケットの中継機能を有する装置が相当する。また、例えば通信事業者ネットワークが固定通信ネットワークである場合は、ユーザ端末１を収容する収容ルータや各種中継ルータなどが相当する。

中継ネットワーク２０上の通信パケットは、カプセル化され、所定のルールに従ってネットワーク装置２１間を転送される。すなわち、中継ネットワーク２０内にはネットワーク装置２１間にトンネルが形成され、ユーザ端末１の通信フローに係るパケットは、中継ネットワーク２０内においては前記トンネル内を通過する。

例えば前記中継ネットワーク２０がＬＴＥ移動体通信ネットワークのモバイルバックホールであれば、ＧＴＰトンネリングプロトコル（General Pack et Radio Service Tunneling Protocol）によりカプセル化されたユーザ通信パケットが、ＧＴＰヘッダの宛先・送信元ＩＰアドレスに基づいてネットワーク装置２１間を転送される。

また、例えば、前記中継ネットワーク２０がインターネットアクセスのための固定通信ネットワークであれば、ＰＰＰｏＥ（Point-to-Point Protocol over Ethernet）によってイーサネット上にカプセル化されたＰＰＰフレームの認証情報に従って、ユーザ端末１とユーザ加入ＩＳＰ（Internet Service Provider）との間で通信できるようにユーザ通信パケットがネットワーク装置２１間を転送される。

アクセスネットワーク１０は、ユーザ端末１を前記中継ネットワーク２０に収容するための装置群により構成されるものである。アクセスネットワーク１０は、例えば移動体通信ネットワークであれば無線区間・モバイルフロントホール・基地局等を含む。また、例えば、光固定通信ネットワークであれば、ＯＮＵ（Optical Network Unit）・光ファイバ・光スプリッタ・ＯＬＴ（Optical Line Terminal）・集約スイッチ等を含む。

ＩＰネットワーク３０は、中継ネットワーク２０との接続点および、ポータルサーバ４０との接続点を含む。他にも、例えば、他ＩＳＰ事業者との接続点や、クラウドサービス提供事業者ネットワークとの接続点を含んでいてもよい。

ポータルサーバ４０は、ＩＰネットワーク３０との接続点を備え、ユーザ端末１からのエッジサーバ利用リクエストまたは中継ネットワーク２０内折り返し通信リクエストおよび、ユーザ端末１の位置を特定する為の情報を受信する機能を有する。

また、ポータルサーバ４０は、アプリケーション作成者によって作成されたエッジサーバ利用アプリケーションの登録およびプログラムファイルアップロードを、ＩＰネットワーク３０を通じて受け付ける機能を備える。

また、ポータルサーバ４０は、中継ネットワーク２０内のエッジサーバ２５群との通信手段を有し、アプリケーション作成者によって登録・アップロードされたプログラムをユーザにサービス提供する為に必要なデータ（例：プログラムファイル、ＶＭ（Virtual Machine）、コンテナイメージ、ユーザデータ、等）を送信、変更、削除指示する機能を備える。

管理ノード５０は、ポータルサーバ４０および中継ネットワーク２０内のネットワーク装置２１群・エッジサーバ２５群との通信手段を有し、ポータルサーバ４０から受け取ったユーザリクエスト情報およびユーザ位置情報に基づいて、該ユーザに関する全通信または特定アプリケーション通信に係る転送ルール変更指示をネットワーク装置２１群に対して送信する機能および、ネットワーク装置２１群からネットワークの状態情報（帯域、遅延、パケロス、輻輳状況等）を取得する機能および、エッジサーバ２５群からリソース情報（ＣＰＵ使用率、メモリ使用量、ストレージ使用量、ＶＭ起動数、利用中ユーザ端末数等）を取得する機能を備える。

管理ノード５０の機能ブロック図を図３に示す。管理ノード５０は、上記機能を実現するため、ポータルサーバ接続部５１と、ユーザ情報受付部５２と、管理系情報収集部５３と、計算部５４と、ネットワーク構成情報データベース（ＤＢ）５５と、ネットワーク装置群管理ネットワーク接続部５６と、ルーティング情報変更指示部５７とを備える。

ユーザ情報受付部５２は、ポータルサーバ４０から受け取ったユーザリクエスト（エッジサーバ利用リクエスト、中継ネットワーク２０内折り返し通信リクエスト等）およびユーザ位置情報（移動体通信であれば基地局情報・ＧＰＳ情報等、光固定通信ネットワークであれば収容局情報・ＯＮＵの論理ＩＤ等）を格納し、計算部５４に情報を通知する機能を備える。ユーザ情報受付部５２で取得するデータの一例を図４に示す。取得データは、図４の例では、ユーザＩＤ，ユーザＩＰアドレス，ユーザ利用アプリ情報，ユーザ最寄りネットワーク装置２１（例えば移動体通信ネットワークの場合には基地局であるｅＮｏｄｅＢのＩＤ）、カプセルＩＤ（例えば移動体通信ネットワークの場合にはＧＴＰトンネルのＴＥＩＤ等）を含む。

管理系情報収集部５３は、ネットワーク装置２１群から受け取ったネットワークの状態情報（帯域、遅延、パケロス、輻輳状況等）やエッジサーバ２５群からリソース情報（ＣＰＵ使用率、メモリ使用量、ストレージ使用量、ＶＭ起動数、利用中ユーザ端末数等）を格納し、計算部５４に情報を通知する機能を備える。管理系情報収集部５３で保持する情報の一例を図５に示す。保持情報は、図５の例では、ネットワーク装置２１全体やそのポート毎の状態情報と、ＣＰＵ使用率やメモリ使用量などのリソース情報を保持する。

ネットワーク構成情報ＤＢ５５は、ネットワーク装置２１群・エッジサーバ２５群の位置関係を保有するデータベースであって、ネットワーク構成情報（地理情報、トポロジー）、中継ネットワーク内ルーティングルールを含む情報を保持する。図６にネットワーク構成情報ＤＢに保持された情報の一例を示す。保持情報は、図６の例では、列１としてネットワーク装置２１群のうちアクセスネットワーク１０に最も近いネットワーク装置２１のリストを含む。このリストに含まれるネットワーク装置２１は、例えば移動体通信ネットワークの場合には基地局であるｅＮｏｄｅＢが挙げられる。さらに保持情報は、列２として前記列１の各ネットワーク装置２１から最も近く且つエッジサーバ２５を備えた（エッジサーバ２５が接続された）ネットワーク装置２１のリストを含む。ここで、列２に含まれるネットワーク装置２１には、ネットワーク自身がエッジサーバ２５を備える場合には当該ネットワーク装置２１が含まれる。さらに保持情報は、例３として前記列２の次に優先されるネットワーク装置２１のリスト、例４として前記列３の次に優先されるネットワーク装置２１のリスト、…を含む。ここで、列３以降のリストに含まれるネットワーク装置２１は、前列のリストに含まれるネットワーク装置２１配下のエッジサーバ２５が機能しなかった場合のバックアップとなる。

計算部５４は、ユーザ情報受付部５２・管理系情報収集部５３・ネットワーク構成情報ＤＢ５５から受け取った情報に基づき、ユーザ端末１に利用させるエッジサーバ２５を決定する機能、もしくは、ユーザ端末１間の通信の中継ネットワーク２０内折り返し通信経路を決定し、中継ネットワーク２０内のネットワーク装置２１群に対するルーティング変更内容を算出する機能を備える。

計算部５４の動作の一例を図７のフローチャートに示す。計算部５４は、図７に示すように、ユーザからのリクエストがあると（ステップＳ１）、ネットワーク構成情報ＤＢ５５からネットワーク情報を取得する（ステップＳ２）。計算部５４は、繰り返し処理のために変数ｉに１をセットし（ステップＳ３）、ユーザリクエスト情報とネットワーク構成情報を照合し、該当行ｉ列目の情報に従い当該ユーザに割り当てるエッジサーバ２５（乃至それを収容しているネットワーク装置２１）を決定する（ステップＳ４）。次に、計算部５４は、管理系情報収集部５３から管理情報を取得し（ステップＳ５）、前記ステップＳ４で決定されたエッジサーバ２５や通信経路上に故障・輻輳等の問題があるかを判定する（ステップＳ６）。判定の結果、問題がある場合には、ネットワーク構成情報ＤＢ５５の表の該当行ｉ＋１列目に有効な情報が記載されているかを判定し（ステップＳ７）、記載がない場合には、ポータルサーバ４０及びユーザに対してエラーメッセージを返す（ステップＳ８）。記載がある場合には、変数ｉをインクリメントし（ステップＳ９）、前記ステップＳ４に処理を移す。前記ステップＳ６の判定の結果、問題がない場合には、ネットワーク装置２１群に対するルーティング変更リストを作成し（ステップＳ１０）、当該リストをルーティング情報変更指示部５７へ受け渡す（ステップＳ１１）。

ルーティング情報変更指示部５７は、前記計算部５４によって決定されたルーティング変更計画に従ってルーティング変更指示コマンドを生成し、ネットワーク装置２１群に対して前記コマンドを送信する機能を備える。

管理ノード５０は、中継ネットワーク２０の中にあっても外にあってもよいし、ポータルサーバ４０と一体であってもよい。管理ノード５０は、例えばＳＤＮ（Software Defined Network）コントローラのようなものであっても良いし、ネットワーク装置２１群に対してｔｅｌｎｅｔやｓｓｈ等によりコマンドを送出するサーバやコンピュータであっても良い。

以下の説明においては、便宜上、ユーザ端末１からＩＰネットワーク３０向きの通信を上り通信、ＩＰネットワーク３０からユーザ端末１向きの通信を下り通信と呼ぶこととする。また、便宜上、ネットワーク装置２１のアクセスネットワーク１０向きのポートを下流ポート、中継ネットワーク２０中枢方向のポートを上流ポートと呼ぶこととする。

図８にネットワーク装置２１の機能ブロック図を示す。ネットワーク装置２１は、図８に示すように、上流ポート２１１と、１つ又は複数の下流ポート２１２、エッジサーバ接続部２１３と、管理ネットワーク接続部２１４と、振り分け部２１５と、ルーティング情報データベース２１６と、ネットワーク情報収集部２１７を含む。

ネットワーク情報収集部２１７は、ネットワーク装置２１内の各ポート（上流ポート２１１、下流ポート２１２、エッジサーバ接続部２１３）から得られた帯域、遅延、パケットロス、輻輳状況等の情報を、管理ネットワーク接続部２１４を経由して管理ノード５０に送信する機能を有する。

ルーティング情報データベース２１６は、ルーティングテーブルと、振り分け部２１５に対してルーティングルールを通知する機能と、管理ノード５０から受け取ったルーティング変更コマンドに基づいてルーティングテーブルを更新する機能を有する。

振り分け部２１５は、ルーティング情報ＤＢ２１６から提供されるルーティングルールにしたがって、通信パケットを各ポートから各ポートへ振り分ける機能を有する。なお、ここでの振り分けには同一ポートへの折り返しも含む。

また、振り分け部２１５は、ルーティング情報ＤＢ２１６から提供されるルーティングルールにしたがって、特定ユーザ端末１の通信パケット（一部または全部）をエッジサーバ接続部２１３へ振り分ける機能を有する。

また、振り分け部２１５は、ルーティング情報ＤＢ２１６から提供されるルーティングルールにしたがって、一の下流ポート２１２から受け取った特定ユーザ端末１からの通信パケットを、別（または同一）の下流ポート２１２に振り分ける機能を有する。

また、振り分け部２１５は、カプセル化ヘッダを書き換える機能を有する。この書き換え処理については後述する。

また、振り分け部２１５は、カプセル化ヘッダの宛先が自機であった場合に、カプセル化を解除されたＩＰパケットを所定のポートから送出する機能を有する。

以下に、パケット振り分け部２１５によるパケット書き換えの具体例を図９を参照して説明する。ここでは一例として、通信事業者ネットワーク２が移動体通信ネットワークの一種であるＬＴＥネットワークであり、ユーザ最寄りのネットワーク装置２１が「基地局（ｅＮｏｄｅＢ）」であり、ユーザ最寄りのエッジサーバ２５がＭＥＣサーバ（１）」であり、ＭＥＣサーバ（１）を収容するネットワーク装置２１が「ＭＥＣルータ（１）」であり、 ネットワーク装置２１のうち最上流（ＩＰネットワークとの境界に位置する）の装置が「Ｓ−ＧＷ」であるものとして説明する。

図９中、送信元ＩＰアドレスを「Ｓ−ＩＰ（Source IP）」と表記し、宛先ＩＰアドレスを「Ｄ−ＩＰ（Destination IP）」と表記する。また図中、ＴＥＩＤ（Tunnel Endpoint IDentifier）は、ＧＴＰトンネルの各セッション（ユーザやアプリケーションごとの通信フロー）を識別するための記号番号を意味する。

図９に示すように、通常（エッジサーバ利用無し）時であれば、ＧＴＰパケットヘッダとして一律「Ｓ−ＩＰ＝ｅＮｏｄｅＢ，Ｄ−ＩＰ＝Ｓ−ＧＷ」と付与される。本発明では、当該パケットヘッダ部分を、「Ｓ−ＩＰ＝ｅＮｏｄｅＢ，Ｄ−ＩＰ＝ＭＥＣルータ（１）」に置換することにより、上り信号がＳ−ＧＷへ向かわずＭＥＣルータ（１）へ向かう。ユーザ識別にはＴＥＩＤやＩＰヘッダの送信元ＩＰアドレス等を利用する。

図１０にエッジサーバ２５の機能ブロック図を示す。エッジサーバ２５は、図１０に示すように、ネットワーク装置接続部２５１と、管理系ネットワーク接続部２５２と、サーバリソース情報収集部２５３と、パケット振り分け部２５４と、仮想マシンネットワークＬ２分離部２５５と、仮想マシン２５６とを含む。

サーバリソース情報収集部２５３は、エッジサーバ２５のリソース情報（ＣＰＵ使用率、メモリ使用量、ストレージ使用量、ＶＭ起動数、利用中ユーザ端末数等）を収集し、管理系ネットワーク接続部２５２を通して管理ノード５０へ通知する機能を備える。

パケット振り分け部２５４は、ネットワーク装置２１から渡されたユーザ端末パケットをエッジサーバ２５内の各仮想ネットワークに振り分けるルーティング機能を備える。

仮想マシンネットワークＬ２分離部２５５は、例えばＶＬＡＮ（Virtual Local Area Network）等により、異なるＩＰアドレス空間に属する仮想マシン２５６を分離する機能を備える。

仮想マシン２５６は、ポータルサーバ４０から引き継いだデータやセッション情報に基づいて、ユーザ端末１に対してアプリケーションサービスを提供する機能を備える。

なお、前述したように、エッジサーバ２５とネットワーク装置２１が一体となっていてもよい。例えば、ＧＴＰトンネルの開始点／終端点としての機能がエッジサーバ２５内に置かれる場合などが挙げられる。

次に、本実施の形態に係る通信システムを用いたエッジコンピューティングを実現するための通信フローについて説明する。まず図１１を参照して実施例１に係る通信フローを説明する。なお、以下で説明する各実施例では通信事業者ネットワークとして移動体通信ネットワークの場合について説明する。

［実施例１］
本実施例１の係る通信フローは、ユーザ端末１を、ポータルサーバ４０と同じＩＰアドレスでエッジサーバ２５−１と通信させるパターンである。この場合、エッジサーバ２５−２には、クラウド上のポータルサーバ４０（例えばＷｅｂアプリケーションサーバ）と同じＩＰアドレスを付与しておく。そして、トンネリング中継ネットワーク２０のルーティングを変更し、（当該ユーザ端末１の当該アプリケーションパケットのみ）ローカルブレークアウトさせる。これにより、ユーザから見ると、クラウド上のＷｅｂアプリケーションを利用している状態と変わらないように見せることができる。本実施例１は例えば、エッジサーバ２５においてユーザの仮想デスクトップ環境を備えたＶＭが格納・実行され、ユーザ端末１をシンクライアント端末としてエッジサーバ２５内仮想デスクトップ環境にリモートアクセスさせるようなユースケースが想定されるが、他のユースケースに適用することもできる。

本実施例１の具体的シーケンスは、図１１に示すように、エリア１に在圏しているユーザ端末１は、アプリケーションからサービスを受けるに際して、ＤＮＳサーバ３５に対してＦＱＤＮ（Fully Qualified Domain Name）名の名前解決要求を送信すると、ポータルサーバ４０のＩＰアドレスが回答されるので、ポータルサーバ４０に対してサービス開始要求や位置情報等を通知する（ステップＳ１１〜Ｓ１３）。ポータルサーバ４０は、エッジサーバ利用開始通知及び最寄りエッジサーバ問合せを管理ノード５０に送信する（ステップＳ１４）。管理ノード５０は、ネットワーク構成情報ＤＢ５５を参照して利用させるエッジサーバを決定し（ステップＳ１５，Ｓ１６）、中継ネットワーク２０内の各ネットワーク装置２１に対してルーティング変更指示を送信する（ステップＳ１７）。

また、管理ノード５０は、エッジサーバを選定した旨の通知をポータルサーバ４０に送信する（ステップＳ１８）。ポータルサーバ４０は、選定されたエッジサーバ２５−２に対して、データやステータスの引き継ぎ情報を送信する（ステップＳ１９）。選定されたエッジサーバ２５−２は、ユーザ端末１に対してエッジサーバ利用開始通知を送信する（ステップＳ２０）。

前記ステップＳ１７でルーティング変更指示を受信したネットワーク装置２１のうち、アクセスネットワーク１０を介してユーザ端末１を収容し、中継ネットワーク２０内で生成するトンネルの始点となるもの（図１１ではｅＮｏｄｅＢであるネットワーク装置２１−１）は、トンネルプロトコルのヘッダのうち宛先アドレスを、選定されたエッジサーバ２５−２が収容されているネットワーク装置２１−２のＩＰアドレスに書き換える。これにより、ユーザ端末１は選定されたエッジサーバ２５−２と通信を行う（ステップＳ２１）。

通信を終了する場合、ユーザ端末１はエッジサーバ２５−２に終了要求を送信すると、エッジサーバ２５−２はポータルサーバ４０を介して管理ノード５０に終了通知を送信する（ステップＳ２２〜Ｓ２４）。また、エッジサーバ２５−２はポータルサーバ４０に対してデータ引き継ぎに係る情報を送信する（ステップＳ２５）。管理ノード５０はポータルサーバ４０を介してエッジサーバ２５−２に終了承認を通知し、エッジサーバ２５−２はユーザ端末１に終了通知を送信する（ステップＳ２６〜Ｓ２８）。さらに、管理ノード５０は、中継ネットワーク２０内の各ネットワーク装置２１に対してルーティング変更指示を送信する（ステップＳ２９）。なお、アプリケーションによっては、前記ステップＳ２５のデータ引き継ぎ処理を省略することができる。

［実施例２］
次に、図１２を参照して実施例２に係る通信フローを説明する。本実施例２に係る通信フローは、エッジサーバ専用ＩＰアドレスを用いるパターンである。

各エッジサーバ２５には、トンネリング中継ネットワーク２０内で固有のＩＰアドレス（ネットワークアドレス）を割り当てる。このＩＰアドレスは、ポータルサーバ４０とは異なるものである。また、このＩＰアドレスは、ユーザ端末１側にプライベートアドレスのＬＡＮが存在してアドレス重複が発生することがある場合を考慮すると、グローバルアドレスを付与すると好適であるが、プライベートアドレスを付与することもできる。また、中継ネットワーク２０の各ネットワーク装置２１には、固定的なルーティング設定を予め設定しておく。この固定的なルーティング設定は、管理ノード５０からのルーティング変更指示により行われる。なお、本実施例２のユースケースは、前記実施例１と同様、シンクライアントアプリケーション等が想定されるが、他のユースケースに適用することもできる。

本実施例２の具体的シーケンスについて図１２を参照して説明する。なお、本実施例２では、ポータルサーバ４０と管理ノード５０が一体となっている例を示す。また、図１２では中継ネットワーク２０内におけるユーザ端末１を収容し、中継ネットワーク２０内で生成するトンネルの端点となるネットワーク装置２１であるｅＮｏｄｅＢについては図示を省略した。

エリア１に在圏しているユーザ端末１は、図１２に示すように、アプリケーションからサービスを受けるに際して、ＤＮＳサーバ３５に対してＦＱＤＮ名の名前解決要求を送信すると、ポータルサーバ４０のＩＰアドレスが回答されるので、ポータルサーバ４０に対してサービス開始要求や位置情報等を通知する（ステップＳ３１〜Ｓ３３）。ポータルサーバ４０は、前記第１の実施の形態と同様の処理により、ネットワーク構成情報ＤＢ５５を参照して利用させるエッジサーバを決定する（ステップＳ３４，Ｓ３５）。ポータルサーバ４０は、前記第１の実施の形態と同様に、選定されたエッジサーバ２５−１に対して、データやステータスの引き継ぎ情報を送信する（ステップＳ３６）。また、ポータルサーバ４０は、ユーザ端末１に対して、選定されたエッジサーバ２５−１に割り当てられているＩＰアドレスを送信する（ステップＳ３７）。

ユーザ端末１は選定されたエッジサーバ２５−１と通信を行う（ステップＳ３８）。ここで、アクセスネットワーク１０を介してユーザ端末１を収容し、中継ネットワーク２０内で生成するトンネルの端点となるネットワーク装置２１（図１２では図示省略）は、トンネルプロトコルのヘッダのうち宛先アドレスを、選定されたエッジサーバ２５−１が収容されているネットワーク装置２１−１のＩＰアドレスに書き換える。これにより、ユーザ端末１と、選定されたエッジサーバ２５−１との通信が可能になる。通信終了のフローについては、第１の実施の形態と同様である（ステップＳ３９〜Ｓ４３）。

本実施例２では、前記実施例１と比較して、通信経路変更指示の制御フローが削減できるというメリットがある。反面、エッジサーバ２５（更にはその中のＶＭや個別アプリ）の数だけ、グローバルＩＰアドレスの割当や管理が必要となるというデメリットがある。

［実施例３］
次に、図１３を参照して実施例３に係る通信フローを説明する。本実施例３に係る通信フローは、固定的にエッジサーバを割り当てるパターンである。本実施例３では、各ネットワーク装置２１には、固定的にルーティングルールを予め付与する。この固定的なルーティング設定は、管理ノード５０からのルーティング変更指示により行われる。

本実施例３では、ユーザ端末１がどこに在圏していても、各エッジサーバ２５で共通の特定の固定ＩＰアドレスに対して通信しに行くが、在圏エリアごとに最寄りの何れかのエッジサーバ２５にローカルブレークアウトされる。すなわち、この固定ＩＰアドレスは、特定のエッジサーバ２５のＩＰアドレスを具体的に示すものではなく、エッジサーバ２５群のうちのどれかであることを抽象的に示す識別子として機能するものである。本実施例３のユースケースは、逐次処理系ユースケース向け、大量設置型ＩｏＴ向けであるが、他のユースケースに適用することもできる。

また、本実施例３では、ローカルブレークアウト方法のシンプルさを優先し、ポータルサーバ４０とエッジサーバ２５間のデータ引継ぎは行わないことを想定する。より具体的には、大量設置型ＩｏＴ端末において、カメラやセンサから得られたデータの計算処理（統計計算、有用データ選別、不要データ選別削除等）を、端末ＣＰＵの代わりにエッジサーバを用いて処理させる類のアプリケーションを想定する。

本実施例３の具体的シーケンスを図１３に示す。エリア１に在圏しているユーザ端末１−１は、図１３に示すように、アプリケーションからサービスを受けるに際して、ＤＮＳサーバ３５に対してＦＱＤＮ名の名前解決要求を送信すると、エッジサーバ２５共通の固定ＩＰアドレスが回答される（ステップＳ５１，Ｓ５２）。ユーザ端末１−１は、前記固定ＩＰアドレスに対して通信パケットを送出する（ステップＳ５３）。ここで、アクセスネットワーク１０を介してユーザ端末１−１を収容し、中継ネットワーク２０内で生成するトンネルの端点となるネットワーク装置２１（図１３ではｅＮｏｄｅＢ（１）であるネットワーク装置２１−１）には、前記固定ＩＰアドレス宛ての通信パケットをカプセル化する際に、トンネルプロトコルのヘッダのうち宛先アドレスを、エッジサーバ２５−３が収容されているネットワーク装置２１−３のＩＰアドレスとするルールが予め管理ノード５０によって設定されている。これにより、ユーザ端末１−１とエッジサーバ２５−３との通信が可能になる。

本実施例３では、図１３に示すように、ユーザ端末１がどのエリアに在圏している場合においても共通の固定ＩＰアドレスに対して通信を行おうとするが、ユーザ端末１がエリア１（例えばｅＮｏｄｅＢ（１）配下）に在圏している場合はエッジサーバ（１）と、エリア２（例えばｅＮｏｄｅＢ（２）配下）に在圏している場合はエッジサーバ（２）と疎通する点に留意されたい（ステップＳ５１〜Ｓ５９参照）。

［実施例３’］
次に、図１４を参照して実施例３’に係る通信フローを説明する。本実施例は、前記実施例３において、固定的に割り当てられているエッジサーバが混雑又は故障していた場合の通信フローである。本発明では、ネットワーク装置２１・エッジサーバ２５の混雑・故障状況により、通常使用されるプライマリのエッジサーバ２５ではなく、予備的なセカンダリのエッジサーバ２５へ疎通させる。

本実施例３’の具体的シーケンスを図１４に示す。前記実施例３と同様の処理手順により、エリア１に在圏しているユーザ端末１−１は、エッジサーバ２５−３との通信を行っているものとする（ステップＳ６１〜Ｓ６３）。ただし、ＤＮＳサーバ３５からの名前解決応答には、固定的に割り当てられたプライマリのエッジサーバ２５−３の固定ＩＰアドレスとともに、固定的に割り当てられた予備的なセカンダリのエッジサーバ２５−４の固定ＩＰアドレスを含む。なお、中継ネットワーク２０内の各ネットワーク装置２１は、予め、管理ノード５０からの指示により、セカンダリのエッジサーバ２５−４の固定ＩＰアドレスでアクセスがあった場合のルーティングについても固定的に設定されているものとする。

ここで、プライマリのエッジサーバ２５−３又は当該エッジサーバ２５−３が収容されているネットワーク装置２１−３に混雑又は故障が発生したものとする。ユーザ端末１−１は、当該混雑又は故障の発生を検出すると、宛先ＩＰアドレスをプライマリのエッジサーバ２５−３の固定ＩＰアドレスからセカンダリのエッジサーバ２５−４の固定ＩＰアドレスに切り替えて以降の通信を行う（ステップＳ６４〜Ｓ６６）。なお、図１４に示すように、エリア２に在圏しているユーザ端末１−２の通信には影響はない（ステップＳ６７〜Ｓ６９）。

他のパターンとしては、エッジサーバ２５−３又は当該エッジサーバ２５−３が収容されているネットワーク装置２１−３に混雑又は故障が発生したときのみ、前記実施例１や実施例２と同様に、管理ノード５０から中継ネットワーク２０の各ネットワーク装置２１に対してルーティング変更指示を行い、エリア１に在圏するユーザ端末１−１がセカンダリのエッジサーバ２５−４にアクセスできるようにする方法も考えられる。なおこの場合、前記実施例１や実施例２と相違する点は、あくまでユーザ端末１−１からは、ある固定的なＩＰアドレスに対してアクセスしようとする点である。

以上、本発明の実施の形態について詳述したが本発明はこれに限定されるものではない。例えば、上記実施例では通信事業者ネットワークとして移動体通信ネットワークの場合について例示したが、固定通信ネットワークであってもよい。また、上記実施の形態で挙げた移動体通信ネットワークの規格や固定通信ネットワークの規格は一例であり、他の規格の通信ネットワークであっても本発明を適用できる。

また、上記実施例１及び実施例２では、ポータルサーバ４０とエッジサーバ２５との間でデータ引き継ぎを行う例を示したが、ユースケースによってはデータ引き継ぎを省略することもできる。同様に、上記実施例３及び３’では、ポータルサーバ４０とエッジサーバ２５との間でデータ引き継ぎを行わない例を示したが、ユースケースによってはデータ引き継ぎを実施することもできる。

１…ユーザ端末
２…通信事業者ネットワーク
３…インターネット
４…サーバ
５，９…アプリケーション
６…エッジサーバ
７…管理ノード
８…トンネル
１０…アクセスネットワーク
２０…中継ネットワーク
２１…ネットワーク装置
２１１…上流ポート
２１２…下流ポート
２１３…エッジサーバ接続部
２１４…管理ネットワーク接続部
２１５…振り分け部
２１６…ルーティング情報
２１７…ネットワーク情報収集部
２５…エッジサーバ
２５１…ネットワーク装置接続部
２５２…管理系ネットワーク接続部
２５３…サーバリソース情報収集部
２５４…パケット振り分け部
２５５…仮想マシンネットワークＬ２分離部
２５６…仮想マシン
３０…ＩＰネットワーク
４０…ポータルサーバ
５０…管理ノード
５１…ポータルサーバ接続部
５２…ユーザ情報受付部
５３…管理系情報収集部
５４…計算部
５５…ネットワーク構成情報データベース
５６…ネットワーク装置群管理ネットワーク接続部
５７…ルーティング情報変更指示部

Claims (8)

1. 複数のネットワーク装置を備えるとともにそれぞれ何れかの前記ネットワーク装置に接続した複数のエッジサーバを備えアクセスネットワークを介してユーザ端末を収容する中継ネットワークと、中継ネットワークと接続した外部ネットワークとを有する通信ネットワークにおいて、
   前記ユーザ端末の通信フローを前記中継ネットワークの途中でローカルブレークアウトさせて前記ユーザ端末と前記エッジサーバとの間で通信させるよう前記ネットワーク装置にルーティング指示を送信する管理ノードを備えた
   ことを特徴とする通信システム。
2. 前記中継ネットワークでは前記ユーザ端末の通信フローに係るパケットは前記ネットワーク装置間でカプセル化されて転送され、
   前記管理ノードは、
   前記ネットワーク装置及び前記エッジサーバの位置情報を含む前記中継ネットワークの構成情報を保持するネットワーク構成情報記憶部と、
   前記ユーザ端末の位置情報を取得するユーザ端末位置情報取得手段と、
   前記ネットワーク装置からネットワーク装置の状態情報を取得するネットワーク装置状態情報取得手段と、
   前記エッジサーバのリソース情報を取得するリソース情報取得手段と、
   前記ネットワーク構成情報、ユーザ端末の位置情報、ネットワーク装置の状態情報、及びエッジサーバのリソース情報の何れか又は任意の組み合わせに基づき、ユーザ端末の通信フローに割り当てるエッジサーバを算出する計算手段と、
   前記計算手段により算出された割当情報に基づき前記中継ネットワーク内の前記ネットワーク装置に対してカプセルヘッダの書き換え及びルーティングのルール設定を指示するルーティング指示手段とを備え、
   前記ネットワーク装置は、前記管理ノードからの指示情報に基づきルーティング処理を行うとともにカプセルヘッダを書き換える振り分け手段を備えた
   ことを特徴とする請求項１記載の通信システム。
3. 前記管理ノードは、前記ユーザ端末からの前記外部ネットワーク宛ての通信要求に対して、前記エッジサーバの割り当て処理及び前記ネットワーク装置へのルーティング指示処理を行う
   ことを特徴とする請求項２記載の通信システム。
4. 前記エッジサーバには予め固定アドレスを割り当てておき、
   前記管理ノードは予め前記ネットワーク装置へのルーティング指示処理を行い、前記ユーザ端末からの前記外部ネットワーク宛ての通信要求に対して、前記エッジサーバの割り当て処理を行うとともに割り当てたエッジサーバの固定アドレスを前記ユーザ端末に通知する
   ことを特徴とする請求項２記載の通信システム。
5. 前記各エッジサーバには予め共通の固定アドレスを割り当てておき、
   前記管理ノードは、前記共通の固定アドレスに対する通信パケットが、ユーザ端末の在圏エリアごとに異なるエッジサーバへローカルブレークアウトされるよう前記ネットワーク装置へのルーティング指示処理を予め行い、
   前記ユーザ端末からの名前解決要求に対して前記エッジサーバ共通の固定アドレスを回答する名前解決サーバを備えた
   ことを特徴とする請求項２記載の通信システム。
6. 前記管理ノードは、前記ユーザ端末が通信中の前記エッジサーバ又は当該エッジサーバが収容されている前記ネットワーク中継装置の混雑・故障状況に応じて、前記ユーザ端末の通信相手先を他のエッジサーバに切り替えるようルーティング指示処理を行う
   ことを特徴とする請求項２乃至５何れか１項記載の通信システム。
7. 前記名前解決サーバは、第１のエッジサーバに係る第１の固定アドレスと第２のエッジサーバに係る第２の固定アドレスとを前記ユーザ端末に回答し、
   前記ユーザ端末は、通信中の前記第１のエッジサーバ又は当該第１のエッジサーバが収容されている前記ネットワーク中継装置の混雑・故障状況に応じて、通信相手先を前記第２のエッジサーバに切り替える
   ことを特徴とする請求項５記載の通信システム。
8. 複数のネットワーク装置を備えるとともにそれぞれ何れかのネットワーク装置に接続した複数のエッジサーバを備えアクセスネットワークを介してユーザ端末を収容する中継ネットワークと、中継ネットワークと接続した外部ネットワークとを有する通信ネットワークにおいて、
   前記通信ネットワークに配置した管理ノードが、前記ユーザ端末の通信フローを前記中継ネットワークの途中でローカルブレークアウトさせて前記ユーザ端末と前記エッジサーバとの間で通信させるよう前記ネットワーク装置にルーティング指示を送信するステップを備えた
   ことを特徴とする通信方法。

Images