JP6605955B2

JP6605955B2 - ポリシーベースのローカルブレークアウト（ｌｂｏ）のための方法、システム、およびコンピュータ読取可能な媒体

Info

Publication number: JP6605955B2
Application number: JP2015521879A
Authority: JP
Inventors: ラジャゴパラン，スンダラム; バントゥクル，アピラクス; デーオ，アジャイ・パドマカール
Original assignee: Tekelec Inc
Current assignee: Tekelec Global Inc
Priority date: 2012-07-14
Filing date: 2013-07-15
Publication date: 2019-11-13
Anticipated expiration: 2033-07-15
Also published as: CN104429103B; EP2873256A4; EP2873256B1; WO2014014823A1; US20140018067A1; EP2873256A1; JP2015528244A; CN104429103A; US9473928B2

Description

優先権主張
本願は、２０１２年７月１４日に出願された米国仮特許出願第連続番号第６１／６７１，６９２号の利益を主張する。当該仮特許出願の開示はその全体がここに引用により援用される。

技術分野
ここに説明される主題は、ポリシー構成に関する。より特定的には、主題は、ポリシーベースのローカルブレークアウト（local breakout：ＬＢＯ）のための方法、システム、およびコンピュータ読取可能な媒体に関する。

背景
ローカルブレークアウト（ＬＢＯ）とは、ユーザーデータフローが、ホームネットワークを通るその通常の予期されるコールフローから分流され、代わりに別のネットワークを通ってルーティングされる手法である。たとえば、ＬＢＯが生じると、モバイル加入者用のデータサービスは、加入者のホームネットワークオペレータとビジネスおよび運営上の関係があるかもしれない、またはないかもしれないネットワーク（たとえば、モバイル加入者が外国を訪れた場合には、訪問先のモバイルネットワーク）によって取扱われる場合がある。

現在のネットワークオペレータは一般に、サービングゲートウェイ、スモールセル、および／または他の場所でＬＢＯが生じることを許可している。さまざまな規格が、ＬＢＯアーキテクチャおよび／またはプロシージャについて検討している。そのような１つの規格は３ＧＰＰＴＲ２３．８２９であり、その開示はその全体がここに引用により援用される。従来のＬＢＯプロシージャは一般に、本質的に静的であり、また、ＬＢＯがホームネットワーク、加入者、および／または他のエンティティにとって有益であり得るあるシナリオを許可していない。特に、従来のＬＢＯプロシージャは、セッションおよび／または加入者を意識したものではない場合がある。

従って、ポリシーベースのＬＢＯのための方法、システム、およびコンピュータ読取可能な媒体に対する要望が存在する。

概要
一局面によれば、ここに説明される主題は、ポリシーインフラストラクチャを使用してローカルブレークアウトを制御するためのシステムを含む。このシステムは、加入者に関連付けられた承認要求を進化型ノードＢ（ｅＮｏｄｅＢ）から受信するとともに、承認要求に応答して、加入者固有ポリシーをｅＮｏｄｅＢにインストールして、加入者のためにｅＮｏｄｅＢでローカルブレークアウトを実現するように構成された、ポリシーおよび課金ルール機能（policy and charging rules function：ＰＣＲＦ）を含む。

ポリシーインフラストラクチャを使用してローカルブレークアウトを制御するための方法も、開示されている。この方法は、ポリシーおよび課金ルール機能（ＰＣＲＦ）で起こる。この方法は、加入者に関連付けられた承認要求を進化型ノードＢ（ｅＮｏｄｅＢ）から受信するステップと、承認要求に応答して、加入者固有ポリシーをｅＮｏｄｅＢにインストールして、加入者のためにｅＮｏｄｅＢでローカルブレークアウトを実現するステップとを含む。

ポリシーインフラストラクチャを使用してローカルブレークアウトを実現するためのシステムも、開示されている。このシステムは進化型ノードＢ（ｅＮｏｄｅＢ）を含み、ｅＮｏｄｅＢは、加入者に関連付けられた承認要求をポリシーおよび課金ルール機能（ＰＣＲＦ）に送信するとともに、加入者のためにｅＮｏｄｅＢでローカルブレークアウトを実現するための加入者固有ポリシーを、ＰＣＲＦから受信するように構成されている。

ポリシーインフラストラクチャを使用してローカルブレークアウトを実現するための方法も、開示されている。この方法は、進化型ノードＢ（ｅＮｏｄｅＢ）で起こる。この方法は、加入者に関連付けられた承認要求を進化型ノードＢ（ｅＮｏｄｅＢ）から受信するステップと、加入者のためにｅＮｏｄｅＢでローカルブレークアウトを実現するための加入者固有ポリシーを、ＰＣＲＦから受信するように構成されている。

ポリシーベースのＬＢＯのためにここに説明される主題（たとえば、ＬＢＯを実現するかまたは制御すること）は、コンピュータのプロセッサによって実行されるとステップを行なうようにプロセッサを制御する実行可能な命令が格納された非一時的なコンピュータ読取可能な媒体を使用して、実現されてもよい。ここに説明される主題を実現するのに好適な、例示的な非一時的なコンピュータ読取可能な媒体は、プロセッサ、プログラマブルロジックデバイス、および特定用途向け集積回路によってアクセス可能な、チップメモリデバイスまたはディスクメモリデバイスを含む。

ここで使用されるように、「ノード」という用語は、１つ以上のプロセッサおよびメモリを含む物理的コンピューティングプラットフォームを指す。

ここで使用されるように、「機能」または「モジュール」という用語は、ここに説明される特徴を実現するためにハードウェアおよび／またはファームウェアと組合されたソフトウェアを指す。

図面の簡単な説明
ここに説明される主題を、添付図面を参照して以下に説明する。

ここに説明される主題の一実施形態に従ったポリシーベースのＬＢＯのための例示的なネットワークを示すネットワーク図である。ここに説明される主題の一実施形態に従ったポリシーベースのＬＢＯのための例示的なポリシーノードを説明するブロック図である。ここに説明される主題の別の実施形態に従ったポリシーベースのＬＢＯを説明するメッセージフロー図である。ここに説明される主題の一実施形態に従った、ポリシーインフラストラクチャを使用してローカルブレークアウトを制御するための例示的なプロセスを説明するフローチャートである。ここに説明される主題の一実施形態に従った、ポリシーインフラストラクチャを使用してローカルブレークアウトを実現するための例示的なプロセスを説明するフローチャートである。

詳細な説明
ここに説明される主題は、ポリシーベースのローカルブレークアウト（ＬＢＯ）のための方法、システム、およびコンピュータ読取可能な媒体を含む。従来のＬＢＯアーキテクチャは、サービングゲートウェイ（serving gateway：ＳＧＷ）、スモールセル、および他の場所でＬＢＯを提供する。しかしながら、これらのアーキテクチャのどれも、ローカルブレークアウトがポリシーインフラストラクチャ、たとえばポリシーおよび課金ルール機能（ＰＣＲＦ）によって管理される動的なローカルブレークアウトシナリオを提供しない。また、従来のＬＢＯアーキテクチャは、ユーザーデータフローが短期間の間オペレータのコアを通過することを適切な課金および／または会計モデルが必要とするオフロードシナリオに対処していない。

この主題のいくつかの局面によれば、ＬＢＯは、進化型ノードＢ（evolved node B：ｅＮＢ）といった無線アクセスネットワーク（radio access network：ＲＡＮ）コンポーネントまたはノードで提供されてもよく、ＰＣＲＦまたはポリシーサーバといったポリシーインフラストラクチャによって制御されてもよい。ポリシーベースのＬＢＯを利用することにより、ネットワークオペレータは、加入者の経験品質（quality of experience：ＱｏＥ）およびさまざまなネットワーク状態を認識しつつ、ネットワークを動的に最適化することができる。たとえば、ポリシーベースのＬＢＯを使用して、オペレータのネットワークがオーバーロードされつつあることにＰＣＲＦまたはポリシーコントローラが気づくようになると、それは、いくつかのサービスプロバイダとの予め確立されたピアリング協定を利用して、ネットワークトラフィックをオフロードし、１つのピアを通って他のピアにわたるトラフィックのフローを管理してもよい。また、ＲＡＮコンポーネントで動的なＬＢＯを提供することにより、媒体経路におけるノードの総数が（たとえばＳＧＷでの従来のＬＢＯと比較して）最小化される場合があり、このため、オペレータのために媒体転送処理を最適化し、コスト（たとえば１ビット当たりのコスト）を下げる。

ここで、添付図面に例が示された、ここに説明される主題の例示的な実施形態を、詳細に参照する。同じまたは同様の部分を指すために、可能な場合は必ず、同じ参照番号を図面全体にわたって使用する。

図１は、ここに説明される主題の一実施形態に従ったポリシーベースのＬＢＯのための例示的なネットワークを示すネットワーク図である。図１は、ここに説明される主題の一実施形態に従った例示的な通信ネットワーク１００を説明するブロック図である。図１を参照して、ネットワーク１００は、ユーザ端末（user equipment：ＵＥ）１０２と、アクセスノードまたは進化型ノードＢ（ｅＮＢ）１１０４と、ポリシーおよび課金実施機能（policy and charging enforcement function：ＰＣＥＦ）またはパケットデータネットワークゲートウェイ（packet data network gateway：ＰＧＷ）１０８と、ポリシーコントローラまたはＰＣＲＦ１１０と、加入者プロファイルリポジトリ（subscriber profile repository：ＳＰＲ）１１２と、アクセスノードまたはｅＮＢ２１１６と、ビジターネットワーク１１８と、ローカルＰＧＷ１２０と、コアネットワーク１０６と、インターネット１１４とを含んでいてもよい。

ＵＥ１０２は、ネットワーク１００の１つ以上の部分と通信するための、携帯電話機などのデバイスを表わす。たとえば、ＵＥ１０２は、コンピュータ、ポケットベル、スマートフォン、電話、無線モデム、ホットスポット、コンピューティングプラットフォーム、携帯電話機、および他の加入者デバイスを含んでいてもよい。

ＵＥ１０２は、ｅＮＢ１１０４および／またはｅＮＢ２１１６と通信してもよい。ｅＮＢ１１０４および／またはｅＮＢ２１１６は、同じアクセスネットワーク内に位置していてもよく、または異なるアクセスネットワーク内に位置していてもよい。アクセスネットワークは、１つ以上のネットワーク（たとえばコアネットワーク１０６）におけるサービス、機能、またはデバイスへのアクセスをＵＥ１０２に提供するためのノード、機能、デバイス、および／またはコンポーネントを含んでいてもよい。たとえば、アクセスネットワークは、ユニバーサル・モバイル・テレコミュニケーション・システム（universal mobile telecommunications system：ＵＭＴＳ）ＲＡＮ（ＵＴＲＡＮ）、進化型ＵＴＲＡＮ（ｅＵＴＲＡＮ）、高速パケットアクセス（High Speed Packet Access：ＨＳＰＡ）ネットワーク、または進化型ＨＳＰＡ（ｅＨＳＰＡ＋）ネットワークといった無線アクセスネットワーク（ＲＡＮ）を含んでいてもよい。

ｅＮＢ１１０４および／またはｅＮＢ２１１６は、ＵＥ１０２をさまざまな通信ネットワークおよび／またはノードに接続するための無線アクセス機能を行なってもよい。ｅＮＢ１１０４および／またはｅＮＢ２１１６は、ゲートウェイ機能性を使用してコアネットワーク１０６と通信してもよい。たとえば、ｅＮＢ２１１６または他のノード（たとえばゲートウェイ）は、メッセージ（たとえば、認証またはモビリティに関するメッセージ）を、コアネットワーク１０６内の１つ以上のノードに通信してもよい。

いくつかの実施形態では、ｅＮＢ１１０４および／またはｅＮＢ２１１６は、所与の加入者またはサービスデータフローのためにＬＢＯを行なうべきかどうかを判断するために、ＰＣＲＦ１１０と通信してもよい。たとえば、加入者がアクセスネットワークの使用を試みている場合、ｅＮＢ１１０４は承認要求をＰＣＲＦに送信してもよい。承認要求の受信に応答して、ＰＣＲＦ１１０は、ポリシーおよび課金制御（policy and charging control：ＰＣＣ）ルールまたはポリシーをｅＮＢ１０４に送信またはインストールすべきであると判断してもよい。ＰＣＣルールまたはポリシーは、ｅＮＢ１０４がＬＢＯを行なう（たとえば、サービスデータフロー（service data flow：ＳＤＦ）をコアネットワーク１０６を通してルーティングする代わりに、インターネット１１４に関わるデータサービスをビジターネットワーク１１８にオフロードする）ことを許可するかまたは却下するためのものであってもよい。いくつかの実施形態では、ＰＣＣルールまたはポリシーは、（たとえばローカルＰＧＷ１２０を介して）オフロードされ得る特定のサービスおよび／またはＳＤＦを示していてもよい。

