JP2018534812A - 通信システムにおけるデータフロートランスポートのための改善されたプライオリティハンドリング - Google Patents

Abstract

通信システムにおけるデータフローのプライオリティハンドリングのためのシステムは、１つ以上のデータベアラと、データフロー間のプライオリティ付けを行うように構成されるプライオリティハンドリングモジュールと、を備える。前記プライオリティハンドリングモジュールは、第１のデータフローのプライオリティの構成又は再構成についてのリクエストを受信し、前記第１のデータフローのプライオリティ共有識別子を取得する、ように構成され、前記通信システム内の、前記第１のトランスポートデータフローの前記プライオリティ共有識別子を有する他のデータフローを識別する、ようにも構成される。前記プライオリティハンドリングモジュールは、前記第１のデータフローに関連付けられ及び前記通信システム内の前記第１のトランスポートデータフローの前記プライオリティ共有識別子を有する何らかの他の識別されたデータフローにも関連付けられるプライオリティルールを更新して、共有されるプライオリティルールに関し合意する、ように構成される。【選択図】図２

Description

ここで提示される実施形態は、通信システムにおけるデータフロートランスポートのためのプライオリティハンドリングに関連する。具体的には、本開示は、上記データフロートランスポートのプライオリティハンドリングのための、システム、方法、コンピュータプログラム、ネットワークノード及びメッセージに関連する。

図１は、無線基地局又はｅＮｏｄｅＢといったアクセスポイント１２０へワイヤレスに接続している複数のワイヤレスデバイス１１０、を含む通信ネットワーク１００を示している。アクセスポイント１２０は、転じて、サービングゲートウェイ（ＧＷ）１３０及びパケットデータネットワークゲートウェイ（ＰＧＷ）１４０を介して、ワイヤレスデバイスをパケットデータ通信ネットワークといった外部ネットワーク１５０へ接続する。

図２は、図１に示したネットワークのようなワイヤレス通信ネットワーク２００を、３ＧＰＰ（3rd Generation Partnership Project）の設定において示している。ここでは、ワイヤレスデバイス１１０は、３ＧＰＰ ＴＳ２３．００２ｖ１３．３．０に従って、ＥＰＳ（Evolved Packet System）ネットワークへ接続される。ワイヤレスデバイスは、ＥＰＳベアラと呼ばれる仮想的な接続を使用し、ＥＰＳベアラは、ＰＧＷ内で終端し、１つ以上のトラフィックフロー、即ちサービスデータフロー（ＳＤＦ）のトランスポートを、３ＧＰＰ ＴＳ２３．２０３ｖ１３．５．１に従って有効化する。ＥＰＳベアラは、ワイヤレスデバイスとアクセスポイント（１２０）との間のデータ無線ベアラにより搬送される。ＥＰＳベアラは、共通的なサービス品質（ＱｏＳ）の取扱いを受けるＳＤＦを一意に識別し、それはワイヤレスデバイスとＰＧＷとの間のプライオリティを含む。３ＧＰＰ ＴＳ２３．２０３ｖ１３．５．１において定義されている通りのサービス品質は、ＱＣＩ（Quality of Service Call Identifier）及びＡＲＰ（Allocation and Retention Priority）属性の双方を含む。ＥＰＳベアラは、３ＧＰＰ ＴＳ２３．４０１ｖ１３．４．０及び３ＧＰＰ ＴＳ３６．３００ｖ１３．１．０において定義されている。注記されることとして、ＥＰＳベアラはワイヤレスデバイス１１０とピアエンティティとの間のエンドツーエンドのサービストランスポートの一部を成し、いくつかの観点によればピアエンティティは外部ネットワーク１５０内に位置する。

３ＧＰＰ ＴＳ３６．３３１ｖ１２．７．０は、ワイヤレスデバイスが最大８つのデータ無線ベアラをサポートするのみであることを記述している。それらデータ無線ベアラのうちの３つを、確認応答無しモード（ＵＭ：unacknowledged mode）で使用することができ、ＵＭは、リアルタイムメディアトラフィック、即ち低レイテンシで伝達されることが好ましいトラフィックを送信するために好適なモードである。

３ＧＰＰ ＴＳ３６．３００ｖ１３．１．０において定義されているように、ワイヤレスデバイスがネットワーク１５０といったＩＰネットワークへ接続する際に１つのＥＰＳベアラが確立され、それはＩＰネットワークへの接続のライフタイムを通じて確立されたまま維持されて常時オンのＩＰ接続性をワイヤレスデバイスへ提供する。そのベアラを、デフォルトベアラという。デフォルトベアラは、ベストエフォートサービスであり、各デフォルトベアラにはＩＰアドレスが付随する。同じＩＰネットワークへ向けて確立される任意の追加的なＥＰＳベアラを、専用ベアラという。

図２の設定において、プライオリティは、ＥＰＳベアラごとに定義される属性である。プライオリティは、３ＧＰＰ ＴＳ２３．２０３ｖ１３．５．１に従ってベアラレベルパラメータであるＡＲＰ（Allocation and Retention Priority）に関連付けられる。ＡＲＰのプライオリティ情報は、通信システム２００を通じた流入（admission）の期間中により高いプライオリティを有するＥＰＳベアラにより低いプライオリティを有するＥＰＳベアラに対する優先権（preference）を与えるために使用される。プライオリティ属性は、例えば公衆安全（Public Safety）オペレータ及び公衆安全エイジェンシにより提供されるような、いわゆるミッションクリティカルなサービスのために不可欠である。それは、そうしたサービスがしばしば低レイテンシ及び／又は高信頼性のトランスポートを要するためである。そうしたミッションクリティカルなサービスの例は、警察、火災及びレスキューサービス、並びに緊急医療を含む。

３ＧＰＰ ＴＳ２３．２０３ｖ１３．５．１によれば、他のＳＤＦと同じＥＰＳベアラを共有する第１のＳＤＦについてプライオリティの修正がリクエストされた場合、以下が保証される：
（ａ）リクエストされたプライオリティと、第１のＳＤＦについて３ＧＰＰ ＴＳ２３．２０３ｖ１３．５．１において定義されているものと同一のＱｏＳ（Quality of Service）クラス識別子（ＱＣＩ）とを伴う他のＥＰＳベアラが存在する場合、第１のＳＤＦはそのＥＰＳベアラへ移される、又は、
（ｂ）リクエストされたプライオリティと、上記同一のＱＣＩとを伴う他のＥＰＳベアラが存在しない場合、通信システムは、リクエストされた修正プライオリティパラメータを有する、第２のＳＤＦをトランスポートするための新たなＥＰＳベアラの生成を試行する。

ワイヤレスデバイス別のＥＰＳベアラ数の制限に少なくとも部分的に起因して、現行のプライオリティ修正の振る舞いは、ミッションクリティカルな要件と整合しない。それがなぜかを理解するために、ＳＤＦのプライオリティの修正がリクエストされる際にワイヤレスデバイスが既に確立済みの３つのＥＰＳベアラ（ＵＭ）を有している一例としてのシナリオを考慮されたい。修正後のプライオリティが同じＱＣＩを伴う既存のＥＰＳベアラについて定義されているプライオリティではないとすると、これは新たなＥＰＳベアラがリクエストされることに帰結し、即ち、通信システムにおいてＥＰＳベアラの生成が試行されるであろう。３つのＥＰＳベアラが既に確立済みであるために、ネットワークは、新たなＥＰＳベアラを生成するためのリクエストを拒絶するであろう。その直接的な結果として、修正後のＳＤＦは接続性を失い、リソースが許可されなかったという通知をアプリケーションシステムが受け取ることになる。同じ一連の事象が、当然ながら、どのＥＰＳベアラによっても以前に使用されていない特有のプライオリティ構成を有する新たなＳＤＦ向けのリソースを確立するためのリクエストについて生じる。

よって、上で議論したタイプの通信ネットワークにおける改善されたプライオリティハンドリングについてのニーズが存在する。具体的には、ミッションクリティカルなサービスのために使用される通信システムにおける改善されたプライオリティハンドリングについてのニーズが存在する。

ここで提示される実施形態の目的は、通信システムにおける改善されたプライオリティハンドリングを提供することである。

第１の観点によれば、通信システムにおけるデータフローのプライオリティハンドリングのためのシステムが提示される。上記システムは、各々がデータフローの１つ以上をトランスポートするように構成される１つ以上のデータベアラ、を含む。上記システムは、データフロー間のプライオリティ付けを行うように構成されるプライオリティハンドリングモジュール、をも含む。上記プライオリティハンドリングモジュールは、第１のデータフローのプライオリティの構成又は再構成についてのリクエストを受信する、ように構成される。上記プライオリティハンドリングモジュールは、上記第１のデータフローのプライオリティ共有識別子を取得する、ようにも構成される。上記プライオリティハンドリングモジュールは、上記通信システム内の、上記第１のトランスポートデータフローの上記プライオリティ共有識別子を有する他のデータフローを識別する、ようにさらに構成される。上記プライオリティハンドリングモジュールは、上記第１のデータフローに関連付けられ及び上記通信システム内の上記第１のトランスポートデータフローの上記プライオリティ共有識別子を有する何らかの他の識別されたデータフローにも関連付けられるプライオリティルールを更新して、共有されるプライオリティルールに関し合意する、ように構成される。

これにより、許容可能な最大数よりも多くのデータフローベアラを生成するリスクが低減される点において、改善されたプライオリティハンドリングを有する通信システムが提供される。

例えば、ＥＰＳベースの通信システムは、提示される技法により、各トラフィックフローのプライオリティのニーズに関わらず、トラフィックフローがプライオリティ共有識別子を共通して有する限り、通信のために１つのＥＰＳベアラを再利用することになる。結果として、提案される解決策は、ＥＰＳベアラの最大数に達し、追加的なＥＰＳベアラの生成の失敗に起因して何らかのＳＤＦのための接続性が失われる確率を制限する。

言い換えると、ワイヤレスデバイスにおける例えばＥＰＳベアラの制限に起因してクリティカルサービスが拒絶されてしまう問題に対処するための解決策は、同一のプライオリティ共有識別子に関連付けられるＳＤＦの間でプライオリティを共有する可能性、即ちプライオリティ識別子を共有する可能性を導入することである。

第２の観点によれば、通信ネットワークにおいてプライオリティハンドリングモジュールにより実行される方法が提示される。上記方法は、通信システム内のデータフローに関連付けられるプライオリティルールの構成又は再構成についてのリクエストであって、プライオリティ共有識別子を含む当該リクエストを受信すること、を含む。上記方法は、受信される上記リクエストに基づいて、上記通信システムのプライオリティパラメータを計算すること、及び、上記通信システム内の上記プライオリティ共有識別子に関連付けられる他のデータフローを識別することと共に、構成又は再構成についての上記リクエスト、及び上記通信システム内の上記プライオリティ共有識別子に関連付けられる何らかの他の識別されたデータフローの既存のプライオリティ構成に基づいて、共有されるプライオリティパラメータを判定すること、をも含む。

ある観点によれば、判定される上記共有されるプライオリティパラメータに基づいて、上記通信システム内のデータフローに関連するプライオリティ構成を更新すること、をも含む。

いくつかの観点によれば、上記プライオリティハンドリングモジュールは、３ＧＰＰにより定義される通信システムのＰＣＲＦ（Policy and Charging Rule Function）を含む。

いくつかの観点によれば、上記プライオリティハンドリングモジュールは、３ＧＰＰにより定義される通信システムのＰＣＥＦ（Policy and Charging Enforcement Function）を含む。

通信システムのネットワークノードにおいて実行された場合に、上記通信システムに、ここで開示される通りの方法を実行させるコンピュータプログラムコード、を含むコンピュータプログラム、もまたここで開示される。

通信ネットワークにおいてプライオリティハンドリングを実行するように構成されるネットワークノードがここでさらに開示される。上記ネットワークノードは、通信システム内のデータフローに関連付けられるプライオリティルールの構成又は再構成についてのリクエストであって、プライオリティ共有識別子を含む当該リクエストを受信する、ように構成される受信モジュール、を備える。上記ネットワークノードは、受信される上記リクエストに基づいて、上記通信システムのプライオリティパラメータを計算する、ように構成される計算モジュール、上記通信システム内の、上記プライオリティ共有識別子に関連付けられる他のデータフローを識別する、ように構成されるデータフロー識別モジュール、並びに、構成又は再構成についての上記リクエスト、及び上記通信システム内の上記プライオリティ共有識別子に関連付けられる何らかの他の識別されたデータフローの既存のプライオリティ構成に基づいて、共有されるプライオリティパラメータを判定する、ように構成される判定モジュール、をも備える。

提案される解決策は、いくつかの観点によれば、ＰＣＣ（Policy and Charging Control）に基づく。ＰＣＣの機能性は、ＰＣＥＦ（Policy and Charging Enforcement Function）、ＰＣＲＦ（Policy and Charging Rules Function）及びＡＦ（Application Function）からなる。プライオリティの共有に関する提案される解決策は、ＰＣＥＦ若しくはＰＣＲＦのいずれか、又はそれら２つの組み合わせで実装されることができる。

そのうえ、通信システムにおいてある数のＳＤＦ（Service Data Flow）の共有されるプライオリティハンドリングのために構成される修正ＡＡＲ（Authentication/Authorization Request）メッセージがここで開示される。上記修正ＡＡＲメッセージは、ＧＣＳ識別子（Group Communication Service Identifier）を含み、上記ＧＣＳ識別子の値のレンジの少なくとも一部が上記通信システムのプライオリティ共有識別子又はプライオリティ共有キーを定義する。

上記方法、コンピュータプログラム、ネットワークノード及びメッセージは、全て、上で言及したシステムとの関連において既に説明した利点に対応する利点を呈する。

次に、以下の添付図面を参照しながら、本開示がより詳細に説明されるであろう。

通信ネットワークの概略図を示している。 通信ネットワークの概略図を示している。 従来技術に係るプライオリティハンドリングの一例を示している。 従来技術に係るプライオリティハンドリングの一例を示している。 本開示の複数の観点に係るプライオリティハンドリングの例を示している。 本開示の複数の観点に係るＰＣＲＦにより実行される方法を例示するフローチャートを示している。 本開示の複数の観点に係るプライオリティハンドリングの例を示している。 本開示の複数の観点に係る方法を例示するフローチャートである。 本開示の複数の観点に係る方法を例示するフローチャートである。 本開示の複数の観点に係る方法を例示するフローチャートである。 本開示の複数の観点に係るネットワークノードを概略的に示している。 本開示の複数の観点に係る修正ＡＡＲ（Authentication/Authorization Request）メッセージを概略的に示している。 データフローのプライオリティハンドリングを実装する通信ネットワーク内のシグナリングを概略的に示している。

これ以降、本発明概念のある実施形態が示されている添付図面を参照しながら、本発明概念がより充分に説明されるであろう。しかしながら、本発明概念は、多くの異なる形式で具現化されてよく、ここで説示される実施形態に限定されるものとして解釈されるべきではなく、むしろ、それら実施形態は、本開示を綿密且つ完結したものとするように例示の手段で提供されており、本発明概念のスコープを当業者に充分に伝えるであろう。類似の番号は、本説明を通じて類似の要素への言及である。破線で示されたいかなるステップ又は特徴も、オプション的なものとして見なされるべきである。

上で議論したように、図１及び図２は、通信ネットワーク１００、２００の概略図を示している。ワイヤレスデバイス１１０は、１つ以上のデータフローを用いて外部ネットワーク１５０へ接続される。そうしたデータフローの１つの例は、３ＧＰＰ ＳＤＦである。しかしながら、本技法は、そのタイプのデータフローに限定されるのではなく、広い範囲の様々なタイプのデータフローへ適用可能である。

ワイヤレスデバイス１１０の例は、限定ではないものの、移動局、モバイルフォン、ハンドセット、ワイヤレスローカルループフォン、ユーザ機器（ＵＥ）、スマートフォン、ラップトップコンピュータ、及びタブレットコンピュータを含む。アクセスポイント１２０の例は、限定ではないものの、無線基地局、基地送受信局、ノードＢ、拡張ノードＢを含む。当業者は理解するように、通信システム１００、２００は、複数のアクセスポイント１２０を含んでよく、その各々が複数のワイヤレスデバイス１１０へネットワークアクセスを提供する。ここで開示される実施形態は、アクセスポイント１２０又はワイヤレスデバイス１１０のいかなる具体的な数にも限定されない。その点において、通信システム１００、２００は、プライオリティハンドリングを含むものと想定される。プライオリティハンドリングは、通信システムがいくつかのデータフローに、よりプライオリティの低い他のデータフローに対して優先権を与えることを可能にする。高められたプライオリティを与えられることの多いデータフローの例は、上で議論したような、ミッションクリティカルな通信に関連するデータフローを含む。

ここでプライオリティ、プライオリティパラメータ又はプライオリティ値について議論する場合、それは広い意味でプライオリティへの言及である。即ち、より低いプライオリティを有するデータフローに対して、より高いプライオリティを有するデータフローに、通信システムにおけるトランスポート又は記憶の期間中に、あるタイプの優先的な取扱いを与える、という概念である。

３ＧＰＰの設定では、プライオリティは、少なくとも部分的に、ＡＲＰ（Allocation and Retention Priority）属性を用いて特定される。ＡＲＰ属性は、０〜１５の間のプライオリティレベル値（値０は他の用途のために予約され、値１が最高のプライオリティを、値１５が最低のプライオリティを提供する）と、ＰＣＩ（Preemption Capability Indicator）フラグと、ＰＶＩ（Preemption Vulnerability Indicator）フラグとを含む。ここでは、プライオリティとは、ＡＲＰ属性のこれら構成要素のいかなる組み合わせへの言及であってもよい。

上で議論したように、３ＧＰＰにより定義されるＵＥといったワイヤレスデバイスは、いくつかのケースにおいて、いくつのデータベアラを同時にサポートすることができるかという点での無線インタフェースに関する制限に関連付けられる。上で言及した３ＧＰＰ標準では、確認応答無しモードのデータ無線ベアラ（ＵＭ ＤＲＢ）は、ワイヤレスデバイス別に同時に３つのみ確立することを許容される。

ＰＴＴ（Push-To-Talk）、及びＶｏＬＴＥ（video and voice-over-LTE）といった他のサービスは、保証ビットレート（ＧＢＲ）データベアラの特性を要し又は少なくとも選好する。従って、全てのＰＴＴ関連のデータフローは、それらＧＢＲベアラのうちの１つへインストールされる可能性が高い。そのうえ、上記サービスのためのＧＢＲベアラは、ＵＭ ＤＲＢの特性を要し又は少なくとも選好する。

ミッションクリティカルＰＴＴ（ＭＣＰＴＴ）アプリケーションサーバは、その時点で確立されているＥＰＳベアラの、及びＰＣＲＦによりいかにしてＰＣＣルールが評価されるのかのいかなる知識も有しない。その結果、ＭＣＰＴＴアプリケーションサーバが緊急のグループ通信のためのリソースをリクエストした場合であってその時に、当該アプリケーションは、その緊急メディアのトラフィックフローがベアラハンドリングに関してネットワークレイヤ上でどのように実際に扱われるかを知得しないことになる。

緊急のグループ通信は、例えばＶｏＬＴＥのためにその時点で構成されているよりも良好なプライオリティの取扱いを要する可能性が最も高いであろう。従って、ＰＣＲＦは、他のグループ通信トラフィックフロー向けのものよりも良好なＡＲＰ、即ちより高いプライオリティでＰＣＣルールを評価する可能性が最も高いであろう。この直接的な結果として、ＰＣＥＦは、リクエストされる特性を有する既に存在するＥＰＳベアラが無いとすれば、緊急のグループ通信のために新たな専用のＥＰＳベアラの生成を試行することになる。

緊急のグループ通信がリクエストされる時点で既に３つのＥＰＳベアラ（ＵＭ）が確立されている場合、追加的なベアラを求めるそのリクエストは、最大数のＥＰＳベアラ（ＵＭ）が既に確立されているために、ネットワーク又は通信システムにより拒絶されることになる。これは、当然ながら、迅速かつ信頼性の高い接続に依拠している多くのミッションクリティカルなサービスにとって受け入れ可能ではない。ＥＰＳベアラの破棄に起因する接続性喪失を被ることは、ミッションクリティカルなアプリケーションにとって重大な結末を有しかねない。

この問題に対する以下に詳述される解決策は、データフロー間のプライオリティ共有の概念を導入することである。この新規な概念によれば、データフローは、プライオリティ共有識別子又はプライオリティ共有アイデンティティに関連付けられ得る。このプライオリティ共有識別子は、キーのように動作し、あるデータフローを、同じキーを有する他のデータフローにリンクさせる。そして、プライオリティを共有する複数のデータフローがデータフローのセットを形成する。データフローのこのセットは、プライオリティについて言えば通信システム内で共通の取扱いを与えられることになる。その効果は、同一のプライオリティ共有識別子を有する他のデータフローがトランスポートされているＥＰＳベアラに、あるデータフローがその時点で割り当てられる場合、そのデータフローが新たなＥＰＳベアラへ割り当てられなくなることである。

例示のために、本概念が使用される次の２つの例示的なシナリオを考慮されたい：
（ｉ）第１のデータフローが第１のプライオリティ共有識別子に関連付けられており、第１のＥＰＳベアラによりトランスポートされ、最大数のＥＰＳベアラが割り当て済みであるものとする。また、第１のプライオリティ共有識別子を有する第２のデータフローが導入されるものとする。この第２のデータフローは、すると、第１及び第２のデータフローのプライオリティ設定に関わらず、第１のＥＰＳベアラへ割り当てられることになる。第１のデータフローが第２のそれよりも低いプライオリティを有するケースでは、そのプライオリティが第２のデータフローのプライオリティに適合するように増加させられるであろう。第２のデータフローが第１のデータフローのそれを下回るプライオリティを有する場合、そのプライオリティは、第１のそれに適合するように増加させられるであろう。双方のケースにおいて、それら２つのデータフローは、共通のプライオリティ共有識別子に起因して、共通のプライオリティの取扱いを与えられることになる。プライオリティの共有が適用される場合、デフォルトベアラのプライオリティもまた、第２のデータフローのそれに適合するように増加させられる。
（ｉｉ）第１及び第２のデータフローが同一のプライオリティを有するように構成されており、同一のプライオリティ共有識別子をも有し、共に第１のＥＰＳベアラへ割り当てられているものとする。また、第２のデータフローのプライオリティレベルが増加するように再構成されるものとする。このケースでは、第１のデータフローのプライオリティレベルもまた、第２のデータフローのそれに適合するようにやはり増加させられ、これは、２つのデータフローが依然として同一のＥＰＳベアラ内でトランスポートされ得ることを意味する。プライオリティの共有が適用される場合、デフォルトベアラのプライオリティもまた、第２のデータフローのそれに適合するように増加させられる。

よって、プライオリティ共有識別子を共通して有する例えばＳＤＦなどの複数のデータフローが寄せ集められ、実際のＳＤＦ別に構成されたプライオリティ値に関わらず共通のプライオリティの取扱いを与えられる。これは、それらを同一のＥＰＳベアラへ割り当てることができることを意味する。

緊急のアクティビティの無い通常のシナリオでは、ユーザがリッスンする全てのグループ通信セッションは同一のプライオリティの取扱いを経験する。よって、それらは同一のＥＰＳベアラにより搬送される。緊急のセッションについてのリクエストが存在する場合、そのセッションのプライオリティは、ネットワーク内でトランスポートされる期間中にそのデータフローが優先されることを確保するために引き上げられる可能性が最も高いであろう。そうしたシナリオにおいて、ＥＰＳシステムは、最良のプライオリティを要する緊急サービスのプライオリティに適合するようにＥＰＳベアラを調整することになる。その結果として、他のグループ通信セッションについてのＰＣＣルールもまた引き上げられたプライオリティに適合するように調整される。

この技法のさらなる詳細及び例が以下に与えられるであろう。

ここで提示される解決策の１つの観点は、ＥＰＳシステムが全てのＰＴＴ（Push-To-Talk）関連トラフィックフロー及び／又はミッションクリティカル関連サービスデータフローを、共有されるプライオリティの取扱いを伴うＧＢＲ特性を有する１つの専用のＥＰＳベアラへ集める仕組みを有効化する可能性である。これは、より効果的なベアラの利用につながり、それにより他のサービスのトラフィックフローのためにＥＰＳベアラが解放されることになる。

プライオリティ共有識別子又はプライオリティ共有キーは、本発明概念のいくつかの３ＧＰＰ関連の観点によれば、Ｒｘインタフェース上のグループ通信サービス識別子（GCS-Identifier）の範囲内でアプリケーションにより提供される識別子である。例えば、ＧＣＳ識別子のパラメータ空間のサブレンジがプライオリティ共有識別子機能のために予約されてもよい。ＧＣＳ識別子パラメータは、３ＧＰＰ ＴＳ２９．２１４ｖ１３．３．０において定義されている。

当然ながら、データフローを同一のプライオリティ構成でトランスポートし及びプライオリティに関して１つのエンティティとして取り扱うことができるように、所与のデータフローについてプライオリティハンドリングシステムがプライオリティ共有識別子を取得し及び通信システム内の同一のプライオリティ共有識別子を有する他のデータフローを識別することをプライオリティ共有識別子が可能とする限り、プライオリティ共有識別子を定義し及び通信するための他の可能性が存在する。

例えばＰＴＴ（Push-to-Talk）などのアプリケーションは、いくつかの観点によれば、所与のワイヤレスデバイス又は複数のワイヤレスデバイスのグループに関連付けられる全てのＰＴＴ関連ＳＤＦについて同一のプライオリティ共有識別子を提供するであろう。同一のプライオリティ共有識別子を伴う複数のＳＤＦが、プライオリティハンドリングに関して併せて一単位として取り扱われることになる。そのプライオリティをより良好なものへと修正することに続く帰結として、ＥＰＳシステムは、ワイヤレスデバイスについて同一のプライオリティ共有識別子を伴う全てのＳＤＦを修正後のものへ調整し、デフォルトベアラのプライオリティを修正後のＳＤＦと同じレベルへ調整する。

提案される解決策は、いくつかの観点によれば、３ＧＰＰ ＴＳ２３．２０３ｖ１３．５．１において定義されているＰＣＣ（Policy and Charging Control）に基づく。ＰＣＣの機能性は、ＰＣＥＦ（Policy and Charging Enforcement Function）、ＰＣＲＦ（Policy and Charging Rules Function）及びＡＦ（Application Function）からなる。プライオリティ共有に関する提案される解決策は、ＰＣＥＦ若しくはＰＣＲＦのいずれか、又はそれら２つの組み合わせで実装されることができる。

ＰＴＴといった３ＧＰＰグループ通信アプリケーションにおいて、リソースを求めるリクエストは、ＡＦ（Application Function）からＰＣＲＦへＲｘインタフェース上で送信される（図２参照）。ＰＣＲＦは、そのリクエストを評価し、適用されるべきプライオリティ（ＡＲＰ）を計算し又は判定する。

次に、従来技術に係るプライオリティハンドリングの例が図３ａ及び図３ｂとの関連において与えられ、続いて本発明概念が議論されるであろう。

図３ａを参照すると、あるアプリケーションが、時刻Ａにおいて、３ＧＰＰ ＴＳ２９．２１４ｖ１３．３．０に従い、Ｒｘインタフェース上でＰＣＲＦへＡＡＲ（Authentication / Authorization Request）メッセージを送信することにより、グループＧ１についてのリソースを要求する。次いで、ＰＣＲＦは、Ｇｘインタフェース上でＰＣＥＦとの通信を進め、その後、ＥＰＳベアラがＧ１のためのＳＤＦを収容するようにセットアップされる。

図３ａにおいて、グループ通信システムは、ミッションクリティカルな（ＭＣ）ＰＴＴアプリケーションサーバ（ＡＳ）、即ちＭＣＰＴＴサーバと、ＳＩＰ（Session Initiation Protocol）コアとを含むように示されている。

次に、図３ｂを参照すると、同一の又は異なるアプリケーションが、時刻Ｂにおいて、ミッションクリティカルなアプリケーションに関連付けられる第２のグループＧ２についてのリソースをリクエストする。従って、グループＧ２は、より高いプライオリティ、即ち本例では５というプライオリティ値（予約プライオリティ＝５）をリクエストする。ＰＣＲＦは、従って、Ｇ２についてサービス品質クラスインジケータ（ＱＣＩ）及びＡＲＰを計算し（ＱＣＩ＝１、ＡＲＰ＝５）、これはＧ１のそれ（ＱＣＩ＝１、ＡＲＰ＝１０）とは異なる。従って、Ｇ１についてのＳＤＦとＧ２についてのＳＤＦとは、互いに異なるＥＰＳベアラにおいてトランスポートされることになり、これが図３ｂにおいて２つの別個のＥＰＳベアラとして示されている。

結果的に、上で議論したように、図３ｂでは、ＥＰＳベアラの数に関する上で言及した制限に起因して新たなＥＰＳベアラを生成することができないというリスクが存在する。

図４を参照すると、上の問題に対する解決策が、本発明概念に従って概略的に示されている。図４の例では、グループＧ１についてのＳＤＦが時刻Ａにおいて存在するものとされ、続いて時刻Ｂにおいて新たなグループＧ２、続いて時刻Ｃにおいてまた別のグループＧ３の追加が行われる。

ここで、アプリケーションは、３ＧＰＰ ＴＳ２９．２１４ｖ１３．３．０に従い、Ｒｘインタフェース上でＰＣＲＦへＡＡＲメッセージを送信することにより、リソースを要求する。それは、新たなＳＤＦのためのリソース又は既存のＳＤＦのための修正されるリソースであり得る。このメッセージは、ＧＣＳ識別子パラメータの範囲内のプライオリティ共有識別子を含む。ＰＣＲＦは、リクエストが適用されるユーザ及びアクセスポイント名（ＡＰＮ）（３ＧＰＰ ＴＳ２３．００３ｖ１３．３．０）を見つけ出すための処理である、３ＧＰＰ ＴＳ２９．２１３ｖ１３．３．０に記述された通りのセッションバインディングを実行する。ＰＣＲＦは、アプリケーションから受信される情報を用いて、ＰＣＣルールを評価する（３ＧＰＰ ＴＳ２３．２０３ｖ１３．５．１）。ＰＣＣルールは、ユーザプレーンプライオリティ及びＱｏＳ制御を有効化するために要する情報を含む。

ＰＣＲＦが本発明概念の観点に係るプライオリティ共有のロジックを保持している場合、ＰＣＲＦは、複数の観点に従い、次のことを行うことになる：
（ａ）ＰＣＲＦは、ＡＡＲ情報を解析し及びＧＣＳ識別子を見て、それがプライオリティ共有のためにマーク付けされているかを認識するであろう。プライオリティ共有識別子でマーク付けされたリクエストは、暗黙的に、同一のプライオリティ共有識別子又はプライオリティ共有キーを伴う他のＳＤＦを探すようにＰＣＲＦへ指示する。図４の例では、ＧＣＳ識別子＝１００を伴う他のＳＤＦが探される。新たなリクエストの要求されたプライオリティがその時点の構成と比較して引き上げられる場合、ＰＣＲＦは、同一のプライオリティ共有識別子に関連付けられる全てのＰＣＣルールを、それらＳＤＦのうち最高のプライオリティのレベルへ修正するであろう。新たなリクエストの要求されたプライオリティがその時点の構成と比較して引き上げられる場合、ＰＣＲＦは、デフォルトベアラのプライオリティを、それらＳＤＦのうち最高のプライオリティのレベルへ修正するであろう。要求されたＳＤＦのプライオリティが既に存在するＳＤＦよりも低い場合、その新たなＳＤＦは、他のＳＤＦと同一のプライオリティ共有キーを共有しているために、より高いプライオリティを受け取るであろう。
（ｂ）ＰＣＲＦは、複数の観点に従い、ＡＡＡ（Authentication/Authorization Answer）メッセージで応答し得る。

図４の例では、時刻ＢにおいてグループＧ２が導入される際に、それは、既存のグループＧ１に等しいプライオリティ共有識別子と共に導入される（ＧＳＣ識別子＝１００）。よって、より高いＡＲＰプライオリティレベル値、即ちより低いプライオリティを有するグループＧ１は、新たなグループＧ２と同一のプライオリティ構成へ再構成される。図４に示したように、これは、Ｇ１及びＧ２が同一のＰＣＣルールを有する（ＱＣＩ＝１、ＡＲＰ＝５）ことから新たなＥＰＳベアラが生成されないこと、及び、グループＧ１及びＧ２の双方のＳＤＦが共有されるＥＰＳベアラへ割り当てられること、を意味する。

グループＧ２の導入の期間中のグループＧ１の再構成の結果は、ＥＰＳベアラの構成がＱＣＩ＝１、ＡＲＰ＝１０からＱＣＩ＝１、ＡＲＰ＝５という新たな構成へ変化することである。

さらに、図４の例は、時刻Ｃにおける新たなグループＧ３の導入を示している。このグループは、プライオリティ値７に関連付けられ、既存のグループＧ１及びＧ２と同一のプライオリティ共有識別子を有する。プライオリティ値７はその時点で構成されているＥＰＳベアラのＡＲＰ値よりも高いものの、Ｇ３向けのＳＤＦは、図４に示したように、ＡＲＰ値５を与えられ、同一のベアラ内に配置される。

グループＧ３のプライオリティ再構成の結果は、ＥＰＳベアラの構成が変化せず、即ちＱＣＩ＝１、ＡＲＰ＝５に留まることである。

よって、理解され得ることとして、プライオリティ共有識別子を使用し及び既存の及びリクエストされたプライオリティパラメータに基づいて新たなＰＣＣルールを計算するという本概念に起因して、異なる複数のＳＤＦを収容するために新たなＥＰＳベアラが割り当てられない。結果的に、改善されたプライオリティハンドリングが提供される。

図５は、少なくとも部分的にＰＣＲＦによりプライオリティ共有の仕組みが実行される、本開示の複数の観点に係る方法を例示するフローチャートを示している。アプリケーション機能からＰＣＲＦへＲｘ上で送信されるリソースを求めるリクエストに続いて、上記方法は、次を含む
−ＰＣＲＦは、Ｒｘ上での入力に基づいてＡＲＰを計算５１０する。新たなＰＣＣルールが生成される。
−プライオリティ共有識別子であるＧＣＳ識別子が提供された場合、同一の識別子を有する他のセッションを識別５２０する。
−前のステップにおいて識別されたセッションについての共通のＡＲＰ（通常、最も低いプライオリティ値ＡＲＰ）を計算５３０する。
−ＡＲＰの上記共通の値で全ての関係するＰＣＣルールを更新５４０する。
−オプションとして、より良好なＡＲＰを伴うセッションが終了した場合に以前のＡＲＰ値へ立ち戻ることができるように、Ｒｘリクエスト情報を記憶５５０する。

