(57)【特許請求の範囲】
【請求項１】
ＲＡＣＳ（Ｒｅｓｏｕｒｃｅ  Ａｄｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｓｕｂｓｙｓｔｅｍ）アーキテクチャに基づくリソース失効方法であって、
前記ＲＡＣＳアーキテクチャが有するサービスベースポリシー決定ファンクションにより、前記ＲＡＣＳアーキテクチャが有するアクセスリソース及びアドミッションコントロールファンクションからのサービスリソースに関するコンテクストを含む確保失効通知を受信するステップと、
前記サービスベースポリシー決定ファンクションにより、前記確保失効通知に含まれる前記コンテクストを解析するステップと、
前記サービスベースポリシー決定ファンクションにより、前記確保失効通知から解析された前記コンテクストに従って、セッションのために前記サービスリソースが、前記ＲＡＣＳアーキテクチャが有するボーダーゲートウェイファンクションにより割り当てられたか否かを判断するステップと、
前記セッションのために前記サービスリソースが前記ボーダーゲートウェイファンクションにより割り当てられたと判断すると、前記サービスベースポリシー決定ファンクションにより、前記セッションのために割り当てられた前記サービスリソースをリリース及び失効するよう前記ボーダーゲートウェイファンクションに通知するステップと、
を含み、
前記確保失効通知は、リソース確保を失効するよう通知するものである、
ことを特徴とする方法。
【請求項２】
請求項１記載の方法であって、さらに、
前記サービスベースポリシー決定ファンクションにより、前記ボーダーゲートウェイファンクションから前記サービスベースポリシー決定ファンクションに返す実行結果を受信するステップを有することを特徴とする方法。
【請求項３】
請求項１記載の方法であって、さらに、
前記アクセスリソース及びアドミッションコントロールファンクションにより、前記ＲＡＣＳアーキテクチャが有するリソースコントロール実行ファンクションに対してインストールされているポリシーを失効する必要があるか否かをチェックし、
前記必要がある場合、前記アクセスリソース及びアドミッションコントロールファンクションにより、前記リソースコントロール実行ファンクションに前記ポリシーを失効するよう通知し、
前記リソースコントロール実行ファンクションにより、実行結果を前記アクセスリソース及びアドミッションコントロールファンクションに返すステップを有することを特徴とする方法。
【請求項４】
請求項１又は２記載の方法であって、
前記サービスベースポリシー決定ファンクションが前記確保失効通知を受信する前に、さらに、前記ＲＡＣＳアーキテクチャが有するＮＡＳＳ（Ｎｅｔｗｏｒｋ  Ａｔｔａｃｈｍｅｎｔ  Ｓｕｂｓｙｓｔｅｍ）、又は、前記ＲＡＣＳアーキテクチャが有するリソースコントロール実行ファンクションにより、確保失効に係るイベントをトリガーするステップを有することを特徴とする方法。
【請求項５】
請求項１又は２記載の方法であって、
前記サービスベースポリシー決定ファンクションが前記確保失効通知を受信した後、さらに、前記サービスベースポリシー決定ファンクションにより、前記ＲＡＣＳアーキテクチャが有するアプリケーションファンクションにリソース確保を失効するよう通知するステップを有することを特徴とする方法。
【請求項６】
ＲＡＣＳ（Ｒｅｓｏｕｒｃｅ  Ａｄｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｓｕｂｓｙｓｔｅｍ）アーキテクチャに基づくネットワーク装置であって、
前記ＲＡＣＳアーキテクチャが有するアクセスリソース及びアドミッションコントロールファンクションからのサービスリソースに関するコンテクストを含む確保失効通知を受信する処理ユニットと、
前記処理ユニットからの前記確保失効通知に従って、前記ＲＡＣＳアーキテクチャが有するボーダーゲートウェイファンクションに前記サービスリソースをリリース及び失効するよう要求する必要があるか否かを判断する判定ユニットであって、当該判定ユニットは、前記アクセスレソース及びアドミッションコントロールファンクションからの前記確保失効通知に含まれる前記コンテクストを解析するコンテクスト解析ユニットと、前記コンテクスト解析ユニットからの解析結果に従って、セッションのために前記ボーダーゲートウェイファンクションが前記サービスリソースを割当てたか否かを判断する判断ユニットと、を含む判定ユニットと、
前記判断ユニットが、前記セッションのために前記サービスリソースが前記ボーダーゲートウェイファンクションにより割り当てられたと判断すると、前記セッションのために割り当てられた前記サービスリソースをリリース及び失効するよう前記ボーダーゲートウェイファンクションに通知する第２通知ユニットと、
を含み、
前記確保失効通知は、リソース確保を失効するよう通知するものである、
ことを特徴とするネットワーク装置。
【請求項７】
請求項６記載のネットワーク装置であって、さらに、
前記確保失効通知に従って、前記ＲＡＣＳアーキテクチャが有するアプリケーションファンクションにリソース確保を失効するよう通知する第１通知ユニットを有することを特徴とする装置。
【請求項８】
ＲＡＣＳ（Ｒｅｓｏｕｒｃｅ  Ａｄｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｓｕｂｓｙｓｔｅｍ）アーキテクチャに基づくリソース失効方法であって、
前記ＲＡＣＳアーキテクチャが有するサービスベースポリシー決定ファンクションにより、前記ＲＡＣＳアーキテクチャが有するアクセスリソース及びアドミッションコントロールファンクションからの確保失効通知を受信するステップと、
前記確保失効通知を受信した後に、前記サービスベースポリシー決定ファンクションにより、前記ＲＡＣＳアーキテクチャが有するアプリケーションファンクションがサービスリソースを要求する際に生成され、前記サービスベースポリシー決定ファンクションに記録されている情報を検索することで、セッションのために前記サービスリソースが、前記ＲＡＣＳアーキテクチャが有するボーダーゲートウェイファンクションにより割り当てられたか否かを判断するステップと、
前記セッションのために前記サービスリソースが前記ボーダーゲートウェイファンクションにより割り当てられたと判断すると、前記サービスベースポリシー決定ファンクションにより、前記セッションのために割り当てられた前記サービスリソースをリリース及び失効するよう前記ボーダーゲートウェイファンクションに通知するステップと、
を含み、
前記確保失効通知は、リソース確保を失効するよう通知するものである、
ことを特徴とする方法。
【請求項９】
請求項８記載の方法であって、さらに、
前記サービスベースポリシー決定ファンクションにより、前記ボーダーゲートウェイファンクションから返す実行結果を受信するステップを有することを特徴とする方法。
【請求項１０】
請求項８記載の方法であって、さらに、
前記アクセスリソース及びアドミッションコントロールファンクションにより、前記ＲＡＣＳアーキテクチャが有するリソースコントロール実行ファンクションに対してインストールされているポリシーを失効する必要があるか否かをチェックし、
前記必要がある場合、前記アクセスリソース及びアドミッションコントロールファンクションにより、前記リソースコントロール実行ファンクションに前記ポリシーを失効するよう通知し、
前記リソースコントロール実行ファンクションにより、実行結果を前記アクセスリソース及びアドミッションコントロールファンクションに返すステップを有することを特徴とする方法。
【請求項１１】
請求項８又は９記載の方法であって、
前記サービスベースポリシー決定ファンクションが前記確保失効通知を受信する前に、さらに、前記ＲＡＣＳアーキテクチャが有するＮＡＳＳ（Ｎｅｔｗｏｒｋ  Ａｔｔａｃｈｍｅｎｔ  Ｓｕｂｓｙｓｔｅｍ）、又は、前記ＲＡＣＳアーキテクチャが有するリソースコントロール実行ファンクションにより、確保失効に係るイベントをトリガーするステップを有することを特徴とする方法。
【請求項１２】
請求項８又は９記載の方法であって、
前記サービスベースポリシー決定ファンクションが前記確保失効通知を受信した後、さらに、前記サービスベースポリシー決定ファンクションにより、前記ＲＡＣＳアーキテクチャが有するアプリケーションファンクションにリソース確保を失効するよう通知するステップを有することを特徴とする方法。
【請求項１３】
請求項８又は９記載の方法であって、
生成された前記情報は、前記ボーダーゲートウェイファンクションの識別情報であることを特徴とする方法。
【請求項１４】
ＲＡＣＳ（Ｒｅｓｏｕｒｃｅ  Ａｄｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｓｕｂｓｙｓｔｅｍ）アーキテクチャに基づくネットワーク装置であって、
前記ＲＡＣＳアーキテクチャが有するアクセスリソース及びアドミッションコントロールファンクションからの確保失効通知を受信する処理ユニットと、
前記処理ユニットからの前記確保失効通知に従って、前記ＲＡＣＳアーキテクチャが有するボーダーゲートウェイファンクションにサービスリソースをリリース及び失効するよう要求する必要があるか否かを判断する判定ユニットであって、当該判定ユニットは、前記ＲＡＣＳアーキテクチャが有するアプリケーションファンクションが前記サービスリソースを要求する際に生成され、ローカルに記録されている情報を検索する記録情報検索ユニットと、前記記録情報検索ユニットからの検索結果に従って、セッションのために前記ボーダーゲートウェイファンクションが前記サービスリソースを割当てたか否かを判断する判断ユニットと、を含む判定ユニットと、
前記判断ユニットが、前記セッションのために前記サービスリソースが前記ボーダーゲートウェイファンクションにより割り当てられたと判断すると、前記セッションのために割り当てられた前記サービスリソースをリリース及び失効するよう前記ボーダーゲートウェイファンクションに通知する第２通知ユニットと、
を含み、
前記確保失効通知は、リソース確保を失効するよう通知するものである、
ことを特徴とするネットワーク装置。
【請求項１５】
請求項１４記載のネットワーク装置であって、さらに、
前記確保失効通知に従って、前記アプリケーションファンクションにリソース確保を失効するよう通知する第１通知ユニットを有することを特徴とする装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信技術分野に関し、特にＲＡＣＳ（Ｒｅｓｏｕｒｃｅ  Ａｄｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｓｕｂｓｙｓｔｅｍ）に基づくリソース失効方法及びネットワーク装置に関する。
【背景技術】
【０００２】
インターネットが拡大するに従って、多様なネットワークサービス及び先進的なマルチメディア通信システムが急速に出現した。リアルタイムサービスがネットワーク送信遅延やタイムジッタなどの特徴の影響を受けるという事実により、画像ファイルに関するＦＴＰ（Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）又はＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）サービスの突出が存在するとき、このようなサービスは重大な影響を被るであろう。さらに、マルチメディアサービスは帯域幅を大きく占有するため、既存のネットワークを介し保証されねばならない主要なサービスを確実に送信することが困難となる。従って、時代が要求するのに従って、多様なＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）技術が登場している。ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）は、ＱｏＳに対する要求を満たすため、多数のサービスモデル及びメカニズムを提案してきた。
【０００３】
広範なポータルベースアプリケーション及びサービスは、ブロードバンドマルチメディアサービスと共に、豊富な映像／音声ストリーム、ビデオ・オン・デマンド（ＶＯＤ）、ビデオマルチキャスティング、マルチメディアインタラクション及び高い帯域幅要求のネットワークゲームを通常の一般ユーザに提供することや、テレビ会議、遠隔教育、ＶＰＮ（Ｖｉｒｔｕａｌ  Ｐｒｉｖａｔｅ  Ｎｅｔｗｏｒｋ）、ＱｏＳ保証されたデータプライベートライン及びＩＰホテルなどを企業ユーザに提供することを含むブロードバンド処理における重要なコンテンツとなってきた。
【０００４】
運営者や企業ユーザに対して、イーサネット（登録商標）技術やエンド・ツー・エンドイーサネット（登録商標）技術は広く認知されている。イーサネット（登録商標）技術は、統合されたネットワークやメトロポリタンエリアネットワーク（ＭＡＮ）を構築するのに重要な技術の１つとなってきており、イーサネット（登録商標）サービスは、将来の市場において大きく期待されている。上記状況に基づき、ヨーロッパ電気通信規格研究所（ＥＴＳＩ）によってＴＩＳＰＡＮ（Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  ａｎｄ  Ｉｎｔｅｒｎｅｔ  ｃｏｎｖｅｒｇｅｄ  Ｓｅｒｖｉｃｅｓ  ａｎｄ  Ｐｒｏｔｏｃｏｌｓ  ｆｏｒ  Ａｄｖａｎｃｅｄ  Ｎｅｔｗｏｒｋｉｎｇ）において提案されたパケットベースネットワークアーキテクチャ（すなわち、次世代ネットワーク（ＮＧＮ））では、ベアラネットワークにおけるリソースを集中的に管理するため、アプリケーションレイヤとトランスポートレイヤとの間にＲＡＣＳ（Ｒｅｓｏｕｒｃｅ  Ａｄｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｓｕｂｓｙｓｔｅｍ）が導入される。さらに、ネットワークアドレス変換（ＮＡＴ）とベアラネットワークのＱｏＳなどがＲＡＣＳを開始アクセス及び制御されるように、ポリシーベース制御が提供される。
【０００５】
図１において、ＴＩＳＰＡＮに規定されるＲＡＣＳアーキテクチャが示される。ここでは、ＲＡＣＳは主として、アプリケーションファンクション（ＡＦ）１１０と、サービスベースポリシー決定ファンクション（ＳＰＤＦ）１２０と、ボーダーゲートウェイファンクション（ＢＧＦ）１３０と、アクセスリソース及びアドミッションコントロールファンクション（Ａ−ＲＡＣＦ）１４０と、リソースコントロール実行ファンクション（ＲＣＥＦ）１５０とを有する。図１において、ＲＡＣＳにおける各ファンクション間の関係とインタフェースがまた示される。
【０００６】
ネットワークアドレス及びポート変換（ＮＡＰＴ）の制御は、主としてＡＦ１１０、ＳＰＤＦ１２０及びＢＧＦ１３０の間のやりとりにより行われる。Ａ−ＲＡＣＦ１４０とＲＣＥＦ１５０は、主としてアクセスレイヤに対するＱｏＳリソースの制御のために利用される。
【０００７】
上述のＲＡＣＳアーキテクチャでは、ベアラパスがリリースされるか、インストールされたポリシーが無効になると、関連するリソースが失効される必要がある。リソース失効プロセスは、従来技術ではＮＡＳＳ（Ｎｅｔｗｏｒｋ  Ａｔｔａｃｈｍｅｎｔ  Ｓｕｂｓｙｓｔｅｍ）又はＲＣＥＦにより開始することが可能である。
【０００８】
図２を参照するに、従来技術によるＮＡＳＳによるリソース失効を開始する主要なプロセスは、以下の通りである。
【０００９】
ステップ２０１において、ＮＡＳＳはベアラパスをリリースすることを決定する。例えば、加入者宅内機器が、ＮＡＳＳにベアラパスをリリースすることを要求する。
【００１０】
ステップ２０２において、ＮＡＳＳは、Ａ−ＲＡＣＦにアクセスネットワーク情報が無効になったことを通知するため。ＩＰ接続リリース指示を送信することによりアクセス情報を削除するようＡ−ＲＡＣＦに通知する。
【００１１】
ステップ２０３において、Ａ−ＲＡＣＦは、ＳＰＤＦにリソース確保を失効するよう通知するため、確保失効リクエストを送信することにより関連するすべてのリソースを失効することを要求する。
【００１２】
ステップ２０４において、ＳＰＤＦは、確保失効リクエストを送信することによりＡＦにリソース確保を失効するよう通知する。
【００１３】
ステップ２０５において、Ａ−ＲＡＣＦは、ＰＣＥＦに対してインストールされているポリシーを失効するか否かチェックする。そうである場合（すなわち、ＲＣＥＦに対してポリシーがインストールされている）、Ａ−ＲＡＣＦはステップ２０６を実行し、そうでない場合には、当該プロセスを終了する。
【００１４】
ステップ２０６において、Ａ−ＲＡＣＦは、ＲＣＥＦにサービスリソースリリースリクエストを送信することによりＲＣＥＦにポリシーを失効するよう通知する。
【００１５】
ステップ２０７において、ＲＣＥＦは、当該ポリシーを失効し、ＲＣＥＦにサービスリソースリリースアクノリッジメントを送信することにより当該結果を返す。
【００１６】
図３を参照するに、従来技術によりＲＣＥＦによるリソース失効を開始する主要なプロセスは、以下の通りである。
【００１７】
ステップ３０１において、ＲＣＥＦは、インストールされているポリシーが失効したと判断する（例えば、内部の不具合などにより）。
【００１８】
ステップ３０２において、ＲＣＥＦは、当該ポリシーがイベント通知イベントにより失効したことをＡ−ＲＡＣＦに通知する。
【００１９】
ステップ３０３において、Ａ−ＲＡＣＦは、ＳＰＤＦにリソース確保を失効するよう通知するため、ＳＰＤＦに確保失効リクエストを送信することにより関連するすべてのリソースを失効するよう要求する。
【００２０】
ステップ３０４において、ＳＰＤＦは、確保失効リクエストを送信することにより、ＡＦにリソース確保を失効するよう通知する。
【００２１】
上記２つのリソース失効プロセスによると、従来技術によるＲＡＣＳアーキテクチャでは、サービスリソース（ＮＡＴなど）に対する呼び出しがＢＧＦに要求されるが、ＮＡＳＳ又はＲＣＥＦがある理由のためリソース失効を開始する場合、ＢＧＦにより割り当てられたサービスリソースは失効されず、ネットワークリソースが浪費される。
【発明の開示】
【発明が解決しようとする課題】
【００２２】
本発明は、セッションサービスがＢＧＦからリソースを要求した後、サービスリソースをリリースするようＢＧＦに通知されず、これにより、リソースが時間内に失効できないという従来技術による問題点を解消するものである。
【課題を解決するための手段】
【００２３】
上記課題を解決するため、本発明は、ＲＡＣＳ（Ｒｅｓｏｕｒｃｅ  Ａｄｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｓｕｂｓｙｓｔｅｍ）に基づくリソース失効方法であって、サービスベースポリシー決定ファンクションにより、確保失効通知を受信するステップと、サービスリソースがセッションのためにボーダーゲートウェイファンクションにより割り当てられたと判断すると、前記サービスベースポリシー決定ファンクションにより、前記ボーダーゲートウェイファンクションに前記セッションのために割り当てられたサービスリソースをリリース及び失効するよう前記ボーダーゲートウェイファンクションに通知するステップとから構成されることを特徴とする方法を提供する。
【００２４】
本発明の一実施例では、本方法はさらに、前記ボーダーゲートウェイファンクションからの実行結果を前記サービスベースポリシー決定ファンクションに返すステップを有する。
【００２５】
本発明の一実施例では、前記セッションのためにサービスリソースがボーダーゲートウェイファンクションにより割り当てられたか否かは、アプリケーションファンクションがリソースを要求した際に生成され、前記通知に含まれていたコンテクストに従って実行される。
【００２６】
本発明の一実施例では、前記セッションのためにサービスリソースがボーダーゲートウェイファンクションにより割り当てられたか否かは、アプリケーションファンクションがリソースを要求した際に生成され、前記サービスベースポリシー決定ファンクションに記録された情報に従って実行される。
【００２７】
本発明の一実施例では、前記アプリケーションファンクションがリソースを要求した際に生成された情報は、前記ボーダーゲートウェイファンクションの識別情報である。
【００２８】
本発明の一実施例では、前記確保失効通知は、アクセスリソース及びアドミッションコントロールファンクションから与えられる。
【００２９】
本発明の一実施例では、本方法はさらに、前記アクセスリソース及びアドミッションコントロールファンクションにより、リソースコントロール実行ファンクションに対してインストールされているポリシーを失効する必要があるかチェックし、必要がある場合、前記リソースコントロール実行ファンクションに前記ポリシーを失効するよう通知するステップを有する。
【００３０】
本発明の一実施例では、本方法はさらに、前記リソースコントロール実行ファンクションからの実行結果を前記アクセスリソース及びアドミッションコントロールファンクションに返すステップを有する。
【００３１】
本発明の一実施例では、前記サービスベースポリシー決定ファンクションが前記確保失効通知を受信する前に、本発明はさらに、ＮＡＳＳ（Ｎｅｔｗｏｒｋ  Ａｔｔａｃｈｍｅｎｔ  Ｓｕｂｓｙｓｔｅｍ）又は前記リソースコントロール実行ファンクションにより、確保失効に係るイベントをトリガーするステップを有する。
【００３２】
本発明の一実施例では、前記サービスベースポリシー決定ファンクションが前記確保失効通知を受信した後、本方法はさらに、前記サービスベースポリシー決定ファンクションにより、前記アプリケーションファンクションにリソース確保を失効するよう通知するステップを有する。
【００３３】
上記課題を解決するため、本発明は、確保失効指示を受信する処理ユニットと、前記処理ユニットからの確保失効指示に従って、ボーダーゲートウェイファンクションにサービスリソースをリリース及び失効するよう要求する必要があるか判断する判定ユニットと、前記判定ユニットが前記サービスリソースをリリース及び失効するよう前記ボーダーゲートウェイファンクションに要求することを決定すると、前記ボーダーゲートウェイファンクションに通知する第２通知ユニットとから構成されることを特徴とするネットワーク装置を提供する。
【００３４】
本発明の一実施例では、前記判定ユニットは、アプリケーションファンクションがリソースを要求した際に生成されたアクセスリソースからの確保失効通知のコンテクストを解析するコンテクスト解析ユニットと、前記コンテクスト解析ユニットからの結果に従って、前記ボーダーゲートウェイファンクションがセッションのためにサービスリソースを割当てたか判断する判断ユニットとを有する。
【００３５】
本発明の一実施例では、前記判定ユニットは、アプリケーションユニットがリソースを要求した際に生成され、ローカルに記録された情報を検索するレコード情報検索ユニットと、前記レコード情報検索ユニットからの検索結果に従って、前記ボーダーゲートウェイファンクションがセッションのためにサービスリソースを割り当てたか検出する判断ユニットとを有する。
【００３６】
本発明の一実施例では、当該ネットワーク装置はさらに、前記確保失効指示に従って、前記アプリケーションにリソース確保を失効するよう通知する第１通知ユニットを有する。
【発明の効果】
【００３７】
本発明において提供されるＲＡＣＳアーキテクチャでは、ＳＰＤＦが確保失効指示を受信すると、ＢＧＦにサービスリソースを失効するよう時間内に通知することができる。この結果、本発明によると、リソースの利用率を効果的に向上させることが可能である。
【発明を実施するための最良の形態】
【００３８】
ＮＡＳＳ（Ｎｅｔｗｏｒｋ  Ａｔｔａｃｈｍｅｎｔ  Ｓｕｂｓｙｓｔｅｍ）又はリソースコントロール実行ファンクション（ＲＣＥＦ）がリソース確保の失効に関するイベントをトリガーすると、あるセッションのためにサービスリソースを割り当てたＢＧＦがサービスリソースを失効することを可能にするため、サービスベースポリシー決定ファンクション（ＳＰＤＦ）は、ＢＧＦが当該セッションのためにサービスリソースを割り当てたか判断し、ＢＧＦが当該セッションのためにサービスリソースを割り当てたと判断すると、ＢＧＦにサービスリソースをリリース及び失効するよう通知する。
【００３９】
Ａ−ＲＡＣＦは、当該リソースに関するコンテクストを含む通知メッセージをＳＰＤＦに送信する。このコンテクストは、ＡＦがＳＰＤＦにリソースをリクエストしたときに生成され、ＡＦ及びＡ−ＲＡＣＦなどに格納されている。ＳＰＤＦがポリシーに従ってサービスリソースを割り当てるのにＢＧＦを選択すると、対応する情報が当該コンテクストに記録される。従って、Ａ−ＲＡＣＦがＢＧＦ情報を含む確保失効リクエストメッセージを送信する場合、ＳＰＤＦは、コンテクストの対応する情報に従って、当該セッションのためにサービスリソースを割り当てたか判断することが可能となる。
【００４０】
さらに、ＡＦがリソースを要求すると、ＳＰＤＦは、それがリソースを割り当てるのにＢＧＦを選択した後、ＢＧＦ情報をローカルに記録することが可能である。このように、ローカルに記録されたレコードに従って、ＢＧＦが当該セッションのためにサービスリソースを直接割り当てたかＳＰＤＦが判断する間、Ａ−ＲＡＣＦからの確保失効リクエストメッセージにＢＧＦ情報を含めることは不要である。
【００４１】
図４を参照するに、本発明の一実施例によるＮＡＳＳによるリソース失効を開始する主要なプロセスは、以下の通りである。
【００４２】
ステップ４０１において、ＮＡＳＳは、ベアラパスをリリースするよう決定する。例えば、加入者宅内機器が、ＮＡＳＳにベアラパスをリリースするよう要求する。
【００４３】
ステップ４０２において、ＮＡＳＳは、アクセスネットワーク情報が無効になったことをＡ−ＲＡＣＦに通知するため、Ａ−ＲＡＣＦにＩＰ接続リリース指示を送信する。
【００４４】
ステップ４０３において、Ａ−ＲＡＣＦは、対応するコンテクスト情報を含む確保失効リクエストメッセージをＳＰＤＦに送信することにより、対応するセッションに割り当てられたすべての対応するリソースを失効する。
【００４５】
ステップ４０４において、ＳＰＤＦは、当該セッションのために確保失効リクエストメッセージをＡＦに送信する。
【００４６】
ステップ４０５において、Ａ−ＲＡＣＦは、ＲＣＥＦにインストールされたポリシーを失効するか否かチェックする。そうである場合、当該プロセスはステップ４０６及び４０７の後にステップ４０８に移行し、そうでない場合、当該プロセスは、ステップ４０８に直接移行する。
【００４７】
このチェックを行う方法は多数ある。例えば、リソースを要求する際、Ａ−ＲＡＣＦは、ＮＡＳＳからの加入者アクセス情報及びローカルポリシーに従って、サービスリソースについてＲＣＥＦにリクエストするか判断し、必要に応じて、サービスリソースを要求するためＲＣＥＦを選択し、ＲＣＥＦエンティティの情報をローカルに記録する。このように、Ａ−ＲＡＣＦがサービスリソースをリリースしようとするとき、それは、このローカルに記録されているＲＣＥＦエンティティの情報に従ってポリシーを失効するようＲＣＥＦに通知するか否か判断することが可能となる。
【００４８】
ステップ４０６において、Ａ−ＲＡＣＦは、ＲＣＥＦにポリシーを失効するよう通知する。
【００４９】
ステップ４０７において、ＲＣＥＦは、ポリシーを失効し、その結果をＡ−ＲＡＣＦに返す。
【００５０】
ステップ４０８において、ＳＰＤＦは、コンテクストの情報に従って、ＢＧＦにサービスリソースをリリースするよう要求するか（すなわち、ＢＧＦが、当該セッションのためにサービスリソースを割り当てたか）チェックする。そうである場合、当該プロセスはステップ４０９に移行し、そうでない場合、それはリソース失効の処理フローを終了する。
【００５１】
ステップ４０９において、ＳＰＤＦは、ＢＧＦに当該セッションのために割り当てられたサービスリソースをリリースするよう要求するため、サービスリソースリリースリクエストをＢＧＦに送信する。
【００５２】
ステップ４１０において、ＢＧＦは、当該リソースを失効し、実行結果をＳＰＤＦに通知するため、アクノリッジメントメッセージをＳＰＤＦに返す。
【００５３】
本発明の他の実施例では、ＮＡＳＳによるリソース失効を開始するプロセスは、上記プロセスに限定されない。それはまた、図５に示されるプロセス、すなわち、ステップ５０７（ＢＧＦの決定）がまず実行され、その後ステップ５１０（ＡＦへの通知）が実行されることも可能である。すなわち、ＢＧＦをチェックし、ＡＦに通知するシーケンスは、本発明の実現形態に影響を与えないが、共通のステップは、ＳＰＤＦがさらに、ＢＧＦにサービスリソースをリリースするよう要求するか判断するというものである。
【００５４】
さらに、ＲＣＥＦに対してインストールされているポリシーを失効するかチェックし（ステップ４０５又は５０３）、Ａ−ＲＡＣＦによりＢＧＦを決定する（ステップ４０８又は５０７）シーケンスは、本発明の実現形態に影響を与えるものではなく、それについてはここでは詳細には説明されない。
【００５５】
図６を参照するに、本発明の一実施例によるＲＣＥＦによるリソース失効を開始する主要なプロセスは、以下の通りである。
【００５６】
ステップ６０１において、ＲＣＥＦは、例えば、内部の不具合により、当該ポリシーが無効になったと判断する。
【００５７】
ステップ６０２において、ＲＣＥＦは、当該ポリシーがイベント通知イベントにより無効になったとＡ−ＲＡＣＦに通知する。
【００５８】
ステップ６０３において、Ａ−ＲＡＣＦは、対応するコンテクスト情報を含む第１の確保失効リクエストをＳＰＤＦに送信することにより、対応するすべてのリソースを失効する。
【００５９】
ステップ６０４において、ＳＰＤＦは、第２の確保失効リクエストをＡＦに送信する。
【００６０】
ステップ６０５において、ＳＰＤＦは、サービスリソースをリリースするようＢＧＦに要求するか判断する。そうである場合、当該プロセスはステップ６０６に移行し、そうでない場合、それはリソース失効プロセスを終了する。
【００６１】
ステップ６０６において、ＳＰＤＦは、サービスリソースリリースリクエストメッセージをＢＧＦに送信する。
【００６２】
ステップ６０７において、ＢＧＦは、当該リソースを失効し、実行結果をＳＰＤＦに通知するため、ＳＰＤＦにアクノリッジメントメッセージを返す。
【００６３】
本発明の他の実施例では、ＲＣＥＦによるリリース失効を開始するプロセスは、上記プロセスに限定されるものではない。それはまた、図７に示されるプロセス、すなわち、ステップ７０４（ＢＧＦの決定）がまず実行され、その後ステップ７０７（ＡＦへの通知）が実行されるプロセスとすることも可能である。すなわち、ＢＧＦを決定し、ＡＦに通知するシーケンスは、本発明の実現形態に影響を与えるものではないが、共通のプロセスは、ＳＰＤＦがさらに、ＢＧＦにサービスリソースをリリースするよう要求するか判断するものである。
【００６４】
図８を参照するに、本発明の実施例による装置では、ＳＰＤＦ５０は、処理ユニット５００と、第１通知ユニット５１１と、判定ユニット５２０と、第２通知ユニット５３０とを有する。
【００６５】
処理ユニット５００は、確保失効リクエストを受信し、従来技術における基本ファンクションのために必要とされる他のすべてのプロセスを実現するのに使用される。
【００６６】
第１通知ユニット５１１は、処理ユニット５００と論理的に結合され、第１の確保失効指示に示されるように、リソース確保を失効するようＡＦに通知するのに利用される。
【００６７】
判定ユニット５２０は、処理ユニット５００と論理的に結合され、ＮＡＳＳ又はＲＣＥＦによりトリガーされる第２の確保失効指示に示されるように、サービスリソースをリリース及び失効するようＢＧＦに要求するか判断するのに利用される。
【００６８】
第２通知ユニット５３０は、処理ユニット５００と論理的に結合され、判定ユニット５２０がサービスリソースをリリース及び失効するようＢＧＦに要求するよう決定すると、ＢＧＦに通知するのに利用される。
【００６９】
上記実施例におけるＳＰＤＦの機能構成では、第２通知ユニット５３０は第１通知ユニット５１１に含めることが可能であり、すなわち、これら２つの通知ユニットは一体的な構成とされる。
【００７０】
本発明の他の実施例では、ＳＰＤＦは、他の物理的装置に含まれる論理ファンクションエンティティ又は独立した物理的装置とすることが可能である。
【００７１】
ある実施例では、判定ユニット５２０は、コンテクスト解析ユニットと判断ユニットとを有する。コンテクスト解析ユニットは、ＡＦがリソースを要求したときに生成され、Ａ−ＲＡＣＦからの確保失効通知に含まれるコンテクストを解析するのに利用され、判断ユニットは、解析結果に従って当該セッションのためにＢＧＦがサービスリソースを割り当てたか判断するのに利用される。
【００７２】
本発明の他の実施例では、判定ユニット５２０は、レコード情報検索ユニットと判断ユニットとを有する。レコード情報検索ユニットは、ＡＦがリソースを要求したときに生成され、ローカルに記録される情報を検索するのに利用され、判断ユニットは、検索結果に従って当該セッションのためにＢＧＦがサービスリソースを割り当てたか判断するのに利用される。
【００７３】
本発明の趣旨及び範囲から逸脱することなく、当業者は本発明に対して様々な変更及び変形を行うことが可能であるということは明らかである。しかしながら、そのような変更及び変形は何れも、それが請求項に規定される範囲又は均等な技術的範囲内に属する場合、本発明の保護範囲に属するであろう。
【図面の簡単な説明】
【００７４】
【図１】図１は、従来技術によるＲＡＣＳアーキテクチャの概略図である。
【図２】図２は、従来技術によるＮＡＳＳによるリソース失効を開始する処理フロー図である。
【図３】図３は、従来技術によるＲＣＥＦによるリソース失効を開始する処理フロー図である。
【図４】図４は、本発明の一実施例によるＮＡＳＳによるリソース失効を開始する処理フロー図である。
【図５】図５は、本発明の他の実施例によるＮＡＳＳによるリソース失効を開始する処理フロー図である。
【図６】図６は、本発明の一実施例によるＲＣＥＦによるリソース失効を開始する処理フロー図である。
【図７】図７は、本発明の他の実施例によるＲＣＥＦによるリソース失効を開始する処理フロー図である。
【図８】図８は、本発明の実施例において提供される装置のブロック図である。
【図１】
0004540648.tif 000002
【図２】
0004540648.tif 000003
【図３】
0004540648.tif 000004
【図４】
0004540648.tif 000005
【図５】
0004540648.tif 000006
【図６】
0004540648.tif 000007
【図７】
0004540648.tif 000008
【図８】
0004540648.tif 000009