JP2006101428A - 無線ネットワークの制御装置及び制御方法、制御プログラム並びに記録媒体 - Google Patents

Abstract

【課題】アドホック無線ネットワークにおいて１つのアソシエーションに属する複数のパケットを複数のルートを用いて効率的に伝送してデータ転送全体のスループットを向上できる。
【解決手段】ＳＣＴＰを用いて１つのデータの複数のパケットを送信元通信端末装置から宛先通信端末装置に伝送する無線ネットワークの制御装置において、データの各パケットに対して、ルートを識別するルート識別子（ＲＩＤ）と、ルート毎のシーケンス番号であるルートシーケンス番号（ＲＳＮ）とを付して、各パケットを複数のルートを介して伝送するように制御する。ここで、宛先通信端末装置からの、送信パケットに対する選択的肯定確認応答（ＳＡＣＫ）メッセージに応答して、ルート識別子（ＲＩＤ）に基づいて、ルート毎のデータ転送時間（ＲＴＴ）を計算するルート毎の再送タイマーを含み、再送時刻を管理する。
【選択図】図１

Description

本発明は、例えばアドホック無線ネットワークなどのための無線ネットワークの制御装置及び制御方法、制御プログラム並びに、上記制御プログラムを格納したコンピュータにより読み取り可能な記録媒体に関する。

アドホック無線ネットワークはユビキタスコンピューティングの世界で重要な技術となりつつある。しかしながら、アドホック無線ネットワークのプロトコルはスケーラビリティを考慮して設計されていないために、インターネット上における全てのサービス（アプリケーション）をアドホック無線ネットワーク上で提供できるわけではない。特に、ユビキタスコンピューティングに欠かせないマルチメディアアプリケーションにおいては、アドホック無線ネットワークの特徴である高い転送エラー率や狭帯域などが大きな制約となると考えられる。以下、本願では、アドホック無線ネットワークなどのネットワークにおいて用いられる、従来技術であるトランスポート層の通信手順であるＳＣＴＰ（Stream Control Transmission Protocol；以下、ＳＣＴＰという。）において伝送品質の改善を行って、スケーラビリティを考慮することを考える。

次いで、非特許文献１乃至３を引用して、従来技術に係るＳＣＴＰについて以下説明する。

近年、インターネットは世界規模の通信基盤として広く普及している。このインターネット上の通信において確実にデータを送り届けるためには、経路の冗長性の確保が必要である。また、固定あるいは移動端末などを利用してインターネットに接続する端末数は年々増加し、通信トラフィック量もこれに応じて増大しているため、トラフィックの負荷分散を行うことが重要となっている。これら双方の目的のために、複数の通信経路を持つことができるマルチホーム（multihoming）環境が整いつつある。一方、移動端末環境に着目すると、携帯電話、ＰＤＡ、ノートパソコン等によるモバイルアクセスの要求が年々高まっている。この要求の高まりに伴い、ＩＥＥＥ８０２．１１ｂに準拠した無線ＬＡＮシステムやＩＭＴ−２０００（International Mobile Telecommunications-2000）などの多様な無線接続技術が普及している。移動端末装置において、これらの多様な無線接続技術を生かしマルチホーム環境を達成できれば、切断がなく効率の良い通信を実現できる。しかしながら、現在のインターネットにおける通信の大部分を占めるＴＣＰ（Transmission Control Protocol；以下、ＴＣＰという。）は、マルチホーム環境を前提とする通信はできない。これはＴＣＰが通信継続中に一つのアドレスのみしか使用できないためである。このため、通信経路の変更によってＩＰアドレスが変更されると通信が継続できない。そこで、現在マルチホーム通信が可能な新しいトランスポートプロトコルであるＳＣＴＰに注目が集まっている。

ＳＣＴＰは、２０００年１０月にＲＦＣ２９６０としてＩＥＴＦ（Internet Engineering Task Force）で標準化されたトランスポートプロトコルであり、電話のシグナリング制御のためにＩＥＴＦ ＳＩＧＴＲＡＮワーキンググループにより開発されたものが基礎となっている。ＳＣＴＰはＴＣＰの機能の大部分を受け継ぎ、マルチホーム対応であることから次世代汎用トランスポートプロトコルとして期待されている。

しかしながら、標準化されてから間もないため、既存の機構のままインターネット上で通信をするのには不備な点も多い。現行のＳＣＴＰでは、同時にマルチホーム通信を行っているわけではなく、実際の通信は１組の送信元アドレス及び宛先アドレスによって行う。この送信元アドレス及び宛先アドレスをプライマリアドレス（primary address）と呼ぶ。プライマリアドレス以外に持っている送信元アドレス及び宛先アドレスをセカンダリアドレス（secondary address）と呼ぶ。そして、通常はプライマリアドレス同士で通信をおこない、セカンダリアドレスは再送のときのみ使用する。よって、現在のＳＣＴＰでは、複数の通信経路を使用した負荷分散を達成することはできない。また、ＳＣＴＰでは、ＴＣＰにおけるコネクションに相当するものとして、通信開始時に複数のアドレスによって構成されるアソシエーション（association）を確立し、信頼性のある通信を実現する。しかしながら、一度アソシエーションを確立すると動的なアドレスの追加はできない。これは、端末の移動に応じて動的にアドレスを変更する必要のある移動体通信においては、極めて大きな問題となる。また、ＳＣＴＰでは、プライマリアドレスはアソシエーション確立時に決定された後は変更できない。加えて、プライマリアドレスの選択手法は実装依存となっており、明確な決定方法が定義されていない。よって、他に高速に通信できるアドレスが存在するにもかかわらず通信速度が低速であるアドレスがプライマリアドレスに選択された場合、非常に効率の悪い通信となってしまう。また、無線区間の伝送誤りを考慮したフロー制御については、現在のところ規定されていない。

次いで、ＳＣＴＰの基本的な機能について簡単に説明する。図２１は従来技術に係るＳＣＴＰ（Stream Control Transmission Protocol）を用いた通信システムを示すブロック図である。

ＳＣＴＰでは、それぞれのホストの無線局をエンドポイントといい、本願では、その通信端末装置をエンドポイント装置５１Ａ，５１Ｂと呼ぶ。エンドポイント装置５１Ａ，５１Ｂは１つ又は複数のＩＰアドレスを持ち、双方のエンコード装置５１Ａ，５１Ｂが互いに通信するときに使用可能なアドレスリストを交換することによりアソシエーションを確立する。ここで、ＳＣＴＰのアソシエーションは、ＴＣＰのコネクションに相当するものである。ＳＣＴＰはＴＣＰと同様にコネクション指向型のプロトコルである。ＴＣＰでは、送信元のＩＰアドレス及び宛先のＩＰアドレスとポート番号を交換することでコネクションを確立していた。これに対しＳＣＴＰでは、送信元及び宛先のＩＰアドレスリストとポート番号を交換することでアソシエーションを確立する。

次いで、ＳＣＴＰの機能について以下に簡単に説明する。

ＳＣＴＰは、トランスポートプロトコルとして現在主に使われているＴＣＰからスロースタート、輻輳回避、ファストリカバリを含む輻輳制御機能、パケットロスの回復、再送のために選択的肯定確認応答（selective acknowledgement；以下、ＳＡＣＫという。）パケットを使用する再送機能などを受け継いでいる。従って、ＴＣＰで動く全てのアプリケーションは、ＳＣＴＰでその機能を失うことなく動作できる。ＳＣＴＰはＴＣＰから受け継いだ機能に加えて、新たに以下の機能も提供する。

（１）メッセージ境界の保持（message boundary preservation）：チャンク（chunk）により、バイト単位ではなくメッセージ単位で通信できる。サイズの小さなメッセージは、複数まとめて１つのチャンクに格納できる。また、サイズの大きなメッセージは、複数のチャンクに渡って分割できる。
（２）複数の転送モード（multiple delivery mode）:以下のような、さまざまな転送モードが存在する。（ａ）ＴＣＰのような厳密な順序転送。（ｂ）ストリームに応じた部分的な順序転送。（ｃ）ＵＤＰのような順序を保証しない転送。
（３）データの分割（user data fragment）：ＭＴＵ（Maximum Transmit Unit；以下、ＭＴＵという。）のサイズに従ってメッセージを分割する。この機能は、オプションで使われる。
（４）ハートビート（ＨＥＡＲＴＢＥＡＴ）による生存確認（heartbeat keep-alive mechanism）：ある一定期間データ送信に使用していない宛先アドレスに対して定期的にハートビート（ＨＥＡＲＴＢＥＡＴ）パケットを送り、その使用していなアドレスがアクティブ（動作状態）であるか否かを確認する。肯定確認応答（acknowledgement；以下、ＡＣＫという。）パケットがあるしきい値の回数だけ返ってこなければ、そのアドレスをインアクティブ（非動作状態）と認識し、通信には使用しないようにする。
（５）サービス不能攻撃（Denial of Service attack；以下、Ｄｏｓ攻撃という。）により保護：ＴＣＰで起こるＳＹＮフラッディングアタック（SYN flooding attacks）の影響を受けないように、アソシエーションを確立する段階でクッキー（cookie）というセキュリティ技術を使う。ここで、ＳＹＮはコネクションの確立を要求する同期フラグのパケットである。

図２２は図２１のＳＣＴＰで用いるＳＣＴＰパケットの構成を示す図である。図２２において、ＳＣＴＰパケットは、ＩＰヘッダ、送信元ポート番号、宛先ポート番号、照合タグ、チェックサム、チャンクタイプ、チャンクフラグ、チャンク長、ＴＳＮ（トランスポートシーケンス番号）、ストリームＩＤ（ストリーム識別子）、ＳＳＮ（ストリームシーケンス番号）、プロトコルＩＤ（プロトコル識別子）、ユーザデータ、少なくとも１つのチャンクを備えて構成される。

すなわち、図２２に示すように、ＳＣＴＰパケットは１つのＳＣＴＰ共通ヘッダと複数のチャンクからなる。チャンクには制御チャンクとデータチャンクがあるが、図２２ではデータチャンクの場合について示している。制御チャンクはアソシエーションの確立や解放のときなどに送信され、その際にはデータチャンクよりも必ず前に配置しなければならない。ＳＣＴＰ共通ヘッダについて説明する。まず、送信元及び宛先のポート番号は、ＳＣＴＰパケットの受信者を見分けるために使う。照合タグ（verification tag）は、以前のアソシエーションからの古いＳＣＴＰパケットの到着を防ぐ。従って、ＴＣＰでは以前のコネクションの内容を消去するために必要としていた、タイミング調整された待機状態（timed-wait state）は、ＳＣＴＰでは必要ない。最後にチェックサムは、ＳＣＴＰパケットがＩＰネットワーク上を通る際のデータの完全性を保証する。

次いで、チャンクについて説明する。チャンクはパス最大送信単位（Path Maximum Transmit Unit；以下、ＰＭＴＵという。）が許す限り、１つのＳＣＴＰパケットにまとめることができる。チャンクの先頭には、チャンクの種類や長さが記される。また、トランスポートシーケンス番号（Transport Sequence Number；以下、ＴＳＮという。）は単純に、転送の順番を表す番号である。ストリームＩＤ（Stream Identifier）は、ストリーム毎に付与される番号であり、従って、アソシエーションは複数のストリームを束ねたものとなる。さらに、ストリームシーケンス番号（Stream Sequence Number；以下、ＳＳＮという。）は、ストリーム内の転送の順番を表す番号である。プロトコルＩＤ（Protocol Identifier）には、ＳＣＴＰのプロトコル番号が格納され、ユーザデータ（User Data）には送信したいメッセージが格納される。

次いで、ＳＣＴＰのデータ転送に必要となる機能について説明し、まず、アソシエーションの確立と解放について説明する。

アソシエーションの確立は、４ウェイのハンドシェイク（4 way handshake）により行う。ＳＣＴＰの４ウェイのハンドシェイクとＴＣＰの３ウェイのハンドシェイクの最大の違いは、クッキーを使っている点である。クッキーの使用により、ＳＹＮフラッディングアタックを受けても影響を受けない。ＳＹＮフラッディングアタックとは、頻繁にＴＣＰが受ける攻撃であり、攻撃者から続々と送信されるＳＹＮに対して受信側がＳＹＮ−ＡＣＫを返信し続けることで記憶する情報が膨大となり、システムリソースが不足し通信継続が困難になる状況をいう。送信側は、送信されてきた情報をもとに相手を特定するためのクッキーを作成して通信相手に送信する。通信相手を確実に特定できるまではリソースの確保を行わないため、ＳＹＮフラッディングアタックを防ぐことができる。

アソシエーションの確立において用いられるＩＮＩＴチャンク、ＩＮＩＴ−ＡＣＫチャンク、ＣＯＯＫＩＥ−ＥＣＨＯチャンク、ＣＯＯＫＩＥ−ＡＣＫチャンクは、制御チャンクとして扱われる。さらに、アソシエーション確立の手順を説明すると、まず、エンドポイント装置５１Ａは、アソシエーションを確立するために必要な情報の初期値を含んだＩＮＩＴチャンクを送信し、クッキー待機状態に入る。エンドポイント装置５１Ｂは、ＩＮＩＴチャンクを受け取るとクッキーを含んだＩＮＩＴ−ＡＣＫチャンクを送信する。クッキーを用いることにより、メモリに保存する予定であった情報をＩＮＩＴ−ＡＣＫチャンクの中に詰め込む。エンドポイント装置５１Ａは、ＩＮＩＴ−ＡＣＫチャンクを受け取ると、その中からクッキーを取り出し、ＣＯＯＫＩＥ−ＥＣＨＯチャンクとして送信し、クッキーエコーされた状態に入る。エンドポイント装置５１Ｂは、ＣＯＯＫＩＥ−ＥＣＨＯチャンクを受け取るとそこからクッキーを取り出し、ＣＯＯＫＩＥ−ＡＣＫチャンクを送信する。以上の動作を経てアソシエーションが確立される。なお、ＩＮＩＴチャンク、ＩＮＩＴ−ＡＣＫチャンクの転送に使われているアドレスは、アソシエーション確立のためのアドレスリストに含まれていなくても、アソシエーションの一部となる。

また、ＳＣＴＰのアソシエーションの解放には、３ウェイハンドシェイクを用いる。ＴＣＰでは、データを受信している最中でもコネクションを解放できた。しかしながら、ＳＣＴＰではＴＣＰとは違い、丁寧な方法でアソシエーションの解放を行う。ＳＣＴＰのアソシエーションの解放において、ＳＨＵＴＤＯＷＮチャンク、ＳＨＵＴＤＯＷＮ−ＡＣＫチャンク、ＳＨＵＴＤＯＷＮ−ＣＯＭＰＬＥＴＥチャンクは、制御チャンクとして扱われる。さらに、アソシエーションの解放の手順を説明すれば、まず、エンドポイント装置５１Ａは、アソシエーションの解放を決定したあとは、上位層装置からのデータを受け付けない。そして、シャットダウン係属中状態に入り、現在キューにたまっているデータチャンクを送信する。エンドポイント装置５１Ａは、キューにたまっている全てのデータチャンクを送信したあと、ＳＨＵＴＤＯＷＮチャンクを送り、シャットダウン送信済み状態に入る。エンドポイント装置５１Ｂは、ＳＨＵＴＤＯＷＮチャンクを受け取ったあとは上位層装置からのデータを受け付けない。そして、シャットダウン受信済み状態に入り、現在キューにたまっているデータチャンクを送信する。エンドポイント装置５１Ａは、エンドポイント装置５１Ｂからデータチャンクが届く度にＳＨＵＴＤＯＷＮチャンクを送信する。エンドポイント装置５１Ｂは、キューにたまっている全てのデータチャンクを送信したあと、ＳＨＵＴＤＯＷＮ−ＡＣＫチャンクを送り、ＳＨＵＴＤＯＷＮ−ＡＣＫＳＥＮＴ状態に入る。エンドポイント装置５１Ａは、ＳＨＵＴＤＯＷＮ−ＡＣＫチャンクを受け取るとＳＨＵＴＤＯＷＮ−ＣＯＭＰＬＥＴＥチャンクを送信する。これでアソシエーションの解放が完了する。

次いで、ＳＣＴＰのデータ転送について以下説明する。ＳＣＴＰのデータ転送では、ＳＣＴＰパケットが到着する毎にＳＡＣＫチャンクを返す。ＳＡＣＫチャンクには、受信側（ここでは、エンドポイント装置５１Ｂ）がどのデータチャンクを受け取ったかの情報が格納される。具体的には、ＳＡＣＫチャンク中にあるギャップ肯定確認応答ブロック（ＧａｐＡｃｋｂｌｏｃｋ）というパラメータに受信したＴＳＮ（トランスポートシーケンス番号）を格納している。データチャンクの送信者は、これをもとに、どのデータチャンクを再送すべきかを特定できる。

また、ＳＣＴＰはＴＣＰと同様に、高速再送信とタイムアウトという２つの手法による再送アルゴリズムを提供する。プライマリアドレス同士で通信している際にパケット廃棄をＳＡＣＫチャンクにより検出すると、セカンダリアドレスに向けて再送を行い、エラーカウンタの計数値を１ずつ増加させる。セカンダリアドレスが通信可能であるかの確認は、ハートビート（ＨＥＡＲＴＢＥＡＴ）パケットにより行う。再送後は再びプライマリアドレス同士で通信を継続する。

さらに、データの再送制御について以下説明する。送信したＳＣＴＰパケットに対するＳＡＣＫチャンクを受信せずにタイムアウトが経過した場合には、同じ内容のＳＣＴＰパケットをセカンダリアドレスに対して再送する。その後、セカンダリアドレスに再送したＳＣＴＰパケットに対するＳＡＣＫチャンクを受信すると、それからの通信はプライマリアドレスによって再開される。このとき、再送タイマーの値を前回の２倍に設定する。この再送タイマーの値を再送信タイムアウト値（Retransmission Time Out；以下、ＲＴＯという。）という。また、タイムアウトをむかえる毎にＲＴＯを２倍に設定するアルゴリズムを「指数的バックオフ法」という。このように、再送タイマーのＲＴＯは、再送を行う度に２倍に設定され、指数的に増加する。再送を行った回数はアドレス毎にエラーカウンタで保持される。エラーカウンタは再送時やハートビート（ＨＥＡＲＴＢＥＡＴ）の送信時に加算される。送信したデータに対するＳＡＣＫチャンク又はハートビート（ＨＥＡＲＴＢＥＡＴ）応答チャンクを受け取ると、エラーカウンタはリセットされる。同時にＲＴＯも初期値である１秒となる。ＳＣＴＰでは、再送は所定のしきい値に達するまで連続して行われる。このしきい値であるパス最大再送信値（Path Maximum Retransmission；以下、ＰＭＲという。）を超えると、その宛先のプライマリアドレスをインアクティブ（非動作状態）とし、通信に使用しない。そして、宛先のセカンダリアドレスでの通信に切り替える。ただし、全ての宛先アドレスがインアクティブ（非動作状態）となった場合や、セカンダリアドレスを持たない場合は、アソシエーションそのものが喪失する。現行のＳＣＴＰでは、ＰＭＲの値は５が推奨されている。

さらに、ＳＣＴＰの障害検知や再送制御に使用される制御チャンクであるハートビート（ＨＥＡＲＴＢＥＡＴ）について説明する。ＳＣＴＰでは、送信側のエンドポイント装置５１Ａから宛先のエンドポイント装置５１Ｂのアドレスが使用可能であるかを、そのアドレスから制御チャンク、データチャンク、ハートビート（ＨＥＡＲＴＢＥＡＴ）チャンクの肯定確認応答（ＡＣＫ）が返信されているかどうかに基づいて判断する。これらの肯定確認応答（ＡＣＫ）がある一定期間に返信されていない場合は、ハートビート（ＨＥＡＲＴＢＥＡＴ）チャンクを送信することで通信可能であるかを確認する。このハートビート（ＨＥＡＲＴＢＥＡＴ）を送出する期間をハートビート周期（heartbeat period）という。ハートビート周期Ｈ_ｉは通常、次式で次式で与えられる。なお、当該明細書において、数式がイメージ入力された墨付き括弧の数番号と、数式が文字入力された大括弧の数式番号とを混在して用いており、また、当該明細書での一連の数式番号として「式（１）」の形式を用いて数式番号を式の最後部に付与して用いることとする。

［数１］
Ｈ_ｉ＝ＲＴＯ_ｉ＋ＨＢＩｎｔｅｒｖａｌ（１＋δ） （１）

