JP2020502958A - マシンツーマシンネットワーク最適化およびオンライン課金 - Google Patents

Abstract

モバイル通信ネットワークの効率を向上させるシステムおよび方法が記載される。一実施形態では、ネットワークリソースを保存する方法は、１つ以上のネットワークノードにおいてユーザー端末（「ＵＥ」）セッションに関連するネットワークリソースを、ＵＥに通知せずに解放することを含む。ＵＥと接続するために使用することができるセッション情報のサブセットはネットワークノードに記憶される。ＵＥに対するデータが受信される場合に、１）以前に解放されたＵＥに関するネットワークリソースを確立するため、および２）データをＵＥに送達するために、記憶された情報のサブセットを用いることができる。別の実施形態では、共有データリソースは、指定ユーザーグル−プ（「ＤＵＧ」）と関連付けられた一人以上の加入者に許可される。オンライン課金セッションは、指定ユーザーグループに共有データリソースを許可するポリシーデータを識別するＤＵＧに割り当てられる。【選択図】図５

Description

関連出願の相互参照
本出願は、「ＭＡＣＨＩＮＥ−ＴＯ−ＭＡＣＨＩＮＥ ＮＥＴＷＯＲＫ ＯＰＴＩＭＩＺＡＴＩＯＮ ＡＮＤ ＯＮＬＩＮＥ ＣＨＡＲＧＩＮＧ」と題する、２０１６年１２月１３日に出願された米国仮特許出願第６２／４３３，４１２号に対する米国特許法１１９（ｅ）に基づく利益を主張し、その内容は、その全体が参照により本明細書に組み込まれる。

本発明は、概して遠距離通信システムに関し、具体的には「マシンツーマシン」（ｍａｃｈｉｎｅ ｔｏ ｍａｃｈｉｎｅ、Ｍ２Ｍ）および無線アクセスネットワーク（ｒａｄｉｏ ａｃｃｅｓｓ ｎｅｔｗｏｒｋ、ＲＡＮ）通信システムに関する。

マシンツーマシン（Ｍ２Ｍ）通信は、無線ネットワーク技術において急速に拡大している分野である。Ｍ２Ｍデバイスは、リアルタイムまたは非リアルタイム、低スループットまたは高スループット、およびモビリティ型または非モビリティ型とすることができる。Ｍ２Ｍデバイスの数は、２０２０年頃までに１０億デバイスに達すると予測されている。このような劇的な規模の増大があると、従来の加入者トラフィックモデルおよび請求／課金プランは実用性が高くはなさそうである。その上、ロングタームエボリューション（ｌｏｎｇ−ｔｅｒｍ ｅｖｏｌｕｔｉｏｎ、ＬＴＥ）ネットワークに接続されるＭ２Ｍデバイスの数は非常に多いが、運営者は各Ｍ２Ｍデバイスに対する収益を受け取らない。一部のＭ２Ｍデバイスは既存の第三世代パートナーシッププロジェクト（３^ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ、３ＧＰＰ）によって規定された課金に適合し得るが、すべてのタイプのＭ２Ｍデバイスが適応するわけではない。

運営者は、多くの場合、運営者の加入者総数に比例してＬＴＥ設備に投資する必要があるが、関連の収益発生は投資に比例しない。Ｍ２Ｍが出現したことで、運営者は、数が増加したモビリティ管理エンティティ（ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｅｎｔｉｔｉｅｓ、ＭＭＥ）、サービングゲートウェイ（ｓｅｒｖｉｎｇ ｇａｔｅｗａｙ、ＳＧＷ）、パケットゲートウェイ（ｐａｃｋｅｔ ｇａｔｅｗａｙ、ＰＧＷ）、ポリシーおよび課金ルール機能（ｐｏｌｉｃｙ ａｎｄ ｃｈａｒｇｉｎｇ ｒｕｌｅｓ ｆｕｎｃｔｉｏｎ、ＰＣＲＦ）、ホームロケーションレジスタ（ｈｏｍｅ ｌｏｃａｔｉｏｎ ｒｅｇｉｓｔｅｒ、ＨＬＲ）、オンライン課金システム（ｏｎｌｉｎｅ ｃｈａｒｇｉｎｇ ｓｙｓｔｅｍ、ＯＣＳ）およびオフライン課金システム（ｏｆｆｌｉｎｅ ｃｈａｒｇｉｎｇ ｓｙｓｔｅｍ、ＯＦＣＳ）をサポートする必要がある場合もある。また、エネルギー／電力計報告および自動販売機課金などのＭ２Ｍ機能は、異なる課金パラメータを有することができる。このような仕組みにおいて、関連のＭ２Ｍデバイスのユーザーが運営者に直接支払いをするのではなく、ユーザーにＭ２Ｍデバイスを提供するエネルギー会社または販売会社が、例えば、利用全体に基づいておよび／または帯域一括販売に対して、ユーザーに支払いをする。これらのＭ２Ｍネットワークを企業ネットワークモデルに従うものとして扱っている運営者があり、関連の運営サポートシステム（ｏｐｅｒａｔｉｏｎｓ ｓｕｐｐｏｒｔ ｓｙｓｔｅｍ、ＯＳＳ）の費用は相当なものとなる可能性がある。Ｍ２Ｍ運営者は、企業顧客と同じレートを支払うことができない場合がある。

本開示の主題の様々な実施形態をより完全に理解するために、添付の図面と関連してなされる次の説明をここで参照する。

加入者コールフローを例示するフロー図である。 ユーザー端末（ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ、ＵＥ）によって開始されるコールフローを例示するフロー図である。 ネットワーク（ｎｅｔｗｏｒｋ、ＮＷ）によって開始されるコールフローを例示するフロー図である。 本開示の主題のいくつかの実施形態による、Ｄｉａｍｅｔｅｒクレジット制御アプリケーション（Ｄｉａｍｅｔｅｒ ｃｒｅｄｉｔ−ｃｏｎｔｒｏｌ ａｐｐｌｉｃａｔｉｏｎ、ＤＣＣＡ）セッションを例示するブロック図である。 本開示の主題のいくつかの実施形態による、グループＤＣＣＡセッションを例示するブロック図である。 本開示の主題のいくつかの実施形態による、初期の加入者コールフローを例示するフロー図である。 本開示の主題のいくつかの実施形態による、加入者終了コールフローを例示するフロー図である。 本開示の主題のいくつかの実施形態による、更新コールフローを例示するフロー図である。 本開示の主題のいくつかの実施形態による、初期の加入者コールフローを例示するフロー図である。

本明細書に記載のいくつかの実施形態は、Ｍ２Ｍ型デバイスをより良好に収容するために、エボルブドパケットコア（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ、ＥＰＣ）および他の同様のネットワークの容量を解放することに関する。例えば、運営者がＥＰＣリソースをより効率的に使用することができるように、所与の量のネットワーク要素にサービスするのに必要とされるＯＣＳサーバーセッションの数を本明細書に記載の方法およびシステムを使用して低減することができる。他の実施形態は、個々のデバイスとは対照的に、グループ化されたＭ２Ｍデバイスのオンライン課金に関する。

