JP2009513041A

JP2009513041A - ネットワークを利用したモジュール的ポリシー決定

Info

Publication number: JP2009513041A
Application number: JP2008534105A
Authority: JP
Inventors: ヘイッキワリス
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2005-10-13
Filing date: 2006-10-09
Publication date: 2009-03-26
Anticipated expiration: 2026-10-09
Also published as: KR20080058380A; KR100950840B1; CN101288270B; JP4705173B2; US8151321B2; US20070089161A1; CN101288270A; EP1938513B1; WO2007042903A1; EP1938513A1

Abstract

本発明は、ネットワークを利用したモジュール的ポリシー決定を可能にするポリシー決定の方法およびシステム、アクセス・ネットワークならびに端末装置に関する。ポリシー決定は別々の段階に分けられ、各段階は特定の種類のトリガ・イベントを処理し、特定の種類のポリシー・アクションを実行する。この別々の段階はポリシー決定ラウンド中に順次処理され、ポリシー決定ラウンド中に発生するトリガ・イベントは、次のポリシー決定ラウンドの開始まで凍結される。その結果、遅延および不安定状態が軽減されたモジュール式ポリシー決定を実現できる。さらに、ポリシー決定に使用される端末リソースを節約できるように、ポリシー処理を、ネットワークのポリシー決定ポイント機能と、ネットワークまたは端末装置のポリシー実行ポイント機能とに分けることができる。
【選択図】図３

Description

本発明は、互いに関係し合っているトリガ・イベントとポリシー・アクションとを用いるポリシー決定のための方法、システム、ネットワーク構成要素および端末装置に関する。特に、本発明は多重アクセス・ポリシー決定に関する。

発明の背景

動的なシステムを要求通りに動作させるために、当該システムのユーザおよびオペレータは、種々の状況にシステムがどのように対応するべきであるかを指定する一連のポリシーを使用できる。各ポリシーまたはポリシー・ステートメントは、特定のアプリケーションまたはアプリケーションのセットに適用され、さらにアプリケーションの論理インスタンスに特有であることもある。これは、条件と、その条件に一致するトラフィックに適用されるネットワーク・サービスとを記述することもある。ポリシー・ステートメントは、基礎を成すポリシー条件の全般的な論理式を含むこともある。各条件は、アプリケーションのトラフィック・フローのサブセットについて記述しており、全体的なポリシー・パラメータ識別子、演算子およびオペランドをそれぞれ含んだ基礎的な条件要素を含んでいることもある。ポリシー識別子は、アプリケーション特有であることもある。各ポリシー識別子は、文字列、整数または列挙値など、所定の型式を有することもある。例えば、ポリシー識別子が"URL"であり、演算子が"contains"であり、オペランドが"www.nokia.com"であることもある。複数のグローバルな所定のポリシー識別子には、ソースおよび宛先のインターネット・プロトコル（IP：Internet Protocol）・アドレス、ソースおよび宛先のポート番号、プロトコル、アプリケーション識別子、ならびにアプリケーションのコード・ポイント（ACP：application code point）が含まれることもあり、このACPは、アプリケーションによりつくられる１つもしくは複数の種類のトラフィック・フローもしくはクラスを識別および定義すること、または、例えば内在するアプリケーション・パラメータに従って静的な形でアプリケーション・フローを定義することもある。

こうしたことから、メカニズム全体は、ポリシーの構成および管理（ポリシー制御メカニズムのヒューマン・インターフェース）、ならびにポリシーの決定および実行（メカニズムの自動化部分）から成る。ポリシーの決定および実行は、まずポリシー決定を開始するトリガ・イベントを入力として受信し、続いて、決定されたポリシー・アクションの結果を実行する命令を出力として送信することによって、構成されたポリシーを適用する。

一般的に、トリガ・イベントおよびポリシー・アクションは状態変化として説明することができる。トリガ・イベントが、入力として受信される既に発生した状態変化である一方、ポリシー・アクションは将来発生するべき状態変化であり、そのために出力として送信される。トリガ・イベントの実際の検出、およびポリシー・アクションにより指示される変化の影響は、ポリシー制御メカニズムの外のコンポーネントに存在すると考えることができる。

トリガ・イベントおよびポリシー・アクションは両方とも状態変化であり、唯一異なるのがタイミングおよび確率（トリガ・イベントについては1、ポリシー・アクションについては＜1）であるため、結果的に、一部のポリシー・アクションがその後のポリシーのトリガ・イベントとなることがある。この２つの間には一方向の因果関係があり、ある状態変化は前後の別の状態変化につながっている。このことから、ポリシーI／Oは、ソフトウェアなどにおいての一般的なI／Oと異なることになる。

ポリシー制御の分野の一例に多重アクセスがあるが、これは、装置が多重インターフェース、複数の論理アクセスおよび接続されている複数のネットワーク・ドメインを有する状況を意味し、装置はこれを通して接続およびトラフィック・フローを有する。装置は、これら複数のネットワークを通して順次または同時にアクセスでき、どのネットワークでどの接続が受け入れられるか、ならびに新たなネットワークへ移動できるかまたは移動させるべきかを記述するために、ポリシーが必要とされる。

ポリシー決定の例は、ネットワークへの接続性をインターフェースが失ったことの検出などのトリガ・イベントが、別のインターフェースを有する新たなネットワークの検出を試み、その新たなネットワークに接続し、続いてすべてのトラフィックを前のネットワークからそこへ移動させるというポリシー・アクションを引き起こす場合である。このタスクに関係するポリシーは非常に複雑化しやすく、複数のトリガ・イベントが非常に短い期間中に受信される可能性もある。さらに、一部のポリシー・アクションの決定は他よりも多くのステップおよび長い時間から成るため、複数のポリシー・アクションが別々の時間に出力として送信可能になることもある。これは決定の遅延につながることもある。例えば、最初に決定エンジンが新たなフローが開始されたことを伝えるトリガ・イベントを受信して、それに適切なネットワークを選択し；すぐ後に決定エンジンが、新たなネットワークを選択する必要があることを意味する、ネットワークが利用不可能になったことを伝えるトリガ・イベントを受信した場合などである。さらに、端末の接続性において繰り返し（looping）および不安定状態（oscillation）が生じることもある。例えば、最初に決定エンジンが、フローが閉じられたことを伝えるトリガ・イベントを受信し、当該のアクセス・ネットワークを使用しているフローがなくなったためそのアクセス・ネットワークから切断し、すぐ後に、新たなフローが開始され同じネットワークに再び接続する必要があることを伝えるトリガ・イベントを受信した場合などである。

