JP2007520905A - 無線通信ネットワークシステム、通信システム及び通信デバイスにおけるリソース予約のための方法とシステム - Google Patents

無線通信ネットワークシステム、通信システム及び通信デバイスにおけるリソース予約のための方法とシステム Download PDF

Info

Publication number
JP2007520905A
JP2007520905A JP2006516253A JP2006516253A JP2007520905A JP 2007520905 A JP2007520905 A JP 2007520905A JP 2006516253 A JP2006516253 A JP 2006516253A JP 2006516253 A JP2006516253 A JP 2006516253A JP 2007520905 A JP2007520905 A JP 2007520905A
Authority
JP
Japan
Prior art keywords
media stream
transmitting
transmission
wireless communication
receiving device
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.)
Withdrawn
Application number
JP2006516253A
Other languages
English (en)
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.)
Nokia Oyj
Original Assignee
Nokia Oyj
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 Nokia Oyj filed Critical Nokia Oyj
Publication of JP2007520905A publication Critical patent/JP2007520905A/ja
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/74—Admission control; Resource allocation measures in reaction to resource unavailability
    • H04L47/748—Negotiation of resources, e.g. modification of a request
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/801—Real time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/805—QOS or priority aware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/808—User-type aware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/824—Applicable to portable or mobile terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/825—Involving tunnels, e.g. MPLS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/752—Media network packet handling adapting media to network capabilities
    • 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/18—Negotiating wireless communication parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities
    • 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/26—Resource reservation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/12—Setup of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/15—Setup of multiple wireless link connections

Landscapes

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

Abstract

本発明は、通信システムでの方法、通信システム及び通信デバイスに関する。その方法では、ストリームは送信デバイスから受信デバイスへ無線通信ネットワークを介して送信される。少なくとも１つのメディアストリームが受信デバイスに送信され、選択された少なくとも１つのメディアストリームを送信するためのＱｏＳ要件が定義され、送信リソースが少なくとも１つのメディアストリームの送信のために予約され、設定手続が１つのデータ伝送を有効にするために送信デバイスと受信デバイス間で実行される。少なくとも１つのメディアストリームの送信開始は、受信デバイスから要求され、１つのデータ伝送コンテキストは、選択された少なくとも１つのメディアストリームの伝送で使用される。そこでは、予約リソースに関する情報が、少なくとも１つのメディアストリームの送信開始が受信デバイスによって要求された時又は後に送信される。

Description

