JP4880775B2 - 通信ベアラに関する装置及び方法 - Google Patents

Description

本発明は相異なるトラフィック・タイプの情報の通信、特にパケット・データの通信をサポートする装置又はネットワーク・ノードと、情報を転送する方法とに関する。

ここ１０年間又はここ数年間の発展により、ユーザは多くの異なるタイプのサービスに様々な方式でアクセスできるようになってきた。サービスは固定ネットワークだけでなく無線ネットワークを通じても利用可能であり、音声、データ・サービス、ビデオ・サービス、メディア・サービスなどのような多種多様なサービスが存在する。増加しつつある数のサービスへのアクセスは、様々なアクセス技術を用いて、例えばＰＳＴＮ（公衆交換電話網）を介して、移動体通信網を介して、テレビ・チャネル、ケーブル又は衛星を介して、ＰＳＴＮ又はブロードバンド上で提供されるインターネット、例えばＷＬＡＮ（無線ローカルエリアネットワーク）などの無線アクセス・ネットワークを介して提供され得る。無線ユーザ局に対して、サービスは多くの異なる方法でアクセスされ得る。

異なるタイプのサービスに対して要求は異なる。従って、サービス品質（ＱｏＳ）という概念が導入されている。

３Ｇ移動体ネットワーク（３ＧＰＰ、第３世代パートナーシップ・プロジェクト）は通信リンクのために四つの相異なるタイプの無線アクセス・ベアラをサポートする。これらの無線アクセス・ベアラ（ＲＡＢ）は、会話型、ストリーミング型、インタラクティブ型、バックグラウンド型のタイプであり、これらはサポートするサービス品質（ＱｏＳ）が異なる。

会話型ＲＡＢについて、要件は最も厳しくて、遅延が短く且つトラフィック・ストリームの情報エンティティ間の時間関係（変動）が保存されることが重要である。会話型アプリケーションの典型例は音声である。

ストリーミング型ＲＡＢは会話型ＲＡＢと同様に時間関係を保存することが要求されるものの、短い遅延を保証しない。典型例はストリーミング・ビデオである。

インタラクティブ型ＲＡＢはウェブ・ブラウジングのようなアプリケーションに適する。なぜなら、インタラクティブ型ＲＡＢは単に要求‐応答パターンに従うアプリケーションのために用いられるからである。最後に、バックグラウンド型ＲＡＢは、所定の時間フレーム内にデータが期待されない場合のアプリケーションのために用いられ得る。バックグラウンド型ＲＡＢが適するアプリケーションの例は電子メールやバックグランドでのダウンロードなどである。バックグラウンド型ＲＡＢはベストエフォート型ＲＡＢでもある。

上述のＲＡＢの振る舞いは、会話が行われている限り連続的にＲＡＢが必要となる人間対人間の通信のために設計されていて、この通信に適しており、又は人間対コンピュータ通信、例えばウェブ・ブラウジングのために設計されていて、この通信に適している（ＲＡＢは所定のバッファが満たされるのを待つ間に非アクティブ状態に移行し得る）。

しかしながら、近い将来には１億のモバイル・コネクションが存在するだろうし、これらのコネクションの５０％超が機械又はその他の人間以外から由来するコネクションであろうことが推測される。実際に、このような人間以外から由来するコネクションは、人間に由来する今日のコネクションの大部分とはまったく異なるトラフィック・パターンを有するだろう。産業プロセスを監視するセンサ・ネットワークのようなネットワークの監視は、オペレータ若しくは中央データベース又はそれ以外のどこかに測定データをおおよそ周期的に転送することが要求されるだろうことが信じられている。

このような転送イベントを処理する一つの方法は、各転送イベントのために新たな通信リンク又はＲＡＢを設定することである。しかしながら、各転送イベントの間に送信されるデータ量はしばしば非常に小さく、いくつかのアプリケーションではたった数ビットであろうことを心にとどめるべきである。このことは、この目的のためのＲＡＢの確立及び開放は、各時間に転送される実際のユーザ・データに関するデータのシグナリングが不均衡に高く使用されるだけであることを意味する。すなわち、各時間のＲＡＢの確立及び開放は重大なシグナリングのオーバヘッドを伴う。このことは、本質的に、ネットワーク・リソースの利用効率が非常に粗悪であるだろうことを意味する。頻繁に通信リンクを確立及び開放することはまた、転送される情報を生成する機械に悪影響を与える。このことは特にしばしば限られたエネルギー・リソースを有し、従ってこのような機械に存続期間が存在し、例えばエネルギー蓄電池は置き換えられなければならないセンサ・ネットワークの場合に成り立つ。

このようなイベントを処理する別の方法はＲＡＢを確立してこれを無制限に維持することであり得るだろう。しかしながら、この場合には、各時間において、送信されるデータ又は情報が存在しない場合や非常に小さい量だけが送信される場合にも、ネットワーク・リソースが不必要に占拠される。このことは全体的なネットワーク容量を減らし、トラフィック・リソースだけでなくシグナリングを浪費し、このことはまた他のサービス及びユーザをサポートする能力及び容量を減らす。

情報の反復転送（repetitive transfer）を処理するためにインタラクティブ型ＲＡＢが設定される場合に、転送する情報又はデータがないときに非アクティブ状態（スリープ・モード）に移行するような方法でインタラクティブ型ＲＡＢが構成し得るだろうことが確立されてきている。その後にネットワーク・リソースのほとんどは開放され、指定されたバッファが一杯になった際に再び「起きる」ようになされ得るだろう。しかしながら、転送イベントが実行される毎回ごとにネットワーク・リソースにアクセスすることを保証する方法は存在しない。このことは、バッファが満たされてデータが転送されるべきになった時点で、ネットワーク・リソースが再び割り当てられなければならないことを意味する。そして、ネットワーク・リソースが実際に利用可能であるかは定かではない。なぜならば、その間にネットワーク・リソースが他のユーザにより占拠されているかもしれないからである。一般に、ネットワーク・リソースは先着順に割り当てられ、いかなる反復転送パターンをも考慮に入れることはあり得ない。

会話型ＲＡＢはパッシブなスリープ状態に入ることができない。会話型ＲＡＢは完全にアクティブであり、ネットワーク・リソースが割り当てられるか、存在しないかのいずれかである。このことはストリーミング型ＲＡＢにも当てはまる。

バックグラウンド型ＲＡＢを用いることも十分でない。なぜならば、タイムリーな情報の配信が保証されなく、このことは例えば処理制御監視データや医療データ転送などにおいてしばしば重要である。

よって、今日では情報、特におおよそ周期的に発生し、又は反復転送パターンに従う比較的少量のデータの転送を処理する満足できる方法は存在しない。

従って、反復して転送される必要のある情報の転送を処理する手段を提供することが本発明の一つの目的である。特に所与の一定の頻度又は変動する頻度で情報が転送され得るとともに、ネットワーク・リソースが浪費されない解決策が必要となる。さらに具体的には、シグナリング・リソースの使用が低く抑えられ得る解決策が必要となる。用いられるシグナリング・リソースと転送される情報量との間の関係を最適に維持し得る解決策、すなわち最小のシグナリング・リソースを用いて転送データ量を最大とする解決策も必要とされる。さらに、効率的且つ確実で複雑でない方法でデータを転送できる解決策が必要となる。さらにいっそう具体的には、少量の情報、特に機械生成されたデータが、シグナリング・リソース又はトラフィック・リソースのいずれかを浪費することなく反復してタイムリー且つセキュアに転送され得る解決策が必要となる。特に、上述の目的の一つ以上が達成され得るネットワーク・ノードが必要となる。

