JP4780343B2 - 通信方法、通信システム、ノードおよびプログラム - Google Patents

通信方法、通信システム、ノードおよびプログラム Download PDF

Info

Publication number
JP4780343B2
JP4780343B2 JP2007554937A JP2007554937A JP4780343B2 JP 4780343 B2 JP4780343 B2 JP 4780343B2 JP 2007554937 A JP2007554937 A JP 2007554937A JP 2007554937 A JP2007554937 A JP 2007554937A JP 4780343 B2 JP4780343 B2 JP 4780343B2
Authority
JP
Japan
Prior art keywords
packet
control information
block
leader
node
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2007554937A
Other languages
English (en)
Other versions
JPWO2007083687A1 (ja
Inventor
恒夫 中田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Priority to JP2007554937A priority Critical patent/JP4780343B2/ja
Publication of JPWO2007083687A1 publication Critical patent/JPWO2007083687A1/ja
Application granted granted Critical
Publication of JP4780343B2 publication Critical patent/JP4780343B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/14—Multichannel or multilink protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/28—Timers or timing mechanisms used in protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Description

本発明は、パケット通信技術および多重化通信技術に関する。
パケットデータ通信においては、デジタルデータはパケットと呼ばれる小包に収容されてネットワーク上を転送される。パケットは転送されるデータ本体と、ネットワーク上の転送制御に用いられる情報を収容したヘッダを含む。階層化ネットワークでは、上位階層のヘッダは下位階層ではデータ本体に含まれる。パケットデータ通信を行う網内の各ノードには、入力される各パケットのヘッダを解読、必要に応じ編集して同じデータを次のノードへ送信する、転送プロトコルの機能が実装される。なお一般にパケット転送プロトコルは非同期プロトコルであり、同じネットワーク上の異なるパケットの転送は各ノードが任意の時刻に行う。したがってパケット転送は送信ノードの性能が許す限り任意の速度で行えることになる。
しかしながらネットワーク上の各ノードや通信路はそれぞれ個別の性能や負荷の下で動作しているので、送信ノードから受信ノードに至る経路上のどこかで、転送能力が送信速度を下回れば、パケットの遅延または廃棄が起こる。このような事態を避けるために、送信ノードと受信ノードの間で通信状態監視のためのシグナリングを行い、その結果を送信速度にフィードバックして適正な送信速度を保つ機構はフロー制御と呼ばれる。
代表的なフロー制御プロトコルとしてはOSI７層モデルにおける第４層プロトコルであるＴＣＰが知られている（詳細は、非特許文献１参照）。第３層にＩＰ（インターネット・プロトコル）が用いられている場合に、ＴＣＰパケットを送信ノードから受信ノードへ送信する例を図１６に示す。ＴＣＰは、第３層以下が提供するエンドエンド接続の上で、過剰な負荷を与えることによるパケットの遅延や欠損、また他のセッションへの過剰な帯域圧迫を避けるために、スライディングウィンドウ方式のフロー制御を実装している（詳細は、非特許文献２参照）。スライディングウィンドウ方式では、ネットワークに一定量（例えば、送信したパケットに対応するＡＣＫが到着するまでに送信可能な量）以下のパケットを保持させることで、過負荷による転送障害を回避しつつ、下位階層の接続が提供する帯域の有効活用を実現する。
ネットワークに保持されるデータ量の上限値はウィンドウサイズと呼ばれる。スライディングウィンドウ方式では、帯域を有効活用するには、帯域と往復遅延の積に比例したウィンドウサイズを設定する必要がある。例えば、下位層の転送ノードにおける処理遅延が無視でき、かつ経路上の物理リンクが、伝播遅延が無視できる程度に短距離の有線回線のみからなるような場合、パケットの転送遅延は帯域に反比例するので、帯域によらずウィンドウサイズは同一でよい。
しかしながら下位層の転送ノードにおける処理遅延や、伝播遅延が無視できないケースでは、下位層の接続の帯域が広いほど、ネットワークの帯域を有効活用するために、ウィンドウサイズを大きく設定する必要がある。一方、ウィンドウサイズが大きくなると、結果的にネットワークへの負荷は大きくなりパケット遅延や損失が生じる可能性が高まるために、ＴＣＰでは一定以上の遅延・帯域積を有する経路ではフロー制御が転送帯域を制限してしまい、経路本来の帯域を有効活用できない（詳細は、非特許文献３参照）。このような場合にもネットワークへの負荷を一定以下に抑えつつ帯域を有効活用する手法として、同一系路上に複数のＴＣＰセッションを張り、各セッションの遅延・帯域積を一定以下に保つことで高い帯域利用効率を確保する並列ＴＣＰの手法が提案されている（詳細は、非特許文献４参照）。
また、２ノード間に複数の経路が存在する場合に、該２ノード間に経路ごとにパケット転送セッションを張り、各セッションに負荷分散して並列転送することにより２ノード間の通信を広帯域化する、逆多重化の手法が知られている。例えば各経路上にＴＣＰセッションを張って並列転送し、単一の経路を用いる場合に比べ広帯域な２ノード間転送を行う手法も提案されている（詳細は、非特許文献５参照）。
次に、遅延や帯域が急激に変動する無線リンクを含む経路上にＴＣＰを適用する場合について考える。この場合、帯域の有効活用のためには遅延と帯域との積（以下、遅延・帯域積という）が最も大きい状態（時点）に合わせてウィンドウサイズを設定する必要がある。そうすると帯域が小さくなったときには遅延が帯域に反比例して大きくなるため、そのような複数の経路を用いて並列転送した場合、経路間のジッタが大きくなる問題がある。このような問題を回避しつつ無線リンクを含む経路を多重化する手段として、各経路の速度および遅延を監視しながら、各パケットが最短の遅延の経路を経由するように経路間の負荷分散を行うＭｏｂｉｌｅ Ｉｎｖｅｒｓｅ Ｍｕｘが提案されている（詳細は、非特許文献６、８、１０、１１参照）。以下ではＭｏｂｉｌｅ Ｉｎｖｅｒｓｅ ＭｕｘをＭＩＭと略する。
ＭＩＭは、各経路の速度と遅延を監視するが、遅延の大きい無線リンクを含む経路では監視結果のフィードバックに遅れが生じるため、保持してある過去の送信履歴を参照して、フィードバック結果が有効となる時刻以降の履歴から、現在パケットを送信した場合の遅延を予測する。各経路に対する遅延予測値に基づきフロー制御を行うことで、帯域を有効活用しつつ経路を多重化する際のジッタを抑制する。
ＭＩＭなどの逆多重化プロトコルの多くでは、異なる経路を経由して転送されたパケットの順序が下流ノードへの転送の際に逆転しないよう、パケット順序制御機能を実装している。この機能は例えば、順序を保存したいフローごとに、送信側ノードは各パケットにシーケンス番号を付与し、受信側ノードは受信したシーケンス番号にしたがってパケットの順序を正しく並べてから下流に転送することで実現される。
RFC793 マスタリングTCP/IP、Phillip Miller著、オーム社開発局（1998） M. Nakamura et al., "End-Node tranmissionrate control kind to intermediate routers," PFLDnet 2004. 角澤ら、「長距離・高バンド幅通信における並列ＴＣＰストリーム間の調停の実現」、SACSIS 2004. 牧、長谷川、村田、村瀬、「ＴＣＰオーバレイネットワークの性能解析および評価」、信学技報IN０4-96 (2004). T.Nakata et al.,"Efficient bundling of heterogeneousradio resources for broadband Internet access from moving vehicles," inproceedings of Global Mobile Congress 2004, Oct. 11-13 2004, Shanghi, China. Dovrolis, Ramanathan, and Moore, "What Do PacketDispersion Techniques Measuere?," IEEE INFOCOM 2001） 小野ら、「移動体インターネット（３） ―再送制御方式―」、２００４年電子情報通信学会総合大会、論文B-5-165 (2004). L.S.Brakmo and L.L.Peterson, "TCP Vegas: End to EndCongestion Avoidance on a Global Internet," IEEE Journal of Selected Areas inCommunications, Vol.13, No.8, p1465 (1995). 岡ノ上ら、「移動体インターネット（１） ―基本コンセプトとシステム構成―」、２００４年電子情報通信学会総合大会、論文B-5-163 (2004). 中田ら、「移動体インターネット（２） ―フロー制御方式―」、２００４年電子情報通信学会総合大会、論文B-5-164 (2004).
以上述べたように、従来パケット転送セッションのフロー制御方式として広く用いられているＴＣＰでは、ある程度以上の遅延・帯域積を有する経路で帯域を有効活用するには、複数セッションを張るなどして各セッションが保つべき遅延・帯域積を小さく保つ機構が必要になる。しかしこれでは、結果として各セッション間への負荷分散など複雑な制御が必要になるという問題がある。また帯域が変動する経路上で用いる場合、帯域に反比例して遅延が増加する問題がある。
一方、遅延を抑制しつつ帯域を有効活用するための複雑なフロー制御を行うＭＩＭにおいては、パケットごとに情報量の多いヘッダ作成、送信履歴情報の保存などの処理負荷が転送速度を制限してしまう問題がある。
またＴＣＰやＭＩＭなどのフロー制御プロトコルでは、転送の完全性を保障するために、特に障害がない場合でも一定以上の周期でＡｃｋなどの確認メッセージを受信側ノードが返信する必要がある。特にセルラ回線のように上りと下りの速度が著しく異なる非対称ネットワークの場合、下り帯域が上り帯域と比較し広いので、上り帯域にあわせてウィンドウサイズを設定すると、帯域利用効率の低下を招き、また、上り帯域の利用率がもともと大きい時にＡｃｋ信号を大量に送信してしまうと往復遅延の増加を招いてしまうという問題がある。
またＭＩＭのように、推定速度などあらわな経路状態をフィードバックしてフロー制御を行うプロトコルにおいては、当該経路への負荷を増やすほど、経路の帯域が大きい方向に変化するときに帯域の利用効率を高く保てる。一方経路の帯域が小さい方向に変化するときには、当該経路への負荷が高いほど転送遅延が増大し、フィードバックにかかる時間が増えるので、誤った状態認識に基づいた負荷分散を行う時間が拡大される。複数の経路のうちの一部で誤った状態認識が生じると、複数の経路間ジッタが増大し、複数の経路をまとめた全体としての通信において、パケット廃棄率または再送率も上昇する。したがって経路の帯域の変化が上昇傾向のときにこれに追随してウィンドウサイズを大きくしてパケットの送出レートを上昇させると、下降傾向のときに悪影響を与えるトレードオフの問題がある。
さらにこれらのフロー制御プロトコルではパケット全体のデータサイズに対するヘッダの占有率が高く、データ転送に使える帯域が圧迫される問題がある。この対策として、ヘッダ圧縮の手法を適用することもできる。しかし、データ転送の信頼性を確保しつつヘッダ圧縮を行うには送信側と受信側で圧縮および伸張に必要な状態変数を共有している必要があり、その更新や同期の確認などのためにプロトコルが複雑になる。また遅延やロスが大きいリンクでは状態変数の同期が追いつかず圧縮効果が出にくいという問題がある。
また、順序制御機能を実装した逆多重化プロトコルにおいて、単一のユーザフローが各経路に負荷分散されて転送さる場合、ユーザフロー内で転送順序を正しく保つために、受信ノードにおいて経路間の速度差により、受信済みの最大シーケンス番号よりも２以上大きいシーケンス番号のパケットが到着した場合に、受信済み最大シーケンス番号より１だけ大きいシーケンス番号のパケット到着まで転送を保留しなければならない。
しかしパケット損失がある場合には、損失したパケットを待つことは転送順序を救済できないのみならず余剰な遅延をもたらすので好ましくない。逆多重化される各経路においては、あるユーザフローのパケットに続くパケットは一般に異なるユーザフローのものなので、損失したパケットがどのユーザフローのものか推定できない。したがって本来不要な、損失したパケットの待機が防げず、転送のリアルタイム性が損なわれると言う問題がある。
また、従来のパケット通信においては、送信側ノードはヘッダに含める制御情報の決定を各送信パケットにつき行い、受信ノードはヘッダ読み取りおよび解析を各パケット受信につき行う。このときノードの処理負荷は送受信データ速度の上昇と共に高まり、ノードの処理能力が特定のプロトコルでのノードの最大転送速度を決める。ＭＩＭやＴＣＰのように処理が複雑なプロトコルでは、ノードの最大転送速度が経路の帯域よりも低くなりやすく、本来は経路の帯域の有効活用のために導入するフロー制御の処理速度がボトルネックとなり、結果的に経路の帯域の活用効率が低下してしまう問題がある。
そこで、本発明は上記課題に鑑みて発明されたものであって、その目的は、データパケットに関する制御情報の送信による負荷を軽減し、通信効率を高める通信技術を提供することにある。
また、本発明の目的は、複数の経路で結ばれたノード間でパケット通信を行う際に、制御情報を格納したリーダパケットを低遅延な経路や信頼性の高い経路を用いて転送することで、シグナリング情報の損失や遅延を抑制することのできる技術を提供することにある。
上記課題を解決するための第１の発明は、
複数のデータパケットとリーダパケットとを１つのブロックとし、
前記複数のデータパケットに関する制御情報を、前記リーダパケットにまとめて送信し、
受信したリーダパケットの制御情報に基づいて、パケットの送信を制御することを特徴とする。
上記課題を解決するための第２の発明は、上記第１の発明において、
前記制御情報は、フロー制御情報であることを特徴とする。
上記課題を解決するための第３の発明は、上記第１の発明において、
前記制御情報は、再送制御情報であることを特徴とする。
上記課題を解決するための第４の発明は、上記第１の発明において、
前記制御情報は、ルーティング情報であることを特徴とする。
上記課題を解決するための第５の発明は、上記第１の発明において、
前記制御情報は、経路情報であることを特徴とする。
上記課題を解決するための第６の発明は、上記第１から第５のいずれかの発明において、
前記制御情報は、前記データパケットに共通する制御情報であることを特徴とする。
上記課題を解決するための第７の発明は、上記第１から第６のいずれかの発明において、
リーダパケットを一意に識別する識別情報を前記データパケットに含めることを特徴とする。
上記課題を解決するための第８の発明は、上記第１から第７のいずれかの発明において、
制御情報をまとめたデータパケットを一意に識別する識別情報を前記リーダパケットに含めることを特徴とする。
上記課題を解決するための第９の発明は、上記第１から第８のいずれかの発明において、
前記複数のデータパケットまたはリーダパケットが、複数の回線を経由して送受信されることを特徴とする。
上記課題を解決するための第１０の発明は、上記第９の発明において、
前記リーダパケットは、前記複数回線中最速の回線を用いて送信することを特徴とする。
上記課題を解決するための第１１の発明は、上記第９の発明において、
前記制御情報に基づいて、前記リーダパケットまたは前記データパケットを送信する回線を選択することを特徴する。
上記課題を解決するための第１２の発明は、上記第１の発明において、受信したリーダ パケットに含まれる制御情報に基づき送信するブロックの送信時刻を決定することを特徴 とする。
上記課題を解決するための第１３の発明は、上記第１の発明において、同一のブロック に属する複数のデータパケットの受信時刻から通信経路の速度を推定することを特徴とす る。
上記課題を解決するための第１４の発明は、複数のデータパケットとリーダパケットと を１つのブロックとして扱い、前記複数のデータパケットに関する制御情報を前記リーダ パケットにまとめるパケットブロック作成手段と、受信したリーダパケットにまとめられ た制御情報に基づいて、パケットの送信を制御するスケジューリング手段と、を有するこ とを特徴とする。
上記課題を解決するための第１５の発明は、上記第１４の発明において、前記制御情報 は、フロー制御情報であることを特徴とする。
上記課題を解決するための第１６の発明は、上記第１４の発明において、前記制御情報 は、再送制御情報であることを特徴とする。
上記課題を解決するための第１７の発明は、上記第１４の発明において、前記制御情報 は、ルーティング情報であることを特徴とする。
上記課題を解決するための第１８の発明は、上記第１４の発明において、前記制御情報 は、経路情報であることを特徴とする。
上記課題を解決するための第１９の発明は、上記第１４の発明において、前記パケット ブロック作成手段は、前記データパケットに共通する制御情報を前記リーダパケットにま とめることを特徴とする。
上記課題を解決するための第２０の発明は、上記第１４の発明において、リーダパケッ トを一意に識別する識別情報を前記データパケットに含めることを特徴とする。
上記課題を解決するための第２１の発明は、上記第１４の発明において、制御情報をま とめたデータパケットを一意に識別する識別情報を前記リーダパケットに含めることを特 徴とする。
上記課題を解決するための第２２の発明は、上記第１４の発明において、前記複数のデ ータパケットまたはリーダパケットを複数の回線を経由して送信する送信手段を有するこ とを特徴とする。
上記課題を解決するための第２３の発明は、上記第２２の発明において、前記スケジュ ーリング手段は、リーダパケットを前記複数回線中最速の回線を用いて送信するように制 御することを特徴とする。
上記課題を解決するための第２４の発明は、上記第２２の発明において、前記スケジュ ーリング手段は、制御情報に基づいて、前記リーダパケットまたは前記データパケットを 送信する回線を選択することを特徴する。
上記課題を解決するための第２５の発明は、上記第１４の発明において、前記スケジュ ーリング手段は、受信したリーダパケットに含まれる制御情報に基づき送信するブロック の送信時刻を決定することを特徴とする。
上記課題を解決するための第２６の発明は、上記第１４の発明において、同一のブロッ クに属する複数のデータパケットの受信時刻から通信経路の速度を推定するパケット解析 部を有することを特徴とする。
上記課題を解決するための第２７の発明は、複数のデータパケットとリーダパケットと を１つのブロックとして扱い、前記複数のデータパケットに関する制御情報を前記リーダ パケットにまとめるパケットブロック作成手段と、他ノードから受信したリーダパケット にまとめられた制御情報に基づいて、パケットの送信を制御するスケジューリング手段と 、を有することを特徴とする。
上記課題を解決するための第２８の発明は、上記第２７の発明において、前記パケット ブロック作成手段は、前記データパケットに共通する制御情報を前記リーダパケットにま とめることを特徴とする。
上記課題を解決するための第２９の発明は、上記第２７の発明において、リーダパケッ トを一意に識別する識別情報を前記データパケットに含めることを特徴とする。
上記課題を解決するための第３０の発明は、上記第２７の発明において、制御情報をま とめたデータパケットを一意に識別する識別情報を前記リーダパケットに含めることを特 徴とする。
上記課題を解決するための第３１の発明は、上記第２７の発明において、前記複数のデ ータパケットまたはリーダパケットを複数の回線を経由して送信する送信手段を有するこ とを特徴とする。
上記課題を解決するための第３２の発明は、上記第３１の発明において、前記スケジュ ーリング手段は、リーダパケットを前記複数回線中最速の回線を用いて送信するように制 御することを特徴とする。
上記課題を解決するための第３３の発明は、上記第３１の発明において、前記スケジュ ーリング手段は、他ノードから受信したリーダパケットにまとめられた制御情報に基づい て、前記リーダパケットまたは前記データパケットを送信する回線を選択することを特徴 する。
上記課題を解決するための第３４の発明は、上記第２７の発明において、前記スケジュ ーリング手段は、他ノードから受信したリーダパケットに含まれる制御情報に基づき送信 するブロックの送信時刻を決定することを特徴とする。
上記課題を解決するための第３５の発明は、上記第２７の発明において、同一のブロッ クに属する複数のデータパケットの受信時刻から通信経路の速度を推定するパケット解析 部を有することを特徴とする。
上記課題を解決するための第３６の発明は、複数のデータパケットとリーダパケットと を１つのブロックとして扱い、前記複数のデータパケットに関する制御情報を前記リーダ パケットにまとめるパケットブロック作成処理と、他ノードから受信したリーダパケット にまとめられた制御情報に基づいて、パケットの送信を制御するスケジューリング処理と 、をコンピュータに実施させることを特徴とする。
上記課題を解決するための第３７の発明は、複数のデータパケットとリーダパケットと を１つのブロックとし、前記複数のデータパケットに関する制御情報を、送信ノードが前 記リーダパケットにまとめて送信し、受信したリーダパケットの制御情報に基づいて推定 した通信経路の状態を示した制御情報をリーダパケットに収容して前記送信ノードに送信 し、前記リーダパケットに収容された制御情報に基づいて送信するブロックのデータ量を 前記送信ノードが決定することを特徴とする。
上記課題を解決するための第３８の発明は、複数のデータパケットとリーダパケットと を１つのブロックとして扱い、前記複数のデータパケットに関する制御情報を、送信ノー ドが前記リーダパケットにまとめるパケットブロック作成手段と、受信したリーダパケッ トにまとめられた制御情報に基づいて推定した通信経路の状態を示した制御情報をリーダ パケットに収容して前記送信ノードに送信する送信手段と、前記リーダパケットに収容さ れた制御情報に基づいて送信するブロックのデータ量を決定するスケジューリング手段と 、を有することを特徴とする。
上記課題を解決するための第３９の発明は、複数のデータパケットとリーダパケットと を１つのブロックとして扱い、前記複数のデータパケットに関する制御情報を、送信側の ノードが前記リーダパケットにまとめるパケットブロック作成手段と、前記送信側のノー ドから受信したリーダパケットにまとめられた制御情報に基づいて推定した通信経路の状 態を示した制御情報をリーダパケットに収容して前記送信側のノードに送信する送信手段 と、前記リーダパケットに収容された制御情報に基づいて送信するブロックのデータ量を 決定するスケジューリング手段と、を有することを特徴とする。
上記課題を解決するための第４０の発明は、複数のデータパケットとリーダパケットと を１つのブロックとして扱い、前記複数のデータパケットに関する制御情報を、送信側の ノードが前記リーダパケットにまとめるパケットブロック作成処理と、前記送信側のノー ドから受信したリーダパケットにまとめられた制御情報に基づいて推定した通信経路の状 態を示した制御情報をリーダパケットに収容して前記送信側のノードに送信する送信手段 と、前記リーダパケットに収容された制御情報に基づいて送信するブロックのデータ量を 決定するスケジューリング処理とをコンピュータに実施させることを特徴とする。
本発明は上述のとおり、複数のデータパケットとリーダパケットとを１つのブロックとし、前記複数のデータパケットの制御情報を、前記リーダパケットにまとめ、前記リーダパケットの制御情報に基づいて、パケットの送信を制御する。このため、ノードにおいて、制御情報を早期に知ることができるので、シグナリングを高速に実施することが可能となる。
本発明は、１つ以上の経路を選択可能な２ノード間において、パケットブロックごとの受信シーケンスに基づく経路状態推定の結果をフィードバックすることで、従来例に比べ正確な経路状態推定に基づくフロー制御および負荷分散を実現できる。
また、本発明は、フロー制御および経路選択処理を複数のパケットに対し１回だけ行うので、送信パケットごとにフロー制御および経路選択処理を行う従来例に比べ処理負荷が軽減される。
また、本発明は、各経路のフロー制御情報、負荷分散情報、ARQ情報、順序制御情報をリーダパケットに集約し、最も低遅延な経路や信頼性の高い経路からブロックの先頭として送信することでシグナリング情報の損失や遅延を抑制し、経路の帯域が上昇傾向のときの帯域利用効率と、下降傾向のときの制御の追従性の間のトレードオフを緩和できる。
また、本発明は、受信ノードはリーダの情報により当該ブロック内のパケット受信シーケンスを予測できるので、予測と違う場合には通信異常と判断することで、通信異常の早期検出が可能となる。
また、本発明は、順序制御バッファ内データの転送を必要以上の長時間保留することがなくなり、エンドエンドジッタが改善される。
また、本発明は、送信側と受信側での状態情報共有が必要なヘッダ圧縮の従来例に比べ簡略な実装でヘッダ情報削減を実現する。
図１は、本発明の第１の実施例を示すシステム構成図である。 図２は、本発明のリーダパケットの構成図である。 図３は、本発明のデータパケットの構成図である。 図４は、フロー制御アルゴリズム（ＰＡＣスケジューラ）を本発明の第１の実施例に応用した例である。 図５は、スケジューリング部が従うフローチャートである。 図６は、パケット作成部が従うフローチャートである。 図７は、本発明の第２の実施例を示すシステム構成図である。 図８は、フロー制御アルゴリズム（ＰＡＣスケジューラ）を本発明の第２の実施例に応用した例である。 図９は、本発明の第２の実施例のフィードバック周期を短くできる例である。 図１０は、本発明の第２の実施例の速度推定精度を一定に保つ例である。 図１１は、本発明の第３の実施例を説明する図である。 図１２は、本発明の第４の実施例を説明する図である。 図１３は、本発明の第５の実施例を説明する図である。 図１４は、本発明の概要を説明する図である。 図１５は、本発明の概要（データパケットが３個以上の場合）を説明する図である。 図１６は、従来の発明の概要を説明する図である。
符号の説明
００３ リーダパケット
００４、００５、００６ データパケット
１０１、１０２ 転送ノード
２０１ バッファ部
２０２ スケジューリング部
２０３ パケットブロック作成部
２０４ パケット送信部
２０５ 記憶部
２０６ パケット受信部
２０７ パケット解析部
２０８ パケット転送部
３０１ データパケット
３０２ リーダパケット
（発明の概要）
図１４を用いて、第１の実施の形態について説明する。図１４は、送信ノード００１から受信ノード００２に対して、本発明のパケット転送を行う様子を示している。従来技術の第４層プロトコルであるＴＣＰを用いたパケット転送では、図１６に示したように、各パケットは、先頭からＩＰヘッダ、ＴＣＰヘッダ、ペイロードの順で構成されている。ＴＣＰにおいては、複数のパケットを同時または制御情報が変化しない程度の短時間のうちに送信する場合、各パケットに付与されるＴＣＰヘッダの制御情報は全て等しくなる。
一方、本発明では、複数のパケットを同時または制御情報が変化しない程度の短時間のうちに送信する場合、制御情報は先頭のリーダパケット００３用のヘッダのみに格納し、当該本発明のリーダパケット用ヘッダに従来と同様にあて先ノードを示すＩＰヘッダを付加して、ＩＰヘッダと本発明のリーダパケット用ヘッダとからなるリーダパケットをまず送信する。
そして、当該リーダパケット００３に後続して、リーダパケット用ヘッダより情報量の少ない本発明のデータパケット用ヘッダを含むデータパケット００４，００５を送信する。
このように、本発明では、各パケットのヘッダに格納されていた制御情報を先頭のリーダパケット００３のヘッダに格納しており、パケット００３の受信に必要な時間は、従来のパケット００４０の受信に必要な時間より短い。よって、受信ノードでは、当該制御情報（例えば、ＡＣＫ情報等）について従来のパケット転送方法より早期に知ることができる。この結果、当該制御情報に基づくシグナリングを高速に実施することが可能となる。
また、上述の効果は、送信するデータパケットが図１５に記載したように、３つ以上になった場合でも同様である。図１５では、従来の方式において同時または制御情報が変化しない程度の短時間のうちに送信する場合、データパケット００４ａ，００５ａ，００６ａそれぞれに、重複のある、同じデータ量の第４層ヘッダを付与するのに対し、本発明では従来例における各パケットヘッダの重複部分に当たる制御情報を先頭のリーダパケット００３ａのヘッダにまとめて格納し、各データパケットには、ＴＣＰヘッダより軽い本発明のデータパケット用ヘッダを第４層ヘッダとして付与している。
この図１５に示したように、従来多数のパケットで重複して持たれていた情報をリーダパケットに代表して持たせることで、ヘッダによるシグナリングの情報量はＴＣＰと同等に保ちつつ、全パケットのヘッダサイズの合計は、ＴＣＰに比較して減らすことが可能となる。この結果、パケット送信全体の伝送効率を向上させることが可能となる。
また、図１５に示したように多数のパケットについて１つのリーダパケットを作成してパケット送信することによる更なる効果は、経路の速度測定の精度が上昇する点にある。速度は、最低２パケットあれば測定可能であるが、パケットが多ければ多いほど、その制度は上昇する。
その一つの理由は、あるひとつのフローに含まれる多くのパケットを送信した場合、各パケット間にほかのフローに属するパケットが挟み込まれる可能性が高まる。実際の伝送路では、そのようなことは通常起こりえることであるので、パケット数が多ければ多いほど、実際の伝送路に近い状態での速度測定が可能となるからである。
また、もう一つの理由は、パケットブロックに含まれるパケット数が増えると、１つの測定に係わるパケットの先頭と末尾の受信時刻の差が大きくなるため、受信ノードに要求される時間分解能も大きくてよいこととなり、同じ時間分解能のノードであれば、本発明のパケットブロックを使用した方が速度制度が向上することとなるからである。
以上、本発明の概要について説明した。以下に、更に詳細に説明する。
（第１の実施例）
図１に、本発明の第１の実施例を示す。図において、転送ノード１０１と転送ノード１０２の間では、本発明のパケット転送方法を用いてパケットの転送を行う。本実施例は双方向対称のプロトコルを想定するため、転送ノード１０１と転送ノード１０２の構成は同一である。以下、転送ノード１０１から転送ノード１０２へのパケット転送を例に取り説明するが、転送ノード１０２から転送ノード１０１への転送も同様の動作で行われる。
まず転送ノード１０１のパケット送信動作について説明する。転送ノード１０１は、転送ノード１０２に転送すべきデータを、他のノードもしくは同じノード上のユーザアプリケーション等のデータ発生手段から受け取り、バッファ部２０１に収容する。
スケジューリング部２０２は、記憶部２０５に格納されたスケジューリング情報に基づき送信を制御する。例えば、パケット送信を行うべき時刻とリーダパケットに続いて送信するデータパケット（以下、パケット郡と称する）の構成を後述するように決定し、パケット送信を行うべき時刻が来ると、パケットブロック作成部２０３にリーダパケットおよびパケット郡の構成を通知する。リーダパケットおよびパケット郡の構成を通知されたパケットブロック作成部２０３は、データパケットの制御情報をリーダパケットにまとめる。例えば、通知された構成および記憶部２０５に格納されたフロー制御情報に基づきリーダパケットを作成し、またバッファ部２０１から、通知された構成に基づく数のデータを取り出し、取り出したデータの各々に所定のヘッダ情報を付加してパケット群を作成し、パケット群とリーダパケットとを同時または所定の間隔をおいてパケット送信部２０４に渡す。このとき送信されるパケットの集合を以下ではパケットブロックと称する。
パケット送信部２０４はパケットブロック作成部２０３から渡されたパケットを順次、転送ノード１０２内のパケット受信部２０６に対して転送する。３００-１は、パケット送信部２０４から送信された、通信経路上のパケットブロックの模式図であり、リーダパケット３０２に複数のデータパケット３０１が続くことを示している。
次に、転送ノード１０１からのパケットブロック３００-１受信時の転送ノード１０２の動作について説明する。パケット解析部２０７は、パケットブロック３００-１から後述するように所定の情報を抽出するとともに、受信パケットに関する後述するような所定の計測を行い、その結果をフロー制御情報として記憶部２０５に格納する。解析部２０７での処理を終えたパケットのデータは順次パケット転送部２０８に渡され、パケット転送部２０８はパケット解析部２０７から受け取ったデータを次の転送ノード、または同一ノード内のユーザアプリケーション等のデータ受信手段に転送する。
転送ノード１０２内のスケジューリング部２０２は、転送ノード１０１内のスケジューリング部２０２と同様の動作により、記憶部２０５に格納されたスケジューリング情報に基づき、パケット送信を行うべき時刻とパケット郡の構成を後述するように決定し、パケット送信を行うべき時刻が来ると、パケットブロック作成部２０３にリーダパケットおよびパケット郡の構成を通知する。
転送ノード１０２内のパケットブロック作成部２０３は、通知された構成および記憶部２０５に格納されたフロー制御情報に基づきリーダパケットを作成し、バッファ部２０１に格納されたデータとともにパケットブロック３００-２を構成し、パケット送信部２０４を介して転送ノード１０１内のパケット受信部２０６に対し送信する。送信後、送信履歴を記憶部２０５に格納する。
転送ノード１０２から新しいパケットブロック３００-２を受信すると、転送ノード１０１内のパケット解析部２０７はパケットブロック３００-２から所定の情報を抽出するとともに、受信パケットに関する所定の計測を行い、その結果をフロー制御情報として記憶部２０５に格納し、フロー制御情報が更新されたことをスケジューリング部２０２に通知する。スケジューリング部２０２は、更新されたフロー制御情報に基づき、同様に記憶部２０５に格納されたスケジューリング情報を更新する。以降のパケット送信タイミングおよびパケットブロック構成の決定は、更新したスケジューリング情報に基づき行われる。
図２に、本発明で用いるリーダパケットの構造の例を示す。本発明はいかなる通信レイヤ上のプロトコルとしても実施可能であるが、本実施例では第４層のプロトコルとして実装するものとし、下位層の転送プロトコルがＩＰである場合の構造例を示している
図２に示されるように、本実施例におけるリーダパケットには、先頭のＩＰヘッダに続くブロック管理情報、フロー制御情報がリーダパケット用ヘッダに含まれる。一方データパケットの構造は図３に示され、ＩＰヘッダ以外にデータパケット用ヘッダにブロック被管理情報を、ペイロードにデータ本体を含む。
ブロック管理情報は、送信側ノードが生成する、パケットブロック内パケットのパケット数やパケットの優先度等の属性情報である。一方ブロック被管理情報は、リーダパケットを一意に識別する識別情報である。即ち、各データパケットが属するパケットブロックを識別するための情報である。本実施例では、送信ノードは各パケットブロックにユニークなシーケンス番号を付与するものとし、これをブロック被管理情報とする。またブロック内の各パケットは、リーダパケットを先頭として順次送信される（パケットブロック作成部２０３からパケット送信部２０４に渡される）ものとし、その送信時のタイムスタンプと、パケットブロックに属するパケットのシーケンス番号の範囲をブロック管理情報とする。これらの情報をもとに、受信ノードでは遅延の測定及び非特許文献に記載されているパケットトレイン方式（総データ量／最後のパケットと最初のパケットとの受信時刻の差 から帯域推定を行う方式）による通信経路の帯域推定を行う。
また、制御情報をまとめたデータパケットを一意に識別する識別情報をリーダパケットに含めることで、リーダパケットとデータパケット郡との関係を担保しても良い。
以上の前提に基づき、再び図１を参照して、本実施例のフロー制御の機構を具体的に説明する。転送ノード１０２内のパケット解析部２０７は、パケット受信部２０６よりパケットブロック３００−１のリーダパケット３０２を受信すると、ブロック管理情報よりパケットブロック３００−１のタイムスタンプとシーケンス番号の範囲を抽出する。また受信時刻と抽出したタイムスタンプの差を、経路遅延の推定結果として記憶部２０５に書き込む。後続のデータパケット３０１の受信時に、シーケンス番号がパケットブロック３００−１のシーケンス番号範囲内であったらそのデータサイズを記憶しておく。また受信したパケットがブロック内で最後に受信されるパケットであったら、受信されたパケットブロック内データパケットのパケットサイズの総計を、当該パケットの受信時刻とリーダパケットの受信時刻の差で割ったものを、通信経路の帯域の推定結果として記憶部２０５に書き込む。
以上の動作により転送ノード１０２内のパケット解析部２０７が記憶部２０５に記録したフロー制御情報（経路遅延の推定結果と経路帯域の推定結果）は、転送ノード１０２から転送ノード１０１に送信するパケットブロック３００-２のリーダパケットに収容され、転送ノード１０１内のパケット解析部２０７を介して記憶部２０５に届けられる。転送ノード１０１内の記憶部２０５は新たなフロー制御情報が届けられると、フロー制御情報更新をスケジューリング部２０２に通知し、該通知を受けたスケジューリング部２０２は、更新されたフロー制御情報、すなわち経路遅延の推定結果と経路帯域の推定結果とを用いて、スケジューリング情報を更新し、以降は更新したスケジューリング情報に基づきパケットブロックが構成される。
以上、第１の実施例におけるパケットブロック転送方式を実装したノードの構成と動作の例について説明した。以下では、図１においてパケットブロックの送信タイミングを決定するスケジューリング部２０２と、パケットブロックの構成を決定するパケットブロック作成部２０３が従うフロー制御アルゴリズムの例について説明する。
フロー制御アルゴリズムの第１の例として、ＴＣＰで用いられているウィンドウ制御を応用し、ウィンドウサイズをパケットトレイン方式により推定した経路帯域に基づき決定するフロー制御アルゴリズムにつき説明する。この実施例では、転送ノード１０２から転送ノード１０１に送信するリーダパケット３０２にはＴＣＰで用いられるのと同様なＡｃｋ情報、受信ウィンドウサイズ（受信ノード側で決定した受診可能なデータ量）を含める。このリーダパケット３０２を受信した転送ノード１０１は以下の手順で転送ノード１０２への送信処理を行う。リーダパケット３０２を受信したら、パケット解析部２０７は該リーダパケット３０２に含まれるＡｃｋ内容を記憶部２０５に記録し、記憶部２０５は新規Ａｃｋ受信イベントをスケジューリング部２０２に通知する。
スケジューリング部２０２は受信したリーダパケットから抽出した受信ウィンドウサイズと、記憶部に記録されている送信履歴より抽出した、Ａｃｋされたパケットの後に送信したパケットのデータ量の差を送信可能データ量としてパケットブロック生成部２０３に通知する。
パケットブロック生成部２０３はリーダパケット３０２を含むパケットブロックサイズが送信可能データ量を超えないような最大量のデータをバッファ部から取り出し、各データにブロック被管理情報を付加したデータパケットを作成する。また、Ａｃｋ情報およびブロック管理情報を含むリーダパケットを作成し、両者からなるパケットブロックをパケット送信部２０４に渡す。もし送信可能データ量が、予め定めた下限に満たない場合は、次のスケジューリング部２０２からの送信可能データ量通知までパケットブロック作成を保留する。
パケットブロックを送信できた場合、送信履歴を記憶部２０５に記録する。ここで転送ノード１０１が用いた受信ウィンドウサイズは、転送ノード１０２のパケット解析部２０７が、転送ノード１０１からのパケットブロックを受信した時に推定した経路速度より決めている。受信ウィンドウサイズの値は、例えば、予め定めた最大往復遅延と推定速度の積で与えられる。
さらに、受信バッファ残量などに基づく上限を別途設け、この上限未満であれば、受信ウィンドウサイズの決定に推定速度に基づく値を用いるようにしてもよい。
以上説明した、速度推定結果を援用したウィンドウ制御を用い、従来複数のパケットで重複して持たれていた情報をリーダパケットに代表して持たせることで、ノード処理負荷軽減やヘッダサイズ低減の効果が得られる。また、これに加え、下記の効果が生じる。まず、往路と復路の経路速度差によらず往復遅延時間が、予め定めた最大往復遅延時間以下になるよう制御するため、速度変動のある経路では従来のウィンドウ制御に比べ遅延の分散を低減する効果がある。またウィンドウサイズが速度推定結果を用いて直接求められるため、損失や遅延変動が大きい経路上でも帯域を有効活用できる特徴がある。この点は、非特許文献１、９と比較し有利な点である。すなわち、非特許文献１、９では、送信側の輻輳ウィンドウサイズと受信ウィンドウサイズの小さいほうをウィンドウサイズとして採用していることから、パケットロスが発生した場合にウィンドウサイズを小さくする制御をしてしまう。これに対し、本発明では、パケットロスが発生した場合であっても、速度推定結果を用いてウィンドウサイズを決定しているためウィンドウサイズ自体には影響がないので、対域の有効活用が可能となる。
なおリーダパケットには受信ウィンドウサイズではなく速度推定結果を含め、ウィンドウサイズの計算は送信側のノードのパケット解析部２０７が行ってもよい。さらに、リーダパケット受信時に計算した送信可能なデータ量を同時に全て送るのではなく、複数のパケットブロックに分割し、推定速度から決まる送信間隔をおいて送信してもよい。ただし、このときの送信間隔は、先に送信したパケットブロックと後から送信したパケットブロックが経路上で接触するような間隔である必要がある。また、このようにパケットブロックを分割して送信することにより、経路に送出されるバーストのサイズが小さくなるため、パケットロス確率低下の効果が期待できる。
フロー制御アルゴリズムの第２の例として、非特許文献６で公開されているＰＡＣスケジューラの方法を応用した方法について説明する。送信ノードにおけるＰＡＣスケジューラの基本動作は、受信ノードからフィードバックされた遅延と推定速度、およびそれらの経路状態の測定に用いたパケット以降の送信履歴をもとに現状の経路遅延を予測し、この予測遅延が予め定めた閾値未満となる時刻に次のパケットを送信する。これをパケットブロック転送方式に応用した場合のフロー制御プロトコル動作例を図４を用いて説明する。
図４において、「１０１時刻」数直線は転送ノード１０１上の時刻、「１０２時刻」数直線は転送ノード１０２上の時刻を表す。またノード１０２上の時刻T以降では、T以前より経路の帯域が低下したと仮定している。転送ノード１０１は、時刻ts(a)にパケットブロック３００-aを送信しており、その先頭は時刻tb(a)に転送ノード１０２に届いている。tb(a)は無負荷時にパケットブロック３００-aの先頭が受信ノードに届く時刻を意味する。
つまりノード１０１においてts(a)以前には負荷がないので、パケットブロック３００-aの先頭は無負荷時の遅延のみでノード１０２に届く。ノード１０２ではリーダパケット３０２-a、データパケット３０１-１の受信時刻から計算した推定速度およびリーダパケット３０２-aに搭載されたタイムスタンプと転送ノード１０２の受信時刻から推定した遅延の情報とを、ts(f)に転送ノード１０２から転送ノード１０１に送信するパケットブロック３００-fのリーダパケット３０２-fに収容することでノード１０１に通知する。
ノード１０１はパケットブロック３００-aに続き、経路の帯域が一定とみなしてパケットブロック３００-bを送信している。パケットブロック３００-bを送信後に３０２-fの受信により経路情報（推定速度および遅延）を更新するが、これは時刻T以前の情報であるのでノード１０１は経路帯域が依然３００-a送信時と同じく無負荷状態と判断して時刻ts(c)にパケットブロック３００-cを送信する。このときノード１０１は、以下の方法で時刻ts(c)を決定する。すなわち、受信したパケット３０２-fに含まれる経路情報（推定速度および遅延）、および、その経路情報の測定に使われたパケットブロック３００-a以降の送信履歴から求めた、パケットブロック３００-cの先頭が受信されると予測される時刻tf(c)を、無負荷時予測到着時刻tb(c)に、閾値thを加えた値と同じか又は早い時刻として決定している。
ここで無負荷時予測到着時刻tb(c)とは、ts(c)の時点で通信経路が無負荷としてパケットを送信した場合にその先頭が受信ノード１０２に到着する予測時刻である。したがってts(c)の時点でノード１０１は、パケットブロック３００-cの先頭がtb(c)+thに届くと予想している。またパケットブロック３００-cのサイズは、末尾の予測到着時刻が、tb(c)に最大余剰遅延toを加えたtb(c)+toまでに収まるよう決定されている。
また、最大余剰遅延とは、これ以上の遅延が予測される経路からはパケット送信をしないとする閾値を示している。即ち「最大余剰遅延がto」のときには、送信側ノードがパケットpを経路rから送信する際の予測到着時刻が送信時刻−to以降となる送信時刻になるまではパケットpの経路rを用いた送信をしない。逆に、予測到着時刻＜現在時刻−toである経路からは、パケットを即時に送信可能である。
しかし本実施形態では、実際には経路帯域は時刻Tを境に小さくなっているので、パケットブロック３００-bの伝播遅延はノード１０１の予測より大きく、パケットブロック３００-cの受信開始はtf’(c)まで遅れ、また末尾のデータパケット３０１-９の受信完了時刻も予測したtb(c)+toより遅れて、tf’(d)となっている。ノード１０２はts(g)にパケットブロック３００-gを送信しており、このリーダパケット３０２-gにはパケットブロック３００-b受信により検出した、経路情報（即ち、経路帯域が低下した情報）が含まれる。このようにノード１０１はパケット３０２-gの受信により、経路帯域の低下を知るので、それに合わせて経路情報を更新し、更新以前にはts(d)に送信予定だった次のパケットブロック３００-dの送信時刻をts’(d)に変更する。またノード１０１から１０２へ送信するパケットブロックのサイズも３００-b,
３００-cに比べ小さく変更している。
以上の判断は、更新された経路情報および送信履歴を用いて求めた、ブロック先頭の予測到着遅延tf(d)が、tb(d)+th以下となり、また末尾の予測到着時刻がtb(d)+to以下になるよう送信時刻とブロックサイズを計算した結果である。実際にはts(g)以降tf(d)までの間にも経路状態は変動するので、図では実際に先頭が届く時間tf’(d)はtf(d)とずれている。
このずれも、次の測定結果のフィードバックにより以降のパケットブロックの送信スケジューリングに反映される。以上のような動作により、ＰＡＣスケジューラは予測到着時刻のずれを修正するよう送信タイミング制御を行い、帯域の有効利用と遅延抑制の両立を図る。先に説明したウィンドウ制御は往復遅延に対する制御を提供するが、ＰＡＣスケジューラではさらに、経路の片道ごとの遅延を個別に測定、フードバックするため、往路と復路の状態が異なる経路において、各々に適した制御ができるメリットがある。例えば往路の帯域が現状の負荷に対して大きく、復路の帯域が逆に現状の負荷に対して小さい場合に、復路の遅延の増大のみが増大する。このとき往復遅延に基づく制御を行っていると往路、復路ともの送信側ノードが当該経路への負荷を減らすので、結果として、往路の帯域を有効に活用できなくなる。ところがこのとき往路と復路の遅延を別個に監視していれば、往路の負荷軽減が必要ないことが分かるので、往路の帯域を有効に活用できる。
上記フロー制御プロトコルの動作を実現するためにスケジューリング部２０２が従うフローチャートを図５に、パケットブロック作成部２０３が従うフローチャートを図６に示す。スケジューリング部２０２は記憶部２０５の記憶内容の更新の度に次にパケットブロックを送信可能とする時刻とブロックサイズを決定してパケットブロック作成部２０３に通知する。
まず、図５について具体的に説明する。Ｓ５１の処理では、記憶部２０５より、経路状態情報またはパケット送信履歴情報の更新がされるとそれらの通知を受ける。次に、最新の送信経路状態情報と、該送信経路状態情報が有効となる送信済みパケット以降の送信履歴より、つぎに送信するパケットの先頭の到着予測時刻が無負荷時の到着予測時刻(tb)に閾値(th)を加えた時刻と等しくなるように、次のパケット送信時刻(tf)を計算する（Ｓ５２）。次に、最新の送信経路状態情報から、最大余剰遅延toの伝播遅延をもたらすと予測されるデータ量(d)を計算する（Ｓ５３）。そして、以上で求めたパケット送信時刻(tf)およびデータ量(d)をパケットブロック作成部２０３に通知(Ｓ５４)して処理を終了する。
パケットブロック作成部２０３は、バッファ部２０１にデータがあり、かつパケットブロックが送信可能である場合に、スケジューリング部２０２から通知されたブロックサイズ以内のサイズのパケットブロックを構成してパケット送信部２０４に渡す。
図６では、起点となる状態がwaitとidleの２種類あるが、これは「送信可能となる時刻になってからパケットブロックを送信する」処理がタイマの援用により実現されているためである。このタイマの満了を待つ間はスケジューリング部２０２はwait状態に留まる。一方idle状態は、タイマを待ってもいないし、処理すべきデータも受信していない状態である。
以下、図６について説明する。
まず、idle状態時について説明する。この状態においては、「バッファ部２０１より新規パケット受信通知を受信」した場合(Ｓ６１)、または、「スケジューリング部２０２から、パケット送信時刻(tf)およびデータ量(d)の更新通知を受信」した場合(Ｓ６２)に処理が開始される。処理が開始されるとまずパケット送信時刻(tf)≦現在を判断する(Ｓ６３)。この判断の結果がNoであれば、時刻tfに満了するようにタイマを起動し処理を終了し(Ｓ６４)、wait状態となる。また、Ｓ６３の判断の結果がYesの場合、最新の受信経路状態情報およびＡｃｋ情報を含むリーダパケットを作成する(Ｓ６５)。次に、バッファの先頭からパケットブロックサイズがデータ量(d)以下となる最大量のデータをバッファ部２０１から取り出してデータパケット郡を作成する(Ｓ６６)。次に、リーダパケットおよびデータパケット郡をパケット送信部２０４に送信する(Ｓ６７)。次に、送信記録を記憶部２０５に書き込み(Ｓ６８)処理を終了しidle状態に戻る。
次に、wait状態時について説明する。Wait状態時にスケジューリング部２０２から、パケット送信時刻(tf)およびデータ量(d)の更新通知を受信」した場合(Ｓ７１)の処理は上記idle状態時にスケジューリング部２０２から、パケット送信時刻(tf)およびデータ量(d)の更新通知を受信した場合の処理と同じである。
また、wait状態時に、送信タイマが満了した場合の処理は、上記idle時のＳ６５〜Ｓ６８の処理と同じ処理を行う。
なお、以上のアルゴリズムの説明において、記憶部２０５の記憶内容が更新された際のスケジューリング部２０２への通知は記憶部が行っているが、これをパケット解析部２０７、パケットブロック作成部２０３またはパケット送信部２０４が行っても同様な動作が実現される。
上記ＰＡＣスケジューリングを実施した場合、tb(a)等を求めるために無負荷時の経路遅延の知識が必要になる。これは予め計測しておき定数として扱うこともできるが、経路状態や時計のドリフト等の影響を避けるために更新したい場合、次のような手順で通信中にこれを行うことができる。まず、受信側ノードのパケット解析部２０７において、あるパケットブロックAの末尾の受信時刻から次のパケットブロックBの先頭の受信時刻の間に間隔があるとき、経路には余裕があり、パケットブロックBの先頭パケットは無負荷状態で到着したと考えられる。
図４の例では、パケットブロック３００-bのリーダパケット３０２-bは直前のパケットブロック３００-aの末尾の受信時から間隔を置いて受信しているので、無負荷状態で到着している。このような間隔を検出したときに、転送ノード１０２はパケット３０２-bが無負荷で到着したことを示す情報を送信ノード宛のリーダパケット３０２-gに含めることで、無負荷遅延検出を転送ノード１０１に伝える。
リーダパケット３０２-gを受信した転送ノード１０１は、無負荷時の経路遅延値を３０２-bの遅延に更新する。
また、ＰＡＣスケジューラを用いる場合には、定期的に無負荷遅延値を用いる。このため、一定時間以上無負荷遅延が検出されなかった場合には、ブロック送信閾値となる余剰遅延thを負の値とすることで、強制的に無負荷での転送を誘発するようにすれば、一定時間以内の周期での負荷時経路遅延値が実現できる。そのために、th<０として経路に全く負荷がかかっていない状態でしか、データが送信できないような状態を作り出している。
以上説明したように、転送ノード１０１および１０２内の構成要素各々の動作により、通信経路の遅延及び速度の監視結果をフィードバックし、パケット流量制御を行うので、本発明では、経路情報（推定速度および遅延）を考慮したパケット送信が可能となる。また、このようにシグナリング情報をリーダパケットに集約して通信しているために、受信側でのフロー制御情報の抽出、送信側でのスケジューリング情報の更新ともに、従来例のようにパケット送受信と同じ頻度で行うのではなく、パケットブロック送受信の頻度で行うので、転送ノードの処理負荷が軽減される。
また一つのパケットブロックに含まれるパケット数が一定以上であれば、シグナリング情報をデータパケットから省略し、リーダパケットに集約する分、同じデータ量に対して従来例に比べパケットサイズの合計を低く抑えられる効果がある。さらにパケットトレイン方式による高精度な経路帯域推定を、速度測定のためにのみ用いられる専用プローブパケット（ダミーパケット）等を用いて帯域利用効率を損なうことなく行うことができる。
なお、以上の説明では速度測定の有効性を最大化するために、同一パケットブロック内のパケットは同時に送信しているが、本発明の実施としては、同時ではなく、ボトルネック帯域よりも高いレートで複数のパケットを一定の送信速度で送信してもよい。受信側で計測されるパケットの分散はボトルネック帯域を反映するので、帯域推定が可能だからである。
その場合には、経路のボトルネック帯域が送信速度以上であると推定速度が得られないが、例えばある特定の速度を必要とするアプリケーションが、経路がその速度以上で転送可能か否かを判断することはできる。理由は、受信レートが送信レートより低い場合には経路の速度により転送レートが制限されていることになり、速度が測定できるからである。また、そうでなくても、経路速度が送信レート以上であることは分かるからである（経路上、送信レートよりも低いレートのリンクが存在しないため）。送信速度を一定以下に保つことで、同時に送信する場合に比べ経路に加わる負荷を抑えられるために、過剰負荷によるパケット損失の可能性を低下させることができる。
以上説明した第１の実施例ではフロー制御情報として経路遅延及び帯域の監視情報（経路情報）のみを含めていたが、その他に受信確認情報などを含めてもよい。例えばリーダパケットの受信確認と、対応するパケットブロック内で受信できていないデータパケットの識別情報（再送制御情報）を含めると、送信側が再送すべきパケットを正確に同定することができる。
リーダパケットが損失している場合には、例えばリーダパケットの損失を示す情報と、ＴＣＰで用いられるのと同様な、シーケンス番号に基づくＡｃｋ情報を併用することで送信の完全性が保たれる。例えば、リーダパケットにもシーケンス番号を付与し、受信側がＡｃｋ情報を返すようにすれば、Ａｃｋされていないパケットを送信側が再送することで、リーダパケット、データパケットともに無損失の転送を保障できる。
また第１の実施例ではリーダパケットは単一としているが、冗長性のために複数にしても構わない。その際同一のパケットのクローンを作成してもよいし、複数のリーダパケットを合わせてブロック全体のブロック制御情報がカバーされるようにしてもよい。
また本発明におけるリーダパケットは、パケットブロックが複数のデータパケットから成る場合にはデータ本体を含んでいてもよく、またブロック管理情報がブロック内パケットを識別するのに既存の識別子、例えばＩＰヘッダ内のIdentificationフィールドを用いる場合には、データパケットにブロック被管理情報は不要である。
また、これらの「リーダパケットがユーザデータを含まない」「データパケットはブロック費管理情報を含む」という限定を除いても、本発明の特徴である、リーダパケットにブロック内パケットおよびそれらからのフロー制御情報生成方法を同定できる情報を付与すること、また受信側ノードで、受信パケットが所属するパケットブロックに応じたフロー制御情報の生成を行うことは可能であるためである。
なお、上述の制御情報は、ルーティング情報であってもよい。
また送信されるパケット全てがいずれかのパケットブロックに属する必要はなく、例えば定期的な回線監視を行うときのみパケットブロックを構成して送信し、監視結果を得た後は次の監視時刻までの間は各データパケットを単独で送信してもよい。
（第２の実施例）
次に本発明の第２の実施例について説明する。図７に、本実施例で用いられる転送ノード１０１および１０２の構成を示す。転送ノード１０１の構成は第１の実施例で用いた図１のものと同様であるが、転送ノード１０２は複数のパケット受信部２０６およびパケット送信部２０４を有している。転送ノード１０１と１０２の間にあるＩＰ網４００は、転送ノード１０１のパケット送信部２０４から転送ノード１０２のパケット受信部２０６-１への経路と、パケット受信部２０６-２への経路を与え、それぞれの経路は一般に物理的に離れたリンクを含み、帯域や遅延は互いに独立に変動するものとする。同様に、転送ノード１０２のパケット送信部２０６-１から転送ノード１０１のパケット受信部２０４への経路と、パケット受信部２０４-２からの経路の帯域や遅延も、互いに独立に変動するものとする。
本実施例は以上のような、２ノード間に複数の選択可能な経路がある場合への本発明の適用例である。本実施例のパケット構造およびフロー制御のためのシグナリング機構は、第１の実施例と同様であるが、フロー制御情報およびスケジューリング情報の内容、およびパケットブロックの構成が第１の実施例と異なる。
本実施例でのパケットブロックは、複数の経路の各々に送出されるデータパケットと、１つ以上のリーダパケットからなる。シーケンス番号は経路ごとに与えられるものとし、リーダパケットはブロック管理情報としてタイムスタンプと、経路ごとのパケットブロック内パケットのシーケンス番号範囲を含む。パケット解析部２０７による遅延及び速度の推定も、経路ごとに行われる。同様にリーダパケット上のフロー制御情報も、経路ごとの遅延及び速度推定結果を含む。
図７に示されるパケットブロック３００-１および３００―２は、選択可能な経路が２つで、リーダパケットが１つの場合の例である。パケットブロック作成部２０３は複数経路に対して１つのパケットブロックの作成を行い、パケット送信部２０４はブロック内の各パケットにつき、パケットブロック作成部２０３が指示した経路を経由して送出する。
パケットトレイン方式による経路帯域推定は当該経路に２つ以上のパケットが同時または該経路のボトルネック帯域以上の送信速度で送信されたときに可能となるので、帯域推定を可能とするためには１つのパケットブロックにつき各経路から２つ以上のパケットが送信される必要がある。このためパケットブロック構成の結果送信パケットが１つになった経路に対しては、送信対象のパケットとともにダミーパケットを送信する。このダミーパケットの内容は、例えばシーケンス番号だけでよい。
本実施例で用いるフロー制御アルゴリズムとしては、第１の実施例で用いるフロー制御アルゴリズムの例として挙げたものを拡張して適用することができる。
第１の実施例における第１のフロー制御アルゴリズムの例として説明したウィンドウ制御方式は、第２の実施例においては以下のように拡張される。リーダパケットには全経路のＡｃｋ情報および受信ウィンドウサイズを含める。リーダパケットを受信した転送ノードのスケジューリング部２０２は、各経路の送信可能データ量を後に示すように計算してパケットブロック生成部２０３に通知する。
パケットブロック生成部２０３は、パケットブロックの各経路部分が送信可能データ量を超えないようにバッファ部のデータを取り出し、各経路への割り当てを決定する。
ただし送信可能データ量が、予め定めた下限に満たない経路に対しては、データの割り当てを行わない。リーダパケットは、最も送信可能データ量が大きい経路に割り当てる。同じリーダパケットを、冗長化のために他の経路にも割り当ててもよい。
また、リーダおよびデータ合わせて１パケットしか割り当てられない経路に対しては、併せてダミーパケットを割り当てる。ブロック内の各パケットに対する割り当て経路が決定したら、割り当て情報とともに全てのブロック内パケットをパケット送信部２０４に渡す。
パケット送信部２０４に渡したパケットの情報は送信履歴として記憶部に記録する。受信側ノードにおける受信ウィンドウサイズの決定は、第１の実施例におけるのと同様に行われる。
第１の実施例における第２のフロー制御アルゴリズムの例として説明したＰＡＣスケジューラ方式は、第２の実施例においては以下のように拡張される。２つの経路を含む場合の動作を、図８を用いて説明する。図８には、２つの経路に対応して２本の時刻数直線があり、それぞれ各経路を経由したパケットの到着予測シーケンスが示されている。
n番目の経路の対し、tb、tf、th、toはそれぞれtb(n)、tf(n)、th(n)、to(n)と示されており、それぞれの意味は図４におけるものと同じであるが、示されているパケットが実際の到着シーケンスではなく、送信側ノードが予測した到着シーケンスである点が異なる。送信側ノードは、いずれかの経路について、tb(n)+th(n) < tf(n)であればパケットブロック送信可能とする。図８では、tb(１)+th(１) < tf(１)であるので、即座に送信可能である。
スケジューリング部２０２は、リーダパケット３０２の到着予測時刻を各経路について計算し、最も早く到着すると予測される経路にリーダパケット３０２を送信するようパケットブロックを構成する。図８では、リーダパケット送信経路として経路２が選ばれている。
次にバッファ部２０１にある最初のパケット３０１-１のデータサイズを取得し、リーダパケットと合わせて送信した場合に最も早く到着すると予測される経路に配する。図８では、最初のデータパケット３０１-１は経路１に配されている。以下１つずつブロック内パケットを増やして同様に配置し、どの経路についても、送信されるパケットサイズの和がtb(n)+to(n)以下となるような最大の送信パケット数が求まったところでパケットブロックの構成が決定する。
図８では、経路１と２合わせて５つのデータパケット３０１-１から３０１-５を含むパケットブロック３００を構成している。
以上説明した、拡張されたウィンドウ制御およびＰＡＣスケジューリングでは、リーダパケットを最も低遅延と予測される経路から送信することで、より遅延の大きい経路に関するフロー制御情報の通知も、最も低遅延な経路と同等の遅延で行うことができる。
しかし受信ノードにおけるパケット受信から、その受信状態に基づき生成したフロー制御情報が送信ノードに通知されるまでにかかる時間には、フロー制御情報の伝送遅延のみでなく、パケット受信からフロー制御情報の送信までの待機時間が含まれる。この待機時間は、最大でブロック送信間隔となるので、ノード処理負荷軽減、パケットトレイン方式での経路帯域推定の精度や、帯域の有効活用のために経路上にバッファするデータ量を一定以上に保つなどの目的でブロックあたりの各経路への割当量を大きくすると、フロー制御情報フィードバック遅延の増大をもたらす。
以下では、同等な遅延の経路が複数存在する場合に、各経路のブロックあたりのデータ量を一定以上に保ちつつ、フロー制御情報送信までの待機時間も低減するための第３のフロー制御アルゴリズムについて、図９を参照して説明する。
図９では、図４と同様、「１０１時刻」数直線は転送ノード１０１上の時刻、「１０２時刻」数直線は転送ノード１０２上の時刻を表す。ただし転送ノード１０１と転送ノード１０２の間には経路１と経路２の２つの経路があるものとし、それぞれの経路を経由したパケットについて、転送ノード１０１による、転送ノード１０２上での受信シーケンスの予測を「経路１受信予測」および「経路２受信予測」線上に示している。
各パケットブロックは基本的に１つの経路のみで構成する。各経路のパケットブロックのブロックサイズは、ブロック内パケットの伝送遅延が一定、即ち、どの経路のブロックも(ブロックに含まれるパケットサイズの合計/経路の速度)が同じになるように定められる。その上で各パケットブロックは、ブロック内パケットの伝送遅延／シグナリングに使用可能な経路数で定義されるブロック送信周期tiだけずらして送信され、これがリーダパケット送信の周期となる。
すると図９に示されるように、経路１を用いるパケットブロックと経路２を用いるパケットブロックの到着は交互となる。このようにパケットブロック送信をスケジューリングすることで、速度推定に使われるパケットトレインの長さに比べリーダパケットの送信間隔（フィードバック周期）を短くすることができる。
これは、第１の実施例のように１つの経路のみを用いてパケットブロックを送信する場合には、リーダパケットの到着間隔は、パケットトレインの長さとほぼ等しいのに対し、図９に記載のように複数の経路を用いてパケットブロックを送信する場合は、リーダパケットの到着は、パケットトレインの長さより短いtiの間隔で受信可能となるからである。
経路状態が変動する場合には必ずしも図９のように定期的なレポートの到着が保障されない。例えば時刻tf(a)と時刻tf(c)の間で経路１の速度が低下すれば、リーダパケット３０２-cの到着はtf(c)よりも遅くなる。このような場合には、ノード１０１はts(f)またはts(g)にノード１０２より送信されたリーダパケットの情報により速度変化を検知し、ts(d)に送信されるパケットブロック３００-dのデータ量を、ノード１０２において先頭から末尾までの受信にかかる時間（受信完了時間）がti程度以下になるよう調節する。また３００-dの次に送信するパケットブロックも、受信完了時間がti程度以下となるサイズとして、経路２から送信する。以降、経路１が送信可能な状態、つまりtb+th < tfとなるまでは、経路２からのみ受信完了時間がti程度以下となるサイズのパケットブロックを送信する。以上のようにして、経路状態の変化により経路１の遅延が大きくなっている状態においても、リーダパケットの送受信周期をti程度以下に保つことができる。
逆に例えば時刻tf(a)と時刻tf(c)の間で経路１の速度が上昇すると、リーダパケット３０２-cの到着はtf(c)よりも早くなる。このような場合には、ノード１０１が速度変化をts(c)とts(d)の間で検知し、次の経路１経由のリーダパケットの到着予定時刻tf(e)までの間に到着可能なデータ量だけ経路１経由のパケットを、ts(d) に送信されるパケットブロック３００-dに加える。このときパケットブロック３００-dは経路１，２双方のパケットを含む。３００-e以降のパケットブロック送信に関しては、ブロックサイズを新たな速度に対し伝送遅延がtiの使用可能経路数倍以内となるよう再決定する。このとき、リーダパケット到着間隔は速度変化前と同様にti以内に保たれる。一方、パケットブロックに占めるリーダパケットのデータ量の割合は小さくなるため、帯域利用効率は向上する。
以上説明した第２の実施例によれば、各通信経路の遅延及び速度の監視結果を反映した各経路への負荷分散が可能となる。
本発明は送信側での送信タイミングの決定および送信経路の決定を、従来例のように単一パケットまたはパケットペアごとに行うのではなく、パケットブロック単位で行うので、パケットブロックのデータ量を大きくすると転送ノードの送信処理にかかる負荷が軽減される。
またシグナリング情報をリーダパケットに集約したために、受信側でのフロー制御情報の抽出、スケジューリング情報の更新ともに、従来例のようにパケット送信と同じ頻度で行うのではなく、パケットブロック送信の頻度で行うことになるので、転送ノードの受信処理にかかる負荷が軽減される。
また、シグナリング情報が集約されたリーダパケットを最も早く到着する経路からパケットブロックの先頭として送出することで、遅延の大きい経路の状態情報を、当該遅延の大きい経路自身を用いてフィードバックする場合に比べ短時間でフィードバックできる効果がある。また各経路のパケットブロックに含まれるパケット数が一定以上であれば、シグナリング情報をデータパケットから省略する分、同じデータ量に対して従来例に比べパケットサイズの合計を低く抑えられる効果がある。
さらに上記第２の実施例におけるように、パケットトレイン方式による高精度な経路帯域推定を、専用プローブパケット等を用いて帯域利用効率を損なうことなく、行うことができる。
以上では、主に転送すべきデータが多い、高負荷の状態での動作を説明している。低負荷の時には、送るべきデータがバッファ部にないので、定期的にダミーパケットなどを送信して回線の状態を監視する必要がある。
その場合、単一パケットブロックに含まれるパケット数が小さくなるため、速度推定の精度が高負荷時に比べ不足する。このような場合にも、連続するパケットブロックに含まれるパケットを連結して考えることで、速度推定精度を一定以上に保つことができる。図１０を参照して説明する。図中、３つのパケットブロック３００-a、３００-b、３００-cに属するパケットがある経路上で受信されており、先行するパケットブロックの末尾と次のパケットブロックの先頭の間には何も受信されていない時間がある。
このような場合、受信速度の推定は、パケットブロック３００-bに含まれるデータパケット３０１-２、３０１-３が３０１-１の直後に受信されたと仮定して行う。また同様に、パケットブロック３００-cに含まれるデータパケット３０１-４は３０１-３の直後に受信されたと仮定する。すると、パケットブロック４００のような仮想パケットブロックが構成される。このとき、データパケット３０１-２、３０１-３の受信に要した時間はパケットブロック３００-bの受信時に測定したパケット３０２-bとパケット３０１-３の受信時間差を、またデータパケット３０１-４の受信に要した時間はパケットブロック３００-cの受信時に測定したパケット３０２-cとパケット３０１-４の受信時間差を用いる。そして仮想パケットブロック４００のデータパケット受信に要した時間は、３００-a、３００-b、３００-cの受信時に測定したデータパケットの受信所要時間の合計とする。受信速度は、仮想パケットブロック４００のデータパケット受信に要した時間で３０１-１から３０１-４までの４つのデータパケットのデータ量の合計を割った値と推定する。
リーダも含め５つのパケットから成る仮想パケットブロック４００を用いて速度推定を行うことで、より構成パケット数が少ないパケットブロック３００-a、３００-b、３００-cに比べ測定精度向上の効果が期待できる。
（第３の実施例）
以下では、リーダパケットのブロック管理情報として含める情報により新たな機能を実現する実施例について説明する。図１１は，本発明の第３の実施例として、ブロック管理情報５００に、送信側ノードが予測した各リンクの速度と、ブロック内データのサイズを含めて、通信異常の早期検出を可能とする動作の概略を示している。
図１１は、ある経路につきシーケンス番号１から６のパケットを含むパケットブロックを、当該リンクの速度が３５０Kbpsと推定した場合に第３の実施例において送信されるブロック管理情報と、受信側ノードにおけるデータパケット受信タイミングの関係を示している。図１１下部の時刻の数直線は、受信ノードにおける実際のパケット到着シーケンスを示す。
受信ノードは、パケット２までは送信ノードの予測通りの速度で届いているので何もしないが、パケット３で到着間隔の伸びを検出し、送信側の予測速度と実際の転送速度のずれが生じたことを認識する。ずれが一定以上と判断したところで異常レポートを作成し返信することで、送信ノードがリンク状態を誤認識している時間を最小限にでき、フロー制御動作の追従性が向上する。
（第４の実施例）
次に、ユーザフロー単位でのパケットロスの早期検出を可能とする第４の実施例について説明する。
図１２は、本発明の第４の実施例におけるブロック管理情報と、受信側ノードでのデータパケット受信シーケンスの例を示している。ブロック管理情報５００には、ブロック内各パケットのユーザフロー情報が含まれている。ここでユーザフローとは、パケットの到着順序を保存する対象となる、エンドホスト間パケット転送セッションを指し、各ユーザフローにはユニークなIDが付与されているものとする。
またユーザフロー内の各パケットには、ユーザフロー内でユニークなシーケンス番号が、経路ごとのシーケンス番号とは別に付与されているものとする。図では、送信ノードはある経路につき４から１１までのシーケンス番号のパケットを含むパケットブロックに、２０４９と２０５０という２つのユーザフローが含まれている。図１２下部の時刻の数直線は、受信ノードにおける実際のパケット到着シーケンスを示す。
図１２の例では、送信した結果、パケット５とパケット６が損失するが、パケット７の受信により損失は検出される。また損失したパケット５と６がそれぞれフロー２０４９の＃１４とフロー２０５０の＃４１であることがフロー管理情報５００により分かるので、それまでに到着したこれら２つのフローに属するパケットは、損失パケットの到着を待たずに転送される。
経路ごとおよびユーザフローごとに別個のシーケンス番号を付与する従来例には非特許文献８があるが、該従来例でも損失パケットのユーザフロー情報は提供されず、したがって特定のユーザフローのパケットが順序どおりに届いていない場合に、原因がパケットロスか逆多重化リンク通過による順序逆転かを判断することはできなかった。そのため原因がパケットロスであった場合にも、順序逆転を想定して一定時間転送を保留せざるを得なかった。本実施例は損失したパケットのユーザフローごとのシーケンス番号を受信ノードが知ることができるので、パケット損失を順序逆転と混同することなく確実に検出できる。したがってパケット損失検出の際には転送保留を省略でき、エンドホスト間セッションのジッタを軽減する効果がある。
（第５の実施例）
次に本発明の第５の実施例として、ブロック管理情報に図１３に示されるような、ブロック内データパケットのデータ共通部分に関する情報を含めることでデータ圧縮を可能とする動作の概略を説明する。ここで圧縮対象となるデータパケットは、データ領域内に共通の部分を含むこととする。図中、開始シーケンス番号および終了シーケンス番号はデータ圧縮対象となるパケットの範囲を示す。
また開始ビットおよび終了ビットは、圧縮対象パケットのデータ領域のうち共通な範囲を、ビット位置の視点と終点により示すものである。開始ビット〜終了ビット間データには、開始ビットから終了ビットまでの間の共通データが収容される。以上の圧縮情報をブロック管理情報に含める一方、そこで指定した共通データはデータパケットのデータフィールドから削除することで送信パケットサイズの総量を低減する。
以上のようなデータ圧縮は、特にデータ自体が他のプロトコルのヘッダを含み、共通部分が大きい場合に有効である。共通部分が異なるパケットの組み合わせやビット範囲に複数存在する場合には、図１３に示すような圧縮情報を複数、ブロック管理情報に含めればよい。本実施例による送信データ圧縮は、圧縮状態を送受信ノード間で共有するためのシグナリングが必要な従来のデータ圧縮方法に比べ制御が簡略となる。
なお、上述の制御情報は、ルーティング情報であってもよい。
本発明のノード１０１、１０２等は、その動作をハードウェア的に実現することはもちろんとして、各部の機能を実行するプログラムをコンピュータで実行することにより、ソフトウェア的に実現することもできる。このプログラムは、磁気ディスク、半導体記憶装置その他の記録媒体に保持され、その記録媒体からコンピュータに読み込まれ、その動作を制御することにより、上述した機能を実現できる。

Claims (40)

  1. 複数のデータパケットとリーダパケットとを１つのブロックとし、
    前記複数のデータパケットに関する制御情報を、前記リーダパケットにまとめて送信し、
    受信したリーダパケットの制御情報に基づいて、送信するブロックのデータ量を決定することを特徴とする通信方法。
  2. 前記制御情報は、フロー制御情報であることを特徴とする請求項１記載の通信方法。
  3. 前記制御情報は、再送制御情報であることを特徴とする請求項１記載の通信方法。
  4. 前記制御情報は、ルーティング情報であることを特徴とする請求項１記載の通信方法。
  5. 前記制御情報は、経路情報であることを特徴とする請求項１記載の通信方法。
  6. 前記制御情報は、前記データパケットに共通する制御情報であることを特徴とする請求項１に記載の通信方法。
  7. リーダパケットを一意に識別する識別情報を前記データパケットに含めることを特徴とする請求項１に記載の通信方法。
  8. 制御情報をまとめたデータパケットを一意に識別する識別情報を前記リーダパケットに含めることを特徴とする請求項１に記載の通信方法。
  9. 前記複数のデータパケットまたはリーダパケットが、複数の回線を経由して送受信されることを特徴とする請求項１に記載の通信方法。
  10. 前記リーダパケットは、前記複数回線中最速の回線を用いて送信することを特徴とする請求項９に記載の通信方法。
  11. 前記制御情報に基づいて、前記リーダパケットまたは前記データパケットを送信する回線を選択することを特徴する請求項９に記載の通信方法。
  12. 受信したリーダパケットに含まれる制御情報に基づき送信するブロックの送信時刻を決定することを特徴とする請求項１に記載の通信方法。
  13. 同一のブロックに属する複数のデータパケットの受信時刻から通信経路の速度を推定することを特徴とする請求項１に記載の通信方法。
  14. 複数のデータパケットとリーダパケットとを１つのブロックとして扱い、前記複数のデータパケットに関する制御情報を前記リーダパケットにまとめるパケットブロック作成手段と、
    受信したリーダパケットにまとめられた制御情報に基づいて、送信するブロックのデータ量を決定するスケジューリング手段と、
    を有することを特徴とする通信システム。
  15. 前記制御情報は、フロー制御情報であることを特徴とする請求項１４記載の通信システム。
  16. 前記制御情報は、再送制御情報であることを特徴とする請求項１４記載の通信システム。
  17. 前記制御情報は、ルーティング情報であることを特徴とする請求項１４記載の通信システム。
  18. 前記制御情報は、経路情報であることを特徴とする請求項１４記載の通信システム。
  19. 前記パケットブロック作成手段は、前記データパケットに共通する制御情報を前記リーダパケットにまとめることを特徴とする請求項１４に記載の通信システム。
  20. リーダパケットを一意に識別する識別情報を前記データパケットに含めることを特徴とする請求項１４に記載の通信システム。
  21. 制御情報をまとめたデータパケットを一意に識別する識別情報を前記リーダパケットに含めることを特徴とする請求項１４に記載の通信システム。
  22. 前記複数のデータパケットまたはリーダパケットを複数の回線を経由して送信する送信手段を有することを特徴とする請求項１４に記載の通信システム。
  23. 前記スケジューリング手段は、リーダパケットを前記複数回線中最速の回線を用いて送信するように制御することを特徴とする請求項２２に記載の通信システム。
  24. 前記スケジューリング手段は、制御情報に基づいて、前記リーダパケットまたは前記データパケットを送信する回線を選択することを特徴する請求項２２に記載の通信システム。
  25. 前記スケジューリング手段は、受信したリーダパケットに含まれる制御情報に基づき送信するブロックの送信時刻を決定することを特徴とする請求項１４に記載の通信システム。
  26. 同一のブロックに属する複数のデータパケットの受信時刻から通信経路の速度を推定するパケット解析部を有することを特徴とする請求項１４に記載の通信システム。
  27. 複数のデータパケットとリーダパケットとを１つのブロックとして扱い、前記複数のデータパケットに関する制御情報を前記リーダパケットにまとめるパケットブロック作成手段と、
    他ノードから受信したリーダパケットにまとめられた制御情報に基づいて、送信するブロックのデータ量を決定するスケジューリング手段と、
    を有することを特徴とするノード。
  28. 前記パケットブロック作成手段は、前記データパケットに共通する制御情報を前記リーダパケットにまとめることを特徴とする請求項２７に記載の通信ノード。
  29. リーダパケットを一意に識別する識別情報を前記データパケットに含めることを特徴とする請求項２７に記載のノード。
  30. 制御情報をまとめたデータパケットを一意に識別する識別情報を前記リーダパケットに含めることを特徴とする請求項２７に記載のノード。
  31. 前記複数のデータパケットまたはリーダパケットを複数の回線を経由して送信する送信手段を有することを特徴とする請求項２７に記載のノード。
  32. 前記スケジューリング手段は、リーダパケットを前記複数回線中最速の回線を用いて送信するように制御することを特徴とする請求項３１に記載のノード。
  33. 前記スケジューリング手段は、他ノードから受信したリーダパケットにまとめられた制御情報に基づいて、前記リーダパケットまたは前記データパケットを送信する回線を選択することを特徴する請求項３１に記載のノード。
  34. 前記スケジューリング手段は、他ノードから受信したリーダパケットに含まれる制御情報に基づき送信するブロックの送信時刻を決定することを特徴とする請求項２７に記載のノード。
  35. 同一のブロックに属する複数のデータパケットの受信時刻から通信経路の速度を推定するパケット解析部を有することを特徴とする請求項２７に記載のノード。
  36. 複数のデータパケットとリーダパケットとを１つのブロックとして扱い、前記複数のデータパケットに関する制御情報を前記リーダパケットにまとめるパケットブロック作成処理と、
    他ノードから受信したリーダパケットにまとめられた制御情報に基づいて、送信するブロックのデータ量を決定するスケジューリング処理と
    をコンピュータに実施させることを特徴とするプログラム。
  37. 複数のデータパケットとリーダパケットとを１つのブロックとし、
    前記複数のデータパケットに関する制御情報を、送信ノードが前記リーダパケットにまとめて送信し、
    受信したリーダパケットの制御情報に基づいて推定した通信経路の状態を示した制御情報をリーダパケットに収容して前記送信ノードに送信し、
    前記リーダパケットに収容された制御情報に基づいて送信するブロックのデータ量を前記送信ノードが決定する
    ことを特徴とする通信方法。
  38. 複数のデータパケットとリーダパケットとを１つのブロックとして扱い、前記複数のデータパケットに関する制御情報を、送信ノードが前記リーダパケットにまとめるパケットブロック作成手段と、
    受信したリーダパケットにまとめられた制御情報に基づいて推定した通信経路の状態を示した制御情報をリーダパケットに収容して前記送信ノードに送信する送信手段と、
    前記リーダパケットに収容された制御情報に基づいて送信するブロックのデータ量を決定するスケジューリング手段と、
    を有することを特徴とする通信システム。
  39. 複数のデータパケットとリーダパケットとを１つのブロックとして扱い、前記複数のデータパケットに関する制御情報を、送信側のノードが前記リーダパケットにまとめるパケットブロック作成手段と、
    前記送信側のノードから受信したリーダパケットにまとめられた制御情報に基づいて推定した通信経路の状態を示した制御情報をリーダパケットに収容して前記送信側のノードに送信する送信手段と、
    前記リーダパケットに収容された制御情報に基づいて送信するブロックのデータ量を決定するスケジューリング手段と、
    を有することを特徴とするノード。
  40. 複数のデータパケットとリーダパケットとを１つのブロックとして扱い、前記複数のデータパケットに関する制御情報を、送信側のノードが前記リーダパケットにまとめるパケットブロック作成処理と、
    前記送信側のノードから受信したリーダパケットにまとめられた制御情報に基づいて推定した通信経路の状態を示した制御情報をリーダパケットに収容して前記送信側のノードに送信する送信手段と、
    前記リーダパケットに収容された制御情報に基づいて送信するブロックのデータ量を決定するスケジューリング処理と
    をコンピュータに実施させることを特徴とするプログラム。
JP2007554937A 2006-01-23 2007-01-18 通信方法、通信システム、ノードおよびプログラム Expired - Fee Related JP4780343B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2007554937A JP4780343B2 (ja) 2006-01-23 2007-01-18 通信方法、通信システム、ノードおよびプログラム

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2006014458 2006-01-23
JP2006014458 2006-01-23
JP2007554937A JP4780343B2 (ja) 2006-01-23 2007-01-18 通信方法、通信システム、ノードおよびプログラム
PCT/JP2007/050660 WO2007083687A1 (ja) 2006-01-23 2007-01-18 通信方法、通信システム、ノードおよびプログラム

Publications (2)

Publication Number Publication Date
JPWO2007083687A1 JPWO2007083687A1 (ja) 2009-06-11
JP4780343B2 true JP4780343B2 (ja) 2011-09-28

Family

ID=38287639

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007554937A Expired - Fee Related JP4780343B2 (ja) 2006-01-23 2007-01-18 通信方法、通信システム、ノードおよびプログラム

Country Status (6)

Country Link
US (1) US20090059958A1 (ja)
EP (1) EP1981220A4 (ja)
JP (1) JP4780343B2 (ja)
KR (1) KR20080079335A (ja)
CN (1) CN101379781A (ja)
WO (1) WO2007083687A1 (ja)

Families Citing this family (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5103900B2 (ja) * 2006-12-28 2012-12-19 富士通株式会社 パス状態監視方法及び装置
JP2008199605A (ja) * 2007-02-12 2008-08-28 Asustek Computer Inc 無線通信システムにおいてリソース使用効率を向上させる方法及び装置
EP2003799A1 (en) * 2007-06-12 2008-12-17 Sony Deutschland Gmbh Adaptive history aware beam steering
JP4941753B2 (ja) * 2007-08-31 2012-05-30 横河電機株式会社 フィールド制御システム
US8270404B2 (en) * 2008-02-13 2012-09-18 International Business Machines Corporation System, method, and computer program product for improved distribution of data
JP4926113B2 (ja) * 2008-04-07 2012-05-09 三菱電機株式会社 モバイルルータアドホックネットワーク通信システム
US9047421B2 (en) * 2008-04-30 2015-06-02 Alcatel Lucent Serial link buffer fill-level compensation using multi-purpose start of protocol data unit timing characters
US8374091B2 (en) * 2009-03-26 2013-02-12 Empire Technology Development Llc TCP extension and variants for handling heterogeneous applications
JP5482795B2 (ja) * 2009-09-17 2014-05-07 富士通株式会社 通信方法、通信システム、送信装置、受信装置
JP5519683B2 (ja) 2009-09-30 2014-06-11 パナソニック株式会社 送信装置、受信装置、送受信システム、及び送受信方法
US8824285B1 (en) 2009-12-16 2014-09-02 Dnutch Associates, Inc. System and method for collision detection and avoidance during packet based communications
JP5257373B2 (ja) * 2010-01-29 2013-08-07 ブラザー工業株式会社 パケット送信装置、パケット送信方法及びパケット送信プログラム
US9515925B2 (en) 2011-05-19 2016-12-06 Qualcomm Incorporated Apparatus and methods for media access control header compression
US9125181B2 (en) * 2011-08-23 2015-09-01 Qualcomm Incorporated Systems and methods for compressing headers
EP2760182B1 (en) * 2011-09-21 2017-03-01 Fujitsu Limited Data communication apparatus, data transmission method, and computer system
US9479979B2 (en) * 2012-06-29 2016-10-25 Nokia Solutions And Networks Oy Success rate improvements for ANR measurements while reducing data loss at a UE
CN103442438B (zh) * 2012-07-23 2017-04-12 英特尔公司 用于隧道通用寻呼消息的装置和方法
EP2936739B1 (en) * 2012-12-21 2017-12-13 Telefonaktiebolaget LM Ericsson (publ) Method and node arrangement for providing more accurate estimation of data path conditions
KR102094718B1 (ko) * 2013-09-26 2020-05-27 삼성전자주식회사 무선 네트워크에서 학습에 기반한 중계 노드 선택 방법 및 중계 장치
US9729439B2 (en) 2014-09-26 2017-08-08 128 Technology, Inc. Network packet flow controller
US10277506B2 (en) 2014-12-08 2019-04-30 128 Technology, Inc. Stateful load balancing in a stateless network
US9736184B2 (en) 2015-03-17 2017-08-15 128 Technology, Inc. Apparatus and method for using certificate data to route data
US9729682B2 (en) 2015-05-18 2017-08-08 128 Technology, Inc. Network device and method for processing a session using a packet signature
US9762485B2 (en) 2015-08-24 2017-09-12 128 Technology, Inc. Network packet flow controller with extended session management
US9871748B2 (en) 2015-12-09 2018-01-16 128 Technology, Inc. Router with optimized statistical functionality
US9985883B2 (en) 2016-02-26 2018-05-29 128 Technology, Inc. Name-based routing system and method
US10205651B2 (en) 2016-05-13 2019-02-12 128 Technology, Inc. Apparatus and method of selecting next hops for a session
US10298616B2 (en) 2016-05-26 2019-05-21 128 Technology, Inc. Apparatus and method of securing network communications
US11075836B2 (en) 2016-05-31 2021-07-27 128 Technology, Inc. Reverse forwarding information base enforcement
US10200264B2 (en) 2016-05-31 2019-02-05 128 Technology, Inc. Link status monitoring based on packet loss detection
US10841206B2 (en) 2016-05-31 2020-11-17 128 Technology, Inc. Flow modification including shared context
US10257061B2 (en) 2016-05-31 2019-04-09 128 Technology, Inc. Detecting source network address translation in a communication system
US10091099B2 (en) 2016-05-31 2018-10-02 128 Technology, Inc. Session continuity in the presence of network address translation
US9832072B1 (en) 2016-05-31 2017-11-28 128 Technology, Inc. Self-configuring computer network router
US10009282B2 (en) 2016-06-06 2018-06-26 128 Technology, Inc. Self-protecting computer network router with queue resource manager
US9985872B2 (en) 2016-10-03 2018-05-29 128 Technology, Inc. Router with bilateral TCP session monitoring
US10425511B2 (en) 2017-01-30 2019-09-24 128 Technology, Inc. Method and apparatus for managing routing disruptions in a computer network
EP4195597A1 (en) 2017-03-07 2023-06-14 128 Technology, Inc. Routing device using flow duplication
US10432519B2 (en) 2017-05-26 2019-10-01 128 Technology, Inc. Packet redirecting router
KR101983088B1 (ko) * 2017-06-23 2019-05-31 (주)넷비젼텔레콤 다중 경로 환경에서의 udp 패킷 처리 방법
US11165863B1 (en) 2017-08-04 2021-11-02 128 Technology, Inc. Network neighborhoods for establishing communication relationships between communication interfaces in an administrative domain
KR20200053620A (ko) * 2017-10-05 2020-05-18 지멘스 악티엔게젤샤프트 네트워크 및 통신 네트워크를 구성하기 위한 방법 및 장치
US20190253341A1 (en) 2018-02-15 2019-08-15 128 Technology, Inc. Service Related Routing Method and Apparatus
GB2575511A (en) 2018-07-13 2020-01-15 Nokia Technologies Oy Spatial audio Augmentation
GB2575509A (en) * 2018-07-13 2020-01-15 Nokia Technologies Oy Spatial audio capture, transmission and reproduction
EP4140106A1 (en) 2020-04-23 2023-03-01 Juniper Networks, Inc. Session monitoring using metrics of session establishment
KR102502758B1 (ko) 2022-11-24 2023-02-23 펌킨네트웍스(주) 멀티코어 환경의 운영체제에 적합한 패킷 전송 장치

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH01101758A (ja) * 1987-10-15 1989-04-19 Oki Electric Ind Co Ltd 固定長パケット通信におけるパケット分解・組立および粉失検出方法
JPH08223217A (ja) * 1995-02-08 1996-08-30 Nippon Telegr & Teleph Corp <Ntt> 無線パケット多重方法
JP2002064473A (ja) * 2000-07-18 2002-02-28 Eastman Kodak Co ワイヤレス画像データを送信するパケット・データ送信システム
JP2004088208A (ja) * 2002-08-23 2004-03-18 Sony Corp データ伝送システム及びデータ伝送方法
JP2004535097A (ja) * 2001-04-17 2004-11-18 ノキア コーポレイション パケットモードスピーチ通信
WO2005067227A1 (ja) * 2004-01-09 2005-07-21 Nec Corporation 負荷分散方法、ノード及び制御プログラム
WO2005067261A1 (ja) * 2004-01-09 2005-07-21 Nec Corporation 通信方法

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6021433A (en) * 1996-01-26 2000-02-01 Wireless Internet, Inc. System and method for transmission of data
JP3587352B2 (ja) * 1999-02-04 2004-11-10 富士通株式会社 ネットワーク通信性能測定方法及び装置並びにネットワーク通信性能測定プログラムを格納したコンピュータ読取り可能な記録媒体
US20020031103A1 (en) * 2000-05-02 2002-03-14 Globalstar L.P. User terminal employing quality of service path determination and bandwidth saving mode for a satellite ISP system using non-geosynchronous orbit satellites
JP3816314B2 (ja) * 2000-07-11 2006-08-30 三菱電機株式会社 パケット交換装置
US20020073217A1 (en) * 2000-12-08 2002-06-13 Ma David Yin-Shur Method and apparatus for facilitating communication between a wireless device and disparate devices or systems
JP4187940B2 (ja) * 2001-03-06 2008-11-26 株式会社エヌ・ティ・ティ・ドコモ パケット伝送方法及びシステム、並びにパケット送信装置、受信装置、及び送受信装置
US20020131103A1 (en) * 2001-03-16 2002-09-19 Nicholas Bambos Method and system for reconfiguring a network element such as an optical network element
US7778179B2 (en) * 2005-11-23 2010-08-17 Telefonaktiebolaget L M Ericsson (Publ) Using filtering and active probing to evaluate a data transfer path

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH01101758A (ja) * 1987-10-15 1989-04-19 Oki Electric Ind Co Ltd 固定長パケット通信におけるパケット分解・組立および粉失検出方法
JPH08223217A (ja) * 1995-02-08 1996-08-30 Nippon Telegr & Teleph Corp <Ntt> 無線パケット多重方法
JP2002064473A (ja) * 2000-07-18 2002-02-28 Eastman Kodak Co ワイヤレス画像データを送信するパケット・データ送信システム
JP2004535097A (ja) * 2001-04-17 2004-11-18 ノキア コーポレイション パケットモードスピーチ通信
JP2004088208A (ja) * 2002-08-23 2004-03-18 Sony Corp データ伝送システム及びデータ伝送方法
WO2005067227A1 (ja) * 2004-01-09 2005-07-21 Nec Corporation 負荷分散方法、ノード及び制御プログラム
WO2005067261A1 (ja) * 2004-01-09 2005-07-21 Nec Corporation 通信方法

Also Published As

Publication number Publication date
EP1981220A1 (en) 2008-10-15
CN101379781A (zh) 2009-03-04
EP1981220A4 (en) 2011-04-13
US20090059958A1 (en) 2009-03-05
KR20080079335A (ko) 2008-08-29
WO2007083687A1 (ja) 2007-07-26
JPWO2007083687A1 (ja) 2009-06-11

Similar Documents

Publication Publication Date Title
JP4780343B2 (ja) 通信方法、通信システム、ノードおよびプログラム
JP4394541B2 (ja) 通信装置、データ通信方法およびプログラム
US11405265B2 (en) Methods and systems for detecting path break conditions while minimizing network overhead
US8098648B2 (en) Load distributing method
TWI429242B (zh) 用於對資料中心乙太網路架構虛擬道之適應性壅塞控制的方法、系統及電腦程式產品
US6072797A (en) Methods, apparatus and computer program products for aggregated transmission groups in high speed networks
JP2007527170A (ja) 並列通信のためのシステムおよび方法
US20060221825A1 (en) Congestion control network relay device and method
WO2002019654A2 (en) Method for improving tcp performance over wireless links
WO2002087276A2 (en) Method and device for robust real-time estimation of bottleneck bandwidth
JPWO2005006664A1 (ja) トランスポート層中継方法及びトランスポート層中継装置並びにプログラム
JP2008518552A (ja) 粗細試験期間を使用したネットワーク・パケットの経験的スケジューリング法
JP4488256B2 (ja) 通信方法、ノード及び制御プログラム
JP5039677B2 (ja) エッジノードおよび帯域制御方法
KR20080059897A (ko) Ｉｐ 패킷망에서 타임스탬프 메시지와 단방향 지연시간 차이를 이용한 단대단 가용대역폭 측정방법
JP2009105662A (ja) マルチホップ通信システム、マルチホップ通信方法、端末装置および中継装置
Zhong et al. Adaptive load balancing algorithm for multiple homing mobile nodes
JP4828555B2 (ja) ノード装置および帯域制御方法
JP4977677B2 (ja) エッジノードおよび帯域制御方法
Jacquet et al. Striping over wireless links: effects on transmission delays
JP3590789B2 (ja) 光通信網およびプログラムおよび記録媒体
CN115733755A (zh) 一种可填充网络带宽的数据中心传输控制系统及方法
Pu et al. Improving Quality of Service for Congestion Control in High-Speed Wired-cum-Wireless Networks
KR20100062604A (ko) 다수의 무선망을 이용한 패킷 전송 장치
JP2009206734A (ja) Ｔｃｐフローレート制御エッジノードにおけるフローレート制御方法及びエッジノード

Legal Events

Date Code Title Description
A529 Written submission of copy of amendment under article 34 pct

Free format text: JAPANESE INTERMEDIATE CODE: A5211

Effective date: 20080627

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20090415

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110202

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110404

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110608

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110621

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140715

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees