"ネットワークにおいてサービス品質QualityofServiceQoS制御関連情報を報告する方法であって、エンドツーエンドendtoendの経路間に位置する中間ネットワークエンティティがチャンネル状態を測定してQoS制御関連情報を生成するステップと、前記QoS制御関連情報を、前記QoSを制御する他のネットワークエンティティに報告するステップと、を含むことを特徴とするQoS制御関連情報を報告する方法。前記QoS制御関連情報は、前記中間ネットワークエンティティに関連するパケット損失率、遅延、使用可能なビットレートのうち、少なくとも一つを含むことを特徴とする請求項1に記載のQoS制御関連情報を報告する方法。前記QoS制御関連情報は、RTCPRealtimeTransportControlProtocol報告ブロック形式で生成されることを特徴とする請求項1に記載のQoS制御関連情報を報告する方法。前記QoS制御関連情報は、RTCPRealtimeTransportControlProtocol報告ブロックを含むIPInternetProtocolパケットの形式で生成されることを特徴とする請求項1に記載のQoS制御関連情報を報告する方法。前記QoS制御関連情報は、RTCPRealtimeTransportControlProtocol報告ブロックを含むRTCPパケットの形式で生成されることを特徴とする請求項1に記載のQoS制御関連情報を報告する方法。前記RTCPパケットは、送信器報告パケットSenderReportPacket、受信器報告パケットReceiverReportPacket、そしてXMReXtendedinterMediateReportパケットのうち、少なくとも一つであることを特徴とする請求項5に記載のQoS制御関連情報を報告する方法。前記中間ネットワークエンティティは、ルータ、MANEMediaAwareNetworkEntity、無線通信システムの基地局のうち、少なくとも一つであることを特徴とする請求項1に記載のQoS制御関連情報を報告する方法。ネットワークにおいてサービス品質QualityofServiceQoS制御関連情報を報告するネットワークエンティティであって、エンドツーエンドendtoendの経路間においてチャンネル状態を測定してQoS制御関連情報を生成し、前記QoS制御関連情報を、前記QoSを制御する他のネットワークエンティティに報告するように制御する制御器と、前記ネットワークを通して前記QoS制御関連情報を前記他のネットワークエンティティに伝送する送信器と、を含むことを特徴とするネットワークエンティティ。前記QoS制御関連情報は、前記ネットワークエンティティに関連するパケット損失率、遅延、使用可能なビットレートのうち、少なくとも一つを含むことを特徴とする請求項8に記載のネットワークエンティティ。前記制御器は、RTCPRealtimeTransportControlProtocol報告ブロック形式で前記QoS制御関連情報を生成することを特徴とする請求項8に記載のネットワークエンティティ。前記制御器は、RTCPRealtimeTransportControlProtocol報告ブロックを含むIPInternetProtocolパケットの形式で前記QoS制御関連情報を生成することを特徴とする請求項8に記載のネットワークエンティティ。前記制御器は、RTCPRealtimeTransportControlProtocol報告ブロックを含むRTCPパケットの形式で前記QoS制御関連情報を生成することを特徴とする請求項8に記載のネットワークエンティティ。前記RTCPパケットは、送信器報告パケットSenderReportPacket、受信器報告パケットReceiverReportPacket、そしてXMReXtendedinterMediateReportパケットのうち、少なくとも一つであることを特徴とする請求項12に記載ののネットワークエンティティ。前記ネットワークエンティティは、ルータ、MANEMediaAwareNetworkEntity、無線通信システムの基地局のうち、少なくとも一つであることを特徴とする請求項8に記載のネットワークエンティティ。前記制御器は、サービスの種類別に前記QoS制御関連情報を生成することを特徴とする請求項8に記載のネットワークエンティティ。本発明は、上述した課題もしくは不都合な点を解決し、少なくとも以下に示す優位性を提供する。すなわち、本発明の目的は、ネットワークで適応的にQoS制御関連情報を報告する方法とこのためのネットワークエンティティを提供することにある。本発明の他の目的は、中間ネットワークがQoS制御関連情報を他のネットワークエンティティに報告する方法とこのための中間ネットワークを提供することにある。本発明のさらに他の目的は、ネットワークエンティティでネットワーク環境に適応的にQoS制御関連情報を報告するための報告パケットの構造を提供することにある。本発明の実施形態によって、ネットワークにおいてサービス品質QualityofServiceQoS制御関連情報を報告する方法は、エンドツーエンドendtoendの経路間に位置する中間ネットワークエンティティがチャンネル状態を測定してQoS制御関連情報を生成するステップと、上記中間ネットワークエンティティが上記QoS制御関連情報を、上記QoSを制御する他のネットワークエンティティに報告するステップと、を含むことを特徴とする。また、本発明の他の実施形態によってネットワークにおいてサービス品質QualityofServiceQoS制御関連情報を報告するネットワークエンティティは、エンドツーエンドendtoendの経路間においてチャンネル状態を測定してQoS制御関連情報を生成し、上記QoS制御関連情報を、上記QoSを制御する他のネットワークエンティティに報告するように制御する制御器と、上記ネットワークを通して上記QoS制御関連情報を上記他のネットワークエンティティに伝送する送信器と、を含むことを特徴とする。以下、本発明の好適な実施形態を添付した図面を参照して詳しく説明する。また、以降の説明では、具体的な特定事項を示しているが、これは、本発明のより全般的な理解を助けるために提供したのに過ぎず、このような特定事項なしでも本発明が実施できることは、当該技術分野における通常の知識を有する者には自明である。そして、本発明を説明するに際し、関連公知機能あるいは構成についての具体的な説明が、本発明の要旨を不明確にするおそれがあると判断される場合は、その詳細な説明を省略する。以下、本発明の実施形態ではネットワーク環境に適したサービス品質QoS制御のために、ネットワークエンティティの間に適応的にサービス品質QoS制御と関連した情報以下、QoS制御関連情報と称するを報告する方法、ネットワークでエンドツーエンドendtoendpathの経路間に位置する中間ネットワークエンティティintermediatenetworkentity以下、IEと称するがサービス品質QoS制御を遂行する他のネットワークエンティティにサービス品質QoS制御関連情報または、QoSと関連した情報を報告する方法を提案する。また、本発明の実施形態ではネットワークエンティティでネットワーク環境に従って適応的にQoSと関連した情報を報告するための報告パケットの構造を提案する。本発明の実施形態で、IEは、例えばRFC3550ではミキサーmixerと変換器translatorであるとよく、MPEG/JVTではMANEMediaAwareNetworkEntityであるとよく、無線通信システムでは基地局basestation;BSまたはアクセスポイントaccesspoint;APであるとよい。本発明の実施形態は、リアルタイムマルチメディアサービスを含む各種マルチメディアサービスでサービス品質QoSを向上させるために使用される。ここで、リアルタイムマルチメディアサービスは、TV会議やビデオ電話のような対話形conversationalサービス、VODVideoOnDemandのようなストリーミングstreamingサービス、ブロードキャスト/マルチキャストbroadcast/multicastのような放送broadcastサービスを含む。全体的なサービス品質に影響を大きく及ぼすチャンネルchannelの状態を、ネットワーク経路に位置する送信器senderや受信器receiver、またはネットワーク経路内でQoSを制御するネットワークエンティティに伝達することによって、適応的なQoS制御を可能にする。ここで、リンクとは、セルラcellularネットワークとWiBroネットワークIEEE80216における基地局basestationと端末機間のチャンネル、無線LANWLAN、IEEE80211におけるAPAccessPointと端末機間のチャンネルなどを指すとよい。本発明の実施形態では、QoS制御のために適応的に情報を報告するための新しいRTCPパケットまたはRTCP報告ブロック以下、RTCPXMReXtendedintermediateReportパケット、またはXMRブロックと呼ぶを提案する。XMRパケット、またはXMRブロックをXMRと呼ぶ。XMRは、SRパケットやRRパケットのように独立されたパケットで伝送されるか、既存のRTCPパケットに報告ブロックを追加する形態で具現されるとよい。XMRは、エンドツーエンドQoSを決定するノードとリンクchannelの特性を適応的なQoS制御adaptiveQoScontrolに利用できるようにするために、エンドツーエンドの経路の中間に位置するネットワークエンティティすなわち、IEがMAC/PHY階層及びネットワークレイヤーの状況を統合して報告できるようにする。IEは、i‘エンドツーエンドQoSに大きく影響を及ぼす動作’を遂行するか、ii‘エンドツーエンドQoSに大きく影響を及ぼすパラメータを検出することができる。ここで、‘エンドツーエンドQoSに大きく影響を及ぼす動作は、ネットワークで遂行される各種フィルタリングfilteringや抽出extractionを含んでもよい。フィルタリングとは、マルチメディアストリームのうち、一つ以上のストリームの転送forwardingを遮断することを意味する。例えば、オーディオストリームとビデオストリームとからなるAVサービスで、ネットワーク状況が悪くなって使用可能なビットレートavailablebitrateまたは使用可能な帯域幅が低くなるとき、ビデオストリームを転送することなく、オーディオストリームのみを転送する場合である。マルチキャスト伝送である場合、ネットワークのサイドブランチsidebranchに接続したデバイスdeviceにビデオ機能がない時もフィルタリングが必要である。抽出とは、マルチレイヤーストリームで構成された一つのメディアmediaのうち一つ以上のレイヤーのストリームの転送を遮断することを意味する。例えば、マルチレイヤーのスケーラブルscalableなビデオストリームから構成されたビデオサービスでネットワーク状況が悪くなって使用可能なビットレートavailablebitrateが低くなる時、上位upperレイヤーのストリームを転送することなく、下位lowerレイヤーのストリームのみを転送する場合を意味する。ここで、上位レイヤーのストリームとは高解像度ビデオストリームを含んでもよく、下位レイヤーのストリームとは低解像度ビデオストリームを含んでもよい。有無線統合ネットワークにおいてマルチキャストを伝送する場合に、無線通信システムへ向かうブランチbranchには、下位レイヤーストリームのみをフォーワーディングする場合にも抽出が必要である。‘エンドツーエンドQoSに大きく影響を及ぼすパラメータを検出’することができるIEは、上述のように無線通信システムにおいてBSbasestationまたはAPaccesspointを例に挙げられる。これらのIEは、エンドツーエンドQoSに最も大きく影響を及ぼすlasthopに関与している。IEは各RTPストリームまたは各サービスに割り当てられたチャンネルの現在状態変数を測定する。チャンネルの状態変数は、Queuebufferfullness、CINRCarriertoInterferenceplusNoiseRatio、SINRSignaltoInterferenceplusNoiseRatio、RSSIReceivedSignalStrengthIndication、MCSModulationandCodingSchemeレベル、AMCAdaptiveModulationandCodingレベル、Retryフレーム再送回数、hybridARQAutomaticRepeatreQuestレベルなどを含んでもよい。このようなチャンネルの状態変数を使用すると、エンドツーエンドQoSを推定するのに有用である。チャンネルが変われば、使用されるパラメータが相異なるので、これらのパラメータを用いて統一化された単位でチャンネル状態変数が計算されなければならない。統一化された単位におけるチャンネル状態変数は、トラフィックパラメータとQoSパラメータに分けられる。トラフィックパラメータは、伝達されるストリームの特性を示し、RFC2205RSVPResourceReservationProtocolに定義されるTSPECで規定する変数を使用することができる。トラフィックパラメータには、例えば、トークンレート、バケットデプスbucketdepth、ピークレート、最大パケットサイズなどが含まれるとよい。QoSパラメータは、チャンネルまたはネットワークの特性を示し、遅延/ジッターdelay/jitterの程度、スルーアウト、損失/エラー率などを含み、RFC3611でVoIPメトリクスmetricsに含まれる変数を使用することができる。計算されたQoSパラメータは、XMRを用いて送信器、受信器、または他のIEに伝達される。QoSパラメータは、マルチキャスト伝送である場合にはダウンストリーム受信器に伝達され得る。MANEのようにエンドツーエンドの経路の中間にQoSを制御するネットワークエンティティが存在する場合には、QoSパラメータは、そのネットワークエンティティに伝達され使用されるとよい。以下、本発明の実施形態でXMRを伝送する3種類のオプションオプション1、2、3と、XMRパケットでのIPアドレスと、XMR報告周期、XMRブロックの構造などXMRを構成して利用する多様な実施形態に対して具体的に説明する。オプション1は、送信器から伝送されたSRパケットをアップデートする方式で、SRパケットに報告ブロックを追加する方式である。オプション2は、受信器から伝送されたRRパケットをアップデートする方式で、RRパケットに報告ブロックを追加する方式である。オプション3は、IEでXMRパケットを作って伝送する方式である。マルチキャストである場合には、オプション1が適しており、ユニキャストである場合には、オプション2が適している。ここで、SR及びRRは、RFC3550で定義されたようにSRSenderReportパケットとRRReceiverReportパケットをいう。図5は、本発明の実施形態によってXMRを伝送する方法の3つのオプションを示した図である。図5を参照すると、オプション1510では、IE1はSRパケットに新しい情報を追加してSRにアップデートする。SRパケットに追加される情報は、IE1でRTPパケットを転送するのに影響を及ぼす因子として、IE1の内部状態と受信器側への出口egressリンクの現在状態を反映する。例えば、IE1がルータであれば、遅延の程度、パケット廃棄率packetdiscardingratio、該当セッションに割り当て可能なビットレート帯域幅を、混雑congestionレベルに応じて適切な形式で追加する。さらに他の例として、IE2がLTEBSLTE基地局であれば、基地局と受信器間のリンク状況と基地局でのスケジューリング状況を測定して、該当セッションのRTPパケットに対する遅延の程度、パケット損失率packetlossratio、該当セッションに割り当て可能なビットレート帯域幅を、SRに適切な形式で追加する。もし、受信器が最後のリンクの状況を測定してRTCPXMR報告ブロックを作成することができ、そのブロックを測定及び作成できるIEがないと、受信器は入口ingressチャンネルのRTCPXMR報告ブロックを作成して送信器に伝送する。この場合、受信器は、全体経路上のXMR報告ブロックを統合して、XMR報告ブロックを作成し、RRパケットに追加し、RRパケットをMANEや送信器に伝送する。オプション2530を使用する場合、RRやRRに含まれるQoS制御関連情報は、各々IEの内部状態と該当IEから受信器側への出口リンクに関する情報を含んでもよい。オプション1510とオプション2530を適用する際には、該当IEにSRまたはRRパケットが留まるstay時間に関する情報をXMRに含んでもよい。ここで、SRまたはRRパケットが留まる時間rをXMRに記録する方法は、RTCPRRでの該当情報の報告ブロックにおける記録方法と同じである。オプション3550は、XMR報告ブロックをSRパケットやRRパケットに追加する代わりに、XMR報告ブロックは別のXMRパケットとともに伝送される。XMRパケットを周期的に報告する場合には、最初のXMRパケットを作って伝送する送信器や受信器が経るIEは、XMRパケットをアップデートすることによって、エンドツーエンドQoSを統合できる。周期的な報告とは別に、特に環境が変わった場合は、環境が変わったIEがXMRパケットを生成して伝送するとよい。オプション1510の場合、送信器が、最初のXMR報告ブロックを作成してSRに追加するとよい。同様に、オプション2530の場合、受信器が、最初のXMR報告ブロックを作成してRRに追加するとよい。この場合、追加される情報は、RFC3611での報告ブロックと同じ形式で含まれるとよい。図6は、本発明の実施形態による、報告ブロックの一般的な構造を示した図である。図6を参照すれば、8ビットのBTBlocktypeは、報告ブロックの種類を識別する番号であり、本発明の実施形態に従って、XMRにおいて新しく指定されるブロックに対しては、新しいBT番号が割り当てられ、IANAInternetAssignedNumbersAuthorityに登録されるべきである。BTを識別できない送信器や受信器は、ブロック長だけスキップして、次の報告ブロックを処理すればよい。図5のオプション1、2、3では、各々SR、RR、XMRパケットをIEが識別identificationする方法が必要である。IPv4では拡張されたIPヘッダーextendedIPheaderを使用して当該パケットを識別することができ、IPv6ではflowlabelを用いて当該パケットを識別することができる。すなわち、一つのリアルタイムマルチメディアサービスでストリームごとに異なるflowlabel番号が指定される。例えば、下位4ビットを用いて図7に示されるように区別することができる。図7は、本発明の実施形態による、ストリーム区別のためのIPv6のFlowLabelの下位4ビット値を示した図である。図5のオプション3の場合には、XMRパケットの構造が決められなければならない。その構造は、一般的にSRとRRパケットの構造と同一である。SRとRRを区別できるPTPacketType番号がIANAInternetAssignedNumbersAuthorityに登録されなければならない。図8は、本発明の実施形態による、RTCPXMRパケットの構造を示した図である。XMRパケットの基本的な構造は、図3で説明したRTCPXRパケットRFC3611参照を利用するとよい。RTCPXRパケットがXMRパケットとして利用される場合、図8のパケットタイプフィールドPTフィールドは、XMRとして指定される。本発明の実施形態に従って、QoS制御関連情報は、図8のReportBlockフィールドにより伝達される。また図8のReportBlockフィールドは、図9で説明するXMRブロックの構造で具現化されるとよい。図5で説明したオプション1とオプション2の場合には、既存のRFC3350RTPで定義されたミキサー変換器と同じ方式でソースアドレスを使用し、該当RTPストリームに対する一つのSSRCが割り当てられる。すなわち、XMRパケットにおいて、送信元アドレスと宛先アドレスは、一般的にSRとRRのように、送信器と受信器のIPアドレスを使用することができる。しかしながら、ミキサーと変換器のようなIEにおいて、ストリームが新しく形成される場合には、IEのIPアドレスを送信元アドレスとし、受信器または送信器のIPアドレスを宛先アドレスとする。同様に、オプション3の場合にも、XMRパケットを作って伝送するIEのIPアドレスを送信元アドレスとして使用することができる。オプション1及び2の場合、RTCPXMRの報告周期は、既存のRTCP周期、すなわち、SRやRRの周期と等しくてもよい。しかしながら、オプション3の場合には、RTCPXMRはIE自体のインターバルに応じて伝送される。例えば、伝送方法は、XMRを一定の時間間隔で伝送する方法と、QoS因子の変化が激しい時、伝送する方法とに分けられる。ここで、一定の時間間隔とは、典型的なリアルタイムマルチメディアサービスでは1秒程度が適している。XMRブロックは、RTCP報告ブロック形式で具現されてもよい。XMRブロックは、オプション1、オプション2、オプション3の場合に、それぞれSR、RR、XMRパケットに追加される。XMRブロックにはRFC2210で使用されるTSPECやFLOWSPECのトラフィックパラメータとRTCPRRに含まれるQoSパラメータが含まれてもよい。このようなパラメータは、例えば、使用可能なビットレート、パケット損失率、遅延、使用可能なバッファーサイズなどを含んでもよい。基本的にトラフィックパラメータは、TSPEC形式で定義されてもよい。このような変数は一例として図9に示されたような構造で伝達されてもよい。図9は、本発明の実施形態による、RTCPXMRブロックの構造を示した図である。ブロックタイプBT901は8ビットを有し、報告ブロックの種類を識別するための番号を示す。XMRにおいて新しく指定するブロックに対しては、新しい番号BTを割り当てて、IANAInternetAssignedNumbersAuthorityに登録すべきである。BTを識別できない送信器や受信器は、ブロック長だけスキップして次の報告ブロックを処理すればよい。追加する前に存在したIE番号IntermediateentitynumberIE,8bit903に、1を加えて記録される。もし、XMR報告ブロックがなければ、1が記録される。RFC3611で定義された内容がそのまま利用されてもよい。ブロック長90516ビットは、ヘッダーを含むバイト数で表現される。RFC2210でトークンバケットレートを記述する方式が利用されてもよい。もし使用可能なビットレートRa32ビットを測定できない場合には、0として記録される。この場合には、記録された情報は無視される。報告ブロックが該当IEに到着して成功的に伝送されるまでの時間が推定され記録される。遅延909は、キューイング遅延Queueingdelayとリンクでの再伝送による遅延を含む。RFC3611でラウンドトリップ遅延roundtripdelayを表現するように、遅延909はミリセカンドmillisecond単位で16ビット整数integerにて表現される。もし、遅延909を測定できない場合には、遅延909は0として記録される。この場合には、記録された情報は無視される。パケット損失率PacketLossRatioPLR911を表示するのに、RFC3611において損失率lossratioと廃棄率discardratioを表示する方法と同じ方法が使用されてもよい。すなわち、PLR911は、256をかけることによって、8ビット整数で表示される。例えば、損失率が5であれば、256をかけて128になり、少数点以下を捨てて‘12’で表示する。もしPLR911を測定できない場合には、PLR911は0として記録される。この場合には、記録された情報は無視される。予約フィールドReservedfield9138ビットは将来的に他の変数を追加するために使用する。図9に示されたようなXMRブロックを構成する情報変数の指定方法とその情報の表現方法は、一例として示されたに過ぎない。他の目的のために新しい情報が追加され、異なる方式で表現方法が決められてもよい。本発明はこれを制限しない。各IEにおいてXMRブロックに含まれる情報すなわち変数を記録する方法を上述した。以下では、複数のIEによるXMRブロックに含まれる情報を統合する方法について述べる。その情報を統合するエンティティをマージャmergerと呼ぶ。オプション1の場合には、一般的に送信器がマージャとなる。これに対して、オプション2の場合には、受信器がマージャとなる。しかしながら、オプション1及び2が共に必要、もしくは共に可能である場合、IEがマージャであってもよい。オプション3の場合には、送信器、受信器、IEの全てがマージャとなることができる。RTPセッションだけでなく、HTTPストリーミングにおいてもこの方法が利用されてもよい。n個のIEから伝送されたXMRブロックの情報は、以下のように統合される。ここで、受信器や送信器がXMRブロックを追加したら、受信器や送信器もIEの個数に含まれる。XMR情報を伝達するSR、RR、orXMRパケット内でもっとも大きいIE番号がnであり、n個のIEを経たi番目の使用可能なビットレートをRaiと表すと、最終的に使用可能なビットレートは、下記の[数1]のように計算できる。同じ条件で、それぞれのPLRPiを用いて最終的なパケット損失率Pは[数2]のように計算できる。同じ条件で、それぞれのワンウェイ遅延onewaydelayDiを用いて最終的な遅延Dは[数3]のように計算できる。同じ条件で、それぞれの使用可能なバッファーBiを用いて最終的に使用可能なバッファーサイズBは、[数4]のように計算できる。オプション1では、受信器は、統合されたXMRブロックをRRパケットに含めて、送信器またはMANEに伝送してQoS適応動作が実行されるようにする。オプション2の場合には、送信器またはMANEがXMRブロックを統合し、すぐにQoS適応動作が実行されるようにする。オプション3の場合には、XMRパケットが受信器に送信されるのであれば、オプション1のように受信器がXMRパケットを統合し、RRパケットに含めて送信器またはMANEに伝送してQoS適応動作が実行されるようにする。これに対し、オプション3で、XMRパケットが送信器に伝送されるのであれば、オプション2のように送信器またはMANEがXMRブロックを統合して、すぐにQoS適応動作が実行されるようにする。XMRは、RFC2327セッション記述プロトコルSessionDescriptionProtocolと互換性を有しなければならない。オプション1及びオプション2の場合、SDPパラメータ及び属性名SDPparameterandattributenameは既存のSRまたはRRパケットの属性のように取扱われてもよく、オプション3の場合には、新しい属性が定義される。RTCPXMRブロックのSDP属性は、RFC2234ABNFAugmentedBackusNaurFormによって定義されるべきである。これに対する詳細な方法は、RFC3611に記述された方法を利用できる。Securityに関する事項は、SRTPSecureRTPのために、RFC3550RTPAppendixBに記載された方法を利用できる。リアルタイムマルチメディアサービスの品質を向上させるために、ネットワーク状況に従ってQoSを制御することが重要である。これを実現するために、既存RTPRealtimeTransportProtocol標準では、RTCPを使用してエンドツーエンドQoSQualityOfServiceを測定した。送信器はRTCPを用いて測定されたQoSに応じてマルチメディアストリームの品質を制御した。特に、遅延が増加すると、送信器はビットレートを減らし、パケット損失が増加すると、送信器は、損失を低減する方法を使用した。ところが、既存のRTCPを使用すれば、ネットワークレイヤー下の下部階層をブラックボックスblackboxとして考えるので、エンドツーエンドQoSパラメータのみを測定する。RTCPパラメータの測定は、遅延、損失結果に対する測定であるからフィードバックが遅れて、不安定性が生じる。対照的に、QoS値を決定する原因であるMAC/PHY階層のチャンネルパラメータを用いてQoSパラメータを推定すれば、フィードバックがより速くなり、不安定性が減少する。無線通信システムでは、特に既存のRTCPを用いてラウンドトリップ時間roundtriptimeを測定し、これを半分に分けてワンウェイ遅延onewaydelayとして使用することは正しくないアプローチである。なぜなら、モバイルチャンネルのアップリンクとダウンリンクは、プロトコルと特性が全く異なるためである。パケット損失率の場合にも、パケット損失がランダムrandomに生じるため、その値が不安定uncertainである。不安定性を減少させるためには、測定時間を増加させなければならないが、そのようにすると、フィードバックが遅れる。したがって、パケット損失の直接的な原因となるMAC/PHY特性を用いてQoS因子を推定することがより効果的である。図10は、本発明の実施形態によってRTCPXMRブロックを生成するネットワークエンティティの構成を示した図である。上述のIEは、図10のように具現化されるとよい。図10を参照すれば、IEはそれぞれのサービスに適合するようにXMRブロックを追加する。パケット識別子1010は、該当パケットのサービスタイプを特定する。IPv4では拡張ヘッダーextendedheaderにより、IPv6ではflowlabelにより、サービスタイプを特定することができる。このために、まずRTCPパケットを識別できるようにすることが必要である。ネットワークレイヤーNetworklayer、MAC/PHYレイヤーで測定されたパラメータを用いて、QoS推定器1030は、ブロックに含まれるパラメータを計算する。その計算方法はMAC/PHY及びネットワークレイヤーの特性に応じて異なる。しかしながら、XMRブロックに含まれる値に関しては、予め定められた単位の情報が予め定められた形式で含まれている。XMR加算器1050は、それぞれのサービスに適合するようにXMRブロックを追加する。パケット識別子1010、QoS推定器estimator1030、そしてXMR加算器adder1050が一つまたは複数の制御器で具現化されてもよい。また図示されていないが、図10のネットワークエンティティは、XMRの送受信のための送信器、受信器を具備する。図11は、本発明の実施形態によってRTCPXMRの情報を用いてQoS制御を遂行するネットワークエンティティの構成を示した図である。図11のネットワークエンティティは、例えば、送信器とMANEに対応する。図11を参照すると、パケット識別子1110は該当パケットのサービスタイプを特定する。IPv4では拡張ヘッダーextendedheaderにより、IPv6ではflowlabelにより、サービスタイプを特定できる。送信器とMANEは、統合されたXMRレポートに応じてQoS制御を遂行する。マージャmergerにより統合されたXMRレポートは、QoS動作決定部ActionDecisionblock1130に提供される。XMRレポートは、オプション1、オプション2の場合に、各々受信器と送信器においてサービス毎に統合される。統合されたXMRレポートは、使用可能なビットレート、パケット損失率、遅延のような情報を含む。QoS動作決定部1130はQoS動作を決定する。QoS動作には、メディアフィルタリング、レート制御ratecontrol、FECパケット追加などが含まれる。これによって、適応的QoS制御器1150はあるRTPストリームをフィルターにて除去filteringoutするか、あるRTPストリームにFECパケットを追加する。送信器は、パケット識別子1110のように点線で表示された要素blockを含まない。パケット識別子1110、QoS動作決定部ActionDecisionblock1130、そして適応的QoS制御器1150は、一つまたは複数の制御器により具現化されてもよい。また図示されていないが、図11のネットワークエンティティは、XMRの送受信のための送信器及び/または受信器を具備する。送信器は、RTCPXMRを用いて適応的QoS制御を遂行する。すなわち、送信器は、RTCPXMRブロックに記録された情報を統合して、エンドツーエンドQoSを推定し、この推定結果によって、メディアフィルタリング、レート制御、FECレベル制御levelcontrolなどを遂行する。MANEも、RTCPXMRを用いて適応的QoS制御を遂行する。すなわち、MANEは、RTCPXMRブロックに記録された情報を統合して、エンドツーエンドQoSを推定し、この推定結果によって、メディアフィルタリング、レート制御、FECレベル制御などを遂行する。QoSレベルが異なる網で分かれるQoS分化型マルチキャストdifferentiatedmulticast伝送である場合には、時々刻々に変わる各々の網の特性をRTCPXMRを用いて測定し、測定結果に基づいて、使用可能な伝送リソースを用いて、可能な限りの最高の品質のサービスを提供することができる。以上、本発明の詳細な説明においては具体的な実施形態に関して説明したが、特許請求の範囲の記載及びこれと均等なものに基づいて定められる本発明の範囲及び趣旨を逸脱することなく、形式や細部の様々な変更が可能であることは、当該技術分野における通常の知識を持つ者には明らかである。"