JP2013523003A - ネットワークにおいてサービス品質制御関連情報を報告する方法とこのためのネットワークエンティティ - Google Patents

ネットワークにおいてサービス品質制御関連情報を報告する方法とこのためのネットワークエンティティ Download PDF

Info

Publication number
JP2013523003A
JP2013523003A JP2012558073A JP2012558073A JP2013523003A JP 2013523003 A JP2013523003 A JP 2013523003A JP 2012558073 A JP2012558073 A JP 2012558073A JP 2012558073 A JP2012558073 A JP 2012558073A JP 2013523003 A JP2013523003 A JP 2013523003A
Authority
JP
Japan
Prior art keywords
packet
related information
qos
rtcp
network entity
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2012558073A
Other languages
English (en)
Other versions
JP5912089B2 (ja
Inventor
ソ，デュグ−ヨン
パク，クァン−フン
キム，キュ−ヒョン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Publication of JP2013523003A publication Critical patent/JP2013523003A/ja
Application granted granted Critical
Publication of JP5912089B2 publication Critical patent/JP5912089B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/24—Negotiating SLA [Service Level Agreement]; Negotiating QoS [Quality of Service]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5009—Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823—Errors, e.g. transmission errors
    • H04L43/0829—Packet loss
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/06—Transport layer protocols, e.g. TCP [Transport Control Protocol] over wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Quality & Reliability (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

ネットワークにおいてサービス品質（Quality of Service:ＱｏＳ）制御関連情報を報告する方法は、エンドツーエンド（end-to-end）の経路間に位置する中間ネットワークエンティティがチャンネル状態を測定してＱｏＳ制御関連情報を生成するステップと、中間ネットワークエンティティがＱｏＳ制御関連情報を、ＱｏＳを制御する他のネットワークエンティティに報告するステップと、を含む。

Description

本発明は、ネットワークにおいてサービス品質関連情報を報告する方法に関し、特にネットワークリンク及びノード情報を用いたリアルタイムマルチメディアサービスの品質向上方法及びこれを利用した機器に関する。
マルチメディアサービスのサービス品質制御のためのパラメータは、トラフィックパラメータ（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）の経路間に位置する中間ネットワークエンティティがチャンネル状態を測定してＱｏＳ制御関連情報を生成するステップと、上記中間ネットワークエンティティが上記ＱｏＳ制御関連情報を、上記ＱｏＳを制御する他のネットワークエンティティに報告するステップと、を含むことを特徴とする。
また、本発明の他の実施形態によってネットワークにおいてサービス品質（Quality of Service:ＱｏＳ）制御関連情報を報告するネットワークエンティティは、エンドツーエンド（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 ＸＭＲパケット内でもっとも大きいＩＥ番号がｎであり、ｎ個のＩＥを経たｉ番目の使用可能なビットレートをＲａｉと表すと、最終的に使用可能なビットレートは、下記の［数１］のように計算できる。
Figure 2013523003
同じ条件で、それぞれのＰＬＲ（Ｐｉ）を用いて最終的なパケット損失率（Ｐ）は［数２］のように計算できる。
Figure 2013523003
同じ条件で、それぞれのワンウェイ遅延（one way delay）Ｄｉを用いて最終的な遅延（Ｄ）は［数３］のように計算できる。
Figure 2013523003
同じ条件で、それぞれの使用可能なバッファーＢｉを用いて最終的に使用可能なバッファーサイズ（Ｂ）は、［数４］のように計算できる。
Figure 2013523003
オプション１では、受信器は、統合されたＸＭＲブロックをＲＲパケットに含めて、送信器またはＭＡＮＥに伝送してＱｏＳ適応動作が実行されるようにする。オプション２の場合には、送信器またはＭＡＮＥがＸＭＲブロックを統合し、すぐにＱｏＳ適応動作が実行されるようにする。オプション３の場合には、ＸＭＲパケットが受信器に送信されるのであれば、オプション１のように受信器がＸＭＲパケットを統合し、ＲＲパケットに含めて送信器またはＭＡＮＥに伝送してＱｏＳ適応動作が実行されるようにする。これに対し、オプション３で、ＸＭＲパケットが送信器に伝送されるのであれば、オプション２のように送信器またはＭＡＮＥがＸＭＲブロックを統合して、すぐにＱｏＳ適応動作が実行されるようにする。
ＸＭＲは、ＲＦＣ２３２７（セッション記述プロトコル（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）伝送である場合には、時々刻々に変わる各々の網の特性をＲＴＣＰ ＸＭＲを用いて測定し、測定結果に基づいて、使用可能な伝送リソースを用いて、可能な限りの最高の品質のサービスを提供することができる。
以上、本発明の詳細な説明においては具体的な実施形態に関して説明したが、特許請求の範囲の記載及びこれと均等なものに基づいて定められる本発明の範囲及び趣旨を逸脱することなく、形式や細部の様々な変更が可能であることは、当該技術分野における通常の知識を持つ者には明らかである。

Claims (15)

  1. ネットワークにおいてサービス品質（Quality of Service:ＱｏＳ）制御関連情報を報告する方法であって、
    エンドツーエンド（end-to-end）の経路間に位置する中間ネットワークエンティティがチャンネル状態を測定してＱｏＳ制御関連情報を生成するステップと、
    前記ＱｏＳ制御関連情報を、前記ＱｏＳを制御する他のネットワークエンティティに報告するステップと、を含むことを特徴とするＱｏＳ制御関連情報を報告する方法。
  2. 前記ＱｏＳ制御関連情報は、前記中間ネットワークエンティティに関連するパケット損失率、遅延、使用可能なビットレートのうち、少なくとも一つを含むことを特徴とする請求項１に記載のＱｏＳ制御関連情報を報告する方法。
  3. 前記ＱｏＳ制御関連情報は、ＲＴＣＰ（Real-time Transport Control Protocol）報告ブロック形式で生成されることを特徴とする請求項１に記載のＱｏＳ制御関連情報を報告する方法。
  4. 前記ＱｏＳ制御関連情報は、ＲＴＣＰ（Real-time Transport Control Protocol）報告ブロックを含むＩＰ（Internet Protocol）パケットの形式で生成されることを特徴とする請求項１に記載のＱｏＳ制御関連情報を報告する方法。
  5. 前記ＱｏＳ制御関連情報は、ＲＴＣＰ（Real-time Transport Control Protocol）報告ブロックを含むＲＴＣＰパケットの形式で生成されることを特徴とする請求項１に記載のＱｏＳ制御関連情報を報告する方法。
  6. 前記ＲＴＣＰパケットは、送信器報告パケット（Sender Report Packet）、受信器報告パケット（Receiver Report Packet）、そしてＸＭＲ（eXtended interMediate Report）パケットのうち、少なくとも一つであることを特徴とする請求項５に記載のＱｏＳ制御関連情報を報告する方法。
  7. 前記中間ネットワークエンティティは、ルータ、ＭＡＮＥ（Media Aware Network Entity）、無線通信システムの基地局のうち、少なくとも一つであることを特徴とする請求項１に記載のＱｏＳ制御関連情報を報告する方法。
  8. ネットワークにおいてサービス品質（Quality of Service:ＱｏＳ）制御関連情報を報告するネットワークエンティティであって、
    エンドツーエンド（end-to-end）の経路間においてチャンネル状態を測定してＱｏＳ制御関連情報を生成し、前記ＱｏＳ制御関連情報を、前記ＱｏＳを制御する他のネットワークエンティティに報告するように制御する制御器と、
    前記ネットワークを通して前記ＱｏＳ制御関連情報を前記他のネットワークエンティティに伝送する送信器と、を含むことを特徴とするネットワークエンティティ。
  9. 前記ＱｏＳ制御関連情報は、前記ネットワークエンティティに関連するパケット損失率、遅延、使用可能なビットレートのうち、少なくとも一つを含むことを特徴とする請求項８に記載のネットワークエンティティ。
  10. 前記制御器は、ＲＴＣＰ（Real-time Transport Control Protocol）報告ブロック形式で前記ＱｏＳ制御関連情報を生成することを特徴とする請求項８に記載のネットワークエンティティ。
  11. 前記制御器は、ＲＴＣＰ（Real-time Transport Control Protocol）報告ブロックを含むＩＰ（Internet Protocol）パケットの形式で前記ＱｏＳ制御関連情報を生成することを特徴とする請求項８に記載のネットワークエンティティ。
  12. 前記制御器は、ＲＴＣＰ（Real-time Transport Control Protocol）報告ブロックを含むＲＴＣＰパケットの形式で前記ＱｏＳ制御関連情報を生成することを特徴とする請求項８に記載のネットワークエンティティ。
  13. 前記ＲＴＣＰパケットは、送信器報告パケット（Sender Report Packet）、受信器報告パケット（Receiver Report Packet）、そしてＸＭＲ（eXtended interMediate Report）パケットのうち、少なくとも一つであることを特徴とする請求項１２に記載ののネットワークエンティティ。
  14. 前記ネットワークエンティティは、ルータ、ＭＡＮＥ（Media Aware Network Entity）、無線通信システムの基地局のうち、少なくとも一つであることを特徴とする請求項８に記載のネットワークエンティティ。
  15. 前記制御器は、サービスの種類別に前記ＱｏＳ制御関連情報を生成することを特徴とする請求項８に記載のネットワークエンティティ。
JP2012558073A 2010-03-12 2011-03-11 ネットワークにおいてサービス品質制御関連情報を報告する方法とこのためのネットワークエンティティ Expired - Fee Related JP5912089B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
KR10-2010-0022497 2010-03-12
KR1020100022497A KR101705359B1 (ko) 2010-03-12 2010-03-12 네트워크에서 서비스 품질 제어 관련 정보를 보고하는 방법과 이를 위한 네트워크 엔터티
PCT/KR2011/001726 WO2011112043A2 (en) 2010-03-12 2011-03-11 Method for reporting qos control-related information in network and network entity therefor

Publications (2)

Publication Number Publication Date
JP2013523003A true JP2013523003A (ja) 2013-06-13
JP5912089B2 JP5912089B2 (ja) 2016-05-11

Family

ID=44559876

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012558073A Expired - Fee Related JP5912089B2 (ja) 2010-03-12 2011-03-11 ネットワークにおいてサービス品質制御関連情報を報告する方法とこのためのネットワークエンティティ

Country Status (6)

Country Link
US (1) US20110222403A1 (ja)
EP (1) EP2545730B1 (ja)
JP (1) JP5912089B2 (ja)
KR (1) KR101705359B1 (ja)
CN (1) CN102792733A (ja)
WO (1) WO2011112043A2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018509786A (ja) * 2014-12-08 2018-04-05 サムスン エレクトロニクス カンパニー リミテッド 無欠性検査データ提供方法及びその装置

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9072005B2 (en) 2011-04-20 2015-06-30 Qualcomm Incorporated Quality of service control in a multicast transmission
US8767576B2 (en) * 2011-08-17 2014-07-01 Verizon Patent And Licensing Inc. Accessing an application based on a level of service quality
US9178778B2 (en) 2012-03-23 2015-11-03 Avaya Inc. System and method for end-to-end RTCP
US9860296B2 (en) 2012-03-23 2018-01-02 Avaya Inc. System and method for end-to-end call quality indication
US9356917B2 (en) 2012-03-23 2016-05-31 Avaya Inc. System and method for end-to-end encryption and security indication at an endpoint
GB2500740B (en) * 2012-03-23 2014-07-09 Avaya Inc System and method for end-to-end RTCP
US10182487B2 (en) * 2012-11-30 2019-01-15 Enlighted, Inc. Distributed fixture beacon management
US9743231B2 (en) * 2015-08-25 2017-08-22 Verint Systems Ltd. System and method for using multiple networks to estimate a location of a mobile communication terminal
US11206297B2 (en) * 2018-03-19 2021-12-21 Livescale Technologies Inc. Video streaming
US10721174B2 (en) * 2018-10-09 2020-07-21 Cisco Technology, Inc. Network-based coordination of loss/delay mode for congestion control of latency-sensitive flows
CN112584418A (zh) * 2019-09-27 2021-03-30 中兴通讯股份有限公司 媒体流传输质量通知方法和会话边界控制实体
KR20210097285A (ko) 2020-01-30 2021-08-09 삼성전자주식회사 이동통신 네트워크의 미디어 처리 및 전송에 대한 지연을 할당하기 위한 장치와 방법
CN113765732A (zh) * 2020-06-02 2021-12-07 华为技术有限公司 网络性能的测量方法、装置、设备、系统及存储介质
US12101532B2 (en) 2020-10-27 2024-09-24 Circle Computer Resources, Inc. Low-latency content delivery over a public network

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002281078A (ja) * 2001-03-21 2002-09-27 Ntt Docomo Inc 通信品質制御方法、通信品質制御システム、パケット解析装置及びデータ送信端末装置
JP2005073211A (ja) * 2003-08-28 2005-03-17 Kddi Corp 品質レポートサーバ及びシステム
JP2006352420A (ja) * 2005-06-15 2006-12-28 Kddi Corp 通信品質情報を含む品質パケットを送受信する端末、品質レポートサーバ及びプログラム

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7894354B2 (en) * 2002-10-04 2011-02-22 Jds Uniphase Corporation System and method to monitor RTP streams using RTCP SR/RR packet information
KR100724680B1 (ko) * 2005-11-14 2007-06-04 주식회사 케이티 패킷 전송 품질 측정 시스템 및 그 방법
US20070239820A1 (en) * 2005-11-23 2007-10-11 Nokia Corporation System and method for providing quality feedback metrics for data transmission in rich media services
US7796532B2 (en) 2006-05-31 2010-09-14 Cisco Technology, Inc. Media segment monitoring
KR20070120257A (ko) * 2006-06-19 2007-12-24 주식회사 케이티 차세대 통신망에서 실시간성 서비스에 대한 품질 분석시스템 및 그 분석 방법
US8064391B2 (en) * 2006-08-22 2011-11-22 Embarq Holdings Company, Llc System and method for monitoring and optimizing network performance to a wireless device
US20080137552A1 (en) * 2006-12-06 2008-06-12 Hyun Woo Lee APPARATUS AND METHOD OF MEASURING AND MANAGING REAL-TIME SPEECH QUALITY IN VoIP NETWORK
US8767636B2 (en) * 2007-08-21 2014-07-01 Optis Cellular Technology, Llc Scheduling in wireless networks
JP2009055327A (ja) * 2007-08-27 2009-03-12 Hitachi Ltd ネットワークシステム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002281078A (ja) * 2001-03-21 2002-09-27 Ntt Docomo Inc 通信品質制御方法、通信品質制御システム、パケット解析装置及びデータ送信端末装置
JP2005073211A (ja) * 2003-08-28 2005-03-17 Kddi Corp 品質レポートサーバ及びシステム
JP2006352420A (ja) * 2005-06-15 2006-12-28 Kddi Corp 通信品質情報を含む品質パケットを送受信する端末、品質レポートサーバ及びプログラム

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018509786A (ja) * 2014-12-08 2018-04-05 サムスン エレクトロニクス カンパニー リミテッド 無欠性検査データ提供方法及びその装置
US10516677B2 (en) 2014-12-08 2019-12-24 Samsung Electronics Co., Ltd. Method and apparatus for providing integrity check data

Also Published As

Publication number Publication date
EP2545730B1 (en) 2016-09-07
KR101705359B1 (ko) 2017-02-10
CN102792733A (zh) 2012-11-21
KR20110103259A (ko) 2011-09-20
EP2545730A4 (en) 2014-03-26
EP2545730A2 (en) 2013-01-16
JP5912089B2 (ja) 2016-05-11
US20110222403A1 (en) 2011-09-15
WO2011112043A3 (en) 2012-01-12
WO2011112043A2 (en) 2011-09-15

Similar Documents

Publication Publication Date Title
JP5912089B2 (ja) ネットワークにおいてサービス品質制御関連情報を報告する方法とこのためのネットワークエンティティ
TWI594641B (zh) 保留通訊網路中交接之應用識別資訊的系統及方法
Hwang et al. Cross‐Layer End‐to‐End QoS for Scalable Video over Mobile WiMAX
JP4927333B2 (ja) 帯域幅適応
US8942243B2 (en) Adaptive rate control in a communications system
US7944880B2 (en) Method and arrangement for establishing a communication session for multimedia
EP2022201B1 (en) Media segment monitoring
US9838209B2 (en) Method for subscribing to streams from multicast clients
US20120026876A1 (en) Technique for admission control of packet flows
TW200822617A (en) Method and system for guaranteeing QoS between different radio networks
Siomina et al. The impact of QoS support on the end user satisfaction in LTE networks with mixed traffic
Hajlaoui et al. Experimental performance evaluation and frame aggregation enhancement in IEEE 802.11 n WLANs
Musabe et al. Evaluation of a new scheduling scheme for VoIP with mobility in 3G LTE
Bayer et al. Application-aware scheduling for VoIP in wireless mesh networks
NYAMBO et al. Quality of service in mobile ad hoc networks, carrying multimedia traffic
Jung et al. Home/office intranet resource management for QoS-guaranteed realtime stream service provisioning on IEEE 802.11 e WLAN
Musabe et al. A new scheduling scheme for voice awareness in 3G LTE
Fernàndez et al. An enhanced quality of service method for guaranteed bitrate services over shared channels in egprs systems
Lin et al. Provisioning an end to end QoS for VoIP over WiMAX network
Beaufort et al. Measured performance of TCP friendly rate control protocol over a 2.5 G network
Coronado et al. SDN@ Play as a strategy to enhance the multicast delivery rate in WLANs
Singh Rate-control for RTP-based multimedia applications
JP4634501B2 (ja) ネットワークシステム、ポリシーサーバ及びポリシー設定方法
Heiskanen Quality of Person-to-Person Services in the Third Generation Partnership Project Architecture
Vivekananda et al. ESCTP optimized unidirectional delay technique for the efficient video transmission in MANETs

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20130926

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20131001

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20131225

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140304

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140603

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20140701

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20141104

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20141105

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20141127

A912 Re-examination (zenchi) completed and case transferred to appeal board

Free format text: JAPANESE INTERMEDIATE CODE: A912

Effective date: 20141219

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20151028

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20151130

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20160126

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160331

R150 Certificate of patent or registration of utility model

Ref document number: 5912089

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees