JP2008505530A - サービス品質を変更する方法および装置 - Google Patents

Abstract

本発明は送信を変化する送信能力要求に適応させるためのサービス品質パラメータの変更に関する。本発明に従う方法は進行中の通信セション中に適用可能である。少なくとも１つのクライアント端末１０５はネットワークノード３１０を介して提供されたサービスを利用し、かつ初期のサービス品質パラメータが使用される。クライアント端末から発せられたコンテンツ要求に応答する処理において、この方法は、コンテンツ要求への応答の配信が品質サービスパラメータの修正から益を得られるか否かを判断する（５１５）。もし、その修正が有益であると判断されたならば、その方法は、コンテンツ要求への応答に使用するサービス品質パラメータの修正を開始する（５２０）。

Description

関連出願への相互参照
本願は、同一出願人による係属中の２００４年７月５日出願の発明の名称を「通信ネットワークにおけるサービス品質管理のためのバインディング機構（Binding Mechanism for Quality of Service Management in a Communication Network）」という国際特許出願番号“ＰＣＴ／ＳＥ０４／＿＿”、２００４年７月５日に出願の発明の名称を「サービス品質パラメータをＨＴＴＰメッセージの中に供給するための方法と装置（Methods and Devices for Supplying Quality of Service Parameters in HTTP Messages）」という国際特許出願番号“ＰＣＴ／ＳＥ０４／＿＿”、そして、２００４年７月５日出願の発明の名称を「プッシュメッセージによって開始されるサービスのための装置および方法（Devices and Methods for Push Message Initiated Service）」という国際特許出願番号“ＰＣＴ／ＳＥ０４／＿＿”と関係しており、それらの開示は参照により本願に組み込まれる。

本発明はパケットデータサービスを提供する移動通信システムにおける方法と装置に関するものである。特に、本発明は、変化する送信能力の需要に送信を適応させるためにサービス品質パラメータを変更することに関する。

全球規模移動体通信システム（ＵＭＴＳ）のようなパケット交換サービスを提供する現代の移動通信システムは、例えば、必要な送信能力、送信の遅延に対する感度、インタラクティブ性の要求などについてのさまざまな要求がある多数の多様なアプリケーションをサポートすることができなければならない。そのアプリケーションは、高い能力や時間の厳密性を必要としないアプリケーションの一例であるテキストメッセージの単純な転送から、高度な送信能力を必要とするリアルタイムアプリケーションであるテレビ会議まで、多岐にわたる。サービス品質（ＱｏＳ）という概念は、アプリケーションを実行するエンドユーザがその特定のアプリケーションに必要なシステム資源を受け取ることを保証するために導入されたものである。同時に、そのアプリケーションに必要な程度以上の資源を使用しないことによって、ＱｏＳの使用は、システム資源、特に、少ない無線資源の使用の最適化に貢献する。どのようにＱｏＳがＵＭＴＳで実現されるかについては、非特許文献１と非特許文献２とに記述されている。

図１に図解するのは、ＱｏＳが利用されている一般的な移動通信システムである。移動通信システム１００は、例えば、アプリケーションサーバ１２０のようなネットワークノードと通信して、例えば、サービスプロバイダによって提供されるサービスを用いることができるクライアント端末１０５を含んでいる。クライアント端末１０５は、それらに限定されるものではないが、携帯（セルラ）電話、通信機能を備えたノートパソコンやＰＤＡなどを含む種々の機器を表わしていると考えるべきであり、また、一般にユーザ機器（ＵＥ）あるいは移動局（ＭＳ）とも呼ばれる。クライアント端末１０５とアプリケーションサーバ１２０との間の通信を提供するため、無線アクセスネットワーク（ＲＡＮ）１２５、コアネットワーク（ＣＮ）１３０、およびサービスネットワーク（ＳＮ）１３５が関与しており、相互作用している。

ＵＭＴＳでは、ＱｏＳはＵＭＴＳベアラサービスを規定する１組の属性によって定義されている。ＵＭＴＳのＱｏＳ属性は以下の通りである。

−トラヒッククラス
−最大ビットレート
−保証ビットレート
−配信順序
−最大ＳＤＵサイズ
−ＳＤＵフォーマット情報
−ＳＤＵ誤り率
−未解決ビット誤り率
−誤ったＳＤＵの配信
−転送遅延
−トラヒック処理優先順位
−割当／捕捉優先順位
−資源統計記述子
−シグナリング表示
これらの属性は所定のＵＭＴＳ ＱｏＳクラス、即ち、会話クラス、ストリーミングクラス、インタラクティブクラス、バックグラウンドクラスにマップすることができる。ＱｏＳクラスはパケットデータプロトコル（ＰＤＰ）コンテキストによって通信システムに指定される。

図２は、ＵＭＴＳにおけるクライアント端末１０５とアプリケーションサーバ１２０との間の通信を概略的に図示している。通信は、ＲＮＣ（無線ネットワーク制御装置）２０５と主要なノードであるＳＧＳＮ（サービングＧＰＲＳサポートノード）２１０およびＧＧＳＮ（ゲートウェイＧＰＲＳサポートノード）２１５を介してＳＮ１３５の中のアプリケーションサーバ１２０に対して発生する。

従来技術におけるＵＭＴＳでの実施では、ＱｏＳクラスは、ＰＤＰコンテキスト管理を用いてネゴシエーションされ管理される。アプリケーションレベルのＱｏＳの要件は、クライアント端末の中のＰＤＰコンテキストパラメータにマップされる。パケット交換アプリケーションを起動してネットワークに接続する時にマッチングする事前構成されたＰＤＰコンテキストが起動されるように、ＰＤＰコンテキストの事前構成がクライアント端末の中で行われる。このＰＤＰコンテキストは、そのアプリケーションの望ましいＱｏＳ要件に合致すべき選択されたＱｏＳクラスを有している。例えば、そのアプリケーションがＷＡＰブラウザかまたはＭＭＳクライアントであるとすれば、起動されたＰＤＰコンテキストのＱｏＳクラスは、通常はインタラクティブクラスである。図２に矢印２２０で示したのがＰＤＰコンテキストであり、必要なＱｏＳクラスを定義していて、クライアント端末１０５から発信され、ＧＧＳＮ２１５によって受信される。