次に図６へ移ると、図４の例のケースのようにＰＣＲＦ１６ではなく、ＰＣＥＦ１４１が主に関わる本発明概念の複数の観点が示されている。ＰＣＥＦがプライオリティ共有のロジックを保持している場合、ＰＣＥＦは、次のことを行うことになる：
（ａ）ＰＣＥＦは、Ｇｘインタフェース上でＰＣＲＦからＳＤＦに関連付けられる新たな又は修正されたＰＣＣルールを受信する。そのＰＣＣルールは、プライオリティ共有を適用する新たなプライオリティルールがＳＤＦへ関連付けられることを当該ＰＣＲＦへ通知する目的を伴う、新たなプライオリティ共有パラメータ又はプライオリティ共有識別子を含む。
（ｂ）ＰＣＥＦは、ユーザ及びＡＰＮについてインストールされたＰＣＣルールを解析して、他のＳＤＦがプライオリティ共有の対象であるかを認識する。それらが新たなプライオリティ共有パラメータの同一の値を保持している場合には、対象である。
（ｃ）次いで、ＰＣＥＦは、同一のプライオリティ共有値又はプライオリティ共有識別子を有する全てのＳＤＦのプライオリティの、それらＳＤＦのうちの最高のプライオリティのレベル（通常は、最も低いプライオリティ値ＡＲＰ）への調整を進める。ＰＣＥＦは、デフォルトベアラのプライオリティのそれらＳＤＦのうちの最高のプライオリティのレベルへの調整をも行う。

よって、あらためて言うと、理解され得ることとして、プライオリティ共有識別子を用いる本技法に起因して、異なる複数のＳＤＦを収容するために新たなＥＰＳベアラが割り当てられない。これは、図６において、Ｇ１〜Ｇ３についてリクエストされたプライオリティが異なる場合でさえ、Ｇ１〜Ｇ３についてのＳＤＦを単一のＥＰＳベアラがトランスポートすることにより示されている。結果的に、改善されたプライオリティハンドリングが提供される。

提案される解決策の結果は、プライオリティの変化時に追加的なベアラを生成するリスクが排除され又は少なくともかなり低減されることである。

いくつかの観点によれば、プライオリティ共有の識別のために、ＴＳ２９．２１４ｖ１３．３．０におけるＲｘインタフェース仕様において定義されているＧＣＳ識別子パラメータを使用することが提案される。上記観点によれば、ＧＣＳ識別子を、同一のプライオリティの取扱いを共有すべき全てのグループ通信セッション又はＳＤＦを識別するためのキーとして使用することができる。

上のさらなる例が、図１２との関連において以下で与えられるであろう。

図７は、本開示の複数の観点に係る方法を例示するフローチャートを示している。

具体的には、通信ネットワーク１００、２００においてプライオリティハンドリングモジュール１１０、２１０により実行される方法７００が示されている。当該方法は、通信システム内のデータフローに関連付けられるプライオリティルールの構成又は再構成についてのリクエストであって、プライオリティ共有識別子を含む当該リクエストを受信することＳ１、を含む。このリクエストは、図４及び図６に関連して例示したものである。そうしたリクエストが生成される一例は、例えば、アプリケーションがミッションクリティカルなステータスへ進行し、従って、関連付けられるＳＤＦに、より高いプライオリティが付与されることをリクエストする場合である。そうしたリクエストが生成される他の例は、例えば、アプリケーションがミッションクリティカルなステータスから退出し、従って、関連付けられるＳＤＦに、より低いプライオリティが付与されることをリクエストする場合である。

方法７００は、受信される上記リクエストに基づいて、通信システムのプライオリティパラメータを計算することＳ２、をも含む。即ち、図４及び図６の例ではそれはＡＲＰパラメータである。

上記方法は、さらに、通信システム内の、プライオリティ共有識別子に関連付けられる他のデータフローを識別することＳ３、を含む。これは、本発明概念の裏にある１つの鍵である。この識別により、通信システムは、共通のプライオリティ共有識別子を有しプライオリティに関して均一な取扱いを与えられるデータフローをグルーピングすることができる。

上記方法は、構成又は再構成についての上記リクエスト、及び通信システム内の上記プライオリティ共有識別子に関連付けられる何らかの他の識別されたデータフローの既存のプライオリティ構成に基づいて、共有されるプライオリティパラメータを判定することＳ４、をも含む。この判定が、プライオリティに関して複数のデータフローの均一な取扱いが生じる場である。共有されるプライオリティパラメータは、図４及び図６において、最高のプライオリティを与える最も低いＡＲＰパラメータによって例示されている。但し、本技法は、この具体的な共有プライオリティパラメータには決して限定されない。逆に、共通するプライオリティ共有識別子を有するデータフローへプライオリティ値を割り当てるために、いかなるプライオリティポリシーを適用することもできる。例えば、ＡＲＰの実際のプライオリティレベル値があっても無くても、ＰＣＩ（Preemption Capability Indicator）フラグ及びＰＶＩ（Preemption Vulnerability Indicator）フラグで、共有プライオリティパラメータの一部を形成することができる。

複数の観点によれば、上記方法は、通信システム内のデータフローに関連する現行のプライオリティ構成を記憶することＳ５、をも含む。そうした記憶の１つの理由は、前の構成に戻ってプライオリティ構成を追跡し直すことができることである。プライオリティ構成のトラックレコードが利用可能であれば、通信システムにおいて前に使用されたプライオリティ構成を使用することを要するシナリオが発生する場合に、前の構成をリロードすることができる。

複数の観点によれば、上記方法は、判定された共有されるプライオリティパラメータに基づいて、通信システム内のデータフローに関連するプライオリティ構成を更新することＳ６、をさらに含む。この更新は、プライオリティ共有の概念に基づく判定されたプライオリティ構成の実際の適用である。注記されることとして、この更新は、図７に示した方法の他の部分を実行したものと同じノード又は演算モジュールにより実行されてもされなくてもよい。

図８は、本開示の複数の観点に係る方法を例示するフローチャートを示している。

具体的には、図７に示した方法の複数の観点が示されており、その方法のそれぞれの部分が通信システムのＰＣＲＦにおいて実行される。プライオリティハンドリング処理にＰＣＲＦが関与するケースの一例は、図４に関連して与えられている。

よって、観点８００によれば、プライオリティハンドリングモジュールは、３ＧＰＰにより定義される通信システムのＰＣＲＦ（Policy and Charging Rule Function）を含む。

複数の観点によれば、上記受信することＳ１は、ＧＣＳ（Group Communication Service）識別子により与えられるプライオリティ共有識別子を有するＳＤＦ（service data flow）に関連するＡＡＲ（Authentication/Authorization Request）を受信することＳ１１、を含む。このＡＡＲメッセージは、例えば図４との関連において議論されたものであり、後に図１１との関連においても議論される。

複数の観点によれば、上記計算することＳ２は、ＡＲＰ（Allocation and Retention Priority）を計算することＳ２１、を含む。

複数の観点によれば、上記計算することＳ２は、ＰＣＩ（Preemption capability）及び／又はＰＶＩ（Preemption Vulnerability）を計算することＳ２２、並びに、受信されるＡＡＲについてのＰＣＣ（Policy and Charging Control）ルールを生成すること、を含む。

複数の観点によれば、上記識別することＳ３は、通信システム内の上記同一のプライオリティ共有識別子を有する他のＳＤＦを識別することＳ３１、を含む。

複数の観点によれば、上記判定することは、同一のＧＣＳ識別子を有する識別されるＳＤＦの間で共通のＡＲＰ（Allocation and Retention Priority）を計算することＳ４１、を含む。これは、例えば、ＡＲＰのプライオリティレベルが計算されることを意味し得る。

複数の観点によれば、方法８００は、計算される最低のプライオリティ値で、識別されるＳＤＦについてのＰＣＣルールを更新することＳ６１、を含む。

複数の観点によれば、方法８００は、通信システムの現行のＰＣＣルール構成を記憶することＳ５１、をさらに含む。

図９は、本開示の複数の観点に係る方法を例示するフローチャートを示している。

具体的には、図７に示した方法の複数の観点が示されており、その方法のそれぞれの部分が通信システムのＰＣＥＦにおいて実行される。プライオリティハンドリング処理にＰＣＥＦが関与するケースの一例は、図６に関連して与えられている。

よって、観点９００によれば、プライオリティハンドリングモジュールは、３ＧＰＰにより定義される通信システムのＰＣＥＦ（Policy and Charging Enforcement Function）を含む。

複数の観点によれば、上記受信することＳＡ１ａは、ＰＣＲＦからプライオリティ構成又は再構成メッセージを受信すること、を含む。

複数の観点によれば、方法９００は、上記構成又は再構成メッセージに関連付けられるプライオリティ共有属性を受信することＳＡ１ｂ、を含む。

複数の観点によれば、上記識別することは、通信システム内の上記プライオリティ共有属性を有する他のＳＤＦを識別することＳＡ３、を含む。