一般的に、現在のポリシー制御メカニズムは、一連の明示的なテスト（トリガの条件）を使用して、ポリシーを決定し、実行可能な結果を得る。したがって、トリガの追加は、非常に深い平行した一連の条件文および過度に大きなポリシー記述につながる。さらに、一部のトリガは他のトリガに従属している。例えば、物理層で適切なインターフェースが作動されリンク層（L2）のリンクが検出されるまで、ネットワーク層（L3）でネットワークを検出することはできない。ポリシー条件文の直線的な実行が原因で、トリガ間のこのような依存関係が解決されるのを待つことはその間に端末が他の何らかのポリシー決定を行うのを妨げることになる。

さらに、直線的に実行されるポリシーが、起こり得る全トリガのうちの一部のみを使用すると、結果が別のトリガ・イベントを引き起こし、次に、その直線的に実行される別のポリシーが最初のポリシーのトリガをもたらす可能性がある。このような繰り返しとしては、例えば、新たなトラフィック・フローによりトリガされてインターフェースが作動し、その作動が第２のポリシーで、該トラフィック・フローを維持するのに必要な別のインターフェースの使用をブロックすることにつながることもあり、その結果、第１のポリシーの結果が一変して無効にされることなどが考えられる。

3.9G（第３.9世代）システムのアーキテクチャを定義するために継続的な取り組みが行われている。ユーザにはホーム・ドメインがあり、そのポリシー情報は、プロキシ・ポリシー決定および実行を目的として他のネットワーク・ドメインへ転送できるというのが、現在の考えである。アクセス集約ドメイン（Access Aggregation Domain）があると考えられ、これを通して、エンド・ユーザのトラフィックの制御プレーンおよびユーザ・プレーン両方が流れる。このドメインは、複数のローカルなアクセス接続性ドメイン（local Access Connectivity domains）からのエンド・ユーザ・アクセスの知的管理を提供し、これは例えば、WLAN（Wireless Local Area Network：無線ローカル・エリア・ネットワーク）またはWiMAX（Worldwide Interoperability for Microwave Access：マイクロ波アクセスの世界的相互接続性）アクセス・ネットワークとすることも可能である。これは、ネットワーク・ベースの多重アクセス・プロキシ・ポリシー決定および実行の両方を促進する。

移動端末装置は、どのアクセス・ネットワークまたはアクセス・ポイントに各データ・フローが関連付けられるべきかについて、自動的に決定する必要がある。しかし端末は、一部のアクセス・ポイントに関する定義が欠如していること、または、すぐ近くにあるがそれでもやはり対象範囲からちょうど外れている無線ネットワークを検出できないことなど、ローカル・アクセス・ネットワーク上の不十分な情報が原因で、最適な方法で動作できないこともある。

発明の摘要

そのため、決定遅延、繰り返しおよび不安定状態、ならびに端末リソースの消費を軽減できる手段で、改善されたポリシー決定スキームを提供することが本発明の目的である。

この目的は、相互に依存しているトリガ・イベントおよびポリシー・アクションを用いるポリシー決定の方法によって達成される。この方法は、
・前記ポリシー決定を別々の段階に分けるステップであって、前記段階はそれぞれ、特定の種類の前記トリガ・イベントを処理し特定の種類の前記ポリシー・アクションを実行する、前記ステップと；
・前記別々の段階をポリシー決定ラウンド中に時間順で処理するステップと；
・ポリシー決定ラウンド中に発生するトリガ・イベントを次のポリシー決定ラウンドが開始するまで凍結するステップと
を含む。

さらに、上記の目的は、相互に依存しているトリガ・イベントおよびポリシー・アクションを用いてポリシー決定を実行するポリシー決定システムにより達成される。このシステムは、
・前記ポリシー決定の別々の段階をポリシー決定ラウンド中に時間順で処理する処理手段であって、前記段階はそれぞれ、特定の種類の前記トリガ・イベントを処理し特定の種類の前記ポリシー・アクションを実行する、前記手段と；
・ポリシー決定ラウンド中に発生するトリガ・イベントを次のポリシー決定ラウンドの開始まで凍結する凍結手段と
を含む。

したがって、ポリシー決定は、特定の種類のトリガ・イベントを処理し特定の種類のポリシー・アクションを実行する、明確に区別された段階に分けられる。各ポリシー決定ラウンドは、時間順で段階を進む。ラウンドの開始後に開始したトリガ・イベントがあればそれらは次の決定ラウンドまで延期されるように、一連のトリガ・イベントは各ラウンドまで凍結される。これによって、対立するポリシーまたはイベントがある場合の複雑な（ネストされた）ポリシー・ルールが回避され、決定遅延、繰り返し、および端末の接続性における不安定状態が軽減される。したがって、決定結果もしくは処理のゆれ、または繰り返しを回避することができる。特定の種類のトリガを、集合としてその他のトリガに依存することなく（その集合の種類に基づくスケジュールによるものを除いて）処理することができる。特定のトリガの種類に影響を及ぼす全ての要素が同時に処理され、これによって予期しない結果を避けられるようになる。

決定ラウンドは、ネットワークの利用可能性を検出する第１段階と、アクセス可能なネットワークをリストアップする第２段階と、トラフィック・フローとそれらの親ドメインとの間の関連付けを更新し、ドメインに好適なネットワークを選択して接続する第３段階と、フローとアクセス・ネットワークとの間の関連付けを更新し、ハンドオーバーについて決定する第４階と、ネットワークから切断するかまたはインターフェースを停止する第５段階と、ポリシー決定を実行する第６段階とを含むとよい。