コアネットワークにおける無線アクセスネットワーク（ＲＡＮ）最適化
エボルブドパケットコア（ＥＰＣ）ネットワークの状況では、ある一定のタイプのＭ２Ｍデバイスは必ずしも連続してオンライン状態を保つ必要がない。それにも関わらず、既存の４Ｇ ＬＴＥネットワークアーキテクチャは、すべての加入者セッションを「常時オン」に保つ。したがって、加入者セッションを維持するために、すべての関連のネットワーク要素（例えば、モビリティ管理エンティティ（ＭＭＥ）、ホーム加入者サーバー（ｈｏｍｅ ｓｕｂｓｃｒｉｂｅｒ ｓｅｒｖｅｒ、ＨＳＳ）、サービングゲートウェイ（ＳＧＷ）、パケットゲートウェイ（ＰＧＷ）、ポリシーおよび課金ルール機能（ＰＣＲＦ）、オンライン課金システム（ＯＣＳ）およびオフライン課金システム（ＯＦＣＳ）は、連続して動作している。加入者／Ｍ２Ｍデバイスの数字が増加するにつれて、このようなネットワーク要素の対応する必要性が直線的に増加する。ネットワーク要素ＭＭＥ、ＨＳＳ、ＳＧＷ、ＰＧＷ、ＰＣＲＦ、ＯＣＳ、ＯＦＣＳにおいて１０億のセッションを維持することは、大規模な基盤および極端に高い運営者費用を伴う可能性がある。ある一定の要素の仮想化は、費用を削減するのに役立つ可能性があるが、それでも経済上実用性が高くない、または正当ではない場合がある。

ある一定のタイプのＭ２Ｍデバイスは、連続してオンライン状態のままにしておく必要はない。しかし、現行のＬＴＥアーキテクチャは、ネットワーク要素がネットワーク要素（ｎｅｔｗｏｒｋ ｅｌｅｍｅｎｔ、ＮＥ）側のセッションを解放することを許容せず、またたとえセッションが解放される場合でも、ユーザー端末（ＵＥ）は直ちに復帰することになる。また、ＵＥがＵＥのセッションを解放する場合に、ネットワークは、ＵＥに到達して再接続することができない場合がある。

本明細書に記載の、ＮＥリソース利用を向上させる方法は、ユーザー端末（ＵＥ）セッションを維持しながら、Ｍ２Ｍデバイス／ＵＥによって消費されているＮＥセッションリソースを解放することを含む。セッションが開設状態になったままである間、すべてのネットワーク要素ＭＭＥ、ＨＳＳ、ＳＧＷ、ＰＧＷ、ＰＣＲＦ、ＯＣＳ、ＯＦＣＳは、加入者セッションを維持する必要がある。いくつかの実施形態では、１）ＵＥとネットワークとの間のセッションを維持し（すなわち、ＵＥはＵＥがネットワークに接続されていると考え）、セッション情報を圧縮またはトランケートされた様式でＰＧＷ（またはクラウドなどのＰＧＷと通信する任意の他のノード）に記憶することにより、セッションリソースを解放するにも関わらずこれらのデバイスに対して接続性を維持する。例えば、いくつかの実施形態において、セッション情報のサブセットを記憶することができる。例えば、ネットワークが後にＵＥに接続すること（例えば、データパケットを送信すること）を試行する場合、記憶されたセッション情報を使用して、以前に解放されたセッションリソースを確立することができる。いくつかの実施形態において、他のネットワーク要素のいくつかまたはすべてにおいてセッションリソースを解放することなく、セッション情報を、圧縮またはトランケートされた形式でＰＧＷ（または他のノード）に記憶することができる。

本明細書に記載の技法は、異なるネットワーク要素レベル、例えば、
●ＰＧＷのみ（ＰＣＲＦ、ＯＣＳなどの＋外部ノードリソース）
●ＰＧＷおよびＳＧＷ（＋外部ノードリソース）
●ＳＧＷ、ＭＭＥ、およびＰＧＷ（＋外部ノードリソース）に対して適用することができる。

本明細書に記載の技法は、例えばＭ２Ｍデバイスタイプに応じて、異なるタイムアウト期間（例えば、６時間、２４〜２８時間、日または週のオーダーで、など）で実装することができる。セッションの閉鎖は、例えば、デバイスユーザーグループ（Ｄｅｖｉｃｅ Ｕｓｅｒ Ｇｒｏｕｐ、「ＤＵＧ」）に基づいて（例えば、ＤＵＧ内のすべてのメンバーが所定期間より長く非アクティブである（inactive、活動していない、加わっていない）ときに）、または（例えば、所定のセッション期間を特定する）認証、認可、および課金（ａｕｔｈｅｎｔｉｃａｔｉｏｎ、ａｕｔｈｏｒｉｚａｔｉｏｎ ａｎｄ ａｃｃｏｕｎｔｉｎｇ、「ＡＡＡ」）サーバーからの情報に基づいて、開始することができる。

いくつかの実施形態では、トランザクション指向システムとして作用することができるセッションデータベースがＰＧＷ上（またはクラウドなどの、ＰＧＷと通信する任意の他のノード上）で作成および／または維持される。例えば、セッションデータベース内にいくつかまたはすべてのセッションを配置することができる。続いて、セッションに対してサーブする必要があるときは常に、セッションは、ゲートウェイ（「ＧＷ」）、または各ＧＷ上の負荷に基づいて制御プレーンの見地から１つ以上のゲートウェイ機能を特定することができるワークフロー（「ＷＦ」）に、割り当てることが可能である。各セッションのある一定のアイドル期間後に、セッションをＧＷからパージすることができるが、セッションデータベースに記憶することができ、任意で圧縮またはトランケートすることができる。いくつかの実施形態では、ネットワークパケットが受信されると、ＰＧＷはＤＢを調べ、セッションに対する閉鎖を開始する。

いくつかの実装形態では、セッション作成要求（ｃｒｅａｔｅ ｓｅｓｓｉｏｎ ｒｅｑｕｅｓｔ、ＣＳＲ）、（ＭＢＲ）内のＧＴＰｖ２ Ｃｏｎｔｒｏｌ ＳｉｇｎａｌにＰａｇｅＢｌｏｃｋ Ｉｎｆｏ ＩＥが追加される。例えば、ＭＭＥは、ＰａｇｅＢｌｏｃｋ Ｉｎｆｏ ＩＥをＵＥのページ詳細と共に送信する。ＭＭＥがセッション解放についてＵＥに通知しないがローカルリソースを解放するように、解放原因コードセットに新たな原因コード（例えば、ＮＷ＿ＲＥＬ＿ＯＮＬＹ）が追加される。言い換えれば、従来のシステムと異なり、ＭＭＥは、ＵＥに関するＰａｇｅＢｌｏｃｋ Ｉｎｆｏ ＩＥなどの情報をもはや保持しない。それに代えてまたはそれに加えて、ネットワークノード要素を追加することができ、当該ネットワークノード要素にＭＭＥおよび／またはＰＧＷから解放されたデータを記憶することができる。ＰＧＷは、セッション情報の圧縮またはトランケートされたコピーを維持しながら、ＵＥセッションリソースを解放することができる。いくつかの実施形態において、ＰＧＷは、次の情報、すなわちＵＥ ＩＰ Ａｄｄｒｅｓｓ、Ｐａｇｅ Ｉｎｆｏｒｍａｔｉｏｎ、およびＭＭＥ／ＳＧＷ Ｉｎｆｏｒｍａｔｉｏｎを維持することができる。