複数の観点によれば、上記判定することは、上記プライオリティ共有属性を有する識別されるＳＤＦの間で共有されるプライオリティを判定することＳＡ４、を含む。

複数の観点によれば、方法９００は、共有されるプライオリティに基づいて、ＳＤＦについてのプライオリティ構成を更新することＳＡ６、を含む。

図１０は、本開示の複数の観点に係るネットワークノードを概略的に示している。具体的には、通信ネットワーク１００、２００においてプライオリティハンドリングを実行するように構成されるネットワークノード１０００が示されている。当該ネットワークノードは：
通信システム内のデータフローに関連付けられるプライオリティルールの構成又は再構成についてのリクエストであって、プライオリティ共有識別子を含む当該リクエストを受信する、ように構成される受信モジュールＳｘ１と、
受信される上記リクエストに基づいて、上記通信システムのプライオリティパラメータを計算する、ように構成される計算モジュールＳｘ２と、
上記通信システム内の、上記プライオリティ共有識別子に関連付けられる他のデータフローを識別する、ように構成されるデータフロー識別モジュールＳｘ３と、
構成又は再構成についての上記リクエスト、及び上記通信システム内の上記プライオリティ共有識別子に関連付けられる何らかの他の識別されたデータフローの既存のプライオリティ構成に基づいて、共有されるプライオリティパラメータを判定する、ように構成される判定モジュールＳｘ４と、
を備える。

複数の観点によれば、上記ネットワークノードは、ＰＣＲＦ（Policy and Charging Rule Function）を実行する、ように構成される。

複数の観点によれば、上記ネットワークノードは、ＰＣＥＦ（Policy and Charging Enforcement Function）を実行する、ように構成される。

図１１は、通信システムにおいてある数のＳＤＦ（Service Data Flow）の共有されるプライオリティハンドリングのために構成される修正ＡＡＲ（Authentication/Authorization Request）メッセージ１１００を概略的に示しており、当該修正ＡＡＲメッセージは、グループ通信サービス識別子１１１０（GCS-Identifier）を含み、上記ＧＣＳ識別子の値のレンジの少なくとも一部は、プライオリティ共有識別子１１１５又はプライオリティ共有キーを定義する。

図１２は、本技法に従ってデータフローのプライオリティハンドリングを実装する、３ＧＰＰにより定義される通信ネットワークにおけるシグナリングを概略的に示している。

上で言及したように、ワイヤレスデバイスは、いくつかの通信システムにおいて、ＴＳ３６．３３１ｖ１２．７．０に従い、３つまでの確認応答無しモードのデータ無線ベアラ（ＵＭ ＤＲＢ）しか有することができない。このタイプのベアラは、典型的には、ＭＣＰＴＴ呼におけるメディアのようなリアルタイムメディアのために使用される。例えば、ＶｏＬＴＥ標準（ＩＲ．９２）は、ＶｏＬＴＥ呼においてそのメディアのためにＵＭ ＤＲＢの使用を必須としている。

これのユースケースの例として、あるワイヤレスデバイスが１つのＶｏＬＴＥ呼、１つのＭＣＶｉｄｅｏ呼、及び１つのＭＣＰＴＴ呼に関与している場合、３つの利用可能なＵＭ ＤＲＢの全てが使用されることになる。ＭＣＰＴＴサーバがＭＣＰＴＴ緊急呼を開始すると、ベアラを求めるリクエストは、ＵＥが既に３つのアクティブなＵＭ ＤＲＢを有することから、失敗するであろう。

これをハンドリングする１つの手法は、ここで提案したように、ＭＣＰＴＴ呼が共通のＥＰＳベアラプライオリティを共有することを可能にすることである。次いで、ベアラは、１つのワイヤレスデバイスのための（又はそのような固有のベアラ上の）ＭＣＰＴＴ呼のリクエストされた最高のプライオリティへ設定されたプライオリティと共に構成される。あるユースケースは、次の通りであり得る：

ＭＣＰＴＴクライアントが３つのＭＣＰＴＴグループに加入しており、全てのグループ上で進行中の呼が存在するものとする。ＭＣＰＴＴグループ呼のうちの１つがステータスを緊急へと変更する場合、ベアラのプライオリティが調整されるべきである（ＴＳ２３．１７９ｖ１．０．０ 第１０．１１項参照）。このケースでは、ベアラ修正リクエストがＰＣＣへ送信されることになり、ＰＣＣは、このＭＣＰＴＴ呼及び識別される他のＭＣＰＴＴ呼を搬送するＥＰＳベアラについてプライオリティの調整がなされることを確実にすべきである。この機能は、ＰＣＣの拡張を要する。

これは、ＰＣＲＦへ向けてのリソースリクエストにおいてプライオリティ共有識別子又はプライオリティ共有アイデンティティを提供することにより達成されることができる。プライオリティ共有識別子は、Ｇｘ上でＰＣＥＦへ転送され得る。このプライオリティ共有アイデンティティは、プライオリティを共有し得る１つのベアラ内の全てのサービスデータフロー（ＳＤＦ）を識別するために使用される。よりプライオリティの低いＭＣＰＴＴ呼は、この手法で、よりプライオリティの高いＥＰＳベアラに便乗することになるが、それが、全てのベアラが使用されている場合に緊急呼を拒絶しないことの代償となる。ＭＣＰＴＴサーバは、この代償を考慮に入れるべきである。

図１２に示した情報のフローは、１つのＥＰＳベアラ内の複数のＳＤＦの間で共有されるプライオリティをサポートするためのＰＣＣの更新を提案している。それらＳＤＦは、プライオリティ共有アイデンティティで互いに関連付けられ、プライオリティ共有アイデンティティを、上で議論したように、ＲｘインタフェースにおけるＧＣＳアイデンティティＡＶＰ内に含めることができる。

また、マルチメディアプライオリティサービスの同じ原理に従って、同一のプライオリティで、デフォルトベアラをもアップグレードすべきである。

ここで提案した解決策は、別個のプライオリティを伴う２つ又は３つでさえあり得る並列的なＵＭ ＤＲＢベアラをＭＣＰＴＴが使用することに制限を取り入れるものではない。

図１２を参照しつつ、ＭＣＰＴＴからの全ての前のリソースリクエストが同一のプライオリティ共有識別子を含んでいたものとする。図１２には、次の一連のイベントが示されている：
１．ＭＣＰＴＴサーバは、進行中の呼のプライオリティを調整しなければならないと決定する。その一例は、ＭＣＰＴＴグループ呼が緊急呼へ変更される場合である（ＴＳ２３．１７９ｖ１．０．０第１０．１１項参照）。
２．ＭＣＰＴＴサーバは、ＳＩＰ（Session Initiation Protocol）コアを介してＵＥへ、セッション更新リクエスト（例えば、ＳＩＰ再招待（SIP re-invite）又はＳＩＰ更新（SIP update））を送信する。このリクエストは、ＭＣＰＴＴサーバにより使用されるプライオリティ共有識別子を含むであろう。
３．ＳＩＰコア内のプロキシ機能は、修正されたプライオリティをリクエストするために、Ｒｘ上でＰＣＲＦへＡＡＲリクエストを送信する。ＡＡＲリクエストは、Ｒｘ上のＧＣＳ識別子ＡＶＰ内のプライオリティ共有アイデンティティを含むであろう。そのＡＡＲリクエストは、図４及び図６との関連において議論したものである。
４．ＰＣＲＦは、ＡＡＡ（Authentication/Authorization Answer）で応答する。このＡＡＡは、図４及び図６に関連して明示的には言及されなかったが、ＰＣＲＦがＡＡＲを受信することの直接的な結果である。
５．ＰＣＣは、上で議論したように、同一のプライオリティ共有識別子に関連付けられるＳＤＦを含むベアラについてのベアラプライオリティを更新する。そのプライオリティは、それらＳＤＦのうちの最高のプライオリティ（最も低いＡＲＰ）へ設定される。追加的なベアラは生成されない。デフォルトベアラのプライオリティもまた、それに応じて更新される。
６．セッション更新がＭＣＰＴＴクライアントへ転送される。

言い換えると、ワイヤレスデバイスにおける例えばＥＰＳベアラの制限に起因してクリティカルなサービスが拒絶されてしまう問題に対処するための解決策は、同一のプライオリティ共有識別子に関連付けられる複数のＳＤＦの間でプライオリティを共有する可能性、即ちプライオリティ識別子を共有する可能性を導入することである。図１２を参照すると、通信ネットワーク内のプライオリティハンドリングモジュール、即ちＰＣＣにより実行される方法が示されている。その方法は、通信システム内のデータフローに関連付けられるプライオリティルールの構成又は再構成についてのリクエストを受信すること、を含み、当該リクエストは、プライオリティ共有識別子、即ちセッション更新及びＡＡＲを含む。図１２におけるイベント５として示したＰＣＣによるベアラプライオリティの更新は、受信されるリクエストに基づいて通信システムのプライオリティパラメータを計算すること、及びプライオリティ共有識別子に関連付けられる通信システム内の他のデータフローを識別することに加えて、構成又は再構成を求める上記リクエストと上記プライオリティ共有識別子に関連付けられる通信システム内の何らかの他の識別されるデータフローの既存のプライオリティ構成とに基づいて共有されるプライオリティパラメータを判定すること、の結果である。

