(57)【特許請求の範囲】
【請求項１】
ネットワークにおいてサービス品質（Quality of Service:ＱｏＳ）制御関連情報を報告する方法であって、
エンドツーエンド（end-to-end）の経路間において第１のネットワークエンティティからＱｏＳ関連報告パケットを受信した中間ネットワークエンティティが前記中間ネットワークエンティティのＰＨＹ階層、ＭＡＣ階層、及びネットワーク階層でチャンネル状態を各々測定し、前記各々測定されたチャンネル状態を用いて前記中間ネットワークエンティティと関連するＱｏＳ制御関連情報を生成するステップと、
前記中間ネットワークエンティティが前記ＱｏＳ制御関連情報を、前記エンドツーエンドの経路間にある第２のネットワークエンティティに伝送するステップと、を含み、
前記ＱｏＳ関連報告パケットが送信器報告パケット（Sender Report Packet）である場合、前記中間ネットワークエンティティと関連する前記ＱｏＳ制御関連情報は、前記送信器報告パケットに追加される形で前記送信器報告パケットに含まれ、前記送信器報告パケットの伝送方向と同一な方向に伝送されることを特徴とするＱｏＳ制御関連情報を報告する方法。
【請求項２】
前記ＱｏＳ制御関連情報は、前記中間ネットワークエンティティに関連するパケット損失率、前記中間ネットワークエンティティが前記第１のネットワークエンティティからＱｏＳ関連報告パケットを受信してから前記ＱｏＳ制御関連情報を前記第２のネットワークエンティティに伝送するのに成功するまでの遅延、前記第１のネットワークエンティティと前記中間ネットワークエンティティとの間の使用可能なビットレートのうち、少なくとも一つを含むことを特徴とする請求項１に記載のＱｏＳ制御関連情報を報告する方法。
【請求項３】
前記ＱｏＳ制御関連情報は、ＲＴＣＰ（Real-time Transport Control Protocol）報告ブロックのフォーマットに準拠することを特徴とする請求項１に記載のＱｏＳ制御関連情報を報告する方法。
【請求項４】
前記ＱｏＳ制御関連情報は、ＲＴＣＰ（Real-time Transport Control Protocol）報告ブロックを含むＩＰ（Internet Protocol）パケットのフォーマットに準拠することを特徴とする請求項１に記載のＱｏＳ制御関連情報を報告する方法。
【請求項５】
前記ＱｏＳ制御関連情報は、ＲＴＣＰ（Real-time Transport Control Protocol）報告ブロックを含むＲＴＣＰパケットのフォーマットに準拠することを特徴とする請求項１に記載のＱｏＳ制御関連情報を報告する方法。
【請求項６】
前記中間ネットワークエンティティは、ルータ、ＭＰＥＧ／ＪＶＴ（Joint Video Team）で規定されるＭＡＮＥ（Media Aware Network Entity）、無線通信システムの基地局のうち、少なくとも一つであることを特徴とする請求項１に記載のＱｏＳ制御関連情報を報告する方法。
【請求項７】
ネットワークにおいてサービス品質（Quality of Service:ＱｏＳ）制御関連情報を報告するネットワークエンティティであって、
エンドツーエンド（end-to-end）の経路間において第１のネットワークエンティティからＱｏＳ関連報告パケットを受信した場合、前記ネットワークエンティティのＰＨＹ階層、ＭＡＣ階層、及びネットワーク階層でチャンネル状態を各々測定し、前記各々測定されたチャンネル状態を用いて前記ネットワークエンティティと関連するＱｏＳ制御関連情報を生成し、前記ＱｏＳ制御関連情報を、前記エンドツーエンドの経路間にある第２のネットワークエンティティに伝送するように制御する制御器と、
前記ネットワークを通して前記第１のネットワークエンティティから前記ＱｏＳ関連報告パケットを受信し、前記ＱｏＳ制御関連情報を前記第２のネットワークエンティティに伝送する送受信器と、を含み、
前記ＱｏＳ関連報告パケットが送信器報告パケット（Sender Report Packet）である場合、前記中間ネットワークエンティティと関連する前記ＱｏＳ制御関連情報は、前記送信器報告パケットに追加される形で前記送信器報告パケットに含まれ、前記送信器報告パケットの伝送方向と同一な方向に伝送され、前記ネットワークエンティティは前記エンドツーエンド（end-to-end）の経路間に位置する中間ネットワークエンティティであることを特徴とするネットワークエンティティ。
【請求項８】
前記ＱｏＳ制御関連情報は、前記ネットワークエンティティに関連するパケット損失率、前記中間ネットワークエンティティが前記第１のネットワークエンティティからＱｏＳ関連報告パケットを受信してから前記ＱｏＳ制御関連情報を前記第２のネットワークエンティティに伝送するのに成功するまでの遅延、前記第１のネットワークエンティティと前記中間ネットワークエンティティとの間の使用可能なビットレートのうち、少なくとも一つを含むことを特徴とする請求項７に記載のネットワークエンティティ。
【請求項９】
前記制御器は、ＲＴＣＰ（Real-time Transport Control Protocol）報告ブロックのフォーマットに準拠して前記ＱｏＳ制御関連情報を生成することを特徴とする請求項７に記載のネットワークエンティティ。
【請求項１０】
前記制御器は、ＲＴＣＰ（Real-time Transport Control Protocol）報告ブロックを含むＩＰ（Internet Protocol）パケットのフォーマットに準拠して前記ＱｏＳ制御関連情報を生成することを特徴とする請求項７に記載のネットワークエンティティ。
【請求項１１】
前記制御器は、ＲＴＣＰ（Real-time Transport Control Protocol）報告ブロックを含むＲＴＣＰパケットのフォーマットに準拠して前記ＱｏＳ制御関連情報を生成することを特徴とする請求項７に記載のネットワークエンティティ。
【請求項１２】
前記ネットワークエンティティは、ルータ、ＭＰＥＧ／ＪＶＴ（Joint Video Team）で規定されるＭＡＮＥ（Media Aware Network Entity）、無線通信システムの基地局のうち、少なくとも一つであることを特徴とする請求項７に記載のネットワークエンティティ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークにおいてサービス品質関連情報を報告する方法に関し、特にネットワークリンク及びノード情報を用いたリアルタイムマルチメディアサービスの品質向上方法及びこれを利用した機器に関する。
【背景技術】
【０００２】
マルチメディアサービスのサービス品質制御のためのパラメータは、トラフィックパラメータ（traffic parameter）とＱｏＳパラメータ（parameter）を含む。トラフィックパラメータは、帯域幅（bandwidth）及びバッファーサイズ（buffer size）を含み、ＱｏＳパラメータ（parameter）は、遅延（delay）及びロスレート（loss rate）を含む。トラフィックパラメータは、ネットワークで特定のフロー（flow）にリソースを割り当てるためのリソース予約プロトコルであるＲＳＶＰ（Resource reSerVation Protocol）に定義されており、ＱｏＳパラメータは、ＲＴＰ（Real-time Transport Protocol）のＱｏＳを維持するためのプロトコルであるＲＴＣＰ（real-time transport control protocol）に定義されている。以下では、トラフィックパラメータとＱｏＳパラメータの例を説明するために、各々ＲＦＣ ２２０５ ＲＳＶＰとＲＦＣ ３５５０ ＲＴＣＰ標準に対する内容を詳細に記述する。
【０００３】
ＲＴＣＰ（ＲＦＣ３５５０ ＲＴＰ Section６.４.１）
ＲＴＣＰは、ユニキャスト／マルチキャスト（unicast／multicast）アプリケーション（application）のための帯域外制御プロトコル（out-of-band control protocol）である。ＲＴＣＰは、ＲＴＰエンティティがデータ伝送（data delivery）をモニターリングし、最小限の制御機能（control functionality）を有することができるようにする。
【０００４】
ＲＴＣＰと関連したパラメータは、送信器（Senders）と受信器（receivers）との間で交換されてもよい。いろいろな参加者（participants）が参加するオーディオ会議セッション（audio conference session）を考えてみると、新しい受信器はＳＤＥＳ（Source DEScription）、ＣＮＡＭＥ（Canonical NAME:正規名）などを送信器から受信すべきである。
【０００５】
ＲＴＣＰは以下のような四つの目的を有する。
【０００６】
１．エンドツーエンドのネットワーク品質のフィードバック（Feedback of end-to-end network quality）、
２．ＣＮＡＭＥの運搬（Carriers of CNAME（複数のデータストリームを関連づける正規名称））、
３．ＲＴＣＰパケットのビットレート制御、
４．最小のセッション制御情報（Minimal session control information）
ＲＴＣＰパケットの種類には、ＳＲ（Sender Report）、ＲＲ（Receiver Report）、ＳＤＥＳ_for_ＣＮＡＭＥ、ＢＹＥ、ＡＰＰパケットなどがある。ＲＴＣＰインターバル（interval）は、統計的解決法（statisticre solution）を提供しながら、セッション帯域幅（session bandwidth）が限定された範囲以内となるように決定される。
【０００７】
ＳＲ（Sender Report）／ＲＲ（Receiver Report）パケットは、０〜３１個の受信ブロック（reception block）を有する。ＳＳＲＣ（Synchronization SouRCe、participant identifier）ごとに一つの受信ブロックが存在する。これは、固有のＳＳＲＣを有したミキサーの出力からそれぞれのソースを区分するための番号である、ＣＳＲＣ（Contribution SouRCe）とは関係がない。
【０００８】
図１は、ネットワークで使用される一般的なＳＲパケットの構造を示す図である。図２はネットワークで使用される一般的なＲＲパケットの構造を示す図である。ＳＲパケットとＲＲパケットに対する具体的な説明は、ＲＦＣ ３５５０ ＲＴＣＰ標準に記述されているので、その詳細な説明は省略する。
【０００９】
ＲＴＣＰ ＸＲ
既存のＲＦＣ３６１１ ＲＴＣＰ ＸＲ（ＲＴＰ Control Protocol Extended Reports）にあるLoss ＲＬＥ（Run-Length Encoding）報告ブロックは、ＲＴＣＰインターバルの間、個別のＲＴＰパケットの損失に対する情報を伝達する。これによって、ＦＥＣ[ＲＦＣ５１０９]及び／または再伝送[ＲＦＣ４５８８]を実行して損失を補償する。既存のＲＦＣ３６１１とは異なり、現在標準化中であるDraft-ietf-avt-post-repair-rtcp-xr-０７（２０１０）では、post-loss-repairのLoss ＲＬＥに対する情報を伝達して、ＲＴＰ送信器が損失補償（loss repair）の効果を確認できるようにする。
【００１０】
上記Draft-ietf-avt-post-repair-rtcp-xr-０７（２０１０）では、新しい報告ブロックタイプが提案され登録（register）された。その報告ブロックタイプはＲＦＣ３６１１のそれと類似している。
【００１１】
図３は、ネットワークで使用される一般的なＲＴＣＰ ＸＲパケットの構造を示す図である。
【００１２】
図３を参照すると、“Ｖ”フィールドはＲＴＰのバージョンを示し、“Ｐ”フィールドはパディング（padding）を示す。“Ｐ”フィールドが設定されていると、ＲＴＣＰ ＸＲパケットは終端部分に付加的なパディングオクテット（padding octets）を含む。“Ｐ”フィールドのセマンティックス（semantics）は、ＳＲパケットでのパディングフィールドのセマンティックスと同一である。“ＰＴ”フィールドは、パケットタイプを示し、ＲＴＣＰ ＸＲパケットを確認するためのタイプ情報（定数２０７）を含む。“length”フィールドは、ＲＴＣＰ ＸＲパケットの長さを示し、“ＳＳＲＣ”フィールドは、ＲＴＣＰ ＸＲパケットの発信者（originator）に対する同期化ソース識別子（Synchronization Source identifier）を示す。そして“Report Block”フィールドは、可変長さの０または複数の拡張報告ブロックを示す。
【００１３】
ＲＳＶＰ（Resource Reservation Protocol）
ＲＦＣ ２２０５ ＲＳＶＰは、ルータ（router）でリソースを予約するためのプロトコルである。この標準によれば、送信器（Sender）によってまず伝送されるＰＡＴＨパケット（ＰＡＴＨメッセージとも称する。）と、応答において受信器（receiver）によって伝送されるＲＥＳＶパケット（ＲＥＳＶメッセージとも称する。）を用いて、使用するトラフィックパラメータ（traffic parameter）に対する情報を交換する。オプションでルータ（router）がＡＤＳＰＥＣパケットで現在の空きリソースに対する情報を提供してもよい。ＰＡＴＨパケットには、データフロー（flow）の特性に関するＴＳＰＥＣが含まれ、ＲＥＳＶパケットには、リソース予約情報に対するＦＬＯＷＳＰＥＣが含まれる。制御された負荷（Controlled load）の場合には、ＴＳＰＥＣとＦＬＯＷＳＰＥＣとも同一の二重リーキバケット（double leaky bucket）因子を利用する。ＦＬＯＷＳＰＥＣで、[Rate R、Slack Term S]が追加されると、保証されたサービス（guaranteed service）となる。ここで、スラックターム（Slack Term）Ｓは、所望の遅延値とリソース予約により得られた遅延値との差を示す。このような方式は、呼設定（call setup）と呼制御（call control）の両方に使用される。呼制御（Call control）に対する方法で、帯域幅減少（bandwidth reduction）をする手順がＲＦＣ４４９５に定義されている。
【００１４】
ＲＦＣ２２１２に定義されている保証されたサービスのＦＬＯＷＳＰＥＣは、図４に示されている。図４は、ＲＶＳＰのためのＲＥＳＶパケットのＦＬＯＷＳＰＥＣ構造を示す図である。図４に示されたＦＬＯＷＳＰＥＣ構造は、例えば、トークンバケットレート（Token Bucket Rate）r、ピークデータレート（Peak Data Rate）p、レート（Rate）Ｒを含む、３種類のビットレートを有する。それぞれのビットレートは、バケットサイズ（bucket size）、パケットサイズ、スラックターム（slack term）と対となって、個々のリーキバケット（leaky bucket）を定義することができる。ＦＬＯＷＳＰＥＣ構造の詳細な説明は、ＲＦＣ２２１２を参照するとよい。
【００１５】
マルチメディアサービスの品質を向上させるために、ネットワーク状況に応じてそのサービス品質を制御することが重要である。ＲＴＰ（Realtime Transport Protocol）標準では、ＲＴＣＰを使用してエンドツーエンドのＱｏＳ（Quality Of Service）を測定する。送信器（sender）は、ＲＴＣＰ ＳＲ（Sender Report）パケットを伝送し、受信器（receiver）は、ＳＲパケットを受けるとすぐその間に計算してきたＱｏＳをＲＴＣＰ ＲＲ（Receiver Report）パケットに含めて伝送する。送信器はＲＴＣＰを用いて測定されたＱｏＳに従ってマルチメディアサービスの品質を制御する。遅延が増加すると、送信器はビットレート（bit rate）を減らし、パケット損失が増加すると、送信器はパケット損失を防止するための既存方法を使用する。
【００１６】
ところが、既存のＲＴＣＰを使用すると、ネットワークレイヤー下の下部階層をブラックボックス（black box）として考え、エンドツーエンドの（end-to-end）ＱｏＳパラメータを測定する。ここで、ＲＴＣＰパラメータの測定は、遅延、損失などの結果に対する測定であるから、フィードバック（feedback）が遅れ、不安定性（uncertainty）が生じる。
【００１７】
また、既存のＲＴＣＰを用いて往復遅延時間、すなわちround trip timeを測定し、これを半分に分けてone way delayとして使用する方式は、モバイルネットワークでは改善が必要である。これは、モバイルチャンネルのアップリンクとダウンリンクのプロトコルと特性は、全く相異であるためである。パケット損失率の場合にもパケット損失がランダムに生じるため、その値が不安定（uncertain）である。不安定性を減少させるためには、測定時間を増加させなければならないが、そのようにすると、フィードバックが遅れる。
【発明の概要】
【発明が解決しようとする課題】
【００１８】
本発明は、上述した課題もしくは不都合な点を解決し、少なくとも以下に示す優位性を提供する。すなわち、本発明の目的は、ネットワークで適応的にＱｏＳ制御関連情報を報告する方法とこのためのネットワークエンティティを提供することにある。
【００１９】
本発明の他の目的は、中間ネットワークがＱｏＳ制御関連情報を他のネットワークエンティティに報告する方法とこのための中間ネットワークを提供することにある。
【００２０】
本発明のさらに他の目的は、ネットワークエンティティでネットワーク環境に適応的にＱｏＳ制御関連情報を報告するための報告パケットの構造を提供することにある。
【課題を解決するための手段】
【００２１】
本発明の実施形態によって、ネットワークにおいてサービス品質（Quality of Service:ＱｏＳ）制御関連情報を報告する方法は、エンドツーエンド（end-to-end）の経路間において第１のネットワークエンティティからＱｏＳ関連報告パケットを受信した中間ネットワークエンティティがチャンネル状態を測定して上記中間ネットワークエンティティと関連するＱｏＳ制御関連情報を生成するステップと、上記ＱｏＳを制御する第２のネットワークエンティティに伝送するステップと、を含み、上記ＱｏＳ関連報告パケットが送信器報告パケット（Sender Report Packet）である場合、上記中間ネットワークエンティティと関連する上記ＱｏＳ制御関連情報は、上記送信器報告パケットをアップデートする方式で上記送信器報告パケットに含まれ、上記送信器報告パケットの伝送方向と同一な方向に伝送されることを特徴とする。
【００２２】
また、本発明の他の実施形態によってネットワークにおいてサービス品質（Quality of Service:ＱｏＳ）制御関連情報を報告するネットワークエンティティは、エンドツーエンド（end-to-end）の経路間において第１のネットワークエンティティからＱｏＳ関連報告パケットを受信した場合、チャンネル状態を測定して上記ネットワークエンティティと関連するＱｏＳ制御関連情報を生成し、上記ＱｏＳ制御関連情報を、上記ＱｏＳを制御する第２のネットワークエンティティに伝送するように制御する制御器と、上記ネットワークを通して上記第１のネットワークエンティティから上記ＱｏＳ関連報告パケットを受信し、上記ＱｏＳ制御関連情報を前記第２のネットワークエンティティに伝送する送受信器と、を含み、上記ＱｏＳ関連報告パケットが送信器報告パケット（Sender Report Packet）である場合、上記中間ネットワークエンティティと関連する上記ＱｏＳ制御関連情報は、上記送信器報告パケットをアップデートする方式で上記送信器報告パケットに含まれ、上記送信器報告パケットの伝送方向と同一な方向に伝送され、上記ネットワークエンティティは上記エンドツーエンド（end-to-end）の経路間に位置する中間ネットワークエンティティであることを特徴とする。
【図面の簡単な説明】
【００２３】
【図１】ネットワークで使用される一般的なＳＲパケットの構造を示す図である。
【図２】ネットワークで使用される一般的なＲＲパケットの構造を示す図である。
【図３】ネットワークで使用される一般的なＲＴＣＰ ＸＲパケットの構造を示す図である。
【図４】ＲＶＳＰのためのＲＥＳＶパケットのＦＬＯＷＳＰＥＣ構造を示す図である。
【図５】本発明の実施形態によってＸＭＲを伝送する方法の３つの異なるオプションを示した図である。
【図６】本発明の実施形態による報告ブロックの一般的な構造を示した図である。
【図７】本発明の実施形態によるストリーム区別のためのＩＰｖ６のFlow Labelの下位４ビット値を示した図である。
【図８】本発明の実施形態によるＲＴＣＰ  ＸＭＲパケットの構造を示した図である。
【図９】本発明の実施形態によるＲＴＣＰ  ＸＭＲブロックの構造を示した図である。
【図１０】本発明の実施形態によってＲＴＣＰ  ＸＭＲブロックを生成するネットワークエンティティの構成を示した図である。
【図１１】本発明の実施形態によってＲＴＣＰ  ＸＭＲの情報を用いてＱｏＳ制御を遂行するネットワークエンティティの構成を示した図である。
【発明を実施するための形態】
【００２４】
以下、本発明の好適な実施形態を添付した図面を参照して詳しく説明する。また、以降の説明では、具体的な特定事項を示しているが、これは、本発明のより全般的な理解を助けるために提供したのに過ぎず、このような特定事項なしでも本発明が実施できることは、当該技術分野における通常の知識を有する者には自明である。そして、本発明を説明するに際し、関連公知機能あるいは構成についての具体的な説明が、本発明の要旨を不明確にするおそれがあると判断される場合は、その詳細な説明を省略する。
【００２５】
以下、本発明の実施形態ではネットワーク環境に適したサービス品質（ＱｏＳ）制御のために、ネットワークエンティティの間に適応的にサービス品質（ＱｏＳ）制御と関連した情報（以下、“ＱｏＳ制御関連情報”と称する）を報告する方法、ネットワークでエンドツーエンド（end-to-end path）の経路間に位置する中間ネットワークエンティティ（intermediate network entity:以下、“ＩＥ”と称する）がサービス品質（ＱｏＳ）制御を遂行する他のネットワークエンティティにサービス品質（ＱｏＳ）制御関連情報（または、ＱｏＳと関連した情報）を報告する方法を提案する。また、本発明の実施形態ではネットワークエンティティでネットワーク環境に従って適応的にＱｏＳと関連した情報を報告するための報告パケットの構造を提案する。
【００２６】
本発明の実施形態で、ＩＥは、例えばＲＦＣ３５５０ではミキサー（mixer）と変換器（translator）であるとよく、ＭＰＥＧ／ＪＶＴではＭＡＮＥ（Media Aware Network Entity）であるとよく、無線通信システムでは基地局（base station；ＢＳ）またはアクセスポイント（access point；ＡＰ）であるとよい。
【００２７】
本発明の実施形態は、リアルタイムマルチメディアサービスを含む各種マルチメディアサービスでサービス品質（ＱｏＳ）を向上させるために使用される。ここで、リアルタイムマルチメディアサービスは、ＴＶ会議やビデオ電話のような対話形（conversational）サービス、ＶＯＤ（Video On Demand）のようなストリーミング（streaming）サービス、ブロードキャスト／マルチキャスト（broadcast／multicast）のような放送（broadcast）サービスを含む。全体的なサービス品質に影響を大きく及ぼすチャンネル（channel）の状態を、ネットワーク経路に位置する送信器（sender）や受信器（receiver）、またはネットワーク経路内でＱｏＳを制御するネットワークエンティティに伝達することによって、適応的なＱｏＳ制御を可能にする。ここで、リンクとは、セルラ（cellular）ネットワークとＷｉＢｒｏネットワーク（ＩＥＥＥ８０２.１６）における基地局（base station）と端末機間のチャンネル、無線ＬＡＮ（ＷＬＡＮ、ＩＥＥＥ８０２.１１）におけるＡＰ（Access Point）と端末機間のチャンネルなどを指すとよい。
【００２８】
本発明の実施形態では、ＱｏＳ制御のために適応的に情報を報告するための新しいＲＴＣＰパケットまたはＲＴＣＰ報告ブロック（以下、ＲＴＣＰ ＸＭＲ（eXtended intermediate Report）パケット、またはＸＭＲブロックと呼ぶ）を提案する。ＸＭＲパケット、またはＸＭＲブロックをＸＭＲと呼ぶ。ＸＭＲは、ＳＲパケットやＲＲパケットのように独立されたパケットで伝送されるか、既存のＲＴＣＰパケットに報告ブロックを追加する形態で具現されるとよい。
【００２９】
ＸＭＲは、エンドツーエンドＱｏＳを決定するノードとリンク（channel）の特性を適応的なＱｏＳ制御（adaptive QoS control）に利用できるようにするために、エンドツーエンドの経路の中間に位置するネットワークエンティティ（すなわち、ＩＥ）がＭＡＣ／ＰＨＹ階層及びネットワークレイヤーの状況を統合して報告できるようにする。
【００３０】
ＩＥは、i）‘エンドツーエンドＱｏＳに大きく影響を及ぼす動作’を遂行するか、ii）‘エンドツーエンドＱｏＳに大きく影響を及ぼすパラメータを検出'することができる。
【００３１】
ここで、‘エンドツーエンドＱｏＳに大きく影響を及ぼす動作'は、ネットワークで遂行される各種フィルタリング（filtering）や抽出（extraction）を含んでもよい。
【００３２】
“フィルタリング”とは、マルチメディアストリームのうち、一つ以上のストリームの転送（forwarding）を遮断することを意味する。例えば、オーディオストリームとビデオストリームとからなるＡＶサービスで、ネットワーク状況が悪くなって使用可能なビットレート（available bit rate）（または使用可能な帯域幅）が低くなるとき、ビデオストリームを転送することなく、オーディオストリームのみを転送する場合である。マルチキャスト伝送である場合、ネットワークのサイドブランチ（side branch）に接続したデバイス（device）にビデオ機能がない時もフィルタリングが必要である。
【００３３】
“抽出”とは、マルチレイヤーストリームで構成された一つのメディア（media）のうち一つ以上のレイヤーのストリームの転送を遮断することを意味する。例えば、マルチレイヤーのスケーラブル（scalable）なビデオストリームから構成されたビデオサービスでネットワーク状況が悪くなって使用可能なビットレート（available bit rate）が低くなる時、上位（upper）レイヤーのストリームを転送することなく、下位（lower）レイヤーのストリームのみを転送する場合を意味する。ここで、上位レイヤーのストリームとは高解像度ビデオストリームを含んでもよく、下位レイヤーのストリームとは低解像度ビデオストリームを含んでもよい。有無線統合ネットワークにおいてマルチキャストを伝送する場合に、無線通信システムへ向かうブランチ（branch）には、下位レイヤーストリームのみをフォーワーディングする場合にも抽出が必要である。
【００３４】
‘エンドツーエンドＱｏＳに大きく影響を及ぼすパラメータを検出’することができるＩＥは、上述のように無線通信システムにおいてＢＳ（base station）またはＡＰ（access point）を例に挙げられる。これらのＩＥは、エンドツーエンドＱｏＳに最も大きく影響を及ぼすlast hopに関与している。ＩＥは各ＲＴＰストリームまたは各サービスに割り当てられたチャンネルの現在状態変数を測定する。チャンネルの状態変数は、Queue（buffer）fullness、ＣＩＮＲ（Carrier to Interference plus Noise Ratio）、ＳＩＮＲ（Signal to Interference plus Noise Ratio）、ＲＳＳＩ（Received Signal Strength Indication）、ＭＣＳ（Modulation and Coding Scheme）レベル、ＡＭＣ（Adaptive Modulation and Coding）レベル、Retry（フレーム再送回数）、hybrid ARQ（Automatic Repeatre Quest）レベルなどを含んでもよい。このようなチャンネルの状態変数を使用すると、エンドツーエンドＱｏＳを推定するのに有用である。チャンネルが変われば、使用されるパラメータが相異なるので、これらのパラメータを用いて統一化された単位でチャンネル状態変数が計算されなければならない。
【００３５】
統一化された単位におけるチャンネル状態変数は、トラフィックパラメータとＱｏＳパラメータに分けられる。
【００３６】
トラフィックパラメータは、伝達されるストリームの特性を示し、ＲＦＣ ２２０５ ＲＳＶＰ（Resource Reservation Protocol）に定義されるＴＳＰＥＣで規定する変数を使用することができる。トラフィックパラメータには、例えば、トークンレート、バケットデプス（bucket depth）、ピークレート、最大パケットサイズなどが含まれるとよい。
【００３７】
ＱｏＳパラメータは、チャンネルまたはネットワークの特性を示し、遅延／ジッター（delay／jitter）の程度、スルーアウト、損失／エラー率などを含み、ＲＦＣ３６１１でＶｏＩＰメトリクス（metrics）に含まれる変数を使用することができる。計算されたＱｏＳパラメータは、ＸＭＲを用いて送信器、受信器、または他のＩＥに伝達される。ＱｏＳパラメータは、マルチキャスト伝送である場合にはダウンストリーム受信器に伝達され得る。ＭＡＮＥのようにエンドツーエンドの経路の中間にＱｏＳを制御するネットワークエンティティが存在する場合には、ＱｏＳパラメータは、そのネットワークエンティティに伝達され使用されるとよい。
【００３８】
以下、本発明の実施形態でＸＭＲを伝送する３種類のオプション（オプション１、２、３）と、ＸＭＲパケットでのＩＰアドレスと、ＸＭＲ報告周期、ＸＭＲブロックの構造などＸＭＲを構成して利用する多様な実施形態に対して具体的に説明する。
【００３９】
オプション１は、送信器から伝送されたＳＲパケットをアップデートする方式で、ＳＲパケットに報告ブロックを追加する方式である。
【００４０】
オプション２は、受信器から伝送されたＲＲパケットをアップデートする方式で、ＲＲパケットに報告ブロックを追加する方式である。
【００４１】
オプション３は、ＩＥでＸＭＲパケットを作って伝送する方式である。
【００４２】
マルチキャストである場合には、オプション１が適しており、ユニキャストである場合には、オプション２が適している。ここで、ＳＲ及びＲＲは、ＲＦＣ３５５０で定義されたようにＳＲ（Sender Report）パケットとＲＲ（Receiver Report）パケットをいう。
【００４３】
図５は、本発明の実施形態によってＸＭＲを伝送する方法の３つのオプションを示した図である。
【００４４】
図５を参照すると、オプション１（５１０）では、ＩＥ１はＳＲパケットに新しい情報を追加してＳＲ'にアップデートする。ＳＲパケットに追加される情報は、ＩＥ１でＲＴＰパケットを転送するのに影響を及ぼす因子として、ＩＥ１の内部状態と受信器側への出口（egress）リンクの現在状態を反映する。例えば、ＩＥ１がルータであれば、遅延の程度、パケット廃棄率（packet discarding ratio）、該当セッションに割り当て可能なビットレート（帯域幅）を、混雑（congestion）レベルに応じて適切な形式で追加する。さらに他の例として、ＩＥ２がＬＴＥ ＢＳ（ＬＴＥ基地局）であれば、基地局と受信器間のリンク状況と基地局でのスケジューリング状況を測定して、該当セッションのＲＴＰパケットに対する遅延の程度、パケット損失率（packet loss ratio）、該当セッションに割り当て可能なビットレート（帯域幅）を、ＳＲ''に適切な形式で追加する。もし、受信器が最後のリンクの状況を測定してＲＴＣＰ ＸＭＲ報告ブロックを作成することができ、そのブロックを測定及び作成できるＩＥがないと、受信器は入口（ingress）チャンネルのＲＴＣＰ ＸＭＲ報告ブロックを作成して送信器に伝送する。この場合、受信器は、全体経路上のＸＭＲ報告ブロックを統合して、ＸＭＲ報告ブロックを作成し、ＲＲパケットに追加し、ＲＲパケットをＭＡＮＥや送信器に伝送する。
【００４５】
オプション２（５３０）を使用する場合、ＲＲ'やＲＲ''に含まれるＱｏＳ制御関連情報は、各々ＩＥの内部状態と該当ＩＥから受信器側への出口リンクに関する情報を含んでもよい。オプション１（５１０）とオプション２（５３０）を適用する際には、該当ＩＥにＳＲまたはＲＲパケットが留まる（stay）時間に関する情報をＸＭＲに含んでもよい。ここで、ＳＲまたはＲＲパケットが留まる時間ｒをＸＭＲに記録する方法は、ＲＴＣＰ ＲＲでの該当情報の報告ブロックにおける記録方法と同じである。
【００４６】
オプション３（５５０）は、ＸＭＲ報告ブロックをＳＲパケットやＲＲパケットに追加する代わりに、ＸＭＲ報告ブロックは別のＸＭＲパケットとともに伝送される。ＸＭＲパケットを周期的に報告する場合には、最初のＸＭＲパケットを作って伝送する送信器や受信器が経るＩＥは、ＸＭＲパケットをアップデートすることによって、エンドツーエンドＱｏＳを統合できる。周期的な報告とは別に、特に環境が変わった場合は、環境が変わったＩＥがＸＭＲパケットを生成して伝送するとよい。
【００４７】
オプション１（５１０）の場合、送信器が、最初のＸＭＲ報告ブロックを作成してＳＲに追加するとよい。同様に、オプション２（５３０）の場合、受信器が、最初のＸＭＲ報告ブロックを作成してＲＲに追加するとよい。この場合、追加される情報は、ＲＦＣ３６１１での報告ブロックと同じ形式で含まれるとよい。
【００４８】
図６は、本発明の実施形態による、報告ブロックの一般的な構造を示した図である。
【００４９】
図６を参照すれば、８ビットのＢＴ（Block type）は、報告ブロックの種類を識別する番号であり、本発明の実施形態に従って、ＸＭＲにおいて新しく指定されるブロックに対しては、新しいＢＴ番号が割り当てられ、ＩＡＮＡ（Internet Assigned Numbers Authority）に登録されるべきである。ＢＴを識別できない送信器や受信器は、ブロック長だけスキップして、次の報告ブロックを処理すればよい。
【００５０】
図５のオプション１、２、３では、各々ＳＲ、ＲＲ、ＸＭＲパケットをＩＥが識別（identification）する方法が必要である。ＩＰｖ４では拡張されたＩＰヘッダー（extended IP header）を使用して当該パケットを識別することができ、ＩＰｖ６ではflow labelを用いて当該パケットを識別することができる。すなわち、一つのリアルタイムマルチメディアサービスでストリームごとに異なるflow label番号が指定される。例えば、下位４ビットを用いて図７に示されるように区別することができる。
【００５１】
図７は、本発明の実施形態による、ストリーム区別のためのＩＰｖ６のFlow Labelの下位４ビット値を示した図である。
【００５２】
図５のオプション３の場合には、ＸＭＲパケットの構造が決められなければならない。その構造は、一般的にＳＲとＲＲパケットの構造と同一である。ＳＲとＲＲを区別できるＰＴ（Packet Type）番号がＩＡＮＡ（Internet Assigned Numbers Authority）に登録されなければならない。
【００５３】
図８は、本発明の実施形態による、ＲＴＣＰ ＸＭＲパケットの構造を示した図である。ＸＭＲパケットの基本的な構造は、図３で説明したＲＴＣＰ  ＸＲパケット（ＲＦＣ３６１１参照）を利用するとよい。ＲＴＣＰ  ＸＲパケットがＸＭＲパケットとして利用される場合、図８のパケットタイプフィールド（“ＰＴ”フィールド）は、ＸＭＲとして指定される。本発明の実施形態に従って、ＱｏＳ制御関連情報は、図８の“Report Block”フィールドにより伝達される。また図８の“Report Block”フィールドは、図９で説明するＸＭＲブロックの構造で具現化されるとよい。
【００５４】
図５で説明したオプション１とオプション２の場合には、既存のＲＦＣ３３５０ＲＴＰで定義されたミキサー（変換器）と同じ方式でソースアドレスを使用し、該当ＲＴＰストリームに対する一つのＳＳＲＣが割り当てられる。すなわち、ＸＭＲパケットにおいて、送信元アドレスと宛先アドレスは、一般的にＳＲとＲＲのように、送信器と受信器のＩＰアドレスを使用することができる。しかしながら、ミキサーと変換器のようなＩＥにおいて、ストリームが新しく形成される場合には、ＩＥのＩＰアドレスを送信元アドレスとし、受信器または送信器のＩＰアドレスを宛先アドレスとする。同様に、オプション３の場合にも、ＸＭＲパケットを作って伝送するＩＥのＩＰアドレスを送信元アドレスとして使用することができる。
【００５５】
オプション１及び２の場合、ＲＴＣＰ  ＸＭＲの報告周期は、既存のＲＴＣＰ周期、すなわち、ＳＲやＲＲの周期と等しくてもよい。しかしながら、オプション３の場合には、ＲＴＣＰ  ＸＭＲはＩＥ自体のインターバルに応じて伝送される。例えば、伝送方法は、ＸＭＲを一定の時間間隔で伝送する方法と、ＱｏＳ因子の変化が激しい時、伝送する方法とに分けられる。ここで、一定の時間間隔とは、典型的なリアルタイムマルチメディアサービスでは１秒程度が適している。
【００５６】
ＸＭＲブロックは、ＲＴＣＰ報告ブロック形式で具現されてもよい。ＸＭＲブロックは、オプション１、オプション２、オプション３の場合に、それぞれＳＲ、ＲＲ、ＸＭＲパケットに追加される。ＸＭＲブロックにはＲＦＣ２２１０で使用されるＴＳＰＥＣやＦＬＯＷＳＰＥＣのトラフィックパラメータとＲＴＣＰ ＲＲに含まれるＱｏＳパラメータが含まれてもよい。このようなパラメータは、例えば、使用可能なビットレート、パケット損失率、遅延、使用可能なバッファーサイズなどを含んでもよい。基本的にトラフィックパラメータは、ＴＳＰＥＣ形式で定義されてもよい。このような変数は一例として図９に示されたような構造で伝達されてもよい。
【００５７】
図９は、本発明の実施形態による、ＲＴＣＰ  ＸＭＲブロックの構造を示した図である。
【００５８】
ブロックタイプ（ＢＴ）９０１は８ビットを有し、報告ブロックの種類を識別するための番号を示す。ＸＭＲにおいて新しく指定するブロックに対しては、新しい番号ＢＴを割り当てて、ＩＡＮＡ（Internet Assigned Numbers Authority）に登録すべきである。ＢＴを識別できない送信器や受信器は、ブロック長だけスキップして次の報告ブロックを処理すればよい。
【００５９】
追加する前に存在したＩＥ番号（Intermediate entity number（ＩＥ#），８bit）９０３に、１を加えて記録される。もし、ＸＭＲ報告ブロックがなければ、１が記録される。
【００６０】
ＲＦＣ３６１１で定義された内容がそのまま利用されてもよい。ブロック長９０５（１６ビット）は、ヘッダーを含むバイト数で表現される。
【００６１】
ＲＦＣ２２１０でトークンバケットレートを記述する方式が利用されてもよい。もし使用可能なビットレート（Ｒａ）（３２ビット）を測定できない場合には、０として記録される。この場合には、記録された情報は無視される。
【００６２】
報告ブロックが該当ＩＥに到着して成功的に伝送されるまでの時間が推定され記録される。遅延９０９は、キューイング遅延（Queueing delay）とリンクでの再伝送による遅延を含む。ＲＦＣ３６１１でラウンドトリップ遅延（round trip delay）を表現するように、遅延９０９はミリセカンド（millisecond）単位で１６ビット整数（integer）にて表現される。もし、遅延９０９を測定できない場合には、遅延９０９は０として記録される。この場合には、記録された情報は無視される。
【００６３】
パケット損失率（Packet Loss Ratio（ＰＬＲ））９１１を表示するのに、ＲＦＣ３６１１において損失率（loss ratio）と廃棄率（discard ratio）を表示する方法と同じ方法が使用されてもよい。すなわち、ＰＬＲ９１１は、２５６をかけることによって、８ビット整数で表示される。例えば、損失率が５％であれば、２５６をかけて１２.８になり、少数点以下を捨てて‘１２’で表示する。もしＰＬＲ９１１を測定できない場合には、ＰＬＲ９１１は０として記録される。この場合には、記録された情報は無視される。
【００６４】
予約フィールド（Reserved field）９１３（８ビット）は将来的に他の変数を追加するために使用する。
【００６５】
図９に示されたようなＸＭＲブロックを構成する情報（変数）の指定方法とその情報の表現方法は、一例として示されたに過ぎない。他の目的のために新しい情報が追加され、異なる方式で表現方法が決められてもよい。本発明はこれを制限しない。
【００６６】
各ＩＥにおいてＸＭＲブロックに含まれる情報（すなわち変数）を記録する方法を上述した。以下では、複数のＩＥによるＸＭＲブロックに含まれる情報を統合する方法について述べる。その情報を統合するエンティティをマージャ（merger）と呼ぶ。オプション１の場合には、一般的に送信器がマージャとなる。これに対して、オプション２の場合には、受信器がマージャとなる。
【００６７】
しかしながら、オプション１及び２が共に必要、もしくは共に可能である場合、ＩＥがマージャであってもよい。オプション３の場合には、送信器、受信器、ＩＥの全てがマージャとなることができる。ＲＴＰセッションだけでなく、ＨＴＴＰストリーミングにおいてもこの方法が利用されてもよい。ｎ個のＩＥから伝送されたＸＭＲブロックの情報は、以下のように統合される。ここで、受信器や送信器がＸＭＲブロックを追加したら、受信器や送信器もＩＥの個数に含まれる。
【００６８】
ＸＭＲ情報を伝達するＳＲ、ＲＲ、or ＸＭＲパケット内でもっとも大きいＩＥ番号がｎであり、ｎ個のＩＥを経たｉ番目の使用可能なビットレートをＲａｉと表すと、最終的に使用可能なビットレートは、下記の［数１］のように計算できる。
【００６９】
【数１】
0005912089.tif 000002
【００７０】
同じ条件で、それぞれのＰＬＲ（Ｐｉ）を用いて最終的なパケット損失率（Ｐ）は［数２］のように計算できる。
【００７１】
【数２】
0005912089.tif 000003
【００７２】
同じ条件で、それぞれのワンウェイ遅延（one way delay）Ｄｉを用いて最終的な遅延（Ｄ）は［数３］のように計算できる。
【００７３】
【数３】
0005912089.tif 000004
【００７４】
同じ条件で、それぞれの使用可能なバッファーＢｉを用いて最終的に使用可能なバッファーサイズ（Ｂ）は、［数４］のように計算できる。
【００７５】
【数４】
0005912089.tif 000005
【００７６】
オプション１では、受信器は、統合されたＸＭＲブロックをＲＲパケットに含めて、送信器またはＭＡＮＥに伝送してＱｏＳ適応動作が実行されるようにする。オプション２の場合には、送信器またはＭＡＮＥがＸＭＲブロックを統合し、すぐにＱｏＳ適応動作が実行されるようにする。オプション３の場合には、ＸＭＲパケットが受信器に送信されるのであれば、オプション１のように受信器がＸＭＲパケットを統合し、ＲＲパケットに含めて送信器またはＭＡＮＥに伝送してＱｏＳ適応動作が実行されるようにする。これに対し、オプション３で、ＸＭＲパケットが送信器に伝送されるのであれば、オプション２のように送信器またはＭＡＮＥがＸＭＲブロックを統合して、すぐにＱｏＳ適応動作が実行されるようにする。
【００７７】
ＸＭＲは、ＲＦＣ２３２７（セッション記述プロトコル（Session Description Protocol））と互換性を有しなければならない。オプション１及びオプション２の場合、ＳＤＰパラメータ及び属性名（SDP parameter and attribute name）は既存のＳＲまたはＲＲパケットの属性のように取扱われてもよく、オプション３の場合には、新しい属性が定義される。ＲＴＣＰ  ＸＭＲブロックのＳＤＰ属性は、ＲＦＣ２２３４ＡＢＮＦ （Augmented Back us-Naur Form）によって定義されるべきである。これに対する詳細な方法は、ＲＦＣ３６１１に記述された方法を利用できる。
【００７８】
Securityに関する事項は、ＳＲＴＰ（Secure RTP）のために、ＲＦＣ３５５０ ＲＴＰ Appendix Ｂに記載された方法を利用できる。
【００７９】
リアルタイムマルチメディアサービスの品質を向上させるために、ネットワーク状況に従ってＱｏＳを制御することが重要である。これを実現するために、既存ＲＴＰ（Realtime Transport Protocol）標準では、ＲＴＣＰを使用してエンドツーエンドＱｏＳ（Quality Of Service）を測定した。送信器はＲＴＣＰを用いて測定されたＱｏＳに応じてマルチメディアストリームの品質を制御した。特に、遅延が増加すると、送信器はビットレートを減らし、パケット損失が増加すると、送信器は、損失を低減する方法を使用した。
【００８０】
ところが、既存のＲＴＣＰを使用すれば、ネットワークレイヤー下の下部階層をブラックボックス（black box）として考えるので、エンドツーエンドＱｏＳパラメータのみを測定する。ＲＴＣＰパラメータの測定は、遅延、損失結果に対する測定であるからフィードバックが遅れて、不安定性が生じる。対照的に、ＱｏＳ値を決定する原因であるＭＡＣ／ＰＨＹ階層のチャンネルパラメータを用いてＱｏＳパラメータを推定すれば、フィードバックがより速くなり、不安定性が減少する。
【００８１】
無線通信システムでは、特に既存のＲＴＣＰを用いてラウンドトリップ時間（round trip time）を測定し、これを半分に分けてワンウェイ遅延（one way delay）として使用することは正しくないアプローチである。なぜなら、モバイルチャンネルのアップリンクとダウンリンクは、プロトコルと特性が全く異なるためである。パケット損失率の場合にも、パケット損失がランダム（random）に生じるため、その値が不安定（uncertain）である。不安定性を減少させるためには、測定時間を増加させなければならないが、そのようにすると、フィードバックが遅れる。したがって、パケット損失の直接的な原因となるＭＡＣ／ＰＨＹ特性を用いてＱｏＳ因子を推定することがより効果的である。
【００８２】
図１０は、本発明の実施形態によってＲＴＣＰ  ＸＭＲブロックを生成するネットワークエンティティの構成を示した図である。上述のＩＥは、図１０のように具現化されるとよい。
【００８３】
図１０を参照すれば、ＩＥはそれぞれのサービスに適合するようにＸＭＲブロックを追加する。パケット識別子１０１０は、該当パケットのサービスタイプを特定する。ＩＰｖ４では拡張ヘッダー（extended header）により、ＩＰｖ６ではflow labelにより、サービスタイプを特定することができる。このために、まずＲＴＣＰパケットを識別できるようにすることが必要である。ネットワークレイヤー（Network layer）、ＭＡＣ／ＰＨＹレイヤーで測定されたパラメータを用いて、ＱｏＳ推定器１０３０は、ブロックに含まれるパラメータを計算する。その計算方法はＭＡＣ／ＰＨＹ及びネットワークレイヤーの特性に応じて異なる。しかしながら、ＸＭＲブロックに含まれる値に関しては、予め定められた単位の情報が予め定められた形式で含まれている。ＸＭＲ加算器１０５０は、それぞれのサービスに適合するようにＸＭＲブロックを追加する。パケット識別子１０１０、ＱｏＳ推定器（estimator）１０３０、そしてＸＭＲ加算器（adder）１０５０が一つまたは複数の制御器で具現化されてもよい。また図示されていないが、図１０のネットワークエンティティは、ＸＭＲの送受信のための送信器、受信器を具備する。
【００８４】
図１１は、本発明の実施形態によってＲＴＣＰ  ＸＭＲの情報を用いてＱｏＳ制御を遂行するネットワークエンティティの構成を示した図である。図１１のネットワークエンティティは、例えば、送信器とＭＡＮＥに対応する。
【００８５】
図１１を参照すると、パケット識別子１１１０は該当パケットのサービスタイプを特定する。ＩＰｖ４では拡張ヘッダー（extended header）により、ＩＰｖ６ではflow labelにより、サービスタイプを特定できる。送信器とＭＡＮＥは、統合されたＸＭＲレポートに応じてＱｏＳ制御を遂行する。マージャ（merger）により統合されたＸＭＲレポートは、ＱｏＳ動作決定部（Action Decision block）１１３０に提供される。ＸＭＲレポートは、オプション１、オプション２の場合に、各々受信器と送信器においてサービス毎に統合される。統合されたＸＭＲレポートは、使用可能なビットレート、パケット損失率、遅延のような情報を含む。ＱｏＳ動作決定部１１３０はＱｏＳ動作を決定する。ＱｏＳ動作には、メディアフィルタリング、レート制御（rate control）、ＦＥＣパケット追加などが含まれる。これによって、適応的ＱｏＳ制御器１１５０はあるＲＴＰストリームをフィルターにて除去（filtering-out）するか、あるＲＴＰストリームにＦＥＣパケットを追加する。送信器は、パケット識別子１１１０のように点線で表示された要素（block）を含まない。パケット識別子１１１０、ＱｏＳ動作決定部（Action Decision block）１１３０、そして適応的ＱｏＳ制御器１１５０は、一つまたは複数の制御器により具現化されてもよい。また図示されていないが、図１１のネットワークエンティティは、ＸＭＲの送受信のための送信器及び／または受信器を具備する。
【００８６】
送信器は、ＲＴＣＰ  ＸＭＲを用いて適応的ＱｏＳ制御を遂行する。すなわち、送信器は、ＲＴＣＰ  ＸＭＲブロックに記録された情報を統合して、エンドツーエンドＱｏＳを推定し、この推定結果によって、メディアフィルタリング、レート制御、ＦＥＣレベル制御（level control）などを遂行する。
【００８７】
ＭＡＮＥも、ＲＴＣＰ  ＸＭＲを用いて適応的ＱｏＳ制御を遂行する。すなわち、ＭＡＮＥは、ＲＴＣＰ  ＸＭＲブロックに記録された情報を統合して、エンドツーエンドＱｏＳを推定し、この推定結果によって、メディアフィルタリング、レート制御、ＦＥＣレベル制御などを遂行する。ＱｏＳレベルが異なる網で分かれるＱｏＳ分化型マルチキャスト（differentiated multicast）伝送である場合には、時々刻々に変わる各々の網の特性をＲＴＣＰ  ＸＭＲを用いて測定し、測定結果に基づいて、使用可能な伝送リソースを用いて、可能な限りの最高の品質のサービスを提供することができる。
【００８８】
以上、本発明の詳細な説明においては具体的な実施形態に関して説明したが、特許請求の範囲の記載及びこれと均等なものに基づいて定められる本発明の範囲及び趣旨を逸脱することなく、形式や細部の様々な変更が可能であることは、当該技術分野における通常の知識を持つ者には明らかである。
【図１】
0005912089.tif 000006
【図２】
0005912089.tif 000007
【図３】
0005912089.tif 000008
【図４】
0005912089.tif 000009
【図５】
0005912089.tif 000010
【図６】
0005912089.tif 000011
【図７】
0005912089.tif 000012
【図８】
0005912089.tif 000013
【図９】
0005912089.tif 000014
【図１０】
0005912089.tif 000015
【図１１】
0005912089.tif 000016