図面 (/)

技術 通信システム及び方法

出願人 日本電信電話株式会社
発明者 玉置真也岩澤宏紀徳永和宏高谷直樹
出願日 2017年8月25日 (2年10ヶ月経過) 出願番号 2017-162449
公開日 2019年3月14日 (1年3ヶ月経過) 公開番号 2019-041266
状態 未査定
技術分野 広域データ交換
主要キーワード シンクライアントアプリケーション データ引継ぎ 光固定 上流ポート 下流ポート ルーティング指示 ポート番 引き継ぎ情報
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2019年3月14日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (15)

課題

従来技術およびそれらの単純な組み合わせでは解決できなかったエッジコンピューティングサービスの提供が可能な通信ステム及び方法を提供する。

解決手段

複数のネットワーク装置21を備えるとともにそれぞれ何れかのネットワーク装置21に接続した複数のエッジサーバ25を備えアクセスネットワーク10を介してユーザ端末1を収容する中継ネットワーク20と、中継ネットワーク20と接続した外部ネットワーク30とを有する通信ネットワークにおいて、前記ユーザ端末1の通信フローを前記中継ネットワーク20の途中でローカルブレークアウトさせて前記ユーザ端末1と前記エッジサーバ25との間で通信させるよう前記ネットワーク装置21にルーティング指示を送信する管理ノード50を備えた。

概要

背景

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

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

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

概要

従来技術およびそれらの単純な組み合わせでは解決できなかったエッジコンピューティングサービスの提供が可能な通信システム及び方法を提供する。複数のネットワーク装置21を備えるとともにそれぞれ何れかのネットワーク装置21に接続した複数のエッジサーバ25を備えアクセスネットワーク10を介してユーザ端末1を収容する中継ネットワーク20と、中継ネットワーク20と接続した外部ネットワーク30とを有する通信ネットワークにおいて、前記ユーザ端末1の通信フローを前記中継ネットワーク20の途中でローカルブレークアウトさせて前記ユーザ端末1と前記エッジサーバ25との間で通信させるよう前記ネットワーク装置21にルーティング指示を送信する管理ノード50を備えた。

目的

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

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

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

請求項2

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

請求項3

前記管理ノードは、前記ユーザ端末からの前記外部ネットワーク宛ての通信要求に対して、前記エッジサーバの割り当て処理及び前記ネットワーク装置へのルーティング指示処理を行うことを特徴とする請求項2記載の通信システム。

請求項4

前記エッジサーバには予め固定アドレスを割り当てておき、前記管理ノードは予め前記ネットワーク装置へのルーティング指示処理を行い、前記ユーザ端末からの前記外部ネットワーク宛ての通信要求に対して、前記エッジサーバの割り当て処理を行うとともに割り当てたエッジサーバの固定アドレスを前記ユーザ端末に通知することを特徴とする請求項2記載の通信システム。

請求項5

前記各エッジサーバには予め共通の固定アドレスを割り当てておき、前記管理ノードは、前記共通の固定アドレスに対する通信パケットが、ユーザ端末の在圏エリアごとに異なるエッジサーバへローカルブレークアウトされるよう前記ネットワーク装置へのルーティング指示処理を予め行い、前記ユーザ端末からの名前解決要求に対して前記エッジサーバ共通の固定アドレスを回答する名前解決サーバを備えたことを特徴とする請求項2記載の通信システム。

請求項6

前記管理ノードは、前記ユーザ端末が通信中の前記エッジサーバ又は当該エッジサーバが収容されている前記ネットワーク中継装置混雑故障状況に応じて、前記ユーザ端末の通信相手先を他のエッジサーバに切り替えるようルーティング指示処理を行うことを特徴とする請求項2乃至5何れか1項記載の通信システム。

請求項7

前記名前解決サーバは、第1のエッジサーバに係る第1の固定アドレスと第2のエッジサーバに係る第2の固定アドレスとを前記ユーザ端末に回答し、前記ユーザ端末は、通信中の前記第1のエッジサーバ又は当該第1のエッジサーバが収容されている前記ネットワーク中継装置の混雑・故障状況に応じて、通信相手先を前記第2のエッジサーバに切り替えることを特徴とする請求項5記載の通信システム。