いくつかの実施形態では、ｅＮＢ１１０４および／またはｅＮＢ２１１６は、ＰＣＥＦとして機能するように、またはＰＣＥＦのような機能を行なうように構成されてもよい。たとえば、ｅＮＢ１１０４および／またはｅＮＢ２１１６は、ＰＣＲＦ１１０と通信してもよく、ＰＣＣルールまたはポリシーを受信してもよい。ＰＣＣルールまたはポリシーを受信後、ｅＮＢ１１０４および／またはｅＮＢ２１１６は、ＰＣＣルールまたはポリシーを実施してもよい。

コアネットワーク１０６は、ＵＥ１０２にサービスを提供するためのネットワークであってもよい。たとえば、コアネットワーク１０６は、ＵＥ１０２のために、ネットワークアグリゲーション、課金および認証機能を行なってもよい。いくつかの実施形態では、コアネットワーク１０６は、４Ｇネットワーク、ＬＴＥネットワーク、ＥＰＣネットワーク、第３世代パートナーシッププロジェクト（3rd Generation Partnership Project：３ＧＰＰ）ネットワーク、または他のネットワークであってもよい。

コアネットワーク１０６は、ＰＧＷ１０８と、ＰＣＲＦ１１０とを含んでいてもよい。コアネットワーク１０６はまた、ＳＰＲ１１２、Ｄｉａｍｅｔｅｒリレーエージェントおよび／またはＤｉａｍｅｔｅｒシグナリングルータ（Diameter relay agent/Diameter signaling router：ＤＲＡ／ＤＳＲ）、モビリティ管理エンティティ（mobility management entity：ＭＭＥ）、ホーム加入者サーバ（home subscriber server：ＨＳＳ）、認証、認可および会計（authentication, authorization, and accounting：ＡＡＡ）サーバ、ならびに、ベアラ結合およびイベント報告機能（bearer binding and event reporting function：ＢＢＥＲＦ）といった他のノードを含んでいてもよい。

ＰＧＷ１０８は、インターネット１１４または他のデータネットワークへのアクセスを提供するためのあらゆる好適なエンティティであってもよい。ＰＧＷ１０８は、ネットワーク間、たとえばインターネット１１４とコアネットワーク１０６との間で通信するために、ゲートウェイ（たとえば、パケットデータネットワーク（packet data network：ＰＤＮ）ゲートウェイ）または他のノードに位置する機能性を含んでいてもよい。

いくつかの実施形態では、ＰＧＷ１０８は、ＰＣＥＦまたは同様の機能性を含んでいてもよい。たとえば、ＰＧＷ１０８は、ＰＣＲＦ１１０によって提供されたポリシーおよび課金制御（ＰＣＣ）ルールを管理および／または実施してもよい。たとえば、ルールは、ＰＧＷ１０８の使用を試みている各ＳＤＦおよび／または各ＵＥ１０２について提供されてもよい。この例では、ＰＧＷ１０８は、ＰＣＲＦ１１０から受信したルールに基づいて、外部ネットワークへのアクセスを制御し、そのようなアクセスについて課金してもよい。

いくつかの実施形態では、ＰＧＷ１０８は、ＧＰＲＳネットワークと外部ネットワーク、たとえばインターネット１２６またはプライベートネットワーク１２８との間で通信するために、ゲートウェイＧＰＲＳサポートノード（gateway GPRS support node：ＧＧＳＮ）を含むかまたはそれと統合されていてもよい。たとえば、コアネットワーク１０６がＧＰＲＳコアネットワークを含む一実施形態では、ＰＧＷ１０８はＧＧＳＮを含んでいてもよい。ＰＧＷ１０８は、ＵＥ１０２にサービスを提供するために、サービングＧＰＲＳサポートノード（serving GPRS support node：ＳＧＳＮ）または他のゲートウェイと通信してもよい。たとえば、ＰＧＷ１０８は、ＰＣＲＦ１１０からＰＣＣルールを要求し、受信してもよい。ＰＣＣルールを使用して、ＰＧＷ１０８は、ＰＣＣルールに基づいて外部ネットワークへのアクセスを制御し、そのようなアクセスについて課金してもよい。

たとえば、ポリシー制御下にあるＳＤＦ（たとえば、１つ以上の関連するパケット）については、（たとえば、１つ以上の関連するＰＣＣルールによって定められるように）対応するゲートが開いている場合、ＰＧＷ１０８は、そのＳＤＦがノードを通過することを許可してもよい。課金制御下にあるＳＤＦについては、対応するアクティブなＰＣＣルールがあり、かつ、オンライン課金のためにＯＣＳがその課金キーを用いて適用可能なクレジットを認可した場合、ＰＧＷ１０８は、そのＳＤＦがノードを通過することを許可してもよい。クレジット再認可プロシージャの過程において、ＰＧＷ１０８はＳＤＦにゲートウェイを通過させてもよい。ＰＣＲＦ１１０によって要求された場合、ＰＧＷ１０８は、関連するＳＤＦのステータスが変化するとＰＣＲＦ１１０に報告してもよく、それは、ＡＦシグナリングトラフィック専用のベアラ経路をモニタリングするために使用可能である。

ＰＧＷ１０８も、ＢＢＥＲＦを含んでいてもよい。ＢＢＥＲＦは、ベアラ結合および／またはイベント報告を行なうためのあらゆる好適なエンティティであってもよい。いくつかの実施形態では、ＢＢＥＲＦは、ユーザプレーントラフィックを制御してもよい。たとえば、ＢＢＥＲＦは、ＳＤＦが適切なサービス品質でベアラ経路上を搬送されることを確実にしてもよく、リソース予約を行なってもよい。ＢＢＥＲＦはまた、ネットワーク１００における１つ以上のノードにイベント報告を提供してもよい。たとえば、ＢＢＥＲＦは、たとえばＰＣＲＦ１１０によってインストールまたは要求されたイベントトリガーに基づいて、さまざまなネットワークまたはベアラに関連するイベントをＰＣＲＦ１１０に通知してもよい。

ＰＣＲＦ１１０は、ポリシー（たとえば、１つ以上のＰＣＣルール）を作成し、選択し、または他の態様で決定するためのあらゆる好適なエンティティであってもよい。たとえば、ＰＣＲＦ１１０は、スタンドアロンノード、たとえばポリシーサーバまたはマルチメディアポリシーエンジン（multimedia policy engine：ＭＰＥ）であってもよく、もしくは、ネットワーク１００における１つ以上のノード、たとえばＤＲＡ／ＤＳＲと同じ場所に位置するかまたはそれと統合されていてもよい。ＰＣＲＦ１１０は、ポリシー決定に従って、ＰＣＣ制御下にある各ＳＤＦの処理について、ＰＣＣルールの使用を通してＰＧＷ１０８に通知してもよい。ポリシー決定を行なう際、ＰＣＲＦ１１０は、加入関連情報を集めるために、ネットワーク１００における１つ以上のノードと通信してもよい。たとえば、ＰＣＲＦ１１０は、ポリシー情報を検索するために、ＳＰＲ１１２と通信してもよい。別の例では、ＰＣＲＦ１１０は、たとえばシンプルネットワーク管理プロトコル（simple network management protocol：ＳＮＭＰ）インターフェイスを介して、ネットワーク管理システム（network management system：ＮＭＳ）と通信してもよい。この例では、ＰＣＲＦ１１０は、たとえばアクセスネットワーク、コアネットワーク、または他のネットワークにおける１つ以上のデバイスの状態に関する情報を受信するために、ＮＭＳまたは関連するデータベースにポーリングし、もしくは他の態様で問合せてもよい。