反復して情報を転送するとともに、上述の目的の一つ以上が達成され得る方法を提供することが本発明のさらなる一つの目的である。

上述の目的の一つ以上を実現するために、パケット・データの通信をサポートするネットワーク・ノードが提供され、当該ネットワーク・ノードはベアラ・サービス処理手段を備え、複数の属性をそれぞれが規定する一つ以上のベアラ・サービスをサポートする。本発明によれば、ネットワーク・ノードは、反復するデータ転送を処理するように構成されたベアラ・サービスをサポートするように構成される。特に、管理手段は少なくとも二つの連続する情報転送イベントの間の期間に関する情報を備えるベアラ・サービスの第１の追加属性と、転送イベントで転送されるデータ情報量に関連する情報を備えるベアラ・サービスの第２の追加属性とを処理するように構成される。管理手段は、二つの連続する情報転送イベントの最初のものが終了した場合に、活性化された反復型ベアラ・サービスを非活性化しするとともにリソースを開放し、前記第１の追加属性により示される後続のデータ情報転送イベントにおいて再活性化をすることを提供するように構成される。

ネットワーク・ノードは、特定のＱｏＳを有するベアラ・サービスの利用可能性、変更及び維持を制御するベアラ・サービス（ＢＳ）管理手段と、情報の転送を要求するベアラ・サービスの間にリソースを分配するように構成されたリソース処理手段とを備える。ネットワーク・ノードはまた、ベアラ・サービス属性の処理を提供し、一つの実施形態ではベアラ・サービス処理属性と複数のトラフィック・クラスに対して与えられたＱｏＳ属性／プロファイルとの間のマッピングをも提供するするように構成されたベアラ属性処理手段と、ベアラ・サービスのリソースの割り当てに関する情報を制御し保持するように構成されたアドミッション制御手段とを備える。

従って、パケット・データの通信をサポートする移動体ネットワークにおける情報の反復転送を処理する方法も提供され、本方法は、少なくとも連続する第１の情報転送イベントと第２の情報転送イベントとの間の期間を示す第１の追加ベアラ・サービス処理属性を提供するステップと、少なくとも前記第１の情報転送イベントにおいて転送される情報量に関連する情報を備える第２の追加ベアラ・サービス処理属性を提供するステップと、少なくとも前記転送イベントについて、反復情報転送のためにベアラを提供又は設定するとともにコア・ネットワーク及び無線ネットワーク内のリソースを予約するために、前記第１の追加属性及び前記第２の追加属性を用いるステップと、前記第１の転送イベントが完了するまで、すなわち前記第２の追加属性により示される情報量が転送されるまでは前記設定されたベアラを維持するステップと、前記第１の追加属性により示された前記期間の経過後に前記反復型ベアラを自動的に再活性化するステップと、所与のイベントが発生するまでは前記第１の追加属性及び前記第２の追加属性により示されるように前記ベアラの自動的な維持、非活性化、再活性化を繰り返すステップとを含む。

本発明の一つの利点は、最少のシグナリング・オーバヘッドを伴い、トラフィック・リソースが節約される、周期的な情報転送のための新たな又は追加のＲＡＢ状態又は変更されたＲＡＢ状態が提供されることである。特に、本発明の利点は、特に機械生成データの情報の転送が確実且つリソース使用効率の高い方法で提供され得ることである。特に、反復する又は周期的な転送パターンが考慮に入れられ、所望の際にタイムリーに情報（データ）が転送され得ることが保証され得ることが一つの利点である。さらに具体的には、少量の情報、特に機械生成データが一定の又は変動する周期性で、特に転送される比較的少量のデータに関して、リソースを占有する必要なく且つ過度のシグナリングを必要とすることなく転送され得ることが一つの利点である。さらに、特に近い将来に広範囲に及び頻繁に起こることが予想される少量の機械生成データ、例えば監視目的のデータの転送のためのベアラ・サービスにおいて、複数の個別の情報転送サービスが、他のユーザ又はサービスのためのリソースを浪費することなく、可能であることが本発明の一つの利点である。

さらに、反復パターンを有するトラフィック・クラスの処理を可能にする柔軟な解決策が提供され、さらにはネットワーク容量計画が改良され得、大量の監視ネットワークを処理し得ることが一つの利点である。移動体ネットワークの容量を増加し、実際に利用可能な容量をこれまでよりも効率的に使用することを可能とする解決策が提供されることも一つの利点である。

３ＧＰＰ ＴＳ ２３．１０７に記載されたＵＭＴＳベアラ・サービスのレイヤ・アーキテクチャを示す。 図１に示されるアーキテクチャに対する制御プレーンのＱｏＳ管理機能を示す。 図１に示されるアーキテクチャに対するユーザ・プレーンのＱｏＳ管理機能を示す。 本発明の概念の実装に関与する例示的なノードの組を説明する単純化されたブロック図である。 本発明の概念が実装される無線アクセス・ネットワーク・ノードを説明する概略ブロック図である。 本発明の概念が実装されるコア・ネットワーク・ノードを説明する概略ブロック図である。 本発明の概念が実装される移動局の概略ブロック図である。 反復型無線アクセス・ベアラの最初の確立におけるＭＳ、ＲＡＮノード及びＣＮノード間のメッセージングを示すシーケンス図である。 最新のベアラ・トラフィック・クラスの状態と、本発明に係る反復型クラスを規定するＵＭＴＳ／無線アクセス・ベアラ属性の例を示す。 本発明の概念の一つの実装を表す概略フロー図である。 本発明の概念の別の実装を表す概略フロー図である。

本発明は添付の図面を参照しつつ以下に説明されるが、これに限定されない。

本発明によれば、周期的なデータ転送に対して、新たなベアラ状態が導入され、この新たなベアラ状態は最小のシグナリング・オーバヘッドのみを必要とし、新たな呼がシステムに収容されなければならない将来において、宣言された転送を考慮に入れる。または、既存のベアラ・クラスに反復性を考慮に入れる機能が提供され得る。

好適には、シグナリング・メッセージは一度だけ、つまり最初の反復型ベアラ又はＲＡＢ確立の間にだけ交換される。ユーザは後続の情報転送イベントの間の期間と、一つのセッション中に反復型ベアラがアクティブでなければならない時間、特に転送イベントの間に送信される情報量に対応する時間とを（動的又は静的に、若しくは要求に応じて変更可能なように）規定するだろう。すべての後続の反復型ベアラ又はＲＡＢの非活性化及び再活性化は、シグナリング・メッセージの交換を要求することなく、ネットワーク、すなわち影響を受けるネットワーク内のノードにより自動的に行われるだろう。ネットワーク又はネットワーク・ノードは、新たなセルのためのネットワークの利用可能性を算出する際に、個別のアドミッション制御アルゴリズムにおける最初の反復型ベアラ又はＲＡＢの確立の間にユーザにより提供されるパラメータである上述された第１及び第２の追加属性を用いる。

特に、個別のネットワーク・ノードそれぞれの管理手段は、第１及び第２の追加ベアラ・サービス属性に関する情報を保持するように構成される。さらに、管理手段は好適には、転送イベントの終了時にベアラ・リソースを開放するように構成されるとともに、後続の転送イベントにおける再活性化のためのリソースを予約するように構成されたリソース処理手段を制御するように構成される。ノードの管理手段はさらに好適には、上述の第１及び第２の追加属性に関する情報を、反復型ベアラ・サービスのためのベアラ設定に関与するすべてのノードの管理手段に特にエンド・ツー・エンドで通信するように構成される。このようにして、後続の転送イベントにおいてネットワークを通じて必要な場合にリソースが再活性化され得る。

