(57)【特許請求の範囲】
【請求項１】
ＩＰネットワークが前記ＩＰネットワークに接続されるリソース予約プロキシ及びアクセスノード（７０６）を介してターミナル（７０３）に接続され、
前記ＩＰネットワークがさらに、終端ノード（７０４）に接続され、
前記ＩＰネットワークと前記プロキシ（７０５）がリソース予約プロトコルを使用する、ＩＰネットワーク（７０２）に接続されたアプリケーションレベルサーバ（７０１）であって、
サーバ（７０１）がターミナル（７０３）と終端ノード（７０４）間にサービス品質を確立するリソース予約を管理することと、
サーバ（７０１）が機能的構成要素（７０７）を含むことと、
機能的構成要素（７０７）がターミナル（７０３）に対してリソース予約プロトコルを有していてもそれを使用しないように指示する手段（７０９）を有することと、
機能的構成要素（７０７）がさらにリソース予約を実施するのに要求される必須のパラメータを識別する手段（７０８）を有することと、
機能的構成要素（７０７）が、リソース予約シグナリングがアクセスノードから終端ノードに向けて適用されることを示すように、シグナリングメッセージを変更する手段（７１０）をさらに有することと、
機能的構成要素（７０７）がさらにプロキシ（７０５）とＩＰレベル上の終端ノード（７０４）間に必須のパラメータに準拠した特定のサービス品質をプロキシ（７０５）から要求する手段（７１１）をさらに有することとを特徴とするアプリケーションレベルサーバ（７０１）。
【請求項２】
リソース予約プロトコルがリソースリザベーションプロトコル(Resource Reservation Protocol)（ＲＳＶＰ）であり、よってリソース予約プロキシはＲＳＶＰプロキシであることを特徴とする請求項１に記載のアプリケーションレベルサーバ（７０１）。
【請求項３】
機能的構成要素（７０７）が、サーバ（７０１）からターミナル（７０３）へ送られるＨ．２２５／ＲＡＳのＡＣＦシグナリングメッセージにおいて、リソース予約プロトコルを使用しないように、ターミナル（７０３）に指示する手段（７０９）を有することを特徴とする請求項２に記載のアプリケーションレベルサーバ（７０１）。
【請求項４】
必須パラメータの１つが、サービス品質モード、サービス品質情報、または、終端ノード（７０４）への入力メディアストリームの受信のために終端ノード（７０４）により使用されるポートのポートＩＤであることを特徴とする請求項１に記載のアプリケーションレベルサーバ（７０１）。
【請求項５】
機能的構成要素（７０７）は、ターミナル（７０３）から終端ノード（７０４）に送られたシグナリングメッセージの指示内容を、「サービス品質実現不可能」から「サービス品質可能」に変更する手段（７１０）を有することを特徴とする請求項１に記載のアプリケーションレベルサーバ（７０１）。
【請求項６】
機能的構成要素（７０７）は、終端ノード（７０４）からターミナル（７０３）に送られるシグナリングメッセージの指示内容を、「サービス品質実現可能」から「サービス品質不可能」に変更する手段（７１０）を有することを特徴とする請求項１に記載のアプリケーションレベルサーバ（７０１）。
【請求項７】
プロキシ（７０５）と終端ノード（７０４）間のサービス品質の要求は、サーバ（７０１）からプロキシ（７０５）への要求サービス品質メッセージにおいて送信され、前記メッセージは必須パラメータを含むことを特徴とする請求項１に記載のアプリケーションレベルサーバ（７０１）。
【請求項８】
請求項１ないし７のいずれかに記載のアプリケーションレベルサーバ（６０９）とサーバ（６０９）に接続されるＩＰネットワーク（６０７）を含む通信システム（６００）において、
前記サーバ（６０９）が通信システム内の呼をルーティングし、
前記ＩＰネットワーク（６０７）がリソース予約プロトコルを使用し、
前記通信システム（６００）がさらにＩＰネットワークに接続されるリソース予約プロキシ及びアクセスノード（６０３）を介してＩＰネットワーク（６０７）に接続されるターミナル（６０５）を含み、
前記通信システム（６００）がＩＰネットワーク（６０７）に接続される終端ノード（６０８）も含み、
前記通信システム（６００）がさらにターミナル（６０５）とアクセスノード（６０３）間にリンクレベル上の特定のサービス品質を有する、アクセスベアラを確立する手段（６１２）を含む通信システムであって、
アクセスノード（６０３）と終端ノード（６０８）間にＩＰレベル上の特定のサービス品質を確立するためにリソース予約を実施する手段（６１３）を有するリソース予約プロトコルプロキシ（６０２）を含むことを特徴とする通信システム（６００）。
【請求項９】
通信システムがリソース予約プロトコルを使用するＩＰネットワークを含み、
前記通信システムがさらにアクセスノードに接続されるターミナルを含み、前記アクセスノードがリソース予約プロトコルプロキシに接続され、前記プロキシがＩＰネットワークに接続され、
前記ＩＰネットワークが、通話経路の決定とリソース予約の管理を行うアプリケーションレベルサーバに接続される、
通信システム内のターミナルと終端ノード間にエンドツーエンドのサービス品質を確立するためのリソースを予約する方法であって、
アプリケーションレベルサーバが、ターミナルがリソース予約プロトコルを有していてもそれをターミナルに使用させないで、ＩＰレベル上のリソース予約シグナリングを前記プロキシと終端ノード間に適用することを指示する過程（５０１）と、
アプリケーションレベルサーバが、リソース予約を実施するための必須パラメータを識別する過程（５０２）と、
リソース予約プロトコルプロキシを用いて、アプリケーションレベルサーバから伝えられた、アクセスノードと終端ノード間にＩＰレベル上のサービス品質を有するリソース予約を実施する過程（５０３）と、
前記ターミナルと前記アクセスノード間にリンクレベル上のサービス品質を有するアクセスベアラを確立する過程（５０４）と、を含む方法。
【請求項１０】
前記リソース予約シグナリングをプロキシと終端ノード間に適用することを指示する過程（５０１）は、サーバがターミナルから終端ノードに向けて送られたシグナリングメッセージの指示内容を「サービス品質実現不可能」から「サービス品質実現可能」に変更することにより実施される請求項９に記載の方法。
【請求項１１】
前記リソース予約情報をプロキシと終端ノード間に伝達することを指示する過程（５０１）は、サーバが終端ノードからターミナルに向けて送られたシグナリングメッセージの指示内容を「サービス品質実現可能」から「サービス品質実現不可能」に変更することにより実施される請求項９又は１０に記載の方法。
【請求項１２】
サーバが、アクセスノードとターミナル間に必須パラメータに準拠するサービス品質をプロキシから要求する過程をさらに含む請求項９ないし１１のいずれかに記載の方法。
【請求項１３】
前記要求は必須のサービスパラメータを含む要求サービス品質メッセージで送られる請求項１２に記載の方法。
【請求項１４】
リソース予約を実施する過程（５０３）は、プロキシから終端ノードに向けて、必須パラメータを含むＲＳＶＰのPathシグナリングメッセージを送信することによりリソース予約を開始するプロキシにより実施される請求項９ないし１３のいずれかに記載の方法。
【請求項１５】
リソース予約を実施する過程（５０３）は、プロキシを介してターミナルに到達するように終端ノードから送られるリソース予約シグナリングメッセージが、プロキシにより停止され、かつターミナルに転送されない請求項９ないし１４のいずれかに記載の方法。
【請求項１６】
リソース予約を実施する過程（５０３）は、終端ノードから送られてプロキシにより停止される前記リソース予約シグナリングメッセージが、プロトコルから要求されたとき、ターミナルではなくプロキシが終端ノードに向けて送信するリソース予約シグナリングメッセージにより応答されることにより実施される請求項１５に記載の方法。
【請求項１７】
請求項８に記載の通信システムにおける構成要素内のコンピュータに請求項９ないし１６のいずれかに記載の方法の実行を制御させるコンピュータプログラム。
【発明の詳細な説明】
【０００１】
【発明の分野】
発明の分野
本発明はディジタル通信システムのアプリケーションレベルのサーバ、方法及び構成に関係するものである。さらに詳細には、本発明はエンドツーエンドのサービス品質を確立するためのリソース予約に関わるものである。
【０００２】
従来技術
マルチメディア通信は多様な組織及び団体において開発されてきた。パケット対応ネットワークにおけるマルチメディアに対して現在有力な枠組みが国際電気通信連合−通信部(International Telecommunication Union - Telecommunication sector(ITU-T)による勧告Ｈ．３２３及びそれに関連する勧告により規定されている。Ｈ．３２３はマルチメディアの構造及び一連の動作プロトコルを記述している。他のマルチメディア通信の基本構想も存在しており、Multimedia Session Control(MMUSIC)及びSession Initiation Protocol(SIP)、などのワークグループにおいてＩＥＴＦにより開発された、Session Description Protocol(SDP)及びReal Time Streaming Protocol(RTSP)などのプロトコルを使用する構想も同様に適用することができる。
【０００３】
パケットネットワークは一般的にはインターネットプロトコル（ＩＰ）に基づいている。ＩＰネットワークはサービス品質を提供するのにリソース予約又は他のいずれのメカニズムにも対応しない場合がある。実際のリソース予約メカニズムが欠如している場合、受入れ要求、帯域幅の要求などのＨ．３２３手順はさらに認証性を高め、本来のサービス性能を何も保証しない。サービス及び動作が予測可能でそのレベルが保証された、信頼できるサービスを提供するために、サービス品質はアプリケーションニーズに応えてリソースの割当てが可能となるように基本的なＩＰネットワークによって提供される必要がある。
【０００４】
セルラー環境にマルチメディア通信を導入する際は、高いコストが伴うため、無線スペクトルの能率を最適化する必要がある。と同時に、能率化の課題を解決しようとする一方で、一定の品質及びサービス行為を現在のマルチメディアサービスの柔軟性の維持と両立されなければならない。
【０００５】
ＩＰベアラサービス品質を提供する１つの方法は、Internet Engineering Task Force(IETF)の統合サービス(Integrated Service)（ＩＳ）フレームワークにおいて、また前記ＩＳにおいてリソースリザベーションプロトコル(Resource reSerVation Protocol(RSVP))を使用して提供される。ＲＳＶＰを有するＩＳがエンドツーエンドのサービス品質を提供するために使用される場合もある。
【０００６】
ＲＳＶＰは、フローのソースホストがフローシンクホスト(flow sink host)に向けてＲＳＶＰ  Ｐａｔｈ(Path)メッセージを送信することにより予約手順を開始する、フロー単位の単一方向予約プロトコルである。次にシンクホストがソースホストに向けてＲＳＶＰ予約(Resv)メッセージを返送するというタスクにより、実際の予約が実施される。そのメッセージは所望の帯域幅及び他のチャネルリソース情報を含む。次に、前記ソースホストは前記予約を確認する(ResvConf)。
【０００７】
Ｈ．３２３のマルチメディアに関わるＲＳＶＰの適用についてはＩＴＵ−Ｔ  Ｈ．３２３  ０２／９８規格において仕様が定められている。図１には、Ｈ．３２３環境対応のリソース予約の基本動作を実施する方法の模式的なブロック図が示されている。通信システム１００は、なかでも、アドレス変換、アクセス制御及び帯域幅管理をＨ．３２３の端末及びゲートウェイのためにローカルエリアネットワーク（ＬＡＮ）に提供することができる、Ｈ．３２３の構成要素であるＨ．３２３のゲートキーパー（ＧＫ）１０１を含む。図１は単純な概略図であり、呼シグナリング、ターミナル能力交換、マスタ・スレイブ決定などは図から除かれている。焦点は、ターミナル１０２、Ｈ．３２３ゲートキーパー１０１、ＲＳＶＰ対応サブネットワーク１０３、Ｈ．３２３対応ＩＰネットワーク１０４及び終端ノード１０５の間のシグナリングの関連部分である。
【０００８】
Ｈ．３２３のクライアント１０６はアプリケーションレイヤに属しており、ＲＳＶＰ１０７はＩＰレイヤに属し、図中にはまたリンクレイヤ１０８が図示されている。開放型システム間相互接続（ＯＳＩ）モデルを引用するレイヤは国際標準機構（ＩＳＯ）に規定された国際勧告である。図示した例はゲートキーパールートコール及びＨ．２４５制御ヴァージョン（Gatekeeper routed call and H.245 control version）に関するものである。ＩＴＵ−Ｔ  Ｈ．２４５，０９／９８規格はマルチメディア通信の制御プロトコルである。
リソース予約に対する重要な実行ステップを以下に列挙する。
１０９  Ｈ．３２３の受入れ要求(Admission ReQuest)（ARQ）では、クライアントはＡＲＱのTransportQoS領域の値を適切に設定することによりリソース予約能力を有することを示している。
１１０  Ｈ．３２３ＧＫは受入れ確認(Admission ConFirmed)（ACF）を返送して前記要求を確認する。この例ではクライアントがそのリソース予約能力を使用できることを示している。
１１１  時間になると、クライアントは、QoSCapability領域において要求されるサービス品質に関する情報を含むＨ．２４５のOpenLogicalChannelメッセージをゲートキーパーに送信することにより論理チャネルをオープンにする。そのとき、前記領域は要求されるＲＳＶＰパラメータを含む。
１１２  OpenLogicalChannelメッセージは通常はネットワークを介して他の終端点に送られる。
１１３  ステップ１１２がOpenLogicalChannelAckメッセージで承認されると、次に適切なサービス品質を有するＩＰベアラサービスが要求される。これは、図のステップ１１３に示したように、Ｈ．３２３のクライアントアプリケーションがターミナル１０２のＲＳＶＰの機能的構成要素からサービス品質を要求することにより開始される。
１１４  RSVP Pathメッセージをサブネットワーク１０３に送信してサービス品質要求の開始がなされる。
１１５  RSVP Pathメッセージはさらに、ＩＰネットワーク１０４を介して終端ノード１０５に送信される。
【０００９】
上述ステップに対するさらに完全なフローは図２に図示されており、２方向の音声に対する双方向通信が確立されている。OpenLogicalChannelは本明細書では双方向論理チャネルを確立すると仮定する。ＲＳＶＰはフロー方向ごとに１つの予約を確立する。このようにして、リソースはＩＰレイヤ内に留保され、要求されたサービス品質が提供される。リソース予約はその下層にあるリンクレイヤ技術工学とは無関係であることに注目する。これがＩＰが共通の特徴である不均一なネットワーキング技術工学を介してエンドツーエンドのサービス品質を提供できるようにするために必要である。
【００１０】
現在のマルチメディアソリューションは固定アクセスネットワークを考慮して構築されたものである。セルラー又は無線環境の特定のニーズに対応するように考慮されたものではなかった。
【００１１】
図３はセルラー環境におけるＨ．３２３のシグナリング３０１に基づくマルチメディア通信の適用例の簡易概略図である。例えば、ターミナル３０２は、Ｈ．３２３のクライアントソフトウェアを動作させるラップトップに接続されたセルラー電話でもよい。他の構成も可能である。前記ターミナルは、エアインターフェース上の無線アクセスベアラ３０３を介して無線アクセスノード３０４にアクセスし、アクセスノード３０４は続いて残りのＨ．３２３対応ＩＰネットワーク３０５にアクセスする。本明細書で使用される「無線アクセスノード」("radio access node")という用語は一般的な用語であって、ＧＳＭ、ＥＤＧＥ、ＵＭＴＳなどの他の技術工学において規定される場合がある特殊な無線アクセスノードと混同してはならない。
ＱｏＳは通常は無線アクセス全体を含むエンドツーエンド３０８において要求される。前記ターミナル３０２はＲＳＶＰを使用してリソースを予約する能力を有する。
【００１２】
Ｈ．３２３と組み合わせて公知技術によるリソース予約を使用するとき、ターミナル３０２、無線アクセスノード３０４、ゲートキーパー３０６及び残りのＨ．３２３対応ＩＰネットワーク３０５間のシグナリングの結果を示す典型的なシーケンス線図が図４に提供される。ターミナル３０２と無線アクセスノード３０４間のシグナリングはエアインターフェース４００を介してなされる。前記シグナリングは実際のリソース予約の関連部のみ摘出して図示している。
４０１  ターミナル３０２はＨ．２２５．０／ＲＡＳシグナリングを使用して呼を確立するための受入れ要求をする。ＩＴＵ−Ｔ  Ｈ．２２５．０／ＲＡＳはパケット対応マルチメディア通信システムに使用される登録(Registration)、受入れ(Admission)及びステータスシグナリング(Status signaling)のプロトコルである。ターミナル３０２はＡＲＱメッセージのTransportQoS領域においてリソース予約能力を有することも示す。前記要求は、ゲートキーパー３０６が、ターミナル３０２がリソース予約能力を使用できることを通知するＡＣＦを返送することにより受入れ及び確認される。
４０２  Ｈ．２２５．０／Ｑ．９３１を使用する呼制御シグナリング(Call control signaling)（ＣＣＳ）及びＨ．２４５シグナリングを使用するマスタ・スレイブ決定、ターミナル能力交換などといった他のシグナリングが行われる。ＩＴＵ−Ｔ  Ｈ．２２５．０／Ｑ．９３１は通信制御シグナリングのプロトコルであり、ＩＴＵ−Ｔ  Ｈ．２４５  ０９／９８はマルチメディア通信の制御プロトコルである。
４０３  双方向論理チャネルは、Ｈ．２４５のシグナリングを使用するＲＳＶＰ形式でサービスパラメータのリソース予約品質を含んでオープンされる。
４０４  対応するサービス品質を有する無線アクセスベアラ３０３が確立される。これがいつ、どのようになされるかといったことはここでは重要ではなく、どこかで確立される必要があるというだけである。
４０５  エンドツーエンドのサービス品質に対するリソース予約ＩＰベアラサービスはＲＳＶＰシグナリングを使用して確立される。これは、以前交換されたサービス品質パラメータを使用してなされる。前記予約はフロー単位でなされ、本事例では双方向通信について行われる。
【００１３】
大規模なシグナリングでは、エアインターフェース全体の性能及びコストに問題が現れるのは明らかである。ＲＳＶＰは、ＲＳＶＰメッセージがベアラ予約を補給するために（通常は３０秒間隔で）周期的に送信される、いわゆるソフトステートメカニズムを使用するので、サービス品質を確立するためだけでなく維持するためにも前記シグナリングが要求される。Ｈ．２４５の典型的なメッセージが２０バイト程の長さを有するのに対し、ＲＳＶＰメッセージは標準的な１５０から２３０バイトの長さを有する。
【００１４】
本明細書で議論される問題は以下の通りである。
【００１５】
セルラー環境において、無線スペクトラムの能率化は最優先事項である。無線スペクトラムのコストは高く、どのような場合においてもできるだけ多くのユーザに対して無線スペクトラムを利用することが強く望まれる。したがって、チャネル帯域幅を保持する必要が非常に注目されている。他方ではエンドユーザが一定水準のサービス品質又はサービス行為を期待している。エンドユーザのサービス要求へのサービス応答時間がその１つであり、これにはシグナリングメッセージの送信を待つ待ち時間が短いことと、交換されるシグナリングメッセージが少ないことが要求される。
【００１６】
このような２つの要件は二重の問題を示している。制御シグナリングを見ると、シグナリングの負荷は無線を介してやり取りするメッセージの数及びメッセージ長に依存する。制御チャネル帯域幅を狭小化することによりメッセージ転送時間が増加し、その結果、エンドユーザが認知するネットワーク応答時間が増加する。
【００１７】
要約すると、リソース予約のシグナリングは大容量の帯域幅を消費する。したがって、帯域幅の制限又は帯域幅の大量消費を伴う場合、アクセスベアラを介するリソース予約シグナリングを行わずに、エンドツーエンドのサービス品質を確立する方法が必要とされる。
【００１８】
別の問題は、エンドツーエンドのＩＰサービス品質が望まれているが、ターミナルがＩＰレベル上のリソース予約プロトコルを欠く場合である。この場合、ＩＰリソース予約シグナリングがアクセスベアラを介して行われることのない、エンドツーエンドのサービス品質を確立するための方法が必要とされる。
【００１９】
したがって、本発明の目的は上述の問題を解決することである。
【００２０】
本発明による解決法は、例えば不経済的な狭い無線チャネルなどのアクセスインターフェースを介したＩＰレベルのリソース予約プロトコルによるシグナリングを排除し、ネットワークにリソース予約プロトコルプロキシを導入する。プロキシ機能を導入して、アクセスインターフェースを介したリンクレイヤのサービス品質を有するリソースを確立することによりエンドツーエンドのリソースを予約するための可能性を裏付ける、ないしは、要件を満たす。
【００２１】
本発明によるサービス品質を確立するためにリソース予約を管理するためのアプリケーションレベルサーバは機能的構成要素を含んでいる。この機能的構成要素は、リソース予約の実施及びシグナリングメッセージの変更のために要求される必須パラメータを識別する。さらに、該機能的構成要素は、リソース予約プロトコルプロキシからアクセスノードと終端ノード間の品質サービスを要求する。サーバはたとえリソース予約プロトコルを有していてもそれを使用しないようにターミナルに指示する。本明細書において本発明の第１実施様態によるサーバは特許請求項１の記載事項を特徴とする。
【００２２】
ターミナルと終端ノード間のサービス品質を確立するためにリソース予約を実行する通信システムはＩＰネットワークを含む。上述のリソース予約プロトコルプロキシ、終端ノード及びアプリケーションレベルサーバはＩＰネットワークに接続される。そのターミナルはリンクレベルのサービス品質を有するアクセスベアラを確立する手段によりアクセスノードに接続される。アクセスノードは、プロキシと終端ノード間において、ＩＰレベルのサービス品質を確立するためにリソース予約を実施する、リソース予約プロトコルに接続される。ＩＰネットワークはリソース予約プロトコルを使用する。本明細書において本発明の第２実施様態による通信システムは特許請求項１５の記載事項を特徴とする。
【００２３】
本発明の第３実施様態によれば、該サーバは、リソース予約シグナリングがアクセスノードから終端ノードに向けて実施されるよう指示する。さらに、該サーバは、サービス品質を確立するためにリソースを予約するのに必要なパラメータを識別する。プロキシは必須のパラメータに準拠して、ＩＰレベルにおけるサービス品質を有するリソースを予約する。該リソースはアクセスノードと終端ノード間に予約される。リンクレベルにおいてサービス品質を有するアクセスベアラは、ターミナルとアクセスノード間に確立される。本明細書において本発明の第３実施様態による方法は特許請求項２０の記載事項を特徴とする。
【００２４】
本発明の第４実施様態によれば、本発明はソフトウェアコードセグメントにより実施することができ、例えばリソース予約プロキシ、アプリケーションレベルサーバ、ゲートキーパー等の、通信システムの関連構成要素のいずれかに格納することができる。コンピュータプログラム製品は該構成要素内のディジタルコンピュータの内部記憶装置に直接ロードすることができ、前記プログラムがコンピュータ上で動作するときは、本発明の方法によるステップを実施するソフトウェアコード部を含む。本明細書において、本発明の第４実施様態によるコンピュータプログラム製品は、特許請求項３９の記載事項を特徴とする。
【００２５】
本発明の第５実施様態によれば、コンピュータプログラム製品は、本発明による通信システムの構成要素内部でコンピュータに本発明による方法の実行ステップを制御させる読込み可能なプログラムを含む、コンピュータで使用可能な媒体に格納される。本発明の第５実施様態によるコンピュータプログラム製品は本明細書では特許請求項４０を特徴とする。
【００２６】
本発明の長所は、リソース予約シグナリングがアクセスインターフェース上から排除されるので、ターミナルアクセスインターフェース上に必要とされる帯域幅が小さくなることである。
【００２７】
本発明のさらなる長所は、ターミナルがアクセスインターフェースのＩＰレベルにリソースを予約する能力を有していなくてもエンドツーエンドのサービス品質を確立することが可能なことである。
【００２８】
本発明のさらなる長所は、ネットワークを網羅するアプリケーションに対して透明性を伴うことである。終端ノードにとって、ターミナルがリソース予約を使用したか、或いはプロキシが該ターミナルの代わりにそれを行ったかは、差異を生まない。また、サーバはターミナルがリソース予約を使用するべきか否かを決定する能力を有しているので、リソース予約プロトコルプロキシの導入による既存ターミナルを実施する上での影響はない。
【００２９】
本特許明細書で使用するリソース予約プロトコルの用語は、ＩＰレベルのリソース予約プロトコルすべてを含め、一般的な用語として解釈されなければならない。
【００３０】
本発明のさらなる適用範囲は以下の詳細な説明から明らかとなる。しかし、本発明の精神及び範囲内で様々な変形及び変更が可能であることはこの詳細な説明から当業者にとっては自明のものであるので、詳細な説明及び特定の実施例は、本発明の好ましい実施形態を述べていると同時に、例示手段としてのみ提示されている。
【００３１】
好ましい実施形態の説明
ＩＰを介して通信しているとき、及び、ＩＰを介する音声、マルチメディア、リアルタイム会話サービス(real-time conversational service)、オーディオストリーミング、ビデオストリーミング、保証ビットレートでのウェブサーフィンなどのためにリソース予約を必要としているときには、上述のようにかなり不経済的な帯域幅を必要とする、帯域幅の能率化及び必須のＩＰサービス品質の２つの要件が存在する。別の問題は、必須のＩＰサービス品質を予約する能力を有してはいないが、サービス品質が要求される場合である。
【００３２】
上記の解決法は、無線インターフェースなどのアクセスインターフェースにおいて下層のリンクレイヤがリンクを介して所要のサービス品質を提供することができるという点に基づいている。このリンクは専用リソースであり、それは予測可能で保証されたやり方で必須の及び所要のサービス品質を提供する。帯域幅といった必須のリンクサービス品質を予約することは、ＩＰレイヤにおけるリソースがアクセスインターフェースを介して確実に予約される必要はないということを意味する。アクセスネットワークにおいて、リソース予約プロトコルシグナリングはリソース予約プロトコルプロキシを使用して発生及び終端させることができる。したがって、エンドツーエンドでＩＰベアラサービス品質要件を満たす。
【００３３】
図５は一般モードにおいて本発明によるエンドツーエンドのサービス品質を確立するフローチャートを図示している。サービス品質は、通信システムにおいてＩＰネットワークを介してターミナルと終端ノード間に確立される。前記通信システムはリソース予約プロトコルを使用してＩＰネットワークを含み、以下のものが接続されている。
アクセスノードを介したターミナル
終端ノード
リソース予約プロトコルプロキシ
図７に示したリソース予約を保守管理するアプリケーションレベルサーバ
当該ネットワーク及び当該構成要素はＩＰレベル上のリソース予約プロトコルを使用するが、ターミナルはＩＰレベル上のリソース予約プロトコルのいずれも使用しなくてもよい。本発明を使用する機会とは、ネットワークがリソース予約プロトコルの使用を望むが、ターミナルがリソース予約プロトコルを何も有していない場合である。代わりに、ＩＰパケットが転送されるリンクレベル上に非同期転送モード（ＡＴＭ）を有してもよい。ターミナルはターミナルとアクセスノード間においてＡＴＭレベル上のアクセスベアラを使用できる。リソース予約プロトコルプロキシ及びサーバはそれぞれ、コンピュータプログラムを格納する内部記憶装置を具備するディジタルコンピュータを含む。
【００３４】
当該方法は以下のステップを含む。
５０１  サーバは、アクセスノードから終端ノードへのリソース予約シグナリングを指示する。
５０２  サーバは、エンドツーエンドのサービス品質を確立するためのリソース予約に必要なパラメータを識別する。
５０３  アクセスノードと終端ノード間に、ＩＰレベル上のサービス品質を有するリソース予約がリソース予約プロトコルプロキシにより実施される。
５０４  サービス品質を有するアクセスベアラが、ターミナルと、ＡＴＭレベル又は無線リンクレベルなどのリンクレベル上のアクセスノードとの間に確立される。
ステップ５０４をステップ５０３の前又は同時に実施することも可能である。本発明による方法のさらに詳細な説明を図８に基づいて述べる。
【００３５】
図６は通信システム６００の概観図を示している。前記システムにおいて、本発明に従い、サービス品質はターミナル６０５と終端ノード６０８間に確立される。前記通信システム６００は、例えば、一般パケット無線サービス(General Packet Radio Service(GPRS))、Enhanced Data rates of GSM and TDMA/136 Evolution(EDGE)、及びユニバーサル移動体電気通信システム（ＵＭＴＳ）におけるＵＭＴＳ地上無線接続網(UMTS Terrestrial Radio Access Network(UTRAN))などの、セルラー環境におけるＨ．３２３による通信６０１に基づいている。
【００３６】
本発明のこの実施形態において、構成要素及びＩＰネットワークはリソース予約プロトコル（ＲＳＶＰ）を使用している。このようにしてＲＳＶＰプロキシ６０２のリソース予約プロトコルプロキシは構成され、本実施形態ではＲＳＶＰはサブネットワーク６０４内の無線アクセスノード６０３に具備されている。前記サブネットワークはＨ．３２３対応ＩＰネットワーク６０７にアクセスしている。
ＲＳＶＰプロキシ６０２はアクセスノードと終端ノード間にＩＰレベル上のサービス品質を確立するためにリソース予約を実施する手段６１３を有する。
ターミナル６０５とアクセスノード６０３は共に、ターミナル６０５とアクセスノード６０３間のリンクレイヤ上にサービス品質を有する無線アクセスベアラを確立する手段６１２を有する。
ＲＳＶＰプロキシ６０２は、それが適当であれば図６に示されていないサブネットワーク６０４内の他の構成要素に具備されていてもよい。配置される場所は本発明においては重要ではない。
当該サブネットは、例えば、無線アクセスネットワーク、或いは、無線アクセスネットワークとコアネットワークを構成していてもよい。
そのシナリオはＨ．３２３ゲートキーパールートコール(Gatekeeper routed call)のシナリオに適用する。ターミナル６０５は、無線アクセスを提供する無線モデムに接続されるＨ．３２３のクライアントソフトウェアを動作させるラップトップで構成されてもよい。他の構成も可能である。ターミナル６０５は無線アクセスベアラ６０６を経由して無線アクセスノード６０３にアクセスする。終端ノード６０８はＩＰネットワーク６０７に接続される。
【００３７】
通信システムは本発明によるアプリケーションレベルサーバ６０９を含み、それは図７にさらに詳細に図示されている。該アプリケーションレベルサーバ７０１はＩＰネットワーク７０２に接続され、本発明によるリソース予約プロトコルプロキシ７０５を用いて、ターミナル７０３と終端ノード７０４間にサービス品質を確立するリソース予約の過程を管理する。ターミナル７０３はアクセスノード７０６を経由してＩＰネットワークに接続される。前記アクセスノード７０６はプロキシ７０５に接続され、そのプロキシ７０５がＩＰネットワークに接続される。終端ノード７０４はＩＰネットワーク７０２に接続され、ＩＰネットワーク７０２はリソース予約プロトコルを使用する。サーバ７０１は、例えば、Ｈ．２２５及びＨ．２４５シグナリングプロトコルを管理するゲートキーパーであるか、又は従来技術のＳＩＰを管理する、ＳＩＰプロキシなどで、本発明により、リソース予約プロトコルプロキシ７０５を用いてサービス品質を確立するリソース予約の過程を管理する機能的構成要素７０７を含むように変更される。
【００３８】
サーバ７０１はプロキシ７０５と終端ノード７０４間にリソース予約プロトコルシグナリングを指示するための手段７１２を有する。例えば、プロビジョニングにより使用する、プロキシ７０５とアクセスノード７０６間のサービス品質を達成するために様々な手段が存在する。
【００３９】
サーバの機能的構成要素７０７は、リソース予約の過程を実施するのに使用される、シグナリングメッセージなどから必須のパラメータを識別する手段７０８を有する。
必須パラメータの例は、終端ノード７０４の受信者のＩＰアドレス、終端ノード７０４の受信者ポートＩＤ、終端ノード７０４が使用することを目的とするサービス品質モード及び所要の帯域幅といったサービス品質情報である。サービス品質情報はアプリケーションの識別力に基づいてサーバにより認識されてもよい。例えば、サーバはアプリケーション及びサーバにより欧州汎用移動体通信（ＧＳＭ）伝送音声符号化が使用されることを認知し、ＧＳＭ用の特定音声コーデックが特定の帯域幅量を要することを認識する。（ポートは、ＩＰパケットが転送されるべきホストにおける過程をさらにアドレス指定するためにＩＰ準拠システムで使用される。）
【００４０】
サーバ７０１の機能的構成要素７０７は、リソース予約プロトコルを有していてもそれを使用しないようにターミナルに指示する手段７０９を有する。
【００４１】
サーバ７０１の機能的構成要素７０７は、ターミナル７０３と終端ノード７０４間の、及び場合によってはそれらと他のゲートキーパー間のシグナリングメッセージを変更する手段７１０を有する。
リソース予約プロトコルを使用しないように指示されるターミナルは、終端ノード７０４に向けたシグナリングメッセージの中で、リソース予約能力を有していないことを示すが、アクセスノードに向けられたリソース予約プロトコルを使用しなければならない終端ノード７０４は、リソース予約能力を有するという情報を得る必要がある。
ターミナルは、終端ノードに向けた別のシグナリングメッセージの中で、リソース予約能力を使用しないことも表明しているが、アクセスノードに向けたリソース予約プロトコルを使用する終端ノード７０４は、リソース予約能力が使用されるという情報を獲得しなければならない。
終端ノード７０４又はターミナル７０３に向かう経路上でサーバ７０１を通るこれらのシグナリングメッセージは、それらが目的地に到達する前に機能的構成要素７０７によりしかるべく変更される。
【００４２】
サーバ７０１の機能的構成要素７０７は、リソース予約プロトコルプロキシ７０５から、プロキシ７０５と終端ノードの間に所要のサービス品質を要求する手段７１１も有する。機能的構成要素７０７により集められた必須のパラメータは、リソース予約プロトコルプロキシ７０５に送られる。リソース予約プロトコルプロキシは、プロキシ７０５と終端ノード７０４間に所要のサービス品質を有するリソース予約を実施する。
【００４３】
図６に戻り、ＩＰネットワーク６０７に接続されるサーバ６０９は、本発明の本実施例において、図７に基づく上述のサービス品質を確立するためにＲＳＶＰプロキシ６０２を使用する過程を管理する手段６１０を含むように変更されたＨ．３２３のゲートキーパー６０９を構成する。ＲＳＶＰプロキシ６０２は、アクセスノードと終端ノード間にゲートキーパー６０９に要求されたサービス品質を有するリソース予約を実施する手段を有する。
本発明の実施例において、「実際の」ＲＳＶＰ対応サービス品質が無線アクセスノード６０３と終端ノード６０８間に提供されるが、無線リンク６０６がその信頼できるサービス品質を提供するという事実に基づけば、ＩＰレイヤにおいて「仮想的な」サービス品質６１１がエンドツーエンドに提供される。ＲＳＶＰプロキシ６０２及びＧＫ６０９はコンピュータプログラムを格納する内部記憶装置を具備するディジタルコンピュータをそれぞれ有する。
【００４４】
図８は、図６に図示されたシナリオに基づく、本発明によりエンドツーエンドのサービス品質を確立する各段階を示す概略的なシーケンス図である。図中の構成要素及びネットワークは、ターミナル６０５、エアインターフェース８００、図６に描かれたようにＲＳＶＰプロキシ６０２を含む無線アクセスノード６０３、ゲートキーパー６０９、Ｈ．３２３及びＲＳＶＰ対応ＩＰネットワーク６０７及び終端ノード６０８である。
図８は単純化された概略図であり、本発明による方法に関連するシグナリングの一部に焦点を当てたものである。
８０１  ターミナル６０５は、ゲートキーパー６０９からＨ．２２５／ＲＡＳシグナリングを使用して呼を確立するために受入れ(admission)を求める。本事例では、構成要素がＲＳＶＰを動作させているので、ＡＲＱメッセージのTransportQoS領域にリソースを予約するための能力を有することも示している。ゲートキーパー６０９は前記要求を受入れ、承認すると、ターミナルがリソース予約能力を使用してはいけないこと、或いは、ゲートキーパー６０９が必須のリソースを予約することとをACFメッセージのTransportQoS領域においてターミナル６０５に伝える。
８０２  Ｈ．２２５．０／Ｑ．９３１を使用する呼制御シグナリングＣＣＳは、Ｈ．２４５のシグナリングを使用するマスタ・スレイブの決定やターミナル能力の交換といった他のシグナリングと同様に実行される。なかでも、本発明に対して重要である能力交換シグナリングが図８の参照番号８０２に示されている。能力交換シグナリングにおいて、ターミナル６０５はそのリソース予約能力を使用しないように指示されているので、終端ノード６０８に向けられるTreminalCapabilitySetメッセージ中にサービス品質は使用される予定がない旨を示す。しかし、サービス品質は無線アクセスノード６０３内のＲＳＶＰプロキシにより確立されるので、終端ノード６０８がリソース予約を使用しない決定を認識することになってはならない。したがって、ゲートキーパー６０９は、終端ノード６０８に向けて転送される前に、サービス品質が支持されていること及びどのタイプのサービス品質モードが対応されるかを指示するために、TerminalCapabilitySetメッセージのQoSMode領域を、セットしない、から、セットする、に変更する。これは、当該ＲＳＶＰシグナリングが無線アクセスノード６０３と終端ノード６０８間に使用されてもよいことを意味する。終端ノード６０８は反対方向のTerminalCapabilitySetメッセージにおいて、どのサービス品質モードを使用するのかを返送する。ＲＳＶＰにおいて、保証サービス品質又は制御モードなどのサービス品質モードには様々なクラスがある。ターミナル６０５に向かう途中でこのメッセージがゲートキーパー６０９を通過するとき、ゲートキーパー６０９はサービス品質モードを遮断し、転送する前にメッセージから使用されるべきサービス品質モードを排除する。サービス品質モードは、図５に記載のリソース予約の過程を実施するのに使用される必須パラメータの１つである。さらに、このメッセージはサービス品質が使用できることを示すが、それは無線アクセスノード６０３内部のＲＳＶＰプロキシにより確立されるので、ターミナル６０５がそれを認識することになってはならない。したがって、このメッセージも、ターミナル６０５に転送される前に、サービス品質が使用されないことを指示するためにゲートキーパー６０９により変更される。
８０３  双方向論理チャネルをオープンにするとき、ターミナル６０５は、Ｈ．２４５のOpenLogicalCannelをゲートキーパー６０９に送り、ゲートキーパー６０９は、終端ノード６０８にメッセージを転送する。１つの双方向論理チャネルが、ビデオに対して１つ、オーディオに対して１つ、データに対して１つというように、必要な各タイプのフローに対してオープンにされる。伝達される情報は、（ＡＣＦのTransportQoSにより返送された値に基づき）所要の帯域幅、遅延タイプなどのサービス品質情報を含んでもよい。バイト毎秒単位の最大帯域幅などのこのサービス品質情報は、ゲートキーパー６０９がOpenLogicalChannelメッセージを受信したときに、ゲートキーパー６０９によって遮断されても良いが、ゲートキーパー６０９のアプリケーションについての知識を用いて推定されてもよい。アプリケーションについての知識とは、例えば、ＧＳＭコードを有するチャネルがオープンにされる場合、特定の帯域幅量などが必要とされることなどである。他の伝達される情報は、供給される受信ポートなどが無線アクセスノード６０３のＲＳＶＰプロキシのポートであり、ターミナル６０５内のポートではないということである。さらに、重要な伝達情報は、例えば使用されるべきポートのポート識別を指示することによって、終端ノード６０８における論理チャネルがどこで終端すべきかということである。これは、OpenLogicalChannelAckメッセージ中で、終端ノード６０８からゲートキーパー６０９を経由してターミナル６０５へ返送される。ターミナル受信ポートＩＤなどは終端ノード６０８から受信される、次のＲＳＶＰ  Pathメッセージで使用される。
８０４  ゲートキーパー６０９はサービス品質要求メッセージにおいて無線アクセスノード６０３のＲＳＶＰプロキシからサービス品質を要求する。サービス品質は無線アクセスノード６０３と終端ノード６０８間に要求される。ゲートキーパー６０９は獲得したサービス品質情報、サービス品質モード、終端ノード６０８の受信ポートＩＤをＲＳＶＰプロキシへのメッセージを含む。
８０５  無線アクセスノード６０３のＲＳＶＰプロキシ６０２と終端ノード６０８間に、ターミナル６０５から終端ノード６０８に向かうメディアストリームに使用されるべき予約を確立するために、無線アクセスノード６０３のＲＳＶＰプロキシ６０２は、（ターミナルから送られたかのような）ＲＳＶＰシグナリングメッセージPathを使用して、ステップ７０４で要求されたように、終端ノード６０８に向けて必須のリソース予約を開始する。当該メッセージは獲得したサービス品質情報、サービス品質モード及び終端ノード６０８の受信ポートＩＤを含み、それらは、リソース予約を実施するのに必要である。次のＲＳＶＰのResvメッセージが終端ノード６０８からターミナル６０５に返送されるとき、該メッセージはＲＳＶＰプロキシ６０２により遮断されてターミナル６０５にそれを通過させない。Resvメッセージへの応答として、ＲＳＶＰプロキシ６０２はRSVP ResvConfメッセージを作成し、（ターミナルから送られたかのように）終端点６０８に送る。ＲＳＶＰプロキシ６０２と終端ノード６０８の間に、終端ノード６０８からターミナル６０５に向かって進むメディアストリームに使用されるべき予約を確立するために、終端ノード６０８（又は本発明のプロキシなど終端ノードの代わりの役割を果たす別の構成要素）はＲＳＶＰ Pathメッセージをターミナル６０５に送ることによりターミナル６０５の方向へ必須のリソース予約を開始する。Pathメッセージは必須のサービス品質情報、サービス品質モード及びターミナル６０５の受信ポートＩＤを含み、それらは、リソース予約を実施するのに必要である。前記Pathメッセージは無線アクセスノード６０３のＲＳＶＰプロキシにより遮断され、ターミナル６０５に到達しない。ＲＳＶＰプロキシ６０２は、（ターミナルから送信されたかのように）ＲＳＶＰResvメッセージを終端点６０８に返送することによりPathメッセージに応答する。ＲＳＶＰResvConfメッセージ中のリソース予約の確認が終端ノード６０８（又は本発明のＲＳＶＰプロキシといった終端ノードの代わりの役割を果たす構成要素）から受信されるときに、前記メッセージはＲＳＶＰプロキシ６０２により遮断され、ターミナル６０５に到達しない。予約は本事例においては、双方向通信に対してフローごとに行われる。
８０６  無線アクセスベアラは、ターミナル６０５のリンクレイヤと無線アクセスノード６０３のリンクレイヤ間において、相当するサービス品質を有して確立される。ＵＭＴＳネットワークシナリオにおいては、これは、ターミナル６０５がＵＭＴＳセッションマネージメントシングナリング（技術仕様書２４．００８：「Mobile Radio Interface layer 3 specification, core network protocols - stage 3」 v3.2.1, 3rd Generation Partnership Project(3GPP)）に準拠したActivatePDPContextRequestメッセージを送信することにより開始される。これが行われるタイミングは本発明においては重要ではなく、いつか行われていればよいというだけである。
最終的に、エアインターフェースを介してＲＳＶＰを送ることなく、リソースがエンドツーエンドで保証される。
【００４５】
記載された本発明による方法は、本方法のステップを実施するソフトウェアコードを具備するコンピュータプログラム製品を用いてそれぞれ実施される。前記コンピュータプログラム製品は、サーバ内及びリソース予約プロトコルプロキシ内のディジタルコンピュータに格納されるコンピュータ上で実行される。
当該コンピュータプログラムはフロッピー（登録商標）ディスク、ＣＤ、インターネットなどといった、コンピュータで使用可能な媒体から又は直接ロード可能である。
【図面の簡単な説明】
図１〜４は従来技術に関わるものであり、「関連技術の説明」に記載されている。
【図１】  図１はＨ．３２３環境におけるリソース予約の基本動作を図示したブロック図である。
【図２】  図２はＨ．３２３アーキテクチャにおいてＲＳＶＰを使用するリソース予約の基本動作の概略的なシグナリングシーケンスを図示している。
【図３】  図３はセルラー環境におけるＨ．３２３に基づいたマルチメディア通信の概略ブロック図を図示している。
【図４】  図４はセルラー環境にＨ．３２３アーキテクチャを適用した場合の基本動作の概略的なシグナリングシーケンスを図示している。
【図５】  図５は本発明による方法のフローチャートを図示している。
【図６】  図６は本発明による通信システムを図示した概略ブロック図を示している。
【図７】  図７は本発明によるアプリケーションレベルサーバを図示したブロック図である。
【図８】  図８は本発明によるシグナリングシーケンス図を示している。
【図１】
0004607412.tif 000002
【図２】
0004607412.tif 000003
【図３】
0004607412.tif 000004
【図４】
0004607412.tif 000005
【図５】
0004607412.tif 000006
【図６】
0004607412.tif 000007
【図７】
0004607412.tif 000008
【図８】
0004607412.tif 000009