トリガ・イベントは、構成イベントおよび接続性イベントを含む。構成イベントは、１つのセットで構成アプリケーションによって送信されてもよい。さらに、構成イベントは、他のトリガ・イベントよりも長い期間にわたってバッファリングされてもよい。

上記の第１段階は、その必要性に関する知識またはそれがいつ新たな情報をもたらし得るかに関する推定に基づき行われるとよい。特に、第１段階は、タイマー・イベントおよび位置検出のうちの少なくとも１つを示すコンテキスト情報と、ユーザ・インターフェース・アクセス・イベントおよびユーザ・インターフェース構成イベントのうちの少なくとも１つを示す構成情報と、フロー開始およびフロー終了のうちの少なくとも１つを示すネットワーク状態情報とに基づき行われるとよい。

上記の第２段階は、利用可能であると検出されたネットワークのリストから開始されるとよく、続いて、現在のポリシーによってブロックされるネットワークがリストから削除されるとよい。具体的には、第２段階は、プロファイル・プリファレンスの変更およびアクセス・ポイントの変更のうち少なくとも１つを示す構成情報、ならびに利用可能なアクセス・ポイントおよび利用不可能なアクセス・ポイントのうち少なくとも１つを示すネットワーク状態情報に基づき行われるとよい。

上記の第３段階は、第１ドメインのフローを第２ドメインへ移動する必要性について確認することによって実行されるとよい。特に、第３段階は、ドメイン・プリファレンスの変更およびドメイン定義の変更のうちの少なくとも１つを示す構成情報と、フロー開始およびフロー終了のうちの少なくとも１つを示すネットワーク状態情報に基づき行われるとよい。

上記の第４段階は、利用不可能なアクセス・ポイントおよび開始されたフローのうちの少なくとも１つを示すネットワーク状態情報に基づき行われてもよい。

さらに、第５段階での切断および停止は、アクティブ・フローを何らもたない任意のアクセス・ネットワークに対して行われるとよい。具体的には、第５段階は、フロー開始およびフロー終了のうちの少なくとも１つを示すネットワーク状態情報に基づき行われるとよい。

前記第１、第３および第４段階それぞれの処理、ならびに前記第２段階の少なくとも一部の処理は、アクセス・ゲートウェイ装置（50）で行われる。別の方法として、前記第１段階の処理は各ユーザの端末装置において行われてもよく、これはさらに第５段階の処理も行ってもよい。第２段階の少なくとも一部の処理はサービス・ゲートウェイ装置で行われてもよい。

さらに、上記の目的は、相互に依存しているトリガ・イベントおよびポリシー・アクションを用いるポリシー決定を行うアクセス・ネットワークにより達成され、前記アクセス・ネットワークは、
・ユーザのプリファレンス情報を保持する保持手段と；
・ユーザ・フローを識別する識別手段と；
・前記プリファレンス情報を使用してプロキシ・ポリシー決定処理を実行するポリシー決定手段と
を含む。

さらに、上記の目的は、相互に依存しているトリガ・イベントおよびポリシー・アクションを用いる多重アクセスポリシーを実行する端末装置により達成され、前記端末装置は、
・アクセス・ネットワークへ向かうトラフィック・フローを開始する開始手段と；
・前記アクセス・ネットワークから受信される実行信号に応答して、部分的なポリシー実行を行う決定実行手段と
を含む。

したがって、モジュール式多重アクセスポリシー決定構造のコンポーネントは、端末装置およびその関連のアクセス・ネットワーク（単数または複数）に分配される。アクセス・ネットワークは、ユーザの最新のプリファレンス情報の関連部分を保持する。続いてアクセス・ネットワークは、各ユーザのフローを識別し、ユーザのプリファレンス情報を使用して、そのフローに適切なアクセス・ポイントを選択するべく、プロキシ・ポリシー決定処理を実行できる。

アクセス・ネットワークは、ポリシーを透過的に実行するよう構成されていてもよい。あるいはアクセス・ネットワークは、端末装置との実行信号伝達を開始することによって各端末装置において少なくとも部分的にポリシーを実行させるよう構成されていてもよい。

さらにアクセス・ネットワークは、プリファレンス情報と合うものを見つけるためのアクセス定義を作成するよう構成されていてもよい。

識別手段は、エンド・ユーザをそのインターネット・プロトコル・アドレスに基づき識別するよう構成されていてもよい。さらに識別手段は、セッション開始プロトコル（SIP：Session Initiation Protocol）・プロキシにより検出される統一リソース識別子（URI：Uniform Resource Identifier）、DNSサーバにより検出されるドメイン・ネーム・サーバ（DNS：Domain Name Server）名、または、境界ルータもしくはモビリティ・ゲートウェイ（mobility gateway）により検出されるインターネット・プロトコル（IP：Internet Protocol）・アドレスおよびポートのうちの少なくとも１つに基づきリモート・エンド・ポイントを識別するよう構成されていてもよい。

端末装置は、多重アクセス・ポリシーを保持しているネットワーク・エンティティへのセキュアな接続を確立し、多重アクセス・ポリシーを構成するようになっていてもよい。

さらに端末装置は、エンド・ユーザのポリシー構成のサブセットを在圏アクセス・ネットワークへ転送するよう構成されていてもよい。

さらなる都合のよい変形が従属請求項で定義されていることがある。

好適な実施形態の説明

以下では添付の図面を参照し、実施形態に基づいて本発明についてさらに詳しく説明する。

ここからは、無線端末装置またはユーザ機器（UE：user equipment）の多重アクセス・ネットワーク環境に基づいて好適な実施形態について説明する。