ここで図面を参照すると、図１は、いくつかの実施形態に従う、加入者コールフロー１００を示す。図示されるように、加入者のＵＥ１０２は、モビリティ管理エンティティ（ＭＭＥ）１０４に「アタッチ」要求を送信し、ＭＭＥ１０４はセッション作成要求（ＣＳＲ）（ＰａｇｅＩｎｆｏデータを含む）を生成してセッション作成要求をサービングゲートウェイ（ＳＧＷ）１０６に送信する。ＳＧＷ１０６はＣＳＲメッセージをＰＧＷ１０８に転送し、ＰＧＷ１０８は、それに応じて、セッションを開始するためにＣＣＲ−Ｉメッセージを生成してＯＣＳサーバー１１０に送信する。ＯＣＳサーバー１１０は、ＣＣＡ−ＩメッセージをＰＧＷ１０８に返信し、セッションを確立する。ＰＧＷ１０８は、セッション作成応答（ＣＳ Ｒｅｓｐ）を生成してＳＧＷ１０６に送信し、ＳＧＷ１０６はＣＳ ＲｅｓｐをＭＭＥ１０４に転送し、ＭＭＥ１０４は次いでアタッチ応答（Ａｔｔａｃｈ Ｒｅｓｐ）をＵＥ１０２に送信する。続いて、ＰＧＷ１０８は、いくつかのネットワークリソースを解放することを決定し、原因コードネットワーク解放「ｃｃ−ＮＷ＿ＲＥＬ」を特定するベアラ削除要求（ｄｅｌｅｔｅ ｂｅａｒｅｒ ｒｅｑｕｅｓｔ、ＤＢＲ）をＳＧＷ１０６に送信する。ネットワークリソースを解放するＰＧＷ１０８の決定は、特定のリソースが使用中である期間、ネットワーク負荷、最も長い間使用されていないアルゴリズム、所定の閾値を超過する容量、および最も長い間使用されていない１つ以上のリソースの識別のうちの１つ以上に基づく可能性がある。ＰＧＷ１０８はまた、クレジット制御要求終了（ｃｒｅｄｉｔ ｃｏｎｔｒｏｌ ｒｅｑｕｅｓｔ ｔｅｒｍｉｎａｔｅ、ＣＣＲ−Ｔ）メッセージをＯＣＳサーバー１１０に送信し、ＯＣＳサーバー１１０はクレジット制御応答終了（ｃｒｅｄｉｔ ｃｏｎｔｒｏｌ ａｎｓｗｅｒ ｔｅｒｍｉｎａｔｅ、ＣＣＡ−Ｔ）メッセージをＰＧＷ１０８に返す。ＳＧＷ１０６は、ＤＢＲメッセージをＭＭＥ１０４に転送する。ＭＭＥ１０４は、それに応じてＤＢＲｓｐメッセージをＳＧＷ１０６に返信し、ＳＧＷ１０６はＤＢＲｓｐメッセージをＰＧＷ１０８に転送する。加入者コールフロー１００の終了時に、ＰＧＷはＵＥセッションリソースを解放しているが、ＵＥ１０２に関するセッションデータは、セッションが完全に終了しないように圧縮されてＰＧＷ１０８に記憶され、セッションが再度アクティブになるまでより少ないリソースを使用し続ける。圧縮されたセッションデータは、ＵＥ１０２のＩＰアドレス、ページ情報（例えば、ＰａｇｅＢｌｏｃｋ）およびＭＭＥ／ＳＧＷ情報のうちの１つ以上を含むことができる。ＵＥ１０２から見て、セッション状態の明らかな変化はない。

図２は、いくつかの実施形態に従う、ＵＥによって開始されたコールフロー２００を示す。フロー２００は、加入者ＵＥ２０２が、ＵＥに既知であるセッションＩＤを含むメッセージをＭＭＥ２０４に送信することによってコールを開始することを試行することで始まる。アクティブなセッションを検出せずに（アクティブなセッションはＵＥ関連データをもはや記憶しないため）、ＭＭＥ２０４はＵＥ２０２に「閉鎖」メッセージ（原因コード「ｃｃ＝ＳｅｓｓｉｏｎＮｏｔＦｏｕｎｄ」を含む）を返信する。次に、ＵＥ２０２はＭＭＥ２０４に「アタッチ」メッセージを送信し、ＭＭＥ２０４はＣＳＲメッセージ（「ＰａｇｅＩｎｆｏ」を含む）を生成してＳＧＷ２０６に送信する。ＳＧＷ２０６はＰＧＷ２０８にＣＳＲメッセージ（「ＰａｇｅＩｎｆｏ」を含む）を送信し、ＰＧＷ２０８はセッションを開始するためにＣＣＲ−Ｉメッセージを生成してＯＣＳサーバー２１０に送信する。ＯＣＳサーバー２１０はＰＧＷ２０８にＣＣＡ−Ｉメッセージを返し、ＰＧＷ２０８は「ＣＳ Ｒｅｓｐ」メッセージを生成してＳＧＷ２０６に送信し、ＳＧＷ２０６は次いでＣＳ ＲｅｓｐをＭＭＥ２０４に転送する。ＭＭＥ２０４はその後ＵＥ２０２にＡｔｔａｃｈ Ｒｅｓｐを送信して、セッションが開始されたことを確認する。

図３は、いくつかの実施形態に従う、ＮＷによって開始されるコールフロー３００を示す。図２を参照して上述したフローの多くは図３にも存在するが、データパケットは最初にインターネット３１２からＰＧＷ３０８に送信され、そこでは圧縮またはトランケートされたセッションデータが記憶されており、そしてＰＧＷ３０８はＤｏｗｎＬｉｎｋＤａｔａ（ＰａｇｅＩｎｆｏを含む）を生成してＭＭＥ３０４に送信し、ＭＭＥ３０４はＵＥ３０２にページを送信する。コールフロー３００は、上述したコールフロー２００と同様である。ページを受信すると、ＵＥ３０２はＭＭＥ３０４にメッセージを送信することによってコールを開始することを試行する。ＭＭＥ３０２は、アクティブなセッションを検出せず、ＵＥ３０２に「閉鎖メッセージ（原因コード「ｃｃ＝ＳｅｓｓｉｏｎＮｏｔＦｏｕｎｄ」を含む）を返信する。次に、ＵＥ３０２はＭＭＥ３０４に「アタッチ」メッセージを送信し、ＭＭＥ３０４はＣＳＲメッセージ（「ＰａｇｅＩｎｆｏ」を含む）を生成してＳＧＷ３０６に送信する。ＳＧＷ３０６はＣＳＲメッセージ（「ＰａｇｅＩｎｆｏ」を含む）をＰＧＷ３０８に送信し、ＰＧＷ３０８はセッションを開始するためにＯＣＳサーバー３１０にＣＣＲ−Ｉメッセージを送信する。ＯＣＳサーバー３１０はＰＧＷ３０８にＣＣＡ−Ｉメッセージを返し、ＰＧＷ３０８はＳＧＷ３０６への「ＣＳ Ｒｅｓｐ」メッセージを生成し、ＳＧＷ３０６は次いでＣＳ ＲｅｓｐをＭＭＥ３０４に転送する。ＭＭＥ３０４はその後ＵＥ３０２にＡｔｔａｃｈ Ｒｅｓｐを送信して、セッションが開始されたことを確認する。最初にインターネット３１２からＰＧＷ３０８に送信されたデータパケットは、その後典型的な様式でＵＥ３０２に送達される。

Ｍ２Ｍに対する課金最適化
既存のネットワーク課金アーキテクチャでは、単一のＯＣＳセッションは単一の加入者に対応する。しかし、Ｍ２Ｍデバイスの普及が拡大するにつれて、すなわち「モノのインターネット」（ｉｎｔｅｒｎｅｔ ｏｆ ｔｈｉｎｇｓ、ＩＯＴ）の出現で、このようなデバイスへのサービスの規模を変化させる圧力が生じるであろう。第三世代パートナーシッププロジェクト（３ＧＰＰ）は、例えば、同じグループに属するＭ２Ｍデバイスに対する大量の課金データレコード（ＣＤＲ）を生成するために、Ｍ２Ｍデバイスに対する課金ガイドライン（ＴＲ ２３．８８７に基づく）を規定しているが、オフライン課金のみがサポートされている。