本発明概念が主にわずかな実施形態への参照と共に上で説明されている。しかしながら、当業者により容易に認識されるように、以下の別添の列挙される実施形態のリストにより定義される通りの本発明概念のスコープの範囲内で、上で開示したもの以外の他の実施形態が等しく可能である。

１．
通信システム（１００，２００）におけるデータフローのプライオリティハンドリングのためのシステムであって、
各々がデータフローの１つ以上をトランスポートするように構成される１つ以上のデータベアラと、
データフロー間のプライオリティ付けを行うように構成されるプライオリティハンドリングモジュール（１４０，１４１，１６０）と、
を備え、
前記プライオリティハンドリングモジュールは、第１のデータフローのプライオリティの構成又は再構成についてのリクエストを受信する、ように構成され、
前記プライオリティハンドリングモジュールは、前記第１のデータフローのプライオリティ共有識別子を取得する、ように構成され、
前記プライオリティハンドリングモジュールは、前記通信システム内の、前記第１のトランスポートデータフローの前記プライオリティ共有識別子を有する他のデータフローを識別する、ように構成され、
前記プライオリティハンドリングモジュールは、前記第１のデータフローに関連付けられ及び前記通信システム内の前記第１のトランスポートデータフローの前記プライオリティ共有識別子を有する何らかの他の識別されたデータフローにも関連付けられるプライオリティルールを更新して、共有されるプライオリティルールに関し合意する、ように構成される、
システム。
２．
前記同一のプライオリティルールは、前記第１のトランスポートデータフローの前記プライオリティ共有識別子を有する、前記通信システム内の前記第１のデータフロー及び前記他の識別されたデータフローのうち、最高のプライオリティ値に対応する、実施形態１に記載のシステム。
３．
前記プライオリティハンドリングモジュールは、前記第１のデータフローに関連付けられるデータベアラのプライオリティルールを、前記共有されるプライオリティルールに関する合意におけるプライオリティルールに関連付けられるように更新する、ように構成される、実施形態１〜２のいずれかに記載のシステム。
４．
前記同一のプライオリティルールは、予め構成されるプライオリティポリシーに従って設定される、実施形態１に記載のシステム。
５．
通信ネットワーク（１００，２００）においてプライオリティハンドリングモジュール（１１０，２１０）により実行される方法（７００）であって、
通信システム内のデータフローに関連付けられるプライオリティルールの構成又は再構成についてのリクエストであって、プライオリティ共有識別子を含む当該リクエストを受信すること（Ｓ１）と、
受信される前記リクエストに基づいて、前記通信システムのプライオリティパラメータを計算すること（Ｓ２）と、
前記通信システム内の、前記プライオリティ共有識別子に関連付けられる他のデータフローを識別すること（Ｓ３）と、
構成又は再構成についての前記リクエスト、及び前記通信システム内の前記プライオリティ共有識別子に関連付けられる何らかの他の識別されたデータフローの既存のプライオリティ構成に基づいて、共有されるプライオリティパラメータを判定すること（Ｓ４）と、
を含む方法。
６．
前記通信システム内のデータフローに関連する現行のプライオリティ構成を記憶すること（Ｓ５）、を含む、実施形態５に記載の方法。
７．
判定される前記共有されるプライオリティパラメータに基づいて、前記通信システム内のデータフローに関連するプライオリティ構成を更新すること（Ｓ６）、を含む、実施形態５又は実施形態６のいずれかに記載の方法。
８．
前記プライオリティハンドリングモジュールは、３ＧＰＰにより定義される通信システムのＰＣＲＦ（Policy and Charging Rule Function）を含む、実施形態４〜７のいずれかに記載の方法（８００）。
９．
前記受信すること（Ｓ１）は、ＧＣＳ（Group Communication Service）識別子により与えられるプライオリティ共有識別子を有するＳＤＦ（service data flow）に関連するＡＡＲ（Authentication and Authorization Request）を受信すること（Ｓ１１）、を含む、実施形態８に記載の方法（８００）。
１０．
前記計算すること（Ｓ２）は、ＡＲＰ（Allocation and Retention Priority）を計算すること（Ｓ２１）、及び、受信される前記ＡＡＲについてのＰＣＣ（Policy and Charging Control）ルールを生成すること、を含む、実施形態９に記載の方法（８００）。
１１．
前記計算すること（Ｓ２）は、ＰＣＩ（Preemption capability）及び／又はＰＶＩ（Preemption Vulnerability）を計算すること（Ｓ２２）、を含む、実施形態９又は実施形態１０のいずれかに記載の方法（８００）。
１２．
前記識別すること（Ｓ３）は、前記通信システム内の前記同一のプライオリティ共有識別子を有する他のＳＤＦを識別すること（Ｓ３１）、を含む、実施形態８〜１１のいずれかに記載の方法（８００）。
１３．
前記判定することは、同一のＧＣＳ識別子を有する識別されるＳＤＦの間で共通のＡＲＰ（Allocation and Retention Priority）を計算すること（Ｓ４１）、を含む、実施形態８〜１２のいずれかに記載の方法（８００）。
１４．
計算される最低のプライオリティ値で、識別されるＳＤＦについてのＰＣＣルールを更新すること（Ｓ６１）、を含む、実施形態１３に記載の方法（８００）。
１５．
デフォルトベアラについてのプライオリティを更新すること（Ｓ６２）、を含む、実施形態１４に記載の方法（８００）。
１６．
前記通信システムの現行のＰＣＣルール構成を記憶すること（Ｓ５１）、をさらに含む、実施形態８〜１５のいずれかに記載の方法（８００）。
１７．
前記プライオリティハンドリングモジュールは、３ＧＰＰにより定義される通信システムのＰＣＥＦ（Policy and Charging Enforcement Function）を含む、実施形態５〜７のいずれかに記載の方法（９００）。
１８．
前記受信すること（ＳＡ１ａ）は、ＰＣＲＦからプライオリティ構成又は再構成メッセージを受信すること、を含む、実施形態１７に記載の方法（９００）。
１９．
前記構成又は再構成メッセージに関連付けられるプライオリティ共有属性を受信すること（ＳＡ１ｂ）、を含む、実施形態１８に記載の方法。
２０．
前記識別することは、前記通信システム内の前記プライオリティ共有属性を有する他のＳＤＦを識別すること（ＳＡ３）、を含む、実施形態１９に記載の方法。
２１．
前記判定することは、前記プライオリティ共有属性を有する識別される前記ＳＤＦの間で共有されるプライオリティを判定すること（ＳＡ４）、を含む、実施形態１７〜２０のいずれかに記載の方法（８００）。
２２．
共有されるプライオリティに基づいて、ＳＤＦについてのプライオリティ構成を更新すること（ＳＡ６）、を含む、実施形態２１に記載の方法。
２３．
通信システム（１００，２００）のネットワークノードにおいて実行された場合に、前記通信システムに、実施形態５〜２２のいずれかに記載の方法を実行させるコンピュータプログラムコード、を含むコンピュータプログラム。
２４．
通信ネットワーク（１００，２００）においてプライオリティハンドリングを実行するように構成されるネットワークノード（１０００）であって、
通信システム内のデータフローに関連付けられるプライオリティルールの構成又は再構成についてのリクエストであって、プライオリティ共有識別子を含む当該リクエストを受信する、ように構成される受信モジュール（Ｓｘ１）と、
受信される前記リクエストに基づいて、前記通信システムのプライオリティパラメータを計算する、ように構成される計算モジュール（Ｓｘ２）と、
前記通信システム内の、前記プライオリティ共有識別子に関連付けられる他のデータフローを識別する、ように構成されるデータフロー識別モジュール（Ｓｘ３）と、
構成又は再構成についての前記リクエスト、及び前記通信システム内の前記プライオリティ共有識別子に関連付けられる何らかの他の識別されたデータフローの既存のプライオリティ構成に基づいて、共有されるプライオリティパラメータを判定する、ように構成される判定モジュール（Ｓｘ４）と、
を備えるネットワークノード。
２５．
前記ネットワークノードは、ＰＣＲＦ（Policy and Charging Rule Function）を実行する、ように構成される、実施形態２４に記載のネットワークノード。
２６．
前記ネットワークノードは、ＰＣＥＦ（Policy and Charging Enforcement Function）を実行する、ように構成される、実施形態２５に記載のネットワークノード。
２７．
通信システムにおいてある数のＳＤＦ（Service Data Flow）の共有されるプライオリティハンドリングのために構成される修正ＡＡＲ（Authentication/Authorization Request）メッセージであって、前記修正ＡＡＲメッセージは、ＧＣＳ識別子（Group Communication Service Identifier）を含み、前記ＧＣＳ識別子の値のレンジの少なくとも一部は、プライオリティ共有識別子又はプライオリティ共有キーを定義する、修正ＡＡＲメッセージ。

