JP6504608B2 - 通信装置及びその制御方法並びにプログラム、並びに通信システム - Google Patents

Description

本発明は、パケット通信システムに関する。

２０１５年現在普及しているＬＴＥ（Long Term Evolution）は、３ＧＰＰ（The 3rd Generation Partnership Project）で標準化され、移動通信システムのオールＩＰ（Internet Protocol）化、下り最大１００Ｍｂｐｓ、上り最大５０Ｍｂｐｓ以上をミニマム要件にするなど、従来の移動通信システムをより高速、高機能化したものである。

ＩＥＥＥ８０２．１１規格のＷｉ−Ｆｉ（登録商標）は、利用する周波数帯や通信方式により様々な規格があり、多くの規格ではアンライセンスドバンド（免許不要の周波数帯）を用いることが特徴である。２０１４年に規格化されたＩＥＥＥ８０２．１１ａｃでは、５ＧＨｚ帯を利用し、利用帯域幅の拡大やＭＩＭＯ（Multi-Input Multi-Output）技術により１Ｇｂｐｓを超える最大速度を実現する。

また現在、３ＧＰＰではＷｉ−Ｆｉで用いられているような２．４ＧＨｚ帯や５ＧＨｚ帯といったアンライセンスバンドを用いてＬＴＥによる通信を行うＬＡＡ（Licensed-Assisted Access using LTE）や、次世代移動通信システムの５Ｇ（第５世代移動通信システム）が検討されている。５Ｇでは、既存移動通信システムよりも、さらに高速、低遅延、省電力化が要求条件として掲げられており、ミリ波のような６０ＧＨｚ以上の周波数帯利用も検討されている。

一方で、一般的なインターネットのＥｎｄ ｔｏ Ｅｎｄの通信ではＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）のプロトコルが標準的に用いられている。

現在Ｌｉｎｕｘ（登録商標）で標準となっているＴＣＰの輻輳制御アルゴリズムであるＣＵＢＩＣ（非特許文献１参照）は、一度にパケットを送れる量を表す輻輳ウィンドウサイズが、ＲＴＴ（Round Trip Time）依存ではなく、パケットロスからの経過時間に依存するため、高遅延環境でのスループットを改善する。

ＴＣＰには輻輳制御アルゴリズムの他に様々な制御が提案されており、オプションとして利用することができる。

Ｑｕｉｃｋ−Ｓｔａｒｔ（非特許文献２参照）は、送信側の要求するスループットを送受信間の全てのノードが承認すれば、要求するスループットに対応するウィンドウサイズに変更する手法である。このオプションを利用するには、送受信間の全ノードがＱｕｉｃｋ−Ｓｔａｒｔに対応している必要があるが、急速にスループットを上げることが可能となる。

ＭＰＴＣＰ（Multipath TCP）（非特許文献３参照）はＴＣＰによる通信をサブフローに分割し、複数パスを利用することでスループット向上や冗長性を高める手法である。

また非特許文献４では、ネットワーク特性やアプリケーション特性に応じてＴＣＰの他に、ＲＰＳ（Random Packet System）、ＵＮＡＰ（Universal Network Acceleration Protocol）といった独自プロトコルを切り替える手法が提案されている。

Injong Rhee, and Lisong Xu, "CUBIC: A New TCP-Friendly High-Speed TCP Variant", 2008 S. Floyd, 他３名, "Quick-Start for TCP and IP", IETF, RFC4782, 2007年1月 A. Ford, 他３名, " TCP Extensions for Multipath Operation with Multiple Addresses", IETF, RFC6824, 2013年1月 武藤亮一，小口直樹，高野陽介，朝長博，"通信環境の応じた通信プロトコルの適応的選択技術の検討"，IEICE Technical Report，IN2012-184(2013-03)

５Ｇ時代では、ヘテロジーニアス（異種混合）環境と呼ばれる、利用周波数帯やセル半径などの特性が異なる複数のＲＡＴ（Radio Access Technology）を混合して用いることが想定されている（図１参照）。利用するＲＡＴは、既存のＬＴＥやＷｉ−Ｆｉに加え、例えば、高周波のミリ波を用いた超広帯域だがセル半径が小さいものや、アンライセンスバンドを用いた安価だが高エラーレートのものが考えられる。このようなヘテロジーニアス環境では、セル半径数メートルから数百メートルのスモールセルが点在するため、電車や車での移動に伴うセルの切り替わりによって通信環境の変化が頻発すると考えられる。