本開示のいくつかの実施形態では、Ｍ２Ｍデバイスは、例えば共通のグループ識別子（ＩＤ）または「デバイスユーザーグループ」（ＤＵＧ）を用いてまとめてグループ化され、これによりＭ２Ｍデバイスが、オンライン課金を目的として同じ（共通の）Ｍ２Ｍ運営者に対して課金することができるようになっている。このような構成により、所与のＯＣＳが所与の時間に収容する必要があるセッションの数を低減して、ＯＣＳ容量を解放し、これによってより多くの加入者がサービスを受けることができる。例えば、加入者がデータ通信可能量（例えば、１０ＭＢ）を要求すると仮定すると、ＯＣＳ／運営者は、加入者がいずれのデバイス（複数可）またはネットワーク要素に対するデータ通信可能量を使用しているかを知ることを要せずに当該要求を承認し、ＤＵＧに当該１０ＭＢを割り当てることができる。これにより、ユーザーデバイスと関連の加入者に課金するＯＣＳとの間の一対一結合が解消され、複数の加入者および／またはユーザーデバイスが単一のＯＣＳセッションを介してデータを課金することができる。言い換えれば、ネットワーク要素レベルで統合が実装される。結果として、所与の数の加入者にサービスするための、ＯＣＳサーバーとのセッションの数が低減される。ＯＣＳはまた、これにより、小規模のトランザクション／利用に基づくのではなく、より集約されたやり方で、データ通信可能量要求を処理する。

いくつかの実装形態では、「同じサービス」のＭ２Ｍデバイスのグループは、ローカルで、または１つ以上の対応する課金サーバーを介して構成することができる。データ／ユニット許可、利用および報告レベルは、こうして、単一加入者レベルではなくグループレベルで実行することができる。

いくつかの実施形態では、オンライン課金システム（ＯＣＳ）は、ＲＦＣ４００６、３２．２９９Ｇｘ、ＧｙなどのＤｉａｍｅｔｅｒクレジット制御アプリケーション（ＤＣＣＡ）アプリケーションを使用するが、当該プロトコルを効率化してＭ２Ｍデバイスのグループを収容する（複数のＭ２Ｍデバイスを、単一のＤＵＧと、また任意で単一の関連のクォータと関連付ける）。例えば、オンライン課金は、次のメッセージを有するクレジット制御アプリケーションを使用して実行することができる。
●クレジット制御要求（ＣＣＲ）
○ＩＮＩＴＩＡＬ、ＵＰＤＡＴＥおよびＴＥＲＭＩＮＡＴＥ
●クレジット制御応答（ＣＣＡ）
○ＩＮＩＴＩＡＬ、ＵＰＤＡＴＥおよびＴＥＲＭＩＮＡＴＥ
●再認可（ＲＡＲ）

図４は、本開示の主題のいくつかの実施形態による、リアルタイムオンライン課金を容易にする単一のＤＣＣＡセッション（例えば、許可の実行）を例示するブロック図である。図４に示されるように、単一のＤＣＣＡセッション４１４（例えば、ＯＣＳサーバーによってホストされる）は、例えば、それぞれ４１６Ａ〜４１６Ｅであるサービス識別子「Ａ」〜「Ｅ」によって識別される５つのサービスと関連付けられる。各サービスは、場合によっては複数のサービスによって共有される、対応するクォータ（４１８Ａ、４１８Ｂおよび／または４１８Ｃ）にリンクされる。ＤＣＣＡセッションの間に、加入者はデータ通信可能量要求を行い、加入者に利用可能な十分なクォータがある場合にはデータユニットは許可される可能性がある。サービス識別子（「Ｓｅｒｖｉｃｅ−Ｉｄ」）およびレーティンググループ（それぞれ４１７Ａおよび４１７Ｂである、「１」および「ｎ」）を使用して、許可されたユニット（複数可）を所与のサービスまたはレーティンググループと関連付ける。この構成により、運営者が有する各サービスに対して１つ以上の異なるクォータを割り当てることができるため、運営者が異なるサービスを異なるように構築／体系化することができるように、運営者に柔軟性が与えられる。例えば、コール時間などのリソースが安価であるときに、そのリソースに関連付けられたクォータはより高くなる可能性がある。言い換えれば、リソース割り当て（例えば、エネルギーユニット、データユニットなど）は、同じセッション内の異なる期間においては「より安価」であるかまたは「より高価」になる可能性がある（例えば、関連付けられたレーティンググループによって示されるように）。クォータおよび／またはレーティンググループは、多数のデバイス（例えば、電気メーター、携帯電話、コンピューティングデバイスなど）の集約に少なくとも部分的に基づく可能性がある。

図５は、本開示の主題のいくつかの実施形態による、「グループＤＣＣＡセッション」５２０を例示するブロック図である。グループＤＣＣＡセッション５２０は、単一の加入者（例えば、水道会社）またはＤＵＧ内のデバイスのグループ（例えば、複数の水道メーター）に対応することができる。個々の加入者またはＤＵＧ内のデバイスから発せられるオンライン課金要求をサービスするために、時系列になっている従属的なセッション（それぞれ５１４Ａ〜５１４Ｂであるセッション「１」〜「ｎ」）はグループＤＣＣＡセッション５２０と相互作用することができる。各従属的なセッション５１４Ａ〜５１４Ｂは、その場合に、図４を参照して上述したように動作する。言い換えれば、セッション１（５１４Ａ）およびセッションｎ（５１４Ｂ）は、例えば、各々がそれぞれ５１６Ａ〜５１６Ｅであるサービス識別子「Ａ」〜「Ｅ」によって識別される５つのサービスと関連付けられる。各サービスは、場合によっては複数のサービスによって共有される、対応するクォータ（５１８Ａ、５１８Ｂおよび／または５１８Ｃ）にリンクされる。セッション１〜ｎの各々の間、加入者はデータ通信可能量要求を行い、加入者に利用可能な十分なクォータがある場合にはデータユニットを許可することができる。上記のように、サービス識別子（「Ｓｅｒｖｉｃｅ−Ｉｄ」）およびレーティンググループ（それぞれ５１７Ａおよび５１７Ｂである「１」および「ｎ」）を用いて、許可されたユニットを所与のサービスまたはレーティンググループに関連付ける。

ＤＣＣＡ ＡＶＰの変形例
いくつかの実施形態では、Ｓｕｂｓｃｒｉｐｔｉｏｎ−Ｉｄ−Ｔｙｐｅの属性値ペア（Ａｔｔｒｉｂｕｔｅ−Ｖａｌｕｅ Ｐａｉｒ 、ＡＶＰ）を使用してユーザーの加入を識別する。特定のＭ２Ｍデバイスがいずれのグループに属するかを識別するために、新たな加入識別子タイプ「ＥＮＤ＿ＵＳＥＲ＿ＧＲＯＵＰ」を定義することができる。この情報は、例えば、Ｍ２Ｍ ＵＥ Ｄｅｖｉｃｅから、またはＧＴＰ−Ｃ Ｖ２メッセージを介してホーム加入者サーバー（ＨＳＳ）から、受信される可能性がある。Ｓｕｂｓｃｒｉｐｔｉｏｎ−Ｉｄ値の一部として国際移動体装置識別番号（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ Ｅｑｕｉｐｍｅｎｔ Ｉｄｅｎｔｉｔｙ、ＩＭＥＩ）を送信するために別の加入識別子タイプ「ＥＮＤ＿ＵＳＥＲ＿ＩＭＥＩ」を追加することができる。ＤＵＧを表すためにＤｉａｍｅｔｅｒ（またはクレジット制御アプリケーションに使用することができる任意の他の好適なプロトコル）にＤｅｖｉｃｅ−Ｕｓｅｒ−Ｇｒｏｕｐ Ｎａｍｅ ＡＶＰを追加することができる。

