JP2007526727A - 通信システムにおける方法、通信システム、および通信装置 - Google Patents

通信システムにおける方法、通信システム、および通信装置 Download PDF

Info

Publication number
JP2007526727A
JP2007526727A JP2007502105A JP2007502105A JP2007526727A JP 2007526727 A JP2007526727 A JP 2007526727A JP 2007502105 A JP2007502105 A JP 2007502105A JP 2007502105 A JP2007502105 A JP 2007502105A JP 2007526727 A JP2007526727 A JP 2007526727A
Authority
JP
Japan
Prior art keywords
communication device
media stream
transmitting
transmission
receiving
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.)
Pending
Application number
JP2007502105A
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 JP2007526727A publication Critical patent/JP2007526727A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • 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
    • 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
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/54—Allocation or scheduling criteria for wireless resources based on quality criteria
    • H04W72/543—Allocation or scheduling criteria for wireless resources based on quality criteria based on requested quality, e.g. QoS

Abstract

本発明は、通信システムにおける方法、通信システム、および通信装置に関する。本方法において、メディアストリームは、送信通信装置から受信通信装置へ少なくとも一部無線通信ネットワークを介して送信される。受信通信装置へ送信されるべき少なくとも1つのメディアストリームが選択され、選択された少なくとも1つのメディアストリームを送信するためのQoS要求が定義され、少なくとも1つのメディアストリームの送信のために、前記無線通信ネットワークから送信リソースが予約され、1つのパケットデータ送信接続を開始するために、受信通信装置と送信通信装置との間に設定プロシージャが実行される。
【選択図】図１

Description

本技術領域はモバイルネットワーク上のストリーミングメディアであり、マルチメディアサーバや、モバイルネットワーク、ストリーミングクライアントが、例えば、セッションの設定および制御に使用されるRTSP（Real Time Streaming Protocol；リアルタイムストリーミングプロトコル）やメディア転送のためのRTPプロトコル（Real Time Streaming Protocol；リアルタイムトランスポートプロトコル）によって論理的に接続される。ストリーミングシステムは、レートアダプティブまたは非アダプティブとすることができる。本発明は、コンテンツおよび/または転送速度を様々なネットワークチャネルの状態に適応させられる、レートアダプティブストリーミングシステムに関する。
本発明は、マルチメディアストリームを、送信通信装置から受信通信装置へ少なくとも一部無線通信ネットワークを介して送信する、通信システムにおける方法に関する。本発明はまた、送信通信装置、受信通信装置、およびマルチメディアストリームを送信通信装置から受信通信装置へ少なくとも一部無線通信ネットワークを介して送信する通信ネットワークを備える通信システムに関する。本発明はさらに、送信通信装置および受信通信装置に関する。
本説明において送信通信装置とは、マルチメディアストリームを通信ネットワークへ送信するように構成される送信機を備えた通信装置を指す。また受信通信装置とは、通信ネットワークからメディアストリームを受信するための受信機を備えた通信装置を指す。同通信装置は、送信機および受信機を備えることが可能であり、それによって、通信ネットワークとの一方向または双方向の通信を行うことができることは明らかである。無線通信装置は、無線通信ネットワークにおいて無線通信を実行する送信機および/または受信機を備える。モバイル通信システムなどの無線通信システムとは、概して、無線通信装置とそのシステムの固定部品との間の無線データ送信接続を可能にし、その無線通信装置のユーザーがそのシステムの作動範囲内を移動するような、あらゆる通信システムを指す。代表的な無線通信システムには、PLMN（Public Land Mobile Network；公衆陸上モバイルネットワーク）がある。周知の例には、GSMシステム（Global System for Mobile telecommunications；モバイル通信用グローバルシステム）がある。本発明は、第三世代のモバイル通信システムに関することが好ましい。一例として、UMTS（Universal Mobile Telecommunications System；汎用モバイル通信システム）が、当該の第三世代の通信システムの一例として使用される。
第三世代システムでは、ベアラサービスおよびサービスという用語が使用される。ベアラサービスとは、アクセスポイント間で信号を送信するための設備を提供する通信サービスのタイプである。一般にベアラサービスは、例えば、無線通信装置とシステムの一部との間で情報が送信された時に、そのシステムで使用されるべきデータ転送速度およびQoS（Quality of Service；サービスの質）を定義する、トラフィックチャネルという用語に相当する。無線通信装置と基地局との間のベアラサービスは、例えば無線ベアラサービスであり、無線ネットワーク制御ユニットとコアネットワークとの間のベアラサービスは、例えばIuベアラサービス（Interface UMTS bearer；インターフェースUMTSベアラ）である。UMTSシステムにおいて、無線ネットワーク制御ユニットとコアネットワークとのインタフェースはIuインターフェースと呼ばれる。UMTSにはいわゆるGERANも存在し、これはIuインターフェースに加えて、Gbインターフェースと呼ばれるインターフェースも使用する。この点について、サービスは、例えば、データサービスが通信システム内でデータ送信を実行したり、電話サービスを通話に関連付けたりするなどのタスクを実行するために、モバイル通信ネットワークによって提供される。したがって、サービスには、無線通信装置とシステムの固定部品との間に通話またはマルチメディアストリームの送信などのデータ送信を必要とする。第三世代のモバイル通信システムの動作のうちの重要なタスクの1つは、利用可能な帯域幅を消費せずに、リクエストされたサービスのそれぞれを移動局に割り当てることができるように、ベアラサービスを制御（必要により初期化、継続および終了）することである。
サービスの質は、例えば、送信の間にPDU（Protocol Data Units；プロトコルデータユニット）がモバイル通信ネットワークにおいてどのように処理されているのかを判断する。例えば、接続アドレスに対して定義されるQoSレベルは、特に2つ以上の接続が同時に送信されるべきパケットを有する場合に、送信順序を制御し、サポートノードおよびゲートウェイサポートノードのパケットをバッファリング（パケット文字列）および拒否するために使用される。異なるQoSレベルは、例えば、異なるビットレートとともに、接続の異なる末端間のパケット通信に対する異なる遅延を判断する。また、拒否されたおよび/または失われたパケットデータユニットの数は、異なるQoSレベルに関連して変化するだろう。
各PDPコンテキストのための異なるQoSをリクエストすることが可能である。例えば、電子メール接続では、ストリームの送信において比較的に長い遅延を許容することができる。しかし、テレビ会議のようなリアルタイムの対話型アプリケーションは、高いレートでのパケット通信を必要とする。ファイル転送などのいくつかのアプリケーションでは、パケット交換送信が完全であることが重要であるが、エラー状態では、パケットデータユニットが必要に応じて再送信される。
UMTSシステムにおけるパケット交換通信サービスには、4つの異なるトラフィッククラスを定義することが提案され、これらのトラフィッククラスの特性には、異なる接続タイプに対する異なる基準を考慮することが目的とされている。第1および第2のクラスに対して定義される1つの基準は、送信がリアルタイムで行われるということであり、その送信には著しい遅延があってはならない。しかし、そのようなクラスでは、データ転送の精度はそれほど重要な特性ではない。対応する態様では、第3および第4のトラフィッククラスに対しては非リアルタイムのデータ転送で十分であるが、比較的正確なデータ送信が必要とされる。リアルタイムの第1クラスの通信の一例には、2人以上が無線通信装置によって互いに話をする状況における会話の音声信号の送信がある。リアルタイムの第2クラスの通信が実行可能な状況の一例には、即時視聴（ストリーミング）用のビデオ信号の送信がある。第3クラスの非リアルタイムのパケット通信は、例えば、インターネットのホームページの閲覧のようなデータベースサービスの利用に使用することができ、その通信では、妥当なレートでの比較的正確なデータ送信がリアルタイムのデータ送信よりも重要な要素である。この例によるシステムでは、例えば、電子メールのメッセージおよびファイルの転送は、第4のカテゴリに分類することができる。必然的に、トラフィッククラスの数は、必ずしもここで述べたように4つではなく、本発明は、あらゆる数のトラフィッククラスを備えるパケット交換通信システムに適用することができる。提示された4つのトラフィッククラスの特性を表1に簡潔に示す。
Figure 2007526727
保証ビットレートはアドミッション制御およびリソース予約のためにRANおよびCNで使用され、最高ビットレートはCNで使用される。すなわち、最高ビットレートよりも低ければ、GGSNでCNに入ることが許可され、このビットレートを超えるパケットは外されることになる。
最新の第二世代および第三世代の無線通信装置は、旧型の無線通信装置よりも良好なデータ処理特性を有する。例えば、それらは既にインターネットに接続する設備を備え、無線通信装置の閲覧アプリケーションを使用してインターネットから情報を取り出す。また今後は、例えば、リアルタイムのテレビ会議などのためのマルチメディア呼の設定が可能になるであろう。
アプリケーションが異なれば、その要件は著しく異なる場合がある。いくつかのアプリケーションでは送信機と受信機との間に高速通信を必要とする。これらのアプリケーションには、例えばビデオおよび電話のアプリケーションが挙げられる。他のいくつかのアプリケーションでは可能な限り正確なデータ送信が必要とされる場合があるが、そのデータ送信接続のビットレートはそれほど重要ではない。これらのアプリケーションには、例えば、電子メールおよびデータベースのアプリケーションが挙げられる。一方で、これらのアプリケーションは、異なる特性を有する複数の無線通信装置において使用することができる。
無線通信装置のユーザーは、無線通信装置によってマルチメディアプレゼンテーションを見ようとする場合がある。ユーザーは、当該のプレゼンテーションのローディングアドレスを発見し、無線通信装置へそのプレゼンテーションを送信させるリクエストを送信する。そのリクエストは、通信システムにおいて処理される。リクエストされたマルチメディアプレゼンテーションのローディングアドレスは、インターネットのサーバーのような通信ネットワーク内のサーバーへアドレス指定を行うことが可能である。この説明では、マルチメディアプレゼンテーションを受信無線通信装置へ配信するサーバーをストリーミングサーバーと呼ぶ。
通信システムは、リクエストされたマルチメディアプレゼンテーションを配信できるように、ストリーミングサーバーと無線通信装置との間の通信のために十分なリソースを確保しなければならない。さもなければ、そのプレゼンテーションは、受信無線通信装置において、同じ精度およびエラーフリーで表示されない場合がある。UMTS通信システムにおいて、無線通信装置は、最初に特定のQoSパラメータを有するPDPコンテキストをリクエストする。次いでネットワークは、いくつかの選択ベース、例えば、無線通信装置がそのリクエストで使用している可能性のあるパラメータを使用することによって、接続のためのベアラを選択する。ベアラサービスがその接続に対して十分な送信容量を提供できなかったり、必要以上の容量を提供してネットワークリソースの使用が効率的でないことが生じる場合があったりする状況では、その選択の根拠は不適切であるか、十分に正確ではなくなる場合がある。
マルチメディア情報の配信が必要となる場合のある別の状況では、ビデオまたは静止画像のようなマルチメディア情報を交換するために、2つの無線通信装置が互いに通信を行う。またこの種の状況では、通信のための十分なリソースがネットワークによって確保されなければならない。しかし、従来技術の方法を使用した場合、接続に対する要求について、その接続の両端に常に通知できるとは限らない。
基本的なストリーミングシステムは非アダプティブである。例えば、リリース4および5の3GPPによって定義される現在のPSS（Packet Switched streaming Service；パケット交換ストリーミングサービス）は非アダプティブである。パケット交換ストリーミングサービスのリリース6は、アダプティブである。アダプティブ特性は、QoSネゴシエーション済チャネルビットレートの変化、転送遅延、または他のQoSパラメータ、あるいはハンドオーバーの場合の下層のネットワークの変化などの、様々なネットワークチャネルの状態に適応するように、システムの能力、すなわちサーバーおよびクライアントの両方によって与えられる。
システムをアダプティブにするためには、ストリーミングサーバーとクライアントとの間にいくつかの通信を構築しなければならない。これは、RTSPプロトコルがセッションの設定や制御に使用されるときにはいつも既に配置されている。しかし、サーバーとクライアントとの間の必要な情報の送信は、システムがアダプティブとなり、最終的にオーディオおよびビデオストリーミングに対して最良のユーザーQoSが達成できることを確実にするために、正しい方法で発生させなければならない。
このために、いくつかの従来技術では、既に、下層のモバイルネットワークに由来するQoS情報のストリーミングクライアントからストリーミングサーバーへの送信を可能にしている。これによって、システムをよりアダプティブにさせるために、両端間でさらに協調することができる。
これまでに規定されていないのは、特定のモバイルネットワーク環境のQoSパラメータとPDP（Packet Data Protocol；パケットデータプロトコル）コンテキストの使用と間の関係である。例えば、様々な場合が考えられる。以下、各RTPメディアストリームに関連する関連RTCPフローは考慮しないものとする。その代わりに、同じマルチメディアストリームの一部としてのRTPおよびそれに関連したRTCPフローが、その問題の性質を変えないものとする。