加入関連情報は、ＰＣＣルールを生成するために（たとえばＰＣＲＦ１１０によって）使用されてもよい。ＰＣＣルールは典型的には、ユーザプレーントラフィック（たとえばデータパケット）を管理するための情報を含む。たとえば、ＰＣＣルールは、ルール名、サービス識別子、ＳＤＦフィルター、順位情報、ゲートステータス、ＱｏＳパラメータ、課金キー（すなわち格付けグループ）、他の課金パラメータ、および／またはモニタリングキーを含んでいてもよい。ルール名またはＰＣＣルール識別子は、ＰＣＥＦとＰＣＲＦとの間の通信においてＰＣＣルールを参照するために使用されてもよく、ＩＰ−ＣＡＮセッション中に使用されるＰＣＣルールごとに一意的であってもよい。サービス識別子は、ＳＤＦが関連するサービスまたはサービスコンポーネントを識別するために使用されてもよい。ＳＤＦフィルターは、ルールがあてはまるトラフィックを選択するために使用されてもよい。たとえば、ＳＤＦフィルターは、（１）ソースＩＰアドレス、（２）宛先ＩＰアドレス、（３）ソースポート番号、（４）宛先ポート番号、および（５）アプリケーションプロトコル（たとえば、伝送制御プロトコル（transmission control protocol：ＴＣＰ）、ユーザデータグラムプロトコル（user datagram protocol：ＵＤＰ））を特定するＩＰ５タプルの形をとっていてもよい。この例では、ＩＰ５タプルに整合する情報を含むパケットは、対応するＰＣＣルールが適用されることになっているＳＤＦの一部であると考えられてもよい。別の例では、ＳＤＦフィルターは、より少ない、異なる、および／または追加の基準に基づいていてもよい。たとえば、ネットワーク１００におけるＵＥ１０２または別のノードは、カスタムパラメータフィールドにおけるパケットに、ＳＤＦ識別子（たとえば、値）を割当ててもよい。この場合、ＰＣＣルールにおけるＳＤＦフィルターは、ルールがあてはまるトラフィックを判断するために、このパラメータを使用してもよい。

ＰＣＣポリシー決定は、Ｒｘインターフェイスを介してＡＦから得られた情報（たとえば、セッション、媒体および加入者関連情報）、ＰＧＷ１０８から得られた情報（たとえば、ベアラ属性、要求タイプ、デバイス情報、および加入者関連情報）、ＳＰＲ情報（たとえば、加入者およびサービス関連データ）、ならびに事前構成された情報、のうちの１つ以上に基づいていてもよい。ＰＧＷ１０８からの情報が、ＰＣＲＦ１１０が知っているＳＤＦフィルターに整合しないトラフィックマッピング情報を含み、かつ、ＰＣＲＦ１１０が知らないサービスについてＵＥが向上したＱｏＳを要求することをＰＣＲＦ１１０が許可した場合、ＰＣＲＦ１１０は、トラフィックマッピング情報をＳＤＦフィルターとして、対応する認可されたＰＣＣルールに追加してもよい。ＰＣＲＦ１１０は、見つからないフィルターパラメータ、たとえばＧＰＲＳの場合、見つからないアップリンクＴＦＴアドレスおよびポート情報をワイルドカード検索してもよい。たとえば、ブランクまたは「ワイルドカード」フィルター（たとえば、ポート番号＝“^＊’）は、任意の値（空またはゼロの値を含む）を、フィルター基準に整合すると考えてもよい。

ＳＰＲ１１２は、加入プロファイル、ポリシー情報、および／またはＰＣＣルールといった加入関連情報を格納または保持するための好適なエンティティを表わしていてもよい。たとえば、ＳＰＲ１１２は、データベース、ＨＳＳ、ＡＡＡ、または他のノードを含んでいてもよい。ＳＰＲ１１２は、ポリシー決定を行なう際にＰＣＲＦ１１０が使用するためのポリシー情報を格納していてもよい。一実施形態では、加入プロファイルは、加入者、セッション、デバイス、および／またはＳＤＦに関連付けられた、認可情報、課金情報、加入情報（たとえば、アクセス層またはサービス層）、およびサービス品質（quality of service：ＱｏＳ）情報を含んでいてもよい。たとえば、加入プロファイルは、異なるタイプのＳＤＦについての、加入者の許可されたサービス、サービス占有優先度、許可されたＱｏＳについての情報、および課金関連データ情報を含んでいてもよい。

ＳＰＲ１１２は、ＰＣＲＦ１１０、およびさまざまな他のノード、たとえばＨＳＳ、ＡＡＡ、ＭＭＥ、およびまたはＤＲＡ／ＤＳＲと通信してもよい。ＳＰＲ１１２は、ＰＣＲＦ１１０の外部に、またはＰＣＲＦ１１０とは異なる場所に位置していてもよく、もしくは、ＰＣＲＦ１１０と同じ場所に位置するかまたはそれと統合されていてもよい。

ビジターネットワーク１１８は、コアネットワーク１０６とは異なる、ＵＥ１０２にサービスを提供するためのネットワークであってもよい。たとえば、ビジターネットワーク１１８は、コアネットワーク１０６からは外国に位置するセルラーまたはモバイルネットワークであってもよい。いくつかの実施形態では、ビジターネットワーク１１８は、ｅＮＢ１１０４またはｅＮＢ２１１６に関連付けられていてもよく、もしくは、ｅＮＢ１１０４またはｅＮＢ２１１６を含んでいてもよい。いくつかの実施形態では、ビジターネットワーク１１８は、４Ｇネットワーク、ＬＴＥネットワーク、ＥＰＣネットワーク、３ＧＰＰネットワーク、または他のネットワークであってもよい。

いくつかの実施形態では、ビジターネットワーク１１８は、コアネットワーク１０６に関連付けられた加入者にアクセスおよびサービスを提供するためのサービス契約を有していてもよい。いくつかの実施形態では、ビジターネットワーク１１８は、コアネットワーク１０６とのサービス契約を有していなくてもよく、および／または、動的ベースまたはプリペイドベースで加入者らをローミングするためのサービスを行なってもよい。

