(57)【要約】【課題】Ｐ２Ｐ通信における通信制御を適切に実行することを可能とする技術を提供する。【解決手段】デバイスが中継サーバを介して他のデバイスとＰ２Ｐ通信を実行するネットワークにおける制御を行う制御システムにおいて、前記デバイスから品質要求情報を含む接続要求を受信し、当該品質要求情報を登録する登録手段と、前記中継サーバから、前記Ｐ２Ｐ通信における前記デバイスと前記中継サーバとの間の通信に関する通信情報を取得する取得手段と、前記通信情報と前記品質要求情報に基づいて、前記デバイスと前記中継サーバとの間のトラフィック制御を実行する制御手段とを備える。【選択図】図４
2019186907.tif 000002
【特許請求の範囲】
【請求項１】
デバイスが中継サーバを介して他のデバイスとＰ２Ｐ通信を実行するネットワークにおける制御を行う制御システムであって、
前記デバイスから品質要求情報を含む接続要求を受信し、当該品質要求情報を登録する登録手段と、
前記中継サーバから、前記Ｐ２Ｐ通信における前記デバイスと前記中継サーバとの間の通信に関する通信情報を取得する取得手段と、
前記通信情報と前記品質要求情報に基づいて、前記デバイスと前記中継サーバとの間のトラフィック制御を実行する制御手段と
を備える制御システム。
【請求項２】
前記制御手段は、前記トラフィック制御として、前記デバイスと前記中継サーバとの間に備えられるＣＰＥ又はエッジルータに対してシェーピング処理設定を行う
請求項１に記載の制御システム。
【請求項３】
前記取得手段は、前記中継サーバと前記他のデバイスの側の中継サーバとの間の通信に関する中継系通信情報を前記デバイスから取得し、
前記制御手段は、前記中継系通信情報と前記品質要求情報に基づいて、前記中継サーバと前記他のデバイスの側の中継サーバとの間のトラフィック制御を実行する
請求項１又は２に記載の制御システム。
【請求項４】
前記制御手段は、前記中継サーバと前記他のデバイスの側の中継サーバとの間のトラフィック制御として、前記中継サーバと前記他のデバイスの側の中継サーバとの間の通信経路を変更する経路制御を実行する
請求項１ないし３のうちいずれか１項に記載の制御システム。
【請求項５】
デバイスが中継サーバを介して他のデバイスとＰ２Ｐ通信を実行するネットワークにおける制御を行う制御システムが実行する制御方法であって、
前記デバイスから品質要求情報を含む接続要求を受信し、当該品質要求情報を登録する登録ステップと、
前記中継サーバから、前記Ｐ２Ｐ通信における前記デバイスと前記中継サーバとの間の通信に関する通信情報を取得する取得ステップと、
前記通信情報と前記品質要求情報に基づいて、前記デバイスと前記中継サーバとの間のトラフィック制御を実行する制御ステップと
を備える制御方法。
【請求項６】
コンピュータを、請求項１ないし４のうちいずれか１項に記載の制御システムにおける各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デバイス間で実行される通信を安定化させるための技術に関連するものである。
【背景技術】
【０００２】
Ｗｅｂシステム上での映像コミュニケーションを可能とするＷｅｂＲＴＣ（Web Real-Time Communication）の普及に伴い、それを活用したサービスユースケースは多様化の一途をたどっている。ユースケースとしては、従来のテレビ会議にとどまらず、オンライン英会話・遠隔医療・遠隔作業支援など様々なケースで活用されており、より複合的なものとなっている。
【０００３】
ユースケースの発展に伴い、ＷｅｂＲＴＣ通信の品質に関わる要望も多様なものになってきている。ここで、品質に関わる要望としては、「低遅延」、「安定した映像・音声通信」といったものが挙げられる。なお、ＷｅｂＲＴＣに関する先行技術として例えば特許文献１に開示された技術がある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１６−１３４６６５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、ＷｅｂＲＴＣ通信で用いられるポート番号等はセッション毎に動的に決められるため、どのＵＤＰフローがどのＷｅｂＲＴＣ通信に属しているかが分からないので、品質に関わる要望を満たすように通信制御を行うことが難しい。なお、このような課題はＷｅｂＲＣＴ通信以外のＰ２Ｐ通信にも生じ得る課題である。
【０００６】
本発明は上記の点に鑑みてなされたものであり、Ｐ２Ｐ通信における通信制御を適切に実行することを可能とする技術を提供することを目的とする。
【課題を解決するための手段】
【０００７】
開示の技術によれば、デバイスが中継サーバを介して他のデバイスとＰ２Ｐ通信を実行するネットワークにおける制御を行う制御システムであって、
前記デバイスから品質要求情報を含む接続要求を受信し、当該品質要求情報を登録する登録手段と、
前記中継サーバから、前記Ｐ２Ｐ通信における前記デバイスと前記中継サーバとの間の通信に関する通信情報を取得する取得手段と、
前記通信情報と前記品質要求情報に基づいて、前記デバイスと前記中継サーバとの間のトラフィック制御を実行する制御手段と
を備える制御システムが提供される。
【発明の効果】
【０００８】
開示の技術によれば、Ｐ２Ｐ通信における通信制御を適切に実行することを可能とする技術が提供される。
【図面の簡単な説明】
【０００９】
【図１】通信経路の例を示す図である。
【図２】通信経路の例を示す図である。
【図３】パケットシェーパーを配置した構成を示す図である。
【図４】本発明の実施の形態におけるシステム構成図である。
【図５】Ｄｅｖｉｃｅからの接続要求フローを示す図である。
【図６】ＷｅｂＲＴＣ通信開始後のトラフィック制御フローである。
【図７】Ｄｅｖｉｃｅの機能構成図である。
【図８】ＣＯＮＮ−ＭＮＧの機能構成図である。
【図９】ＴＵＲＮの機能構成図である。
【図１０】ＲＣ−ＭＮＧの機能構成図である。
【図１１】ＮＥ−ＣＴＲＬの機能構成図である。
【図１２】装置のハードウェア構成例を示す図である。
【発明を実施するための形態】
【００１０】
以下、図面を参照して本発明の実施の形態（本実施の形態）を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。
【００１１】
以下、本実施の形態として、ＴＵＲＮ（Traversal Using Relay around NAT）を活用したＷｅｂＲＴＣ通信安定化システム（ＲＴＣ−ＣＤＮ（Real-Time Communication - Content Delivery Network））について説明するが、ＲＴＣ−ＣＤＮの効果が明確にわかるように、まずは、ＷｅｂＲＴＣ通信の安定化のために想定される手法、及びその課題を説明する。なお、ＷｅｂＲＴＣ通信の安定化のために想定される手法、及びその課題の説明において示す構成や手法は、出願人が認める従来技術ではない。
【００１２】
（ＷｅｂＲＴＣ通信の安定化のために想定される手法）
背景技術で説明したように、ＷｅｂＲＴＣのユースケースの発展に伴い、ＷｅｂＲＴＣ通信の品質に関わる要望（「低遅延」、「安定した映像・音声通信」など）は多様なものになってきている。
【００１３】
このような品質要望に対してはＮＷ内で経路制御を行うなどのトラフィックエンジニアリングを行ったり、最適な配置でサーバシステムを分散配置することが考えられる。
【００１４】
しかしながら、ＷｅｂＲＴＣ通信は、Ｐ２Ｐの技術を用いているため、図１に示すとおりインターネット上のどの経路を通るかは、それぞれのユーザの環境（どのＩＳＰを利用しているかなど）に依存してしまうため、経路のコントロールを行うことは困難である。典型的には海外との通信など、ユーザデバイス間の距離が増大するに従い、不安定さは増大する。なお、図１は、通信を行う装置であるＤｅｖｉｃｅ１，２がインターネット３を介してＰ２Ｐ通信を行うことを示している。
【００１５】
また、通常のＷｅｂトラフィックと違い、通信に用いるＵＤＰ（User Datagram Protocol）のポート番号等はＷｅｂＲＴＣセッションごとに動的に変化し、かつ通信データは全て暗号化されている。このため、ポート番号や内部データよりパケット種別を判定し、それに応じた制御を行うことは困難となっている。これの解決策として、ＴＵＲＮの活用が考えられる。図２に、図１の構成にＴＵＲＮ４、５を導入した構成を示す。なお、特に断らない限り、明細書及び図面における"ＴＵＲＮ"はＴＵＲＮサーバを意味する。
【００１６】
ＴＵＲＮは、そもそもはＷｅｂＲＴＣ通信においてＮＡＴの種別によりＰ２Ｐコネクションが形成できない場合に用いられるリレーサーバ（中継サーバ）である。これを活用することにより、ＷｅｂＲＴＣ通信を図２に示すように"アクセス区間（デバイス-ＴＵＲＮ間）"、"中継区間（ＴＵＲＮ−ＴＵＲＮ間）"と二つの区間に分離することが出来る。これにより、中継区間はユーザ環境非依存となるため、トラフィックエンジニアリングが容易となる。アクセス区間は依然として制御が困難であるが、接続するＴＵＲＮをユーザデバイス至近とすることで、ＮＷの不安定要素を削減することができる。
【００１７】
また、アクセス区間においても、図３に示すように、デバイス近傍にシェーパー６を配置し、ジッタ（ＩＰパケットの到達間隔のゆらぎ）を吸収することで、映像・音声通信を安定化することができる。これは、ＷｅｂＲＴＣ通信のフロー制御がジッタに大きく依存し、ジッタが大きくなるとデバイス側で映像・音声トラフィックの品質を下げてしまうためである（参考：https://tools.ietf.org/html/draft-ietf-rmcat-gcc-02）。
【００１８】
従って、これらの対処を行うことにより、ＷｅｂＲＴＣ通信の安定化が期待される。
【００１９】
（課題について）
しかしながら、前述したＴＵＲＮやシェーパー等を用いた安定化には課題がある。まず、ＴＵＲＮ間のトラフィックエンジニアリングであるが、前述したようにＷｅｂＲＴＣ通信で用いられるポート番号等はセッション毎に動的に決められるため、中継区間においてどのＵＤＰフローがどのＷｅｂＲＴＣ通信に属しているかが分からない。また、要求される品質制御はユースケースに依存する。例えば、ゲーム通信であれば低遅延性が優先されるし、映像音声通信であれば帯域安定性が優先される傾向が強い。
【００２０】
従って、前者については最短経路を選択し、後者については空いている迂回経路を選択するといったトラフィックエンジニアリングが想定される。しかしながら、どのＵＤＰフローがどの通信に該当するか不明なままでは、このような制御は不可能である。
【００２１】
ここで、通信に用いられるポート番号などの５ｔｕｐｌｅ情報（送信元ＩＰアドレス、送信先ＩＰアドレス、送信元ポート番号、送信先ポート番号、プロトコル（ｔｃｐ  ｏｒ  ｕｄｐ））は、ＷｅｂＲＴＣのＳｔａｔｉｓｔｉｃｓＡＰＩ（参考：https://www.w3.org/TR/webrtc-stats/）をユーザデバイス内アプリケーションで用いることで取得することができる。従って、この情報をいずれかの手段でＮＷ側に通知することにより、上記問題は解決されることが期待される。
【００２２】
しかしながら、ここで得られる５ｔｕｐｌｅ情報（通信情報）は、ＴＵＲＮを利用した場合、ＴＵＲＮ−ＴＵＲＮ間の中継区間のものであり、デバイス−ＴＵＲＮ間のものは取得できない。このため、アクセス区間での解決策である、シェーピングについては、その制御を行うことができない。また、シェーピングの要否も一意に決められるものでは無く、例えば映像通信であれば、シェーピングパラメータはユースケースやデバイス種別に依存する必要映像帯域等に左右されるし、ゲーム通信などであれば、シェーピングは不要となるであろう（シェーピングにより遅延が増加するため）。アクセス区間の５ｔｕｐｌｅ情報が得られないままでは、この制御を行うことは実質不可能である。
【００２３】
（実施の形態の概要）
本実施の形態では、ユーザデバイスと、ＴＵＲＮを含めたＮＷシステムとを連携させることで、前述の課題を解決する。すなわち、各区間での５ｔｕｐｌｅ情報を管理することで、ＷｅｂＲＴＣ通信の安定化・高品質化を実現するものである。本実施の形態におけるＮＷシステムをＲＴＣ−ＣＤＮと呼ぶ。具体的には、ＲＴＣ−ＣＤＮにおいて、ユースケースに応じた中継区間での経路制御や、アクセス区間でのシェーピングを実現する。以下、実施の形態をより詳細に説明する。
【００２４】
（システム構成）
図４に、本実施の形態におけるＲＴＣ−ＣＤＮのシステム構成を示す。図４に示すように、ＲＴＣ−ＣＤＮに関する対象装置の設置場所は、典型的には、ＣＥ１０、ＮＥ２０、ＲＣＣ３０の大きく３つに大別される。なお、本実施の形態では、ＲＴＣ−ＣＤＮは、ＮＥ２０及びＲＣＣ３０からなるＮＷシステムである。ただし、ＲＴＣ−ＣＤＮにＣＥ１０を含めてもよい。
【００２５】
図４には、複数のＣＥとしてＣＥ１０Ａ、ＣＥ１０Ｂが示されている。ＣＥ１０ＡとＣＥ１０Ｂは同じ構成を有している。どちら側のＣＥかを特に区別しないで記述する場合には"ＣＥ１０"と記述する。他の場所、他の装置においても同様である。
【００２６】
ＣＥ（CustomerEdge）１０は、ＷｅｂＲＴＣ通信を利用するエンドユーザがいる場所である。例えば、コンシューマーサービスであればユーザ宅内、エンタープライズサービスであれば事業所ビルなどが該当する。
【００２７】
ＣＥ（CustomerEdge）１０には、ＣＰＥ（Customer Premises Equipment）１１とＤｅｖｉｃｅ（User Device）１２が設置されている。ＣＰＥ１１とＤｅｖｉｃｅ１２との間は有線又は無線で接続されている。また、ＣＰＥ１１は、ＮＥ２０が存在するネットワーク（アクセスネットワーク等）に接続されている。
【００２８】
ＣＰＥ１１は例えばアクセスルータであり、Ｄｅｖｉｃｅ１２は例えばパソコンやスマートフォンなどのユーザが利用するデバイスである。ＷｅｂＲＴＣアプリケーションは、Ｄｅｖｉｃｅ１２上で稼働する。なお、モバイルでの利用の場合など、ＣＰＥ１１の機能がＤｅｖｉｃｅ１２の中に内包されていてもよい。
【００２９】
ＮＥ（Network Edge）２０は、ＲＴＣ−ＣＤＮへのユーザ収容局である。ＮＥ２０は、ユーザ分布に応じ分散配置された構成となっており、基本的にＣＥ１０からは最寄りのＮＥ２０に接続する形態となる。図４の例では、ＣＥ１０Ａに対する最寄りのＮＥ２０はＮＥ２０Ａであり、ＣＥ１０Ｂに対する最寄りのＮＥ２０はＮＥ２０Ｂである。
【００３０】
ＮＥ２０には、ＲＣ−ＥＲ（RTC-CDN Edge Router）２３、ＴＵＲＮ（TURN Server）２２、ＲＣ‐ＢＲ（RTC-CDN Border Router）２１が設置される。ＴＵＲＮ２２はＲＣ−ＥＲ２３とＲＣ‐ＢＲ２１のそれぞれに接続される。
【００３１】
ＲＣ−ＥＲ２３はＣＥ１０（ＣＰＥ１１）からの接続ポイントとなるルータである。ここで、エンタープライズ用途などでＶＰＮ（Virtual Private Network）を用いる場合には、ＣＰＥ１１がＶＰＮルータ、ＲＣ−ＥＲ２３がＶＰＮ接続点となる。
【００３２】
ＴＵＲＮ２２は、Ｄｅｖｉｃｅ１２間のＷｅｂＲＴＣ通信をリレーするサーバであり、後述するようにＤｅｖｉｃｅ１２上のＷｅｂＲＴＣアプリケーションから、このＴＵＲＮ２２のアドレスを指定することでＲＴＣ−ＣＤＮに接続する。なお、図４の構成において、Ｄｅｖｉｃｅ１２ＡはＴＵＲＮ２２Ａを使用し、Ｄｅｖｉｃｅ１２ＢはＴＵＲＮ２２Ｂを使用する。ただし、これは一例であり、ＷｅｂＲＴＣ通信を行う２つのＤｅｖｉｃｅ１２が同じＮＥ２０配下に存在する場合には、当該２つのＤｅｖｉｃｅ１２は同じ１つのＴＵＲＮ２２を使用して通信を行うこととしてもよい。
【００３３】
ＲＣ‐ＢＲ２１は、各ＮＥ２０間を接続する境界ルータである。つまり、各ＮＥ２０におけるＲＣ‐ＢＲ２１同士が接続される。接続トポロジー（フルメッシュやハブアンドスポークなど）は、各ＮＥ２０の物理配置やトラフィック状況等に応じ最適なものとなるよう決められる。
【００３４】
ＲＣＣ（RTC-CDN Center）３０はＲＴＣ−ＣＤＮの集約センター設備であり、Ｄｅｖｉｃｅ１２からのコネクション要求管理や、ＲＴＣ−ＣＤＮ内の各種制御を行う。図４に示すとおり、ＲＣＣ３０は、ＣＯＮＮ−ＭＮＧ（Connection Manager）３１、ＲＣ−ＭＮＧ（RTC-CDN Manager）３２、ＮＥ−ＣＴＲＬ（Network Equipments Controller）３３、及びＤａｔａｂａｓｅ３４を有する。なお、ＲＣＣ（RTC-CDN Center）３０は、物理的に１つの装置であってもよいし、ＣＯＮＮ−ＭＮＧ３１、ＲＣ−ＭＮＧ３２、ＮＥ−ＣＴＲＬ３３、及びＤａｔａｂａｓｅ３４がそれぞれ１つの装置であってもよいし、その他の構成であってもよい。また、「ＣＯＮＮ−ＭＮＧ３１、ＲＣ−ＭＮＧ３２、ＮＥ−ＣＴＲＬ３３、及びＤａｔａｂａｓｅ３４」を制御システムと称してもよい。
【００３５】
ＲＣＣ３０は、各ＮＥ２０及び各ＣＥ１０とネットワーク（インターネットでもよいし、専用の制御ネットワークでもよい）を介して通信可能である。
【００３６】
ＣＯＮＮ−ＭＮＧ３１は、Ｄｅｖｉｃｅ１２からの接続制御を管理するサーバであり、Ｄｅｖｉｃｅ１２が接続するＴＵＲＮ２２のアドレスや、接続認証情報の払い出しなどを行う。
【００３７】
ＲＣ−ＭＮＧ３２は、ＲＴＣ−ＣＤＮシステムを管理するサーバであり、ＣＯＮＮ−ＭＮＧ３１から受け取った接続情報のデータベース管理や、それを基にした、ＴＵＲＮとの連携やＮＥ−ＣＴＲＬ３３へのネットワーク機器制御指示等を行う。
【００３８】
Ｄａｔａｂａｓｅ３４は、上記接続情報等を格納するデータベースである。Ｄａｔａｂａｓｅ３４は、ＲＣ−ＭＮＧ３２の外部にあるサーバであってもよいし、ＲＣ−ＭＮＧ３２内の機能であってもよい。
【００３９】
ＮＥ−ＣＴＲＬ３３は、ＲＣ−ＭＮＧ３２からの指示に従い、ＲＴＣ−ＣＤＮの各種ネットワーク機器を制御するサーバである。具体的には、個々のＷｅｂＲＴＣ通信に対するＲＣ−ＢＲ２１での経路制御や、ＲＣ−ＥＲ２３でのシェーピング制御等を行う。なお、ＣＰＥ１１とＲＣ−ＥＲ２３との間がＳＤ−ＷＡＮ技術で構成されており、技術要件を満たしかつユーザポリシーとしてＲＴＣ−ＣＤＮからのＣＰＥ１１のコントロールが可能な場合は、ＮＥ−ＣＴＲＬ３３は、ＣＰＥ１１に対するシェーピング処理も実施する。
【００４０】
（システムの動作例）
次に、上述した構成を有するシステムの動作例を説明する。ここで説明する動作例は２つのフェーズに分かれており、一つは「Ｄｅｖｉｃｅからの接続要求フロー」もう一つは「ＷｅｂＲＴＣ通信開始後のトラフィック制御フロー」である。以下、それぞれについて説明する。以下で説明する処理は、例えば、図４におけるＣＥ１０Ａ側の処理であるが、ＣＥ１０Ａと通信を行うＣＥ１０Ｂ側でも同様の処理が実行される。
【００４１】
＜Ｄｅｖｉｃｅからの接続要求フロー＞
まず、ＷｅｂＲＴＣ通信に先立って実施されるＲＴＣ−ＣＤＮに対するＤｅｖｉｃｅ１２からの接続要求フローについて、図５に示すステップ番号の順に説明する。
【００４２】
ステップ１：ＷｅｂＲＴＣ通信に先立ち、Ｄｅｖｉｃｅ１２は、ＣＯＮＮ−ＭＮＧ３１に対し、接続要求を送信する。接続要求には、Ｄｅｖｉｃｅ１２がＲＴＣ−ＣＤＮを利用するに当たっての認証情報、及び該当ＷｅｂＲＴＣ通信に対する品質要求情報（"遅延最小"、"帯域重視"、"バースト耐性低"、"ジッタ耐力低"、"高優先"など）が含まれている。
【００４３】
ステップ２〜３：ＣＯＮＮ−ＭＮＧ３１は、Ｄｅｖｉｃｅ１２から受信した接続要求に対し、Ｄｅｖｉｃｅ１２が利用するＴＵＲＮ２２のドメイン名もしくはＩＰアドレス（耐障害性を考慮し、複数のＴＵＲＮサーバとすることも可能）やワンタイムのＴＵＲＮ接続認証情報（ユーザ名とパスワード）を生成する。ここで、生成されたワンタイム認証情報は必要に応じ、ステップ２、３により該当ＴＵＲＮ２２に登録される。ただし、例えばhttps://tools.ietf.org/html/draft-uberti-rtcweb-turn-rest-00記載のTURN REST API方式を用いる場合は、認証情報のＴＵＲＮへの登録は不要であるため、この登録フロー（ステップ２、３）はキャンセルされる。
【００４４】
ステップ４〜５：ＣＯＮＮ−ＭＮＧ３１は、ＲＣ−ＭＮＧ３２に対しset connection info requestを送信することで、上記ステップで生成したワンタイム認証情報、品質要求情報、ユーザ識別情報（ユーザのＩＰアドレスなど）などを登録することをＲＣ−ＭＮＧ３２に要求し、ＲＣ−ＭＮＧ３２はＤａｔａｂａｓｅ３４にこれらの情報を登録（格納）する。登録に成功すればsuccess responseが返される。
【００４５】
ステップ６：ＣＯＮＮ−ＭＮＧ３１は、ステップ２〜３で生成された接続ＴＵＲＮの情報（ドメイン名あるいはＩＰアドレス）及びワンタイム認証情報をＤｅｖｉｃｅ１２に返信する。
【００４６】
その後、Ｄｅｖｉｃｅ１２は、ステップ６で得た情報を用いてＴＵＲＮ２２に接続することで、対向のＤｅｖｉｃｅ１２とＷｅｂＲＴＣ通信を行うことができる。
【００４７】
＜ＷｅｂＲＴＣ通信開始後のトラフィック制御フロー＞
次に、先のフローで得られた接続情報を用いたＷｅｂＲＴＣ通信に対するトラフィック制御フローについて、図６に示すステップ番号の順に説明する。
【００４８】
ステップ１：Ｄｅｖｉｃｅ１２は、図５で示したフローで得られたワンタイム認証情報により、該当ＴＵＲＮ２２を用いたＷｅｂＲＴＣ通信を確立すると、Ｄｅｖｉｃｅ１２内で駆動しているＷｅｂＲＴＣアプリケーションが、このＴＵＲＮ２２を用いた通信経路情報（success ICE info：中継系のＴＵＲＮ−ＴＵＲＮ間で用いられる５ｔｕｐｌｅ情報）をＡＰＩにより取得し、Ｄｅｖｉｃｅ１２は、この取得した情報とワンタイム認証情報をセットでＲＣ−ＭＮＧ３２に送信する。なお、この時点では該当ＷｅｂＲＴＣ通信はＲＴＣ−ＣＤＮ内のデフォルトパスを通っており、いずれのトラフィックエンジニアリングも行われていない。
【００４９】
ステップ２〜３：ＲＣ−ＭＮＧ３２は、ＴＵＲＮ２２から該当ＷｅｂＲＴＣ通信で用いているＤｅｖｉｃｅ１２−ＴＵＲＮ２２間の５ｔｕｐｌｅ情報を取得する。この時、ＲＣ−ＭＮＧ３２は、ステップ１で取得したＴＵＲＮ−ＴＵＲＮ間の５ｔｕｐｌｅ情報もしくはワンタイム認証情報（５ｔｕｐｌｅ情報とワンタイム認証情報の両方でもよい）をキーとして、それにマッチするものを取得する。
【００５０】
ステップ４〜５：ＲＣ−ＭＮＧ３２は、ステップ１及びステップ２〜３で取得した５ｔｕｐｌｅ情報、及び「Ｄｅｖｉｃｅからの接続要求フロー」で取得している品質要求情報をＮＥ−ＣＴＲＬ３３に送信し、該当ＷｅｂＲＴＣ通信のトラフィック制御処理を要求する。
【００５１】
ＮＥ−ＣＴＲＬ３３は、ＴＵＲＮ一丁ＵＲＮ間については、ステップ１で取得した５ｔｕｐｌｅ情報及び品質要求条件により、ＲＣ−ＢＲ２１に対し、最短経路への経路変更又は混雑していないパスへの経路変更などの経路制御を行う。
【００５２】
ＮＥ−ＣＴＲＬ３３は、Ｄｅｖｉｃｅ１２‐ＴＵＲＮ２２間については、ステップ２〜３で取得した５ｔｕｐｌｅ情報と品質要求条件を用い、必要に応じ、ＲＣ−ＥＲ２３もしくはＣＰＥ１１に対し、シェーピング設定処理等を実施する。なお、ＲＣ−ＥＲ２３にシェーピング処理等を行わせるのは、例えば、Ｄｅｖｉｃｅ１２がパブリックインターネット経由でＲＴＣ−ＣＤＮを利用している場合であり、コンシューマー用途が典型である。また、ＣＰＥ１１にシェーピング処理等を行わせるのは、ＣＰＥ１１でＶＰＮ処理をしている場合であり、エンタープライズ用途が典型である。
【００５３】
なお、シェーピング処理は、トラフィック制御の一例であり、シェーピング処理に代えて、あるいはシェーピング処理に加えて、キューイング処理、ポリシング処理などのＱｏＳ制御を実施してもよい。
【００５４】
ステップ６：ＲＣ−ＭＮＧ３２は、Ｄｅｖｉｃｅ１２に対し、処理が完了した旨返信する。
【００５５】
上記ステップ１〜６により、ＷｅｂＲＴＣ通信のトラフィック制御が行われる。以降では、トラフィック制御の解放ステップについて説明する。
【００５６】
ステップ７〜８：ＲＣ−ＭＮＧ３２は、ＴＵＲＮ２２に対し、ポーリング処理を行い、Ｄｅｖｉｃｅ１２による該当ＷｅｂＲＴＣ通信が利用されているか否かを確認する。ここで、該当ＷｅｂＲＴＣ通信が終了している場合は、次のステップに移る。
【００５７】
ステップ９〜１０：ＲＣ−ＭＮＧ３２は、ＮＥ−ＣＴＲＬ３３に対し、該当ＷｅｂＲＴＣ通信に対する経路制御やシェーピング制御などの解放要求を行う。ＮＥ−ＣＴＲＬ３３は、ステップ４〜５で制御処理を行った機器（ＲＣ−ＢＲ２１，ＲＣ−ＥＲ２３，ＣＰＥ１１）の、該当５ｔｕｐｌｅの経路変更設定やシェーピング設定の解放制御を行う。
【００５８】
（装置構成）
以下、図５、図６に示した動作を実行する各装置の機能構成の例を説明する。なお、以下で説明する各装置の機能構成は、本実施の形態の動作に関連する機能を主に示している。以下で説明する各装置内の機能区分は一例に過ぎない。本実施の形態の動作を実行できるのであれば、機能区分はどのような機能区分であってもよい。
【００５９】
図７は、Ｄｅｖｉｃｅ１２の機能構成図である。図７に示すように、Ｄｅｖｉｃｅ１２は、接続制御部１２１、通信部１２２を有する。接続制御部１２１は、接続要求の送信（図５のステップ１）、及び接続ＴＵＲＮの情報とワンタイム認証情報の受信（図５のステップ６）を実行する。通信部１２２は、ＷｅｂＲＴＣ通信を行うとともに、ＲＣ−ＭＮＧ３２への情報送信及び応答受信（図６のステップ１、６）を実行する。
【００６０】
図８は、ＣＯＮＮ−ＭＮＧ３１の機能構成図である。図８に示すように、ＣＯＮＮ−ＭＮＧ３１は、接続制御部３１１、登録部３１２を有する。接続制御部３１１は、Ｄｅｖｉｃｅ１２からの接続要求に対し、ＴＵＲＮサーバの情報及びワンタイム認証情報を生成し、Ｄｅｖｉｃｅ１２に返信する（図５のステップ１、６）。登録部３１２は、必要に応じてワンタイム認証情報をＴＵＲＮサーバへ登録するとともに、ワンタイム認証情報、品質要求情報、及びユーザ識別情報をＲＣ−ＭＮＧ３２に登録する（図５のステップ２、３、４、５）。
【００６１】
図９は、ＴＵＲＮ２２の機能構成図である。図９に示すように、ＴＵＲＮ２２は、通信部２２１、通信情報管理部２２２を有する。通信部２２１は、ＷｅｂＲＴＣトラフィックの中継を行う。通信情報管理部２２２は、必要に応じて、ＣＯＮＮ−ＭＮＧ３１からワンタイム認証情報を受信し、登録（格納する）する（図５のステップ２、３）。
【００６２】
また、通信情報管理部２２２は、通信部２２１が実行しているＤｅｖｉｃｅ−ＴＵＲＮ間の通信の５ｔｕｐｐｌｅ情報を管理（格納）しており、ＲＣ−ＭＮＧ３２からの要求に基づいて当該５ｔｕｐｐｌｅ情報をＲＣ−ＭＮＧ３２に送信する（図６のステップ２、３）。また、通信情報管理部２２２は、通信部２２１によるＷｅｂＲＴＣ通信を管理しており、ＲＣ−ＭＮＧ３２からのポーリングに応答してＷｅｂＲＴＣ通信の有無を返答する（図６のステップ７、８）。
【００６３】
図１０は、ＲＣ−ＭＮＧ３２の機能構成図である。図１０に示すように、ＲＣ−ＭＮＧ３２は、登録部３２１、通信制御要求部３２２、通信確認部３２３を有する。
【００６４】
登録部３２１は、ＣＯＮＮ−ＭＮＧ３１からワンタイム認証情報、品質要求情報、ユーザ識別情報等を受信し、登録（格納）する（図５のステップ４、５）。また、登録部３２１は、Ｄｅｖｉｃｅ１２から、ＴＵＲＮ−ＴＵＲＮ間で用いられる５ｔｕｐｌｅ情報と、ワンタイム認証情報を受信し、登録（格納）する（図６のステップ１、６）とともに、Ｄｅｖｉｃｅ−ＴＵＲＮ間の５ｔｕｐｌｅ情報を取得し、登録（格納）する（図６のステップ２、３）。
【００６５】
通信制御要求部３２２は、ＮＥ−ＣＴＲＬ３３に対してトラフィック制御処理を要求する（図６のステップ４、５）とともに、ＮＥ−ＣＴＲＬ３３に対してトラフィック制御処理の解除を要求する（図６のステップ９、１０）。通信確認部３２３は、ＴＵＲＮ２２に対してポーリング処理を行い、該当ＷｅｂＲＴＣ通信が利用されているか否かを確認する（図６のステップ７、８）。
【００６６】
図１１は、ＮＥ−ＣＴＲＬ３３の機能構成図である。図１１に示すように、ＮＥ−ＣＴＲＬ３３は、経路制御部３３１、シェーピング制御部３３２を有する。経路制御部３３１は、ＴＵＲＮ−ＴＵＲＮ間通信についての経路制御を実行し、シェーピング制御部３３２は、Ｄｅｖｉｃｅ−ＴＵＲＮ間通信についてのシェーピング制御を実行する（図６のステップ４、５、９、１０）。
【００６７】
上述した各装置（Ｄｅｖｉｃｅ１２、ＴＵＲＭ２２、ＣＯＮＮ−ＭＮＧ３１、ＲＣ−ＭＮＧ３２、ＮＥ−ＣＴＲ３３、「ＣＯＮＮ−ＭＮＧ３１、ＲＣ−ＭＮＧ３２、ＮＥ−ＣＴＲ３３」が一体となった装置、など）はいずれも、例えば、コンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。なお、この「コンピュータ」は、クラウドサービスにより提供される仮想マシンであってもよい。仮想マシンを使用する場合、ここで説明する「ハードウェア」とは仮想的なハードウェアである。
【００６８】
当該装置は、コンピュータに内蔵されるＣＰＵやメモリ等のハードウェア資源を用いて、当該装置で実施される処理に対応するプログラムを実行することによって実現することが可能である。上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メール等、ネットワークを通して提供することも可能である。
【００６９】
図１２は、本実施の形態における上記コンピュータのハードウェア構成例を示す図である。図１２のコンピュータは、それぞれバスＢで相互に接続されているドライブ装置１０００、補助記憶装置１００２、メモリ装置１００３、ＣＰＵ１００４、インタフェース装置１００５、表示装置１００６、及び入力装置１００７等を有する。
【００７０】
当該コンピュータでの処理を実現するプログラムは、例えば、ＣＤ−ＲＯＭ又はメモリカード等の記録媒体１００１によって提供される。プログラムを記憶した記録媒体１００１がドライブ装置１０００にセットされると、プログラムが記録媒体１００１からドライブ装置１０００を介して補助記憶装置１００２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１００１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１００２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
【００７１】
メモリ装置１００３は、プログラムの起動指示があった場合に、補助記憶装置１００２からプログラムを読み出して格納する。ＣＰＵ１００４は、メモリ装置１００３に格納されたプログラムに従って、当該装置に係る機能を実現する。インタフェース装置１００５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置１００６はプログラムによるＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）等を表示する。入力装置１００７はキーボード及びマウス、ボタン、又はタッチパネル等で構成され、様々な操作指示を入力させるために用いられる。
【００７２】
（実施の形態のまとめ）
以上説明した本実施の形態におけるＮＷシステム（ＲＴＣ−ＣＤＮ）によれば、ＴＵＲＮを用いたＷｅｂＲＣＴ通信において、ＴＵＲＮ−ＴＵＲＮ間（中継区間）のみならず、デバイス−ＴＵＲＮ間（アクセス区間）でも適切なトラフィック制御を実行することが可能となる。
【００７３】
本明細書には少なくとも下記の各項の構成が開示されている。
（第１項）
デバイスが中継サーバを介して他のデバイスとＰ２Ｐ通信を実行するネットワークにおける制御を行う制御システムであって、
前記デバイスから品質要求情報を含む接続要求を受信し、当該品質要求情報を登録する登録手段と、
前記中継サーバから、前記Ｐ２Ｐ通信における前記デバイスと前記中継サーバとの間の通信に関する通信情報を取得する取得手段と、
前記通信情報と前記品質要求情報に基づいて、前記デバイスと前記中継サーバとの間のトラフィック制御を実行する制御手段と
を備える制御システム。
ＣＯＮＮ−ＭＮＧ３１及びＲＣ−ＭＮＧ３２は登録手段の例であり、ＲＣ−ＭＮＧ３２は取得手段の例であり、ＲＣ−ＭＮＧ３２及びＮＥ−ＣＴＲＬ３３は制御手段の例である。
（第２項）
前記制御手段は、前記トラフィック制御として、前記デバイスと前記中継サーバとの間に備えられるＣＰＥ又はエッジルータに対してシェーピング処理設定を行う
第１項に記載の制御システム。
（第３項）
前記取得手段は、前記中継サーバと前記他のデバイスの側の中継サーバとの間の通信に関する中継系通信情報を前記デバイスから取得し、
前記制御手段は、前記中継系通信情報と前記品質要求情報に基づいて、前記中継サーバと前記他のデバイスの側の中継サーバとの間のトラフィック制御を実行する
第１項又は第２項に記載の制御システム。
（第４項）
前記制御手段は、前記中継サーバと前記他のデバイスの側の中継サーバとの間のトラフィック制御として、前記中継サーバと前記他のデバイスの側の中継サーバとの間の通信経路を変更する経路制御を実行する
第１項ないし第３項のうちいずれか１項に記載の制御システム。
（第５項）
デバイスが中継サーバを介して他のデバイスとＰ２Ｐ通信を実行するネットワークにおける制御を行う制御システムが実行する制御方法であって、
前記デバイスから品質要求情報を含む接続要求を受信し、当該品質要求情報を登録する登録ステップと、
前記中継サーバから、前記Ｐ２Ｐ通信における前記デバイスと前記中継サーバとの間の通信に関する通信情報を取得する取得ステップと、
前記通信情報と前記品質要求情報に基づいて、前記デバイスと前記中継サーバとの間のトラフィック制御を実行する制御ステップと
を備える制御方法。
（第６項）
コンピュータを、第１項ないし第４項のうちいずれか１項に記載の制御システムにおける各手段として機能させるためのプログラム。
【００７４】
以上、本実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【００７５】
１、２、１２  Ｄｅｖｉｃｅ
３  インターネット
２、５、２２  ＴＵＲＮ
２２１  通信部
２２２  通信情報管理部
６  Ｐａｃｋｅｔ  Ｓｈａｐｅｒ
１０  ＣＥ
１１  ＣＰＥ
１２  Ｄｅｖｉｃｅ
１２１  接続制御部
１２２  通信部
２０  ＮＥ
２１  ＲＣ−ＢＲ
２３  ＲＣ−ＥＲ
３０  ＲＣＣ
３１  ＣＯＮＮ−ＭＮＧ
３１１  接続制御部
３１２  登録部
３２  ＲＣ−ＭＮＧ
３２１  登録部
３２２  通信制御要求部
３２３  通信確認部
３３  ＮＥ−ＣＴＲＬ
３３１  経路制御部
３３２  シェーピング制御部
３４  Ｄａｔａｂａｓｅ
【図１】
2019186907.tif 000003
【図２】
2019186907.tif 000004
【図３】
2019186907.tif 000005
【図４】
2019186907.tif 000006
【図５】
2019186907.tif 000007
【図６】
2019186907.tif 000008
【図７】
2019186907.tif 000009
【図８】
2019186907.tif 000010
【図９】
2019186907.tif 000011
【図１０】
2019186907.tif 000012
【図１１】
2019186907.tif 000013
【図１２】
2019186907.tif 000014