前述したＴＣＰ輻輳制御アルゴリズムのＣＵＢＩＣは、大陸間通信等で課題であった広帯域でかつ高遅延な環境におけるスループットを改善しつつ、ＲＴＴや他のＴＣＰフローとの公平性を高めた手法であり、通信環境の急激な変化に合わせるように設計されたものではない。このため、ＣＵＢＩＣによる通信中にセル半径数メートルの超広帯域ＲＡＴに切り替わったとしても、輻輳が起きないようにするため急激にスループットを上げることは行わない。したがって移動中であれば帯域を十分に使い切る前にセルから抜けてしまうことが課題として挙げられる。またＣＵＢＩＣはパケットロスを輻輳と判断するため、高エラーレートのアンライセンスバンドを用いる際は、エラーによるパケットロスが頻発して不必要にスループットを下げてしまうことが課題である。

ＭＰＴＣＰは複数のネットワークを用いることができるため、冗長性を確保することはできるが、フローを分割する際は公平性を考慮して消極的な輻輳制御を行うことや、ネゴシエーションやコネクション確立などのオーバーヘッドが存在するため、急激にスループットを上げる効果は期待できない。

広帯域セルに切り替わった際は、Ｑｕｉｃｋ−Ｓｔａｒｔや、輻輳制御をしないＵＤＰ（User Datagram Protocol）を用いることで、短時間でスループットを向上させることができるが、広帯域セルを抜けると輻輳を起こす可能性がある。また高エラーレートのセルに変わった際は、パケットロスに過剰に反応しないような制御をすればスループットを保つことができる。このように環境ごとに適したプロトコルや制御は存在するが、あらゆる環境変化に全て対応できるトランスポート技術はないことが課題である。

前記非特許文献４に記載の手法は、環境に応じてプロトコルを変更することはできるが、ヘテロジーニアス環境などで複数のネットワークを利用する仕組みは考慮されていない．

本発明は、上記事情に鑑みてなされたものであり、通信環境の急激な変化に即応することができる通信装置及びその制御方法並びに通信システムを提供することにある。

上記目的を達成するために、本願発明は、パケットの送受信を行う通信装置において、ＯＳＩ７階層モデルのトランスポート層を上位レイヤと下位レイヤに分割し、下位レイヤには複数のトランスポートプロトコル処理部を配置するとともに、上位レイヤには複数のトランスポートプロトコル処理部による通信を統合管理する統合管理機能部とを備え、前記統合管理機能部は、トランスポートプロトコル処理部による通信の通信環境を監視する通信環境監視部と、前記通信環境監視部により通信環境の変化を検知すると変化した通信環境に適した１つ以上のトランスポートプロトコル処理部を選択するとともに選択した１つ以上のトランスポートプロトコル処理部による通信に切り替える通信方式選択部と、前記通信方式選択部が複数のトランスポートプロトコル処理部による通信に切り替えた際に各トランスポートプロトコル処理部によるフローに係るパケットに共通のシーケンス番号を割り当てるシーケンス番号管理部とを備えたことを特徴とする。
また、本願発明は、パケットの送受信を行う通信装置において、ＯＳＩ７階層モデルのトランスポート層を上位レイヤと下位レイヤに分割し、下位レイヤには複数のトランスポートプロトコル処理部を配置するとともに、上位レイヤには複数のトランスポートプロトコル処理部による通信を統合管理する統合管理機能部とを備え、前記統合管理機能部は、トランスポートプロトコル処理部による通信の通信環境を監視する通信環境監視部と、前記通信環境監視部により通信環境の変化を検知すると変化した通信環境に適した１つ以上のトランスポートプロトコル処理部を選択するとともに選択した１つ以上のトランスポートプロトコル処理部による通信に切り替える通信方式選択部と、前記通信方式選択部が第１のトランスポートプロトコル処理部による通信から第１及び第２のトランスポートプロトコル処理部による通信に切り替えた際に既存の第１のトランスポートプロトコル処理部によるフローに対して第２のトランスポートプロトコル処理部によるサブフローを追加するサブフロー追加部とを備えたことを特徴とする。
また、本願発明は、パケットの送受信を行う通信装置において、ＯＳＩ７階層モデルのトランスポート層を上位レイヤと下位レイヤに分割し、下位レイヤには複数のトランスポートプロトコル処理部を配置するとともに、上位レイヤには複数のトランスポートプロトコル処理部による通信を統合管理する統合管理機能部とを備え、前記統合管理機能部は、トランスポートプロトコル処理部による通信の通信環境を監視する通信環境監視部と、前記通信環境監視部により通信環境の変化を検知すると変化した通信環境に適した１つ以上のトランスポートプロトコル処理部を選択するとともに選択した１つ以上のトランスポートプロトコル処理部による通信に切り替える通信方式選択部と、前記通信方式選択部が選択した第１のトランスポートプロトコル処理部が再送制御を有しない場合に第２のトランスポートプロトコル処理部に係る通信経路を利用して前記第１のトランスポートプロトコル処理部におけるパケットの再送制御を行う再送制御部とを備えたことを特徴とする。

