(57)【要約】本発明は、通信システムにおける方法、通信システム、および通信装置に関する。本方法において、メディアストリームは、送信通信装置から受信通信装置へ少なくとも一部無線通信ネットワークを介して送信される。受信通信装置へ送信されるべき少なくとも1つのメディアストリームが選択され、選択された少なくとも1つのメディアストリームを送信するためのQoS要求が定義され、少なくとも1つのメディアストリームの送信のために、前記無線通信ネットワークから送信リソースが予約され、1つのパケットデータ送信接続を開始するために、受信通信装置と送信通信装置との間に設定プロシージャが実行される。【選択図】図１
2007526727.tif 000002
【特許請求の範囲】
【請求項１】
通信システムにおける方法であって、
送信通信装置から受信通信装置へ少なくとも一部無線通信ネットワークを介して送信されるべき少なくとも1つのメディアストリームを選択するステップと、
前記選択された少なくとも1つのメディアストリームを送信するためのQoS要求を定義するステップと、
前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースを予約するステップと、
1つのパケットデータ送信接続を開始するために、前記受信通信装置と前記送信通信装置との間に設定プロシージャを実行するステップと、
前記受信通信装置によって、前記少なくとも1つのメディアストリームの送信開始をリクエストするステップと、
前記選択された少なくとも1つのメディアストリームを、前記送信通信装置から前記受信通信装置へと送信するステップとを含み、
前記送信するステップは、前記選択された少なくとも1つのメディアストリームの前記送信において1つのデータ送信コンテキストを使用するステップを含み、前記予約されたリソースに関する情報は、前記少なくとも1つのメディアストリームの送信開始をリクエストするステップの際か、または該ステップ後に、前記送信通信装置へと送信される、方法。
【請求項２】
前記データ送信接続のために、少なくとも、
・  最高ビットレート、
・  保証ビットレート、
・  転送遅延
のパラメータを定義するステップと、
前記パラメータを前記送信通信装置に通知するステップとを含む、請求項1に記載の方法。
【請求項３】
前記無線通信ネットワークのタイプに関する情報を、前記受信通信装置によってリクエストされた前記少なくとも1つのメディアストリームの送信開始時に、または開始後に、前記送信通信装置へと送信するステップを含む、請求項1に記載の方法。
【請求項４】
通信システムにおける方法であって、
送信通信装置から受信通信装置へ少なくとも一部無線通信ネットワークを介して送信されるべき少なくとも1つのメディアストリームを選択するステップと、
前記選択された少なくとも1つのメディアストリームを送信するためのQoS要求を定義するステップと、
前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースを予約するステップと、
少なくとも1つのパケットデータ送信接続を開始するために、前記受信通信装置と前記送信通信装置との間に設定プロシージャを実行するステップと、
前記受信通信装置によって、前記少なくとも1つのメディアストリームの送信開始をリクエストするステップと、
前記送信通信装置から受信通信装置へメディアストリームを送信するステップとを含み、
前記送信するステップは、選択されたメディアストリームのそれぞれに1つのデータ送信コンテキストを使用するステップを含み、予約された前記リソースに関する情報は、前記設定プロシージャに関連して前記送信通信装置へと送信される、方法。
【請求項５】
メディアストリームが送信通信装置から受信通信装置へ少なくとも一部無線通信ネットワークを介して送信される、通信システムにおける方法であって、前記受信通信装置へ送信されるべき少なくとも1つのメディアストリームが選択され、前記選択された少なくとも1つのメディアストリームを送信するための前記無線通信ネットワークのタイプが定義され、前記少なくとも1つのメディアストリームの前記送信のために前記無線通信ネットワークから送信リソースが予約され、1つのパケットデータ送信接続を開始するために前記受信通信装置と前記送信通信装置との間に設定プロシージャが実行され、前記受信通信装置によって前記少なくとも1つのメディアストリームの送信開始がリクエストされ、前記選択された少なくとも1つのメディアストリームの前記送信において1つのデータ送信コンテキストが使用され、前記無線通信ネットワークのタイプに関する情報は、前記受信通信装置によってリクエストされた前記少なくとも1つのメディアストリームの送信開始時または開始後に前記送信通信装置へと送信される、通信システムにおける方法。
【請求項６】
前記無線通信ネットワークのタイプを定義するための少なくとも1つのパラメータは、前記データ送信接続のために定義される、請求項5に記載の方法。
【請求項７】
少なくともネットワーク規格、ネットワークのタイプ、およびネットワークのリリースに関する情報が定義される、請求項6に記載の方法。
【請求項８】
通信システムにおける方法であって、
受信通信装置によって、送信通信装置から前記受信通信装置へ少なくとも一部無線通信ネットワークを介して少なくとも1つのメディアストリームを送信するためのQoS要求に関する情報をリクエストするステップと、
前記受信通信装置によって、前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースをリクエストするステップと、
前記無線通信ネットワークによって、前記送信のためのリソースを予約し、前記予約されたリソースに関する情報を前記受信通信装置へと送信するステップと、
前記受信通信装置および前記送信通信装置によって、前記1つのパケットデータ送信接続を開始するために、設定プロシージャを実行するステップと、
前記受信通信装置によって、送信を開始するコマンドを前記送信通信装置へ送信することによって、前記少なくとも1つのメディアストリームの送信開始をリクエストするステップであって、前記コマンドでは、前記予約されたリソースに関する情報も前記送信通信装置へ送信される、送信開始リクエストステップと
1つのパケットデータ送信接続を使用して、前記送信通信装置から前記受信通信装置へメディアストリームを送信するステップとを含む、方法。
【請求項９】
通信システムにおける方法であって、
受信通信装置によって、少なくとも1つのパケットデータ送信接続を使用して、送信通信装置から前記受信通信装置へ少なくとも一部無線通信ネットワークを介して少なくとも1つのメディアストリームを送信するためのQoS要求に関する情報をリクエストするステップと、
前記受信通信装置によって、前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースをリクエストするステップと、
前記無線通信ネットワークによって、前記送信のためのリソースを予約するステップと、
前記受信通信装置へ、前記予約されたリソースに関する情報を送信するステップと、
前記受信通信装置および前記送信通信装置によって、前記少なくとも1つのパケットデータ送信接続を開始するために、設定プロシージャを実行するステップとを含み、
前記設定プロシージャは、
前記受信通信装置情報によって、前記送信通信装置へ、前記予約されたリソースに関する情報を送信するステップと、
前記受信通信装置によって、送信を開始するコマンドを前記送信通信装置へ送信することによって、前記少なくとも1つのメディアストリームの送信開始をリクエストするステップであって、前記コマンドでは、前記予約されたリソースに関する情報が前記送信通信装置へ送信されない、送信開始リクエストステップとを備え、
前記方法は、前記送信通信装置から前記受信通信装置へメディアストリームを送信するステップをさらに含む、方法。
【請求項１０】
送信通信装置から受信通信装置へ少なくとも一部無線通信ネットワークを介してメディアストリームを送信するための手段を有する通信システムであって、
前記受信通信装置へ送信されるべき少なくとも1つのメディアストリームを選択する手段と、
前記選択された少なくとも1つのメディアストリームを送信するためのQoS要求を定義する手段と、
前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースを予約する手段と、
1つのパケットデータ送信接続を開始するために、前記受信通信装置と前記送信通信装置との間に設定プロシージャを実行する手段と、
前記受信通信装置によって、前記少なくとも1つのメディアストリームの送信開始をリクエストする手段と、
前記選択された少なくとも1つのメディアストリームの前記送信において1つのデータ送信コンテキストを使用する手段と、
前記予約されたリソースに関する情報を、前記受信通信装置によってリクエストされた前記少なくとも1つのメディアストリームの送信開始時または開始後に前記送信通信装置へと送信する手段とをさらに有する、通信システム。
【請求項１１】
前記無線通信ネットワークのタイプに関する情報を、前記受信通信装置によってリクエストされた前記少なくとも1つのメディアストリームの送信開始時、または開始後に前記送信通信装置へと送信する手段を有する、請求項10に記載の通信システム。
【請求項１２】
少なくとも1つのパケットデータ送信接続を使用して、送信通信装置から受信通信装置へ少なくとも一部無線通信ネットワークを介してメディアストリームを送信するための手段を有する通信システムであって、
前記受信通信装置へ送信されるべき少なくとも1つのメディアストリームを選択する手段と、
前記選択された少なくとも1つのメディアストリームを送信するためのQoS要求を定義する手段と、
前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースを予約する手段と、
前記少なくとも1つのパケットデータ送信接続を開始するために、前記受信通信装置と前記送信通信装置との間に設定プロシージャを実行する手段と、
前記受信通信装置によって、前記少なくとも1つのメディアストリームの送信開始をリクエストする手段と、
前記選択された少なくとも1つのメディアストリームの前記送信において1つのデータ送信コンテキストを使用する手段と、
予約された前記リソースに関する情報を、前記設定プロシージャに関連して前記送信通信装置へと送信する手段とをさらに有する、通信システム。
【請求項１３】
前記データ送信接続のために、少なくとも、
・  最高ビットレート、
・  保証ビットレート、および
・  転送遅延
のパラメータを定義する手段を有する、請求項12に記載の通信システム。
【請求項１４】
前記無線通信ネットワークのタイプに関する情報を、前記受信通信装置によってリクエストされた前記少なくとも1つのメディアストリームの送信開始時または開始後に前記送信通信装置へと送信する手段を有する、請求項12に記載の通信システム。
【請求項１５】
少なくとも1つのメディアストリームの送信のために、前記無線通信ネットワークから送信リソースを予約するためのリクエストを受信する手段と、
少なくとも1つのメディアストリームの前記送信のために、リソースを予約する手段と、
前記少なくとも1つのメディアストリームを前記受信通信装置へ送信するための送信機であって、前記少なくとも1つのパケットデータ送信接続を起動するために、前記受信通信装置と前記送信通信装置との間の設定プロシージャに関連して設定メッセージを送信するように構成された送信機と、
前記選択された少なくとも1つのメディアストリームの前記送信において1つのデータ送信コンテキストを使用する手段と、
前記設定プロシージャに関連して前記無線通信ネットワークから予約された前記送信リソースに関する情報を受信するように構成された受信機とを少なくとも有する、送信通信装置。
【請求項１６】
少なくとも1つのパケットデータ送信接続を使用して、送信通信装置から少なくとも一部無線通信ネットワークを介してメディアストリームを受信するための受信機と、
前記送信通信装置から前記受信通信装置へ送信されるべき少なくとも1つのメディアストリームを選択する手段と、
前記選択された少なくとも1つのメディアストリームを送信するためのQoS要求を定義する手段と、
前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースをリクエストする手段と、
前記少なくとも1つのパケットデータ送信接続を開始するために、前記受信通信装置と前記送信通信装置との間に設定プロシージャを実行する手段と、
前記予約されたリソースに関する情報を、前記設定プロシージャに関連して前記送信通信装置に送信する手段と、
前記送信通信装置から前記少なくとも1つのメディアストリームの送信開始をリクエストする手段と、
前記選択された少なくとも1つのメディアストリームの前記送信において1つのデータ送信コンテキストを使用する手段とを少なくとも有する、受信通信装置。
【請求項１７】
少なくとも1つのパケットデータ送信接続を使用して、送信通信装置から少なくとも一部無線通信ネットワークを介してメディアストリームを受信するための受信機と、
前記送信通信装置から前記無線通信装置へ送信されるべき少なくとも1つのメディアストリームを選択する手段と、
前記選択された少なくとも1つのメディアストリームを送信するためのQoS要求を定義する手段と、
前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースをリクエストする手段と、
前記少なくとも1つのパケットデータ送信接続を開始するために、前記無線通信装置と前記送信通信装置との間に設定プロシージャを実行する手段と、
前記予約されたリソースに関する情報を、前記設定プロシージャに関連して前記送信通信装置に送信する手段と、
前記送信通信装置から前記少なくとも1つのメディアストリームの送信開始をリクエストする手段と、
前記選択された少なくとも1つのメディアストリームの前記送信において1つのデータ送信コンテキストを使用する手段とを少なくとも有する、無線通信装置。
【請求項１８】
前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースをリクエストする手段は、設定メッセージを定義する手段を有する、請求項17に記載の無線通信装置。
【請求項１９】
前記送信通信装置から前記少なくとも1つのメディアストリームの送信開始をリクエストする手段は、再生メッセージを定義する手段を有する、請求項17に記載の無線通信装置。
【請求項２０】
リクエストされた前記少なくとも1つのメディアストリームの送信開始時、または開始後に、前記送信通信手段へ前記無線通信ネットワークに関する情報を送信する手段を有する、請求項17に記載の無線通信装置。
【請求項２１】
少なくとも1つのパケットデータ送信接続を使用して、少なくとも一部無線通信ネットワークを介して受信通信装置へ送信されるべき少なくとも1つのメディアストリームの選択に関する情報を受信する手段と、
前記選択された少なくとも1つのメディアストリームを送信するためのQoS要求を受信する手段と、
前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースをリクエストする手段と、
前記選択された少なくとも1つのメディアストリームを前記受信通信装置へ送信するための送信機であって、前記少なくとも1つのパケットデータ送信接続を起動するために、前記受信通信装置と前記ネットワーク要素との間の設定プロシージャに関連して設定メッセージを送信するように構成された送信機と、
前記選択された少なくとも1つのメディアストリームの前記送信において1つのデータ送信コンテキストを使用する手段と、
前記設定プロシージャに関連して前記無線通信ネットワークから予約された前記送信リソースに関する情報を受信するように構成された受信機とを少なくとも有する、ネットワーク要素。
【請求項２２】
メディアストリームが、送信通信装置から受信通信装置へ少なくとも一部無線通信ネットワークを介して送信される、通信システムにおける方法であって、前記受信通信装置へ送信されるべき少なくとも1つのメディアストリームが選択され、前記選択された少なくとも1つのメディアストリームを送信するために、QoS要求が定義され、前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースが予約され、1つのパケットデータ送信接続を開始するために、前記受信通信装置と前記送信通信装置との間に設定プロシージャが実行され、前記受信通信装置によって前記少なくとも1つのメディアストリームの送信開始がリクエストされ、前記選択された少なくとも1つのメディアストリームの前記送信において1つのデータ送信コンテキストが使用され、前記予約されたリソースに関する情報は、前記受信通信装置によってリクエストされた前記少なくとも1つのメディアストリームの送信開始時、または開始後に前記送信通信装置へ送信される、通信システムにおける方法。
【請求項２３】
メディアストリームが、送信通信装置から受信通信装置へ少なくとも一部無線通信ネットワークを介して送信される、通信システムにおける方法であって、前記受信通信装置へ送信すべき少なくとも1つのメディアストリームが選択され、前記選択された少なくとも1つのメディアストリームを送信するために、QoS要求が定義され、前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースが予約され、少なくとも1つのパケットデータ送信接続を開始するために、前記受信通信装置と前記送信通信装置との間に設定プロシージャが実行され、前記受信通信装置によって前記少なくとも1つのメディアストリームの送信開始がリクエストされ、選択されたメディアストリームのそれぞれに対して、1つのデータ送信コンテキストが使用され、前記予約されたリソースに関する情報は、前記設定プロシージャに関連して前記送信通信装置に送信される、通信システムにおける方法。
【請求項２４】
メディアストリームが、1つのパケットデータ送信接続を使用して送信通信装置から受信通信装置へ少なくとも一部無線通信ネットワークを介して送信される、通信システムにおける方法であって、前記受信通信装置は、前記送信通信装置から前記受信通信装置へ少なくとも1つのメディアストリームを送信するためのQoS要求に関する情報をリクエストし、前記受信通信装置は、前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースをリクエストし、前記無線通信ネットワークは、前記送信のためのリソースを予約し、また、前記予約されたリソースに関する情報を前記受信通信装置へと送信し、前記受信通信装置および前記送信通信装置は、前記1つのパケットデータ送信接続を開始するために、設定プロシージャを実行し、前記受信通信装置は、送信を開始するコマンドを前記送信通信装置へ送信することによって、前記少なくとも1つのメディアストリームの送信開始をリクエストし、前記コマンドでは、前記予約されたリソースに関する情報も前記送信通信装置へと送信される、通信システムにおける方法。
【請求項２５】
メディアストリームが、少なくとも1つのパケットデータ送信接続を使用して送信通信装置から受信通信装置へ少なくとも一部無線通信ネットワークを介して送信される、通信システムにおける方法であって、前記受信通信装置は、前記送信通信装置から前記受信通信装置へ少なくとも1つのメディアストリームを送信するためのQoS要求に関する情報をリクエストし、前記受信通信装置は、前記少なくとも1つのメディアストリームの前記送信のために、前記無線通信ネットワークから送信リソースをリクエストし、前記無線通信ネットワークは、前記送信のためのリソースを予約し、また、前記予約されたリソースに関する情報を前記受信通信装置へと送信し、前記受信通信装置および前記送信通信装置は、前記少なくとも1つのパケットデータ送信接続を開始するために、設定プロシージャを実行し、前記設定プロシージャにおいて、前記受信通信装置は、前記予約されたリソースに関する情報も前記送信通信装置へと送信し、前記受信通信装置は、送信を開始するコマンドを前記送信通信装置へ送信することによって、前記少なくとも1つのメディアストリームの送信開始をリクエストし、前記コマンドでは、前記予約されたリソースに関する情報が前記送信通信装置へ送信されない、通信システムにおける方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術領域はモバイルネットワーク上のストリーミングメディアであり、マルチメディアサーバや、モバイルネットワーク、ストリーミングクライアントが、例えば、セッションの設定および制御に使用される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に簡潔に示す。
【表１】
2007526727.tif 000003
【０００８】
保証ビットレートはアドミッション制御およびリソース予約のために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予約およびセッション制御のシグナリング図を示す。
【図１】
2007526727.tif 000004
【図２】
2007526727.tif 000005
【図３】
2007526727.tif 000006
【図４】
2007526727.tif 000007
【国際調査報告】
2007526727.tif 000008
2007526727.tif 000009
2007526727.tif 000010