(57)【要約】ネットワーク輻輳通知の方法、装置、および装置が開示される。送信側ノードは、宛先ノードにデータパケットを送信する。データパケットの受信後、ネットワーク輻輳が検知される場合、宛先ノードは、データパケットに輻輳標識を付与する。輻輳標識を含むデータパケットは、送信側ノードに送信される。【選択図】図３
2008529381.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークにおける輻輳通知（congestion notification）のための方法であって、
送信側ノードにおいて、データパケットを宛先ノードに伝送することであって、各データパケットはヘッダーを含むことと、
輻輳に遭遇したか否かを決定することと、
ネットワーク輻輳の標識を前記データパケットの一部に付与することと、
受信側ノードにおいて、前記ネットワーク輻輳の標識とともに、前記データパケットを前記データパケットの送信側ノードに伝送することと、
を含む方法。
【請求項２】
ネットワーク輻輳の標識を付与することは、前記ネットワーク輻輳の標識として、明示的な輻輳標識を供給することを含む、請求項1に記載の方法。
【請求項３】
非同期転送モード（Asynchronous Transfer Mode; ATM）プロトコルに従って、前記データパケットを伝送する、請求項2に記載の方法。
【請求項４】
前記ネットワーク輻輳の標識を付与することは、非同期転送モード適合層（Asynchronous Transfer Mode Adaptation Layer; AAL2）ヘッダーに前記明示的輻輳標識を付与することを含む、請求項3に記載の方法。
【請求項５】
前記ネットワーク輻輳の標識を付与することは、ATMセルの明示的順方向輻輳標識（Explicit Forward Congestion Indication; EFCI）フィールドに前記明示的輻輳標識を付与することを含む、請求項3に記載の方法。
【請求項６】
インターネットプロトコル（IP）に従って、前記データパケットを伝送する、請求項2に記載の方法。
【請求項７】
ネットワーク輻輳の標識を付与することは、前記明示的輻輳標識をIPパケットヘッダーに付与することを含む、請求項6に記載の方法。
【請求項８】
前記データパケットを伝送することは、制御フレームを前記ネットワーク輻輳の標識として伝送することを含み、前記制御フレームは、前記輻輳の標識を含む、請求項1に記載の方法。
【請求項９】
前記輻輳制御フレームを含むデータパケットを伝送することは、前記ネットワーク輻輳の標識である、請求項8に記載の方法。
【請求項１０】
前記データパケットを伝送することは、前記輻輳制御フレームに含まれるバイナリフラグをさらに含み、前記バイナリフラグは、前記ネットワーク輻輳の標識である、請求項8に記載の方法。
【請求項１１】
前記データパケットを伝送することは、前記制御フレームのペイロード部分に前記ネットワーク輻輳の標識として新規フィールドを含めることをさらに含み、前記新規フィールドは前記ネットワーク輻輳の重度（severity）を示す、請求項8に記載の方法。
【請求項１２】
前記データパケットを伝送することは、前記輻輳を発生させたデータの発信元の標識をさらに含む前記新規フィールドをさらに含む、請求項11に記載の方法。
【請求項１３】
前記データパケットを伝送することは、前記ネットワーク輻輳の標識を含むために、アプリケーションプロトコルを使用することを含む、請求項1に記載の方法。
【請求項１４】
ネットワークにおける輻輳通知のための装置であって、
送信側ノードにおいて、データパケットを宛先ノードに伝送するための第一の伝送手段であって、各データパケットはヘッダーを含む手段と、
輻輳に遭遇したか否かを決定するための決定手段と、
ネットワーク輻輳の標識を前記データパケットの一部に付加するための挿入手段と、
受信側ノードにおいて、前記ネットワーク輻輳の標識とともに、前記データパケットを前記データパケットの送信側ノードに伝送するための第二の伝送手段と、
を備える装置。
【請求項１５】
前記挿入手段によって挿入された前記ネットワーク輻輳の標識は、明示的な輻輳標識を含む、請求項14に記載の装置。
【請求項１６】
前記伝送手段は、非同期転送モード（ATM）プロトコルに従って前記データパケットを伝送する、請求項15に記載の装置。
【請求項１７】
前記伝送手段は、インターネットプロトコル（IP）に従って前記データパケットを伝送する、請求項15に記載の装置。
【請求項１８】
前記付与手段は、前記明示的輻輳標識をIPパケットヘッダーに付与する、請求項17に記載の装置。
【請求項１９】
輻輳通知のためのシステムであって、
データパケットの受信においてネットワーク輻輳を決定する決定モジュールと、
ネットワーク輻輳の標識をデータパケットに付与する、輻輳標識モジュールと、
データパケットを前記データパケットの送信側に伝送する伝送モジュールであって、前記データパケットは、ネットワーク輻輳の前記標識を含む伝送モジュールと、
を備えるシステム。
【請求項２０】
前記輻輳標識モジュールは、明示的な輻輳通知であるネットワーク輻輳の標識を付与する、請求項19に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、第三世代（Third Generation; 3G）無線アクセスネットワーク、トラフィック管理、輻輳通知および回避の分野に関する。
【背景技術】
【０００２】
輻輳（congestion）は、高ビットレートの無線ベアラおよびアクセスネットワークシステムにおいて発生する。輻輳制御は、プロトコル階層の単一レベルに分離されないため、複雑な問題となっている。輻輳制御は、ネットワーク内のルータまたはスイッチで部分的に、およびホストマシン上で動くトランスポートプロトコルで部分的に実行される。
【０００３】
輻輳制御の一機構は、メモリや処理などの、宛先におけるリソースの割当を処理する。通常、宛先は、宛先にデータを送信する各送信側がそのデータを伝送する伝送速度に、フロー制御に応じて制限を設ける。送信側および宛先は、要求と確認を含むメッセージを交換してデータの伝送を調整する。データパケットなどのデータグラムの送信を開始する前に、送信側は、伝送を開始する許可を求める要求を宛先に送信する。その要求に応じて、宛先は、送信側が宛先に、さらなる承認を取ることなく送信できるパケット数の識別を含むメッセージを送信する。この数は一般的にウィンドウサイズと呼ばれる。次に、送信側は、承認された数のパケットを宛先に送信開始し、宛先がパケットの受信に成功してパケットの受信成功を示し、場合によっては、さらなるパケット送信を送信側に承認する確認を含むメッセージを送信側に返信するのを待つ。このように、送信側から宛先へ移動するネットワーク上のパケットの数は、承認されたウィンドウサイズを決して越えない。
【０００４】
しかしながら、この機構は、ネットワーク内のトラフィック分配を十分に処理しない。この機構が設けられていても、混み合うネットワークにおいては、多数の送信者が一つ以上の宛先にネットワーク上でのトラフィックを一斉に送信する可能性がある。また、このトラフィックを短時間で単一のルータで負担する場合、ルータまたは通信ゲートウェイのバッファ容量が限られているため、そのパケットが拒否または破棄される。この時点で、ネットワークが輻輳していると考えられる。
【０００５】
ネットワークが輻輳されると、ネットワーク性能は大幅に低下する。影響を受けた送信側は、損失または拒否されたパケットを再送信しなければならない。しかしながら、再送信によって、必然的に、バッファ記憶装置、処理時間、およびリンク帯域幅などのネットワークリソースが古いトラフィックを対処するために使用され、よって、まだ送信待ちである新しいメッセージの処理には少しのリソースしか残されない。輻輳が発生すると、ネットワーク遅延が急激に増加し、ネットワークスループットが低下する。ネットワークに既に大きな負荷が発生している時に、いくつかのネットワークリソースが再送信に対処するために取られるため、輻輳が拡大し、ネットワーク全体を停止してしまうリスクが高くなる。
【０００６】
ネットワーク輻輳に対処するための一般的方法が二つ存在する。一つは、一定時間にネットワーク上で許可されるトラフィック量に制限を設ける厳密なリソース予約の方法である。例として、パケット送信前にメモリが受信パケットを保存するために利用可能であることを確実にするための、ルータにおけるバッファの事前割当が挙げられる。
【０００７】
第一の方法においては、許可遮断を介して過負荷が回避される。一方、第二の方法は、輻輳が検知された時点で輻輳を緩和する方法に基づく。TCP／IPは、第一の方法を支持するプロトコルの一般的な例であり、TCPは、終端間パスにおいて輻輳が確認された時にその負荷を軽減することよって対処する。TCPは、IPネットワークで一般的であるように、パケット損失が過負荷を示すものと考える。チャネルについてのトランスポートリソースの厳密なリソース予約には、その接続の高ピークデータレートのため、費用がかかる場合がある。集中的なパケットデータを統計的に多重化することは、トランスポートネットワーク配置において大きな節約をもたらすことができる。
【０００８】
リソース予約には、伝送ネットワークの過負荷のリスクを利用することができる。輻輳を緩和するための方法が利用できない場合、過負荷によって、エンドユーザー性能に深刻な影響が生じる可能性がある。これは、トランスポートネットワーク層（Transport Network Layer; TNL）における損失により、RLC再送信要求をもたらし、潜在的にはトランスポートネットワークの連続的な過負荷をもたらすためである。RLC再送信レートは上昇し、反対にスループットは低下し、トランスポートネットワークの輻輳は拡大する。RLCは、終端間プロトコルからTNL損失を「隠す」が、それは、例えば、TCPがトランスポートネットワークにおける輻輳関連の損失を観測しないことを意味する。
【０００９】
インターフェースにおいて検知された輻輳を、データの送信者に警告することに関して問題が存在する。輻輳を検知するために、インターフェースの受信側には利用可能な手段が存在するが、輻輳に関するデータまたはプロトコルデータユニット（Protocol Data Unit; PDU）について送信者に通知するための利用可能な手段が存在しない。
【発明の開示】
【００１０】
本発明の一例において、ネットワークにおける輻輳通知（congestion notification）のための方法を説明する。前記方法は、送信側ノードにおいて、データパケットを宛先ノードに伝送することであって、各データパケットはヘッダーを含むことを含む。前記方法は、輻輳に遭遇したか否かを決定することと、前記データパケットの一部にネットワーク輻輳の標識を付与することとをさらに含む。さらに、前記方法は、ネットワーク輻輳の前記標識とともに、受信者ノードにおいて、前記データパケットを前記データパケットの送信側ノードに伝送することを含む。
【００１１】
別の例において、ネットワークにおける輻輳通知のための装置を説明する。前記装置は、送信側ノードにおいて、データパケットを受信ノードに伝送するための第一の伝送手段であって、各データパケットはヘッダーを含む伝送手段を備える。前記装置は、輻輳に遭遇したか否かを決定するための決定手段と、前記データパケットの一部にネットワーク輻輳の標識を付加するための挿入手段とをさらに備える。さらに、前記装置は、ネットワーク輻輳の標識とともに、受信者ノードにおいて、前記データパケットを前記データパケットの送信側ノードに伝送するための第二の伝送手段を備える。
【００１２】
さらに別の例において、輻輳通知のためのシステムを説明する。前記システムは、データパケットを受信してネットワーク輻輳を決定する、決定モジュールを備える。前記システムは、ネットワーク輻輳の標識をデータパケットに付与する、輻輳標識モジュールをさらに備える。さらに、前記システムは、データパケットを前記データパケットの送信側に伝送し、前記データパケットはネットワーク輻輳の前記標識を含む、伝送モジュールを備える。
【図面の簡単な説明】
【００１３】
【図１】本発明の一例にかかる、パケット交換ネットワークの例を示す。
【００１４】
【図２】図2Aおよび2Bは、本発明にかかる、パケット交換ネットワークにおいて使用されるデータパケットを示す。
【００１５】
【図３】本発明の例示的実施形態のフロー図である。
【００１６】
【図４】シグナル伝達図の例示的説明図である。
【００１７】
【図５】本発明の例示的実施形態にかかるシステムの説明図である。
【好適な実施形態の詳細な説明】
【００１８】
本発明は、IubおよびIurインターフェースにおいて検知された輻輳を、どのようにデータの送信者に気付いてもらうかという問題に対応するものである。現在、インターフェースにおける輻輳を検知するために、インタ?フェースの受信側に、3GPP地上無線アクセスネットワーク（Terrestrial Radio Access Network; UTRAN）において利用可能なシステムが存在する。本システムにおいて、検知は、トランスポート遅延の監視およびその遅延の増加の検知、あるいは受信プロトコルデータユニット（PDU）のシーケンスの監視およびシーケンスにおけるPDUの損失の検知に基づくことが可能である。しかしながら、輻輳に関してPDUの送信者に通知するための利用可能なシステムは存在しない。送信者が適切に対処することができるようにその輻輳を送信者に報告することによって、輻輳レベルの増加または輻輳の継続時間の延長の可能性を軽減することが本発明の実施形態の重要な特徴である。
【００１９】
輻輳検知についてデータの送信者に通知する方法はいくつかある。図1は、パケット交換ネットワーク100の例である。図1に示すように、パケット交換ネットワーク100は、送信側ノード110および宛先ノード120を備える。リンク202および204は、送信側ノード110を宛先ノード120に接続するために使用される。パケット交換ネットワークは、インターネットサービスプロバイダー（Internet Service Provider; ISP）のTCP/IPネットワーク、インターネット、および異なる送信側および宛先のネットワークを備えてもよく、例えば、送信側ノード110および宛先ノード120をリンクするパケット交換ネットワークを備えてもよい。
【００２０】
送信側ノード110および宛先ノード120は、PC、ワークステーション、メインフレーム、ファイルサーバー、記憶装置、およびその他の種類のコンピュータの他に、終端システムまたは別のルータへの伝送のために、リンク上で受信するデータを別のリンクに送信するための多数の通信リンクを含むルータまたは通信ゲートウェイを含むことが既知であるが、それだけに限定されない。
【００２１】
図2Aは、ユーザーネットワークインターフェース（User-Network Interface; UNI）におけるATMのセル形式である。セルの左端のバイトから、最初の4ビットは、汎用フロー制御（Generic Flow Control; GFC）のためのものである。次の24ビットは、8ビットの仮想識別子（Virtual Path Identifier; VPI）および16ビットの仮想チャネル識別子（Virtual Circuit Identifier; VCI）を含む。VPI／VCIは、仮想接続を識別するために使用される識別子である。Typeのフィールドは3ビット、ゆえに8つの可能な値を有する。その値のうち4つは、第一のビットが設定される場合に管理機能に関連する。第一のビットがない場合、セルがユーザーデータを含むことを示している。この場合、第二のビットは、明示的順方向輻輳標識（Explicit Forward Congestion Indication; EFCI）ビットである。EFCIビットは、設定されると、輻輳していることを別のノードに伝えるために輻輳されたスイッチによって設定されることができる。
【００２２】
次のビットは、過負荷時に優先的に廃棄すべきセルを示すために使用されるセル廃棄優先（Cell Loss Priority; CLP）である。ヘッダーの最後のバイトは、8ビットのヘッダーエラーチェックである。
【００２３】
図2Bは、TCPヘッダーのTCPヘッダー形式の説明図であり、送信元ポート番号、宛先ポート番号、シーケンス番号、確認応答（ACK）番号、データオフセット、将来の使用のための予約フィールド、制御ビット、ウィンドウ、チェックサム、緊急ポインタ、可変オプション、およびパディングを含む。制御ビットは、URG（Urgent Pointer field significant; 緊急ポインタフィールド関連）、ACK（Acknowledgment field significant; 確認応答番号関連）、PSH（Push Function; プッシュ機能）、RST（Reset the connection; コネクションをリセット）、SYN（Synchronize sequence numbers; シーケンス番号を同期させる）、およびFIN（No more data from sender; データ送信のクローズ）を含む。確認応答番号は、TCP送信側が受信することを予定する次のシーケンス番号の値を示すための32ビットを含むことができる。データオフセットは、データの開始位置を示すための4ビットを含むことができる。ウィンドウは、データセグメントのTCP送信者が受け入れる、確認フィールドで示された数から始まるデータオクテットの数を示すための16ビットを含むことができる。チェックサムは、ヘッダーおよびテキストにおいて16ビットワードの補数計算を示すための16ビットを含むことができる。緊急ポインタは、緊急データに付随してオクテットのシーケンス番号を示すための16ビットを含んでもよい。可変オプションは、多数の8ビット長を含み、チェッックサムに含まれてもよい。可変ヘッダーパディングは、TCPヘッダーが終了しデータが32ビット境界で開始することを確実にするために使用されてもよい。IPに対する明示的輻輳通知（Explicit Congestion Notification; ECN）のために、TCPヘッダー120Bの予約フィールドにおける1ビット（好ましくはビット番号9）は、輻輳を経験した（Congestion Experienced; CE）パケットが受信された場合に、宛先ノードが送信側ノードに報告できるように、ECN-Echoフラグに指定されてもよい。TCPヘッダー120Bの予約フィールドにおける別のビット（好ましくはビット番号8）は、輻輳ウィンドウが減少したこと、および宛先ノードがECN-Echoフラグの設定の停止時期を決定可能であることを送信側ノードが宛先ノードに報告できるように、輻輳ウィンドウ減少（Congestion Window Reduced; CWR）フラグに指定されてもよい。さらに、IPv4 TOS（Type of Service; サービスの種別）オクテットのビット番号6およびビット番号7は、ECN対応トランスポート（ECN-Capable Transport; ECT）ビットおよびCEビットにそれぞれ指定されてもよい。ECTビット（またはECTフラグ）は、トランスポートプロトコルの終端システムがECN対応であることを示すために、送信側ノードによって設定されてもよい。一方、CEビット（またはCEフラグ）は、輻輳を別のノードに示すために、中間ノード130によって設定されてもよい。
【００２４】
図3は、本発明の例示的実施形態を示すフロー図である。310において、送信側ノードは、データパケットを宛先ノードに伝送する。フレームは、例えばATMプロトコルまたはTCP/IPプロトコルに従って伝送されることが可能である。
【００２５】
320において、受信パケットの逆方向にネットワーク輻輳が存在することが決定または検知される。輻輳の検知は、トランスポート遅延の監視およびその遅延の増加の検知、あるいは受信PDUまたはパケットのシーケンスの監視またはシーケンスにおけるPDUまたはパケットの損失の検知に基づいて行われる検知など、上に説明されたさまざまな手段で遂行される。ネットワーク輻輳が検知されない場合、パケット伝送は通常どおり進められる。
【００２６】
しかし、ネットワーク輻輳が検知されると、輻輳を示す標識が330において付与される。輻輳標識の例は以下に説明される。輻輳が標示される方法は、使用されるプロトコルの種類、または当技術分野に精通する者により認識されるその他の要素に依存している。さらに、ネットワーク輻輳は、ネットワーク輻輳の送信側が宛先ノードのダウンリンク方向であるとして知られるような方法で標示される。例示的実施形態において、輻輳標識は、明示的な輻輳標識（Explicit Congestion Indication; ECI）である。
【００２７】
輻輳の標識を付与する例として、ECIが挙げられる。この例において、標識は、上に説明されたATMのEFCIフィールドに付加される。ECIの付加以外の例として、AAL2パケットヘッダーまたはインターネットプロトコル（Internet Protocol; IP）パケットヘッダーに標識を付与することが挙げられるが、それだけに限られない。
【００２８】
輻輳の標識が、宛先ノードによってPDUまたはパケットに付加されると、パケットの送信側ノードは、ネットワークの輻輳について通知を受ける。送信側ノードは、ネットワーク輻輳についての付与された標識を含むPDUまたはパケットを宛先ノードから受信することによって、ネットワーク輻輳について通知を受ける。上に説明されるように、輻輳標識は、輻輳の源の方向を示すように付与される。本発明の別の例示的実施形態において、付与された輻輳通知を含むPDUまたはパケットは、宛先ノードから直接送信側ノードに送信される。
【００２９】
送信側ノードがネットワーク輻輳について通知を受けると、送信側ノードは、許容可能なサービス品質（Quality of Service; QoS）を維持するために措置を講じることができる。例えば、パケットは、宛先ノードに再送されることが可能である。
【００３０】
本発明の別の例示的実施形態によると、ネットワーク輻輳を示す別の方法は、フレームプロトコルを利用する。本実施形態によると、新規フレームプロトコル制御フレームまたは輻輳通知（Congestion Notification; CN）制御フレームが宛先ノードから送信側ノードへ輻輳標識のために導入される。本実施形態によると、輻輳標識に関して四つの例示的手段が存在する。
【００３１】
本例示的実施形態にかかる輻輳標識の第一の手段には、送信側ノードに送信されるCN制御フレームが単に存在するだけである。本例示的実施形態にかかる輻輳標識のための別の手段には、CN制御フレームに含まれるバイナリフラグが存在する。この例において、輻輳の終了は、バイナリフラグを削除またはバイナリフラグの値を変更することによって示される。
【００３２】
本例示的実施形態にかかる輻輳標識のさらに別の手段は、CN制御フレームのペイロードにおける新規フィールドを使用する。新規フィールドは、例えば、検知された輻輳のレベルや重度（severity）を示し得る。このレベル／重度の表示により、宛先ノードは、さらなる輻輳を回避するための適切な措置を取ることができる。例えば、適切な措置として、輻輳に対する無反応、伝送されるデータ量の軽減、またはデータ伝送の停止などが挙げられるが、これらに限定されない。
【００３３】
本例示的実施形態にかかる輻輳標識のためのさらなる別の手段は、CN制御フレームのペイロード部分を使用する。この例によると、ペイロード部分は、輻輳のレベル／重度の両方に加え、輻輳を引き起こしたデータの発信元であるユーザーまたは無線セルを示すために使用される。
【００３４】
別の例示的実施形態における別の手段は、送信側ノードに輻輳を通知する。本例示的実施形態によれば、対応するアプリケーションプロトコルは、データの送信側に輻輳通知を伝えるために使用される。Iub（無線ネットワーク制御装置とノードBの間のインターフェース）上では、アプリケーションプロトコルはNBAP（Node B Application Part; ノードBアプリケーション部）であり、一方、Iur（無線ネットワークサブシステムとシステムの間のインターフェース）上では、RNSAP（Radio Network System Application Part; 無線ネットワークシステムアプリケーション部）である。NBAPおよびRNSAPは、UTRAN無線ネットワーク層のプロトコルである。どちらの場合でも、新規メッセージまたは既存メッセージのうちの一つは、輻輳通知IEと呼ばれる新規情報要素（Information Element; IE）を既存または新規のメッセージに導入することによって、アプリケーションプロトコルに導入される。NBAP／RNSAPによって、輻輳通知、輻輳レベルおよび輻輳の発信元（ユーザー、MAC-dフロー、無線セル、など）の両方を伝えることが可能になる。
【００３５】
図4は、NBAPプロトコルにかかる、シグナル伝達の例示的説明図である。NBAPプロトコルの無線リンク再構成準備メッセージにおいて、トランスポート層アドレス番号1は、IEにおいて、RNCからノードBに送られる。次に、NBAPプロトコルのメッセージを伝える無線リンク再構成待機は、トランスポート層アドレス番号2およびノードBの輻輳標識を、IEにおいてノードBからRNCに送信するために使用される。新規IEは、輻輳標識のコンテナとしての役割を果たす。同様なメッセージのセットが、RNSAPプロトコルを使用して利用されることが可能である。
【００３６】
図5は、本発明の例示的実施形態にかかるシステムの説明図である。システム500は、ネットワーク輻輳を送信側ノードに通知する。システム500は三つの構成要素を備える。第一の構成要素は、決定モジュール510である。決定モジュール510は、検知されたネットワーク輻輳が存在するかを決定する。上に説明されたような輻輳を検知するさまざまな方法は、トランスポート遅延の監視およびその遅延の増加の検知、あるいは受信PDUまたはパケットのシーケンスの監視またはシーケンスにおけるPDUまたはパケットの損失の検知などを含むがそれだけに限定されない。
【００３７】
本例示的実施形態によると、システムは、輻輳標識モジュール520をさらに備える。輻輳標識モジュール520は、ネットワーク輻輳が検知されると、輻輳標識をPDUまたはパケットに付加する。
【００３８】
本例示的実施形態によるシステムは、伝送モジュール530をさらに備える。伝送モジュールは、輻輳標識を含むPDUまたはパケットを送信側ノードに送信する。送信側ノードがPDUまたはパケットを受信した後、輻輳を緩和するために適切な措置を講じることができる。ネットワーク輻輳を緩和するための方法またはシステムは、当技術分野において既知である。
【００３９】
当技術分野において通常の技能を有する者は、上に説明された本発明が、異なる順序の措置により、および／または開示されたものと異なる構成のハードウェアの構成要素により実施してもよいことを容易に理解できるだろう。例えば、本発明は、少なくとも、コンピュータ可読のコード、チップセット、またはASICを含むコンピュータ製品、あるいは方法またはシステムを実行するよう構成されるプロセッサとして実行されてもよい。したがって、本発明は好適な実施形態に基づいて説明されたが、変形、変更、および代替構造が明白であり、それらは本発明の精神と範囲内にあることが当技術分野に精通する者にとって明白であろう。
【図１】
2008529381.tif 000003
【図２】
2008529381.tif 000004
【図３】
2008529381.tif 000005
【図４】
2008529381.tif 000006
【図５】
2008529381.tif 000007
【国際調査報告】
2008529381.tif 000008
2008529381.tif 000009
2008529381.tif 000010
2008529381.tif 000011