JP2013509057A - マルチアクセスにおけるリソース予約 - Google Patents

Abstract

本発明は、ユーザ機器（１４）とマルチアクセス環境内のゲートウェイとの間のサービスデータフローについてのリソース割当てを可能とするための方法に関する。方法は、リソース予約デバイス（１０，１９）が、サービスデータフローについて予約されるべき専用アクセスリソースを求める予約命令を、ポリシー制御ノード（１３）から受信（１５）するステップと、リソース予約デバイス（１０，１９）が、予約命令により求められたリソース予約の結果をポリシー制御ノード（１３）へ報告するステップと、を含む。方法を特に特徴付けるのは、リソース予約デバイス（１０，１９）が、複数のアクセス（１１，１２）において、予約命令により求められたリソースの予約を要求するステップと、リソース予約デバイス（１０，１９）が、求められたリソースを有効化する選択される単一のアクセス（１１，１２）を、当該アクセス（１１，１２）が選択された際に、ポリシー制御ノードへ報告するステップと、である。
【選択図】図２

Description

本発明は、ユーザ機器とマルチアクセス環境内のゲートウェイとの間のサービスデータフローについてのリソース割当てを可能とするための方法に関する。また、同じ目的のために適合される、リソース予約デバイス、ポリシー制御ノード及びシステムに関する。

端末（ＵＥ／ＭＳ）がいくつかの異なるアクセス技術を介してアクセスできることがますます一般的になってきている。例えば、携帯電話には多くの場合、セルラアクセス機能とＷＬＡＮ（無線ＬＡＮ）アクセス機能の両方が付いてくる。ラップトップは多くの場合、イーサネットとＷＬＡＮとを有し、場合によってはセルラアクセス機能も有する。通常これらの異なるインターフェースは一度に１つずつ使用される。またさらに重要なことには、所与のサービス又は所与のＩＰセッションは一度に１つのアクセスを使用しているにすぎない。

現在、３ＧＰＰ ＥＰＳ（Evolved Packet System）（3GPP SAE（System Architecture Evolution）ともいう）は、ＵＥが異なるアクセス間を移動するときにセッション連続性をどのようにして達成し得るかについての解決策を定義している。これは例えば、セルラアクセス上で動作しているサービスが、代わりにＷＬＡＮアクセス上で動作するように移動されることを意味し得る。しかしこの解決策ではやはりＵＥは一度に１つのアクセスを使用しているにすぎず、アクセス変更の間に、ＩＰセッション及び当該ＩＰセッション内のすべての実行中のサービスは移動元アクセスから移動先アクセスへ移動される。複数のアクセスの同時使用（別名マルチホーミング）は、２つのアクセス間でのハンドオーバ時の非常に短い時間を除いてサポートされない。

ＩＥＴＦ（Internet Engineering Task Force）で進行中の作業があり、関連した作業が、マルチホーミングシナリオにおけるモビリティ解決策を定義するために３ＧＰＰにおいて立ち上がっている。この作業の一部として、「フローモビリティ（flow mobility）」、即ち、所与のＩＰセッションについてのＩＰフローの一部だけがあるアクセスから別のアクセスへ移動されるという概念が研究されている。例えばそれは、マルチメディア呼の映像構成要素だけがセルラアクセスからＷＬＡＮに移動され、同じ呼の音声構成要素に関連したＩＰフローはセルラアクセスに留まることとすることができるはずである。

ポリシー及び課金制御（ＰＣＣ：Policy and Charging Control）アーキテクチャは３ＧＰＰリリース７において導入され、３ＧＰＰリリース８においてさらに進化している（図１参照）。ＰＣＣアーキテクチャは事業者に、サービス対応（service-aware）のＱｏＳ（Quality of Service：サービス品質）及び課金制御のための高度なツールを提供する。ＰＣＥＦ（Policy and Charging Enforcement Function：ポリシー及び課金実施機能）は、ＧＷ（Gateway：ゲートウェイ）、即ち、ＧＰＲＳ（General Packet Radio Service：汎用パケット無線サービス）ベースのコアネットワークのためのＧＧＳＮ（Getaway GPRS Support Node：ゲートウェイＧＰＲＳサポートノード）と、ＥＰＣ（Evolved Packet Core：進化型パケットコア）ベースのコアネットワークのためのＰＤＮ−ＧＷ（Packet Data Network Gateway：パケットデータネットワークゲートウェイ）に含まれる。ＰＣＥＦに接続するためにＧＴＰ（GPRS Transfer Protocol：ＧＰＲＳ転送プロトコル）が使用されるとき、ＰＣＥＦはベアラバインディング及びＱｏＳ予約機能を有する。このアーキテクチャの変種をオンパス（on-path）ＰＣＣという。

リリース８における修正は、ＥＰＣにおけるモバイルＩＰベースのプロトコルのサポートを含む。モバイルＩＰが、（３ＧＰＰベースのアクセスのために）ＧＷとサービスＧＷとの間で、又は（非３ＧＰＰベースのアクセスのために）アクセスＧＷにおいて使用されるときに、ＰＣＣアーキテクチャはやはりベアラバインディング及びイベント報告のためにＢＢＥＲＦ（Bearer Binding and Event Reporting Function：ベアラバインディング及びイベント報告機能）に依拠しなければならない。ＢＢＥＲＦは、３ＧＰＰベースのアクセスではサービスＧＷに、非３ＧＰＰベースのアクセスではアクセスＧＷに包含される。この変形アーキテクチャをオフパスＰＣＣという。オフパスアーキテクチャにおいて、ＰＣＥＦは、リソースを予約するための機能、又はベアラバインディングを行うための機能を持たない。ＰＣＲＦ（Policy and Charging Rules Function：ポリシー及び課金ルール機能）は、（適用できる場合には）ＰＣＣルールをＰＣＥＦへ、ＱｏＳルールをＢＢＥＲＦへ、インストールし及び除去することによって、サービスの使用を承認する。

また図１には、ＳＧＳＮ（Serving GPRS Support Node：サービスＧＰＲＳサポートノード）及びＭＭＥ（Mobility Management Entity：モビリティ管理エンティティ）も示されている。また図１には、ノード間の通信のためのいくつかのリファレンスポイント（Ｓｐ、Ｒｘ、Ｇｘｃ、Ｓ５、Ｇｘａ、Ｓ２ａ、Ｇｚ、Ｇｙ、Ｇｘ、ＳＧｉ）も示されている。これらのノード及びリファレンスポイントは３ＧＰＰ及び非３ＧＰＰの一部であり、本特許出願ではこれ以上詳細に説明しない。

ＰＣＣ又はＱｏＳルールは、パケットをサービスデータフローと関連付けられるリソースとに分類するために使用されるフィルタのセットを定義する。即ち、ＱｏＳクラス及びビットレートである。オンパスＰＣＣでは、ＰＣＥＦにおけるＰＣＣルールのインストール又は除去が、適用可能なアクセスにおけるリソース要求をトリガし得る。オフパスＰＣＣでは、ＢＢＥＲＦにおけるＱｏＳルールのインストール又は除去が、適用可能なアクセスにおけるリソース要求をトリガし得る。ＰＣＣルールは、オフパスＰＣＣの場合にもＰＣＥＦにおいてインストールされ、除去されるが、この場合には、アクセスにおけるリソース要求をトリガすることができず、アクセス制御及び課金に使用されるにすぎない。

いくつかのサービス、例えば、電話技術やオーディオ／ビデオストリーミングなどは、（１名又は複数の）エンドユーザに十分に良好なサービス品質レベルを提供することができるように、ターゲットアクセスにおいて予約されるべきリソースを求める。ネットワークにおけるそのようなサービスの追加を容認し、又は拒否するための機能は、現在のネットワーク負荷に基づくものである。流入制御（admission control）は、セッションセットアップ時とハンドオーバの間とにネットワーク内の様々な点において行われる。ダイナミックＰＣＣが配備される事例では、ネットワークにおいてこのリソースの予約をトリガするのは、（適用できる場合には）ＰＣＥＦ又はＢＢＥＲＦにおけるＧＢＴコンポーネントを用いた（適用できる場合には）ＰＣＣ又はＱｏＳルールのインストールである。リソースの予約に失敗した場合（あるレベルでのシステムにおける不十分な容量）には、ＰＣＥＦ又はＢＢＥＲＦはこれを折り返しＰＣＲＦへ報告し、関連付けられるサービスは（新しいサービス要求については）容認されず、又は切断される（ハンドオーバ）。

多くの事業者は今日すでに、ＧＳＭやＵＭＴＳといった並列セルラアクセス技術を展開している。１Ｇから２Ｇ及び２Ｇから３Ｇへの移行から得られた１つの教訓は、新しいネットワークにおけるカバレージ及び容量が不十分であるために、顧客が多くの場合新しいアクセスを使用したがらないことである。その結果、事業者らは、新しいアクセスにおける容認できない呼ブロックレート（call blocking rate）を防止するために、非常に精力的にそられのネットワークを展開することを強いられる。これは当然ながら事業者にとって非常に高く付き、さらに悪いことに、このために新しいアクセスネットワークの販売をいつ開始し得るかについての限界が生じる。このことの深刻な結果として、このためにネットワークが事業者にとっての収益を生み出し始めるまでの時間が遅延することになる。

本発明の目的は、したがって、展開される新しいネットワークにおける呼ブロックレートを低減することである。

本発明の目的は、ユーザ機器とマルチアクセス環境内のゲートウェイとの間のサービスデータフローについてのリソース割当てを可能とするための方法によって解決される。当該方法は、
リソース予約デバイスが、サービスデータフローについて予約されるべき専用アクセスリソースを求める予約命令を、ポリシー制御ノードから受信するステップと、
リソース予約デバイスが、予約命令により求められたリソースの予約の結果をポリシー制御ノードへ報告するステップと、
を含む。方法を特に特徴付けるのは、
リソース予約デバイスが、複数のアクセスにおいて、予約命令により求められたリソースの予約を要求するステップと、
リソース予約デバイスが、求められたリソースを有効化する選択される単一のアクセスを、当該アクセスが選択された際に、ポリシー制御ノードへ報告するステップと、
である。

また本発明の目的は、リソース予約デバイスによっても解決される。リソース予約デバイスは、ユーザ機器とマルチアクセス環境内のゲートウェイとの間のサービスデータフローについてのリソース割当てを可能とするように適合される。リソース予約デバイスはさらに、ポリシー制御ノード（下記参照）から予約命令を受信するように適合される。予約命令は、サービスデータフローについて予約されるべき専用アクセスリソースを求める。リソース予約デバイスはさらに、予約命令により求められたリソース予約の結果をポリシー制御ノードへ報告するように適合される。

リソース予約デバイスを特に特徴付けるのは、これがさらに、複数のアクセスにおいて、予約命令により求められたリソースの予約を要求するように適合されることである。またリソース予約デバイスは、求められたリソースを有効化する選択される単一のアクセスを、ポリシー制御ノードへ報告するようにも適合される。これは、当該アクセスが選択された際に報告される。

また本発明の目的は、ポリシー制御ノードによっても解決される。ポリシー制御ノードは、ユーザ機器とマルチアクセス環境内のゲートウェイとの間のサービスデータフローについてのリソース割当てを可能とするように適合される。ポリシー制御ノードはさらに、リソース予約デバイス（上記参照）に予約命令を送信するように適合される。予約命令は、サービスデータフローについて予約されるべき専用アクセスリソースを求める。ポリシー制御ノードはさらに、予約命令により求められたリソース予約の結果に関してリソース予約デバイスから報告を受信するように適合される。

ポリシー制御ノードを特に特徴付けるのは、これがさらに、リソース予約デバイスから報告を受信するように適合されることである。報告は、アクセスが選択された際に受信され、求められたリソースを有効化する選択される単一の当該アクセスに関するものである。

最後に、本発明の目的は、システムによって解決される。システムは、ユーザ機器とマルチアクセス環境内のゲートウェイとの間のサービスデータフローについてのリソース割当てを可能とするように適合される。システム内のリソース予約デバイスは、システム内のポリシー制御ノードから予約命令を受信するように適合されるように適合される。予約命令は、サービスデータフローについて予約されるべき専用アクセスリソースを求める。リソース予約デバイスはさらに、予約命令により求められたリソース予約の結果をポリシー制御ノードへ報告するように適合される。

システムを特に特徴付けるのは、リソース予約デバイスがさらに、複数のアクセスにおいて、予約命令により求められたリソースの予約を要求するように適合されることである。またリソース予約デバイスは、求められたリソースを有効化する選択される単一のアクセスを、ポリシー制御ノードへ報告するようにも適合される。これは、当該アクセスが選択された際に報告される。

本発明の主要な利点は、リソース予約が、エラーが折り返しＰＣＲＦへ報告される前に複数のアクセスにおいて試行されるため、すべての利用可能なアクセスが輻輳していない限り、呼が高負荷状況の間に損失（lost）とならないことである。その結果、呼がブロックされる確率が減少し、事業者のすべてのアクセスタイプの総利用量が増加する。

容量のより低い新しいネットワークは、当初から、新しいアクセスの初期容量が限られていることが原因でユーザがブロックされる危険を伴わずに実施されることができる。新しいアクセスにおいて呼が受け入れられない場合には、従来のアクセスタイプが当該呼のために使用される。しかしその要件は、過剰な音声及び映像トラフィックを処理することができるより成熟したレガシーネットワークが並列に存在することである。

さらに別の利点は、以上では言及されていない従属請求項の特徴のうちの１つ又は複数を実施することにより実現される。これを以下でさらに説明する。

以下で、添付図面に示されている実施形態を参照して、本発明をさらに詳細に説明する。

ＥＰＳについての３ＧＰＰリリース８のＰＣＣ非ローミングアーキテクチャを示す図である。 リソース割当てについての既知の解決策を示す図である。 本発明による方法を示す図である。 本発明によるリソースの順次（sequential）予約の第１の選択肢を示す図である。 本発明によるリソースの順次予約の第２の選択肢を示す図である。 本発明によるリソースの並列（parallel）予約の第１の選択肢を示す図である。 本発明によるリソースの順次予約の第３の選択肢を示す図である。 本発明によるリソースの順次予約の第４の選択肢を示す図である。 本発明によるリソースの並列予約の第２の選択肢を示す図である。

本発明は、ユーザ機器とマルチアクセス環境内のゲートウェイとの間のサービスデータフローについてのリソース割当てを可能とするための方法に関するものである。また本発明は、同じ目的のために適合される、リソース予約デバイス、ポリシー制御ノード及びシステムにも関するものである。以下の説明では、後述する上記方法を実行するように適合されるリソース予約デバイス、ポリシー制御ノード及びシステムも開示されることを当業者は理解するであろう。サービスデータフローは、ユーザ機器における特定のサービスについてのデータトラフィックに関するものである。

図２に、一度に単一のアクセスネットワークだけが考慮されるときのリソースの割当てのための既存の手順を示す。リソースは、オンパスＰＣＣが使用されるときのシナリオにおいて以下のように割り当てられる。
１．ポリシー制御ノードがあるサービスデータフローについてリソース予約デバイスに新しい、又は更新された予約命令を提供する。予約命令は、アクセスネットワーク１１（アクセスＡ）において予約されるべき専用リソースを求める。複数の許容されるアクセス１１、１２が並列に存在し得る（図においてアクセスＢで示される）が、ＵＥ／ＭＳは、一度に１つの単一アクセスシステムにおいてしかアクティブになることができない。
２．リソース予約デバイスが、ＵＥ／ＭＳが現在アクティブであるアクセス１１（アクセスＡ）において求められたリソースの予約を要求する。
３．リソースが利用可能である場合には、リソースがアクセス１１（アクセスＡ）において予約される。ユーザ機器１４（ＵＥ／ＭＳ）はその予約の一部である。
４．予約要求の結果が、折り返しリソース予約デバイス１０に伝えられる。
５．リソース予約の結果が、折り返しポリシー制御ノード１３へ報告される。求められたリソースを予約することができなかった場合には、関連付けられたサービスは受け入れられない可能性がある。

以下において、ユーザ機器とマルチアクセス環境内のゲートウェイとの間のサービスデータフローについてのリソース割当てを可能とする本発明の方法を説明する。当該方法は、リソース割当てについて単一のアクセスネットワークだけが使用されるために、低容量の新しいネットワークにおいてビジーな時間帯に呼が損失となる問題を解決するためのものである。これは例えば、図２に示す例における問題である。

アクセス（accesses）とは、以下においては例えば（図１参照）、ＧＥＲＡＮ（GSM Radio Access Network）、ＵＴＲＡＮ（UMTS Terrestial Radio Access Network）、Ｅ−ＵＴＲＡＮ（Evolved UTRAN）、非３ＧＰＰアクセス（non-3GPP Access）などである。図１を参照されたい。当業者は、別の種類のアクセスも「アクセス」という用語に含まれることを理解するであろう。

本発明においては、以下の方法ステップが実行される。図３を参照されたい。
１．リソース予約デバイス１０が、ポリシー制御ノード１３から予約命令を受信１５する。予約命令は、サービスデータフローについて予約されるべき専用アクセスリソースを求める。
２．リソース予約デバイス１０が、予約命令により求められたリソース予約の結果をポリシー制御ノード１３へ報告１６する。
３．リソース予約デバイスが、複数のアクセスにおいて、予約命令により求められたリソースの予約を要求１７する。
４．リソース予約デバイス１０が、求められたリソースを有効化する選択される単一のアクセスを、当該アクセスが選択された際に、ポリシー制御ノード１３へ報告１８する。

本発明は、ステップ１〜４が順番に連続して実行されることを必要としない。ステップ１及び２は一般に知られ、使用される手順の部分（図２参照）であり、ステップ３及びステップ４はリソースを予約するためにリソース予約デバイス１０によって実行されるさらに別のステップである。これらのステップは、リソース予約デバイス１０が予約命令を受信しているときに実行される。

リソース予約デバイスは、以下においては、ＰＣＥＦ１０又はＢＢＥＲＦ１９（ベアラバインディング及びイベント報告機能）によって例示される。ポリシー制御ノードは、以下においては、ＰＣＲＦ１３（ポリシー及び課金ルール機能）によって例示される。予約命令は、以下においては、ＰＣＣ（ポリシー及び課金制御）ルール又はＱｏＳ（サービス品質）ルールによって例示される。ルールは、サービスデータフローの検出を可能とし、ポリシー制御及び／又は課金制御のためのパラメータを提供する情報のセットを含む。ＰＣＣルール及びＱｏＳルールのさらなる定義が３ＧＰＰに記載されている。

ＰＣＥＦ（ポリシー及び課金実施機能）は、ＧＷ（ゲートウェイ）に包含される。例えば、ＧＰＲＳ（汎用パケット無線サービス）ベースのコアネットワークのためのＧＧＳＮ（ゲートウェイＧＰＲＳサポートノード）や、ＥＰＣ（進化型パケットコア）ベースのコアネットワークのためのＰＤＮ−ＧＷ（パケットデータネットワークゲートウェイ）である。このアーキテクチャの変種をオンパスＰＣＣという。ＢＢＥＲＦは３ＧＰＰベースのアクセスのためのサービスＧＷと、非３ＧＰＰベースのアクセスのためのアクセスＧＷとに含まれる。このアーキテクチャの変種をオフパスＰＣＣという。図１を参照されたい。

本発明において受信されるＰＣＣ又はＱｏＳルールは、どの１つ又は複数のアクセスからのリソースの予約をＰＣＥＦ又はＢＢＥＲＦが要求すべきかの情報を含む。ＭＡＰＩＭ（Multi Access PDN connectivity and IP Flow Mobility：マルチアクセスＰＤＮ接続性及びＩＰフローモビリティ）では、専用リソースを求めるサービスを搬送するために潜在的に使用することができるはずの複数のアクセスタイプが提供され得る。あるサービスが複数のアクセスタイプにわたって提供されることを許される場合には、ＰＣＲＦは例えば、これを許容されるアクセスタイプのリストとしてルールにおいて表示することもできる。

第１に、図４〜６を参照して、オンパスＰＣＣにおけるリソース予約の例を示す。オンパスＰＣＣでは、ＰＣＥＦがサービスのためのリソースを予約する。さらに、オンパスではＰＣＣルールが使用される。第２に、図７〜９を参照して、オフパスＰＣＣにおけるリソース予約の例を示す。オフパスＰＣＣでは、ＢＢＥＲＦがサービスのためのリソースを予約する。さらに、オフパスではＱｏＳルールが使用される。

例に示すように、リソース予約はオンパスとオフパスとの両方において２つの異なるやり方で行うことができる。順次リソース予約において、ＰＣＥＦ１０は、複数のアクセスにおいて求められたリソースの予約をシーケンシャルに要求する。並列リソース予約において、ＰＣＥＦは、複数のアクセスにおいて求められたリソースの予約をパラレルに要求する。

またやはり例に示すように、ＰＣＣルールは、シーケンシャル及びパラレルの双方の予約について、複数のアクセス内のリソースの予約を要求することを許容し得る。順次予約では、ルールは、選択肢として、ただ１つの（第１の）アクセス内のリソースの予約を要求することも許容してもよい。これを以下においてさらに説明する。

例に示すように、順次予約におけるＰＣＣルールが複数のアクセスにおいてリソースの予約を要求することを許容するときに、リソース予約の要求は優先度順に実行され得る。そうではなくルールが、ただ１つのアクセスにおいてリソースの予約を要求することを許容するときに、ＰＣＥＦは、最初のアクセスにおいて求められたリソースの予約を要求し得る。次いでＰＣＥＦは、ある次のアクセスにおいて求められたリソースの予約を、上記次のアクセスへのアクセスを許可する新しいルールを受信した後で引き続き要求する。次いでＰＣＲＦは、次のアクセスを優先度順に選択し得る。

ＰＣＣルールが複数のアクセスにおける予約を許容するとき、ＰＣＥＦ１０はまず、最高の優先度を有するアクセスにおけるサービスについてリソースを予約しようとする。これに失敗した場合には、次に高い優先度を有するアクセスタイプが試行されるはずであり、以下同様である。正常なリソース割当てが行われているときに、ＰＣＥＦは、ＰＣＣルールについてのアクセスタイプの結果を折り返しＰＣＲＦ１３へ報告する。順次予約は、例えば、多少長い遅延が許容されるときのサービスセットアップにおいて適当であろう。