ここで、ｉは宛先アドレスを表す。ＲＴＯ_ｉはその宛先アドレスにおける最新のＲＴＯ値が入力される。ＨＢＩｎｔｅｒｖａｌは３０秒が推奨されているが、ハートビート（ＨＥＡＲＴＢＥＡＴ）送信のタイミングは制御係数δを用いて制御されている。これにより、ハートビート（ＨＥＡＲＴＢＥＡＴ）を送信する際のトラフィックの増加を防いでいる。制御係数δは−０．５〜＋０．５の間のランダムな値であるので、式（１）の右辺第２項はＨＢＩｎｔｅｒｖａｌの値を±５０％した秒数となる。従って、式（１）の右辺第２項は１５〜４５秒の間の値をとりうる。ハートビート（ＨＥＡＲＴＢＥＡＴ）チャンクを受け取ったエンドポイント装置は、ハートビート（ＨＥＡＲＴＢＥＡＴ）チャンクの送信元アドレスへとハートビート肯定確認応答チャンク（heartbeat acknowledgement chunk）を送信する。

このハートビート（ＨＥＡＲＴＢＥＡＴ）はアイドル状態のパスにのみに送信することで、トラフィックの増大や必要以上の処理の増加を防いでいる。ここでいう、アイドル状態とは、データ転送時間（ＲＴＴ）の計測を行えるチャンク（例：再送でないＤＡＴＡ、ＩＮＩＴ、ＣＯＯＫＩＥＥＣＨＯ、ＨＥＡＲＴＢＥＡＴ）がハートビート周期内に１つも送られていない状態であり、アクティブ（動作状態）とインアクティブ（非動作状態）のどちらの場合にも適用される。宛先アドレスがアイドル状態でかつアクティブ（動作状態）であるときのハートビート周期は式（１）表される。宛先アドレスがアイドル状態でかつインアクティブ（非動作状態）であるときのハートビート周期は次式で与えられる。

［数２］
Ｈ_ｉ＝ＲＴＯ_{Ｉｎｉｔｉａｌ}＋ＨＢＩｎｔｅｒｖａｌ（１＋δ） （２）

ここで、ＲＴＯ_{Ｉｎｉｔｉａｌ}はＲＴＯの初期値であり、通常３秒に設定されている。ハートビート（ＨＥＡＲＴＢＥＡＴ）の送出を決定するハートビートタイマーはエンドポイント装置毎に保持されており、このタイマーをタイムアウトする毎にハートビート（ＨＥＡＲＴＢＥＡＴ）を１つ送信する。ハートビート（ＨＥＡＲＴＢＥＡＴ）を実際にどのアイドル状態の宛先アドレスに送信するかは実装依存となっている。

特開２０００−２２４１８０号公報。 特開２００３−０２３４４３号公報。 特開２００３−２５６３２１号公報。 R. Stewart et al., "RFC 2960 - Stream Control Transmission Protocol", Internet RFC/STD/FYI/BCP Archives, Network Working Group, October 2000， http://www.faqs.org/rfcs/rfc2960.html。 R. Stewart et al., "Stream Control Transmission Protocol (SCTP) Reference Guide", Addison-Wesley, 2002。 玉田妙子，"ＳＣＴＰにおける通信媒体選択手法の検証および評価"，特別研究報告，九州工業大学情報工学部電子情報工学科，平成１５年３月１０日，http://infonet.cse.kyutech.ac.jp/research-j/detail.php3?oid=29527。 Gavin Holland et al., "Analysis of TCP Performance over Mobile AD Hoc Networks", Wireless Networks, Kluwer Publishers Manufactured in The Netherlands, No. 8, pp.275-288, 2002。 Janardhan R. Iyengar et al., "Concurrent Multipath Transfer Using SCTP Multihoming", Collaborative Participation in the Communications and Networks Consortium sponsored by the U.S. Army Research Laboratory under the Collaborative Technology Program, Cisco Systems, http://www.cis.udel.edu/~amer/PEL/poc/pdf/TR2004-02.CMT.Iyengar.pdf。

例えば、アドホック無線ネットワークにおいてトランスポート層の通信手順として上述のＳＣＴＰを用いたときに、１つのアソシエーションのデータ転送全体のスループットを上げるために、単純に送信データを複数のルートに分けて送信することが考えられるが、複数のルートを同時に利用するだけで、ルートが動的に生成され削除される環境では、以下の問題点が生じる。

（Ａ）パケットロス検出手法に関する問題点（以下、問題点Ａという。）について。
転送データの消失を検出する主な手法は、実際のデータ転送時間に基づいてデータ到着時間を想定し、想定時間以内にデータが到着しなければ、データが失われたと見なし再送及びＣＷＮＤの更新を行う手法であり、いわゆる、タイムアウトに基づくパケットロスの検出手法である。例えばＳＣＴＰでは、次式を用いてＲＴＯを計算している。

［数３］
ＲＴＯ＝ＳＲＴＴ＋４×ＲＴＴＶＡＲ （３）

ここで、ＳＲＴＴはデータ転送時間の推定値であり、次式で計算される。

［数４］
ＳＲＴＴ_ｎｅｗ＝ＲＴＴ_１ｓｔ （４）
［数５］
ＳＲＴＴ＝（１−α）×ＳＲＴＴ_ｏｌｄ＋α×ＲＴＴ_ｎｅｗ （５）
［数６］
ＲＴＴＶＡＲ＝ＲＴＴ_１ｓｔ／２ （６）
［数７］
ＲＴＴＶＡＲ_ｎｅｗ
＝（１−β）×ＲＴＴＶＡＲ_ｏｌｄ＋β×｜ＳＲＴＴ_ｏｌｄ−ＲＴＴ_ｎｅｗ｜ （７）

ここで、ＲＴＴ_１ｓｔは最初に計測したＲＴＴ値であり、ＲＴＴＶＡＲはデータ転送時間の分散値である。また、α、βは所定の重み係数であり、好ましくは、α＝１／８，β＝１／４である。

しかしながら、上記の式を用いてＲＴＯを計算したとき、データ転送時間はルート毎に異なるために、アソシエーション全体で転送時間を計測すると、正確なデータ転送時間が得られず、実際にはデータが消失していなくても、データ消失を検出してしまう可能性が高くなる。その結果、無駄なデータの再送が発生するという問題点があった。

もう１つの転送データの消失を検出する主な手法は、データに割り振られたシーケンス番号に基づいて、式（３）を用いて計算されるタイムアウト時刻より前にデータを再送して輻輳ウィンドウ値（ＣＷＮＤ）の更新を行う手法であり、いわゆる高速再送信（Fast Retransmission）におけるパケットロスの検出方法である。具体的にはデータ受信側からの到着確認である選択的肯定確認応答（ＳＡＣＫ）において、特定のデータのシーケンス番号（ｎ）の到着番号に空きが発生した状態が４回続くと、データの再送を行う。しかしながら、データの到着順序は、ルートの状態に依存するために、アソシエーション全体でシーケンス番号を管理すると、他のルートよりデータ転送に時間がかかるルートから送られてきたデータを消失データと見なして、再送が発生する可能性が高くなる。その結果、無駄なデータの再送が発生するという問題点があった。

（Ｂ）輻輳制御に関する問題点（以下、問題点Ｂという。）について。
輻輳制御をアソシエーション全体で行うと、特定のルート上でパケットロスが発生した場合、パケットロスが発生していないルートにおいても輻輳ウィンドウサイズを小さくしてしまい、結果的に不必要に転送レートを下げてしまう。なお、ＳＣＴＰにおいては、次式を用いる。

（Ｂ１）再送タイマーが計時終了した場合。なお、「計時終了」とは、タイマーにセットされた時間が順次時間経過に応じてデクリメントされることにより、セットされた時間が経過してタイムオーバーすることをいう。

［数８］
Ｓｓｔｈｒｅｓｈ＝ｍａｘ（ＣＷＮＤ／２，２×ＭＴＵ） （８）
［数９］
ＣＷＮＤ＝１×ＭＴＵ （９）

（Ｂ２）高速再送信した場合。
［数１０］
Ｓｓｔｈｒｅｓｈ＝ｍａｘ（ＣＷＮＤ／２，２×ＭＴＵ） （１０）
［数１１］
ＣＷＮＤ＝Ｓｓｔｈｒｅｓｈ （１１）

ここで、Ｓｓｔｈｒｅｓｈは、ＳＣＴＰにおけるスロースタートしきい値であって、輻輳制御のスロースタートモードと輻輳回避モードとを切り換えるための値である。なお、ｍａｘ（Ａ，Ｂ）は、２つの引数Ａ，Ｂのうち最大値を出力する最大値関数である。

（Ｃ）ルートの状態管理に関する問題点（以下、問題点Ｃという。）について。
これは、ルート切り替えに基づく無駄なデータ再送の発生に関するものである。具体的には、アドホック無線ネットワークなどのネットワークにおいて、ルートの状態が激しく変動するような環境においては、同じルートＩＤ（ＲＩＤ）について削除と追加を繰り返す場合が想定される。従来技術に係るＳＣＴＰでは、パスの状態を「アクティブ（動作状態）」と「インアクティブ（非動作状態）」に分けて管理している。また、パスの状態をインアクティブ（非動作状態）に遷移するためには、ハートビート（ＨＥＡＲＴＢＥＡＴ）チャンクを複数回送信し、十分な待ち時間を経過してから状態を遷移させる。しかしながら、上述のようにルートの削除、追加が激しく変動する場合、また、ルートの状態が下位層装置から通知される場合、ルート状態の変更検出は十分な待ち時間の後で行われない可能性がある。このとき、以下の問題点が発生する。

データの送信ルートと、受信確認データである選択的肯定確認応答（ＳＡＣＫ）の送信ルートが異なる場合、ルートの削除を検出しても、実際には転送データは通信相手に届く可能性がある。また、受信確認通知である肯定確認応答（ＡＣＫ）も他のルートを通してデータ送信側に到着する可能性がある。ルート削除の通知をトリガーにして、管理情報を初期化した場合、結果として無駄なデータ再送が発生するという問題点があった。

（Ｄ）ルート選択に関する問題点（以下、問題点Ｄという。）について。
複数のルートを利用する場合通常は、利用可能なルートが静的に決まっている場合と、動的に変化する場合がある。アドホック無線ネットワークではない従来技術に係るインターネットにおいては、静的なルーティング情報に基づいてルートが決定される。しかしながら、ルートが動的に変化する場合、効率よくルートの情報を取得して利用するためには以下の問題があった。

（Ｄ１）ルート検出パケットによるネットワーク負荷の発生（以下、問題点Ｄ１という、）について。
アドホック無線ネットワーク等の静的なルート情報が利用できない状況では、ルートの状態を監視するためにはブロードキャストパケットを定期的（時間、イベント）に送信する必要がある。特に、ブロードキャストパケットはネットワークに対して高負荷をかけるために、できるだけ送信する回数を減らす必要がある。

（Ｄ２）古いルート情報を利用することによる問題点（以下、問題点Ｄ２という。）について。
複数のルートを動的に検出して利用する場合、上記で述べたようにルートの検索要求パケット数をできるだけ減らして、ネットワーク負荷を必要以上にあげてはならない。またその場合は、ルート検索結果を内部にキャッシュしておく必要がある。しかしながら、キャッシュしたルート情報は、前回ルート検索した時点の情報であり、端末装置が移動をするような場合はルートの切り替えが発生した段階では、キャッシュしたルートが利用不可能な古い情報になっている可能性がある。しかし、ルート検索を減らす（全ルート利用不可能な場合のみ検索する）と１つずつのルートで実際にデータを転送するまで、ルートの状態を検出できない。もし利用不可能なルートが複数個キャッシュに存在すれば、各ルートのエラー検出時間の総和時間までまたないと、ルート検出処理が動作しない可能性がある。

（Ｄ３）指数的バックオフ法（Exponential Back Off）に関連した問題点（以下、問題点Ｄ３という。）について。
従来技術に係る再送タイムアウト時間調整方式である指数的バックオフ法では、再送タイムアウトイベントが発生する度に、次式のごとく、再送タイムアウト時間ＲＴＯ_ｎｅｗを前回の再送タイムアウト時間ＲＴＯｏｌｄの２倍の時間に設定している。

［数１２］
ＲＴＯ_ｎｅｗ＝ＲＴＯ_ｏｌｄ×２ （１２）

しかしながら、この方式はインターネットにおける輻輳を回避するために提案されている。マルチルートを利用する主な環境である、アドホック無線ネットワークにおいては輻輳が発生していなくても、端末装置の移動によるリンクの切断によってパケットが連続して廃棄される可能性がある。上記の場合は、再送タイムアウト時間（ＲＴＯ）を必要以上に大きくしてしまい、スループット悪化の原因となるという問題点があった。

（Ｄ４）選択したルート間で品質の差が大きい場合の問題点（以下、問題点Ｄ４という。）について。
上述のように、複数のルートを同時に利用する場合、アドホック無線ネットワークのトポロジー（例えば、ルートの構成、電波環境など）によってルートの品質が異なる。例えば、データ転送時間（ＲＴＴ）に関しても、ルート毎で異なる値になる可能性が大きい。また、トポロジーによっては、利用可能なルートのデータ転送時間（ＲＴＴ）のばらつきが非常に大きくなる。その場合、データ転送時間（ＲＴＴ）の大きなルートにおいて、輻輳ウィンドウ値（ＣＷＮＤ）が大きくなると、データ転送時間（ＲＴＴ）の大きなルートでデータを転送している間に、データ転送時間（ＲＴＴ）の小さなルートが受信側のバッファを埋めつくしてしまう可能性があり、一時的にはデータ転送が停止する場合もあるという問題点があった。

本発明の目的は以上の問題点を解決し、例えばアドホック無線ネットワークなどの無線ネットワークにおいて、１つのアソシエーションに属する複数のパケットを複数のルートを用いて、従来技術に比較して効率的に伝送することができ、データ転送全体のスループットを向上できる無線ネットワークの制御装置及び制御方法、制御プログラム並びに、上記制御プログラムを格納したコンピュータにより読み取り可能な記録媒体を提供することにある。

第１の発明に係る無線ネットワークの制御装置は、トランスポート層の所定のプロトコルを用いて１つのデータの複数のパケットを送信元通信端末装置から宛先通信端末装置に伝送する無線ネットワークの制御装置であって、
上記データの各パケットに対して、ルートを識別するルート識別子（ＲＩＤ）と、ルート毎のシーケンス番号であるルートシーケンス番号（ＲＳＮ）とを付して、上記各パケットを複数のルートを介して伝送するように制御する制御手段を備えたことを特徴とする。

上記無線ネットワークの制御装置において、上記制御手段は、宛先通信端末装置からの、送信パケットに対する選択的肯定確認応答（ＳＡＣＫ）メッセージに応答して、ルート識別子（ＲＩＤ）に基づいて、ルート毎のデータ転送時間（ＲＴＴ）を計算するルート毎の再送タイマーを含み、再送時刻を管理することを特徴とする。

また、上記無線ネットワークの制御装置において、上記制御手段は、宛先通信端末装置からの、同一の送信データに対する所定の複数回の選択的肯定確認応答（ＳＡＣＫ）メッセージに応答して、上記各選択的肯定確認応答（ＳＡＣＫ）メッセージに含まれるルート識別子（ＲＩＤ）及びルートシーケンス番号（ＲＳＮ）に基づいて、再送マークを付与して高速再送信で当該送信データの再送処理を実行することを特徴とする。

さらに、上記無線ネットワークの制御装置において、上記制御手段は、宛先通信端末装置からの、送信パケットに対する選択的肯定確認応答（ＳＡＣＫ）メッセージに応答して、上記選択的肯定確認応答（ＳＡＣＫ）で通知されたルート識別子（ＲＩＤ）で示されたルートを介して送信データを再送することを特徴とする。

またさらに、上記無線ネットワークの制御装置において、上記制御手段は、宛先通信端末装置からの、ルート削除の通知メッセージを受信したときに、上記通知されたルートにおいて再送マークが付された送信データがあるとき、当該送信データを他のルートを介して再送することを特徴とする。

また、上記無線ネットワークの制御装置において、上記制御手段は、宛先通信端末装置からの、送信パケットに対する選択的肯定確認応答（ＳＡＣＫ）メッセージに応答して、ルート識別子（ＲＩＤ）に基づいて、ルート毎の輻輳ウィンドウ値（ＣＷＮＤ）を計算することを特徴とする。

さらに、上記無線ネットワークの制御装置において、上記制御手段は、各ルートに送信している送信データを把握し、全てのルートにおける伝送中の送信データのデータサイズを計算し、上記計算した当該全てのルートにおける伝送中の送信データのデータサイズに基づいてフロー制御することを特徴とする。

またさらに、上記無線ネットワークの制御装置において、上記制御手段は、宛先通信端末装置からの、送信パケットに対する選択的肯定確認応答（ＳＡＣＫ）メッセージにより通知された受信バッファサイズから、上記計算した当該全てのルートにおける伝送中の送信データのデータサイズと、新規に送信するデータのサイズとを減算した値が０以上であるときに、当該新規に送信するデータを送信することを特徴とする。

また、上記無線ネットワークの制御装置において、上記制御手段は、宛先通信端末装置からの、送信パケットに対する選択的肯定確認応答（ＳＡＣＫ）メッセージにより通知された受信バッファサイズが０であるときに、上記計算した全てのルートにおける伝送中の送信データのデータサイズが０でないとき、当該ルートを介して送信データを送信することを中止するように制御することを特徴とする。

さらに、上記無線ネットワークの制御装置において、上記制御手段は、宛先通信端末装置からの、ルート削除の通知メッセージを受信したときに、通常ルート処理における削除済み状態に遷移し、宛先通信端末装置からの、送信パケットに対する選択的肯定確認応答（ＳＡＣＫ）メッセージに応答して、当該ルートを介して伝送中の送信データのデータサイズが０でないとき、送信データを他のルートで当該ルートの輻輳ウィンドウ値の範囲で再送する一方、当該ルートを介して伝送中の送信データのデータサイズが０となったとき、当該ルートを削除することを特徴とする。

またさらに、上記無線ネットワークの制御装置において、上記制御手段は、通常ルート処理における削除済み状態にあるときに、宛先通信端末装置からの、ルート追加の通知メッセージを受信したときに、通常ルート処理における待機削除状態に遷移し、当該待機削除状態において、宛先通信端末装置からの、ルート削除の通知メッセージを受信したときに、通常ルート処理における削除済み状態に戻ることを特徴とする。

また、上記無線ネットワークの制御装置において、上記制御手段は、デフォルトルートの初期状態においてルート追加の通知メッセージを受信したとき待機初期状態となり、当該待機初期状態においてＨＥＡＲＴＢＥＡＴ−ＡＣＫメッセージを受信して再送すべきデータがあり再送できれば、確立済み状態に遷移し、また、デフォルトルート処理の初期状態においてデフォルトルートのルート識別子（ＲＩＤ）であって当該状態が確立済みになったとき、ＨＥＡＲＴＢＥＡＴメッセージを送信して、デフォルトルート処理の停止状態に遷移し、当該停止状態においてデフォルトルートのルート識別子（ＲＩＤ）であって他のルートが全て確立済み以外の状態になったときＨＥＡＲＴＢＥＡＴメッセージを送信して待機初期状態に遷移することを特徴とする。

さらに、上記無線ネットワークの制御装置において、上記制御手段は、上記確立済み状態においてデフォルトルートのルート識別子（ＲＩＤ）であって他のルートのいずれかの状態確立済み状態になったとき削除済みデフォルト状態に遷移し、再送タイマーが計時終了し選択的肯定確認応答（ＳＡＣＫ）メッセージを受信しかつ当該デフォルトルートを介して伝送中の送信データのデータサイズが０となったとき停止状態に遷移することを特徴とする。

またさらに、上記無線ネットワークの制御装置において、上記プロトコルはＳＣＴＰ（Stream Control Transmission Protocol）であることを特徴とする。

第２の発明に係る無線ネットワークの制御方法は、トランスポート層の所定のプロトコルを用いて１つのデータの複数のパケットを送信元通信端末装置から宛先通信端末装置に伝送する無線ネットワークの制御方法であって、
上記データの各パケットに対して、ルートを識別するルート識別子（ＲＩＤ）と、ルート毎のシーケンス番号であるルートシーケンス番号（ＲＳＮ）とを付して、上記各パケットを複数のルートを介して伝送するように制御する制御ステップを含むことを特徴とする。

上記無線ネットワークの制御方法において、上記制御ステップは、宛先通信端末装置からの、送信パケットに対する選択的肯定確認応答（ＳＡＣＫ）メッセージに応答して、ルート識別子（ＲＩＤ）に基づいて、ルート毎のデータ転送時間（ＲＴＴ）を計算するルート毎の再送タイマーを含み、再送時刻を管理することを特徴とする。