今日、アプリケーションあるいはサービスノード、例えば、ＷＷＷサーバは、クライアント端末の中でセション記述プロトコル（ＳＤＰ）によって実行されるＱｏＳクラスの選択に影響を及ぼすことがある。ＷＷＷサーバは、ストリーミングセションを実施するために、例えば、すでに使用中のものよりもっとダウンロードに適した別のベアラを使用しようとすることがある。そのとき、ＷＷＷサーバは、ＳＤＰ文書をクライアント端末に対して発行し、望ましいＱｏＳクラスを指定することがある。続いて、クライアント端末は、ダウンロードが実行される前に実際のＱｏＳの変更を開始しなければならない。
技術仕様書３ＧＰＰ ＴＳ２３．１０７Ｖ６.１．０（２００４−０３) 技術仕様書３ＧＰＰ ＴＳ２３．２０７Ｖ６.２．０（２００４−０３)

上述のようにシステムは、必要なＱｏＳを決定したりＳＤＰメッセージの中のＱｏＳ情報を正しく処理したりして、ＲＮＣ２０５、ＳＧＳＮ２１０およびＧＧＳＮのようなシステムノードとネゴシエーションするのを、すべての端末に任せている。しかし、多数のベンダからの多数の多様な３Ｇ端末を扱うシナリオにおいては、すべての端末がその標準に完全に準拠しているのではないというのがもっともなことである。そうは言ってもやはり、サービスプロバイダにとって、例えば、提供されたアプリケーションがエンドユーザによって正確に使用されることを保証できることは非常に重要だと言えよう。さらに、ＱｏＳ要件の一定の変更が望ましい場合でも、それは端末には容易に予測できないであろう。

本発明の目的は、サービスネットワークの中のネットワークノードまたはネットワークノード内のアプリケーションが、クライアント端末とアプリケーションとの間のベアラサービスのための適切なＱｏＳパラメータを決定してサービス品質の更新を開始できるようにする装置と方法を提供することである。

上述の目的は、請求項１に従うネットワークノードの中の方法、請求項２３に従うネットワークノード、そして、請求項２１および２２に従うコンピュータプログラムによって実現される。

本発明の基本的な考え方とは、ネットワークノードが、進行中の通信セション中にサービス品質パラメータを変更するための要件を特定してサービス品質パラメータの修正を開始できるために、ネットワークノードにおける方法と構成を提供することである。その処理は、ネットワークノード内のアプリケーションによって開始され制御される。本発明に従うネットワークノードにおける方法では、クライアント端末から発行されるコンテンツ要求に応答する処理において、そのコンテンツ要求に対する応答の配信がサービス品質パラメータの修正によって利益を得るか否かを判断する。修正すると利益があると判断されたなら、そのコンテンツ要求への応答に使用されるサービス品質パラメータの修正がネットワークノードによって開始される。

本発明を第１の側面から見れば、ネットワークノードに１つの方法が提供される。この方法は進行中の通信セション中に適用可能であり、少なくとも１つのクライアント端末がそのネットワークノードを介して提供されるサービスを利用し、また、進行中の通信セションでは初期のサービス品質パラメータが使用される。クライアント端末から発行されるコンテンツ要求に応答する処理において、この方法は、
−クライアント端末がコンテンツ要求を発行した時点で、前記要求に対する応答に関連する第２のサービス品質パラメータを決定する工程と、
−サービス品質パラメータを修正するための要件を判断するために、初期のサービス品質パラメータと第２のサービス品質パラメータとを比較する工程と、
−前記比較／決定する工程において、修正の要件が特定されたならば、初期のサービス品質パラメータから第２のサービス品質パラメータへの更新命令をクライアント端末に対して発行することによって、サービス品質パラメータを修正する工程とを、
有する。

それによって、この方法は、コンテンツタイプとコンテンツサイズとの内の少なくともいずれかにより適した第２のサービス品質パラメータを利用することで、コンテンツ要求への応答の配信を円滑にする。サービス品質パラメータを比較する工程は、できれば、初期のサービス品質パラメータについての情報をセションデータベースから取り出す工程を有することが好ましい。この方法はさらに、前記要求への応答が完了した後に初期のサービス品質パラメータの使用へと復帰する工程を含むことが都合がよい。

本発明の方法を第２の側面から見れば、サービス品質パラメータを比較する工程において、もし初期のサービス品質パラメータが第２のサービス品質パラメータに相当する転送速度より低い転送速度に相当するならば、サービス品質パラメータを修正する要件が識別される。初期および第２のサービス品質パラメータは、例えば、サービス品質のクラス、例えば、会話クラス、ストリーミングクラス、インタラクティブクラス、バックグラウンドクラスを有する所定のＵＭＴＳサービス品質クラスようなサービス品質クラスを参照してもよい。

本発明の方法を第３の側面から見れば、第２のＱｏＳパラメータを決定する工程は、
−コンテンツおよび少なくともコンテンツのファイルタイプに関する情報を有するメッセージを第２のネットワークから受信する工程と、
−そのコンテンツのファイルタイプに関する情報に基づいて、ファイルタイプを適切なＱｏＳパラメータにリンクさせている所定のリストとの比較によって第２のＱｏＳパラメータを決定する工程と、
を有する。

本発明の方法を第４の側面から見れば、第２のＱｏＳパラメータを決定する工程は、
−コンテンツ要求の応答として第２のネットワークノードからメッセージを受信する工程と、
−必要なＱｏＳパラメータに関する情報をメッセージから読み取って、必要なサービス品質パラメータに関する情報に基づいて、第２のＱｏＳパラメータを決定する工程とを有し、
要求されたコンテンツとそのコンテンツをクライアント端末に配信するために必要なＱｏＳパラメータに関する情報とはそのメッセージの中に含まれている。

本発明に従うネットワークノードを１つの側面から見れば、そのネットワークノードは
−クライアント端末によって発行されたコンテンツ要求に応じて、前記要求されたコンテンツに関連する第２のサービス品質パラメータを決定するように適合されたサービス品質決定手段と、
−更新ＰＤＰコンテキストメッセージを利用して、初期のサービス品質パラメータから第２のサービス品質パラメータへの更新命令を発行するように適合されたサービス品質修正手段と、
を備えている。