管理手段は特に、ネットワーク・ノードの利用可能なすべてのリソースに関する情報と、ベアラ・サービスに割り当てられたすべてのリソースに関する情報とを保持するアドミッション制御手段を備え、又はこのアドミッション制御手段と通信する。上記のアドミッション制御手段は特に、とりわけ新たなセルへのリソースの割り当てにおいて上記の第１及び第２の追加属性に関する情報を検討するように構成される。

好適には、管理手段はタイマを備え、またはタイマと通信する。このタイマは上述の反復時間間隔すなわち第１の追加属性に設定されるように構成される。管理手段はまた、上述の時間間隔が経過すると、個別の反復型ベアラの再確立を引き起こすように構成される。

特に、保持手段は、タイマ間隔を規定する第１の追加属性を保持及び制御する手段を備える。管理手段は属性取処理手段を制御するように構成された属性制御手段を備え、これらは、各転送イベントにおいて第１の属性の値が維持されるべきか又は変更されるべきかを確立し、及び／又は、各転送イベントについて第２の属性の値が維持されるべきか又は変更されるべきかを確立するように構成される。また、このことは第１の属性によって与えられる頻度に対応しない所定の頻度で行われてもよいし、要求に応じていかなる時点で行われてもよい。各後続の転送イベントにおいて第１の属性値が維持又は変更されるべきなのは与えられた時間間隔によるのか、それとも要求に応じたものかを確立するように構成された検出手段が提供されてもよい。一つの実施形態では、管理手段又は保持手段は、第１の属性と第２の属性との少なくともいずれかを変更する要求を受信するまでは第１及び第２の追加属性を保持し、それによって周期的に反復して活性化されるベアラ・サービスを維持する。

管理手段又はアドミッション制御手段はまた、第１の情報転送イベントにおいて反復型ベアラの設定に必要となるネットワーク・パラメータ及び参照と、第１の属性と第２の属性との少なくともいずれかが変更される場合に後続の転送イベントにおいて変更される更新版のネットワーク・パラメータ及び参照とを記憶する記憶手段を備えてもよく、またはこの記憶手段と通信してもよい。

大部分の有用な実装では、ネットワーク・ノードは、データ、より具体的には例えばセンサ・ネットワーク又は監視ネットワークにより生成される機械生成データを備える反復情報転送を処理するように構成される。これに代えて、またはこれに加えて、ネットワーク・ノードは音声を備える情報を処理するように構成されてもよい。

管理手段は多くの場合に好適には、反復転送イベントを処理するために、最初の反復型ベアラの確立時に制御メッセージを送受信するように構成されるとともに、上記の第１及び第２の属性に従って自動的に後続の反復型ベアラの非活性化／再活性化を実行するように構成される。

そして、制御メッセージは反復型ベアラ・サービスに関与するすべての他のノードに送信される。ノードは無線アクセス・ネットワーク・ノード、例えばＲＮＣ（無線ネットワーク制御装置）、ＢＳ（基地局）すなわちノードＢ、ＡＰ（アクセス・ポイント）を備えてもよく、この場合に無線アクセス・ネットワーク・ノードは第１及び第２の追加属性を備えるシグナリング情報をコア・ネットワーク・ノードから受信する。ノードはまた、コア・ネットワーク・ノード、例えば実質的に同じ機能を備えるＳＧＳＮ（パケット・アクセス制御ノード）、ＣＮ（コア・ネットワーク）エッジ・ノード、又はＣＮゲートウェイ・ノードを備えてもよい。この場合に、関係する他のコア・ネットワーク・ノード、例えばＧＧＳＮ（パケット・ゲートウェイ・ノード）などと、関係する無線アクセス・ネットワーク・ノードとに向けてシグナリングされる情報が必要となる。ネットワーク・ノードはまた、移動端末、例えば端末機器、ＰＣ、ラップトップ、パームトップ、又はより一般的には移動局を備えてもよい。第１及び第２の追加パラメータは通常はまず移動局のユーザ・インタフェースを介して入力され、変更された無線アクセス・ベアラ割り当てを開始するコア・ネットワークにその後に提供される。

一つ以上の上述の目的を達成するために、付随するオプションの又は好適な実施形態が発明の方法についても提供され、好適な実施形態は添付した個別の従属項で与えられる。

本発明は二つの追加属性の導入を通じて可能となる新たなベアラ・クラス（又は拡張機能を有する「旧」ベアラ・クラス）の導入からなると言い得る。他の観点では、処理手段は実質的に例えば３ＧＰＰ ＴＳ ２３．１０７ ｖ６．４．０に記載されたものと同一である。ベアラ・サービスの機能とエンドユーザのＱｏＳ要件とを説明するために、図１、図２及び図３が参照される。ＱｏＳについての複数の技術要件が存在する。これらの要件は、例えばＵＭＴＳのＱｏＳに対する複数の基準を満たすべき属性の集合によって規定でき、ＵＭＴＳのＱｏＳ制御メカニズムは、ユーザ機器と３Ｇゲートウェイ・ノードとの間のピア・ツー・ピアによるＱｏＳ属性制御を提供するだろう。さらに、アプリケーション要件とＵＭＴＳサービスとの間にマッピングが存在すべきであり、ユーザ機器又は３Ｇゲートウェイ・ノード内のアプリケーション又は特別なソフトウェアは自身のデータ転送についてのＱｏＳ値を示し得るべきであり、ＱｏＳ振る舞いは動的などであるべきである。

ネットワーク・サービスは通常はエンド・ツー・エンド、すなわち一つの端末機器から別のものまでとみなされ、ネットワーク・サービスは所定のＱｏＳを有してもよい。所定のネットワークＱｏＳを実現するために、明確に規定された特性及び機能を有するベアラ・サービスがサービスのソースから宛先にむけて設定されるべきであり、ベアラ・サービスは契約されたＱｏＳの提供を可能とするために必要となるすべての側面を含む。とりわけ、これらの側面はシグナリング制御、ユーザ・プレーン・トランスポート、及びＱｏＳ管理機能を伴う。

図１はＵＭＴＳベアラ・サービスのレイヤ・アーキテクチャを示し、特定のレイヤ上の各ベアラ・サービスは下位レイヤにより提供されるサービスを用いて自身の個別のサービスを提供するように構成される。

ＴＥ（端末機器）は図１では移動終端機器ＭＴを用いてＵＭＴＳネットワークに接続され、アプリケーション・レベルのエンド・ツー・エンド・サービス１Ｓは（通常はいくつかのネットワークであり、ＵＭＴＳだけではない）下層のネットワークのベアラ・サービスを用いる。ＴＥにより用いられるエンド・ツー・エンド・サービス１ＳはＴＥ／ＭＴローカル・ベアラ・サービス２Ｓ₂、ＵＭＴＳベアラ・サービス２Ｓ₁、及び外部ベアラ・サービス２Ｓ₃を用いて実現される。ＴＥ／ＭＴローカル・ベアラ・サービス及び外部ベアラ・サービス２Ｓ₃は本明細書ではさらには議論されないだろう。なぜなら、本明細書でＵＭＴＳのＱｏＳを提供するのはＵＭＴＳベアラ・サービス２Ｓ₁であるからである。