本技術分野は、マルチメディアサーバ、移動体ネットワーク、及び、ストリーミングクライアントが論理的に、例えば、メディア転送のためのＲＴＳＰプロトコル（リアルタイム・ストリーミング・プロトコル）を介して、接続されている移動体ネットワーク上のストリーミングメディアの技術分野である。ストリーミングシステムは、速度に適応する場合と、そうでない場合がある。この発明は、変化するネットワーク通信路状況に対して、コンテンツ及び／又は伝送速度を適応させる速度適応ストリーミングシステムに関する。
本発明は、さらに、マルチメディアストリームが送信デバイスから、受信デバイスへ、少なくとも部分的に無線通信システムを介してマルチメディアストリームを伝送するための送信デバイス、受信デバイス、及び通信ネットワークを備える通信システムに関する。本発明は、さらに、送信デバイス及び受信デバイスに関する。
この記述においては、送信デバイス（sending communication device）という用語は、マルチメディアストリームを通信ネットワークに送信するようになっている送信機を含む通信デバイスに言及し、受信デバイス（receiving communication device）という用語は、その通信ネットワークからマルチメディアストリームを受信するための受信機を含む通信デバイスに、それぞれ、言及する。同じ通信デバイスは、通信機と受信機両方を含み、それにより、通信ネットワークと共に片方向又は双方向通信が可能である。無線通信デバイスは、無線通信ネットワーク内で無線通信を実装する送信機及び／又は受信機を含む。移動体通信システムのような、無線通信システムという用語は、無線通信デバイスと、そのシステムの固定部品、及び、そのシステムの動作可能範囲内に移動する無線通信デバイスのユーザとの間にあり得る無線データ伝送接続をするいかなる通信システムに、一般に、言及する。典型的な無線通信システムは、公衆陸上移動網（ＰＬＭＮ：Public Land Mobile Network）である。良く知られた例は、ＧＳＭシステム（移動体通信用グローバルシステム）である。本発明は、好ましくは、移動体通信システムの第３世代に関する。
第３世代では、ベアラサービス（bearer service）及びサービスという用語が使用される。ベアラサービスは、電気通信サービスタイプであり、ベアラサービスは、アクセスポイント間の信号を伝送する便宜を提供する。一般に、ベアラサービスは、通信路（channel）という用語に相当し、通信路は、例えば、データ伝送速度、及び、情報が無線通信デバイスとシステムの別の部分間に伝送されるとき、そのシステムで使用されるべきクオリティ・オブ・サービス（ＱｏＳ：Quality Of Service）を規定する。無線通信デバイスと基地局間のベアラサービスは、例えば、無線ベアラサービス、及び、無線通信制御ユニットと、例えば論理ユニット（ｌｕ）ベアラサービス（インタフェースＵＭＴＳベアラ）であるコアネットワーク間のベアラサービスである。ＵＭＴＳシステムでは、無線ネットワーク制御ユニットと、コアネットワーク間のインタフェースは、ｌｕインタフェースと呼ばれる。ＵＭＴＳでは、一般に、ＧＥＲＡＮ部分、ｌｕインタフェースに加えて、Ｇｂインタフェースと呼ばれるインタフェースもある。これに関して、サービスは、タスクを実行する移動体通信ネットワークにより提供される。例えば、データサービスは、通信システムの中でデータ伝送を実行し、電話サービスは、電話、マルチメディア等に関連する。従って、サービスは、無線通信デバイスとそのシステムの固定部分間の電話又はマルチメディアストリーム伝送のようなデータ伝送を要求する。第３世代移動体通信システムの１つの重要なタスクは、各要求サービスが利用可能な帯域を消費せずに移動局に配置可能であるような方法で、ベアラサービスを（開始、維持、終了、その要求に従って）制御することである。
ＱｏＳは、例えば、プロトコルデータ単位（ＰＤＵ：Protocol Data Unit）が、伝送中に移動体通信ネットワークでどのように処理されるかを決定する。接続アドレスのために規定されるＱｏＳレベルは、特に、２つ以上の接続が同時に送信されるパケットを有するとき、例えば、送信順番を制御し、（パケット文字列を）バッファリングし、サポートノード及びゲートウェイノードでパケットを破棄するために使用される。異なるＱｏＳレベルは、例えば、異なるビット速度はもちろんのこと、異なる接続末端間のパケット伝送のための異なる遅延を決定する。また、破棄及び／又は欠損パケットデータ単位は、異なるＱｏＳレベルを有するコネクション（connection）において変化する。
各ＰＤＰコンテキスト（context）のための異なるＱｏＳを要求することが可能である。例えば、電子メールコネクションにおいて、相対的に長い遅延は、ストリームの伝送において許可される。しかし、ビデオカンファレンス（video conference）のようなリアルタイムインタラクティブ的応用は、高速度でのパケット伝送を要求する。ファイル転送のような、幾つかの応用においては、パケット交換伝送（packet switched Transmission）は、失敗が無いということは重要であり、エラー状況では、必要ならパケットデータ単位が再送信される。
ＵＭＴＳネットワークでのパケット交換通信サービスのために、４つの異なるトラフィッククラスの定義が提案されており、これらのトラフィッククラスの特性にとって、その目的は、異なる接続タイプのための異なる基準を考慮された。第１及び第２クラスのために規定される１つの基準は、伝送がリアルタイムで起こるということであり、そこでは、伝送に重要な遅延が全く無い必要がある。しかし、そのようなクラスでは、データ伝送の速度は、それほど重要な性質では無い。相当する方法では、非リアルタイムデータ伝送は、第３及び第４トラフィッククラスのために十分であるが、相対的に正確なデータ伝送が要求される。リアルタイム第１クラス通信の例は、二人以上が無線通信デバイスで互いに議論する状況における対話型のスピーチ信号の伝送である。リアルタイム第２クラス通信における状況例は、すぐに見れる（ストリーミング）ためのビデオ信号の伝送である。第３クラス非リアルタイムパケット通信は、例えば、相対的に妥当な速度でデータ伝送精度がリアルタイムデータ伝送より重要な要素であるインターネットホームページのブラウジングのような、データベースサービス使用のために使われる。この例によるシステムでは、例えば、電子メールメッセージとファイル転送は、第４カテゴリに分類される。自然に、トラフィッククラスの数は、必ずしも、ここで述べられる４つでは無いが、本発明はいかなるトラフィッククラスをも有するパケット交換通信システムに適応可能である。４つの表されるトラフィッククラスの特性は、簡単に、表１に表される。
Figure 2007520905
Figure 2007520905
保障ビット速度（guaranteed bit rate）は、ＲＡＮとＣＮでの管理制御及びリソース予約用に使用される。最大ビット速度（maximum bit rate）は、ＣＮでの規定決め用に使用される。即ち、ＧＧＳＮでのＣＮを入れることが出来る最大ビット速度より速くない、このビット速度を越えるパケットは、欠損するだろう。
近年の第２及び第３世代無線通信デバイスは、それより古い通信デバイスより、データ処理特性はずっと良い。例えば、それらは、すでに、インターネットに接続する設備を有し、かつ、インターネットから情報を獲得するために無線通信デバイス内でブラウジングを用い、例えば、リアルタイムビデオカンファレンス等のようなマルチメディア呼び出しを設定することも可能である。
異なる応用の要件は、非常に重要である。幾つかの応用は、送信側と受信側の間の速い通信を要求する。これらの応用は、例えば、ビデオ及び電話の応用を含む。幾つかの他の応用は、可能な限り精度のあるデータ伝送を要求するが、データ伝送接続（data transmission connection）のビット速度は、殆ど重要ではない。これらの応用は、例えば、電子メール及びデータベースの応用を含む。他方では、これらの応用は、異なる特性を有する幾つかの通信デバイスにおいて使用される。
無線通信デバイスのユーザは、無線通信デバイスと共に、マルチメディアプレゼンテーションを見ようとする。そのユーザは、そのようなプレゼンテーションの読み込みアドレス（loading address）を見つけ、その無線通信デバイスに対してプレゼンテーションを送信するための要求（request）を送る。その要求は、通信システムで処理される。要求されたマルチメディアプレゼンテーションの読み込みアドレスは、インターネットのサーバのような通信ネットワーク内のサーバにアドレス指定する。無線受信デバイスに対してマルチメディアプレゼンテーションを送るサーバは、ここの記載において、ストリーミングサーバとして呼ばれる。
通信システムは、ストリーミングサーバと要求されるマルチメディアプレゼンテーションを送信可能な無線通信デバイスとの間の通信のための十分なリソースを予約する。さもなければ、そのプレゼンテーションは、無線受信デバイスにおいて同じ精度及びエラー無しで表されないだろう。ＵＭＴＳ通信システムでは、無線通信デバイスは、ＰＤＰコンテキストをあるＱｏＳパラメータと共に、最初に要求する。それから、そのネットワークは、幾つかの選択ベースを用いることで、その接続用のベアラを選択する。幾つかの選択ベースは、例えば、無線通信デバイスが有するパラメータが、その要求の中で使用され得る選択ベースである。そのような選択ベースは、ベアラサービスが十分にその接続のための伝送容量を供給できない場合、適当ではなく、また、十分な精度を有せず、又は、ネットワークリソースの使用が効率的でない場合、そのような選択ベースは、その要求より十分な容量を供給できない。
マルチメディア情報の配信が必要とされる別の状況は、ビデオや静止画のようなマルチメディア情報を交換するために互いに通信する２つの無線通信デバイスである。また、この種の状況では、十分なリソースが通信用ネットワークによって予約されるべきである。しかし、従来技術の方法を用いるとき、接続要求について、接続末端の両方に通知することは必ずしも可能ではない。
基本ストリーミングシステムは、非適応（non-adaptive）である。例えば、リリース４及び５で３ＧＰＰにより規定される現在のパケット交換ストリーミングサービス（ＰＳＳ）は、非適応である。リリース６においてパケット交換ストリーミングサービス（ＰＳＳ）は、適応（adaptive）できる。適応特性は、そのシステム、変化するネットワーク通信路状況に適応する、即ち、ストリーミングサーバとクライアント両方の能力によって得られ、変化するネットワークとは、ＱｏＳネゴシエート通信路ビット速度、配信遅延、他のＱｏＳパラメータ、ハンドオーバの場合での基礎をなすネットワークにおける変化のようなものである。
そのシステムを適応可能にするために、ストリーミングサーバとクライアントの幾つかの通信が成立されなければならない。これは、ＲＴＳＰプロトコルがセッション設定（session setup）及び制御に使用されるときはどんなときでも、すでに適切にされている。しかし、サーバとクライアント間に必要な情報の伝送は、そのシステムが適応可能であり、究極的に、画像及び音声用の最高のユーザＱｏＳが達成されることを保障するために、正しい方法で起こる必要がある。
この目的のために、幾つかの従来技術が、基礎となる移動体ネットワークに由来する、ストリーミングクライアントからストリーミングサーバへの、ＱｏＳ情報の伝送を可能にする。これは、そのシステムをより適応可能にするために、最終端間のさらなる協調を可能にする。
これまで明確にされていないものは、明確な移動体ネットワーク環境下のＱｏＳパラメータ間の関係であり、かつ、ＰＤＰ（パケットデータプロトコル）コンテキストの使用である。例えば、異なる場合が可能である。以下では、各ＲＴＰストリームに関連する関係ＲＴＣＯフローは、考慮されない。代わりに、ＲＴＰと同じマルチメディアストリームの部分として、その関連ＲＴＣＰフローが考慮されるが、問題の本質は変わらない。
１．ＰＤＰコンテキストは、ストリーミングセッションのただ１つのメディアを搬送する。
２．ＰＤＰコンテキストは、ストリーミングセッションに１つ以上のメディアがある場合、ストリーミングセッションにおける全メディアを搬送する。
ストリーミングクライアントが、例えばＲＴＳＰを介してストリーミングサーバに、ＱｏＳプロファイルパラメータ、例えば、保障ビット速度、最大ビット速度、転送遅延を知らせるなら、幾つかの問題が、ＱｏＳプロファイルの正しい解釈、及び、結局は、ネットワーク接続の本質で生ずるかもしれない。
ＲＴＳＰでは、２種類のセッションが有り、一般に集約制御セッション（aggregate controlled session）と非集約制御セッション（non-aggregate controlled session）と呼ばれる。集約制御セッションは、トランスポートレベルでのセッションで、全てのメディアコンポネントは、クライアントによりサーバに送信される単一コマンド（例えば、映像及び音楽コンポネント両方のための１つのＲＴＳＰ ＰＬＡＹコマンド）により制御される。これが生じない、即ち、少なくとも１つの映像コンポネントが、セッション内で個別に制御される場合は、そのセッションは、非集約制御を有すると言われる。
以下では、幾つかの例が、マルチメディアストリーム用ＱｏＳパラメータのネゴシエーション（negotiation）に関する問題を明確にするために開示される。例及び例で使用される異なるパラメータは、非制限的であり、そして、メディアストリームの異なる種類のパラメータ及び組合せの実際的な実装が存在するということに注意すべきである。
例１
この例では、マルチメディアストリームは、２つの媒体（例えば、１つは音声ストリームそして１つは映像ストリーム）を含む。全ての異なるメディアは、単一のＰＤＰコンテキストを用いて伝送される。
ストリーミングクライアントは、ストリーミングサーバ（例えば、ＳＤＰプロトコルを介して）通知を受信し、音声ストリームは１２kbps、及び、画像ビットストリームは５２kbpsを要求するとする。ストリーミングクライアントは、単一のＰＤＰコンテキストを用いて、クライアントが音声及び映像ストリーム両方の伝送を望む移動体ネットワークとの接続を成立し、ネットワークは、次の（他の中の）ＱｏＳプロファイルパラメータと共にＰＤＰコンテキストを許可したとする。
Guaranteed bit rate = 64 kbps
Maximum bit rate = 70 kbps
システムをもっと適応可能にするために、ストリーミングクライアントが、そのネットワークから許可ＱｏＳ（granted QoS）についてストリーミングサーバに知らせたいとする。その効率を上げるために、クライアントは、２つの媒体の再生を開始する前に、その情報をシグナリングすることを決めたとする。それゆえ、クライアントは、ＳＥＴＵＰメソッドを用いて、２つのフィールドをシグナリングすることを決める。２つのメディアがあるので、クライアントは、次の情報と共に、２つのＳＥＴＵＰメッセージ（１つは音声、１つは映像）に貼り付けた２つのフィールドを送信する。
SETUP(Audio):
Guaranteed bit rate = 12 kbps
Maximum bit rate = 70 kbps
SETUP(Video):
Guaranteed bit rate = 52 kbps
Maximum bit rate = 70 kbps
各SETUPにおける信号で伝えられる保障ビットレート（Guaranteed bit rate）は、（ストリーミングサーバとストリーミングクライアント両方に知られる）各メディアのために要求される帯域幅を含めるが、最大ビット速度（Maximum bit rate）情報は、ＰＤＰコンテキストの中で許可された最大ビット速度であるだけである。それゆえ、この例では、７０kbpsより他の速度ではない。なぜなら、２つのメディア間に最大ビット速度を分ける方法は無いからである。SETUPメソッドは、ストリーミングサーバによって、メディア毎の情報として解釈される。それゆえ、サーバは、２つのSETUPメッセージ（12kbpsの保障ビット速度と70kbpsの最大ビット速度を有する１つの通信路、及び、52kbpsの保障ビット速度と70kbpsの最大ビット速度を有する別の通信路）によって記述される特性と共に、事実上２つのネットワーク通信路かのように解釈する。そのメディアの累積最大ビット速度は、12+52=64 kbpsであり、それは、ＰＤＰコンテキストの実際のネットワーク保障速度である。サーバは、映像用70kbps最大ビット速度と音声用70kbps最大ビット速度を送信する権利を与えられる。単一のＰＤＰコンテキストが使用されるとき、これは、そのメディアの蓄積最大ビット速度は、70+70=140 kbpsであることを意味し、それは、ＰＤＰコンテキスト用ネットワーク最大ビット速度ではない。各メディアストリームは、可変ビット速度で伝送され、２つの媒体の瞬間的ビット速度の合計は、いかなる時においても、140 kbpsに到達する。しかし、ネットワーク（例えば、70 kbps）によって提供される最大ビット速度より大きいどの値も許されない。なぜなら、そのネットワークリソースは、利用できないからである。それゆえ、サーバは、ＰＤＰコンテキストのＱｏＳ情報を誤まって解釈するように導かれる。これが、バッドユーザＱｏＳ（bad user QoS）を促進する。
他方では、２つのメディア間の適当な方法で70kbpsを分割することを考慮することは、異なるメディア間で共有されるチャネル使用のサブオプション的使用をするために、サーバを導くことである。サーバは、２つの分割ＰＤＰコンテキストであるかのように通信路を使おうとする。
サーバに送信される保障ビット速度情報が、ＰＤＰコンテキスト内で、ネットワークにより本当に許可されるものかどうかという、類似の問題が生じる。例えば、許可された64kbps保障ビット速度は、両方のSETUPメッセージ内でサーバに送られるならば、さらなる問題が発生する。なぜなら、サーバが合計保障ビット速度128kbpsにして、均等な音声64kbps、映像64kbpsの保障ビット速度で送信することを保障するからである。そしてそれは、この例におけるPDP QoSで利用できない。これは、ネットワークバッファのオーバーフローと、バッドユーザQoSを生む。
例２
この例では、マルチメディアストリームは、さらに、２つのメディア（１つは映像ストリーム、１つは音声ストリーム）を含み、しかし、全ての異なるメディアは、分割ＰＤＰコンテキストを用いて送信される。
ストリーミングクライアントが、音声ストリーム12kbpsと映像ストリーム52kbpsを（例えば、SDPプロトコルを介して）要求するストリーミングサーバから通知を受け取ることを考える。さらに、ストリーミングクライアントが２つの分割ＰＤＰコンテキストを用いて、そのクライアントが映像と音声ストリームをそれぞれ送信したい移動体ネットワークとの接続を確立すること、及び、そのネットワークが次の（その他の中に）ＱｏＳプロファイルパラメータと共にＰＤＰコンテキストを許可することを考える。
PDP context for Audio:
Guaranteed bit rate = 12 kbps
Maximum bit rate = 20 kbps
PDP context for Video:
Guaranteed bit rate = 52 kbps
Maximum bit rate = 64 kbps
ストリーミングクライアントが、システムをより適応可能にするために、ネットワークから許可されたＱｏＳについて、ストリーミングサーバに通知しようとすることを考える。そのＱｏＳ情報は、ＰＬＡＹコマンドで送信される。ＰＬＡＹコマンドは、一般に、情報収集セッションコマンドとしてサーバにより翻訳される。それゆえ、ただ一組のパラメータが送信されなければならない。クライアントは、保障ビット速度12+52=64kbps、及び、最大ビット速度20+64=84kbpsを送信することを決定する。これは、サーバを混乱させ、サーバは、ただ１つのＰＤＰコンテキストが、明確なＱｏＳパラメータで使用されると理解し、そしてそれは、この例におけるケースに該当しないことになる。
上述の両方の例では、主要問題は、ストリーミングサーバは、（ただ１つの又は複数の通信路である）データ伝送用に保存されたネットワーク通信路のタイプがどんなものであるか知らないということである。なぜなら、それは、ＰＤＰコンテキスト配置タイプに関して視認性を有しないからである。その視認性は、ストリーミングクライアントのみが有している。
従って、本発明の目的は、クライアントにより、ネットワークＰＤＰコンテキストのＱｏＳ情報について、通知されるとき、サーバが遭遇する可能性のある誤解を解決しようとする方法と発明を表すことである。
本発明のその目的は、そのネットワークによりクライアントへ許可されるセッションプロパティについて、サーバに通知するための方法をシグナリングするパラメータの異なる種類を用いて達成することである。
本発明の第１の形態によれば、受信デバイスに送信される少なくとも１つのメディアストリームを選択するステップ、その選択された少なくとも１つのメディアストリームを送信するためのＱｏＳ要件（requirement）を規定するステップ、その少なくとも１つのメディアストリームのその送信のために、無線通信ネットワークから送信リソースを予約するステップ、１つのパケットデータ伝送接続を有効にするために、その受信デバイスと送信デバイス間の設定手続を実行するステップ、その受信デバイスにより、その少なくとも１つのメディアストリームの送信開始を要求するステップ、その送信デバイスから、その受信デバイスへ、少なくとも部分的に無線通信ネットワークを介して、メディアストリームを送信するステップであって、その送信ステップは、その選択された少なくとも１つのメディアストリームの送信内の１つのデータ伝送コンテキストを用いるステップ、を有する通信システムでの方法において、その受信デバイスによりその少なくとも１つのメディアストリームその送信の開始のその要求時、又は、その後で、その予約リソースに関する情報を、その送信デバイスに送信するステップ、をさらに有する方法が提供される。
本発明の第２の形態によれば、受信デバイスに送信されるべき少なくとも１つのメディアストリームを選択するステップ、その選択された少なくとも１つのメディアストリームを送信するためのＱｏＳ要件を定義するステップ、その少なくとも１つのメディアストリームのその送信用の無線通信ネットワークから送信リソースを予約するステップ、少なくとも１つのパケットデータ伝送接続を有効にするために、その受信デバイスとその送信デバイス間の設定手続を実行するステップ、その受信デバイスによってその少なくとも１つのメディアストリームの送信開始を要求するステップ、その送信デバイスから、その受信デバイスへ、少なくとも部分的にその無線通信ネットワークを介して、メディアストリームを送信するステップであって、各選択メディアストリームのための１つのデータ伝送コンテキストを用いる送信ステップ、を有する通信システムでの方法において、その設定手続に関連して、その送信デバイスへ、その予約リソースに関する情報を送信するステップをさらに有する方法が提供される。
本発明の第３の形態によれば、送信デバイスから受信デバイスへ少なくとも１つのメディアストリームを送信するためのＱｏＳ要件に関する情報を、受信デバイスにより要求し、その少なくとも１つのメディアストリームのその送信のために、無線通信ネットワークから送信リソースを、その受信デバイスにより要求するステップ、その送信のためのリソースを、その無線通信ネットワークにより予約するステップ、その予約リソースに関する情報を、その受信デバイスへ、その無線通信ネットワークにより、送信し、その１つのパケットデータ伝送接続を有効にするために、その受信デバイスとその送信デバイスにより、設定手続を実行するステップ、その送信デバイスへ送信コマンドの開始を送信することによるその少なくとも１つのメディアストリームのその送信の開始を、その受信デバイスにより要求するステップであって、そこでは、その予約リソースに関する情報もあるコマンドが、その送信デバイスに送信され、送信デバイスから受信デバイスへ、少なくとも部分的に無線通信ネットワークを介して、１つのパケットデータ伝送接続を用いて、メディアストリームを送信する要求ステップを有する通信システムでの方法が提供される。
本発明の第４の形態によれば、送信デバイスから受信デバイスへ少なくとも１つのメディアストリームを送信するために、ＱｏＳ要件に関する情報を、受信デバイスによって要求するステップ、その少なくとも１つのメディアストリームのその送信のために、無線通信ネットワークから送信リソースを、その受信デバイスにより要求するステップ、その送信のためのリソースを、その無線通信ネットワークにより予約し、その少なくとも１つのパケットデータ伝送接続を有効にするために、その受信デバイスとその送信デバイスにより、その送信デバイスへのその予約リソースに関する情報をその受信デバイスによって送信する設定手続を実行するステップ、その送信デバイスに、送信コマンドの開始を送信することによって、その少なくとも１つのメディアストリームのその送信の開始を要求するステップであって、そこで、その予約リソースに関する情報無しコマンドは、その通信デバイスに送信される要求ステップ、を有する通信システムでの方法において、その送信デバイスからその受信デバイスへ、少なくとも部分的にその無線通信ネットワークを介して、少なくとも１つのパケットデータ伝送接続を用いて、メディアストリームを送信するステップを、さらに有する方法が提供される。
本発明の第５の形態によれば、送信デバイスから受信デバイスへ少なくとも部分的に無線通信ネットワークを介してメディアストリームを送信する手段と、その受信デバイスに送信されるべき少なくとも１つのメディアストリームを選択する手段と、その選択された少なくとも１つのメディアストリームを送信するために、ＱｏＳ要件を規定する手段と、その少なくとも１つのメディアストリームのその送信のために、その無線通信ネットワークから送信リソースを予約する手段と、１つのパケットデータ伝送接続を有効にするために、その受信デバイスとその送信デバイス間の設定手続を実行する手段と、その少なくとも１つのメディアストリームのその送信の開始を、その受信デバイスにより要求する手段と、その選択された少なくとも１つのメディアストリームのその送信の中に１つのデータ伝送コンテキストを用いる手段と、その送信デバイスへその予約リソースに関する情報を、その少なくとも１つのメディアストリームのその送信の開始が、その受信デバイスにより要求されるとき、又は、その後で送信する手段と、を備える通信システムが提供される。
本発明の第６の形態によれば、送信デバイスから受信デバイスへ、少なくとも部分的に無線通信ネットワークを介して、少なくとも１つのパケットデータ伝送接続を用いてメディアストリームを送信する手段と、その受信デバイスに送信されるべき少なくとも１つのメディアストリームを選択する手段と、その選択された少なくとも１つのメディアストリームを送信するために、ＱｏＳ要件を定義する手段と、その少なくとも１つのメディアストリームのその送信のために、その無線通信ネットワークから送信リソースを予約する手段と、その少なくとも１つのパケットデータ伝送接続を有効にするために、その受信デバイスとその送信デバイス間の設定手続を実行する手段と、その受信デバイスにより、その少なくとも１つのメディアストリームのその送信の開始を要求する手段と、その選択された少なくとも１つのメディアストリームのその送信の中に、１つのデータ伝送コンテキストを用いる手段と、その設定手続と関連してその送信デバイスにその予約リソースに関する情報を送信する手段と、を備える通信システムが提供される。
本発明の第７の形態によれば、少なくとも部分的に無線通信ネットワークを介して、少なくとも１つのパケットデータ伝送接続を用いて、受信デバイスへメディアストリームを送信する手段と、その受信デバイスへ送信されるべき少なくとも１つのメディアストリームの選択の情報を受信する手段と、その少なくとも１つのパケットデータ伝送接続を有効にするために、その受信デバイスとその送信デバイスの間の設定手続のための要求を受信する手段と、その少なくとも１つのメディアストリームの送信の開始のための要求を受信する手段と、その選択された少なくとも１つのメディアストリームのその送信の中に、１つのデータ伝送コンテクストを用いる手段と、その設定手続に関連して、その少なくとも１つのパケットデータ伝送接続のための予約リソースに関する情報を受信する手段と、を備える送信デバイスが提供される。
本発明の第８の形態によれば、少なくとも１つのパケットデータ伝送接続を用いて、少なくとも部分的に無線通信ネットワークを介して、送信デバイスからメディアストリームを受信する手段と、その受信デバイスに送信されるべき少なくとも１つのメディアストリームを選択する手段と、その選択された少なくとも１つのメディアストリームを送信するために、ＱｏＳ要件を規定する手段と、その少なくとも１つのメディアストリームのその送信のために、その無線ネットワークから送信リソースを要求する手段と、その少なくとも１つのパケットデータ伝送接続を有効にするために、その受信デバイスとその送信デバイスの間の設定手続を開始する手段と、その少なくとも１つのメディアストリームのその送信の開始を要求する手段と、その選択された少なくとも１つのメディアストリームのその送信の中に、１つのデータ伝送コンテキストを用いる手段と、その設定手続に関連して、その送信デバイスに、その予約リソースに関する情報を送信する手段と、を備える受信デバイスが提供される。
本発明の第９の形態によれば、少なくとも１つのパケットデータ伝送接続を用いて、少なくとも部分的に無線通信ネットワークを介して、受信デバイスにメディアストリームを送信する手段と、その受信デバイスに送信されるべき少なくとも１つのメディアストリームの選択の情報を受信する手段と、その少なくとも１つのパケットデータ伝送接続を有効にするために、その受信デバイスとその無線デバイス間の設定手続のためのリクエストを受信する手段と、その少なくとも１つのメディアストリームの送信の開始のための要求を受信する手段と、その少なくとも１つのメディアストリーム送信の開始の要求を受信する手段と、その選択された少なくとも１つのメディアストリームのその送信の中に、１つのデータ伝送コンテキストを用いる手段と、その設定手続に関連して、その少なくとも１つのパケットデータ伝送接続のための予約リソースに関する情報を受信する手段と、を備える無線通信デバイスが提供される。
本発明の第１０の形態によれば、少なくとも１つのパケットデータ伝送接続を用いて、少なくとも部分的に無線通信ネットワークを介して、送信デバイスからメディアストリームを受信する手段と、その無線通信デバイスに送信されるべき少なくとも１つのメディアストリームを選択する手段と、その選択された少なくとも１つのメディアストリームを送信するためのＱｏＳ要件を規定する手段と、その少なくとも１つのメディアストリームのその送信のために、その無線通信ネットワークから、送信リソースを要求する手段と、その少なくとも１つのパケットデータ伝送接続を有効にするために、その無線通信デバイスとその送信デバイス間の設定手続を開始する手段と、その少なくとも１つのメディアストリームのその送信の開始を要求する手段と、その選択された少なくとも１つのメディアストリームのその送信の中に、１つのデータ伝送コンテキストを用いる手段と、その設定手続に関連して、その送信デバイスに、その予約リソースに関する情報を送信する手段と、を備える無線通信デバイスが提供される。
本発明は、従来のシステムと方法と比較するとき利点がある。本発明は、ストリーミングサーバに、各ＰＤＰコンテキストのために許可されたＱｏＳパラメータを認識させることが出来る。これは、さらに正確なＱｏＳプロファイルパラメータを特定するすことで、より良い、正確な適合性を許す。
本発明は、ストリーミングセッション用のクライアントによってただ１つの／複数のＰＤＰコンテキスト使用のために生じる衝突と、そのサーバへシグナリングするＱｏＳパラメータを明確にする。
本発明で述べられる手続が使用されないなら、マルチメディアセッションは、ＱｏＳパラメータから利益を得ることは出来ないが、代わりにＱｏＳは、深刻に劣化する危険性がある。
本発明は、無線ストリーミングコンセプトを利用し、そして、３ＤＰＰと特有のプロトコルとコーデックを利用して、マルチメディアストリーミング性能及び無線領域への適合性を改善する。
もう１つの重要な利点は、最大ビット速度−保障ビット速度として計算される差分帯域を効率的に利用する可能性が与えられる。この帯域は、低域適合性又は映像ビット速度のピーク処理のために使用される。最後に、この差分帯域は、リアルタイムでマルチメディアストリームを符号化するとき、ビット速度に影響のある（メディアストリームビット速度を含む）パラメータ符号化を急ぎ変更することで、最大メディア品質を転送するために使用され得る。
本発明は、添付図面を参照してより詳細に理解される。
本発明の好ましい実施例における以下の記述においては、ＵＭＴＳタイプ移動体通信システムは、例として使用されるが、本発明はこのシステムに単に制限されず、通信用の様々なＱｏＳレベルを決定することが可能な他の通信システムにも適応可能であることが問う業者には明らかであるだろう。
以下では、セッション記述言語（ＳＤＰ）をより詳細に説明する。
インターネット・マルチキャスト・バックボーン（Ｍｂｏｎｅ）上では、セッションディレクトリツールが、マルチメディア・カンファレンス（multimedia conference）、参加に必要なメディア特定情報を通知するために使用される。マルチキャストバックボーンは、ＩＰ（インターネットプロトコル）マルチキャストをサポートするインターネット部分であり、従って、効率的な多対多の通信を許可する。それは、マルチメディア・カンファレンス開催のために広く使用される。そのようなカンファレンスは、通常は、カンファレンス構成員のしっかりとした協調が必要とされない特性がある。あるカンファレンスを受信するために、マルチキャストバックボーンサイトにおけるユーザは、ただ、そのカンファレンスのマルチキャスト・グループ・アドレス及びそのカンファレンスデータストリーム用のＵＤＰポートを知る必要がある。
セッションディレクトリは、カンファレンスセッションの通知を援助し、予想される参加者への関連するカンファレンスセットアップ情報を通信する。ＳＤＰは、このような情報を参加者へ配信するように設計される。ＳＤＰは、純粋にセッション記述用のフォーマットであり、それは、トランスポート・プロトコルと一体とならず、セッション告知プロトコル（Session Announcement Protocol）、セッション開始プロトコル（Session Initiation Protocol）、リアルタイム・ストリーミング・プロトコル（ＲＴＳＰ）、ＭＩＭＥ拡張、及び、ハイパーテキスト・トランスポート・プロトコルを含む、異なるプロトコルと共に配信され得る。
ＳＤＰは、ただのマルチキャスト・セッション・ディレクトリより、より広い範囲のネットワーク環境とアプリケーションのために使用されるために、一般的な目的向けを意図されている。
マルチメディア・カンファレンスは、それらが通信に使用するソフトウェアと共に、通信を行う通信デバイスのセットである。
以下では、セッション記述プロトコルの本発明の定義の幾つかの詳細を、述べる。そのプロトコルの幾つかの記述が得られ、それらのいくつかは、オプションである。オプションアイテムは、「＊」で印が付けられる。
セッション記述
v=(プロトコルバージョン)
o=(所有者/作成者及びセッション識別子)
s=(セッション名称)
i=*(セッション情報)
u=*(記述のＵＲＩ)
e=*(電子メールアドレス)
p=*(電話番号)
c=*(全メディアに含まれるかどうかを要求しない接続情報)
b=*(帯域情報)
０以上の時間識別子（下記参照）
z=*(時間０調整)
k=*(暗号鍵)
a=*(０又はそれ以上のセッション属性ライン)
０以上のメディア識別子（下記参照）
時間記述
t=(セッションが有効である時間)
r=*(０又は繰り返し回数)
メディア記述
M=(メディア名称及び送信アドレス)
i=*(メディアタイトル)
c=*(セッションレベルに含まれるなら、接続情報オプション)
b=*(帯域情報)
k=*(暗号鍵)
a=*(０又はそれ以上のメディア属性ライン)
上述で述べた図書によれば、帯域幅記述は、以下のように定義される。
b=<modifier>:<bandwidth-value>
これは、セッション又はメディアで使用されるべき提案される帯域幅を特定し、オプションである。
<bandwidth-value>は、デフォルトでは、キロビット／秒である。<modifier>は、帯域幅形態の意味を与える１つのアルファベット文字である。２つの修飾因子（modifier）は、最初に規定される。
ＣＴ（カンファレンス総計）：セッション又は１つのセッションの中のメディアの帯域幅が、その領域から暗黙的な帯域幅と異なるなら、'b=CT:...線が、使用される帯域幅への提案上限を与えるセッションのために提供される。この本来の目的は、２以上のセッションが同時に共に存在できるかどうかについて、おおよその考えを与えることである。
ＡＳ（アプリケーション特有最大値）：帯域幅は、アプリケーション特有になるように解釈される、即ち、最大帯域幅のアプリケーションの概念である。通常は、これは、適応可能なら、アプリケーションの「最大帯域幅」制御上に設定されるものと共に同時に生じる。ＲＴＰベースのアプリケーションにとっては、（メディアビット速度とＵＤＰ／ＩＰヘッダオーバヘッドを含む）ＲＦＣ１８８９（ＲＴＰ）セクション６．２で定義されるように、ＡＳは、ＲＴＳ「セッション帯域幅」を与える。
リアルタイムストリーミングプロトコルは、リアルタイム特性と共にデータの配信を制御するクライアント−サーバプロトコルである。映像や音声のような連続メディアの単一又は複数の時間同期ストリームのどちらかを確立し、制御する。ＲＴＳＰは、ＵＤＰ及びＴＣＰのようなトランスポート・プロトコルで配信される。言い換えれば、ＲＴＳＰは、マルチメディアサーバ用のネットワーク遠隔制御として行動する。データのソースは、生のデータフィード（例えば、リアルタイム映像及び／又は音声）及び保存場面（例えば静止画）の両方を含めることができる。ＲＴＳＰクライアント及びサーバは、メディア配信用の適切なパラメータセットを、例えば、部分的に、これらのパラメータを述べるための、ＳＤＰ構文を用いて、ネゴシエートする。
図１は、無線通信デバイスＭＴ１、基地局２（ＢＳ）を備えるラジオアクセスノード１（ＲＡＮ）、基地局２を制御し基地局２と残りのシステム間の通信経路を指定するラジオネットワークコントローラ３（ＲＮＣ）、無線移動体交換センタ４（ＷＭＳＣ）、及び、ラジオネットワークコントローラ３に加えた実現性を経路指定するパケットデータアクセスノード５を有するＵＭＴＳシステムの一部分を示す。図１によるＵＭＴＳシステムは、さらに、例えば、バックボーンネットワーク６及びインターネットプロトコル７のような、他のパケットネットワークへのパケットデータゲートウェイ８（ＰＤＧ）を備え、そこでは、無線通信デバイスは、例えば、ＩＰネットワークに接続されるサーバと通信できる。さらに、図１は、（移動体サービス交換センタへのゲートウェイ）回路交換ゲートウェイ９、及び、例えば加入者のアクセス契約データを保存するホーム位置レジスタ１１（ＨＬＲ）を表す。
さらに、図２は、限定したブロックチャートにおいて、Ｎｏｋｉａ９２１０ｉコミュニケータのようなデータ処理機能と移動局機能を備える通信デバイスである本発明の好ましい実施例に従う無線通信デバイスＭＴ１を示す。無線通信デバイスＭＴ１は、１以上のＣＰＵ、ＤＳＰ、メモリ手段ＭＥＭ、ＵＭＴＳ加入者識別子モジュール（ＵＳＩＭ）又は加入者を識別する対応手段、及び、基地局２と共に通信用のラジオパートＲＦを備える。メモリ手段は、好ましくは、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）及び加入者識別モジュールＵＳＩＭの少なくともメモリ部分を備える。無線通信デバイスＭＴ１は、さらに、好ましくは、キーパッド１３、１４、ディスプレイ１５、１６及び音声手段、例えば、マイクロフォン１７、スピーカ１８、コーデック１９を備える１以上のユーザインタフェースを備える。
図１において、電話管理（ＣＭ：Call Management）に関する機能は、無線通信デバイスＭＴ１、及び、無線移動体交換センタ４とパケットデータアクセスノード５の両方に実装される。これらの電話管理機能は、通話を開始、継続、終了する手段を構成する。従って、無線通信デバイスＭＴ１と無線移動体交換センタ４又はパケットデータアクセスノード５は、通話を開始、継続、終了するために通話シグナリングメッセージを交換する。ベアラ管理（ＢＭ）及びラジオリソース管理（ＲＭ）は、無線通信デバイスＭＴ１及び無線ネットワークコントローラ３の中で実装される。ベアラ管理機能は、例えば、ベアラサービスに従うサービスのＱｏＳを出力するために、無線通信デバイスＭＴ１と基地局２の間の通信のために選択されるベアラサービスの特性に従って、１以上の論理経路を選択するために利用される。無線リソース管理機能は、例えば、無線通信デバイスＭＴ１と基地局２の間の無線通信用の無線通信路を選択するために使用される。
無線通信デバイスＭＴ１とＩＰネットワーク７の間のパケットデータ伝送接続は、パケットデータバックボーン６及びパケットデータゲートウェイ８（ＰＤＧ）を介して、パケットデータアクセスノード５（ＰＤＡＮ）から設定される。無線通信デバイスＭＴ１と無線アクセスノード１を介した無線通信ネットワーク間の回路交換データ伝送接続、無線移動局交換センタ４、及び、移動局サービス交換センタ９（ＧＷＭＳＣ）へのゲートウェイを設定することも可能である。この移動局サービス交換センタへのゲートウェイは、移動局通信ネットワークと、ＧＳＭ、ＰＳＴＮ又はＩＳＤＮのような第２ネットワークＮＷ２をセットする手段を備える。
以下では、ストリーミングマルチメディア応用のための本発明の好ましい実施例による方法が、図１のシステム、及び、図３と４のシグナリング図に関連して説明される。次の実施例は、ＲＴＳＰプロトコルの仕様に基づく。さらに、「ＱｏＳＰａｒａｍ、ＭａｘＢＷ、ＧｕａＢＷ、ＴｄｅｌａｙＭａｘ及びｕｒｌ」パラメータは、上記説明の発明のための概念的な代替物である仮想的なパラメータ名称である。
第１に、幾つかの用語が定義される。クライアントは、無線通信デバイスＭＴ１であり、サーバは、そのクライアントへのストリーミングマルチメディアプロバイダ（例えば、図１におけるサーバ１０）である。マルチメディアセッションは、マルチメディア関連データが、クライアントとサーバ間に交換される間の時間の間隔である。マルチメディアセッション設定段階は、クライアントとサーバがマルチメディアセッション関連設定情報、例えば、セッション間に使用されるマルチメディアコンポネント、帯域幅情報、マルチメディアコーデック関連情報等を交換する間の時間間隔である。ＰＤＰコンテキストは、ＱｏＳリソース予約処理と、ストリーミングクライアントを起動する移動局間の抽象的な結合の論理的表示である。
クライアントは、ＱｏＳ（サービス・オブ・クオリティ）可能ネットワークＮＷ１内にあり、ＮＷ１は、そのリソースに基づいてクライアントに幾つかの保障値を出力する。これらの保障値は、次の１以上をカバーする。
− 最大ビット速度（MaxBW）：ネゴシエートされたメディアコンポネント又は合計マルチメディアセッションのためのクライアントに対して保障する最大帯域幅。
− 転送遅延（TDelayMax）：各データ単位がサーバからクライアント及びその逆の伝送間に経験する遅延（msec）。
− 他のパラメータも定義されるが、ここでは詳細に説明しない。
本発明は、クライアントがその能力に基づいて、ただ１つ又は複数のコンテキストをマルチメディアセッション間に有するために、経験できる２つの異なる実現性をカバーする。
第１に、クライアントがある時間にただ１つのＰＤＰコンテキストを処理できるだけの状況を、より詳細に説明する。言い換えると、ただ１つのＰＤＰコンテキストをサポートするクライアントは、マルチメディアセッション中に全てのメディアコンポネント（即ち、映像、音声等）に及ぶ単一時間にただ１つのＱｏＳリソース予約を有することができる。これは、マルチメディアデータが、映像や音声等にかかわらず、同じＱｏＳリソースを有する同じ伝送通信路を共有することを意味する。
第１のシナリオでは、収集制御セッションは、ストリーミングセッション用のただ１つのＰＤＰコンテキストサポートのみを有する無線通信デバイスＭＴ１（クライアント）のために始動する。このシナリオでは、無線通信デバイスＭＴ１が、（例えば、映像及び伴うビデオストリーム）セッション用に設定するための複数のメディアコンポネントを有するならば、そのとき、クライアントは、背景技術の欄で述べた問題のために、最大ビット速度MaxBW、保障ビット速度GuaBW、最大転送遅延TdelayMax及び設定段階間にサーバ１０への他のＱｏＳプロファイルパラメータのような、ネゴシエートされたＱｏＳパラメータを送信する必要は無い。
ＱｏＳネゴシエートパラメータは、ストリーム伝送始動時又は後で、即ち、Ｐｌａｙコマンドが無線通信デバイスＭＴ１からサーバ１０へ伝送されるとき、又は、後で、送られなければならない。
そのコマンド列は、以下のようになる（図３）。
無線通信デバイスＭＴ１は、サーバ１０に、Describe Sessionコマンドを伝送する３０１。
DESCRIBE rtsp:/lserver.com/session1.3gpRTSP/1.0
CSeq:1
Accept:application/sdp
サーバ１０は、異なるメディアストリームに関する情報を含むＳＤＰ記述を送信することでこのコマンドに応答する。
RTSP/1.0 200 O
CSeq:1
Content-Base:rtsp://server.com/session1.3gp/
Content-Type:application/sdp
Content-Length:441
v=O
o=-3242987154 3242987154 IN IP4111.111.111
s=session1.3gp
c=iN IP4 0.0.0.0
t=0 0
a=control:*
a=range:npt=0-60
m=video 0 RTP/AVP 96
b=AS:50
a=rtpmap:96H263-2000/90000
a=control:tracklD=2
a=range:npt=0-60
a=fmtp:96profile=0;level=10
m=video 0 RTP/AVP 98
b=AS: 40
a=rtpmap: 98 H263-2000/90000
a=control :tracklD=3
a=range: npt=0-60
a=fmtp: 98 profile=0;level=10
m=audio 0 RTP/AVP 97
b=AS:10
a=rtpmap: 97 AMR/8000/1
control :tracklD=1
a=range: npt=0-60 a=fmtp: 97 octet-align=1
m=audio 0 RTP/AVP 99
b=AS:20
a=rtpmap:99AMR-WB/16000
a=control:tracklD=4
a=range:npt=0-60
a=fmtp:99 octet-align=1
上記のＳＤＰ記述においては、video1は、50kbpsというb=AS定義を有し、video2は、20kbpsというb=AS定義を有し、audio1は、10kbpsというb=AS定義を有し、audio2は、20kbpsというb=AS定義を有する。
それから、無線通信デバイスＭＴ１では、例えばユーザによって、セッションが、無線通信デバイスＭＴ１に送信されるストリームを選択するために、通知されるメディア内に、確立される。この例では、video1（50kbps）とaudio2（20kbps）が合計ビット速度70kbpsを有するために選択される。その後に、無線通信デバイスは、通信ネットワークＮＷ１へのベアラサービス用の要求（Request）を送る３０３。その要求の中で、無線通信デバイスＭＴ１は、全てのメディアコンポネント用の必要なＱｏＳパラメータ（70kbpsの最大ビット速度）を含める。
この例では、ネットワークは、60kbpsだけ保障でき、80kbpsの最大ビット速度を可能にする。それから、ネットワークＮＴ１は、ベアラサービス用許可ＱｏＳパラメータを、無線通信デバイスＭＴ１を送信する。ＰＤＰセッション用ベアラサービスのためのネットワークとのネゴシエーションの後で、無線通信デバイスＭＴ１は、選択第１メディアストリーム、即ち、video1を通知するために、サーバ１０に第１設定（Setup）メッセージを転送する。
SETUP rtsp:l/server.comisession1.3gp/tracklD=2 RTSP/1.0
CSeq:2
Transport:RTP/AVP/UDP;unicast;client_port=6984-6985;ssrc=31336d02
サーバ１０は、その選定がＯＫの場合、ＯＫメッセージで返答する３０６。
RTSP/1.0 200 OK
CSeq:2
Session:41
Transport:RTP/AVP/UDP;unicast;client port=6984-
6985;server_port=6900-6901;ssrc=1d12115
無線通信デバイスＭＴ１は、さらに、選択第２メディアストリーム、即ち、audio2を通知するために、サーバ１０に第２設定（Setup）メッセージを送信する３０７。
SETUP rtsp://server.comlsession1.3gp/tracklD=4 RTSP/1.0
CSeq:3
Transport:RTP/AVP/UDP;unicast;client port=6986-6987;ssrc=37115e8d
Session:41
サーバ１０は、その選定がＯＫの場合、ＯＫメッセージで返答する３０８。
RTSP/1.0 200 OK
CSeq:3
Session:41
Transport:RTP/AVP/UDP;unicast;client_port=6986-
6987;server_port=6902-6903 ;ssrc=7475313
メディアストリームの再生は、無線通信デバイスＭＴ１から、サーバ１０へ再生（Play）コマンドを送信することで開始される３０９。この場合、再生コマンドは、最大ビット速度とネットワークＮＴ１が許可する保障ビット速度に関する少なくともＱｏＳパラメータに関する情報と共に含められる。
PLAY rtsp://server.com/session1.3gpRTSP/1.0
CSeq:4
Session:41
QoSParams:MaxBW=80;GuaBW=60;TDelayMax=500
Range:npt=0-
サーバは、無線通信デバイスＭＴ１にＯＫを送ることによるコマンドに返答する。
RTSP/1.0 200 OK
CSeq:4
Session:41
Range:npt=0-
RTP-Info:
url=rtsp://server.com/session1.3gp/tracklD=2;seq=0;rtptime=10000,url=rtsp://server.com/sessionl.3gp/tracklD=4;seq=0;rtptime=10000
サーバ１０が再生コマンドを受信したとき、サーバ１０は、すぐに、無線通信デバイスＭＴ１により信号で送られるＱｏＳパラメータを有するただ１つのＱｏＳ通信路が存在することを知り、そのパラメータに従って選択メディアストリームの伝送を適応させる。再生コマンドの後、無線通信デバイスＭＴ１は、ストリーミングセッションのコンテキスト内に定義された他のＲＴＳＰコマンドを用いて、全体マルチメディアセッション用ネゴシエートＱｏＳパラメータを更新する。
マルチメディアセッションが、非収集制御セッション（例えば、音声と映像データが２つの分かれたサーバから回収される）であるなら、分かれたメディアサーバが互いに気付かない、また、分かれたメディアサーバが、メディアコンポネントが同じＱｏＳ保存通信路を共有するという事実に気付かないので、無線通信デバイスＭＴ１は、ＱｏＳパラメータを送信しない。
第２に、クライアントが同時に複数のＰＤＰコンテキストをサポートできる場合をより詳細に述べる。他の言葉で言い換えると、複数のＰＤＰコンテキストをサポートするクライアントは、単一時間に、複数のＱｏＳリソース予約を有し、そのＱｏＳリソース予約は、マルチメディアセッション中に、各メディアコンポネント（即ち、音声、映像等）に分配される。全てのメディアコンポネントは、異なるＱｏＳリソース予約を持つことが出来る。
第２シナリオにおいては、無線通信デバイスＭＴ１は、セッションを設定（set up）するために、複数のメディアコンポネントを有する場合、及び、無線通信デバイスＭＴ１が、異なるメディアコンポネントのために複数のＰＤＰコンテキストを始動しようとする場合、さらに、そのセッション制御プロトコルがメディアコンポネントｕｒｌ表示に、メディアコンポネント間を区別することを許可する場合、無線通信デバイスＭＴ１は、ＱｏＳネゴシエートされたMaxBW、GuaBW、TDelayMax及び他のＱｏＳプロファイルパラメータを、これらのパラメータの殆どが付加である再生コマンドでサーバに送信する必要は無い。
ＱｏＳパラメータは、各メディアコンポネントのセットアップ段階中に、代わりに、送られるべきである。
コマンド列は、次のようになる（図４）。
無線通信デバイスＭＴ１は、サーバ１０にDescribe Sessionコマンドを送信する４０１。
DESCRIBE rtsp://server.com/session1.3gpRTSP/1.0
CSeq:1
Accept:application/sdp
サーバ１０は、異なるメディアストリームに関する情報を含むＳＤＰ記述を送信することでこのコマンドに応答する４０２。
RTSP/1.0 200 OK
CSeq:1
Content-Base: rtsp://server.com/session1.3gp/
Content-Type:application/sdp
Content-Length:441
v=O
o=-3242987154 3242987154 IN IP4 111.111.111
s= session1.3gpc=IN IP4 0.0.0.0
t=0 0
a=control:*
a=range:npt=0-60
m=video 0 RTP/AVP 96 b=AS: 50
a=rtpmap: 96H263-2000/90000
a=control:tracklD=2
a=range:npt=0-60
a=fmtp:96 profile=0;level=10
m=video 0 RTP/AVP 98
b=AS:40
a=rtpmap:98H263-2000/90000
a=control:tracklD=3
a=range:npt=0-60
a=fmtp:98 profile=0;level=10
m=audio 0 RTP/AVP 97
b=AS:10a=rtpmap: 97AMR/8000/1
a=control:trackID=1
a=range:npt=0-60
a=fmtp:97 octet-align=1
m=audio 0 RTP/AVP 99
b=AS:20
a=rtpmap:99 AMR-WB/16000
a=control:trackID=4
a=range:npt=0-60
fmtp:99 octet-align=1
上述のＳＤＰセッションでは、video1は、50kbpsのb=AS定義を有し、video2は、20kbpsのb=AS定義を有し、audio1は、10kbpsのb=AS定義を有し、audio2は、20kbpsのb=AS定義を有する。
それから、無線通信デバイスＭＴ１において、セッションは、例えばユーザによって、無線通信デバイスＭＴ１に送信されるストリームを選択するために、通知されるメディアの中で確立される。この例においては、50kbpsのビット速度を有するvideo1と20kbpsのビット速度を有するaudio2が選択されると推定する。その後、無線通信デバイスは、通信ネットワークＮＷ１に、第１ベアラサービス用の第１要求（request）を送る４０３。その要求（request）の中で、無線通信デバイスＭＴ１は、第１メディアコンポネント（video1）のための必要なQoSパラメータ（50kbpsの保障ビット速度）を含める。この例では、ネットワークは、50kbpsのみ保障でき、80kbpsの最大ビット速度を可能にする。それから、ネットワークＮＴ１は、無線通信デバイスＭＴ１に、第１ベアラサービス用許可ＱｏＳパラメータを通知する。次に、無線通信デバイスは、通信ネットワークＮＷ１に、第２ベアラサービスのための要求を送る。その要求において、無線通信デバイスＭＴ１は、要求ＱｏＳパラメータ（20kbpsの保障ビット速度）を、第２メディアコンポネントのために含める。この例では、ネットワークは、20kbpsだけ保障し、40kbpsの最大ビット速度を可能にする。それから、ネットワークＮＴ１は、無線通信デバイスＭＴ１に、第２ベアラサービス用の許可ＱｏＳパラメータを通知する。ＰＤＰセッション用ベアラサービスのためのネットワークとネゴシエートした後に、無線通信デバイスＭＴ１は、選択された第１メディアストリーム、即ち、video1を通知するために、サーバ１０へ第１セットアップメッセージを送信する。
SETUP rtsp:llserver.com/session1.3gp/tracklD=2 RTSP/1.0
CSeq:2
Transport:RTP/AVP/UDP;unicast;client port=6984-6985;ssrc=31336dO2
QoSParams:url=
rtsp://server.com/session1.3gp/tracklD=2;MaxBW=80;GuaBW=50;TDelay
Max=500
サーバ１０は、その選択がＯＫならば、ＯＫメッセージで返答する４０８。
RTSP/1.0 200 OK
CSeq:2
Session:41
Transport:RTP/AVP/UDP;unicast;client_port=6984-
6985;server_port=6900-6901;ssrc=1d12115
無線通信デバイスＭＴ１は、さらに、選択された第２メディアストリーム、即ち、audio2を通知するためにサーバ１０に第２セットアップメッセージを送信する４０９。
SETUP rtsp://server.com/session1.3gp/tracklD=4 RTSP/1.0
CSeq:3
Transport:RTP/AVP/UDP;unicast;client_port=6986-6987;ssrc=37115e8d
Session:41
QoSParams:MaxBW=40;GuaBW=20;TDelayMax=500
サーバ１０は、その選択がＯＫなら、ＯＫメッセージで返答する４１０。
RTSP/1.0 200 OK
CSeq:3
Session:41
Transport:RTP/AVP/UDP;unicast;client_port=6986-
6987;server_port=6902-6903;ssrc=7475313
メディアストリームの再生は、無線通信デバイスＭＴ１から、サーバ１０へPlayコマンドを送信することによって開始される４１１。
PLAY rtsp://server.com/session1.3gpRTSP/1.0
CSeq:4
Session:41
Range:npt=0-
このケースでは、Playコマンドは、最大ビット速度とネットワークＮＴ１が許可した保障ビット速度に関連するQoSパラメータに関する情報を含めない。
サーバは、無線通信デバイスＭＴ１にＯＫを送ることによってコマンドに応答する４１２。
RTSP/1.0 200 OK
CSeq:4
Session:41
Range:npt=O-
RTP-Info:
url=rtsp://server.com/session1.3gp/tracklD=2;seq=O;rtptime=10000,
url=rtsp://server.com/session1.3gp/tracklD=4;seq=O;rtptime=10000
代わりに、RTSP 再生（PLAY）要求では、無線通信デバイスＭＴ１は、以下のようになされる。
PLAY rtsp://server.com/session1.3gp RTSP/1.0
CSeq:4
Session:41
Range:npt=0-
QoSParams:url=rtsp://server.com/session1.3gp/tracklD=2;MaxBW=80;
GuaBW=50;TDelay
Max=500,url=rtsp:llserver.comisession1.3gpitracklD=4;MaxBW=40;GuaBW=20;TDelay
Max=500
すぐに、サーバは、どのＱｏＳパラメータが、メディアコンポネントＵＲＬに基づいてそのメディアコンポネントに割り当てられるかを識別できる。
Server -> Client:OK RTSP/1.0 200 OK
CSeq:4
Session:41
Range:npt=0-RTP-lnfo:url=rtsp:llserver.comisession1.3gpitracklD=2;seq=0;rtptime=10000,
url=rtsp:l/server.com/session1. 3gpitracklD=4 ;seq=0;rtptime=10000
すぐに、サーバ１０がPlayコマンドを受信したとき、無線通信デバイスＭＴ１により信号で伝えられる個々のＱｏＳパラメータと共に複数のＱｏＳパラメータが存在することを知る。各メディアコンポネントは、各ＰＤＰコンテキストのために有効なＱｏＳネゴシエートパラメータのその所有セットを有するので、サーバは、安全に、各メディアコンポネントを、正しい割り当て値と共に、正しいＱｏＳネゴシエート通信路に関係付けることが出来る。
ＱｏＳ再ネゴシエーションが、特定のＰＤＰコンテキスト（即ち、特定のメディアコンポネント）に生じ、クライアントは、その変更が生じるメディアコンポネントを正しく参照することによって、利用可能なＲＴＳＰコマンドを用いて、新しいＱｏＳ値を信号で伝える。
そのセッション制御プロトコルが、メディアコンポネントｕｒｌ表示に、メディアコンポネント間を区別することを許すなら、ＱｏＳパラメータは、再生要求でも、信号で伝えられる。以下の擬似コマンド列は、可能性のあるシナリオを示す。
Client- > Server:Setup (media component 1)
Server- > Client:OK
Client -> Server:Setup(media component 2)
Server- > Client:OK
Client- > Server: Play (URL of media component 1 + Negotiated QoS parameters for the media component 1; URL of media component 2 + Negotiated QoS parameters for the media component 2)
Server- > Client : OK
上述の例では、サーバ（server）は、メディアコンポネントと「メディアコンポネントＵＲＬ」情報の使用によって各コンポネントに割り当てられたQoSパラメータを区別することが出来る。このフィールドは、あるセッションの中でメディアコンポネントの独自の識別子を有する。クライアント（client）とサーバがそのようなパラメータを利用することができるならば、無線通信デバイスＭＴ１は、設定段階、又は再生段階のどちらかのＱｏＳパラメータを送ることを選択する。ＱｏＳ再ネゴシエーションが生じると、このメディアコンポネントＵＲＬ識別子は、さらに、セッション間にＱｏＳパラメータを更新するために、無線通信デバイスＭＴ１に実現性を与える。
マルチメディアセッションは、非収集制御セッション（例えば、音声と映像データが分かれた２つのサーバから回収される）であるなら、クライアントは、再生（Play）コマンドはもちろん、設定（Setup）コマンドでもＱｏＳネゴシエートパラメータを安全にシグナリングすることができる。なぜなら、各メディアコンポネント用の２つの分かれた再生コマンドがあるからである。
メディアコンポネントＵＲＬフィールドは、第１例でのセッションＵＲＬを識別するためにも存在するが、設定段階では、ＱｏＳパラメータを送らないことに関する制限は、そのケースでも有効である。
ＱｏＳパラメータが、メディアコンポネントＵＲＬに含まれないなら、ストリーミング制御プロトコルの要求ＵＲＬは、ＱｏＳパラメータ割り当て用主要ＵＲＬとして使用される。
本発明は、上述の実施例に単に制限されず、添付の請求の範囲内で修正されることは明らかである。
本発明の好ましい実施例により達成されるシステムを表す図である。 簡易ブロックチャートにおける本発明の好ましい実施例による無線通信デバイスを表す図である。 単一のＰＤＰコンテキストを有するクライアント用のＱｏＳ予約及びセッション制御を表すシグナリングダイアグラムである。 複数のＰＤＰコンテキストを有するクライアント用のＱｏＳ予約及びセッション制御を表すシグナリングダイアグラムである。