本発明により、コンテンツ要求に対する応答が進行中の通信セション中にサービス品質パラメータの変更から益が得られることを、ネットワークノードが識別することができるかもしれない。適切であるならば、そのネットワークノードはサービス品質パラメータの変更を開始して実行する。

本発明によって得られる１つの利点は、閲覧−ダウンロードのシナリオにおいて通常発生するベアラ能力に対する要求の変化に対して通信システムがより良く適応できるということであり、メディアファイルはネットワークノードを介してクライアント端末にダウンロードされる。

更なる利点には、本発明によれば、明らかに必要とされていないときには不要に高いサービス品質、即ち、高ベアラ能力が避けられるので、少ない無線資源の一層効率的な利用が可能になることがある。

また更なる利点には、高ベアラ能力は明白に必要なときに限って使用されるため、電力消費を最小限に維持できることがある。これは、バッテリ寿命が延びるため、ユーザ機器にとって最も重要である。

本発明の実施例の更なる利点と特徴については、添付図面に関連した以下の詳細な説明を読むと明らかになるであろう。

ここからは、本発明について添付図面を参照しながら詳しく説明する。その図面には、本発明の好適な実施例が示されている。しかしながら、本発明は、多くの異なる形態で実施することができ、この明細書で説明した実施例に限られると解釈されてはならない。むしろ、これらの実施例は、この開示が徹底的かつ完全であり、本発明の範囲を当業者に十分に伝えるように備えられたものである。図面においては、同じ参照番号は同じ要素に言及している。

本発明は移動通信システムにおけるパケット交換サービスに適用可能であり、そのサービスは通常、サービスプロバイダによって提供され、クライアント端末の助けを借りてエンドユーザによって利用される。特に、本発明は、エンドユーザがウェブページなどを閲覧して、以下メディアファイルとして言及する、音楽、絵、動画クリップのようなコンテンツを見つけてダウンロードするというシナリオに関するものであるが、それに限定されることはない。送信能力に関する要求が大きく変動するという特徴がある利用について、「ベストエフォート」送信は閲覧に関しては十分であることが多い一方で、例えば、メディアファイルのダウンロードはその送信能力に非常に大きい要求を課する。背景技術の項で説明したとおり、従来技術の方法と構成では、メディアファイルのダウンロードのような特定のアプリケーション中の送信能力の要求の急速な変化に対処できない。

大局的に説明したとおり、本発明は、進行中の通信セション中にネットワークノードがサービス品質パラメータを変更する要件を識別して、サービス品質パラメータの修正を開始できるためにネットワークノードにおける方法と構成を提供する。この処理はネットワークノード或はネットワークノード内のアプリケーションによって開始され、制御される。本発明に従うネットワークノードにおける方法は、クライアント端末から発行されるコンテンツ要求に応答する処理において、そのコンテンツ要求に対する応答の配信がサービス品質パラメータの修正によって益を得るか否かを判断する。その修正には益があると判断されたなら、コンテンツ要求への応答に使用されるサービス品質パラメータの修正がネットワークノードによって開始される。

図３は本発明が用いられる移動通信システムの概略図である。移動通信システム１００はクライアント端末１０５を有し、クライアント端末１０５はサービスプロバイダのネットワークノード３１０と通信し、それによってサービスプロバイダが提供するサービスを受ける。ネットワークノード３１０は通常、ＷＷＷサーバ３２０を利用する時のクライアント端末１０５のプロキシである。クライアント端末１０５とネットワークノード３１０との間の通信には通常、別個であるが相互接続された３つのネットワークである無線アクセスネットワーク（ＲＡＮ）１２５、コアネットワーク（ＣＮ）１３０、そして、サービスネットワーク（ＳＮ）１３５が関係する。考えられる無線アクセスネットワーク１２５には、ＷＣＤＭＡ、ＣＤＭＡ２０００、無線ＬＡＮ、またはＧＰＲＳネットワークが含まれるが、それらに限定されることはない。コアネットワークとサービスネットワークは、ＩＰベースの通信ネットワークまたはＡＴＭベースの通信ネットワークとして広く実現されている。

クライアント端末１０５は、無線アクセスネットワーク（ＲＡＮ）１２５に常駐しており、無線アクセスネットワーク（ＲＡＮ）１２５は、コアネットワーク１３０のサービングＧＰＲＳサポートノード（ＳＧＳＮ）２１０と通信している少なくとも１つの無線ネットワーク制御局（ＲＮＣ）２０５によって制御されている。ＣＮ１３０はゲートウェイノードを介して他のネットワークと通信している。ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）２１５は、ＣＮ１３０をサービスネットワーク１３５と相互接続している。このＧＧＳＮはさらにセションデータベース３１７と通信することもある。クライアント端末１０５と通信しているネットワークノード３１０またはプロキシは、サービスネットワーク１３５の一部であり、実際のサービスを提供している更なるネットワークノード、例えば、ＷＷＷサーバ３２０、ＭＭＳサーバ３２５、あるいは他のタイプのアプリケーションサーバと接続されることがある。それらはすべて、サービスネットワーク１３５の一部である。ネットワークノード３１０またはプロキシはまた、サービスネットワーク１３５の一部ではなく外部ネットワーク３３５に属するサーバに接続することがある。

本発明に従う方法と構成について、ＵＭＴＳネットワークにおいて、図４に描かれた概略シグナリング方式と図５ａのフローチャートを参照しながら説明する。本発明の実施例が図５ｂ及び図６に図示されている。

本発明に従う方法は、図４のシグナリング方式によって図示されているようにクライアント端末１０５とネットワークノード３１０との間の通信セション中に適用可能である。アプリケーション層では、通信は、例えば、ブラウザ４０５のような端末アプリケーションとサービスプロバイダ４１０のアプリケーションとの間で、ネットワークノード３１０の中のプロキシアプリケーション４１５を経由して行われる。通信セションは、公知の技術である標準的手順に従ってセットアップされる。従って、本発明の方法を理解するのに必要なセットアップ手順のステップだけを説明する。通信セションをセットアップするステップは本発明の一部とはみなされてはならない。