1. PDPコンテキストは、ストリーミングセッションの1つのメディアだけを搬送する。
2. PDPコンテキストは、1つ以上ある場合にストリーミングセッションの全てのメディアを搬送する。
ストリーミングクライアントが、例えば保証ビットレート、最高ビットレート、または転送遅延などのいくつかのQoSプロファイルパラメータなどの信号を、例えばRTSPを介してストリーミングサーバーへ送ろうとした場合、QoSプロファイルの正しい解釈や、最終的にはネットワーク接続の性質において、サーバーにいくつかの問題が生じる場合がある。
RTSPでは、2種類の可能なセッションがあり、それらはいわゆる集合制御セッションと、非集合制御セッションである。集合制御セッションとは、トランスポートレベルで、クライアントによってサーバーに送信される単一のコマンドによって全てのメディアコンポーネントを制御できるセッションである。（このコマンドの例として、、オーディオおよびビデオコンポーネントのための1つのRTSP PLAYコマンドがある。）このセッションが発生しなければ、すなわち、メディアコンポーネントがセッションにおいて個々に制御されていれば、そのセッションは非集合制御を有するといわれる。
以下、マルチメディアストリームのためのQoSパラメータのネゴシエーションに関する問題を明らかにするために、いくつかの例を示す。これらの例で使用される例および種々のパラメータは、これに制限されるものではなく、その実用において異なる種類のパラメータや、メディアストリームの組み合わせが存在することに留意されたい。
＜例1＞
この例では、マルチメディアストリームには2つのメディア（例、1つはオーディオストリーム、もう1つはビデオストリーム）が含まれる。全ての異なるメディアは、単一のPDPコンテキストを使用して送信される。
ストリーミングクライアントは、オーディオストリームが12kbpsを必要とし、ビデオストリームが52kbpsを必要とする旨のストリーミングサーバーからの通知を（例えば、SDPプロトコルを介して）受信していると仮定する。またストリーミングクライアントは、単一のPDPコンテキストを使用してモバイルネットワークとの接続を確立し、クライアントはそれを通じてオーディオおよびビデオストリームの両方の送信を望んでおり、またネットワークには、（その他の中から）以下のQoSプロファイルパラメータを有するPDPコンテキストが与えられる、と仮定する。

保証ビットレート= 64kbps
最高ビットレート= 70kbps
ここで、システムがよりよく適応できるように、ストリーミングクライアントが、所与のQoSについてネットワークからストリーミングサーバーへ通知したいと仮定してみる。効率を上げるために、クライアントは、2つのメディアが再生される前に、この情報を送ることを決めなることになっている。したがって、SETUPメソッドを使用して上述の2つのフィールドを送ることを選択する。2つのメディアがあるので、クライアントは、以下の情報とともに、2つのSETUPメッセージ（1つはオーディオ用、もう1つはビデオ用）に組み込まれた2つのフィールドを送信することになる。

SETUP（オーディオ）：
保証ビットレート= 12kbps
最高ビットレート= 70kbps

SETUP（ビデオ）：
保証ビットレート= 52kbps
最高ビットレート= 70kbps
各SETUPに送られる保証ビットレートは、各メディアに必要な（ストリーミングサーバーおよびストリーミングクライアントの両方にとって既知である）帯域幅を含むが、最高ビットレートはPDPコンテキストにおいて与えられた最高ビットレートにしかできない。したがって、2つのメディアの間でその最高ビットレートを分割する方法がないので、この例では最高ビットレートを70kbps以外にすることができない。SETUPメソッドは、ストリーミングサーバーによって、メディアごとの記述であるとして解釈される。したがって、サーバーは、2つのSETUPメッセージによって記述される特性を有する仮想的な2つのネットワークチャネルがあるかのうように解釈する（一方のチャネルは、保証ビットレートが12kbpsで最高ビットレートが70kbps、他方のチャネルは保証ビットレートが52kbpsで最高ビットレートが70kbps）。メディアの累積的な保証ビットレートは12 + 52 = 64kbpsであり、これはPDPコンテキストの実際のネットワークの保証ビットレートである。サーバーは、オーディオを70kbpsの最高ビットレートで、またビデオを70kbpsの最高ビットレートで送信できる。単一のPDPコンテキストを使用する場合、これは累積的な最高ビットレートが70 + 70 = 140kbpsであり、PDPコンテキストに対するネットワークの最高ビットレートではないことを意味する。各メディアストリームは可変ビットレートで送信することができるので、2つのメディアの瞬間的なビットレートの和は、ある瞬間において140kbpsに達しうる。しかし、ネットワークリソースが利用できないので、ネットワークによって提供される最高ビットレート（この例では70kbps）よりも大きな値は一切許容されない。したがってサーバーは、PDPコンテキストのQoS情報の誤解に至る。そして、不良なユーザーQoSをもたらす。
一方で、2つのメディア間で70kbpsの最高ビットレートを比例的な方法で分割するということは、異なるメディアによって共有される、サーバーのチャネル使用を次善のものとする可能性があるということである。サーバーは、2つの別々のPDPコンテキストがあるかのようにチャネルの使用を試みる。
サーバーに送信された保証ビットレートの情報が、PDPコンテキストのネットワークによって実際に与えられたものである場合に、同様の問題が生じる。例えば、与えられた64kbpsの保証ビットレートの情報が両方のSETUPメッセージでサーバーに送信された場合、そのサーバーは、オーディオを64kbsの保証ビットレート、ビデオを64kbsの保証ビットレート、全体で128kbpsの保証ビットレートで送信できるようになり、この例ではPDP QoSにおいて利用できないので、更なる問題が生じうる。そして、ネットワークのバッファオーバフローおよび不良なユーザーQoSをもたらす。
＜例2＞
この例でも、マルチメディアストリームには、2つのメディア（例、1つはオーディオストリーム、もう1つはビデオストリーム）が含まれるが、すべての異なるメディアは別々のPDPコンテキストを使用して送信される。
ストリーミングクライアントは、オーディオストリームが12kbpsを必要とし、ビデオストリームが52kbpsを必要とする旨のストリーミングサーバーからの通知を、（例えば、SDPプロトコルを介して）受信していると仮定する。またストリーミングクライアントは、2つのPDPコンテキストを使用してモバイルネットワークとの接続を確立し、クライアントはそれを通じてオーディオおよびビデオストリームそれぞれの送信を望んでおり、またネットワークには、（その他の中から）以下のQoSプロファイルパラメータを有するPDPコンテキストが与えられる、と仮定する。

オーディオのPDPコンテキスト：
保証ビットレート= 12kbps
最高ビットレート= 20kbps

