JP4445547B2 - 通信ネットワークにおけるサービス品質管理のためのバインディングメカニズム - Google Patents

Description

本発明は、移動通信システムにおける装置と方法に関するものであり、特にパケットデータサービスに関する送信のサービス品質管理のためのメカニズムに関するものである。

関連出願の引用
本願は、同一出願人による同時係属の、２００４年７月５日に出願され、「プッシュメッセージによって開始されるサービスのための装置および方法（Devices and Methods for Push Message Initiated Service）」と題された国際特許出願Ｎｏ.ＰＣＴ／ＳＥ０４／００１０８６、２００４年７月５日に出願され、「サービス品質パラメータをＨＴＴＰメッセージの中に供給するための方法と装置（Methods and Devices for Supplying Quality of Service Parameters in HTTP Messages）」と題された国際特許出願Ｎｏ.ＰＣＴ／ＳＥ０４／００１１０３、そして、２００４年７月５日に出願され、「サービス品質を変更する方法および装置（Methods and Devices for Changing Quality of Service）」と題された国際特許出願Ｎｏ.ＰＣＴ／ＳＥ０４／００１１０２に関するものであり、それらの開示を、参照により本願に援用する。

データビット形式でパケットベースの情報通信を行う通信ネットワークは、当業者に良く知られている。移動通信の重要性が増すにつれ、無線接続によってデータを転送する需要も高まっている。３ＧＰＰ（3rd Generation Partnership Project）は、複数の通信標準化団体を一つにまとめるための共同協定であり、進化したＧＳＭコアネットワークとそれらがサポートする無線アクセス技術に基づいて、グローバルに適用できる第3世代移動システムの技術仕様書と技術報告書を作成するために設立されたものである。これには、進化した無線アクセス技術（例えばＧＰＲＳ（General Packet Radio Service）やＥＤＧＥ（Enhanced Data rates for GSM Evolution））を含むＧＳＭ（Global System for Mobile communication）の技術仕様書と技術報告書の維持及び発展が盛り込まれている。

３ＧＰＰが現在取り組んでいる課題の一つが、技術仕様書３ＧＰＰ ＴＳ ２３．２０７ Ｖ６．２．０（２００４−０３）に記述されたようなＧＰＲＳネットワークを含むサービスのためのエンド・エンドサービス品質を提供する枠組みである。この技術仕様書は、サービスの設定に先立つネットワーク資源の使用を制御して許可するために、ポリシーコントロールメカニズムを利用することについて記述している。

将来は、パケット交換サービスがＰＤＦ（ポリシー決定機能：Policy Decision Function）によってポリシーコントロールされると想定されている。ＰＤＦは論理要素であり、論理ポリシー決定要素として使用され、アプリケーション層におけるイベントとＩＰベアラ層における資源管理の間の協調を可能にするものである。

ユーザおよびアプリケーションのＩＤ／許可レベル、トラヒック帯域幅の要件、セキュリティへの配慮、曜日、時間といった一定の基準から導出した「ポリシー」に基づいて、ネットワーク管理者やサービスプロバイダが、ネットワーク資源やサービスの利用を監視し、制御し、実施できることは重要だと考えられたことから、ポリシーコントロールが開発された。環境は多様であり、その中で各種の団体はそれぞれの要求するサービスを利用する権利があるため、規則の必要性、そのような規則の実施方法の必要性が存在し、そして、それらがいつ適用されるかを決定するための「判定者」が必要となる。従って、ポリシーシステムの３つの主な構成要素には、通常はポリシーデータベース内に保存されているポリシー規則、ポリシー実施点（ＰＥＰ）に実装されることがあるポリシー実施部、そして、ポリシー決定点が含まれる。ＩＥＴＦは、ＣＯＰＳ（Common Open Policy Service）という呼び名で、ＰＥＰとポリシー決定点の間の情報交換用プロトコルを標準化した。一般に、ポリシーとは、特定の諸条件が存在する時１つ以上の動作をもたらす規則の集合と考えてよい。

図１は、３ＧＰＰによって開発されたポリシーコントロールメカニズムに含まれる多様な要素を例示する、概略的なブロック図である。図１は、移動可能なユーザ装置（ＵＥ）とサービスプロバイダのアプリケーション機能（ＡＦ）との間にサービスが設定された例を例示している。ＵＥは、アプリケーションセッションを開始するため、ＡＦセッション信号４によってＡＦ２と通信するＡＦクライアント３を有する。セッションの設定とサービスの起動には、セッションのデータパケットを搬送するベアラサービスの設定が必要である。セッションは、ベアラ資源についての特定の用件を持つ、１つ以上の異なるＩＰフローを有していてもよい。ＡＦセッションシグナリング信号４は、ＵＥの中の翻訳／マッピング機能によってベアラＱｏＳパラメータに翻訳される、サービス品質（ＱｏＳ）要件に関する情報を有していてもよい。ベアラサービスを起動するため、ＵＥは、ＰＤＰコンテクスト起動要求を翻訳／マッピング機能によって決定されるベアラＱｏＳパラメータと共に、関門ＧＰＲＳサポートノード（ＧＧＳＮ）６に送信する。ＵＥとＧＧＳＮ間の通信は、この例によれば、ＵＥおよびＧＧＳＮそれぞれの中のＵＭＴＳ ＢＳマネージャ７および８によって処理される。この例で、ＧＧＳＮはＰＥＰとして機能しており、ＱｏＳ管理に関与するＩＰ ＢＳマネージャ９を備えている。ＧＧＳＮ６は、ポリシーコントロールを実行するため、Ｇｏインタフェース１１を介してＰＤＦ１０と相互作用する。ＰＤＦ１０は、Ｇｑインタフェース１２を介してＡＦ２から取得したポリシー設定情報に基づいて、ポリシー決定を行う。図１に例示した諸要素およびそれらの機能に関する詳細情報は、上記の技術仕様書ＴＳ２３．２０７ Ｖ６．２．０．で入手できる。

３ＧＰＰがポリシーコントロールメカニズムの仕様を定めたとき、ＰＤＰコンテクストとＩＰフローをポリシー情報にマッピングするためのバインディングメカニズムを確立するため、許可トークンも導入された。許可トークンは、ＡＦから要求があると、特定のＡＦセッションのためＰＤＦによって生成される。許可トークンは、ＰＤＦについての十分に限定されたドメイン名の情報を含んでおり、ＡＰＮ（アクセスポイント名、Access Point Name）に関連するすべてのＰＤＰコンテクストを通じて一意である。ＡＦは、ＡＦセッション信号の中でＵＥに許可トークンを送信する。その後、ＵＥは、ＰＤＰコンテクストを起動または修正するいかなる要求の中にも、適用可能な許可トークンを搭載すべきとなっている。その後、許可トークンは、正しいポリシー情報にマップされるよう、ＧＧＳＮおよびＰＤＦで使用される。

３Ｇシステムにおいてポリシーコントロールを実装するとき、許可トークンおよびその関連処理を導入する計画には、いくつか不都合な点がある。主な問題点の一つは、許可トークンを既存のＵＥが処理できるようにするには、それらの修正が必要なことである。もう一つの問題点は、許可トークンを導入するには、ＲＴＳＰ（Real-Time Streaming Protocol）、ＳＩＰ（Session Initiation Protocol）、ＳＤＰ（Session Description Protocol）、およびアプリケーションセッションの設定と処理に使用される、その他のプロトコルの新規標準化が必要なことである。

本発明の目的は、移動端末にサービスを配信するためポリシーコントロールされたベアラサービスを設定するとき、単純なバインディングメカニズムを用いる装置および方法を提供することである。

上述の目的は、請求項１から１０までによる方法によって、および、請求項１９によるポリシー決定機能によって達成される。

本発明の基本的な考え方は、適用可能なポリシー情報にベアラサービスの起動要求をバインドするために、そしてそれによって、ベアラサービスを起動している間、許可トークンを端末に送信する必要性を低減するために、端末ＩＤ（識別情報）をバインディング情報として利用することである。

本発明の第１の態様によれば、アプリケーション機能部から移動端末にサービスを配信するためにポリシー制御されたベアラサービスを設定する方法を提供する。本方法は、ポリシー識別情報に関連付けられた移動端末の端末識別情報（例えばＭＳＩＳＤＮ、ＩＭＥＩ、ＩＭＳＩ等）をポリシー決定機能部に備えられる登録器（レジスタ）に登録するステップと、移動端末からコアネットワークノードを介して、ベアラサービスに要求される複数のＱｏＳパラメータの１組と端末識別情報とを含む、ベアラサービスの起動要求を受信するステップと、ベアラサービスに適用可能なポリシー情報を決定するため、端末識別情報を用いてベアラサービスの起動要求をポリシー識別情報にバインディングするステップと、ＱｏＳパラメータが適用可能なポリシー情報を満たすＱｏｓパラメータであるか否かをチェックすることによってポリシーチェックを実行するステップと、ポリシーチェックが成功した場合、ベアラサービスの設定について完了処理を開始するために、承認メッセージをコアネットワークノードに送信するステップとを含む。

本発明の第２の態様によれば、ポリシー決定機能部において、アプリケーション機能部から移動端末にサービスを配信するためのベアラサービスについてポリシー制御を実行する方法が提供される。本発明の第２の態様によるこの方法は、端末識別情報とポリシー識別情報を有する登録メッセージを受信するステップと、ポリシー識別情報に関連付けて端末識別情報を登録器に登録するステップと、ベアラサービスに適用可能なポリシー情報を決定するため、端末識別情報を用いて登録器内でベアラサービスの起動要求をポリシー識別情報にバインディングするステップと、ＱｏＳパラメータが適用可能なポリシー情報を満たすＱｏｓパラメータであるか否かをチェックすることによってポリシーチェックを実行するステップと、ポリシーチェックが成功した場合、ベアラサービスの設定について完了処理を開始するために、承認メッセージをコアネットワークノードに送信するステップ（３１７，３１８）とを含む。

本発明の第３の態様によれば、あるサービスをアプリケーション機能部から移動端末へと配信するベアラサービスに対してポリシーコントロールを実行するためのポリシー決定機能（装置）が提供される。ポリシー決定機能は、端末識別情報とポリシー識別情報を有する登録メッセージを受信するための第１のインタフェース、ポリシー識別情報に関連付けられた端末識別情報を登録するための登録器、コアネットワークノードを介して端末からベアラサービス起動要求（ベアラサービス起動要求は端末ＩＤとベアラサービスのための一組の要求されたＱｏＳパラメータを有している）を受信するための第２のインタフェース、及び、ベアラサービスに適用可能なポリシー情報を決定するため、端末識別情報によってポリシー識別情報にベアラサービス起動要求をバインディングし、要求されたＱｏＳパラメータがその適用可能なポリシー情報を満たしているか否かをチェックすることによってポリシーチェックを実行し、ポリシーチェックが成功した場合、ベアラサービス設定の完了を開始するため、承認メッセージをコアネットワークノードに送信するための処理手段を有している。