通信セションは通常、エンドユーザが、例えば、ＷＥＢブラウザ４０５を起動させることによって、クライアント端末１０５の中のパケットサービスアプリケーションを開始することから始まる。ＵＭＴＳでは、ＰＤＰコンテキスト管理が用いられて、数あるパラメータの中でも適切なＱｏＳクラスでセションをセットアップする。クライアント端末１０５でアプリケーションが起動されると通常、アプリケーションＱｏＳ要件と合致すべきＱｏＳクラスを指定する事前に構成されたＰＤＰコンテキストの起動によって、アプリケーションレベルＱｏＳ要件がクライアント端末のＰＤＰコンテキストパラメータにマップされる。図４のセットアップ部分４０７に示すように、ＳＧＳＮ２１０とＧＧＳＮ２１５に関与するネゴシエーション処理が、通信セションの中で使われる初期ＱｏＳパラメータを確立する。ＧＧＳＮはＰＤＰコンテキスト情報を、矢印４１０で示すように、セションデータベースに保存する。セットアップ完了後、通信セションはアプリケーションレベル通信の確立を進める。それは、この例では、矢印４１５で示す、クライアント端末１０５の中のアプリケーション（ブラウザ）とネットワークノード３１０のプロキシアプリケーションとの間のＷＥＢ閲覧セションである。

ウェブ閲覧中は、コンテンツ要求、例えば、矢印４２０のＷＷＷサーバからメディアファイルをダウンロードするという要求は、クライアント端末１０５のアプリケーションから発行される。コンテンツ要求の一例として、ネットワークノード３１０のプロキシアプリケーションに対して発行される「コンテンツを入手する（Ｇｅｔ ｃｏｎｔｅｎｔ）」メッセージがある。

ネットワークノード３１０は、要求されたコンテンツを、例えば、サービスプロバイダサーバ（不図示）から取り出すことによって、そのコンテンツ要求に応答し、コンテンツに関連した第２のＱｏＳパラメータを決定する（４２５）。ＱｏＳパラメータとコンテンツの関連については、下記でさらに検討する。

ネットワークノード３１０はさらに、初期ＱｏＳパラメータと第２のＱｏＳパラメータを比較することによって、セションで用いるＱｏＳパラメータの修正がクライアント端末１０５へのコンテンツの配信に利益をもたらすか否かを判断する。ネットワークノード３１０は、矢印４３０で示されるように、セションデータベース３１７に格納されたＰＤＰコンテキスト情報から初期のＱｏＳパラメータに関する情報を取り出すことが望ましい。

もしネットワークノード３１０が第２のＱｏＳパラメータへの変更を行うと判断したならば、例えば、もし初期のＱｏＳパラメータが第２のＱｏＳパラメータよりも低いＱｏＳクラスに相当するならば、ネットワークノード３１０はそのセションで使用されるＱｏＳパラメータを修正する処理（４４０）を開始する。ネットワークノード３１０は、ＰＤＰコンテキストの更新命令をＧＧＳＮ２１５に対して発行する。ネットワークノード３１０は、どのＧＧＳＮ２１５にアドレス指定するかについての情報を必要としており、できればＧＧＳＮ２１５がクライアント端末１０５を識別するのに使用する情報も含んでいることが望ましい。できれば、ネットワークノード３１０はこの情報をセションデータベース３１７から取りだすことが望ましいが、これについては下記でさらに検討する。さらなるＰＤＰ更新処理である矢印４４０：２、３、４、５、６は、ＧＧＳＮ２１５、ＳＧＳＮ２１０、ＲＮＣ２０５およびクライアント端末が関与し、標準的手順に従って実行されるので、当業者には周知である。ＧＧＳＮ２１５はクライアント端末１０５によって発行されたＰＤＰコンテキスト応答を転送し、ネットワークノード１００に更新処理の結果を矢印４４０：７で知らせる。

更新処理の結果は、第２のＱｏＳパラメータによって定義された要求されたＱｏＳに従って通信が現在発生しているか、あるいは、例えば、無線環境の一時的な制約のために要求された更新に従うことが出来なかったかのいずれかである。後者の場合、更新処理は要求されたもの（第２のＱｏＳパラメータ）より低いＱｏＳに終わる結果となる可能性があるが、場合によっては初期ＱｏＳパラメータより高くなることもある。その後、ネットワークノード３１０は、利用可能なＱｏＳでコンテンツを配信すべきか、あるいは、処理を中止すべきかを決定する必要がある。ほとんどの場合、一定の転送速度未満では、メディアファイルは事実上転送不可能であるか、少なくとも非常に不都合なものとなるであろう。従って、ネットワークノード３１０は、適当なＱｏＳが使用できないならば、ほとんどの場合、配信処理を中止することを選択すべきである。要求されたものより低いＱｏＳが依然として当該コンテンツ（ファイルタイプ）のために使用できるか否かについての情報は、第２のＱｏＳパラメータに含まれていても良いし、他の手段でネットワークノード３１０に伝達されてもよい。

ネットワークノード３１０のアプリケーションはさらに、要求されたＱｏＳがクライアント端末１０５の機能およびエンドユーザの加入制限に従っているかどうかをチェックすることがある。それはポリシーチェックとよく言われるプロセスであり、当技術分野では既知である。本発明において都合良く利用される改良されたポリシーチェックが、上記言及した出願「通信ネットワークにおけるサービス品質管理のためのバインディング機構（Binding Mechanism for Quality of Service Management in a Communication Network）」の中で教示されている。

ＰＤＰコンテキスト更新が完了すると、矢印４５０のとおり、ネットワークノード３１０は要求されたコンテンツをクライアント端末１０５に配信するが、ここでは第２のＱｏＳパラメータが使用される。

メディアファイルの配信を完了した後、ネットワークノード３１０は、例えば、初期ＱｏＳパラメータへの復帰を開始しても良い（４６０）。これは、上記のＰＤＰコンテキスト更新と同じＰＤＰコンテキスト更新によって実行される。