ビジターネットワーク１１８は、ローカルＰＧＷ１２０を含んでいてもよい。ビジターネットワーク１１８はまた、ＭＭＥまたはＡＡＡサーバといった他のノードを含んでいてもよい。ローカルＰＧＷ１２０は、インターネット１１４または他のデータネットワークへのアクセスを提供するためのあらゆる好適なエンティティであってもよい。ローカルＰＧＷ１２０は、ネットワーク間、たとえばインターネット１１４とビジターネットワーク１１８との間で通信するための機能性を含んでいてもよい。

いくつかの実施形態では、ローカルＰＧＷ１２０は、ＰＣＥＦまたは同様の機能性を含んでいてもよい。たとえば、ローカルＰＧＷ１２０は、ＰＣＲＦ１１０によって提供されたポリシーおよび課金制御（ＰＣＣ）ルールを管理および／または実施してもよい。たとえば、ルールは、ローカルＰＧＷ１２０の使用を試みている各ＳＤＦおよび／または各ＵＥ１０２ごとに提供されてもよい。この例では、ローカルＰＧＷ１２０は、ＰＣＲＦ１１０から受信したルールに基づいて、外部ネットワークへのアクセスを制御し、そのようなアクセスについて課金してもよい。

図１は例示を目的としていること、ならびに、さまざまなノード、それらの場所、および／またはそれらの機能は、変更、修正、追加、または除去されてもよいことが、理解されるであろう。たとえば、いくつかのノードおよび／または機能が単一のエンティティへと組合わされてもよく、たとえば、ＳＰＲ１１２およびＰＣＲＦ１１０がＭＰＥに含まれていてもよい。第２の例では、１つのノードおよび／または機能が、２つ以上のノードに位置し、もしくは、２つ以上のノードによって実現されてもよい。

図２は、ここに説明される主題の一実施形態に従ったポリシーベースのＬＢＯのための例示的なノード２００を説明するブロック図である。ノード２００は、ＬＢＯを制御または判断するように構成されてもよく、たとえばポリシーノードであってもよく、もしくは、ＬＢＯを実現するように構成されてもよく、たとえば、ｅＮＢ１１０４またはｅＮＢ２１１６のようなＲＡＮノードであってもよい。ノード２００は、スタンドアロンノードであってもよく、もしくは、追加の機能性または別のノードと統合されていてもよい。いくつかの実施形態では、ノード２００は、ＰＣＲＦ、ｅＮＢ、または同様の機能性を含んでいてもよい。

図２を参照して、ノード２００は、（たとえば、Ｇｘインターフェイス、Ｇｘｘインターフェイス、Ｓ１インターフェイス、Ｓ７インターフェイス、Ｓｐインターフェイス、拡張可能マークアップ言語（extensible markup language：ＸＭＬ）インターフェイス、セッション初期化プロトコル（session initiation protocol：ＳＩＰ）インターフェイス、ＳＯＡＰインターフェイス、またはハイパーテキスト転送プロトコル（hypertext transfer protocol：ＨＴＴＰ）インターフェイスなどを介して）メッセージを通信するための１つ以上の通信インターフェイス２０２を含んでいてもよい。いくつかの実施形態では、ポリシー情報（たとえばＰＣＣルール）を要求するために、クレジット制御要求（credit control request：ＣＣＲ）または承認要求が、ＧｘインターフェイスまたはＳ１インターフェイスを介して送受信されてもよい。いくつかの実施形態では、メッセージを通信し、ＬＢＯを制御するかまたは実現し、および／または他の機能を行なうために、他のインターフェイスが使用されてもよい。

ノード２００は、ＬＢＯモジュール２０４を含んでいてもよい。ＬＢＯモジュール２０４は、ＬＢＯを制御および／または実現するといった、ここに説明される主題の１つ以上の局面を行なうためのあらゆる好適なエンティティ（たとえば、プロセッサ上で実行されるソフトウェア）であってもよい。ノード２００の場所または使い方に依存して、ＬＢＯモジュール２０４は、ある加入者のためにＲＡＮノードでＬＢＯが実現されるべきかどうか判断するように構成されてもよく、もしくは、ポリシーを実施するように、および／または、ＬＢＯを実現するかまたは実現しないように構成されてもよい。

ノード２００がＰＣＲＦ１１０またはＰＣＲＦ機能性を含むいくつかの実施形態では、ＬＢＯモジュール２０４は、ＲＡＮノードでＬＢＯが実現されるべきかどうか判断するための機能性を含んでいてもよい。たとえば、ＬＢＯモジュール２０４は、ｅＮＢ１１０４またはｅＮＢ２１１６から承認要求または他のメッセージを受信するための機能性を含んでいてもよい。ＬＢＯモジュール２０４は、ＳＰＲ１１２および／または他のソースに問合せるための機能性を含んでいてもよい。集められた情報を使用して、ＬＢＯモジュール２０４は、加入者のためにＲＡＮでＬＢＯを許可するかまたは却下する（許可しない）ようにｅＮＢ１１０４またはｅＮＢ２１１６に命令するためのポリシー（たとえば、１つ以上のＰＣＣルール）を生成してもよい。ＬＢＯモジュール２０４は、ｅＮＢ１１０４またはｅＮＢ２１１６にポリシーを提供するための機能性を含んでいてもよい。

ノード２００がＲＡＮノードを含むいくつかの実施形態では、ＬＢＯモジュール２０４は、ＰＣＲＦ１１０からのポリシーを実施するための、および／または、受信したポリシーに基づいてＬＢＯを実現するかまたは実現しないための機能性を含んでいてもよい。たとえば、ＬＢＯモジュール２０４は、ＰＣＲＦ１１０と通信し、ＰＣＲＦ１１０からポリシー（たとえば、１つ以上のＰＣＣルール）を受信し、および、ノード２００でＬＢＯを実現するかまたは実現しないことによってポリシーを実施するための機能性を含んでいてもよい。

ポリシーノード２００は、データストレージ２０６にアクセスしてもよい（情報を読出し、および／または書込んでもよい）。データストレージ２０６は、さまざまなデータを格納するためのあらゆる好適なエンティティ（たとえば、コンピュータ読取可能な媒体またはメモリ）であってもよい。ノード２００がＰＣＲＦ１１０またはＰＣＲＦ機能性を含むいくつかの実施形態では、データストレージ２０６は、１人以上の加入者に関連付けられたＰＣＣルールおよび／またはポリシーを含んでいてもよい。データストレージ２０６は、ＲＡＮノードで、またはＲＡＮノード上でＬＢＯが実現されるべきかどうか判断するための情報を含んでいてもよい。そのような判断において使用可能な例示的な情報は、ネットワーク状態、加入者層、デバイスタイプ、場所、時刻、ＱｏＳ要件、ＱｏＥ要件、サービス契約、および／または他の情報を含んでいてもよい。