本発明の有利な点は、ポリシーコントロールされたベアラサービスを設定する目的で許可トークンを端末に送信する必要性を本発明が低減できるということである。これは、端末についての標準の影響が端末に及ばないことを意味する。

本発明のもう１つの有利な点は、本発明を使えば、ＲＴＳＰ（Real-Time Streaming Protocol）、ＳＩＰ（Session Initiation Protocol）、ＳＤＰ（Session Description Protocol）、およびアプリケーションセッションの設定と処理に使用されるその他のプロトコルの新規標準化が不要ということである。

本発明のさらなる有利な点は、本発明のポリシーメカニズムとＱｏＳコントロールメカニズムは、今日市場で入手可能な移動端末にも実装することが可能だということである。従って、本発明を実装するために移動端末を変更する必要はない。

本発明の一実施形態による別の有利な点は、要求されたＱｏＳパラメータがサービスプロバイダのＱｏＳ需要を満たさない場合、端末がベアラサービス用に要求するＱｏＳパラメータをサービスプロバイダがアップグレード（格上げ）させることが可能だということである。これが可能なのは、アプリケーション機能部によって提供される一組の所定の最小限度のＱｏＳ要件を、要求されたＱｏＳパラメータが満たしているか否かチェックすることを、本発明の実施形態が可能にさせているからである。要求されたＱｏＳパラメータが所定の最小限度のＱｏＳ要件を満たしていないならば、ベアラサービスを設定するときに使用するＱｏＳパラメータを修正することができる。

本発明の実施形態のさらなる有利な点と特徴は、下記の詳細説明を図面と関連させて読むことによって明らかになるであろう。

以下、本発明の好適な実施形態を示す添付図面を参照しながら、本発明についてもっと詳細に説明する。しかし、本発明は多くの異なる形態で実施可能であり、本明細書の中に述べられた実施形態に限定されると解釈されるべきではない。そうではなく、これらの実施形態は、十分かつ完全に、本発明を当業者が実施できるよう提供されているにすぎない。図面の中では、類似の番号は類似要素に言及している。

本発明は、移動通信システムにおけるパケット交換サービスに適用可能である。そのようなサービスには、エンドユーザの移動クライアント端末とアプリケーションサーバ装置の間で実行されるパケット交換通信が含まれる。移動通信システムには、移動クライアント端末が存在する無線ネットワーク、例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、無線ＬＡＮ、ＧＰＲＳネットワーク等のネットワークシステムが含まれる。

図２は、本発明がその中で使われることがある移動通信システムの一般的なネットワークアーキテクチャを例示する概略ブロック図である。図２の移動通信システム１０１は、サービスプロバイダのネットワークノード１０６と通信し、それによってサービスプロバイダが提供するサービスを受けることがある移動クライアント端末１０２を備えている。クライアント端末１０２とネットワークノード１０６間の通信は、無線ネットワーク１０３、コアネットワーク１０４、およびサービスネットワーク１０５を介して行われる。無線ネットワーク１０３は例えばＵＴＲＡＮ（UMTS Terrestrial Radio Access Network）であってもよく、コアネットワーク１０４は例えばＵＭＴＳコアネットワークであってもよく、サービスネットワークは例えばインターネットやサービスプロバイダの専用ＩＰネットワークであってもよい。サービスプロバイダのネットワークノード１０６は例えばアプリケーションサーバであってもよい。

図３は、本発明による方法の一実施形態を例示する概略フロー図である。この図は、ポリシーコントロール（ポリシー制御）されたベアラサービスを設定するときの、移動端末３０１、ＧＧＳＮ（Gateway GPRS Support Node）３０２、ポリシー決定機能部（PDF）３０３、アプリケーション機能部（ＡＦ）３０４、そしてセッションデータベース３０５の間の相互作用を例示している。ベアラサービス設定プロセスにはさらなるネットワークノードが関与してもよいが、本発明の説明を簡略化するため、本発明に特に関連があるノードに限って図３に例示している。

図３では、初期のＰＤＰコンテクストが存在し、ステップ３０６で端末３０１がＡＦ３０４にストリーミングコンテンツを要求すると想定されている。この例では、ＡＦはストリーミングサーバである。ＡＦは例えばＭＭＳやダウンロードサーバである可能性もある。

ストリーミングコンテンツの要求を受信した後、ＡＦ３０４は端末３０１に関連付けられた端末ＩＤを検出する。この例では、端末ＩＤは、ＭＳＩＳＤＮ（移動機識別電話番号）であり、これはステップ３０７で当業者には周知の方法に従って、端末ＩＰアドレスとＭＳＩＳＤＮ間のマッピングをセッションデータベース３０５に問い合せることによって抽出される。その後、ＡＦは、ステップ３０８で、要求されたストリーミングコンテンツの配信のために設定されようとしているＰＤＰコンテクストのＱｏＳをチェックすることに関心があることをＰＤＦ３０３に登録する。登録には、ポリシー識別情報に関連付けられたＭＳＩＳＤＮをＰＤＦの登録器（レジスタ）に登録するステップが含まれる。この例では、ポリシー識別情報はＡＦのＩＰアドレスであり、従ってＡＦは適用可能なポリシー情報を要求されうる。ＰＤＦのアドレスは事前にＡＦに知られていると想定されている。ＰＤＦで登録が実行された後、ステップ３０９で、ＡＦは、ＳＤＰファイルを端末に送信する。端末は、その後、ステップ３１０で、ＳＤＰファイルを解釈し、ストリーミングコンテンツの配信のためベアラサービスが設定されるよう要求するため、ＱｏＳパラメータを推定する。端末は、その後ステップ３１１で、第２のＰＤＰコンテクストの起動要求を送信することによって、第２のＰＤＰコンテクストを開始する。起動要求は、ＳＤＰファイルの解釈から推定されたＱｏＳパラメータを含んでいる。これらのＱｏＳパラメータは、以下、要求されたＱｏＳパラメータと表される。ステップ３０９、３１０、３１１は当業者には周知であり、従って本明細書の中では、詳細な説明はしない。