本発明の方法に従う、通信セション中のＱｏＳを変更する処理は、ネットワークノード３１０から開始され制御される。ネットワークノード３１０における方法は、図５のフローチャートに説明されており、それは以下のステップを有する。

ステップ５０５：クライアント端末１０５によって発行されたコンテンツ要求に対して、要求されたコンテンツに関連する第２のＱｏＳパラメータ、または第２のＱｏＳパラメータの表現を決定する。

ステップ５１０：初期のＱｏＳパラメータを第２のＱｏＳパラメータと比較する。

ステップ５１５：ステップ５１０での比較に基づいて、ＱｏＳパラメータを更新すべきか否かを判断する。もし、第２のＱｏＳパラメータが、使用中のＱｏＳ（初期のＱｏＳパラメータ）より高いＱｏＳを、即ち、より高いベアラ能力を必要とするＱｏＳを示すならば、コンテンツ配信を実行するためにＱｏＳパラメータを更新する要件が識別される。そうでないならば、コンテンツ配信は初期のＱｏＳパラメータで実行してもよい。即ち、ＱｏＳパラメータを更新する必要はない。

ステップ５２０：もし決定するステップにおいて修正の要件が識別されたならば、初期のサービス品質パラメータから第２のサービス品質パラメータへの更新命令を発行することによって、サービス品質パラメータの修正を開始する。

ステップ５２５：要求されたコンテンツを、第２のＱｏＳパラメータを用いてクライアント端末１０５へと配信する。

この方法は、加えて、以下のオプションのステップを含んでも良い。

ステップ５２２：任意で、ＰＤＰ情報を第２のＱｏＳパラメータで更新するために、セションデータベース３１７にアクセスする。これは修正を行うステップ５２０の後で、かつ、配信するステップ５２５の前にとられるステップである。

ステップ５３０：ステップ５２０と同様に、第２のＱｏＳパラメータから初期のＱｏＳパラメータへと更新を発行することによって、初期のＱｏＳパラメータの使用に復帰する。これは配信するステップ５２５の後にとられるステップである。

初期のＱｏＳパラメータを第２のＱｏＳパラメータと比較するステップ５１０は、以下のステップを含んでも良い。

ステップ５１０：１ 通信セションに関連するＰＤＰ情報を取りだすために、セションデータベース３１７にアクセスする。

ステップ５１０：２ ＰＤＰ情報から初期のＱｏＳパラメータを読み取る。ＱｏＳは、３ＧＰＰ ＴＳ ２４．００８の中で定義されている“ネゴシエーションされたＱｏＳ”として保存されることが望ましい。

ステップ５１０：３ 任意で、ＰＤＰ情報からアドレス指定情報を読み取る。

ＱｏＳパラメータが更新されるべきか否かを決定するステップ５１５は、以下のステップを含んでいても良い。

ステップ５１５：１ 初期のＱｏＳパラメータへ任意で復帰する際に使用される初期のＱｏＳパラメータを一時的に保存する。

ステップ５１０：３において、ネットワークノード３１０が任意で読み取った情報は、主として、アプリケーションがエンドユーザのＧＧＳＮ２１５を見つけ、そして、ＧＧＳＮ２１５がその要求を正しいＧＴＰ（ＧＰＲＳトンネルプロトコル）にマップするため、即ち、クライアント端末１０５に関連するＧＴＰを見つけるために用いられても良い。表１は、進行中の通信セションに関連するセションデータベース３１７のＰＤＰ情報の中に（他の情報と共に）含まれているアドレス指定に関する情報を規定している。

表１ セションデータベースの属性
┌−−−−−−−−−−−−−┬−−−−−−−−−−−−−−−−−−−−−−−┐
｜ ｜要求を送信したＲＡＤＩＵＳクライアントの ｜
｜ＮＡＳ ＩＰアドレス ｜ＩＰアドレス。これは通常、ＩＡＳまたは ｜
｜ ｜ＧＧＳＮである。 ｜
├−−−−−−−−−−−−−┼−−−−−−−−−−−−−−−−−−−−−−−┤
｜ＩＰアドレス ｜端末に割り当てられるＩＰアドレス。 ｜
├−−−−−−−−−−−−−┼−−−−−−−−−−−−−−−−−−−−−−−┤
｜発信局Ｉｄ（ＭＳＩＳＤＮ）｜接続された端末のＭＳＩＳＤＮ ｜
├−−−−−−−−−−−−−┼−−−−−−−−−−−−−−−−−−−−−−−┤
｜ＩＭＳＩ ｜国際移動加入者ＩＤ ｜
｜ ｜(The International Mobile Subscriber Identity)｜
├−−−−−−−−−−−−−┼−−−−−−−−−−−−−−−−−−−−−−−┤
｜ネゴシエーションされた ｜３ＧＰＰ ＴＳ ２４．００８に定義された ｜
｜ＱｏＳ ｜ネゴシエーションされたサービス品質 ｜
└−−−−−−−−−−−−−┴−−−−−−−−−−−−−−−−−−−−−−−┘

ＧＧＳＮ２１５に関連するアドレス、例えば、ＮＡＳ ＩＰアドレスまたはＵＲＬ／ＵＲＩは、“Ｕｐｄａｔｅ−ＰＤＰ要求”を正しいＧＧＳＮ２１５に送信するため、ネットワーク３１０のアプリケーションによって使用される。端末または加入に関連する識別手段であるＩＭＳＩまたはＭＳＩＳＤＮは、できれば、ＧＧＳＮ２１５が正しいＧＴＰを見つけるため、ネットワークノード３１０からのメッセージに含まれることが望ましい。あるいは、セションデータベースが、直接、進行中の通信セションのＧＴＰを識別するＧＴＰ識別子によって更新される。もう１つの選択肢は、もしそれがＰＤＰ情報の中に提供されているならば、クライアント端末１０５のＩＰアドレスを使用することである。

要求されたコンテンツに関連する第２のＱｏＳパラメータまたは第２のＱｏＳパラメータの表現を決定するステップ５０５は、いろいろな方法で実行される。