また、上記無線ネットワークの制御方法において、上記制御ステップは、宛先通信端末装置からの、同一の送信データに対する所定の複数回の選択的肯定確認応答（ＳＡＣＫ）メッセージに応答して、上記各選択的肯定確認応答（ＳＡＣＫ）メッセージに含まれるルート識別子（ＲＩＤ）及びルートシーケンス番号（ＲＳＮ）に基づいて、再送マークを付与して高速再送信で当該送信データの再送処理を実行することを特徴とする。

さらに、上記無線ネットワークの制御方法において、上記制御ステップは、宛先通信端末装置からの、送信パケットに対する選択的肯定確認応答（ＳＡＣＫ）メッセージに応答して、上記選択的肯定確認応答（ＳＡＣＫ）で通知されたルート識別子（ＲＩＤ）で示されたルートを介して送信データを再送することを特徴とする。

またさらに、上記無線ネットワークの制御方法において、上記制御ステップは、宛先通信端末装置からの、ルート削除の通知メッセージを受信したときに、上記通知されたルートにおいて再送マークが付された送信データがあるとき、当該送信データを他のルートを介して再送することを特徴とする。

また、上記無線ネットワークの制御方法において、上記制御ステップは、宛先通信端末装置からの、送信パケットに対する選択的肯定確認応答（ＳＡＣＫ）メッセージに応答して、ルート識別子（ＲＩＤ）に基づいて、ルート毎の輻輳ウィンドウ値（ＣＷＮＤ）を計算することを特徴とする。

さらに、上記無線ネットワークの制御方法において、上記制御ステップは、各ルートに送信している送信データを把握し、全てのルートにおける伝送中の送信データのデータサイズを計算し、上記計算した当該全てのルートにおける伝送中の送信データのデータサイズに基づいてフロー制御することを特徴とする。

またさらに、上記無線ネットワークの制御方法において、上記制御ステップは、宛先通信端末装置からの、送信パケットに対する選択的肯定確認応答（ＳＡＣＫ）メッセージにより通知された受信バッファサイズから、上記計算した当該全てのルートにおける伝送中の送信データのデータサイズと、新規に送信するデータのサイズとを減算した値が０以上であるときに、当該新規に送信するデータを送信することを特徴とする。

また、上記無線ネットワークの制御方法において、上記制御ステップは、宛先通信端末装置からの、送信パケットに対する選択的肯定確認応答（ＳＡＣＫ）メッセージにより通知された受信バッファサイズが０であるときに、上記計算した全てのルートにおける伝送中の送信データのデータサイズが０でないとき、当該ルートを介して送信データを送信することを中止するように制御することを特徴とする。

さらに、上記無線ネットワークの制御方法において、上記制御ステップは、宛先通信端末装置からの、ルート削除の通知メッセージを受信したときに、通常ルート処理における削除済み状態に遷移し、宛先通信端末装置からの、送信パケットに対する選択的肯定確認応答（ＳＡＣＫ）メッセージに応答して、当該ルートを介して伝送中の送信データのデータサイズが０でないとき、送信データを他のルートで当該ルートの輻輳ウィンドウ値の範囲で再送する一方、当該ルートを介して伝送中の送信データのデータサイズが０となったとき、当該ルートを削除することを特徴とする。

またさらに、上記無線ネットワークの制御方法において、上記制御ステップは、通常ルート処理における削除済み状態にあるときに、宛先通信端末装置からの、ルート追加の通知メッセージを受信したときに、通常ルート処理における待機削除状態に遷移し、当該待機削除状態において、宛先通信端末装置からの、ルート削除の通知メッセージを受信したときに、通常ルート処理における削除済み状態に戻ることを特徴とする。

また、上記無線ネットワークの制御方法において、上記制御ステップは、デフォルトルートの初期状態においてルート追加の通知メッセージを受信したとき待機初期状態となり、当該待機初期状態においてＨＥＡＲＴＢＥＡＴ−ＡＣＫメッセージを受信して再送すべきデータがあり再送できれば、確立済み状態に遷移し、また、デフォルトルート処理の初期状態においてデフォルトルートのルート識別子（ＲＩＤ）であって当該状態が確立済みになったとき、ＨＥＡＲＴＢＥＡＴメッセージを送信して、デフォルトルート処理の停止状態に遷移し、当該停止状態においてデフォルトルートのルート識別子（ＲＩＤ）であって他のルートが全て確立済み以外の状態になったときＨＥＡＲＴＢＥＡＴメッセージを送信して待機初期状態に遷移することを特徴とする。

さらに、上記無線ネットワークの制御方法において、上記制御ステップは、上記確立済み状態においてデフォルトルートのルート識別子（ＲＩＤ）であって他のルートのいずれかの状態確立済み状態になったとき削除済みデフォルト状態に遷移し、再送タイマーが計時終了し選択的肯定確認応答（ＳＡＣＫ）メッセージを受信しかつ当該デフォルトルートを介して伝送中の送信データのデータサイズが０となったとき停止状態に遷移することを特徴とする。

またさらに、上記無線ネットワークの制御方法において、上記プロトコルはＳＣＴＰ（Stream Control Transmission Protocol）であることを特徴とする。

第３の発明に係る無線ネットワークのプログラムは、上記無線ネットワークの制御方法における各ステップを含むことを特徴とする。

第４の発明に係るコンピュータで読み取り可能な記録媒体は、上記プログラムを格納したことを特徴とする。

従って、本発明に係る無線ネットワークのための制御装置及び制御方法によれば、トランスポート層の所定のプロトコルを用いて１つのデータの複数のパケットを送信元通信端末装置から宛先通信端末装置に伝送する無線ネットワークの制御装置及び制御方法であって、上記データの各パケットに対して、ルートを識別するルート識別子（ＲＩＤ）と、ルート毎のシーケンス番号であるルートシーケンス番号（ＲＳＮ）とを付して、上記各パケットを複数のルートを介して伝送するように制御する。ここで、例えば、宛先通信端末装置からの、送信パケットに対する選択的肯定確認応答（ＳＡＣＫ）メッセージに応答して、ルート識別子（ＲＩＤ）に基づいて、ルート毎のデータ転送時間（ＲＴＴ）を計算するルート毎の再送タイマーを含み、再送時刻を管理し、また、宛先通信端末装置からの、同一の送信データに対する所定の複数回の選択的肯定確認応答（ＳＡＣＫ）メッセージに応答して、上記各選択的肯定確認応答（ＳＡＣＫ）メッセージに含まれるルート識別子（ＲＩＤ）及びルートシーケンス番号（ＲＳＮ）に基づいて、再送マークを付与して高速再送信で当該送信データの再送処理を実行する。それ故、例えばアドホック無線ネットワークなどの無線ネットワークにおいて、１つのアソシエーションに属する複数のパケットを複数のルートを用いて、従来技術に比較して効率的に伝送することができ、データ転送全体のスループットを向上できる。

以下、本発明に係る実施形態について図面を参照して説明する。なお、同様の構成要素については同一の符号を付している。

本発明に係る実施形態では、アドホック無線ネットワーク技術により、近い将来に地域社会における多様なサービス（無料ＩＰ電話、地域掲示板、監視カメラ画像の共有等）が提供されることを想定し、アドホック無線ネットワークにおけるスケーラビリティ向上を目的としている。本実施形態ではアドホック無線ネットワークの品質改善のアプローチとして、アドホック無線ネットワークプロトコル上でデータ送信に複数のルートを同時に利用する方式を提案する。また、複数のルートを効率良く同時に利用するためには、アドホック無線ネットワークプロトコルに対する拡張だけでなく、トランスポート層プロトコルに対する拡張が必要となる。本来、アドホック無線ネットワークプロトコルはＩＰ層及びリンク層で実装されパケットのルーティングを行うことがプロトコルの主目的である。複数のルートを同時に利用するためには、複数のルートの中からどのルートをデータ送信に利用するか（ルート選択）またルートをいつ利用するか（送信スケジュール）を動的に決定する必要がある。ＴＣＰの通信に置き換えると、ルート選択は送信元アドレスの選択に該当し、送信スケジュールは肯定確認応答（ＡＣＫ）受信をトリガーにデータ転送を行うＴＣＰの機能である。これらの処理はアドホック無線ネットワークプロトコルの役割外の機能であり、トランスポート層のプロトコルの機能である。そこで、本実施形態では、アドホック無線ネットワークの品質改善のアプローチとして、マルチルート環境でアドホック無線ネットワークを効率良く使用するために、トランスポート層のプロトコルであるＳＣＴＰを拡張する。

すなわち、本実施形態においては、アドホック無線ネットワークにおいて、トランスポート層の通信手順であるＳＣＴＰを拡張して、複数のルートを同時にデータ転送に利用することにより以下のことを達成することを目的としている。
（１）データ転送全体での遅延を減らす。
（２）データの転送レートを上げる。
（３）転送ルート中に障害が発生した場合、データ転送を止めることなく直ぐにデータ転送を続ける。

さらに、利用する複数のルートが追加と削除を繰り返す場合（アドホック無線ネットワークのように不安定なルート状態の場合）以下のことを達成することを目的としている。
（４）ルートの切り替えが発生した場合に、無駄な再送を減らす。
（５）同一のルートＩＤ（ＲＩＤ）のルートが削除と追加を繰り返した場合、そのルートはすぐに利用せず、不安定なルートの利用を避ける。

図１は、本発明の実施形態に係るアドホック無線ネットワークのためのエンドポイント装置５０の構成を示すブロック図である。図１において、本実施形態に係るエンドポイント装置５０は、アンテナ１を備えた無線送受信部２と、マルチルート−ダイナミック・ソース・ルーティング（Dynamic Source Routing）処理部（以下、ＭＲ−ＤＳＲ処理部という。）１０と、マルチルート−ＳＣＴＰ処理部（以下、ＭＲ−ＳＣＴＰ処理部という。）２０と、上位層装置３０とを備えて構成される。

無線送受信部２は、アドホック無線ネットワークでの無線通信を実行するために、ＭＡＣ層の無線信号を処理するための無線送受信機であって、例えば、ＩＥＥＥ８０２．１１やブルートゥース（Bluetooth）などに準拠して構成される。無線送受信部２は、アンテナ１を用いて無線信号を受信し、高周波増幅、中間周波変換、中間周波増幅、復調などの処理を実行することにより、所定のデータ信号に復調してＭＲ−ＤＳＲ処理部１０に出力する。一方、ＭＲ−ＤＳＲ処理部１０から入力されるデータ信号は、変調、高域周波変換、高周波電力増幅などの処理を実行することにより、無線信号に変換してアンテナ１を用いて放射する。

また、ＭＲ−ＤＳＲ処理部１０は、アドホックルーティングプロトコル処理部１２と、それを制御するコントローラ１１とを備えて構成される。ここで、アドホックルーティングプロトコル処理部１２は、受信バッファメモリ１２ａと、送信バッファメモリ１２ｂとを内蔵する。ＭＲ−ＤＳＲ処理部１０は、ＩＰ層においてデータ信号をルーティングするための処理部であって、マルチルートで拡張された本実施形態に係るＭＲ−ＳＣＴＰを用いてアドホック無線通信するために、マルチルートで拡張されたダイナミック・ソース・ルーティング法（以下、ＤＳＲ法という。）を用いてデータ信号のルーティングを行う。ＤＳＲ法は、リアクティブ型の経路制御プロトコルであって、ユニットキャスト、マルチキャストをサポートし、送信元のエンドポイント装置から宛先のエンドポイント装置までの始点経路制御方式を採用している。すなわち、ＭＲ−ＳＣＴＰ処理部２０から入力されるデータ信号を一時的に送信バッファメモリ１２ｂに格納した後所定のルーティング情報を付加して無線送受信部２に出力するとともに、無線送受信部２から入力される他の宛先のデータ信号を一時的に受信バッファメモリ１２ａに格納した後転送のための所定のルーティング情報を付加して無線送受信部２に出力し、また、無線送受信部２から入力される自装置宛のデータ信号を受信バッファメモリ１２ａに格納した後ＭＲ−ＳＣＴＰ処理部２０に出力する。

さらに、ＭＲ−ＳＣＴＰ処理部２０は、当該処理部２０全体の動作を制御するコントローラ２１と、プロトコルインターフェース２２と、バンドル／アンバンドル処理部２３と、ルート毎輻輳制御部２４と、アソシエーションフロー制御部２５と、アソシエーションバッファ部２６と、フラグメント／リアッセンブリ処理部２７とを備えて構成される。ＭＲ−ＳＣＴＰ処理部２０は、マルチルートで拡張された本実施形態に係るＭＲ−ＳＣＴＰを用いて、トランスポート層でのデータ信号を処理する。

ここで、プロトコルインターフェース２２は、ＭＲ−ＤＳＲ処理部１０と、ＭＲ−ＳＣＴＰ処理部２０との間のプロトコル変換及び信号変換などのインターフェース処理を実行し、また、ＭＲ−ＳＣＴＰ処理部２０におけるルート情報を管理する。また、バンドル／アンバンドル処理部２３は、入出力されるデータ信号についてチャンクのバンドル又はアンバンドルを実行する。さらに、ルート毎輻輳制御部２４は、仮想的には生成されるルート毎に制御部が生成され、データ信号を転送するルート毎に詳細後述するように輻輳制御を行う。また、アソシエーションフロー制御部２５は、ＭＲ−ＳＣＴＰを用いてアソシエーションを伝送するときにアソシエーション全体のフローを制御する。さらに、ＭＲ−ＳＣＴＰを用いてアソシエーションを伝送するときにアソシエーション全体をまとめて一時的に格納するために提供される。またさらに、フラグメント／リアッセンブリ処理部２７は、上位層装置３０から入力されるアプリケーションデータをフラグメントした後、アソシエーションバッファ部２６に出力する一方、アソシエーションバッファ部２６からのデータ信号をリアッセンブリしてアプリケーションデータに変換して上位層装置３０に出力する。

以上のように構成されたＭＲ−ＳＣＴＰ処理部２０において、当該エンドポイント装置５０で受信された無線信号のデータ信号は、ＭＲ−ＤＳＲ処理部１０からプロトコルインターフェース２２を介してＭＲ−ＳＣＴＰ処理部２０に入り、バンドル／アンバンドル処理部２３、ルート毎輻輳制御部２４、アソシエーションフロー制御部２５、アソシエーションバッファ部２６、フラグメント／リアッセンブリ処理部２７の順序で処理がなされて、上位層装置３０に出力される。一方、当該エンドポイント装置５０から送信されるデータ信号は、上位層装置３０からフラグメント／リアッセンブリ処理部２７に入り、アソシエーションバッファ部２６、アソシエーションフロー制御部２５、ルート毎輻輳制御部２４、バンドル／アンバンドル処理部２３の順序で処理がなされて、プロトコルインターフェース２２を介してＭＲ−ＤＳＲ処理部１０に出力される。なお、上位層装置３０は、アプリケーション層などでの処理を行う装置である。

図１のＭＲ−ＳＣＴＰ処理部２０内のコントローラ２１は例えばディジタル計算機又はコンピュータで構成され、コントローラ２１によって実行される詳細後述する制御フロー又は制御方法の各ステップは無線ネットワークの制御プログラムで記述され、当該プログラムは、例えばコンピュータにより読み取り可能なＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ±Ｒ、ＤＶＤ±ＲＷなどの光ディスク等の記録媒体に格納されてもよい。当該記録媒体に格納された無線ネットワークの制御プログラムはコンピュータにより読み取り可能な光ディスクドライブに挿入して読み出して、コントローラ２１にロードした上で当該制御プログラムが実行される。

上述した問題点Ａ，Ｂ，Ｃ，Ｄを解決するために、ＭＲ−ＳＣＴＰ処理部２０ではルートの状態を表す変数である通信制御データを新規に導入する。これらの通信制御データは、複数の処理において共通して取り扱われる場合が多いため、まず、新規又は拡張を行った主な通信制御データについて述べる。そしてそれらの通信制御データが上記の問題解決に対してどのように使われるのかについて述べる。

上述のこれらの問題の原因について考えると、複数のルートを同時に利用するデータ転送処理では、関連データを分析するとルート毎に保持し更新すべき制御データと、アソシエーション全体で保持し更新すべきデータに分類できる。しかし、従来技術のＳＣＴＰの例では、それらの考慮を行わずに全ての値をアソシエーション全体で制御しており、そのために不正確な情報に基づく転送制御が行われている。また、問題点Ｄに示すように、データ管理対象をルートとアソシエーションに分けた場合でも、ルートの状態管理と、転送処理を適切に分割していないと、同じく転送効率の悪化の原因となる。これを解決するために、以下の表に示す主な通信制御データを用いる。

図２は図１の通信制御データメモリ２１ａに格納される詳細データを示すブロック図である。図２において、拡張されたＳＣＴＰにおいて用いるＳＣＴＰインスタンスデータ９０は、アソシエーションリストと、秘密キーと、アドレスリストと、ＳＣＴＰポートと、アソシエーション毎データ９１とを含む。ここで、アソシエーション毎データ９１は、ピア照合タグなどの後述するデータと、宛先アドレスリスト９２と、ピア宛先リスト９３と、ストリームリスト９４とを含む。上記宛先アドレスリスト９２は、エラー計数値などの後述するデータと、ルートリスト９５とを含み、上記ピア宛先リスト９３は送信元アドレスと、ピアルートリスト９６とを含む。また、上記ストリームリスト９４は、ストリームと、アンオーダー情報とを含む。さらに、上記ルートリスト９５は、状態などの後述するデータと、ピアルートリスト９６と、ルートＩＤ（ＲＩＤ）と、マッピングアレイ（ＲＳＮ）とを含む。

さらに、これらの通信制御データについて以下に説明する。

（１）ＳＣＴＰインスタンスデータ９０：
＞アソシエーションリスト：ＭＲ−ＳＣＴＰ処理部２０のコントローラ２１に生成されたアソシエーションのリストである。
＞秘密キー：ＭＡＣ層で使用するキーコードである。
＞アドレスリスト：ＭＲ−ＳＣＴＰ処理部２０が使用するＩＰアドレスのリストである。
＞ＳＣＴＰポート：ＭＲ−ＳＣＴＰ処理部２０が使用するポート番号である。

（２）アソシエーション毎データ９１：
＞ピア照合タグ：パケットを送信するときにつけられるアソシエーションの識別子であり、ＩＮＩＴチャンク又はＩＮＩＴ−ＡＣＫチャンクから受け取る。
＞マイ照合タグ：全ての受信パケットに要求するアソシエーションの識別子であり、ＩＮＩＴチャンク又はＩＮＩＴ−ＡＣＫチャンクで送信する。
＞状態：アソシエーションがどのような状態にあるかを示す値であり、一例として以下の値を含む。
（ａ）閉鎖（ＣＬＯＳＥＤ）。
（ｂ）クッキー待機（ＣＯＯＫＩＥ＿ＷＡＩＴ）。
（ｃ）クッキーエコー済み（ＣＯＯＫＩＥ＿ＥＣＨＯＥＤ）。
（ｄ）確立済み（ＥＳＴＡＢＬＩＳＨＥＤ）。
（ｅ）シャットダウン送信済み（ＳＨＵＴＤＯＷＮ＿ＳＥＮＴ）。
（ｆ）シャットダウン受信済み（ＳＨＵＴＤＯＷＮ＿ＲＥＣＥＩＶＥＤ）。
（ｇ）シャットダウン肯定確認応答送信済み（ＳＨＵＴＤＯＷＮ＿ＡＣＫ＿ＳＥＮＴ）。
（ｈ）シャットダウン係属中（ＳＨＵＴＤＯＷＮ＿ＰＥＮＤＩＮＧ）。
＞宛先アドレスリスト９２：ＳＣＴＰのエンドポイント装置５０が持つ宛先アドレスの一覧である。
＞プライマリパス：主として使用する宛先アドレスである。
＞オーバーオールエラー計数値：アソシエーションで発生したエラーを計数した計数値である。
＞オーバーオールエラーしきい値：アソシエーションをシャットダウンさせるために使われるエラーカウントのしきい値である。
＞ピアＲＷＮＤ：ＭＲ−ＳＡＣＫチャンクに含まれる空きバッファ容量ＡＲＷＮＤに基づいて計算された、相手側（受信側）のエンドポイント装置５０の空きバッファ容量（ＲＷＮＤ）の値である。
＞次のＡＳＮ：次に送信するＭＲ−ＤＡＴＡチャンクのＡＳＮ（アソシエーションシーケンス番号）の値である。
＞最後に受信したＡＳＮ：最後に受信したチャンクのＡＳＮの値であり、ＩＮＩＴチャンク又はＩＮＩＴ−ＡＣＫチャンクに書かれた初期ＡＳＮの値で初期化される。
＞マッピングアレイ：ＡＳＮの順番とは違った順番で受信したＭＲ−ＤＡＴＡチャンクを示すビット、もしくはバイトの配列であり、全てのチャンクがＲＳＮの順に届いているときは、全て０となる。
＞肯定確認応答状態：次にＤＡＴＡチャンクを受信したとき、ＳＡＣＫチャンクで応答するかどうかを示す値であり、この値が２以上になるとＳＡＣＫチャンクを送信して、０にリセットする。
＞インバウンドストリーム：受信したストリームを検知するための構造体の配列であり、通常は次のシーケンス番号が入る。
＞アウトバンドストリーム：送信したストリームを検知するための構造体の配列。通常は次のシーケンス番号が入る。
＞リアッセンブリキュー：データチャンクを作成するときに断片化されたデータを再構成するためのキューである。
＞ローカルトランスポートアドレスリスト：自己のアソシエーションへ送信するときのＩＰアドレスのリストである。
＞アソシエーションＰＭＴＵ：全ての相手側宛先アドレスから知らされるパスＭＴＵの最小値である。
＞マルチルートサポートフラグ：自己のアソシエーションがマルチルート送信をサポートするかどうかを示すフラグである。