ＧＧＳＮ３０２は、ＰＤＰコンテクスト起動要求を受信する。ＧＧＳＮは、ステップ３１２で、要求されたＱｏＳパラメータをチェックするため、要求をＰＤＦに送信する。チェック要求は移動端末のＭＳＩＳＤＮと要求されたＱｏＳパラメータを有している。ＰＤＦのアドレスはＧＧＳＮに把握されていることを前提としている。チェック要求を受信すると、ＰＤＦ３０３は、ステップ３１３で、受信したチェック要求に含まれているＭＳＩＳＤＮを、ＡＦ３０４の以前の登録を保存している登録器に対してマッピングすることにより、当該ＭＳＩＳＤＮに対応付けて登録されているＡＦ３０４のアドレスを検出する。ＰＤＦ３０３は、その後、ステップ３１４で、登録器の中に保存されている端末のＭＳＩＳＤＮに一致したアドレスを使って、チェック要求をＡＦ３０４に送信する。チェック要求は端末のＭＳＩＳＤＮと要求されたＱｏＳパラメータとを搭載している。ＡＦ３０４は、ステップ３１５で、ＱｏＳパラメータを処理してＱｏＳパラメータのポリシーチェックを実行する。ポリシーチェックは、ポリシーメカニズム用に３ＧＰＰによって記述された原則に従って、移動端末ユーザの加入の制限をＱｏＳ要件が受け継いでいないことをチェックするステップを有してもよい。

本発明の一実施形態によると、ポリシーチェックは、また、サービスプロバイダがベアラサービス用として望ましいかまたは必要であると考えるＱｏＳを定義した、一組の所定の最小限度のＱｏＳパラメータを、要求されたＱｏＳパラメータが満たしているか否かを確認するための追加チェックを含んでもよい。この追加チェックにより、要求されたＱｏＳパラメータではサービスプロバイダが望ましいかまたは必要であると考えるＱｏＳを実現できない場合、アプリケーション機能部がＱｏＳ要件の格上げを開始することが可能になる。追加チェックおよび要求されたＱｏＳパラメータを格上げするメカニズムについては、下記で詳細に説明する。

ＡＦ３０４が、要求されたＱｏＳパラメータをチェックした後、ＡＦはステップ３１６で承認メッセージまたは修正メッセージをＰＤＦに返信する。ポリシーチェックにより、要求されたＱｏＳパラメータが適用可能なポリシーを実現しており、また所定の最小限度のＱｏＳパラメータも選択的に実現していると判定した場合、承認メッセージが送信される。要求されたＱｏＳパラメータが、適用可能なポリシーを越えている場合、修正メッセージが送信されてもよい。その場合、修正メッセージは、要求されたＱｏＳパラメータを格下げさせる命令を含むであろう。要求されたＱｏＳパラメータを格下げさせる命令は、ベアラサービスを設定するときに用いられる一組の格下げされたＱｏＳパラメータの形式を採用するものであってもよい。上述したポリシーチェックが、所定の最小限度のＱｏＳパラメータと要求されたＱｏＳパラメータとが一致することをチェックするステップを有する場合であって、もし、サービスプロバイダが望ましいかまたは必要であると定義したＱｏＳよりも要求されたＱｏＳパラメータが悪いＱｏＳをもたらすと判断されたならば、修正メッセージが送信されてもよい。その場合、修正メッセージは要求されたＱｏＳパラメータを格上げさせる命令を含んでもよい。要求されたＱｏＳパラメータを格上げさせる命令は、ベアラサービスを設定するときに用いられる一組の格上げされたＱｏＳパラメータの形式を採用したものであってもよい。

ＡＦ３０４から承認メッセージまたは修正メッセージを受信した後、ＰＤＦ３０３は、ＧＧＳＮに返信する。この例では、ステップ３１７で、ＰＤＦは第２のＰＤＰコンテクストを承認するメッセージをＧＧＳＮに送信する。もしポリシーチェックが、要求されたＱｏＳパラメータを修正する決定をもたらしたならば、ＰＤＦ３０３からＧＧＳＮ３０２へのメッセージは、第２のＰＤＰコンテクストを設定するときに用いられる修正されたＱｏＳパラメータを有していてもよい。

第２のＰＤＰコンテクストの設定は、その後、当業者には周知のＰＤＰコンテクスト設定メッセージによって完了する。これには、ステップ３１８で、ＧＧＳＮが無線ネットワークノードおよびコアネットワークノード（図示していない）を介して端末に返信することが含まれる。ＰＤＰコンテクストが設定されると、ステップ３１９でストリーミングセッションが続くが、ストリーミングコンテンツは、第２のＰＤＰコンテクストによって端末に配信されてもよい。