本発明の１つの実施例において、ネットワークノード３１０のアプリケーションは、要求されたコンテンツのタイプを分析することによって、例えば、コンテンツファイルのファイルヘッダの中に通常は備えられているファイルタイプを識別することによって、第２のＱｏＳパラメータを判断する。ネットワークノード３１０のアプリケーションは、その後、そのファイルタイプを所定の“ファイルタイプ−ＱｏＳパラメータ”索引リストと比較し、第２のＱｏＳパラメータをファイルタイプに対応するＱｏＳパラメータとして選択する。第２のＱｏＳパラメータまたは第２のＱｏＳパラメータの表現を決定するステップ５０５は、この実施例に従えば以下のステップを含んでも良い。

ステップ５０５：ａ コンテンツ要求を第２のネットワークノード、例えば、サービスプロバイダサーバに転送する。

ステップ５０５：ｂ コンテンツとそのコンテンツのファイルタイプとおそらくファイルのサイズについての情報とを有する第２のネットワークからのメッセージを受信する。

ステップ５０５：ｃ コンテンツのファイルタイプとそのファイルのサイズとの内、少なくともいずれかについての前記情報に基づいて、ファイルタイプを適切なＱｏＳパラメータと結びつける所定のリスト、或は所定のファイルサイズの範囲内のファイルタイプを適切なＱｏＳパラメータと結びつける所定のリストとの比較によって、第２のＱｏＳパラメータを決定する。

本発明の好適な実施例において、ＱｏＳパラメータまたはＱｏＳパラメータの表現が、コンテンツと同じメッセージ中で提供される。第２のＱｏＳパラメータまたは第２のＱｏＳパラメータの表現を決定するステップ５０５は、好適な実施例に従えば、以下のステップを含んでいても良い。

ステップ５０５：１ コンテンツ要求を第２のネットワークノード、例えば、サービスプロバイダサーバに転送する。

ステップ５０５：２ ステップ５０５：１で転送されたコンテンツ要求の応答として、第２のネットワークノードからメッセージを受け取る。メッセージ内には、要求されたコンテンツとそのコンテンツをクライアント端末１０５に配信するために必要なＱｏＳパラメータについての情報とが含まれている。

ステップ５０５：３ 必要なＱｏＳパラメータについての情報をメッセージから読み取り、必要なサービス品質パラメータについての前記情報に基づいて第２のＱｏＳパラメータを決定する。その必要なＱｏＳパラメータは、第２のＱｏＳパラメータとして直接利用可能なフォーマットで、ＱｏＳクラスの仕様、或はネットワークノード３１０のアプリケーションが第２のＱｏＳパラメータに変換するかもしれない英数字表現であってもよい。

そして、ステップ５０５は、オプションとして以下のステップを含んでも良い。

ステップ５０５：４ メッセージからＱｏＳパラメータについての情報を除去することによって、クライアント端末への応答を準備する。

これらのステップは、図６のシグナリング方式で例示されており、そこでは、通信セションが上記のことに従って設定されている。クライアント端末１０５のブラウザは、矢印６０５で示されている“ＨＴＴＰ ＧＥＴ”を、ここではプロキシサーバとして例示されているネットワークノード３１０に対して発行する。そのプロキシは、矢印６１０のように、その要求をＷＷＷサーバに転送する（ステップ５０５：１に相当）。ＷＷＷサーバは、コンテンツを有効に配信するため、コンテンツと必要なＱｏＳパラメータに関する情報との両方を含むメッセージを準備し、矢印６１５のように、そのメッセージをＨＴＴＰ応答としてプロキシに対して発行する。そのプロキシはメッセージを受信し、ステップ５０５：２−３で説明したようにＱｏＳパラメータを読み取って分析し、ステップ５０５：４に従ってメッセージを準備する。ステップ５１０に従って処理は続行し、図５のフローチャートにあるように転送する。

複数の提示されたステップおよびオプションを含んでいる最も好適な実施例が、図５ｂによるフローチャートに図示されているが、それは以下のステップを有する。

ステップ５０５：クライアント端末１０５が発行するコンテンツ要求について、要求されたコンテンツに関連する第２のＱｏＳパラメータ、或は第２のＱｏＳパラメータの表現を以下のステップによって決定する。

ステップ５０５：１ コンテンツ要求を第２のネットワークノード、例えば、サービスプロバイダサーバに転送する。

ステップ５０５：２ ステップ５０５：１の転送されたコンテンツ要求の応答として、第２のネットワークノードからメッセージを受け取る。そのメッセージ内には、要求されたコンテンツとそのコンテンツをクライアント端末１０５に配信するために必要なＱｏＳパラメータについての情報とが含まれている。

ステップ５０５：３ 必要なＱｏＳパラメータについての情報をメッセージから読み取り、必要なサービス品質パラメータについての前記情報に基づいて第２のＱｏＳパラメータを決定する。必要なＱｏＳパラメータは、第２のＱｏＳパラメータとして直接利用可能なフォーマットで、ＱｏＳクラスの仕様、またはネットワークノード３１０のアプリケーションが第２のＱｏＳパラメータに変換するかもしれない英数字表現でも良い。

ステップ５０５：４ メッセージからＱｏＳパラメータについての情報を除去することによって、クライアント端末への応答を準備する。

ステップ５１０：初期のＱｏＳパラメータを第２のＱｏＳパラメータと以下のステップによって比較する。

ステップ５１０：１ 通信セションに関連するＰＤＰ情報を取りだすためにセションデータベース３１７にアクセスする。

ステップ５１０：２ ＰＤＰ情報から初期のＱｏＳパラメータを読み取る。ＱｏＳは、３ＧＰＰ ＴＳ ２４．００８の中で定義されている“ネゴシエーションされたＱｏＳ”として保存されることが望ましい。

ステップ５１０：３ ＰＤＰ情報からアドレス指定情報を読み取る。