ビデオのPDPコンテキスト：
保証ビットレート= 52kbps
最高ビットレート= 64kbps
ここで、システムの最適化をより進めるために、ストリーミングクライアントが、所与のQoSについてネットワークからストリーミングサーバーへ通知したいと仮定してみる。QoS情報はPLAYコマンドで送信することができる。PLAYコマンドは、サーバーによって集合セッションコマンドであると概して解釈される。したがっていくつかのパラメータだけが送信されなければならない。クライアントは、保証ビットレートを12 + 52 = 64kbpsで、また最高ビットレートを20 + 64 = 84kbpsで送信するように決定することができる。これは、単一のPDPコンテキストが特定のQoSパラメータとともに使用されると理解することになり、サーバーを混乱させるが、この例における事例ではない。
ストリーミングサーバーはストリーミングデータの配信の役割を果たし、無線通信装置は実際の再生の前に所定量のデータを予めバッファする。ストリーミングサーバーはまた、実際の送信帯域幅の変動を補正するために送信ビットレートを調整し、受信バッファ（ジッタバッファ）を保守する役割を果たす。
3GPPにおいて、PSS（Packet Switch Streaming；パケット交換ストリーミング）クライアントは、無線通信ネットワークの特性をPSSサーバーに報告することができる。情報は、RTSP（Real Time Streaming Protocol；リアルタイムストリーミングプロトコル）のヘッダーに含めることができ、ヘッダーではネットワークに関連するパラメータが定義される。パラメータは、例えば、ネットワークの保証ビットレート、ネットワークの最高ビットレート、およびネットワークの最高転送遅延とすることができる。
マルチメディアストリーミングサーバーは、EGPRS（Enhanced General Packet Radio Service；強化型汎用パケット無線サービス）およびCDMA2000（Code Division Multiple Access；符号分割多重アクセス方式） 1xEV-DVのような、異なる接続条件およびネットワークのタイプに適応できることも重要である。異なるモバイルネットワークは異なって作用し、例えば、EGPRS送信チャネルの帯域幅の変動は、CDMA2000 1xEV-DVチャネルのそれよりも小さい。ストリーミングサーバーは、クライアントが使用しているネットワークのタイプについて知っている場合、十分にサービスを配信することができる。例えば送信チャネルの変動が大きい場合、ストリーミングサーバーは、そのチャネル変動にあまり急速に反応してはならない。一方でストリーミングサーバーは、モバイルが安定したチャネルで動作していることを知っている場合は、あらゆるチャネル変動を考慮し、より速く反応しなければならない。ストリーミングサーバーは、ネットワークのタイプを知っていれば、ストリーミングデータを配信するための制御パラメータを調整することができる。しかし残念なことに、その情報は、クライアント側でしか利用できない。
現在、3GPPおよび3GPP2は、レート適応および他のシグナリングに関して異なる命名規則を有する。マルチメディアストリーミングサーバーが、クライアントが使用しているネットワークのタイプを知らない場合、そのサーバーは、シグナリングの間にリクエストへの応答に問題を有する可能性がある。3GPPおよび3GPP2に準拠したサーバーは、対応する規格に関連するシグナリングを解析および送信できなければならない。ただし、これはそのサーバーで当該の情報を利用できる場合に限ったことである。
上述の実施例の場合における主たる問題は、ストリーミングサーバーがPDPコンテキストの割当てタイプについて可視性を持たないので、どのタイプのネットワークチャネルがデータ転送に予約されているのかを知らないことである。（そのデータ転送は単一または複数のPDPコンテキストになりうる。）この可視性は、ストリーミングクライアント側だけにある。
発明のまとめ
したがって、本発明は、クライアントによってネットワークPDPコンテキストのQoS情報について通知された場合にサーバーが直面する可能性のある、起こりうる誤解の解決を対象とした方法およびシステムを提供することを目的とする。
本発明の別の目的は、ストリーミングデータの配信および/または最適なサービスの質を提供するためのシグナリングを調整することである。
本発明の別の目的は、3GPPおよび3GPP2に存在する命名規則の問題に関する。
本発明の目的は、ネットワークによってクライアントに与えられるセッション特性についてサーバーに通知するための、異なる種類のパラメータの送信方法を使用することによって達成される。
本発明は、無線通信ネットワークタイプに対する新しいシグナリングおよびヘッダーを提供する。無線通信ネットワークタイプの情報はモバイルでのみ利用可能である。本発明では、この情報を受信機からサーバーへ送信することを提案する。
本発明には、従来技術のシステムおよび方法と比較していくつかの利点がある。本発明によって、各PDPコンテキストに与えられたQoSパラメータストリーミングをサーバーに認識させることができる。これによって、より正確なQoSプロファイルパラメータを規定することによる良好かつより正確な適応化が可能となる。
本発明によって、無線通信装置によって使用されるネットワークのタイプをストリーミングサーバーに認識させることもでき、サービスの質をさらに向上させる。本発明によって、サーバーはまた、3GPPおよび3GPP2準拠のシグナリングを適切に構成することも可能である。
本発明は、ストリーミングセッションのためにクライアントが使用する単一または複数のPDPコンテキスト、およびサーバーへのQoSパラメータのシグナリングによって生じる競合を解決する。
本発明に記述されるプロシージャを使用しなければ、マルチメディアセッションはQoSパラメータ情報からの利益を得られず、反対に、サービスの質が低下する危険がある。
本発明は、無線ストリーミングのコンセプトを使用して、マルチメディアストリーミングの能力を向上させ、また、3GPPおよび3GPP2特定のプロトコルおよびコードを使用する無線ドメインへの適応力を向上させる。
もう1つの重要な利点は、最高ビットレートすなわち保証ビットレートとして計算される、デルタ帯域幅を効率的に使用できる可能性があるということである。この帯域幅は、帯域幅の適応化やビデオビットレートのピーク処理に使用することができる。最後に、このデルタ帯域幅は、例えば、ビットレートに影響を与える符号化パラメータ（メディアストリームビットレートを含む）を高速に変更することによって、リアルタイムでマルチメディアを符号化する場合に、最良のメディア品質を提供するために使用することができる。
発明の詳細な説明
以下、添付の図面を参照して本発明を詳細に説明する。以下の本発明の好適な実施態様の説明では、UMTSタイプのモバイル通信システムを一例として使用する。しかし、本発明はこのシステムに限定されるものではなく、通信のために様々なQoSレベルを判断できる他の通信システム（例、EGPRS）にも適用できることは、当業者には明らかであろう。
以下、SDP（Session Description Protocol；セッション記述プロトコル）を詳述する。
Mbone（Internet Multicast Backbone；インターネットマルチキャストバックボーン）上では、マルチメディア会議を通知するためや、会議のアドレスと参加者に必要なメディア固有の情報を通信するために、セッションディレクトリツールが使用される。マルチキャストバックボーンは、IP（Internet Protocol；インターネットプロトコル）マルチキャストに対応するインターネットの一部であるため、効率的な多対多の通信が可能となる。マルチキャストバックボーンはマルチメディア会議のために幅広く使用される。そのような会議は通常、会議の受信には会議のメンバーシップの堅固な連携は必要でなく、マルチキャストバックボーンサイトのユーザーは、その会議のマルチキャストグループのアドレスおよび会議のデータストリームのためのUDPポートだけを知っていればよいという、特性を有する。
セッションディレクトリは、会議セッションの通知を支援し、予定される関係者に関連する会議の設定情報を伝える。SDPは、当該の情報を受信者に伝えるように構成される。SDPは単にセッションを記述するフォーマットであり、トランスポートプロトコルは組み込まず、また、Session Announcement Protocol（セッションアナウンスプロトコル）やSession Initiation Protocol（セッション開始プロトコル）、RSTP（Real-Time Streaming Protocol；リアルタイムストリーミングプロトコル）、MIME拡張を使用した電子メール、およびHypertext Transport Protocol（ハイパーテキスト転送プロトコル）を含む、様々なプロトコルによって伝達することができる。
SDPは、マルチキャストセッションディレクトリだけではなく、広範囲のネットワーク環境およびアプリケーションに使用できるように汎用となることが意図されたものである。
マルチメディア会議では、2つ以上で一組となる通信装置がソフトウェアとともに通信に使用される。しかし、例えばビデオ会議などの他の好適なアプリケーションがあることも明らかになろう。
マルチメディアセッションは、一組のマルチメディア送信者および受信者であり、データストリームは送信者から受信者へ流れる。マルチメディア会議は、マルチメディアセッションの一例である。
以下、セッション記述プロトコルの本定義のいくつかを詳述する。プロトコルの記述は、一部が必須であり、一部はオプションである。"*"は、オプションのアイテムを示す。

セッションの記述
v= （プロトコルのバージョン）
o= （オーナー/クリエータおよびセッションの識別子）
s= （セッション名）
i=* （セッション情報）
u=* （記述のURI）
e=* （電子メールアドレス）
p=* （電話番号）
c=* （接続情報：全てのメディアに含まれていれば不要）
b=* （帯域幅情報）
1つ以上の時間の記述（下記参照）
z=* （タイムゾーン調整）
k=* （暗号鍵）
a=* （ゼロ以上のセッション属性ライン）
ゼロ以上のメディアの記述（下記参照）

時間の記述
t= （セッションがアクティブである時間）
r=* （ゼロ以上の繰り返し数）

メディアの記述
m= （メディア名およびトランスポートアドレス）
i=* （メディア名称）
c=* （接続情報：セッションレベルで含まれる場合はオプション）
b=* （帯域幅情報）
k=* （暗号鍵）
a=* （ゼロ以上のセッション属性ライン）
上述の資料によれば、帯域幅の記述は以下のように定義される。

b=<修飾子>：<帯域幅-値>

これは、セッションまたはメディアで使用されるように提案された帯域幅を規定するものであるが、オプションである。
<帯域幅-値>は、デフォルトでキロビット/秒である。修飾子は使用される別のユニットを規定することが可能である。
<修飾子>は、帯域幅の図の意味を与える単一の英数字単語である。2つの修飾子が最初に定義される。

CT（Conference Total；会議全体）：セッションまたはセッション内のメディアの帯域幅が想定される帯域幅とは異なる場合、"b=CT：..."行は、使用される帯域幅の上限案をセッションに与えるべく提供されなければならない。この主たる目的は、2つ以上のセッションが同時に共存できるかどうかに関して、おおよその予測を与えることである。

AS（Application Specific Maximum；アプリケーション特有の最大値）：帯域幅は、アプリケーションに特有であると解釈される。すなわち、アプリケーションの最大帯域幅の概念となる。通常、これは妥当な場合にアプリケーションの"最大帯域幅"制御に設定されているものと一致する。RTPベースのアプリケーションに関して、ASは、RFC 1889（RTP）の6.2項に定義される（メディアビットレートおよびUDP/IPヘッダーのオーバーヘッドを含む）ようなRTP"セッション帯域幅"を提供する。
RTSP（Real Time Streaming Protocol；リアルタイムストリーミングプロトコル）は、リアルタイム特性を有するデータの配信を制御するクライアント-サーバープロトコルである。RTSPは、オーディオおよびビデオのような連続的メディアの単一または複数の時間同期ストリームの構築および制御に使用される。RTSPは、UDPおよびTCPのようなトランスポートプロトコルによって伝達される。すなわち、RTSPは、マルチメディアサーバーのためのネットワークの遠隔制御としての役割を果たす。データのソースは、実データフィード（例、リアルタイムのビデオおよび/またはオーディオ）および格納クリップ（例、静止画像）の両方を備えることができる。RTSPクライアントおよびサーバーは、メディア配信のための適切なセットのパラメータについてネゴシエーションを行い、それらのパラメータを記述するために、一部、例えばSDP（Session Description Protocol；セッション記述プロトコル）構文を使用する。
図1は、UMTSシステムの一部を示すものであり、無線通信装置MT1と、基地局2（BS）および基地局2を制御し、基地局2と残りのシステムとの間の接続のルーティングを行う無線ネットワークコントローラ3（RNC；Radio Network Controller）を備える無線アクセスノード1（RAN；Radio Access Node）と、無線モバイル交換局4（Wireless Mobile Switching Centre；WMSC）と、無線ネットワークコントローラ3に加えてルーティングの可能性としてパケットデータアクセスノード5（PDAN；Packet Data Access Node）とを備える。図1に記載のUMTSシステムはまた、バックボーンネットワーク6およびインターネットプロトコル（IP；Internet Protocol）ネットワーク7などの他のネットワークへのパケットデータゲートウェイ8（PDG；Packet Data Gateway）も備え、無線通信ネットワークは、例えばIPネットワークに接続されるサーバー10と通信することができる。さらに、図1は、例えば第2のモバイル通信ネットワークNW2へ接続するための回路交換ゲートウェイ9（Gateway to Mobile services Switching Centre；GWMSC；モバイルサービス交換局へのゲートウェイ）と、サブスクライバのアクセス契約データを格納するためのホームロケーションレジスタ11（HLR；Home Location Register）とを示す。
また、図2は、本発明の好適な実施態様に適合する無線通信装置MT1を簡略化したブロック図において示しており、この実施例では、通信装置がNokia 9210iコミュニケータのようなデータ処理機能および移動局機能を備える。無線通信装置MT1は、例えば、1つ以上のプロセッサCPU、DSP、メモリ手段MEM、USIM（UMTS subscriber identity module；UMTSサブスクライバアイデンティティモジュール）、またはサブスクライバを識別するための対応する手段、および基地局2と通信するための無線部分RFを備える。プロセッサCPUは、例えば、特定用途向け集積回路12（Application Specific Integrated Circuit；ASIC）に組み込むことができ、それによって、無線通信装置MT1の多数の論理機能を実行することが可能である。メモリ手段は、ランダムアクセスメモリ（RAM；Random Access Memory）、リードオンリメモリ（ROM；Read Only Memory）、およびサブスクライバアイデンティティモジュールUSIMのメモリの少なくとも一部を備えることが好ましい。無線通信装置MT1はまた、1つ以上のユーザーインターフェースも備え、キーパッド13および14、ディスプレイ15および16、およびマイク17、スピーカ18、およびコーデック19などのオーディオ手段を備えることが好ましい。
図1では、呼管理（CM；Call Management）に関連する機能は、無線通信装置MT1および無線モバイル交換局4とパケットデータアクセスノード5の両方で実行されるものとする。これらの呼管理機能は、呼を初期化、保持、および終了するための手段を構成する。したがって、無線通信装置MT1および無線モバイル交換局4またはパケットデータアクセスノード5は、呼を初期化、保持、および終了するために呼信号メッセージを交換する。ベアラ管理（BM；Bearer Management）および無線リソース管理（RM；Resource Management）機能は、無線通信装置MT1および無線ネットワークコントローラ3において実行される。ベアラ管理機能は、ベアラサービスに適合するサービスの質を提供するために、例えば、無線通信装置MT1と基地局2との間の通信のために選択されるベアラサービスの特性の基づいた1つ以上の論理チャネルの選択に用いられる。無線リソース管理機能は、例えば、無線通信装置MT1と基地局2との間の無線通信のための無線チャネルの選択に使用される。
無線通信装置MT1とIPネットワーク7との間のパケットデータ送信接続は、パケットデータバックボーン6およびパケットデータゲートウェイ8（PDG；Packet Data Gateway）を介して、パケットデータアクセスノード5（PDAN；Packet Data Access Node）から設定することができる。無線通信装置MT1とモバイル通信ネットワークとの間の回路交換データ送信接続は、無線アクセスノード1、無線モバイル交換局4、およびモバイルサービス交換局へのゲートウェイ9（GWMSC；Gateway to Mobile services Switching Centre）を介して設定することが可能である。このモバイルサービス交換局へのゲートウェイ9は、モバイル通信ネットワークとGSM、PSTN、またはISDNなどの第2のネットワークNW2との間の接続を設定するための手段を備える。
以下、ストリーミングマルチメディアアプリケーションのための本発明の好適な実施態様による方法を図1のシステム図と、図3および4のシグナリング図を参照して説明する。以下の実施態様は、RTSPプロトコルの使用に基づいたものである。また、"QoSParams、MaxBW、GuaBW、TdelayMax、url"パラメータは、上述の発明の概念的プレースホールダである仮想のパラメータ名である。それらは、現実の実施とは異なって命名される場合がある。
まず、いくつかの用語を定義する。クライアントは無線通信装置MT1であり、サーバーはクライアントへのトリーミングマルチメディアサービスプロバイダである（例、図1のサーバー10）。マルチメディアセッションは、マルチメディア関連のデータがクライアントとサーバーと間で交換される間の時間間隔である。マルチメディアセッションSet-upフェーズは、クライアントとサーバーとの間で、例えば、セッション中に使用されるマルチメディアコンポーネントや帯域幅情報、コーデック関連の情報などのマルチメディアセッション関連の設定情報を交換する間の時間間隔である。PDPコンテキストは、QoSリソース予約処理とストリーミングクライアントを実行する移動局との間の概念上の範囲の論理的指示である。
クライアントは、QoS（Quality of Service；サービスの質）が有効なネットワークNW1内に存在することが可能であり、そのリソースに基づいてクライアントへいくつかの保証を提供することができる。これらの保証は、次のうちの1つ以上をカバーすることが可能である。