図1はこのような多重アクセス・ネットワーク環境の概略図を示しており、ここで、多重アクセス機能を有する集中型端末装置、すなわちUE20は、各インターフェースl1〜l4を介し、異なるメカニズムを使用することによって、異なるネットワークもしくはネットワーク・ドメイン10−1〜10−4および／またはサービスに接続可能である。多重アクセス・ネットワークは、異なるメカニズムを通したネットワーク・サービスへのアクセスをサポートするネットワークである。例えば、典型的な企業イントラネットには、建物内のイーサネット（登録商標）を介して、またはGPRS（General Packet Radio Services：汎用パケット無線サービス）、EDGE（Enhanced Data rates for GSM Enhancement：GSM拡張に対応するデータ転送速度向上）、WCDMA（Wideband Code Division Multiple Access：広帯域符号分割多元接続）、ケーブル、xDSL（Digital Subscriber Line：デジタル・サブスクライバ・ライン）、WLANなどを通してのアクセスが可能である。

図2は、図1の多重アクセス・ネットワーク環境においてポリシー決定に使用できるポリシー決定のメカニズムまたはエンジンの概略的なブロック図を示す。全体的なポリシー決定メカニズムは、ポリシーの構成および管理（C＆M：configuration and management）を担いポリシー制御メカニズム300のヒューマン・インターフェースを形成する第１メカニズム302、および、ポリシーの決定および実行（R＆E：resolution and enforcement）を担う第２メカニズム304から成る。第２メカニズム304は、ポリシー制御メカニズム300の一部を形成しており、ポリシー決定メカニズム全体の中の自動化された部分である。第２メカニズム304によって行われるポリシーの決定および実行は、ポリシー決定を開始するトリガ・イベントTE（trigger event）をまず入力として受信し、続いて、決定されたポリシー・アクションPA（policy action）の結果を実行する命令を出力として送信することによって構成されたポリシーを適用するよう構成されている。図2に点線で描かれている矢印は、一部のポリシー・アクションPAがその後のポリシーのトリガ・イベントTEとなり得る、最初に説明した結果を示す。

第１実施形態によれば、多重アクセス・ポリシー決定は、特定の種類のトリガ・イベントを処理し特定の種類のポリシー・アクションを実行する明確に区別された段階に分けられており、各ポリシー決定ラウンドは時間順で段階を進む。

図3は、第１実施形態による決定ラウンドの段階の流れ図を示す。ラウンドの開始後に始まったトリガ・イベントがあればそれらが次の決定ラウンドまで延期されるように、一連のトリガ・イベントは各ラウンドの前まで凍結される。図2に示されているように、ポリシー決定エンジンは、構成イベントおよび接続性イベント両方を含むトリガ・イベントTEを外部コンポーネントから受信し、それらを種類に基づき分類する。これらのイベントは、明確な相互関係を持つイベントが起こるのに十分な時間である、一定の短い期間にわたって受信される。

図3によれば、決定ラウンドは、その必要性に関する知識（例えばタイマーまたは位置）、またはそれがいつ新たな情報をもたらし得るかに関する推定（最も信頼できる推測）に基づきIAP（Internet Access Point：インターネット・アクセス・ポイント）利用可能性検出を開始することによってアクセス・ネットワークの利用可能性が検出される第１ステップ、つまり段階S101を含む。ユーザが新たな利用可能性について知っており、構成を通してそのことを直接的に表現するかまたはフローを開始することで間接的に表現することもあると想定するとよい。

続いて第２ステップ、つまり段階S102で、利用可能であると検出されたもののリストから開始し、続いてこれから、何らかのポリシー・コンポーネントによって明示的に拒否されているためかまたは単にネットワークの機能に対して全てのユーザ・プリファレンスを比較した場合に不十分であるために現在のポリシーによってブロックされるものを削除して、使用可能なアクセス・ネットワークのリストを作成することにより、利用可能なネットワークがリストアップされる。

その後の第３ステップ、つまり段階S103で、フローとドメイン（ドメインは、ネットワーク、または特定のトラフィックもしくはサーバの種類を意味する）との関連付けが更新される。例えば、ユーザがIPアドレス範囲の分類子要素をあるドメインから別のドメインへ移すと、エンジンは、第２ドメインへ移す必要があるかどうかについて第１ドメインの全フローを確認しなくてはならない。さらに、各ドメインに好適なアクセス・ネットワークが選択され、必要であれば停止中であるが利用可能なアクセス・ネットワークが接続される（インターフェースの作動を含む）。これがドメイン全体に対して行われる理由は、ポリシー・エンジンの処理要求を減らすためである。十分な電力が利用可能であれば、このドメイン特有の既定のものの代わりに、各フロー後からがそれぞれ選択できる。

続いて第４ステップ、つまり段階S104では、各フローについてフローとアクセス・ネットワークとの間の関連付け（つまりアクセス・ネットワークの選択）が更新され、それら個々のフローがハンドオーバーを行うことができるかどうか、および行うべきかどうかが決定される。それらがIPモビリティをサポートせず、現在のネットワークに留めることができなければ、それらは閉じられる必要がある。

その後の第５ステップ、つまり段階S105では、アクティブ・フローを何らもたない任意のアクセス・ネットワークが切断され、インターフェースが停止されなければならない。

最終的に、決定ラウンドの最後の第６ステップ、つまり段階S106で、端末装置（UE）、アクセス・ゲートウェイ（AGW：Access Gateway）、サービス・ゲートウェイ（SGW：Service Gateway）またはサブスクライバ・プロファイル・リポジトリ（SPR：Subscriber Profile Repository）など、一連のネットワーク構成要素（NE：network element）のうちの１つにおいて、ポリシー決定アルゴリズム・コンポーネントが実行される。SGWは、サービス主導型のエンド・ツー・エンドのセッション確立の場合に使用される。より単純に展開する場合（単一のオペレータ）は、AGWがSGWの機能を実行する。