ステップ５１５：ステップ５１０での比較に基づいて、ＱｏＳパラメータを更新すべきか否かを判断する。もし第２のＱｏＳパラメータが、使用中のＱｏＳ（初期のＱｏＳパラメータ）より高いＱｏＳを、即ち、より高いベアラ能力を必要とするＱｏＳを示すならば、コンテンツ配信を実行するためにＱｏＳパラメータを更新する要件が識別される。そうでないならば、コンテンツ配信は初期のＱｏＳパラメータで実行してもよい。即ち、ＱｏＳパラメータを更新する必要はない。初期のＱｏＳパラメータへ任意で復帰する際に使用される初期のＱｏＳパラメータを一時的に保存する（ステップ５１５：１）。

ステップ５２０：もし決定するステップにおいて修正の要件が識別されたならば、初期のサービス品質パラメータから第２のサービス品質パラメータへの更新を発行することによってサービス品質パラメータの修正を開始する。

ステップ５２２：ＰＤＰ情報を第２のＱｏＳパラメータで更新するためにセションデータベース３１７にアクセスする。

ステップ５２５：要求されたコンテンツを第２のＱｏＳパラメータを用いてクライアント端末１０５へと配信する。

ステップ５３０：ステップ５２０と同様に第２のＱｏＳパラメータから初期のＱｏＳパラメータへの更新を発行することによって、初期のＱｏＳパラメータの使用に復帰する。

コンテンツとＱｏＳ情報の組み合わせの適切なフォーマットは、多目的インターネットメール拡張仕様（ＭＩＭＥ）に基づいていてもよい。ＭＩＭＥは、メッセージが異なるシステム間で交換できるためにはどのようにフォーマットされる必要があるかを定めた公式のインターネット標準のことであり、例えば、ブラウザを介してコンテンツをダウンロードするのに広く使われている。ＭＩＭＥは非常に柔軟性があるフォーマットで、これによりユーザは、実質的にいかなるタイプのファイルや文書でも電子メールメッセージの中に含めることができる。特に、ＭＩＭＥメッセージは、テキスト、画像、音声、動画、その他の特定用途のデータを含むことができる。ＭＩＭＥの説明は、ＩＥＴＦ（インターネット技術標準化委員会）刊行物のＲＦＣ１５２１、１５２２に見出すことができる。

本発明に従えば、閲覧セション中に要件が変化することから生じるＱｏＳパラメータの利用の際の柔軟性要求を満たすため、新しいＭＩＭＥタイプが導入される。新しいＭＩＭＥタイプは図７に図示されている。ＭＩＭＥタイプ７００は、特に、メインヘッダ７０５、コンテンツタイプ７０７、転送符号化７１０、及びコンテンツ７１５を有するが、コンテンツ７１５は従来のＭＩＭＥの中にも存在する。本発明に従うＭＩＭＥタイプでは、新しいフィールドであるＱｏＳフィールド７２０が導入され、これはＭＩＭＥメッセージを効率よく転送するために必要な、または望ましいＱｏＳを指定する。ＱｏＳフィールドは、必ずというわけではないが、できれば“コンテンツタイプ”フィールドのサブフィールドであることが望ましい。新しいＭＩＭＥタイプを利用すると、コンテンツおよびＱｏＳ情報の交換が効果的に行える。１つの前提条件は、ＱｏＳ情報を正確に使用してクライアント端末１０５に理解できるメッセージを準備するために、ネットワークノード３１０のアプリケーションはこの特定のＭＩＭＥタイプについての知識を持つ必要があるということである。

修正されたＭＩＭＥを使用する代わりに、ＱｏＳについての情報がＨＴＴＰヘッダに含まれていても良く、それは本発明のもう１つの実施例を表すことになる。この実施例では、第２のネットワークノード、例えば、ＷＷＷサーバは、図８に概略的に示す正規のＨＴＴＰ応答メッセージ８００を準備するが、これは通常、バージョン、ステータスコード等を示すステータス行８０５、コンテンツタイプとコンテンツの長さを指定できる複数のヘッダ行８１０、そして実際のデータを有するエンティティ部８１５を含んでいる。本発明の実施例によれば、ＱｏＳ情報もヘッダの中に、できればコンテンツタイプ、サイズ等を指定する他のヘッダ行の中に、ＱｏＳ行８１１として含まれることが望ましい。このメッセージは非常に融通がきく。例えば、もしヘッダ行８１１の中で提供されているＱｏＳ情報がネットワーク３１０のプロキシアプリケーションには理解できないならば、この情報は単純に廃棄されて、ＨＴＴＰ応答がとにかく配信される。ただし、最適なＱｏＳパラメータを備えていない可能性がある。

“第２のＱｏＳパラメータ”という用語は広義に解釈されるべきであり、即ち、例えば、ビットレートを明確に指定するパラメータに限定されるべきではない。第２のＱｏＳパラメータは、例えば、所定のＵＭＴＳ ＱｏＳクラスの表現、或は受け入れ可能なビットレートの範囲の表現であってもよい。これらの表現は、ネットワークノードのプロキシアプリケーションによって復号化可能である。

本発明の更なる実施例では、第２のＱｏＳパラメータは、異なるＱｏＳレベルまたはクラスの表現を少なくとも２つ有する。第１の表現である所望のＱｏＳレベルは、コンテンツが適合されるレベル（例えば、ビットレート）を指定し、第２の表現である最小のＱｏＳレベルは、配信が依然として実行できる最低のＱｏＳレベルを指定する。そのとき、ネットワークノードのアプリケーションが、所望のＱｏＳレベルに対する否定応答を受信すると、ポリシーチェックから、またはＰＤＰコンテキスト更新応答の中で、コンテンツを配信するため最小のＱｏＳレベルまたは中間のレベルを選択する。

本発明に従うネットワークノード３１０は、好ましくはソフトウェアコード手段として実現され、本発明に従う方法を実行するように適合される複数の機能部を有する。図３ｂに主な機能部が概略的に描かれているが、それらは通信セション中のＱｏＳの変更に関わるものである。“有する”および“接続された”という用語は、ここでは機能部間のリンクと解釈されるべきであって、物理的接続であるとは限らない。