・ 最高ビットレート（MaxBW）： ネゴシエーション済メディアコンポーネントまたはマルチメディアセッション全体で使用することができる最大帯域幅。
・ 保証ビットレート（GuaBW）： QoS予約プロシージャが、ネゴシエーション済メディアコンポーネントまたはマルチメディアセッション全体に対する保証をクライアントに行う帯域幅の値。
・ 転送遅延（TDelayMax）： 各データユニットが、サーバーからクライアントへの送信およびその逆の送信の間に遭遇する遅延（ミリ秒）。
・ 他のパラメータも定義することができるが、ここでは詳述しない。
本発明は、クライアントがその能力に基づいてマルチメディアセッション中に複数または単一のPDPコンテキストを有しうる2つの異なる可能性をカバーする。
最初に、クライアントが一度に単一のPDPコンテキストしか処理できない状況について詳述する。すなわち、単一のPDPコンテキストのサポートを有するクライアントは、一度に単一のQoSリソース予約を有することができ、それはマルチメディアセッション中の全てのメディアコンポーネント（すなわち、オーディオ、ビデオなど）に及ぶ。これは、ビデオまたはオーディオなどであることに関係なく、マルチメディアデータは、同じQoSリソースと同じ送信チャネルを共有することを意味する。
第1のシナリオでは、ストリーミングセッションに対して単一のPDPコンテキストしか持たない無線通信装置MT1（クライアント）のために、集合制御セッションが起動される。このシナリオでは、無線通信装置MT1がセッションを設定するための複数のメディアコンポーネントを有する場合（例えば、オーディオと付随のビデオストリーム）、本出願の背景技術の項に記載した問題により、クライアントは、Set-Upフェーズの間に、最高ビットレートMaxBWや、保証ビットレートGuaBW、最大転送遅延TdelayMax、および他のQoSパラメータなどのネゴシエーション済QoSパラメータをサーバー10に送信しなければならない。
QoSネゴシエーション済パラメータは、ストリームの送信が開始されるとき又はその後、すなわち、Playコマンドが無線通信装置MT1からサーバー10へ送信されるとき又はその後に、サーバーに送信されなければならない。
コマンドシーケンスは、次のようになる（図3）。
無線通信装置MT1は、301で、Describe Sessionコマンドをサーバー10に送信する。

DESCRIBE rtsp://server.com/session1.3gp RTSP/1.0
CSeq: 1
Accept: application/sdp
サーバー10は、302で、異なるメディアストリームに関する情報を含むSDPの記述を送信することによって、このコマンドに応答する。

RTSP/1.0 200 OK
CSeq: 1
Content-Base: rtsp://server.com/session1.3gp/
Content-Type: application/sdp
Content-Length: 441
v=0
o=- 3242987154 3242987154 IN IP4 111.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:96 H263-2000/90000
a=control:trackID=2
a=range:npt=0-60
a=fmtp:96 profile=0;level=10
m=video 0 RTP/AVP 98
b=AS:40
a=rtpmap:98 H263-2000/90000
a=control:trackID=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
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
a=fmtp:99 octet-align=1
上述のSDPの記述では、ビデオ1は50kbpsのb=ASの定義を有し、ビデオ2は20kbpsのb=ASの定義を有し、オーディオ1は10kbpsのb=ASの定義を有し、オーディオ2は20kbpsのb=ASの定義を有する。
次いで無線通信装置MT1では、無線通信装置MT1へ送信されるべきストリームを選択するために、通知されたメディアの中から、例えばユーザーによって選択が行われる。この実施例では、合計70kbpsのビットレートで、ビデオ1（50kbps）およびオーディオ2（20kbps）が選択されたものとする。その後無線通信装置は、303で、ベアラサービスのためのリクエストを通信ネットワークNW1へ送信する。そのリクエストにおいて、無線通信装置MT1は、全てのメディアコンポーネントに所望されるQoSパラメータ（70kbpsの最高ビットレート）を含む。
この実施例では、ネットワークは、60kbpsしか保証できず、可能な最高ビットレートは80kbpsである。次いで、ネットワークNT1は、304で、ベアラサービスための与えられたQoSパラメータを無線通信装置MT1に通知する。PDPセッションへのベアラサービスのためのネットワークとのネゴシエーションの後、無線通信装置MT1は、305で、選択された第1のメディアストリーム、すなわちビデオ1を通知するために、第1の設定メッセージをサーバー10に送信する。

SETUP rtsp://server.com/session1.3gp/trackID=2 RTSP/1.0
CSeq: 2
Transport:RTP/AVP/UDP;unicast;client_port=6984-6985;ssrc=31336d02
選択が許可されれば、306で、サーバー10はOKメッセージで応答する。

RTSP/1.0 200 OK
CSeq: 2
Session: 41
Transport:RTP/AVP/UDP;unicast;client_port=6984-6985;server_port=6900-6901;ssrc=1d12115
無線通信装置MT1はまた、307で、選択された第2のメディアストリーム、すなわちオーディオ2を通知するために、第2の設定メッセージをサーバー10に送信する。

SETUP rtsp://server.com/session1.3gp/trackID=4 RTSP/1.0
CSeq: 3
Transport: RTP/AVP/UDP;unicast;client_port=6986-6987;ssrc=37115e8d
Session: 41
選択が許可されれば、308で、サーバー10はOKメッセージで応答する。

RTSP/1.0 200 OK
CSeq: 3
Session: 41
Transport:RTP/AVP/UDP;unicast;client_port=6986-6987;server_port=6902-6903;ssrc=7475313
メディアストリームの再生は、309で、無線通信装置MT1からサーバー10へPlayコマンドを送信することによって開始される。この場合、Playコマンドには、ネットワークNT1が与えた最高ビットレートおよび保証ビットレートに関連する少なくともQoSパラメータに関する情報が含まれる。

PLAY rtsp://server.com/session1.3gp RTSP/1.0
CSeq: 4
Session: 41
QoSParams: MaxBW=80;GuaBW=60;TDelayMax=500
Range: npt=0-
サーバーは、無線通信装置MT1へOKを送信することによってそのコマンドに応答する。

RTSP/1.0 200 OK
CSeq: 4
Session: 41
Range: npt=0-
RTP-Info: url=rtsp://server.com/session1.3gp/trackID=2;seq=0;rtptime=10000,url= rtsp://server.com/session1.3gp/trackID=4;seq=0;rtptime=10000
これで、サーバー10がPlayコマンドを受信したときに、無線通信装置MT1によって送られたQoSパラメータを有する単一のQoSチャネルが存在し、サーバー10は、選択されたメディアストリームの送信をそのパラメータに基づいて適応させることができることがわかる。
Playコマンドの後、無線通信装置MT1は、ストリーミングシステムのコンテキスト内で定義される他のいずれかのRTSPコマンドを使用して、マルチメディアセッション全体に対するネゴシエーション済のQoSパラメータを交信することが可能である。
マルチメディアセッションが非集合制御セッションである（例えば、オーディオおよびビデオデータが2つの別々のサーバーから取り出される）場合、別々のメディアサーバーが互いに認識しないように、またメディアコンポーネントが同じQoS予約チャネルを共有してるということを認識しないように、無線通信装置MT1は、QoSパラメータを送信してはならない。
次に、クライアントが一度に複数のPDPコンテキストをサポートできる状況について詳述する。すなわち、複数のPDPコンテキストのサポートを有するクライアントは、一度に複数のQoSリソース予約を有することができ、マルチメディアセッション中にメディアコンポーネント（すなわち、オーディオ、ビデオなど）間に配信することができる。マルチメディアセッション中には、各メディアコンポーネント（すなわち、オーディオ、ビデオなど）に対して別々のマルチメディアセッションが存在し得る。全てのメディアコンポーネントは、異なるQoSリソース予約を有することができる。
この第2のシナリオでは、無線通信装置MT1がセッションを設定するための複数のメディアコンポーネントを有する場合や、無線通信装置MT1が異なるメディアコンポーネントに対して複数のPDPコンテキストを起動しようとする場合、またセッション制御プロトコルがメディアコンポーネントurlインジケータにメディアコンポーネント間の識別をさせない場合、無線通信装置MT1は、QoSネゴシエーション済MaxBW、GuaBW、TDelayMax、および他のQoSプロファイルパラメータ（おそらくはこれらのパラメータに追加されるパラメータ）をPlayコマンドでサーバーに送信してはならない。各メディアコンポーネントの設定フェーズの間に、QoSパラメータがその代わりとして送信されなければならない。
コマンドシーケンスは、次のようになる（図4）。
無線通信装置ＭＴ1は、401で、Describe Sessionコマンドをサーバー10に送信する。