請求項8

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

技術分野

背景技術

0002

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

0003

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

0004

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

先行技術

0005

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, THIRDQUARTER2012
C. Contavalli, 他3名, "Client Subnet in DNS Queries",IETF RFC7871, 2017年1月, [online], [平成29年6月29日検索],インターネット

発明が解決しようとする課題

0006

上記(1)に関する従来の技術としては、LIPA(Local IP Access)やSIPTO(Selected IP Traffic Offload)がある(非特許文献4及び5参照)。

0007

LIPAは、NAT(Network Address Translation)機能搭載のHome eNodeBにより個人宅内やオフィス向けローカルネットワークトラヒックコアネットワークへ転送せずオフロードする技術である。しかし、LIPAでは、装置設置個所近傍における固定的利用しかできないという課題がある。

0008

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

0009

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

0010

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

0011

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

課題を解決するための手段

0012

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

0013

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

発明の効果

0014

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

図面の簡単な説明

0015

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

実施例

0016

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

0017

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

0018

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

0019

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

0020

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

0021

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

0022

本実施の形態に係る通信システムは、図2に示すように、ユーザ端末1と、アクセスネットワーク10と、中継ネットワーク20と、IPネットワーク30と、ポータルサーバ40と、管理ノード50とを含んで構成される。通信事業者ネットワークはアクセスネットワーク10と中継ネットワーク20を含んで構成される。

0023

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

0024

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

0025

ネットワーク装置21は、例えば通信事業者ネットワークが移動体通信ネットワークであるLTEネットワークの場合、eNodeB、モバイルバックホールを構成する装置、S−GW(Serving-Gateway)やP−GW(PDN(Packet Data Network)-Gateway)などEPCを構成する装置のうちユーザデータ通信パケット中継機能を有する装置が相当する。また、例えば通信事業者ネットワークが固定通信ネットワークである場合は、ユーザ端末1を収容する収容ルータや各種中継ルータなどが相当する。

0026

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

0027

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

0028

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

0029

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

0030

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

0031

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

0032

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

0033

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

0034

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

0035

管理ノード50の機能ブロック図を図3に示す。管理ノード50は、上記機能を実現するため、ポータルサーバ接続部51と、ユーザ情報受付部52と、管理系情報収集部53と、計算部54と、ネットワーク構成情報データベース(DB)55と、ネットワーク装置群管理ネットワーク接続部56と、ルーティング情報変更指示部57とを備える。

0036

ユーザ情報受付部52は、ポータルサーバ40から受け取ったユーザリクエスト(エッジサーバ利用リクエスト、中継ネットワーク20内折り返し通信リクエスト等)およびユーザ位置情報(移動体通信であれば基地局情報GPS情報等、光固定通信ネットワークであれば収容局情報・ONUの論理ID等)を格納し、計算部54に情報を通知する機能を備える。ユーザ情報受付部52で取得するデータの一例を図4に示す。取得データは、図4の例では、ユーザID,ユーザIPアドレス,ユーザ利用アプリ情報,ユーザ最寄りネットワーク装置21(例えば移動体通信ネットワークの場合には基地局であるeNodeBのID)、カプセルID(例えば移動体通信ネットワークの場合にはGTPトンネルのTEID等)を含む。

0037

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

0038

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

0039

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

0040

計算部54の動作の一例を図7フローチャートに示す。計算部54は、図7に示すように、ユーザからのリクエストがあると(ステップS1)、ネットワーク構成情報DB55からネットワーク情報を取得する(ステップS2)。計算部54は、繰り返し処理のために変数iに1をセットし(ステップS3)、ユーザリクエスト情報とネットワーク構成情報を照合し、該当行列目の情報に従い当該ユーザに割り当てるエッジサーバ25(乃至それを収容しているネットワーク装置21)を決定する(ステップS4)。次に、計算部54は、管理系情報収集部53から管理情報を取得し(ステップS5)、前記ステップS4で決定されたエッジサーバ25や通信経路上に故障・輻輳等の問題があるかを判定する(ステップS6)。判定の結果、問題がある場合には、ネットワーク構成情報DB55の表の該当行i+1列目に有効な情報が記載されているかを判定し(ステップS7)、記載がない場合には、ポータルサーバ40及びユーザに対してエラーメッセージを返す(ステップS8)。記載がある場合には、変数iをインクリメントし(ステップS9)、前記ステップS4に処理を移す。前記ステップS6の判定の結果、問題がない場合には、ネットワーク装置21群に対するルーティング変更リストを作成し(ステップS10)、当該リストをルーティング情報変更指示部57へ受け渡す(ステップS11)。