図３には、要求されたＱｏＳパラメータをチェックするようにＰＤＦ３０３がＡＦ３０４に要求するステップがポリシーチェックに含まれることが例示されている。しかし、このチェックをＰＤＦが行うことも可能である。例えば、ＡＦがＰＤＦからチェック要求を受信したとき、ＡＦは、適用可能なポリシー情報および所定の最小限度のＱｏＳパラメータの組を選択的にＰＤＦに送信してもよい。また、端末ＩＤをＰＤＦに登録するステップ３０８を実行する際に、適用可能なポリシー情報をＰＤＦに転送することも可能である。そうすれば、適用可能なポリシー情報が端末ＩＤと共にＰＤＦの中の登録器に保存されうる。

上述した本発明に係る実施形態の説明の中で、ＡＦとＧＧＳＮはＰＤＦのアドレスを把握していることを前提としていると述べた。例えば、１個のＰＤＦと複数のＧＧＳＮおよび複数のＡＦの間に事前に構築された関係があるようにネットワークアーキテクチャが構成された場合はこれに該当することがある。ただし、その場合、各ＧＧＳＮおよび各ＡＦは、ポリシーコントロールを行うため、１個のＰＤＦとだけ通信するように構成されるべきである。

本発明により提供される、端末ＩＤをバインディング情報として使用するバインディングメカニズムの前提条件は、移動端末が一時にＰＤＰコンテクストのような単一のベアラサービスの起動を要求することである。ＰＤＦ内への端末ＩＤの登録は、できれば、端末が別のベアラサービスの設定を要求でき、新しい要求を適用可能なポリシー情報に正確にマップできるようにポリシーチェックが完了した後で、削除（解除）されるべきである。

サービスプロバイダがベアラサービスにとって望ましいかまたは必要だと考えるＱｏＳに要求されたＱｏＳ要件が一致しているか否かを決定するための上述した追加チェックは、オプションであるが、これによってサービスプロバイダは、先行技術のソリューションが提供する程度を超えてＱｏＳを制御できるため、非常に有利となり得る。ＱｏＳが悪くなるためベアラサービスには不適切だとサービスプロバイダが考えているＱｏＳパラメータに、受信したＳＤＰファイルを端末がマップしないように保証することに、サービスプロバイダが関心を持つことがある。たとえＱｏＳが悪いのは端末の実装の結果であったとしても、ＱｏＳが悪いとサービスプロバイダにも悪い影響がある。ここでは、追加チェックはトークンを知らない端末（すなわち、先行技術のような、許可トークンを知らない端末）と組み合わせて提案されているが、追加チェックは、本明細書で説明した端末ＩＤの代わりに許可トークンをバインディングメカニズムとして利用するシステムに実装されてもよい。

追加チェックを実行することに関心がある場合、要求されたＱｏＳ要件に対してチェックされうる一組の最小限度のＱｏＳパラメータを定義した情報を、ＡＦは、実装すべきである。追加チェックの結果、要求されたＱｏＳパラメータを格上げする決定が行われた場合には、要求されたＱｏＳパラメータの格上げに相当する修正されたＱｏＳパラメータが、ＡＦまたはＰＤＦによって決定されてもよい。また、要求されたＱｏＳパラメータの格上げをＧＧＳＮが処理できるようにＧＧＳＮが実装されることも必要である。このような格上げシナリオには、ＧＧＳＮとその他のコアネットワークノードおよび無線ネットワークノード間に新たな信号が必要となる可能性がある。

図４は、サービスプロバイダまたはＡＦの観点からは要求された帯域幅が低すぎるため、要求されたＱｏＳパラメータが格上げされるというシナリオを例示する概略フロー図である。図４は、移動端末３０１以外に、ＧＧＳＮ３０２、ＰＤＦ３０３、ＡＦ３０４、および無線ネットワークノード４０１、例えば無線ネットワーク制御装置（ＲＮＣ）または無線局制御装置（ＢＳＣ）、そしてＳＧＳＮ（Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）４０２を例示している。セッションデータベース３０５は図４には示されていないが、ＡＦ３０４は特定のセッション情報を検索するためのセッションデータベースへのインタフェースを有してもよい。点線で示す四角の枠４０３は原稿の３ＧＰＰ標準でサポートされるものと比較して、要求されたＱｏＳパラメータの格上げを処理するために必要な新しい信号スキームを囲んでいる。図４に示すステップ４１１から４２４までについて、これから説明する。

ステップ４１１ ユーザの双方向／ブラウジングセッションが確立される。

ステップ４１２ ユーザが「ｒｔｓｐ−ｌｉｎｋ」をクリックする。

ステップ４１３ ストリーミングセッションの確立が行われる。

ステップ４１４ ＡＦ（アプリケーション／ストリーミングサーバ）が端末ＩＤをＰＤＦに登録する（このステップは図３のステップ３０８に対応する）。

ステップ４１５ 端末が第２のＰＤＰコンテクストの起動を要求する（このステップは図３のステップ３１１に対応する）。

ステップ４１６ ＧＧＳＮがＰＤＦとポリシー／ＱｏＳチェックを開始する（このステップは図３のステップ３１２に対応する）。

ステップ４１７ ＰＤＦが、要求されたＱｏＳパラメータによって定義された必要な資源予約は加入の制限内にあることをチェックし、ＡＦに対してチェック要求を発行する（このステップは図３のステップ３１４に対応する）。

ステップ４１８ ＡＦは、満足なエンドユーザＱｏＳを保証するため、サービス回線開設の間帯域幅を格上げする必要があることを理解する。従ってＡＦは、当初要求された端末より広い帯域幅を要求する（このステップは図３のステップ３１６に対応する）。

ステップ４１９ ＰＤＦはＧＧＳＮに返信する。ＧＧＳＮは、帯域幅パラメータが、端末が要求した値より高い値に変更されたのを発見する。従って、ＧＧＳＮは第２のＰＤＰコンテクストの更新を要求する必要がある。

ステップ４２０ ＧＧＳＮは、ＰＤＰコンテクスト更新要求メッセージをＳＧＳＮ４０２に送信することによって、端末が要求した第２のＰＤＰコンテクストの修正（帯域幅の格上げ）を要求し、ＳＧＳＮ４０２はその要求を無線ネットワークノード４０１に転送する。

ステップ４２１ 無線ネットワークノード４０１は、帯域幅パラメータを格上げするのに十分な資源を自分が有しているか否かをチェックする。このシナリオでは、十分な資源を有しており、確認応答を用いてＳＧＳＮへ（およびＳＧＳＮを介してＧＧＳＮへ）返信する。無線ネットワークノードが十分な資源を有していなかった場合、サービスの設定が中断されたり、要求されたサービスが拒否されたりする可能性がある。

ステップ４２２ ＳＧＳＮは、当初、端末が要求したパラメータとは異なる帯域幅パラメータを用いて端末のＰＤＰコンテクスト起動要求に応答する（ステップ４２１と並行して行われる可能性がある）。

ステップ４２３ 端末は「要求を実行する（Play request）」を発行する。

ステップ４２４ アプリケーションセッションが始まる。

上述した追加チェックが希望されてもよい理由は、アプリケーションレベルでのＱｏＳパラメータをベアラサービスＱｏＳパラメータ、例えばＰＤＰコンテクストパラメータに翻訳またはマップを担当するのが、端末だからである。端末内での翻訳／マッピング機能の実装はベンダ独自のものであり、従って端末によって異なることがある。サービスプロバイダが、サービスを要求する端末に関わらず品質の良いサービスの配信に関心があるのなら、追加チェックが望ましいであろう。

アプリケーションレベルＱｏＳパラメータの例は、ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ）向けに定義されたものである。ＵＭＴＳでは、ＵＭＴＳベアラサービスを規定する１組の属性によってＱｏＳが定義されている。ＵＭＴＳのＱｏＳ属性は以下のようである。

−トラヒッククラス
−最大ビットレート
−保証ビットレート
−配信順序
−最大ＳＤＵサイズ
−ＳＤＵフォーマット情報
−ＳＤＵ誤り率
−未解決ビット誤り率
−誤ったＳＤＵの配信
−転送遅延
−トラヒック処理優先順位
−割当または捕捉優先順位
−資源統計記述子
−信号表示
これらの属性は所定のＵＭＴＳ ＱｏＳクラス、すなわち、通話クラス、ストリーミングクラス、双方向クラス、バックグラウンドクラスにマップすることができる。ＵＭＴＳ ＱｏＳについての詳細情報は、技術仕様書３ＧＰＰ ＴＳ２３．１０７Ｖ６.１．０（２００４−０３)および３ＧＰＰ ＴＳ ２３．２０７Ｖ６．２．０（２００４−０３)に記述されている。

ＱｏＳクラスは、ＰＤＰコンテクスト管理を用いてネゴシエーション（交渉）され、管理されてもよい。アプリケーションレベルのＱｏＳの要件は、移動クライアント端末の中のＰＤＰコンテクストパラメータにマップされる。先行技術によるソリューションでは、ＰＤＰコンテクストの事前構成処理はクライアント端末の中で実行されるが、これは、パケット交換型のアプリケーションが起動してネットワークに接続する際に、事前構成されたＰＤＰコンテクストのマッチング処理が起動されるように実行される。このＰＤＰコンテクストは、そのアプリケーションが望むＱｏＳ要件に合致すべきである、選択されたＱｏＳクラスを有している。例えば、そのアプリケーションがＷＡＰブラウザかまたはＭＭＳクライアントであるとすれば、起動されたＰＤＰコンテクストのＱｏＳクラスは、通常は双方向クラスである。

このように、先行技術のソリューションによれば、サービス配信用に設定されたベアラサービスのためのＱｏＳパラメータの選択は、例えば、端末ベンダの移動クライアント端末構成に依存する。サービスプロバイダは、ＱｏＳパラメータの選択に影響を与えることはできない。上述したように、多くの場合、特にサービスプロバイダの観点から、これは問題をはらんでいるが、サービスの配信に適切でないＱｏＳでベアラサービスを設定することにでもなれば、ユーザの立場から見ても問題がある。サービスプロバイダは、通常、提供するサービスが一定の最小限度の品質で配信されることを保証できることに関心がある。サービス品質が悪いと、たとえ悪い品質の原因がネットワークオペレータや端末ベンダであった場合にも、サービスプロバイダの評判に悪影響を及ぼす。ＱｏＳが悪いと、サービスのユーザはいら立ち、品質が悪いと言ってサービスプロバイダを非難するであろう。１つの端末を持つあるユーザがあるサービスコンテンツを受信するとき、承認できないほど悪いＱｏＳになる一方で、別のベンダが提供している端末を持つ別のユーザは、同じサービスコンテンツを受信するとき、承認できるＱｏＳになるということも起こり得る。

しかし、上述したように、本発明の実施形態は、追加チェックを有しており、追加チェックでは、要求されたＱｏＳパラメータをサービスプロバイダが制御でき、必要だと考えられればそれらを修正することもできる。本発明の実施形態によって、端末がアプリケーションレベルのＱｏＳ要件をベアラサービスＱｏＳパラメータに翻訳／マップするときに発生しうる多くの弱点の克服が可能になる。

図面と明細書において、本発明の典型的かつ好適な実施形態を開示してきたが、特定の用語が採用されているとはいえ、それらは一般的な説明の意味でのみ使用しているのであって、限定を目的としているのではない。本発明の範囲は添付の請求項に記載されている。

図１は、３ＧＰＰによって開発されたポリシーコントロールメカニズムに含まれている多様な要素を例示する概略ブロック図である。 図２は、本発明がその中で使われることがある移動通信システムの一般的なネットワークアーキテクチャを例示する概略ブロック図である。 図３は、本発明による方法の一実施形態を例示する概略フロー図である。 図４は、本発明による別の実施形態を例示する概略フロー図である。

Claims (25)

1. アプリケーション機能部（３０４）から移動端末（３０１）にサービスを配信するためにポリシー制御されたベアラサービスを設定する方法であって、
   ポリシー識別情報に関連付けられた前記移動端末（３０１）の端末識別情報をポリシー決定機能部（３０３）に備えられる登録器に登録するステップ（３０８）と、
   前記移動端末（３０１）からコアネットワークノードを介して、前記ベアラサービスに要求される複数のＱｏＳパラメータの１組と前記端末識別情報とを含む、ベアラサービスの起動要求を受信するステップ（３１２）と、
   前記ベアラサービスに適用可能なポリシー情報を決定するため、前記端末識別情報を用いて前記ベアラサービスの起動要求を前記ポリシー識別情報にバインディングするステップ（３１３）と、
   前記ＱｏＳパラメータが前記適用可能なポリシー情報を満たすＱｏｓパラメータであるか否かをチェックすることによってポリシーチェックを実行するステップ（３１４，３１５，３１６）と、
   前記ポリシーチェックが成功した場合、前記ベアラサービスの設定について完了処理を開始するために、承認メッセージをコアネットワークノードに送信するステップ（３１７，３１８）と
   を含むことを特徴とする方法。
2. 前記端末識別情報は、前記移動端末に関連付けられた移動機識別電話番号（ＭＳＩＳＤＮ）、国際移動加入者識別番号（ＩＭＳＩ）又は国際移動機器識別情報（ＩＭＥＩ）のいずれかであることを特徴とする請求項１に記載の方法。
3. 前記ポリシー識別情報は、前記アプリケーション機能部（３０４）のアドレスを含み、
   前記ベアラサービスの起動要求を前記ポリシー識別情報にバインディングするステップ（３１３）は、前記ポリシー識別情報に含まれていた前記アドレスによって特定された前記アプリケーション機能部（３０４）からの前記適用可能なポリシー情報を要求するステップ（３１４）を含むことを特徴とする請求項１又は２に記載の方法。
4. 前記ポリシー識別情報は、設定対象の前記ベアラサーサービス用の前記適用可能なポリシー情報を含むことを特徴とする請求項１又は２に記載の方法。
5. 前記ポリシーチェックを実行するステップは、
   前記要求されたＱｏＳパラメータが、前記アプリケーション機能部から提供された所定の最低限度のＱｏＳ要件を満たすか否かをチェックするステップ（３１５）を含むことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
6. 前記要求されたＱｏＳパラメータが前記最低限度のＱｏＳ要件を満たしていない場合に、前記最低限度のＱｏＳ要件に合致するよう修正された複数のＱｏＳパラメータの組を決定するステップと、
   前記ベアラサービスを設定するときに使用するために、前記コアネットワークノード（３０２）へ前記修正された複数のＱｏＳパラメータの組を送信するステップ（３１６、３１７）と
   をさらに含むことを特徴とする請求項５に記載の方法。
7. 前記コアネットワークノードは、関門ＧＰＲＳサポートノード（ＧＧＳＮ）であることを特徴とする請求項１乃至６のいずれか１項に記載の方法。
8. 前記ポリシーチェックを実行するステップの後で、前記ポリシー決定機能部（３０３）の前記登録器から、前記端末識別情報と前記ポリシー識別情報との登録を解除するステップ（３１４，３１５，３１６）と
   をさらに含むことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
9. 前記ベアラサービスは、パケットデータプロトコル（ＰＤＰ）コンテクストであることを特徴とする請求項１乃至８のいずれか１項に記載の方法。
10. ポリシー決定機能部（３０３）において、アプリケーション機能部（３０４）から移動端末（３０１）にサービスを配信するためのベアラサービスについてポリシー制御を実行する方法であって、
    端末識別情報とポリシー識別情報を有する登録メッセージを受信するステップ（３０８）と、
    前記ポリシー識別情報に関連付けて前記端末識別情報を登録器に登録するステップと、
    前記移動端末（３０１）からコアネットワークノード（３０２）を介して、前記ベアラサービスに要求される複数のＱｏＳパラメータの１組と前記端末識別情報とを含む、ベアラサービスの起動要求を受信するステップ（３１２）と、
    前記ベアラサービスに適用可能なポリシー情報を決定するため、前記端末識別情報を用いて前記登録器内で前記ベアラサービスの起動要求を前記ポリシー識別情報にバインディングするステップ（３１３）と、
    前記ＱｏＳパラメータが前記適用可能なポリシー情報を満たすＱｏｓパラメータであるか否かをチェックすることによってポリシーチェックを実行するステップ（３１４）と、
    前記ポリシーチェックが成功した場合、前記ベアラサービスの設定について完了処理を開始するために、承認メッセージをコアネットワークノード（３０２）に送信するステップ（３１７，３１８）と
    を含むことを特徴とする方法。