いくつかの実施形態では、Ｕｓｅｄ−Ｓｅｒｖｉｃｅ−Ｕｎｉｔ ＡＶＰを使用して、各Ｍ２Ｍデバイスの固有の情報を利用データと共に伝えることができる。本発明に従うＵｓｅｄ−Ｓｅｒｖｉｃｅ−Ｕｎｉｔ ＡＶＰの実施形態は次の通りである（太字のパラメータを参照）。

ＧＴＰ−Ｃ Ｖ２メッセージの変形例
いくつかの実施形態では、Ｍ２Ｍ Ｄｅｖｉｃｅ Ｇｒｏｕｐ Ｕｓｅｒを識別するために、汎用パケット無線サービス（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ、ＧＲＰＳ）Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ（ＧＴＰ−Ｃ）メッセージに新たな識別子が追加される。新たな識別子は、ＵＴＦ８によって符号化することができ、文字列型変数とすることができる。新たな識別子を使用して、単一のアクセスポイント名（ａｃｃｅｓｓ ｐｏｉｎｔ ｎａｍｅ、ＡＰＮ）の下で同じタイプのＭ２Ｍデバイスのグループ（すなわち、単一のユーザーによってサポートされる）を定義し、これによって、単一のＡＰＮ内の複数のＭ２Ｍデバイスユーザーグループメンバーをサポートする（すなわち、課金、ＰＣＲＦポリシー設定などを容易にする）ことができる。ホーム加入者サーバー（ＨＳＳ）またはＵＥデバイスはこの新たな情報／属性を送信することができる。ＨＳＳが当該情報を送信する場合に、ＨＳＳはＵＥによって渡された情報をオーバーライドすることができる。対応するモビリティ管理エンティティ（ＭＭＥ）は、その場合に、当該情報をＳＧＷに送信することができ、ＳＧＷは当該情報をＰＧＷに送信することができる。いくつかの実装形態では、当該情報は、初期のベアラ設定メッセージ、例えば、ベアラが一旦設定されると変更できないＣｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔメッセージの一部として送信される。ＨＳＳが当該情報を変更する場合には、ベアラは終了されて新たな属性値で再作成される。

Ｄｅｖｉｃｅ Ｇｒｏｕｐ Ｉｄｅｎｔｉｆｉｅｒ Ａｔｔｒｉｂｕｔｅの実施例は次の通りである。

Ｄｅｖｉｃｅ Ｇｒｏｕｐ Ｉｄｅｎｔｉｆｉｅｒは、いくつかの方法のうちの１つで供給され得る。例えば、ＵＥがそれ自体にＤｅｖｉｃｅ Ｇｒｏｕｐ Ｉｄｅｎｔｉｆｉｅｒを（例えば、メモリ内に）保有し、当該Ｄｅｖｉｃｅ Ｇｒｏｕｐ Ｉｄｅｎｔｉｆｉｅｒを送信してもよい。それに代えてまたはそれに加えて、ＨＳＳは、ＵＥの認証を実行しながらＤｅｖｉｃｅ Ｇｒｏｕｐ Ｉｄｅｎｔｉｆｉｅｒを取得し、ＧＴＰ Ｖ２／Ｖ１制御プロトコルを使用して当該Ｄｅｖｉｃｅ Ｇｒｏｕｐ ＩｄｅｎｔｉｆｉｅｒをＳＧＷ／ＰＧＷに送信することができる。それに代えてまたはそれに加えて、Ｄｅｖｉｃｅ Ｇｒｏｕｐ Ｉｄｅｎｔｉｆｉｅｒを、例えば２９．０６１ Ｒａｄｉｕｓ／Ｄｉａｍｅｔｅｒプロトコルを使用して、任意の外部の認証、認可、および課金（ＡＡＡ）サーバーから受信することができる。

仮想ＥＰＣ実装形態（例えば、Ａｆｆｉｒｍｅｄ ＮｅｔｗｏｒｋのゲートウェイＭＣＣなど）は、Ｄｅｖｉｃｅ Ｇｒｏｕｐ Ｉｄｅｎｔｉｆｉｅｒを加入者アナライザキーとして使用することができる。例えば、各インターフェースタイプ（例えば、ＰＣＲＦインターフェース、ＡＡＡインターフェース、ＯＣＳインターフェース、クレジット制御インターフェース、オフライン課金インターフェース）についてのローカル構成に基づいて、グループ内のデバイスの数を定義することができ、またはＰＣＲＦ／ＡＡＡ／ＯＣＳサーバーは各グループ内のデバイスの数を判定することができる。

いくつかの実施形態では、各デバイスユーザーグループに対して複数のＤｉａｍｅｔｅｒセッションが存在することができるが、個々のデバイスはＤｉａｍｅｔｅｒセッショングループのうちの１つのみに存在することができる。特定のＩＭＥＩは単一のＤＵＧにのみ属すことができるが、当該ＤＵＧは同時に複数のセッションと関連付けることができる。

図６は、いくつかの実施形態による、初期の加入者コールフロー６００を例示するフロー図である。ＭＭＥ６０４は、「ＩＭＳＩ１」という国際移動体装置識別番号（「ＩＭＳＩ」）と指定ユーザーグループ（ＤＵＧ）「ＴＥＤ」とに対するセッション作成要求（ＣＳＲ）をＳＧＷ６０６に送信し、ＳＧＷ６０６はＣＳＲをＰＧＷ６０８に渡し、ＰＧＷ６０８は「ＴＥＤ」ユーザーグループに対してチェックを行う。図６に示されるシナリオでは、ＰＧＷがＣＳＲを受信する時点では既存のＯＣＳセッションはなく、そのためＰＧＷは、ＤＵＧ「ＴＥＤ」に対するクレジット制御要求開始（「ＣＣＲ−Ｉ」）メッセージをＯＣＳサーバー６１０に送信し、セッションを開始することを要求する。ＯＣＳサーバーは、許可されたサービスユニット（「ＧＳＵ」＝１００ＭＢ）と有効期間（「ＶＴ」＝３００秒）とを特定するクレジット制御応答（ＣＣＡ−Ｉ）を返信する。セッション作成応答（「ＣＳ Ｒｅｓｐ」）がＰＧＷ６０８からＳＧＷ６０６に送信され、ＳＧＷ６０６は当該セッション作成応答をＭＭＥ６０４に渡す。後に、ＭＭＥ６０４は、今回はＩＭＳＩ２に対するものであり、これもＤＵＧ「ＴＥＤ」に属する第２のＣＳＲをＳＧＷ６０６に送信し、ＳＧＷ６０６は、同じくＣＳＲをＰＧＷ６０８に送信する。ＰＧＷ６０８は、同じく「ＴＥＤ」ユーザーグループに対してチェックを行い、今回は既存のＯＣＳセッションがすでにあることを検出する。そのためＰＧＷ６０８は、ＯＣＳに別のＣＣＲ−Ｉ要求を送信する必要がない。そうせずに、ＰＧＷ６０８は、既存のセッション中に、「ＴＥＤ」に既に以前に許可されたデータユニットを使用し、それに基づいて、（ＰＧＷ６０８がＳＧＷ６０６に送信する）ＣＳ Ｒｅｓｐを生成する。ＳＧＷ６０６はその後ＣＳ ＲｅｓｐをＩＭＳＩ２に対してＭＭＥ６０４に渡す。