並列リソース予約は、例えば、サービスセットアップ時間が順次リソース予約を許容しないときなどに使用されてよい。その場合、同時に同じサービスについて複数のアクセスにおいてリソースを予約しようとする試みが行われ得る。並列リソース予約において、リソースが複数のアクセスにおいて利用可能であるときに、その手順は、単一のアクセスが優先度順に利用可能なリソースの中から選択されるものとすることができる。これを並列予約に関連する例において示す。ＰＣＥＦ１０は、（例えば優先度や他のある基準に基づいて）予約に成功した場合に、１つのアクセスを選択し、選択されなかった別のアクセスにおけるリソースを解放し、次いで、選択されたアクセスをＰＣＲＦへ報告する。

図４〜６に、オンパスＰＣＣにおける順次及び並列リソース予約の例を示す。オンパスＰＣＣでは、ＰＣＥＦがサービスのためのリソースを予約する。さらに、オンパスではＰＣＣルールが使用される。これらの例では、ＵＥ１４は２つの異なるアクセスタイプ、アクセスＡ１１及びアクセスＢ１２を使用して同じＡＰＮ（アクセスポイント名）にアクセスすることができるものと仮定する。どちらのアクセスも、専用リソースを求めるあるサービスを搬送するために使用され得る。ＵＥが２つを上回る異なるアクセスタイプを使用してアクセスすることができる場合も本発明は含むことを、当業者は理解するであろう。

図４に順次予約の一例を示す。この例では、複数のアクセスについて有効なＰＣＣルールがＰＣＥＦ１０にインストールされる。この例では、以下のステップが実行される。
１．ＰＣＲＦ１３が、あるサービスデータフローについて、新しい、又は更新されたＰＣＣルールをＰＣＥＦ１０に提供する。ＰＣＣルールは、アクセスネットワークにおいて予約されるべき専用リソースを求める。サービスは、さらに、アクセスタイプＡ１１とアクセスタイプＢ１２の両方について許可されるが、アクセスタイプＡの方が好ましい。
２．ＰＣＥＦは、アクセスＡにおいて求められたリソースの予約を要求する。
３．リソースが利用可能である場合には、リソースが当該アクセスにおいて予約される。
４．予約要求の結果が折り返しＰＣＥＦに伝えられる。これが成功した場合には、ステップ５から７がスキップされ、ステップ８でアクセスタイプＡが折り返しＰＣＲＦへ報告される。
５．アクセスＡにおける予約が成功しなかった場合には、ＰＣＥＦはアクセスＢにおいてリソースを引き続き要求する。
６．リソースが利用可能である場合には、リソースが当該アクセスにおいて予約される。
７．予約要求の結果が折り返しＰＣＥＦに伝えられる。
これが成功した場合には、ステップ８でアクセスタイプＢが折り返しＰＣＲＦへ報告される。これが成功しなかった場合には、ステップ８でＰＣＥＦがエラーをＰＣＲＦへ報告する。
８．ＰＣＥＦが、ステップ１でインストールされたＰＣＣルールについて、リソース予約の結果を報告する。この情報に基づいて、ＰＣＲＦは次の動作（例えば、課金キー／レーティンググループを変更するなど）を開始し得る。

図５に順次予約の別の例を示す。この例では、１つのアクセスについてのみ有効なＰＣＣルールがＰＣＥＦ１０にインストールされる。リソース予約が失敗した場合、ＰＣＲＦ１３は別のアクセスについて同じＰＣＣルールをインストールする。よってこの選択肢は、図４による例と比べて、ＰＣＥＦに対する要求が少ない（ＰＣＲＦに対する要求が多い）。この例では以下のステップが実行される。
１．ＰＣＲＦ１３が、あるサービスデータフローについて、新しい、又は更新されたＰＣＣルールをＰＣＥＦ１０に提供する。ＰＣＣルールは、アクセスネットワークにおいて予約されるべき専用リソースを求める。サービスは、さらに、アクセスタイプＡ１１とアクセスタイプＢ１２の両方について許可されるが、アクセスタイプＡの方が好ましい。
２．開始されたＰＣＥＦが、アクセスＡにおいて求められたリソースの予約を要求する。
３．リソースが利用可能である場合には、リソースが当該アクセスにおいて予約される。
４．予約要求の結果が折り返しＰＣＥＦに伝えられる。
５．リソース予約の結果が折り返しＰＣＲＦに報告される。結果が成功であった場合には、使用事例はここで終了する。
６．アクセスＡにおける予約が成功しなかった場合には、ＰＣＲＦは、ステップ１の場合と同じサービスデータフローについて、新しい、又は更新されたＰＣＣルールを提供するが、今度は、ＰＣＣルールにおいてアクセスタイプＢが許可される。
７．ＰＣＥＦが次に、アクセスＢにおいてリソースを要求する。
８．リソースが利用可能である場合には、リソースが当該アクセスにおいて予約される。
９．予約要求の結果が折り返しＰＣＥＦに伝えられる。
１０．ＰＣＥＦが、ステップ６でインストールされたＰＣＣルールについて、リソース予約の結果を報告する。