本発明によれば、ＲＡＴ等の通信環境の変化を検知したとき、環境に合ったトランスポートプロトコルに切り替えることで、超広帯域になった際は短時間でスループットを最大化する、高エラーレートになった際は不必要にスループットを下げないといった、それぞれの環境下でＱｏＳを最大化する制御が可能となる。超広帯域を短時間で利用できることにより、移動中でもスモールセルを利用して大容量ファイルのダウンロード等が実現できる。スモールセルを有効利用することで通信トラフィックを分散させることができ、ＬＴＥのようなライセンスバンドの混雑を避けることができる。また複数のＲＡＴを併用することで冗長性が高く、移動時にセルの切り替えが頻発するヘテロジーニアス環境においても安定した通信を維持することができる。

さらに、トランスポート層でプロトコル切り替えの制御を行うため、アプリケーション側で通信環境の変化に応じた制御を行う必要がなくなる。

ヘテロジーニアス環境を説明する図 無線通信システムの構成図 他の例に係る無線通信システムの構成図 トランスポート処理部の構成図 パケットヘッダの構成例 通信方式データベースの構成例 統合管理機能部の動作を説明するフローチャート 統合管理機能部によりＵＤＰで再送処理を実施する場合のイメージ図 実施例１に係る無線通信システムの構成図及びシーケンス図 実施例２に係る無線通信システムの構成図及びシーケンス図 実施例３に係る無線通信システムの構成図及びシーケンス図

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

本実施の形態に係る通信システムは、図２に示すように、複数の通信方式に対応した端末１００と、各通信方式で端末１００を収容するための複数のアクセス機能２００と、各通信方式における複数のパケットコアネットワーク３００と、各パケットコアネットワーク３００と接続したＩＰサービスネットワーク４００と、端末１００との通信相手先でありＩＰサービスネットワーク４００に接続したサーバ５００とを備えている。他の変形例としては、図３に示すように、端末１００はプロキシ６００を介してサーバ５００と通信を行う構成が考えられる。

本願発明の特徴点は、後述するように、ＯＳＩ参照モデルのトランスポート層処理部７００であって、端末１００とサーバ５００又はプロキシ６００との間のトランポート層コネクションを終端するものの機能にある。当該トランスポート層処理部７００は、図２の構成例の場合は端末１００及びサーバ５００に実装され、図３の構成例の場合は端末１００及びプロキシ６００のＩＰサービスネットワーク４００側（端末１００側）に実装される。プロキシ６００を利用する場合、サーバ５００には改造・変更等を加えることなく本発明を実施することができる点で有利である。

アクセス機能２００・パケットコアネットワーク３００・ＩＰサービスネットワーク４００の構成、及び、各装置による全体構成については従来周知のものである。前記複数の通信方式としては、例えばＬＴＥ、Ｗｉ−Ｆｉ、有線イーサネット（登録商標）などが挙げられる。前記複数のアクセス機能２００は、それぞれの通信方式に対応するものであり、例えばＬＴＥの場合には無線区間のネットワークであるＥ−ＵＴＲＡＮ（Evolved Universal Terrestrial Radio Access Network）を構成するｅＮｏｄｅＢなどの各装置が含まれる。前記複数のパケットコアネットワーク３００も、それぞれの通信方式に対応するものであり、例えばＬＴＥの場合にはＥＰＣ（Evolved Packet Core）である。なお、１つのパケットコアネットワーク３００に通信方式の異なる又は同じ複数のアクセス機能２００が収容される場合もある点に留意されたい（例えば、キャリアアグリケーションやデュアルコネクティビティが適用されている場合）。

トランスポート層処理部７００は、図２及び図３に示すように、ＯＳＩ参照モデルのトランスポート層における通信の両終端に位置するトランスポート層処理部７００を上位層と下位層に分割し、下位層には複数のトランスポートプロトコル処理部８００を並列配置し、上位層には複数のトランスポートプロトコル処理部８００を統合管理する統合管理機能部９００を配置した。なお、このトランスポート層処理部７００は、基本的な構成は、端末１００・サーバ５００・プロキシ６００とで共通である。また、端末１００・サーバ５００・プロキシ６００において、ＯＳＩ参照モデルのトランスポート層以外の層の構成は任意であり、従来周知の構成をとることができる。

