(57)【要約】  他の通信装置からパケットを受信し、前記パケットを受信したことを示す受信確認パケットを作成し、前記作成した受信確認パケットを送信バッファに格納するように制御する制御部と、前記送信バッファに格納されている受信確認パケットの一部を前記他の通信装置に送信し、前記送信した受信確認パケット以外の受信確認パケットを前記他の通信装置に送信しない送受信部とを有する。
2017145227.tif 000002
【特許請求の範囲】
【請求項１】
他の通信装置からパケットを受信し、前記パケットを受信したことを示す受信確認パケットを作成し、前記作成した受信確認パケットを送信バッファに格納するように制御する制御部と、
前記送信バッファに格納されている受信確認パケットの一部を前記他の通信装置に送信し、前記送信した受信確認パケット以外の受信確認パケットを前記他の通信装置に送信しない送受信部とを有する
通信装置。
【請求項２】
前記一部の受信確認パケットは、最後に受信したパケットに対する受信確認パケットを含む
請求項１記載の通信装置。
【請求項３】
前記受信確認パケットは、対応するパケットの送信順を示す対応パケット番号を含み、
さらに、前記受信確認パケットを受信したとき、前回受信した受信確認パケットの対応パケット番号と、今回受信した受信確認パケットの対応パケット番号の差分から、未受信の受信確認パケットの数を算出し、前記算出した数が第１差分数の場合、パケットの送信データ量を第１データ量だけ増加させ、前記算出した数が、前記第１差分数より大きい第２差分数の場合、パケットの送信データ量を前記第１データ量より大きい第２データ量だけ増加させる受信確認受信処理部を有する
請求項２記載の通信装置。
【請求項４】
前記一部の受信確認パケットは、最後に受信したパケットに対する受信確認パケットを含み、
前記送受信部は、前記一部の受信確認パケットの数を、前記受信確認パケットを含むパケットを送信するために割り当てられた送信リソースの割当量に応じて増減する
請求項１記載の通信装置。
【請求項５】
前記送受信部は、前記送信リソースが第１の割当量の場合、第１の数の受信確認パケットを送信し、前記送信リソースが前記第１の割当量より大きい第２の割当量の場合、第１の数より大きい第２の数の受信確認パケットを送信する
請求項４記載の通信装置。
【請求項６】
前記割当量は、前記送信に使用する周波数の帯域幅である
請求項５記載の通信装置。
【請求項７】
さらに、前記受信確認パケットを受信するごとに、パケットの送信データ量を増加させる受信確認受信処理部を有する
請求項４または５記載の通信装置。
【請求項８】
さらに、輻輳ウィンドウのサイズに基づいて前記送信データ量を決めるパケット送信処理部を有し、
前記受信確認受信処理部は、前記送信データ量を増加させるとき、前記輻輳ウィンドウのサイズを拡張する
請求項３または７記載の通信装置。
【請求項９】
前記送受信部は、前記受信確認パケットの送信を、前記他の通信装置からのパケット受信と非同期に行う
請求項１記載の通信装置。
【請求項１０】
さらに、第１の通信装置と第２の通信装置の間で送受信されるパケットを中継するパケット中継部を有し、
前記パケット中継部は、前記第１の通信装置から受信した受信確認パケットの対応するパケットの送信順を示す対応パケット番号に基づいて、前記第１の通信装置から前記第２の通信装置に送信されない受信確認パケットの対応パケット番号を算出し、前記算出した対応パケット番号のパケットに対応する追加の受信確認パケットを作成し、前記中継する受信確認パケットに加えて、前記作成した追加の受信確認パケットを前記第２の通信装置に送信する
請求項１記載の通信装置。
【請求項１１】
第１の通信装置と、前記第１の通信装置にパケットを送信する第２の通信装置との間で送受信するパケットを中継するパケット中継部を有し、
前記第１の通信装置は、前記パケットを受信したことを示す受信確認パケットを作成し、前記作成した受信確認パケットを送信バッファに格納し、前記送信バッファに格納されている受信確認パケットの一部を前記第２の通信装置に送信し、前記送信した受信確認パケット以外の受信確認パケットを前記第２の通信装置に送信せず、
さらに、前記中継する受信確認パケットの対応するパケットの送信順を示す対応パケット番号に基づいて、前記第１の通信装置から前記第２の通信装置に送信されない受信確認パケットの対応パケット番号を算出し、前記算出した対応パケット番号のパケットに対応する追加の受信確認パケットを作成し、前記中継する受信確認パケットに加えて、前記作成した追加の受信確認パケットを前記第２の通信装置に送信する受信確認処理部を有する
パケット中継装置。
【請求項１２】
第１の通信装置にパケットを送信する第２の通信装置と、
前記パケットを受信したことを示す受信確認パケットを作成し、前記作成した受信確認パケットを送信バッファに格納し、前記送信バッファに格納されている受信確認パケットの一部を前記第２の通信装置に送信し、前記送信した受信確認パケット以外の受信確認パケットを前記第２の通信装置に送信しない第１の通信装置とを有する
通信システム。
【請求項１３】
さらに、前記第１及び第２の通信装置間を送受信するパケットを中継するパケット中継装置を有し、
前記パケット中継装置は、前記第１の通信装置から受信した受信確認パケットの対応するパケットの送信順を示す対応パケット番号に基づいて、前記第１の通信装置から前記第２の通信装置に送信されない受信確認パケットの対応パケット番号を算出し、前記算出した対応パケット番号のパケットに対応する追加の受信確認パケットを作成し、前記中継する受信確認パケットに加えて、前記作成した追加の受信確認パケットを前記第２の通信装置に送信する
請求項１２記載の通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置、中継装置、及び通信システムに関する。
【背景技術】
【０００２】
現在、標準化団体である３ＧＰＰ（3rd Generation Partnership Project）では、ＬＴＥ（Long Term Evolution）システムや、ＬＴＥシステムをベースとしたＬＴＥ−Ａ（LTE-Advanced）システムの仕様が完了又は検討されている。【０００３】
ＬＴＥにおけるデータ通信においては、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）と呼ばれる通信プロトコルが用いられる場合がある。ＴＣＰ／ＩＰは、ＴＣＰとＩＰとを組み合わせたプロトコルであり、インターネットなどで標準的に用いられている。【０００４】
ＴＣＰにおける通信は、送信側の通信装置がＴＣＰパケットを送信し、受信側の通信装置はＴＣＰパケットを正常に受信できたとき、受信したＴＣＰパケットに対する受信確認のＡＣＫ（Acknowledgement）を返信する。送信側の通信装置はＡＣＫを受信し、次のＴＣＰパケットを送信する。このように、ＴＣＰにおける通信では、ＡＣＫを受信することで、ＴＣＰパケットが到達したことを確認することができ、信頼性のある通信を実現している。【０００５】
ＬＴＥ及びＴＣＰ／ＩＰに関する技術については、以下の先行技術文献に記載されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００４―１８０３１５号公報
【特許文献２】特開２０００―２９５２７８号公報
【特許文献３】特開２０１４―１７５６８号公報
【非特許文献】
【０００７】
【非特許文献１】3GPP TS36.300 V13.2.0(2015-12)
【非特許文献２】3GPP TS36.211 V13.0.0(2015-12)
【非特許文献３】3GPP TS36.212 V13.0.0(2015-12)
【非特許文献４】3GPP TS36.213 V13.0.0(2015-12)
【非特許文献５】3GPP TS36.321 V13.0.0(2015-12)
【非特許文献６】3GPP TS36.322 V13.0.0(2015-12)
【非特許文献７】3GPP TS36.323 V13.0.0(2015-12)
【非特許文献８】3GPP TS36.331 V13.0.0(2015-12)
【非特許文献９】3GPP TR36.881 V0.5.0 (2015-11)
【非特許文献１０】3GPP TS23.203 V13.1.0 (2014-12)
【非特許文献１１】3GPP TR36.814 V9.0.0 (2010-3)
【非特許文献１２】RFC793 (1981-05)
【非特許文献１３】RFC896 (1984-01)
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかし、ＴＣＰの通信において、ＡＣＫの送信が多くなると、ＡＣＫの送信で通信リソースが使用され、他の送信すべきデータの通信速度が低下する場合がある。特に通信リソースが不足すると、ＡＣＫの滞留により通信遅延が発生し、データの通信速度が低下する場合がある。また、ＡＣＫの送信数が多くなると、無線区間における干渉量も増加する。【０００９】
そこで、開示の一つの目的は、ＡＣＫ送信による通信速度の低下を防止する通信装置を提供することにある。
【課題を解決するための手段】
【００１０】
他の通信装置からパケットを受信し、前記パケットを受信したことを示す受信確認パケットを作成し、前記作成した受信確認パケットを送信バッファに格納するように制御する制御部と、前記送信バッファに格納されている受信確認パケットの一部を前記他の通信装置に送信し、前記送信した受信確認パケット以外の受信確認パケットを前記他の通信装置に送信しない送受信部とを有する。
【発明の効果】
【００１１】
一開示は、ＡＣＫ送信による通信速度の低下を防止する通信装置を提供することにある。
【図面の簡単な説明】
【００１２】
【図１】図１は、通信システム１０の構成例を示す図である。
【図２】図２は、通信システム１０の構成例を示す図である。
【図３】図３は、通信装置１００の構成例を示す図である。
【図４】図４は、通信装置におけるパケット送受信のシーケンスの例を示す図である。
【図５】図５は、パケット受信処理の処理フローチャートの例を示す図である。
【図６】図６は、受信確認送信処理の処理フローチャートの例を示す図である。
【図７】図７は、通信装置１００−１における、送信バッファの例を示す図である。
【図８】図８は、受信確認受信処理の処理フローチャートの例を示す図である。
【図９】図９は、通信装置におけるパケット送受信のシーケンスの例を示す図である。
【図１０】図１０は、受信確認送信処理の処理フローチャートの例を示す図である。
【図１１】図１１は、通信装置１００−１における、送信バッファの例を示す図である。
【図１２】図１２は、受信確認受信処理の処理フローチャートの例を示す図である。
【図１３】図１３は、中継装置２００の構成例を示す図である。
【図１４】図１４は、通信装置１００の構成例を示す図である。
【図１５】図１５は、中継装置２００によるパケット中継処理のシーケンスの例を示す図である。
【図１６】図１６は、パケット中継処理の処理フローチャートの例を示す図である。
【図１７】図１７は、通信システムにおけるプロトコルスタックの例を示す図である。
【図１８】図１８は、ベアラ設定処理の処理フローチャートの例を示す図である。
【図１９】図１９は、受信確認送信処理をシミュレーションしたときの、ＡＣＫの送信数及び下りのスループットをグラフ化した図である。
【発明を実施するための形態】
【００１３】
以下、本実施の形態について図面を参照して詳細に説明する。本明細書における課題及び実施例は一例であり、本願の権利範囲を限定するものではない。特に、記載の表現が異なっていたとしても技術的に同等であれば、異なる表現であっても本願の技術を適用可能であり、権利範囲を限定するものではない。
【００１４】
［第１の実施の形態］
最初に第１の実施の形態について説明する。
【００１５】
図１は、第１の実施の形態における、通信システム１０の構成例を示す図である。通信システム１０は、通信装置１００−１，２を有する。通信装置１００−１，２は、有線または無線を介して接続しており、例えば、パケットを使用してデータの送受信を行う。また通信装置１００−１，２の間は、例えば、中継装置などを介して接続されていてもよい。通信装置１００は、例えば、携帯電話などの端末装置や、サーバやホストマシンなどのコンピュータである。通信装置１００−１，２は、例えば、互いにＴＣＰ／ＩＰに基づき通信を行う。また、通信装置１００−１，２は、図示しないＣＰＵ、ストレージ、メモリを有し、ストレージに記憶されたプログラムをメモリにロードし、ＣＰＵがロードしたプログラムを実行することで、制御部１０１と送受信部１０２を構築し、各処理を実行する。通信システム１０で使用するパケットは、ＴＣＰパケット（データ送信用パケット）及び受信確認パケット（例えば、ＡＣＫ）である。以降、単にパケットと称する場合、ＴＣＰパケット、又は受信確認パケット、又はその両方を示す。
【００１６】
通信装置１００−１は、制御部１０１、送受信部１０２、送信バッファ１０３を有する。通信装置１００−２も、同様の構成（図示せず）を有する。
【００１７】
制御部１０１は、通信装置１００−２からＴＣＰパケットを受信し、当該パケットを受信したことを示す受信確認パケットを送信バッファ１０３に格納する。
【００１８】
送受信部１０２は、送信契機が発生すると、送信バッファに格納されている受信確認パケットの一部を、通信装置１００−２に送信し、残りの受信確認パケットを送信しない。
【００１９】
通信装置１００−２は、通信装置１００−１にＴＣＰパケットを送信する。ＴＣＰパケットには、当該パケットの識別子あるいはシーケンス番号（以降、対応パケット番号と呼ぶ）が含まれる。対応パケット番号は、例えば、ＴＣＰパケットを送信するごとにインクリメントされる数値であり、ＴＣＰパケットの送信順を示す。なお、対応パケット番号は、ＴＣＰパケットの送信順が算出可能であって、ＴＣＰパケットごとに一意に決まる数値であれば、例えば、送信するデータの先頭アドレスなど、前回送信したＴＣＰパケットにおけるデータとの関連を示す数値であってもよい。通信装置１００−２は、例えば、対応パケット番号が１〜４の４つのＴＣＰパケットを送信する（Ｓ１）。
【００２０】
通信装置１００−１は、通信装置１００−２からＴＣＰパケットを受信すると（Ｓ１）、制御部１０１が、送信バッファ１０３に受信確認パケットを格納する（Ｓ２）。制御部１０１は、例えば、ＴＣＰパケット（１）（対応パケット番号が１であるＴＣＰパケットの意味。以降、同様に記載。）を受信すると、受信確認パケット（１）（対応パケット番号が１である受信確認パケットの意味。ＡＣＫ（１）とも記載する。以降、同様に記載。）を作成し、送信バッファ１０３に格納する。制御部１０１は、ＴＣＰパケットを受信するごとに、同様に対応する受信確認パケットを作成し、送信バッファ１０３に格納する。従って、送信バッファ１０３には、受信確認パケット（１）〜（４）が格納される。
【００２１】
次に、パケットの送信契機が発生すると、送受信部１０２は、送信バッファに格納されている受信確認パケットの一部を取り出し（Ｓ３）、通信装置１００−２に送信する（Ｓ４）。送信契機は、例えば、パケット送信待ちタイマのタイムアウトや、送信バッファに所定のサイズまでパケットが格納されたときや、基地局装置（例えば、通信装置２００−２）が移動機端末装置（例えば、通信装置２００−１）に対して上り送信許可（UL Grant）を与えたときなど、ＴＣＰパケットの受信とは非同期に発生する。
【００２２】
図１の例においては、通信装置１００−１は、一部の受信確認パケットとして、受信確認パケット（４）を送信する。受信確認パケット（４）は、最後に受信したパケットに対する受信確認パケットである。図示はしないが、送信する受信確認パケットは、１つであってもよいし、受信確認パケット（４）を含む複数のパケットであってもよい。送信した一部の受信確認パケット以外の受信確認パケットは、次の送信契機が発生するのを待たずに送信バッファから破棄することで、通信装置１００−２に送信しない。なお、ここでは、説明簡単のために、送信パケット（ｘ）に対応するＡＣＫを、ＡＣＫ（ｘ）と記載した。しかし、例えば、ＴＣＰ通信において、次に受信すべきパケットに関する情報がＡＣＫに含まれる場合がある。従って、送信パケット（ｘ）に対応するＡＣＫは、ＡＣＫ（ｘ＋１）となる場合がある。以降の説明におけるＡＣＫについても同様である。
【００２３】
第１の実施の形態においては、受信したパケット全てに対して受信確認パケットを返信するのではなく、一部の受信パケットに対して受信確認パケットを返信する。こうすることで、送信する受信確認パケットの数を減少させることができ、受信確認パケット（ＡＣＫ）送信による通信速度の低下を防止することができる。
【００２４】
また、例えば、所定の数のＴＣＰパケットを受信するごとに、所定の数のＴＣＰパケットを受信したことを示す１つの受信確認パケットを送信する比較対象方式と比較する。比較対象方式では、所定の数のＴＣＰパケットを受信するまで受信確認パケットを返信することができないため、受信確認パケットの送信遅延による通信速度の低下が発生する場合がある。しかし、第1の実施の形態では、ＴＣＰパケットを受信するごとに受信確認パケットを作成し、送信バッファに格納しており、送信契機の発生により受信確認パケットを送信する。よって、第１の実施の形態では、ＴＣＰパケットの受信とは非同期に受信確認パケットを送信することができ、ＴＣＰパケットの受信を待つことによる受信確認パケットの送信遅延が発生せず、通信速度の低下は発生しない。
【００２５】
［第２の実施の形態］
次に、第２の実施の形態について説明する。本実施の形態は、第１の実施の形態をより具体化した実施の形態として捉えることもでき、従い、第１の実施の形態と第２の実施の形態は組み合わせて実施できることは言うまでもない。
【００２６】
第２の実施の形態では、通信装置１００−１は、最後に受信したパケットに対する受信確認パケットを含むパケットを送信する。受信確認パケットを受信した通信装置１００−２は、未受信の受信確認パケットの数を算出し、算出した数に応じてパケットの送信データ量を増加させる。なお、受信確認パケットを、ＡＣＫと呼ぶ場合がある。
【００２７】
＜通信システムの構成例＞
図２は、通信システム１０の構成例を示す図である。通信システム１０は、通信装置１００−１，２、中継装置２００、及びネットワーク３００を有する。通信システム１０は、例えば、ＬＴＥの通信規格に対応した通信システムである。
【００２８】
通信装置１００は、例えば、携帯端末やコンピュータである。通信装置１００−１は、例えば、通信装置１００−２と通信を行い、通信装置１００−２からデータをダウンロードしたり、サービスの提供を受けたりする。また、通信装置１００−１と１００−２は、例えば、ＴＣＰ／ＩＰに基づいて通信を行う。
【００２９】
中継装置２００は、通信装置１００間で送受信するパケットを中継するパケット中継装置である。なお、通信装置１００が、通信装置１００間で送受信されるパケットを中継する機能を有する場合、中継装置２００は、通信装置１００であってもよい。中継装置２００は、例えば、ＬＴＥにおいては、ｅＮｏｄｅＢ（evolved Node B）などの基地局装置である。また、中継装置２００は、スイッチやルータなどのネットワーク機器であってもよい。
【００３０】
ネットワーク３００は、例えば、インターネットであってもよいし、専用線で構成されているイントラネットであってもよい。
【００３１】
＜通信装置の構成例＞
図３は、通信装置１００の構成例を示す図である。通信装置１００は、ＣＰＵ（Central Processing Unit）１１０、ストレージ１２０、メモリ１３０、及びＮＩＣ（Network Interface Card）１４０−１〜ｎを有する。
【００３２】
ストレージ１２０は、プログラムやデータを記憶する補助記憶装置である。ストレージ１２０は、ハンドシェイクプログラム１２１、パケット受信処理プログラム１２２、受信確認送信処理プログラム１２３、パケット送信処理プログラム１２４、受信確認受信処理プログラム１２５、前回受信対応パケット番号１２６、送信バッファ１２７、及び輻輳ウィンドウ１２８を記憶する。
【００３３】
前回受信対応パケット番号１２６は、前回受信したＡＣＫの対応パケット番号を記憶する。前回受信対応パケット番号１２６は、通信装置１００が、未受信のＡＣＫの対応パケット番号を算出するときに使用される。通信装置１００は、ＡＣＫを受信すると、前回受信対応パケット番号１２６を更新する。
【００３４】
送信バッファ１２７は、作成したＡＣＫを格納する領域である。また、送信バッファ１２７には、ＡＣＫに加え、ＴＣＰパケットが格納されてもよい。通信装置１００は、パケットを送信するとき、送信バッファ１２７から取り出し、他の通信装置に送信する。また、通信装置１００は、ＡＣＫ送信のための送信バッファと、ＴＣＰパケット送信用の送信バッファを、それぞれ有してもよい。
【００３５】
輻輳ウィンドウ１２８は、送信データ量を調整するバッファである。輻輳ウィンドウ１２８のサイズが拡張されると、パケットの送信データ量は増加する。また、通信装置１００は、ＡＣＫを受信すると、輻輳ウィンドウ１２８のサイズを拡張する。なお、送信データ量は、例えば、１パケットのデータサイズや、一連のパケット送信処理で送信可能なパケット数である。また、送信データ量は、例えば、一連のパケット送信処理において、１つまたは複数のパケットで送信できるデータの合計サイズである。
【００３６】
メモリ１３０は、ストレージ１２０に記憶されているプログラムをロードする領域である。また、メモリ１３０、プログラムがデータを記憶する領域としても使用される。
【００３７】
ＮＩＣ１４０−１〜ｎは、他の通信装置と無線または有線で接続し、通信を行う装置である。ＮＩＣ１４０−１〜ｎは、ハブやスイッチを介して他の通信装置と接続してもよい。
【００３８】
ＣＰＵ１１０は、ストレージ１２０に記憶されているプログラムを、メモリ１３０にロードし、ロードしたプログラムを実行し、各処理を実現するプロセッサである。
【００３９】
ＣＰＵ１１０は、ハンドシェイクプログラム１２１を実行することで、他の通信装置にパケットを送信するためのセッションを確立するセッション確立処理を実行する。通信装置１００は、他の通信装置にパケットを送信するとき、セッション確立処理を実行する。
【００４０】
また、ＣＰＵ１１０は、パケット受信処理プログラム１２２を実行することで、パケット受信処理部（又は制御部）を構築し、パケット受信処理を実行する。パケット受信処理は、他の通信装置からＴＣＰパケットを受信する処理である。パケット受信処理は、ＴＣＰパケットを受信すると、受信したＴＣＰパケットに対応するＡＣＫを作成し、送信バッファ１２７に格納する。
【００４１】
さらに、ＣＰＵ１１０は、受信確認送信処理プログラム１２３を実行することで、受信確認送信処理部（又は送受信部）を構築し、受信確認送信処理を実行する。受信確認送信処理は、他の通信装置にＡＣＫを送信する処理である。受信確認送信処理は、送信契機が発生すると、送信バッファ１２７に格納されているＡＣＫのうち、最後に受信したＴＣＰパケットに対するＡＣＫを他の通信装置に送信し、それ以外のＡＣＫを送信バッファから破棄する。
【００４２】
さらに、ＣＰＵ１１０は、パケット送信処理プログラム１２４を実行することで、パケット送信処理部を構築し、パケット送信処理を実行する。パケット送信処理は、他の通信装置にＴＣＰパケットを送信する処理である。パケット送信処理は、送信契機が発生すると、送信バッファ１２７に格納されているＴＣＰパケットを、他の通信装置に送信する。
【００４３】
さらに、ＣＰＵ１１０は、受信確認受信処理プログラム１２５を実行することで、受信確認受信処理部を構築し、受信確認受信処理を実行する。受信確認受信処理は、他の通信装置からＡＣＫを受信したとき、パケットの送信データ量を増加させる処理である。受信確認受信処理は、ＡＣＫを受信すると、未受信のＡＣＫの数を算出し、算出した数に応じて送信データ量を増加させる。受信確認受信処理は、送信データ量を増加させるために、輻輳ウィンドウ１２８のサイズを拡張する。
【００４４】
＜パケット送受信処理＞
図４は、通信装置におけるパケット送受信のシーケンスの例を示す図である。以下、図４を用いて、通信装置１００のパケット送受信処理について説明する。
【００４５】
通信装置１００−１は、通信装置１００−２からＴＣＰパケット（１）を受信すると（Ｓ２０１）、パケット受信処理（Ｓ２０２）を実行する。
【００４６】
図５は、パケット受信処理（Ｓ２０２）の処理フローチャートの例を示す図である。通信装置１００は、ＴＣＰパケットを受信すると（Ｓ２０２１のＹｅｓ）、受信したＴＣＰパケットに対するＡＣＫを作成する（Ｓ２０２２）。ＡＣＫには、受信したＴＣＰパケットに含まれる対応パケット番号が含まれるため、作成したＡＣＫはどのＴＣＰパケットに対応するものかを特定することができる。図５においては、通信装置１００−１は、通信装置１００−２からＴＣＰパケット（１）を受信すると（Ｓ２０１）、対応するＡＣＫ（１）を作成する。そして、通信装置１００は、作成したＡＣＫを送信バッファ１２７に格納する（Ｓ２０２３）。図５においては、通信装置１００−１は、作成したＡＣＫ（１）を、送信バッファ１２７に格納する。通信装置１００は、ＴＣＰパケットを受信したタイミングでＡＣＫを作成し、ＴＣＰパケットの受信とは非同期に発生する送信契機が発生したときに送信できるように、作成したＡＣＫを送信バッファに格納する。こうすることで、送信契機がどのようなタイミングで発生しても、過去に受信したＴＣＰパケットに対してもＡＣＫを返信することができる。また、通信装置１００は、送信契機が発生したときの状況に応じて、返信するＡＣＫの数を変更することができる。
【００４７】
図４のシーケンスに戻り、通信装置１００−１は、ＴＣＰパケット（２）を受信し（Ｓ２０３）、パケット受信処理（Ｓ２０２）を実行する。以降、ＴＣＰパケット（３）の受信（Ｓ２０５）及びＴＣＰパケット（４）の受信（Ｓ２０６）におけるパケット受信処理においても、ＴＣＰパケット（１）の受信時と同様の処理を行う。
【００４８】
図７は、通信装置１００−１における、送信バッファ１２７の例を示す図である。通信装置１００は、ＴＣＰパケットを受信するごとにＡＣＫを送信バッファに格納し、４つのＴＣＰパケットを受信すると、送信バッファ１２７には、ＡＣＫ（１）〜（４）が格納される。
【００４９】
図４のシーケンスに戻り、送信契機が発生すると（Ｓ２０８のＹｅｓ）、通信装置１００は、パケットを送信するためのセッション確立処理（Ｓ２１０）を実行する。送信契機は、例えば、パケット送信待ちタイマのタイムアウトや、送信バッファに所定のサイズまでパケットが格納されたとき、基地局装置（例えば、通信装置２００−２）が移動機端末装置（例えば、通信装置２００−１）に対して上り送信許可（UL Grant）を与えたときである。また、セッション確立処理（Ｓ２１０）は、パケットを送信する前であれば、パケット送信の直前でなくてもよい。また、パケットを送信するとき、セッションが確立されていれば、セッション確立処理（Ｓ２１０）を実行しなくてもよい。
【００５０】
セッション確立処理（Ｓ２１０）は、パケットを送信する側の通信装置である通信装置１００−１がＳＲ（Scheduling Request）を通信装置１００−２に送信する（Ｓ２１１）。ＳＲは、これからパケット送信を行うための送信用のリソースである送信リソースを要求するメッセージである。通信装置１００−２は、ＳＲを受信すると、Ｇｒａｎｔを返信する（Ｓ２１２）。Ｇｒａｎｔは、ＳＲによる要求に対して応答するメッセージであり、送信リソースに関する情報が含まれる。送信リソースは、通信装置１００−２から割り当てられた割当量であり、例えば、使用する周波数やその帯域幅などの、パケットを送信するデータ量や通信速度である。通信装置１００−１は、Ｇｒａｎｔを受信すると、Ｇｒａｎｔを受信したことを確認するＡＣＫ、もしくはＨＡＲＱ（Hybrid Automatic Repeat request）ＡＣＫを送信する（Ｓ２１３）。ＨＡＲＱ  ＡＣＫは、セルラ通信において使用される再送制御方式であるＨｙｂｒｉｄ  ＡＲＱ方式において、送信したＨＡＲＱプロセスに対するＡＣＫである。セッション確立処理（Ｓ２１０）は、例えば、ＴＣＰ／ＩＰにおける、スリーウェイハンドシェイクである。
【００５１】
そして、通信装置１００−１は、受信確認送信処理（Ｓ２２０）を実行する。
【００５２】
図６は、受信確認送信処理（Ｓ２２０）の処理フローチャートの例を示す図である。通信装置１００−１は、送信バッファにＡＣＫが格納されているかどうかを確認する（Ｓ２２０１）。送信バッファにＡＣＫが格納されていれば（Ｓ２２０１のＹｅｓ）、最新の対応パケット番号のＡＣＫを送信する（Ｓ２２０２）。最新の対応パケット番号とは、例えば、対応パケット番号が最も大きいものであり、最後に受信したＴＣＰパケットの対応パケット番号である。なお、送信対象とするＡＣＫは、最後に受信したＴＣＰパケットに対応するＡＣＫを含む複数のＡＣＫであってもよい。
【００５３】
また、ＡＣＫの対応パケット番号が連続になっておらず、受信していないＴＣＰパケットがある可能性がある場合、通信装置１００は、ＡＣＫを送信しなくてもよい。この場合、例えば、ＴＣＰパケットの送信順と受信順が食い違っている可能性もあるため、欠如している対応パケット番号のＴＣＰパケットを受信するのを待ってから、受信確認送信処理（Ｓ２２０）を実行してもよい。こうすることで、ＴＣＰパケットを送信した通信装置は、受信したＡＣＫに対応するＴＣＰパケットより以前に送信したＴＣＰパケットについても、送信先の通信装置に到達していることが確認できる。
【００５４】
そして、通信装置１００は、送信バッファに格納されている、送信したＡＣＫ以外のＡＣＫを破棄する（Ｓ２２０３）。こうすることで、次の送信契機が発生しても、残りのＡＣＫは破棄されており、送信先の通信装置に送信されない。
【００５５】
図４のシーケンスに戻り、通信装置１００−１は、受信確認送信処理（Ｓ２２０）において、最新のＴＣＰパケット（４）に対応するＡＣＫ（４）を送信する（Ｓ２２１）。
【００５６】
図７に示すように、通信装置１００−１が受信確認送信処理（Ｓ２２０）を実行するとき、送信バッファ１２７には、ＡＣＫ（１）〜（４）が格納されている。通信装置１００−１は、最新のＡＣＫ（４）を送信し、それ以外のＡＣＫ（１）〜（３）を破棄する。
【００５７】
図４のシーケンスに戻り、通信装置１００−２は、ＡＣＫ（４）を受信すると、受信確認受信処理（Ｓ２３０）を実行する。
【００５８】
図８は、受信確認受信処理（Ｓ２３０）の処理フローチャートの例を示す図である。通信装置１００は、ＡＣＫを受信すると（Ｓ２３０１のＹｅｓ）、輻輳ウィンドウ１２８を、所定のサイズだけ伸張する（Ｓ２３０２）。通信装置１００は、輻輳ウィンドウ１２８のサイズに基づいて、送信するパケットの送信データ量を決定する。通信装置における送信データ量は、輻輳ウィンドウ１２８のサイズを伸張させる。所定のサイズは、現在送信可能なＴＣＰパケット数であり、例えば、最大パケットサイズや、平均パケットサイズなど、通信システムの特性に応じた数値であってよい。また、所定のサイズは、ＡＣＫを受信するごとに異なるサイズであってもよい。以降、輻輳ウィンドウが拡張する場合を例として説明する。
【００５９】
次に、通信装置１００は、未受信のＡＣＫがあるかを判定する（Ｓ２３０３）。未受信のＡＣＫがあるかどうかの判定は、前回受信対応パケット番号１２６に記憶されている、前記受信したＡＣＫの対応パケット番号と、今回受信したＡＣＫの対応パケット番号の差分をから実施する。例えば、前回受信したＡＣＫがＡＣＫ（１）であり、今回受信したＡＣＫがＡＣＫ（３）であれば、ＡＣＫ（２）が未受信であることが判定できる。
【００６０】
未受信のＡＣＫがある場合（Ｓ２３０３のＹｅｓ）、未受信のＡＣＫの数を算出し（Ｓ２３０４）、所定のサイズに算出した数を掛けたサイズだけ、輻輳ウィンドウ１２８を拡張する（Ｓ２３０５）。拡張処理Ｓ２３０２においては、１つのＡＣＫに対する所定のサイズだけ拡張したが、拡張処理Ｓ２３０５では、未受信の分のＡＣＫに対するサイズを拡張する。こうすることで、受信したＡＣＫに加え、未受信のＡＣＫの分も輻輳ウィンドウ１２８のサイズを拡張することができ、送信データ量がさらに増加する。なお、拡張処理Ｓ２３０５における拡張サイズは、所定のサイズに算出した数を掛けたサイズでなくてもよい。例えば、拡張処理Ｓ２３０５における拡張サイズは、未受信のパケットの数が多くなるほど大きくなるような数値であればよい。
【００６１】
そして、通信装置１００は、前回受信対応パケット番号を更新する（Ｓ２３０６）。
【００６２】
第２の実施の形態では、送信する一部のＡＣＫとして、最新のパケットに対応するＡＣＫを送信し、他のＡＣＫを送信しない。こうすることで、ＡＣＫを送信する数を減少させ、送信リソースの使用量を減少させることで、通信速度の低下を防止している。
【００６３】
また、第２の実施の形態では、未受信のＡＣＫを算出し、未受信のＡＣＫの分も輻輳ウィンドウのサイズを拡張させる。こうすることで、通信装置がＡＣＫを送信する数を減少させても、ＡＣＫを受信する側の通信装置からの送信データ量を、実質的にＴＣＰパケット送信が成功した回数に比例して増加させることができ、通信速度の低下を防止する。
【００６４】
［第３の実施の形態］
次に、第３の実施の形態について説明する。本実施の形態は、第１の実施の形態をより具体化した実施の形態として捉えることができ、従い、第１の実施の形態と第３の実施の形態は、それぞれ組み合わせて実施することができることは言うまでもない。
【００６５】
第３の実施の形態では、通信装置１００−１は、割り当てられた送信リソースに応じて、送信する受信確認パケットの数を増減する。また、受信確認パケットを受信した通信装置１００−２は、受信したＡＣＫの数に応じて、パケットの送信データ量を増加させる。
【００６６】
＜パケット送受信処理＞
図９は、通信装置におけるパケット送受信のシーケンスの例を示す図である。以下、図９を用いて、通信装置１００のパケット送受信処理について説明する。なお、ＴＣＰパケット送信（Ｓ２０１）からセッション確立処理（Ｓ２１０）までは、第２の実施の形態と同様である。
【００６７】
通信装置１００−１は、受信確認送信処理（Ｓ３２０）を実行する。
【００６８】
図１０は、受信確認送信処理（Ｓ３２０）の処理フローチャートの例を示す図である。通信装置１００−１は、送信バッファ１２７にＡＣＫが格納されている場合（Ｓ３２０１のＹｅｓ）、Ｇｒａｎｔで割り当てられた送信リソースから、通信装置１００−２に送信するＡＣＫの数を算出する（Ｓ３２０２）。送信するＡＣＫの数は、例えば、割り当てられた送信リソースを、送信するＡＣＫのパケットサイズで割った数である。また、送信するＡＣＫの数は、例えば、ＴＣＰパケットを送信するのに使用する送信リソースを除いた送信リソースを、ＡＣＫのパケットサイズで割った数であってもよい。さらに、送信するＡＣＫの数は、例えば、複数の閾値と、閾値に応じたＡＣＫの送信数をあらかじめ決めておき、送信リソースがどの閾値の間であるかを判定し、それぞれの閾値に応じた数としてもよい。こうすることで、割り当てられた送信リソースに応じて、ＡＣＫの送信数を増減させている。
【００６９】
通信装置１００−１は、最新のＡＣＫから、算出した数だけＡＣＫを送信する（Ｓ３２０３）。通信装置１００−１は、複数のＡＣＫを送信する場合、最新のＡＣＫ以外のＡＣＫは、どのＡＣＫを送信してもよい。例えば、２つのＡＣＫを送信する場合について説明する。送信バッファ１２７に、ＡＣＫ（１）〜（４）が格納されている場合、最新のＡＣＫ（４）と次に新しいＡＣＫ（３）を送信してもよいし、最新のＡＣＫ（４）と最古のＡＣＫ（１）を送信してもよい。
【００７０】
通信装置１００−１は、送信したＡＣＫ以外の送信バッファ１２７に格納されているＡＣＫを破棄する（Ｓ３２０４）。
【００７１】
図９のシーケンスに戻り、通信装置１００−１は、受信確認送信処理（Ｓ３２０）において、ＡＣＫ（３）を送信し（Ｓ３２１）、続いてＡＣＫ（４）を送信する（Ｓ３２２）。
【００７２】
図１１は、通信装置１００−１における、送信バッファ１２７の例を示す図である。通信装置１００は、ＴＣＰパケットを受信するごとにＡＣＫを送信バッファに格納し、４つのＴＣＰパケットを受信すると、送信バッファ１２７には、ＡＣＫ（１）〜（４）が格納される。通信装置１００−１は、受信確認送信処理（Ｓ３２０）において、最新のＡＣＫ（４）と最新のＡＣＫの次に新しいＡＣＫ（３）を送信し、それ以外のＡＣＫ（１），（２）を破棄する。
【００７３】
図９のシーケンスに戻り、通信装置１００−２は、ＡＣＫ（３），（４）を受信すると、受信確認受信処理（Ｓ３３０）を実行する。
【００７４】
図１２は、受信確認受信処理（Ｓ３３０）の処理フローチャートの例を示す図である。通信装置１００−２は、ＡＣＫを受信すると（Ｓ３３０１のＹｅｓ）、輻輳ウィンドウを所定のサイズだけ拡張する（Ｓ３３０２）。輻輳ウィンドウのサイズを拡張することで、パケットの送信データ量が増加する。通信装置１００−２は、ＡＣＫを受信するたびに受信確認受信処理を行うことで、ＡＣＫの受信数に応じて、輻輳ウィンドウのサイズを拡張し、パケットの送信データ量を増加させる。
【００７５】
第３の実施の形態では、送信する一部のＡＣＫとして、送信リソースに応じた数のＡＣＫを送信し、他のＡＣＫを送信しない。こうすることで、送信リソースが制限される状況下では、送信するＡＣＫの数を減少させ、ＡＣＫ送信による送信リソースの使用量を減少させることで、通信速度の低下を防止している。
【００７６】
また、第３の実施の形態における受信側の通信装置のように、ＡＣＫの受信数によって送信データ量を増加させる処理を行っている場合、できるだけＡＣＫを送信したほうが送信データ量を増加させることができる。第３の実施の形態では、送信リソースが大きい場合、すなわち、送信リソースに余裕がある場合は、送信するＡＣＫの数を増加させることで、ＡＣＫを受信する側の通信装置の送信データ量を増加させ、通信速度を上昇させることができる。
【００７７】
［第４の実施の形態］
次に、第４の実施の形態について説明する。
【００７８】
第４の実施の形態では、中継装置２００が、通信装置１００−１と通信装置１００−２との間で送受信するパケットを中継する。中継装置２００は、中継する受信確認パケットの対応パケット番号に基づいて、通信装置１００−１から通信装置１００−２に送信されない受信確認パケットの対応パケット番号を推定・算出する。中継装置２００は、算出した対応パケット番号のパケットに対応する受信確認パケットを作成し、作成した受信確認パケットを通信装置１００−２に送信する。すなわち、中継装置２００は、受信確認パケットの代理送信を実施する。
【００７９】
なお、第４の実施の形態では、中継装置２００がパケットを中継する場合を例として説明するが、中継装置２００は、パケット中継処理を有する通信装置１００であってもよい。
【００８０】
＜中継装置の構成例＞
図１３は、中継装置２００の構成例を示す図である。
【００８１】
中継装置２００は、ＣＰＵ２１０、ストレージ２２０、メモリ２３０、及びＮＩＣ２４０−１〜ｎを有する。中継装置２００は、通信装置間において送受信されるパケットを中継する、パケット中継装置である。
【００８２】
ストレージ２２０は、プログラムやデータを記憶する補助記憶装置である。ストレージ２２０は、パケット中継処理プログラム２３１及び前回受信対応パケット番号２２６を記憶する。
【００８３】
前回受信対応パケット番号２２６は、前回受信したＡＣＫの対応パケット番号を記憶する。前回受信対応パケット番号２２６は、未受信のＡＣＫの対応パケット番号を算出するときに使用される。中継装置２００は、ＡＣＫを受信すると、前回受信対応パケット番号２２６を更新する。
【００８４】
ＣＰＵ２１０は、ストレージ２２０に記憶されているプログラムを、メモリ２３０にロードし、ロードしたプログラムを実行し、各処理を実現するプロセッサである。
【００８５】
ＣＰＵ２１０は、パケット中継処理プログラム２３１を実行することで、パケット中継部を構築し、パケット中継処理を実行する。パケット中継処理は、他の通信装置から受信したパケットを、送信先の通信装置に送信する処理である。
【００８６】
また、ＣＰＵ２１０は、パケット中継処理プログラム２３１内の受信確認処理モジュール２３１１を実行することで、受信確認処理部を構築し、受信確認処理を実行する。受信確認処理は、ＡＣＫを受信したときの処理である。中継装置は、送信されない受信確認パケットの対応パケット番号を算出し、算出した対応パケット番号のＡＣＫを作成し、作成したＡＣＫを送信する。
【００８７】
メモリ１３０、及びＮＩＣ１４０−１〜ｎは、第２の実施の形態における通信装置のメモリ２３０、及びＮＩＣ２４０−１〜ｎと同様である。
【００８８】
＜通信装置の構成例＞
図１４は、通信装置１００の構成例を示す図である。通信装置１００が、パケット中継部を有する場合、図１４に示す構成となる。
【００８９】
通信装置１００は、さらに、ストレージ１２０にパケット中継処理プログラム１２９を有する。
【００９０】
ＣＰＵ１１０は、パケット中継処理プログラム１２９を実行することで、パケット中継部を構築し、パケット中継処理を実行する。パケット中継処理は、他の通信装置から受信したパケットを、送信先の通信装置に送信する処理である。また、パケット中継処理において、ＡＣＫを受信したとき、送信されない受信確認パケットの対応パケット番号を算出し、算出した対応パケット番号のＡＣＫを作成し、作成したＡＣＫを送信する。
【００９１】
＜パケット中継処理＞
図１５は、中継装置２００によるパケット中継処理のシーケンスの例を示す図である。以下、中継装置２００が通信装置１００−１より、ＡＣＫ（１）、ＡＣＫ（４）を中継する場合の処理について説明する。
【００９２】
中継装置２００は、通信装置１００−１より、ＡＣＫ（１）を受信すると（Ｓ４０１）、パケット中継処理（Ｓ４０２）を実行する。
【００９３】
図１６は、パケット中継処理（Ｓ４０２）の処理フローチャートの例を示す図である。中継装置２００は、パケットを受信すると（Ｓ４０２１のＹｅｓ）、受信したパケットはＡＣＫであるかどうかを確認する（Ｓ４０２２）。受信したパケットがＡＣＫである場合（Ｓ４０２２のＹｅｓ）、未受信のＡＣＫがあるかどうかを判定する（Ｓ４０２３）。
【００９４】
未受信のＡＣＫがあるかどうかの判定は、前回受信対応パケット番号２２６に記憶されている、前記受信したＡＣＫの対応パケット番号と、今回受信したＡＣＫの対応パケット番号の差分をから実施する。例えば、前回受信したＡＣＫがＡＣＫ（１）であり、今回受信したＡＣＫがＡＣＫ（３）であれば、ＡＣＫ（２）が未受信であることが判定できる。また、中継装置２００は、中継するＴＣＰパケットの対応シーケンス番号を内部メモリに記憶しておき、記憶したＴＣＰパケットの対応シーケンス番号のＡＣＫを受信したかどうかで、未受信のＡＣＫがあるかどうかの判定を行ってもよい。
【００９５】
未受信のＡＣＫがある場合（Ｓ４０２３のＹｅｓ）、未受信のＡＣＫを作成する（Ｓ４０２４）。未受信のＡＣＫの作成は、例えば、受信したＡＣＫの複製を生成し、対応パケット番号を変更する。そして、作成したＡＣＫと受信したＡＣＫを、対応パケット番号順に送信する（Ｓ４０２５）。
【００９６】
受信したパケットがＡＣＫでない場合（Ｓ４０２２のＮｏ）、及び未受信のＡＣＫがない場合（Ｓ４０２３のＮｏ）は、受信したパケットを送信先の通信装置に送信する（Ｓ４０２７）。
【００９７】
中継装置２００は、受信したパケットがＡＣＫである場合、前回受信対応パケット番号を更新し（Ｓ４０２６）、パケットの受信待ちに遷移する。
【００９８】
図１５のシーケンスに戻り、中継装置２００は、ＡＣＫ（１）を受信すると、未受信のＡＣＫはないと判定し、ＡＣＫ（１）を通信装置１００−２に送信する（Ｓ４０３）。ＡＣＫ（４）を受信すると（Ｓ４０４）、パケット中継処理（Ｓ４０２）において、未受信のＡＣＫはＡＣＫ（２）及びＡＣＫ（３）であると判定し、ＡＣＫ（２）及びＡＣＫ（３）を作成する。そして、中継装置２００は、受信したＡＣＫ（４）及び、作成したＡＣＫ（２）及びＡＣＫ（３）を、対応パケット番号順に通信装置１００−２に送信する（Ｓ４０５〜Ｓ４０７）。
【００９９】
第４の実施の形態では、通信装置間の通信を中継する中継装置（または通信装置）が、未受信のＡＣＫを作成し、送信先の通信装置に送信する。送信先の通信装置は、例えば、第３の実施の形態における受信確認受信処理のように、受信したＡＣＫの数に応じて送信データ量を増加させている場合がある。このような場合でも、未受信のＡＣＫが送信先の通信装置に送信されるため、送信データ量が増加し、通信速度を上昇させることができる。
【０１００】
例えば、ＡＣＫを送信する通信装置と中継装置間は無線で通信を行っており、通信リソースが少ないが、ＡＣＫを受信する通信装置と中継装置は有線で通信を行っており、通信リソースが多い場合がある。この場合、第４の実施の形態は、通信リソースが少ない区間ではＡＣＫ送信数を少なくし、通信リソースが多い区間ではＡＣＫ送信数を増加させることができ、通信システム全体での通信速度を上昇させることができる。
【０１０１】
［第５の実施の形態］
次に、第５の実施の形態について説明する。
【０１０２】
第５の実施の形態では、第１〜３の実施の形態における受信確認処理を実行する場合、通信装置は、送信するＡＣＫが属するＴＣＰセッションに、他のＴＣＰセッションとは異なるベアラを単独で設定する。ベアラとは、例えば、ＴＣＰパケットを送信するための伝送経路である。
【０１０３】
＜ＬＴＥにおけるベアラについて＞
図１７は、通信システムにおけるプロトコルスタックの例を示す図である。通信システム１０は、例えば、ＬＴＥに準じた通信システムであり、中継装置２００はＬＴＥの基地局装置であるｅＮＢである。
【０１０４】
通信システム１０は、例えば、図１７に示すプロトコルスタック８００を適用することができる。プロトコルスタック８００は、３ＧＰＰに規定されたＬＴＥ−Ａのプロトコルスタックである。レイヤ群８０１〜８０５は、それぞれ通信装置１００−１、中継装置２００、図示しないＳＧＷ（Serving Gateway）、図示しないＰＧＷ（Packet data network Gateway）、及び通信装置１００−２における各処理を示すレイヤ群である。
【０１０５】
通信システム１０において、各装置はＩＰプロトコルを用いてパケットを伝送する（以降、ＩＰフローと呼ぶ）。通信システム１０においては、個々のＩＰフローに対してＱｏＳ（Quality of Service）クラスに応じた取り扱いを実施するために、ＩＰフローのフィルタリングが実施される。たとえば通信装置１００−１がＩＰフローを受信する下りリンクについては、ＰＧＷがＩＰフローに対するパケットフィルタリングを行い、それぞれのＩＰフローをＥＰＳ（Evolved Packet System）ベアラに分類する。ＥＰＳベアラは、Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ ＳｙｓｔｅｍにおけるＩＰフローである。
【０１０６】
通信装置１００−１がＩＰフローを送信する上りリンクについては、ＰＧＷからパケットのフィルタリング規則が通信装置１００−１に通知される。そして、ＰＧＷから通知されたフィルタリング規則に基づいて、通信装置１００−１がＩＰフローに対するパケットフィルタリングを行って、それぞれのＩＰフローをＥＰＳベアラに分類する。
【０１０７】
例えば、上りリンクにおいて、ＰＧＷは、ＰＧＷのレイヤ群８０４のうちのＩＰレイヤ（ＩＰ）に含まれるフィルタレイヤ８１１（Ｆｉｌｔｅｒ）によって、ＩＰフローのフィルタリングを行う。また、下りリンクにおいて、通信装置１００−１は、通信装置１００−１のレイヤ群８０１のうちのＩＰレイヤ（ＩＰ）に含まれるフィルタレイヤ８１２（Ｆｉｌｔｅｒ）によって、ＩＰフローのフィルタリングを行う。
【０１０８】
また、通信システム１０内のルータ（図示しない）でＱｏＳ制御（又はＱｏＳ管理）を行うために、ＰＧＷ（下りリンクの場合）または通信装置１００−１（上りリンクの場合）が、ＩＰパケットのヘッダのＴｏＳ（Ｔｙｐｅ ｏｆ Ｓｅｒｖｉｃｅ）フィールドにＱｏＳ値を設定する。
【０１０９】
ＰＧＷまたは通信装置１００−１によるパケットフィルタリングは、たとえば５−ｔｕｐｌｅ（送受信元ＩＰアドレス、送受信元ポート番号、プロトコルタイプ）を利用して行われる。パケットフィルタリングのフィルタリング規則は、たとえばＴＦＴ（Ｔｒａｆｆｉｃ Ｆｌｏｗ Ｔｅｍｐｌａｔｅ）と呼ばれる。なお、ＥＰＳベアラの中にはＴＦＴが設定されないＥＰＳベアラが存在してもよい。
【０１１０】
ＴＦＴを用いてＩＰフローのフィルタリングを実施すると、ＩＰフローを最大で１１種類のＥＰＳベアラに分類することができる。ＥＰＳベアラのうちの一つのベアラはデフォルトベアラ（Ｄｅｆａｕｌｔ Ｂｅａｒｅｒ：既定ベアラ）と呼ばれる。デフォルトベアラは、ＰＧＷが通信装置１００−１にＩＰアドレスを割り当てる際に生成され、通信装置１００−１に割り当てられたＩＰアドレスが解放されるまで常に存在する。ＥＰＳベアラのうちのデフォルトベアラとは異なるベアラは、個別ベアラ（Ｄｅｄｉｃａｔｅｄ Ｂｅａｒｅｒ）と呼ばれる。個別ベアラは、伝送するユーザデータの状況に応じて適宜生成および解放することが可能である。
【０１１１】
＜ベアラ設定処理＞
図１８は、ベアラ設定処理（Ｓ５００）の処理フローチャートの例を示す図である。なお、ベアラの設定は、例えば、通信装置１００−１，２、中継装置２００、ＳＧＷ、及びＰＧＷのどの装置が行ってもよい。また、一旦設定されたベアラは、適宜再設定されてもよい。以下、通信装置１００−１がベアラの設定（又は再設定）を行う場合について説明する。
【０１１２】
通信装置１００−１は、ＡＣＫを送信するとき、ベアラ設定処理（Ｓ５００）を実行する。なお、ベアラ設定処理（Ｓ５００）は、ＴＣＰパケット受信時に行ってもよい。また、通信装置１００−１が、第１〜３の実施の形態におけるそれぞれの受信確認送信処理及び従来の受信確認処理を切り替えて実行する場合、各受信確認送信処理の切り替え時にベアラ設定処理を行ってもよい。
【０１１３】
通信装置１００−１は、特殊な受信確認送信処理を行っているかどうかを確認する（Ｓ５０１）。特殊な受信確認送信処理とは、例えば、第１〜３の実施の形態における受信確認送信処理である。逆に、特殊でない受信確認送信処理とは、例えば、所定の複数のパケット受信に対して１つのＡＣＫを返信するＴＣＰ遅延ＡＣＫ（Delayed Ack）や、パケットを受信するごとにＡＣＫを返信する処理である。
【０１１４】
通信装置１００−１は、特殊な受信確認送信処理であった場合（Ｓ５００のＹｅｓ）、当該ＡＣＫに対応するＴＣＰセッション（以降、当該ＴＣＰセッション）として、単独のベアラを設定する（Ｓ５０１）。設定される単独のベアラは、個別ベアラでも、デフォルトベアラのどちらでもよい。また、設定される単独のベアラは、下り／上りそれぞれ異なるベアラであってよい。また、設定される単独のベアラは、下りは当該ＴＣＰセッション以外のＴＣＰセッションが混在する状態でベアラを設定し、上りだけ当該ＴＣＰセッションのＡＣＫ返信用のベアラを単独で設定してもよい。少なくとも、上りの当該ＴＣＰセッションのＡＣＫ返信が、他のＴＣＰセッションと混在しない単独のベアラであればよい。
【０１１５】
第５の実施の形態では、ＡＣＫ返信用に単独のベアラを設定している。こうすることで、通信装置は当該単独のベアラにおいて受信するパケットは当該ＡＣＫのみとなる。よって、通信装置はヘッダ解析が簡単化することで、処理を軽減することができ、省電力が実現できる。つまり、当該特殊処理を実施するベアラと実施しないベアラが混在する場合、実施しないベアラについてもヘッダ解析が必要であったが、混在させないことによって、実施するベアラについてのみヘッダ解析を行えばよいこととなる。
【０１１６】
［その他の実施の形態］
第１〜第５の実施の形態における、受信確認送信処理、受信確認受信処理、パケット中継処理、及びベアラ設定処理は、それぞれ組み合わせて実施してもよい。
【０１１７】
例えば、第３の実施の形態における受信確認送信処理と、第２の実施の形態における受信確認送信処理を組み合わせる場合がある。この場合、受信確認処理は、送信リソースに応じた数のＡＣＫを送信する。そして、受信確認送信処理において、送信されないＡＣＫの数に対応した送信データ量を増加させる。このようにすることで、送信データ量を増加させ、通信速度の低下を防ぐことができる。
【０１１８】
また、例えば、第２及び第３の実施の形態において、中継装置２００は、第４の実施の形態におけるパケット中継処理を行う場合がある。この場合、中継装置２００は、未受信のＡＣＫを作成し、通信装置に送信するため、ＡＣＫを受信する側の通信装置が、第２及び第３の実施の形態のどちらの実施の形態の受信確認受信処理を行っていても、送信データ量を増加させることができ、通信速度の低下を防止することができる。
【０１１９】
さらに、例えば、通信装置は、第１及び第２の実施の形態における受信確認送信処理、ＴＣＰ遅延ＡＣＫによる受信確認送信処理、及びＴＣＰパケットを受信するごとにＡＣＫを返信する受信確認送信処理など、複数の受信確認送信処理を有してもよい。この場合、通信装置は、中継装置２００の間の無線品質に応じて、どの受信確認送信処理を行うかを切り替えてもよい。無線品質は、例えば、通信装置が無線通信において使用する電波の干渉度合いである。通信装置は、無線品質が不良な場合、ＡＣＫの送信頻度が低い受信確認送信処理を実行する。これは、無線品質が不良であれば、送信データに対し多くの符号化ビットの付加が必要なことや、パケットの再送などで無線リソースを多く使用するため、ＡＣＫ送信による無線リソースの使用を抑制するためである。逆に、無線品質が良好な場合、通信装置は、ＡＣＫの送信頻度が高い受信確認送信処理を実行する。これは、無線品質が良好であれば、送信データに対し多くの符号化ビットの付加は不要で、パケットの再送が発生しないため、ＡＣＫを送信するための無線リソースに余裕があるからである。一般に、通信装置１００では、ＡＣＫを受信するか、所定の量の送信データが生成されるか、所定時間がタイムアウトするかの、いずれかの契機でデータパケットを送信する。従って、ＡＣＫ送信により無線リソースが逼迫しない場合、なるべく多くのＡＣＫを送信することで、パケットの送信契機が増加し、無線通信におけるスループットが向上する。
【０１２０】
［シミュレーション］
次に、それぞれの実施の形態における受信確認送信処理、及び基本的な受信確認処理を行った場合、下りのスループットにどれくらいの影響を及ぼすかを確認するシミュレーションを実施した結果について説明する。
【０１２１】
＜シミュレーション条件＞
シミュレーション対象の受信確認処理は、第２の実施の形態における受信確認送信処理（以下、ＨｉｇｈｅｓｔＡｃｋと呼ぶ）、第３の実施の形態における受信確認送信処理（以下、ＧｒａｎｔＡｃｋと呼ぶ）、及び２つのＴＣＰパケットを受信する毎に１つのＡＣＫを返信する、ＴＣＰ遅延ＡＣＫに相当する受信確認送信処理（以下、Ｂａｓｉｃと呼ぶ）の、３つの受信確認処理である。
【０１２２】
各受信確認送信処理が下りのスループットに与える影響を評価するため、無限長ファイルのＦＴＰ（File Transfer Protocol）通信を用いてシミュレーションを行う。本シミュレーションでは、スロースタートモードと輻輳回避モードが断続的に切り替わるようにする．ＦＴＰ通信は９７秒間で終了する。外部インターネットからＬＴＥ網（EPC：Evolved Packet Core）に流入したパケットは、ゲートウェイであるＰＧＷとＳＧＷを経由しｅＮＢに流入する。ＳＧＷからｅＮＢへのリンクは、無線リンクの最大キャパシティである約７０ＭＢ／ｓ（ＭｅｇａＢｉｔ／Ｓｅｃｏｎｄ）の7割程度となる５０ＭＢ／ｓに規制する。ＦＴＰ通信のＴＣＰトラヒックは、ＬＴＥ網内の往復遅延時間の目標値が３００ｍｓであるため、パケット廃棄を実施するタイマを設定する。タイマの上限値は１５０ｍｓとする。通信装置は、ｅＮＢの通信セル範囲内に、１０台をランダムに配置する。主要な無線パラメータは３ＧＰＰ Ｃａｓｅ１モデルに準拠する。主要な上位レイヤのパラメータは、無線レイヤにおけるＨＡＲＱ（Hybrid ARQ）が３回実施された場合の遅延時間が２４ｍｓ（８プロセスを３回再送）であることを考慮して設定する。パケットスケジューリング方式として、下りはＰＦ（Proportional Fairness）方式、上りはＲＲ（Round Robin）方式を採用する。無限長ファイルのＦＴＰ通信では多くのＡＣＫが発生するため、ｅＮＢが通信装置に事前に送信許可（ＵＬ  Ｇｒａｎｔ）を与える方式を採用する。送信許可を与える周期は５ｍｓとする。
【０１２３】
また、ＴＣＰ／ＩＰのヘッダ圧縮（ROHC：Robust Header Compression）を実行した場合としない場合についても、併せてシミュレーションを行う。
【０１２４】
＜シミュレーション結果＞
上記条件におけるシミュレーション結果について以下に説明する。
【０１２５】
図１９は、Ｂａｓｉｃ、Ｈｉｇｈｅｓｔ  Ａｃｋ、Ｇｒａｎｔ  Ａｃｋをシミュレーションしたときの、ＡＣＫの送信数及び下りのスループットをグラフ化した図である。図１９の上のグラフは、それぞれの受信確認送信処理における下りのスループットを示しており、下のグラフは、それぞれの受信確認送信処理におけるＡＣＫの送信数を示している。また、両グラフとも、それぞれの受信確認送信処理の左側がＲＯＨＣを実行した場合であり、右側がＲＯＨＣを実行しない場合のグラフである。
【０１２６】
図１９の上のグラフより、３つの受信確認送信処理すべてにおいて、ＲＯＨＣを実行した場合のほうが、ＲＯＨＣを実行しない場合と比較して、下りのスループットが高いことがわかる。すなわち、どの受信確認送信処理を実行しても、ＲＯＨＣを実行することによって、より多くのＡＣＫを返信できるようになるため、下りリンクと上りリンクの帯域の非対称性がなくなり、有線と同等の通信環境になるためである。各受信確認送信処理を行うのと同時に、ＲＯＨＣを実行することで、さらにスループットが向上する。ただし、ＲＯＨＣは必ずしも通信装置に実装されるわけではない。ＲＯＨＣを実装すると、ベースバンド部の処理が増加する。また、無線品質が悪い場合は、ヘッダ圧縮率が低下し、今回のシミュレーションのように高い特性が得られるとは限らない。
【０１２７】
また、図１９の下のグラフより、ＲＯＨＣの実行の有無に関わらず、Ｂａｓｉｃ、Ｇｒａｎｔ  Ａｃｋ、Ｈｉｇｈｅｓｔ  Ａｃｋの順番に、ＡＣＫの送信数が減少していることがわかる。さらに、図１９の上のグラフより、Ｈｉｇｈｅｓｔ  Ａｃｋ及びＧｒａｎｔ  Ａｃｋの下りスループットは、Ｂａｓｉｃの下りスループットより大きく低下することなく、例えば、ＲＯＨＣがＯＦＦの場合については、Ｂａｓｉｃの下りスループットより向上することがわかる。すなわち、Ｈｉｇｈｅｓｔ  Ａｃｋ及びＧｒａｎｔ  Ａｃｋを実行すると、ＡＣＫの送信数を減少させることができ、なおかつ、Ｈｉｇｈｅｓｔ  Ａｃｋ及びＧｒａｎｔ  Ａｃｋを実行しない場合と同等又は向上した下りスループットを実現できる。ＲＯＨＣを実装していない通信装置にとっては効果的な方式であると言える。
【０１２８】
また、ＡＣＫの送信数を抑制することで、無線区間における干渉の発生を減少させ、パケット送信による電力の消費を抑制することができる。よって、ＡＣＫの送信数が最も少なく、なおかつ下りのスループットもＢａｓｉｃと同等であるＨｉｇｈｅｓｔ  Ａｃｋが、無線区間の干渉低減及び省電力を最も実現できる方式であると言える。
【０１２９】
さらに、第４の実施の形態におけるパケット中継処理を、ｅＮＢに実装したシミュレーションを実施すると、より特性向上が見込まれる。この場合、Ｈｉｇｈｅｓｔ  Ａｃｋ及びＧｒａｎｔ  Ａｃｋのそれぞれで、第４の実施の形態におけるパケット中継処理を行わない場合と比較して、ＡＣＫの送信数を約８０％減少させることができるという結果が見込まれる。また、Ｈｉｇｈｅｓｔ  Ａｃｋ及びＧｒａｎｔ  Ａｃｋのそれぞれで、第４の実施の形態におけるパケット中継処理を行わない場合と比較して、下りのスループットは向上することも見込まれる。すなわち、第４の実施の形態におけるパケット中継処理は、ＡＣＫの送信を抑制しつつ、Ｂａｓｉｃと同様または向上した下りスループットを実現することができる処理である。
【符号の説明】
【０１３０】
１０…通信システム                  １００…通信装置
１０１…制御部                      １０２…送受信部
１０３…送信バッファ                １１０…ＣＰＵ
１２０…ストレージ                  １２１…ハンドシェイクプログラム
１２２…パケット受信処理プログラム
１２３…受信確認送信処理プログラム
１２４…パケット送信処理プログラム
１２５…受信確認受信処理プログラム
１２６…前回受信対応パケット番号    １２７…送信バッファ
１２８…輻輳ウィンドウ 
１２９…パケット中継処理プログラム
１３０…メモリ                      １４０…ＮＩＣ
２００…中継装置                    ２１０…ＣＰＵ
２２０…ストレージ                  ２２６…前回受信対応パケット番号
２３０…メモリ
２３１…パケット中継処理プログラム
２３１１…受信確認処理モジュール    ２４０…ＮＩＣ
３００…ネットワーク                ８００…プロトコルスタック
８０１〜８０５…レイヤ群            ８１１、８１２…フィルタレイヤ
【図１】
2017145227.tif 000003
【図２】
2017145227.tif 000004
【図３】
2017145227.tif 000005
【図４】
2017145227.tif 000006
【図５】
2017145227.tif 000007
【図６】
2017145227.tif 000008
【図７】
2017145227.tif 000009
【図８】
2017145227.tif 000010
【図９】
2017145227.tif 000011
【図１０】
2017145227.tif 000012
【図１１】
2017145227.tif 000013
【図１２】
2017145227.tif 000014
【図１３】
2017145227.tif 000015
【図１４】
2017145227.tif 000016
【図１５】
2017145227.tif 000017
【図１６】
2017145227.tif 000018
【図１７】
2017145227.tif 000019
【図１８】
2017145227.tif 000020
【図１９】
2017145227.tif 000021
【手続補正書】
【提出日】平成30年8月27日(2018.8.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
他の通信装置からパケットを受信し、前記パケットを受信したことを示す受信確認パケットを作成し、前記作成した受信確認パケットを送信バッファに格納するように制御する制御部と、
前記送信バッファに格納されている受信確認パケットの一部を前記他の通信装置に送信し、前記送信した受信確認パケット以外の受信確認パケットを前記他の通信装置に送信しない送受信部とを有する
通信装置。
【請求項２】
前記一部の受信確認パケットは、最後に受信したパケットに対する受信確認パケットを含む
請求項１記載の通信装置。
【請求項３】
前記受信確認パケットは、対応するパケットの送信順を示す対応パケット番号を含み、
さらに、前記受信確認パケットを受信したとき、前回受信した受信確認パケットの対応パケット番号と、今回受信した受信確認パケットの対応パケット番号の差分から、未受信の受信確認パケットの数を算出し、前記算出した数が第１差分数の場合、パケットの送信データ量を第１データ量だけ増加させ、前記算出した数が、前記第１差分数より大きい第２差分数の場合、パケットの送信データ量を前記第１データ量より大きい第２データ量だけ増加させる受信確認受信処理部を有する
請求項２記載の通信装置。
【請求項４】
前記一部の受信確認パケットは、最後に受信したパケットに対する受信確認パケットを含み、
前記送受信部は、前記一部の受信確認パケットの数を、前記受信確認パケットを含むパケットを送信するために割り当てられた送信リソースの割当量に応じて増減する
請求項１記載の通信装置。
【請求項５】
前記送受信部は、前記送信リソースが第１の割当量の場合、第１の数の受信確認パケットを送信し、前記送信リソースが前記第１の割当量より大きい第２の割当量の場合、第１の数より大きい第２の数の受信確認パケットを送信する
請求項４記載の通信装置。
【請求項６】
さらに、前記受信確認パケットを受信するごとに、パケットの送信データ量を増加させる受信確認受信処理部を有する
請求項４または５記載の通信装置。
【請求項７】
さらに、輻輳ウィンドウのサイズに基づいて前記送信データ量を決めるパケット送信処理部を有し、
前記受信確認受信処理部は、前記送信データ量を増加させるとき、前記輻輳ウィンドウのサイズを拡張する
請求項３または６記載の通信装置。
【請求項８】
前記送受信部は、前記受信確認パケットの送信を、前記他の通信装置からのパケット受信と非同期に行う
請求項１記載の通信装置。
【請求項９】
さらに、第１の通信装置と第２の通信装置の間で送受信されるパケットを中継するパケット中継部を有し、
前記パケット中継部は、前記第１の通信装置から受信した受信確認パケットの対応するパケットの送信順を示す対応パケット番号に基づいて、前記第１の通信装置から前記第２の通信装置に送信されない受信確認パケットの対応パケット番号を算出し、前記算出した対応パケット番号のパケットに対応する追加の受信確認パケットを作成し、前記中継する受信確認パケットに加えて、前記作成した追加の受信確認パケットを前記第２の通信装置に送信する
請求項１記載の通信装置。
【請求項１０】
第１の通信装置と、前記第１の通信装置にパケットを送信する第２の通信装置との間で送受信するパケットを中継するパケット中継部を有し、
前記第１の通信装置は、前記パケットを受信したことを示す受信確認パケットを作成し、前記作成した受信確認パケットを送信バッファに格納し、前記送信バッファに格納されている受信確認パケットの一部を前記第２の通信装置に送信し、前記送信した受信確認パケット以外の受信確認パケットを前記第２の通信装置に送信せず、
さらに、前記中継する受信確認パケットの対応するパケットの送信順を示す対応パケット番号に基づいて、前記第１の通信装置から前記第２の通信装置に送信されない受信確認パケットの対応パケット番号を算出し、前記算出した対応パケット番号のパケットに対応する追加の受信確認パケットを作成し、前記中継する受信確認パケットに加えて、前記作成した追加の受信確認パケットを前記第２の通信装置に送信する受信確認処理部を有する
パケット中継装置。
【請求項１１】
第１の通信装置にパケットを送信する第２の通信装置と、
前記パケットを受信したことを示す受信確認パケットを作成し、前記作成した受信確認パケットを送信バッファに格納し、前記送信バッファに格納されている受信確認パケットの一部を前記第２の通信装置に送信し、前記送信した受信確認パケット以外の受信確認パケットを前記第２の通信装置に送信しない第１の通信装置とを有する
通信システム。
【請求項１２】
さらに、前記第１及び第２の通信装置間を送受信するパケットを中継するパケット中継装置を有し、
前記パケット中継装置は、前記第１の通信装置から受信した受信確認パケットの対応するパケットの送信順を示す対応パケット番号に基づいて、前記第１の通信装置から前記第２の通信装置に送信されない受信確認パケットの対応パケット番号を算出し、前記算出した対応パケット番号のパケットに対応する追加の受信確認パケットを作成し、前記中継する受信確認パケットに加えて、前記作成した追加の受信確認パケットを前記第２の通信装置に送信する
請求項１１記載の通信システム。
【国際調査報告】
2017145227.tif 000022
2017145227.tif 000023
2017145227.tif 000024
2017145227.tif 000025