(57)【要約】送信ノード（１２Ｓ）と受信ノード（１２Ｒ）との間のネットワーク接続を介したデータ・パケット伝送を最適化する適応パケット・メカニズム及び方法。ネットワーク状況が送信ノード（１２Ｓ）と受信ノード（１２Ｒ）との間のパケット伝送の待ち時間及び揺らぎに関連する、接続における現在のネットワーク状況が定期的に測定される。接続の待ち時間及び揺らぎの測定値は、送信ノード（１２Ｓ）と受信ノード（１２Ｒ）との間におけるパケット・データの伝送について、最適パケット・サイズ及び最適パケット間隔を決定するために用いられ、また送信ノード（１２Ｓ）から受信ノード（１２Ｒ）へのデータ・パケットの伝送において用いられる。ネットワーク状況は、モニタ・パケットあるいはデータ・パケットの送信により測定することができ、また送信ノード（１２Ｓ）と受信ノード（１２Ｒ）の片方あるいは両方において判断することができ、最適パケット・サイズ及びパケット間隔がファジー・ロジック・アナライザ（４８Ａ）、ニューラル・ネットワーク・アナライザ（４８Ｂ）によって決定される。
2004533184.tif 000002
【特許請求の範囲】
【請求項１】
データ通信ネットワーク内の、送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する方法であって、
（ａ）ネットワーク状況が前記送信ノードと前記受信ノードとの間におけるパケット伝送の待ち時間及び揺らぎに関連する、前記送信ノードと前記受信ノードとの間の接続における現在のネットワーク状況を、定期的に測定するステップと、
（ｂ）前記現在のネットワーク状況から、前記送信ノードと前記受信ノードとの間におけるパケット・データの伝送に関する、最適パケット・サイズ及び最適パケット間隔を決定するステップとを含む方法。
【請求項２】
送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項１に記載の方法であって、ステップ（ｂ）が更に
（１）前記送信ノードと前記受信ノードとの間で通信されるべき所与の量及びタイプのデータに関して、前記送信ノードと前記受信ノードとの間におけるパケット・データの伝送に関する最適パケット・サイズ及び最適パケット間隔を決定することを含む方法。
【請求項３】
送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項１に記載の方法であって、ステップ（ａ）が更に
（ａ１）選択されたサイズの一連のモニタ・パケットを、選択されたパケット間隔で、前記送信ノードから前記受信ノードに送信するステップと、
（ａ２）前記受信ノードにおいて、前記モニタ・パケットを、該モニタ・パケットが前記送信ノードにおいて受信される順序で、前記受信ノードから前記送信ノードに返送するステップと、
（ａ３）前記送信ノードにおいて、前記受信ノードから前記返送されたモニタ・パケットを受信した際に、既知のサイズ及び既知のパケット間伝送間隔のモニタ・パケットに関して、ネットワーク状況が前記送信ノードと前記受信ノードとの間のパケット伝送の待ち時間及び揺らぎに関連する、前記送信ノードと前記受信ノードとの間の接続におけるネットワーク状況を判断するステップとを含む方法。
【請求項４】
送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項３に記載の方法であって、
各モニタ・パケットが、前記送信ノードから該モニタ・パケットが送信された時間を表す出発時間、該モニタ・パケットのサイズを表すパケット・サイズ及び前記一連のモニタ・パケットにおける該モニタ・パケットの順位を表すパケット番号を含む方法。
【請求項５】
送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項４に記載の方法であって、
（１）前記モニタ・パケットによって測定される前記ネットワーク状況が、前記モニタ・パケットの伝送及び返送についての最大往復遅延時間、前記モニタ・パケットの伝送及び返送についての最小往復遅延時間、前記モニタ・パケットの平均往復遅延時間、前記モニタ・パケットの平均揺らぎ、及び順序の狂ったパケットの数を含む方法。
【請求項６】
送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項５に記載の方法であって、前記モニタ・パケットによって測定される前記ネットワーク状況が、更に
（２）失われたパケットの数を含む方法。
【請求項７】
送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項３に記載の方法であって、
（１）前記モニタ・パケットによって測定される前記ネットワーク状況が、前記接続の利用可能な帯域幅及び揺らぎを含む方法。
【請求項８】
送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項７に記載の方法であって、
前記モニタ・パケットによって測定される前記ネットワーク状況が、更に平均揺らぎ、最大揺らぎ及び最小揺らぎを含む方法。
【請求項９】
送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項３に記載の方法であって、
前記モニタ・パケットによって測定される前記ネットワーク状況が、更に前記受信ノードにおいて該モニタ・パケットが受信される順序を含む方法。
【請求項１０】
送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項３に記載の方法であって、
前記モニタ・パケットによって測定される前記ネットワーク状況が、更に失われたモニタ・パケットの数を含む方法。
【請求項１１】
送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項１に記載の方法であって、更に
（ｃ）前記ネットワーク状況に応じて決定されたパケット・サイズ及びパケット間隔で、前記送信ノードから前記受信ノードにデータ・パケットを送信するステップを含む方法。
【請求項１２】
送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項１に記載の方法であって、更に
（ａ１）一連のモニタ・パケットを、前記送信ノードから前記受信ノードに送信するステップと、
（ａ２）前記受信ノードにおいて、前記モニタ・パケットを、該モニタ・パケットが前記送信ノードにおいて受信される順序で、前記受信ノードから前記送信ノードに返送するステップと、
（ａ３）前記送信ノードにおいて、前記受信ノードから前記返送されたモニタ・パケットを受信した際に、既知のサイズ及び既知のパケット間伝送間隔のモニタ・パケットに関して、ネットワーク状況が前記送信ノードと前記受信ノードとの間のパケット伝送の待ち時間及び揺らぎに関連する、前記送信ノードと前記受信ノードとの間の接続におけるネットワーク状況を判断するステップと、
（ｃ）前記送信ノードにおいて、前記ネットワーク状況から、前記送信ノードから前記受信ノードにパケットを伝送するための最適パケット・サイズ及び最適パケット間隔を決定するステップとを含む方法。
【請求項１３】
送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項１２に記載の方法であって、更に
（ｄ）前記受信ノードにおいて、前記受信されたモニタ・パケットからネットワーク状況を判断するステップを含む方法。
【請求項１４】
前記送信ノードと前記受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項１３に記載の方法であって、更に
（ｅ）前記受信ノードにおいて、１つ以上の状況記録における前記ネットワーク状況を保存するステップを含む方法。
【請求項１５】
送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項１３に記載の方法であって、更に
（ｄ）前記受信ノードにおいて判断された前記ネットワーク状況を前記送信ノードに返信するステップと、
（ｅ）前記送信ノードにおいて、前記受信ノードにおいて判断された前記ネットワーク状況を用いて、最適パケット・サイズ及び最適パケット間隔を更新するステップとを含む方法。
【請求項１６】
データ通信ネットワーク内の送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する方法であって、
（ａ）前記送信ノードから前記受信ノードにパケットを送信するステップと、
（ｂ）前記受信ノードにおいて、前記送信ノードから受信した各パケットについて、該パケットの受領通知を生成し、該送信ノードに送信するステップと、
（ｃ）前記送信ノードにおいて、前記受信ノードからパケットの受領通知を受信した際に、既知のサイズ及び既知のパケット間伝送間隔のモニタ・パケットに関して、ネットワーク状況が前記送信ノードと前記受信ノードとの間のパケット伝送の待ち時間及び揺らぎに関連する、前記送信ノードと前記受信ノードとの間の接続におけるネットワーク状況を判断するステップと、
（ｃ）前記受信ノードにおいて、前記ネットワーク状況から、前記受信ノードにデータ・パケットを伝送するための最適パケット・サイズ及び最適パケット間隔を決定するステップとを含む方法。
【請求項１７】
データ通信ネットワーク内の送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する方法であって、
（ａ）一連のデータ・パケットを、前記送信ノードから前記受信ノードに送信するステップと、
（ｂ）前記受信ノードにおいて、前記受信したデータ・パケットからネットワーク状況を判断するステップと、
（ｃ）前記受信ノードにおいて判断された前記ネットワーク状況を前記送信ノードに返信するステップと、
（ｄ）前記送信ノードにおいて、前記受信ノードにおいて判断された前記ネットワーク状況を用いて、前記送信ノードから前記受信ノードへのデータ・パケットの伝送に関する最適パケット・サイズ及び最適パケット間隔を決定するステップとを含む方法。
【請求項１８】
データ通信ネットワーク内の送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する適応パケット・メカニズムであって、
（ａ）ネットワーク状況が前記送信ノードと前記受信ノードとの間のパケット伝送の待ち時間及び揺らぎに関連する、前記送信ノードと前記受信ノードとの間の接続における現在のネットワーク状況を定期的に測定するための、前記接続を介して通信する送信ノード・パケット転送エンジン及び受信ノード・パケット転送エンジンと、
（ｂ）前記現在のネットワーク状況から、前記送信ノードと前記受信ノードとの間におけるパケット・データの伝送に関する最適パケット・サイズ及び最適パケット間隔を決定するための、コレクタ／コントローラとを含む適応パケット・メカニズム。
【請求項１９】
データ通信ネットワーク内の送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項１８に記載の適応パケット・メカニズムであって、
（１）前記コレクタ／コントローラが、前記送信ノードと前記受信ノードとの間で通信されるべき所与の量及びタイプのデータについて、該送信ノードと該受信ノードとの間におけるパケット・データの伝送に関する前記最適パケット・サイズ及び前記最適パケット間隔を決定する適応パケット・メカニズム。
【請求項２０】
データ通信ネットワーク内の送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項１８に記載の適応パケット・メカニズムであって、
（ａ１）前記送信ノード・パケット転送エンジンが、選択されたサイズの一連のモニタ・パケットを選択されたパケット間隔で前記送信ノードから前記受信ノードに送信するため、前記コレクタ／コントローラに応答し、
（ａ２）前記受信ノード・パケット転送エンジンが、前記送信ノードにおいて前記モニタ・パケットが受信される順序で、該モニタ・パケットを前記受信ノードから前記送信ノードに返送するため、送信ノードから受信した前記モニタ・パケットに応答し、
（ａ３）前記送信ノード・パケット転送エンジンが、既知のサイズ及び既知のパケット間伝送間隔のモニタ・パケットに関して、ネットワーク状況が前記送信ノードと前記受信ノードとの間のパケット伝送の待ち時間及び揺らぎに関連する、前記送信ノードと前記受信ノードとの間の接続におけるネットワーク状況を判断するため、受信ノードから受信した返送されたモニタ・パケットに応答する適応パケット・メカニズム。
【請求項２１】
データ通信ネットワーク内の送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項２０に記載の適応パケット・メカニズムであって、
各モニタ・パケットが、前記送信ノードから該モニタ・パケットが送信された時間を表す出発時間、該モニタ・パケットのサイズを表すパケット・サイズ及び前記一連のモニタ・パケットにおける該モニタ・パケットの順位を表すパケット番号を含む適応パケット・メカニズム。
【請求項２２】
データ通信ネットワーク内の送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項２１に記載の適応パケット・メカニズムであって、
（１）前記モニタ・パケットによって測定される前記ネットワーク状況が、前記モニタ・パケットの伝送及び返送についての最大往復遅延時間、前記モニタ・パケットの伝送及び返送についての最小往復遅延時間、前記モニタ・パケットの平均往復遅延時間、前記モニタ・パケットの平均揺らぎ、及び順序の狂ったパケットの数を含む適応パケット・メカニズム。
【請求項２３】
データ通信ネットワーク内の送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項２２に記載の適応パケット・メカニズムであって、前記モニタ・パケットによって測定される前記ネットワーク状況が、更に
（２）失われたパケットの数を含む適応パケット・メカニズム。
【請求項２４】
データ通信ネットワーク内の送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項２０に記載の適応パケット・メカニズムであって、
（１）前記モニタ・パケットによって測定される前記ネットワーク状況が、前記接続の利用可能な帯域幅及び揺らぎを含む適応パケット・メカニズム。
【請求項２５】
データ通信ネットワーク内の送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項２４に記載の適応パケット・メカニズムであって、
前記モニタ・パケットによって測定される前記ネットワーク状況が、更に平均揺らぎ、最大揺らぎ及び最小揺らぎを含む適応パケット・メカニズム。
【請求項２６】
データ通信ネットワーク内の送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項２０に記載の適応パケット・メカニズムであって、
前記モニタ・パケットによって測定される前記ネットワーク状況が、更に前記受信ノードにおいて該モニタ・パケットが受信される順序を含む適応パケット・メカニズム。
【請求項２７】
データ通信ネットワーク内の送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項２０に記載の適応パケット・メカニズムであって、
前記モニタ・パケットによって測定される前記ネットワーク状況が、更に失われたモニタ・パケットの数を含む適応パケット・メカニズム。
【請求項２８】
データ通信ネットワーク内の送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項１８に記載の適応パケット・メカニズムであって、
（ｃ）前記送信ノード・パケット転送エンジンが、前記ネットワーク状況に応じて決定されたパケット・サイズ及びパケット間隔で、前記送信ノードから前記受信ノードにデータ・パケットを送信するため、前記コレクタ／コントローラにより決定された前記最適パケット・サイズ及びパケット間隔に応答する適応パケット・メカニズム。
【請求項２９】
データ通信ネットワーク内の送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項１８に記載の適応パケット・メカニズムであって、
（ｄ）前記受信ノード・パケット転送エンジンが、受信したモニタ・パケットからネットワーク状況を判断するため、前記送信ノードから受信した前記モニタ・パケットに応答する適応パケット・メカニズム。
【請求項３０】
データ通信ネットワーク内の送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項２９に記載の適応パケット・メカニズムであって、
（ｅ）前記受信ノード・パケット転送エンジンが、１つ以上の状況記録にネットワーク状況を保存するため、前記送信ノードから受信した前記モニタ・パケットに応答する適応パケット・メカニズム。
【請求項３１】
データ通信ネットワーク内の送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項３０に記載の適応パケット・メカニズムであって、
（ｅ）前記受信ノード・パケット転送エンジンが、前記受信ノードにおいて判断されたネットワーク状況を前記コレクタ／コントローラに供給するため、前記送信ノードから受信した前記モニタ・パケットに応答し、
（ｆ）前記コレクタ／コントローラが、前記前記受信ノードにおいて判断されたネットワーク状況を用いて前記最適パケット・サイズ及び最適パケット間隔を更新するため、前記前記受信ノードにおいて判断されたネットワーク状況に応答する適応パケット・メカニズム。
【請求項３２】
データ通信ネットワーク内の送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する適応パケット・メカニズムであって、
（ａ）前記送信ノードから前記受信ノードにパケットを送信するための送信ノード・パケット転送エンジンと、
（ｂ）前記受信ノードにおいて前記送信ノードから受信された各パケットに応答して、該パケットの受領通知を生成して前記送信ノード・パケット転送エンジンに送信するための、受信ノード・パケット受領確認メカニズムと、
（ｃ）既知のサイズ及び既知のパケット間伝送間隔のモニタ・パケットに関してネットワーク状況が前記送信ノードと前記受信ノードとの間のパケット伝送の待ち時間及び揺らぎに関連する、前記送信ノードと前記受信ノードとの間の接続における前記ネットワーク状況を判断するため、受信ノードからのパケットの受領通知に応答する前記送信ノード・パケット転送エンジンと、
（ｃ）ネットワーク状況に応答して、前記受信ノードへのデータ・パケットの送信に関する最適パケット・サイズ及び最適パケット間隔を決定するコレクタ／コントローラとを備えた適応パケット・メカニズム。
【請求項３３】
データ通信ネットワーク内の送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する適応パケット・メカニズムであって、
（ａ）前記送信ノードから前記受信ノードに一連のデータ・パケットを送信するための送信ノード・パケット転送エンジンと、
（ｂ）受信されたデータ・パケットからネットワーク状況を判断する受信ノード・パケット転送エンジンと、
（ｃ）前記送信ノードから前記受信ノードへのデータ・パケットの送信について最適パケット・サイズ及び最適パケット間隔を決定するために、前記受信ノード・パケット転送エンジンにより判断されたネットワーク状況に応答するコレクタ／コントローラとを備えた適応パケット・メカニズム。
【請求項３４】
無線データ通信ネットワーク内の送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する方法であって、
（ａ）前記送信ノードから前記受信ノードにパケットを送信するステップと、
（ｂ）前記受信ノードにおいて、前記送信ノードから受信した各パケットについて、該パケットの受領通知を生成して該送信ノードに送信するステップと、
（ｃ）前記送信ノードにおいて、
（ｃ１）前記受信ノードからパケットの受領通知を受信した際に、既知のサイズ及び既知のパケット間伝送間隔のパケットに関する接続待ち時間及び揺らぎを含む、前記送信ノードと前記受信ノードとの間の接続におけるネットワーク状況を判断するステップと、
（ｃ２）前記ネットワーク状況から、前記接続を介してデータ・パケットを伝送するための最適パケット・サイズ及び最適パケット間隔を決定するステップと、
（ｄ）前記送信ノードのネットワーク・プロトコル・スタックにおいて、
（ｄ１）前記受信ノードに送信されるべき各パケットを捕捉するステップと、
（ｄ２）前記パケットを前記最適パケット・サイズのフラグメント・パケットにフラグメント化し、フラグメント化されたパケットのサイズを反映させるためにパケット・ヘッダのフラグメンテーション・フィールドを変更するステップと、
（ｄ３）前記受信ノードに前記フラグメント・パケットを送信するステップと、
（ｅ）前記受信ノードにおいて、前記フラグメンテーション・フィールドに応じて前記フラグメント・パケットをパケットにデフラグメントするステップとを含む方法。
【請求項３５】
無線データ通信ネットワーク内の送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項３４に記載の方法であって、更に
（ｆ）前記受信ノードのネットワーク・プロトコル・スタックにおいて、
（ｆ１）前記送信ノードに送信されるべき各パケットを、該送信ノードから受信したフラグメント・パケットから決定された前記最適パケット・サイズのパケットに構築するステップと、
（ｆ２）前記受信ノードのパケットを前記送信ノードに送信するステップとを含む方法。
【請求項３６】
無線データ通信ネットワーク内の送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項３４に記載の方法であって、前記無線ネットワークが８０２．１１等のネットワークである方法。
【請求項３７】
無線データ通信ネットワーク内の送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する適応パケット・メカニズムであって、
（ａ）送信ノードから受信ノードにパケットを通信するため、ネットワーク・プロトコル・スタック、該プロトコル・スタックから接続されたデバイス・ドライバ、及び該デバイス・ドライバから接続へと接続されたネットワーク・インターフェイスをそれぞれ含んでいる、送信ノード及び受信ノードと、
（ｂ）送信ノードにおいて、前記ネットワーク・プロトコル・スタックと前記デバイス・ドライバとの間に存在するネットワーク中間ドライバであって、
（ｂ１）前記受信ノードに送信されるパケット及び各送信されたパケットに応答して前記受信ノードから受信したエコー受領通知から、送信ノードと受信ノードとの間の前記接続における、既知のサイズ及び既知のパケット間伝送間隔についての接続待ち時間及び揺らぎを含むネットワーク状況を判断し、
（ｂ２）前記受信ノードに送信されるべき各パケットを捕捉し、
（ｂ３）前記パケットを前記最適パケット・サイズのフラグメント・パケットにフラグメント化し、フラグメント化されたパケットのサイズを反映させるためにパケット・ヘッダのフラグメンテーション・フィールドを変更し、
（ｂ４）前記受信ノードに前記フラグメント・パケットを送信するためのネットワーク中間ドライバとを備えた適応パケット・メカニズム。
【請求項３８】
無線データ通信ネットワーク内の送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項３７に記載の適応パケット・メカニズムであって、
（ｃ１）前記ネットワーク・プロトコル・スタックが、前記フラグメンテーション・フィールドに応じて前記フラグメント・パケットをパケットにデフラグメントするために、受信した各フラグメント・パケットに応答する適応パケット・メカニズム。
【請求項３９】
無線データ通信ネットワーク内の送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項３８に記載の適応パケット・メカニズムであって、
（ｃ１）前記送信ノードに送信されるべきパケットを前記最適パケット・サイズのフラグメント・パケットにフラグメント化するために、前記パケット・ヘッダのフラグメンテーション・フィールドをそれに併せて変更することも含めて、前記ネットワーク・プロトコル・スタックが受信したフラグメント・パケットに応答する、適応パケット・メカニズム。
【請求項４０】
無線データ通信ネットワーク内の送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化する、請求項３７に記載の適応パケット・メカニズムであって、前記ネットワーク中間ドライバが、
前記接続における前記ネットワーク状況を判断し、
前記パケットを対応するフラグメント・パケットにフラグメント化するための、
前記ネットワーク・プロトコル・スタックと前記デバイス・ドライバとの間に接続されたパケット転送エンジンと、
前記パケット転送エンジンに関連付けられ、前記ネットワーク状況に応答して、前記ネットワークを介したパケットの伝送に関する最適パケット・サイズ及び最適パケット間隔を決定するコレクタ／コントローラとを備えた適応パケット・メカニズム。
【発明の詳細な説明】
【０００１】
関連出願の相互参照
本願は、ネットワークにおけるデータ・パケット・サイズの適応制御について２００１年６月１２日にＭｕｒａｔ  Ｉ．  Ｂａｈａｄｉｒｏｇｌｕにより出願され、本願と同一の譲受人に譲渡された、係属中の米国特許出願Ｎｏ．０９／８７９,７６１に関連する、その一部継続出願である。
発明の分野
本願発明は、ネットワークを介したデータ伝送のための方法及びシステムを対象とし、特に、データ伝送の所定の要件を満たすようデータ伝送速度を高めるため、データ・パケット・サイズがネットワーク状況に適応させられる、ネットワークを介したデータ伝送のための方法及びシステムを対象とする。
発明の背景
ネットワークは、プログラム・コードや音声、画像及び映像あるいは画像情報を含むデータのような、種々のコンピュータ・システム間のあらゆる形の情報をやりとりするために、長い間広く用いられている。その結果、コンピュータ・システム及び通信システムは一緒に発達してきており、それぞれが他方に影響を与え、それぞれが他方により提起された方法や問題に対処するために発達しているのである。
【０００２】
例えば、コンピュータが最初に開発されたときには、ある地点から別の地点へ情報を伝達する広く利用可能な手段として長い間存在していた電話ネットワークが、コンピュータ・システム間の通信に利用されるネットワークの最初の形の一つであった。元々の電話ネットワークの本来的な特徴が、結果として、当初のコンピュータ通信の方法及び技術を規定していた。周知であり、また当然のことであるが、電話ネットワークは、１つ以上の中央切換システムを介して２人以上のユーザ間に専用通信回路すなわち「チャンネル」を確立することによって、そのユーザ間における音声データ、より広く言えば音声信号の通信を可能にする。同様に周知であり、また当然のことであるが、コンピュータ・システムにおける情報は、予め定められたサイズの多数のビットあるいはバイトのユニットすなわちパケットとして構成されており、従って、電話ネットワークを介してデジタル情報のパケットをやり取りするために、種々の方法及び信号のフォーマットが開発された。
【０００３】
元々の電話ネットワークの基本的な性質は、情報がユーザ間の会話であろうと、１台のコンピュータと別のコンピュータとの間でやり取りされるデジタル情報であろうと、一旦確立されたチャンネルが専ら単一の情報交換にのみ当てられることである。専用チャンネルは、チャンネルの全帯域が所与の情報交換に利用できる点において、また情報源から情報受領者への伝送の遅延が全て、単にチャンネルを介した直接伝送速度の関数である点において有利である。専用チャンネル伝送速度は、時間が経過しても情報伝送負荷が増しても大きく変化しないため、専用チャンネルは、「等時性」伝送を提供することができる。しかし、専用チャンネルの非常に不利な点は、専用チャンネルが通信ネットワークの大部分の帯域を先に占有してしまうことである。すなわち、情報交換がチャンネルの全帯域を必要としないときであっても、また情報が伝送されないときであっても、１つのチャンネルの全帯域が、コンピュータ・システム間の所定のリンクにのみ利用可能な状態に保たれ、それに専用されることである。
【０００４】
上記の理由によって、コンピュータ・システム間の情報交換がますます一般的になり広く普及するにつれて、専用チャンネルはコンピュータ間の通信のニーズを満たすには不適当になってきた。その結果、電話システム及びコンピュータ通信方法は、大体において、高まるコンピュータ間の情報交換の要求を満たすべく発達してきており、具体的にはデータ伝送という一般的なニーズを満たすとともに、同時に発達しつつある技術を活用するために発展してきた。
【０００５】
例えば、コンピュータ間の通信専用の、すなわち特にコンピュータ間の通信に適応した様々な形のネットワークが開発されてきた。特にコンピュータ間通信指向型であるネットワークは、一般的に、それぞれのコンピュータに、光ファイバ・ケーブル、同軸ケーブルもしくはツイストペアケーブルのような比較的広い帯域幅を有する共通通信バックボーンへの、共有のアクセスを提供する。一般に「ノード」と称されるネットワーク化されたそれぞれのコンピュータは、通常、ある期間、各情報パケットの伝送のためにバックボーンの全帯域へのアクセスを許可され、送信側コンピュータがパケットの送信を完了すると、ネットワークに接続された他のコンピュータすなわちノードにとって、バックボーンが直ちに利用可能となる。これにより、各コンピュータはネットワークの全帯域へのアクセスを有するが、それはパケットを実際に送信している間に限られるため、多くのコンピュータが共通のバックボーンを効率的に共有することができる。このようなコンピュータ・ネットワークの一般例は、パーソナル・コンピュータ（「ＰＣ」）にコンピュータ・ネットワークを通して互いに通信し合うことを要求する多様なアプリケーションにＰＣが用いられる際の、ＰＣのネットワークである。ＰＣ及び他のコンピュータ、ノード、関連装置及びシステムを繋ぐ一般的なコンピュータ・ネットワークは、比較的近接して配置されているＰＣを相互接続するローカル・エリア・ネットワーク（「ＬＡＮｓ」）や、通常個々のＬＡＮのネットワークから成り、より広い地域にわたって通信を提供するワイド・エリア・ネットワーク（「ＷＡＮｓ」）を含んでいる。例えば、「Ｗｅｂ」は、ＰＣ、大型コンピュータ、ノード及び関連装置だけでなくＬＡＮを相互接続している、非常に大規模なＷＡＮである。
【０００６】
しかし、様々な形の電話ネットワークは、依然としてコンピュータ間の相互接続および通信のための最も一般的な方法である。例えば、電話ネットワークは、個々のコンピュータあるいはＬＡＮを接続するＷＡＮとして頻繁に用いられており、ワールド・ワイド・ウェブは本来、電話ネットワークに基づいている。現在、多くの電話ネットワークは、コンピュータ・データ及びデジタル化された音声信号の伝送用に多数のチャンネルあるいは広いチャンネルの帯域幅を提供するため、光ファイバ回線のようなブロードバンド・チャンネルを備えている。従って、様々な電話ネットワークの実施によって、より速くより効率的にデジタル情報パケットを伝送するための、インターフェイスの規格、方法、技術を確立する多大な努力が為されてきた。例えば、多くの電話システムは、現在、ブロードバンド・バックボーンなどのコンピュータ・ネットワーク技術を用いて実施され、多くの電話ネットワークも、音声情報すなわち音声信号を、コンピュータ・データ・パケットに類似したデジタル・データ・パケットにデジタル化している。コンピュータ・ネットワーク技術を電話ネットワークに適応させることにより、一回線上での多数のチャンネルの同時通信及びデジタル化された音声パケットの多数の経路を介したルーティングによって、コンピュータ情報パケットと同様に、音声情報をやり取りすることが可能になる。コンピュータに端を発した技術及び方法を電話システム及び音声通信に適応させることにより、電話ネットワークは、音声情報とコンピュータ情報の両方を同じ設備で伝えることができる。電話システムにおけるこうした発展の影響は、本来電話ネットワークを介して行われるコンピュータ間におけるワールド・ワイド・ウェブ通信の実施及び急速な拡大において見受けられる。
【０００７】
電話ネットワーク及びコンピュータ特有のネットワークのハードウェア技術の発達は、コンピュータ・ネットワークを介したデータ・パケットのより効率的な伝送のための規格及びプロトコルの開発と平行してきた。この点において、電話ネットワークに基づいているにせよ、コンピュータ間の通信専用であるかもしくは特にコンピュータ間の通信に適応させられているにせよ、あらゆるコンピュータ・ネットワークの核心は通信プロトコルである。ここで通信プロトコルとは、コンピュータ装置間のデータ転送を規定する一連の取り決めあるいは規則である。最も簡単なプロトコルはハードウェアの構成のみを規定するが、より複雑なプロトコルは、タイミング、データ・フォーマット、エラー検出と修正法、及びソフトウェアの構造を規定する。実質上、あらゆる形式のコンピュータ・ネットワークが、ネットワークを介したコンピュータ間の通信における動作の対応するレベルをプロトコルの各レイヤが規定し制御する、マルチレイヤのプロトコルを広く採用している。例えば、物理プロトコル・レイヤは、通常、動作の最下位を規定及び制御するものであり、２つの装置間のデータ・ストリームの送受信を確保する下位の物理あるいは装置レイヤ・プロトコルを含むのに対して、上位のデータ・リンク・プロトコル・レイヤは、データ・パケットの構造及び伝送を規定し管理する。伝送制御プロトコル／インターネット・プロトコル（「ＴＣＰ／ＩＰ」）のようなネットワーク及びトランスポート・レイヤ・プロトコルは、物理レイヤ・プロトコルより上位で動作し、ネットワーク自体を介するデータ伝送を支配することによって、下位において規定されるデータ・パケットの信頼性のある端末相互間の配信を確実なものにする。
【０００８】
現在、コンピュータ特有のネットワーク及び電話ネットワークの両方を介してデータの効率的な伝送を行うための、各種の工業規格プロトコルがあり、その多くはデータのパケット伝送に基づいている。電話ネットワーク及びコンピュータ特有のネットワークを含むネットワークを介したコンピュータ・データの伝送のための現存する規格及びプロトコルの例は、総合デジタル通信網（ＩＳＤＮ）を含むが、ＩＳＤＮは、接続インターフェイス、伝送プロトコル及びサービスを規格化し、統一的なデジタル回路スイッチング・ネットワークを形成している。更なる例は、デジタル・ネットワーク規格であるＩＳＤＮとは異なり、具体的にはブロードバンドの「バックボーン」を介する伝送のための伝送規格として、パケット・リレーすなわち非同期転送モード（「ＡＴＭ」）」を用いている、ブロードバンドＩＳＤＮ（「ＢＩＳＤＮ」）である。ＡＴＭは、本来、接続指向及び非接続指向サービスの両方を一定ビット速度あるいは可変ビット速度で転送し得る、接続指向的な技術である。ＡＴＭは、要求に応えて帯域を与え、プロトコルの処理を減少させる高速パケット切換法によって、全トラフィック・タイプを処理し、ネットワークを介した伝送を制御するために統計的なマルチプレクシングを用いる。
【０００９】
しかし、ネットワークを介したデータ通信についての本質的な限界が、どのネットワークにおいても利用可能な帯域幅リソースが限られる点であることは、長い間一般に認識及び理解されている。他の関連する問題には、種々の原因から生じる終端間データ伝送における遅れである、ネットワーク待ち時間及び揺らぎが含まれる。ネットワークの「待ち時間」は、ケーブルあるいは回線、スイッチング・ルータ、及び接続の各終端で実行される通信処理あるいはプロトコルといった、ネットワークの要素による固有の遅延時間を含んでいる。ネットワークの待ち時間は、特定の接続については比較的一定している傾向があるが、特定の接続によりネットワークを介して利用される具体的なルートに応じ、またそのネットワークあるいはその接続のために規定されるルートにおけるトラフィックの負荷に応じて、待ち時間は接続によって異なり得る。特に多くのプロトコルが、次のパケットが伝送される前に各パケットの受領確認を要求するため、データ、具体的にはパケット・データがネットワークを介してやり取りされる速度に現実的な制限を加えることにより、ネットワークの待ち時間は、ネットワークの全体的効率及び有効帯域幅もしくは容量に影響を与える。次に、「揺らぎ」は、時間の関数であるネットワーク待ち時間の変化として定義することができる。揺らぎは、通常予測不可能であり、色々な原因により生じ得るものであるが、ネットワークを介した接続により利用されるルートに沿ったトラフィック負荷の変動により生じることが最も多い。従って、ネットワーク接続の「揺らぎ」はパケット毎に大きく異なり、個々のパケットの独立したルーティングを可能にするシステムにおいては、より大きく異なる。揺らぎもまた、データがネットワークを介してやり取りされる速度に現実的な制限を加えることにより、ネットワークの全体的効率及び有効帯域幅もしくは容量に影響を与え、多くのコンピュータ・ネットワーク及び例えばＡＴＭプロトコルを採用しているネットワークのような非同期ネットワークにおいては、特に悪い影響を与える。
【００１０】
ネットワークの帯域幅及び容量をフルに活用するために効率的な帯域幅及びトラフィックの管理が重要であることは、以前から理解されており、利用可能なネットワークの帯域幅及び容量を管理するために、トラフィック・フロー及び混雑を制御するプロセス、帯域幅管理メカニズム、及び利用可能なネットワークの帯域幅及び容量を管理するためのルーティング・アルゴリズムの構築において、多大な努力が為されてきた。こうした開発の目標は、加えられるトラフィック負荷に拘らず、ネットワークに与えられたトラフィックに正比例する有用なレベルのトラフィックを、そのネットワークの最大伝送容量まで伝送することができ、その後、その最大のネットワーク容量で動作し続けるネットワークである。しかしながら、ネットワークにおいて達成される実際の能力は、ネットワークを実施する際の現実的な制約に関する理由及びネットワークを管理するために現在用いられている方法に特有な限界から生じる理由のため、こうした目標を遥かに下回っている。
【００１１】
例えば、ネットワークにおいて十分な能力を得る最も簡単な方法は、設備を必要以上に大きくすることである。すなわち、チャンネルの数や容量及びルーティング・スィッチのトラフィック容量を過大にして、予想されるどのような動作状態においても、ネットワークが動作の混雑レベルあるいは範囲から十分に隔たった範囲で動作することになる。しかし、コストのため、またネットワークに対するトラフィックの需要が、時の経過とともにこれまで急速に増加して予想されたネットワークへの最大負荷を超えてしまい、その結果、当初のネットワークの容量に拘らず最終的に混雑状態に至るため、この方法は一般的に不満足なものである。
【００１２】
従って、ネットワークにおける十分な能力を得る好適な方法は、ネットワークにおけるトラフィック負荷及びフローを管理及び制御するトラフィック管理法、ネットワーク帯域幅を割り当てるメカニズム、及びデータを効率的に伝送するためのプロトコルの改良に重点を絞ってきた。例えば、トラフィック・フロー及び制御手段は、通常、伝送システムのパケット伝送速度を、受信側システムが受容し得る速度と適合する速度に調整するためのフロー制御を含んでいる。そして、負荷制限メカニズムが、ネットワークに各時点において存在するパケットの数を全体的に制限することにより、チャンネル及びルーティング・スイッチの容量に対して過大な負荷を与えることを回避する一方で、負荷均衡メカニズムが、局部的な混雑を避けるためネットワークのリンク全体にわたってトラフィックを配分する。
【００１３】
しかし、トラフィック管理システム、帯域幅割り当てメカニズムあるいは通信プロトコルは、対応するのが困難なネットワークの特徴から生じる要求を満たすように構成されなければならない。例えば、ネットワーク・トラフィックは、通常、仕様通りに挙動しない。すなわち、トラフィック負荷は、予測できない時あるいは予測できない状況下で大きく変動することがあり、当初想定されたトラフィックのパラメータから大幅に逸脱してしまうこともしばしばある。そのような逸脱が続くと、トラフィック管理システムは、その新たなトラフィックのパラメータに対応するために、例えば１つ以上の新たな接続帯域幅を１つ以上の接続に割り当てなければならず、そのことが更に他の接続にも影響を与えて、それらの接続の適応すなわち修正等が必要となる。トラフィックの挙動における急激な変化へのトラフィック管理システムの適切な対応を決定することが、更なる問題を提起する。代表的な問題は、トラフィックの挙動の一時的な変化と長期的変化とを区別するために、トラフィック負荷の測定値を得てフィルタリングする問題、及び当初想定されたトラフィックのパラメータが維持される範囲であって、それを超えると新たな接続帯域幅が必要となる範囲を決定する問題である。例えば、実際のトラフィックに対して大きすぎる帯域幅は接続リソースの無駄であり、小さすぎる帯域幅は過度のパケット損失を生じさせる。しかし、一時的な条件を満たすように連続的にチャンネルの帯域を調整すると、調整の効果が現れるまでに変化してしまったかもしれない条件への連続的調整に、ネットワークのリソースを過度に消耗することになる。
【００１４】
効率的なデータ伝送のため特定のネットワークに提供されている通信プロトコルが、そのネットワークのトラフィック管理システムの動作と対立する場合には、ネットワークの問題の別の原因が生じる。この問題は、例えば、トラフィック・マネージャがネットワークの全体的な動作を最適化しようとして動作する一方で、ネットワークのユーザ達に実行されるプロトコルが、ネットワークにおける各ユーザの動作を個々に最適化しようとする場合に、対立する目標から生じるのである。例えば、上記のように、ＴＣＰ／ＩＰはかなり一般的に使用されるプロトコルである。しかし、ＴＣＰ／ＩＰは、エラー及びネットワーク全体にわたるフロー制御の問題を処理するために、「ｇｏ  ｂａｃｋ  Ｎ  メソッド」を採用している。伝送エラー、パケット損失、パケットの配信における過度の待ち時間、順序の狂ったパケット配信、あるいは受信側バッファのオーバーフローがあった場合、プロトコルは、Ｎ個の先行パケットを再送する。トラフィックの混雑から生じ得る問題に対応してＴＣＰ／ＩＰによりパケットを再送することによって、ネットワーク管理システムが処理しようとしているトラフィック負荷の混雑が、非常に増大するであろう。数人のユーザのＴＣＰ／ＩＰプロトコルが、個々の送信者あるいは受信者の状況からではなく、トラフィックの混雑から生じているデータ通信の問題に対応してパケットを再送している場合、この問題は特に深刻なものとなるであろう。
【００１５】
先行技術の様々なプロトコルのメカニズム及びネットワーク管理メカニズムを考察することによって上記のことを更に詳細に説明するため、ＴＣＰ／ＩＰ等のプロトコルの多くは、ネットワークの飽和を防ぐために、パケット優先メカニズムを実施している。例えば、「ｌｅａｋｙ  ｂｕｃｋｅｔ」アルゴリズムは、パケットが本来の伝送速度から外れると、一定時間に伝送し得る優先度の低いパケットの数を制限するため、優先度の高いトラフィックがほとんどあるいは全く遅延なく送信される。ｌｅａｋｙ  ｂｕｃｋｅｔもしくは同様なパケット優先メカニズムは、トラフィックが不適切でなく、またトラフィックが当初の伝送パラメータの適切な範囲内にある場合、このようにパケット伝送を受容可能なレベルに維持する。しかし、ネットワークのトラフィック負荷は、しばしば不適切であり、しばしば当初の伝送パラメータから大幅に逸脱したりするので、トラフィック負荷の変化に対応するための他のメカニズムが必要となる。
【００１６】
例えば、ある接続における当初の伝送パラメータからの逸脱がかなり長時間続く場合、トラフィック制御システムは、通常、新たな伝送パラメータに対応するため、その接続に新たな接続帯域幅を割り当てる。しかし、このメカニズムは、トラフィックの挙動の急激な変化と、トラフィックの挙動の長期的変化とは対照的な短期的変化の問題の両方に適応しなければならず、また、どの接続帯域幅がある時点でのトラフィックの挙動に適しているかを決定しなければならない。大きすぎる帯域幅は接続リソースを浪費し、小さすぎる帯域幅はパケット損失を生じさせる。
【００１７】
適切な接続帯域幅を決定する問題は、待ち時間、揺らぎ及び「バースト」型データの問題を考察することによって説明できよう。すなわち、例えば所与の接続を介してパケットが損失なしに伝送されており、ウィンドウ・サイズが接続帯域幅及び所与のシステムへの伝送のために指定された時間間隔と見なされる場合に、予め定義された最大ウィンドウ・サイズが適切であるとすれば、伝送データの安定したフローがＴＣＰ／ＩＰプロトコルを安定状態に置くことになる。この安定状態においては、先行するパケットの受領通知が接続の送信ノードにより接続の受信ノードから受信される度に、新たな１パケットのデータが伝送のためネットワーク上に置かれる。従って、受領通知が送信ノードに到達する速度によって、パケット伝送間の時間経過が決定される。ネットワーク帯域幅及び待ち時間が一定であれば、パケットは自由に流れ、ルータ等でのオーバーフローを緩衝するために失われるパケットはほとんどない。しかし、上記のように、トラフィック状況の変化、及び例えば短期的トラフィック状況による揺らぎを含む待ち時間の長期的及び短期的変動によって、帯域幅が再割り当てされる場合のように、多くのネットワークは接続帯域幅の長期的変化を受ける。帯域幅要求の変動は、伝送されているデータの特性からも生じ得る。例えば、映像及び音声データは、通常、大きなすき間を有して散らばっているデータ「クラスタ」として現われる。従って、音声及び映像データ・クラスタは、通常「バースト」状態で伝送され、その結果、ＴＣＰ／ＩＰのようなプロトコルは、バースト間で、利用可能な帯域幅の効率的使用をすることができない。
【００１８】
トラフィック制御システムは、一般的に、帯域幅割り当てがトラフィックの要求を満たすような調整を必要とするネットワークの領域と必要としない領域とを定義することにより、トラフィックのパラメータの変化に適応する。予測最大受容可能パケット損失が超過していること、あるいは接続上のトラフィックが伝送手段を共有している他の接続に支障をきたすであろうことを測定値が示唆している場合、帯域幅割り当てが上方に調整される。サービスの質が全てのユーザに容認されるような場合には、帯域幅要求が下方に調整される。
【００１９】
必要な帯域幅適応を決定するために、トラフィック制御システムは平均バースト時間及び平均ビット速度を測定し、統計的に信頼し得る数の未加工の測定値が得られたことを保証するため、その測定値をフィルタリングする。未加工の測定値の最小必要数及びトラフィックの平均ビット速度が、未加工の測定値を収集するのに要する時間を決定する。そして、この測定時間は、例えばｌｅａｋｙ  ｂｕｃｋｅｔ  メカニズムへの受信データ・ストリームの統計値を分析して、受信トラフィックに対するｌｅａｋｙ  ｂｕｃｋｅｔの効果を判断するのに用いることができる。そして、この効果は、ｌｅａｋｙ  ｂｕｃｋｅｔがどのように伝送を監視しているのか予測し、パケット損失の可能性を判断するのに用いることができる。
【００２０】
トラフィックのパラメータが受容できる帯域適応範囲から外れると、トラフィック制御システムは、異なった帯域幅を有する新たな接続を要求する。しかし、一般的に適応メカニズムは、測定及びフィルタリング・プロセスにおけるタイムラグのため、トラフィックのパラメータにおける上方への変化、すなわちトラフィック負荷あるいは速度の増加に適応するのに、より長い時間を要する。このため、上方あるいは下方ネットワーク帯域幅調整における過補償がしばしば生じ、またネットワーク・リソースの非効率的な使用とデータ伝送の低下のいずれかもしくはその両方が生じる。幾つかの接続について単一のプロセッサにトラフィック制御機能を監視および実行させることが一般的であり、その結果、帯域幅適応機能が不十分な処理能力によって制限される点において、この問題は更に度を増す。
【００２１】
多くのプロトコル及びネットワーク管理システムは、ネットワーク・リソースの「ウィンドウイング」、すなわちネットワークを介した通信用のシステムへの伝送時間及び帯域幅の割り当て、及びトラフィック要求が変化した際のウィンドウの調整も行っている。ＴＣＰ／ＩＰに監視される伝送の能力は、ウィンドウの増大の閾値用に決定された値、すなわちウィンドウが増大し得る速度及び最大のウィンドウ・サイズに大きく左右される。ウィンドウ・サイズが小さすぎる、すなわち閾値が低すぎると、ＴＣＰ／ＩＰは最適な能力に十分なデータを転送することができず、ウィンドウ・サイズが大きすぎると、ＴＣＰ／ＩＰがパケットを失ったりネットワークの混雑が起こったり、あるいはその両方が生じたりする。
【００２２】
例えば、ある状況下では、現在のウィンドウ・サイズが、そのリンクに最適なウィンドウ・サイズを超えるような最大ウィンドウ・サイズに増大することがあり、こうした過大なウィンドウはＴＣＰ／ＩＰが過剰な数のパケットを伝送することを可能にする。過剰なパケットは、利用可能な帯域幅及び接続の送信ノードと受信ノードの間にあるノードにおいて利用可能なバッファ・スペースに対して最適な数のパケットを超過しており、そのためシステムに過大な負荷を与える。
【００２３】
過剰なパケットが伝送される場合、ＴＣＰ／ＩＰプロトコル下でのパケットの廃棄処理において更に別の問題が生じる。例えば、ある接続の送信ノードと受信ノードの間にある最も遅い中間ノードが、余分なパケットを保持するのに十分なバッファ・スペースを有していない場合には、そのパケットが廃棄される。パケットの廃棄の結果、ＴＣＰ／ＩＰがタイムアウト及びパケットの再送を開始する。ＴＣＰ／ＩＰのバージョンに応じて、プロトコルはウィンドウ・サイズを半分に低減させるか、それぞれの廃棄されたパケットについて元のウィンドウ・サイズで再開するかのいずれかを行う。このような状況下では、ＴＣＰ／ＩＰによるこの対応が、ＴＣＰ／ＩＰがウィンドウ・サイズを増大させ、過剰なパケットが伝送され、不十分なバッファ・スペースのためにパケットが廃棄され、そしてウィンドウ・サイズが低減させられるといった繰り返しのサイクルを開始することになり、パケットのスループットの深刻な低下を招く結果となる。
【００２４】
最も遅い中間ノードが、余分なパケットを保持するのに十分なバッファ・スペースを有していないという状況において、パケットは最初のうちは廃棄されない。しかし、それに続くパケットがネットワーク上の他のノードから連続的に伝送され、飽和状態に近いバッファのために、パケットの転送速度が徐々に遅くなっていく。ある時点で、ネットワークは混雑状態となり、バッファは最終的にもうそれ以上のパケットを保存することができなくなる。するとパケットが廃棄され、上記のサイクルが始まるのである。
【００２５】
先行技術の方法における別の問題は、ＴＣＰ／ＩＰのようなウィンドウイングを利用するプロトコルの能力が、変動するウィンドウ・サイズに大きく依存している点において生じる。例えば、ＴＣＰ／ＩＰにおいては、ネットワークからデータが送信されていないときには、ウィンドウ・サイズが１に設定されており、パケットがネットワーク上を流れ始めると、ＴＣＰ／ＩＰが所定の最大値に向かってウィンドウ・サイズを増大させ始める。新たなデータが伝送されたときに、その時点でのウィンドウ・サイズが最大値であるかそれに近いと、全てのパケットが送信されるまで間断なくパケットがネットワーク上に置かれ、それ以上伝送されるパケットがなくなると、すぐにウィンドウ・サイズが１にリセットされる。しかし、このプロセスは多くの好ましくない結果をもたらすであろう。例えば、ウィンドウ・サイズが最大値であるかそれに近い場合のパケットの急速な伝送は、上記のように、ネットワークの混雑の原因となり得るパケットの「バースト」を構成する。その結果、パケットのバーストによりもたらされるネットワークの混雑のため、バーストの最後に伝送されたパケットは、ネットワークの混雑及び／あるいはバッファのオーバーフローを理由に廃棄されるであろう。更に、データが連続する分離されたブロックとして断続的に伝送される場合、伝送されたデータの各ブロックの終わりにおいて、ウィンドウ・サイズが１にリセットされるであろう。新たな各データ・ブロックに対して、ウィンドウ・サイズがこのように１で始まるため、ＴＣＰ／ＩＰは利用可能な帯域幅を十分に利用することができない。
【００２６】
ネットワークからネットワークへ情報を転送し、その間にプロトコルの物理レイヤ及びネットワーク・レイヤにおいて変換動作を行うルータの動作からも、やはり問題が生じるであろう。具体的には、物理レイヤ２８は、通常、物理的手段を介して伝送され得る最大伝送ユニット（ＭＴＵ）を特定するメディア・アクセス・レイヤ（ＭＡＣ）を含み、ここでいうＭＴＵとは、ネットワーク・セグメントが伝送することのできる伝送ユニットの最大数として定義及び説明される。従って、ＭＴＵは実質上、ネットワークの物理的手段を介して伝送され得る、またネットワーク、ルータ及びプロトコルの物理的特性に左右される、セグメントと称されることもあるデータ・ブロックあるいはデータ・ユニットの最大サイズである。従って、ＭＴＵの限界により、ルータは、ネットワークを介してパケットを転送するために、しばしば１つのパケットを一般に「フラグメント」と称される小さいユニットに変換する必要がある。
【００２７】
特に、非接続ネットワークを介して、多くの場合データグラムと呼ばれるパケットを伝送する際、ＭＴＵの厄介な問題が生じる。非接続ネットワークにおいては、あるパケットがネットワークのノード間を移動する際、接続情報がパケットに割り当てられず、パケットの宛先ノードを特定する情報のみがそのパケットに含まれている。従って、予定された結果として、各パケットは大抵、宛先ノードに到達するために１つ以上のネットワークを介して１つ以上のネットワークあるいはルートの異なった経路を経て移動することになる。データグラムが送信ノードから宛先ノードに移動する際、それぞれの中間ネットワークのＭＴＵに適合するように、データグラムが様々な量でフラグメント化されるのが一般的である。従って、インターネットのような非接続ネットワークにおけるルータは、大きなセグメントを小さなセグメントにフラグメント化するための高い処理能力を必要とし、それにより、データグラムを伝送する際の伝送オーバーヘッドや処理時間を増大させる。更に、宛先ホストは、潜在的に大きいセグメントのキャッシュをバッファして、そのセグメントを元のメッセージに再構成するために、大量の処理リソース及び時間を費やす必要がある。こうした要求から、ネットワークの待ち時間やフラグメントの様々な伝送時間による揺らぎが増大する一方、フラグメント化のために伝送されなければならない大量のパケット・ヘッダ情報が、有効なネットワーク帯域幅を事実上減少させる。
【００２８】
データグラムが本質的に大きいＭＴＵを有するルートを移動する場合、パケットをフラグメント化する必要はないであろう。しかし、フラグメント化が必要な場合、各セグメントが異なるルートを経て移動するため、非接続ネットワーク上で制御するのは困難であろう。また、ネットワークのルートが機能しなかったり誤って構成されたりすると、ネットワークの特性が変化するため、セグメントがより小さいＭＴＵを有するルートを経て送信されることになり、これによって更なるフラグメント化が必要となる。その結果、データグラムのセグメントすなわちフラグメントのルーティングが非常に複雑になり、フラグメント化を最も少なくするような適切なデータグラム・サイズを送信ホストが選択することは困難になる。従って、最適な帯域幅を維持しながら全体のフラグメント化を減少させるためにデータグラム・サイズを選択する現在の技術は、功を奏しなくなってきた。
【００２９】
ネットワーク管理のための先行技術における他の方法においては、特定のプロトコルのトランスポート・レイヤ２８は、ウィンドウ・サイズ調整プロトコルではなく「パケット測定」プロトコルを用いることができる。上記のように、ウィンドウ・サイズ調整は、先行するパケットの受領通知が接続の送信ノードにより接続の受信ノードから受領される度に、１つの新たなデータ・パケットが伝送のためネットワーク上に置かれる。これに対して、パケット測定は、ネットワークが混雑していない場合には、選択された速度でパケットを送信するよう送信ノードに指示することによって、パケットがネットワーク上に置かれる速度を制限する。パケット測定システムにおいては、当初のシステム構築時にパケット測定速度が設定され、その後も一定に保たれるが、他のシステムにおいては、変化するネットワーク状況に測定速度が適応させられる。
【００３０】
ウィンドウ・サイズ調整及びパケット測定は、相対的な長所と短所を有している。例えば、パケット測定速度が適切に設定されている場合、パケット測定は、ウィンドウ・サイズ調整システムにおいて断続的なデータ伝送により発生するバーストを回避する。また、最適パケット測定は、利用可能な帯域幅を最適に利用しながら混雑やパケット廃棄を生じさせない速度でのデータ伝送をもたらす。
【００３１】
対照的に、ウィンドウ・サイズ調整は、混雑を回避するが、伝送される各データ・ブロック毎にウィンドウ・サイズを減少させることにより帯域幅を非効率的に利用する。しかし、パケット測定に対するウィンドウ・サイズ調整の利点は、ウィンドウ・サイズ調整の方が、予定された受領通知が受信されなかった場合にパケットの伝送を直ちに止めることによって、パケットが廃棄された後に伝送される追加パケット数をよりうまく制限する場合が多いことである。これに対して、パケット測定は、２つ以上のパケットが送信された後に得られるパケット速度の測定値に依存するため、欠落している受領通知に対してメカ二ズムが反応するのが遅くなる。例えば、あるパケット測定システムにおいて、受信ノードにパケットが到着する速度及びそのパケットが処理のために受信ノードのバッファから取り出される速度が送信ノードに伝送され、その測定中及び速度情報の伝送中は、余分なパケットがネットワーク上に置かれ続けることになる。
【００３２】
しかし、ウィンドウ・サイズ調整、パケット測定及び同様なシステム及びプロトコルの経常的かつ深刻な問題は、こうしたシステムや方法が、ネットワークのパラメータに関する正確な情報と、有効であるべき適応パラメータの注意深い選択とを必要とすることである。例えば、こうしたメカニズムの多くは、最大ウィンドウ・サイズ、スタート・ウィンドウ増加閾値、急速なウィンドウ増加とより遅いウィンドウ増加とを区別する範囲、あるいはデフォルトのパケット測定速度といったパラメータにより、静的に構成されている。しかし、ネットワーク、具体的にはあらゆるネットワーク及び特にインターネットのような非接続ネットワークは非常に複雑であり、こうしたメカニズムに関する最適な動作パラメータを決定することは、非常に難しい。トラフィック負荷のようなネットワークのパラメータのばらつきや変動及びネットワークの様々なリンクあるいは接続により変化する状況によって、問題は更に複雑化する。
【００３３】
ネットワークの管理及び動作に関する先行技術における方法及びメカニズムの前述の問題は、最近のネットワーク技術の発達及び映像データの伝送等の発展しつつあるネットワークのアプリケーションによって、更に複雑化する。
【００３４】
例えば、無線ネットワークを通じたインターネットのアプリケーションが急速に普及しており、急速に増大するあらゆる形のデータ・トラフィックを運んでいるため、モバイル環境におけるデータ通信の信頼し得る性能が、極めて重要な問題になりつつある。しかし、ネットワーク・データ通信の管理のための先行技術における方法及びメカニズムは、基本的に先の有線ネットワーク・モデルに基づいており、移動可能な無線ネットワークのような新たなネットワーク技術にとって大抵は不十分なものであり、実際にそうしたネットワークの動作を低下させることも多いであろう。
【００３５】
例えば、無線環境における遅延及びパケット損失は、無線セル間のハンドオフ中の通信中断、基地ステーションの範囲外を移動するモバイル・ノードのパケット損失、無線リンク上の伝送エラーによるパケット損失といった、ネットワークの混雑とは関係のない問題によってしばしば引き起こされる。しかし、ＴＣＰ／ＩＰのようなプロトコルは、こうした遅延やパケット損失をネットワークの混雑の表れと解釈する。上記のように、ＴＣＰ／ＩＰはネットワークの混雑を推定し、失われたと見られるパケットを再送し、混雑制御手続を開始することによってパケット損失に対応することになる。このような手続は、伝送ウィンドウ・サイズの減少、ウィンドウ増加速度の制限、及び連続的タイムアウトのそれぞれを兼ねるバックオフ間隔への再送タイマーのリセットを含んでいる、あるいは含んでいてもよい。その結果、無線ネットワークが通常通りセル間のハンドオフ等のネットワークの変化を示すメカニズムを含んでいても、そうしたメカニズムは、ＴＣＰ／ＩＰのネットワーク混雑手続の開始を阻止するのに間に合うよう反応することができない場合がある。それによって、ＴＣＰ／ＩＰが、モバイル式の無線ネットワークに特有な、ネットワークの性能を低下させる短期的な無線ネットワークの問題への対応が不適切になることも多いであろう。
【００３６】
無線ネットワークが、物理的伝送エラー、アンテナの間違った配置、周囲の雑音、マルチパス干渉及びその他の要因のような、ノードの移動に起因する問題以外の更なる問題を免れないことに留意しなければならない。しかし、やはり先行技術のネットワーク管理メカニズム及びプロトコルが基本的に有線ネットワーク用に構築されたものであるがゆえに、現存するメカニズム及びプロトコルが、無線ネットワークあるいは他の新たなネットワーク技術に特有な問題に、しばしば適切に対応できないことがある。
【００３７】
それに加えて、上記の問題は、一般にマルチメディア・データと呼ばれる特定の種類のデータの通信、特にコンピュータ間あるいはコンピュータから他の種類の受信者への電話式ネットワークを介するマルチメディア・データの通信について、ネットワークの利用を妨げ、遅れさせてきた。マルチメディア・データは、一般的に、音楽、音声及び動画、すなわち「映画」のようなデジタル化された音声及び映像信号を意味する、パケット化されたデータを含むあらゆる形のデータを含むものと理解及び定義されている。こうした分野における現在の開発努力の目標は、例えば、従来のコンピュータ・データだけでなく、電話式の音声通信を行うためのコンピュータ・ネットワークの使用を可能にすることであり、最終的に音楽、「映像」、及び「映画」等の伝送及び配信を可能にすることである。
【００３８】
この点について、コンピュータ・データが、従来、「バースト型」、すなわち定義されたブロックあるいはユニットの形で存在しているため、データ「パケット」の形でネットワークを介して伝送するのに適していると見なされていることに着目する必要がある。このコンピュータ・データに関する従来の見方あるいは概念は、無論、１以上のビット、バイト、及びワードのユニットに分かれる、デジタル・コンピュータ内のデジタル・データの本来の構造からもたらされている。しかし、コンピュータ内のデータの構造は、コンピュータのデータ処理要素の内部の物理的構造、つまりデジタル・コンピュータのレジスタ、バッファ、バス等がデータを個々のビットとして保存するよう物理的に構成されていることに起因している。しかし、一旦接続が確立されれば、データは、パケットとしてのみでなく、事実上連続的なビットのストリームとして、ネットワークを介して伝送し得るし、しばしば伝送されてもいることに留意する必要がある。
【００３９】
対照的に、マルチメディア・データすなわち音声及び映像データは、本質的に「バースト型」ではなく「連続的」であると見なされ、あるいは考えられていることが多い。しかし、このようなマルチメディアの見方は必ずしも正確ではなく、ネットワークを介したマルチメディア・データの通信における現実の問題の所在を、ある程度覆い隠してしまう。例えば、音声通信の話し言葉は不連続なユニットあるいは発話、すなわち音節や単語から成るように聞こえ、音楽は音符の不連続な集まりあるいは配列から成るように聞こえる。しかし、よく考えてみると、声であれ音楽であれ、音声データが、非常に変動しやすいサイズ及び時間を有する連続的な一連のユニットではあるが、事実上、情報の連続的な流れであることが認識されよう。従って、音声データと従来のコンピュータ・データとの主要な差異は、従来のコンピュータ・データが不連続なパケットとして構成及び伝送され、またされ得るのに対して、音声データは、声であれ音楽であれ、連続的なデータ・ストリームである点である。しかし、留意すべきは、あらゆる形式の音声データが従来のコンピュータ・デジタル・データ形式、すなわちバイト及びワードにデジタル化されて保存され、おそらくデジタルからアナログへの変換をという付加的なステップを伴って、コンピュータ・データの形式でユーザに提供され得るし、しばしばそうされていることである。同様に、あらゆる形式の映像データは、多くの例において通常デジタル化され、保存されて、テレビジョン信号のラインやフレーム及びコンピュータにおけるビデオ・ドライバの出力のようなデジタル・データとして出力装置に提供され、多くの場合、「パケット化された」形で生成されて本質的に存在する。このように、音声／映像情報が本質的に連続的な形式である一方で、音声／映像データが従来のデジタル形式、すなわちデジタル・データの「パケット」として表され得るし、実際表されているのであるから、デジタル・コンピュータ・データと同様に、ネットワークを介した伝送に適していると無理なく考えられることは明らかであろう。
【００４０】
しかし、音声／映像マルチメディア・データと従来形式のコンピュータ・データとの大きな差異であり、電話ネットワーク等のネットワークを介したマルチメディア・データの通信における現在の問題の主要な原因となるのは、ネットワーク待ち時間における時間に依存する変動として先に定義された「揺らぎ」に対する、マルチメディア・データの感応性である。すなわち、一般に電話を基礎とするネットワークを含むネットワークを介して通信される従来形式のコンピュータ・データは、通常、そのデータ全体が受信された後にのみ利用されるか、あるいはネットワーク待ち時間及び揺らぎが明らかでないか、ユーザにとって問題とならないような方法で利用される。従って、ネットワークを介して従来形式のコンピュータ・データをやり取りする際にまず考慮すべきことは、伝送の信頼性及び伝送速度であって、従来形式のコンピュータ・データは揺らぎに対して比較的無頓着である。
【００４１】
これに対し、人間の目や耳は音程や音調における僅かな変化や変動、及び例えば声であれ音楽であれ、音声データの中断に対して、また映像データの提示速度における一時停止あるいは変動に対して非常に敏感である。その結果、音声／映像マルチメディア・データ、特に音声／映像マルチメディア・データのリアル・タイムの伝送及び提示は、揺らぎに対して非常に敏感であり、ネットワーク待ち時間による悪影響を受けやすい。従って、音声及び映像のマルチメディア・データをやり取りするために用いられるネットワーク及びプロトコルは、例えば、通信ネットワークに存在する待ち時間から生じる問題、つまり符号化、パケット構築、メディア・アクセス、パケット伝搬、受信側バッファリング及び復号化、及びこうした動作の一部あるいは全部における揺らぎに関する問題を、埋め合わせるか解消しなければならない。
【００４２】
近年、デジタル化された音声及び映像信号を表すマルチメディア・データのやり取りが可能であり、それによりコンピュータ・データ・ネットワークとしてのみでなく、マルチメディア及び電話ネットワークとして機能することが可能な、電話ネットワークを含むデジタル・データ・ネットワークを形成する多くの試みが為されている。しかし、前述のように、マルチメディア音声・映像信号は非常に時間及び揺らぎに敏感であり、現在のネットワーク及び伝送プロトコルが従来形式のコンピュータ・データの伝送に概ね適切であるのに対して、こうしたネットワーク及びプロトコルは、マルチメディア音声・映像データの満足のゆく通信には不十分であることが分っている。
【００４３】
従って、要するに、ネットワーク及びネットワークを介したデータの通信を管理するための先行技術の方法及びメカニズムは、多くの問題を抱えているのである。例えば、先行技術の方法及びメカニズムは、ネットワークあるいは接続にとっては外部的な要因であって、ネットワーク状況には間接的にしか関連がない、もしくはネットワーク状況には全く関連がないかもしれない要因の観測によって、そのネットワークあるいは接続内のトラフィック状況を判断し制御しようとする。例えば、送信ノードにおけるパケット廃棄率あるいはパケット再送率に関する観測結果は、帯域幅制限あるいはバッファの混雑といった要因には間接的にしか関連がないか、帯域幅制限あるいはバッファの混雑には全く関連がないかもしれない。先行技術のプロセスに内在する問題は、ネットワークあるいは接続内の状況を判断するプロセスが、一般に、ネットワークあるいは接続内の状況についてのしばしば有効でない仮定に基づいている点において、更に複雑化する。例えば、パケット廃棄率あるいはパケット再送率は、速すぎるパケット伝送速度による帯域幅制限あるいはバッファの混雑といったネットワーク状況を反映すると仮定されているが、実際には、他のトラフィックによる干渉や受信ノードにおけるデータ処理エラーあるいは制限から生じるのかもしれない。その結果、ネットワークあるいは接続内の状況を判断するために観測される要因、それらの要因から導かれる仮定、及びその結果としての適応プロセスは、しばしば実際の状況とは関連がなく、実際には、データの伝送を低下させることもある。
【００４４】
先行技術の更に別の問題は、ネットワークあるいは接続内のトラフィック及びデータ伝送を管理するために実施される方法及びメカニズムが、実際には、相互に、あるいは伝送されているデータの基本的特性あるいはその接続の特性と対立する場合もあり得ることである。例えば、１つの送信ノードのプロトコルにより行われる適応が、他の送信ノードのプロトコルにより行われる適応と競合及び対立することもある。別の例では、標準プロトコル及びメカニズムの多くが、「バースト型」データ等のある種のデータにはうまく適応せず、こうしたデータに対する先行技術のプロトコル及びメカニズムの反応が、実際には、こうしたデータの伝送を低下させることもある。他の例では、同様の理由から、先行技術の方法及びメカニズムが、無線接続のような新しいネットワーク技術の本質的な特性と対立したり、特性にすぐに適応できなかったりして、しばしばそうした非従来型の接続間のデータ伝送を低下させたり、これと対立したりする。更に別の例では、先行技術のプロトコル及びメカニズムは、データ伝送の新しいアプリケーションの要求に対処していない。例えば、先行技術のプロトコル及びメカニズムは、データ伝送速度を最大化する、あるいはパケット廃棄率あるいはパケット再送率を最小化するために動作することが多く、音声／映像伝送において顕著な揺らぎの問題に対処できないであろう。
【００４５】
本願発明は、先行技術のこれらの問題及び他の関連する問題に取り組み、解決法を提供するものである。
発明の要旨
本願発明は、パケット・データを送信する少なくとも１つの送信ノード及びパケット・データを受信する１つの受信ノードを含むデータ通信ネットワークにおいて利用される、送信ノードと受信ノードとの間の接続を介したデータ・パケット伝送を最適化するための適応パケット・メカニズム及び方法を対象としている。
【００４６】
本願発明によれば、ネットワーク状況が送信ノードと受信ノードとの間のパケット伝送の待ち時間及び揺らぎに関連する、送信ノードと受信ノードとの間の接続における、現在のネットワーク状況が定期的に測定される。そして、接続の待ち時間及び揺らぎの測定値は、送信ノードと受信ノードとの間におけるパケット・データの伝送について、最適パケット・サイズ及び最適パケット間隔を決定するために用いられる。最適パケット・サイズ及び最適パケット間隔を決定する際には、送信ノードから受信ノードに送信すべきデータの量及びタイプも考慮される。本願発明の方法及びメカニズムは、ネットワーク状況に応じて決定されたパケット・サイズ及びパケット間隔で送信ノードから受信ノードにデータ・パケットを送信するために用いることができる。
【００４７】
本願発明の第一の側面及び実施例において、本適応パケット・メカニズムは、送信ノードから受信ノードに一連のモニタ・パケットを送信するが、各モニタ・パケットは、送信ノードからそのモニタ・パケットが送信された時間を表す出発時間、そのモニタ・パケットのサイズを表すパケット・サイズ及び一連のモニタ・パケットにおけるそのモニタ・パケットの順位を表すパケット番号を含んでいる。受信ノードは、モニタ・パケットを、そのモニタ・パケットが送信ノードにおいて受信される順序で受信ノードから送信ノードに返送し、送信ノードは、受信ノードから返送されたモニタ・パケットを受信すると、既知のサイズ及び既知のパケット間伝送間隔について、ネットワーク状況が送信ノードと受信ノードとの間のパケット伝送の待ち時間及び揺らぎに関連する、送信ノードと受信ノードとの間の接続のネットワーク状況を判断する。
【００４８】
本願発明の一実施例において、モニタ・パケットによって測定されるネットワーク状況は、モニタ・パケットの伝送及び返送についての最大往復遅延時間、モニタ・パケットの伝送及び返送についての最小往復遅延時間、モニタ・パケットの平均往復遅延時間、モニタ・パケットの平均揺らぎ、及び順序の狂ったパケットの数を含んでいる。本発明の他の実施例において、モニタ・パケットによって測定されるネットワーク状況は、更に失われたパケットの数を含んでいる。本発明の更に別の実施例においては、モニタ・パケットによって測定されるネットワーク状況は、更に利用可能な帯域幅、平均揺らぎ、最大揺らぎ及び最小揺らぎを含んでいる。
【００４９】
本願発明の第一の側面によれば、ネットワーク状況は、送信ノードから受信ノードに一連のモニタ・パケットを送信することにより測定されるが、各モニタ・パケットは、送信ノードからそのモニタ・パケットが送信された時間を表す出発時間、そのモニタ・パケットのサイズを表すパケット・サイズ及び一連のモニタ・パケットにおけるそのモニタ・パケットの順位を表すパケット番号を含んでいる。受信ノードにおいて、モニタ・パケットは、そのモニタ・パケットが送信ノードにおいて受信される順序で受信ノードから送信ノードに返送される。送信ノードは、受信ノードから返送されたモニタ・パケットを受信すると、送信ノードと受信ノードとの間の接続のネットワーク状況を判断し、そのネットワーク状況から、送信ノードから受信ノードへのパケット伝送についての最適パケット・サイズ及び最適パケット間隔を決定する。
【００５０】
本願発明の別の側面においては、受信ノードが、受信したモニタ・パケットからネットワーク状況を判断し、１つ以上の状況記録にそのネットワーク状況を保存してもよい。あるいは、受信ノードが、受信ノードにおいて判断されたネットワーク状況を送信ノードに返送してもよく、その場合、送信ノードは受信ノードにおいて判断されたネットワーク状況を用いて最適パケット・サイズ及び最適パケット間隔を更新する。
【００５１】
本願発明の更に別の側面においては、パケットが送信ノードから受信ノードに送信され、受信ノードが、送信ノードから受信した各パケットに対して受領通知を送信する。送信ノードは、既知のサイズ及び既知のパケット間伝送間隔について、ネットワーク状況が送信ノードと受信ノードとの間のパケット伝送の待ち時間及び揺らぎに関連する、接続におけるネットワーク状況を判断するために、受信ノードから受信した受領通知を利用する。送信ノードは、そのネットワーク状況から、送信ノードから受信ノードへのデータ・パケット伝送についての最適パケット・サイズ及び最適パケット間隔を決定する。
【００５２】
本願発明の他の側面においては、送信ノードが一連のデータ・パケットを送信ノードから受信ノードに送信し、受信ノードが受信したデータ・パケットからネットワーク状況を判断する。受信ノードは、受信ノードにおいて判断されたネットワーク状況を送信ノードに送信し、送信ノードは、受信ノードから受信したネットワーク状況から、送信ノードから受信ノードへのデータ・パケット伝送についての最適パケット・サイズ及び最適パケット間隔を決定する。
発明の詳細な説明
Ａ．動作の一般原理
前述のように、データ・ソースとデータ受領者間のネットワーク接続を介して通信され得るデータ・トラフィックの量、及びネットワークを介してそのデータ・トラフィックを通信するのに要する時間は、接続の帯域幅によって決定される。そして、接続の帯域幅は、接続を介したデータの通信に内在する遅延によって決定され、かつ制限される。そして、ネットワークを介したデータの通信における遅延は、相対的に一定である要素及び時間により変化する要素から成るものと見なすことができる。ネットワークの「待ち時間」と呼ばれる一定的要素は、例えば、ケーブルや回線といったネットワークの要素、スイッチング・ルータ及び接続の各それぞれの端部で実行されている通信プロセスやプロトコル等による内在的な遅延時間を含んでいる。ネットワークの待ち時間は、ネットワークを介してデータが伝送され得る最大速度に事実上の制限を加えることによって、全体的な効率、有効な帯域幅あるいはネットワークの能力に影響を与えるのだが、最も低い帯域幅を有するネットワーク接続の要素によって決定されることが多い。ネットワークによる遅延の「揺らぎ」と呼ばれる時間によって変動する要素は、通常は予測不可能であり、多くの原因によって生じ得るのだが、ネットワークを介した接続により利用されるルートに沿ったトラフィック負荷の変動から生じることが最も多い。揺らぎもまた、ネットワークを介してデータが伝送され得る最大速度に事実上の制限を加えることによって、全体的な効率、有効な帯域幅あるいはネットワークの能力に影響を与えるのだが、しばしば、ネットワークあるいはネットワーク接続の有効な事実上の帯域幅を、ネットワークあるいはネットワーク接続の理論上の最大帯域幅よりはるかに低い値に制限する。また、接続において最も低い帯域幅を有する要素の帯域幅によって通常決定される、ネットワークのより一定的な待ち時間とは異なり、ネットワーク接続の揺らぎが、通常その接続に沿ったネットワーク揺らぎ要素の合計から成り、独立して変動しうることに留意する必要がある。
【００５３】
先行技術の方法及びメカニズムとは対照的に、本願発明は、先行技術の方法におけるように、パケット・エラー、パケット損失、パケット廃棄あるいはパケット再送率といった二次的要因に基づいてネットワークあるいは接続の状況を判断しようとはしないが、特定の実施例において、そうしたエラー要因が本願発明の結果を改良するために利用されることはあり得る。本願発明は、ネットワークあるいは接続のデータ伝送状況を、外部から観測されたデータのみから判断する。すなわち、本願発明は、ネットワークあるいは接続にとって内部的な状況や事象を監視しようとするのではなく、ネットワークあるいは接続を事実上「ブラック・ボックス」として扱い、データ送信機及びデータ受信機において直接入手できる、ネットワークあるいは接続に関する情報を獲得し抽出することにのみ基づいている。
【００５４】
また、先行技術の方法とは対照的に、本願発明は、ネットワークあるいは接続の内部的状況もしくは動作を制御あるいは修正しようとはせず、外部的に制御可能なデータ伝送特性の制御及び適応のみによって、観測対象のネットワークあるいは接続の状況にデータ伝送を適応させる。具体的には、本願発明は、ネットワークあるいは接続を介して利用できる最適な帯域幅を直接判断して、その利用可能な帯域幅に最適に適合するデータ伝送特性を決定しようとする。更に具体的に言えば、本願発明は、パケット・サイズ及びパケット間の間隔を制御することにより、現在のリアルタイムのネットワークあるいは接続の状況及び利用可能な帯域幅に、データ伝送を適応させるのである。利用可能な帯域幅にネットワーク通信を適応させることは、言い換えると、パケット・エラー率、パケット損失あるいはパケット廃棄という二次的影響に対処することになる。
【００５５】
本願発明によれば、ネットワークの待ち時間及び揺らぎは、接続毎にも、所与の接続内での時間においても変動するものであり、ネットワークあるいは接続の待ち時間及び揺らぎは、時間、データ・タイプあるいはトラフィック負荷といった変数に対する一次関数でないことが多い。従って、ネットワークの待ち時間及び揺らぎは非常に複雑であるか、実質上予測あるいは判断することができない。言い換えれば、待ち時間及び揺らぎを低減または制御するために、かなりの規模あるいは複雑さを有するネットワークにおける通信を管理するのに必要な、内部的動作及び状況の全てを監視あるいは制御することは、いくらよく見ても困難である。しかし、本願発明によれば、所与のネットワーク接続の待ち時間及び揺らぎとネットワーク接続の帯域幅とは、パケットの相対的サイズ及び伝送のパケットの間隔、すなわちその接続を介して連続的に伝送されるパケット間の間隔の関数であり、様々なサイズのパケットの相対的、比較的待ち時間及び揺らぎを比較することによって決定することができる。
【００５６】
本願発明が取り組むネットワークあるいは接続のこれらの側面は、２台の同一なペンティアムIII５００ＭＨｚに１２８ＭＢのメモリを搭載したソニー製ラップトップ・コンピュータの間におけるネットワーク接続であって、その２台のラップトップ・コンピュータが同一の無線電話をモデムとして用い、インターネットを介して接続されているネットワーク接続の典型的な実験に関して、図１Ａ乃至１Ｃに示されている。接続速度は、上限がほぼ毎秒１０キロビット、下限が毎秒８キロビットで、全てのテストは全データのうち１０ＫＢを転送に用いた。図１Ａ及び１Ｂで表にされている２つのテストは、１０ｍｓｅｃのパケット間の遅延をパケット間遅延として用い、２００ｍｓｅｃだけ時間が隔たっており、図１Ｃに示されている第三のテストは、２０ｍｓのパケット間遅延を用いた。テストの無数の表示と、図１Ａ乃至１Ｃに示されたテストのテスト結果が、それぞれ付録Ａ、Ｂ及びＣにおいて図表の形式で提示されている。
【００５７】
パケット・サイズがパケット損失に重大な影響を及ぼし、パケット・サイズとパケット損失との関連は、短い時間間隔においても大きく変動するので、非常に予測し難く、パケット損失は、何ミリ秒のうちに、たった１つのパケット・サイズの劇的な変動により起こったことが、これらの例から分るであろう。例えば、所与のパケット・サイズについて得られる結果が、２００ミリセカンドといった非常に短時間のうちに劇的に変わり得ること、及びこうした変化が５０から１０００バイトの広範な異なるパケット・サイズについて生じること、及び所与のパケット・サイズに関して得られる結果が、同様のネットワーク状況において逆にさえなり得ることも特筆されよう。従って、ネットワークを介したデータ伝送用のパケット・サイズとパケット損失との関連モデルが、非常に複雑かつ非常にダイナミックであり、時間の経過につれて大きく変化することは明らかである。その結果、ネットワークあるいは接続の待ち時間あるいは揺らぎは、時間、データ・タイプ、トラフィック負荷、パケット・サイズあるいはパケット間の間隔といった変数に関する一次関数でないことが多く、ネットワークの待ち時間及び揺らぎは、非常に複雑であるか事実上予測不可能である。
【００５８】
以下で説明するように、本願発明における方法及びメカニズムは、様々なサイズのパケットの相対的待ち時間及び揺らぎを比較することにより、現在のネットワーク待ち時間、揺らぎ及びトラフィック状況において、接続の最大の利用可能な帯域幅を最も効率的に使用するパケット・サイズ及びパケット間の間隔をリアルタイムで判断する。本願発明は、次に、伝送されたパケット・サイズ及びパケット間の間隔を、現在のネットワーク及び接続帯域幅についての最適条件にリアルタイムで調整する。
Ｂ．本願発明を組み込んだネットワークの概要説明（図２）
図２には、本願発明が実施される代表的なネットワーク１０の概要図が示されている。代表的なネットワーク１０は、例えば、インターネットのようなパケットに基づいたシステムであってもよいし、パケット切換ＩＰ（インターネット・プロトコル）バックボーンにリンクされた、各種のネットワークから成っていてもよい。ネットワーク１０は、回線１４により相互接続された複数のノード１２から成り、回線１４は、例えば光ファイバ・ケーブル、同軸ケーブル、電話回線、無線接続等のような、様々な形の伝送手段のいずれかであってもよい。そして、ノード１２は、コンピュータ、ネットワーク・サーバあるいはルータ、ネットワーク、あるいは例えば電話、携帯電話あるいは処理装置、テレビあるいはオーディオ・システムのようなより特化されたデータ・ディスプレイあるいは表示装置から成っていてもよい。
【００５９】
広範な形式のうちいずれかの形式のデータを有するパケット１６は、送信ノード１２Ｓと受信ノード１２Ｒの間のパケット１６伝送経路である接続１８を介して、送信ノード１２Ｓから受信ノード１２Ｒに伝達される。接続１８が回線１４及びノード１２のいかなる組合せから成っていてもよく、接続１８内のノード１２が、例えば、送信ノード１２Ｓと受信ノード１２Ｒの間に接続１８を確立するために動作するルータ、交換器、ネットワークあるいはサブ・ネットワークもしくはサーバを含んでいてもよいことは、当業者には理解されよう。接続１８、ネットワーク１０あるいはパケットがたどる経路が、フレーム・リレーあるいはＡＴＭのような各種のトポロジーに従っていてもよいことも、同じく理解されよう。また、接続１８が双方向性を有していてもよく、通常は双方向性を有しており、送信ノード１２Ｓと受信ノード１２Ｒとは、パケット１６が伝送される方向に応じて常に送信ノード１２Ｓと受信ノード１２Ｒとして変わることも理解されよう。従って、送信ノード１２Ｓ及び受信ノード１２Ｒという指定は、以下の説明における例示のためのみのものであって、所与のノード１２の構造あるいは機能を限定もしくは規定するものと受け取ったり理解したりすべきではないことも理解されよう。例えば、接続１６内のルータが、あるノード１２からパケット１６を受信し、他のノード１２へパケット１６を送信するための送信ノード１２Ｓ及び受信ノード１２Ｒの片方あるいは両方であると見なしてもよく、また本願発明の目的のためその片方あるいは両方を含んでいてもよく、本願発明は、ルータ、交換器あるいは接続１６の他の要素であるノード１２内で実施される。
【００６０】
更に、例えば、非接続ネットワーク１０において、受信ノード１２Ｒに到達するために、１つ以上のネットワークを介して１つ以上のネットワークあるいはルートの異なった経路を経て各パケット１６が移動してもよいことは、当業者には理解されよう。このようなネットワークにおいて、本願発明の目的のため、接続１６が回線１４及びルータや交換器といったノード１２の単一の経路からは成り得ず、また通常成っておらず、回線１４及びノード１２の、時間により変化する一連の経路からなっている。このような例において、また本願発明の以下の説明を目的として、こうした時間により変化する一連あるいは一組の経路は、「接続１６」と称されており、本願発明の方法及びメカニズムがこうした「非接続的接続１６」を接続１６として取り扱うことも理解されよう。要するに、言い換えれば、本願発明の方法及びメカニズムは、「非接続的接続１４」を、例えばパケット１６毎の待ち時間及び揺らぎの平均以上に大きい変化量を有する接続１６として取り扱うことになる。
【００６１】
これに関して最後に、パケット１６が、例えば音声あるいは映像情報もしくは音声及び映像情報の組合せを含む、どのような形式のデータをも含み得ることが理解されよう。このような例において、音声情報は、例えば音楽、音声通信あるいはサウンド・トラックを含み、映像情報は、例えば動画、映画あるいは映像信号を含み得る。従って、１つのノード１２から別のノードへのデータの転送あるいは伝送は、単一のパケット１６の伝送あるいは一連のパケット１６の伝送から成り得る。
【００６２】
図２に示され、また以下の説明において更に詳細に論じられているように、本願発明の方法及びメカニズムは、接続１６の待ち時間及び揺らぎの現在の状況について、送信ノード１２Ｓと受信ノード１２Ｒの間の接続１６の最大利用可能帯域幅を最も効率的に利用するよう、最適なデータ・パケット１６のサイズ及びパケット間の間隔を決定するために動作する、適応パケット・メカニズム２０において具体化されている。上記のように、この最適なパケット・サイズ及びパケット間の間隔は、結果として、所与の受信ノード１２Ｒにパケットが上手く到達する最大の可能性を生み出すことになる。以下でより詳しく説明するように、選択されたサイズのパケット１６について、接続１６の利用可能な帯域幅及び接続１６による待ち時間及び揺らぎを含む、接続１６の帯域幅により直接決定され、また接続１６の帯域幅を直接決定する、以下においてネットワーク状況と称される接続１６の状況を測定することにより、接続１６の現在の最大利用可能帯域幅及び待ち時間及び揺らぎの状況を判断するために、適応パケット・メカニズム２０が動作する。
【００６３】
現在の好適な実施例において、適応パケット・メカニズム２０は２つ以上のパケット転送エンジン（ＰＴＥ）及び１つ以上のコレクタ／コントローラ２０Ｃを含むかそれらから成っている。つまり、以下で更に詳細に説明するように、接続１８の送信ノード１２Ｓに常駐している転送エンジン２０Ｔが、１つ以上のモニタ・パケット１６Ｍのシーケンスを、接続１８の受信ノード１２Ｔに常駐している転送エンジン２０Ｔに伝送するというコレクタ／コントローラ（Ｃ／Ｃ）２０ＣＡの指令を受けて動作することができる。接続１８の転送エンジン（ＰＴＥ）２０Ｔの一方あるいは両方が、接続を介したモニタ・パケット１６Ｍの伝送特性を判断し、利用可能な帯域幅、待ち時間及び揺らぎといった接続１８の現在のネットワーク状況を推測あるいは判断する。そして、ネットワーク状況の情報がコレクタ／コントローラ（Ｃ／Ｃ）２０Ｃに提供され、コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃが、接続１８の現在のネットワーク状況に対する最適パケット・サイズ及びパケット間の間隔を決定する。
【００６４】
更に、送信ノード１２Ｓ及び受信ノード１２Ｒに常駐しているパケット転送エンジン（ＰＴＥ）２０Ｔが、すなわち伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）等のデータ伝送プロトコル・スタック・メカニズムを動作させて、送信ノード１２Ｓのデータ・ソース２２Ｓと受信ノード１２Ｒのデータ・レシピエント２２Ｒとの間で、最適パケット・サイズで最適パケット間隔の「ペイロード」データ・パケット１６Ｃをやり取りする。
【００６５】
従って、本願発明によれば、パケット転送エンジン（ＰＴＥ）２０Ｔが、送信ノード１２Ｓあるいは受信ノード１２Ｒとして機能すべきネットワーク１０の各ノードに常駐していることは明らかであろう。しかし、特定のノード１２は２つ以上のパケット転送エンジン（ＰＴＥ）２０Ｔを備えていてもよい。そのような例として、例えば、２つ以上のネットワーク１０に接続されたルータや、同時に存在する他のノード１２への複数の接続１８をサポートするサーバのような、２つ以上の接続１８をサポートする必要のあるノード１２が挙げられる。１つのコレクタ／コントローラ（Ｃ／Ｃ）２０Ｃが複数のパケット転送エンジン（ＰＴＥ）２０Ｔとともに動作し、それを制御することができるため、ネットワーク１０が、単一のコレクタ／コントローラ（Ｃ／Ｃ）２０Ｃのみを必要としていてもよいが、それぞれが複数のパケット転送エンジン（ＰＴＥ）２０Ｔをサポートする、複数のコレクタ／コントローラ（Ｃ／Ｃ）２０Ｃを備えていてもよいことも、また理解されよう。また、コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃは、パケット転送エンジン（ＰＴＥ）２０Ｔとともに、ノード１２すなわち送信ノード１２Ｓあるいは受信ノード１２Ｒのいずれかに常駐していてもよいし、パケット転送エンジン（ＰＴＥ）２０Ｔが常駐しているノード１２とは別のノード１２に常駐していてもよい。従って、ネットワーク１０におけるパケット転送エンジン（ＰＴＥ）２０Ｔ及びコレクタ／コントローラ２０Ｃの数及び構成は、例えば、送信ノード１２Ｓあるいは受信ノード１２Ｒもしくはその両方として動作すべきノード１２の数及び構成、各時点でサポートされるべき接続１８の数等に左右される。
【００６６】
更に、図２において詳細には示されていないが、送信ノード１２Ｓあるいは受信ノード１２Ｒに常駐しているパケット転送エンジン（ＰＴＥ）２０Ｔが、効率的に常駐して、送信ノード１２Ｓあるいは受信ノード１２Ｒのネットワーク・プロトコル・スタック（スタック）２４の１つのレイヤあるいは１つのレイヤの要素として機能することは、認識及び理解されよう。例えば、適応パケット・メカニズム２０の本好適な実施例では、ＴＣＰ／ＩＰのＵＤＰレイヤにおいては、パケット転送エンジン（ＰＴＥ）２０Ｔがパケット１６を伝送し、ＴＣＰ／ＩＰのＴＣＰレイヤにおいては、パケット転送エンジン（ＰＴＥ）２０Ｔがコレクタ／コントローラ（Ｃ／Ｃ）２０Ｃと通信する。しかし、適応パケット・メカニズム２０が、多種多様なプロトコルで、そうしたプロトコルの多数の異なったレイヤにおいて、ネットワーク１６を介したデータ伝送のために実行あるいは動作することは、認識及び理解されよう。パケット・サイズ及びパケット間の間隔といったプロトコルの特徴を同時運用する様式、度合い及び方法は、プロトコル間で非常に異なるが、そのようなプロトコルは関連技術、すなわち具体的なプロトコルの詳細に通じた当業者には広く知られ、理解されている。従って、本願発明の適応パケット・メカニズム２０の様々な実施例及び具体例が各プロトコルに適応できるような手段及び方法は、本文中では詳細に説明していない。
【００６７】
適応パケット・メカニズム２０の代表的な実施例の以下における説明に関しては、適応パケット・メカニズム２０の少なくとも一部のメカニズムもしくは機能は専用回路において実施され得るが、適応パケット・メカニズム２０が、通常、パーソナル・コンピュータあるいはネットワーク・サーバ等のプロセッサのプログラム制御によって実施されることに留意すべきである。しかし、データ送信機１０、データ受信機２０及び適応パケット・メカニズム３２の考え得る実施例は、当業者には周知であるため、本文中では更に詳細に説明しない。
Ｃ．適応パケット・メカニズム２０の説明（図２、３、４及び５）
１．データ通信プロトコルの総合的検討（図３、４及び５）
データ通信を可能にして実施するため、事実上、全てのネットワークが、プロトコルのレイヤがプロトコルの「スタック」としばしば称されるマルチ・レイヤ・プロトコルを採用していることは、上記で説明してきた。プロトコルの各レイヤはネットワークを介した通信における動作の対応レベルを規定及び制御しており、レイヤの数及び各レイヤにより実行される機能は、ネットワーク通信の要求により左右される。例えば、プロトコルの物理レイヤは動作の最低位を規定及び制御するものであり、通常、接続１４を介して通信しているネットワーク装置間のデータ・ストリームの送信及び受信を確保する、低位物理レイヤあるいは装置レイヤを含んでいる。高位データ・リンク・レイヤはデータ・パケットの構造及び伝送を規定及び管理し、更に高位のネットワーク及び転送レイヤはネットワークを介したデータの伝送を管理する。図３、４、５及び以下の議論は、先に「ネットワーク・プロトコル・スタック（スタック）２４」として論じられた２つの一般に使用され標準となっている代表的なプロトコルのレイヤを、手短に説明することになる。以下で論じられる２つの例は、オープン・システム相互接続（ＯＳＩ）プロトコル・モデル２４Ｏ及び伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）２４Ｔであり、どちらも、例えばインターネット通信において非常に一般的に利用されている。
【００６８】
図３及び４において一般的に示されているように、通信要求２６は、一般に、送信ノード１２Ｒにおいてプロトコル２４の最高位レイヤ２８で作り出され、続くレイヤ２８すなわちスタックを介して、プロトコル・データ・ユニット（ＰＤＵ）３０とも称されるプロトコル・パケット１６Ｐの形で伝えられてゆく。レイヤ２８は、１つ以上のサービス・アクセス・ポイント（ＳＡＰｓ）３２を介して隣接するレイヤ２８と通信し、スタック内の連続するレイヤ２８のそれぞれが、特有の情報をプロトコル・パケット１６Ｐに追加してゆく。最低位レイヤ２８において、生じたパケット１６がデータ・フレーム３４にコード化され、受信ノード１２Ｒへの伝送のためにネットワーク１０の接続１６上に置かれる。
【００６９】
データ・フレーム３４は、受信ノード１２Ｒへと接続１６を横断するが、パケット１６がプロトコル２４スタックのレイヤ２８を通って上方へと処理される際、全体のプロセスがプロトコル・パケット１６Ｐとは逆になる。スタックを上方へと移動する際、各レイヤ２８は、送信ノード１２Ｒの同位レイヤ２８によってプロトコル・パケット１６Ｐに追加された、プロトコル・パケット１６Ｐのそれぞれの要素を「剥ぎ取って」、送信ノード１２Ｒの同位レイヤ２８からの情報を受領する。
【００７０】
高位レイヤの一部が特定の例において利用されないこともあり得るが、多くの通信動作において、レイヤ２８が通過されることはなく、送信ノード１２Ｒあるいは受信ノード１２Ｒのレイヤ２８が他方の同位レイヤ２８と直接通信することはできない点に留意する必要がある。つまり、ピアツーピア・レイヤ２８通信は、プロトコル・パケット１６Ｐにメッセージを付加し、連続するレイヤ２８を介し接続１６を横断してプロトコル・パケット１６Ｐを下方に送り、その後相手側ノードの同位レイヤ２８までスタックの上方へと送ることによって成立するに過ぎない。しかし、以下で述べるように、ルータのような特定のタイプの送信ノード１８及び受信ノード２０は、プロトコル２４スタックの比較的少ないレイヤ２８、主に低位レイヤ２８内でのみ動作する。また、本願発明の適応パケット・メカニズム２０が、プロトコル２４スタックの低位レイヤ２８と結合し、相互作用し得ることにも留意する必要がある。
【００７１】
図３を参照し、まずＯＳＩプロトコル・モデル２４Ｏを考察すると、ＯＳＩプロトコル・モデル２４Ｏは、ユーザのアプリケーションから目標アプリケーションへの情報伝達において実行されるタスクの進行を規定する、７つのレイヤ２８から成っている。レイヤ２８は特定の機能を区分しており、各レイヤ２８は、明確なインターフェイスと明確に規定されたエントリ・ポイント及びエグジット・ポイントすなわちＳＡＰ３２を有している。各レイヤ２８は、それにより隣接するレイヤ２８にとって透過的であり、接続１６は送信ノード１２Ｒ及び受信ノード１２Ｒにとって「仮想的」あるいは透過的である。ＯＳＩプロトコル・モデル２４Ｏも、上記で論じたように、先行して伝送されたパケットについての受領通知パケットが受信された後にのみ、送信ノード１２Ｒによって次のパケットが伝送される「受領通知」メカニズムを具現化している。最後に、全てのネットワーク通信が、ＯＳＩプロトコル・モデル２４Ｏの全レイヤ２８まであるいは全レイヤ２８を介して広がっているわけではないことに留意すべきである。例えば、信頼性のあるＴＣＰ／ＩＰ通信を用いている様々なホストの間の通信は、ＯＳＩプロトコル・モデル２４Ｏの全レイヤ２８を横断するかもしれないが、ＩＢＭプロトコル２４を用いている同じネットワーク１０内のローカルなウィンドウズ・フォア・ワークグループ通信あるいはルータ間の通信は、データ・リンク・レイヤ２８及び物理レイヤ２８においてのみ存在するかもしれない。
【００７２】
ＯＳＩプロトコル・モデル２４Ｏの各レイヤ２８を簡単に考えてみると、最低位レイヤ２８は、伝送手段、伝送装置、バス、スター、リング及びメッシュ・トポロジー等のネットワーク１６の構造及び構成、及び伝送手段間のデータ信号といったネットワーク１０の物理特性を表す物理レイヤ２８Ａである。
【００７３】
そして、データ・リンク・レイヤ２８Ｂは、（ローカル・エリア・ネットワーク）ＬＡＮのようなネットワーク１０の通信機能を具現化する。データ・リンク・レイヤ２８Ａは、データ・ビットの基本構造の第一レベルの開始を担っており、データ・リンク・フレーム３４は、目標装置へのデータのフローを制御する。フレーム３４は、フレーム３４の開始及び終了、送信ノード１２Ｒのアドレス、受信ノード１２Ｒのアドレス及びエラーチェック法を特定する情報フィールド内に形成される。データ・リンク・レイヤ２８Ｂは、２つのサブ−レイヤとして構築され、メディア・アクセス・コントロール（ＭＡＣ）サブレイヤ２８ＢＡは、伝送データに許可を与え、衝突を解決し、トークン信号を伝達し、ポーリングすることによりメディアへのアクセスを監視するＭＡＣプロトコル２４を参照する。ＭＡＣサブ−レイヤ２８ＢＡはまた、ネットワーク上の各ステーションでの物理アドレスを特定し、それらがデータ・リンク・フレーム３４における送信元データ及び宛先データとなる。そして、ロジカル・リンク・コントロール（ＬＬＣ）サブ−レイヤ２８ＢＢは、フレーム同期化、フレーム３４内のフロー制御及びエラーチェック、及び物理レイヤ２８Ａにおかれた固有のアドレスといったデータ・リンク管理あるいは制御フィールドの一部を含む。イーサネット、トークン・リングあるいは他のＬＡＮネットワーク・システム、Ａｔｔａｃｈｅｄ  Ｒｅｓｏｕｒｃｅｓ  Ｃｏｍｐｕｔｅｒ  Ｎｅｔｗｏｒｋ（ＡＲＣＮＥＴ）、ローカルト−ク、Ｆｉｂｅｒ  Ｄｉｇｉｔａｌ  Ｄｅｖｉｃｅ  Ｉｎｔｅｒｆａｃｅ（ＦＤＤＩ）といったネットワーク１０のインフラストラクチャーの物理特性が、物理レイヤ２８において規定されており、それらの通信特性がデータ・リンク・レイヤ２８Ｂにおいて規定されている。
【００７４】
ＯＳＩプロトコル・モデル２４Ｏのネットワーク・レイヤ２８Ｃは、ネットワーク間でデータを確実に送受信するためのネットワークプロセスを担っている。例えば、ネットワーク・レイヤ２８Ｃを介し、ＴＣＰ／ＩＰを用いてルータ２４により送信され得る標準イーサネット・フレームの図表が、図５に示されている。
【００７５】
ネットワーク・レイヤ２８Ｃは、論理アドレス指定、ネットワーク・ルーティング、ネットワーク接続を監視するフロー制御、及びシーケンス及び変換機能を提供する。アドレス指定は、ネットワーク・レイヤ２８においても行われ、アドレス指定の形式は、一定のプロトコルに固有のものである。例えば、イーサネット・ワークステーションは、各ネットワーク・レイヤ２８Ｃプロトコルが異なった論理アドレス指定法を有するようなＴＣＰ／ＩＰとＮｏｖｅｌｌ  ＩＰＸ／ＳＰＸ  ネットワーク・レイヤ２８Ｃプロトコルの両方で動作する。ＴＣＰ／ＩＰ、ＵＰＤ／ＩＰ，ＩＰＸ／ＳＰＸ、  ＤＥＣＮＥＴといったネットワーク・レイヤ２８Ｃプロトコルはまた、ネットワーク１６と相互接続するために、ルータにより利用される。しかし留意すべきは、ネットワーク・レイヤ２８にまで広がらない、特定のネットワーク１０プロトコル２４がある点である。ＤＥＣＬＡＴ、ＩＢＭのＮｅｔｗｏｒｋ  Ｂａｓｉｃ  Ｉｎｐｕｔ／Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ（ＮｅｔＢＩＯＳ）、ＮｅｔＢＩＯＳ用のＩＢＭのＥｘｔｅｎｄｅｄ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ（ＮｅｔＢＥＵＩ）他が、例として挙げられる。これらのプロトコル２４は、ネットワーク・レイヤ２８Ｃについてのアドレス指定及びルーティングの規定を有していないため、異なるＬＡＮ間でのこれらのプロトコル２４の接続は、ＬＡＮブリッジあるいはＬＡＮスイッチのようなＭＡＣサブ−レイヤ２８ＢＡ装置によって達成されなければならない。
【００７６】
トランスポート・レイヤ２８Ｄは、サービス・アドレス指定、フロー制御、データグラム・セグメント化及び送信元と宛先間のエラー・チェックを提供することにより、確実なネットワーク間通信を提供する。エラー・チェックは、データ・リンク・レイヤ２８Ｂ及びセッション・レイヤ２８Ｅにおいても生じる。トランスポート・レイヤ２８Ｄの主な機能は、高位レイヤ２８から送られたデータを、セグメントと呼ばれるより小さな断片にまとめ、受信ノード１２Ｒにおいてデータが正しい順番で誤りなく再構築されるように、各セグメントにセグメント番号を割り当てることである。
【００７７】
サービス・アドレス指定は、トランスポート・レイヤ２８Ｄに特有で、トランスポート・レイヤ２８Ｄが高位レイヤ２８のネットワーク・サービスを指し示すアドレスあるいはポートを特定するものである。このレベルのアドレス指定はまた、接続識別子、すなわち接続識別子、ポート識別子、ソケット識別子、あるいは変換を追跡するのとは対照的に各要求を追跡できるトランザクション識別子を追跡することにより、ネットワーク１０に生じ得る多数の接続あるいは変換を監視する。
【００７８】
ＯＳＩプロトコル・モデル２４Ｏのセッション・レイヤ２８Ｅは、セッションへの接続を確立し、維持し、終了させる責任を負っている。セッションを管理することは、ユーザのタスクの同期化とダイアログ制御、つまり、どのプロセスがどれだけ長い時間伝送可能であるかに関係している。同期化は、チェックポイントあるいは「受領通知番号」の使用及び再送手続を含んでいる。セッション・レーヤ２８Ｅもまた、ログオン、名称認識及びセキュリティ機能を担っており、これらの機能においてはトランスポート・レイヤ２８Ｄに依存している。
【００７９】
ＯＳＩプロトコル・モデル２４Ｏのプレゼンテーション・レイヤ２８Ｆは、データが常駐しているか伝送されたホスト内の、データ形式及び構造を翻訳及び変換し、それによって、データが存在する各ホストによりデータを操作することができるようになる。プレゼンテーション・レイヤ２８Ｆによる操作は、例えば、ファイル構成、開始／終了境界、命名規則、アクセス・セキュリティ及びファイル保存法の変換を含み得る。プレゼンテーション・レイヤ２８Ｆにより行われる変換は、バイト・レベル及びキャラクタ・レベルにおいても行われ、ファイル構文変換、暗号化／復号化処理及び圧縮／解凍処理をも含み得る。例えば、プレゼンテーション・レイヤ２８Ｆは、Ａｍｅｒｉｃａｎ  Ｓｔａｎｄａｒｄ  Ｃｏｄｅ  ｆｏｒ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｉｎｔｅｒｃｈａｎｇｅ（ＡＳＣＩＩ）を用いた、１バイトのデータの最左ビットが最上位すなわち最重要ビットであるデータを、最左ビットが最下位すなわち最も重要でないビットであるＩＢＭのＥｘｔｅｎｄｅｄ  Ｂｉｎａｒｙ  Ｃｏｄｅｄ  Ｄｅｃｉｍａｌ  Ｉｎｔｅｒｃｈａｎｇｅ  Ｃｏｄｅ（ＥＢＣＤＩＣ）を用いたデータに変換することができる。
【００８０】
最後に、ＯＳＩプロトコル・モデル２４Ｏのアプリケーション・レイヤ２８Ｇは、ホスト装置のオペレーティング・システムに、メール・クライアント、ウェブ・ブラウザあるいはファイル転送といったネットワーク・サービスへの直接的なアクセスを提供する。アプリケーション・レイヤ２８Ｇは、文書処理プログラム、表計算プログラム及びその他のアプリケーション等のユーザ・アプリケーションに、ネットワーク・サービスへのインターフェイスを提供し、例えば、あるアプリケーション・プログラムがネットワーク・サーバからファイルを取得することができるようにする。
【００８１】
伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）のプロトコル２４Ｔを参照すると、図４に示されたように、ＴＣＰ／ＩＰプロトコル２４Ｔのアーキテクチャは、アプリケーション・レイヤ２８Ｈ、トランスポート・レイヤ（ＴＣＰ／ＵＤＰ）２８Ｉ、インターネット・プロトコル（ＩＰ）・レイヤ２８Ｊ及びネットワーク・レイヤ２４Ｋを含んでいる。この場合も、レイヤ２８Ｈ乃至２４Ｋのそれぞれは、ＴＣＰ／ＩＰプロトコル２４を用いてデータが伝送される際に実行される特定のタスクを表しており、連続する各レイヤ２８がデータ・パケットを受領すると、そのレイヤ２８がタスクを実行して、パケットを次のレベルへと送る。
【００８２】
ネットワーク・レイヤ２４Ｋは、ネットワーク１０通信のためのハードウェア装置や、ネットワーク１０のハードウェア・レベルにおいて通信を制御するためのプログラム及び処理法を含んでいる。ＯＳＩプロトコル・モデル２４Ｏの例におけるのと同様に、ＴＣＰ／ＩＰプロトコル２４Ｔは、例えば送信ノード１８と受信ノード２０との間のネットワーク１０を介した仮想経路、及び非同期転送モード、イーサネット、フレーム・リレーといった通信コンフィギュレーションをサポートする。
【００８３】
そして、インターネット・プロトコル（ＩＰ）・レイヤ２８Ｊは、大きく異なっていることもあるネットワーク１６上及びネットワーク１６間におけるメッセージ伝送のための規格を定義する、非接続データグラム・プロトコルを表す。パケット・アドレス指定、すなわちインターネット・プロトコル（ＩＰ）・パケットは、ネットワーク１０環境でのリンクに頼らず、同一のピアツーピア・ベースで、送信ノード１８と受信ノード２０にエラーのない伝送を行わせることができる。インターネット・プロトコル（ＩＰ）・レイヤ２４Ｊは、ゲートウェイ接続を用いて異なったプロトコル２４をサポートする異なったネットワーク間においても、通信のベースとして用いることができる。
【００８４】
ＴＣＰ／ＩＰプロトコル２４Ｔは、データが送信される前に送信ノード１２Ｒと受信ノード１２Ｒ間に接続を確立する、接続指向型パケット伝送システムである。トランスポート・レイヤ２８Ｋは、データ改悪を最小化するためのデータ・フロー速度の調整を含むデータ・フローの管理及び制御を担っており、こうした目的のため、ＴＣＰ及びＵＤＰプロトコルを含んでいる。
【００８５】
特に、トランスポート・レイヤ２８ＫのＴＣＰプロトコルは、パケット・フロー制御、パケット再送、パケット・シーケンシング及びエラー訂正のためのメカニズムを備えている。フロー制御機能においては、送信側と受信側の両方のノードが、パケット・オーバーフローの可能性を軽減するようにパケット伝送速度を制御する。更に、パケットが宛先に到達すると、受信ノードから送信ノードにパケットの受領通知が送信され、それによって、パケットがそのまま到達したことを送信者に知らせる。パケットがそのまま到達せず、送信者が一定時間内に受領通知を受け取らなかった場合、パケットは再送される。更に、パケットは番号をつけて順番に送信されるので、順序が狂った状態でパケットが送信あるいは受信された場合や、パケットを再送する必要がある場合、受信ノードはパケットを正しい順序で再構築することができる。最後に、ＴＣＰは、パケットの元々のデータ・ビットを記録している各パケットにおけるチェックサムを作成して調べることにより、エラー検出を行う。
【００８６】
トランスポート・レイヤ２８ＩのＵＤＰプロトコルは、ＴＣＰプロトコルの接続確立処理、フロー制御及び再送／エラー・チェック機能を除外することにより、伝送遅延を最小にする。ＴＣＰプロトコルにより提供される機能を欠くことによりデータが劣化するため、ＵＤＰプロトコルは、主として、ＩＰアドレス・データを送信する際などに用いられる。
【００８７】
最後に、アプリケーション・レイヤ２４Ｈは、ファイル転送、ｅ−メール、ウェブ・アプリケーション等のためのクライアント／サーバ・アプリケーション・プロトコルを確立する。こうしたクライアント／サーバ・プロトコルは、例えばリモート・コンピュータのファイル転送及びディレクトリ管理のためのファイル・トランスファー・プロトコル（ＦＴＰ）、ｅ−メール配信のためのシンプル・メール・トランスファー・プロトコル（ＳＭＴＰ）及びワールド・ワイド・ウェブ上で用いられているハイパー・テキスト・トランスポート・プロトコル２４（ＨＴＴＰ）を含んでいる。
２．適応パケット・メカニズム２０（図６Ａ，６Ｂ及び６Ｃ）
適応パケット・メカニズム２０が１つ以上のコレクタ／コントローラ２０Ｃ及び２つ以上のパケット転送エンジン（ＰＴＥ）２０Ｔを含む、あるいはそれらから成ることは、すでに説明した。パケット転送エンジン（ＰＴＥ）２０Ｔは、接続１８のネットワーク状況を判断し、これらのネットワーク状況から、所与の量及びタイプのデータについて、接続１８を介してデータ・パケットを伝送するのに最適なパケット・サイズと最適なパケット間の間隔とを決定するために、コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃの制御下で動作するが、適応パケット・メカニズム２０により調べられるネットワーク状況とは、接続の待ち時間及び揺らぎと利用可能な帯域幅に関するものである。以下で説明されるように、適応パケット・メカニズム２０は、接続１８を介したモニタ・パケット１２Ｍの伝送及び接続１８を介したデータ・パケット１２Ｄの伝送の調査を含むネットワーク状況の情報を得るために、複数のモードで動作する。以下で説明されるように、適応パケット・メカニズム２０の動作及び機能は、各ノード１２、すなわち送信ノード１２Ｓあるいは受信ノード１２Ｒもしくはその両方におけるパケット転送エンジン（ＰＴＥ）２０Ｔと、例えば送信ノード１２Ｓあるいはノード１２Ｓ及びノード１２Ｒとは別のノード１２に常駐し得るコレクタ／コントローラ（Ｃ／Ｃ）２０Ｃとを介して実現される。
【００８８】
図６Ａを参照すると、送信ノード１２Ｓと受信ノード１２Ｒとの間にある単一の接続１８に関して、適応パケット・メカニズム２０の構造及び動作が示されている。そこに示されているように、パケット転送エンジン（ＰＴＥ）２０Ｔは送信ノード１２Ｓに常駐し、以下でパケット転送エンジン（ＰＴＥ）２０ＴＳとして特定され、第二のパケット転送エンジン（ＰＴＥ）２０Ｔが受信ノード１２Ｒに常駐し、以下でパケット転送エンジン（ＰＴＥ）２０ＴＲとして特定される。図６Ａにおける、送信ノード１２Ｓ及び受信ノード１２Ｒとしてのノード１２の指定、及びパケット転送エンジン（ＰＴＥ）２０ＴＳ及びパケット転送エンジン（ＰＴＥ）２０ＴＲとしてのパケット転送エンジン（ＰＴＥ）２０Ｔの対応する指定が、本論議のためのみのものであり、限定を意図あるいは意味するものでないことは理解されよう。例えば、送信側及び送信ノード１２及びパケット転送エンジン（ＰＴＥ）２０Ｔの指定は、データ・パケットのフローが反転する場合、ノード１２間での二者間データ・パケット通信において周期的になろうし、ノード１２が１つの接続１８では送信ノード１２Ｓとして動作し、また別の接続１８では受信ノード１２Ｒとして動作することもあり得る。
【００８９】
上記のように、接続１８のパケット転送エンジン（ＰＴＥ）２０ＴＳ及びパケット転送エンジン（ＰＴＥ）２０ＴＲとともに動作し、かつそれらを制御するコレクタ／コントローラ（Ｃ／Ｃ）２０Ｃは、ネットワーク１０のどのノード１２に常駐していてもよい。従って、図６Ａでは、説明のためにのみコレクタ／コントローラ（Ｃ／Ｃ）２０Ｃが送信ノード１２Ｓに常駐しているものとして示されていること、及びこの表示が限定的であることを意図あるいは意味するものでないことは理解されよう。図６Ａに示され、また以下で更に詳細に説明されるように、コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃは、色々な形で実施され得るが、現在の接続１８の状況下における最適なパケット・サイズ及びパケット間の間隔を決定するために、パケット転送エンジン（ＰＴＥ）２０ＴＳあるいはパケット転送エンジン（ＰＴＥ）２０ＴＳとパケット転送エンジン（ＰＴＥ）２０ＴＲの組み合わせにより得られたネットワーク状況の情報と、現在実行されるべきデータ転送及び転送されるべきデータの量及びタイプに関する情報とを受領するネットワーク・アナライザ４８を含むか伴っている。以下において説明されているように、例えば、ネットワーク・アナライザ４８は、ファジー・ロジック、ニューラル・ネットワーク、あるいはニューラル・ネットワークとファジー・ロジックの組合せとして実施することができ、ネットワーク状況の情報がコレクタ／コントローラ（Ｃ／Ｃ）２０Ｃによって得られた上で利用されるモードは、部分的にはネットワーク・アナライザ４８を実施するために用いられる特定の方法によって決定される。逆に、ネットワーク・アナライザ４８を実施するために用いられる方法は、部分的には、ネットワーク状況の情報を得るのに利用しうる方法及び動作モードと、得られるネットワーク状況の情報のタイプによって決定される。
【００９０】
また、送信ノード１２Ｓあるいは受信ノード１２Ｒに常駐するパケット転送エンジン（ＰＴＥ）２０Ｔが、効果的に常駐してネットワーク・プロトコル・スタック（スタック）２４のレイヤ２８あるいはレイヤ２８の要素として機能する送信ノード１２Ｓあるいは受信ノード１２Ｒがパケット１６を形成し、送信し、受信することはすでに説明されている。例えば、適応パケット・メカニズム２０の本好適な実施例では、パケット転送エンジン（ＰＴＥ）２０Ｔは、ＴＣＰ／ＩＰのＵＤＰレイヤにおいてモニタ・パケット１６Ｍ及びデータ・パケット１６Ｃをやり取りし、ＴＣＰ／ＩＰのＴＣＰレイヤにおいてコレクタ／コントローラ２０Ｃと通信する。しかし、適応パケット・メカニズム２０が、ネットワーク１６を介したデータ転送のため、様々なプロトコルで、そうしたプロトコルの多数の異なるレイヤにおいて実行すなわち動作し得ることは、認識及び理解されよう。パケット・サイズやパケット間の間隔等のプロトコルの特徴と同時使用するためのタイプ、度合い、及び方法はプロトコル間で大きく違い得るが、こうしたプロトコルは関連技術の当業者には周知であり、十分に理解されよう。従って、本願発明のパケット転送エンジン（ＰＴＥ）２０Ｔの種々の実施例及び具体例が、各プロトコルにおいて適応及び実施されるであろう手段及び方法は、本文中では、詳しく論じられない。
【００９１】
上記のように、接続１８に関連するコレクタ／コントローラ２０Ｃ、パケット転送エンジン（ＰＴＥ）２０ＴＳ及びパケット転送エンジン（ＰＴＥ）２０ＴＲは、多数の動作モードが可能である。例えば、データ転送モードにおいて、コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃ、パケット転送エンジン（ＰＴＥ）２０ＴＳ及びパケット転送エンジン（ＰＴＥ）２０ＴＲは、接続１８を介して送信ノード１２Ｓから受信ノード１２Ｒにデータを転送するために動作する。以下で「テスト」モードと呼ばれるネットワーク・データ取得モード及びネットワーク状況判断モードにおいて、接続１８に関連するコレクタ／コントローラ２０Ｃ、パケット転送エンジン（ＰＴＥ）２０ＴＳ及びパケット転送エンジン（ＰＴＥ）２０ＴＲは、利用可能な帯域幅、待ち時間及び揺らぎといった接続１８のネットワーク状況を判断するために動作し、この情報から、所与のデータの量及びタイプについて、接続１８を介してデータ・パケット１６Ｃを通信するための、現在最適なパケット１６・サイズ及びパケット間の間隔を決定する。
【００９２】
適応パケット・メカニズム２０の動作モードを一般的に考えると、コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃ及びパケット転送エンジン（ＰＴＥ）２０ＴＳは、データが送信ノード１２Ｓから受信ノード１２Ｒに転送されるデータ転送動作モードと、ネットワーク状況に関して情報が取得されるネットワーク状況取得動作モードとの間で行き来することができる。その他のモードにおいて、適応パケット・メカニズム２０は、データ・パケット１２Ｄの伝送中に明らかになった伝送特性を調べることにより、データ転送中にネットワーク状況の情報を取得してもよい。更に別の状況では、適応パケット・メカニズム２０が、例えばネットワーク・アナライザ４８においてニューラル・ネットワークを形成したり、ネットワーク・アナライザ４８において用いるファジー・ロジック・アナライザを構成したりするために、ネットワーク状況の情報を取得するために、初期あるいは予備的ネットワーク状況取得モードで動作してもよい。その後、適応パケット・メカニズム２０は、初期あるいは予備的ネットワーク状況取得動作中に取得したネットワーク状況の情報を更新あるいは修正するために、ネットワーク状況の情報を取得するための最初の２つのモードのうちいずれかにおいて動作することになる。
【００９３】
ネットワーク状況取得動作モードにおいて、また特定のネットワーク状況取得モードに応じて、接続１８を介して送信ノード１２Ｓから受信ノード１２Ｒに伝送されたモニタ・パケット１６Ｍあるいはデータ・パケット１６Ｄのいずれかあるいは両方の伝送特性を判断することにより、接続１８のパケット転送エンジン（ＰＴＥ）２０ＴＳ及び２０ＴＲのうちの１つあるいは両方が、ネットワーク状況の情報を取得することができ、利用可能な帯域幅、待ち時間及び揺らぎといった接続１８の現在のネットワーク状況を推測あるいは判断する。上記のように、ネットワーク状況の情報はコレクタ／コントローラ（Ｃ／Ｃ）２０Ｃに提供され、そこでネットワーク・アナライザ４８が、接続１８の現在のネットワーク状況について、最適なパケット１６・サイズ及びパケット間の間隔の値を決定し、コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃが、データ転送モードにおいてこれら最適なパケット１６・サイズ及びパケット間の間隔を用いる。
【００９４】
一般に、特定の状況に対して選択されるネットワーク状況取得モードは、ネットワーク・アナライザ４８で実施されるパケット・サイズ及びパケット間の間隔決定方法と、実行されるべきデータ転送のタイプとの両方に左右される。これに関して、ネットワークを介したデータ転送は、データ・パケットのストリームがある連続した時間、実質上連続している「連続的な」ものであると特徴付けることができるか、もしくはパケットが伝送されない区間により分離されている、データ・パケットの「バースト」の伝送により特徴付けられる「バースト型」であることは既に説明した。「連続的な」転送は、例えば音声／映像情報の転送において生じるが、「バースト型」の転送は、例えばデータ・ファイルの転送において生じる。
【００９５】
以下で説明するように、本好適な実施例において、適応パケット・メカニズム２０は、幾つかの基本的ネットワーク状況取得モードにおいて動作することができ、そのモードの一部は主に「バースト型」データ転送を対象とし、他のモードは主に「連続的な」データ転送を対象としているが、他のモードは、例えばニューラル・ネットワークを形成する際やファジー・ロジック・アナライザを構成する際に利用されるネットワーク状況の情報の、予備的あるいは初期取得において用いられる。「バースト型」データ転送の場合、データ・パケット１２Ｄが伝送されず、接続１８の伝送状況に関する情報がデータ・パケット１２Ｄの観察により判断できない連続した時間があり得るか、または実際にある。このような場合、データ・パケット１２Ｄが伝送されていないときには、送信ノード１２Ｓと受信ノード１２Ｒとの間でモニタ・パケット１２Ｍのシーケンスが断続的に伝送され、接続１８のネットワーク状況は、モニタ・パケット１２Ｍの伝送特性から判断される。「連続的な」データ伝送の例において、接続１８は実質的にデータ・パケット１２Ｄの伝送で完全に占められ、ネットワーク状況は主にデータ・パケット１２Ｄの観察結果から判断される。
【００９６】
コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃやパケット転送エンジン（ＰＴＥ）２０ＴＳ及び２０ＴＲの動作モードについて詳しく論ずる前に、本好適な実施例において留意すべきは、例えば、ファイル転送あるいは連続的な音声／映像データ・ストリームの伝送等のどのタイプのデータ転送動作が行われるべきであるかと、転送されるべきデータ量とを示す、データ・ソース２２Ｓあるいは送信ノード１２Ｓの他のソースからの入力によって、動作モードがある程度制御されることである。次に、コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃは、ネットワーク状況の情報を取得する方法を含む、送信ノード１２Ｓにより要求される特定のデータ転送のための適切な動作モードを選択する。そして、コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃは、要求されたデータ転送中、パケット転送エンジン（ＰＴＥ）２０ＴＳ及びパケット転送エンジン（ＰＴＥ）２０ＴＲの動作モードを制御するために、パケット転送エンジン（ＰＴＥ）２０ＴＳ及びパケット転送エンジン（ＰＴＥ）２０ＴＲに対する制御出力３８Ｃを生成する。以下で説明するように、送信ノード１２Ｓ及び受信ノード１２Ｒとの間のパケット転送は、１つのデータ転送モードと１つ以上のネットワーク状況取得モードの両方を含み、動作に関るコレクタ／コントローラ（Ｃ／Ｃ）２０Ｃ、パケット転送エンジン（ＰＴＥ）２０ＴＳ及びパケット転送エンジン（ＰＴＥ）２０ＴＲに、データ転送中に、データ転送モードとネットワーク状況取得モードとの間で切り換わるよう要求することができる。本好適な実施例において、コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃ、パケット転送エンジン（ＰＴＥ）２０ＴＳ及びパケット転送エンジン（ＰＴＥ）２０ＴＲの動作モードは、コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃによりコレクタ／コントローラ（Ｃ／Ｃ）２０Ｃ、パケット転送エンジン（ＰＴＥ）２０ＴＳ及びパケット転送エンジン（ＰＴＥ）２０ＴＲに設定されたフラグによって決定される。
【００９７】
これに関して留意すべきは、接続１８に関連するコレクタ／コントローラ（Ｃ／Ｃ）２０Ｃ、パケット転送エンジン（ＰＴＥ）２０ＴＳ及びパケット転送エンジン（ＰＴＥ）２０ＴＲが、接続１８の現在のネットワーク状況を判断するためにネットワーク状況取得モードで動作している場合、適応パケット・メカニズム２０の動作は、スクリプト・ファイル３８によって制御されることである。図６Ａに示されているように、スクリプト・ファイル３８はコレクタ／コントローラ（Ｃ／Ｃ）２０Ｃによって読み出され、次にコレクタ／コントローラ（Ｃ／Ｃ）２０Ｃが、ネットワーク状況取得モードによって、パケット転送エンジン（ＰＴＥ）２０ＴＳへの、あるいはパケット転送エンジン（ＰＴＥ）２０ＴＳ及びパケット転送エンジン（ＰＴＥ）２０ＴＲへの対応する制御出力３８Ｃを生成する。スクリプト・ファイル３８の一例が図６Ｂに示されており、またスクリプト・ファイルは当業者にとって周知であって、スクリプト・ファイルにおける各ステップの目的及び機能が図６Ｂに示された例において説明されているので、スクリプト・ファイル３８について本文中で更に詳しく論じはしない。
【００９８】
ａ．データ転送モード
まずデータ転送モード、すなわちデータ・パケット１２Ｄが送信ノード１２Ｓから受信ノード１２Ｒに転送される方法について考察すると、送信ノード１２Ｓ及び受信ノード１２Ｒに常駐するパケット転送エンジン（ＰＴＥ）２０ＴＳ及び２０ＴＲは、送信ノード１２Ｓ及び受信ノード１２Ｒのデータ通信ネットワーク・プロトコル・スタック（スタック）２４・メカニズムとして、あるいはその一部として動作する。つまり、例えばパケット転送エンジン（ＰＴＥ）２０ＴＳ及びパケット転送エンジン（ＰＴＥ）２０ＴＲは、送信ノード１２Ｓにおけるデータ・ソース２２Ｓと受信ノード１２Ｒにおけるデータ・レシピエント２２Ｒの間で「ペイロード」データ・パケット１６Ｃを通信するための、伝送制御プロトコル／インターネット・プロトコル（「ＴＣＰ／ＩＰ」）・メカニズムのレイヤ２８として動作する。例えば、適応パケット・メカニズム２０の本好適な実施例において、パケット転送エンジン（ＰＴＥ）２０ＴＳ及び２０ＴＲは、ＴＣＰ／ＩＰのＵＤＰレイヤにおいてモニタ・パケット１６Ｍ及びデータ・パケット１６Ｃをやり取りし、ＴＣＰ／ＩＰのＴＣＰレイヤにおいてコレクタ／コントローラ（Ｃ／Ｃ）２０Ｃと通信する。
【００９９】
データ転送モードにおいて、また本願発明によれば、コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃは、送信ノード１２Ｓのパケット転送エンジン（ＰＴＥ）２０ＴＳにパケット制御３６出力を与え、パケット制御３６出力は、現在の接続１８ネットワーク状況に対する最適パケット・サイズ３６Ｓ及び最適なパケット間隔３６Ｉを指定する。パケット転送エンジン（ＰＴＥ）２０ＴＳは、データ・ソース２２Ｓから、あるいはパケット転送エンジン（ＰＴＥ）２０ＴＲが備えられているレイヤ２８に応じて、ネットワーク・プロトコル・スタック（スタック）２４の上位レイヤ２８からデータ２２Ｄを受領し、最適パケット・サイズ３６Ｓにより示されたサイズのデータ・パケット１６Ｃにデータ２２Ｄを「パケット化」する。パケット転送エンジン（ＰＴＥ）２０ＴＳは、直接、あるいはパケット転送エンジン（ＰＴＥ）２０ＴＲが備えられているレイヤ２８に応じて、ネットワーク・プロトコル・スタック（スタック）２４の下位レイヤを介して、最適なパケット間隔３６Ｉにより示されたパケット間隔で、データ・パケット１６Ｃを接続１８へと送信する。
【０１００】
データ・パケット１６Ｃは、接続１８を介して受信ノードへと転送され、パケット転送エンジン（ＰＴＥ）２０ＴＲは、直接、あるいはパケット転送エンジン（ＰＴＥ）２０ＴＲが備えられているレイヤ２８に応じて、ネットワーク・プロトコル・スタック（スタック）２４の下位レイヤを介して、接続１８からそのデータ・パケット１６Ｃを受領する。パケット転送エンジン（ＰＴＥ）２０ＴＲは、データ２２Ｄを「非パケット化」し、直接、あるいはやはりパケット転送エンジン（ＰＴＥ）２０ＴＲが備えられているレイヤ２８に応じて、ネットワーク・プロトコル・スタック（スタック）２４の上位レイヤ２８を介して、データ２２Ｄをデータ・レシピエント２２Ｒに送る。パケット転送エンジン（ＰＴＥ）２０ＴＳは、データ２２Ｄを最適パケット・サイズ３６Ｓにより示されたサイズのデータ・パケット１６Ｃにし、そのデータ・パケット１６Ｃを最適なパケット間隔３６Ｉにより示されたパケット間隔で送信する。
【０１０１】
ｂ．ネットワーク状況取得モード、モニタ・パケット１２Ｍ
第一のネットワーク・データ取得及びネットワーク状況判断モードにおいて、接続１８の送信ノード１２Ｓに常駐する転送エンジン２０ＴＳは、コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃの指示の下で、１つ以上のモニタ・パケット１６Ｍのシーケンスを、所定の間隔で、接続１８の受信ノード１２Ｔに常駐する転送エンジン２０ＴＲへと送信する。本願発明の好適な実施例において、モニタ・パケット１６Ｍの各シーケンスは、例えば１０個のモニタ・パケット１６Ｍを含んでいてもよく、シーケンスは、例えば２秒間隔で送信される。受信ノード１２Ｔに常駐するパケット転送エンジン（ＰＴＥ）２０ＴＲは、送信ノード１２Ｓに常駐するパケット転送エンジン（ＰＴＥ）２０ＴＳにモニタ・パケット１６Ｍを返送する。送信ノード１２Ｓのパケット転送エンジン（ＰＴＥ）２０ＴＳは、返送されたすなわちエコー・バックされたモニタ・パケット１２Ｍから、接続１８のネットワーク状況を直接的に表すモニタ・パケット１６Ｍの伝送特性を抽出し、利用可能な帯域幅、待ち時間及び揺らぎといった接続１８のネットワーク状況を判断して、ネットワーク状況の情報をコレクタ／コントローラ（Ｃ／Ｃ）２０Ｃに提供する。
【０１０２】
モニタ・パケット１２Ｍの送信及び返送は、例えばデータ・パケット１２Ｄの「バースト型」伝送中に、つまりデータ・パケット１２Ｄの伝送の合間に、ネットワーク状況の情報の取得に用いることができる。別の例において、モニタ・パケット１２Ｍの送信及び返送は、以下で更に説明されるように、ネットワーク・アナライザ４８に備えられたニューラル・ネットワークをトレーニングする際に利用されるネットワーク状況の情報を取得するために、ネットワーク状況の情報の予備的なあるいは初期の取得中に、もしくはネットワーク・アナライザ４８に備えられたニューラル・ネットワークの更新あるいは修正に用いられるネットワーク状況の情報を取得するためにデータを送信する際の、適応パケット・メカニズム２０の動作中に用いることができる。同じく以下で説明するように、モニタ・パケット１２Ｍの送信及び返送は、ネットワーク・アナライザ４８において用いられるファジー・ロジックの構築において使用するための、ネットワーク状況の情報を取得するために用いることができる。
【０１０３】
更にこの動作モードに関して、以下で説明するように、受信ノード１２Ｒに常駐するパケット転送エンジン（ＰＴＥ）２０ＴＲは、記録保管のため及びその後利用するために、接続１８に関するネットワーク状況の情報を抽出して保存することができ、また、この情報を結果データベース４０内のネットワーク状況記録４０Ｒの結果エントリ４０Ｅに保存することができる。このような情報は、以下に記載のように、ネットワーク・アナライザ４８に備えられたニューラル・ネットワークをトレーニングするため、もしくはネットワーク・アナライザ４８において用いられるファジー・ロジックの構築において使用するための、ネットワーク状況の情報の初期あるいは予備的な取得の際に用いることができる。更に、受信ノード１２Ｒに常駐するパケット転送エンジン（ＰＴＥ）２０ＴＲは、ネットワーク状況の情報、すなわち対応する結果エントリ４０Ｅあるいはネットワーク状況記録３０Ｒが取得されたとき、つまりネットワーク・アナライザ４８に備えられたニューラル・ネットワークを更新あるいは修正する際に用いるためリアルタイムで、それをコレクタ／コントローラ（Ｃ／Ｃ）２０Ｃに送信する。
【０１０４】
モニタ・パケット１６Ｍとデータ・パケット１６Ｃ及び本願発明の動作を一般的に簡単に考察してみると、上記のように、本願発明によれば、所与の接続１８の利用可能な帯域幅、待ち時間及び揺らぎは、パケット１６のサイズ及び連続するパケット間の間隔、すなわち接続１８を介して連続的に伝送されるパケットの間の間隔の関数である。本願発明の方法及びメカニズムは、現在のネットワーク待ち時間、揺らぎ及びトラフィック状況の下で、接続の最大の利用可能帯域幅を最も効率的に利用するパケット・サイズ及びパケット間隔を決定し、それによって有効データ転送速度を最大にする。これに関して、所与のパケット１６が、パケット１６のネットワーク伝送を管理及び制御する際に用いられる、しばしば「ヘッダ」ビットあるいはバイトと称される制御ビットあるいはバイトの１つ以上のフィールドと、パケット１６の実際の「ペイロード」である１つ以上のデータ・フィールドから成ることは、当業者には周知であり明らかである。従って、パケット１６のサイズ、すなわちパケット１６に含まれているビットあるいはバイト数は、本質的に制御あるいはヘッダ・フィールドから成る定数と、データ・フィールドから成る制御可能な数とから成っている。適応パケット・メカニズム２０が、パケット１６のサイズを接続１８の現在のネットワーク状況に対する最適値になるよう制御することは上記の通りであり、制御あるいはヘッダ・フィールドは、通常、送信ノード１２Ｓおよび受信ノード１２Ｒにより採用されている通信プロトコルによって決定されるので、適応パケット・メカニズム２０がパケット１６のデータ・フィールドのサイズを制御することによって上記の制御をしていることは明らかであろう。従って、パケット１６・サイズの範囲は、パケット１６の制御あるいはヘッダ・フィールドのサイズによって本質的に決定される最小値から、送信ノード１２Ｓおよび受信ノード１２Ｒにより採用され、ネットワーク・インターフェイス・メカニズム２６により実行される通信プロトコルによって決定される最大値に及び、制御あるいはヘッダ・フィールドとデータ・フィールドの最大容量の両方を含んでいよう。従って、本願発明の文脈の中で、パケット１６のサイズは、それがデータ・パケット１６Ｃであるにせよモニタ・パケット１６Ｍであるにせよ、制御あるいはヘッダ・フィールドとデータ・フィールドの両方の関数であることが理解されよう。
【０１０５】
図６Ａを参照すると、この動作モードの本好適な実施例において用いられ得る典型的なモニタ・パケット１６Ｍが示されている。本好適な実施例においては、パケット転送エンジン（ＰＴＥ）２０ＴＳが１０個のこうしたモニタ・パケット１２Ｍのシーケンスを伝送し、適応パケット・メカニズム２０が、例えば接続１８の平均利用可能帯域幅やモニタ・パケット１２Ｍのサンプル全体の接続１８にわたる平均の揺らぎ等に関連する情報、及びパケット１６が伝送されたシーケンスとは順序の違ったシーケンスで到着する程度に関する情報を入手することができるようになっている。図６Ａが、特に、本好適な実施例において「２８バイト・パケット」と称されるモニタ・パケット１６Ｍのデータ・フィールドあるいは「ペイロード」を示していることに留意しなければならない。図６Ａに示されているように、例えばモニタ・パケット１６Ｍは、モニタ・パケット１６Ｍのパケット転送エンジン（ＰＴＥ）２０Ｔからの出発時間を表す出発時間１２ＭＴと、モニタ・パケット１６Ｍのサイズを表すパケット・サイズ１６ＭＳと、モニタ・パケット１６Ｍのシーケンスにおけるそのモニタ・パケット１６Ｍの順位を表すパケット番号１６ＭＮとを含んでいる。モニタ・パケット１６Ｍは、例えば、現在判断あるいは予測されている最適パケット・サイズ３６Ｓと最適パケット間隔３６Ｉとを表す現在のパケット制御３６から成る、伝送パラメータ１６ＭＰを含んでいてもよい。
【０１０６】
説明したように、送信ノード１２Ｓから受信ノード１２Ｒに送信されたモニタ・パケット１６Ｍのシーケンスのモニタ・パケット１６Ｍは、パケット転送エンジン（ＰＴＥ）２０ＴＲにより受領されたとき、受領されると即座に、つまり可能な限り迅速に、かつ受領された際の順序で、パケット転送エンジン（ＰＴＥ）２０ＴＲにより送信ノード１２Ｓに返送すなわちそのままエコー・バックされる。パケット転送エンジン（ＰＴＥ）２０ＴＳは、パケット転送エンジン（ＰＴＥ）２０ＴＲから戻される返送あるいはエコー・バック・モニタ・パケット１６Ｍの到着の時間及び順序を測定し、ネットワーク状況４２を抽出及び決定する。パケット転送エンジン（ＰＴＥ）２０ＴＳは、ネットワーク状況４２をコレクタ／コントローラ（Ｃ／Ｃ）２０Ｃに提供し、以下で説明するように、コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃが、ネットワーク状況４２から、現在判断あるいは予測される最適パケット・サイズ３６Ｓと最適パケット間隔３６Ｉとを表す現在のパケット制御３６を決定する。
【０１０７】
適応パケット・メカニズム２０の一実施例において、ネットワーク状況４２は、例えば接続１８の平均利用可能帯域幅、接続１８についての揺らぎ値、順序が狂って受領されたパケット１６の発生すなわち割合といった要素に関連する、あるいはそれらを表す情報を含み、これらの要素は、モニタ・パケット１６Ｍが接続１８で送信及び受信される間に決定される。例えば、ネットワーク状況４２は、平均利用可能帯域幅４２Ａ、平均揺らぎ４２Ｂ、最大揺らぎ４２Ｃ、最小揺らぎ４２Ｄ、最大揺らぎを生じさせるパケット番号４２Ｅ及び最小揺らぎを生じさせるパケット番号４２Ｆ等を含み得る。
【０１０８】
本実施例において、平均利用可能帯域幅４２Ａはパケット転送エンジン（ＰＴＥ）２０ＴＳから送られるモニタ・パケット１２Ｍのシーケンス、及びパケット転送エンジン（ＰＴＥ）２０ＴＳにより受領されるモニタ・パケット１２Ｍのシーケンスの返送されたモニタ・パケット１２Ｍに必要な往復時間の半分で割った、モニタ・パケット１２Ｍのシーケンスで通信される全バイト数として決定される。そして、接続１８の平均往復待ち時間は、各モニタ・パケット１２Ｍのパケット転送エンジン（ＰＴＥ）２０ＴＳからの出発時間と返送されたモニタ・パケット１２Ｍのパケット転送エンジン（ＰＴＥ）２０ＴＳへの到着時間との差の平均として決定され、接続１８の片道待ち時間は往復待ち時間の半分として決定され得る。各モニタ・パケット１２Ｍの揺らぎは、様々な方法で決定することができる。例えば、揺らぎゼロについての各モニタ・パケット１２Ｍの予定到着時間は、各モニタ・パケット１２Ｍのパケット転送エンジン（ＰＴＥ）２０ＴＳからの出発時間及び接続１８の平均往復待ち時間から決定できる。各モニタ・パケット１２Ｍの予定到着時間は、次に、パケット転送エンジン（ＰＴＥ）２０ＴＳへの各モニタ・パケット１２Ｍの実際の到着時間と比較され、その差の半分がその特定のモニタ・パケット１２Ｍに関する揺らぎを表すことになる。留意すべきは、接続１８を介した待ち時間におけるパケット毎の差異である揺らぎが、連続的なパケットの到着の間隔を測定して、これらの測定値をモニタ・パケット１２Ｍにおいて特定されたパケット間隔と比較することにより、相対的に決定することもできることである。そして、平均揺らぎ４２Ｂは、個々の揺らぎ値の平均として決定することができ、最大揺らぎ４２Ｃ及び最小揺らぎ４２Ｄは、個々の揺らぎ値の最大値及び最小値として決定することができる。最後に、最大揺らぎ４２Ｃ値及び最小揺らぎ４２Ｄ値を有するモニタ・パケット１２Ｍのパケット番号１２ＭＣから、最大揺らぎを生じさせるパケット番号４２Ｅ及び最小揺らぎを生じさせるパケット番号４２Ｆを決定することができる。
【０１０９】
本願発明の別の好適な実施例において、ネットワーク状況４２は、双方向遅延最大値４２Ｇ、双方向遅延最小値４２Ｈ、双方向遅延平均値４２Ｉ、揺らぎ平均値４２Ｊ、順序の狂ったパケットの数４２Ｋ及びパケット損失の数４２Ｌから成るかもしくはこれらを含んでいてもよい。これらの値が、遅延すなわち時間が、パケット転送エンジン（ＰＴＥ）２０ＴＳからパケット転送エンジン（ＰＴＥ）２０ＴＲへ、そしてパケット転送エンジン（ＰＴＥ）２０ＴＳに戻るまでの往復時間について決定されており、その半分ではないことを除いて、ネットワーク状況４２Ａ乃至４２Ｆの値と同様である、すなわち同様なやり方で求められることが分るであろう。また、接続１８の帯域幅が、往復の最大及び最小待ち時間の間に転送されるバイト数が周知であるため、往復の最大及び最小待ち時間として間接的に表され、揺らぎが最大及び最小揺らぎによっても表されるのではなく平均の揺らぎのみによって表されていることも分るであろう。他の違いは、接続１８での伝送中におけるパケットの順序の変更が、最大及び最小揺らぎを有するパケットを示す値ではなく、順序の狂ったパケットの数によって表されること、及びネットワーク状況４２がここでは失われたパケットの数を含んでいることである。
【０１１０】
パケット転送エンジン（ＰＴＥ）２０Ｔ及びコレクタ／コントローラ（Ｃ／Ｃ）２０Ｃの他の実施例においては、パケット転送エンジン（ＰＴＥ）２０ＴＳが、出発時間やパケット・シーケンス番号情報をモニタ・パケット１２Ｍから読み出して、返送されるモニタ・パケット１２Ｍの到着時間を決定するといった基本的測定動作を行うことに留意する必要がある。パケット転送エンジン（ＰＴＥ）２０ＴＳは、基本的測定情報をコレクタ／コントローラ（Ｃ／Ｃ）２０Ｃに提供し、コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃは、平均利用可能帯域幅４２Ａ、平均揺らぎ４２Ｂ、最大揺らぎ４２Ｃ、最小揺らぎ４２Ｄ、最大揺らぎを生じさせるパケット番号４２Ｅ及び最小揺らぎを生じさせるパケット番号４２Ｆ等のネットワーク状況４２を抽出あるいは決定する動作を行う。
【０１１１】
ネットワーク状況４２の決定に関して更に留意すべきは、この動作モードの本実施例において、待ち時間、揺らぎ及び利用可能帯域幅が「往復」時間について決定されることである。すなわち、例えば帯域幅及び待ち時間は、接続１８を介して送信され接続１８を介して返送されるモニタ・パケット１２Ｍについての、往復間隔すなわち時間の半分に関して決定される。従って、接続１８を介した伝送経路の待ち時間及び揺らぎは、伝送の両方向において等しい、もしくは本願発明の目的にとっては十分に等しいと仮定されている。これに関して留意すべきは、接続１８の送信ノード１２Ｓ及び受信ノード１２Ｒに常駐するクロックが、通常同期していないか、少なくとも待ち時間及び揺らぎの差異あるいは変動を測定するのに求められる精度までは同期していないことである。パケット転送エンジン（ＰＴＥ）２０ＴＳにおいて、すなわち接続１８の片方の端部においてモニタ・パケット１２Ｍの出発時間及び到着時間を測定することによる接続１８を介した待ち時間及び揺らぎの決定は、全ての測定に単一のクロックのみを使用することによって、このように送信ノードのクロックと受信ノードのクロックの間における非同期の問題を回避あるいは軽減する。更に留意すべきは、この方法が本願発明の基本原理、すなわち、利用可能な接続１８帯域幅を最適利用するために、最適パケット・サイズ及びパケット間隔を決定するために、接続１８及び接続１８の全ての要素を「ブラック・ボックス」として扱うことに基づいていることである。
【０１１２】
Ｃ．ネットワーク状況取得、状況記録４０Ｒ及びテスト結果エントリ４０Ｅ
受信ノード１２Ｒに常駐するパケット転送エンジン（ＰＴＥ）２０ＴＲが記録のため及びその後の利用のために接続１８に関するネットワーク状況の情報を抽出して保存することができ、またこの情報を結果データベース４０のネットワーク状況記録４０Ｒに一連のテスト結果エントリ４０Ｅとして保存できることは、先に説明した。ネットワーク状況記録４０Ｒの一例が図６Ｃに示されているが、状況記録４０Ｒが、例えばネットワーク・テスト結果フィールド４４Ａ乃至４４ＡＣを含んでいてもよいことが分るであろう。図６Ｃに示された代表的なネットワーク状況記録４０Ｒにおいては、ネットワーク・テスト結果フィールド４４Ａ乃至４４ＡＣのそれぞれに保存されている値あるいは情報が定義されていることが分るであろう。更に、ネットワーク・テスト結果フィールド４４Ａ乃至４４ＡＣに存在する値あるいは情報の一部が、ネットワーク状況４２について決定された値あるいは情報と同一あるいは類似であることも分るであろう。
【０１１３】
ネットワーク・テスト結果フィールド４４Ａ乃至４４ＡＣに存在するこれら及びその他の値及び情報の決定は、図６Ｃに提示されたフィールドの値の定義及び内容を用いれば当業者にとっては明白であるため、本文中で更に説明はしない。これに関して、上記のように、接続１８の送信ノード１２Ｓ及び受信ノード１２Ｒに常駐するクロックが、通常、同期していないか、少なくとも待ち時間及び揺らぎの差異あるいは変動を測定するのに求められる精度までは同期していないことに留意すべきである。しかし、接続１８を介した待ち時間におけるパケット毎の差異である揺らぎのような特定の値は、連続的なパケットの到着の間隔を測定して、これらの測定値をモニタ・パケット１２Ｍにおいて特定されたパケット間隔と比較することにより、相対的に決定することもできる。だが、他のテスト結果フィールド４４の値あるいは情報は、接続１８のパケット転送エンジン（ＰＴＥ）２０ＴＳ側においてよりもパケット転送エンジン（ＰＴＥ）２０ＴＲ側において、より簡単に決定できる。例えば、モニタ・パケット１２Ｍは、テスト・シーケンスにおけるモニタ・パケット１２Ｍの数を識別し、受信されたパケットの数、あるいはソケットに対する読み出しもしくは読み出しを試みた数、または失われたパケットの数は、返送中のパケット損失あるいはエラーの可能性が除かれるため、パケット転送エンジン（ＰＴＥ）２０ＴＲによってより正確に決定される。テスト結果フィールド４４が、遅延あるいは揺らぎ時間における傾向のような、パケット転送エンジン（ＰＴＥ）２０ＴＳによっては取得されないが、パケット転送エンジン（ＰＴＥ）２０ＴＲにおけるモニタ・パケット１２Ｍの到着時間の比較によって取得でき、送信ノード１２Ｓのクロックと受信ノード１２Ｒのクロックの非同期に左右されない値あるいは情報を含むことも分るであろう。
【０１１４】
パケット転送エンジン（ＰＴＥ）２０ＴＲにおいて及びそれによって取得されるネットワーク状況の情報は、様々な利用の仕方がある。例えば、モニタ・パケット１２Ｍは、上記のように、適応パケット・メカニズム２０の全面的な使用動作の開始すなわち初期設定前の初期あるいは予備期間中に、接続１８に関するネットワーク状況の情報を取得するために、１つ以上の接続１８を介して伝送することができる。そして、保存されている状況記録４０Ｒ及び結果データベース４０に取得された及び結果エントリ４０Ｅは、例えばネットワーク・アナライザ４８に備えられたニューラル・ネットワークの初期トレーニングのために、あるいはネットワーク・アナライザ４８に備えられたファジー・ロジック・アナライザの構成において利用される。
【０１１５】
上記のようにモニタ・パケット１２Ｍの伝送により、パケット転送エンジン（ＰＴＥ）２０ＴＲにおいて及びそれによって取得されるネットワーク状況の情報、すなわち状況記録４０Ｒあるいは結果エントリ４０Ｅは、リアルタイムで、つまり送信ノード１２Ｓから受信ノード１２Ｒへのデータ・パケット１２Ｄの伝送に際した適応パケット・メカニズム２０の動作中に、コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃに伝送することができる。前述のように、例えばデータ・パケット１２Ｄが伝送されていない合間の「バースト型」伝送中に、これらのモニタ・パケット１２Ｍを伝送することができ、それによって、リアルタイムで、かつデータ・パケット１２Ｄの伝送に適応パケット・メカニズム２０を使用している間に、パケット転送エンジン（ＰＴＥ）２０ＴＲによるネットワーク状況の情報の取得が可能になり、その結果、状況記録４０Ｒあるいは結果エントリ４０Ｅにおける情報は、ネットワークにおける現在の状況を表す。この情報は、次に例えばネットワーク・アナライザ４８に備えられたニューラル・ネットワークを更新あるいは修正して、ニューラル・ネットワークの動作がネットワークの現在の状況を反映するよう、継続的に更新されるために使用される。パケット転送エンジン（ＰＴＥ）２０ＴＲによるネットワーク状況の情報の「リアルタイム」の取得においては、モニタ・パケット１６Ｍのシーケンスの終わりに、あるいは各モニタ・パケット１２Ｍが受領されたときに、情報がコレクタ／コントローラ（Ｃ／Ｃ）２０Ｃに伝送されてもよい。
【０１１６】
ｄ．ネットワーク状況の取得、連続的転送
上記のように、適応パケット・メカニズム２０は、接続１８がデータ・パケット１２Ｄを転送することに、長時間、実質的に完全に占有される、音声／映像データの転送のような連続的なデータ転送を実行することができる。このモードは、ネットワーク状況の情報がモニタ・パケット１２Ｍからでなくデータ・パケット１２Ｄの伝送特性から抽出され、但しモニタ・パケット１２Ｍは伝送されて、例えばデータ・パケット１２Ｄの伝送の合間すなわち一時停止中に利用されることを除き、多くの点で上記のネットワーク状況取得モードに類似している。しかし、一般に、状況記録４０Ｒあるいは結果エントリ４０Ｅに表されているネットワーク状況の情報は、上記の第一及び第二のテスト・モードにおけるのと同様に抽出あるいは決定される。例えば、データ・パケット１２Ｄは、通常、その中に含まれるバイト数、出発時間等の情報を含んでいる。パケット間隔等の他の値は、制御出力３８Ｃから取得しても、データ・パケット１２Ｄの到着時間から決定された値を平均してもよく、揺らぎの測定値は第一及び第二のテスト・モードのように決定される。しかし、このモードにおいては、パケット転送エンジン（ＰＴＥ）２０ＴＳにより取得される情報でなく、状況記録４０に表されている情報が、コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃに提供されるネットワーク状況の情報の主要なソースであることに留意すべきである。また、一定のネットワーク状況の値あるいは情報は、例えば連続する１０個のデータ・パケット１２Ｄ群用の定期的サンプルとして、もしくは新たに受領される各データ・パケット１２Ｄについて更新される「連続ウィンドウ」値として確定することができる。
【０１１７】
ｅ．シングルエンド・オペレーション
最後に、図６Ａに示されているように、適応パケット・メカニズム２０は、受信ノード１２Ｒのパケット転送エンジン（ＰＴＥ）２０ＴＲを必要としない、「シングルエンド」コンフィギュレーションで実施してもよい。図６Ａに示されているように、パケット転送エンジン（ＰＴＥ）２０ＴＲの本質的すなわち基本的な機能は、図４に示されているように、ＴＣＰ／ＩＰモデル２４Ｔのインターネット・プロトコル・レイヤ２８ＪのＩＣＭＰによって実行される。当業者にとって周知であるように、パケット１６を受信するノード１２のＩＣＭＰは、パケット１６を送信するノード１２に対して受信したパケット１６の受領通知を送信することにより、「ピング」機能を果たす。従って、この動作モードにおいて、送信ノード１２Ｓのパケット転送エンジン（ＰＴＥ）２０ＴＳにより送信された各モニタ・パケット１２Ｍあるいはデータ・パケット１２Ｄは、受信ノード１２ＲのＩＣＭＰからの受領通知によって受領が確認される。各モニタ・パケット１２Ｍあるいはデータ・パケット１２ＤについてＩＣＭＰの受領通知を受領することにより、パケット転送エンジン（ＰＴＥ）２０ＴＳは、送信されたパケット１６の往復時間プラス受領通知の返送に要する時間としての接続１８の待ち時間等のネットワーク状況４２を決定し、またこの情報からモニタ・パケット１２Ｍに関する上記の方法と同様にして各パケット１６の揺らぎ等のネットワーク状況４２を決定することができる。接続１８及びその他の要因に応じて、パケット１６が受信ノード１２Ｒによって受信される順番等の要素も決定することができよう。しかし、この方法が、例えば状況記録４０Ｒあるいは結果エントリ４０Ｅに関する上記のネットワーク状況の情報を作成するものでないことは分るであろう。ゆえに、この方法は、ニューラル・ネットワークをトレーニングあるいは更新するためのネットワーク情報が、過去の記録としてもリアルタイムの情報にしても、通常十分でないため、ネットワーク・アナライザ４８に基づくニューラル・ネットワークで実行することは難しい。従って、この方法は、以下で説明するように、ファジー・ロジック・アナライザに基づくネットワーク・アナライザ４８によって実行することが好ましい。
【０１１８】
要するに、適応パケット・メカニズム２０は、以下の例を含む様々なモードで動作することができる。
（ａ）連続モードあるいはバースト・モードのいずれかでデータ・パケット１２Ｄが伝送され、パケット・サイズ及びパケット間隔が、接続１８の待ち時間及び揺らぎと利用可能帯域幅を含み、パケット損失及び転送されるデータの量及びタイプ等の要素を含むこともあるネットワーク状況により決定されるデータ転送モード。
【０１１９】
（ｂ）ネットワーク・アナライザ４８におけるニューラル・ネットワークの初期トレーニングの際に用いるための状況記録４０及び結果エントリ４０Ｅを作成するため、初期ネットワーク状況情報取得期間の間にモニタ・パケット１２Ｍが伝送される返送モニタ・パケット１２Ｍモード。
【０１２０】
（ｃ）現在のネットワーク状況に応じて、ネットワーク・アナライザ４８におけるニューラル・ネットワークを更新あるいは修正する際に用いるための、コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃにリアルタイムで返送される状況記録４０及び結果エントリ４０Ｅを作成するため、適応パケット・メカニズム２０の動作中にモニタ・パケット１２Ｍが伝送される返送モニタ・パケット１２Ｍモード。
【０１２１】
（ｄ）適応パケット・メカニズム２０の動作中のネットワーク状況４２を作成するため、適応パケット・メカニズム２０の動作中にモニタ・パケット１２Ｍが伝送される返送モニタ・パケット１２Ｍモード。
【０１２２】
（ｅ）パケット転送エンジン（ＰＴＥ）２０ＴＳにより送信され、コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃに「リアルタイム」で返送されるデータ・パケット１２Ｄの観察された伝送特性から、リアルタイムで状況記録４０及び結果エントリ４０Ｅが作成される連続伝送モード。この情報は、例えばネットワーク・アナライザ４８におけるニューラル・ネットワークを、ネットワーク状況４２と同様に、現在のネットワーク状況に応じて更新あるいは修正する際に用いることができる。
【０１２３】
（ｆ）返送モニタ・パケット１２Ｍモードに類似しているが、パケット転送エンジン（ＰＴＥ）２０ＴＲの基本的機能が、「ピング」すなわちＴＣＰ／ＩＴモデル２４Ｔのインターネット・プロトコル・レイヤ２８ＪのＩＣＭＰの受領通知機能によって果たされる「シングル・エンド」モード。
【０１２４】
上記の要約された適応パケット・メカニズム２０の動作モードについて留意すべきは、「バースト型」データ転送時に、データ転送モードが返送モニタ・パケット１２Ｍモードと交互配置される場合のように、様々な動作モードが交互配置できる。しかし、ニューラル・ネットワークのトレーニングの際に用いる状況記録４０及び結果エントリ４０Ｅを作成するために返送モニタ・パケット１２Ｍモードが用いられる場合、あるいはデータ転送モードが連続伝送モードにおいて単独で用いられる場合のように、一定の動作モードは単独で実行される。
【０１２５】
ｅ．コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃの説明（図６Ａ）
図６Ａにおいて示されているように、接続１８の現在のネットワーク・パケット伝送特性を現す情報が、実行されるべき現在のデータ転送に関する情報とともにコレクタ／コントローラ（Ｃ／Ｃ）２０Ｃに提供され、コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃが、現在の最適パケット・サイズ３６Ｓ及び最適パケット間隔３６Ｉを示すパケット制御３６出力を生成する。先に論じたように、現在のネットワーク・パケット伝送特性は、パケット転送エンジン（ＰＴＥ）２０ＴＳからネットワーク状況４２として提供することも、パケット転送エンジン（ＰＴＥ）２０ＴＲから状況記録４０Ｒあるいは状況記録エントリ４０Ｅとして提供することもできる。図のように、現在のデータ転送要求に関する情報は、例えば要求されているデータ転送のタイプ及び伝送されるべきデータ量を特定するデータ・ソース２２Ｓからの転送要求４６に含まれている。これに関して留意すべきは、転送要求４６が、送信ノード１２Ｓの主導であるいは受信ノード１２Ｒからのデータ要求に応えて送信ノード１２Ｓにより提示されてもよいが、送信ノード１２Ｓへのデータ要求の一部として受信ノード１２Ｒにより提示されてもよいことである。いずれの場合も、実行されるべきデータ転送のタイプに応じて、パケット制御３６出力が送信ノード１２Ｓあるいは受信ノード１２Ｒに与えられる。
【０１２６】
ネットワーク状況４２が直接的あるいは間接的に相当数のネットワーク変数を表しており、これらの変数と現在の最適パケット・サイズ及びパケット間隔との関係は複雑で、非線形かつ時間により可変であることが多いことは、上記から明らかであろう。更に、その結果、これらネットワーク変数の値の可能な組合せの数は非常に多い。加えて、本願発明によれば、接続伝送状況の急速な変動性のため、適応パケット・メカニズム２０、具体的にはネットワーク・アナライザ４８が、現在の接続状況に対する最適パケット・サイズ及びパケット間隔を、「リアルタイム」で決定できることが必要である。
【０１２７】
しかし、本願発明の適応パケット・メカニズム２０の要件及び要求を満たすような、複雑に関連する多数の変数を有する問題の解を決定するための様々な方法があり、その多くは当業者には周知である。例えば、これらの方法のうちの２つは「ファジー・ロジック」及び「ニューラル・ネットワーク」と呼ばれ、それぞれ異なった特徴及び長所と短所とを有し、いずれも適応パケット・メカニズム２０によって実行される機能のために用いられる。以下で説明するが、図６Ａに示したように、本願発明のコレクタ／コントローラ（Ｃ／Ｃ）２０Ｃは、所与の一連の現在のネットワーク状況４２及び現在の転送要求４６に対する現在の最適パケット・サイズ及びパケット間隔を決定するために、ネットワーク・アナライザ４８を含んでいても、これと機能的に関連していてもよい。ネットワーク・アナライザ４８は、所与のコレクタ／コントローラ（Ｃ／Ｃ）２０Ｃに対する要求に応じて、各種の方法及びメカニズムにより実施され得る。コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃは、例えばファジー・ロジック・アナライザ４８ＣＡ、ニューラル・ネットワーク４８Ｂ、あるいはファジー・ロジック・アナライザ４８ＣＡとニューラル・ネットワーク４８Ｂとを含む複合アナライザ４８Ｃを含んでいても、これと関連していてもよい。これらの実施例のそれぞれは以下で説明されるが、これらの方法のそれぞれは当業者には周知であるため、簡単な説明のみとする。
【０１２８】
まずファジー・ロジックについて簡単に考察すると、ファジー・ロジックは、特性の集合あるいは部分集合により表されるあるエンティティが、その特性の値の関数としてのグループに属する度合いを決定する方法である。ファジー・ロジック・システムは、空間の各次元の軸が特性に対応し、グループが多次元空間の領域として定義されており、その領域が排他的であっても、ある程度重なっていてもよい多次元空間として概念化することができる。所与の特性の集合あるいは部分集合が、１つ以上のグループに属する度合いを特定する際、多次元空間はその集合あるいは部分集合の特性に対応する各軸に沿って、その集合あるいは部分集合の各特性の値によって指標化される。特性の値の交点により空間内で特定される点は、定義された領域に関して特性の集合あるいは部分集合の位置を特定し、それにより特性の集合あるいは部分集合が１つ以上のグループに属する度合いを特定する。この場合、特性の集合あるいは部分集合は、一部あるいは全てのネットワーク状況４２により定義され、グループは、混雑していない、中程度に混雑している、あるいは混雑しているというような、ネットワークあるいは接続の１つ以上の分類あるいは区分である。
【０１２９】
ファジー・ロジック・アナライザ４８Ａは、ファジー・ロジック・システムが比較的効率的で、システムの処理リソースを比較的少ししか必要とせず、比較的速い、すなわち特性値の入力を与えてからグループに属する程度を示す出力を受け取るまでの時間が比較的短いことに利点がある。短所は、ファジー・ロジック・システムが、本来そして通例、学習あるいは適応設備を有しておらず、従って時間が経つと特性値あるいは属性領域の値もしくは範囲が変化するシステムにはあまり向いていないことである。基本的に、ファジー・ロジック・システムは、状況が変化する際、自然に「トレーニングされる」すなわち「学習する」ことはできず、属性領域の再定義及びことによるとシステムの再構築により更新しなくてはならない。従って、ファジー・ロジック・システムは、小さめのシステム及び特性値あるいは特性値の範囲及び属性領域が時間とともに大きく変化しないシステムにおいて、最も効率的かつ効果的である。
【０１３０】
対照的に、ニューラル・ネットワーク４８Ｂは、ファジー・ロジック・システムと同じ機能、すなわち入力された情報に基づいた決定を表す出力を生成することの多くを行うシステムとして、特に開発及び構成されているが、最初にも時間が経つにつれても「学習する」すなわち「トレーニングされる」能力を有している。
【０１３１】
ニューラル・ネットワーク４８Ｂは、基本的に人間の脳を大まかにモデルにした意思決定システムあるいはプロセスであり、機能的には、レイヤ状に形成され、様々な構成で同じレイヤの隣接するニューロンや上位あるいは下位レイヤのニューロンとリンクされているニューロン機能から成る。各ニューロンは、入力情報または下位レイヤ・ニューロンあるいは等位の隣接ニューロンの出力毎に、一定の定義及び限定されたロジック及び意思決定動作を実行することができ、またこれらの動作の結果を出力信号として次のニューロンに送ることができる。ニューラル・ネットワークは、ニューロン間の接続の「重み」を変えることにより「教えられる」すなわち「トレーニングされる」が、この「重み」はニューロン内で保持され、従ってトレーニングあるいは「経験」の「メモリ」を効果的に備えている。ニューラル・ネットワークをトレーニングする各種の形式及び方法があるが、ニューラル・ネットワーク４８Ｂの本好適な実施例は、ネットワークが正しい決定の強化とエラー情報の両方を備え、その両方が接続及び接続の重みをニューロン間で調整するために用いられる、「バック・プロパゲーション」と称される方法を用いている。最後に留意すべきは、ニューラル・ネットワークが「オフライン」学習及び「オンライン」学習の両方のために構成されていることである。これに関して、ニューラル・ネットワークがニューロンの相互接続の重みを変えるために入力情報を利用している場合、ネットワークは「学習」あるいは「トレーニング」モードにあると称され、ネットワークが入力情報に基づいて決定を生成するために動作している場合、ネットワークは「動作」あるいは「呼び出し」モードにあると称される。「オフライン」トレーニングにおいて、「動作」あるいは「呼び出し」モード時に、ニューロンの相互接続の重みは一定つまり変化しないので、動作モードにおいて決定の根拠は変化しない。「オンライン」トレーニングにおいては、動作モード時にニューロンの相互接続の重みが変わり得るので、ネットワークは意思決定中に動的に「学習する」。
【０１３２】
ニューラル・ネットワーク４８Ｂは、システム・リソースを比較的多く消費し、トレーニングは比較的遅い。しかし、学習及び適応の能力があるため、ニューラル・ネットワーク４８Ｂは、ファジー・ロジック・アナライザ４８Ａの属性領域が最初に定義しにくい、大き目でより複雑なネットワーク・システム１０及び入力される特性の値あるいは値の範囲もしくは必要な決定の範囲が、時間が経つと大きく変化すると予想されるシステムにおいて有用である。
【０１３３】
最後に、コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃの一好適な実施例が、共同して動作するファジー・ロジック・アナライザ４８ＣＡとニューラル・ネットワーク４８ＣＢとを備えた、関連する複合アナライザ４８Ｃにより実行されていることが図６Ａに示されている。この実施例において、ファジー・ロジック・アナライザ４８ＣＡは実質的に機能上ニューラル・ネットワーク４８ＣＢに組み込まれており、ネットワーク１０の接続１８における伝送の想定される状況及び特性に対して、最初に構成される。以下で論じるように、それによって、ファジー・ロジック・アナライザ４８ＣＡが、ニューラル・ネットワーク４８ＣＢに初期トレーニング「知識」を提供することになる。
【０１３４】
動作の際、ファジー・ロジック・アナライザ４８ＣＡ及びニューラル・ネットワーク４８ＣＢは、現在のデータ転送のタイプ及び用いられている現在のテスト・モデルに応じて、ネットワーク状況４２及び状況記録２０Ｒの片方あるいは両方を、パケット転送エンジン（ＰＴＥ）２０ＴＳ及びパケット転送エンジン（ＰＴＥ）２０ＴＲの片方あるいは両方から受領し、転送要求４６を受領する。次に、複合アナライザ４８Ｃが、最適パケット・サイズ３６Ｓ及び最適パケット間隔３６Ｉを特定するパケット制御３６Ａ出力を生成し、パケット制御３６Ａ出力をコレクタ／コントローラ（Ｃ／Ｃ）２０Ｃに供給する。すると、コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃが、パケット制御３６Ａ出力を、関係するパケット転送エンジン（ＰＴＥ）２０ＴＳ及びパケット転送エンジン（ＰＴＥ）３０ＴＲの片方あるいは両方に供給する。
【０１３５】
動作の初期段階、すなわちニューラル・ネットワーク４８ＣＢが現在の接続向けにトレーニングされていない段階で、ファジー・ロジック・アナライザ４８ＣＡのパケット制御３６出力が、パケット転送エンジン（ＰＴＥ）２０ＴＳ及びパケット転送エンジン（ＰＴＥ）２０ＴＲの片方あるいは両方からのネットワーク状況４２の情報とともに、ニューラル・ネットワーク４８ＣＢをトレーニングするのに利用される。その後、ファジー・ロジック・アナライザ４８ＣＡ及びニューラル・ネットワーク４８ＣＢは、パケット転送エンジン（ＰＴＥ）２０ＴＳ及びパケット転送エンジン（ＰＴＥ）２０ＴＲからのネットワーク状況４２の入力に応じて、パケット制御３６出力を生成する。
【０１３６】
これに関して、ファジー・ロジック・アナライザ４８ＣＡのパケット制御３６Ａ出力は、ファジー・ロジック・アナライザ４８ＣＡの概して速い応答のため、データ伝送特性及びネットワーク１０及び接続１６の状況が比較的安定している間、すなわちネットワーク状況４２及び状況記録４０Ｒが比較的安定している間は、コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃへの主要な制御入力となるであろう。ネットワーク１０あるいは接続１６の状況及び特性が、パケット１６が被る待ち時間及び揺らぎの増大によって示されるように、ファジー・ロジック・アナライザ４８ＣＡの有効な対応範囲を超えて変化すると、ニューラル・ネットワーク４８ＣＢのパケット制御３６Ａ出力が、コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃの制御を引き受けることになる。ファジー・ロジック・アナライザ４８ＣＡからニューラル・ネットワーク４８ＣＢへのこうした制御の切換が、モニタ・パケット１６Ｍのパケット１６が被る待ち時間あるいは揺らぎが所定の限界を超えると、ファジー・ロジック・アナライザ４８ＣＡの出力を不可能にする内部ロジック等の、ネットワーク状況４２あるいは状況記録４０Ｒに反映されるような、色々な方法で実行され得ることは理解できよう。この場合、ニューラル・ネットワーク４８ＣＢは、パケット制御３６Ａ出力を生成するとともに、ニューラル・ネットワーク４８ＣＢの学習プロセスが新たなネットワーク１０及び接続１８の伝送状況及び特性に適応する自己学習モードに入る。この間、ニューラル・ネットワーク４８ＣＢは、ファジー・ロジック・アナライザ４８ＣＡへの更新５０Ｕ出力を生成し、更新５０Ｕ入力は、ファジー・ロジック・アナライザ４８ＣＡの能力がニューラル・ネットワーク４８ＣＢの能力と同程度になるまで、ネットワーク特性の集合及び部分集合と定義された属性領域とを更新するために、ファジー・ロジック・アナライザ４８ＣＡによって利用される。ネットワーク１０及び接続１６の伝送状況及び特性が一旦比較的安定してしばらくすると、通常、これと逆の制御の切換が起こることは理解されよう。このとき、ファジー・ロジック・アナライザ４８ＣＡは、コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃの主要な制御を引き受けることができる。
【０１３７】
ニューラル・ネットワーク４８Ｂとして、あるいは複合アナライザ４８Ｃのニューラル・ネットワーク４８ＣＢとして実行され得るバック・プロパゲーション・ニューラル・ネットワークの本例を考えると、そうしたネットワークは、それぞれ入力レイヤ、中間レイヤ及び出力レイヤとして示される３つのレイヤにおいて実行される。入力レイヤは、ニューラル・ネットワークがパケット制御３６Ａ出力を生成する基となる情報を表しかつ構成する入力変数を受領するが、これら変数は好ましくは最適パケット・サイズ３６Ｓ及び最適パケット間隔３６Ｉを予測するのに必要な最小数の変数から成るであろう。本実施例において、例えば入力レイヤは転送タイプ及びデータ・ボリュームに関する情報を転送要求から受領することもできる。そして、中間レイヤは、最適パケット・サイズ３６Ｓ及び最適パケット間隔３６Ｉを決定するのに必要な動作の大半を行う重み付けされたニューロンから成り、出力レイヤは、パケット制御３６Ａ出力として、最適パケット・サイズ３６Ｓ及び最適パケット間隔３６Ｉの実際の値を生成する。ニューラル・ネットワークへのその他の入力は、通常、接続１６の能力、状況及び特性を現すネットワーク状況４２及び状況記録４０Ｒのようなトレーニング入力であろう。これらの入力は、ニューラル・ネットワークがパケット制御３６Ａ出力の生成を評価し、ニューラル・ネットワークが「学習する」ことを可能にする基準を含んでいる。
【０１３８】
最後に、適応パケット・メカニズム２０が、それぞれ送信ノード１２Ｓと受信ノード１２Ｒとの間のネットワークを介した伝送経路を備えた複数の接続１８について、同時に上記の動作を行い得ることは、当業者には理解されよう。他の実施例において、また適応パケット・メカニズム２０の実施の設定に応じて、ネットワーク・システム１０の送信ノード１２Ｓ及び受信ノード１２Ｒは、それぞれが送信ノード１２Ｓ及び受信ノード１２Ｒの１つ以上の組あるいはグループの間で動作し、１つ以上の接続１８を管理する、複数の適応パケット・メカニズム２０を含んでいてもよい。最後に、上記のように、コレクタ／コントローラ（Ｃ／Ｃ）２０Ｃは、パケット転送エンジン（ＰＴＥ）２０Ｔを含むノード１２に常駐する必要はなく、送信ノード１２Ｓ及び受信ノード１２Ｒとは別のノード１２に常駐してもよい。
【０１３９】
３．適応パケット・メカニズム２０の適用の代表的実施例（図７Ａ及び７Ｂ）
特に適応パケット・メカニズム２０の各種の具体例及び実施例として、本願発明の方法及び装置の構造及び動作と少なくとも幾つかの実施状況を説明してきたので、以下では本願発明のある特定の代表的実施例について論じ説明する。
【０１４０】
例えば、図７Ａを参照すると、ここには、ネットワーク１０のノード１２に常駐する各種アプリケーション・プログラムの間で転送されるパケットのサイズを動的に最適化するために、ネットワーク化されたシステムにおいて動作するパケット・グルーマ５０としての、本願発明の実施例及び具体例が示されている。パケット・グルーマ５０は、例えば２．４ＧＨｚの帯域で動作する例えば８０２．１１（ｂ）あるいは８０２．１１無線ローカル・エリア・ネットワークにおいて、パケット転送を最適化するために通常実施され、それによってＩＰ接続のデータ・スループット、レンジ及び電力消費を向上させる。図７Ｂに示されているように、このような接続は、例えばＰＣ、ラップトップ・コンピュータ、パームトップ・コンピュータあるいはＰＡ等の装置を、例えば携帯電話や携帯電話ネットワークを介して、同様な装置、サーバ・システムあるいは他のデータ通信システムに接続するために実施される。
【０１４１】
以下の議論から分るように、パケット・グルーマ５０としての本願発明の実施例は、配信制御機能（ＤＣＦ）がＭＡＣレイヤ配信プロトコルに基づく自動反復要求（ＡＲＱ）機能である、こうしたシステムの配信制御機能（ＤＣＦ）の特性によって、データ・フラグメントすなわちフラグメント化されたパケットの配信が保証されるため、８０２．１１タイプのシステムに特によく適している。従って、８０２．３（イーサネット）ＭＡＣ環境においてはフラグメントの配信が保証されておらず、１つのフラグメントが「失われた」場合に１つの伝送における全てのフラグメントを再送する必要があるため、システムの効率に重大な影響を与えるのに対して、あるフラグメントが「失われた」場合にそのフラグメントのみを再送すればよい。
【０１４２】
図７Ａに示されているように、それぞれ適応ノード１２Ａ及びパッシブ・ノード１２Ｐに常駐するアプリケーション・プログラム（アプリケーション）５２Ｓ及び５２Ｒは、ネットワーク１０の接続１８及びこの目的のためのノード１２に常駐する各ネットワーク・プロトコル・スタック（スタック）２４を介して通信する。パケット・グルーマ５０のこの説明のため、及び以下に記載された理由のため、パケット・グルーマ５０が適応ノード１２Ａに常駐してこのノードから伝送されるパケット１６のサイズを、接続１８についての最適パケット・サイズ及び接続１８の現在の伝送状況に「調整する」あるいは「適応させる」ので、適応ノード１２Ａは「アクティブ」ノード１２と呼ばれる。対照的に、以下において更に詳細に記載されているように、パッシブ・ノード１２Ｐはパケット・グルーマ５０の要素を含んでおらず、従来の普通の動作ノード１２である。しかしパッシブ・ノード１２Ｐは、その中のスタック２４による通常の動作によって適応ノード１２Ａにより決定されたパケット・サイズに自動的に適応し、適応ノード１２Ａにより決定された最適パケット・サイズの使用に自動的に適応するため、パッシブ・ノード１２Ｐは適応ノード１２Ａに対する受動的パートナーである。
【０１４３】
図３及び４、及びそれらに関する説明及び議論に関連して先に詳細に説明したように、各スタック２４は、各レイヤ２８の特定の機能、目的、構造及び動作が、ネットワーク・プロトコルあるいは内部で実行されるプロトコル及び各スタック２４の必要な機能及び動作によって決まる、複数の機能レイヤ２８から成る。しかし、この説明の目的のため、スタック２４は、通常、プロトコル・スタック２４とデバイス・ドライバ５４Ｄとアプリケーション５２、及びプロトコル・スタック２４が、接続１８及びアプリケーション５２がパケット１６を伝送する別のノード１２と通信する際に介する関連ネットワーク・インターフェイス５４Ｉとを含むものとして表すこともできる。これに関して留意すべきは、ネットワーク・インターフェイス５４Ｉが、通常、接続１８への信号を駆動し、接続からの信号を受信するハードウェア回路から成り、デバイス・ドライバ５４Ｄが通常ネットワーク・インターフェイス５４Ｉを制御するルーティン、プログラム及びプロトコルから成ることである。また、デバイス・ドライバ５４Ｄとネットワーク・インターフェイス５４Ｉのいずれかもしくはその両方は、スタック２４の構成要素と見なすこともできるが、本論議の上で、ここでは別々の構成要素として示されている。デバイス・ドライバ５４Ｄ及びネットワーク・インターフェイス５４Ｉの代表例は、図３及び４に示されたレイヤ２８Ａ、２８Ｂ、２８Ｋ、２８Ｊの説明に関連して本文中に見受けられよう。
【０１４４】
本願発明の適応パケット・メカニズム２０が、通常、接続１８を介したパケットの転送に関連する情報を監視及び収集するためのコレクタ／コントローラ（Ｃ／Ｃ）２０Ｃ、現在の接続１８を介した転送のための最適パケット・サイズを決定するネットワーク・アナライザ４８、及び転送されるべきデータを最適サイズのパケットに形成し、そのパケットを接続１８を介して転送する、少なくとも１つのパケット転送エンジン（ＰＴＥ）２０Ｔを含んでいることは、先に説明した。図７Ａに示されているように、パケット・グルーマ５０は、Ｃ／Ｃ  ２０Ｃ、ネットワーク・アナライザ４８及びＰＴＥ  ２０Ｔを同様に含み、Ｃ／Ｃ  ２０Ｃ及びネットワーク・アナライザ４８は、アダプティブ・ノード１２Ａにアクセス可能な各接続１８の、現在のパケット伝送特性を反映する情報を決定及び監視するためのネットワーク・エージェントとして、一緒に機能する。上記のように、Ｃ／Ｃ  ２０Ｃは、現ＩＣＭＰエコー・パケットをパッシブ・ノードに送信し、パッシブ・ノードから応答を受信することにより、現在使用されている各接続１８を精査する。
【０１４５】
本文中で既に論じたとおり、パケット１６を受信するノード１２のＩＣＭＰは、受信したパケット１６の受領通知を、そのパケット１６を送信したノード１２に送ることにより、「ピング」機能を果たす。従って、この動作モードにおいて、ノード１２のパケット転送エンジン（ＰＴＥ）２０Ｔにより送信された各モニタ・パケット１２Ｍあるいはデータ・パケット１２Ｄは、そのパケット１６を受信したノード１２のＩＣＭＰからの受領通知によって受領が確認される。従って、各パケット１６、すなわち各モニタ・パケット１２Ｍあるいはデータ・パケット１２ＤについてのＩＣＭＰ受領通知を受信することにより、送信側パケット転送エンジン（ＰＴＥ）２０Ｔで動作するＣ／Ｃ  １０Ｃが、接続１８の待ち時間等のネットワーク状況４２を送信されたパケット１６の往復時間プラス受領通知を返すのに要する時間として決定し、またこの情報から、各パケット１６の揺らぎ等のネットワーク状況４２を上記と同様に決定することができる。接続１８及びその他の要素によって、パケット１６が受信ノード１２により受信される順序等の要素を決定することも可能であろう。
【０１４６】
接続１８を精査するために、ＩＣＭＰ受領通知あるいはエコー・パケット、もしくはノード１２により受信された各パケットについて「リターン・エコー」を供給する同様なシステムを使用することにより、接続１８のパケット伝送特性を接続１８の片側から、すなわちパケット・グルーマ５０が常駐する適応ノード１２Ｐから決定することが可能となる。この特徴は、適応ノード１２Ａから送信されたパケット・サイズに自動的に適応する際の、以下に記載のパッシブ・ノード１２Ｐの動作とともに、パケット・グルーマ５０がシングル・エンド・コンフィギュレーション、すなわちＣ／Ｃ  ２０Ｃ、ネットワーク・アナライザ４８、ＰＴＥ  ２０Ｔのいずれも接続１８の両端部ではなく、接続１８の適応ノード１２Ａの端部にのみ必要とするコンフィギュレーションとして実行されるのを可能にする。
【０１４７】
既に説明したように、Ｃ／Ｃ  ２０Ｃにより得られたパケット伝送状況の情報は、ネットワーク・アナライザ４８に送られ、ネットワーク・アナライザ４８が現在の接続１８の現在のパケット伝送特性を判断し、ノード１２にとって利用可能な各接続１８についての最適パケット・サイズ情報を保存する。例えば、本実施例において、ネットワーク・エージェント５４は、システムＩＰ接続を監視し、その各接続のパケット伝送特性を測定するためにシステム「トレイ」に常駐するサブシステム  ＷＩＮ３２アプリケーションとして実行され、ネットワーク・アナライザ４８機能は、同じく既に説明したように、ニューラル・ネットワークとして実行される。
【０１４８】
そして、ＰＴＥ  ２０Ｔは、パケット１６が伝送されている経路内のＩＰスタック２４レベルにおいてプロトコル・スタック２４とデバイス・ドライバ５４Ｄの間に存在する、ＮＤＩＳ中間ドライバ（ＮＩＤ）  ５６として実行される。図７Ａに示されているように、ＮＩＤ  ５６は、Ｃ／Ｃ  ２０Ｃ、ネットワーク・アナライザ４８及びＰＴＥ  ２０Ｔに関して既に詳細に説明したのと同様に、ネットワーク・エージェント５４から接続されており、それによって制御されている。特に、ＮＩＤ  ５６は、ノード１２Ａが通信しているノード１２ＰのＩＰアドレスをネットワーク・エージェント５４に送り、代わりにノード１２Ａとノード１２Ｐの間の現在の接続１８についての最適パケット・サイズを受領する。
【０１４９】
同じく示されているように、ＮＩＤ  ５６は、接続１８を介する伝送のため、アプリケーション５２及びスタック２４によって生成される、本文中でスタック・パケット２４Ｐと呼ばれる全ての出力パケットを遮って捕捉するために、スタック２４からデバイス・ドライバ５４Ｄへのパケット出力経路内に接続される。ＮＩＤ  ５６は、出力スタック・パケット２４Ｐをスタック２４から本文中でフラグメント・パケット２４Ｆとして特定されるパケットへとフラグメント化するが、フラグメント・パケット２４Ｆはネットワーク・エージェント５４によって決定されたとおりの最適パケット・サイズを有している。次に、ＮＩＤ  ５６は、接続１８を介する伝送のためフラグメント・パケット２４Ｆをネットワーク・インターフェイス５４Ｉに、そしてノード１２Ｐに送る。図７Ｃに表されているように、ＮＩＤ  ５６がスタック・パケット２４Ｐをフラグメント・パケット２４Ｆにフラグメント化する際、ＮＩＤ  ５６は、ＮＩＤ  ５６が動作がなければ存在していたであろう元のＯＳ  ＩＰ  スタック２４のフラグメンテーションを模倣するように、また代わりにパケット・グルーマ５０により決定されたとおりの最適パケット・サイズに従ってパケットの実際のフラグメンテーションを表示するように、パケット２４のＩＰヘッダ（ＩＰＨｓ）  ５８Ｈ内のフラグメンテーション・フィールド（ＦＲＡＧＦｓ）  ５８Ｆをも変更する。これに関して留意すべきは、パケットがスタック２４ＭＡＣレイヤにより許可されたサイズを超え、そうしなければパケット・グルーマ５０により決定されたとおりの最適パケット・サイズのみに従ってＮＩＤ  ５６によるフラグメント化が行われる場合に限り、ＯＳ  ＩＰ  スタック２４がパケットをフラグメント化することである。
【０１５０】
次に、ＮＩＤ  ５６は、変更されたフラグメンテーション・フィールドを有するフラグメント・パケット２４Ｆをデバイス・ドライバ５４Ｄに送り、デバイス・ドライバ５４Ｄは、そのパケットをネットワーク・インターフェイス５４Ｉ及び接続１８を介してノード１２Ｐに送信する。図７Ａに示されているように、「受信」ノード１２Ｒのスタック２４は変更されておらず、最適パケット・サイズにフラグメント化されたフラグメント・パケット２４Ｆを受信するよう、従来の方法で動作する。つまり、受信側のスタック２４は、パケットがフラグメント化されたかのように、またネットワーク・エージェント５４の指示により動作するＮＩＤ  ５６によって書き込まれたのではなく、送信側のスタック２４により書き込まれたかのように、フラグメント・ヘッダＩＰパケットのフラグメンテーション・ヘッダを従来の方法で読み出すのである。従って、受信側のスタック２４は、フラグメント・パケット２４Ｆをスタック・パケット２４Ｐすなわち元のサイズのパケットに再構築し、そのパケット・データを受信側のアプリケーション５２に供給する。これに関して、フラグメント化されたパケットの再構築が、当業者にとって周知である受信側のスタック２４の一般的な従来のデフラグメント動作によって行われる従来の動作であるため、ノード１２Ｐのスタック２４が、ＮＩＤ  ５６によりフラグメント化されたパケットを再構築するために動作する別個のフラグメント・リアセンブラを必要としないことは、顕著であり理解されるであろう。
【０１５１】
ノード１２Ａから送信された１つ以上のパケットに応答するなど、接続１８を介してパッシブ・ノード１２Ｐから適応ノード１２Ａへ送信されるパケットの場合、本文に記載のスタック２４が、他のノード１２から受信したパケットと同じサイズのパケットを形成することによって、他のノード１２から受信したパケットに応答するであろうことは、当業者には理解されよう。言い換えれば、所与の接続１８を介した所与の通信中、受信側のパッシブ・ノード１２Ｐは、送信側の適応ノード１２Ａから受信したパケットのサイズに関する情報を抽出及び保存し、ノード１２Ａにパケットを送信する際に、受信したものと同じサイズ、従って現在の接続１８にとって最適なサイズのパケットを生成する。従って、このため、また適応ノード１２Ａのみがシングル・エンドのエコー・モードで動作することにより接続１８にとって最適なパケット・サイズを決定するため、対になるパッシブ・ノード１２Ｐは全く従来どおりであってもよく、パケット・グルーマ５０の構成要素、動作あるいは機能の存在を必要としない。
【０１５２】
本発明は装置及び方法の好適な実施例に関して具体的に示され、説明されてきたが、添付されたクレームにより規定される本発明の精神及び範囲から逸脱することなく、形状、内容及び実施における種々の変更、変形及び改良が可能であることは、当業者には理解されよう。従って、本発明の真の精神及び範囲に入る本発明のそうした全ての変形及び改良を含むことが、添付されたクレームの目的である。
【図面の簡単な説明】
【０１５３】
【図１Ａ−１Ｃ】本発明が扱うネットワーク状況を示す図である。
【図２】適応パケット・メカニズムを含む代表的なネットワーク・システムの概略図である。
【図３】ＯＳＩプロトコル・モデルの概略図である。
【図４】ＴＣＰ／ＩＰプロトコル・モデルの概略図である。
【図５】イーサネット・フレームの概略図である。
【図６Ａ】適応パケット・メカニズムのブロック図である。
【図６Ｂ】制御スクリプトの概略図である。
【図６Ｃ】ネットワーク状況記録の概略図である。
【図７Ａ．７Ｂ．７Ｃ】無線ネットワークにおいて動作する、シングルエンド・システムとしての本願発明の実施例の概略図である。
【図２】
2004533184.tif 000003
【図３】
2004533184.tif 000004
【図４】
2004533184.tif 000005
【図５】
2004533184.tif 000006
【図６Ａ】
2004533184.tif 000007
【図６Ｂ】
2004533184.tif 000008
【図６Ｃ】
2004533184.tif 000009
【図７Ａ】
2004533184.tif 000010
【図７Ｂ】
2004533184.tif 000011
【図７Ｃ】
2004533184.tif 000012
【図１Ａ】
2004533184.tif 000013
【図１Ｂ】
2004533184.tif 000014
【図１Ｃ】
2004533184.tif 000015
【国際公開パンフレット】
2004533184.tif 000016
2004533184.tif 000017
2004533184.tif 000018
2004533184.tif 000019
2004533184.tif 000020
2004533184.tif 000021
2004533184.tif 000022
2004533184.tif 000023
2004533184.tif 000024
2004533184.tif 000025
2004533184.tif 000026
2004533184.tif 000027
2004533184.tif 000028
2004533184.tif 000029
2004533184.tif 000030
2004533184.tif 000031
2004533184.tif 000032
2004533184.tif 000033
2004533184.tif 000034
2004533184.tif 000035
2004533184.tif 000036
2004533184.tif 000037
2004533184.tif 000038
2004533184.tif 000039
2004533184.tif 000040
2004533184.tif 000041
2004533184.tif 000042
2004533184.tif 000043
2004533184.tif 000044
2004533184.tif 000045
2004533184.tif 000046
2004533184.tif 000047
2004533184.tif 000048
2004533184.tif 000049
2004533184.tif 000050
2004533184.tif 000051
2004533184.tif 000052
2004533184.tif 000053
2004533184.tif 000054
2004533184.tif 000055
2004533184.tif 000056
2004533184.tif 000057
2004533184.tif 000058
2004533184.tif 000059
2004533184.tif 000060
2004533184.tif 000061
2004533184.tif 000062
2004533184.tif 000063
2004533184.tif 000064
2004533184.tif 000065
2004533184.tif 000066
2004533184.tif 000067
2004533184.tif 000068
2004533184.tif 000069
2004533184.tif 000070
2004533184.tif 000071
2004533184.tif 000072
2004533184.tif 000073
2004533184.tif 000074
2004533184.tif 000075
2004533184.tif 000076
2004533184.tif 000077
2004533184.tif 000078
2004533184.tif 000079
2004533184.tif 000080
2004533184.tif 000081
2004533184.tif 000082
2004533184.tif 000083
2004533184.tif 000084
2004533184.tif 000085
2004533184.tif 000086
2004533184.tif 000087
2004533184.tif 000088
2004533184.tif 000089
2004533184.tif 000090
2004533184.tif 000091
2004533184.tif 000092
2004533184.tif 000093
2004533184.tif 000094
2004533184.tif 000095
2004533184.tif 000096
2004533184.tif 000097
2004533184.tif 000098
2004533184.tif 000099
2004533184.tif 000100
2004533184.tif 000101
2004533184.tif 000102
2004533184.tif 000103
2004533184.tif 000104
2004533184.tif 000105
2004533184.tif 000106
2004533184.tif 000107
2004533184.tif 000108
2004533184.tif 000109
2004533184.tif 000110
2004533184.tif 000111
2004533184.tif 000112
2004533184.tif 000113
【国際公開パンフレット（コレクトバージョン）】
2004533184.tif 000114
2004533184.tif 000115
【国際調査報告】
2004533184.tif 000116
2004533184.tif 000117