（３）ピア宛先リスト９２：相手側のエンドポイント装置５０がもつ宛先アドレスのリストである。：
＞送信元アドレス：相手側のエンドポイント装置５０の宛先アドレスである。
＞ピアルートリスト：相手側のエンドポイント装置５０が持つルートのリストである。

（４）ピアルートリスト９６：
＞ルートＩＤ（ＲＩＤ）：ルートの識別番号である。
＞マッピングアレイ：ＲＳＮの順番とは違った順番で受信したＭＲ−ＤＡＴＡチャンクを示すビット、もしくはバイトの配列。全てのチャンクがＲＳＮの順に届いているときは、全て０となる。

（５）宛先アドレスリスト９２：
＞エラー計数値：宛先アドレスで発生したエラーの回数を計数するカウンタの計数値である。
＞エラーしきい値：宛先アドレスを無効にするために使われるエラー回数のしきい値である。
＞ＣＷＮＤ：輻輳ウィンドウの大きさを示し、マルチルートでデータを送信するときは使用されない。
＞Ｓｓｔｈｒｅｓｈ：輻輳制御処理においてスロースタートモードと輻輳回避モードを切り替えるためのしきい値であり、マルチルートでデータを送信するときは使用されない。
＞ＲＴＯ：ＤＡＴＡチャンクを送信してから再送が発生するまでのタイムアウト時間を示す値であり、マルチルートでデータを送信するときは使用されない。
＞ＳＲＴＴ：チャンクを送信してから、応答チャンクが返ってくるまでのタイムアウト時間（ＲＴＴ）の平均値（推定値）であり、マルチルートでデータを送信するときは使用されない。
＞ＲＴＴ＿ＶＡＲ：チャンクを送信してから、応答チャンクが返ってくるまでのタイムアウト時間（ＲＴＴ）の変動値であり、マルチルートでデータを送信するときは使用されない。
＞Ｐａｒｔｉａｌ＿Ｂｙｔｅｓ＿Ａｃｋｅｄ（肯定確認応答されたデータ部分のバイト数）：輻輳制御処理における輻輳回避モードにおいて、ＣＷＮＤを増加させるときのしきい値であり、マルチルートでデータを送信するときは使用されない。
＞状態：宛先の状態を示す値であり、以下の値を有する。
（ａ）インアクティブ（非動作状態）。
（ｂ）アクティブ（動作状態）。
＞ＰＭＴＵ：宛先アドレスまでのパスＭＴＵである。
＞宛先毎タイマー：宛先アドレス毎に用いられるタイマーであり、一部のタイマーはマルチルートでデータを送信するときは使われない
＞ＲＴＯ係属中フラグ：過去にＳＡＣＫチャンクからＲＴＴを計算したことがあるか否かを示すフラグであり、マルチルートでデータを送信するときは使用されない。
＞使用最終時刻：宛先が最後に使用された時刻であり、ＨＥＡＲＴＢＥＡＴの送信のために使われる。
＞ルートリスト９５：宛先アドレスまでパケットを送信することができるルート構造体の配列である。

（６）ルートリスト９５：
＞状態：ルートの状態を示す値であり、一例として以下の値を有する。
（ａ）停止（ＣＬＯＳＥＤ）状態。
（ｂ）待機初期（ＷＡＩＴ＿ＩＮＩＴ）状態。
（ｃ）確立済み（ＣＨＥＣＫＥＤ）状態。
（ｄ）削除済み（ＤＥＬＥＴＥＤ）状態。
（ｅ）待機削除（ＷＡＩＴ＿ＣＬＥＡＲ＿ＩＮＩＴ）状態。
＞ルートＩＤ（ＲＩＤ）：ルートの識別番号であり、アドホックルーティングプロトコル処理部１２から通知される。
＞次のＲＳＮ：次にＭＲ−ＤＡＴＡチャンクを送信するときにつけられるＲＳＮ（ルートシーケンス番号）の値である。
＞送信元アドレス：ルート情報を使用してチャンクを送信するときの送信元アドレスである。
＞最後に受信したＳＡＣＫのタイムスタンプ：最後に受信したＭＲ−ＳＡＣＫチャンクのタイムスタンプであり、ＭＲ−ＳＡＣＫチャンクの順序が不順（乱れ）となったことを検出するために使われる。
＞ＣＷＮＤ：輻輳ウィンドウの大きさを示す値である。
＞Ｓｓｔｈｒｅｓｈ：輻輳制御処理においてスロースタートモードと輻輳回避モードを切り替えるためのしきい値である。
＞ＲＴＯ：ＤＡＴＡチャンクを送信してから再送が発生するまでの時間を示すタイムアウト時間である。
＞ＳＲＴＴ：チャンクを送信してから、応答チャンクが返ってくるまでのデータ転送時間（ＲＴＴ）の平均値（推定値）である。
＞ＲＴＴ＿ＶＡＲ：：チャンクを送信してから、応答チャンクが返ってくるまでのデータ転送時間（ＲＴＴ）の変動値である。
＞Ｐａｒｔｉａｌ＿Ｂｙｔｅｓ＿Ａｃｋｅｄ：輻輳制御処理の輻輳回避モードドにおいて、ＣＷＮＤを増加させるための値である。
＞ＲＴＯ係属中フラグ：過去にＳＡＣＫチャンクからＲＴＴを計算したかどうかを示すフラグである。
＞ルート毎タイマー：ルート毎に用いられるタイマーである。

次いで、本実施形態に係る拡張されたＳＣＴＰパケットを用いて伝送するチャンクのフォーマットについて以下に説明する。

チャンクのフォーマットについては、非特許文献１のＲＦＣ２９６０の３．２章に従うが、チェックタイプに関して以下の定義を追加する。

［表１］
――――――――――――――――――――――――――――――――――――――
ＩＤ値 チャンクタイプ
――――――――――――――――――――――――――――――――――――――
１５ マルチルートペイロードデータ（ＭＲ−ＤＡＴＡ）
１６ マルチルート選択的肯定確認応答（ＭＲ−ＳＡＣＫ）
――――――――――――――――――――――――――――――――――――――

次いで、ＩＮＩＴチャンクにおいて、変数パラメータについて以下の値を追加する。ＩＮＩＴチャンクではマルチアドレスを含むことができるが、ＭＲ−ＳＣＴＰを利用する場合は、アドホックアドレスパラメータにアドホックネットワークで利用する自局ＩＰアドレスを指定する必要がある。なぜなら、マルチホーム環境においてホームの違いはＩＰアドレスという統一されたフォーマットで隠蔽され、異なるＩＤを利用していること以外は区別できないためである。なお、０ｘは１６進数表示を示し、以下同様である。

［表２］
――――――――――――――――――――――――――――――――――――――
変数パラメータ 状態 タイプ値
――――――――――――――――――――――――――――――――――――――
アドホックアドレス オプション ０ｘ００１３
マルチルートＳＣＴＰサポート オプション ０ｘ００１４
――――――――――――――――――――――――――――――――――――――

また、ＩＮＩＴ＿ＡＣＫチェックのフォーマットは、非特許文献１のＲＦＣ２９６０の３．３．３章に従うが、変数パラメータについて以下の値を追加する。

［表３］
――――――――――――――――――――――――――――――――――――――
変数パラメータ 状態 タイプ値
――――――――――――――――――――――――――――――――――――――
アドホックアドレス オプション ０ｘ００１３
マルチルートＳＣＴＰサポート オプション ０ｘ００１４
――――――――――――――――――――――――――――――――――――――

なお、アソシエーションの初期化時にＩＮＩＴ−ＡＣＫの送信側のエンドポイント装置５０はＭＲ−ＳＣＴＰがサポート可能なことを知らせるために上記のオプションフィールドを設定する必要がある。そのフォーマットを以下で定義する。
（ａ）パラメータタイプ（１６ビット）
＝０ｘＣ００２（マルチルートがサポートされたパラメータであることを示す）
（ｂ）パラメータ長＝４

また、ＨＥＡＲＴＢＥＡＴチャンクのフォーマットは、非特許文献１のＲＦＣ２９６０の３．３．５章に従うが、さらに変数パラメータについて以下の値を追加する。ＲＦＣ２９６０では、ＨＥＡＲＴＢＥＡＴチャンクを特定の転送アドレスに対する信頼性の確認に利用する。ＭＲ−ＳＣＴＰでは、ＲＦＣ２９６０の定義に加えて、アドホック無線ネットワークク上の特定ルートに対するパケットの信頼性の確認にＨＥＡＲＴＢＥＡＴチャンクを利用する。

［表４］
――――――――――――――――――――――――――――――――――――――
パラメータ名称 状態 タイプ値
――――――――――――――――――――――――――――――――――――――
初期ＲＳＮ オプション ０ｘ００１１
――――――――――――――――――――――――――――――――――――――

上記初期ＲＳＮのフォーマットは以下のように定義される。
（ａ）パラメータタイプ（１６ビット）＝０ｘ００１０；
（ｂ）パラメータ長（１６ビット）＝８；
（ｃ）ルートＩＤ（ＲＩＤ）（１０ビット）；
（ｄ）Ｉ−ＲＳＮ（２２ビット）：初期ルートシーケンス番号。

さらに、ＨＥＡＲＴＢＥＡＴ＿ＡＣＫチャンクのフォーマットについても、ＨＥＡＲＴＢＥＡＴチャンクと同様のフォーマットを使用する。

また、ＭＲ−ＳＣＴＰではアソシエーションにおいてデータを送信するためには以下で定義するＭＲ−ＤＡＴＡチャンクを利用して送信する必要がある。
（ａ）タイプ（８ビット）＝１０；
（ｂ）予約済み（５ビット）＝すべて０（受信側において無視される）；
（ｃ）Ｕビット（不指示ビット）：不指示されたデータチャンクを示し、このデータチャンクにはストリームシーケンス番号を付与されない。このとき、受信側は対応するストリームシーケンス番号を無視する。
（ｄ）Ｂビット（開始フラグメントビット）：ユーザメッセージの最初のフラグメントであることを示す。
（ｅ）Ｅビット（終了フラグメントビット）：ユーザメッセージの最後のフラグメントであることを示す。
（ｆ）長さ（１６ビット）：データチャンクのバイト数を示す。
（ｇ）ＡＳＮ（３２ビット）：当該アソシエーションにおけるデータチャンクに対するシーケンス番号を示す。
（ｈ）ＲＩＤ（１０ビット）：データチャンクが送信されてるパスを示すルートＩＤである。
（ｉ）ＲＳＮ（２２ビット）：パスでのデータチャンクのシーケンス番号である。
（ｊ）ストリーム識別子Ｓ（１６ビット）：次に続くユーザデータが属するストリームを識別する。
（ｋ）ストリームシーケンス番号ｎ（１６ビット）：ストリームＳ内の次に続くユーザデータのストリームシーケンス番号を示す。
（ｌ）ペイロードプロトコル識別子（３２ビット）：アプリケーションにより特定されるプロトコル識別子を示す。
（ｍ）ユーザデータ（ストリームＳのシーケンスｎ；可変長）：ペイロードのユーザデータが格納される。

さらに、ＭＲ−ＳＣＴＰ処理部２０では、データチャンクの受信確認（肯定確認応答）のために、データチャンクの受信側のエンドポイント装置５０はデータチャンクの送信側のエンドポイント装置５０に対して、受信したチャンクの情報をルート毎にＭＲ−ＳＡＣＫを送信する必要がある。また、現在のアソシエーションバッファ情報も同時に設定しなければならない。チャンクの情報には、処理対象データチャンクが送信ルートされたときに利用されたルートＩＤ（ＭＲ−ＤＡＴＡチャンクで設定されているＲＩＤ）と、そのルートに関して連続で受信した最大のシーケンス番号（累積的ＲＳＮ）、不連続で受信したデータが存在すればそのチャンクに関する情報もＭＲ−ＳＡＣＫに含める。このＭＲ−ＳＡＣＫのフォーマットは以下の通りである。

（ａ）タイプ（８ビット）＝１３。
（ｂ）予約済み（８ビット）：送信側ではすべて０にセットされ、受信側ではこれを無視する。
（ｃ）チャンク長（１６ビット）：チャンクの長さ（バイト数）。
（ｄ）累積的ＡＳＮ＿ＡＣＫ（３２ビット）：ギャップ前のシーケンスにおいて受信された最後のデータチャンクのＡＳＮを示す。
（ｅ）通知される受信側のウィンドウクレジットである空きバッファ容量（ＡＲＷＮＤ）（３２ビット）：このＭＲ−ＳＡＣＫの送信側における更新された受信バッファの空きバイト数を示す。
（ｆ）タイムスタンプ（３２ビット）：このＭＲ−ＳＡＣＫが受信側で発生されたときの時刻を示す。
（ｇ）ルートＩＤ（ＲＩＤ）（１０ビット）：データチャンクが送信されているパスを識別する。
（ｈ）累積的ＲＳＮ＿ＡＣＫ（２２ビット）：このＭＲ−ＳＡＣＫが肯定確認応答されているパス上において、ギャップ前のシーケンスにおいて受信された最後のデータチャンクのＲＳＮを示す。
（ｉ）ギャップ肯定確認応答ブロック（ＧＡＰ＿ＡＣＫ＿ＢＬＯＣＫＳ）の数（１６ビット）＝Ｎ：このＭＲ−ＳＡＣＫにおいて含まれるギャップ肯定確認応答ブロックの数を示す。
（ｊ）重複のＲＳＮの数（１６ビット）＝Ｘ：エンドポイント装置５０がある与えられたパス上で受信された重複のＲＳＮの数を示す。
（ｋ）ギャップ肯定確認応答ブロック＃１の開始位置（１６ビット）。
（ｌ）ギャップ肯定確認応答ブロック＃１の終了位置（１６ビット）。
…………
（ｍ）ギャップ肯定確認応答ブロック＃Ｎの開始位置（１６ビット）。
（ｎ）ギャップ肯定確認応答ブロック＃Ｎの終了位置（１６ビット）。
（ｏ）重複のＲＳＮ＿１（３２ビット）。
…………
（ｐ）重複のＲＳＮ＿Ｎ（３２ビット）。

次いで、本発明の実施形態に係る上記問題点を解決するための具体的方法について以下に説明する。

まず、パケットロス検出方法について説明する。上述したように、単純に複数のルートを同時に利用する場合、問題点Ａが発生する。特に、データ通信においてパケットロスの検出は、フロー制御、輻輳制御、再送制御の全ての制御に関係するイベントであり、より正確に行われなければならない。本実施形態に係るＭＲ−ＳＣＴＰでは、問題点Ａを解決するため、パケットロスを検出するために、ＲＴＴ及びシーケンス番号をルート毎に管理するように拡張を行った。以下で詳細を述べる。

（１）ＳＣＴＰにおけるデータフォーマットを拡張したこと（以下、チャンク拡張という。）である。チャンク拡張では、従来技術に係るＳＣＴＰにおけるデータフォーマットの定義にルートＩＤ（ＲＩＤ）と、ルートシーケンス番号（ＲＳＮ）を追加した。ＲＩＤは転送ルート毎の固有のＩＤであり、ルート識別のために利用する。ＲＳＮは転送ルートにおけるパケットを一意に識別するために利用する。

（２）再送タイマーをルート毎に設置したことである。ＳＣＴＰにおけるデータフォーマットにおいて、ＲＩＤ及びＲＳＮを追加したことで、送信側では、図３に示すように、送信パケットに対するＳＡＣＫを受信した時点で、ルート毎のデータ転送時間（ＲＴＴ）を検出することができる。図３は、図１のエンドポイント装置５０Ａ，５０Ｂ間のパケット通信におけるＴ３−ＲＴＸタイマーの計時終了による再送の発生を示すシーケンス図である。なお、図３及びそれ以降のシーケンス図において、エンドポイント装置５０Ａは送信側にあり、エンドポイント装置５０Ｂは受信側にあるものとする。図３において、送信側のエンドポイント装置５０Ａが複数回のＭＲ−ＤＡＴＡチャンクを送信するときに、ＭＲ−ＤＡＴＡチャンクを送信してからＲＴＯの時間内にＭＲ−ＳＡＣＫチャンクが返ってこなかったらルートから送信した全てのチャンクに再送マークをつけて再送する。これを、上述した式（４）乃至式（７）に適用することで、ルート毎の再送タイマーを設置することができる。

（３）ＳＣＴＰにおける高速再送信（Fast Retransmission）をルート毎に適用したことである。高速再送信は到着シーケンス番号に基づく処理なので、ＲＩＤ及びＲＳＮを利用してルート毎の処理に適用する。図４乃至図６に示すように、データ受信側は肯定確認応答を行うときに、受信したデータについて、ＲＩＤ、累積的ＲＳＮ、ＲＳＮに基づいて、ギャップ肯定確認応答（Ｇａｐ＿Ａｃｋ＿Ｂｌｏｃｋ）を返却する。これらの仕組みにより上述したパケットロス検出の問題点Ａを解決することができる。

図４は、図１のエンドポイント装置５０Ａ，５０Ｂ間のパケット通信における高速再送信の発生を示すシーケンス図である。図４において、送信側のエンドポイント装置５０Ａは、ＭＲ−ＤＡＴＡチャンクを順次送信するが、これに対して、受信側のエンドポイント装置５０ＢはＭＲ−ＳＡＣＫチャンクを返信する。ここで、同一のチャンクに対してＭＲ−ＳＡＣＫチャンクのギャップ肯定確認応答ブロック（Ｇａｐ＿Ａｃｋ＿Ｂｌｏｃｋ）によって４回「届いていない」とされたとき、再送マークをつけて再送する。

図５及び図６は、図１のＭＲ−ＳＣＴＰ処理部２０によって実行されるＭＲ−ＳＡＣＫチャンクのギャップ肯定確認応答ブロック（Ｇａｐ＿Ａｃｋ＿Ｂｌｏｃｋ）による再送チャンクの設定処理を示すフローチャートである。

図５のステップＳ１において、ＭＲ−ＳＡＣＫチャンクを受信したか否かを判断し、ＹＥＳとなるまでステップＳ１の処理を繰り返し、ＹＥＳとなったとき、ステップＳ２においてＭＲ−ＳＡＣＫチャンクは順序が不順となったチャンクであるか否かを判断し、ＹＥＳのときは当該処理を終了する一方、ＮＯのときはステップＳ３に進む。ステップＳ３においてＭＲ−ＳＡＣＫチャンクの送信元アドレスと合致する宛先アドレスを検索し、ステップＳ４において検索した宛先アドレスから、さらにＭＲ−ＳＡＣＫチャンクに書かれたルートＩＤ（ＲＩＤ）と一致するＩＤを持ったルートを検索する。次いで、ステップＳ５において処理対象のチャンクを再送バッファの先頭にあるチャンクに設定し、ステップＳ６において再送バッファ内の全てのチャンクを巡回して検索したか否かを判断する。ステップＳ６において、ＹＥＳのときは図６のステップＳ２１に進む一方、ＮＯのときはステップＳ７に進む。