0041

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

0042

管理ノード50は、中継ネットワーク20の中にあっても外にあってもよいし、ポータルサーバ40と一体であってもよい。管理ノード50は、例えばSDN(Software Defined Network)コントローラのようなものであっても良いし、ネットワーク装置21群に対してtelnetやssh等によりコマンドを送出するサーバやコンピュータであっても良い。

0043

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

0044

図8にネットワーク装置21の機能ブロック図を示す。ネットワーク装置21は、図8に示すように、上流ポート211と、1つ又は複数の下流ポート212、エッジサーバ接続部213と、管理ネットワーク接続部214と、振り分け部215と、ルーティング情報データベース216と、ネットワーク情報収集部217を含む。

0045

ネットワーク情報収集部217は、ネットワーク装置21内の各ポート(上流ポート211、下流ポート212、エッジサーバ接続部213)から得られた帯域、遅延、パケットロス、輻輳状況等の情報を、管理ネットワーク接続部214を経由して管理ノード50に送信する機能を有する。

0046

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

0047

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

0048

また、振り分け部215は、ルーティング情報DB216から提供されるルーティングルールにしたがって、特定ユーザ端末1の通信パケット(一部または全部)をエッジサーバ接続部213へ振り分ける機能を有する。

0049

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

0050

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

0051

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

0052

以下に、パケット振り分け部215によるパケット書換えの具体例を図9を参照して説明する。ここでは一例として、通信事業者ネットワーク2が移動体通信ネットワークの一種であるLTEネットワークであり、ユーザ最寄りのネットワーク装置21が「基地局(eNodeB)」であり、ユーザ最寄りのエッジサーバ25がMECサーバ(1)」であり、MECサーバ(1)を収容するネットワーク装置21が「MECルータ(1)」であり、 ネットワーク装置21のうち最上流(IPネットワークとの境界に位置する)の装置が「S−GW」であるものとして説明する。

0053

図9中、送信元IPアドレスを「S−IP(Source IP)」と表記し、宛先IPアドレスを「D−IP(Destination IP)」と表記する。また図中、TEID(Tunnel Endpoint IDentifier)は、GTPトンネルの各セッション(ユーザやアプリケーションごとの通信フロー)を識別するための記号番号を意味する。

0054

図9に示すように、通常(エッジサーバ利用無し)時であれば、GTPパケットヘッダとして一律「S−IP=eNodeB,D−IP=S−GW」と付与される。本発明では、当該パケットヘッダ部分を、「S−IP=eNodeB,D−IP=MECルータ(1)」に置換することにより、上り信号がS−GWへ向かわずMECルータ(1)へ向かう。ユーザ識別にはTEIDやIPヘッダの送信元IPアドレス等を利用する。

0055

図10にエッジサーバ25の機能ブロック図を示す。エッジサーバ25は、図10に示すように、ネットワーク装置接続部251と、管理系ネットワーク接続部252と、サーバリソース情報収集部253と、パケット振り分け部254と、仮想マシンネットワークL2分離部255と、仮想マシン256とを含む。

0056

サーバリソース情報収集部253は、エッジサーバ25のリソース情報(CPU使用率、メモリ使用量、ストレージ使用量、VM起動数、利用中ユーザ端末数等)を収集し、管理系ネットワーク接続部252を通して管理ノード50へ通知する機能を備える。

0057

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

0058

仮想マシンネットワークL2分離部255は、例えばVLAN(Virtual Local Area Network)等により、異なるIPアドレス空間に属する仮想マシン256を分離する機能を備える。

0059

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

0060

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

0061

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

0062

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

0063