図７は、いくつかの実施形態による、加入者終了コールフロー７００を例示するフロー図である。ＭＭＥ７０４は、ＩＭＳＩ１に対するセッション削除要求をＳＧＷ７０６に送信し、ＳＧＷ７０６は、それに応じて、セッション削除要求をＰＧＷ７０８に送信する。ＰＧＷ７０８は、ＩＭＳＩ１が、図６を参照して上述したＴＥＤグループ許可内の最新の加入者であるかどうかをチェックして確かめる。ＰＧＷ７０８がＩＭＳＩ１は最新のＴＥＤ加入者ではないと判定する場合には、ＰＧＷ７０８は、オンライン課金（例えば、Ｄｉａｍｅｔｅｒ）セッションを終了することを拒否し、「セッション削除応答」メッセージを介してその否認をＳＧＷ７０６に伝達し、ＳＧＷ７０６は当該メッセージをＭＭＥ７０４に転送する。フロー図の下部では、ＭＭＥ７０４は、ＩＭＳＩ２に対する別のセッション削除要求を送信する。今回は、ＰＧＷ７０８は、ＩＭＳＩ１が最新のＴＥＤ加入者であると判定し、ＯＣＳ７１０にＣＣＲ−Ｔ終了要求を送信し、ＩＭＳＩ１およびＩＭＳＩ２（ＤＵＧ「ＴＥＤ」の両方のメンバー）に対して使用されるサービスユニット（「ＵＳＵ」）を特定する。図７に示されるように、ＩＭＳＩ１は１００，０００ＵＳＵを使用し、ＩＭＳＩ２は３５，０００ＵＳＵを使用した。ＯＣＳサーバー７１０は、クレジット制御応答（ＣＣＡ−Ｔ）終了確認をＰＧＷ７０８に送信する。ＰＧＷ７０８はその後セッション削除応答を生成してＳＧＷ７０６に渡し、ＳＧＷ７０６はセッション削除応答をＭＭＥ７０４に転送する。

図８は、いくつかの実施形態に従う、更新コールフロー８００を例示するフロー図である。８２２において、ｅＮｏｄｅＢは、ＩＭＳＩ１に対するベアラデータパケットをＳＧＷ８０６に送信し、ＳＧＷ８０６はパケットを生成して当該パケットをＰＧＷ８０８に送信する。ＰＧＷ８０８はその後ＰＧＷ８０８のローカルメモリを更新して、ＴＥＤデータ許可に対するＩＭＳＩ１の（ユーザーグループ「ＴＥＤ」の）セッション利用を反映する。ＰＧＷ８０８はその後ＤＵＧ＝ＴＥＤに対するＣＣＲ−ＩメッセージをＯＣＳサーバー８１０に送信する。ＯＣＳサーバー８１０は、ＣＣＡ−Ｉで回答し、１００ＭＢのＧＳＵを許可する。続いて、ｅＮｏｄｅＢ８２２は、ＩＭＳＩ２に対するベアラデータパケットをＳＧＷ８０６に送信し、ＳＧＷ８０６は別のパケットを生成して、当該パケットをＰＧＷ８０８に送信する。ＰＧＷ８０８はその後ＰＧＷ８０８のローカルメモリを更新して、ＴＥＤデータ許可に対するＩＭＳＩ２の（ユーザーグループ「ＴＥＤ」の）セッション利用を反映する。この時点では図８では、ＰＧＷ８０８は、ＩＭＳＩ１およびＩＭＳＩ２の組み合わされた利用が、ユーザーグループＴＥＤに対する許可されたサービスユニット（ｇｒａｎｔｅｄ ｓｅｒｖｉｃｅ ｕｎｉｔ、ＧＳＵ）を現時点で超過していると判定した。そのためＰＧＷ８０８はその後ＤＵＧ＝ＴＥＤに対するＣＣＲ−ＵメッセージをＯＣＳサーバー８１０に送信し、「ＵＳＵ１−１００Ｋ，ＩＭＳＩ１」および「ＵＳＵ２−３００Ｋ，ＩＭＳＩ１」を特定する。ＯＣＳサーバー８１０は、ＣＣＡ−Ａで回答し、別の１００ＭＢのＧＳＵを許可する。ＰＧＷ８０８はその後ＴＥＤデバイスユーザーグループに対して、１００ＭＢのＧＳＵでトラフィック検出機能（「ＴＤＦ」）および／またはポリシーおよび課金行使機能（「ＰＣＥＦ」）を更新する。

Ｇｘインターフェース最適化
いくつかの実施形態では、各加入者に対する加入者ポリシーを取得する代わりに、ポリシー制御および課金機能（ＰＣＥＦ）が、ポリシー制御および課金ルール機能（ＰＣＲＦ）からグループポリシーが既に受信されているかどうかを判定することができる。Ｍ２Ｍデバイスグループユーザー名および関連のＡＰＮに基づいて、ＰＣＥＦは、加入者ポリシーデータに対する要求をＰＣＲＦに送信することが可能である。加入者ポリシーデータが所与のＭ２Ｍデバイスグループユーザーに対して利用可能になると、Ｍ２Ｍデバイスグループユーザー（例えば、ＰＧＷ）はこのポリシーデータをキャッシュすることが可能になる。いくつかの実施形態では、同じＤＵＧおよびＡＰＮを有する別のＭ２Ｍデバイスは、最初にローカルにチェックして、ポリシーデータが既にフェッチされているかどうかを判定することが可能である。フェッチされている場合には、当該Ｍ２Ｍデバイスは、当該ポリシーデータを使用することになる。ＰＣＲＦまたはローカル構成データを使用して、所与のユーザーグループ内の加入者の数を判定することができる。ＰＣＲＦはまた、有効期限タイマー（例えば、ＰＣＲＦが更新のチェックを実行するまでの所定の時間間隔）を設定して、これらの加入者ルールの再評価を強制することができる。ＰＣＲＦは、これらのデバイスグループの運営者構成の変化があるときには常に、それでもまだ再認可（ＲＡＲ）メッセージを使用してユーザーグループに基づいて再認証することができる。