DESCRIBE rtsp://server.com/session1.3gp RTSP/1.0
CSeq: 1
Accept: application/sdp
サーバー10は、402で、異なるメディアストリームに関する情報を含むSDPの記述を送信することによって、このコマンドに応答する。

RTSP/1.0 200 OK
CSeq: 1
Content-Base: rtsp://server.com/session1.3gp/
Content-Type: application/sdp
Content-Length: 441

v=0
o=- 3242987154 3242987154 IN IP4 111.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:96 H263-2000/90000
a=control:trackID=2
a=range:npt=0-60
a=fmtp:96 profile=0;level=10
m=video 0 RTP/AVP 98
b=AS:40
a=rtpmap:98 H263-2000/90000
a=control:trackID=3
a=range:npt=0-60
a=fmtp:98 profile=0;level=10
m=audio 0 RTP/AVP 97
b=AS:10a=rtpmap:97 AMR/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
a=fmtp:99 octet-align=1
上述のSDPの記述では、ビデオ1は50kbpsのb=ASの定義を有し、ビデオ2は20kbpsのb=ASの定義を有し、オーディオ1は10kbpsのb=ASの定義を有し、オーディオ2は20kbpsのb=ASの定義を有する。
次いで、無線通信装置MT1では、例えばユーザーによって、無線通信装置MT1へ送信されるべきストリームを選択するために、通知されたメディアの中からの選択が行われる。この実施例では、50kbpsのビットレートのビデオ1および20kbpsのビットレートのオーディオ2が選択されたものとする。その後、無線通信装置は、403で、第1のベアラサービスのための第1のリクエストを通信ネットワークNW1へ送信する。そのリクエストにおいて、無線通信装置MT1は、第1のメディアコンポーネント（ビデオ1）に所望されるQoSパラメータ（50kbpsの保証ビットレート）を含む。この実施例では、ネットワークは、50kbpsしか保証できず、可能な最高ビットレートは80kbpsである。次いで、ネットワークNT1は、404で、第1のベアラサービスのための与えられたQoSパラメータを無線通信装置MT1に通知する。次に、無線通信装置は、405で、第2のベアラサービスのための第2のリクエストを通信ネットワークNW1へ送信する。そのリクエストにおいて、無線通信装置MT1は、第2のメディアコンポーネント（オーディオ1）に所望されるQoSパラメータ（20kbpsの保証ビットレート）を含む。この実施例では、ネットワークは、20kbpsしか保証できず、可能な最高ビットレートは40kbpsである。次いで、ネットワークNT1は、406で、第2のベアラサービスのための与えられたQoSパラメータを無線通信装置MT1に通知する。PDPセッションへのベアラサービスのためのネットワークとのネゴシエーションの後、無線通信装置MT1は、407で、選択された第1のメディアストリーム、すなわちビデオ1を通知するために、第1の設定メッセージをサーバー10に送信する。

SETUP rtsp://server.com/session1.3gp/trackID=2 RTSP/1.0
CSeq: 2
Transport: RTP/AVP/UDP;unicast;client_port=6984-6985;ssrc=31336d02
QoSParams:url= rtsp://server.com/session1.3gp/trackID=2;MaxBW=80;GuaBW=50;TDelayMax=500
選択が許可されれば、408で、サーバー10はOKメッセージで応答する。

RTSP/1.0 200 OK
CSeq: 2
Session: 41
Transport:RTP/AVP/UDP;unicast;client_port=6984-6985;server_port=6900-6901;ssrc=1d12115
無線通信装置MT1はまた、409で、選択された第2のメディアストリーム、すなわちオーディオ2を通知するために、第2の設定メッセージをサーバー10に送信する。

SETUP rtsp://server.com/session1.3gp/trackID=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
選択が許可されれば、410で、サーバー10はOKメッセージで応答する。

RTSP/1.0 200 OK
CSeq: 3
Session: 41
Transport:RTP/AVP/UDP;unicast;client_port=6986-6987;server_port=6902-6903;ssrc=7475313
メディアストリームの再生は、411で、無線通信装置MT1からサーバー10へPlayコマンドを送信することによって開始される。

PLAY rtsp://server.com/session1.3gp RTSP/1.0
CSeq: 4
Session: 41
Range: npt=0-
この場合、Playコマンドには、ネットワークNT1が与えた最高ビットレートおよび保証ビットレートに関連するQoSパラメータに関する情報は含まれない。
サーバーは、無線通信装置MT1へOKを送信することによってそのコマンドに応答する。

RTSP/1.0 200 OK
CSeq: 4
Session: 41
Range: npt=0-
RTP-Info: url=rtsp://server.com/session1.3gp/trackID=2;seq=0;rtptime=10000,url=rtsp://server.com/session1.3gp/trackID=4;seq=0;rtptime=10000
別様には、RTSPのPLAYリクエストにおいて、無線通信装置MT1は以下を行えたはずである。

PLAY rtsp://server.com/session1.3gp RTSP/1.0
CSeq: 4
Session: 41
Range: npt=0-
QoSParams: url= rtsp://server.com/session1.3gp/trackID=2;MaxBW=80;GuaBW=50;TDelayMax=500,url= rtsp://server.com/session1.3gp/trackID=4;MaxBW=40;GuaBW=20;TDelayMax=500
これで、サーバーは、そのメディアコンポーネントURLに基づいて、どちらのQoSパラメータがどちらのメディアコンポーネントに割り当てられるのかを識別することができる。

Server -> Client: OK
RTSP/1.0 200 OK
CSeq: 4
Session: 41
Range: npt=0-
RTP-Info: url=rtsp://server.com/session1.3gp/trackID=2;seq=0;rtptime=10000,url=rtsp://server.com/session1.3gp/trackID=4;seq=0;rtptime=10000
これで、サーバー10がPlayコマンドを受信した時に、無線通信装置MT1によって送られた個々のQoSパラメータを有する複数のQoSチャネルが存在することがわかる。各メディアコンポーネントが、各PDPコンテキストに有効なそれ自体のセットのQoSネゴシエーション済パラメータを有することになるので、サーバーは、割り当てられた正しい値によって、各メディアコンポーネントに正しいQoSネゴシエーション済パラメータを問題なく関連づけることができる。
クライアントはまた、無線通信ネットワークに関する情報をサーバーへ提供することが可能である。この情報はクライアント側で入手可能なため、サーバーは必ずしもこれを有するわけではない。本発明によれば、ネットワークのタイプに関する情報は、クライアントからサーバーへ送信される。そうするために、本発明は、ネットワークのタイプに新しいRTSPヘッダー、"Mobile-Link-Char"、およびそのためのシグナリングを提供する。
上述のように、"Mobile-Link-Char"ヘッダーは、マルチメディアストリーミングサービスクライアントが、ネット枠の特性をストリーミングサーバーに報告できるようにするために定義される。"Mobile-Link-Char"ヘッダーは、SETUP、PLAY、OPTIONS、およびSET_PARAMETERのメソッドのいずれかを、使用するリクエストに含むことができる。ヘッダーは、1つ以上の特性の仕様を含むことができる。各仕様は、絶対または相対のいずれかとすることができるURIを含み、相対URIは、RTSPリクエストURIをベースとして使用する。URIは、所与のパラメータを適用するメディアコンポーネントを指し示す。これは、個々のメディアストリームまたはセッションの集合体のいずれかとなりうる。"Mobile-Link-Char"ヘッダーは、リンク特性に初期値を与えるために、クライアントによってリクエストされるSETUPまたはPLAYに含めなければならない。SET_PARAMETERまたはOPITIONSリクエストは、現在再生しているセッションのMobile-Link-Charの値の更新に使用することができる。
"Mobile-Link-Char"には、モバイルネットワークのタイプ（MNT）のためのフィールドが含まれ、シグナリングに使用される無線通信ネットワークを定義する。"MNT"とともに、送信リンクユーザーデータ転送率（kbits/s）のためのGBW、送信リンクの最大遅延（ミリ秒）のためのMTD、および送信リンクの最高ビットレート（kbits/s）のためのMBWなどの他のパラメータも存在し得る。また、上述以外のパラメータもヘッダーに含むことができる。
本発明による"MNT"フィールドは、次の例に基づいて構成される。

MNT=<標準の本体>-<ネットワークタイプID>-<リリース情報>

"標準の本体"は、例えば、3GPPまたは3GPP2などの対応するネットワークの識別に使用される。これによって、サーバーは好適なシグナリングを行うことができ、当該のネットワークに準拠する。

"MNT"のネットワークのタイプのフィールドにおける有効な文字列は、例えば、EGPRS、W-CDMA、およびCDMA2000とすることができ、"MNT"のリリース情報は、ネットワークの関連リリースのバージョンである。3GPPの"Network type ID"は、EGPRSまたはW-CDMA（Wideband Code-Division Multiple-Access；広帯域符号分割多元接続）に対応し、3GPP2では、HRPD（High Rate Packet Data；高率パケットデータ）またはSSS（Spread Spectrum Systems；広帯域スペクトラムシステム）に対応する。3GPPの"Release information"は、REL-x （xは数字）に対応し、3GPP2ではREL-y （yは0、A、B、Cなど）に対応する。"Standard body"および"Network type ID"のフィールドは、参照目的のためにだけリストされる。本発明の範囲から逸脱することなく、それらにより新しい追加を行えることは明らかである。
例えば、3GPP2準拠のネットワーク（1xEV-DV）のヘッダーは次のようになる。

Mobile-Link-Char: url="rstp://server.example.com/media.3g2";MNT=3GPP2-SSS-REL-C
別の例では、3GPP2準拠のネットワーク（1xEV-DO）のヘッダーは次のようになる。

Mobile-Link-Char: url="rstp://server.example.com/media.3g2";MNT=3GPP2-HRPD-REL-0
さらに別の例では、3GPP準拠のネットワークのヘッダーは次のようになる。

Mobile-Link-Char: url="rstp://server.example.com/media.3gp";MNT=3GPP-EGPRS-REL-5
さらに別の例では、3GPP準拠のネットワーク（1xEV-DV）のヘッダーは、他のパラメータ（ビットレートは32kbpsであり、最大転送遅延は2.0秒である）を有し、次のようになる。

Mobile-Link-Char: url="rstp://server.example.com/media.3gp";MNT=3GPP-CDMA2000-Rev-C;GBW=32;MTD=2000
サーバーは、クライアントが操作している3GPPまたは3GPP2のいずれかに準拠するネットワークの"MNT"フィールドから差し引くことができる。これにより、RTSP、DP、RTCPおよび他のシグナリングに対する適切な構文によってクライアントに応答することができる。1xEV-DVおよび1xEV-DOという用語は、データ転送の進化（それぞれデータおよび音声、およびデータのみ）に対応する。
特定のPDPコンテキスト（すなわち、特定のメディアコンポーネント）に対してQoSの再ネゴシエーションが生じる場合、クライアントは、変化が生じたメディアコンポーネントを適切に参照することによって、利用可能ないずれかのRTSPコマンドを使用して、新しいQoS値を送ることができる。
セッション制御プロトコルがメディアコンポーネントurlインジケータにメディアコンポーネント間の識別を認める場合、QoSパラメータは、Playのリクエストにおいても送ることができる。