図５のステップＳ７からステップＳ１５までの処理は、再送バッファ内のＧａｐＡｃｋで肯定確認応答されたチャンクのギャップ肯定確認応答済みフラグを１にする処理である。ステップＳ７において、処理対象のチャンクを送信した宛先アドレスとルートＩＤ（ＲＩＤ）はそれぞれＭＲ−ＳＡＣＫチャンクに対応する宛先アドレス及びルートＩＤ（ＲＩＤ）と一致するか否かを判断し、ＹＥＳのときはステップＳ８に進む一方、ＮＯのときはステップＳ１５に進む。ステップＳ８において処理対象のチャンクはＭＲ−ＳＡＣＫチャンク内のギャップ肯定確認応答ブロック（Ｇａｐ＿Ａｃｋ＿Ｂｌｏｃｋ）に記されたＲＳＮのチャンクであるか否かを判断し、ＹＥＳのときはステップＳ９に進む一方、ＮＯのときはステップＳ１３に進む。ステップＳ９において処理対象のチャンクは既に肯定確認応答されたチャンクか否かを判断し、ＹＥＳのときはステップＳ１５に進む一方、ＮＯのときはステップＳ１０に進む。ステップＳ１０においてチャンクのギャップ肯定確認応答済みフラグを１にセットし、ステップＳ１１においてチャンクの再送マークをはずし、ステップＳ１２においてルートの再送タイマーが動作中であれば停止した後、ステップＳ１５に進む。一方、ステップＳ１３では、処理対象のチャンクは既に肯定確認応答されたチャンクか否かを判断し、ＹＥＳのときはステップＳ１４に進む一方、ＮＯのときはステップＳ１５に進む。ステップＳ１４においてチャンクのギャップ肯定確認応答済みフラグを０にリセットし、肯定確認応答ずみでない状態にセットし、ステップＳ１５に進む。ステップＳ１５では、処理対象のチャンクを再送バッファ内で１つ次のチャンクに移動させた後、ステップＳ６に戻る。

図６のステップＳ２１では、処理対象のチャンクを再送バッファの先頭にあるチャンクに設定し、ステップＳ２２において再送バッファ内の全てのチャンクを巡回して検索したか否かを判断し、ＹＥＳのときは当該処理を終了する一方、ＮＯのときはステップＳ２３に進む。ステップＳ２３において処理対象のチャンクはＲ−ＳＡＣＫチャンクでＧａｐＮａｃｋで否定応答（受信したチャンクの隙間）となっているチャンクであるか否かを判断し、ＹＥＳのときはステップＳ２４に進む一方、ＮＯのときはステップＳ２８に進む。ステップＳ２４において処理対象のチャンクのエラーカウンタに１を加算し、ステップＳ２５において処理対象のチャンクのエラーカウンタの計数値＞高速再送信の制限値であるか否かを判断し、ＹＥＳのときはステップＳ２６に進む一方、ＮＯのときはステップＳ２８に進む。ステップＳ２６において処理対象のチャンクに再送のマークを付し、ステップＳ２７において高速再送信のフラグを１にセットし、ステップＳ２８において処理対象のチャンクを１つ次に移動させた後、ステップＳ２２に戻る。

以上説明したように、パケットロスを検出するために、ＲＴＴ及びシーケンス番号をルート毎に管理するように拡張を行うことにより、無駄なデータの再送を防止することができる。

次いで、本実施形態に係る輻輳制御処理について以下に説明する。

上述した問題点Ｂに対して、ルート毎で輻輳制御処理を行うように拡張を行うことにより当該問題点を解決する。上述した拡張により、パケットロスの検出はルート毎に行うことができる。図７及び図８に示すように、データの送信側は併せて輻輳ウィンドウ値（ＣＷＮＤ）をルート毎に用意し、輻輳回避アルゴリズムにルート毎のＣＷＮＤを適用する。これにより、ＭＲ−ＳＣＴＰ処理部２０では輻輳回避のアルゴリズムがルート毎に適用可能になる。

図７は、図１のエンドポイント装置５０Ａ，５０Ｂ間のパケット通信における輻輳ウィンドウ値（ＣＷＮＤ）を再計算するタイミングを示すシーケンス図である。図７において、送信側のエンドポイント装置５０Ａは、ＭＲ−ＤＡＴＡチャンクを順次送信するが、これに対して、受信側のエンドポイント装置５０ＢはＭＲ−ＳＡＣＫチャンクを返信する。ここで、ＭＲ−ＳＡＣＫチャンクによって新規に肯定確認応答されたＭＲ−ＤＡＴＡチャンクがあればＣＷＮＤを再計算して更新する。

図８は図１のＭＲ−ＳＣＴＰ処理部２０によって実行される輻輳ウィンドウ値（ＣＷＮＤ）の更新処理を示すフローチャートである。

図８において、まず、ステップＳ３１においてＭＲ−ＳＡＣＫチャンクを受信したか否かを判断し、ＹＥＳとなるまでステップＳ３１の処理を繰り返し、ＹＥＳとなったときステップＳ３２に進む。ステップＳ３２においてＭＲ−ＳＡＣＫチャンクにより新規に肯定確認応答されたチャンクがあるか否かを判断し、ＹＥＳのときはステップＳ３３に進む一方、ＮＯのときは当該処理を終了する。ステップＳ３３において輻輳制御のモードはスロースタートモードであってしきい値（Ｓｓｔｈｒｅｓｈ）≦輻輳ウィンドウ値（ＣＷＮＤ）であるか、もしくは、輻輳回避モードであってしきい値（Ｓｓｔｈｒｅｓｈ）＞輻輳ウィンドウ値（ＣＷＮＤ）であるかを判断し、スロースタートモードであるときはステップＳ３４に進む一方、輻輳回避モードであるときはステップＳ３６に進む。

ステップＳ３４において処理対象ルートで転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）≧輻輳ウィンドウ値（ＣＷＮＤ）であるか否かを判断し、ＹＥＳのときは当該処理を終了する一方、ＮＯのときはステップＳ３５に進む。ステップＳ３５においてＭＲ−ＳＡＣＫチャンクにより肯定確認応答されたチャンクのサイズとＭＴＵのうち小さい方を輻輳ウィンドウ値（ＣＷＮＤ）に加算することにより当該ＣＷＮＤを更新して広げ、当該処理を終了する。一方、ステップＳ３６において処理対象ルートで肯定確認応答されたデータ部分のバイト数（ＰａｒｔｉａｌＢｙｔｅｓＡｃｋｅｄ）と転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）が両方ともＣＷＮＤ以上であるか否かを判断し、ＹＥＳのときはステップＳ３７に進む一方、ＮＯのときは当該処理を終了する。ステップＳ３７において処理対象ルートの肯定確認応答されたデータ部分のバイト数（ＰａｒｔｉａｌＢｙｔｅｓＡｃｋｅｄ）からＣＷＮＤを減算して当該減算結果値をＰａｒｔｉａｌＢｙｔｅｓＡｃｋｅｄとする。ただし、その最小値は０である。さらに、ステップＳ３８においてＣＷＮＤにＭＴＵを加算することにより、ＣＷＮＤを更新してＣＷＮＤを広げ、当該処理を終了する。

なお、上記肯定確認応答されたデータ部分のバイト数（ＰａｒｔｉａｌＢｙｔｅｓＡｃｋｅｄ）の値は以下のために用いている。輻輳回避モードにおいて、その目的は、データ転送時間（ＲＴＴ）毎に、パスＭＴＵだけ輻輳ウィンドウ値（ＣＷＮＤ）をインクリメントすることにある。この動作を近似的に実現するために、ＳＡＣＫが到着するたびに、上記肯定確認応答されたデータ部分のバイト数（ＰａｒｔｉａｌＢｙｔｅｓＡｃｋｅｄ）の変数値は肯定確認応答されたバイト数だけインクリメントされる。当該変数値が輻輳ウィンドウ値（ＣＷＮＤ）を超えたときはいつでも、輻輳ウィンドウ値（ＣＷＮＤ）はＰＭＴＵ（例えば１）だけインクリメントされる。

以上説明したように、本実施形態に係るＭＲ−ＳＣＴＰによれば、パケットロスの検出をルート毎に行うとともに、データの送信側のエンドポイント装置５０は、輻輳ウィンドウ値（ＣＷＮＤ）をルート毎に輻輳制御モードに応じて転送中データサイズに基づいて更新するので、輻輳回避のアルゴリズムをルート毎に適用することができ、不必要に転送レートを下げてしまうという問題点Ｂを解決できる。

次いで、ルート毎の再送制御について以下に説明する。

上述のように、データの送信ルートと、受信確認データである選択的肯定確認応答（ＳＡＣＫ）の送信ルートが異なる場合、ルートの削除を検出しても、実際には転送データは通信相手に届く可能性がある。また、受信確認通知である肯定確認応答（ＡＣＫ）も他のルートを通してデータ送信側に到着する可能性がある。ルート削除の通知をトリガーにして、管理情報を初期化した場合、結果として無駄なデータ再送が発生する。従って、これらの問題点を解決するためには、ルートの状態がデータ転送不可能と認識した場合でも、一定期間ルート毎の状態変数を保持し、ＳＡＣＫの受信を待つ必要がある。

上述したように、ＭＲ−ＳＣＴＰ処理部２０では、「再送タイマーの計時終了」時点をトリガーとして用いてパケットロスの検出を行うことと、図４の高速再送信の判断時をトリガーとして用いてパケットロスの検出を行うことを、ルート毎に実行している。従来技術に係るＳＣＴＰと同じくパケットロスを検出すると、ＭＲ−ＳＣＴＰ処理部２０では、処理対象パケットに再送フラグを設定し、パケットを１つだけ再送する。この処理は輻輳回避のアルゴリズムに基づいて行われ、従来技術のＳＣＴＰと同じである。ただし、ＭＲ−ＳＣＴＰ処理部２０では、再送マークされたデータを、通常のデータ転送処理の中でいつどれだけ転送するかについて拡張を行う必要があり、本実施形態ではこれを図１０及び図１１のごとく実行している。この拡張処理は、ＳＡＣＫ受信時の拡張処理と、ルート削減時の拡張処理を含む。

ＳＡＣＫ受信時の拡張処理では、ＳＡＣＫ受信時は従来技術に係るＳＣＴＰにおいても、再送データが存在すれば輻輳ウィンドウサイズが許す限り、再送データを優先して送信する。ＭＲ−ＳＣＴＰ処理部２０でＳＡＣＫで通知されたルートに関する再送しかしない。すなわち、他のルートの再送データを送信しない。これは、ルート毎で管理している輻輳ウィンドウサイズを正確に管理するためである。

また、ルート削除時の拡張処理では、ルートの削除イベントが発生し、宛先のエンドポイント装置５０Ｂからルート削除の通知を受信された場合、通知されたルートにおいて再送マークされたデータが存在していれば、処理対象データは他のルートの再送データとして引き継がれる。削除通知を受信後に高速再送信のイベントが発生した場合も同様である。再送タイマーが計時終了した場合は、処理対象ルートが管理している送信バッファのデータは全て他のルートに引き継がれる。

なお、引き継ぎの処理は、データのコピーを行うのではなく、下記の２つの変数を更新する。それ以外のデータは全て変更せずに引き継がれる。引き継がれたルートでは、従来と同じくデータ転送時に再送マークされたデータとして処理される（図９参照。）。本実施形態では、データに割り当てられているルートＩＤ（ＲＩＤ）の情報を引継先のルートＩＤ（ＲＩＤ）に変更する。また、シーケンス番号は割り当て先のルートで割り当てているシーケンス番号を新規に割り当てする。また、データの引き継ぎが発生した時点で、データを引き継ぐ前の転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）が０で無い限りパケットの転送は行わない。すなわち、引き継がれたルート上のパケット送信イベント発生時に行う。これは、パケットロス検出時のデータ送信処理は、本来ロスを検出したルートで行うべき処理だからである。

図９は、図１のＭＲ−ＳＣＴＰ処理部２０によって実行されるルート間でのＭＲ−ＤＡＴＡチャンクの引き継ぎ処理を示すフローチャートである。この処理は、ステップＳ４１の判断条件がＹＥＳとなったとき、もしくは、ステップＳ４５の判断条件がＹＥＳとなったときに実行される。

図９のステップＳ４１においてＭＲ−ＳＡＣＫチャンクを受信し、又はＴ３−Ｒｔｘタイマーが計時終了したか否かを判断し、ＹＥＳとなるまでステップＳ４１の処理を繰り返し、ＹＥＳとなったとき、ステップＳ４２においてＭＲ−ＳＡＣＫチャンク、又はＴ３−Ｒｔｘはタイマーの処理対象ルート以外で、状態が確立済み状態である再送ルートを検索し、ステップＳ４３において再送ルートが発見されたか否かを判断し、ＹＥＳのときはステップＳ４７に進む一方、ＮＯのときはステップＳ４４に進む。ステップＳ４４においてＲＩＤ＝０のルートを再送ルートとし、ステップＳ４７に進む。一方、ステップＳ４５においてＨＥＡＲＴＢＥＡＴ−ＡＣＫチャンクを受信したか否かを判断し、ＹＥＳとなるまでステップＳ４５の処理を繰り返し、ＹＥＳとなったとき、ステップＳ４６に進む。ステップＳ４６において確立済み状態に変化したルートがあったか否かを判断し、ＹＥＳのときはステップＳ４７に進む一方、ＮＯのときは当該処理を終了する。

次いで、ステップＳ４７において処理対象のチャンクを再送バッファの先頭のチャンクに設定し、ステップＳ４８において再送バッファ内のチャンクを全て巡回して検索したか否かを判断し、ＹＥＳのときは当該処理を終了する一方、ＮＯのときはステップＳ４９に進む。ステップＳ４９では、処理対象のチャンクは以下の条件を全て満たすか否かを判断し、
（１）宛先アドレスが再送ルートを持つ宛先アドレスと一致する；
（２）ルートＩＤ（ＲＩＤ）が対象ルートのルートＩＤ（ＲＩＤ）と一致する；
（３）再送マークがついている；
ＹＥＳのときはステップＳ５０に進む一方、ＮＯのときはステップＳ５２に進む。ステップＳ５０では、処理対象のチャンクのルートＩＤ（ＲＩＤ）を再送ルートのルートＩＤ（ＲＩＤ）に書き換え、ステップＳ５１において処理対象のチャンクのＲＳＮを再送ルートが新規に発行したＲＳＮに書き換え、ステップＳ５２において処理対象のチャンクを１つ次のチャンクに設定した後、ステップＳ４８に戻る。

図１０及び図１１は、図１のＭＲ−ＳＣＴＰ処理部２０によって実行される再送チャンクの送信処理を示すフローチャートである。

図１０のステップＳ６１において、まず、ＭＲ−ＳＡＣＫチャンクを受信し、もしくはＨＥＡＲＴＢＥＡＴ−ＡＣＫチャンクを受信し、もしくはＴ３−Ｒｔｘタイマーが計時終了したか否かを判断し、ＹＥＳとなるまでステップＳ６１の処理を繰り返し、ＹＥＳとなったとき、ステップＳ６２において再送ルート上の再送対象になっているチャンクの合計サイズを転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）から減算し、減算値を転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）にセットする。次いで、ステップＳ６３において処理対象のチャンクを再送バッファの先頭のチャンクに設定し、ステップＳ６４において再送バッファの全てのチャンクを巡回して検索したか否かを判断し、ＹＥＳのときは図１１のステップＳ８１に進む一方、ＮＯのときはステップＳ６５に進む。

ステップＳ６５において再送サイズの制限はＣＷＮＤであるか、１パケットであるかを判断し、前者であるときはステップＳ６６に進む一方、後者であるときはステップＳ６７に進む。ステップＳ６６において再送対象ルートの転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）＜再送ルートのＣＷＮＤであるか否かを判断し、ＹＥＳのときは図１１のステップＳ７１に進む一方、ＮＯのときは図１１のステップＳ８１に進む。一方、ステップＳ６７において再送チャンクを１パケット以上送信したか否かを判断し、ＹＥＳのときは図１１のステップＳ８１に進む一方、ＮＯのときは図１１のステップＳ７１に進む。

図１１のステップＳ７１では、再送バッファの全てのチャンクを巡回して検索したか否かを判断し、ＹＥＳのときはステップＳ７９に進む一方、ＮＯのときはステップＳ７２に進む。ステップＳ７２において処理対象のチャンクを送信したルートは再送対象のルートと同一であるか否かを判断し、ＹＥＳのときはステップＳ７３に進む一方、ＮＯのときはステップＳ７８に進む。次いで、ステップＳ７３において処理対象のチャンクに再送フラグがついているか否かを判断し、ＹＥＳのときはステップＳ７４に進む一方、ＮＯのときはステップＳ７９に進む。そして、ステップＳ７４においてこれまで書き込んだ再送チャンクの容量の合計がＭＴＵを超えるか否かを判断し、ＹＥＳのときはステップＳ７５に進む一方、ＮＯのときはステップＳ７９に進む。さらに、ステップＳ７５において１回目の再送のときは再送タイマーをリスタートさせ、ステップＳ７６において再送チャンクをパケットのデータ領域に書き込み、ステップＳ７７において処理対象のチャンクの再送フラグをはずす。さらに、ステップＳ７８において処理対象のチャンクを次のチャンクに設定し、ステップＳ７１に戻る。

さらに、ステップＳ７９において再送パケットにデータチャンクが書き込まれたか否かを判断し、ＹＥＳのときはステップＳ８０に進む一方、ＮＯのときはステップＳ８１に進む。ステップＳ８０において再送パケットを再送し、図１０のステップＳ６４に戻る。そして、ステップＳ８１において転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）に再送ルート上の再送対象になっているチャンクで送信されていないチャンクのサイズを加算して、加算値を転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）にセットし、当該処理を終了する。

次いで、ルートに関する通信制御データの取り扱い方法について以下に説明する。まず、ルート情報の交換方法について説明する。

まず、アソシエーション開始時にＩＮＩＴチャンク及びＩＮＩＴ−ＡＣＫチャンクにおいて、送信側及び受信側のエンドポイント装置５０では、マルチルートをサポートする旨（マルチルートＳＣＴＰサポート）と、マルチルートを利用できるアドレス（アドホックアドレス）を通知する。さらに、送信側及び受信側のエンドポイント装置５０で利用するルート情報を交換し合う必要がある。本実施形態では、以下のシーケンスによって、利用するルート情報を交換する。

図１２は、図１のエンドポイント装置５０Ａ，５０Ｂ間のパケット通信におけるアソシエーションの確立時のルートイベントシーケンスを示すシーケンス図であり、図１３は、図１のエンドポイント装置５０Ａ，５０Ｂ間のパケット通信におけるアソシエーションの確立後のルートイベントシーケンスを示すシーケンス図である。

図１２において、送信側のエンドポイント装置５０ＡのＭＲ−ＤＳＲ処理部１０は、ＩＮＩＴチャンク又はＩＮＩＴ−ＡＣＫチャンクの転送時に、宛先アドレスに対してルートの検索を行い、ＭＲ−ＳＣＴＰ処理部２０の状態に関わらず、検出したルート情報をＭＲ−ＳＣＴＰ処理部２０に通知する。しかしながら、ＭＲ−ＳＣＴＰ処理部２０では、アソシエーションが確立するまで、ＭＲ−ＤＳＲ処理部１０から通知されたルート情報を破棄する。アソシエーションの初期化時に利用されるルートはデフォルトの値（ＲＩＤ＝０）を指定し、ＭＲ−ＤＳＲ処理部１０に対してルート検出及び選択を処理させる。

図１３において、アソシエーションが確立すると、送信側のエンドポイント装置５０ＡのＭＲ−ＳＣＴＰ処理部２０は、ＭＲ−ＤＳＲ処理部１０に対して、その時点で獲得していたルート情報を要求する。ＭＲ−ＤＳＲ処理部１０からルート情報を含む応答を受け取ると、ＭＲ−ＳＣＴＰ処理部２０は獲得したルート情報をＨＥＡＲＴＢＥＡＴチャンクに設定して、エンドポイント装置５０ＢのＭＲ−ＳＣＴＰ処理部２０に対して通知する。このＨＥＡＲＴＢＥＡＴチャンクではルートＩＤ（ＲＩＤ）とルート初期シーケンス番号（ＩＮＩＴＩＡＬ−ＲＳＮ）を通知する。受信側のＭＲ−ＳＣＴＰ処理部２０はルートＩＤ（ＲＩＤ）に対応しルート毎輻輳制御部２４で用いる仮想バッファモジュールを、通信制御データメモリ２１ａに作成し、ＨＥＡＲＴＢＥＡＴ−ＡＣＫチャンクを送信する。ここで、ルートＩＤ（ＲＩＤ）とＩＮＩＴＡＩＬ−ＲＳＮをペアにして送信する理由は、データ受信側が受信するシーケンス番号に対して抜けがあるか判定するためである。初期シーケンス番号を通知しない場合は、いずれにせよデフォルトの初期シーケンス番号を暗黙で想定する。次いで、データ送信側のＭＲ−ＳＣＴＰ処理部２０は、送信したＨＥＡＲＴＢＥＡＴチャンクに対する肯定確認応答（ＨＥＡＲＴＢＥＡＴ−ＡＣＫ）を受信した時点で、送信ルートを指定してデータを送信することが可能となる。また、アソシエーション確立後もルートＩＤ（ＲＩＤ）を指定しなければ、データ送信が可能であるので、ＨＥＡＲＴＢＥＡＴ−ＡＣＫチャンクを受信するまでデータ送信が止めずに通信を続けることができる。