ネットワークノードは、アプリケーションレベルでクライアント端末１０５と通信するための通信手段３５０と、クライアント端末１０５によって発行されたコンテンツ要求について、その要求されたコンテンツに関連する第２のＱｏＳパラメータを決定するように適合されたＱｏＳ決定手段３６０とを有する。ＱｏＳ決定手段３６０は好ましくは、第２のネットワークノードとメッセージを送受信するように適合され、第２のネットワークノードからのメッセージを読み取って復号化するように、特に、メッセージに含まれるＱｏＳ情報を読み取るように適合された第２のネットワークノードとインタフェースをとるインタフェース手段３６１を有するか、またはそれに接続していることが望ましい。

ネットワークノード３１０の比較手段３７０は、初期のＱｏＳパラメータと第２のＱｏＳパラメータとを比較するように適合されており、従って、通信セションに関連するＰＤＰ情報を取りだすため、セションデータベース３１７にアクセスするためのセションデータベースインタフェース３７１に接続されていることが好ましく、さらに初期のＱｏＳパラメータと、おそらくＰＤＰ情報からのアドレス指定情報とを読み取るように適合されている。

更新決定手段３８０は、比較手段３７０によって備えられた比較に基づいて、ＱｏＳパラメータが更新されるべきか否かを判断するように適合されている。更新決定手段３８０は、もし第２のＱｏＳパラメータが、使用中のＱｏＳ（初期のＱｏＳパラメータ）より高いＱｏＳを、即ち、より高いベアラ能力を必要とするＱｏＳを示すならば、ＱｏＳパラメータを更新する要件を識別する。更新決定手段３８０は、初期のＱｏＳパラメータを保存する保存手段３８１を有するか、または保存手段３８１に接続されてもよい。

ＱｏＳ修正手段３９０は、更新ＰＤＰコンテキストメッセージを利用して、初期のサービス品質パラメータから第２のサービス品質パラメータへの更新命令を発行するように適合されている。更新ＰＤＰコンテキストメッセージは適切なＧＧＳＮ２１５に向けられるべきであり、従って、ＧＧＳＮインタフェース手段３９１を備えているか、またはＧＧＳＮインタフェース手段３９１に接続されている。ＱｏＳ修正手段はさらにＰＤＰ情報からアドレス指定情報を取りだすように適合されていてもよく、従って、セションデータベースインタフェース３７１に接続されている。

本発明の代表的な実施例から、本発明はネットワークノード３１０またはネットワークノードのアプリケーションが、進行中の通信セション中にＱｏＳパラメータの変更を開始および制御できるようにし、それによって、閲覧またはダウンロードセション中に通常経験する転送能力要求の変化により良く適合できるようにするということは明らかである。本発明はネットワークノードが第２のＱｏＳパラメータを決定し、それらを初期のＱｏＳパラメータと比較し、そして、必要に応じて通信セションの中で使用されるＱｏＳパラメータを修正したり、またはその修正を提案する可能性を提供するのであるから、このことは可能である。

図面および明細書の中で、本発明の典型的な好適な実施例が開示されており、特定の用語が用いられてはいるが、それらは一般的な説明の意味でのみ使用されているのであって、本発明を限定することを目的としてはおらず、本発明の範囲は添付した請求の範囲において説明されている。

一般的移動通信システムの概略説明図である。 移動通信システムにおけるＰＤＰコンテキストの利用法の概略説明図である。 本発明に従う方法と構成が用いられる移動通信システムの概略説明図である。 本発明に従うネットワークノードのソフトウェアコード手段として実装された機能部の概略説明図である。 本発明に従う方法を説明する信号／メッセージシーケンス方式を示す図である。 本発明に従う方法のフローチャートである。 本発明に従う方法の好適な実施例のフローチャートである。 本発明に従う方法の実施例を説明する信号／メッセージシーケンス方式を示す図である。 本発明の１つの実施例に従うＭＩＭＥタイプの概略説明図である。 本発明の１つの実施例に従うＨＴＴＰ応答ヘッダの概略説明図である。

Claims (33)

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. 前記インタフェース手段（３６１）は、前記第２のネットワークノードからのメッセージに含まれているサービス品質情報を読み出すように適合されていることを特徴とする請求項２４に記載のネットワークノード。
26. 前記初期のサービス品質パラメータと前記第２のサービス品質パラメータとを比較するように適合されている比較手段（３７０）をさらに有することを特徴とする請求項２３乃至２５のいずれか１項に記載のネットワークノード。
27. 前記比較手段（３７０）は、前記通信セションと関連したＰＤＰ情報を取り出すためにセションデータベース（３１７）にアクセスするセションデータベースインタフェース（３７１）との通信を行うように適合されていることを特徴とする請求項２６に記載のネットワークノード。
28. 前記セションデータベースインタフェース（３７１）は、前記ＰＤＰ情報から前記初期のサービス品質パラメータを読み出すように適合されていることを特徴とする請求項２７に記載のネットワークノード。
29. 前記セションデータベースインタフェース（３７１）は、前記ＰＤＰ情報からアドレス情報を読み出すように適合されていることを特徴とする請求項２７又は２８に記載のネットワークノード。
30. 進行中の通信セションにおいてサービス品質パラメータが更新されるべきかどうかを前記比較手段（３７０）によって提供された前記比較に基づいて判断するように適合された更新判断手段（３８０）をさらに有し、
    前記更新判断手段（３８０）は前記第２のサービス品質パラメータが前記初期のサービス品質パラメータによって示唆されたサービス品質とは異なるサービス品質を示唆するなら、サービス品質パラメータを更新する要件を特定するよう適合されていることを特徴とする請求項２３乃至２９のいずれか１項に記載のネットワークノード。
31. 前記更新判断手段（３８０）は、前記初期のサービス品質パラメータを格納する格納手段（３８１）を有することを特徴とする請求項３０に記載のネットワークノード。
32. 前記サービス品質修正手段（３９０）は、少なくとも１つのＧＧＳＮ（２１５）への通信機能を提供するＧＧＳＮインタフェース手段（３９１）との通信を行うように適合されていることを特徴とする請求項２３乃至３１のいずれか１項に記載のネットワークノード。
33. 前記サービス品質修正手段（３９０）は、前記ＰＤＰ情報からアドレス情報を取り出すために前記セションデータベースインタフェース（３７１）との通信を行うように適合されていることを特徴とする請求項２７乃至３２のいずれか１項に記載のネットワークノード。

Images