(57)【特許請求の範囲】
【請求項１】
通信ネットワークのポリシー・課金システムにおけるネットワークリソースを管理するための方法であって、
第１ノードのサーバリソースの状態についての表示を第２ノードにおいて受信するステップと、
クライアントと前記第２ノードとの間の接続に関連するサービスセッションの活動が、活動閾値より低いか否かを判定するステップと、
前記活動が前記活動閾値より低いと判定された場合に、前記サービスセッションに割り当てられたベアラリソースの停止を指示するステップと
を含む、方法。
【請求項２】
通信ネットワークのポリシー・課金システムにおけるネットワークリソースを管理するための方法であって、
第１ノードのサーバリソースの状態を検出するステップと、
前記第１ノードにおける前記サーバリソースの前記状態についての表示を第２ノードに送信するステップと、
サービスセッションに割り当てられたベアラリソースの停止の要求を受信するステップであって、前記サービスセッションに対して前記第２ノードが、クライアントと前記第２ノードとの間の接続に関連する前記サービスセッションの活動が活動閾値より低いと判定した、ステップと
を含む、方法。
【請求項３】
前記第１ノードにおいて、前記第２ノードにおける前記表示を受信するべくサブスクライブするステップ
を更に含む、請求項１に記載の方法。
【請求項４】
前記第２ノードがアプリケーション機能ＡＦを含む、又は、前記第１ノードがポリシー・課金規則機能ＰＣＲＦを含む、請求項１乃至３のいずれか一項に記載の方法。
【請求項５】
前記サービスセッションの前記活動が、前記サービスセッションに割り当てられた前記ベアラリソースのデータトラフィック及び保証ビットレートの少なくとも１つに依存する、請求項１乃至４のいずれか一項に記載の方法。
【請求項６】
前記判定の前の一定期間において検出された前記サービスセッションのデータトラフィックが所定の閾値より低い場合、又は、前記判定の前の一定期間において検出されたデータトラフィックと保証ビットレートとの比率が所定の閾値より低い場合、前記サービスセッションの前記活動が不活動閾値より低くなる、請求項１乃至５のいずれか一項に記載の方法。
【請求項７】
前記サービスセッションの前記活動が活動閾値より低いと判定された場合、前記サービスセッションが除去される、請求項１乃至６のいずれか一項に記載の方法。
【請求項８】
前記サーバリソースが前記第１ノードのサーバのストレージを構成し、前記サーバリソースの前記状態が前記第１ノードにおける利用可能なストレージ容量を表示する、請求項１乃至７のいずれか一項に記載の方法。
【請求項９】
前記サーバの前記ストレージの使用量が閾値に達した場合、前記表示が通信される、請求項８に記載の方法。
【請求項１０】
前記ベアラリソースが前記サービスセッション専用のベアラであり、前記サービスセッションが、複数のベアラのなかの前記専用のベアラにマッピングされる、とする請求項１乃至９のいずれか一項に記載の方法。
【請求項１１】
前記第１ノードにおける前記サーバリソースの前記状態についての前記表示を前記第２ノードにおいて受信するステップと、
前記サービスセッションの前記活動が活動閾値より低いか否かを判定するステップと、
前記サービスセッションの前記活動が前記活動閾値より低いと判定された場合に、前記サービスセッションに割り当てられた前記ベアラリソースの前記停止を指示するステップと
を更に含む、請求項２に記載の方法。
【請求項１２】
通信ネットワークのポリシー・課金システムにおけるネットワークリソースを管理するための方法であって、前記方法は、不活動タイマを有するノードによって実施され、かつ
少なくとも１つのクライアントとノードとの間の接続に関連する複数のサービスセッションのなかの少なくとも１つのサービスセッションの活動が活動閾値より低いか否かを周期的に判定するステップと、
前記少なくとも１つのサービスセッションの前記活動が前記活動閾値より低い場合に、前記少なくとも１つのサービスセッションに割り当てられたベアラリソースの停止を指示するステップとを含み、
前記サービスセッションの前記活動が判定される期間の長さが、前記不活動タイマによって設定された期間より短い、方法。
【請求項１３】
前記複数のサービスセッションのなかで最長の不活動を有するサービスセッションに割り当てられた前記ベアラリソースの停止が指示される、請求項１２に記載の方法。
【請求項１４】
通信ネットワークのポリシー・課金システムにおけるネットワークリソースを管理するためのノードであって、
別のノードのサーバリソースの状態についての表示を受信するべく構成された受信器と、
クライアントと前記ノードとの間の接続に関連するサービスセッションの活動が、活動閾値より低いか否かを判定するべく構成された判定器と、
前記活動が前記活動閾値より低いと判定された場合に、前記サービスセッションに割り当てられたベアラリソースの停止を指示するべく構成された停止指示器と
を備える、ノード。
【請求項１５】
通信ネットワークのポリシー・課金システムにおけるネットワークリソースを管理するためのノードであって、
前記ノードのサーバリソースの状態を検出するべく構成された検出器と、
前記ノードにおける前記サーバリソースの前記状態についての表示を別のノードに送信するべく構成された送信器と、
サービスセッションに割り当てられたベアラリソースの停止の要求を受信するべく構成された受信器であって、前記サービスセッションに対して前記別のノードが、クライアントと前記別のノードとの間の接続に関連するサービスセッションの活動が活動閾値より低いと判定した、受信器と
を備える、ノード。
【請求項１６】
通信ネットワークのポリシー・課金システムにおけるネットワークリソースを管理するためのノードであって、
不活動タイマと、
少なくとも１つのクライアントと前記ノードとの間の接続に関連する複数のサービスセッションのなかの少なくとも１つのサービスセッションの活動が活動閾値より低いか否かを周期的に判定するべく構成された判定器と、
前記少なくとも１つのサービスセッションの前記活動が前記活動閾値より低い場合に、前記少なくとも１つのサービスセッションに割り当てられたベアラリソースの停止を指示するべく構成された停止指示器とを備え、
前記サービスセッションの前記活動が判定される期間の長さが、前記不活動タイマによって設定された期間より短い、ノード。
【請求項１７】
請求項１４の前記ノードと、請求項１５の前記ノードとを備えるシステム。
【請求項１８】
データプロセッサ上で実行されるとき、前記データプロセッサに、請求項１乃至１３のいずれか一項に記載の方法を実行させるべく構成された命令を含むコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークのポリシー・課金システムにおけるネットワークリソースを管理するための方法及びノードに関し、それとともに、少なくとも１つの前記ノードを備えるシステム、並びに電気通信ネットワークのリソースを最適化するためのコンピュータプログラムに関する。
【背景技術】
【０００２】
電気通信ネットワーク等の通信ネットワークにおいて、コール又はサービスには多くの場合、一方で制御プレーン又はシグナリングプレーンが関与し、他方でユーザプレーン又はメディアプレーンが関与する。制御プレーン又はシグナリングプレーンは、ネットワークの２点間の接続を確立し、それを管理する役目を担う。ユーザプレーン又はメディアプレーンは、ユーザデータ又はサービスデータを移送する役目を担う。ネットワークオペレータは、ネットワークにおける規則の組を定義し、実施することを望む。規則の組はポリシーを構成する。これらのポリシーを管理し、実施するためのポリシーフレームワークは、通常少なくとも３つの要素又は機能、即ちユーザ固有であり得るポリシー規則を格納するためのポリシーリポジトリ、ポリシー決定要素又は機能、及びポリシー実施要素又は機能を有する。ポリシーフレームワークの目的は、ネットワーク及びサービスへのサブスクライバアクセス、並びにアクセスの種類即ちその特性を制御することである。
【０００３】
ポリシーフレームワークは、とりわけ、サブスクライバがサービスを享受する権限又は承認を有しているか否か、及びネットワークがサブスクライバに対しサービスを提供可能か否か、特にネットワークがサブスクライバに対しサービスを所望のサービスの質（ＱｏＳ）をもって提供可能か否かについての決定を取り扱う。
【０００４】
ポリシー・課金制御アーキテクチャ、例えば以下に限定されないが、３ＧＰＰ  ＴＳ  ２３．２０３  ｖｅｒｓｉｏｎ  １１．１．０（２０１１−０３），Ｔｅｃｈｎｉｃａｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｇｒｏｕｐ  Ｓｅｒｖｉｃｅｓ  ａｎｄ  Ｓｙｓｔｅｍ  Ａｓｐｅｃｔｓに記載のアーキテクチャである、ポリシー・課金制御アーキテクチャ（リリース１１）（ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇ／ｆｔｐ／Ｓｐｅｃｓ／２０１１−０３／Ｒｅｌ−１１／２３＿ｓｅｒｉｅｓ／で入手可）等は、ポリシー・課金制御を統合する。ポリシー・課金制御（ＰＣＣ）アーキテクチャにより、ポリシーと課金制御の両方を統合することが可能となる。ポリシーフレームワークの目的の１つは、サブスクライバ及び／又は所望のサービスに応じて規則をセットアップ及び実施し、全サブスクライバのなかでのネットワークリソースの効率的な使用を確保することである。
【０００５】
ポリシー・課金制御（ＰＣＣ）機能をサポートするアーキテクチャが図１に示されており、これは３ＧＰＰアクセスと非３ＧＰＰアクセスの両方を含むＥｖｏｌｖｅｄ  ３ＧＰＰパケット交換ドメインのためのＰＣＣ機能を特定する３ＧＰＰ  ＴＳ  ２３．２０３から得られたものである。ポリシー・課金制御規則機能（ＰＣＲＦ）１１０は、ポリシー制御決定及びフローベース課金制御の機能性を包含する機能要素である。ＰＣＲＦは、ポリシー・課金実施機能（ＰＣＥＦ）１２０に対するサービスデータフロー（ＳＤＦ）検出、ゲーティング、ＱｏＳ及びフローベース課金（クレジット管理除く）に関するネットワーク制御を提供する。ＰＣＲＦは、アプリケーション機能（ＡＦ）１４０からの情報に関連するセッション及び媒体を受け取り、そのＡＦをトラフィックプレーンイベントに通知する。ＰＣＲＦ１１０はまた、サブスクライバプロフィールリポジトリ（ＳＰＲ）１５０にも接続されている。
【０００６】
ＰＣＲＦは、Ｇｘ参照ポイントを介してＰＣＣ規則をＰＣＥＦにプロビジョニングするものであり、Ｓ７ｘ参照ポイントを介してＱｏＳ規則をベアラ結合及びイベントレポーティング機能（ＢＢＥＲＦ）１３０にプロビジョニングしてもよい。
【０００７】
図１のアーキテクチャ１００では、ＰＣＲＦが、ＰＣＲＦポリシー決定に基づいて、ＰＣＣ制御の下にある各サービスデータフローの処理についてのＰＣＣ規則の使用によってＰＣＥＦを通知するものとしている。
【０００８】
例えば、ＰＣＲＦは、ネットワークにおけるトラフィックを構成するＡＰパケットがベアラリソースに割り当てられ得る場合に電気通信ネットワークの無線リソースをどのように制御するかについて、ＰＣＣ規則の使用によってＰＣＥＦに通知する。
【０００９】
Ｇｘ参照ポイント又はインタフェースは、３ＧＰＰ  ＴＳ  ２９．２１２”Ｐｏｌｉｃｙ  ａｎｄ  ｃｈａｒｇｉｎｇ  ｃｏｎｔｒｏｌ  ｏｖｅｒ  Ｇｘ  ｒｅｆｅｒｅｎｃｅ  ｐｏｉｎｔ”に定義され、ＰＣＲＦとＰＣＥＦとの間に存在する。参照ポイントは、ＰＣＲＦからＰＣＥＦへＰＣＣ規則をプロビジョニング及び除去するため、及びＰＣＥＦからＰＣＲＦへトラフィックプレーンイベントを移送するために用いられる。Ｇｘ参照ポイントは、課金制御、ポリシー制御、又はその両方のために用いることができる。
【００１０】
Ｒｘ参照ポイントは、３ＧＰＰ  ＴＳ  ２９．２１４”Ｐｏｌｉｃｙ  ａｎｄ  ｃｈａｒｇｉｎｇ  ｃｏｎｔｒｏｌ  ｏｖｅｒ  Ｒｘ  ｒｅｆｅｒｅｎｃｅ  ｐｏｉｎｔ”に定義され、ＰＣＲＦとＡＦとの間でアプリケーションレベルセッション情報を交換するために用いられる。ＰＣＲＦの一例として、エリクソン・サービスアウェアポリシーコントローラ（ＳＡＰＣ）が挙げられ、これについて、例えばＦ．Ｃａｓｔｒｏ  ｅｔ  ａｌ．，”ＳＡＰＣ：Ｅｒｉｃｓｓｏｎ’ｓ  Ｃｏｎｖｅｒｇｅｎｔ  Ｐｏｌｉｃｙ  Ｃｏｎｔｒｏｌｌｅｒ”，Ｅｒｉｃｓｓｏｎ  ｒｅｖｉｅｗ  Ｎｏ．１，２０１０，ｐｐ．４−９を参照されたい。ＡＦの一例として、ＩＰマルチメディアサブシステム（ＩＭＳ）プロキシコールセッション制御機能（Ｐ−ＣＳＣＦ）が挙げられる。
【００１１】
図１におけるＳｄ参照ポイントは、Ｒｘ参照ポイントと類似の挙動を有し得る。これは以下に説明するが、そこではＡＦとＴＤＦを、少なくとも本出願に記載の目的のためには、基本的に同じ意味で用いることができる。
【００１２】
Ｇｘ参照ポイントとＲｘ参照ポイントの両方はＤＩＡＭＥＴＥＲに基づいたものであり得、これについては例えば、Ｐ．Ｃａｌｈｏｕｎ  ｅｔ  ａｌ．，”ＲＦＣ  ３５８８：Ｄｉａｍｅｔｅｒ  Ｂａｓｅｄ  Ｐｒｏｔｏｃｏｌ”，ＩＥＴＦ，Ｓｅｐｔｅｍｂｅｒ  ２００３を参照されたい。
【００１３】
ＰＣＥＦは、ＰＣＲＦから受け取ったポリシー決定を実施し、またＰＣＲＦに対しＧｘ参照ポイントを介してユーザ固有及びアクセス固有情報を供給する。ＰＣＥＦ又は他のベアラ結合機能（ＢＢＦ）を含むノードは、ＰＣＣ規則に含められたフィルタ定義に基づくＳＤＦ検出とともに、オンライン及びオフライン課金の対話（本明細書では説明しない）及びポリシーの実施を包含する。ＰＣＥＦは通常は１つのハンドリングベアラであり、そこではＱｏＳが、ＰＣＲＦから入ってきたＱｏＳ情報に従ってそのベアラのために実施される。この機能エンティティ即ちＰＣＥＦは、ゲートウェイに、例えばＧＰＲＳの場合ではゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）に位置している。コアネットワークにプロキシモバイルＩＰ（ＰＭＩＰ）又はデュアルスタックモバイルＩＰ（ＤＳＭＩＰ）が存在する場合は常に、代わりにＢＢＥＲＦにおいてベアラ制御が実施される。
【００１４】
アプリケーション機能（ＡＦ）１４０は、サービスが要求された層（例えばシグナリング層）とは異なる層（例えばトランスポート層）にサービスを提供するアプリケーションを提供する要素である。リソース、例えば限定されないがＩＰベアラリソース等の制御は、取り決められた内容に従って実施される。ＡＦ１４０を含むネットワークノードの一例は、ＩＰマルチメディア（ＩＭ）コアネットワーク（ＣＮ）サブシステムのＰ−ＣＳＣＦ（プロキシコールセッション制御機能）である。ＡＦ１４０はＰＣＲＦ１１０と通信して、ダイナミックセッション情報、即ちトランスポート層に配信されるべきマルチメディアの記述を転送してもよい。この通信は、ＰＣＲＦ１１０とＡＦ１４０との間に置かれ、ＰＣＲＦ１１０とＡＦ１４０との間のアプリケーションレベルの情報を交換するために用いられる上述のＲｘインタフェース又はＲｘ参照ポイントを用いて行われる。Ｒｘインタフェースにおける情報は、Ｐ−ＣＳＣＦにおけるセッション情報又はサービスセッション情報に由来するものであってよく、いわゆるメディアコンポーネントを主として有する。メディアコンポーネントは、各々が５タプルにわたって例えばメディアの種類及び必要な帯域幅を記述しているＩＰフローの組によって構成される。ＡＦ１４０を備えるネットワークノードの別の例として、ストリーミングサーバが挙げられる。
【００１５】
ＡＦは、ダイナミックポリシー及び課金制御を要求するアプリケーションと対話又はそれに介入し得る。ＡＦはサービスセッション情報を抽出し、これをＲｘ参照ポイントを介してＰＣＲＦに供給する。ＡＦはまた、トラフィックプレーンで発生する一定のイベント即ちＰＣＲＦまたはＢＢＥＲＦのいずれかによって検出されるイベントをサブスクライブすることができる。それらのトラフィックプレーンイベントには、ＩＰセッションの停止またはアクセス技術タイプの変更が含まれる。
【００１６】
ＰＣＲＦ１１０は、サブスクリプションデータを得るべくＳＰＲ１５０に連絡することもできる。ＳＰＲは、サブスクライバ及びそのポリシーについての情報を含み得る。ユーザが「プレミアム」サブスクライバであり、永久的に平均的ユーザより広い帯域幅を有することができる場合には、このユーザのユーザセッションは高いＱｏＳをもって接続される。
【００１７】
ＰＣＲＦからＰＣＣ／ＱｏＳ規則を受け取った後、配置シナリオに応じてＰＣＥＦ又はＢＢＥＲＦのいずれかであるベアラ結合機能（ＢＢＦ）は、ベアラ結合を行う、即ちＩＰ−ＣＡＮ（インターネットプロトコル接続アクセスネットワーク）セッションの範囲内で与えられた規則をＩＰ−ＣＡＮベアラに関連付ける。ＢＢＦは、ＰＣＲＦによって提供されるＱｏＳパラメータを用いて、その規則のためのベアラ結合を生成することになる。その結合は、ＰＣＣ／ＱｏＳ規則に含められるサービスデータフローと、同じＱｏＳクラス識別子（ＱＣＩ）及びアロケーションリテンションプライオリティ（ＡＲＰ）を有するＩＰ−ＣＡＮベアラとの間で生成される。
【００１８】
一般的に、ベアラ結合機能は、既存のＩＰ−ＣＡＮベアラの１つを用いることが可能であるか否かを評価するものである。既存のベアラのいずれも用いることができない場合、適切なＩＰ−ＣＡＮベアラの確立が開始されることになる。そうでない場合、必要であれば、例えばＱｏＳ情報が変化したときには、ＢＢＦが対応するベアラの改変を開始することになる。ＧＢＲベアラ即ち保証ビットレートを有するベアラの場合、ＢＢＦは、ＰＣＲＦから提供されたＱｏＳ情報に基づいて必要なリソースを用意しておく。
【００１９】
ＰＣＣ／ＱｏＳ規則のＱＣＩ及びＡＲＰが、デフォルトベアラのＱＣＩ及びＡＲＰに一致した場合には、ＢＢＦはデフォルトベアラにそれらの規則をインストールする。ＰＣＲＦが、以前に提供されたＰＣＣ／ＱｏＳ規則の除去を要求したとき、ＢＢＦはそれらを削除し、ベアラを然るべく改変する。１つのベアラに適用された全てのＰＣＣ／ＱｏＳ規則が削除及び／又は非活動化されたときには、ＢＢＦはベアラ停止手順を開始する。
【００２０】
次に、アプリケーションに対するＰＣＣサポートについて説明する。アプリケーションが、サービスセッションを開始させるべくＩＰ−ＣＡＮユーザプレーンを介してダイナミックポリシー及び／又は課金制御を要求すると、ＡＦはＰＣＲＦと通信して、ＰＣＲＦがＩＰ−ＣＡＮネットワークに対して適切なアクションをとるために必要なダイナミックセッション情報を転送する。ＰＣＲＦはセッション情報を承認し、対応するＰＣＣ／ＱｏＳ規則を生成し、それらをＰＣＥＦ／ＢＢＥＲＦにインストールする。適用可能なベアラが始動／改変され、必要ならばそのアプリケーションのためにリソースが準備される。
【００２１】
一旦アプリケーション又はユーザ端末（ＵＥ）がサービスの停止を決定すると、ＡＦはＰＣＲＦと通信して、ＰＣＲＦが適用可能なＰＣＣ／ＱｏＳ規則を除去できるようにし、ＰＣＥＦ／ＢＢＥＲＦが対応するＳＤＦ検出、ポリシー実施及びフローベース課金機能性を停止して、適用可能なベアラを停止又は更新し、かつ対応するリソースを解放する。
【００２２】
サービスアプリケーションを実行し、ＡＦを備える、例えばストリーミングサーバ等のアプリケーションサーバは、その要求、即ち特定の帯域幅、ＱｏＳ、課金等を要求するビデオ又は他のストリーミングサービスに基づいて、ＰＣＲＦのためのベアラの確立を要求することができる。
【００２３】
ディープ・パケット・インスペクション（ＤＰＩ）技術は、パケット検査及びサービス分類をサポートする。その分類は、ＩＰパケットが特定のサービスセッションに割り当てられるように構成された規則ツリーに基づいて分類されたＩＰパケットからなる。ＤＰＩは、いわゆるトラフィック検出機能（ＴＤＦ）として現在標準化されており、ＴＤＦ１６０等のＴＤＦは、スタンドアロンで又はＰＣＥＦとともに配置することができ（図１２ｂ及び図１２ｃ）、この場合トラフィックがこの機能によってパケット検査のために捕捉される。ＴＤＦ１６０は、アプリケーションの検出、検出されたアプリケーション又はサービス及びそのサービスデータフローの記述のＰＣＲＦへのレポーティングを行う機能エンティティである。ＴＤＦは、要請モードで、即ちＰＣＲＦから要求を受けたときに作動するか、または非要請モードで、即ちＰＣＲＦから要求がなくても作動することができる。ＴＤＦによって捕捉されたデータトラフィックは、通常はＩＰパケットデータである。詳細については、３ＧＰＰ  ＴＲ  ２３．８１３を参照されたい。
【００２４】
現在、殆どの既存のＵＥ、即ち携帯電話や、タブレットやラップトップコンピュータ等の他の移動通信能力を備えたモバイルデバイスは、専用ベアラに対するサポートを有していない。したがって、殆どのトラフィック即ちユーザが実行させているサービスのデータトラフィックは、デフォルトベアラに入ってゆき、ユーザが実行させている各々のサービスのために異なるＱｏＳを割り当てることはできない。しかし、将来的には、１つ又はそれ以上のサービスのサービスセッションのより多くが、専用ベアラにマッピングされることが予想される。
【００２５】
長期間継続する専用ベアラを、例えばスポンサー提供サービスのためのＱｏＳを増強するために用いることは、特に専用ベアラがＡＦ、例えばＭｏｂｉｌｅ  Ｃｌｏｕｄ  Ａｃｃｅｌｅｒａｔｏｒ（ＭＣＡ）ソリューションにおけるＳｍａｒｔ  Ｐｉｐｅ  Ｃｏｎｔｒｏｌｌｅｒ（ＳＰＣ）によってトリガされる場合には、ネットワークリソースに対する要求が高くなることを意味する。
【００２６】
ＡＦセッションは、対応するサービスが活動状態である限り活動状態のままである。ＲＴＳＴのようないくつかのサービス／プロトコルは、それ自身のシグナリング（ＲＴＳＰ．ＴＥＡＲＤＯＷＮ）においてサービス停止条件を示すが、ＨＴＴＰブラウジング等、サービスの大半はそのような表示を有しておらず、サービス停止条件は、ＡＦノードによってローカルにハンドリングされる不活動タイマに基づいたものである必要がある。これは、３ＧＰＰには定義されていない内部的なＡＦ機能であるが、外部への効果は、このイベント（サービス停止）がＡＦセッションの停止をトリガするために用いられることである。これらの不活動タイマは、主としてネットワークシグナリングを低減させるため、即ちタイマが低い値に設定されている場合に生ずるピンポン効果を回避するために、通常は非常に高い値、例えば数１０分又は数１００分程度に設定される。この場合、サービス不活動の検出によって専用ベアラの解放がトリガされるが、ある時間の経過後にいくつかのサービスパケットが検出されると、専用ベアラが再度生成される必要が生ずる。
【発明の概要】
【発明が解決しようとする課題】
【００２７】
シグナリングを低減させるために、専用ベアラは長時間にわたって保持される。不活動タイマを非常に高い値に設定することは、ユーザが対応するサービスをそれ以上実行しない場合であっても、ＡＦセッションが長時間にわたって活動状態のままであることを意味する。ＡＦセッションを長時間にわたって活動状態にしておくことは、例えば多数のユーザの１００万以上に達するセッション情報エントリを保持しておかなければならないＡＦとＰＣＲＦメモリの両方に影響を及ぼす。これによって、メモリ等のネットワークリソースの無駄が生じ得ることになる。したがって、例えばメモリ使用量を低減させるようにネットワークリソースを最適化する要望が存在する。
【課題を解決するための手段】
【００２８】
方法、ノード、システム、及びコンピュータプログラムは、独立請求項に定義されている。有利な実施形態は、従属請求項に定義されている。
【００２９】
一実施形態では、通信ネットワークのポリシー・課金システムにおけるネットワークリソースを管理するための方法が、第１ノードのサーバリソースの状態についての表示を第２ノードにおいて受信するステップを含む。前記方法は、クライアントと前記第２ノードとの間の接続に関連するサービスセッションの活動が、活動閾値より低いか否かを判定するステップを更に含む。前記活動が前記活動閾値より低いと判定された場合に、前記サービスセッションに割り当てられたベアラリソースの停止が指示される。したがって、サーバリソース及びベアラリソース等のネットワークリソースを、そのネットワークリソースを最適化するように管理できる。例えば、メモリ領域不足を回避することができる。
【００３０】
一実施形態では、通信ネットワークのポリシー・課金システムにおけるネットワークリソースを管理するための方法が、第１ノードのサーバリソースの状態を検出するステップを含む。前記方法は、前記第１ノードにおける前記サーバリソースの前記状態についての表示を第２ノードに送信するステップと、前記第２ノードが、クライアントと前記第２ノードとの間の接続に関連するサービスセッションの活動が活動閾値より低いと判定したそのサービスセッションに割り当てられたベアラリソースの停止の要求を受信するステップとを更に含む。したがって、ベアラリソース及びサーバリソース等のネットワークリソースを、そのネットワークリソースを最適化するように管理できる。例えば、メモリ領域不足を回避することができる。
【００３１】
一実施形態では、通信ネットワークのポリシー・課金システムにおけるネットワークリソースを管理するための方法が提供され、前記方法は、不活動タイマを有するノードによって実施される。前記方法は、少なくとも１つのクライアントとノードとの間の接続に関連する複数のサービスセッションのなかの少なくとも１つのサービスセッションの活動が活動閾値より低いか否かを周期的に判定するステップを含む。前記少なくとも１つのサービスセッションの前記活動が前記活動閾値より低い場合に、前記少なくとも１つのサービスセッションに割り当てられたベアラリソースの停止が指示され、前記サービスセッションの前記活動が判定される期間の長さは、前記不活動タイマによって設定された期間より短い。したがって、例えば前記第１ノードのサーバリソースの状態についての表示を含む明示的な要求なしにネットワークリソースを最適化することさえ可能である。このため、上記のメカニズムは、ＡＦノード等のノードにローカルに実現することが可能である。
【００３２】
一実施形態では、通信ネットワークのポリシー・課金システムにおけるネットワークリソースを管理するためのノードが提供される。前記ノードは、別のノードのサーバリソースの状態についての表示を受信するべく構成された受信器と、クライアントと前記ノードとの間の接続に関連するサービスセッションの活動が、活動閾値より低いか否かを判定するべく構成された判定器とを備える。前記ノードは、前記活動が前記活動閾値より低いと判定された場合に、前記サービスセッションに割り当てられたベアラリソースの停止を指示するべく構成された停止指示器を更に備える。したがって、ベアラリソース及びサーバリソース等のネットワークリソースを、そのネットワークリソースを最適化するように管理できる。
【００３３】
一実施形態では、通信ネットワークのポリシー・課金システムにおけるネットワークリソースを管理するためのノードが提供される。前記ノードは、前記ノードのサーバリソースの状態を検出するべく構成された検出器と、前記ノードにおける前記サーバリソースの前記状態についての表示を別のノードに送信するべく構成された送信器とを備える。更に前記ノードは、前記別のノードがクライアントと前記別のノードとの間の接続に関連するサービスセッションの活動が活動閾値より低いと判定したそのサービスセッションに割り当てられたベアラリソースの停止の要求を受信するべく構成された受信器を備える。したがって、ベアラリソース及びサーバリソース等のネットワークリソースを、そのネットワークリソースを最適化するように管理できる。
【００３４】
一実施形態では、通信ネットワークのポリシー・課金システムにおけるネットワークリソースを管理するためのノードが提供され、前記ノードは、活動タイマとともに、少なくとも１つのクライアントとノードとの間の接続に関連する複数のサービスセッションのなかの少なくとも１つのサービスセッションの活動が活動閾値より低いか否かを周期的に判定するべく構成された判定器を備える。前記ノードは、前記少なくとも１つのサービスセッションの前記活動が前記活動閾値より低い場合に、前記少なくとも１つのサービスセッションに割り当てられたベアラリソースの停止を指示するべく構成された停止指示器を更に備え、前記サービスセッションの前記活動が判定される期間の長さは、前記不活動タイマによって設定された期間より短い。したがって、例えば前記第１ノードのサーバリソースの状態についての表示を含む明示的な要求なしにネットワークリソースを最適化することさえ可能である。このため、上記のメカニズムは、ＡＦノード等のノードにローカルに実現することが可能である。
【００３５】
別の実施形態では、前記ノードの少なくとも１つを備えるシステムが提供される。
【００３６】
別の実施形態では、データプロセッサ上で実行されるとき、前記データプロセッサに、上記の方法のいずれか１つを実行させるべく構成された命令を含むコンピュータプログラムが提供される。
【００３７】
本発明の更に有利な実施形態は、従属請求項に開示されている。
【図面の簡単な説明】
【００３８】
【図１】図１は、本発明の実施形態が適用され得る例示的な状況を読者が理解するのを助ける、例示的なＰＣＣアーキテクチャを示す図である。
【図２】図２は、或る実施形態によるネットワークリソースを管理するための方法の作業工程を示す図である。
【図３】図３は、図２の実施と組み合わせることもできる特定の作業工程を示す図である。
【図４】図４は、別の実施形態によるネットワークリソースを管理するための方法の作業工程を示す図である。
【図５】図５は、別の実施形態によるネットワークリソースを管理するための方法の作業工程を示す図である。
【図６】図６は、或る実施形態によるネットワークリソースを管理するべく構成されたノードの要素を示す図である。
【図７】図７は、別の実施形態によるネットワークリソースを管理するべく構成された別のノードの要素を示す図である。
【図８】図８は、別の実施形態によるネットワークリソースを管理するべく構成された別のノードの要素を示す図である。
【図９】図９は、特定アクション（Ｓｐｅｃｉｆｉｃ−Ａｃｔｉｏｎ）ＡＶＰの拡張に基づく実施形態による例示的な方法を示す図である。
【図１０】図１０は、中断原因（Ａｂｏｒｔ−Ｃａｕｓｅ）ＡＶＰに基づく実施形態による例示的な方法を示す図である。
【図１１】図１１は、ＵＥのクライアントとＡＦのサービスとの間のベアラに関連するサービスセッションの説明図である。
【図１２ａ】図１２ａは、ＡＦがＰＣＲＦと通信するＡＦシナリオを示す図であり、
【図１２ｂ】図１２ｂは、スタンドアロンＴＤＦを用いるシナリオを示す図であり、
【図１２ｃ】図１２ｃは、ＰＣＥＦとともに配置されるＴＤＦを用いるシナリオを示す図である。
【発明を実施するための形態】
【００３９】
以下、本発明の実施形態について図面を参照して説明する。以下の記載は例示のみを含んでおり、発明を限定するものとして解するべきではないことに留意されたい。以下の記載においては、類似の又は同一の参照符号は、類似の又は同一の要素又は作業工程を示す。
【００４０】
本発明の実施形態を読者が理解するのを助けるために、図１のＰＣＣアーキテクチャを参照することによって実施例を説明する。上述のように、図１に記載された機能は、ポリシー・課金システムのノードであるか、又はノードに配置されたものであり得、かつ当分野において知られている適切なサーバ、ルータ、コンピュータ、それらの組み合わせ等によって実現され得る機能要素である。以下の説明においては、ＰＣＲＦを備えるノード及びＡＦを備えるノードは、それぞれＰＣＲＦノード及びＡＦノードとも称する。
【００４１】
図２は、通信ネットワークのポリシー・課金システムにおけるネットワークリソースを管理するための方法の流れ図を示す。前記ポリシー・課金システムは、図１のＰＣＣアーキテクチャの１つ又は複数のノード、例えばＰＣＲＦ、ＰＣＥＦ及びＡＦ及び／又はＴＤＦ等を備え得る。前記方法のステップは、ポリシー・課金システムの少なくとも１つのノード、好ましくはＰＣＥＦとともに配置されたものか、又はスタンドアロンであり得るＡＦ又はＴＤＦによって実施され得る。
【００４２】
以下の図２の実施形態の説明においては、ＡＦ１４０を第２ノードの一例として、ＰＣＲＦ１１０を第１ノードの一例として使用する。ＡＦ１４０の代わりにＴＤＦ１６０も第２ノードとみなすことができ、又は第１ノード及び第２ノードの組み合わせも考えることができることを、当業者はすぐに認識されよう。
【００４３】
図２にみられるように、前記方法は、サーバリソースの状態についての表示を受信するステップ２１０を含む。例えば、その表示は、第２ノード、例えばＡＦ１４０又はＴＤＦ１６０によって受信され、第１ノード、例えばＰＣＲＦ１１０のサーバメモリ等のサーバリソースの状態についての表示である。
【００４４】
一般的に、第１ノード、例えばＰＣＲＦ１１０のサーバのメモリ又は処理能力であり得るサーバリソースを管理することが望まれる。例えば、メモリ使用量が一定の閾値、例えば８０％に達すると、ＰＣＲＦノードは、専用ベアラにマッピングされる全てのＡＦセッションが依然として必要であるかを問い合わせるために、ＡＦノードに通知を行う。
【００４５】
ステップ２２０では、クライアントと第２ノード（ＡＦ１４０又はＴＤＦ１６０）、特に第２ノードのサービスとの間の接続に関連するサービスセッションの活動が活動閾値より低いか否かが判定される。この判定は、受信した、サーバリソースの状態についての表示に応じたものであり得る。
【００４６】
サーバセッションの詳細について、ＵＥのクライアントとＡＦのサービスとが接続されている図１１を参照して説明する。ＵＥにはクライアントアプリケーション又は単にクライアントが含まれ、ＡＦにはサービスアプリケーション又は単にサービスが含まれ、そのサービスは単体で実行されるアプリケーションか、又は接続されたクライアント毎のコピーインスタンスのいずれかとして、複数のクライアントに利用可能なものであり得る。ここで、クライアントとサービスとの間の接続は、データが移送されるサービスセッションとみなすことができる。データを移送するために、ＵＥ又はＡＦのいずれかからの要求があったときベアラがセットアップされる。
【００４７】
サービスセッションの活動が活動閾値より低いと判定された場合、即ちサービスセッションが不活動状態であると考えられる場合には、処理はステップ２３０に移行し、ステップ２３０に示すように、そのサービスセッションに割り当てられたベアラリソースの停止が指示される。したがって、確保されていたベアラの処理能力を解放することができる。
【００４８】
しかし、ステップ２２０において、そのサービスセッションの活動が活動閾値より高いと判定された場合、即ちそのサービスセッションが活動状態にあると考えられる場合には、図２における処理はステップ２２０の前に戻り、別のサービスセッションが不活動状態であるか否か、又は一定期間経過後に同じサービスセッションが不活動状態であるか否かがチェックされる（ステップ２２０）。
【００４９】
ベアラリソースはそのサービスセッション専用のベアラであってもよく、サービスセッションは複数のベアラのなかの専用ベアラにマッピングされる。ステップ２３０で停止されたベアラリソースは、特定のサービスのために確立された、そのサービスセッションに関連するデータトラフィック（例えば特定のパケットフォワード処理を必要とするＩＰフローのためのデータトラフィック）を搬送するための専用ベアラであってよい。
【００５０】
例えば、ＡＦノードが直近の活動、例えば対応するサービスセッションのための直近Ｘ秒間（例えば６０秒）における活動を検出しなかった場合、ＡＦノードは内部的にそのサービスセッション及び対応するＡＦセッションを除去する。このとき、或るＡＦセッション（Ｒｘセッション）は１つのサービスセッションにマッピングされている。更に、一人のユーザが、２つの異なるサービス（サービスアプリケーション）、ＨＴＴＰブラウジングとＳｋｙｐｅを同時に活動状態としていてもよい。ＡＦノードが或るサービスを検出すると、それは検出された各サービスに対して１つのＡＦセッション（Ｒｘセッション）を、即ちＨＴＴＰのための１つのＡＦセッションと、Ｓｋｙｐｅのための１つのＡＦセッションとをトリガする。ユーザがＨＴＴＰブラウジングを止めたとき、ＨＴＴＰのためのＡＦセッションは除去され、ＳｋｙｐｅのためのＡＦセッションは、Ｓｋｙｐｅサービスが依然として行われている場合には継続させることができる。ここで、ＨＴＴＰサービスセッションのデータトラフィックを搬送するために専用ベアラが用いられている場合、この専用ベアラは停止させ除去することができるが、Ｓｋｙｐｅサービスセッションのための専用ベアラは維持される。したがって、使用されていないベアラは閉じて、メモリリソースを解放することができる。
【００５１】
具体的には、そのサービスセッションは、通常、対応するＡＦセッションの除去も行うＡＦノードによって除去される。そのサービスセッション及びＡＦセッションは、ＡＦノードにおける異なるモジュール（機能）によってハンドリングされてもよい。
【００５２】
しかし、ＡＦノードが対応するサービスセッションのための直近の活動、例えば直近のＸ秒間における活動を検出した場合には、ＡＦノードは、Ｓｋｙｐｅサービスセッションを維持する例の場合と同様に、そのサービスセッションも対応するＡＦセッションも除去しない。
【００５３】
上述の特定の実施例では、図２の方法がＡＦノードによって実施されている。しかし、前述のように、その方法は、ＴＤＦノード又は類似のノードによっても実施され得る。
【００５４】
以下に、サービスセッションが活動状態か不活動状態かを判定するための活動閾値の例を示す。例えば、サービスセッションは、そのサービスセッションに割り当てられたベアラにおけるデータトラフィックに依存するか、若しくはそのサービスセッションに割り当てられたベアラのデータトラフィック及び／又は保証ビットレートに依存する。
【００５５】
一実施例では、判定ステップ２２０の前の一定の期間に検出されたサービスセッションのデータトラフィックが、所定の閾値より低い、例えば特定のパケット数より小さい場合には、そのサービスセッションの活動が不活動閾値より低いものとなる。即ち、閾値は１００秒間における１０パケットとして定義され得る。別の実施例では、判定の前の一定の期間に検出されたデータトラフィックと保証ビットレートとの比率が所定の閾値より低い場合には、そのサービスセッションの活動が不活動閾値より低いものとなる。第１の実施例では、ベアラを、それらのデータトラフィックに応じてランク付けすることができる。第２の実施例では、ランク付けにおいて保証ビットレートも考慮に入れられる。前記一定の期間の長さに応じて、データトラフィックを平均データトラフィックと考えることもできることに留意されたい。データトラフィック又は比率が最小とランク付けされたベアラは、その後除去することができる。
【００５６】
上述のデータトラフィックは、ＴＤＦの機能であり得る、図１１に示すトラフィックフロー検出器によって検出することができる。活動の判定は特定のサービスの最後のパケットの格納されたタイムスタンプ上で行われてもよく、若しくはログファイルへのエントリをその判定のために用いてもよい。
【００５７】
したがって、サービスセッションの活動が活動閾値より低いと判定された場合には、そのサービスセッションは、例えば上述のＡＦによって除去される。より詳細には、ＡＦノードが、サービスセッション即ちＡＦ／ＴＤＦノードにおいてローカルにハンドリングされるサービスセッションに関連するコンテキスト／メモリ構造と、Ｒｘ  ＳＴＲメッセージをトリガすることによるＡＦセッションとの両方を除去し、ベアラリソース、例えば専用ベアラはＰＣＥＦによって除去され、即ちＡＦノードはそれを行うように指示するのみである。
【００５８】
サービスセッションが存在しない場合には、或るサービスに関連するデータトラフィックが存在せず、そのサービスは不活動状態であり、したがってベアラは不要であるともいえる。一方、活動状態のサービスセッションは非常にアクティブなデータ移送を必要とせず、クライアントとサービスとを接続するベアラを介して、ある時間にはデータトラフィックが存在しないこともあり得る。このとき異なるクライアントが異なるベアラを有していてもよい。一つの例は、ストリーミングバッファであって、それは高速で満たされ、次にバッファにおける低い閾値に達してそのバッファが再度高速で満たされるまでは、より低い速度で空にされる。したがって、数秒間、トラフィックのない状態になり得る。別の例は、毎分ポジションレポート要求とポジション回答が交換されるポジションクエリである。
【００５９】
データトラフィックが検出された場合、例えばトラフィックフロー検出器がクライアントとサービスとの間で移送される実際のパケットを検出した場合、サービスセッションが活動状態であるといえる。しかし、逆は必ずしも真ではない。すなわち短い期間または継続時間にデータトラフィックがないときに、サービスセッションが必ずしも不活動状態であるとは限らない。サービスセッションが依然として活動状態にあっても、データトラフィックは時折しか存在しないからである。したがって、上述のように、一定の期間にわたって、例えばパケット数等のデータトラフィックの解析をすることが有用であり得る。
【００６０】
活動を判定するためにデータトラフィックが検出される期間を設定するとき、その期間が短すぎる場合には、活動状態のセッションを中断し、かつ専用ベアラを解除してその専用ベアラが再度生成される必要があるようにできる、ということも考える必要がある。しかし、その期間が長すぎる場合には、専用ベアラは長時間維持され、その結果ネットワークリソースが浪費される。したがって、シグナリングとネットワークリソース、例えばＡＦ、ＰＣＲＦ、ＧＧＳＮ、ＲＮＣ、ＮｏｄｅＢ等のメモリとの間にはトレードオフの関係が存在し、本明細書に記載するスキームは、メモリ領域不足を避けるためのメカニズムとみなすこともできる。
【００６１】
ステップ２１０において、メモリ等のサーバリソースの状態についての表示が、第２ノード、例えばＡＦノード１４０によって受信されることが述べられている。図３に示すように、ＡＦノード１４０は、この表示を実際に受信するべく第１ノード、例えばＰＣＲＦノード１１０においてサブスクライブすることができる。図３のステップ３０５は、図２のステップ２１０〜２３０の前に実施することができる。このサブスクリプションについての詳細は、図９に関連付けて示す。
【００６２】
以下、第２ノード、例えばＡＦノード１４０と通信するとき、図２に関連付けて説明した方法について、第１ノード、例えばＰＣＲＦノード１１０の観点から図４に関連付けて説明する。
【００６３】
図４のステップは、第１ノードによって実施される作業工程であり、第１ノードは、以下の実施例では、ノード、例えば図１のノード１１０のようなＰＣＲＦを含むサーバである。前記方法は、上述した通信ネットワークのポリシー・課金システムにおけるネットワークリソースを管理し、かつステップ４１０においてサーバリソースの状態を検出する。上述のように、サーバリソースは、ＰＣＲＦを含むノードのサーバのメモリであり得る。
【００６４】
詳細には、サーバリソースが、第１ノード、例えばＰＣＲＦのサーバのストレージ又はメモリを構成してよく、またサーバリソースの状態は、第１ノードにおける利用可能なストレージ容量を示すものでよい。利用可能なストレージ容量は、依然として利用可能な、即ち残りのストレージ容量として定義することができ、例えばストレージ容量が８０％占有されている場合は２０％である。
【００６５】
ステップ４２０では、サーバリソースの状態についての表示が、第２ノード、例えばＡＦ１４０に送信され、第２ノードにサーバリソースの状態が通知される。例えば、上述のように、メモリ使用量が一定の閾値、例えば８０％に達したとき、ＰＣＲＦ１１０は、セッションを除去し、従ってベアラを除去できるか否かを問い合わせるためにＡＦ１４０に通知する。即ち、一実施例では、サーバのストレージの使用量が閾値、例えば８０％に達している場合にのみ表示が通信される。
【００６６】
ベアラリソースの停止が望まれることが第２ノードにおいて判定された場合、ステップ４３０に示すように、第２ノードがその活動が活動閾値より低いと判定したサービスセッションに割り当てられたベアラリソースの停止の要求が受信される。
【００６７】
以下、第１ノード及び第２ノードによって実施される方法の以前に説明した方法ステップについて、順番に説明する。即ち、両方のノードを含むシステムの方法を、第２ノードの一例としてＡＦノード１４０を、第１ノードの一例としてＰＣＲＦノード１１０を用いて説明する。
【００６８】
初めに、ノード１１０の上述のサーバリソースの状態がＰＣＲＦ１１０によって検出され、サーバリソースの状態についての表示がＡＦ１４０に送信される。
【００６９】
ＡＦ１４０は、ＰＣＲＦを含むノードのサーバリソースの状態についての表示を受信し、サービスセッションの活動が活動閾値より低いか否かが判定される。サービスセッションの活動が活動閾値より低いと判定された場合には、ＡＦ１４０は、サービスセッションに割り当てられたベアラリソースの停止を指示する。その指示プロセスは、例えば、ＰＣＲＦ１１０に停止の要求を送信することによって実施される。次に、ＡＦがサービスセッションの活動が活動閾値より低いと判定したサービスセッションに割り当てられたベアラリソースの停止の要求がＰＣＲＦ１１０において受信され、ＰＣＲＦ１１０はＰＣＥＦ１２０に対しそのベアラリソースを除去するように指示する。
【００７０】
サービスセッション、サービスセッションの活動、及び活動閾値の詳細な説明については、不要な繰り返しを避けるため、図２に関連付けた前述の記載を参照されたい。
【００７１】
ＰＣＲＦを含むノードがサーバリソースの状態を検出し、その表示をＡＦに送信し、もってサービスセッションの活動の判定をトリガする上述のスキームの代替的手法として、ＰＣＲＦに影響を与えない即ちＡＦを含むノードにおいてのみ変化が必要なソリューションも可能である。例えば、ＰＣＲＦからの明示的な要求がなくても、上記のメカニズムをＡＦノードにおいてローカルに実現することができる。基本的に、そのようなメカニズムを用いて、ＡＦノードは、対応するサービスセッションの直近の活動が減少したＡＦセッションを除去するために上述の「ガーベッジコレクション」メカニズムを周期的にトリガする。この代替的なメカニズムの利点は、ＰＣＲＦノードが関与せず、何ら変更される必要がないことであり、前述の第１のメカニズムの利点は、図２に示すように、必要なときにＰＣＲＦノードによって判定処理をトリガしさえすればよいことである。
【００７２】
以下、図５に関連付けて、ＰＣＲＦノードからの明示的な要求が必要でない代替的なメカニズムが設けられる、通信ネットワークのポリシー・課金システムにおけるネットワークリソースを管理するための方法の詳細について示す。
【００７３】
この方法は、ＡＦノードのような、不活動タイマを有するノード（代わりに、ＴＤＦノード又はゲートウェイを用いることもできる）において実施される。
【００７４】
第１ステップ５１０では、少なくとも１つのクライアントとノードとの間の接続に関連する複数のサービスセッションのなかの少なくとも１つのサービスセッションの活動が、活動閾値より低いか否かが周期的に判定される。ここで、周期的にとは、判定の間の期間が正確に同一であるとものとして理解すべきではなく、単に判定がある程度の期間をおいて反復して行われるという意味に解されたい。
【００７５】
このステップは、基本的にはステップ２２０に対応するが、判定はサーバリソースの状態についての表示を受信することによってトリガされず、例えば、同じ又は異なる時間間隔で周期的に判定を行うべくタイマによってトリガされる。活動が活動閾値より低いか否かの判定は、上述と同様である。即ち、トラフィックデータを検出することができ、又はタイムスタンプ又はログファイルを用いて活動を判定することができる。
【００７６】
少なくとも１つのサービスセッションの活動が活動閾値より低い場合、即ち少なくとも１つのサービスセッションが不活動状態である場合、図５のステップ５２０に示すように、このサービスセッションに割り当てられたベアラリソースの停止が指示される。
【００７７】
この実施例では、２つの異なる不活動タイマが設けられてもよい。レガシータイマとも呼ばれるより長時間のものと、上述のスキーム即ち「ガーベッジコレクション」メカニズムのためのより短時間のものである。より長時間の不活動タイマは、例えば、関連するベアラリソースの解放又は改変を開始する前のサービスデータフロー（ＳＤＦ）のために許容された不活動期間を示す数十分間の不活動の後に、停止をトリガし得る。加えて、サービスデータがモニタリングされてもよく、より短い期間、例えば１００秒間の経過後にサービスデータが検出されないと判定された場合には、ベアラがより早く不活動化されて、長時間の不活動タイマに従ってベアラに結合されたリソースが解放される前に不活動期間が示されるようにすることができる。
【００７８】
「ガーベッジコレクション」メカニズムは、必ずしも別の短時間不活動タイマに基づくものである必要はなく、代わりに、対応するサービスセッションの直近の活動が少ない既存のＡＦセッションの一定のパーセンテージを周期的に除去するもののような、より一般的なメカニズムであってもよいことは理解されよう。
【００７９】
例えば、複数のサービスセッションのなかの最長の不活動を有するサービスセッションに割り当てられたベアラリソースの停止を指示して、最長の期間不活動状態のサービスセッションが除去されるようにすることができる。
【００８０】
図６は、或る実施形態によるＡＦ又はＴＤＦを実現するべく構成されたノード６００の要素を示す。ノード６００は、上述の機能の少なくともいくつか、特に図２に関連付けて説明したステップを実施するためのプロセッサを備えたサーバであり得る。同様に、ノードは、受信器６１０、判定器６２０、及び停止指示器６３０を備え得る。これらの要素は、有形の要素であるか、ソフトウェアの機能であるか、又はそれらの適切な組み合わせであり得る。
【００８１】
受信器６１０は、他のノードのサーバリソースの状態についての上述の表示を受信する。この表示は、通知メッセージ等のメッセージ内に受け取られてもよく、これについて図９及び図１０に関連付けてより詳細に説明する。例えば、このメッセージは、ＰＣＲＦを含むサーバで使用されるメモリの状態についての情報を含み得る。
【００８２】
判定器６２０は、クライアントとノード、例えばＡＦノード１４０との間の接続に関連するサービスセッションの活動が、活動閾値より低いか否かを判定する。
【００８３】
その活動が活動閾値より低いと判定された場合には、停止指示器６３０が、そのサービスセッションに割り当てられたベアラリソースの停止を指示する。これは、図６に示すように、例えば停止要求を送出することによって行うことができる。
【００８４】
図７のノード７００は、例えばＰＣＲＦを実現するように構成される。上述のように、ノード７００は、少なくとも上述の機能のいくつか、特に図４に関連付けて説明した機能を実施するプロセッサを備えるサーバであり得る。同様に、サーバは、検出器７１０、送信器７２０、及び受信器７３０を備え得る。これらの要素は、有形の要素であるか、ソフトウェアの機能であるか、又はそれらの適切な組み合わせであり得る。
【００８５】
図７に示すように、リソース７４０は、ノード７００に設けられる、例えば上述のサーバのストレージ（メモリ）であってよく、例えばハードディスク、ＲＡＭ、磁気又は光学ストレージ又な任意の適切なストレージ等であり得る。検出器７１０は、例えば上述のようなメモリ使用量等のサーバリソース７４０の状態を検出する。
【００８６】
検出器７１０に接続された送信器７２０は、図７に示すように、ノード７００のサーバリソース７４０の状態についての表示を、ＡＦノード又はＴＤＦノード等の別のノードに対して送信する。
【００８７】
受信器７３０は、他のノードがクライアントと他のノードとの間の接続に関連するサービスセッションの活動が活動閾値より低いと判定したサービスセッションに割り当てられたベアラリソースの停止の要求を受信する。この停止要求は、図７にも示されている。図７における表示は、図６のノード６００の受信器６１０で受信されるものと同じ表示であってよく、図７の停止要求は、図６のノード６００の停止指示器６３０によって送出されるものと同じ停止要求であってよい。
【００８８】
したがって、ネットワークリソースを管理するためのシステムは、上述の表示及び停止要求を通信するノード６００及び７００を備えていてよく、個々の作業工程はその表示及び停止要求に従って実施される。
【００８９】
図８は、例えばＡＦ又はＴＤＦを実現するべく構成されたノード８００の要素を示す。上述のノードと同様に、ノード８００は、少なくとも上述の機能のいくつか、特に図５に関連付けて説明した機能を実施するプロセッサを備えたサーバであり得る。同様に、サーバは、タイマ８１０、判定器８２０、及び停止指示器８３０を備え得る。これらの要素は、有形の要素であるか、ソフトウェアの機能であるか、又はそれらの適切な組み合わせであり得る。
【００９０】
タイマ８１０は、活動タイマであり、例えば１０分超又は数１００分超の長期間に設定される既知の活動タイマである。
【００９１】
判定器８２０は、少なくとも１つのクライアントとノード８００との間の接続に関連する複数のサービスセッションのなかの少なくとも１つのサービスセッションの活動が、活動閾値より低いか否かを周期的に判定する。
【００９２】
停止指示器８３０は、少なくとも１つのサービスセッションの活動が活動閾値より低い場合に、その少なくとも１つのサービスセッションに割り当てられたベアラリソースの停止を指示する。ここで、サービスセッションの活動が判定される期間の長さは、不活動タイマによって設定された期間より短い。即ち、サービスセッションの活動が判定される期間は１００秒程度であり得るが、不活動タイマによって設定される期間は、１００分間程度であり得る。
【００９３】
図２、図４、及び図５の機能の不要な繰り返しを避けるために、これらの機能は、それぞれ図６、図７、及び図８に関連付けて説明した要素によっても何らかの適切な方式で実施され得る、ということを記しておく。
【００９４】
以下、例えば、特定アクション（Ｓｐｅｃｉｆｉｃ−Ａｃｔｉｏｎ）ＡＶＰの拡張に基づく方法（図９）及び中断原因（Ａｂｏｒｔ−Ｃａｕｓｅ）ＡＶＰに基づく方法（図１０）等の例示的な方法について説明する。
【００９５】
図９に示すシーケンスは、ユーザ端末（ＵＥ）９１０、ＰＣＥＦ９２０、ＰＣＲＦ９３０、及びＡＦ９４０等である、またはそれらに含められたクライアントを含むシステムにおいて実施される。ＰＣＥＦ９２０、ＰＣＲＦ９３０、及びＡＦ９４０は、図１に示されているもののようなＰＣＣアーキテクチャの一部であり得る。この実施例では、提示されたスキームはＡＦを含むノードによって実施されるが、上述のように、代わりにＴＤＦノードを用いることも可能である。以下に説明するシーケンスに従って、ネットワークリソースを管理することができる。
【００９６】
図９のボックス９５０にみられるように、ＡＦ９４０はサービスを検出する。ＡＦノード９４０は、ＡＦセッションの確立において、Ｒｘ承認要求（ＲｘＡＡＲ）を用いて、内部サーバリソースの問題が生じたとき（例えばメモリ使用量が一定の閾値に達したとき）にＰＣＲＦ９３０からの表示を受信するべくサブスクライブする。これは、新しい値を有する特定アクション属性値ペア（ＡＶＰ）：ＩＮＤＩＣＡＴＩＯＮ＿ＯＦ＿ＳＥＲＶＥＲ＿ＲＥＳＯＵＲＣＥＳ（１２）を拡張することによって達成される。ここで１２は、最新の３ＧＰＰ  ２９．２１４の利用可能なバージョン（ｂ．２．０）から初めて利用可能となる値である。異なる値を用いてもよく、図９は単に特定の実施例に過ぎないことは当業者には明らかである。ＰＣＲＦ９３０によってＲｘＡＡＲメッセージを受信した後、ＰＣＲＦ９３０は、Ｒｘ参照ポイントを介して承認要求応答（ＡＡＡ）をもって応答、したがって具体的にはメッセージＲｘＡＡＡをもって応答する。
【００９７】
ＡＦノードがいずれのサービスが、例えば増強されたサービスために専用ベアラにマッピングされるかを知っている場合、上述の処理の更なる最適化は、ＡＦノードが専用ベアラの生成をもたらすＡＦセッションに対する表示のみをサブスクライブすることであろう。しかし、これは常に可能であるとは限らない。専用ベアラを生成することの決定は、ＡＦノードには存在せず、ＰＣＲＦ又はＰＣＥＦノードに存在するからである。したがって、一般的には、ＡＦノードは、毎回（初めの）ＲｘＡＡＲについての通知を、「盲目的に」サブスクライブすべきことになる。さらに、どのＡＦセッションが通知されるかを選択することはＰＣＲＦノードに委ねられることになる。
【００９８】
ＰＣＲＦノードは、その内部リソースがいっぱいになってきたとき、例えばメモリ使用量が８０％程度の特定の閾値に達したとき（ボックス９６０参照）、かつ専用ベアラにマッピングされるサブスクライブされたＡＦセッションについてのみ、ＡＦノードに対して、ＩＮＤＩＣＡＴＩＯＮ＿ＯＦ＿ＳＥＲＶＥＲ＿ＲＥＳＯＵＲＣＥＳ（１２）に設定された特定アクションＡＶＰを含むＲｘＲＡＲによって通知する。
【００９９】
ＰＣＲＦが、数千の活動状態のユーザとそれに対応するＡＦセッションをハンドリングしている場合、シグナリングストームを回避、即ちＰＣＲＦが、同時にＡＦノードに向かう数千のＲｘ再承認要求（ＲＡＲ）メッセージをトリガすることを回避するためのメカニズムが必要である。単純な選択は、ＰＣＲＦが、単にそれらのＲｘＲＡＲメッセージを一定のタイムウィンドウにわたって分配される異なるバッチに分割することである。
【０１００】
次にＰＣＲＦ９３０は、ＡＦ９４０からＲｘ再承認回答（ＲＡＡ）メッセージを受信する。
【０１０１】
次にＡＦノード９４０は、ボックス９７０において、サービスセッション活動について対応するＡＦセッションがあるかをチェックし、その結果に応じて、以下の場合に分けられる。
【０１０２】
ＡＦノードが、対応するサービスセッションについて、直近の活動、例えば過去Ｘ秒間の活動を検出しなかった場合には、ＡＦノードは、Ｒｘセッション停止要求（ＲｘＳＴＲ）をトリガすることによってそのサービスセッションと対応するＡＦセッションとを内部的に除去する。ＲｘＳＴＲは、ＰＣＲＦ９３０によって受信されたとき、ＰＣＲＦがＰＣＥＦ９２０に向けてＰＣＣ規則の除去をトリガして、結果的に専用ベアラの除去がなされ得る、ということを示していることに留意されたい。この場合は、図９の波線のボックスによって示されている。より詳細には、このボックスは、Ｇｘ参照ポイントを介してのシグナリング、例えばＰＣＲＦによるＧｘ再承認要求（ＲＡＲ）メッセージ（課金規則除去）の送信、及びＰＣＥＦ９２０が専用ベアラを除去するように指示し、かつＵＥ９１０に通知する前の時点での、ＰＣＥＦ９２０からのＧｘＲＡＡメッセージのＰＣＲＦによる受信も示している。
【０１０３】
ＡＦノード９４０が、対応するサービスセッションについての直近の活動、例えば過去Ｘ秒間の活動を検出した場合には、ＡＦノード９４０は、そのサービスセッションも対応するＡＦセッションも除去せず、ＲｘＲＡＡメッセージを送信することによる回答のみを行う。
【０１０４】
図１０に示すシーケンスは、ＵＥ１０１０、ＰＣＥＦ１０２０、ＰＣＲＦ１０３０、及びＡＦ１０４０を備えるシステムにおいて実施される。ＰＣＥＦ１０２０、ＰＣＲＦ１０３０、及びＡＦ１０４０は、図１に示すもののようなＰＣＣアーキテクチャの一部であってもよい。以下に説明するシーケンスに従って、ネットワークリソースを管理することができる。図９に関連付けて説明した実施例との主な相違点は、図１０では、その方法が特定アクション（Ｓｐｅｃｉｆｉｃ−Ａｃｔｉｏｎ）ＡＶＰではなく、中断原因（Ａｂｏｒｔ−Ｃａｕｓｅ）ＡＶＰに基づいている点である。この選択は、ＡＦがＰＣＲＦ表示を前もってサブスクライブする必要がない点でより単純であり得る。
【０１０５】
ボックス１０５０によって示されるように、ＡＦノード１０４０はサービスを検出し、ＲｘＡＡＲメッセージとＲｘＡＡＡメッセージとが交換されるが、図９の場合と異なり、新しい値１２は用いられない。
【０１０６】
ＰＣＲＦノード１０３０は、その内部リソースがいっぱいになってきたとき、例えばメモリ使用量が８０％程度の特定の閾値に達し（ボックス１０６０）、かつそれが専用ベアラにマッピングされるＡＦセッションのみのためであるとき、ＩＮＳＵＦＦＩＣＩＥＮＴ＿ＳＥＲＶＥＲ＿ＲＥＳＯＵＲＣＥＳ（１）に設定された中断原因ＡＶＰを含むＲｘＲＡＲのメッセージによってＡＦノード１０４０に通知する。
【０１０７】
ここで、３ＧＰＰは、中断原因ＡＶＰ値ＩＮＳＵＦＦＩＣＩＥＮＴ＿ＳＥＲＶＥＲ＿ＲＥＳＯＵＲＣＥＳ（１）を既にサポートしている。しかし、３ＧＰＰを使用する場合は、単にＡＦノードに通知するのではなく、実際にＡＦセッションを除去する。値ＩＮＳＵＦＦＩＣＩＥＮＴ＿ＳＥＲＶＥＲ＿ＲＥＳＯＵＲＣＥＳ（１）は、サーバに過負荷が掛かり、セッションを中止する必要があることを示すために用いられる。
【０１０８】
図９に示す方法の有効な代替的方法とするために、３ＧＰＰ２９．２１４は、上述の値に設定された中断原因ＡＶＰを有するＲＡＲが実際にＡＦセッションを除去しないが、代わりに、後のＲｘＳＴＲをトリガすることによってＡＦセッションが除去される必要があるか否かを決定することをＡＦ１０４０に委ねる、ということを示すように改変される必要がある。
【０１０９】
図９に関連付けて説明したように、シグナリングストームを回避するための類似のメカニズムを図１０の方法でも用いることができるが、この詳細については、前述の説明を参照されたい。
【０１１０】
次にＡＦノード１０４０は、ボックス１０７０に示すように、サービスセッション活動について対応するＡＦセッションがあるかをチェックし、その結果に応じて、以下の場合に分けられる。
【０１１１】
ＡＦノード１０４０が、対応するサービスセッションについて、直近の活動、例えば過去Ｘ秒間の活動を検出しなかった場合には、ＡＦノードは、ＲｘＳＴＲをトリガすることによってそのサービスセッションと対応するＡＦセッションとを内部的に除去する。ＲｘＳＴＲは、ＰＣＲＦ１０３０によって受信されたとき、ＰＣＲＦがＰＣＥＦ１０２０に向けてＰＣＣ規則の除去をトリガし、結果的に専用ベアラの除去がなされ得ることを示していることに留意されたい。これは図９の破線ボックスと同一の図１０の破線ボックスに示されており、したがって前述の説明を参照されたい。
【０１１２】
ＡＦノード１０４０が、対応するサービスセッションについて、直近の活動、例えば過去Ｘ秒間の活動を検出した場合には、ＡＦノードは、そのサービスセッションも対応するＡＦセッションも除去せず、ＲｘＲＡＡメッセージを送信することによる回答のみ行う。
【０１１３】
上述のスキームは、モバイルクラウドアクセラレータのためのＳＰＣ／ＳＡＳＮ及びＳＡＰＣにおいて実現することができる。前に何度か繰り返し説明したように、大半の実施例はＲｘ参照ポイント（ＡＦシナリオ）に関連付けて説明したが、同じスキームは、Ｒｘの代わりにサービス通知のために３ＧＰＰリリース１１Ｇｘイベントトリガを用いるとき、スタンドアロンのＴＤＦノード又はＰＣＥＦとともに配置されたＴＤＦノードの両方にも適用される。３つの異なるシナリオ、即ちＡＦシナリオ、スタンドアロンＴＤＦシナリオ、及びＰＣＥＦとともに配置されたＴＤＦシナリオのそれぞれが図１２ａ、図１２ｂ、図１２ｃに示されている。したがって、図１２ａの場合に大半が関連している上述の実施例は、Ｒｘ参照ポイントに限定されず、Ｓｄ参照ポイント及びＧｘ参照ポイント上でも類似の機能を使用し、かつ同じ効果を達成することが可能であることは明白である。
【０１１４】
上記に従って、長期間継続する専用ベアラがノードによってトリガされたとき異なるシナリオのためのネットワークリソースを最適化でき、特にメモリ領域不足を回避することができる。
【０１１５】
本発明の異なる実施形態による、エレメント、ノード、サーバ、及びシステムを含む物理的エンティティはコンピュータプログラムを備えるか又はそれを格納したものであり得る。そのコンピュータプログラムは、その物理的エンティティ上で実行されるとき、本発明の実施形態によるステップや作業工程が実施される、即ちデータプロセシング手段にその作業工程を実施させるような命令を含む。特に、本発明の実施形態は、本発明の実施形態による作業工程／ステップを実施するためのコンピュータプログラムに関するものであるとともに、また上述の方法を実施するためのコンピュータプログラムを格納したあらゆるコンピュータが読み出し可能な媒体にも関する。コンピュータが読み出し可能な媒体は、あらゆるディスク又はハードディスク、ＲＡＭ又はＲＯＭ又はＥＥＰＲＯＭ、又は信号等の無形の媒体であり得る。
【０１１６】
受信器、判定器、停止指示器、検出器、送信器、及びタイマという用語が用いられる場合、これらの要素がどのように分散され得るかについて、及びこれらの要素がどのように集められ得るかについてはなんら制限されない。即ち、ノード及びシステムの構成要素は、異なるソフトウェア及びハードウェアコンポーネント又は意図する機能をもたらす他のデバイスに分散され得る。意図する機能性を提供するために複数の個別の要素が集められてもよい。例えば、ノードの要素／機能はマイクロプロセッサとメモリによって実現されてもよく、この場合マイクロプロセッサは、マイクロプロセッサに接続されたメモリに命令として格納され得る上述の作業工程又はステップが実施されるようにプログラムされてもよい。
【０１１７】
更に、ノード又はシステムの要素は、ハードウェア、ソフトウェア、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）ファームウェア等において実現されてもよい。
【０１１８】
本発明の範囲又は精神を逸脱することなく本発明のエンティティ及び方法並びに本発明の構成物に種々の改変及び変更を加えることが可能であることは当業者には明らかであろう。
【０１１９】
本発明を特定の実施形態及び実施例に関連して説明してきたが、これらの特定の実施形態及び実施例は、全ての面において、限定ではなく例示を意図したものである。ハードウェア、ソフトウェア、及び／又はファームウェアの多くの異なる組み合わせが、本発明の実施のために適切であることを、当業者は理解されよう。
【０１２０】
更に、本発明の他の実施形態は、明細書及びそこに開示された本発明の実施形態の検討から当業者には明らかとなろう。明細書及び実施例は例示のみとしてみなすべきものであることを意図しており、また上述の実施例で用いられる略語は後に列記されている。この目的のために、本発明の態様は、上述の開示された実施形態又は構成の１つのなかに含まれる全ての特徴より少ない数の特徴のなかに存在することを理解されたい。したがって、本発明の真の範囲及び精神は、請求項によって示されるものである。
【０１２１】
略語
３ＧＰＰ：第３世代標準化プロジェクト
ＡＦ：アプリケーション機能
ＡＶＰ：属性値ペア
ＣＣＡ：クレジット制御回答
ＣＣＲ：クレジット制御要求
ＣＤＮ：コンテンツ配信ネットワーク
ＤＰＩ：ディープ・パケット・インスペクション
ＧＧＳＮ：ゲートウェイＧＰＲＳサポートノード
ＨＴＴＰ：ハイパーテキスト転送プロトコル
ＩＭＳ：ＩＰマルチメディアサブシステム
ＩＰ：インターネットプロトコル
ＩＰ−ＣＡＮ：インターネットプロトコルコネクティビティアクセスネットワーク
ＭＣＡ：モバイルクラウドアクセラレータ
ＰＣＣ：ポリシー・課金制御
ＰＣＥＦ：ポリシー・課金実施機能
ＰＣＲＦ：ポリシー・課金規則機能
Ｐ−ＣＳＣＦ：プロキシコールセッション制御機能
ＰＤＮ  ＧＷ：パケットデータネットワークゲートウェイ
ＰＤＰ：パケットデータプロトコル
ＱｏＳ：サービスの質
ＲＡＡ：再承認回答
ＲＡＲ：再承認要求
ＳＡＰＣ：サービスアウェアポリシーコントローラ
ＳＡＳＮ：サービスアウェアサポートノード
ＳＰＣ：スマートパイプコントローラ
ＴＣＰ：伝送制御プロトコル
ＴＤＦ：トラフィック検出機能
【図１】
0005830185.tif 000002
【図２】
0005830185.tif 000003
【図３】
0005830185.tif 000004
【図４】
0005830185.tif 000005
【図５】
0005830185.tif 000006
【図６】
0005830185.tif 000007
【図７】
0005830185.tif 000008
【図８】
0005830185.tif 000009
【図９】
0005830185.tif 000010
【図１０】
0005830185.tif 000011
【図１１】
0005830185.tif 000012
【図１２ａ】
0005830185.tif 000013
【図１２ｂ】
0005830185.tif 000014
【図１２ｃ】
0005830185.tif 000015