具体的には、以下の既定の機能配分が実装されてもよい。第１段階S101でのアクセス・ネットワーク利用可能性検出およびリストアップはAGWあるいはUEで行われるとよい。第２段階S102でのプロファイル・コンテンツの更新は、UEにおいて作成されてSPRに格納され、AGWおよび／またはSGWで決定されてもよい。特に、好適なネットワークの選択および接続はAGWによる制御が可能である一方、定義済みのドメインの好適なネットワークの選択はSGWによる制御が可能である。さらに、第３段階S103でのトラフィック・フローとそれらの親ドメインとの間の関連付けの更新はSGWによる制御が可能である一方、第４段階S104でのフローの終了および開始はAGWによる制御が可能である。フローとアクセス・ネットワークとの間の関連付けの更新およびハンドオーバーの決定はAGWによる実行または制御が可能である一方、使用されていないインターフェースの閉鎖はUEで達成することが可能である。

NE間、およびUEとNEとの間でトリガ・イベントをやりとりするためのインターフェースおよびプロトコル（つまり、端末の内部アルゴリズムの関数呼び出しまたはプロセス間メッセージ）があるべきである。

図4は、第１実施形態による、ネットワークを利用したモジュール式ポリシー決定手順例の概略的な信号伝達図を示す。UE20は、検出された近接するリンク／ネットワークのリストをAGW50に提供するが、そうしなければこれらはオペレータのインフラストラクチャでは確認できない。オペレータは、手数料を与えることによってこのような情報に対して「支払う」ことさえあると思われる。逆に、UE20がいくつかのオペレータおよび近接する（アドホック）ネットワークから選択できるように、AGW50がUE20に当該のオペレータのネットワークのリストを提供する。UE20のサブスクライバは情報料を支払うこともある。

さらに、UE20またはAGW50は、例えばセッション開始プロトコル（SIP：Session Initiation Protocol）によって自動的に検出されない限り、そのフローの指示をSGW60へ送信する。SGW60は、アクセス制御の決定が原因で閉じられるフローの指示を用いて応答する。AGW50がネットワーク利用可能性の更新をSGW60へ送信する一方、SGW60は、AGWのネットワーク・リストの更新を返し、ドメイン・アクティビティの更新をAGW50へ送信する。

厳密な機能配分は、UEの機能およびオペレータによって提供されるサポートのレベル（例えば、サブスクライバが他のネットワークを使用することを許可するかどうかなど）によって決まる。独立操作ではなくエンド・ユーザからの確認または選択を求める場合には、SPR（既定）を介してかまたは直接、NEとUEとの間にインターフェースがあるとよい。

ユーザ構成について言えば、あらゆる構成イベントは、構成アプリケーションによって１つのセットで（例えば、全ての変更がユーザによって行われたとき、またはユーザが構成アプリケーションもしくはユーザ・インターフェースを閉じたときに）送信されるべきである。これは、その結果、それらをポリシー決定において同時に処理することが可能になるためである。あるいは、ポリシー決定エンジンがこれらを他のトリガ・イベントよりも長い期間にわたってバッファリングしてもよいが、これは簡潔性および効率性が劣るソリューションとなる。ユーザが程なく前の構成変更を取り消すこと、または最初に何らかの重要でない細部を変更して、次に結局、例えば全てのポリシーに影響を及ぼすプロファイルを完全に変更することも考えられるため、ユーザが実際にユーザ構成イベントを選択したときにそれらが送信されると多数の問題が生じることになる。

以下では、Symbian接続性管理構造に関する非常に高レベルな実装例について説明する。ここで、IAPはアクセス・ネットワークを表し、BMはポリシー・アクションを実行するベアラ・マネジャ（bearer manager）を表し、Policy DBはポリシーおよび状態情報のリポジトリを表す。

図3の段階を参照すると、第１段階の目的は決定処理を開始することであり、IAP利用可能性検出で始まり、利用可能性の変化の指示は、タイマーもしくは位置検出（またはその他のセンサ）などの端末の内部ソースから受信されるコンテキスト情報、ユーザ・インターフェース（UI：user interface）・アクセス・イベント（例：ConfigAppのオープン，プロファイルの開始）もしくはUI構成イベントなどの構成情報、および／またはフロー開始もしくはフロー終了などBMから受信されるネットワーク状態情報に基づくとよい。

以下に第１段階の処理のプログラム例を示す。

第２段階の目的は、どのIAPが利用可能であり現在のどのポリシーにもブロックされないか、つまりどのIAPを使用することができるかを決定することである。手順は、変更されたプロファイル・プリファレンスもしくは変更されたIAP定義などの構成情報、および／またはIAP利用可能もしくはIAP利用不可能などのネットワーク状態情報に基づくことが可能である。

以下に第２段階の処理のプログラミング例を示す。

第３段階の目的は、フローとドメインとのマッピングを更新し、各ドメインについてIAPプリファレンスを選択し、停止中であるが利用可能なIAPを必要であれば起動することである。手順は、変更されたドメイン・プリファレンスもしくは変更されたドメイン定義などの構成情報、および／またはフロー開始もしくはフロー終了などのネットワーク状態情報に基づくことが可能である。

以下に第３段階の処理のプログラム例を示す。

第４段階の目的は、必要であれば各フローへのIAP選択を更新し、フローの移動について決定することである。手順は、IAP利用不可能またはフロー開始済みなどのネットワーク状態情報に基づくことが可能である。

以下に第４段階の処理のプログラミング例を示す。

第５段階の目的は、使用されていないIAPを停止することである。手順は、フロー終了済みまたはフロー変更済みなどのネットワーク状態情報に基づくことが可能である。

以下に第５段階の処理のプログラム例を示す。

第２実施形態は、ネットワークを利用したポリシー決定の具体的な例に関し、ここで、第１実施形態で定義されたモジュラ多重アクセス・ポリシー決定構造のコンポーネントが、端末装置と、その関連のホーム・ネットワークおよびアクセス・ネットワークとの間で特定の方法で共有される。