Claims (27)

1. 通信システム（１００，２００）におけるデータフローのプライオリティハンドリングのためのシステムであって、
   各々がデータフローの１つ以上をトランスポートするように構成される１つ以上のデータベアラと、
   データフロー間のプライオリティ付けを行うように構成されるプライオリティハンドリングモジュール（１４０，１４１，１６０）と、
   を備え、
   前記プライオリティハンドリングモジュールは、第１のデータフローのプライオリティの構成又は再構成についてのリクエストを受信する、ように構成され、
   前記プライオリティハンドリングモジュールは、前記第１のデータフローのプライオリティ共有識別子を取得する、ように構成され、
   前記プライオリティハンドリングモジュールは、前記通信システム内の、前記第１のトランスポートデータフローの前記プライオリティ共有識別子を有する他のデータフローを識別する、ように構成され、
   前記プライオリティハンドリングモジュールは、前記第１のデータフローに関連付けられ及び前記通信システム内の前記第１のトランスポートデータフローの前記プライオリティ共有識別子を有する何らかの他の識別されたデータフローにも関連付けられるプライオリティルールを更新して、共有されるプライオリティルールに関し合意する、ように構成される、
   システム。
2. 前記同一のプライオリティルールは、前記第１のトランスポートデータフローの前記プライオリティ共有識別子を有する、前記通信システム内の前記第１のデータフロー及び前記他の識別されたデータフローのうち、最高のプライオリティ値に対応する、請求項１に記載のシステム。
3. 前記プライオリティハンドリングモジュールは、前記第１のデータフローに関連付けられるデータベアラのプライオリティルールを、前記共有されるプライオリティルールに関する合意におけるプライオリティルールに関連付けられるように更新する、ように構成される、請求項１〜２のいずれかに記載のシステム。
4. 前記同一のプライオリティルールは、予め構成されるプライオリティポリシーに従って設定される、請求項１に記載のシステム。
5. 通信ネットワーク（１００，２００）においてプライオリティハンドリングモジュール（１１０，２１０）により実行される方法（７００）であって、
   通信システム内のデータフローに関連付けられるプライオリティルールの構成又は再構成についてのリクエストであって、プライオリティ共有識別子を含む当該リクエストを受信すること（Ｓ１）と、
   受信される前記リクエストに基づいて、前記通信システムのプライオリティパラメータを計算すること（Ｓ２）と、
   前記通信システム内の、前記プライオリティ共有識別子に関連付けられる他のデータフローを識別すること（Ｓ３）と、
   構成又は再構成についての前記リクエスト、及び前記通信システム内の前記プライオリティ共有識別子に関連付けられる何らかの他の識別されたデータフローの既存のプライオリティ構成に基づいて、共有されるプライオリティパラメータを判定すること（Ｓ４）と、
   を含む方法。
6. 前記通信システム内のデータフローに関連する現行のプライオリティ構成を記憶すること（Ｓ５）、を含む、請求項５に記載の方法。
7. 判定される前記共有されるプライオリティパラメータに基づいて、前記通信システム内のデータフローに関連するプライオリティ構成を更新すること（Ｓ６）、を含む、請求項５又は請求項６のいずれかに記載の方法。
8. 前記プライオリティハンドリングモジュールは、３ＧＰＰにより定義される通信システムのＰＣＲＦ（Policy and Charging Rule Function）を含む、請求項５〜７のいずれかに記載の方法（８００）。
9. 前記受信すること（Ｓ１）は、ＧＣＳ（Group Communication Service）識別子により与えられるプライオリティ共有識別子を有するＳＤＦ（service data flow）に関連するＡＡＲ（Authentication and Authorization Request）を受信すること（Ｓ１１）、を含む、請求項８に記載の方法（８００）。
10. 前記計算すること（Ｓ２）は、ＡＲＰ（Allocation and Retention Priority）を計算すること（Ｓ２１）、及び、受信される前記ＡＡＲについてのＰＣＣ（Policy and Charging Control）ルールを生成すること、を含む、請求項９に記載の方法（８００）。
11. 前記計算すること（Ｓ２）は、ＰＣＩ（Preemption capability）及び／又はＰＶＩ（Preemption Vulnerability）を計算すること（Ｓ２２）、を含む、請求項９又は請求項１０のいずれかに記載の方法（８００）。
12. 前記識別すること（Ｓ３）は、前記通信システム内の前記同一のプライオリティ共有識別子を有する他のＳＤＦを識別すること（Ｓ３１）、を含む、請求項８〜１１のいずれかに記載の方法（８００）。
13. 前記判定することは、同一のＧＣＳ識別子を有する識別されるＳＤＦの間で共通のＡＲＰ（Allocation and Retention Priority）を計算すること（Ｓ４１）、を含む、請求項８〜１２のいずれかに記載の方法（８００）。
14. 計算される最低のプライオリティ値で、識別されるＳＤＦについてのＰＣＣルールを更新すること（Ｓ６１）、を含む、請求項１３に記載の方法（８００）。
15. デフォルトベアラについてのプライオリティを更新すること（Ｓ６２）、を含む、請求項１４に記載の方法（８００）。
16. 前記通信システムの現行のＰＣＣルール構成を記憶すること（Ｓ５１）、をさらに含む、請求項８〜１５のいずれかに記載の方法（８００）。
17. 前記プライオリティハンドリングモジュールは、３ＧＰＰにより定義される通信システムのＰＣＥＦ（Policy and Charging Enforcement Function）を含む、請求項５〜７のいずれかに記載の方法（９００）。
18. 前記受信すること（ＳＡ１ａ）は、ＰＣＲＦからプライオリティ構成又は再構成メッセージを受信すること、を含む、請求項１７に記載の方法（９００）。
19. 前記構成又は再構成メッセージに関連付けられるプライオリティ共有属性を受信すること（ＳＡ１ｂ）、を含む、請求項１８に記載の方法。
20. 前記識別することは、前記通信システム内の前記プライオリティ共有属性を有する他のＳＤＦを識別すること（ＳＡ３）、を含む、請求項１９に記載の方法。
21. 前記判定することは、前記プライオリティ共有属性を有する識別される前記ＳＤＦの間で共有されるプライオリティを判定すること（ＳＡ４）、を含む、請求項１７〜２０のいずれかに記載の方法（８００）。
22. 共有されるプライオリティに基づいて、ＳＤＦについてのプライオリティ構成を更新すること（ＳＡ６）、を含む、請求項２１に記載の方法。
23. 通信システム（１００，２００）のネットワークノードにおいて実行された場合に、前記通信システムに、請求項５〜２２のいずれかに記載の方法を実行させるコンピュータプログラムコード、を含むコンピュータプログラム。
24. 通信ネットワーク（１００，２００）においてプライオリティハンドリングを実行するように構成されるネットワークノード（１０００）であって、
    通信システム内のデータフローに関連付けられるプライオリティルールの構成又は再構成についてのリクエストであって、プライオリティ共有識別子を含む当該リクエストを受信する、ように構成される受信モジュール（Ｓｘ１）と、
    受信される前記リクエストに基づいて、前記通信システムのプライオリティパラメータを計算する、ように構成される計算モジュール（Ｓｘ２）と、
    前記通信システム内の、前記プライオリティ共有識別子に関連付けられる他のデータフローを識別する、ように構成されるデータフロー識別モジュール（Ｓｘ３）と、
    構成又は再構成についての前記リクエスト、及び前記通信システム内の前記プライオリティ共有識別子に関連付けられる何らかの他の識別されたデータフローの既存のプライオリティ構成に基づいて、共有されるプライオリティパラメータを判定する、ように構成される判定モジュール（Ｓｘ４）と、
    を備えるネットワークノード。
25. 前記ネットワークノードは、ＰＣＲＦ（Policy and Charging Rule Function）を実行する、ように構成される、請求項２４に記載のネットワークノード。
26. 前記ネットワークノードは、ＰＣＥＦ（Policy and Charging Enforcement Function）を実行する、ように構成される、請求項２５に記載のネットワークノード。
27. 通信システムにおいてある数のＳＤＦ（Service Data Flow）の共有されるプライオリティハンドリングのために構成される修正ＡＡＲ（Authentication/Authorization Request）メッセージであって、前記修正ＡＡＲメッセージは、ＧＣＳ識別子（Group Communication Service Identifier）を含み、前記ＧＣＳ識別子の値のレンジの少なくとも一部は、プライオリティ共有識別子又はプライオリティ共有キーを定義する、修正ＡＡＲメッセージ。
    

Images