ＵＭＴＳベアラ・サービス２Ｓ₁は無線アクセス・ベアラ・サービス３Ｓ₁及びＣＮ（コア・ネットワーク）ベアラ・サービス３Ｓ₂で構成される。無線アクセス・ベアラ・サービス３Ｓ₁は、交渉されたＵＭＴＳベアラ・サービスに従うＱｏＳを、ＭＴとＣＮエッジ・ノードとの間のシグナリング及びユーザ・データの転送に提供する。コア・ネットワーク・ベアラ・サービス３Ｓ₂はＣＮゲートウェイを用いてＵＭＴＳのＣＮエッジ・ノードを外部ネットワークに接続する。このサービスは、契約されたＵＭＴＳベアラ・サービスを提供するために、バックボーン・ネットワークを効率的に制御及び利用する。

無線アクセス・ベアラ・サービス３Ｓ₁は無線ベアラ・サービス４Ｓ₂及びＲＡＮアクセス・ベアラ・サービス４Ｓ₁によって実現される。無線ベアラ・サービス４Ｓ₂は無線インタフェース・トランスポートの側面をカバーし、本明細書では特にＵＴＲＡＮ（ＵＭＴＳ地上波無線アクセス・ネットワーク）、ＦＤＤ／ＴＤＤ（周波数分割複信／時分割複信）、又はＧＥＲＡＮ（ＧＳＭエッジ無線アクセス・ネットワーク）により提供される。ＲＡＮアクセス・ベアラ・サービス４Ｓ₁は物理ベアラ・サービス５Ｓ₁とともにＲＡＮとＣＮとの間のトランスポートを提供する。パケット・トラフィックのためのＲＡＮアクセス・ベアラ・サービス４Ｓ₁は様々なＱｏＳに対して異なるベアラ・サービスを提供する。ＲＡＮアクセス・ベアラ・サービスはＩｕ又はＧｂベアラ・サービスにより提供される。

コア・ネットワーク・ベアラ・サービス３Ｓ₂は汎用バックボーン・ネットワーク・サービス４Ｓ₃を用い、これはコア・ネットワーク・ベアラ・サービス３Ｓ₂のＱｏＳ要件を満たすために事業者の選択に従って選ばれ得る。

最新技術の図である図２及び図３を参照して、制御プレーン及びユーザ・プレーンにおけるＵＭＴＳベアラ・サービスのためのＱｏＳ管理機能がそれぞれ簡潔に説明される。

しかしながら、本発明の概念はＵＭＴＳに基づいて実装されることに限定されないことは明らかであるはずである。ＵＭＴＳは単なる一つの特定の例である。

ここでは、特定のＱｏＳを有するＵＭＴＳベアラ・サービスを確立し、変更し、維持するために必要な機能の概観を与えることを意図する。すべてのＵＭＴＳノードのＱｏＳ管理機能はＵＭＴＳベアラ・サービスのアクセス・ポイント間の交渉されたサービスの提供をともに保証するエンティティであるものの、エンド・ツー・エンド・サービスはＵＭＴＳ外部サービスに翻訳／マッピングすることによって提供される。

ＱｏＳ管理のために、制御プレーンは複数の機能、つまり担当するサービスを確立し、変更し、維持する制御プレーンの機能を調整するサービス・マネージャ機能を備える。さらに、これはまた、関連属性を有するすべてのユーザ・プレーンＱｏＳ管理機能をピア・サービス・マネージャなどに提供する。これはまた、ＵＭＴＳベアラ・サービス制御のための内部サービス・プリミティブと外部ネットワークのインタフェースのサービス制御のための様々なプロトコルとの間で変換する翻訳機能を備える。変換は、ＵＭＴＳベアラ・サービス属性と外部ネットワーク・サービス制御プロトコルのＱｏＳ属性との間の変換を含む。これはさらに、ネットワーク・エンティティの利用可能なすべてのリソースに関する情報及びＵＭＴＳベアラ・サービスに割り当てられたすべてのリソースに関する情報を維持するアドミッション／能力制御手段を備える。これらの手段はＵＭＴＳベアラ・サービスの各要求又は各変更について、要求されたリソースがこのエンティティにより提供され得るかどうか、ＵＭＴＳベアラ・サービスに割り当てられた場合にそれがリソースを予約するかどうかを判定する。最後に、これは、本明細書ではさらには説明されないだろう加入制御機能を備える。

図２は制御プレーンにおけるＵＭＴＳベアラ・サービスのためのＱｏＳ管理機能を示す。ＭＴ（移動終端装置）及びゲートウェイ内の翻訳機能（翻訳）は外部サービス・シグナリングと内部サービス・プリミティブとの間を変換し、この変換はサービス属性の翻訳を含む。ノードであるＭＴ、ＣＮエッジ、及びゲートウェイはＵＭＴＳ ＢＳ（ベアラ・サービス）マネージャを備える。ＵＭＴＳ ＢＳマネージャはそれぞれの間で、翻訳機能を介して、ＵＭＴＳベアラ・サービスを確立又は変更するために外部インスタンスとシグナリングする。ＵＭＴＳ ＢＳマネージャは、関連するアドミッション／能力制御手段と、個別ノードが要求された特定のサービスをサポートするかどうか、及び要求されたリソースが利用可能であるかどうかを通信する。ＭＴ内のＵＭＴＳ ＢＳマネージャはＵＭＴＳベアラ・サービス属性をローカル・ベアラ・サービスについての属性に翻訳し、このローカルＢＳマネージャからのサービスを要求する。ＣＮエッジのＵＭＴＳ ＢＳマネージャはＵＭＴＳベアラ・サービス属性をＲＡＢサービス属性及びＲＡＮアクセス・ベアラ・サービス属性に翻訳し、これはＵＭＴＳベアラ・サービス属性をＣＮベアラ・サービス属性に翻訳する。ＣＮエッジ内のＵＭＴＳ ＢＳマネージャはまた、自身のＲＡＮアクセスＢＳマネージャ、自身のＣＮ ＢＳマネージャ、及びＲＡＮ（無線アクセス・ネットワーク）内のＲＡＢマネージャに要求されたサービスを提供することを要求する。

ＲＡＮ内のＲＡＢマネージャは自身のアドミッション／能力制御を用いて、要求された特定のサービスをＲＡＮがサポートするかどうか、及び要求されたリソースが利用可能であるかどうかを検証する。これは、ＲＡＢサービス属性を無線ベアラ・サービス属性及びＲＡＮアクセス・ベアラ・サービス属性に翻訳し、無線ＢＳマネージャ及びＲＡＮアクセスＢＳマネージャに対して要求された属性を用いてベアラ・サービスを提供することを要求する。

ゲートウェイＵＭＴＳ ＢＳマネージャはＵＭＴＳベアラ・サービス属性をＣＮベアラ・サービス属性に翻訳し、自身のＣＮ ＢＳマネージャに対してサービスを提供することを要求する。これはまた、ＵＭＴＳベアラ・サービス属性を外部ベアラ・サービス属性に翻訳し、この外部ＢＳマネージャからのサービスを要求する。無線ＢＳマネージャ、ＲＡＮアクセスＢＳマネージャ、及びＣＮ ＢＳマネージャは図２に示された下位レイヤにより提供されるサービスを用いる。これらは本明細書ではさらには議論されない。

図内の細い矢印はプロトコル・インタフェースを示し、太い矢印はサービス・プリミティブ・インタフェースを示す。