ノード２００がＲＡＮノードを含むいくつかの実施形態では、データストレージ２０６は、インストールされた実施用ポリシーと加入者らとの間の関連性を含んでいてもよい。たとえば、データストレージ２０６は、第１の加入者がＬＢＯプロシージャを使用しないかもしれないことを示すポリシーと、第２の加入者がＬＢＯプロシージャを使用するかもしれないことを示す第２のポリシーとを含んでいてもよい。これらの関連性を使用して、ノード２００は、どのＳＤＦまたは加入者がＬＢＯプロシージャを使用するかもしれないか、または使用しないかもしれないかを判断してもよい。

上述の説明は例示を目的としていること、ならびに、ノード２００は追加のおよび／または異なるモジュールまたはコンポーネントを含んでいてもよいことが、理解されるであろう。

図３は、ここに説明される主題の一実施形態に従ったポリシーベースのＬＢＯを説明するメッセージフロー図である。ステップ３００で、データフロー要求（たとえば、承認要求、モビリティ管理メッセージ、または他のメッセージ）が、ＵＥ１０２からｅＮＢ１１０４に送信されてもよい。データフロー要求は、加入者「１」に関連付けられてもよい。ステップ３０２で、加入者「１」についてのポリシー要求が、ＰＣＲＦ１１０に送信されてもよい。ポリシー要求は、ＬＢＯがｅＮＢ１１０４で加入者にとって利用可能かどうかに関するポリシーを要求するために送信されてもよい。ステップ３０４で、ＰＣＲＦ１１０は、ＳＰＲ１１２から加入者プロファイルまたは関連情報を要求し、受信してもよい。集められた情報を使用して、ＰＣＲＦ１１０は、加入者「１」のためにＬＢＯを許可するようにｅＮＢ１１０４に命令するポリシーを生成してもよい。たとえば、ＰＣＲＦ１１０は、コアネットワーク１０６が混雑しており、および、ビジターネットワーク１１８が信頼できると判断するかもしれない。ステップ３０６で、ポリシーが、ｅＮＢ１１０４によってインストールされ、実施されてもよい。ステップ３０８で、ｅＮＢ１１０４は、ＬＢＯを実現または実行し、ビジターネットワーク１１８におけるローカルＰＧＷ１２０を介してデータフロー要求または他のメッセージをルーティングしてもよい。

ステップ３１０で、データフロー要求が、ＵＥ１０２からｅＮＢ１１０４に送信されてもよい。データフロー要求は、加入者「２」に関連付けられてもよい。ステップ３１２で、加入者「２」についてのポリシー要求が、ＰＣＲＦ１１０に送信されてもよい。ポリシー要求は、ＬＢＯがｅＮＢ１１０４で加入者にとって利用可能かどうかに関するポリシーを要求するために送信されてもよい。たとえば、ＰＣＲＦ１１０は、コアネットワーク１０６が混雑しておらず、および／または、ビジターネットワーク１１８が信頼できないかまたは安全でないと判断するかもしれない。ステップ３１４で、ＰＣＲＦ１１０は、ＳＰＲ１１２から加入者プロファイルまたは関連情報を要求し、受信してもよい。集められた情報を使用して、ＰＣＲＦ１１０は、加入者「２」のためにＬＢＯを許可しないようにｅＮＢ１１０４に命令するポリシーを生成してもよい。ステップ３１６で、ポリシーが、ｅＮＢ１１０４によってインストールされ、実施されてもよい。ステップ３１８で、ｅＮＢ１１０４は、コアネットワーク１０６におけるＰＧＷ１０８を介してデータフロー要求または他のメッセージをルーティングしてもよい。

ステップ３２０で、データフロー要求（たとえば、承認要求または他のメッセージ）が、ＵＥ１０２からｅＮＢ２１１６に送信されてもよい。データフロー要求は、加入者「３」に関連付けられてもよい。ステップ３２２で、加入者「３」についてのポリシー要求が、ＰＣＲＦ１１０に送信されてもよい。ポリシー要求は、ＬＢＯがｅＮＢ２１１６で加入者にとって利用可能かどうかに関するポリシーを要求するために送信されてもよい。ステップ３２４で、ＰＣＲＦ１１０は、ＳＰＲ１１２から加入者プロファイルまたは関連情報を要求し、受信してもよい。集められた情報を使用して、ＰＣＲＦ１１０は、加入者「３」のためにＬＢＯを許可するようにｅＮＢ２１１６に命令するポリシーを生成してもよい。たとえば、ＰＣＲＦ１１０は、加入者「３」が優先される加入者層に関連付けられ、および／または優先されるデバイスを使用していると判断するかもしれない。この例では、ビジターネットワーク１１８は安全で混雑しておらず、一方、コアネットワーク１０６は混雑しているため、ＬＢＯは許可されてもよい。ステップ３２６で、ポリシーが、ｅＮＢ２１１６によってインストールされ、実施されてもよい。ステップ３２８で、ｅＮＢ２１１６は、ＬＢＯを実現または実行し、ビジターネットワーク１１８におけるローカルＰＧＷ１２０を介してデータフロー要求または他のメッセージをルーティングしてもよい。

ステップ３３０で、データフロー要求が、ＵＥ１０２からｅＮＢ２１１６に送信されてもよい。データフロー要求は、加入者「４」に関連付けられてもよい。ステップ３３２で、加入者「４」についてのポリシー要求が、ＰＣＲＦ１１０に送信されてもよい。ポリシー要求は、ＬＢＯがｅＮＢ２１１６で加入者にとって利用可能かどうかに関するポリシーを要求するために送信されてもよい。たとえば、ＰＣＲＦ１１０は、コアネットワーク１０６が混雑しておらず、しかしながら、ビジターネットワーク１１８が信頼できないかまたは安全でないと判断するかもしれない。ステップ３３４で、ＰＣＲＦ１１０は、ＳＰＲ１１２から加入者プロファイルまたは関連情報を要求し、受信してもよい。集められた情報を使用して、ＰＣＲＦ１１０は、加入者「４」のためにＬＢＯを許可しないようにｅＮＢ２１１６に命令するポリシーを生成してもよい。ステップ３３６で、ポリシーが、ｅＮＢ２１１６によってインストールされ、実施されてもよい。ステップ３３８で、ｅＮＢ２１１６は、コアネットワーク１０６におけるＰＧＷ１０８を介してデータフロー要求または他のメッセージをルーティングしてもよい。