図６に並列予約の一例を示す。複数のアクセスについて有効なＰＣＣルールがＰＣＥＦ１０にインストールされる。以下のステップが実行される。
１．ＰＣＲＦ１３が、あるサービスデータフローについて、新しい、又は更新されたＰＣＣルールをＰＣＥＦ１０に提供する。ＰＣＣルールは、アクセスネットワークにおいて予約されるべき専用リソースを要求する。サービスは、さらに、アクセスタイプＡ１１とアクセスタイプＢ１２の両方について許可されるが、アクセスタイプＡの方が好ましい。
２ａ及び２ｂ．ＰＣＥＦが、同時にアクセスＡ及びＢにおいて求められたリソースの予約を要求する。注：ＰＣＥＦはアクセスタイプごとにトラフィックマッピング情報を提供する。包含されるフィルタは、各アクセスについて同じであってよいが、ＵＥ／ＭＳにおけるトラフィックマッピング競合を回避するために、優先度により分離される。
３ａ及び３ｂ．個々のアクセスにおけるリソースが、割り当てられ、事前に割り当てられ、又は調べられる。
４ａ及び４ｂ．予約要求の結果が折り返しＰＣＥＦに伝えられる。
５ａ及び５ｂ．次いで、ＰＣＥＦにおいて、ＡとＢのどちらのアクセスを使用すべきかの判定が行われる。リソース要求が完了する。これは、ａ）事前割当てリソースをコミットすること、ｂ）調査により肯定的な結果が与えられたアクセスにおいてリソースを割り当てること、ｃ）使用されるべきでないと判定されたアクセスにおける事前割当て又は割当てリソースのロールバック／解放を要求することを含み得る。ＰＣＥＦは、求められる場合には、選択されたアクセス（即ち、アクセスＡ又はアクセスＢ）においてトラフィックマッピング情報を更新し得る。
６ａ及び６ｂ．ＰＣＥＦによって提供される様々な決定が、アクセスＡ及びアクセスＢによって実施される。
７ａ及び７ｂ．予約要求の結果が折り返しＰＣＥＦに伝えられる。
８．ＰＣＥＦが、ステップ１でインストールされたＰＣＣルールについて、リソース予約の結果を報告する。リソースを予約することができた場合には、ＰＣＥＦは選択されるアクセスタイプをＰＣＲＦへ報告する。リソースがアクセスＡに、又はアクセスＢにインストールできなかった場合には、ＰＣＥＦがエラーをＰＣＲＦへ報告する。この情報に基づいてＰＣＲＦは、次の動作（例えば、課金キー／レーティンググループを変更するなど）を開始し得る。

図７〜９に、オフパスＰＣＣにおける順次及び並列リソース予約の例を示す。オフパスＰＣＣでは、ＢＢＥＲＦがサービスのためのリソースを予約する。さらに、オフパスではＱｏＳルールが使用される。これらの例は、多くの点で、図４〜６による例と同様である。しかし、ＢＢＥＲＦは適用可能なＰＣＣルールをインストールすることができないため、新しい最終ステップが導入される。

またこれらの例では、ＵＥ１４が、２つの異なるアクセスタイプ、アクセスＡ１１とアクセスＢ１２とを使用して、同じＡＰＮ（アクセスポイント名）にアクセスすることができるものと仮定する。どちらのアクセスも、専用リソースを求めるあるサービスを搬送するために使用され得る。ＵＥが２つを上回る異なるアクセスタイプを使用してアクセスすることができる場合も本発明は含むことを、当業者は理解するであろう。

図７に順次予約の一例を示す。この例では、複数のアクセスについて有効なＱｏＳルールがＢＢＥＲＦ１０にインストールされる。この例では以下のステップが実行される。
１．ＰＣＲＦ１３が、あるサービスデータフローについて、新しい、又は更新されたＱｏＳルールをＢＢＥＲＦ１９に提供する。ＱｏＳルールは、アクセスネットワークにおいて予約されるべき専用リソースを求める。サービスは、さらに、アクセスタイプＡ１１とアクセスタイプＢ１２の両方について許可されるが、アクセスタイプＡの方が好ましい。
２．開始されたＢＢＥＲＦが、アクセスＡにおいて求められたリソースの予約を要求する。
３．リソースが利用可能である場合には、リソースが当該アクセスにおいて予約される。
４．予約要求の結果が折り返しＢＢＥＲＦに伝えられる。これが成功した場合には、ステップ５から７がスキップされ、ステップ８でアクセスタイプＡが折り返しＰＣＲＦへ報告される。
５．アクセスＡにおける予約が成功しなかった場合には、ＢＢＥＲＦはアクセスＢにおいてリソースを引き続き予約する。
６．リソースが利用可能である場合には、リソースが当該アクセスにおいて予約される。
７．予約要求の結果が折り返しＢＢＥＲＦに伝えられる。これが成功した場合には、ステップ８でアクセスタイプＢが折り返しＰＣＲＦに報告される。これが成功しなかった場合には、ステップ８でＢＢＥＲＦがエラーをＰＣＲＦへ報告する。
８．ＢＢＥＲＦが、ステップ１でインストールされたＱｏＳルールについて、リソース予約の結果を報告する。
９．ＰＣＲＦが、規格に従ってＰＣＥＦ１０に適用可能なＰＣＣルールをインストールする。
１０．ＰＣＥＦが、折り返しインストール手順の結果を報告する。