また、ＭＲ−ＳＣＴＰ処理部２０において動的なルート情報の変更に対応するために、ＭＲ−ＤＳＲ処理部１０では獲得したルート情報をいつでもＭＲ−ＳＣＴＰ処理部２０に伝達することができる。獲得したルート情報の中からどのルートに関する情報を伝達するのかは、ＭＲ−ＤＳＲ処理部１０で決定できる。さらに、伝達されたルート情報がＭＲ−ＳＣＴＰ処理部２０のアソシエーションに関連しない情報（ＩＰアドレスやルート）であれば、ＭＲ−ＳＣＴＰにおいても情報を廃棄することが可能である。以上の通信手順を用いることにより、将来の拡張においてＭＲ−ＤＳＲ処理部１０が通知する情報をＭＲ−ＳＣＴＰ処理部２０で目的を持ってどの情報を利用するか選択できるようになる。例えば、通知されるルート情報を全て利用するのではなく、一定のしきい値を持ってパフォーマンスをより向上させることができる。

次いで、ルートの追加通知について説明すると、ルート情報はアソシエーション確立後に通知された場合でも、セットアップ時と同じくＨＥＡＲＴＢＥＡＴチャンクを利用して、ルートＩＤ（ＲＩＤ）とＩＮＩＴＡＩＬ−ＲＳＮを通知する。データ受信側のＭＲ−ＳＣＴＰ処理部２０では新たにＨＥＡＲＴＢＥＡＴチャンクによって伝えられたルートＩＤ（ＲＩＤ）に関して、セットアップ時と同じく仮想バッファを作成し、受信側のデータ管理オブジェクトを作成する。

さらに、ルート削除通知について説明すると、ルート削除イベントをＭＲ−ＤＳＲ処理部１０から通知された場合、生成時と異なり、データ送信側のＭＲ−ＳＣＴＰ処理部２０がデータ受信側のＭＲ−ＳＣＴＰ処理部２０にルート削除を通知しない。受信側のＭＲ−ＳＣＴＰ処理部２０ではルートＩＤ（ＲＩＤ）毎に受信バッファメモリを持つが、データが送信されない限り、特別な処理は不要である。また、ルートＩＤ（ＲＩＤ）の割り当て方法はＭＲ−ＤＳＲ処理部１０の機能であるためここでは詳細な説明を行わない。すなわち、ＭＲ−ＳＣＴＰ処理部２０はＭＲ−ＤＳＲ処理部１０から通知されたルートＩＤ（ＲＩＤ）を利用するだけである。

またさらに、ルートＩＤ（ＲＩＤ）の再利用について説明すると、送信側のＭＲ−ＳＣＴＰ処理部２０で再利用されたルートＩＤ（ＲＩＤ）は、受信側では削除通知を受け取らないために以前のルート情報と共に保存されている。送信側のＭＲ−ＳＣＴＰ処理部２０では再利用したルートＩＤ（ＲＩＤ）についてもＨＥＡＲＴＢＥＡＴチャンクで通知するので、受信側のＭＲ−ＳＣＴＰ処理部２０では既に管理しているルートＩＤ（ＲＩＤ）についてＨＥＡＲＴＢＥＡＴチャンクを受信すると、管理しているルート情報を初期化することで対応できる。

次いで、マルチルート処理に付随して発生する問題について以下に説明する。まず、フロー制御の問題と対策について述べる。

データ転送において、重要な制御の一つにフロー制御がある。データ送信側は、受信側が受信可能なデータ量を常に把握して、送信量を制御しなければ、データ受信側が処理しきれない程のデータ送信を行ってしまう。その結果、さらに再送が発生しネットワークに無駄なデータが転送されてしまう。そのために、従来技術に係るＳＣＴＰでは、受信側が、現在のデータ受信可能な量をデータ送信側にデータを受信する毎に通知し送信側でそのデータに基づいてデータ転送量を制御する方式が利用される。

本実施形態に係るマルチルートの拡張によって、上述のように、輻輳制御をルート毎で行われ新しく導入したルートの転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）に基づいて輻輳ウィンドウ値（ＣＷＮＤ）の更新が行われる。しかしながら、ルートの転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）に基づいてフロー制御をルート毎で行うと、以下の「オーバーフローの発生の問題」と「ゼロウィンドウの問題」が発生する。

まず、オーバーフローの発生について説明する。各ルートで現在のアソシエーション全体の転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）を把握していなければ、データ受信側のＭＲ−ＳＣＴＰ処理部２０が受信しきれないサイズのデータを送信してしまう可能性がある。図１４では、ルートＲ１に対する選択的肯定確認応答（ＳＡＣＫ）では空きバッファ容量（ＡＲＷＮＤ）が９００（単位は例えば、バイト）と伝えられたためにサイズ４００のデータを送信している。次に、ルートＲ２に対する選択的肯定確認応答（ＳＡＣＫ）では、ルートＲ１で送信中のデータはまだ到着していないため、データ受信側の空きバッファ容量（ＡＲＷＮＤ）＝６００となっている。図１４では、選択的肯定確認応答（ＳＡＣＫ）の受信に応答して、ルートＲ２上でサイズ３００のデータを送信しているが、もしなんらかの原因で（例えば、ギャップの発生や受信側処理遅延等）、データ受信側のＭＲ−ＳＣＴＰ処理部２０でバッファできない状態が続けば、実際にルートＲ２上で転送したデータが受信側のＭＲ−ＳＣＴＰ処理部２０に届いた時点で、空きバッファ容量（ＡＲＷＮＤ）は次式のようになり、サイズ１００のデータがオーバーフローとなる。

［数１３］
ＡＲＷＮＤ
＝６００−４００（Ｒ１に係る）−３００（Ｒ２に係る）
＝−１００ （１３）

次いで、ゼロウィンドウの問題について以下に説明する。従来技術に係るＳＣＴＰでは、受信した選択的肯定確認応答（ＳＡＣＫ）において、空きバッファ容量（ＡＲＷＮＤ）＝０でなおかつ転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）＝０である場合の１パケットのみ送信する処理を提供している。本来この処理は受信側で、処理の遅延等が発生したまたま受信側のバッファがフルの状態になったとき、送信側がデータを転送しなければ、受信側のバッファがいつ利用可能な状態に戻るか検知できないため特別処理として導入されている。

しかしながら、本実施形態に係るＭＲ−ＳＣＴＰ処理部２０においては、選択的肯定確認応答（ＳＡＣＫ）に含まれる空きバッファ容量（ＡＲＷＮＤ）＝０で転送ルートでの転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）＝０の場合、１パケットを転送したとしても、致命的な問題を引き起こす可能性がある。なぜなら、転送ルート以外のルートでは、転送中のデータが存在する可能性があり、もし上記のゼロウィンドウ処理で新規データを送信すると、受信バッファメモリ内のギャップ部分（再送待ち）を埋めてしまう可能性があるためである。受信バッファメモリがこの状態になってしまうと、受信データにはギャップが存在するために上位に移動できないが、たとえ再送パケットを受信しても、受信バッファメモリには空きが無いためギャップを埋めるデータを廃棄してしまい、ＭＲ−ＳＣＴＰ処理部２０の処理は完全に進まなくなる。

次いで、上述のオーバーフロー問題に対する解決方法について以下に説明する。上記で述べたオーバーフロー問題に対してＭＲ−ＳＣＴＰ処理部２０では、ルート毎で転送中のデータを把握し、全ルートにおける転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）を計算してフロー制御を行うことで問題を解決する。具体的には、ＭＲ−ＳＣＴＰ処理部２０では、新たに転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）の合計値である転送中データサイズ合計値（Ｔｏｔａｌ−ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）を導入し、各ルートからデータを送信する直前に、転送中データサイズ合計値（Ｔｏｔａｌ−ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）を計算し、個別の転送ルートにおいて、転送中のデータが存在していなくても、次式のように、転送中データサイズ合計値（Ｔｏｔａｌ−ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）と受信側の空きバッファサイズに基づいて、データが転送可能か判断するように拡張を行った。

［数１４］
もし（ＳＡＣＫで通知された受信バッファサイズ）
−転送中データサイズ合計値（Ｔｏｔａｌ−ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）
−新規送信データサイズ＞０であれば、
（ａ）データ送信を実行し、
（ｂ）転送中データサイズ合計値（Ｔｏｔａｌ−ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）
＝転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）の合計値
の計算を実行する。 （１４）

次いで、ゼロウィンドウ問題の解決方法について以下に説明する。上記で述べたゼロウィンドウ問題に対してＭＲ−ＳＣＴＰ処理部２０では、選択的肯定確認応答（ＳＡＣＫ）の受信時に、ＳＡＣＫに含まれる空きバッファ容量（ＡＲＷＮＤ）＝０の場合に、転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）＝０であっても転送中データサイズ合計値（Ｔｏｔａｌ−ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）が０でなければ、データを送信しない。ただし、データを送信しなければ、ＳＡＣＫを受信できない可能性があるために、空きバッファ容量（ＡＲＷＮＤ）＝０でかつ転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）＝０かつ転送中データサイズ合計値（Ｔｏｔａｌ−ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）が０でなければ、ＨＥＡＲＴＢＥＡＴチャンクを送信し、ルートの状態をデータが送信できない状態に遷移させる。新規データの送信はＨＲＡＲＴＢＥＡＴ−ＡＣＫチャンクを受信した時点で再度、新規データを送信できるかチェックを行って送信する。再度チェックを行っても上記の条件を満たす場合は、この状態遷移を繰り返す。
これらの処理によりゼロウィンドウの問題を解決した（図１５及び図１６参照。）。

図１５及び図１６は、図１のＭＲ−ＳＣＴＰ処理部２０によって実行される１ルート当たりの新規ＭＲ−ＤＡＴＡチャンクの送信処理を示すフローチャートである。当該送信処理は、ステップＳ９１又はＳ９２の判断処理でＹＥＳとなったときに実行される。

図１５のステップＳ９１においてＭＲ−ＳＡＣＫチャンクを受信し、又はＨＥＡＲＴＢＥＡＴチャンクを受信したか否かを判断し、ＹＥＳとなるまでステップＳ９１の処理を繰り返し、ＹＥＳとなったときステップＳ９４に進む。また、ステップＳ９２において上位層装置３０からデータ送信の命令を受信したか否かを判断し、ＹＥＳとなるまでステップＳ９２の処理を繰り返し、ＹＥＳとなったとき、ステップＳ９３において再送バッファメモリにチャンクが存在するか否かを判断し、ＹＥＳのときは当該処理を終了する一方、ＮＯのときはステップＳ９４に進む。

ステップＳ９４において処理対象のルートが以下の条件をすべて満たしているか否かを判断し、
（１）再送マークされたチャンクが無い；
（２）新規データの送信フラグが１である；
（３）ルートの状態が確立済み状態である；
ＹＥＳのときはステップＳ９５に進む一方、ＮＯのときは当該処理を終了する。ステップＳ９５において処理対象のルートで転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）＜輻輳ウィンドウ値（ＣＷＮＤ）であるか否かを判断し、ＹＥＳのときはステップＳ９６に進む一方、ＮＯのときは当該処理を終了する。次いで、ステップＳ９６において次に生成されるＭＲ−ＤＡＴＡチャンクのサイズがピアＲＷＮＤ（相手側エンドポイント装置５０Ｂの空きバッファ容量（ＲＷＮＤ））より小さいか否かを判断し、ＹＥＳのときはステップＳ９７に進む一方、ＮＯのときはステップＳ９８に進む。ステップＳ９７において１個以上のＭＲ−ＤＡＴＡチャンクからなるＳＣＴＰパケットを作成してステップＳ１００に進む。一方、ステップＳ９８において再送バッファメモリに肯定確認応答されていないチャンクが存在するか否かを判断し、ＹＥＳのときは図１６のステップＳ１０１に進む一方、ＮＯのときはステップＳ９９に進む。ステップＳ９９において１個のＭＲ−ＤＡＴＡチャンクからなるＳＣＴＰパケットを作成し、ステップＳ１００において作成したパケットを送信した後、ステップＳ９５に戻る。

次いで、図１６のステップＳ１０１では、処理対象のルートに肯定確認応答されていないチャンクがあるか否かを判断し、ＹＥＳのときは当該処理を終了する一方、ＮＯのときはステップＳ１０２に進む。ステップＳ１０２においてルートＩＤ（ＲＩＤ）、ＲＳＮを除くルートの制御データを初期化し、ステップＳ１０３において処理対象のルートのＨＥＡＲＴＢＥＡＴチャンクを送信し、ステップＳ１０４において処理対象のルートの状態を待機初期状態にセットする。そして、ステップＳ１０５において処理対象の宛先アドレスの中に確立済み状態のルートがあるか否かを判断し、ＹＥＳのときは当該処理を終了する一方、ＮＯのときはステップＳ１０６に進み、ＲＩＤ＝０のルートの状態を確立済み状態にし、当該処理を終了する。

次いで、ルート状態の管理問題とその対策について以下に説明する。上述したルート情報の交換だけでなく、データ転送中においてもルートの状態を管理し、ルートの状態に応じてデータ転送処理を適切に行う必要がある。この状態管理は、マルチルート以外のデータ転送においては、必須の技術ではないが、マルチルート通信においては必須の技術である。従来技術に係るＳＣＴＰにおけるパスの管理手法では、パスの状態は「アクティブ（動作状態）」「インアクティブ（非動作状態）」だが、マルチルートを利用する場合は以下の問題が発生する。

従来技術に係るＳＣＴＰでは、「ロスを検出したパケット」は、送信バッファメモリ内において再送フラグを設定し、再送データとして区別される。しかしながら、マルチルート通信においてはルートの削除と検出を頻繁に繰り返す可能性が高い。ここで、従来技術に係るＳＣＴＰの定義を適用すると、同じルートＩＤ（ＲＩＤ）を持つルートが複数回追加と削除を繰り返す場合、転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）が０にならない間に追加通知を受けても利用することができない。なぜなら、ＭＲ−ＳＣＴＰ処理部２０において一度割り振られたルートＩＤ（ＲＩＤ）と、削除通知を受けた後で割り振られたルートＩＤ（ＲＩＤ）は必ずしも同じルートとは限らないためである。なお、従来技術に係るＳＣＴＰにおけるパスの定義は、送信側と受信側でアソシエーションを確立した時点で一意に決定するものであり、たとえパスが利用不可能になった場合でも、利用可能な状態に戻った時点では、同じパスとしてのみ利用できる。変数も引き継ぐことが可能であった。マルチルート拡張の観点はルートの状態を把握して、転送制御を行うことによって複数のルートを効率良くデータ転送に使うことである。従って、ルートＩＤ（ＲＩＤ）の再割り当てが発生した場合は、基本的にルート上の転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）が０になるまで、状態を初期化できないという問題点があった。

この問題点を解決するために、ＭＲ−ＳＣＴＰ処理部２０において、図１７に示すように、ルートを管理する状態遷移において特別な状態を新たに定義した。図１７は、図１のＭＲ−ＳＣＴＰ処理部２０によって実行される、実施形態に係る通常ルート処理を示す状態遷移図である。この状態遷移の処理について以下に説明する。

図１７において、初期状態においてルートの追加が通知されたとき（すなわち、ルート追加の通知メッセージを受信したときであり、以下同様である。）、ルートオブジェクトを作成し、以前に使用したＲＳＮを復元し、ＨＥＡＲＴＢＥＡＴチャンクを送信し、待機初期（ＷＡＩＴ＿ＩＮＩＴ）状態に遷移する。一方、待機初期（ＷＡＩＴ＿ＩＮＩＴ）状態においてルートの削除が通知されたとき（すなわち、ルート削除の通知メッセージを受信したときであり、以下同様である。）、ルートオブジェクトを削除し、初期状態となる。また、待機初期（ＷＡＩＴ＿ＩＮＩＴ）状態においてＨＥＡＲＴＢＥＡＴ−ＡＣＫチャンクを受信したとき、再送チャンクがあれば、ＣＷＮＤの範囲で再送し、その後で送信できれば新規にＭＲ−ＤＡＴＡチャンクを送信し、確立済み（ＥＳＴＡＢＬＩＳＨＥＤ）状態に遷移する。一方、確立済み（ＥＳＴＡＢＬＩＳＨＥＤ）状態においてデータを新規に送信しようとしたときに、次に送信するＭＲ−ＤＡＴＡチャンクのサイズよりもピアＲＷＮＤが小さく、かつ、自己のルートの転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）が０でかつパス全体の転送中データサイズ合計値（Ｔｏｔａｌ−ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）が０よりも大きいとき、ルートＩＤ（ＲＩＤ）及びＲＳＮ以外の内部変数を初期化し、ＨＥＡＲＴＢＥＡＴチャンクを送信し、待機初期（ＷＡＩＴ＿ＩＮＩＴ）状態に戻る。なお、確立済み（ＥＳＴＡＢＬＩＳＨＥＤ）状態において、以下の場合において以下の処理を実行した後、確立済み（ＥＳＴＡＢＬＩＳＨＥＤ）状態に戻る。
（ａ）送信メッセージにより上位層装置３０からデータを受信し、かつＭＲ−ＳＣＴＰ処理部２０の状態が確立済みで、かつ送信メッセージの受信前のアプリケーション層のバッファメモリが空であるとき、新規にＭＲ−ＤＡＴＡチャンクを送信する。
（ｂ）ＭＲ−ＳＡＣＫチャンクを受信したとき、新規にＭＲ−ＤＡＴＡチャンクを送信する。
（ｃ）Ｔ３−Ｒｔｘタイマーが計時終了したとき、未確認チャンクを同じルートで再送する。

さらに、確立済み（ＥＳＴＡＢＬＩＳＨＥＤ）状態においてルートの削除が通知されたとき、削除済み（ＤＥＬＥＴＥＤ）状態に遷移する。当該削除済み（ＤＥＬＥＴＥＤ）状態において、ＭＲ−ＳＡＣＫチャンクを受信したとき（転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）≠０）再送チャンクを別ルートのＣＷＮＤの範囲で再送し、削除済み（ＤＥＬＥＴＥＤ）状態に戻る。また、削除済み（ＤＥＬＥＴＥＤ）状態において、ルートの追加が通知されたとき、待機削除（ＷＡＩＴ＿ＣＬＥＡＲ＿ＩＮＩＴ）状態に遷移する。待機削除（ＷＡＩＴ＿ＣＬＥＡＲ＿ＩＮＩＴ）状態において、ＭＲ−ＳＡＣＫチャンクを受信したとき（転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）≠０）再送チャンクを別ルートのＣＷＮＤの範囲で再送し、待機削除（ＷＡＩＴ＿ＣＬＥＡＲ＿ＩＮＩＴ）状態に戻る。さらに、待機削除（ＷＡＩＴ＿ＣＬＥＡＲ＿ＩＮＩＴ）状態において、Ｔ３−Ｒｔｘタイマーが計時終了しかつＭＲ−ＳＡＣＫチャンクを受信したとき（転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）＝０）、再送チャンクを別ルートのＣＷＮＤの範囲で再送し、ルートデータを初期化し、ＨＥＡＲＴＢＥＡＴチャンクを送信し、待機初期（ＷＡＩＴ＿ＩＮＩＴ）状態に遷移する。また、待機削除（ＷＡＩＴ＿ＣＬＥＡＲ＿ＩＮＩＴ）状態において、ルートの削除が通知されたとき、削除済み（ＤＥＬＥＴＥＤ）状態に戻る。またさらに、削除済み（ＤＥＬＥＴＥＤ）状態において、以下の場合において以下の処理を実行した後、初期状態に戻る。
（ａ）Ｔ３−Ｒｔｘタイマーが計時終了したとき、再送チャンクを別ルートのＣＷＮＤの範囲で再送し、ルートオブジェクトを削除する。
（ｂ）ＭＲ−ＳＡＣＫチャンクを受信したとき（転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）＝０）ルートオブジェクトを削除する。

図１７において、待機初期（ＷＡＩＴ＿ＩＮＩＴ）状態が従来技術に係るＳＣＴＰにおけるインアクティブ（非動作状態）に対応し、確立済み（ＥＳＴＡＢＬＩＳＨＥＤ）状態が従来技術に係るＳＣＴＰにおけるアクティブ（動作状態）に対応する。また、ＭＲ−ＳＣＴＰ処理部２０では、さらに、削除済み（ＤＥＬＥＴＥＤ）状態及び待機削除（ＷＡＩＴ＿ＣＬＥＡＲ＿ＩＮＩＴ）状態を追加した。