図９は、いくつかの実施形態に従う、別の初期の加入者コールフロー９００を例示するフロー図である。フローは、前述したように、ＭＭＥ９０４がユーザーグループ「ＴＥＤ」のＩＭＳＩ１に対するＣＳＲをＳＧＷ９０６に送信することで始まる。ＳＧＷ９０６はＰＧＷ９０８にＣＳＲを送信し、ＰＧＷ９０８は、ＴＥＤユーザーグループに対してチェックを行い、そしてこの場合も既存のＰＣＲＦセッションが現時点ではないと判定する。そのためＰＧＷ９０８は、ユーザーグループＴＥＤに対するＣＣＲ−ＩをＰＣＲＦ９２４に送信することによって、ＰＣＲＦセッションを（例えば、ＰＧＷ９０８が加入者ポリシーデータを取得できるように）開始する。ＰＣＲＦ９２４は、加入者ポリシーデータとサービス（ＱｏＳ）データのデフォルト品質とを含むＣＣＡ−ＩメッセージをＰＧＷ９０８に返す。ＰＧＷ９０８はその後ＣＳ Ｒｅｓｐメッセージを生成してＳＧＷ９０６に送信し、ＳＧＷ９０６は次いで当該ＣＳ ＲｅｓｐメッセージをＭＭＥ９０４に送信する。続いて、ＭＭＥ９０４は、ユーザーグループ「ＴＥＤ」のＩＭＳＩ２に対するＣＳＲをＳＧＷ９０６に送信し、ＳＧＷ９０６はＰＧＷ９０８にＣＳＲを送信し、ＰＧＷ９０８はＴＥＤユーザーグループに対してチェックを行い、そして今回は既存のＰＣＲＦセッションが現時点ではあると判定する。そのためＰＧＷ９０８は、ＴＥＤグループに割り当てられたポリシーを適用し、ＰＧＷ９０８は当該ポリシーを、セッションのより早期にＰＣＲＦ９２４から受信した以前のＣＣＡ−Ｉメッセージから、既に取得している。したがって、ＰＧＷ９０８は、この段階でＰＣＲＦ９２４と通信する必要がない。ＰＧＷ９０８は、同じくＣＳ Ｒｅｓｐメッセージを生成してＳＧＷ９０６に送信し、ＳＧＷ９０６は次いで当該ＣＳ ＲｅｓｐメッセージをＭＭＥ９０４に送信する。いくつかの実装形態にでは、図９のフロー９００は、図７を参照して上述したＯＣＳセッション終了プロセスと同様のＰＣＲＦ終了プロセスを含むことができる。例えば、ユーザーＩＭＳＩ１がセッションを始動し、ＰＣＲＦが応答し、ＩＭＳＩ１が後に離脱し、他のユーザーがセッションに参加しない場合に、ＰＣＲＦはセッションを終了することができる。いくつかの実施形態では、所定のスケジュールに従って、（例えば、ＰＧＷ９０８がＰＣＲＦ９２４にＣＣＲ−Ｉメッセージを送信することにより）加入者ポリシーの再有効化を実行することができる。それに代えてまたはそれに加えて、ＰＣＲＦは、サーバーレベルで検出される変更（すなわち、加入者ポリシーの変更）に応じて、ＰＧＷ９０８に対する更新を「プッシュ」することができる（例えば、ＲＡＲを介したＣＣＡ−Ｉ、終了する必要なし）。いくつかのこのような場合では、ＰＣＲＦ９２４は、ＰＣＲＦ９２４によって更新／変更が検出される時点で進行中のセッションがある場合に、に加入者ポリシーに対する変更をＰＧＷ９０８へとプッシュするのみである。

本明細書に開示の技法およびシステムは、ネットワーク、コンピュータシステムまたはコンピュータ化された電子デバイスと共に使用するためのコンピュータプログラム製品として実装されてもよい。このような実装形態は、コンピュータ可読媒体（例えば、ディスケット、ＣＤ−ＲＯＭ、ＲＯＭ、フラッシュメモリもしくは他のメモリ、または固定ディスク）などのいずれかの有形の媒体上に固定された、または媒体を介してネットワークに接続された通信アダプタなどのモデムまたは他のインターフェースデバイスを介してネットワーク、コンピュータシステム、またはデバイスへと伝送可能な、一連のコンピュータ命令またはロジックを含んでもよい。

媒体は、有形の媒体（例えば、光またはアナログ通信線）または無線技法を用いて実装される媒体（例えば、Ｗｉ−Ｆｉ、セルラー、マイクロ波、赤外または他の伝送技法）のいずれかであってもよい。一連のコンピュータ命令は、システムに関して本明細書に記載の機能性の少なくとも一部を具現化する。当業者は、このようなコンピュータ命令を、多くのコンピュータアーキテクチャまたはオペレーティングシステムで使用するための多数のプログラミング言語で書くことができることを理解するはずである。

更に、このような命令は、半導体、磁気、光または他のメモリデバイスなどの任意の有形のメモリデバイスに記憶されてもよく、光、赤外、マイクロ波または他の伝送技術などの任意の通信技術を使用して伝送されてもよい。

このようなコンピュータプログラム製品が、印刷または電子書類が付随するリムーバブル媒体（例えば、シュリンクラップで包装されたソフトウェア）として頒布され、コンピュータシステムに予めロードされ（例えば、システムＲＯＭまたは固定ディスク上に）またはサーバーまたは電子掲示板からネットワーク（例えば、インターネットまたはＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）を介して配信されてもよいことが予測される。当然であるが、本発明のいくつかの実施形態は、ソフトウェア（例えば、コンピュータプログラム製品）とハードウェアとの両方の組み合わせとして実装されてもよい。本発明の更に他の実施形態は、ハードドウェア全体としてまたはソフトウェア全体（例えば、コンピュータプログラム製品）として実装される。

以上の説明では、ある一定のステップまたはプロセスは、特定のサーバー上でまたは特定のエンジンの一部として実行することができる。これらの説明は、特定のステップを、サーバーシステムおよび／またはモバイルデバイスを含むがこれらに限定されない様々なハードウェアデバイス上で実行することができることから、単なる例示である。同様に、特定のステップが実行される区分は変化する可能性があり、また区分がないことまたは異なる区分が本発明の範囲内にあることは理解される。更に、コンピュータシステム処理を説明するために使用される「モジュール」および／または他の用語の使用は、交換可能であって機能性を実行することができるロジックまたは回路を表すことが意図されている。

Claims (27)

1. モバイル通信ネットワーク内のネットワークリソースを保存する方法であって、
   既存のユーザー端末（「ＵＥ」）セッションと関連付けられたネットワークリソースを解放することが可能であると判定することであって、前記既存のＵＥセッションはＵＥと関連付けられている、ことと、
   前記既存のＵＥセッションに関連する情報のサブセットを識別することであって、前記情報のサブセットを使用して、前記ＵＥと関連付けられた新たなＵＥセッションを作成することが可能である、ことと、
   前記情報のサブセットを記憶することと、
   １つ以上のネットワークノードにおいて、前記既存のＵＥセッションと関連付けられたネットワークリソースを解放することであって、前記ＵＥは前記解放を通知されない、ことと、
   前記ＵＥにデータを転送する要求を受信することと、
   前記記憶されたセッション情報のサブセットを使用して新たなＵＥセッションを作成し、かつ前記１つ以上のネットワークノードにおいて、前記新たなＵＥセッションと関連付けられたネットワークリソースを確立することと、
   前記新たなＵＥセッションを使用して前記ＵＥに前記データを転送することと、を含む、方法。
2. 前記既存のＵＥセッションと関連付けられたネットワークリソースを解放することが可能であると前記判定することが、基準のセットのうちの１つ以上の基準に基づいており、前記基準のセットが、
   一人以上の加入者が非アクティブである期間と、
   セッション期間を特定する認証、認可、及び課金（「ＡＡＡ」）サーバーからの情報と、
   特定のリソースが使用中である期間と、
   ネットワーク負荷と、
   最近最も使用されていないアルゴリズムと、
   所定の閾値を超過する容量と、
   最近最も使用されていない１つ以上のリソースの識別情報と、を含む、請求項１に記載の方法。