トランスポート層処理部７００の構成について、図４を参照して説明する。トランスポート層処理部７００の上位層である統合管理機能部９００は、複数の異なるトランスポートプロトコルを管理し、通信環境にあったトランスポートプロトコルを動的に切り替える機能を有する。特性に合ったプロトコルの決定方法は、例えばデータベースに登録しておく方法がある。また、統合管理機能部９００は、トランスポート層におけるフローを分割し、複数の異なるネットワークの利用を可能とする機能を有する。ここで、分割したフローは、それぞれ別々のプロトコルを割り当てることができる。また、統合管理機能部９００は、異なるプロトコル間で継続性を担保できる仕組みを持つ。具体的には、共通のシーケンス番号と、サブフロー毎のサブシーケンス番号を割り振る機能、ＴＣＰにおける輻輳ウィンドウサイズなどのパケット伝送レートを通知する機能を備える。通信方式変更のネゴシエーションはプロトコルヘッダで行う。また、統合管理機能部９００は、ＵＤＰのような再送制御を持たないプロトコルを、ＴＣＰ等の他のプロトコルにより再送する制御をトランスポート層で実施する機能を有する。

以上の機能の実装例を図４に示す。統合管理機能部９００は、図４に示すように、通信環境の変化を検知する通信環境監視部９１０と、変化後の環境に適したプロトコルを選択する通信方式選択部９２０と、複数ＲＡＴを利用する際に、サブフローの追加・削除を行うサブフロー制御部９３０と、複数フローを用いる際の共通するシーケンス番号を割り当てるシーケンス番号管理部９４０と、ＵＤＰ等の再送制御を持たないプロトコルを利用する際の再送制御を行う再送制御部９５０と、通信環境と通信方式を関連付ける通信方式データベース９６０と、送信バッファ９７０と、受信バッファ９８０とを備える。なお、後述するように、本通信システムにおける実施例によって前記通信方式データベース９６０は、端末１００側或いはサーバ５００又はプロキシ６００側にのみ備えればよい。

統合管理機能部９００の下位層に配置された複数のトランスポートプロトコル処理部８００は、従来周知のものを含めて任意のプロトコル及びそのオプションを用いることができる。例えば、ＴＣＰ Ｒｅｎｏ、 ＣＵＢＩＣ、ＨｉｇｈＳｐｅｅｄ ＴＣＰ、ＦＡＳＴ ＴＣＰなど任意の輻輳制御アルゴリズム、Ｑｕｉｃｋ−Ｓｔａｒｔ、ＭＰＴＣＰ、ＳＡＣＫ（Selective Acknowledgement）等のＴＣＰオプションなど種々の形態のＴＣＰの他、ＵＤＰ、ＳＣＴＰ（Stream Control Transmission Protocol）、ＱＵＩＣ（Quick UDP Internet Connections）等のＴＣＰ以外のトランスポートプロトコルが挙げられる。ここで、前述したように、統合管理機能部９００は再送制御部９５０を備えているため、ＵＤＰ等の再送制御を持たないプロトコルもトランスポートプロトコル処理部８００として実装可能である。

上記統合管理機能部９００により通信方式を変更する方法について詳述する。なお、ここで通信方式の変更とは、あるトランスポートプロトコル処理部８００から他のトランスポートプロトコル処理部８００に切り替えることを意味するだけでなく、あるトランスポートプロトコル処理部８００を用いた通信中に他のトランスポートプロトコル処理部８００のフローを追加することも含む。すなわち、ある時点の前後でトランスポートプロトコル処理部８００の利用状況が異なること全てが「通信方式の変更」を意味する。以下の説明では、フローを追加した場合、当該追加フローのことをサブフローと呼ぶ。

本発明では、通信環境監視部９１０による通信環境の変化の検知は、既存の手法を用いる。受信側で感知する、あるいはアクセス機能２００の基地局から情報を送信側で取得する等が考えられる。

通信方式の変更は送信側の通信方式選択部９２０が決定する場合と、受信側の通信方式選択部９２０が通信方式を要求する場合が考えられる。

通信方式の通知、要求、ネゴシエーション等は各トランスポートプロトコル処理部８００におけるプロトコルヘッダのオプション領域を用いて行う方法と、本願の統合管理機能専用のヘッダを用いて行う方法が考えられる。各プロトコルヘッダのオプション領域を利用する場合、ＵＤＰ等のオプション領域がないものはヘッダの拡張を行う必要がある。ヘッダの構成例を図５に示す。タイプ番号には、ネゴシエーション時、パケット転送時、などオプション領域の利用方法を識別する番号が入る。ネゴシエーション時には、送受信ＩＰアドレス、利用ＲＡＴ、利用プロトコルなどの通知を行い、パケット転送時にはサブシーケンス番号の管理を行う。