Claims (13)

  1. 受信デバイスに送信される少なくとも１つのメディアストリームを選択するステップ、
    前記選択された少なくとも１つのメディアストリームを送信するためのＱｏＳ要件を規定するステップ、
    前記少なくとも１つのメディアストリームの前記送信のために、無線通信ネットワークから送信リソースを予約するステップ、
    １つのパケットデータ伝送接続を有効にするために、前記受信デバイスと送信デバイスとの間の設定手続を実行するステップ、
    前記受信デバイスにより、前記少なくとも１つのメディアストリームの送信開始を要求するステップ、
    前記送信デバイスから、前記受信デバイスへ、少なくとも部分的に無線通信ネットワークを介して、メディアストリームを送信するステップ、を有し、前記送信ステップは、前記選択された少なくとも１つのメディアストリームの送信内の１つのデータ伝送コンテキストを用いるステップ、を有する通信システムでの方法において、
    前記受信デバイスにより前記少なくとも１つのメディアストリームの前記送信の開始の前記要求時、又は、その後で、前記予約リソースに関する情報を、前記送信デバイスに送信するステップ、をさらに有する方法。
  2. 前記データ伝送接続のために、少なくとも次のパラメータを定義し、
    最大ビット速度、
    保障ビット速度、
    転送遅延、
    前記送信デバイスに前記パラメータを通知することを有する請求項１に記載の方法。
  3. 受信デバイスに送信されるべき少なくとも１つのメディアストリームを選択するステップ、
    前記選択された少なくとも１つのメディアストリームを送信するためのＱｏＳ要件を定義するステップ、
    前記少なくとも１つのメディアストリームの前記送信用の無線通信ネットワークから送信リソースを予約するステップ、
    少なくとも１つのパケットデータ伝送接続を有効にするために、前記受信デバイスと前記送信デバイスとの間の設定手続を実行するステップ、
    前記受信デバイスによって前記少なくとも１つのメディアストリームの送信開始を要求するステップ、
    前記送信デバイスから、前記受信デバイスへ、少なくとも部分的に前記無線通信ネットワークを介して、メディアストリームを送信するステップであって、前記送信するステップは、各選択メディアストリームのための１つのデータ伝送コンテキストを用いる送信ステップ、を有する通信システムでの方法において、
    前記設定手続に関連して、前記送信デバイスへ、前記予約リソースに関する情報を送信するステップをさらに有する方法。
  4. 送信デバイスから受信デバイスへ少なくとも１つのメディアストリームを送信するためのＱｏＳ要件に関する情報を、該受信デバイスにより要求するステップ、
    前記少なくとも１つのメディアストリームの前記送信のために、無線通信ネットワークから送信リソースを、前記受信デバイスにより要求するステップ、
    前記送信のためのリソースを、前記無線通信ネットワークにより予約するステップ、
    前記予約リソースに関する情報を、前記受信デバイスへ、前記無線通信ネットワークにより、送信するステップ、
    前記１つのパケットデータ伝送接続を有効にするために、前記受信デバイスと前記送信デバイスにより、設定手続を実行するステップ、
    前記送信デバイスへ送信コマンドの開始を送信することによる前記少なくとも１つのメディアストリームの前記送信の開始を、前記受信デバイスにより要求するステップであって、そこでは、前記予約リソースに関する情報もあるコマンドが、前記送信デバイスに送信する要求ステップ、
    送信デバイスから受信デバイスへ、少なくとも部分的に無線通信ネットワークを介して、１つのパケットデータ伝送接続を用いて、メディアストリームを送信するステップ、を有する通信システムでの方法。
  5. 送信デバイスから受信デバイスへ少なくとも１つのメディアストリームを送信するために、ＱｏＳ要件に関する情報を、該受信デバイスによって要求するステップ、
    前記少なくとも１つのメディアストリームの前記送信のために、無線通信ネットワークから送信リソースを、前記受信デバイスにより要求するステップ、
    前記送信のためのリソースを、前記無線通信ネットワークにより予約するステップ、
    前記少なくとも１つのパケットデータ伝送接続を有効にするために、前記受信デバイスと前記送信デバイスにより、前記送信デバイスへの前記予約リソースに関する情報を前記受信デバイスによって送信する設定手続を実行するステップ、
    前記送信デバイスに、送信コマンドの開始を送信することによって、前記少なくとも１つのメディアストリームの前記送信の開始を要求するステップであって、そこで、前記予約リソースに関する情報無しコマンドは、前記通信デバイスに送信される要求ステップ、を有する通信システムでの方法において、
    前記送信デバイスから前記受信デバイスへ、少なくとも部分的に前記無線通信ネットワークを介して、少なくとも１つのパケットデータ伝送接続を用いて、メディアストリームを送信するステップ、をさらに有する方法。
  6. 送信デバイスから受信デバイスへ少なくとも部分的に無線通信ネットワークを介してメディアストリームを送信する手段と、
    前記受信デバイスに送信されるべき少なくとも１つのメディアストリームを選択する手段と、
    前記選択された少なくとも１つのメディアストリームを送信するために、ＱｏＳ要件を規定する手段と、
    前記少なくとも１つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースを予約する手段と、
    １つのパケットデータ伝送接続を有効にするために、前記受信デバイスと前記送信デバイスとの間の設定手続を実行する手段と、
    前記少なくとも１つのメディアストリームの前記送信の開始を、前記受信デバイスにより要求する手段と、
    前記選択された少なくとも１つのメディアストリームの前記送信の中に１つのデータ伝送コンテキストを用いる手段と、
    前記送信デバイスへ前記予約リソースに関する情報を、前記少なくとも１つのメディアストリームの前記送信の開始が、前記受信デバイスにより要求されるとき、又は、その後で送信する手段と、を備える通信システム。
  7. 送信デバイスから受信デバイスへ、少なくとも部分的に無線通信ネットワークを介して、少なくとも１つのパケットデータ伝送接続を用いてメディアストリームを送信する手段と、
    前記受信デバイスに送信されるべき少なくとも１つのメディアストリームを選択する手段と、
    前記選択された少なくとも１つのメディアストリームを送信するために、ＱｏＳ要件を定義する手段と、
    前記少なくとも１つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースを予約する手段と、
    前記少なくとも１つのパケットデータ伝送接続を有効にするために、前記受信デバイスと前記送信デバイスとの間の設定手続を実行する手段と、
    前記受信デバイスにより、前記少なくとも１つのメディアストリームの前記送信の開始を要求する手段と、
    前記選択された少なくとも１つのメディアストリームの前記送信の中に、１つのデータ伝送コンテキストを用いる手段と、
    前記設定手続と関連して前記送信デバイスに前記予約リソースに関する情報を送信する手段と、を備える通信システム。
  8. 少なくとも部分的に無線通信ネットワークを介して、少なくとも１つのパケットデータ伝送接続を用いて、受信デバイスへメディアストリームを送信する手段と、
    前記受信デバイスへ送信されるべき少なくとも１つのメディアストリームの選択の情報を受信する手段と、
    前記少なくとも１つのパケットデータ伝送接続を有効にするために、前記受信デバイスと前記送信デバイスとの間の設定手続のための要求を受信する手段と、
    前記少なくとも１つのメディアストリームの送信の開始のための要求を受信する手段と、
    前記選択された少なくとも１つのメディアストリームの前記送信の中に、１つのデータ伝送コンテクストを用いる手段と、
    前記設定手続に関連して、前記少なくとも１つのパケットデータ伝送接続のための予約リソースに関する情報を受信する手段と、を備える送信デバイス。
  9. 少なくとも１つのパケットデータ伝送接続を用いて、少なくとも部分的に無線通信ネットワークを介して、送信デバイスからメディアストリームを受信する手段と、
    前記受信デバイスに送信されるべき少なくとも１つのメディアストリームを選択する手段と、
    前記選択された少なくとも１つのメディアストリームを送信するために、ＱｏＳ要件を規定する手段と、
    前記少なくとも１つのメディアストリームの前記送信のために、前記無線ネットワークから送信リソースを要求する手段と、
    前記少なくとも１つのパケットデータ伝送接続を有効にするために、前記受信デバイスと前記送信デバイスとの間の設定手続を開始する手段と、
    前記少なくとも１つのメディアストリームの前記送信の開始を要求する手段と、
    前記選択された少なくとも１つのメディアストリームの前記送信の中に、１つのデータ伝送コンテキストを用いる手段と、
    前記設定手続に関連して、前記送信デバイスに、前記予約リソースに関する情報を送信する手段と、を備える受信デバイス。
  10. 少なくとも１つのパケットデータ伝送接続を用いて、少なくとも部分的に無線通信ネットワークを介して、受信デバイスにメディアストリームを送信する手段と、
    前記受信デバイスに送信されるべき少なくとも１つのメディアストリームの選択の情報を受信する手段と、
    前記少なくとも１つのパケットデータ伝送接続を有効にするために、前記受信デバイスと前記無線デバイスとの間の設定手続のためのリクエストを受信する手段と、
    前記少なくとも１つのメディアストリームの送信の開始のための要求を受信する手段と、
    前記少なくとも１つのメディアストリーム送信の開始の要求を受信する手段と、
    前記選択された少なくとも１つのメディアストリームの前記送信の中に、１つのデータ伝送コンテキストを用いる手段と、
    前記設定手続に関連して、前記少なくとも１つのパケットデータ伝送接続のための予約リソースに関する情報を受信する手段と、を備える無線通信デバイス。
  11. 少なくとも１つのパケットデータ伝送接続を用いて、少なくとも部分的に無線通信ネットワークを介して、送信デバイスからメディアストリームを受信する手段と、
    前記無線通信デバイスに送信されるべき少なくとも１つのメディアストリームを選択する手段と、
    前記選択された少なくとも１つのメディアストリームを送信するためのＱｏＳ要件を規定する手段と、
    前記少なくとも１つのメディアストリームの前記送信のために、前記無線通信ネットワークから、送信リソースを要求する手段と、
    前記少なくとも１つのパケットデータ伝送接続を有効にするために、前記無線通信デバイスと前記送信デバイスとの間の設定手続を開始する手段と、
    前記少なくとも１つのメディアストリームの前記送信の開始を要求する手段と、
    前記選択された少なくとも１つのメディアストリームの前記送信の中に、１つのデータ伝送コンテキストを用いる手段と、
    前記設定手続に関連して、前記送信デバイスに、前記予約リソースに関する情報を送信する手段と、を備える無線通信デバイス。
  12. 前記設定手続を開始する手段は、リアルタイム・ストリーミング・プロトコルにより、設定コマンドを送信するようになっている請求項１１に記載の無線通信デバイス。
  13. 前記少なくとも１つのメディアストリームの前記送信の開始を要求する手段は、リアルタイム・ストリーミング・プロトコルにより、再生コマンドを送信するようになっている請求項１１に記載の無線通信デバイス。