図３は例示を目的としていること、ならびに、さまざまなネットワークまたは環境においてポリシーインフラストラクチャを使用してＬＢＯを制御または実現する際に、追加のおよび／または異なるメッセージが使用されてもよいことが、理解されるであろう。

図４は、ここに説明される主題の一実施形態に従った、ポリシーインフラストラクチャを使用してローカルブレークアウトを制御するための例示的なプロセスを説明するフローチャートである。いくつかの実施形態では、ここに説明される例示的なプロセス、またはその一部は、ノード２００、ＰＣＲＦ１１０、ＬＢＯモジュール２０４、および／または、別のノードまたはモジュールによって行なわれてもよい。いくつかの実施形態では、例示的なプロセスは、ステップ４００、４０２、および／または、追加のまたは異なるステップを含んでいてもよい。

図４を参照して、ステップ４００で、加入者に関連付けられた承認要求が、ｅＮＢ１１０４またはｅＮＢ２１１６から受信されてもよい。たとえば、承認要求は、加入者がｅＮＢ１１０４またはその関連付けられたアクセスネットワークを初めて使用しようと試みた場合に送信されるメッセージであってもよい。別の例では、承認要求は、インターネット１１４に関連付けられた新しいＳＤＦを開始するための別のメッセージであってもよい。承認情報は、加入者識別子、サービスタイプ識別子、および／または他の情報を含んでいてもよい。

ＰＣＲＦ１１０、ノード２００、またはＬＢＯモジュール２０４は、承認要求を受信してもよく、また、ＳＰＲ１１２に問合せしてもよい。承認要求から集められた情報を使用して、ＳＰＲ１１２、および／または他のソース、ＰＣＲＦ１１０、ポリシーノード２００、またはＬＢＯモジュール２０４は、加入者のためにＲＡＮでＬＢＯを許可するかまたは却下する（許可しない）ようにｅＮＢ１１０４またはｅＮＢ２１１６に命令するためのポリシー（たとえば、１つ以上のＰＣＣルール）を生成してもよい。

ステップ４０２で、承認要求に応答して、加入者のためにｅＮＢ１１０４またはｅＮＢ２１１６でローカルブレークアウトを実現するために、加入者固有のポリシーが、ｅＮＢ１１０４またはｅＮＢ２１１６にインストールされてもよい。たとえば、ＰＣＲＦ１１０は、第１の加入者のためにｅＮＢ１１０４またはｅＮＢ２１１６でＬＢＯを実現し、かつ第１の加入者に関連付けられたＳＤＦがビジターネットワーク１１８および／またはローカルＰＧＷ１２０を通してインターネット１１４にルーティングされることを許可するポリシーを、インストールしてもよい。別の例では、ＰＣＲＦ１１０は、第２の加入者のためにｅＮＢ１１０４またはｅＮＢ２１１６でＬＢＯを防止するポリシーをインストールしてもよく、代わりに、第２の加入者に関連付けられたＳＤＦがコアネットワーク１０６および／またはＰＧＷ１０８を通してインターネット１１４にルーティングされることを必要としてもよい。

いくつかの実施形態では、ＰＣＲＦ１１０は、加入者層に基づくローカルブレークアウトを実現するために、加入者固有ポリシーをｅＮｏｄｅＢにインストールするように構成されてもよい。たとえば、ネットワークオペレータは、データプラン、電話のタイプ、消費性向などに基づいて、加入者らを複数のサービス層またはレベルへとグループ化してもよい。この例では、ある加入者層（たとえば、より高額を支払っている加入者ら）は、データサービスまたはＩＰトラフィックに関して優遇措置を受けてもよく、一方、優先度がより低い他の層は、信頼性がより低いネットワークにオフロードされてもよい。別の例では、ある加入者層（たとえば、より高額を支払っている加入者ら）は、自分たちのデータサービスまたはＩＰトラフィックを、より信頼性が高く、より混雑していないネットワークにオフロードさせることによって、優遇措置を受けてもよい。

いくつかの実施形態では、ＰＣＲＦ１１０は、デバイスタイプに基づくローカルブレークアウトを実現するために、加入者固有ポリシーをｅＮｏｄｅＢにインストールするように構成されてもよい。たとえば、優先される電話（たとえば、ある特定のタイプまたはブランドのスマートフォン）を使用する、ある加入者らは、データサービスを受信するために、（たとえばコアネットワーク１０６を介して）優先されるルートを受信してもよい。

いくつかの実施形態では、ＰＣＲＦ１１０は、ＵＥまたはＵＥアプリケーションによって要求されたサービス品質（ＱｏＳ）またはＱｏＥに基づくローカルブレークアウトを実現するために、加入者固有ポリシーをｅＮｏｄｅＢにインストールするように構成されてもよい。たとえば、映像またはボイス・オーバーＩＰ（ＶｏＩＰ）サービスを要求している、あるＵＥまたはアプリケーションは、（たとえばコアネットワーク１０６を介して）優先されるルートを受信してもよく、もしくは、より信頼性が高く、より混雑していないビジターネットワーク１１８にオフロードされてもよい。

図５は、ここに説明される主題の一実施形態に従った、ポリシーインフラストラクチャを使用してローカルブレークアウトを実現するための例示的なプロセスを説明するフローチャートである。いくつかの実施形態では、ここに説明される例示的なプロセス、またはその一部は、ｅＮＢ１１０４、ｅＮＢ２１１６、および／または、別のノードまたはモジュール（たとえば、ＲＡＮにおける別のアクセスノード）によって行なわれてもよい。いくつかの実施形態では、例示的なプロセスは、ステップ５００、５０２、および／または、追加のまたは異なるステップを含んでいてもよい。

図５を参照して、ステップ５００で、加入者に関連付けられた承認要求が、ｅＮＢ１１０４またはｅＮＢ２１１６に送信されてもよい。たとえば、承認要求は、加入者がｅＮＢ１１０４またはその関連付けられたアクセスネットワークを初めて使用しようと試みた場合に送信されるメッセージであってもよい。別の例では、承認要求は、インターネット１１４に関連付けられた新しいＳＤＦを開始するための別のメッセージであってもよい。承認情報は、加入者識別子、サービスタイプ識別子、および／または他の情報を含んでいてもよい。

ＰＣＲＦ１１０、もしくは別のノードまたはモジュールは、承認要求を受信してもよく、また、ＳＰＲ１１２に問合せしてもよい。承認要求から集められた情報を使用して、ＳＰＲ１１２、および／または他のソース、ＰＣＲＦ１１０、もしくは別のノードまたはモジュールは、加入者のためにＲＡＮでＬＢＯを許可するかまたは却下する（許可しない）ようにｅＮＢ１１０４またはｅＮＢ２１１６に命令するためのポリシー（たとえば、１つ以上のＰＣＣルール）を生成してもよい。