図８に順次予約の別の例を示す。この例では、１つのアクセスについてのみ有効なＱｏＳルールがＢＢＥＲＦ１９にインストールされる。リソース予約が失敗した場合、ＰＣＲＦ１３は、別のアクセスについて同じＱｏＳルールをインストールする。このＱｏＳルールは、異なるアクセスについて異なるＢＢＥＲＦにインストールされ得ることに留意されたい。よってこの選択肢は、図７による例と比べて、ＢＢＥＲＦに対する要求が少ない（ＰＣＲＦに対する要求が多い）。この例では、以下のステップが実行される。
１．ＰＣＲＦ１３が、あるサービスデータフローについて、新しい、又は更新されたＱｏＳルールをＢＢＥＲＦ１９に提供する。ＱｏＳルールは、アクセスネットワークにおいて予約されるべき専用リソースを要求する。サービスは、さらに、アクセスタイプＡ１１とアクセスタイプＢ１２の両方について許可されるが、アクセスタイプＡの方が好ましい。
２．開始されたＢＢＥＲＦが、アクセスＡにおいて求められたリソースの予約を要求する。
３．リソースが利用可能である場合には、リソースが当該アクセスにおいて予約される。
４．予約要求の結果が折り返しＢＢＥＲＦに伝えられる。
５．リソース予約の結果が折り返しＰＣＲＦに報告される。結果が成功でなかった場合には、使用例はステップ１１に進む。
６．アクセスＡにおける予約が成功しなかった場合には、ＰＣＲＦが、ステップ１の場合と同じサービスデータフローについて新しい、又は更新されたＱｏＳルールを提供するが、今度は、ＱｏＳルールにおいてアクセスタイプＢが許可される。
７．ＢＢＥＲＦは次に、アクセスＢにおいてリソースを要求する。これは、アクセスＡにおいてリソースを要求するために使用されたＢＢＥＲＦとは異なるＢＢＥＲＦである可能性もあることに留意されたい（これは図には示されていない）。
８．リソースが利用可能である場合には、リソースが当該アクセスにおいて予約される。
９．予約要求の結果が折り返しＢＢＥＲＦに伝えられる。
１０．ＢＢＥＲＦが、ステップ６でインストールされたＱｏＳルールについて、リソース予約の結果を報告する。
１１．ＰＣＲＦが、規格に従ってＰＣＥＦ１０へ適用可能なＰＣＣルールをインストールする。
１２．ＰＣＥＦが、折り返しインストール手順の結果を報告する。

図９に並列予約の一例を示す。複数のアクセスについて有効なＱｏＳルールがＢＢＥＲＦ１９にインストールされる。以下のステップが実行される。
１．ＰＣＲＦ１３が、あるサービスデータフローについて、新しい、又は更新されたＱｏＳルールをＢＢＥＲＦ１９に提供する。ＱｏＳルールは、アクセスネットワークにおいて予約されるべき専用リソースを要求する。サービスは、さらに、アクセスタイプＡ１１とアクセスタイプＢ１２の両方について許可されるが、アクセスタイプＡの方が好ましい。
２ａ及び２ｂ．ＢＢＥＲＦが、同時にアクセスＡ及びＢにおいて求められたリソースの予約を要求する。ＢＢＥＲＦは、アクセスタイプごとにトラフィックマッピング情報を提供する。包含されるフィルタは、各アクセスについて同じであってよいが、ＵＥ／ＭＳにおけるトラフィックマッピング競合を回避するために、優先度により分離される。
３ａ及び３ｂ．個々のアクセスにおけるリソースが、割り当てられ、事前に割り当てられ、又は調べられる。
４ａ及び４ｂ．予約要求の結果が折り返しＢＢＥＲＦに伝えられる。
５ａ及び５ｂ．次いで、ＢＢＥＲＦにおいて、ＡとＢのどちらのアクセスを使用すべきかの判定が行われる。リソース要求が完了する。これは、ａ）事前割当てリソースをコミットすること、ｂ）調査により肯定的な結果が与えられたアクセスにおいてリソースを割り当てること、ｃ）使用されるべきでないと判定されたアクセスにおける事前割当て又は割当てリソースのロールバック／解放を要求することを含み得る。ＢＢＥＲＦは、求められる場合には、選択されたアクセス（即ち、アクセスＡ又はアクセスＢ）においてトラフィックマッピング情報を更新し得る。
６ａ及び６ｂ．ＢＢＥＲＦによって提供される様々な決定が、アクセスＡ及びアクセスＢによって実施される。
７ａ及び７ｂ．予約要求の結果が折り返しＢＢＥＲＦに伝えられる。
８．ＢＢＥＲＦが、ステップ１でインストールされたＱｏＳルールについて、リソース予約の結果を報告する。リソースを予約することができた場合には、ＢＢＥＲＦは選択されるアクセスタイプをＰＣＲＦへ報告する。リソースがアクセスＡに、又はアクセスＢにインストールできなかった場合には、ＢＢＥＲＦがエラーをＰＣＲＦへ報告する。
９．ＰＣＲＦが、規格に従ってＰＣＥＦへ適用可能なＰＣＣルールをインストールする。
１０．ＰＣＲＦが、折り返しインストール手順の結果を報告する。

本発明は、図４〜９に図示し、前述した例だけに限定されるものとみなされるべきではない。添付の特許請求の範囲内においていくつかのさらに別の変形及び改変が可能である。例えば、順次と並列のリソース要求の組み合わせを考慮することもできるはずである。例えば、並列予約が２つの最高優先度のアクセスについて実行され、それに失敗した場合には、順次予約が次の２つのアクセスについて実行されるなどである。さらに、提示した発明は、初期接続セットアップ時においても、モビリティ／ハンドオーバ状況においても使用されることが可能である。

Claims (18)

1. ユーザ機器（１４）とマルチアクセス環境内のゲートウェイとの間のサービスデータフローについてのリソース割当てを可能とするための方法であって：
   リソース予約デバイス（１０，１９）が、前記サービスデータフローについて予約されるべき専用アクセスリソースを求める予約命令を、ポリシー制御ノード（１３）から受信（１５）するステップと、
   前記リソース予約デバイス（１０，１９）が、前記予約命令により求められた前記リソースの予約の結果を前記ポリシー制御ノード（１３）へ報告（１６）するステップと、
   を含み、
   前記リソース予約デバイス（１０，１９）が、複数のアクセス（１１，１２）において、前記予約命令により求められた前記リソースの予約を要求（１７）するステップと、
   前記リソース予約デバイス（１０，１９）が、前記リソースを有効化する選択される単一のアクセス（１１，１２）を、当該アクセス（１１，１２）が選択された際に、前記ポリシー制御ノード（１３）へ報告（１８）するステップと、
   を特徴とする方法。