本実施例1の具体的シーケンスは、図11に示すように、エリア1に在圏しているユーザ端末1は、アプリケーションからサービスを受けるに際して、DNSサーバ35に対してFQDN(Fully Qualified Domain Name)名の名前解決要求を送信すると、ポータルサーバ40のIPアドレスが回答されるので、ポータルサーバ40に対してサービス開始要求や位置情報等を通知する(ステップS11〜S13)。ポータルサーバ40は、エッジサーバ利用開始通知及び最寄りエッジサーバ問合せを管理ノード50に送信する(ステップS14)。管理ノード50は、ネットワーク構成情報DB55を参照して利用させるエッジサーバを決定し(ステップS15,S16)、中継ネットワーク20内の各ネットワーク装置21に対してルーティング変更指示を送信する(ステップS17)。

0064

また、管理ノード50は、エッジサーバを選定した旨の通知をポータルサーバ40に送信する(ステップS18)。ポータルサーバ40は、選定されたエッジサーバ25−2に対して、データやステータスの引き継ぎ情報を送信する(ステップS19)。選定されたエッジサーバ25−2は、ユーザ端末1に対してエッジサーバ利用開始通知を送信する(ステップS20)。

0065

前記ステップS17でルーティング変更指示を受信したネットワーク装置21のうち、アクセスネットワーク10を介してユーザ端末1を収容し、中継ネットワーク20内で生成するトンネルの始点となるもの(図11ではeNodeBであるネットワーク装置21−1)は、トンネルプロトコルヘッダのうち宛先アドレスを、選定されたエッジサーバ25−2が収容されているネットワーク装置21−2のIPアドレスに書き換える。これにより、ユーザ端末1は選定されたエッジサーバ25−2と通信を行う(ステップS21)。

0066

通信を終了する場合、ユーザ端末1はエッジサーバ25−2に終了要求を送信すると、エッジサーバ25−2はポータルサーバ40を介して管理ノード50に終了通知を送信する(ステップS22〜S24)。また、エッジサーバ25−2はポータルサーバ40に対してデータ引き継ぎに係る情報を送信する(ステップS25)。管理ノード50はポータルサーバ40を介してエッジサーバ25−2に終了承認を通知し、エッジサーバ25−2はユーザ端末1に終了通知を送信する(ステップS26〜S28)。さらに、管理ノード50は、中継ネットワーク20内の各ネットワーク装置21に対してルーティング変更指示を送信する(ステップS29)。なお、アプリケーションによっては、前記ステップS25のデータ引き継ぎ処理を省略することができる。

0067

[実施例2]
次に、図12を参照して実施例2に係る通信フローを説明する。本実施例2に係る通信フローは、エッジサーバ専用IPアドレスを用いるパターンである。

0068

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

0069

本実施例2の具体的シーケンスについて図12を参照して説明する。なお、本実施例2では、ポータルサーバ40と管理ノード50が一体となっている例を示す。また、図12では中継ネットワーク20内におけるユーザ端末1を収容し、中継ネットワーク20内で生成するトンネルの端点となるネットワーク装置21であるeNodeBについては図示を省略した。

0070

エリア1に在圏しているユーザ端末1は、図12に示すように、アプリケーションからサービスを受けるに際して、DNSサーバ35に対してFQDN名の名前解決要求を送信すると、ポータルサーバ40のIPアドレスが回答されるので、ポータルサーバ40に対してサービス開始要求や位置情報等を通知する(ステップS31〜S33)。ポータルサーバ40は、前記第1の実施の形態と同様の処理により、ネットワーク構成情報DB55を参照して利用させるエッジサーバを決定する(ステップS34,S35)。ポータルサーバ40は、前記第1の実施の形態と同様に、選定されたエッジサーバ25−1に対して、データやステータスの引き継ぎ情報を送信する(ステップS36)。また、ポータルサーバ40は、ユーザ端末1に対して、選定されたエッジサーバ25−1に割り当てられているIPアドレスを送信する(ステップS37)。

0071

ユーザ端末1は選定されたエッジサーバ25−1と通信を行う(ステップS38)。ここで、アクセスネットワーク10を介してユーザ端末1を収容し、中継ネットワーク20内で生成するトンネルの端点となるネットワーク装置21(図12では図示省略)は、トンネルプロトコルのヘッダのうち宛先アドレスを、選定されたエッジサーバ25−1が収容されているネットワーク装置21−1のIPアドレスに書き換える。これにより、ユーザ端末1と、選定されたエッジサーバ25−1との通信が可能になる。通信終了のフローについては、第1の実施の形態と同様である(ステップS39〜S43)。