図5は、第２実施形態による、ネットワークを利用したポリシー決定手順の流れ図を示しており、図5の左側の列はアクセス・ネットワーク（AN：access network）で行われる処理ステップを示し、右側の列は端末装置（UE）で行われる処理ステップを示している。図5の中央部に示されている処理ブロックは、アクセス・ネットワークおよび端末装置両方を必要とする処理に関連している。

アクセス・ネットワーク（AN）は、ユーザの最新のプリファレンス情報の関連部分を保持しており、さらにその位置内の全てのアクセス・ポイントおよびネットワークのエッジ・セグメントについての適合性のある定義を有していてもよい。アクセス・ネットワークは、ステップS201で各ユーザのフローを識別し、ステップS202で、フローに適切なアクセス・ポイントを選択するべくユーザのプリファレンス情報およびそれ自体のアクセス・ネットワーク定義を使用してプロキシ・ポリシー決定処理を実行できる。ポリシーは、アクセス・ネットワークによって透過的に（ステップS203に示されているように）かまたはアクセス・ネットワークと端末装置との間の実行信号伝達（代わりのステップS203'）に基づいてエンド・ユーザの端末によって実行される（代わりのステップS204'）。

図6は、好適な第２実施形態によるネットワークを利用したポリシー決定手順のさらに詳しい流れ図を示す。簡単に言えば、手順にはS301からS305の5つのステップが含まれる。

第１ステップ301で、アクセス・ネットワークでの、エンド・ユーザのプリファレンスと合うものを見つけるためのアクセス定義の作成において、アクセス・ネットワーク・エッジで使用されるアクセス技術およびそれらのパラメータの知識に基づく静的情報（これは、例えば、3.9Gアクセス集約ドメインで行われてもよい）、ならびに交雑状態およびトラフィックのQoSレベルなどを示す動的状態情報（これは、3.9Gアクセス集約ドメインにおいて行われてもよく、あるいは、更新がアクセス接続性ドメインから得られてもよい）が結合される。

ステップS302で、ホーム・ネットワーク（3.9Gサブスクリプション・ドメインなど）で保持されているユーザの多重アクセス・ポリシーの構成および同期化が行われる。端末は、例えばIPsec（IPセキュリティ）カプセル化セキュリティ・ペイロード（ESP：Encapsulating Security Payload）・セキュリティ・アソシエーション（SA：Security Association）・トンネルを使用し、ポリシーを保持しているネットワーク・エンティティへのセキュアな接続を有しているとよい。さらにユーザは、例えばパブリック・エンド・ユーザ・アイデンティティに関連したポリシーのみを送信し、同じサブスクライバのコーポレート・エンド・ユーザ・アイデンティティに関連したポリシーは送信しないなど、ポリシー決定に使用されるポリシーをリモート・ネットワークへ転送する条件を指定できる。

続いてステップS303で、エンド・ユーザのポリシー構成のサブセットが、在圏アクセス・ネットワークへ転送され、ユーザがそのネットワークを介してアクセスしている間そこに格納される。現在アクティブなポリシー構成のみが転送されればよい。これは、アクセス・ネットワークおよびホーム・ネットワークの両方を既に関与させているユーザ承認処理の続きであることも考えられる。

その後のステップS304では、アクセス・ネットワーク（3.9Gアクセス集約ドメインなど）内のフローが識別される。エンド・ユーザはそのIPアドレスに基づき識別され、このIPアドレスは、物理的なネットワーク・トポロジに結び付けられていてもよく（例えば3.9Gアクセス接続性ドメインにおいて）、またはモビリティ・ゲートウェイによって制御されていてもよい（例えば3.9Gアクセス集約ドメインにおいて）。フローのリモート・エンド・ポイントは次の3つの方法のうちの１つで識別できる（通常、ポリシー実行には、少なくともそのフローのエンド・ポイントのIPアドレス、および場合によっては端末のIPアドレスも使用する必要がある）。

・ SIPプロキシが、端末からのINVITEメッセージまたは端末へのINVITEメッセージの処理中にセッションのエンド・ポイントのURIを検出し、これをPDPへ送信する。
・ DNSサーバが、端末が開始するフローの行き先のエンド・ポイントのDNS名を検出する。
・境界ルータまたはモビリティ・ゲートウェイが、端末と通信しているエンド・ポイントのIPアドレスおよび／またはポートを検出する。

最後にステップS305で、ポリシー決定がアクセス・ネットワーク（例えば、一部のアイデンティティまたはモビリティ決定については3.9Gアクセス集約ドメインであるが、通常は、コンテキスト転送が必要な場合等は、アクセス制御およびハンドオーバーの決定についてはアクセス接続性ドメイン）で実行される。さらに、実行には端末装置で次の動作が必要とされることもある。

・端末装置が、フローを開始して、好適なアクセス・ポイントの識別子をアクセス・ネットワークが応答として送信するまで待つ（処理状態を把握しての制御を目的として、認証および承認のプロトコルが再利用されることも考えられるし、または、任意のアクセス・ネットワーク決定を受信するよう開いたソケットを端末が有することも考えられる）。
・端末装置がアクセス・ネットワークにより提供される好適なアクセス・ポイント識別子をリクエストする（上記と同じ信号伝達メカニズムを使用）。これによって端末は、モバイルIPまたはIPv6のサポートなど、フローに特有の追加の要件も提供できることになる。
・端末装置はフローを開始するが、アクセス・ネットワークの応答は、アクセス・ネットワークが無線受信可能範囲内であると知っている特定の位置に端末が達するまでか、またはアクセス・ネットワークにおける混雑状態もしくはエラー状態が終わるまで、開始を遅らせることである。