図３はユーザ・プレーンにおけるＵＭＴＳベアラ・サービスについてのＱｏＳ管理機能を説明する。これは、ベアラ・サービスによる転送において意図されたＱｏＳの受信のために要求される特定のマーキングを各データ・ユニットに提供するマッピング機能を備える。これはさらに、ＭＴが複数のＵＭＴＳベアラ・サービスを確立させる場合に、関連するＱｏＳ属性に従って確立されたＭＴのサービスにデータ・ユニットを割り当てる分類機能を備える。これはさらに、同じリソースを共有するすべてのサービスの間で、利用可能なリソースを分配するリソース・マネージャを備える。これは、要求されたＱｏＳ、例えば、無線ベアラについてのスケジューリング、帯域管理、及び電力制御に従って、リソースを分配する。

サービスについて交渉されたＱｏＳとデータ・ユニット・トラフィックとの間の一致を提供するためのトラフィック調整器も提供される。これは本明細書ではさらには議論されない。

ユーザ・プレーンのＱｏＳ管理機能の機能は、ＵＭＴＳ ＢＳ制御機能により確立されるとともにベアラ・サービス属性により表現されるコミットメントに従ってデータ転送特性を維持するように意図される。これらはＱｏＳ管理制御機能により関連属性が提供され、本発明によれば、第１及び第２の追加属性をも提供される。

ゲートウェイ内及びＭＴ内の分類機能（分類）は、外部ベアラ・サービス又はローカル・ベアラ・サービスから受信されたユーザ・データ・ユニットを、各ユーザ・データ・ユニットのＱｏＳ要件に従って適切なＵＭＴＳベアラ・サービスに割り当てる。ＭＴ内のトラフィック調整器は、上りリンクのユーザ・データ・トラフィックと関連ＵＭＴＳベアラ・サービスのＱｏＳ属性との一致を提供する。ゲートウェイのトラフィック調整器は、ＰＤＰコンテキストごとに、下りリンク・ユーザ・データ・トラフィックと、関連するＵＭＴＳベアラ・サービスのＱｏＳ属性との一致を提供してもよい。ＲＡＮ内のトラフィック調整器は、関連ＱｏＳ属性に従って下りリンク・データ・ユニット・トラフィックを形成する。リソース・マネージャはまたトラフィック調整器などの機能を機能を提供する。ネットワーク・エンティティのリソース・マネージャのそれぞれは、特定のリソースを担当する。リソース・マネージャは自身のリソースを、これらのリソース上のデータ・ユニットの転送を要求したすべてのベアラ・サービスの間で分配する。それによって、リソース・マネージャは個別のベアラ・サービスのそれぞれに対して要求されたＱｏＳ属性を提供することを試みる。

本発明によれば、本明細書では反復型と呼ばれる追加のベアラ・タイプが提案され、このベアラ・タイプは会話型、ストリーミング型、インタラクティブ型、及びバックグラウンド型とは異なる。または、既存のベアラ・タイプがオプション機能で拡張される。反復型ベアラ・クラス又は変更されたベアラ・クラスはとりわけ二つの付加的な属性の追加を伴う。その他の側面では、ＵＭＴＳベアラ・サービスについての既知の基本機能を説明する図１、図２及び図３を参照して上述された管理機能が適用される。本発明によれば、ベアラの確立及び開放は、上述されたものと同様に実行されるが、上記でアドミッション／能力制御と表され、特に上述の関連ノードで実装される二つの新たな属性の追加及びアドミッション・アルゴリズムの採用による変更が異なる。

本発明によれば、シグナリング・メッセージは一度だけ、つまり最初のＲＡＢ確立の間に交換されるだろう。ユーザは、連続する二つのデータ転送の間の時間と、一つのセッション又は転送イベントの間にＲＡＢがアクティブとなるべき時間とを規定するだろう。すべての後続のＲＡＢの活性化及び非活性化は、シグナリング・メッセージを交換する必要なくネットワークにより自動的に行われるだろう。ネットワークは、新たなセルについてネットワーク・リソースの利用可能性を算出するアドミッション・アルゴリズムにおいて、最初のＲＡＢ確立の間にユーザにより提供されたパラメータを用いるだろう。

連続する転送イベントの間の期間が同一であり続け、且つ各転送イベントにおいて転送されるデータ量又は情報量が同一である場合に、後続の転送イベントについてシグナリング・メッセージが必要とされないということは正しい。有用な実装では、転送イベントの間の期間又は転送される情報量は、例えば各転送イベントにおいて、又は所与の周期性又は明示的な要求によって、若しくは新たな状況が考慮に入れられる場合に変更され得る。しかしながら、第１の追加属性と第２の追加属性との少なくともいずれかの変更を示すために必要となるのは非常に少量のシグナリングである。

さらに、反復型ベアラ又はＲＡＢの確立及び開放は、二つの新たな属性が検討され、それに応じてノードにおける反復型アドミッション・アルゴリズムが適応されるという追加を伴った従来のベアラと同様の方法で実行されるだろう。

図４は本発明の概念により影響を受ける三つのネットワーク・ノードの非常に簡略化されたブロック図を示し、図４では移動局１０、ＲＮノード２０（無線アクセス・ネットワーク・ノード）、及びＣＮノード３０（コア・ネットワーク・ノード）を備える。新たな種類のベアラを考慮するためにその他のノードもそれに応じて変更される必要があることは明らかなはずである。これらのノードに対する原理と同じであるため、その他のノードは本明細書では説明されない。

ＭＳ１０はベアラ・サービス処理手段１１を備え、ベアラ・サービス処理手段１１は、属性取い手段１３を有する管理手段１２、アドミッション制御手段１４、及びリソース処理手段１５を備える。属性処理手段１３は図４では、記憶されておりアドミッション制御手段１４及びリソース処理手段１５に提供される第１及び第２の追加属性の入力を処理する。さらに、これらの追加属性が入力された場合に又は決定された場合に、属性は、ＣＮノード３０に、より具体的はＣＮノード内のＢＳ処理手段３１の管理手段３２に提供され、その結果として、変更されたＲＡＢ割り当て手続きが開始され得る。この変更されたＲＡＢ割り当て手続きは最新技術におけるものと実質的に同じであるが、反復型ベアラ又は反復機能を有するベアラの導入を可能とする二つの追加属性の導入を伴う。

ＭＳ１０は任意の適切な移動局のすべての従来機能を備え、それらに加えて管理手段１２は実質的に図２に関連して説明された３ＧＰＰ ＴＳ ２３．１０７ ｖ６．４．０で特定される機能を実質的に備えることは明らかなはずである。本発明の概念を実行するために必要な機能及び手段だけが簡略化されて図４に説明される。

ＲＮノード２０は属性処理手段２３を備える管理手段２２を有するベアラ・サービス（ＢＳ）処理手段２１を備える。管理手段２２は、実際にはユーザ・プレーン処理に含まれるアドミッション制御手段２４及びリソース処理手段２５を備えるか又はこれらと通信する。管理手段２２は概略的なに説明され、これらは図４では制御プレーンのいくつかの管理機能とユーザ・プレーンのいくつかの管理機能とを備える。ＣＮノード３０の属性処理手段３３から、第１及び第２の追加属性がその他の従来のＲＡＢ属性に追加して提供され、少なくとも第１及び第２の追加属性が、無線ベアラの開放が要求されるまでは、又は以下にさらに説明されるようにこれらが変更されるまでは、属性処理手段２３（又はこれに関連付けられた手段）に保持される。第１及び第２の追加属性はまた、後続の転送イベントにおいてリソースの予約を可能とするため、及び反復型ベアラの存在を検討に入れるその他のサービスに対するリソースの割り当てを制御するために、アドミッション制御手段２４に提供されなければならない。本発明の概念を実行するための特定の機能及び手段だけが示される。