0072

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

0073

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

0074

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

0075

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

0076

本実施例3の具体的シーケンスを図13に示す。エリア1に在圏しているユーザ端末1−1は、図13に示すように、アプリケーションからサービスを受けるに際して、DNSサーバ35に対してFQDN名の名前解決要求を送信すると、エッジサーバ25共通の固定IPアドレスが回答される(ステップS51,S52)。ユーザ端末1−1は、前記固定IPアドレスに対して通信パケットを送出する(ステップS53)。ここで、アクセスネットワーク10を介してユーザ端末1−1を収容し、中継ネットワーク20内で生成するトンネルの端点となるネットワーク装置21(図13ではeNodeB(1)であるネットワーク装置21−1)には、前記固定IPアドレス宛ての通信パケットをカプセル化する際に、トンネルプロトコルのヘッダのうち宛先アドレスを、エッジサーバ25−3が収容されているネットワーク装置21−3のIPアドレスとするルールが予め管理ノード50によって設定されている。これにより、ユーザ端末1−1とエッジサーバ25−3との通信が可能になる。

0077

本実施例3では、図13に示すように、ユーザ端末1がどのエリアに在圏している場合においても共通の固定IPアドレスに対して通信を行おうとするが、ユーザ端末1がエリア1(例えばeNodeB(1)配下)に在圏している場合はエッジサーバ(1)と、エリア2(例えばeNodeB(2)配下)に在圏している場合はエッジサーバ(2)と疎通する点に留意されたい(ステップS51〜S59参照)。

0078

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

0079

本実施例3’の具体的シーケンスを図14に示す。前記実施例3と同様の処理手順により、エリア1に在圏しているユーザ端末1−1は、エッジサーバ25−3との通信を行っているものとする(ステップS61〜S63)。ただし、DNSサーバ35からの名前解決応答には、固定的に割り当てられたプライマリのエッジサーバ25−3の固定IPアドレスとともに、固定的に割り当てられた予備的なセカンダリのエッジサーバ25−4の固定IPアドレスを含む。なお、中継ネットワーク20内の各ネットワーク装置21は、予め、管理ノード50からの指示により、セカンダリのエッジサーバ25−4の固定IPアドレスでアクセスがあった場合のルーティングについても固定的に設定されているものとする。

0080

ここで、プライマリのエッジサーバ25−3又は当該エッジサーバ25−3が収容されているネットワーク装置21−3に混雑又は故障が発生したものとする。ユーザ端末1−1は、当該混雑又は故障の発生を検出すると、宛先IPアドレスをプライマリのエッジサーバ25−3の固定IPアドレスからセカンダリのエッジサーバ25−4の固定IPアドレスに切り替えて以降の通信を行う(ステップS64〜S66)。なお、図14に示すように、エリア2に在圏しているユーザ端末1−2の通信には影響はない(ステップS67〜S69)。

0081

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

0082

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

0083

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

0084

1…ユーザ端末
2…通信事業者ネットワーク
3…インターネット
4…サーバ
5,9…アプリケーション
6…エッジサーバ
7…管理ノード
8…トンネル
10…アクセスネットワーク
20…中継ネットワーク
21…ネットワーク装置
211…上流ポート
212…下流ポート
213…エッジサーバ接続部
214…管理ネットワーク接続部
215…振り分け部
216…ルーティング情報
217…ネットワーク情報収集部
25…エッジサーバ
251…ネットワーク装置接続部
252…管理系ネットワーク接続部
253…サーバリソース情報収集部
254…パケット振り分け部
255…仮想マシンネットワークL2分離部
256…仮想マシン
30…IPネットワーク
40…ポータルサーバ
50…管理ノード
51…ポータルサーバ接続部
52…ユーザ情報受付部
53…管理系情報収集部
54…計算部
55…ネットワーク構成情報データベース
56…ネットワーク装置群管理ネットワーク接続部
57…ルーティング情報変更指示部

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