11. 前記端末識別情報は、前記移動端末に関連付けられた移動機識別電話番号（ＭＳＩＳＤＮ）、国際移動加入者識別番号（ＩＭＳＩ）又は国際移動機器識別情報（ＩＭＥＩ）のいずれかであることを特徴とする請求項１０に記載の方法。
12. 前記ポリシー識別情報は、前記アプリケーション機能部（３０４）のアドレスを含み、
    前記ベアラサービスの起動要求を前記ポリシー識別情報にバインディングするステップ（３１３）は、前記ポリシー識別情報に含まれていた前記アドレスによって特定された前記アプリケーション機能部（３０４）からの前記適用可能なポリシー情報を要求するステップ（３１４）を含むことを特徴とする請求項１０又は１１に記載の方法。
13. 前記ポリシー識別情報は、設定対象の前記ベアラサーサービス用の前記適用可能なポリシー情報を含むことを特徴とする請求項１０又は１１に記載の方法。
14. 前記ポリシーチェックを実行するステップは、
    前記要求されたＱｏＳパラメータが、前記アプリケーション機能部から提供された所定の最低限度のＱｏＳ要件を満たすか否かをチェックするステップ（３１５）を含むことを特徴とする請求項１０乃至１３のいずれか１項に記載の方法。
15. 前記要求されたＱｏＳパラメータが前記最低限度のＱｏＳ要件を満たしていない場合に、前記最低限度のＱｏＳ要件に合致するよう修正された複数のＱｏＳパラメータの組を決定するステップと、
    前記ベアラサービスを設定するときに使用するために、前記コアネットワークノード（３０２）へ前記修正された複数のＱｏＳパラメータの組を送信するステップ（３１６、３１７）と
    をさらに含むことを特徴とする請求項１４に記載の方法。
16. 前記コアネットワークノードは、関門ＧＰＲＳサポートノード（ＧＧＳＮ）であることを特徴とする請求項１０乃至１５のいずれか１項に記載の方法。
17. 前記ポリシーチェックを実行するステップの後で、前記ポリシー決定機能部（３０３）の前記登録器から、前記端末識別情報と前記ポリシー識別情報との登録を解除するステップ（３１４，３１５，３１６）と
    をさらに含むことを特徴とする請求項１０乃至１６のいずれか１項に記載の方法。
18. 前記ベアラサービスは、パケットデータプロトコル（ＰＤＰ）コンテクストであることを特徴とする請求項１０乃至１７のいずれか１項に記載の方法。
19. アプリケーション機能部（３０４）から移動端末（３０１）にサービスを配信するためのベアラサービスについてポリシー制御を実行するポリシー決定装置（３０３）であって、
    端末識別情報とポリシー識別情報を有する登録メッセージを受信する第１インタフェースと、
    ポリシー識別情報に関連付けられた前記移動端末（３０１）の端末識別情報を登録する登録器と、
    前記移動端末（３０１）からコアネットワークノード（３０２）を介して、前記ベアラサービスに要求される複数のＱｏＳパラメータの１組と前記端末識別情報とを含む、ベアラサービスの起動要求を受信する第２インタフェースと、
    前記ベアラサービスに適用可能なポリシー情報を決定するため、前記端末識別情報を用いて前記ベアラサービスの起動要求を前記ポリシー識別情報にバインディングするとともに、前記ＱｏＳパラメータが前記適用可能なポリシー情報を満たすＱｏｓパラメータであるか否かをチェックすることによってポリシーチェックを実行し、さらに、前記ポリシーチェックが成功した場合、前記ベアラサービスの設定について完了処理を開始するために、承認メッセージをコアネットワークノードに送信する処理手段と
    を含むことを特徴とするポリシー決定装置。
20. 前記端末識別情報は、前記移動端末に関連付けられた移動機識別電話番号（ＭＳＩＳＤＮ）、国際移動加入者識別番号（ＩＭＳＩ）又は国際移動機器識別情報（ＩＭＥＩ）のいずれかであることを特徴とする請求項１９に記載のポリシー決定装置。
21. 前記ポリシー識別情報は、前記アプリケーション機能部（３０４）のアドレスを含み、
    前記処理手段は、前記ポリシー識別情報に含まれていた前記アドレスによって特定された前記アプリケーション機能部（３０４）からの前記適用可能なポリシー情報を要求するよう構成されていることを特徴とする請求項１９又は２０に記載のポリシー決定装置。
22. 前記ポリシー識別情報は、設定対象の前記ベアラサーサービス用の前記適用可能なポリシー情報を含むことを特徴とする請求項１９又は２０に記載のポリシー決定装置。
23. 前記処理手段は、前記要求されたＱｏＳパラメータが、前記アプリケーション機能部から提供された所定の最低限度のＱｏＳ要件を満たすか否かをチェックするよう構成されていることを特徴とする請求項１９乃至２２のいずれか１項に記載のポリシー決定装置。
24. 前記処理手段は、前記要求されたＱｏＳパラメータが前記最低限度のＱｏＳ要件を満たしていない場合に、前記最低限度のＱｏＳ要件に合致するよう修正された複数のＱｏＳパラメータの組を決定し、前記コアネットワークノード（３０２）へ、前記ベアラサービスを設定するときに使用される、前記修正された複数のＱｏＳパラメータの組を送信するよう構成されていることを特徴とする請求項２３に記載のポリシー決定装置。
25. 前記処理手段は、該処理手段が前記ポリシーチェックを完了した後で、前記登録器から、前記端末識別情報と前記ポリシー識別情報との登録を解除するよう構成されていることを特徴とする請求項１９乃至２４のいずれか１項に記載のポリシー決定装置。

Images