通信方式選択部９２０による通信方式の決定法は、例えば通信環境とプロトコルを関連付ける通信方式データベース９６０を利用する方法がある。通信方式データベース９６０の構成例を図６に示す。

送信側（ダウンロードの際はサーバ５００又はプロキシ６００、アップロードの際は端末１００）の統合管理機能部９００が通信方式を選択する場合は、図７の処理を行う。

すなわち、図７に示すように、統合管理機能部９００は、通信環境監視部９１０により利用可能なＲＡＴの状況などの通信環境を監視して通信環境の変化を検知すると（ステップＳ１）、通信方式データベース９６０を参照する（ステップＳ２）。そして、通信方式選択部９２０が、通信方式の変更を行うか否かを判定し（ステップＳ３）、変更がない場合には元の通信を継続する（ステップＳ４）。一方、変更がある場合、サブフローを利用する場合には（ステップＳ５）、フロー追加のネゴシエーション処理を行い（ステップＳ６）、シーケンス番号管理部９４０によりシーケンス割当を行い（ステップＳ７）、通信方式を変更する（ステップＳ８）。サブフローを利用しない場合にも、通信方式を変更する（ステップＳ９）。

受信側の統合管理機能部９００で通信方式を選択する場合は、図７において通信方式変更の代わりに受信側の統合管理機能部９００から送信側の統合管理機能部９００へ通信方式変更要求を行う。送信側の統合管理機能部９００が承認すれば、方式を変更して通信を行う。

次に、上記統合管理機能部９００により異なるプロトコル間の継続性を担保する方法について詳述する。

異なるプロトコルを切り替えても通信の継続性を担保するために、統合管理機能部９００はプロトコルヘッダを利用して次のことを行う。

・全プロトコル共通のシーケンス番号とサブフロー毎のサブシーケンス番号割当
・フロー追加・削除やプロトコル変更のネゴシエーション
・パケット伝送レートなど現在設定されているパラメータを変更後の通信方式への引き継ぎ
・再送制御のないプロトコルを利用する場合の到達確認

また、上記統合管理機能部９００によりＵＤＰ等の再送がないプロトコルをＴＣＰ等で補完する機能について詳述する。

ＵＤＰではパケットの到達順序を保障しないので、統合管理機能部９００に受信バッファ９８０を設け、再送制御部９５０においてパケットの整列及び到達確認応答を行う。到達確認応答は信頼性の高いＴＣＰ等を用いて行い、確認の頻度はバッファ容量に応じて変更する。ＴＣＰとＵＤＰを併用している際は、ＴＣＰのＡＣＫパケットを用いてＵＤＰの確認応答を行うことで、効率化できる。図８に端末１００とプロキシ６００に統合管理機能部９００を具備した場合の再送のイメージを示す。

本発明の実施例１について図９を参照して説明する。本実施例は、他事業者ネットワークのサーバ又はプロキシ側で通信方式決定する場合の例である。また、ここでは端末１００とプロキシ６００側とが通信する場合であって、プロキシ６００から端末１００にパケットを送信する場合を例にとって説明する。

図９に示すように、アクセス機能２００であるＲＡＴ１及びＲＡＴ２は、それぞれ異なるパケットコアネットワーク３００に収容されているものとする。ここで、ＲＡＴ１のセルは広いが通信帯域が狭く、ＲＡＴ２のセルはＲＡＴ１より狭く且つＲＡＴ１のセルに包含されるとともに、ＲＡＴ１よりも通信帯域が広いものとする。端末１００及びプロキシ６００は、統合管理機能部９００を備えているものとする。本例では、プロキシ６００の統合管理機能部９００の通信方式データベース９６０を参照する。

端末１００とプロキシ６００との間で、マクロセルのＲＡＴ１を介してＴＣＰ１による通信中に（ステップＳ１，Ｓ２）、端末１００の統合管理機能部９００で広帯域セルのＲＡＴ２を検知すると（ステップＳ３）、端末１００の統合管理機能部９００はその旨をプロキシ６００の統合管理機能部９００に通知し（ステップＳ４）、プロキシ６００の統合管理機能部９００は通信方式データベース９６０を参照する（ステップＳ５）。なお、端末１００とプロキシ６００との通信中又は通信開始時には、予め、両者で統合管理機能部９００が利用可能である旨を確認しておく（ステップＳ２）。

