(57)【要約】  ＵＭＴＳでは、特定のＱｏＳを満たすため、エンド・ツー・エンドサービスが設定されるようユーザ装置が規定可能なＱｏＳ属性は、大部分の場合、ネットワークにおける中央コール及びアドミッション制御機能により処理される必要がある。これらのＱｏＳ属性は、すべての可能なパスセグメントのアドミッション機能に知らされる必要がある。効果的には、本発明の一実施例によると、ＱｏＳ属性は、ネットワークのエッジの選択されたいくつかのネットワークノードにのみ送信される。この選択された及び限定的ないくつかのネットワークノードは、受信ステーションによってトリガーされるＱｏＳ処理を実行する。効果的には、これは、データトラフィックの低減と実現及び規格化プロセスの向上をもたらすかもしれない。さらに、ＱｏＳ属性は、必須のコンフィギュレーションメッセージに追加されてもよく、これにより、データトラフィックのさらなる低減が可能となる。
2007537652.tif 000002
【特許請求の範囲】
【請求項１】
複数のネットワークノードを有するネットワークにおける送信ステーションから受信ステーションへのデータ送信のためのＱｏＳ制御を実行する方法であって、
設定処理中に、第１ＱｏＳ属性と第１コンフィギュレーションメッセージとを前記受信ステーションから前記複数のネットワークノードの少なくとも１つの選択された第１ネットワークノードに送信するステップと、
前記少なくとも１つの選択された第１ネットワークノードにおいて受信した前記第１ＱｏＳ属性に基づき、前記複数のネットワークノードの１つの第１ネットワークノードによって第１ＱｏＳ処理を実行するステップと、
を有し、
前記第１コンフィギュレーションメッセージは、前記第１ＱｏＳ属性を有することを特徴とする方法。
【請求項２】
請求項１記載の方法であって、
前記ネットワークは、複数の論理チャネルを有し、
データは、データパケットとして送信され、
前記データパケットは、前記複数の論理チャネルの少なくとも１つの第１論理チャネルを介し送信され、
前記第１ＱｏＳ属性は、前記複数の論理チャネルの第２論理チャネルのグループの識別を有し、
前記第１ＱｏＳ属性は、前記第２ネットワークノードによって実行される前記第１ＱｏＳ処理の形式により前記第２論理チャネルのグループに適用される、
ことを特徴とする方法。
【請求項３】
請求項１記載の方法であって、
前記第１ＱｏＳ処理は、前記受信ステーションから前記第１及び第２ネットワークノードの少なくとも１つに送信されるコマンドによりトリガーされることを特徴とする方法。
【請求項４】
請求項２記載の方法であって、
前記第１ＱｏＳ属性は、前記データパケットの送信のフロー制御に対するリクエストに対応することを特徴とする方法。
【請求項５】
請求項２記載の方法であって、
前記少なくとも１つの第１ネットワークノードは、前記第１ＱｏＳ処理が前記第２ネットワークノードにより実行される前に、前記第１ＱｏＳ属性に基づき第２ＱｏＳ処理を実行することを特徴とする方法。
【請求項６】
請求項５記載の方法であって、
前記少なくとも１つの第１ネットワークノードによって実行される前記第２ＱｏＳ処理は、前記データパケットが前記第２論理チャネルのグループの第２論理チャネルを介し送信される場合、前記データパケットのタグ付けを有し、
前記第２ネットワークノードによって実行される第１ＱｏＳ処理は、前記タグ付けされたデータパケットのブロッキングを有する、
ことを特徴とする方法。
【請求項７】
請求項５記載の方法であって、
前記少なくとも１つの第１ネットワークノードによって実行される前記第２ＱｏＳ処理は、前記第１ネットワークノードから前記第２ネットワークノードへの前記第１ＱｏＳ属性に基づく第２ＱｏＳ属性の送信を有し、
前記第２ＱｏＳ属性は、前記複数の論理チャネルの第２論理チャネルのグループの識別を有し、
前記第２ネットワークノードによって実行される前記第１ＱｏＳ処理は、前記データパケットが前記第２論理チャネルのグループの第２論理チャネルを介し送信される場合、前記データパケットのブロッキングを有する、
ことを特徴とする方法。
【請求項８】
請求項７記載の方法であって、
前記少なくとも１つの第１ネットワークノードは、第２設定処理中に、第２コンフィギュレーションメッセージを前記第２ネットワークノードに送信し、
前記第２コンフィギュレーションメッセージは、前記第２ＱｏＳ属性を有する、
ことを特徴とする方法。
【請求項９】
請求項１記載の方法であって、
当該方法は、ＵＭＴＳのＨＳ−ＤＳＣＨ（Ｈｉｇｈ  Ｓｐｅｅｄ  Ｄｏｗｎｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）を介したデータ送信に適用されることを特徴とする方法。
【請求項１０】
複数のネットワークノードを有するネットワークにおいて送信ステーションから受信ステーションに実行されるデータ送信に対して、第１ＱｏＳ処理に対応する第１ＱｏＳ属性を送信する方法であって、
設定処理中に、前記受信ステーションから前記複数のネットワークノードの少なくとも１つの選択された第１ネットワークノードに第１コンフィギュレーションメッセージを送信するステップを有し、
前記第１コンフィギュレーションメッセージは、前記複数のネットワークノードの１つの第２ネットワークノードによる第１ＱｏＳ処理に対応する前記第１ＱｏＳ属性を有することを特徴とする方法。
【請求項１１】
請求項１０記載の方法であって、
前記少なくとも１つの選択された第１ネットワークノードは、第２設定処理中に、第２コンフィギュレーションメッセージを前記第２ネットワークノードに送信し、
前記第２コンフィギュレーションメッセージは、第２ＱｏＳ属性を有する、
ことを特徴とする方法。
【請求項１２】
複数のネットワークノードを有するネットワークにおける送信ステーションから受信ステーションへのデータ送信のためのＱｏＳ制御を実行する通信システムであって、
前記受信ステーションは、第１ＱｏＳ属性を前記複数のネットワークノードの少なくとも１つの選択された第１ネットワークノードに送信するよう構成され、
前記複数のネットワークノードの１つの第２ネットワークノードは、前記少なくとも１つの選択された第１ネットワークノードにおいて受信した前記第１ＱｏＳ属性に基づき、第１ＱｏＳ処理を実行するよう構成される、
ことを特徴とする通信システム。
【請求項１３】
複数のネットワークノードを有するネットワークにおいて送信ステーションから受信ステーションに実行されるデータ送信に対して、第１ＱｏＳ処理に対応する第１ＱｏＳ属性を送信する通信システムであって、
前記受信ステーションは、設定処理中に、前記複数のネットワークノードの少なくとも１つの選択された第１ネットワークノードに第１コンフィギュレーションを送信するよう構成され、
前記第１コンフィギュレーションメッセージは、前記複数のネットワークノードの１つの第２ネットワークノードによる第１ＱｏＳ処理に対応する前記第１ＱｏＳ属性を有する、
ことを特徴とする通信システム。
【請求項１４】
複数のネットワークノードを有するネットワークにおける送信ステーションから当該受信ステーションへのデータ送信のためのＱｏＳ制御を実行する通信システムのための受信ステーションであって、
当該受信ステーションは、前記複数のネットワークノードの少なくとも１つの選択された第１ネットワークノードに第１ＱｏＳ属性を送信するよう構成され、
前記複数のネットワークノードの１つの第２ネットワークノードは、前記第１ネットワークノードにおいて受信した前記第１ＱｏＳ属性に基づき第１ＱｏＳ処理を実行するよう構成される、
ことを特徴とする受信ステーション。
【請求項１５】
複数のネットワークノードを有するネットワークにおいて送信ステーションから当該受信ステーションに実行されるデータ送信に対して、第１ＱｏＳ処理に対応する第１ＱｏＳ属性を送信する受信ステーションであって、
当該受信ステーションは、設定処理中に、前記複数のネットワークノードの少なくとも１つの選択された第１ネットワークノードに第１コンフィギュレーションメッセージを送信するよう構成され、
前記第１コンフィギュレーションメッセージは、前記複数のネットワークノードの１つの第２ネットワークノードによる第１ＱｏＳ処理に対応する前記第１ＱｏＳ属性を有する、
ことを特徴とする受信ステーション。
【請求項１６】
複数のネットワークノードを有するネットワークにおける送信ステーションから受信ステーションへのデータ送信のためのＱｏＳサービス制御を実行するソフトウェアプログラムであって、
当該コンピュータプログラムは、データプロセッサ上で実行されるとき、該データプロセッサに、前記受信ステーションから前記複数のネットワークノードの少なくとも１つの選択された第１ネットワークノードに送信される第１ＱｏＳ属性に基づき、前記複数のネットワークノードの１つの第２ネットワークノードに関する第１ＱｏＳ処理を実行するステップを実行させることを特徴とするソフトウェアプログラム。
【請求項１７】
複数のネットワークノードを有するネットワークにおいて送信ステーションから受信ステーションに実行されるデータ送信に対して、第１ＱｏＳ処理に対応する第１ＱｏＳ属性の送信を実行するソフトウェアプログラムであって、
当該コンピュータプログラムは、データプロセッサ上で実行されるとき、該データプロセッサに、設定処理中に、前記受信ステーションから前記複数のネットワークノードの少なくとも１つの選択された第１ネットワークノードへの第１コンフィギュレーションメッセージの送信を実行するステップを実行させ、
前記第１コンフィギュレーションメッセージは、前記複数のネットワークノードの１つの第２ネットワークノードによる第１ＱｏＳ処理に対応する前記第１ＱｏＳ属性を有する、
ことを特徴とするソフトウェアプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ送信の技術分野に関する。より詳細には、本発明は、ネットワークにおける送信ステーションから受信ステーションへのデータ送信のためのＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）の制御を実行する方法と、ネットワークにおける送信ステーションから受信ステーションへのデータ送信のための第１ＱｏＳ処理に対応する第１ＱｏＳ属性を送信する方法と、データ送信のためのＱｏＳ処理を実行し、ネットワークにおける送信ステーションから受信ステーションへのデータ送信のための第１ＱｏＳ処理に対応する第１ＱｏＳ属性の送信を実行する通信システム、受信ステーション及びソフトウェアプログラムとに関する。
【背景技術】
【０００２】
ＵＭＴＳでは、特定のサービスクオリティを満足するため、セットアップされるべきエンド・ツー・エンドサービスについてユーザ装置（ＵＥ）が規定可能なＱＯＳＡ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ  Ａｔｔｒｉｂｕｔｅ）が存在する。これらのＱＯＳＡは、ネットワークにおけるＣＡＣＦ（Ｃｅｎｔｒａｌ  ｃａｌｌ  ａｎｄ  Ａｄｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）により処理される必要がある。すべてのパスセグメントにおいてそれらを満たすことが可能である場合、それらを満たすための準備が影響を受けるネットワークノードにおいてなされる。
【０００３】
規格化されたネットワークは、通常は経時的に展開及び拡張する拡大していくシステムである。既知のＱｏＳ管理を実行することによって、規格化処理において以降に導入される何れかのＱｏＳ属性が、すべての可能なパスセグメント、すなわちすべてのネットワークレベルに対するアドミッション制御機能に知らせる必要があるであろう。このようなアプローチは、規格化処理、すなわち、多数のワーキンググループが関与する必要があることと、実現形態、すなわち、多数の異なるネットワークノードタイプが影響を受けることの双方の点においてコストがかかる。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
本発明の課題は、向上したＱｏＳ制御を提供することである。
【課題を解決するための手段】
【０００５】
請求項１記載の本発明の一実施例によると、上記課題は、複数のネットワークノードを有するネットワークにおける送信ステーションから受信ステーションへのデータ送信のためのＱｏＳ制御を実行する方法により解決されるかもしれない。設定処理中に、第１ＱｏＳ属性と第１コンフィギュレーションメッセージとが、前記受信ステーションから前記複数のネットワークノードの少なくとも１つの選択された第１ネットワークノードに送信され、前記少なくとも１つの選択された第１ネットワークノードにおいて受信した前記第１ＱｏＳ属性に基づき、前記複数のネットワークノードの１つの第１ネットワークノードによって、第１ＱｏＳ処理が実行される。さらに、前記第１コンフィギュレーションメッセージは、前記第１ＱｏＳ属性を有する。
【０００６】
例えば、ＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）属性が、他のネットワークノードに関与することなく、ネットワークエッジにある第１ネットワークノードに通知されるようにしてもよい。第２ステップでは、第１ＱｏＳ処理が第２ネットワークノードによって実行されるようにしてもよい。第２ネットワークノードは、第１ネットワークノード又は他の何れかのネットワークノードであってもよく、ＱｏＳ処理は、送信されたＱｏＳ属性に基づくものであってもよい。
【０００７】
効果的には、さらなるネットワークノード又はアドミッション制御機能（ＵＴＭＳにおける）が関与しないため、これは、簡単化されたネットワークの実現とＱｏＳ制御の向上を可能にするかもしれない。
【０００８】
さらに、これは、最小限のネットワークノードしか当該属性を処理する必要がないように、受信ステーションと少なくとも１つの第１ネットワークノードとの間でやりとりされる必要があるコンフィギュレーションメッセージにＱｏＳ属性を追加することによって、ＱｏＳ属性をＱｏＳアーキテクチャに組み込むためのシンプルな手段を提供するかもしれない。さらに、これは、通知データトラフィックの低減を可能にするかもしれない。
【０００９】
請求項２記載の本発明の他の実施例によると、前記ネットワークは、複数の論理チャネルを有し、データは、データパケットとして送信される。さらに、前記データパケットは、前記複数の論理チャネルの少なくとも１つの第１論理チャネルを介し送信され、前記第１ＱｏＳ属性は、前記複数の論理チャネルの第２論理チャネルのグループの識別を有する。さらに、前記第１ＱｏＳ属性は、前記第２ネットワークノードによって実行される前記第１ＱｏＳ処理の形式により前記第２論理チャネルのグループに適用される。
【００１０】
効果的には、これは、第２論理チャネルのグループに対するチャネルフロー制御に基づき、ＱｏＳ制御を可能にするかもしれない。
【００１１】
請求項３記載の本発明の他の実施例によると、前記第１ＱｏＳ処理は、前記受信ステーションから前記第１及び第２ネットワークノードの少なくとも１つに送信されるコマンドによりトリガーされる。
【００１２】
効果的には、これは、受信ステーションによるデータ送信のフロー制御などＱｏＳ処理の制御又はトリガーを可能にするかもしれない。
【００１３】
本発明の他の実施例が、請求項４に記載され、前記第１ＱｏＳ属性は、前記データパケットの送信のフロー制御に対するリクエストに対応する。
【００１４】
請求項５記載の本発明の他の実施例によると、前記少なくとも１つの第１ネットワークノードは、前記第１ＱｏＳ処理が前記第２ネットワークノードにより実行される前に、前記第１ＱｏＳ属性に基づき第２ＱｏＳ処理を実行する。
【００１５】
効果的には、これは、第１ＱｏＳ処理の形式による第２ネットワークノードの応答が実行される前に、第１ネットワークノードが第１ＱｏＳ属性に応答することを可能にするかもしれない。
【００１６】
請求項６記載の本発明の他の実施例によると、前記少なくとも１つの第１ネットワークノードによって実行される前記第２ＱｏＳ処理は、前記データパケットが前記第２論理チャネルのグループの第２論理チャネルを介し送信される場合、前記データパケットのタグ付けを有する。さらに、前記第２ネットワークノードによって実行される第１ＱｏＳ処理は、前記タグ付けされたデータパケットのブロッキングを有する。
【００１７】
従って、本発明の当該実施例によると、第２ネットワークノードは、トリガーコマンドが受信ステーションから第２ネットワークノードに送信された後には送信されるべきでないデータパケットを認識する。
【００１８】
請求項７記載の本発明の他の実施例によると、前記少なくとも１つの第１ネットワークノードによって実行される前記第２ＱｏＳ処理は、前記第１ネットワークノードから前記第２ネットワークノードへの前記第１ＱｏＳ属性に基づく第２ＱｏＳ属性の送信を有し、前記第２ＱｏＳ属性は、前記複数の論理チャネルの第２論理チャネルのグループの識別を有する。前記第２ネットワークノードによって実行される前記第１ＱｏＳ処理は、前記データパケットが前記第２論理チャネルのグループの第２論理チャネルを介し送信される場合、前記データパケットのブロッキングを有する。
【００１９】
効果的には、本発明の当該実施例によると、スロットル処理すべき論理チャネルのリストに基づき、第２ネットワークノードは、受信ステーションからＳＴＯＰコマンドを受信すると、これらの論理チャネルのデータパケットを送信することを回避することが可能である。
【００２０】
効果的には、これは、論理チャネルのグループの論理チャネルに対するＱｏＳ属性「フロー制御」を追加し、ＳＴＯＰコマンドを受信ステーションから受信した後、これらの論理チャネルのフロー制御を実行する通知手段の効率的な実現を可能にするかもしれない。
【００２１】
請求項８記載の本発明の他の実施例によると、前記少なくとも１つの第１ネットワークノードは、第２設定処理中に、第２コンフィギュレーションメッセージを前記第２ネットワークノードに送信し、前記第２コンフィギュレーションメッセージは、前記第２ＱｏＳ属性を有する。
【００２２】
従って、第２ＱｏＳ属性を必須の第２コンフィギュレーションメッセージに追加することによって、通知データトラフィックをさらに低減することが可能である。
【００２３】
請求項９記載の本発明の他の実施例によると、当該方法は、ＵＭＴＳのＨＳ−ＤＳＣＨ（Ｈｉｇｈ  Ｓｐｅｅｄ  Ｄｏｗｎｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）を介したデータ送信に適用される。
【００２４】
これは、ＵＭＴＳのＱｏＳアーキテクチャを変更することなく、このため、ＨＳ−ＤＳＣＨにマッピングされたラジオベアラへのＱｏＳ属性「フロー制御」を追加するため、絶対的な最小限のネットワークノードしか伴うことなく、ＨＳ−ＤＳＣＨにマッピングされたラジオベアラを介したデータ送信のためのフロー制御を提供するのに必要な通知手段を導入するシンプルな方法を提供するかもしれない。
【００２５】
本発明の他の実施例が、請求項１０に記載され、複数のネットワークノードを有するネットワークにおいて送信ステーションから受信ステーションに実行されるデータ送信に対して、第１ＱｏＳ処理に対応する第１ＱｏＳ属性を送信する方法が記載される。本方法は、設定処理中に、前記受信ステーションから前記複数のネットワークノードの少なくとも１つの選択された第１ネットワークノードに第１コンフィギュレーションメッセージを送信するステップを有し、前記第１コンフィギュレーションメッセージは、前記複数のネットワークノードの１つの第２ネットワークノードによる第１ＱｏＳ処理に対応する前記第１ＱｏＳ属性を有する。
【００２６】
効果的には、これは、ネットワークのＱｏＳアーキテクチャを変更することなく、ネットワークノード間と、ユーザ装置とネットワークノードの間でやりとりされる通知メッセージに対する最小限の変更によるさらなるＱｏＳ属性の導入と、これにより、通知データトラフィックが低減したＱｏＳ制御の向上を可能にするかもしれない。
【００２７】
請求項１１記載の本発明の他の実施例によると、前記少なくとも１つの選択された第１ネットワークノードは、第２設定処理中に、第２コンフィギュレーションメッセージを前記第２ネットワークノードに送信し、前記第２コンフィギュレーションメッセージは、第２ＱｏＳ属性を有する。
【００２８】
効果的には、これは、通知データトラフィックをさらに低減するかもしれない。
【００２９】
請求項１２及び１３記載の本発明の他の実施例によると、複数のネットワークノードを有するネットワークにおける送信ステーションから受信ステーションへのデータ送信のためのＱｏＳ制御を実行する通信システムが提供される。請求項１２記載の本発明の実施例によると、前記受信ステーションは、第１ＱｏＳ属性を前記複数のネットワークノードの少なくとも１つの選択された第１ネットワークノードに送信するよう構成される。さらに、前記複数のネットワークノードの１つの第２ネットワークノードは、前記少なくとも１つの選択された第１ネットワークノードにおいて受信した前記第１ＱｏＳ属性に基づき、第１ＱｏＳ処理を実行するよう構成される。請求項１３記載の本発明の実施例によると、前記受信ステーションは、設定処理中に、前記複数のネットワークノードの少なくとも１つの選択された第１ネットワークノードに第１コンフィギュレーションを送信するよう構成され、前記第１コンフィギュレーションメッセージは、前記複数のネットワークノードの１つの第２ネットワークノードによる第１ＱｏＳ処理に対応する前記第１ＱｏＳ属性を有する。
【００３０】
効果的には、これは、ネットワークノード間及び端末とネットワークノードの間でやりとりされる通知メッセージに対する最小限の変更により通信システムの向上したＱｏＳ制御を提供するかもしれない。
【００３１】
請求項１４記載の本発明の他の実施例によると、複数のネットワークノードを有するネットワークにおける送信ステーションから当該受信ステーションへのデータ送信のためのＱｏＳ制御を実行する通信システムのための受信ステーションが提供され、当該受信ステーションは、前記複数のネットワークノードの少なくとも１つの選択された第１ネットワークノードに第１ＱｏＳ属性を送信するよう構成される。さらに、前記複数のネットワークノードの１つの第２ネットワークノードは、前記第１ネットワークノードにおいて受信した前記第１ＱｏＳ属性に基づき第１ＱｏＳ処理を実行するよう構成される。
【００３２】
さらに、請求項１５記載の本発明の他の実施例によると、通信システムのための受信ステーションが提供され、当該受信ステーションは、設定処理中に、前記複数のネットワークノードの少なくとも１つの選択された第１ネットワークノードに第１コンフィギュレーションメッセージを送信するよう構成され、前記第１コンフィギュレーションメッセージは、前記複数のネットワークノードの１つの第２ネットワークノードによる第１ＱｏＳ処理に対応する前記第１ＱｏＳ属性を有する。
【００３３】
効果的には、これは、低減した通知データトラフィックを有する向上したＱｏＳ制御を可能にするかもしれない。
【００３４】
本発明はまた、例えば、プロセッサ上で実行可能なコンピュータプログラムに関する。このようなコンピュータプログラムは、例えば、ネットワークにおいてＱｏＳ制御又はデータ送信を実行する通信システムの一部であるかもしれない。本発明の一実施例によるコンピュータプログラムが、請求項１６及び１７に記載される。これらのコンピュータプログラムは、好ましくは、データプロセッサのワーキングメモリにロードされるかもしれない。従って、データプロセッサが、本発明の方法の実施例を実行するため備えられる。コンピュータプログラムは、ＣＤ−ＲＯＭなどのコンピュータ可読媒体に格納されるようにしてもよい。コンピュータプログラムはまた、ワールドワイドウェブなどのネットワークを介し提供されてもよく、このようなネットワークからデータプロセッサのワーキングメモリにダウンロードされてもよい。このようなプログラムは、Ｃ＋＋などの任意の適切なプログラミング言語により記述されてもよい。
【００３５】
本発明の一実施例の要旨として、ＱｏＳ属性が、ＵＭＴＳのラジオベアラサービスなど、ネットワークのエッジの選択されたいくつかのネットワークノードにのみ送信されるということが理解されるかもしれない。選択されたいくつかの（限定的な）ネットワークノードは、受信ステーションによりトリガーされたＱｏＳ処理を実行する。従って、ＱｏＳ属性は、すべての可能なパスセグメント、すなわち、すべてのネットワークレベルにおけるアドミッション制御機能に送信されることはない。効果的には、これは、より少ない異なるネットワークノードタイプしか影響を受けないため、より少ないデータトラフィックと簡単化された実現形態をもたらすかもしれず、より少ないワーキンググループしか関与する必要がないため、規格化プロセスの向上をもたらすかもしれない。効果的には、本発明の一実施例によると、ＱｏＳ属性が必須のコンフィギュレーションメッセージに追加されてもよく、これにより、データトラフィックをさらに低減することが可能となる。
【００３６】
本発明の上記及び他の特徴は、以降に説明される実施例を参照して明らかとなるであろう。
【発明を実施するための最良の形態】
【００３７】
図１は、ＵＭＴＳ  ＱｏＳアーキテクチャの概略図を示す。ＵＭＴＳでは、エンド・ツー・エンドサービスのＱｏＳは、ＵＭＴＳデータカードなどを有するラップトップ、スマートフォン、携帯電話などのモバイル端末と、ネットワークに接続されるモバイル端末、固定端末又はサーバとすることが可能なネットワークを介し到達可能なエンドポイントとの間のエンド・ツー・エンドサービスを提供するネットワークの異なるノードにおける各機能のグループ化から生じるものとしてみなされるネットワークの異なるレイヤによって提供される「基礎となる」サービスによって決定される。
【００３８】
参照することによりここに含まれる“ＴＳ２３．１０７  ３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ；Ｔｅｃｈｎｉｃａｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｇｒｏｕｐ  Ｓｅｒｖｉｃｅｓ  ａｎｄ  Ｓｙｓｔｅｍ  Ａｓｐｅｃｔｓ；Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ（ＱｏＳ）  ｃｏｎｃｅｐｔ  ａｎｄ  ａｒｃｈｉｔｅｃｔｕｒｅ”に規定されるＱｏＳアーキテクチャによると、エンド・ツー・エンドサービスは、
１．モバイル端末（ＭＴ）とコアネットワーク（ＣＮ）ゲートウェイとの間のＵＭＴＳベアラサービス
１．１．Ｉｕインタフェース（コアネットワークＩｕエッジノード）を介しＵＴＲＡＮ（ＵＭＴＳ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）に接続されるコアネットワークエッジノードとモバイル端末との間のラジオアクセスベアラサービス
１．２．コアネットワークＩｕエッジノードとコアネットワークゲートウェイとの間のコアネットワークベアラサービス
１．２．１．モバイル端末とＵＴＲＡＮとの間のラジオベアラサービス
１．２．２．ＵＴＲＡＮとコアネットワークＩｕエッジノードとの間のＩｕベアラサービス
１．２．３．コアネットワークＩｕエッジノードとコアネットワークゲートウェイとの間のバックボーンベアラサービス
１．２．３．１．モバイル端末とＵＴＲＡＮとの間のＵＴＲＡ  ＦＤＤ／ＴＤＤサービス
１．２．３．２．ＵＴＲＡＮとコアネットワークＩｕエッジノードとの間の物理ベアラサービス
に基づく。
【００３９】
図１によると、ＵＭＴＳ  ＱｏＳアーキテクチャは、端末装置とモバイル端末とを区別する。それは、他の何れかの端末装置と通信するため、モバイル端末を介しサービスにアクセス可能な端末装置（ＴＥ）である。
【００４０】
ネットワークノードに関して、エンド・ツー・エンドサービスが必要とする異なるサービスは、ユーザ装置（ＵＥ）がモバイル端末と端末装置を共に表す図２のエンド・ツー・エンドサービスを提供するネットワークのネットワークノードアーキテクチャから、以下のように詳細に説明することが可能である。図２は、パケットスイッチサービスのケースについてのネットワークアーキテクチャを示す。同様のモデルが、回路スイッチサービスについて成り立つ。
【００４１】
図２に示されるネットワークは、ＵＥ２１１を有する複数のラジオセル２０１〜２０６と、異なるＮｏｄｅ  Ｂ（ＵＴＲＡＮ２０７とラジオセルをリンクする）、ＲＮＣ、ＳＧＳＮ及びＧＧＳＮノードなどの異なるネットワークノードとを有する。ＵＴＲＡＮの一部であるＲＮＣ及びＮｏｄｅ  Ｂは、Ｉｕｂインタフェースを介しリンクされる。ＲＮＣ及びＳＧＳＮ（ＵＴＲＡＮとＣＮ２０８をリンクする）は、Ｉｕ−ｐｓインタフェースを介しリンクされる。ＣＮ２０８の一部であるＧＧＳＮ及びＳＧＳＮは、Ｇｎ／Ｇｐインタフェースを介しリンクされる。さらに、ＧＧＳＮは、サーバ又は送信ステーション２１０にリンク可能なＧｉインタフェースを介し外部ネットワーク２０９にリンクされる。
【００４２】
ＵＭＴＳベアラサービスは、ＧＧＳＮ（Ｇａｔｅｗａｙ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）とユーザ装置との間にあり、ラジオアクセスベアラサービスは、ＳＧＳＮとユーザ装置との間にあり、ラジオベアラサービスは、ＲＮＣ（Ｔａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ）とユーザ装置との間にある。その後、ラジオベアラサービスは、Ｎｏｄｅ  Ｂとユーザ装置との間のエアインタフェースにより提供されるＵＴＲＡ  ＦＤＤ／ＴＤＤにマッピングされる（図１を参照されたい）。
【００４３】
エンド・ツー・エンドサービス（例えば、ＵＥとサーバとの間の）のＱｏＳは、当該エンド・ツー・エンドサービスを構築するサービスのＱｏＳによって決定される。例えば、エンド・ツーエンド遅延は、基礎となるサービスがネットワークを介したパスの対応するセグメントに対する遅延が、実質的に２００ｍｓ以上は追加しないことを保証することが可能である場合、約２００ｍｓだけであるかもしれない。同様に、パスのセグメントが十分低い損失確率を提供することが可能である場合、パス全体における０．１％などのパケット損失確率が保証されるだけである。
【００４４】
エンド・ツー・エンドサービスを求めるとき、ユーザ装置は、特別なＱｏＳを意図し、対応するＱｏＳ属性をネットワークに伝達する。ネットワークのアドミッション制御機能は、エンド・ツー・エンドサービスによって使用されるパスのすべてのセグメントについて、要求されたＱｏＳが確保可能であるかチェックする必要がある。
【００４５】
従って、このモデルでは、要求されたＱｏＳが確保可能であるか否かに関わらず、異なるパスセグメントのアドミッション制御機能から収集する一意的な制御エンティティによって、ＱｏＳは管理される。このモデルは、可能なＱｏＳパラメータが中央制御エンティティによって知られており、その後、当該エンティティは、要求されたＱｏＳパラメータを満たすことができるかチェックするため、それらを影響を受けるパスセグメントのアドミッション制御機能に転送することを暗黙的に仮定する。
【００４６】
規格化されたネットワークは、通常は、経時的に展開及び拡張する拡大するシステムである。上記ＱｏＳ管理モデルにより、規格化プロセスにおいて以降に導入されるＱｏＳ属性は、すべての可能なパスセグメント、すなわち、すべてのネットワークレベルに対するアドミッション制御機能に知らされる必要があるであろう。このようなアプローチは、規格化プロセス（すなわち、多数のワーキンググループが関与する必要がある）と実現形態（すなわち、多数の異なるネットワークノードタイプが影響を受ける）の双方の点において高コストである。
【００４７】
しかしながら、いくつかのケースでは、この高コストなアプローチは、ラジオベアラサービスなどのネットワークのエッジのネットワークノード又はネットワークエッジを少なくとも参照する場合、回避することが可能である。ラジオベアラサービスについては、ＨＳ−ＤＳＣＨ（Ｈｉｇｈ  Ｓｐｅｅｄ  Ｄｏｗｎｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）に関するサービス属性「フロー制御」のクオリティに基づき以下において説明される。
【００４８】
ユーザ装置は、専用チャネル（ＤＣＨ）よりかなり高いデータレートを提供するＨＳ−ＤＳＣＨを介しデータをダウンリンクで受信するよう構成可能である。ＨＳ−ＤＳＣＨは、１０Ｍｂｐｓの範囲のピークデータレートを可能にし、ＤＣＨのピークデータレートは、２Ｍｂｐｓを超えることはできないが、通常ははるかにより低いものとなる。ＨＳ−ＤＳＣＨは、典型的には、例えば、ストリーミングデータについて使用される。パケットデータ送信がＤＣＨの場合にはＳＲＮＣにより制御及びスケジューリングされ、ＨＳ−ＤＳＣＨについてデータ送信をスケジューリングするのはＮｏｄｅ  Ｂである。
【００４９】
データ送信のスケジューリングは、ユーザ装置にもはや格納可能でなく、破棄される必要があるデータパケットが送信されることを回避するため、受信側、すなわち、ユーザ装置の現在のバッファ状態を当然考慮すべきである。この場合、貴重なラジオリソースが使用される。ＳＲＮＣが、アクノリッジメントを待機することなく多数のＰＤＵ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｕｎｉｔ）として送信エンティティが送信することが許可されているウィンドウサイズにより与えられるウィンドウ機構に基づき、再送プロトコルを実現するラジオリンク制御プロトコルを実行するため、当該ウィンドウ機構がまたフロー制御に利用可能であり、これにより、パケットのストリームは、メモリが不足する場合には、受信側（ここでは、ユーザ装置）から送信されるメッセージによりスロット処理することが可能である。
【００５０】
しかしながら、ＨＳ−ＤＳＣＨのケースではスケジューリング機能の異なる位置によると共に、ＨＳ−ＤＳＣＨ上で利用可能なはるかに高いデータレートのため、このＲＬＣベースフロー制御は、かなり不活発であるため、ダウンリンクリソースを浪費することを完全には（少なくとも）回避することができないであろう。しかしながら、フロー制御は、ウィンドウベースのフロー制御機構より特別なアップリンクＳＴＯＰコマンドに基づき導入されるかもしれない。ユーザ装置がＨＳ−ＤＳＣＨにマッピングされた論理チャネルを介し受信したパケットを格納するためのメモリが不足しているとわかるとすぐに、このＳＴＯＰコマンドを送信し、それはＮｏｄｅ  Ｂにより受信され、所定の時間、この論理チャネルを介しＨＳ−ＤＳＣＨ上でさらなるパケットが送信されるべきでないと解釈される。
【００５１】
ここでの問題は、エアインタフェースを介しフロー制御によりＨＳ−ＤＳＣＨを使用するエンド・ツー・エンドサービスを求める選択肢をユーザに与えるため、最小限のネットワークノードがこのサービス属性クオリティを処理する必要があるように、この追加的なＱｏＳ属性「フロー制御」を含め、ＨＳ−ＤＳＣＨをＱｏＳアーキテクチャに利用するシンプルな方法を見つけることである。この結果、規格化の作業もまた最小化される。
【００５２】
本発明によると、最小限のネットワークノードしか当該属性を処理する必要がないように、ＱｏＳ属性をＱｏＳアーキテクチャに組み込むためのシンプルな手段が提供される。この技術は、例えば、各ＱｏＳ属性を認識する必要があるネットワークノードとユーザ装置との間でやりとりされるコンフィギュレーションメッセージが存在する場合、適用するようにしてもよい。
【００５３】
本発明によると、コンフィギュレーションメッセージは、チャネル化コード又はスクランブリングコードなど、ネットワークリソースを割り当てるためネットワークコードがユーザ装置に送信するメッセージであってもよく、このようなコンフィギュレーションメッセージの送信は、ユーザ装置に他のコンフィギュレーションメッセージを応答として送信され、これにより、ユーザ装置は、割り当てられたネットワークリソースがユーザ装置とネットワークとの間のデータ送信について利用可能であるように設定されたことを確認する。例えば、ＵＭＴＳでは、ＲＮＣは、データ送信用のラジオベアラを割り当てるため、又はデータ送信用にすでに確立されたラジオベアラを変更するため、ＲＡＤＩＯ  ＢＥＡＲＥＲ  ＲＥＣＯＮＦＩＧＵＲＡＴＩＯＮメッセージをＵＥに送信し、ＵＥはこれに対してＲＡＤＩＯ  ＢＥＡＲＥＲ  ＲＥＣＯＮＦＩＧＵＲＡＴＩＯＮ  ＣＯＭＰＬＥＴＥメッセージにより応答し、これによって、データが新たな又は変更されたラジオベアラを介し送信可能となるように設定されたことを示す。
【００５４】
コンフィギュレーションメッセージは、ボイスコールなど、サービスを要求するためＵＥがネットワークに送信する、又はネットワークの何れかにある他の端末装置（他のＵＥとすることもできる）によって開始されるボイスコールなど、入力サービスリクエストを受け付けるよう求められるため、ＵＥがネットワークから受信するコール制御メッセージと区別する必要がある。サービスをリクエストするのに使用される最新のコール制御メッセージは、通常はＱｏＳ属性を含む。
【００５５】
これらのコール制御メッセージは、コンフィギュレーションメッセージの送信を伴い、これにより、サービスをサポートするのに必要とされるリソースが割り当てられる。
【００５６】
一実施例によると、この問題は、図３に概略的に示されるように解決されるかもしれない。図３は、「フロー制御によるＨＳ−ＤＳＣＨ」を設定するための本発明による方法の実施例のフローチャートを示す。
【００５７】
本方法は、ステップＳ３０からスタートし、ユーザは、音楽の一部などのストリーミングデータをＢｌｕｅｔｏｏｔｈインタフェースしか有しないウォークマンやハイファイシステムにダウンロードすることを所望することを決定する。このデータは、ＵＭＴＳサービスプロバイダを介してのみ利用可能である。従って、ストリーミングデータのダウンロードは、ＵＭＴＳエアインタフェースとは別に、Ｂｌｕｅｔｏｏｔｈインタフェースを有し、これにより、ストリーミングデータをハイファイシステムに転送可能なユーザのＵＭＴＳ−ＵＥにより実行される。ダウンロードを迅速化するため、ダウンロードデータがＨＳ−ＤＳＣＨを介し送信されるように、ユーザは、ＵＭＴＳネットワークとのダウンリンク接続を設定しようとする。課金はエアインタフェースを介し送信されるデータ量に基づくため、ユーザは、エアインタフェースを介し送信されるが、ユーザ装置において破棄される必要があるかもしれないパケットに対する支払をする必要が生じることを回避するため、フロー制御を適用することを所望する。なぜなら、ユーザ装置は、Ｂｌｕｅｔｏｏｔｈインタフェースに対する一時的なボトルネックによりメモリが不足するためである。
【００５８】
ダウンロードを最終的にスタートするため、ユーザはまず、サーバからダウンロードする予定のデータがハイファイシステムなどのターゲット装置に転送されるように自らのユーザ装置を設定するようにしてもよく、そのことは、例えば、データが以降にターゲット装置にコピーされるように、Ｂｌｕｅｔｏｏｔｈ接続を介し到達可能なターゲット装置に当該ユーザ装置からドライブを「マウントする」ことを意味する可能性がある。これは、ステップＳ３１において実行される。
【００５９】
さらに、ユーザは、ＵＭＴＳネットワークを介し到達可能な音楽サーバとの接続を設定する必要があり、そこでユーザが所望の音楽部分を検出し、この接続のため、「高速」オプションを選択する必要がある。この結果、データはＨＳ−ＤＳＣＨを介しダウンロードされる。さらに、ユーザは、「フロー制御による」というオプションを選択してもよい。その後、「フロー制御によるＨＳ−ＤＳＣＨ」オプションが、ユーザ装置のＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）レイヤに格納される。ＲＲＣレイヤは、いわゆるＲＲＣメッセージに応答するためのものであり、これにより、ＵＴＲＡＮは、自らのＲＲＣメッセージによりＨＳ−ＤＳＣＨを介しデータを受信などするため、ユーザ装置を設定する。この設定ステップは、ローカル制御プリミティブにより実行され、これにより、ＲＲＣレイヤは、より上位のレイヤにより設定することが可能となる（ステップＳ３２）。
【００６０】
ここで、接続設定は、いくつかのステップにより実行される。
【００６１】
ユーザ装置は、それのＳＲＮＣ（Ｓｅｒｖｉｎｇ  ＲＮＣ）となる次に到達可能なラジオネットワークコントローラとのいわゆるＲＲＣ接続を設定する（ステップＳ３３）。
【００６２】
その後、ステップＳ３４において、ユーザ装置は、ＲＲＣ接続によって、エンド・ツー・エンドサービスをサーバにリクエストするため、ＣＭ＿ＳＥＲＶ＿ＲＥＱメッセージをネットワークに送信する。その後、ステップＳ３５において、ネットワークは、ユーザ装置に対する周知の「チャレンジ−レスポンス」スキームに基づき、認証プロセスを開始する。すなわち、ネットワークは乱数を送信し、当該乱数から、ユーザ装置は、当該ユーザ装置とネットワークにのみ知られている秘密鍵を使用して、ＲＥＳを計算し、これをネットワークに送信する。ネットワークは、受信したＲＥＳの値が乱数と秘密鍵からネットワークが計算可能な予想されるＲＥＳの値と等しい場合、ユーザ装置が認証されているとみなす。
【００６３】
認証成功後、ネットワークは、ユーザ装置とＳＲＮＣとの間の暗号化及びインテグリティプロテクションをスタートし（ステップＳ３６）、ステップＳ３７において、ユーザ装置は、エンド・ツー・エンドサービスを設定するため、ＳＥＴＵＰメッセージをネットワークに送信する。ステップＳ３８において、ネットワークは、ＣＡＬＬ＿ＰＲＯＣＥＥＤＩＮＧメッセージにより応答し、これにより、エンド・ツー・エンドサービスが確立される。
【００６４】
この時点までに、ユーザ装置は、エアインタフェースにより提供される共通のトランスポートチャネルを介してのみデータを送受信可能であり、それは、通常はＵＴＲＡＮによって実行される設定処理なしに、すなわち、ＳＲＮＣからコンフィギュレーションメッセージを送信することなく利用可能である。その後、ステップＳ３９において、ダウンロードが開始される。
【００６５】
しかしながら、少なくともダウンロードがスタートするとすぐに、エアインタフェースを介しユーザ装置に伝送される必要がある大量のデータは、ＵＴＲＡＮにＨＳ−ＤＳＣＨを介しデータを受信するためユーザ装置を設定させる。この設定は、例えば、図４のステップＳ４０においてＳＲＮＣがユーザ装置に送信するＲＡＤＩＯ  ＢＥＡＲＥＲ  ＲＥＣＯＮＦＩＧＵＲＡＴＩＯＮと呼ばれるＲＲＣメッセージにより実行される。
【００６６】
図４は、ＵＴＲＡＮによる受信ステーションの設定を示し、送信ステーションから受信ステーションへのデータのダウンロードのためのＱｏＳ制御を実行するフローチャートを示す。ステップＳ４０において、ＲＡＤＩＯ  ＢＥＡＲＥＲ  ＲＥＣＯＮＦＩＧＵＲＡＴＩＯＮメッセージを送信した後、ユーザ装置には、ＨＳ−ＤＳＣＨを介した送信用に使用されるチャネル化コード及びスクランブル化コードと共に、ＨＳ−ＤＳＣＨを介したデータ送信に必要とされるＲＬＣセッティング、データ送信に使用される論理チャネル及びラジオベアラアイデンティティが通知されるようにしてもよい。
【００６７】
ＲＲＣレイヤがＲＡＤＩＯ  ＢＥＡＲＥＲ  ＲＥＣＯＮＦＩＧＵＲＡＴＩＯＮメッセージを受信するとすぐに、それは、必要なローカル設定アクションをとる。すなわち、それは物理レイヤ、ＭＡＣ（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）レイヤ及びＲＬＣレイヤを設定する。ＲＬＣレイヤの設定に関して、これは、このために設定された論理チャネルを介し受信したダウンロードデータを処理するためのユーザ装置のＲＬＣエンティティには、それの受信バッファ占有がＰＤＵ損失を生じさせるある最大値に到達するとすぐに、物理レイヤに送信元のＮｏｄｅ  ＢにＳＴＯＰコマンドを発信すべきであると示すべきであるということが通知される。
【００６８】
ＵＴＲＡＮは、ユーザ装置からこのコンフィギュレーションメッセージに対するリプライを期待し、このリプライは、検討されているケースでは、例えば、セキュリティ関連データを搬送するＲＡＤＩＯ  ＢＥＡＲＥＲ  ＲＥＣＯＮＦＩＧＵＲＡＴＩＯＮ  ＣＯＭＰＬＥＴＥメッセージである。ＱｏＳ属性「フロー制御によるＨＳ−ＤＳＣＨ」を関連するネットワークノードに提供するため、本発明の一実施例によると、当該メッセージは、フロー制御が適用すべき論理チャネルリスト、すなわち、必要に応じてユーザ装置がスロットル処理することが可能であるべきデータストリームのパケットを搬送する論理チャネルにより補完される。ステップＳ４２において、ＲＡＤＩＯ  ＢＥＡＲＥＲ  ＲＥＣＯＮＦＩＧＵＲＡＴＩＯＮ  ＣＯＭＰＬＥＴＥメッセージはＳＲＮＣに送信されるが、ＱｏＳ属性「フロー制御」に関する情報は、Ｎｏｄｅ  Ｂにおいて知られている必要がある。なぜなら、真に高速なフロー制御を提供するため、これはＳＴＯＰコマンドに応答するノードであるためである。さらに、フロー制御が適用されるか否かに関係なく、ＳＲＮＣがＨＳ−ＤＳＣＨを介しデータをユーザ装置に送信するため、Ｎｏｄｅ  Ｂを設定することがとにかく要求されるかもしれない。従って、３ＧＰＰ規格は、既存のラジオリンクを再設定するため、ＤＲＩＦＴ  ＲＮＣなどを介しＳＲＮＣからＮｏｄｅ  Ｂに送信すべきメッセージを規定する。このメッセージは、参照することによりここに含まれる“ＴＳ２５．４３３  ３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ；Ｔｅｃｈｎｉｃａｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｇｒｏｕｐ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ；ＵＴＲＡＮ  Ｉｕｂ  Ｉｎｔｅｒｆａｃｅ  ＮＢＡＰ  Ｓｉｇｎａｌｌｉｎｇ”及び“ＴＳ２５．４２３  ３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ；Ｔｅｃｈｎｉｃａｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｇｒｏｕｐ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ；ＵＴＲＡＮ  Ｉｕｒ  Ｉｎｔｅｒｆａｃｅ  ＲＮＳＡＰ  Ｓｉｇｎａｌｌｉｎｇ”によるＲＡＤＩＯ  ＬＩＮＫ  ＲＥＣＯＮＦＩＧＵＲＡＴＩＯＮ  ＰＲＥＰＡＲＥと呼ばれる。
【００６９】
このＲＡＤＩＯ  ＬＩＮＫ  ＲＥＣＯＮＦＩＧＵＲＡＴＩＯＮ  ＰＲＥＰＡＲＥメッセージの送信は、ステップＳ４３において実行されてもよい。Ｎｏｄｅ  ＢにＱｏＳ属性「フロー制御によるＨＳ−ＤＳＣＨ」を認識させるため、このメッセージは、Ｎｏｄｅ  Ｂがユーザ装置によりＳＴＯＰコマンドを受信する場合にスロットル処理すべき対応するラジオベアラの論理チャネルのリストによって補完される。従って、Ｎｏｄｅ  Ｂは、受信したＰＤＵのＭＡＣヘッダを読む必要があり、当該ＭＡＣヘッダは論理チャネル識別子を有する（ステップＳ４４）。ステップＳ４５において、Ｎｏｄｅ  Ｂは、ユーザ装置からＳＴＯＰコマンドを受信する。その後、スロットル処理すべき論理チャネルのリストに基づき、Ｎｏｄｅ  ＢはＨＳ−ＤＳＣＨを介しこれらのチャネルのＰＤＵを送信することを回避することが可能である（ステップＳ４６）。
【００７０】
従って、アドミッション制御機能をネットワークに伴うことなく、リストの論理チャネルを介しさらなるデータパケット送信は行われず、これにより、ネットワークの実現を簡単化することができる。
【００７１】
ステップＳ４７〜Ｓ５０において、異なる実現形態が説明される。そこで、Ｎｏｄｅ  Ｂは、ＳＴＯＰコマンド受信後に送信されるべきでないＰＤＵを認識する。これは以下のように実行される。ステップＳ４７において、ＳＲＮＣは、Ｎｏｄｅ  Ｂへの送信前にＮｏｄｅ  Ｂがスロットル処理可能であるべき各論理チャネルのＰＤＵをタグ付けする。ステップＳ４８において、ＳＲＮＣは、タグ付けされたＰＤＵをＮｏｄｅ  Ｂに送信する。その後、例えば、ユーザ装置がＨＳ−ＤＳＣＨにマッピングされた論理チャネルを介し受信したパケットを格納するメモリが不足していると検出するため、ステップＳ４９において、ユーザ装置は、ＳＴＯＰコマンドをＮｏｄｅ  Ｂに送信する。Ｎｏｄｅ  Ｂが受信する当該タグ付きのＰＤＵは、ＳＴＯＰコマンドがユーザ装置から受信された後、ＨＳ−ＤＳＣＨを介したさらなる送信のためＮｏｄｅ  Ｂが考慮しないＰＤＵである。従って、タグ付けされたＰＤＵの送信は、ステップＳ５０においてブロックされる。
【００７２】
上記説明から理解されるように、通知アプローチは、ネットワークの「絶対」エッジについて成り立つ。ユーザ装置が特定のネットワークノードとメッセージをやりとりする限り、ＱｏＳ属性は、パスセグメントに容易に追加されるかもしれず、このネットワークノードにおいて終了する。
【００７３】
図５は、本発明による方法の一実施例のさらなる概略図を示す。受信ステーション（ＲＳ）又はユーザ装置（ＵＥ）は、設定処理中に第１コンフィギュレーションメッセージを第１ネットワークノード（Ｎ１）に送信する。この第１コンフィギュレーションメッセージは、第１ＱｏＳ属性（１．ＱｏＳＡ）を有する。第１ＱｏＳ属性を受信した後（第１コンフィギュレーションメッセージと共に）、第１ネットワークノードＮ１は、受信した第１ＱｏＳ属性に基づき第２ＱｏＳ処理（２．ＱｏＳＯ）を実行する。この第２ＱｏＳ処理は、データパケットが第１ＱｏＳ属性に基づき特定された第２論理チャネルグループの第２論理チャネルを介し送信される場合、データパケットのタグ付けを有するかもしれない。この場合、データパケットはタグ付けされる。なぜなら、それはリストされた第２論理チャネルの１つを介し送信され、第２ＱｏＳ属性（２．ＱｏＳＡ）が第１ネットワークノードから第２ネットワークノード（Ｎ２）に送信されるためである。この第２ＱｏＳ属性は、「フロー制御によるＨＳ−ＤＳＣＨ」に対する第２ネットワークノードへのリクエストを有するかもしれない。第２ネットワークノードが受信ステーションからＳＴＯＰコマンドを受信するとすぐに、第２ネットワークノードは、第１ＱｏＳ処理（１．ＱｏＳＯ）を実行する。第２ネットワークノードによって実行される第１ＱｏＳ処理は、タグ付けされたデータパケットのブロッキングを有する。
【００７４】
さらに、本発明の他の実施例によると、少なくとも１つの第１ネットワークノードによって実行される第２ＱｏＳ処理は、少なくとも第１ネットワークノードから第２ネットワークノードへの第１ＱｏＳ属性に基づき、第２ＱｏＳ属性の送信を有するようにしてもよく、第２ＱｏＳ属性は、複数の論理チャネルの第２論理チャネルグループの特定を有する。ユーザ装置又は受信ステーションからＳＴＯＰコマンドを受信した後、第１ＱｏＳ処理が、第２ネットワークノードによって実行される。この第１ＱｏＳ処理は、データパケットが第２論理チャネルのリストによって特定される論理チャネルを介し送信される場合、データパケットのブロッキングを有する。効果的には、第２ＱｏＳ属性は、第２設定処理中に少なくとも１つの第１ネットワークノードから第２ネットワークノードに送信される第２コンフィギュレーションメッセージに追加される。
【００７５】
第１ＱｏＳ属性又は第２ＱｏＳ属性を第１又は第２コンフィギュレーションメッセージの一部として送信することによって（当該コンフィギュレーションメッセージは、何れのケースにおいても送信される必要がある）、通知データトラフィック、特にアップリンクデータトラフィックは効率的に低減されるかもしれない。
【００７６】
図６は、本発明の一実施例による通信システムを示す。通信システムは、受信ステーション又はユーザ装置６０１と、例えば、音声ファイル用のデータサーバであるかもしれない送信ステーション６０９又はモバイル端末と、データプロセッサ６０３を有するコンピュータとを有する。通信システムは、第１ネットワークノードＮ１  ６０４や第２ネットワークノードＮ２  ６０２などの複数のネットワークノードを有するネットワークの一部である。データプロセッサ６０３は、通信リンク６０８を介し第２ネットワークノード６０２にリンクされる。さらに、データプロセッサは、ネットワークにおいて送信ステーションから受信ステーションへのデータ送信に対するＱｏＳ制御を実行し、又はネットワークノードＮ１  ６０４とＮ２  ６０２を有するネットワークにおけるデータ送信のための第１ＱｏＳ処理に対応する第１ＱｏＳ属性の送信を実行するためのソフトウェアプログラムを実行するのに使用される。送信ステーション６０９から受信ステーション６０１へのデータパケットの送信は、通信リンク６１０、６０６及び６０７を介し実行されるかもしれない。データパケットはまず、通信リンク（無線通信リンクなど）６１０を介し第１ネットワークノード６０４に送信され、その後、通信リンク６０６を介し第２ネットワークノード６０２に送信されるかもしれない。第２ネットワークノード６０２は、ＵＭＴＳのＨＳ−ＤＳＣＨ（Ｈｉｇｈ  Ｓｐｅｅｄ  Ｄｏｗｎｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）を介したデータ送信のためフロー制御を実行するため、例えば、通信リンク６０７の間にＳＴＯＰコマンドコマンドを送信することによって、受信ステーション６０１からトリガーされるようにしてもよい。図６に示される受信ステーション６０１は、通信リンク６０５及び６１１を介しネットワークの複数のネットワークノードの少なくとも１つの選択されたネットワークノード６０４に第１ＱｏＳ属性を送信するよう構成されてもよい。
【００７７】
本発明の一実施例によると、第１ＱｏＳ属性の送信は、第２ネットワークノード６０２を介し実行可能であるということに留意すべきである（ＵＭＴＳネットワークコンフィギュレーションの場合と同様に、第１ネットワークノードがＲＮＣに対応し、第２ネットワークノードがＮｏｄｅ  Ｂに対応するようにしてもよい）。しかしながら、現在のＵＭＴＳネットワークアーキテクチャ以外のアーキテクチャを有するネットワークでは、第１ＱｏＳ属性の送信はまた、通信リンク６１２を介し受信ステーション６０１から少なくとも１つの選択された第１ネットワークノード６０４に直接実行されてもよい。さらに、第２ネットワークノード６０２は、第１ネットワークノード６０４において受信した第１ＱｏＳ属性に基づき、第１ＱｏＳ処理を実行するよう構成される。
【００７８】
受信ステーションから第１ＱｏＳ属性を受信した後、第１ネットワークノード６０４は、第２ＱｏＳ処理を実行し、通信リンク６０６を介し第２ＱｏＳ属性を第２ネットワークノード６０２に送信する。本発明による方法の一実施例によると、この第２ＱｏＳ属性（効果的には、第２コンフィギュレーションメッセージと共に送信されるかもしれない）は、第２ネットワークノード６０２の受信ステーション６０１からＳＴＯＰコマンドを受信した後、ブロックされる必要があるネットワーク内部の複数の論理チャネルの第２論理チャネルグループの特定を有する。
【００７９】
データプロセッサ６０３は、本発明の実施例によるコンピュータプログラムがデータプロセッサ６０３上で実行されるとき、本発明の一実施例による処理を実行するよう構成される。
【００８０】
しかしながら、第２ネットワークノード６０２がデータプロセッサにリンクされるだけでなく、第１ネットワークノード６０４などの他のネットワークノード、送信ステーション６０９又は受信ステーション６０１が、各処理を実行するためデータプロセッサ（図６に図示せず）にリンク又は有するようにしてもよいということに留意すべきである。
【００８１】
上述した本発明は、例えば、無線通信ネットワークの分野に適用可能である。しかしながら、本発明はまた、グラスファイバ通信ネットワークなどの他の通信ネットワークの分野にも適用可能である。
【００８２】
効果的には、本発明の一実施例によると、ＱｏＳ属性はネットワークのエッジの選択されたいくつかのネットワークノードのみに送信される。この選択されたいくつかの（限定された）ネットワークノードは、受信ステーションによりトリガーされたＱｏＳ処理を実行する。従って、ＱｏＳ属性は、可能なすべてのパスセグメント、すなわち、すべてのネットワークレベルのアドミッション制御機能には送信されない。効果的には、これは、より少ない異なるネットワークノードタイプしか影響を受けないため、より少ないデータトラフィックと実現形態の向上をもたらすかもしれず、より少ないワーキンググループしか関与する必要がないため、規格化プロセスの向上をもたらすかもしれない。効果的には、本発明の一実施例によると、ＱｏＳ属性が必須のコンフィギュレーションメッセージに追加されてもよく、これにより、データトラフィックをさらに低減することが可能となる。
【００８３】
「有する」という用語は、他の要素又はステップを排除するものではなく、「ある」という用語は複数を排除するものでなく、単独のプロセッサ又はシステムが請求項に記載された複数の手段の機能を実現可能であるということに留意すべきである。
【００８４】
また、請求項における参照記号は、その範囲を限定するものとして解釈されるべきでないということに留意すべきである。
【図面の簡単な説明】
【００８５】
【図１】図１は、ＵＭＴＳ  ＱｏＳアーキテクチャの概略図を示す。
【図２】図２は、ネットワークノードを有するネットワークアーキテクチャの概略図を示す。
【図３】図３は、ＵＭＴＳネットワークにおける受信ステーションと送信ステーションの間のエンド・ツー・エンドサービスを確立するためのフローチャートを示す。
【図４】図４は、ＵＴＲＡＮによる受信ステーションのコンフィギュレーションを示し、送信ステーションから受信ステーションへのデータのダウンロードのためのＱｏＳ制御を実行するフローチャートを示す。
【図５】図５は、本発明による方法の一実施例を示す。
【図６】図６は、本発明による方法の一実施例を実行するための本発明によるデータ処理装置を有する通信システムの一実施例を示す。
【図１】
2007537652.tif 000003
【図２】
2007537652.tif 000004
【図３】
2007537652.tif 000005
【図４】
2007537652.tif 000006
【図５】
2007537652.tif 000007
【図６】
2007537652.tif 000008
【国際調査報告】
2007537652.tif 000009
2007537652.tif 000010
2007537652.tif 000011