第２実施形態によれば、ポリシー決定ポイント（PDP：Policy Decision Point）機能がネットワークで提供される一方、ポリシー実行ポイント（PEP：Policy Enforcement Point）機能はネットワークまたは端末装置（UE）で提供されてもよい。そのため、第一実施形態の次の特性が生かされる。エンド・ユーザ主導型のポリシー構成モデルが簡素かつコンパクトなポリシーにつながり、これによって、端末からのネットワーク・ベースのエンド・ユーザ・ポリシーを保持すること、およびリモート・ネットワークでのプロキシ決定のためにそれらを効率よく送信すること両方が容易になる（特定の明示的な構文を使用して定義された非常に詳細なポリシーとは対照的である）。ポリシー・オブジェクト（"プロファイル"、"ドメイン"、"アクセス"）の抽出によって、ポリシー決定アルゴリズムは端末プラットフォームだけではなくアクセス・ネットワーク・プラットフォームにも依存しなくなる。さらに、ポリシー属性（"価格"、"消費電力"など）の抽出は、アクセス・ネットワークが、そのアクセス・ポイント定義およびローカル・ポリシー決定アルゴリズムにおいて多少の柔軟性を持つことを可能にし、同じアルゴリズムで多くの種類のアクセス技術（アクセス接続性ドメイン）をサポートできるようにする。さらに、ユーザに関係するポリシー情報（プロファイルおよびドメイン）と、アクセス・ネットワークに関係するポリシー情報（アクセスおよびアクセス・ポイントのグループ）とを区別することで、全体的なポリシー構成を２つのソース、すなわち個々のエンド・ユーザおよびアクセス・ネットワークから導き出すことが可能になる。最後に、ポリシーが決定されて決断が下される基本的なポリシーの目的物としてデータ・フローを使用することで、端末およびアクセス・ネットワークにおいて、ポリシーの目的物の類似した識別情報およびそれらの関係が可能になる。

図7は、第２実施形態による、端末装置（UE20）とアクセス・ネットワーク（AN10）との間のネットワークを利用したポリシー決定手順例の信号伝達および処理の概略図を示す。

在圏AN10は、その地理的領域内で契約プロバイダによって運用されている全てのアクセス・ポイントの機能定義を有すると想定される。

ステップ1で、UE20は在圏アクセス・ネットワークとの認証を行う。AN10は、端末ユーザの現在アクティブなポリシー情報を受信し、ステップ2でそれを一時的に格納する。続いてステップ3で、UE20は既定のインターフェース上でフローの制御プレーンを開始する。この開始は、ステップ4でAN10によって上記の方法を使用して検出される。続いてステップ5で、AN10はポリシー決定アルゴリズムを実行して結果を得る。ステップ6で、AN10は結果の端末実行が必要な部分をUE20へ送信する。最後にステップ7aで、UE20が結果の受信部分を実行するため、決定の部分的な実行が行われる。同時に、AN10は結果の残りをそれ自体に実行するため、同じく決定の部分的な実行が行われる。

要約すれば、ネットワークを利用したモジュール的ポリシー決定を可能にするポリシー決定の方法およびシステム、アクセス・ネットワークおよび端末装置について説明してきた。ポリシー決定は別々の段階に分けられ、各段階は特定の種類のトリガ・イベントを処理し特定の種類のポリシー・アクションを実行する。個々の段階はポリシー決定ラウンド中に時間順で処理され、ポリシー決定ラウンド中に発生するトリガ・イベントは次のポリシー決定ラウンドの開始まで凍結される。その結果、遅延および不安定状態が軽減されたモジュール式ポリシー決定を実現できる。さらに、ポリシー決定に使用される端末リソースを節約できるように、ポリシー処理を、ネットワークのポリシー決定ポイント機能と、ネットワークまたは端末装置のポリシー実行ポイント機能とに分けることができる。

なお、本発明は、多重アクセス・ポリシーを用いた上記の好適な実施形態には限定されないが、セル部分特有のリモート・ヘッドがよりよい受信可能範囲を得るために使用される任意の種類のポリシー決定に関連して適用できる。そのため、好適な実施形態は、添付の特許請求の範囲の範囲内で変化してもよい。

本発明を実装できる多重アクセス環境の例を示す概略図である。ポリシー決定エンジンの概略的なブロック図である。第１実施形態による、モジュール式ポリシー決定手順の流れ図である。第１実施形態による、ネットワークを利用したモジュール式ポリシー決定手順例の概略的な信号伝達図である。第２実施形態による、ネットワークを利用したポリシー決定手順の流れ図である。好適な第２実施形態による、ネットワークを利用したポリシー決定手順のさらに詳しい流れ図である。第２実施形態による、ネットワークを利用したポリシー決定手順の信号伝達および処理の概略図である。

Claims