図１７から明らかなように、ルートの削除通知を受けると、状態を確立済み（ＥＳＴＡＢＬＩＳＨＥＤ）状態から削除済み（ＤＥＬＥＴＥＤ）状態に遷移させ、処理対象ルートの転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）が０になるまで、状態を遷移させない。転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）が０になった時点で、管理データを削除し及び初期化する。もし転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）が０になる前にルートの追加通知を受信すると、待機削除（ＷＡＩＴ＿ＣＬＥＡＲ＿ＩＮＩＴ）状態に遷移させ、転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）が０になった時点で、待機初期（ＷＡＩＴ＿ＩＮＩＴ）状態に遷移させ通常の状態遷移に戻る。このように、転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）が０になっていない場合の状態遷移に対して、新たな状態を設けたことにより同じルートＩＤ（ＲＩＤ）を再利用する場合の問題を回避できる。なお、この２つの状態の追加のデメリットとして、ルートＩＤ（ＲＩＤ）の再利用時に一定の期間（最長タイムアウト時間まで）待ち時間が発生することが考えられるが、基本的に同じルートＩＤ（ＲＩＤ）が短い周期で、利用可能な状態と、利用不可能な状態を繰り返している場合は、ルートが不安定な場合が多く、転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）が無くなるまで待つことで不安定なルートを直ぐに利用することを防ぐことができる。

図１８は、図１のＭＲ−ＳＣＴＰ処理部２０によって実行される、変形例に係る通常ルート処理を示す状態遷移図である。変形例に係る通常ルート処理では、図１７の実施形態に比較して、待機削除（ＷＡＩＴ＿ＣＬＥＡＲ＿ＩＮＩＴ）状態を削除したことを特徴としている。

以上のように構成することにより、転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）が０になっていない場合の状態遷移に対して、同じルートＩＤ（ＲＩＤ）を再利用する場合の問題を回避できる。

次いで、ルート管理の問題を解決するための「デフォルトルート」の利用方法について以下に説明する。上述のように、パケットロスの検出方法においてアソシエーション開始時にＭＲ−ＳＣＴＰがＩＮＩＴチャンク等を交換するためにデフォルトルートを指定すると述べた。また通常のルートの状態遷移についても説明した。ここではデフォルトルートの説明を行う。

デフォルトルートが必要な理由は、アソシエーション開始時や、データ転送中において全てのルートが削除された場合はＭＲ−ＳＣＴＰがデータ転送のために指定するルートが無くなってしまうことを防止するためである。これは、ルート指定通信を行うためには必須の技術であり、以下のようにデフォルトルートを利用する。

ＭＲ−ＤＳＲ処理部１０では、デフォルトのルート番号（ＲＩＤ＝０）を指定されると、獲得したルート情報の中から指定されたＩＰアドレスに対して最もホップ数が少ないルートを選択して（ＤＳＲの従来技術）して、データを転送する。また、ルートを保持していない場合は、新たにルート検索パケット（ルート要求）を送出してルートを検索する（ＤＳＲの従来技術）。これに対して、ＭＲ−ＳＣＴＰ処理部２０では、ＭＲ−ＤＳＲ処理１０によるルート情報検索結果の取得をきっかけに、ＭＲ−ＤＳＲ処理部１０から新たに利用可能なルートの情報が通知される。利用可能なルート情報を取得すると、ＭＲ−ＳＣＴＰ処理部２０は、デフォルトルートの指定送信から通常のルート指定送信に切り換える。

これに関連する問題点について以下に説明する。デフォルトルートを導入すると、ネットワーク状態が不安定な場合にデフォルトルートとその他ルート利用の切り換えが多発する可能性がある。もしデフォルトルートでデータを送信中にルートの切り換えが複数回発生した場合、デフォルトルート内の転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）を０に初期化してしまうと、デフォルトルートに対して返却されたＳＡＣＫが廃棄されて、データの再送が非常に遅れてしまう可能性がある。上記の問題点を回避するために、図１９に示すように、デフォルトルート処理において特別な状態遷移を適用する。

図１９は、図１のＭＲ−ＳＣＴＰ処理部２０によって実行される、実施形態に係るデフォルトルート処理を示す状態遷移図である。

図１９において、初期状態において、ルートの追加が通知されたとき、ルートオブジェクトを作成し、以前に使用したＲＳＮを復元し、ＨＥＡＲＴＢＥＡＴチャンクを送信し、待機初期（ＷＡＩＴ＿ＩＮＩＴ）状態に遷移する。一方、待機初期（ＷＡＩＴ＿ＩＮＩＴ）状態において、ルートの削除が通知されたとき、ルートオブジェクトを削除し、初期状態に戻る。また、待機初期（ＷＡＩＴ＿ＩＮＩＴ）状態において、ＨＥＡＲＴＢＥＡＴ−ＡＣＫチャンクを受信したとき、再送チャンクがあれば、ＣＷＮＤの範囲で再送し、その後で送信できれば新規にＭＲ−ＤＡＴＡチャンクを送信し、確立済み（ＥＳＴＡＢＬＩＳＨＥＤ）状態に遷移する。一方、確立済み（ＥＳＴＡＢＬＩＳＨＥＤ）状態においてデータを新規に送信しようとしたときに、次に送信するＭＲ−ＤＡＴＡチャンクのサイズよりもピアＲＷＮＤが小さく、かつ、自己のルートの転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）が０でかつパス全体の転送中データサイズ合計値（Ｔｏｔａｌ−ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）が０よりも大きいとき、ルートＩＤ（ＲＩＤ）及びＲＳＮ以外の内部変数を初期化し、ＨＥＡＲＴＢＥＡＴチャンクを送信し、待機初期（ＷＡＩＴ＿ＩＮＩＴ）状態に戻る。なお、確立済み（ＥＳＴＡＢＬＩＳＨＥＤ）状態において、以下の場合において以下の処理を実行した後、確立済み（ＥＳＴＡＢＬＩＳＨＥＤ）状態に戻る。
（ａ）送信メッセージにより上位層装置３０からデータを受信し、かつＭＲ−ＳＣＴＰ処理部２０の状態が確立済みで、かつ送信メッセージの受信前のアプリケーション層のバッファメモリが空であるとき、新規にＭＲ−ＤＡＴＡチャンクを送信する。
（ｂ）ＭＲ−ＳＡＣＫチャンクを受信したとき、新規にＭＲ−ＤＡＴＡチャンクを送信する。
（ｃ）Ｔ３−Ｒｔｘタイマーが計時終了したとき、未確認チャンクを同じルートで再送する。

さらに、確立済み（ＥＳＴＡＢＬＩＳＨＥＤ）状態において、ＲＩＤ＝０でかつ他のルートのいずれかの状態が確立済みになったとき、削除済みデフォルト（ＤＥＬＥＴＥＤ＿ＤＥＦＡＵＬＴ）状態に遷移する。一方、削除済みデフォルト（ＤＥＬＥＴＥＤ＿ＤＥＦＡＵＬＴ）状態において、ＲＩＤ＝０でかつ他のルートが全て確立済み以外の状態になったとき、未確認チャンクを同じルートで再送し、確立済み（ＥＳＴＡＢＬＩＳＨＥＤ）状態に戻る。また、削除済みデフォルト（ＤＥＬＥＴＥＤ＿ＤＥＦＡＵＬＴ）状態において、ＭＲ−ＳＡＣＫチャンクを受信（転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）≠０）したとき、再送チャンクを別ルートのＣＷＮＤの範囲で再送し、削除済みデフォルト（ＤＥＬＥＴＥＤ＿ＤＥＦＡＵＬＴ）状態に戻る。なお、削除済みデフォルト（ＤＥＬＥＴＥＤ＿ＤＥＦＡＵＬＴ）状態において、Ｔ３−Ｒｔｘタイマーが計時終了しかつＭＲ−ＳＡＣＫチャンクを受信したとき（転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）＝０）ルートデータを初期化し、停止（ＣＬＯＳＥＤ）状態に遷移する。

初期状態において、ＲＩＤ＝０でかつＭＲ−ＳＣＴＰ処理部２０の状態が確立済み状態に変化したときＨＥＡＲＴＢＥＡＴチャンクを送信し、停止（ＣＬＯＳＥＤ）状態に遷移する。停止（ＣＬＯＳＥＤ）状態において、ＲＩＤ＝０でかつ他のルートが全て確立済み以外の状態になったとき、ＨＥＡＲＴＢＥＡＴチャンクを送信し、待機初期（ＷＡＩＴ＿ＩＮＩＴ）状態に遷移する。一方、待機初期（ＷＡＩＴ＿ＩＮＩＴ）状態において、ＲＩＤ＝０でかつ他のルートのいずれかの状態が確立済みになり、もし転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）＝０なら他のルートに再送データを移し、停止（ＣＬＯＳＥＤ）状態に遷移する。

図１９から明らかなように、デフォルトルート処理において、待機初期（ＷＡＩＴ＿ＩＮＩＴ）状態及び確立済み（ＥＳＴＡＢＬＩＳＨＥＤ）状態に加えて、削除済みデフォルト（ＤＥＬＥＴＥＤ＿ＤＥＦＡＵＬＴ）状態及び停止（ＣＬＯＳＥＤ）状態を追加した。具体的には、ルートの切り換えが発生した場合でも、転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）が存在していれば、転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）が０になるまでは、ＭＲ−ＳＡＣＫチャンクを受信しかつ再送タイマーが計時終了するまで、状態を削除済みデフォルト（ＤＥＬＥＴＥＤ＿ＤＥＦＡＵＬＴ）状態に保持しておく。状態が削除済みデフォルト（ＤＥＬＥＴＥＤ＿ＤＥＦＡＵＬＴ）状態のままで、ルートの切り換えが発生した場合は、変数を初期化することなくデータの転送を続け、その状態を保持する。

なぜなら、上述のマルチルートのための輻輳制御において、デフォルトルート以外のルートでは、転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）が０になるまで、待機初期（ＷＡＩＴ＿ＩＮＩＴ）状態で待つ理由を説明したが、デフォルトルートでは、上記のように待たないで直ぐに確立済み（ＥＳＴＡＢＬＩＳＨＥＤ）状態に遷移させなければならない。しかしながら、転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）はあくまで転送ルート上のイベント（ＭＲ−ＳＡＣＫチャンクを受信したときの処理や、Ｔ３−Ｒｔｘタイマーが計時終了したとき）に従って管理すべきだからである。なお、デフォルトルート以外のルートでは、同じルートＩＤ（ＲＩＤ）の再利用が待機初期（ＷＡＩＴ＿ＩＮＩＴ）状態に遷移する条件になっているが、デフォルトルートでは、遷移の条件を全てのルートが削除された場合と、１つのルートでも利用可能になることを遷移の条件にしている。

図２０は、図１のＭＲ−ＳＣＴＰ処理部２０によって実行される、変形例に係るデフォルトルート処理を示す状態遷移図である。図２０の変形例では、停止（ＣＬＯＳＥＤ）状態を削除したことを特徴としている。以下、相違点について説明する。

図２０において、初期状態で次の場合において以下の処理を実行して待機初期（ＷＡＩＴ＿ＩＮＩＴ）状態に遷移する。
（ａ）ＲＩＤ＝０でかつＭＲ−ＳＣＴＰ処理部２０の状態が確立済みに変化したとき、ＨＥＡＲＴＢＥＡＴチャンクを送信する。
（ｂ）ＲＩＤ＝０でかつ他のルートが全て確立済み以外の状態になるとき、ＨＥＡＲＴＢＥＡＴチャンクを送信する。
一方、待機初期（ＷＡＩＴ＿ＩＮＩＴ）状態において、ＲＩＤ＝０でかつ他のルートのいずれかの状態が確立済みになり、もし転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）＝０であるとき、他のルートに再送データを移し、初期状態に戻る。

なお、図２０の待機初期（ＷＡＩＴ＿ＩＮＩＴ）状態と確立済み（ＥＳＴＡＢＬＩＳＨＥＤ）状態との間の状態遷移は、図１９と同様である。また、図２０の確立済み（ＥＳＴＡＢＬＩＳＨＥＤ）状態から確立済み（ＥＳＴＡＢＬＩＳＨＥＤ）状態に戻る状態遷移は、図１９の確立済み（ＣＨＥＣＫＥＤ）状態におけるそれと同様であり、図２０の確立済み（ＥＳＴＡＢＬＩＳＨＥＤ）状態と削除済みデフォルト（ＤＥＬＥＴＥＤ＿ＤＥＦＡＵＬＴ）状態との間の状態遷移は、図１９と同様である。さらに、図２０の削除済みデフォルト（ＤＥＬＥＴＥＤ＿ＤＥＦＡＵＬＴ）状態から削除済みデフォルト（ＤＥＬＥＴＥＤ＿ＤＥＦＡＵＬＴ）状態に戻る状態遷移も図１９と同様である。またさらに、削除済みデフォルト（ＤＥＬＥＴＥＤ＿ＤＥＦＡＵＬＴ）状態において、Ｔ３−Ｒｔｘタイマーが計時終了しかつＭＲ−ＳＡＣＫチャンクを受信したとき（転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）＝０）ルートデータを初期化し、初期状態に遷移する。

以上のように構成することにより、図１９の実施形態と同様に、ルートの切り換えが発生した場合でも、転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）が存在していれば、転送中データサイズ（ＯｕｔｓｔａｎｄｉｎｇＢｙｔｅｓ）が０になるまでは、ＭＲ−ＳＡＣＫチャンクを受信しかつ再送タイマーが計時終了するまで、状態を削除済みデフォルト（ＤＥＬＥＴＥＤ＿ＤＥＦＡＵＬＴ）状態に保持しておく。状態が削除済みデフォルト（ＤＥＬＥＴＥＤ＿ＤＥＦＡＵＬＴ）状態のままで、ルートの切り換えが発生した場合は、変数を初期化することなくデータの転送を続け、その状態を保持する。

さらに、ルート選択方法の問題点とその解決方法について以下に説明する。

まず、ルート検出パケットによるネットワーク負荷について説明する。ＭＲ−ＳＣＴＰ処理部２０及びＭＲ−ＤＳＲ処理部１０におけるルート検出パケットは、全ての利用可能なルートが利用不可能な状態になっていることを検出したらルート検索を行う。所定の時間周期での定期的なルート検出は行わない。従って、周期的に検索するよりもネットワークに対する負荷は低くなる。これは従来技術であるＤＳＲにおけるルート検出方法と同じである。

次いで、古いルート情報を利用することによる問題点とその対処方法について以下に説明する。問題点Ｄの第２項目で述べたように、検出したルート情報を内部でメモリ上に保存し、利用しているルートが使えなくなってから他のルートに切り換えた場合、切り換え先のルートが既に存在しない等の理由で利用できない可能性がある。また、切り換えたルートは利用可能であっても既にもっと品質の良いルートが存在している可能性がある。しかしながら、この状態を検出するためには新規にルート検出用のパケットを送信しなければならない。しかし、上述のようにルート検索のパケットはネットワークに多大な負荷をかけるために、単純にルート検索パケットの送信回数（周期）を増やしてはならない。安定してルートを利用できる環境では、ルート検索パケットの送信自体が、ネットワークを不安定にさせる可能性があるためである。

この対処方法は以下の通りである。まず、ルート切り替え時の問題については、ＭＲ−ＳＣＴＰ処理部２０では検出した複数のルートを同時に利用するために、キャッシュしたルートが利用されないまま利用不可能な状態になることはない。従って、従来の単一ルートを利用する場合のように、ルートの切り換え発生時に切り替え先のルートが利用できないという問題は発生しない。なお、通常ルート切り換え先のルートは既にデータ転送を行っている実績のあるルートであるからである。

次に、利用不可能なルートを早期に発見する方法は以下の通りである。また複数のルートを同時に利用することは、品質が悪いあるいは時間を経過すると悪くなるルートを、利用できる間に利用して、利用不可能な状態を早期に検出することにも繋がる。その結果、検出した全てのルートの品質が悪化し、既に品質の良いルートが存在していた場合でも、単一ルートを利用するよりも素早くルートエラーを検出し、新規にルート検索パケットを送信することが可能である。特に、アドホック無線ネットワークにおいては通信端末装置の移動度が高い環境では、古いルート情報をキャッシュして利用すると、上記の問題点はさらにネットワークのパフォーマンスに深刻な影響を与える。以下で事前に検出した全てのルートがホップ数や距離の要因でルートエラーを検出し、新規にルート検索パケットを送信するまでにかかる時間を示す。一般的に存在しているルートが、トラフィックの輻輳や無線通信におけるビットエラーやリンクの切断等により利用不可能な状態だと判断するためには、実際にデータパケットを転送する必要がある。又はルートが存在しない場合は最悪の場合タイムアウトが発生するまで、ルートエラーを検出できない可能性もある。

ここで、転送ルートｎ上でルートエラーを検出するまでにかかる時間をＴｒｎとすると、単一ルートを利用するプロトコルで、ルートの切り換えが発生した時点から全てのルートが利用不可能な状態になることを検出するまでの時間Ｔｒａｌｌは、次式で表される。

［数１５］
Ｔｒａｌｌ＝Σ_ｉ（Ｔｒｉ） （１５）

ここで、式（１５）の右辺における総和は全ての転送ルートｉに関する総和である。移動度の高い環境ではこの時間は高いオーバーヘッドになる可能性がある。一方、ＭＲ−ＳＣＴＰ処理部２０及びＭＲ−ＤＳＲ処理部１０においては、全てのルートが利用不可能な状態になることを検出するまでの時間は、同様に次式で表される。

［数１６］
Ｔｒａｌｌ＝ｍａｘ（Ｔｒｉ） （１６）

ここで、式（１６）の右辺のｍａｘは、引数Ｔｒｉのうちの最大値を示す関数である。この式（１６）は単純に複数のルートを同時に利用した場合、エラーを検出するまでに最も時間がかかるルートの検出時間が、全てのルートについてエラーを検出するまでにかかる時間であることを意味している。また、複数のルートを同時に利用した場合、理想的な環境（ルート間の干渉が発生しない）では最も安定している（ビットエラーやリンク切断が少ない）ルートがエラーになるまでの時間が、ルート検出パケットを送信する時刻となることを示している。最も安定しているルート（ｍａｘ（Ｔｒｉ）の検出時間を有する）がｍａｘ（Ｔｒｉ）秒後に利用不可能な状態になると、同時期に検出していた他のルートでは既に利用不可能な状態になっており、それを契機に新規にルート検索のパケットを送信することになる。これは無駄にルート検索パケットの転送周期を短くしたわけではなく、実際に利用しているネットワークの状態を反映して、従来技術に比較してより適切なタイミングでルート検索パケットを送信可能にした。従って、ＭＲ−ＳＣＴＰ処理部２０では、通常の単一ルートを利用した通信より｛ｍａｘ（Ｔｒｉ）−Σ_ｉ（Ｔｒｉ）｝秒早く全てのルートが利用不可能な状態であることを検出できデータ転送のパフォーマンスも向上させることができる。

さらに、指数的バックオフ法の問題点に対する対処方法について以下説明する。上述の問題点Ｄの第３項目で述べた問題点は、通信端末装置の移動や上位層装置においてルート毎の状態を管理していないことが原因である。なぜなら、指数的バックオフ法は同一のパスで複数回エラーが発生した場合の制御方式だが、従来技術の方式では転送ルートの区別ができないために、別のルート上でエラーが発生していても転送エラーと認識され、指数的バックオフ法の制御対象になってしまうためである。この問題点に対して提案する手法は、ビットエラー・リンク切断等が原因でルートエラーを検出した場合、制御データの状態更新を停止（タイマーを停止させることで実現する）させて状態復帰後にタイマーを再開させる手法である。しかしこの手法を利用する場合は、途中のノードにおけるエラー検出方法・通知方法や通知を受けた側での対処等、複数箇所の設計を変更する必要がある。ＭＲ−ＳＣＴＰ処理部２０では上記の方式を行わないが、マルチルート通信では、上述したように利用できる限り同時に複数のルートを利用して通信を行いＲＴＯの管理もルート毎で行う。ルート毎にＲＴＯの管理を行うことにより、特定ルート上で発生するビットエラーやリンク切断が原因でタイムアウトが発生しても、指数的バックオフ法の処理の原因となる連続したタイムアウトが発生する可能性は低くなる。なぜなら、特定ルート上で発生したリンク切断はルートの削除処理を引き起し、ルートに関連するＲＴＯの発生回数もルート削除と供に初期化されるためである。従って、特別な処理を追加しなくても、指数的バックオフ法の発生を抑えることが可能である。