Client -> Server ： Setup （メディアコンポーネント1）
Server -> Client ： OK
Client -> Server ： Setup （メディアコンポーネント2）
Server -> Client ： OK
Client -> Server ： Play （メディアコンポーネント1のURL +メディアコンポーネント1のためのネゴシエーションを行ったQoSパラメータ；メディアコンポーネント2のURL +メディアコンポーネント2のためのネゴシエーションを行ったQoSパラメータ）
Server -> Client ： OK
上述の実施例では、サーバーは、メディアコンポーネントと、"media component URL"情報を使用して各コンポーネントに割り当てられたQoSパラメータとの差異を認めることができる。このフィールドは、セッション内のメディアコンポーネントの一意の識別子である。クライアントおよびサーバーが当該のパラメータを使用できる場合、無線通信装置MT1は、Set-UpフェーズまたはPlayフェーズのいずれかでQoSパラメータの送信を選択することが可能である。このメディアコンポーネントURLインジケータはまた、QoSの再ネゴシエーションが生じる場合、無線通信装置MT1に、セッション中にQoSパラメータを更新する可能性も与える。
マルチメディアセッションが非集合制御セッションである（例えば、オーディオおよびビデオデータが2つの別々のサーバーから取り出される）場合、クライアントは、各メディアコンポーネントに別々のPlayコンポーネントが存在するので、Playコマンドと同様にSet-UpコマンドでQoSネゴシエーション済パラメータを問題なく送ることができる。
メディアコンポーネントURLフィールドはまた、第1の実施例においてセッションURLを識別するためにも存在するが、その場合でも、Set-UpフェーズでQoSパラメータを送信しない制限は有効である。
QoSパラメータセットがメディアコンポーネントURLを含まない場合、割り当てているQoSパラメータの主URLとして、ストリーミング制御プロトコルのリクエストURLを使用しなければならない。
記述において、RTSPは好適なメソッドとして使用される。他の外部メソッドも可能であることも明らかになろう。ここに記述される実施例は、シグナリングの一部のサンプルを提供しているのみであるが、他の形態における当該シグナリングは依然として本発明の範囲にある。これを理解することで、状況に応じてネットワークのタイプとともにパラメータ名も変わることが明らかになろう。
本発明は上述の実施態様のみに限定されるものではなく、添付の特許請求の範囲内で変更できることは明らかである。
本発明の好適な実施態様による方法を適用することができるシステムを示す。 本発明の好適な実施態様による無線通信装置を縮小したブロック図で示す。 単一のPDPコンテキストによるクライアントに対するQoS予約およびセッション制御のシグナリング図を示す。 複数のPDPコンテキストのサポートによるクライアントに対するQoS予約およびセッション制御のシグナリング図を示す。

Claims (25)

  1. 通信システムにおける方法であって、
    送信通信装置から受信通信装置へ少なくとも一部無線通信ネットワークを介して送信されるべき少なくとも1つのメディアストリームを選択するステップと、
    前記選択された少なくとも1つのメディアストリームを送信するためのQoS要求を定義するステップと、
    前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースを予約するステップと、
    1つのパケットデータ送信接続を開始するために、前記受信通信装置と前記送信通信装置との間に設定プロシージャを実行するステップと、
    前記受信通信装置によって、前記少なくとも1つのメディアストリームの送信開始をリクエストするステップと、
    前記選択された少なくとも1つのメディアストリームを、前記送信通信装置から前記受信通信装置へと送信するステップとを含み、
    前記送信するステップは、前記選択された少なくとも1つのメディアストリームの前記送信において1つのデータ送信コンテキストを使用するステップを含み、前記予約されたリソースに関する情報は、前記少なくとも1つのメディアストリームの送信開始をリクエストするステップの際か、または該ステップ後に、前記送信通信装置へと送信される、方法。
  2. 前記データ送信接続のために、少なくとも、
    ・ 最高ビットレート、
    ・ 保証ビットレート、
    ・ 転送遅延
    のパラメータを定義するステップと、
    前記パラメータを前記送信通信装置に通知するステップとを含む、請求項1に記載の方法。
  3. 前記無線通信ネットワークのタイプに関する情報を、前記受信通信装置によってリクエストされた前記少なくとも1つのメディアストリームの送信開始時に、または開始後に、前記送信通信装置へと送信するステップを含む、請求項1に記載の方法。
  4. 通信システムにおける方法であって、
    送信通信装置から受信通信装置へ少なくとも一部無線通信ネットワークを介して送信されるべき少なくとも1つのメディアストリームを選択するステップと、
    前記選択された少なくとも1つのメディアストリームを送信するためのQoS要求を定義するステップと、
    前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースを予約するステップと、
    少なくとも1つのパケットデータ送信接続を開始するために、前記受信通信装置と前記送信通信装置との間に設定プロシージャを実行するステップと、
    前記受信通信装置によって、前記少なくとも1つのメディアストリームの送信開始をリクエストするステップと、
    前記送信通信装置から受信通信装置へメディアストリームを送信するステップとを含み、
    前記送信するステップは、選択されたメディアストリームのそれぞれに1つのデータ送信コンテキストを使用するステップを含み、予約された前記リソースに関する情報は、前記設定プロシージャに関連して前記送信通信装置へと送信される、方法。
  5. メディアストリームが送信通信装置から受信通信装置へ少なくとも一部無線通信ネットワークを介して送信される、通信システムにおける方法であって、前記受信通信装置へ送信されるべき少なくとも1つのメディアストリームが選択され、前記選択された少なくとも1つのメディアストリームを送信するための前記無線通信ネットワークのタイプが定義され、前記少なくとも1つのメディアストリームの前記送信のために前記無線通信ネットワークから送信リソースが予約され、1つのパケットデータ送信接続を開始するために前記受信通信装置と前記送信通信装置との間に設定プロシージャが実行され、前記受信通信装置によって前記少なくとも1つのメディアストリームの送信開始がリクエストされ、前記選択された少なくとも1つのメディアストリームの前記送信において1つのデータ送信コンテキストが使用され、前記無線通信ネットワークのタイプに関する情報は、前記受信通信装置によってリクエストされた前記少なくとも1つのメディアストリームの送信開始時または開始後に前記送信通信装置へと送信される、通信システムにおける方法。
  6. 前記無線通信ネットワークのタイプを定義するための少なくとも1つのパラメータは、前記データ送信接続のために定義される、請求項5に記載の方法。
  7. 少なくともネットワーク規格、ネットワークのタイプ、およびネットワークのリリースに関する情報が定義される、請求項6に記載の方法。
  8. 通信システムにおける方法であって、
    受信通信装置によって、送信通信装置から前記受信通信装置へ少なくとも一部無線通信ネットワークを介して少なくとも1つのメディアストリームを送信するためのQoS要求に関する情報をリクエストするステップと、
    前記受信通信装置によって、前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースをリクエストするステップと、
    前記無線通信ネットワークによって、前記送信のためのリソースを予約し、前記予約されたリソースに関する情報を前記受信通信装置へと送信するステップと、
    前記受信通信装置および前記送信通信装置によって、前記1つのパケットデータ送信接続を開始するために、設定プロシージャを実行するステップと、
    前記受信通信装置によって、送信を開始するコマンドを前記送信通信装置へ送信することによって、前記少なくとも1つのメディアストリームの送信開始をリクエストするステップであって、前記コマンドでは、前記予約されたリソースに関する情報も前記送信通信装置へ送信される、送信開始リクエストステップと
    1つのパケットデータ送信接続を使用して、前記送信通信装置から前記受信通信装置へメディアストリームを送信するステップとを含む、方法。
  9. 通信システムにおける方法であって、
    受信通信装置によって、少なくとも1つのパケットデータ送信接続を使用して、送信通信装置から前記受信通信装置へ少なくとも一部無線通信ネットワークを介して少なくとも1つのメディアストリームを送信するためのQoS要求に関する情報をリクエストするステップと、
    前記受信通信装置によって、前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースをリクエストするステップと、
    前記無線通信ネットワークによって、前記送信のためのリソースを予約するステップと、
    前記受信通信装置へ、前記予約されたリソースに関する情報を送信するステップと、
    前記受信通信装置および前記送信通信装置によって、前記少なくとも1つのパケットデータ送信接続を開始するために、設定プロシージャを実行するステップとを含み、
    前記設定プロシージャは、
    前記受信通信装置情報によって、前記送信通信装置へ、前記予約されたリソースに関する情報を送信するステップと、
    前記受信通信装置によって、送信を開始するコマンドを前記送信通信装置へ送信することによって、前記少なくとも1つのメディアストリームの送信開始をリクエストするステップであって、前記コマンドでは、前記予約されたリソースに関する情報が前記送信通信装置へ送信されない、送信開始リクエストステップとを備え、
    前記方法は、前記送信通信装置から前記受信通信装置へメディアストリームを送信するステップをさらに含む、方法。
  10. 送信通信装置から受信通信装置へ少なくとも一部無線通信ネットワークを介してメディアストリームを送信するための手段を有する通信システムであって、
    前記受信通信装置へ送信されるべき少なくとも1つのメディアストリームを選択する手段と、
    前記選択された少なくとも1つのメディアストリームを送信するためのQoS要求を定義する手段と、
    前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースを予約する手段と、
    1つのパケットデータ送信接続を開始するために、前記受信通信装置と前記送信通信装置との間に設定プロシージャを実行する手段と、
    前記受信通信装置によって、前記少なくとも1つのメディアストリームの送信開始をリクエストする手段と、
    前記選択された少なくとも1つのメディアストリームの前記送信において1つのデータ送信コンテキストを使用する手段と、
    前記予約されたリソースに関する情報を、前記受信通信装置によってリクエストされた前記少なくとも1つのメディアストリームの送信開始時または開始後に前記送信通信装置へと送信する手段とをさらに有する、通信システム。
  11. 前記無線通信ネットワークのタイプに関する情報を、前記受信通信装置によってリクエストされた前記少なくとも1つのメディアストリームの送信開始時、または開始後に前記送信通信装置へと送信する手段を有する、請求項10に記載の通信システム。
  12. 少なくとも1つのパケットデータ送信接続を使用して、送信通信装置から受信通信装置へ少なくとも一部無線通信ネットワークを介してメディアストリームを送信するための手段を有する通信システムであって、
    前記受信通信装置へ送信されるべき少なくとも1つのメディアストリームを選択する手段と、
    前記選択された少なくとも1つのメディアストリームを送信するためのQoS要求を定義する手段と、
    前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースを予約する手段と、
    前記少なくとも1つのパケットデータ送信接続を開始するために、前記受信通信装置と前記送信通信装置との間に設定プロシージャを実行する手段と、
    前記受信通信装置によって、前記少なくとも1つのメディアストリームの送信開始をリクエストする手段と、
    前記選択された少なくとも1つのメディアストリームの前記送信において1つのデータ送信コンテキストを使用する手段と、
    予約された前記リソースに関する情報を、前記設定プロシージャに関連して前記送信通信装置へと送信する手段とをさらに有する、通信システム。
  13. 前記データ送信接続のために、少なくとも、
    ・ 最高ビットレート、
    ・ 保証ビットレート、および
    ・ 転送遅延
    のパラメータを定義する手段を有する、請求項12に記載の通信システム。
  14. 前記無線通信ネットワークのタイプに関する情報を、前記受信通信装置によってリクエストされた前記少なくとも1つのメディアストリームの送信開始時または開始後に前記送信通信装置へと送信する手段を有する、請求項12に記載の通信システム。
  15. 少なくとも1つのメディアストリームの送信のために、前記無線通信ネットワークから送信リソースを予約するためのリクエストを受信する手段と、
    少なくとも1つのメディアストリームの前記送信のために、リソースを予約する手段と、
    前記少なくとも1つのメディアストリームを前記受信通信装置へ送信するための送信機であって、前記少なくとも1つのパケットデータ送信接続を起動するために、前記受信通信装置と前記送信通信装置との間の設定プロシージャに関連して設定メッセージを送信するように構成された送信機と、
    前記選択された少なくとも1つのメディアストリームの前記送信において1つのデータ送信コンテキストを使用する手段と、
    前記設定プロシージャに関連して前記無線通信ネットワークから予約された前記送信リソースに関する情報を受信するように構成された受信機とを少なくとも有する、送信通信装置。
  16. 少なくとも1つのパケットデータ送信接続を使用して、送信通信装置から少なくとも一部無線通信ネットワークを介してメディアストリームを受信するための受信機と、
    前記送信通信装置から前記受信通信装置へ送信されるべき少なくとも1つのメディアストリームを選択する手段と、
    前記選択された少なくとも1つのメディアストリームを送信するためのQoS要求を定義する手段と、
    前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースをリクエストする手段と、
    前記少なくとも1つのパケットデータ送信接続を開始するために、前記受信通信装置と前記送信通信装置との間に設定プロシージャを実行する手段と、
    前記予約されたリソースに関する情報を、前記設定プロシージャに関連して前記送信通信装置に送信する手段と、
    前記送信通信装置から前記少なくとも1つのメディアストリームの送信開始をリクエストする手段と、
    前記選択された少なくとも1つのメディアストリームの前記送信において1つのデータ送信コンテキストを使用する手段とを少なくとも有する、受信通信装置。
  17. 少なくとも1つのパケットデータ送信接続を使用して、送信通信装置から少なくとも一部無線通信ネットワークを介してメディアストリームを受信するための受信機と、
    前記送信通信装置から前記無線通信装置へ送信されるべき少なくとも1つのメディアストリームを選択する手段と、
    前記選択された少なくとも1つのメディアストリームを送信するためのQoS要求を定義する手段と、
    前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースをリクエストする手段と、
    前記少なくとも1つのパケットデータ送信接続を開始するために、前記無線通信装置と前記送信通信装置との間に設定プロシージャを実行する手段と、
    前記予約されたリソースに関する情報を、前記設定プロシージャに関連して前記送信通信装置に送信する手段と、
    前記送信通信装置から前記少なくとも1つのメディアストリームの送信開始をリクエストする手段と、
    前記選択された少なくとも1つのメディアストリームの前記送信において1つのデータ送信コンテキストを使用する手段とを少なくとも有する、無線通信装置。
  18. 前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースをリクエストする手段は、設定メッセージを定義する手段を有する、請求項17に記載の無線通信装置。
  19. 前記送信通信装置から前記少なくとも1つのメディアストリームの送信開始をリクエストする手段は、再生メッセージを定義する手段を有する、請求項17に記載の無線通信装置。
  20. リクエストされた前記少なくとも1つのメディアストリームの送信開始時、または開始後に、前記送信通信手段へ前記無線通信ネットワークに関する情報を送信する手段を有する、請求項17に記載の無線通信装置。
  21. 少なくとも1つのパケットデータ送信接続を使用して、少なくとも一部無線通信ネットワークを介して受信通信装置へ送信されるべき少なくとも1つのメディアストリームの選択に関する情報を受信する手段と、
    前記選択された少なくとも1つのメディアストリームを送信するためのQoS要求を受信する手段と、
    前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースをリクエストする手段と、
    前記選択された少なくとも1つのメディアストリームを前記受信通信装置へ送信するための送信機であって、前記少なくとも1つのパケットデータ送信接続を起動するために、前記受信通信装置と前記ネットワーク要素との間の設定プロシージャに関連して設定メッセージを送信するように構成された送信機と、
    前記選択された少なくとも1つのメディアストリームの前記送信において1つのデータ送信コンテキストを使用する手段と、
    前記設定プロシージャに関連して前記無線通信ネットワークから予約された前記送信リソースに関する情報を受信するように構成された受信機とを少なくとも有する、ネットワーク要素。
  22. メディアストリームが、送信通信装置から受信通信装置へ少なくとも一部無線通信ネットワークを介して送信される、通信システムにおける方法であって、前記受信通信装置へ送信されるべき少なくとも1つのメディアストリームが選択され、前記選択された少なくとも1つのメディアストリームを送信するために、QoS要求が定義され、前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースが予約され、1つのパケットデータ送信接続を開始するために、前記受信通信装置と前記送信通信装置との間に設定プロシージャが実行され、前記受信通信装置によって前記少なくとも1つのメディアストリームの送信開始がリクエストされ、前記選択された少なくとも1つのメディアストリームの前記送信において1つのデータ送信コンテキストが使用され、前記予約されたリソースに関する情報は、前記受信通信装置によってリクエストされた前記少なくとも1つのメディアストリームの送信開始時、または開始後に前記送信通信装置へ送信される、通信システムにおける方法。
  23. メディアストリームが、送信通信装置から受信通信装置へ少なくとも一部無線通信ネットワークを介して送信される、通信システムにおける方法であって、前記受信通信装置へ送信すべき少なくとも1つのメディアストリームが選択され、前記選択された少なくとも1つのメディアストリームを送信するために、QoS要求が定義され、前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースが予約され、少なくとも1つのパケットデータ送信接続を開始するために、前記受信通信装置と前記送信通信装置との間に設定プロシージャが実行され、前記受信通信装置によって前記少なくとも1つのメディアストリームの送信開始がリクエストされ、選択されたメディアストリームのそれぞれに対して、1つのデータ送信コンテキストが使用され、前記予約されたリソースに関する情報は、前記設定プロシージャに関連して前記送信通信装置に送信される、通信システムにおける方法。
  24. メディアストリームが、1つのパケットデータ送信接続を使用して送信通信装置から受信通信装置へ少なくとも一部無線通信ネットワークを介して送信される、通信システムにおける方法であって、前記受信通信装置は、前記送信通信装置から前記受信通信装置へ少なくとも1つのメディアストリームを送信するためのQoS要求に関する情報をリクエストし、前記受信通信装置は、前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースをリクエストし、前記無線通信ネットワークは、前記送信のためのリソースを予約し、また、前記予約されたリソースに関する情報を前記受信通信装置へと送信し、前記受信通信装置および前記送信通信装置は、前記1つのパケットデータ送信接続を開始するために、設定プロシージャを実行し、前記受信通信装置は、送信を開始するコマンドを前記送信通信装置へ送信することによって、前記少なくとも1つのメディアストリームの送信開始をリクエストし、前記コマンドでは、前記予約されたリソースに関する情報も前記送信通信装置へと送信される、通信システムにおける方法。
  25. メディアストリームが、少なくとも1つのパケットデータ送信接続を使用して送信通信装置から受信通信装置へ少なくとも一部無線通信ネットワークを介して送信される、通信システムにおける方法であって、前記受信通信装置は、前記送信通信装置から前記受信通信装置へ少なくとも1つのメディアストリームを送信するためのQoS要求に関する情報をリクエストし、前記受信通信装置は、前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースをリクエストし、前記無線通信ネットワークは、前記送信のためのリソースを予約し、また、前記予約されたリソースに関する情報を前記受信通信装置へと送信し、前記受信通信装置および前記送信通信装置は、前記少なくとも1つのパケットデータ送信接続を開始するために、設定プロシージャを実行し、前記設定プロシージャにおいて、前記受信通信装置は、前記予約されたリソースに関する情報も前記送信通信装置へと送信し、前記受信通信装置は、送信を開始するコマンドを前記送信通信装置へ送信することによって、前記少なくとも1つのメディアストリームの送信開始をリクエストし、前記コマンドでは、前記予約されたリソースに関する情報が前記送信通信装置へ送信されない、通信システムにおける方法。