ステップ５０２で、加入者のためにローカルブレークアウトを実現するために、加入者固有のポリシーが、ｅＮＢ１１０４またはｅＮＢ２１１６によって受信されてもよい。たとえば、ＰＣＲＦ１１０は、第１の加入者のためにｅＮＢ１１０４またはｅＮＢ２１１６でＬＢＯを実現し、かつ第１の加入者に関連付けられたＳＤＦがビジターネットワーク１１８および／またはローカルＰＧＷ１２０を通してインターネット１１４にルーティングされることを許可するポリシーを、インストールしてもよい。別の例では、ＰＣＲＦ１１０は、第２の加入者のためにｅＮＢ１１０４またはｅＮＢ２１１６でＬＢＯを防止するポリシーをインストールしてもよく、代わりに、第２の加入者に関連付けられたＳＤＦがコアネットワーク１０６および／またはＰＧＷ１０８を通してインターネット１１４にルーティングされることを必要としてもよい。ノード２００がＲＡＮノードを含むさらに別の例では、ＬＢＯモジュール２０４がポリシーを受信し、ノード２００でＬＢＯを実現してもよい。

いくつかの実施形態では、ｅＮＢ１１０４またはｅＮＢ２１１６は、加入者層に基づくローカルブレークアウトを実現するように構成されてもよい。

いくつかの実施形態では、ｅＮＢ１１０４またはｅＮＢ２１１６は、デバイスタイプに基づくローカルブレークアウトを実現するように構成されてもよい。

いくつかの実施形態では、ｅＮＢ１１０４またはｅＮＢ２１１６は、ＰＣＥＦとして機能してもよい。

いくつかの実施形態では、ｅＮＢ１１０４またはｅＮＢ２１１６は、ＵＥまたはＵＥアプリケーションによって要求されたＱｏＳまたはＱｏＥに基づくローカルブレークアウトを実現するように構成されてもよい。

ここに説明される主題のさまざまな詳細は、ここに説明される主題の範囲から逸脱することなく変更されてもよい、ということが、理解されるであろう。さらに、ここに説明される主題は請求項によって定義されているため、前述の説明は、限定のためではなく例示のためのものに過ぎない。

Claims

ポリシーインフラストラクチャを使用してローカルブレークアウトを制御するためのシステムであって、前記ローカルブレークアウトは、コアネットワークを用いたルーティングをローカルネットワークを用いたルーティングに切り替えるものであり、
前記システムは、ポリシーおよび課金ルール機能（ＰＣＲＦ）を含み、
前記ＰＣＲＦは、複数の加入者の各々に関連付けられた承認要求を受信する進化型ノードＢ（ｅＮｏｄｅＢ）から、前記承認要求の各々に基づくポリシー要求を受信するように構成されており、前記ポリシー要求は、第１の加入者のための第１の承認要求に基づく第１のポリシー要求と、第２の加入者のための第２の承認要求に基づく第２のポリシー要求とを含み、
前記ＰＣＲＦは、前記第１の加入者のための第１の加入者固有ポリシーを前記ｅＮｏｄｅＢにインストールして、前記第１の加入者のためのローカルブレークアウトを前記ｅＮｏｄｅＢで実現し、前記第２の加入者のための第２の加入者固有ポリシーをインストールして、前記第２の加入者のための前記ｅＮｏｄｅＢにおけるローカルブレークアウトを禁止するように構成されており、
前記ＰＣＲＦは、
前記第１のポリシー要求の受信に応答して、前記第１の加入者固有ポリシーを生成し、前記第２のポリシー要求の受信に応答して、前記第２の加入者固有ポリシーを生成するように構成されており、
前記ＰＣＲＦは、さらに、各加入者のためのポリシーに従ったローカルブレークアウトルールを実現するために、生成した各ポリシーを前記ｅＮｏｄｅＢにインストールするように構成されており、
ローカルブレークアウトを許可する前記第１の加入者固有ポリシーを生成することは、前記第１の加入者が、優先される加入者層に関連付けられていること、または、優先されるデバイスを使用していることに基づいて、ローカルブレークアウトを許可する前記第１の加入者固有ポリシーを生成することを含む、システム。
ローカルブレークアウトを禁止する前記第２の加入者固有ポリシーを生成することは、前記コアネットワークが混雑しておらず、かつ、前記ローカルネットワークが信頼できないこと又は安全でないことに基づいて、前記ローカルブレークアウトを禁止するための前記第２の加入者固有ポリシーを生成することを含む、請求項１に記載のシステム。
前記ｅＮｏｄｅＢは、ポリシー制御および実施機能（ＰＣＥＦ）として機能する、請求項１または２に記載のシステム。
ポリシーインフラストラクチャを使用してローカルブレークアウトを制御するための方法であって、前記ローカルブレークアウトは、コアネットワークを用いたルーティングをローカルネットワークを用いたルーティングに切り替えるものであり、前記方法は、
ポリシーおよび課金ルール機能（ＰＣＲＦ）で、
複数の加入者の各々に関連付けられた承認要求を受信する進化型ノードＢ（ｅＮｏｄｅＢ）から、前記承認要求の各々に基づくポリシー要求を受信するステップを含み、前記ポリシー要求は、第１の加入者のための第１の承認要求に基づく第１のポリシー要求と、第２の加入者のための第２の承認要求に基づく第２のポリシー要求とを含み、
前記第１のポリシー要求の受信に応答して、第１の加入者固有ポリシーを生成するステップと、
前記第２のポリシー要求の受信に応答して、第２の加入者固有ポリシーを生成するステップと、
各加入者のためのポリシーに従ったローカルブレークアウトルールを実現するために、生成した各ポリシーを前記ｅＮｏｄｅＢにインストールするステップとを含み、
ローカルブレークアウトを許可する前記第１の加入者固有ポリシーを生成するステップは、前記第１の加入者が、優先される加入者層に関連付けられていること、または、優先されるデバイスを使用していることに基づいて、ローカルブレークアウトを許可する前記第１の加入者固有ポリシーを生成することを含む、方法。
ローカルブレークアウトを禁止する前記第２の加入者固有ポリシーを生成するステップは、前記コアネットワークが混雑しておらず、かつ、前記ローカルネットワークが信頼できないこと又は安全でないことに基づいて、ローカルブレークアウトを禁止する前記第２の加入者固有ポリシーを生成することを含む、請求項４に記載の方法。
前記ｅＮｏｄｅＢは、ポリシー制御および実施機能（ＰＣＥＦ）として機能する、請求項４または５に記載の方法。