互いに関係し合っているトリガ・イベントとポリシー・アクションとを用いるポリシー決定の方法であって、
ａ）前記ポリシー決定を別々の段階に分けるステップであって、前記段階はそれぞれ、特定の種類の前記トリガ・イベントを処理し、特定の種類の前記ポリシー・アクションを実行する、前記ステップと；
ｂ）前記別々の段階を、ポリシー決定ラウンド中に時間順に処理するステップと；
ｃ）ポリシー決定ラウンド中に発生するトリガ・イベントを、次のポリシー決定ラウンドの開始まで凍結するステップと
を含む方法。
前記決定ラウンドは、ネットワークの利用可能性を検出する第１段階と、アクセス可能なネットワークをリストアップする第２段階と、トラフィック・フローとそれらの親ドメインとの間の関連付けを更新し、ドメインに好適なネットワークを選択して接続する第３段階と、フローとアクセス・ネットワークとの間の関連付けを更新し、ハンドオーバーについて決定する第４段階と、ネットワークから切断するかまたはインターフェースを停止する第５段階と、ポリシー決定を実行する第６段階とを含む、請求項１に記載の方法。
前記トリガ・イベントは構成イベントおよび接続性イベントを含む、請求項１または２に記載の方法。
前記構成イベントを１つのセットで構成アプリケーションによって送信するステップをさらに含む、請求項３に記載の方法。
前記構成イベントを、他のトリガ・イベントよりも長い期間にわたってバッファリングするステップをさらに含む、請求項３に記載の方法。
前記第１段階は、その必要性に関する知識またはそれがいつ新たな情報をもたらし得るかに関する推定に基づき行われる、請求項２に記載の方法。
前記第２段階は、利用可能であると検出されたネットワークのリストから開始され、続いて、現在のポリシーによってブロックされるネットワークを前記リストから削除する、請求項２または６に記載の方法。
前記第３段階は、第１ドメインのフローを第２ドメインへ移動する必要性について該フローを確認することによって行われる、請求項２、６または７のいずれか１項に記載の方法。
前記第５段階での前記切断および前記停止は、アクティブ・フローを何らもたない任意のアクセス・ネットワークに対して行われる、請求項２または６〜８のいずれか１項に記載の方法。
前記第１段階は、タイマー・イベントおよび位置検出のうちの少なくとも１つを示すコンテキスト情報と、ユーザ・インターフェース・アクセス・イベントおよびユーザ・インターフェース構成イベントのうちの少なくとも１つを示す構成情報と、フロー開始およびフロー終了のうちの少なくとも１つを示すネットワーク状態情報とに基づき行われる、請求項２または６〜９のいずれか１項に記載の方法。
前記第２段階は、プロファイル・プリファレンスの変更およびアクセス・ポイントの変更のうちの少なくとも１つを示す構成情報、ならびに利用可能なアクセス・ポイントおよび利用不可能なアクセス・ポイントのうち少なくとも１つを示すネットワーク状態情報に基づき行われる、請求項２または６〜１０のいずれか１項に記載の方法。
前記第３段階は、ドメイン・プリファレンスの変更およびドメイン定義の変更のうちの少なくとも１つを示す構成情報と、フロー開始およびフロー終了のうちの少なくとも１つを示すネットワーク状態情報に基づき行われる、請求項２または６〜１１のいずれか１項に記載の方法。
前記第４段階は、利用不可能なアクセス・ポイントおよび開始されたフローのうちの少なくとも１つを示すネットワーク状態情報に基づき行われる、請求項２または６〜１２のいずれか１項に記載の方法。
前記第５段階は、フロー開始およびフロー終了のうちの少なくとも１つを示すネットワーク状態情報に基づき行われる、請求項２または６〜１３のいずれか１項に記載の方法。
前記第１および前記第５段階の前記処理は各ユーザの端末装置（２０）で行われる、請求項２または６〜１４のいずれか１項に記載の方法。
前記第１、前記第３および前記第４段階それぞれの処理、ならびに前記第２段階の少なくとも一部の処理は、アクセス・ゲートウェイ装置（５０）で行われる、請求項２または６〜１５のいずれか１項に記載の方法。
前記第２段階の少なくとも一部の処理は、サービス・ゲートウェイ装置（６０）で行われる、請求項２または６〜１６のいずれか１項に記載の方法。
互いに関係し合っているトリガ・イベントとポリシー・アクションとを用いるポリシー決定を行うポリシー決定システムであって、
ａ）前記ポリシー決定の別々の段階をポリシー決定ラウンド中に順次処理する処理手段（３０４）であって、前記段階はそれぞれ、特定の種類の前記トリガ・イベントを処理し特定の種類の前記ポリシー・アクションを実行する、前記手段と；
ｂ）ポリシー決定ラウンド中に発生するトリガ・イベントを、次のポリシー決定ラウンドの開始まで凍結する凍結手段（３０４）と
を含むシステム。
互いに関係し合っているトリガ・イベントとポリシー・アクションとを用いるポリシー決定を行うアクセス・ネットワークであって、
ａ）ユーザのプリファレンス情報を保持する保持手段と；
ｂ）ユーザ・フローを識別する識別手段（Ｓ２０１）と；
ｃ）前記プリファレンス情報を使用してプロキシ・ポリシー決定処理を実行するポリシー決定手段（Ｓ２０２）と
を含むアクセス・ネットワーク。
前記アクセス・ネットワークは、ポリシーを透過的に実行するよう構成されている、請求項１９に記載のアクセス・ネットワーク。
前記アクセス・ネットワークは、端末装置（２０）との実行信号伝達を開始することによって、前記端末装置（２０）それぞれにおいて少なくとも部分的にポリシーを実行させるよう構成されている、請求項２０に記載のアクセス・ネットワーク。
前記アクセス・ネットワークは、前記プリファレンス情報と合うものを見つけるためのアクセス定義を作成するよう構成されている、請求項１９〜２１のいずれか１項に記載のアクセス・ネットワーク。
前記識別手段（Ｓ２０１）は、エンド・ユーザをそのインターネット・プロトコル・アドレスに基づき識別するよう構成されている、請求項１９〜２２のいずれか１項に記載のアクセス・ネットワーク。
前記識別手段（Ｓ２０１）は、セッション開始プロトコル（ＳＩＰ）・プロキシにより検出される統一リソース識別子（ＵＲＩ）、ＤＮＳサーバにより検出されるドメイン・ネーム・サーバ（ＤＮＳ）名、または、境界ルータもしくはモビリティ・ゲートウェイにより検出されるインターネット・プロトコル（ＩＰ）・アドレスおよびポートのうちの少なくとも１つに基づき、リモート・エンド・ポイントを識別するよう構成されている、請求項１９〜２３のいずれか１項に記載のアクセス・ネットワーク。
互いに関係し合っているトリガ・イベントとポリシー・アクションとを用いる多重アクセス・ポリシーを実行する端末装置であって、
ａ）アクセス・ネットワークへ向かうトラフィック・フローを開始する開始手段と；
ｂ）前記アクセス・ネットワークから受信される実行信号に応答して部分的なポリシー実行を行う決定実行手段（７ａ）と
を含む端末装置（２０）。
前記端末装置（２０）は、多重アクセス・ポリシーを保持しているネットワーク・エンティティへのセキュアな接続を確立し、前記多重アクセス・ポリシーを構成するようになっている、請求項２５に記載の端末装置。
前記端末装置（２０）は、エンド・ユーザのポリシー構成のサブセットを在圏アクセス・ネットワークへ転送するよう構成されている、請求項２５または２６に記載の端末装置。