JP2006516253A 2003-06-27 2004-06-24 無線通信ネットワークシステム、通信システム及び通信デバイスにおけるリソース予約のための方法とシステム Withdrawn JP2007520905A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US48315703P 2003-06-27 2003-06-27
PCT/FI2004/050107 WO2005002264A1 (en) 2003-06-27 2004-06-24 Method and system for resource reservation in a wireless communication network

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2010099049A Division JP2010200359A (ja) 2003-06-27 2010-04-22 無線通信ネットワークシステム、通信システム及び通信デバイスにおけるリソース予約のための方法とシステム

Publications (1)

Publication Number Publication Date
JP2007520905A true JP2007520905A (ja) 2007-07-26

Family

ID=33552035

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2006516253A Withdrawn JP2007520905A (ja) 2003-06-27 2004-06-24 無線通信ネットワークシステム、通信システム及び通信デバイスにおけるリソース予約のための方法とシステム
JP2010099049A Pending JP2010200359A (ja) 2003-06-27 2010-04-22 無線通信ネットワークシステム、通信システム及び通信デバイスにおけるリソース予約のための方法とシステム

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2010099049A Pending JP2010200359A (ja) 2003-06-27 2010-04-22 無線通信ネットワークシステム、通信システム及び通信デバイスにおけるリソース予約のための方法とシステム