そしてプロキシ６００の統合管理機能部９００は、例えばＲＡＴ１ではＴＣＰ１による通信、ＲＡＴ２ではＵＤＰによる通信をする方式を選択すると、方式変更のネゴシエーションを行う（ステップＳ６）。具体的には、プロキシ６００の統合管理機能部９００でサブフローの生成とシーケンスの分配を行い、端末１００側に利用する通信方式を通知する。そして、端末１００の統合管理機能部９００は、新たな通信方式が利用可能であればポート解放、コネクション確立を行う。この際、予めＲＡＴ１による通信においてｃｏｏｋｉｅの取得などのネゴシエーションを行っておくことでコネクション確立を短縮することができる。

なお、シーケンスの分配方法は、単純にシーケンス番号の連続したパケットを割り当てる方法や、数パケット毎にブロックを構成し、ブロック毎にフローに割り当てる方法などが考えられる。

以降の送信パケットは、ＲＡＴ２を介したＵＤＰによるフローと、ＲＡＴ１を介したＴＣＰ１によるフローにより送信される（ステップＳ７〜Ｓ９）。ここで、ＵＤＰは再送制御を行わないので、ＲＡＴ１を介したＴＣＰ１のＡＣＫパケットでＴＣＰ１及びＵＤＰフローの確認応答を行い（ステップＳ１０）、必要に応じてＲＡＴ１を介してＴＣＰ１によりパケットの再送を行う（ステップＳ１１）。

本発明の実施例２について図１０を参照して説明する。本実施例は、他事業者ネットワークの端末側で通信方式決定する場合の例である。また、ここでは端末１００とプロキシ６００側とが通信する場合であって、プロキシ６００から端末１００にパケットを送信する場合を例にとって説明する。

図１０に示すように、アクセス機能２００であるＲＡＴ１及びＲＡＴ２は、それぞれ異なるパケットコアネットワーク３００に収容されているものとする。ここで、ＲＡＴ１のセルは広いが通信帯域が狭く、ＲＡＴ２のセルはＲＡＴ１より狭く且つＲＡＴ１のセルに包含されるとともに、ＲＡＴ１よりも通信帯域が広いものとする。端末１００及びプロキシ６００は、統合管理機能部９００を備えているものとする。本例では、端末１００の統合管理機能部９００の通信方式データベース９６０を参照する。

端末１００とプロキシ６００との間で、マクロセルのＲＡＴ１を介してＴＣＰ１による通信中に（ステップＳ２１，Ｓ２２）、端末１００の統合管理機能部９００で広帯域セルのＲＡＴ２を検知すると（ステップＳ２３）、端末１００の統合管理機能部９００は通信方式データベース９６０を参照する（ステップＳ２４）。なお、端末１００とプロキシ６００との通信中又は通信開始時には、予め、両者で統合管理機能部９００が利用可能である旨を確認しておく（ステップＳ２２）。

端末１００の統合管理機能部９００は、例えばＲＡＴ１ではＴＣＰ１による通信、ＲＡＴ２ではＵＤＰによる通信をする方式を選択すると、通信方式変更の要求をプロキシ６００の統合管理機能部９００に通知する（ステップＳ２５）。プロキシ６００の統合管理機能部９００は、通信方式の変更が可能であるかを確認すると（ステップＳ２６）、端末１００の統合管理機能部９００に対して通信方式変更を承認する（ステップＳ２７）。

以降の送信パケットは、ＲＡＴ２を介したＵＤＰによるフローと、ＲＡＴ１を介したＴＣＰ１によるフローにより送信される（ステップＳ２８〜Ｓ３０）。ここで、ＵＤＰは再送制御を行わないので、ＲＡＴ１を介したＴＣＰ１のＡＣＫパケットでＴＣＰ１及びＵＤＰフローの確認応答を行い（ステップＳ３１）、必要に応じてＲＡＴ１を介してＴＣＰ１によりパケットの再送を行う（ステップＳ３２）。

本発明の実施例３について図１１を参照して説明する。本実施例は、同一事業者ネットワークでＣＡ（キャリアアグリゲーション）やＤＣ（デュアルコネクティビティ）を行う場合の例である。すなわち、複数のアクセス機能２００が同一のパケットコアネットワーク３００に収容され、複数のアクセス機能２００を使ってトラフィックを統合する環境が既に構築されている場合において、本願発明を適用する例である。

このようにＣＡ・ＤＣの場合、統合管理機能部９００でフローを分割しても、アクセス機能２００内の基地局のＰＤＣＰ（Packet Data Convergence Protocol）レイヤで無線リソースの割当が行われてしまう。したがって、基地局の特性を考慮してフローの分割を行う場合、ＰＤＣＰレイヤと連携してフローのルーティングをする必要がある。ＣＡ・ＤＣの場合でも、帯域やエラー率の変化を検知して、プロトコルを選択することでＱｏＳ（Quality of Service）の改善を行うことは可能である。