JP2007502105A 2004-03-04 2005-03-03 通信システムにおける方法、通信システム、および通信装置 Pending JP2007526727A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US55044304P 2004-03-04 2004-03-04
US10/876,262 US7701915B2 (en) 2003-06-27 2004-06-24 Method in a communication system, a communication system and a communication device
PCT/US2005/007518 WO2005088919A2 (en) 2004-03-04 2005-03-03 Method in a communication system to allocate resources

Publications (1)

Publication Number Publication Date
JP2007526727A true JP2007526727A (ja) 2007-09-13

Family

ID=34970486

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007502105A Pending JP2007526727A (ja) 2004-03-04 2005-03-03 通信システムにおける方法、通信システム、および通信装置

Country Status (9)

Country Link
US (2) US7701915B2 (ja)
EP (1) EP1721427B1 (ja)
JP (1) JP2007526727A (ja)
KR (1) KR100855610B1 (ja)
AT (1) ATE417439T1 (ja)
AU (1) AU2005222356B2 (ja)
DE (1) DE602005011578D1 (ja)
ES (1) ES2315876T3 (ja)
WO (1) WO2005088919A2 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012507223A (ja) * 2008-10-31 2012-03-22 テレフオンアクチーボラゲット エル エム エリクソン（パブル） ポリシー及び課金制御方法、サーバ、及びコンピュータプログラム
JP2013524724A (ja) * 2010-04-13 2013-06-17 クアルコム，インコーポレイテッド ワイヤレス通信システム内でのストリーミング通信セッション中における物理レイヤネットワーク間の選択的遷移
JP2014534681A (ja) * 2011-10-05 2014-12-18 アルカテル−ルーセント リソースのレート適応型割り当てのための方法およびシステム