Country Status (7)

Country Link
EP (1) EP1639852A1 (ja)
JP (2) JP2007520905A (ja)
KR (1) KR100752608B1 (ja)
CN (1) CN1843050B (ja)
BR (1) BRPI0412014A (ja)
RU (1) RU2337505C2 (ja)
WO (1) WO2005002264A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014527748A (ja) * 2011-08-09 2014-10-16 アルカテル−ルーセント ビデオコンテンツをストリーミングするための方法、そのような方法を実現するエッジノードおよびクライアントエンティティ
JP2016140101A (ja) * 2011-10-21 2016-08-04 フラウンホーファー−ゲゼルシャフト・ツール・フェルデルング・デル・アンゲヴァンテン・フォルシュング・アインゲトラーゲネル・フェライン 情報資源管理概念

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060251093A1 (en) * 2005-05-03 2006-11-09 Nokia Corporation Signaling quality of service (QoS) parameters for a multimedia session
CN101009697B (zh) * 2006-01-26 2011-06-15 华为技术有限公司 业务层提高资源请求成功率和效率的系统及其方法
CN1870651B (zh) * 2006-03-01 2010-10-06 华为技术有限公司 处理资源请求的设备和方法
EP2005693B1 (en) * 2006-03-02 2015-09-02 Telefonaktiebolaget LM Ericsson (publ) Wideband codec negotiation
CN100461766C (zh) * 2006-08-02 2009-02-11 华为技术有限公司 一种为实时流媒体业务分配资源的方法及装置
ATE415763T1 (de) * 2006-08-24 2008-12-15 Research In Motion Ltd System zur feststellung des erreichens der maximalen anzahl hergestellter ip-verbindungen und ein dazugehöriges verfahren
JP4629075B2 (ja) * 2006-08-24 2011-02-09 リサーチ イン モーション リミテッド Ｉｐセッションの最大数が確立されていることを決定するシステムおよび方法
DE602007013097D1 (de) 2006-09-28 2011-04-21 Qualcomm Inc Bündelung von kommunikationssignalen für effizienz
US9253092B2 (en) 2006-09-28 2016-02-02 Qualcomm Incorporated Predictive QoS resource allocation for rapid session establishment
CN101175293B (zh) * 2006-10-30 2010-09-08 华为技术有限公司 采用push模式的呼叫方法
CN101572715B (zh) * 2009-04-15 2014-03-19 中兴通讯股份有限公司 多媒体服务创建方法及系统
CN101583018B (zh) * 2009-06-03 2011-05-11 中兴通讯股份有限公司 流媒体的频道业务和点播业务统一管理的方法及系统
US8873381B2 (en) * 2009-06-22 2014-10-28 Qualcomm Incorporated Bearer quality of service selection
CN101808371B (zh) * 2010-03-30 2012-07-11 重庆邮电大学 支持多跳资源预留的IEEE802.16Mesh网络资源预留方法
TWI583160B (zh) * 2011-02-11 2017-05-11 內數位專利控股公司 在協同對話期間行動站媒體流同步方法及裝置
WO2012175227A1 (en) * 2011-06-23 2012-12-27 Telefonaktiebolaget L M Ericsson (Publ) Methods and apparatus for identifying rtp media streams containing related media data
DE102011088884A1 (de) * 2011-12-16 2013-06-20 Siemens Aktiengesellschaft Verfahren zur Übertragung von Daten in einem Kommunikationsnetz
CN103188730B (zh) * 2011-12-31 2015-10-07 中国移动通信集团山东有限公司 系统资源负荷调节系统、方法及装置、调节服务器设备
CN105659615B (zh) * 2013-10-28 2019-11-05 索尼公司 内容供给装置、内容供给方法、终端装置及内容供给系统
US20150358374A1 (en) * 2014-06-04 2015-12-10 Acer Incorporated Method of Data Transmission in Multicast or Broadcast Service
CN105207982B (zh) * 2014-06-30 2019-10-11 中兴通讯股份有限公司 资源共享处理方法、装置及p-cscf
US9749902B2 (en) * 2014-08-19 2017-08-29 Qualcomm Incorporated Admission control and load balancing
CN107211188B (zh) * 2015-01-28 2021-01-05 索尼公司 信息处理方法、信息处理设备和程序
EP4181485B1 (en) 2016-09-29 2024-03-06 Nokia Technologies Oy Radio bearer switching in radio access
JP7030814B2 (ja) * 2016-12-29 2022-03-07 オッポ広東移動通信有限公司 信号伝送方法、端末装置及びネットワーク装置

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100694026B1 (ko) * 1999-11-01 2007-03-12 삼성전자주식회사 광대역 무선 전송방법 및 장치
EP1154664A1 (en) * 2000-05-09 2001-11-14 Lucent Technologies Inc. Resource reservation in 3G or future generation telecommunication network II
GB2386283A (en) * 2002-03-05 2003-09-10 Pa Consulting Services Packet data communications network

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014527748A (ja) * 2011-08-09 2014-10-16 アルカテル−ルーセント ビデオコンテンツをストリーミングするための方法、そのような方法を実現するエッジノードおよびクライアントエンティティ
JP2016140101A (ja) * 2011-10-21 2016-08-04 フラウンホーファー−ゲゼルシャフト・ツール・フェルデルング・デル・アンゲヴァンテン・フォルシュング・アインゲトラーゲネル・フェライン 情報資源管理概念
JP2018057028A (ja) * 2011-10-21 2018-04-05 フラウンホーファー−ゲゼルシャフト・ツール・フェルデルング・デル・アンゲヴァンテン・フォルシュング・アインゲトラーゲネル・フェライン 情報資源管理概念
JP2018198433A (ja) * 2011-10-21 2018-12-13 フラウンホーファー−ゲゼルシャフト・ツール・フェルデルング・デル・アンゲヴァンテン・フォルシュング・アインゲトラーゲネル・フェライン ネットワーク資源を管理する装置及び方法
JP2019165491A (ja) * 2011-10-21 2019-09-26 フラウンホーファー−ゲゼルシャフト・ツール・フェルデルング・デル・アンゲヴァンテン・フォルシュング・アインゲトラーゲネル・フェライン 情報資源管理概念
US10945269B2 (en) 2011-10-21 2021-03-09 Fraunhofer-Gesellschaft Zur Foerderung Der Angewandten Forschung E.V. Resource management concept
US11240821B2 (en) 2011-10-21 2022-02-01 Fraunhofer-Gesellschaft Zur Foerderung Der Angewandten Forschung E.V. Resource management concept
US12010714B2 (en) 2011-10-21 2024-06-11 Fraunhofer-Gesellschaft Zur Foerderung Der Angewandten Forschung E.V. Resource management concept