3. 前記情報のサブセットが、ＵＥ ＩＰ Ａｄｄｒｅｓｓと、Ｐａｇｅ情報と、モビリティ管理エンティティ（ＭＭＥ）／サービングゲートウェイ（ＳＧＷ）情報とを含む、請求項１に記載の方法。
4. １つ以上のネットワークノードにおいて、前記既存のＵＥセッションと関連付けられたネットワークリソースを前記解放することが、解放原因コードを伝送することを含む、請求項１に記載の方法。
5. 前記解放原因コードが、前記１つ以上のネットワークノードに、前記１つ以上のネットワークノードにおいて、前記既存のＵＥセッションと関連付けられたネットワークリソースを解放して、前記ＵＥへの前記解放の通知を保留するように、指示する、請求項１に記載の方法。
6. 前記情報のサブセットを前記記憶することが、パケットゲートウェイ（「ＰＧＷ」）に情報を記憶することを含む、請求項１に記載の方法。
7. 前記情報のサブセットを前記記憶することが、パケットゲートウェイ（「ＰＧＷ」）において接続されたノードに情報を記憶することを含む、請求項１に記載の方法。
8. 前記情報のサブセットを前記記憶することが、セッションデータベース内に情報を記憶することを含む、請求項１に記載の方法。
9. 通信ネットワーク内のグループに属する一人以上の加入者にデータリソースを許可する方法であって、
   オンライン課金セッションを作成する要求を受信することであって、前記要求が一人以上の加入者と関連付けられている指定ユーザーグループ（「ＤＵＧ」）を識別する、ことと、
   前記ＤＵＧが既存のオンライン課金セッションと関連付けられているかどうかを判定することであって、
   前記ＤＵＧと関連付けられた既存のオンライン課金セッションがない場合に、新たなオンライン課金セッションを要求するオンライン課金ノードに前記ＤＵＧを識別するメッセージを送信し、前記ＤＵＧに割り当てられたポリシーデータを前記オンライン課金ノードから受信し、
   既存のオンライン課金セッションが前記ＤＵＧと関連付けられている場合に、前記ＤＵＧに以前に割り当てられたポリシーデータを読み出す、ことと、
   前記ポリシーデータに基づいて前記一人以上の加入者にデータリソースを許可することであって、前記データリソースが前記一人以上の加入者によって共有される、ことと、を含む、方法。
10. 前記ポリシーデータが１つ以上のクォータを含み、各クォータが１つ以上のサービスまたはレーティンググループと関連付けられている、請求項９に記載の方法。
11. 前記オンライン課金ノードが、オンライン課金システム（「ＯＣＳ」）サーバーまたはポリシー制御および課金ルール機能（「ＰＣＲＦ」）サーバーである、請求項９に記載の方法。
12. 前記ポリシーデータをキャッシュすることを更に含む、請求項９に記載の方法。
13. 所定の時間間隔に基づいて前記ポリシーデータに対する更新をチェックすることを更に含む、請求項１２に記載の方法。
14. 前記セッションを削除する要求が、前記ＤＵＧと関連付けられた最新の加入者と関連付けられている場合にのみ、前記オンライン課金セッションを削除することを更に含む、請求項９に記載の方法。
15. モバイル通信ネットワーク内のネットワークリソースを保存する非一時的コンピュータ可読媒体であって、前記モバイル通信ネットワークが、
    既存のユーザー端末（「ＵＥ」）セッションと関連付けられたネットワークリソースを解放することが可能であると判定し、前記既存のＵＥセッションはＵＥと関連付けられていると判定し、
    前記既存のＵＥセッションに関連する情報のサブセットを識別し、前記ＵＥと関連付けられた新たなＵＥセッションを作成するために前記情報のサブセットを使用することができると識別し、
    前記情報のサブセットを記憶し、
    １つ以上のネットワークノードにおいて、前記既存のＵＥセッションと関連付けられたネットワークリソースを解放するメッセージを前記１つ以上のネットワークノードに送信し、前記ＵＥは前記解放を通知されず、
    前記ＵＥにデータを転送する要求を受信し、
    前記記憶されたセッション情報のサブセットを使用して新たなＵＥセッションを作成し、前記１つ以上のネットワークノードにおいて前記新たなＵＥセッションと関連付けられたネットワークリソースを確立し、かつ
    前記新たなＵＥセッションを使用して前記ＵＥに前記データを転送するように構成されたネットワークノードを含む、非一時的コンピュータ可読媒体。
16. 前記既存のＵＥセッションと関連付けられた前記ネットワークリソースを解放することが可能であるとの前記判定が、基準のセットのうちの１つ以上の基準に基づいており、前記基準のセットが、
    一人以上の加入者が非アクティブである期間と、
    セッション期間を特定する認証、認可、および課金（「ＡＡＡ」）サーバーからの情報と、
    特定のリソースが使用中である期間と、
    ネットワーク負荷と、
    最近最も使用されていないアルゴリズムと、
    所定の閾値を超過する容量と、
    最近最も使用されていない１つ以上のリソースの識別情報と、を含む、請求項１５に記載の非一時的コンピュータ可読媒体。
17. 前記情報のサブセットが、ＵＥ ＩＰ Ａｄｄｒｅｓｓと、Ｐａｇｅ情報と、モビリティ管理エンティティ（ＭＭＥ）／サービングゲートウェイ（ＳＧＷ）情報とを含む、請求項１５に記載の非一時的コンピュータ可読媒体。
18. 前記メッセージが解放原因コードを含む、請求項１５に記載の非一時的コンピュータ可読媒体。
19. 前記解放原因コードが、前記１つ以上のネットワークノードに、前記１つ以上のネットワークノードにおいて、前記既存のＵＥセッションと関連付けられたネットワークリソースを解放して、前記ＵＥへの前記解放の通知を保留するように、指示する、請求項１５に記載の非一時的コンピュータ可読媒体。
20. 前記ネットワークノードが、パケットゲートウェイ（「ＰＧＷ」）またはＰＧＷに接続されたノードを含む、請求項１５に記載の非一時的コンピュータ可読媒体。
21. 前記情報のサブセットの前記記憶することが、セッションデータベースに情報を記憶することを含む、請求項１５に記載の非一時的コンピュータ可読媒体。
22. 通信ネットワーク内のグループに属する一人以上の加入者にデータリソースを許可する非一時的コンピュータ可読媒体であって、前記通信ネットワークが、
    オンライン課金セッションを作成する要求を受信し、前記要求が一人以上の加入者と関連付けられている指定ユーザーグループ（「ＤＵＧ」）を識別し、
    前記ＤＵＧが既存のオンライン課金セッションと関連付けられているかどうかを判定し、
    前記ＤＵＧと関連付けられた既存のオンライン課金セッションがない場合に、新たなオンライン課金セッションを要求するオンライン課金ノードに前記ＤＵＧを識別するメッセージを送信し、前記ＤＵＧに割り当てられたポリシーデータを前記オンライン課金ノードから受信し、
    既存のオンライン課金セッションが前記ＤＵＧと関連付けられている場合に、前記ＤＵＧに以前に割り当てられたポリシーデータを読み出し、かつ
    前記ポリシーデータに基づいて前記一人以上の加入者にデータリソースを許可し、前記データリソースが前記一人以上の加入者によって共有されるように構成されたネットワークノードを含む、非一時的コンピュータ可読媒体。
23. 前記ポリシーデータが１つ以上のクォータを含み、各クォータが１つ以上のサービスまたはレーティンググループと関連付けられている、請求項２２に記載の非一時的コンピュータ可読媒体。
24. 前記オンライン課金ノードが、オンライン課金システム（「ＯＣＳ」）サーバーまたはポリシー制御および課金ルール機能（「ＰＣＲＦ」）サーバーである、請求項２２に記載の非一時的コンピュータ可読媒体。
25. 前記ネットワークノードが、前記ポリシーデータをキャッシュするように更に構成されている、請求項２２に記載の非一時的コンピュータ可読媒体。
26. 前記ネットワークノードが、所定の時間間隔に基づいて前記ポリシーデータに対する更新をチェックするように更に構成されている、請求項２５に記載の非一時的コンピュータ可読媒体。
27. 前記ネットワークノードが、前記セッションを削除する要求が、前記ＤＵＧと関連付けられた最新の加入者と関連付けられている場合にのみ、前記オンライン課金セッションを削除するように更に構成されている、請求項２２に記載の非一時的コンピュータ可読媒体。

Images