Families Citing this family (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106419746B (zh) * 2016-11-03 2019-02-15 江苏美的清洁电器股份有限公司 尘杯和具有其的尘杯组件、手持吸尘器
US7701915B2 (en) * 2003-06-27 2010-04-20 Nokia Corporation Method in a communication system, a communication system and a communication device
US7450723B2 (en) * 2004-11-12 2008-11-11 International Business Machines Corporation Method and system for providing for security in communication
US20060184676A1 (en) * 2005-02-16 2006-08-17 Murata Kikai Kabushiki Kaisha Image communication device
CN100397948C (zh) * 2005-03-11 2008-06-25 上海华为技术有限公司 移动通信系统中预留资源激活方法
US20070115926A1 (en) * 2005-10-27 2007-05-24 3Com Corporation System and method for receiving a user message at a packet-network telephone
US8014389B2 (en) * 2005-12-06 2011-09-06 Lippershy Celestial Llc Bidding network
US8953596B2 (en) * 2006-01-06 2015-02-10 Qualcomm Incorporated Conserving network capacity by releasing QoS resources
US8291102B2 (en) * 2006-03-31 2012-10-16 Alcatel Lucent Method and apparatus for improved multicast streaming in wireless networks
US8139593B2 (en) 2006-03-31 2012-03-20 Qualcomm Incorporated Memory management for high speed media access control
CN100423596C (zh) * 2006-06-16 2008-10-01 丰达软件（苏州）有限公司 手机生成、发送、接收流媒体的方法
US8849297B2 (en) 2006-07-14 2014-09-30 Qualcomm Incorporated Call establishment and maintenance in a wireless network
US7920522B2 (en) * 2006-09-29 2011-04-05 Qualcomm Incorporated Method and apparatus for system interoperability in wireless communications
JP5012044B2 (ja) * 2007-01-26 2012-08-29 日本電気株式会社 コンテンツ配信システム、コンテンツ配信方法及びプログラム
US8190750B2 (en) * 2007-08-24 2012-05-29 Alcatel Lucent Content rate selection for media servers with proxy-feedback-controlled frame transmission
JP5012397B2 (ja) * 2007-10-16 2012-08-29 日本電気株式会社 通信システム、方法、装置、およびプログラム
WO2010058241A1 (en) * 2008-11-24 2010-05-27 Abb Research Ltd. A system and a method for providing control and automation services
CN102257783B (zh) 2008-12-17 2015-12-09 艾利森电话股份有限公司 用于在移动通信网络中提供聊天/VoIP服务的方法以及网络服务器和移动用户设备
TW201121344A (en) * 2009-06-15 2011-06-16 Qualcomm Inc Radio access network control of multimedia application data rates
US11277598B2 (en) * 2009-07-14 2022-03-15 Cable Television Laboratories, Inc. Systems and methods for network-based media processing
US8743711B2 (en) * 2009-12-15 2014-06-03 Intel Corporation Techniques for managing heterogeneous traffic streams
US20110161836A1 (en) * 2009-12-31 2011-06-30 Ruicao Mu System for processing and synchronizing large scale video conferencing and document sharing
CN102158911A (zh) * 2010-02-11 2011-08-17 华为技术有限公司 机器对机器业务的承载建立方法及网络传输设备
US8441962B1 (en) * 2010-04-09 2013-05-14 Sprint Spectrum L.P. Method, device, and system for real-time call announcement
WO2011131211A1 (en) * 2010-04-19 2011-10-27 Telefonaktiebolaget L M Ericsson (Publ) Pre-scheduling of quality of service reservation
JP5512889B2 (ja) * 2010-07-08 2014-06-04 マニパル ユニバーシティ モバイルネットワークにおけるマルチメディアサービスの配信
US9565318B2 (en) * 2010-10-14 2017-02-07 T-Mobile Usa, Inc. Quality of service adjustments to improve network utilization
US8589509B2 (en) * 2011-01-05 2013-11-19 Cloudium Systems Limited Controlling and optimizing system latency
US8886699B2 (en) 2011-01-21 2014-11-11 Cloudium Systems Limited Offloading the processing of signals
US9014170B2 (en) 2011-02-11 2015-04-21 Interdigital Patent Holdings, Inc. Method and apparatus for synchronizing mobile station media flows during a collaborative session
WO2013057315A2 (en) 2011-10-21 2013-04-25 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Resource management concept
DE102011088884A1 (de) 2011-12-16 2013-06-20 Siemens Aktiengesellschaft Verfahren zur Übertragung von Daten in einem Kommunikationsnetz
US9179169B2 (en) 2012-03-14 2015-11-03 Imagine Communications Corp. Adaptive media delivery
US9306994B2 (en) * 2012-06-06 2016-04-05 Cisco Technology, Inc. Stabilization of adaptive streaming video clients through rate limiting
US8843656B2 (en) 2012-06-12 2014-09-23 Cisco Technology, Inc. System and method for preventing overestimation of available bandwidth in adaptive bitrate streaming clients
US9402114B2 (en) 2012-07-18 2016-07-26 Cisco Technology, Inc. System and method for providing randomization in adaptive bitrate streaming environments
US9516078B2 (en) 2012-10-26 2016-12-06 Cisco Technology, Inc. System and method for providing intelligent chunk duration
CN103905378B (zh) * 2012-12-25 2017-04-12 华为技术有限公司 一种传输数据的方法及装置
EP2962462A4 (en) * 2013-07-24 2016-04-06 Huawei Tech Co Ltd SYSTEM AND METHOD FOR NETWORK ASSISTED CONTINUOUS ADAPTIVE BROADCAST
US9699500B2 (en) * 2013-12-13 2017-07-04 Qualcomm Incorporated Session management and control procedures for supporting multiple groups of sink devices in a peer-to-peer wireless display system
US9363814B2 (en) 2014-02-25 2016-06-07 Alcatel Lucent Rate allocation method and apparatus for optimization of adaptive wireless video streaming
WO2018031614A1 (en) * 2016-08-11 2018-02-15 Kyocera Corporation Ran-assisted rate adaptation

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2724084B1 (fr) 1994-08-31 1997-01-03 Alcatel Mobile Comm France Systeme de transmission d'informations par un canal de transmission variant dans le temps, et equipements d'emission et de reception correspondants
US6125136A (en) 1997-12-31 2000-09-26 Sony Corporation Method and apparatus for demodulating trellis coded direct sequence spread spectrum communication signals
JP2000032048A (ja) * 1998-07-14 2000-01-28 Fujitsu Ltd ネットワーク装置
US6487255B1 (en) 1998-08-31 2002-11-26 Ericsson Inc. Information generation for coherent demodulation of differentially encoded signals
US6404746B1 (en) * 1999-07-13 2002-06-11 Intervoice Limited Partnership System and method for packet network media redirection
FI114371B (fi) 1999-08-09 2004-09-30 Nokia Corp Menetelmä kantopalvelun valitsemiseksi palvelulle langattomassa matkaviestinjärjestelmässä, tiedonsiirtojärjestelmä ja matkaviestinpäätelaite
KR20010017931A (ko) * 1999-08-16 2001-03-05 박종섭 동기 통신 시스템에서 동기 무선망과 연결되는 망 인터페이스 방법
US7054938B2 (en) * 2000-02-10 2006-05-30 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for network service reservations over wireless access networks
US6477150B1 (en) * 2000-03-03 2002-11-05 Qualcomm, Inc. System and method for providing group communication services in an existing communication system
US6597919B1 (en) * 2000-06-23 2003-07-22 Motorola, Inc. Optimal radio channel allocation in a distributed connection and transport network
US7254605B1 (en) * 2000-10-26 2007-08-07 Austen Services Llc Method of modulating the transmission frequency in a real time opinion research network
US7546376B2 (en) * 2000-11-06 2009-06-09 Telefonaktiebolaget Lm Ericsson (Publ) Media binding to coordinate quality of service requirements for media flows in a multimedia session with IP bearer resources
US20030172160A9 (en) * 2001-01-10 2003-09-11 Widegren Ina B. Method and apparatus for coordinating end-to-end quality of service requirements for media flows in a multimedia session
US7106718B2 (en) * 2001-02-09 2006-09-12 Telefonaktiebolaget Lm Ericsson (Publ) Signaling quality of service class for use in multimedia communicatations
EP1248431B1 (en) * 2001-03-27 2007-10-31 Sony Deutschland GmbH Method for achieving end-to-end quality of service negotiation for distributed multimedia applications
US7054945B2 (en) * 2001-04-09 2006-05-30 Nokia Corporation Technique for providing announcements in mobile-originated calls
US7218626B2 (en) * 2001-05-29 2007-05-15 Interdigital Technology Corporation System and method for reducing information communicated between universal mobile telecommunication system multimedia capable units
ITRM20010421A1 (it) 2001-07-13 2003-01-13 Univ Roma Metodo di elezione dinamica del controllore tra gli elaboratori o stazioni di una rete mobile in area locale senza fili, o wlan (wireless lo
US7227865B2 (en) * 2001-08-16 2007-06-05 Interdigital Technology Corporation Utilizing session initiation protocol for identifying user equipment resource reservation setup protocol capabilities
TW582155B (en) * 2001-11-02 2004-04-01 Interdigital Tech Corp Bi-directional and reverse directional resource reservation setup protocol
EP1326380B1 (en) * 2002-01-08 2006-04-12 Telefonaktiebolaget LM Ericsson (publ) Network selection for connectivity
JP2003304523A (ja) * 2002-02-08 2003-10-24 Ntt Docomo Inc 情報配信システム、情報配信方法、情報配信サーバ、コンテンツ配信サーバ及び端末
GB2386283A (en) * 2002-03-05 2003-09-10 Pa Consulting Services Packet data communications network
US7206324B2 (en) * 2002-05-03 2007-04-17 Telefonaktiebolaget Lm Ericsson (Publ) QoS translator
US7451229B2 (en) * 2002-06-24 2008-11-11 Microsoft Corporation System and method for embedding a streaming media format header within a session description message
US20040028055A1 (en) * 2002-07-26 2004-02-12 Lila Madour Differentiated accounting in a packet data network
US8161158B2 (en) * 2002-09-25 2012-04-17 Nokia Corporation Method in a communication system, a communication system and a communication device
US7701915B2 (en) * 2003-06-27 2010-04-20 Nokia Corporation Method in a communication system, a communication system and a communication device

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012507223A (ja) * 2008-10-31 2012-03-22 テレフオンアクチーボラゲット エル エム エリクソン（パブル） ポリシー及び課金制御方法、サーバ、及びコンピュータプログラム
JP2013524724A (ja) * 2010-04-13 2013-06-17 クアルコム，インコーポレイテッド ワイヤレス通信システム内でのストリーミング通信セッション中における物理レイヤネットワーク間の選択的遷移
JP2014534681A (ja) * 2011-10-05 2014-12-18 アルカテル−ルーセント リソースのレート適応型割り当てのための方法およびシステム

Also Published As

Publication number Publication date
KR20060122978A (ko) 2006-11-30
KR100855610B1 (ko) 2008-09-01
US20050025180A1 (en) 2005-02-03
US7701915B2 (en) 2010-04-20
US20050232148A1 (en) 2005-10-20
WO2005088919A3 (en) 2005-10-20
ATE417439T1 (de) 2008-12-15
AU2005222356A1 (en) 2005-09-22
DE602005011578D1 (de) 2009-01-22
EP1721427A2 (en) 2006-11-15
ES2315876T3 (es) 2009-04-01
WO2005088919A2 (en) 2005-09-22
AU2005222356B2 (en) 2009-08-06
EP1721427B1 (en) 2008-12-10

Similar Documents

Publication Publication Date Title
EP1721427B1 (en) Method to allocate resources in a communication system
KR100731963B1 (ko) 네트워크에서 ＱｏＳ 프로파일 파라미터를 통지 및부여하는 방법, 시스템 및 통신 장치
KR100752608B1 (ko) 무선통신네트워크에서 자원 예약을 위한 방법 및 시스템
JP4927333B2 (ja) 帯域幅適応
US20150103653A1 (en) Conserving network capacity by releasing qos resources
EP1878295A1 (en) Signaling quality of service (qos) parameters for a multimedia session
US20070223491A1 (en) Apparatus and method for providing quality of service in wireless communication system
CA2632126A1 (en) Method and devices for specifying the quality of service in a transmission of data packets
JP2009124763A (ja) 無線パケットベースの通信を確立するための方法
EP1552655A1 (en) Bandwidth adaptation
KR100541523B1 (ko) 이동통신망에서 멀티미디어 콘텐츠 제공을 위한 채널 제어방법
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: 20090528

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090611

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20091106