Also Published As

Publication number Publication date
EP1639852A1 (en) 2006-03-29
BRPI0412014A (pt) 2006-08-15
CN1843050B (zh) 2011-02-09
RU2006102360A (ru) 2006-08-10
RU2337505C2 (ru) 2008-10-27
WO2005002264A1 (en) 2005-01-06
KR100752608B1 (ko) 2007-08-29
KR20060054206A (ko) 2006-05-22
CN1843050A (zh) 2006-10-04
JP2010200359A (ja) 2010-09-09

Similar Documents

Publication Publication Date Title
JP2010200359A (ja) 無線通信ネットワークシステム、通信システム及び通信デバイスにおけるリソース予約のための方法とシステム
KR100855610B1 (ko) 통신 시스템에서의 자원 할당 방법
KR100731963B1 (ko) 네트워크에서 ＱｏＳ 프로파일 파라미터를 통지 및부여하는 방법, 시스템 및 통신 장치
KR101008698B1 (ko) 멀티미디어 세션을 위한 서비스 품질 파라미터의 시그널링
JP4927333B2 (ja) 帯域幅適応
US20070223491A1 (en) Apparatus and method for providing quality of service in wireless communication system
KR20050105208A (ko) 이동 망들에서 다이나믹 미디어 인가
CN101548524B (zh) 在不同通信方之间的相互作用控制
JP2015029327A (ja) コンテンツダウンロード及びコンテンツアップロード用ポリシー
EP1552655A1 (en) Bandwidth adaptation
EP1809065A1 (en) Method and system for adjusting the traffic category for a real time stream transmission
RU2406242C2 (ru) Способ и устройства для установки фильтров пакетов в передаче данных

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20080821

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080902

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20081201

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20081208

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090226

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20091222

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100422

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

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20100430

A761 Written withdrawal of application

Free format text: JAPANESE INTERMEDIATE CODE: A761

Effective date: 20100514