2. 受信される前記予約命令は、どの１つ又は複数のアクセス（１１，１２）からのリソースの予約を前記リソース予約デバイス（１０，１９）が要求すべきかの情報を含む、請求項１に記載の方法。
3. 前記予約命令は、ポリシー及び課金制御ルールにおいて構成され、前記リソース予約デバイスは、ポリシー制御及び実施機能（１０）において構成される、先行する請求項のいずれかに記載の方法。
4. 前記予約命令は、サービス品質ルールにおいて構成され、前記リソース予約デバイスは、ベアラバインディング及びイベント報告機能（１９）において構成される、請求項１〜２のいずれかに記載の方法。
5. 前記予約命令は、複数のアクセスにおいてリソースの予約を要求することを許容する、先行する請求項のいずれかに記載の方法。
6. リソース予約の前記要求は優先度順に実行される、請求項５に記載の方法。
7. 前記リソース予約デバイス（１０，１９）は、前記複数のアクセス（１１，１２）において求められたリソースの予約を、順次要求する、請求項５〜６のいずれかに記載の方法。
8. 前記リソース予約デバイス（１０，１９）は、前記複数のアクセス（１１，１２）において求められたリソースの予約を、並列的に要求する、請求項５に記載の方法。
9. リソースが複数のアクセス（１１，１２）において利用可能である場合に、前記単一のアクセスが優先度順に前記利用可能なリソースの中から選択される、請求項８に記載の方法。
10. 前記予約命令は、最初のアクセス（１１，１２）だけにおいてリソースの予約を要求することを許容する、請求項１〜４のいずれかに記載の方法。
11. 前記リソース予約デバイス（１０，１９）は、前記最初のアクセス（１１，１２）において求められたリソースの予約を要求し、ある次のアクセス（１１，１２）において求められたリソースの予約を、前記次のアクセスへのアクセスを許可する新しい予約命令を受信した後で引き続き要求する、請求項１０に記載の方法。
12. 前記次のアクセス（１１，１２）は優先度順に選択される、請求項１１に記載の方法。
13. ユーザ機器（１４）とマルチアクセス環境内のゲートウェイとの間のサービスデータフローについてのリソース割当てを可能とするように適合されるリソース予約デバイス（１０，１９）であって、
    前記サービスデータフローについて予約されるべき専用アクセスリソースを求める予約命令を、ポリシー制御ノード（１３）から受信（１５）し、
    前記予約命令により求められた前記リソースの予約の結果を前記ポリシー制御ノード（１３）へ報告（１６）する
    ようにさらに適合され、
    複数のアクセス（１１，１２）において、前記予約命令により求められた前記リソースの予約を要求（１７）し、
    前記リソースを有効化する選択される単一のアクセス（１１，１２）を、当該アクセス（１１，１２）が選択された際に、請求項１６〜１７のいずれかに記載の前記ポリシー制御ノード（１３）へ報告（１８）する、
    ようにさらに適合されることを特徴とする、リソース予約デバイス（１０，１９）。
14. 前記リソース予約デバイスは、ポリシー制御及び実施機能（１０）において構成される、請求項１３に記載のリソース予約デバイス（１０，１９）。
15. 前記リソース予約デバイスは、ベアラバインディング及びイベント報告機能（１９）において構成される、請求項１３〜１４のいずれかに記載のリソース予約デバイス。
16. ユーザ機器（１４）とマルチアクセス環境内のゲートウェイとの間のサービスデータフローについてのリソース割当てを可能とするように適合されるポリシー制御ノード（１３）であって、
    前記サービスデータフローについて予約されるべき専用アクセスリソースを求める予約命令を、リソース予約デバイス（１０，１９）に送信し、
    前記予約命令により求められた前記リソースの予約の結果に関して前記リソース予約デバイスから報告を受信する
    ようにさらに適合され、
    前記リソースを有効化する選択される単一のアクセス（１１，１２）に関して当該アクセス（１１，１２）が選択された際に、請求項１３〜１５のいずれかに記載の前記リソース予約デバイス（１０，１９）から報告を受信する
    ようにさらに適合されることを特徴とするポリシー制御ノード（１３）。
17. 前記ポリシー制御ノードは、ポリシー及び課金ルール機能（１３）において構成される、請求項１６に記載のポリシー制御ノード（１３）。
18. ユーザ機器（１４）とマルチアクセス環境内のゲートウェイとの間のサービスデータフローについてのリソース割当てを可能とするように適合されるシステムであって、
    前記システム内のリソース予約デバイス（１０，１９）は、
    前記サービスデータフローについて予約されるべき専用アクセスリソースを求める予約命令を、請求項１６〜１７のいずれかに記載のポリシー制御ノード（１３）から受信（１５）し、
    前記予約命令により求められた前記リソースの予約の結果を前記ポリシー制御ノード（１３）へ報告（１６）する
    ように適合され、前記システム内の前記リソース予約デバイスは、
    複数のアクセス（１１，１２）において、前記予約命令により求められた前記リソースの予約を要求（１７）し、
    前記リソースを有効化する選択される単一のアクセス（１１，１２）を、当該アクセス（１１，１２）が選択された際に、前記ポリシー制御ノード（１３）へ報告（１８）する、
    ようにさらに適合される、
    ことを特徴とするシステム。
    

Images