図１１は、ＴＣＰ１からＴＣＰ２へ変更するシーケンスを示している。図１１に示すように、端末１００とプロキシ６００との間で、マクロセルのＲＡＴ１を介してＴＣＰ１による通信中に（ステップＳ４１，Ｓ４２）、端末１００の統合管理機能部９００が当該通信の帯域追加を検知すると（ステップＳ４３）、通信方式データベース９６０を参照する（ステップＳ４４）。なお、端末１００とプロキシ６００との通信中又は通信開始時には、予め、両者で統合管理機能部９００が利用可能である旨を確認しておく（ステップＳ４２）。

端末１００の統合管理機能部９００は、ＴＣＰ１からＴＣＰ２への通信方式の変更要求をプロキシ６００の統合管理機能部９００に通知する（ステップＳ４５）。プロキシ６００の統合管理機能部９００は、通信方式の変更が可能であるかを確認すると（ステップＳ４６）、端末１００の統合管理機能部９００に対して通信方式変更を承認する（ステップＳ４７）。

以降の送信パケットは、ＴＣＰ２によるフローにより送信される（ステップＳ４８，Ｓ４９）。

以上のように、本実施の形態に係る通信システムによれば、ＲＡＴ等の通信環境の変化を検知したとき、環境に合ったトランスポートプロトコルに切り替えることで、超広帯域になった際は短時間でスループットを最大化する、高エラーレートになった際は不必要にスループットを下げないといった、それぞれの環境下でＱｏＳを最大化する制御が可能となる。超広帯域を短時間で利用できることにより、移動中でもスモールセルを利用して大容量ファイルのダウンロード等が実現できる。スモールセルを有効利用することで通信トラフィックを分散させることができ、ＬＴＥのようなライセンスバンドの混雑を避けることができる。また複数のＲＡＴを併用することで冗長性が高く、移動時にセルの切り替えが頻発するヘテロジーニアス環境においても安定した通信を維持することができる。

さらに、トランスポート層でプロトコル切り替えの制御を行うため、アプリケーション側で通信環境の変化に応じた制御を行う必要がなくなる．
以上、本発明の実施の形態及びその実施例について詳述したが、本発明はこれに限定されるものではない。例えば、上記実施の形態で列挙したトランスポートプロトコルはその一例であって、他のトランスポートプロトコルであっても本発明を実施できる。また、例えば通信環境の変化の検出手法や、通信方式データベースのデータ構造などについても、上記実施の形態に限定されるものではない。

また、上記実施の形態では、アクセス機能２００について主に無線アクセス機能について例示したが、アクセス機能２００及びアクセス機能２００と接続したパケットコアネットワーク３００の形態は不問であり、例えば光ファイバなど有線アクセス機能が混在していても本発明を実施することができる。

１００…端末
２００…アクセス機能
３００…パケットコアネットワーク
４００…ＩＰサービスネットワーク
５００…サーバ
６００…プロキシ
７００…トランスポート層処理部
８００…トランスポートプロトコル処理部
９００…統合管理機能部
９１０…通信環境監視部
９２０…通信方式選択部
９３０…サブフロー制御部
９４０…シーケンス番号管理部
９５０…再送制御部
９６０…通信方式データベース
９７０…送信バッファ９７０
９８０…受信バッファ９８０

Claims (7)

1. パケットの送受信を行う通信装置において、
   ＯＳＩ７階層モデルのトランスポート層を上位レイヤと下位レイヤに分割し、下位レイヤには複数のトランスポートプロトコル処理部を配置するとともに、上位レイヤには複数のトランスポートプロトコル処理部による通信を統合管理する統合管理機能部とを備え、
   前記統合管理機能部は、トランスポートプロトコル処理部による通信の通信環境を監視する通信環境監視部と、前記通信環境監視部により通信環境の変化を検知すると変化した通信環境に適した１つ以上のトランスポートプロトコル処理部を選択するとともに選択した１つ以上のトランスポートプロトコル処理部による通信に切り替える通信方式選択部と、前記通信方式選択部が複数のトランスポートプロトコル処理部による通信に切り替えた際に各トランスポートプロトコル処理部によるフローに係るパケットに共通のシーケンス番号を割り当てるシーケンス番号管理部とを備えた
   ことを特徴とする通信装置。