同様の手続きがＣＮノード３０において行われるべきであり、第１及び第２の追加属性が属性手段３３又はこれに関連付けられた手段に保持される。これらはまた、上述したように、第１及び第２の追加属性の値及び他のベアラ・サービスに当然払うべき注意を払って割り当てられたリソースに従って自動的にリソースが再活性化又は非活性化され得るように、アドミッション制御手段３４に提供される。

図５は、無線アクセス・ネットワーク・ノード、ここでは例えばＲＮＣ２０Ａの一つの取り得る実装を幾分より詳細に示す。本発明の概念を実行するために必要となる機能を概念的に説明するために異なる手段及び機能の説明が行われ、いくつかの変形が可能であり、また手段及び機能の表現はその他の方法で行い得ることは明らかなはずである。

ＲＮＣ２０Ａは図５ではＲＡＢマネージャ２２Ａを有するＢＳ処理手段２１Ａを備える。上述したように、ＲＡＢマネージャ２２Ａは、ＲＡＢ割り当て手続きの初期においてコア・ネットワーク・ノードから第１及び第２の追加属性を受信するように構成された属性処理手段２３Ａを備える。第１及び第２の追加属性は特定の属性保持手段２７Ａに保持され、属性保持手段２７Ａは属性処理手段２３Ａに含まれるとみなすことももちろんできる。概念的に図説されるＲＡＢマネージャ２２Ａは、第１及び第２の追加属性に従って反復型ベアラを自動的に活性化／非活性化するように構成された特定の（再）活性化手段２８Ａ及び非活性化手段２９Ａを備える。各情報転送イベントにおいて、後続の転送イベントの期限が来る場合に反復型ベアラを再活性化するための活性化手段２８Ａを活性化するタイマＴ１ ２６Ａが設定される。所定量のデータが転送された場合に反復型ベアラが一時的に非活性化されてスリープ・モードに入るように、各イベントにおいて転送される情報量、特に機械生成されたデータ量に関する情報を非活性化手段２９Ａは用いる。その後にネットワーク（ノード）・リソースは他のユーザのために開放される。このことは、第１及び第２の追加属性に関する情報を用いるアドミッション制御手段２４Ａ及びリソース処理手段２５Ａを用いて実行される。関連するデータ量が転送されていたかどうかを確立するために、この機能を監視するための異なるタイマが実装され得る。転送レートが既知である場合（且つ転送レートが一定であると想定される場合）に、追加のタイマを用いることができる。しかしながら、通常は、ｋＢ単位のデータ量として第２の追加のパラメータが与えられる。アドミッション制御手段２４Ａ内のリソース処理手段２５Ａからの矢印は単に、この目的のために反復型ベアラや予約リソースなどの検討について、従来機能が変更されなければならないことを示す。

図６はＣＮノード３０Ａ、例えばＳＧＳＮ（パケット・アクセス制御ノード）又はＣＧＳＮ（統合ＧＰＲＳサポート・ノード）を示す。ＣＮノード３０Ａはベアラ処理手段３１Ａを備え、ベアラ処理手段３１ＡはＢＳマネージャ３２Ａ、アドミッション制御手段３４Ａ、及び無線アクセス・ネットワーク・ノードに関して上述されたように実質的に機能するリソース処理手段３５Ａを有する。なぜならば、コア・ネットワーク及び無線アクセス・ネットワークの両方において、第１及び第２の追加属性に基づいて、ベアラが確立され、リソースが割り当てられ、予約されるなどしなけれればならないためである。ＢＳマネージャ３２Ａは属性処理手段３３Ａを備え、属性処理手段３３Ａは本明細書では移動局から第１及び第２の属性を受信した後に、ＲＡＢ割り当て手続きを開始して、それによって第１及び第２の追加属性を無線ネットワーク・ノード（図５参照）に提供するように構成される。

また、このノードについて、活性化手段３８Ａ及び非活性化手段３９Ａが概念的に説明される。ここでは、第１及び第２の追加属性は特定の属性保持手段３７Ａに記憶例えばキャッシュされるように説明される。属性保持手段３７Ａはまた、属性処理手段３３Ａ内に備えられ又は含まれるもとのみなされてもよい。タイマの機能は図５に関して説明された機能と同様である。次の転送イベントのために用いられ得るように、ネットワーク・パラメータ及び参照が、アドミッション制御手段３４Ａ内に、ＢＳマネージャ３２Ａ内に、又は専用記憶手段（不図示）内に記録される。上記の情報を属性保持手段３７Ａに保持することも可能である。

図７はＢＳ処理手段１４Ａ、ＢＳマネージャ１２Ａ、アドミッション制御手段１３Ａ、及びリソース処理手段１５Ａを備えるＭＳ１０Ａの概略ブロック図である。図７では、ＢＳマネージャは、活性化／非活性化手段１６Ａ、属性入力手段１４Ａから第１及び第２の追加属性を好適にはタイマＴ１ １５Ａを介して受信するように構成された属性処理手段１３Ａを備えるように説明されるが、タイマＴ１ １５Ａを介する必要は必ずしもない。もちろんこれに代えて、タイマＴ１は、属性処理手段１３Ａからの第１の追加属性に関する情報で設定されてもよいし、及び／又はこの情報が提供されてもよい。代替の実装では、ＭＳはいかなるタイマも含まない。

ここで、ユーザが属性入力手段を備えるインタフェースを用いて第１及び第２の追加属性を入力し、属性入力手段は第１及び第２の追加属性を属性処理手段１３Ａに提供し、ＲＡＢ割り当て手続きを開始するために属性処理手段１３Ａから従来の方法で追加属性がコア・ネットワーク・ノードに提供されることを想定する。他の側面では、ＭＳのＢＳ処理手段は従来の方法、例えば上述の３ＧＰＰ ＴＳ ２３．１０７ ｖ６．４．０に記載されるように機能する。

図８は、本発明の手続きの基本的なステップを説明する非常に概略的なシーケンス図である。第１及び第２の追加属性が入力されて、ＭＳから例えばＳＧＳＮに提供される（１）。その後にＳＧＳＮは、従来のＲＡＢ属性などに追加して、前述の第１及び第２の追加属性を備えるＲＡＢ割り当て要求を送信する（２）。第１及び第２の追加属性の受信に応じて、ＳＧＳＮだけでなくＲＡＮにおいても、反復型の又は周期的なＲＡＢについての新たなアドミッション／能力管理を提供する、周期的にＲＡＢを処理し、更新し、又は変更するアドミッション制御手段及びそのアルゴリズムを開始する（３、４）。従来の方法で、無線ベアラの確立／開放／変更のためのシグナリングがＲＡＮとＭＳとの間で実行される（５）。このことはまた、３ＧＰＰ ＴＳ ２３．０６０の１２．７．４節で説明される。これに追加して、第１及び第２の追加属性に基づいて反復型ベアラについてこのことが行われる。続いて、一つ以上のＲＡＢ割り当て応答がＲＡＮからＳＧＳＮに提供される（６）。上述されたように、好適にはタイマが開始され、要求されたデータ量の転送イベントが完了していない限りは、割り当てられた反復型ＲＡＢはアクティブに維持され、完了するとすぐに一時的に非活性化され、又はスリープ・モードに入る。

図９はＵＭＴＳ及びベアラ・トラフィック・クラスについての無線アクセス・ベアラ属性に関する表を概略的に説明する。ベアラ・トラフィック・クラスは、会話型、ストリーミング型、インタラクティブ型、バックグラウンド型であり、反復型クラスをも含むように変更されている。反復型クラスについて、「会話型」のベアラ属性に追加して、第１の追加属性である「時間間隔」及び第２の追加属性である「転送イベントにおける情報量」が含まれている。