またさらに、検出したルート間で品質の差が大きい場合の対処方法について以下に説明する。上述の問題点Ｄの第４項目で述べたように、検出したルート間でデータ転送時間（ＲＴＴ）の差が大きい場合、一時的にデータ転送がストップする可能性がある。通常トポロジーに基づくルートの品質を表す値としては、データ転送時間（ＲＴＴ）、パケットロス率、／遅延等が挙げられる。さらに、ＭＲ−ＳＣＴＰ処理部２０では、無線アドホック無線ネットワーク上での通信を前提にしており、無線アドホック無線ネットワークでは上記以外の重要な値として、ホップ数が用いられる。ＭＲ−ＳＣＴＰ処理部２０では検出したルートの評価を行うために以下のルートのホップ数に基づいた制限を追加した。

ＭＲ−ＤＳＲ処理部２０から通知されたルート情報にはルートに対応するホップ数が含まれているため、ＭＲ−ＳＣＴＰ処理部２０は所定のしきい値（設定により変更可能）の制限以上のルートは利用せずルート情報を廃棄する。ただし、ＭＲ−ＤＳＲ処理部２０ではしきい値以上のルート（ＭＲ−ＳＣＴＰ処理部２０で廃棄したルート）に関しても保持しているために、ＭＲ−ＳＣＴＰ処理部２０が保持しているルートが全て利用不可の状態になりデフォルトルート（ＲＩＤ＝０；ＭＲ−ＤＳＲ処理部１０で管理する）に転送を任せた時点で、それらのルートが使用される。ただし、その際には、ＭＲ−ＳＣＴＰ処理部２０は新規にルート情報を通知されない限り、デフォルトルートのみを利用し続ける。複数のルートを同時に利用することは無い。従って、ルート上記の問題によりデータ転送が止まることは無い。また、この仕組みはしきい値（ホップ数）の値により式（１５）及び式（１６）に影響を与える可能性があり、次式のごとく修正する必要がある。

［数１７］
Ｔｒａｌｌ＝ｍａｘ（Ｔｒｉ）＋Σ_ｊ（Ｔｒｊ） （１７）

ここで、ｊはしきい値以上のルートである。もし、しきい値以上のホップ数のルートが多く存在していた場合（ｍａｘ（Ｔｒｉ）≪Σ_ｊ（Ｔｒｊ））は、通常の単一ルートの場合に比べてルートエラー検出時間に差が無くなる可能性がある。

以上詳述したように、本発明に係る無線ネットワークのための制御装置及び制御方法によれば、トランスポート層の所定のプロトコルを用いて１つのデータの複数のパケットを送信元通信端末装置から宛先通信端末装置に伝送する無線ネットワークの制御装置及び制御方法であって、上記データの各パケットに対して、ルートを識別するルート識別子（ＲＩＤ）と、ルート毎のシーケンス番号であるルートシーケンス番号（ＲＳＮ）とを付して、上記各パケットを複数のルートを介して伝送するように制御する。ここで、例えば、宛先通信端末装置からの、送信パケットに対する選択的肯定確認応答（ＳＡＣＫ）メッセージに応答して、ルート識別子（ＲＩＤ）に基づいて、ルート毎のデータ転送時間（ＲＴＴ）を計算するルート毎の再送タイマーを含み、再送時刻を管理し、また、宛先通信端末装置からの、同一の送信データに対する所定の複数回の選択的肯定確認応答（ＳＡＣＫ）メッセージに応答して、上記各選択的肯定確認応答（ＳＡＣＫ）メッセージに含まれるルート識別子（ＲＩＤ）及びルートシーケンス番号（ＲＳＮ）に基づいて、再送マークを付与して高速再送信で当該送信データの再送処理を実行する。それ故、例えばアドホック無線ネットワークなどの無線ネットワークにおいて、１つのアソシエーションに属する複数のパケットを複数のルートを用いて、従来技術に比較して効率的に伝送することができ、データ転送全体のスループットを向上できる。

本発明の実施形態に係るアドホック無線ネットワークのためのエンドポイント装置５０の構成を示すブロック図である。 図１の通信制御データメモリ２１ａに格納される詳細データを示すブロック図である。 図１のエンドポイント装置５０Ａ，５０Ｂ間のパケット通信におけるＴ３−ＲＴＸタイマーの計時終了による再送の発生を示すシーケンス図である。 図１のエンドポイント装置５０Ａ，５０Ｂ間のパケット通信における高速再送信の発生を示すシーケンス図である。 図１のＭＲ−ＳＣＴＰ処理部２０によって実行されるＭＲ−ＳＡＣＫチャンクのギャップ肯定確認応答ブロック（ＧａｐＡｃｋＢｌｏｃｋ）による再送チャンクの設定処理の第１の部分を示すフローチャートである。 図１のＭＲ−ＳＣＴＰ処理部２０によって実行されるＭＲ−ＳＡＣＫチャンクのギャップ肯定確認応答ブロック（ＧａｐＡｃｋＢｌｏｃｋ）による再送チャンクの設定処理の第２の部分を示すフローチャートである。 図１のエンドポイント装置５０Ａ，５０Ｂ間のパケット通信における輻輳ウィンドウ値（ＣＷＮＤ）を再計算するタイミングを示すシーケンス図である。 図１のＭＲ−ＳＣＴＰ処理部２０によって実行される輻輳ウィンドウ値（ＣＷＮＤ）の更新処理を示すフローチャートである。 図１のＭＲ−ＳＣＴＰ処理部２０によって実行されるルート間でのＭＲ−ＤＡＴＡチャンクの引き継ぎ処理を示すフローチャートである。 図１のＭＲ−ＳＣＴＰ処理部２０によって実行される再送チャンクの送信処理の第１の部分を示すフローチャートである。 図１のＭＲ−ＳＣＴＰ処理部２０によって実行される再送チャンクの送信処理の第２の部分を示すフローチャートである。 図１のエンドポイント装置５０Ａ，５０Ｂ間のパケット通信におけるアソシエーションの確立時のルートイベントシーケンスを示すシーケンス図である。 図１のエンドポイント装置５０Ａ，５０Ｂ間のパケット通信におけるアソシエーションの確立後のルートイベントシーケンスを示すシーケンス図である。 図１のエンドポイント装置５０Ａ，５０Ｂ間のパケット通信におけるマルチルートにおけるオーバーフローを示すシーケンス図である。 図１のＭＲ−ＳＣＴＰ処理部２０によって実行される１ルート当たりの新規ＭＲ−ＤＡＴＡチャンクの送信処理の第１の部分を示すフローチャートである。 図１のＭＲ−ＳＣＴＰ処理部２０によって実行される１ルート当たりの新規ＭＲ−ＤＡＴＡチャンクの送信処理の第２の部分を示すフローチャートである。 図１のＭＲ−ＳＣＴＰ処理部２０によって実行される、実施形態に係る通常ルート処理を示す状態遷移図である。 図１のＭＲ−ＳＣＴＰ処理部２０によって実行される、変形例に係る通常ルート処理を示す状態遷移図である。 図１のＭＲ−ＳＣＴＰ処理部２０によって実行される、実施形態に係るデフォルトルート処理を示す状態遷移図である。 図１のＭＲ−ＳＣＴＰ処理部２０によって実行される、変形例に係るデフォルトルート処理を示す状態遷移図である。 従来技術に係るＳＣＴＰ（Stream Control Transmission Protocol）を用いた通信システムを示すブロック図である。 図２１のＳＣＴＰで用いるＳＣＴＰパケットの構成を示す図である。

符号の説明

１…アンテナ、
２…無線送信部、
１０…ＭＲ−ＤＳＲ処理部、
１１…コントローラ、
１２…アドホックルーティングプロトコル処理部、
１２ａ…受信バッファメモリ、
１２ｂ…送信バッファメモリ、
２０…ＭＲ−ＳＣＴＰ処理部、
２１…コントローラ、
２１ａ…通信制御データメモリ、
２２…プロトコルインターフェース、
２３…バンドル／アンバンドル処理部、
２４…ルート毎輻輳制御部、
２５…アソシエーションフロー制御部、
２６…アソシエーションバッファ部、
２７…フラグメント／リアッセンブリ処理部、
３０…上位層装置、
５０，５０Ａ，５０Ｂ…エンドポイント装置。

Claims (30)

1. トランスポート層の所定のプロトコルを用いて１つのデータの複数のパケットを送信元通信端末装置から宛先通信端末装置に伝送する無線ネットワークの制御装置であって、
   上記データの各パケットに対して、ルートを識別するルート識別子（ＲＩＤ）と、ルート毎のシーケンス番号であるルートシーケンス番号（ＲＳＮ）とを付して、上記各パケットを複数のルートを介して伝送するように制御する制御手段を備えたことを特徴とする無線ネットワークの制御装置。
2. 上記制御手段は、宛先通信端末装置からの、送信パケットに対する選択的肯定確認応答（ＳＡＣＫ）メッセージに応答して、ルート識別子（ＲＩＤ）に基づいて、ルート毎のデータ転送時間（ＲＴＴ）を計算するルート毎の再送タイマーを含み、再送時刻を管理することを特徴とする請求項１記載の無線ネットワークの制御装置。
3. 上記制御手段は、宛先通信端末装置からの、同一の送信データに対する所定の複数回の選択的肯定確認応答（ＳＡＣＫ）メッセージに応答して、上記各選択的肯定確認応答（ＳＡＣＫ）メッセージに含まれるルート識別子（ＲＩＤ）及びルートシーケンス番号（ＲＳＮ）に基づいて、再送マークを付与して高速再送信で当該送信データの再送処理を実行することを特徴とする請求項１又は２記載の無線ネットワークの制御装置。
4. 上記制御手段は、宛先通信端末装置からの、送信パケットに対する選択的肯定確認応答（ＳＡＣＫ）メッセージに応答して、上記選択的肯定確認応答（ＳＡＣＫ）で通知されたルート識別子（ＲＩＤ）で示されたルートを介して送信データを再送することを特徴とする請求項１乃至３のうちのいずれか１つに記載の無線ネットワークの制御装置。
5. 上記制御手段は、宛先通信端末装置からの、ルート削除の通知メッセージを受信したときに、上記通知されたルートにおいて再送マークが付された送信データがあるとき、当該送信データを他のルートを介して再送することを特徴とする請求項３又は４記載の無線ネットワークの制御装置。
6. 上記制御手段は、宛先通信端末装置からの、送信パケットに対する選択的肯定確認応答（ＳＡＣＫ）メッセージに応答して、ルート識別子（ＲＩＤ）に基づいて、ルート毎の輻輳ウィンドウ値（ＣＷＮＤ）を計算することを特徴とする請求項１乃至５のうちのいずれか１つに記載の無線ネットワークの制御装置。
7. 上記制御手段は、各ルートに送信している送信データを把握し、全てのルートにおける伝送中の送信データのデータサイズを計算し、上記計算した当該全てのルートにおける伝送中の送信データのデータサイズに基づいてフロー制御することを特徴とする請求項１乃至６のうちのいずれか１つに記載の無線ネットワークの制御装置。
8. 上記制御手段は、宛先通信端末装置からの、送信パケットに対する選択的肯定確認応答（ＳＡＣＫ）メッセージにより通知された受信バッファサイズから、上記計算した当該全てのルートにおける伝送中の送信データのデータサイズと、新規に送信するデータのサイズとを減算した値が０以上であるときに、当該新規に送信するデータを送信することを特徴とする請求項７記載の無線ネットワークの制御装置。
9. 上記制御手段は、宛先通信端末装置からの、送信パケットに対する選択的肯定確認応答（ＳＡＣＫ）メッセージにより通知された受信バッファサイズが０であるときに、上記計算した全てのルートにおける伝送中の送信データのデータサイズが０でないとき、当該ルートを介して送信データを送信することを中止するように制御することを特徴とする請求項７又は８記載の無線ネットワークの制御装置。
10. 上記制御手段は、宛先通信端末装置からの、ルート削除の通知メッセージを受信したときに、通常ルート処理における削除済み状態に遷移し、宛先通信端末装置からの、送信パケットに対する選択的肯定確認応答（ＳＡＣＫ）メッセージに応答して、当該ルートを介して伝送中の送信データのデータサイズが０でないとき、送信データを他のルートで当該ルートの輻輳ウィンドウ値の範囲で再送する一方、当該ルートを介して伝送中の送信データのデータサイズが０となったとき、当該ルートを削除することを特徴とする請求項１乃至９のうちのいずれか１つに記載の無線ネットワークの制御装置。
11. 上記制御手段は、通常ルート処理における削除済み状態にあるときに、宛先通信端末装置からの、ルート追加の通知メッセージを受信したときに、通常ルート処理における待機削除状態に遷移し、当該待機削除状態において、宛先通信端末装置からの、ルート削除の通知メッセージを受信したときに、通常ルート処理における削除済み状態に戻ることを特徴とする請求項１０記載の無線ネットワークの制御装置。
12. 上記制御手段は、デフォルトルートの初期状態においてルート追加の通知メッセージを受信したとき待機初期状態となり、当該待機初期状態においてＨＥＡＲＴＢＥＡＴ−ＡＣＫメッセージを受信して再送すべきデータがあり再送できれば、確立済み状態に遷移し、また、デフォルトルート処理の初期状態においてデフォルトルートのルート識別子（ＲＩＤ）であって当該状態が確立済みになったとき、ＨＥＡＲＴＢＥＡＴメッセージを送信して、デフォルトルート処理の停止状態に遷移し、当該停止状態においてデフォルトルートのルート識別子（ＲＩＤ）であって他のルートが全て確立済み以外の状態になったときＨＥＡＲＴＢＥＡＴメッセージを送信して待機初期状態に遷移することを特徴とする請求項１乃至１１のうちのいずれか１つに記載の無線ネットワークの制御装置。
13. 上記制御手段は、上記確立済み状態においてデフォルトルートのルート識別子（ＲＩＤ）であって他のルートのいずれかの状態確立済み状態になったとき削除済みデフォルト状態に遷移し、再送タイマーが計時終了し選択的肯定確認応答（ＳＡＣＫ）メッセージを受信しかつ当該デフォルトルートを介して伝送中の送信データのデータサイズが０となったとき停止状態に遷移することを特徴とする請求項１２記載の無線ネットワークの制御装置。
14. 上記プロトコルはＳＣＴＰ（Stream Control Transmission Protocol）であることを特徴とする請求項１乃至１３のうちのいずれか１つに記載の無線ネットワークの制御装置。
15. トランスポート層の所定のプロトコルを用いて１つのデータの複数のパケットを送信元通信端末装置から宛先通信端末装置に伝送する無線ネットワークの制御方法であって、
    上記データの各パケットに対して、ルートを識別するルート識別子（ＲＩＤ）と、ルート毎のシーケンス番号であるルートシーケンス番号（ＲＳＮ）とを付して、上記各パケットを複数のルートを介して伝送するように制御する制御ステップを含むことを特徴とする無線ネットワークの制御方法。
16. 上記制御ステップは、宛先通信端末装置からの、送信パケットに対する選択的肯定確認応答（ＳＡＣＫ）メッセージに応答して、ルート識別子（ＲＩＤ）に基づいて、ルート毎のデータ転送時間（ＲＴＴ）を計算するルート毎の再送タイマーを含み、再送時刻を管理することを特徴とする請求項１５記載の無線ネットワークの制御方法。
17. 上記制御ステップは、宛先通信端末装置からの、同一の送信データに対する所定の複数回の選択的肯定確認応答（ＳＡＣＫ）メッセージに応答して、上記各選択的肯定確認応答（ＳＡＣＫ）メッセージに含まれるルート識別子（ＲＩＤ）及びルートシーケンス番号（ＲＳＮ）に基づいて、再送マークを付与して高速再送信で当該送信データの再送処理を実行することを特徴とする請求項１５又は１６記載の無線ネットワークの制御方法。
18. 上記制御ステップは、宛先通信端末装置からの、送信パケットに対する選択的肯定確認応答（ＳＡＣＫ）メッセージに応答して、上記選択的肯定確認応答（ＳＡＣＫ）で通知されたルート識別子（ＲＩＤ）で示されたルートを介して送信データを再送することを特徴とする請求項１５乃至１７のうちのいずれか１つに記載の無線ネットワークの制御方法。
19. 上記制御ステップは、宛先通信端末装置からの、ルート削除の通知メッセージを受信したときに、上記通知されたルートにおいて再送マークが付された送信データがあるとき、当該送信データを他のルートを介して再送することを特徴とする請求項１７又は１８記載の無線ネットワークの制御方法。
20. 上記制御ステップは、宛先通信端末装置からの、送信パケットに対する選択的肯定確認応答（ＳＡＣＫ）メッセージに応答して、ルート識別子（ＲＩＤ）に基づいて、ルート毎の輻輳ウィンドウ値（ＣＷＮＤ）を計算することを特徴とする請求項１５乃至１９のうちのいずれか１つに記載の無線ネットワークの制御方法。
21. 上記制御ステップは、各ルートに送信している送信データを把握し、全てのルートにおける伝送中の送信データのデータサイズを計算し、上記計算した当該全てのルートにおける伝送中の送信データのデータサイズに基づいてフロー制御することを特徴とする請求項１５乃至２０のうちのいずれか１つに記載の無線ネットワークの制御方法。
22. 上記制御ステップは、宛先通信端末装置からの、送信パケットに対する選択的肯定確認応答（ＳＡＣＫ）メッセージにより通知された受信バッファサイズから、上記計算した当該全てのルートにおける伝送中の送信データのデータサイズと、新規に送信するデータのサイズとを減算した値が０以上であるときに、当該新規に送信するデータを送信することを特徴とする請求項２１記載の無線ネットワークの制御方法。
23. 上記制御ステップは、宛先通信端末装置からの、送信パケットに対する選択的肯定確認応答（ＳＡＣＫ）メッセージにより通知された受信バッファサイズが０であるときに、上記計算した全てのルートにおける伝送中の送信データのデータサイズが０でないとき、当該ルートを介して送信データを送信することを中止するように制御することを特徴とする請求項２１又は２２記載の無線ネットワークの制御方法。
24. 上記制御ステップは、宛先通信端末装置からの、ルート削除の通知メッセージを受信したときに、通常ルート処理における削除済み状態に遷移し、宛先通信端末装置からの、送信パケットに対する選択的肯定確認応答（ＳＡＣＫ）メッセージに応答して、当該ルートを介して伝送中の送信データのデータサイズが０でないとき、送信データを他のルートで当該ルートの輻輳ウィンドウ値の範囲で再送する一方、当該ルートを介して伝送中の送信データのデータサイズが０となったとき、当該ルートを削除することを特徴とする請求項１５乃至２３のうちのいずれか１つに記載の無線ネットワークの制御方法。
25. 上記制御ステップは、通常ルート処理における削除済み状態にあるときに、宛先通信端末装置からの、ルート追加の通知メッセージを受信したときに、通常ルート処理における待機削除状態に遷移し、当該待機削除状態において、宛先通信端末装置からの、ルート削除の通知メッセージを受信したときに、通常ルート処理における削除済み状態に戻ることを特徴とする請求項２４記載の無線ネットワークの制御方法。
26. 上記制御ステップは、デフォルトルートの初期状態においてルート追加の通知メッセージを受信したとき待機初期状態となり、当該待機初期状態においてＨＥＡＲＴＢＥＡＴ−ＡＣＫメッセージを受信して再送すべきデータがあり再送できれば、確立済み状態に遷移し、また、デフォルトルート処理の初期状態においてデフォルトルートのルート識別子（ＲＩＤ）であって当該状態が確立済みになったとき、ＨＥＡＲＴＢＥＡＴメッセージを送信して、デフォルトルート処理の停止状態に遷移し、当該停止状態においてデフォルトルートのルート識別子（ＲＩＤ）であって他のルートが全て確立済み以外の状態になったときＨＥＡＲＴＢＥＡＴメッセージを送信して待機初期状態に遷移することを特徴とする請求項１５乃至２５のうちのいずれか１つに記載の無線ネットワークの制御方法。
27. 上記制御ステップは、上記確立済み状態においてデフォルトルートのルート識別子（ＲＩＤ）であって他のルートのいずれかの状態確立済み状態になったとき削除済みデフォルト状態に遷移し、再送タイマーが計時終了し選択的肯定確認応答（ＳＡＣＫ）メッセージを受信しかつ当該デフォルトルートを介して伝送中の送信データのデータサイズが０となったとき停止状態に遷移することを特徴とする請求項２６記載の無線ネットワークの制御方法。
28. 上記プロトコルはＳＣＴＰ（Stream Control Transmission Protocol）であることを特徴とする請求項１５乃至２８のうちのいずれか１つに記載の無線ネットワークの制御方法。
29. 請求項１乃至２８のうちのいずれか１つに記載の無線ネットワークの制御方法における各ステップを含むことを特徴とする制御プログラム。
30. 請求項２９記載の制御プログラムを格納したことを特徴とするコンピュータで読み取り可能な記録媒体。
    

Images