2. パケットの送受信を行う通信装置において、
   ＯＳＩ７階層モデルのトランスポート層を上位レイヤと下位レイヤに分割し、下位レイヤには複数のトランスポートプロトコル処理部を配置するとともに、上位レイヤには複数のトランスポートプロトコル処理部による通信を統合管理する統合管理機能部とを備え、
   前記統合管理機能部は、トランスポートプロトコル処理部による通信の通信環境を監視する通信環境監視部と、前記通信環境監視部により通信環境の変化を検知すると変化した通信環境に適した１つ以上のトランスポートプロトコル処理部を選択するとともに選択した１つ以上のトランスポートプロトコル処理部による通信に切り替える通信方式選択部と、前記通信方式選択部が第１のトランスポートプロトコル処理部による通信から第１及び第２のトランスポートプロトコル処理部による通信に切り替えた際に既存の第１のトランスポートプロトコル処理部によるフローに対して第２のトランスポートプロトコル処理部によるサブフローを追加するサブフロー追加部とを備えた
   ことを特徴とする通信装置。
3. パケットの送受信を行う通信装置において、
   ＯＳＩ７階層モデルのトランスポート層を上位レイヤと下位レイヤに分割し、下位レイヤには複数のトランスポートプロトコル処理部を配置するとともに、上位レイヤには複数のトランスポートプロトコル処理部による通信を統合管理する統合管理機能部とを備え、
   前記統合管理機能部は、トランスポートプロトコル処理部による通信の通信環境を監視する通信環境監視部と、前記通信環境監視部により通信環境の変化を検知すると変化した通信環境に適した１つ以上のトランスポートプロトコル処理部を選択するとともに選択した１つ以上のトランスポートプロトコル処理部による通信に切り替える通信方式選択部と、前記通信方式選択部が選択した第１のトランスポートプロトコル処理部が再送制御を有しない場合に第２のトランスポートプロトコル処理部に係る通信経路を利用して前記第１のトランスポートプロトコル処理部におけるパケットの再送制御を行う再送制御部とを備えた
   ことを特徴とする通信装置。
4. 前記統合管理機能部は、通信環境とトランスポートプロトコル処理部とを関連づけた情報を記憶する通信方式記憶部を備え、
   前記通信方式選択部は、前記通信方式記憶部に記憶された関連情報に基づき１つ以上のトランスポートプロトコル処理部を選択する
   ことを特徴とする請求項１乃至３何れか１項記載の通信装置。
5. パケットの送受信を行う通信装置における通信制御方法であって、
   ＯＳＩ７階層モデルのトランスポート層を上位レイヤと下位レイヤに分割し、下位レイヤには複数のトランスポートプロトコル処理部を配置するとともに、上位レイヤには複数のトランスポートプロトコル処理部による通信を統合管理する統合管理機能部とを設け、
   前記統合管理機能部の通信環境監視部が、トランスポートプロトコル処理部による通信の通信環境を監視し、
   前記統合管理機能部の通信方式選択部が、前記通信環境監視部により通信環境の変化を検知すると変化した通信環境に適した１つ以上のトランスポートプロトコル処理部を選択するとともに選択した１つ以上のトランスポートプロトコル処理部による通信に切り替え、
   前記統合管理機能部のシーケンス番号管理部が、前記通信方式選択部が複数のトランスポートプロトコル処理部による通信に切り替えた際に各トランスポートプロトコル処理部によるフローに係るパケットに共通のシーケンス番号を割り当てる
   ことを特徴とする通信装置における通信制御方法。
6. コンピュータを、請求項１乃至４の何れか１項に記載の統合管理機能部として動作させるためのプログラム。
7. パケットの送受信を行う端末と、アクセス機能により前記端末を収容したネットワークと、端末のトランスポート層における通信相手先となる通信装置と備えた通信システムであって、
   前記端末及び通信装置は、
   ＯＳＩ７階層モデルのトランスポート層を上位レイヤと下位レイヤに分割し、下位レイヤには複数のトランスポートプロトコル処理部を配置するとともに、上位レイヤには複数のトランスポートプロトコル処理部による通信を統合管理する統合管理機能部とを備え、
   前記統合管理機能部は、トランスポートプロトコル処理部による通信の通信環境を監視する通信環境監視部と、前記通信環境監視部により通信環境の変化を検知すると変化した通信環境に適した１つ以上のトランスポートプロトコル処理部を選択するとともに選択した１つ以上のトランスポートプロトコル処理部による通信に切り替える通信方式選択部と、前記通信方式選択部が複数のトランスポートプロトコル処理部による通信に切り替えた際に各トランスポートプロトコル処理部によるフローに係るパケットに共通のシーケンス番号を割り当てるシーケンス番号管理部とを備えた
   ことを特徴とする通信システム。

Images