本発明によれば、３ＧＰＰ ＴＳ ２３．０６０に記載され上記で参照された従来のＲＡＢ設定手続きが、反復型ＲＡＢの確立を要求するために、及び関連属性を配信するために用いられる。

従来の属性、例えば図９に記載されるような残余ＢＥＲ、ＳＤＵエラー比、転送遅延、最大ビットレート、配信順序、誤りＳＤＵ配信などに追加して、第１及び第２の追加属性が用いられる。第１の追加属性は一定であってもよいし又は可変（変数又は変更可能）であってもよい。第２の追加属性は好適には転送イベントごとに転送されるだろうｋＢ単位のデータ量の指標を備える。これは、固定の属性であってもよいし、可変の属性であってもよい。異なる実装では、第１の追加属性と第２の追加属性との少なくともいずれかは、所定の方法で変わり得る。例えば、各データ転送イベントにおいて、データ転送頻度と転送量との少なくともいずれかを変更してもよい。変更は任意の所与の関連イベントの発生の際に行われてもよい。第１及び第２の追加属性を用いて、適切な反復型ＲＡＢが確立され、ＣＮ及びＲＡＮ内のリソースが割り当てられる。

本発明に係る反復機能は新たなトラフィック・クラスを制定する必要がないことが明らかなはずである。既存のクラスを用いることができ、二つの属性が既存のクラスのそれぞれに追加され得る。このことは、ＲＡＢが会話型且つ周期的ＲＡＢや、ストリーミング型且つ周期的ＲＡＢなどであり得ることを意味する。

本発明の第１の実施形態の基本的なステップを説明する概略的なフロー図が図１０に示される。

第１及び第２の追加属性が、例えばユーザ・インタフェースを介してＭＳに入力される（１００）と想定する。ＭＳは、いくつかの情報の中でとりわけ上述の第１及び第２の追加属性をＣＮ（コア・ネットワーク）ノードに送信する（１０１）。ＣＮノードにおいて、第１及び第２の追加属性は多かれ少なかれ一時的に記憶され、これらはまたＣＮノード内のアドミッション制御手段に提供される（１０２）。ＲＡＢ要求は、従来の方法では、ＲＡＮノードと参照される無線アクセス・ネットワーク・ノードに提供されるが、図１０ではこれは反復型ベアラのための要求である（１０３）。（ＣＮノードに関して上述されたように、）第１及び第２の追加属性はＲＡＮノード内に記憶され、またその中のアドミッション制御手段に提供される（１０４）。これは二つの異なる手続きである必要はなく、追加属性を記憶することは個別のノード内のアドミッション制御手段で行われるとみなすこともでき、そのうちの一つに変更が存在するまでか、反復型ベアラを開放する要求を受信するまでか、又は所与のイベントが発生するまではアドミッション制御手段においてこれらが一時的に保持されてもよいことは明らかなはずである。

従来のシグナリングがベアラの確立のためにＭＳで実行されるが、反復型ベアラのために変更されている点が異なる（１０５）。このシグナリングが完了した場合に、（反復型ベアラに対する）個別のＲＡＢ割り当て応答がＲＡＮノードからＣＮノードに提供される（１０６）。反復型無線ベアラ（群）はこの際に活性化され、連続する二つの転送イベントの間、すなわち第１の反復型ＲＡＢの活性化から後続する再活性化までの時間間隔を示すタイマがＲＡＮノードにおいて（、好適にはＣＮノードにおいても）設定される（１０７）。

第２の追加属性により与えられる量は実際に転送されているかどうか又はいつ転送されたかを確立するために、ある種の監視手段又は検出手段が提供され、活性化される（１０８）ことを想定する。それが転送されている限り、又は第１の転送イベントが完了していない限り、反復型ベアラは維持されるが、完了したことが確立又は算出された場合に、ＲＡＮノードやＣＮノードなどの反復型ベアラ・リソースは制御プレーンのシグナリングを一切必要とせずに、自動的に非活性化される（１０９）。タイマが監視され（１１０）、これが経過すると、すべての関連ノードにおいて、反復型ベアラ・リソースは自動的に非活性化され（１１１）、ステップ１０８などに移行する。ここでは特に、第１及び第２の追加属性は未変更又は一定であると想定する。

図１１は第１の追加属性と第２の追加属性との少なくともいずれかの変更を確立するために行われ得るステップを説明する別の実装の概略フロー図である。まず、第１及び第２の追加属性がＲＡＢセットアップ手続きを用いてＲＡＮノードに提供される（２００）と想定する。（図１０で示したステップと同様のため、先行するステップは図１１では示されない。）図１０のように、第１及び第２の追加属性は個別のアドミッション制御手段に提供されて使用される（２０１）。反復型ベアラが確立され（２０２）、連続する第１及び第２の転送イベントの間の期間を示すタイマＴ１が設定される（２０３）。ここで、転送されたデータ量を監視する監視手段が前述の第２の追加属性を用いて活性化され（２０４）、第２の追加属性に係るデータ量が転送されているかどうかが監視される（２０５）。これが実際に転送されたことが確立された場合に、反復型ベアラが自動的に非活性化され（２０６）、この実施形態では、タイマ、すなわちタイマが設定された時間間隔が変更されるべきかどうかが確立される（２０７）。「ＹＥＳ」の場合にタイマは変更され（２０７Ａ）、それ以外の場合にそれ以降又はその前に、すなわち任意の適切な順序で、第２の追加属性が変更されるべきかどうかが確立される（２０８）。「ＹＥＳ」の場合に、第２の追加属性は変更される（２０８Ａ）。適用できる場合に、ＲＡＮ内のアドミッション制御手段は変更（群）を通知される（２０９）。また、存在するならば、他のノードの対応するアドミッション制御手段は変更群を通知される。Ｔ１が経過したかどうかが監視され（２１０）、「ＹＥＳ」の場合に、反復型ベアラが自動的に再び活性化され（２１１）、任意の変更を考慮に入れながら、上記のステップ２０４に移行する。

本発明は明確に説明された実施形態に限定されず、添付の特許請求の範囲内にある多くの方法で変更され得、主要なことは少なくとも二つの追加属性が反復の又は周期的なベアラ又はこのような機能を有するベアラへのサポートを提供するために導入されるということが明らかなはずである。

Claims (15)

1. 情報の通信をサポートするネットワーク・ノードであって、
   複数の属性によりそれぞれ規定された一つ以上のベアラ・サービスをサポートするベアラ・サービス処理手段(11;21;31;11A;21A;31A)と、
   特定のＱｏＳを有するベアラ・サービスの利用可能性、変更及び維持を制御するベアラ・サービス管理手段(12;22;32;12A;22A;32A)と、
   情報の転送を要求するベアラ・サービスの間にリソースを分配するように構成されたリソース処理手段(15;25;35;15A;25A;35A)と、
   一つ以上のトラフィック・クラスについてのベアラ・サービス属性とＱｏＳ属性又はＱｏＳプロファイルとの少なくとも何れかを処理するように構成された属性処理手段(13;23;33;13A;23A;33A)と、
   ベアラ・サービスのリソースの割り当てに関する情報を制御し保持するように構成されたアドミッション制御手段(14;24;34;14A;24A;34A)と
   を備え、
   前記ベアラ・サービス管理手段(12;22;32;12A;22A;32A)は、少なくとも二つの連続した情報転送イベントの間の期間に関する情報を備えるベアラ・サービスの第１の追加属性と、前記少なくとも二つの連続した情報転送イベントの少なくとも一つの間に転送されるデータ量に関連する情報を備えるベアラ・サービスの第２の追加属性とを処理するように構成されており、
   前記ベアラ・サービス管理手段(12;22;32;12A;22A;32A)は、最初の転送イベントにおいて反復情報転送を処理するように構成されたベアラ・サービスを活性化し、反復情報転送イベントが終了した場合に活性化された反復型ベアラ・サービスを非活性化するとともに前記反復型ベアラ・サービスのリソースを開放し、後続の情報転送イベントの開始以前に前記反復型ベアラ・サービスのリソースの再活性化するように構成されている
   ことを特徴とするネットワーク・ノード。
2. 前記ベアラ・サービス管理手段(12;22;32;12A;22A;32A)は、前記リソース処理手段(15;25;35;15A;25A;35A)を制御するように構成されており、
   前記リソース処理手段(15;25;35;15A;25A;35A)は、転送イベントの終了の際にベアラ・リソースを開放するように構成されるとともに、後続の転送イベントにおける再活性化のためにリソースを予約するように構成された
   ことを特徴とする請求項１に記載のネットワーク・ノード。
3. 前記ベアラ・サービス管理手段(12;22;32;12A;22A;32A)は、前記第１の追加属性及び前記第２の追加属性を備える情報を、前記反復型ベアラ・サービスのベアラ設定に関与する他のすべてのノードのベアラ・サービス管理手段にエンド・ツー・エンドに通信するように構成されたことを特徴とする請求項１に記載のネットワーク・ノード。
4. 前記アドミッション制御手段(14;24;34;14A;24A;34A)は、前記ネットワーク・ノードの利用可能なすべてのリソースに関する情報とベアラ・サービスに割り当てられたすべてのリソースに関する情報との少なくともいずれかを保持するように構成されるとともに、リソースの割り当ての際に前記第１の追加属性及び前記第２の追加属性に関する情報を検討するように構成されたことを特徴とする請求項１乃至３のいずれか１項に記載のネットワーク・ノード。
5. 前記ベアラ・サービス管理手段(12;22;32;12A;22A;32A)は、前記第１の追加属性の前記期間に設定されたタイマ(15A;26A;36A)を備えるか又は当該タイマと通信し、前記期間が経過した際に、前記反復型ベアラの再確立又は再活性化を引き起こすように構成されたことを特徴とする請求項１乃至４のいずれか１項に記載のネットワーク・ノード。
6. 前記属性処理手段(13;23;33;13A;23A;33A)は、前記第１の属性と前記第２の属性との少なくともいずれかを変更するように要求されるまでは前記第１の追加属性及び前記第２の追加属性を維持することによって、周期的に反復して活性化されるベアラ・サービスを維持するように構成されたことを特徴とする請求項１乃至５のいずれか１項に記載のネットワーク・ノード。
7. 前記アドミッション制御手段(14;24;34;14A;24A;34A)は、最初の情報転送イベントにおける反復型ベアラの設定で必要とされるネットワーク・パラメータ及び参照を記憶するとともに、前記第１の属性と前記第２の属性との少なくともいずれかが変更された場合に後続の転送イベントにおける変更後の更新版ネットワーク・パラメータ及び参照を記憶する記憶手段を備えるか又は当該記憶手段と通信することを特徴とする請求項１乃至６のいずれか１項に記載のネットワーク・ノード。
8. 反復情報転送イベントの処理について、前記ベアラ・サービス管理手段(12;22;32;12A;22A;32A)は、最初の反復型ベアラの確立において制御メッセージを送受信するように構成されるとともに、前記第１の追加属性及び前記第２の追加属性を用いて自動的に後続の／反復するベアラの非活性化／再活性化を実行するように構成されたことを特徴とする請求項１乃至７のいずれか１項に記載のネットワーク・ノード。
9. 情報の通信をサポートする移動体ネットワークにおいて情報の反復転送を処理する方法であって、
   少なくとも連続する第１の情報転送イベントと第２の情報転送イベントとの間の期間を示すベアラ・サービス処理の第１の追加属性を提供するステップと、
   少なくとも前記第１の情報転送イベントにおいて転送される情報量に関連する情報を備えるベアラ・サービス処理の第２の追加属性を提供するステップと、
   少なくとも前記転送イベントについて、反復情報転送のためにベアラを設定するとともにコア・ネットワーク及び無線ネットワーク内のリソースを予約するために、前記第１の追加属性及び前記第２の追加属性を用いるステップと、
   前記第２の追加属性により示される情報量を備える前記第１の転送イベントが転送されるまでは前記設定されたベアラを維持するステップと、
   前記反復型ベアラを自動的に非活性化するステップと、
   前記第１の追加属性により示された前記期間の経過後に前記反復型ベアラを自動的に再活性化するステップと、
   所与のイベントが発生するまでは前記第１の追加属性及び前記第２の追加属性により示されるように前記反復型ベアラを自動的に維持し、非活性化し、再活性化するステップと
   を含むことを特徴とする方法。
10. 前記所与のイベントは、前記ベアラの開放が要求されたことの確立と、前記第１の属性値と前記第２の属性値との少なくともいずれかが所定の時間間隔について及び／又は特定のリソース関連指標の受信において与えられた値を超過／下回ることの確立との少なくともいずれかを備えることを特徴とする請求項９に記載の方法。
11. 各転送イベントにおいて、前記第１の属性と前記第２の属性との少なくともいずれかが変更又は更新されるべきかどうかを確立するステップと、
    変更又は更新されるべき場合に、前記第１の属性と前記第２の属性との少なくともいずれかを更新するステップと、
    変更又は更新されるべきでない場合に、前記第１の属性値と前記第２の属性値との少なくともいずれかを維持するステップと
    をさらに含むことを特徴とする請求項９又は１０に記載の方法。
12. 第１の転送イベントにおいて又は反復型ベアラ設定の最初の要求の受信において、前記第１の追加属性を用いてタイマを設定するステップと、
    前記第２の追加属性に従って前記第１の転送イベントが完了しているかどうかを判定するとともに、前記反復型ベアラを非活性化するステップと、
    前記タイマが経過した際に前記反復型ベアラの再活性化を引き起こすステップと
    をさらに含むことを特徴とする請求項９乃至１１のいずれか１項に記載の方法。
13. コア・ネットワーク内及び無線アクセス・ネットワーク内のリソースを前記反復型ベアラに対して割り当て及び予約するステップをさらに備えることを特徴とする請求項９乃至１２のいずれか１項に記載の方法。
14. 反復型ベアラの最初の設定においてのみ関連するすべてのノードに制御メッセージを送信するステップと、
    前記第１の追加属性及び前記第２の追加属性に関する情報を用いて前記非活性化及び再活性化を制御シグナリングせずに自動的に実行するステップと
    をさらに含むことを特徴とする請求項９乃至１３のいずれか１項に記載の方法。
15. コア・ネットワーク・ノードと無線アクセス・ネットワーク・ノードとの少なくともいずれかにおいて、
    個別のアドミッション制御手段に前記第１の追加属性及び前記第２の追加属性に関する情報を提供するステップと、
    前記反復型ベアラの再活性化のためにリソースが利用可能であることを保証するために、ベアラ・リソースの割り当ての際に前記第１の属性及び前記第２の属性を検討するステップと
    をさらに備えることを特徴とする請求項９乃至１４のいずれか１項に記載の方法。

Images