JP6511520B2 - 下層ネットワークとのサービス層課金相関の方法および装置 - Google Patents

Description

（関連出願の引用）
本願は、米国仮特許出願第６２／０６９，４６４号（２０１４年１０月２８日出願）に対する優先権を主張し、上記出願の開示は、その全体が参照により本明細書に引用される。

（背景）
第３世代パートナーシッププロジェクト（３ＧＰＰ）は、無線アクセス、コアトランスポートネットワーク、およびサービス能力を含むセルラー電気通信ネットワーク技術を対象とする。無線通信のための３ＧＰＰモバイルコアネットワーク（ＭＣＮ）アーキテクチャの最新バージョンは、進化型パケットコア（ＥＰＣ）と称される。進化型パケットコア（ＥＰＣ）は、性能および費用の視点からデータトラフィックを効率的に処理するために、「フラットアーキテクチャ」を有する。ＥＰＣはまた、ＥＰＣスケールを独立させるために、ユーザデータ（ユーザプレーンとしても公知である）および信号伝達（制御プレーンとしても公知である）を分離する。

３ＧＰＰネットワークポリシーおよび課金制御（ＰＣＣ）システムは、加入者毎に、かつＩＰデータフロー毎に、ポリシーおよび課金の動的制御を提供する。これは、アプリケーションサーバが、サービス品質（ＱｏＳ）および配信されるサービスのための課金ポリシーを動的に制御することを可能にするために、より細かいＱｏＳをサポートする。

図１は、それらの間に規定インターフェースを伴ういくつかの機能から成る、ＰＣＣアーキテクチャ１００を図示する略図である。ポリシーおよび課金規則機能（ＰＣＲＦ）１０２は、ＩＰ−ＣＡＮセッション、ＩＰ−ＣＡＮベアラ、またはサービスデータフロー（ＳＤＦ）のためのポリシーおよび課金を管理する責任がある。ポリシーおよび課金実施機能（ＰＣＥＦ）１０４は、サービスデータフロー検出、ポリシー実施、およびフローベースの課金機能性を包含する。３ＧＰＰネットワークは、オフラインおよびオンライン課金の両方をサポートする。オフライン課金システム（ＯＦＣＳ）１０６は、課金情報が、後払い加入者等の与えられたサービスにリアルタイムで影響を及ぼさない機構である。ＯＦＣＳ１０６は、課金データ機能（ＣＤＦ）と、課金ゲートウェイ機能（ＣＧＦ）とを含む。ＣＤＦは、課金データ記録（ＣＤＲ）を構築するために、課金トリガ機能（ＣＴＦ）から受信される情報を使用する。ＣＧＦは、ＣＤＲを転送するために、３ＧＰＰネットワークと請求ドメインとの間のゲートウェイの役割を果たす。対照的に、オンライン課金システム（ＯＣＳ）１０８は、課金機能、例えば、クレジット制御をリアルタイムで行う。これは、ＯＣＳ１０８が、典型的には、前払加入者のために、リアルタイムでサービス実行に影響を及ぼすことを可能にする。量ベース、時間ベース、量および時間ベース、イベントベース、ならびに課金なし等の種々の課金モデルが、３ＧＰＰネットワークによってサポートされる。

プロトコルスタックの視点から、サービス層は、典型的には、アプリケーションプロトコル層の上方に位置し、付加価値サービスをクライアントアプリケーションに提供する。故に、サービス層は、多くの場合、「ミドルウェア」サービスとして分類される。例えば、図２は、ＩＰネットワークスタック２０４とアプリケーション２０６との間の例示的サービス層２０２を図示する略図である。

Ｍ２Ｍ／ＩｏＴサービス層は、Ｍ２Ｍ／ＩｏＴタイプデバイスおよびアプリケーションのための付加価値サービスを提供することを特に標的とするあるタイプのサービス層の実施例である。最近、いくつかの業界標準化団体（例えば、ｏｎｅＭ２Ｍ）が、インターネット／ウェブ、セルラー、企業、およびホームネットワーク等の展開の中へのＭ２Ｍ／ＩｏＴタイプのデバイスならびにアプリケーションの統合に関連付けられる課題に対処するために、Ｍ２Ｍ／ＩｏＴサービス層を開発している。

Ｍ２Ｍサービス層は、サービス層によってサポートされるＭ２Ｍ指向能力の集合体へのアプリケーションおよびデバイスのアクセスを提供することができる。いくつかの実施例は、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、およびコネクティビティ管理を含む。これらの能力は、Ｍ２Ｍサービス層によって定義されるメッセージフォーマット、リソース構造、およびリソース表現を利用するＡＰＩを介して、アプリケーションに利用可能にされる。

ｏｎｅＭ２Ｍは、種々のハードウェアおよびソフトウェア内に容易に組み込まれ、分野内の様々なデバイスを世界中のＭ２Ｍアプリケーションサーバと接続するために依拠されることができる共通Ｍ２Ｍサービス層に対するニーズに対処する技術的仕様を開発する新しい規格である。

図３は、共通サービス機能（ＣＳＦ）の組（すなわち、サービス能力）をサポートするｏｎｅＭ２Ｍ共通サービス層３０２を図示する略図である。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、特定用途向けノード）上でホストされることができる共通サービスエンティティ（ＣＳＥ）３０４と称される。

ｏｎｅＭ２Ｍは、２つのアーキテクチャのアプローチにおいてサービス層を開発している。図４は、ｏｎｅＭ２ＭのためのＲｏＡ（リソース指向アーキテクチャ）アーキテクチャを図示する略図である。リソースは、作成、読み出し、更新、および削除等のＲＥＳＴｆｕｌ方法を介して操作可能な表現を有する、アーキテクチャ内の固有にアドレス可能な要素である。これらのリソースは、ユニバーサルリソース識別子（ＵＲＩ）を使用して、アドレス可能にされる。リソースは、子リソースおよび属性を含み得る。子リソースは、親リソースとの包含関係を有するリソースである。親リソース表現は、その子リソースへの参照を含む。子リソースの寿命は、親のリソース寿命によって限定される。各リソースは、リソースの情報を記憶する「属性」の組をサポートする。

図５は、ｏｎｅＭ２ＭのためのＳｏＡ（サービス指向アーキテクチャ）を図示する略図である。ＳｏＡアーキテクチャは、ＲＥＳＴｆｕｌベースではない旧来の展開を考慮するように開発されている。それは、大部分が同じサービス層機能アーキテクチャを再利用する。サービス層は、種々のＭ２Ｍサービスを含み、複数のサービスが、サービスコンポーネントの中にグループ化されることができる。既存の基準点に加え、それは、サービス間基準点Ｍｓｃも導入する。Ｍｓｃ基準点を経由してパスされるＭ２Ｍサービスコンポーネント間の通信は、ウェブサービスアプローチ、例えば、Ｗｅｂサービスメッセージ交換パターン（ＭＥＰ）を利用する。

再び図３を見ると、Ｍｃｎ基準点は、共通サービスエンティティ（ＣＳＥ）３０４と下層ネットワークサービスエンティティ（ＮＳＥ）３０６との間の通信フローのために設計される。これらのフローは、ＣＳＥ３０４が、下層ＮＳＥ３０６によって提供されるサポートされたサービス（トランスポートおよびコネクティビティサービス以外）を使用することを可能にする。

Ｍｃｎ基準点をまたぐＣＳＥ３０４とＮＳＥ３０６との間の通信は、以下を含む。
・ ＣＳＥによる下層ネットワークによって提供されるネットワークサービスにアクセスを提供すること
・ 下層ネットワークのためのネットワークサービス処理を最適化すること
そのようなサービスは、通常、単なる一般的トランスポートサービスではない。

下層ネットワークまでＭｃｎ基準点を経由してパスされる通信は、以下を含む。
・ いくつかの既存の機構を使用して、アプリケーションおよびネットワークオペレータによって幅広く展開されるメッセージングサービス
・ それらのサービスのためにネットワークオペレータによって使用される他のＳＤＯ（例えば、ＯＭＡおよびＧＳＭ（登録商標）Ａ）によって定義されるネットワークＡＰＩ
・ ３ＧＰＰネットワークによって定義されているＭＴＣ（マシンタイプ通信）用のサービスおよびセキュリティ側面のためのインターワーキング

ｏｎｅＭ２Ｍによって定義されるサービス課金および会計（ＳＣＡ）ＣＳＦ３０８は、全ての課金および会計問題に対処する責任がある。表１は、課金相関に関連する課金要件を示すが、これらの要件は、現在のｏｎｅＭ２Ｍ仕様で完全には対処されていない。

サービス層課金相関のための機構が、開示される。例示的機構は、どのようにしてサービス層が課金相関情報に関して下層ネットワークと相互作用するか、および、どのようにしてサービス層において課金相関を行うかを説明する。

実施形態は、下層ネットワークと相互作用し、サービス層において課金情報を相関させる責任があるサービスドメイン課金相関機能（ＳＤ−ＣＣＦ）を含むことができる。課金相関情報は、サービス層課金相関を有効にして促進するために使用されることができる。ＳＤ−ＣＣＦのためのプロシージャは、サービス層における課金相関を促進するために、下層ネットワークと相互作用するために使用されることができる。

ｏｎｅＭ２Ｍ実施形態は、どのようにして提案されたＳＤ−ＣＣＦが、サービス層課金相関を行うために３ＧＰＰネットワークとインターワーキングすることができるかを示す。既存のサービス層課金は、サービス層において課金相関を行ういかなる機構も含まない。特に、既存のサービス層課金は、下層ネットワークから相関のための課金関連情報およびどのようにしてサービス層において課金相関を行うかを取得する機構を有していない。

本概要は、発明を実施するための形態において以下でさらに説明される、一連の概念を簡略化形態において導入するために提供される。本概要は、請求される主題の主要な特徴または不可欠な特徴を識別することを意図しておらず、また、請求される主題の範囲を限定するために使用されることも意図していない。
例えば、本願は以下の項目を提供する。
（項目１）
通信ネットワークのサービス層内のノードによる使用のための方法であって、前記ノードは、プロセッサと、メモリとを備え、前記ノードは、前記メモリ内に記憶されたコンピュータ実行可能命令をさらに含み、前記命令は、前記プロセッサによって実行されると、
相関イベントを送信するためのトリガを前記通信ネットワーク内に設定することと、
前記トリガの結果として相関イベントを受信することと、
前記相関イベントに基づいて前記サービス層における課金動作を更新することと
を含む方法の機能を果たす、方法。
（項目２）
前記トリガは、課金ポリシートリガである、項目１に記載の方法。
（項目３）
前記トリガは、課金イベントトリガである、項目１に記載の方法。
（項目４）
前記課金イベントトリガは、前記サービス層がサービス層課金情報記録（例えば、ＣＤＲ）を更新すべきこと、またはサービス層課金動作を更新すべきことの指示である、項目３に記載の方法。
（項目５）
前記トリガの前記設定は、課金相関規則に従って行われる、項目１に記載の方法。
（項目６）
サービスドメイン−課金相関機能（ＳＤ−ＣＣＦ）が、相関イベントを報告するために前記トリガの前記設定を開始する、項目１に記載の方法。
（項目７）
前記ＳＤ−ＣＣＦは、課金相関規則を管理する、項目６に記載の方法。
（項目８）
前記課金相関規則は、前記トリガが設定されるべきことと、前記サービス層課金相関を行う方法とを示す、項目７に記載の方法。
（項目９）
通信ネットワークのサービス層内のノードであって、前記ノードは、プロセッサと、メモリとを備え、前記ノードは、前記ノードの前記メモリ内に記憶されたコンピュータ実行可能命令をさらに含み、前記命令は、前記ノードのプロセッサによって実行されると、
相関イベントを送信するためのトリガを前記通信ネットワーク内に設定することと、
前記トリガの結果として相関イベントを受信することと、
前記相関イベントを使用して、前記サービス層における課金動作を更新することと
を前記ノードに行わせる、ノード。
（項目１０）
前記トリガは、課金ポリシートリガである、項目９に記載のノード。
（項目１１）
前記トリガは、課金イベントトリガである、項目９に記載のノード。
（項目１２）
前記課金イベントトリガは、前記サービス層がサービス層課金情報記録（例えば、ＣＤＲ）を更新すべきこと、またはサービス層課金動作を更新すべきことの指示である、項目１１に記載のノード。
（項目１３）
前記トリガの前記設定は、課金相関規則に従って行われる、項目９に記載のノード。
（項目１４）
サービスドメイン−課金相関機能（ＳＤ−ＣＣＦ）が、前記トリガの前記設定を開始する、項目９に記載のノード。
（項目１５）
前記ＳＤ−ＣＣＦは、課金相関規則を管理する、項目１４に記載のノード。
（項目１６）
前記課金相関規則は、前記トリガが設定されるべきことと、前記サービス層課金相関を行う方法とを示す、項目１５に記載のノード。
（項目１７）
通信ネットワーク内のノードによる使用のための方法であって、前記ノードは、プロセッサと、メモリとを備え、前記ノードは、前記メモリ内に記憶されたコンピュータ実行可能命令をさらに含み、前記命令は、前記プロセッサによって実行されると、
前記通信ネットワークのサービス層からトリガを受信することと、
前記トリガを使用して、相関イベントを生成することと、
前記トリガの結果として、前記相関イベントを前記サービス層に送信することと
を含む方法の機能を果たす、方法。
（項目１８）
プロセッサとメモリとを備えている通信ネットワークのノードであって、前記ノードは、前記ノードの前記メモリ内に記憶されたコンピュータ実行可能命令をさらに含み、前記命令は、プロセッサによって実行されると、
前記通信ネットワークのサービス層からトリガを受信することと、
前記トリガを使用して、相関イベントを生成することと、
前記トリガの結果として、前記相関イベントを前記サービス層に送信することと
を前記ノードに行わせる、ノード。

より詳細な理解が、添付図面と併せて一例として挙げられる、以下の説明から取得され得る。

図１は、３ＧＰＰネットワークポリシーおよび課金制御（ＰＣＣ）アーキテクチャを図示する略図である 図２は、ＩＰネットワークスタックとアプリケーションとの間の例示的サービス層を図示する略図である。 図３は、共通サービス機能（ＣＳＦ）の組（すなわち、サービス能力）をサポートするｏｎｅＭ２Ｍ共通サービス層を図示する略図である。 図４は、ｏｎｅＭ２ＭのためのＲｏＡ（リソース指向アーキテクチャ）アーキテクチャを図示する略図である。 図５は、ｏｎｅＭ２ＭのためのＳｏＡ（サービス指向アーキテクチャ）を図示する略図である。 図６は、サービスドメイン課金システムのアーキテクチャの略図である。 図７Ａ−Ｂは、３ＧＰＰネットワークとサービス層との間の例示的メッセージ交換プロシージャを図示する略図である。 図７Ａ−Ｂは、３ＧＰＰネットワークとサービス層との間の例示的メッセージ交換プロシージャを図示する略図である。 図８は、＜ｅｖｅｎｔＣｏｎｆｉｇ＞リソースおよび＜ｓｔａｔｓＣｏｌｌｅｃｔ＞リソースを図示する略図である。 図９は、一実施形態の例示的アーキテクチャを示す、略図である。 図１０は、従来技術の課金システムに関する問題を示すフロー図である。 図１１は、Ｍ２Ｍサービス層インスタンス内でホストされることができるサービスドメイン課金相関機能（ＳＤ−ＣＣＦ）を図示する略図である。 図１２は、一実施形態において新しい課金相関規則を作成するためのプロシージャを図示するフロー図である。 図１３は、一実施形態の課金ポリシー相関のためのメッセージ交換のプロシージャを図示するフロー図である。 図１４は、課金情報相関を促進するためのメッセージ交換のプロシージャを図示するフロー図である。 図１５は、サービス層課金相関を行うための例示的方法を図示するフロー図である。 図１６は、ｏｎｅＭ２Ｍ機能的アーキテクチャに基づくサービス課金および会計（ＳＣＡ）ＣＳＦの一部として提案されたＳＤ−ＣＣＦを実装するための一例示的実施形態を図示する略図である。 図１７は、＜ｃｈａｒｇｉｎｇＣｏｒｒｅｌａｔｉｏｎＲｕｌｅ＞リソースを図示する略図である。 図１８は、＜ｃｈａｒｇｉｎｇＣｏｒｒｅｌａｔｉｏｎＴｒｉｇｇｅｒ＞リソースを図示する略図である。 図１９は、３ＧＰＰネットワークとのｏｎｅＭ２Ｍ課金ポリシー相関の例示的実施形態を図示する略図である。 図２０は、３ＧＰＰネットワーク使用事例とのｏｎｅＭ２Ｍ課金情報相関の例示的実施形態を図示する略図である。 図２１は、ｏｎｅＭ２Ｍ ＳｏＡアーキテクチャにおける提案されたＳＤ−ＣＣＦ１１０２の実施形態を図示する略図である。 図２２Ａは、ＩｏＴイベント管理システムおよび方法の１つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）もしくはモノのインターネット（ＩｏＴ）通信システムの略図である。 図２２Ｂは、図２２Ａに図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。 図２２Ｃは、図２２Ａに図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。 図２２Ｄは、図２２Ａの通信システムの側面が具現化され得る、例示的コンピュータシステムのブロック図である。 図２３Ａ−Ｂは、一実施形態の例示的インターフェースを図示する略図である。 図２３Ａ−Ｂは、一実施形態の例示的インターフェースを図示する略図である。

図６は、サービス層が下層ネットワークから独立しているサービス層課金を行うことを可能にするサービスドメイン課金システムのアーキテクチャの略図である。特に、サービスドメイン課金管理（ＳＤ−ＣＭ）６０４は、サービスドメイン課金システム（ＳＤ−ＣＳ）６０２の中心である。ＳＤ−ＣＭ６０４は、課金ポリシーを管理して維持し、課金情報のアグリゲータおよびディスパッチャとしての機能を果たし、異なるノード内のＳＤ−ＣＳの間の相互作用のアンカポイントの役割を果たす。サービスドメインオフライン課金システム（ＳＤ−ＯＦＣＳ）６０６は、ＳＤ−ＣＭ６０４からオフライン課金イベントを受信し、サービスドメイン課金データ記録（ＳＤ−ＣＤＲ）を生成する。サービスドメインオンライン課金システム（ＳＤ−ＯＣＳ）６０８は、サービス要求を受信し、クレジットをチェックし、サービスを供与する。ＳＤ−ＯＣＳ６０８は、異なるサービス加入者のためのクレジット情報を維持することができる。

図７Ａ−Ｂは、３ＧＰＰネットワークとサービス層（すなわち、図６に示されるＳＤ−ＣＳ６０２）との間の例示的メッセージ交換プロシージャを図示する略図である。図に示されるプロシージャは、図に示されるような順序で起こる必要はない。そのような相互作用は、３ＧＰＰネットワークとサービスドメインとの間により統合された課金を提供する。

図７Ａ−Ｂのステップ１−４では、１つの展開シナリオにおいて、３ＧＰＰネットワーク課金システムは、ＳＤ−ＣＳ６０２を制御し得る。３ＧＰＰネットワーク課金ポリシーエンティティＰＣＲＦ７０２は、Ｒｘ基準点を介して、ＳＤ−ＣＳ６０２のための課金ポリシー構成を送信する。ＳＤ−ＣＳ６０２は、３ＧＰＰネットワーク課金システムからの入力に基づいて、その課金ポリシーを構成する。

図７Ａ−Ｂのステップ５−８は、ＭＴＣ−ＩＷＦ７０４が、Ｔｓｐ基準点を介して、３ＧＰＰネットワーク課金情報をＳＤ−ＣＳ６０２に送信する実施例を示す。例えば、ＭＴＣ−ＩＷＦ７０４は、３ＧＰＰ加入者情報を有し、ＳＤ−ＣＳ６０２は、３ＧＰＰネットワークＩＤをサービスドメインＩＤに関連付けることができる。

図７Ａ−Ｂのステップ９−１２では、ＰＣＲＦ７０２は、セッションステータス等の３ＧＰＰネットワーク課金関連情報をＳＤ−ＣＳ６０２にパスすることができる。ＳＤ−ＣＳ６０２は、そのポリシーに従って措置を講じる。例えば、ＳＤ−ＣＳ６０２は、３ＧＰＰネットワークセッションが別のアクセス技術に手渡されたときに異なるレートを適用し得る。

図７Ａ−Ｂのステップ１３−１５において、別の実施形態において、ＳＤ−ＣＳ６０２は、メッセージ交換を制御し得、ＳＤ−ＣＳ６０２は、ユーザプレーン基準点Ｇｉ／ＳＧｉを経由したＰＣＥＦ７０６へのサービスドメイン動作メッセージの中にサービスドメイン課金情報を添付することができる。課金は、ＰＣＥＦ７０６において行われ、情報は、ユーザプレーンを経由してＳＤ−ＣＳ６０２に返信され、ＰＣＲＦ７０２は、必要であればＰＣＥＦ７０６によって、それに応じて更新され得る。

図７Ａ−Ｂに図示されるステップを行うエンティティは、図２２Ｃまたは２２Ｄに図示されるもののうちの１つ等のノード、デバイス、サーバ、もしくは他のコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図７Ａ−Ｂに図示される方法は、例えば、図２２Ｃまたは２２Ｄに図示されるデバイスもしくはコンピュータシステム等のコンピュータデバイスのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、コンピュータデバイスのプロセッサによって実行されると、図７Ａ−Ｂに図示されるステップを行う。図７Ａ−Ｂに図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることも理解されたい。加えて、現在のｏｎｅＭ２Ｍ仕様は、図８に示されるように、課金ポリシーおよび課金記録情報を記録して維持するために、＜ｅｖｅｎｔＣｏｎｆｉｇ＞リソース８０２ならびに＜ｓｔａｔｓＣｏｌｌｅｃｔ＞リソース８０４を定義する。特に、＜ｅｖｅｎｔＣｏｎｆｉｇ＞リソース８０２は、詳細情報とともに課金可能イベントを維持し、＜ｓｔａｔｓＣｏｌｌｅｃｔ＞リソース８０４は、課金ポリシーの性質を示す属性とともに具体的課金ポリシーを維持する。

３ＧＰＰネットワークは、いくつかの仕様において課金相関の概念を導入する。一実施形態では、課金データ相関が、課金トリガ機能（ＣＴＦ）によって生成される複合課金イベントとして定義されるが、それらは、同一のベアラ／セッション／サービスリソース使用に属する。相関は、携帯電話加入者のリソース使用に対する課金情報の関連付けを提供する。加えて、ＩＭＳセッションに関与する異なるオペレータが互いに識別することを可能にするために、オペレータ間識別概念（ＩＯＩ）が、ネットワーク間相関のために導入される。

別の仕様では、課金相関は、３ＧＰＰコアネットワークとＩＭＳとの間で議論される。しかしながら、そこでは相関は、２つのネットワークにわたるＩＤマッピング／関連付けのみに焦点を当てる。

オープンモバイルアライアンス（ＯＭＡ）は、課金相関の概念を定義する。相関が、異なるエンティティによって生成される課金イベントの間で起こり得るが、それらは、協調的に単一のサービスを提供している。相関機能は、課金されるであろうユーザ／アプリケーションに対するイベントの関連付けを提供することができる。この相関は、ネットワーク間相関の代わりに、ＯＭＡ視点内の課金動作に焦点を当てる。

サービス層課金相関は、下層ネットワークによって提供される課金相関情報に基づいてサービス層課金挙動を動的に調節するより広い概念である。

サービスプロバイダが、サービス層動作（例えば、センサデータ読み取り、データ読み出し）に関連するトランザクションに基づいてサービス加入者に課金する一方で、下層ネットワークは、データフローのトランスポートに基づいてサービス加入者に課金する。２つの層における動作は、相関性があり、例えば、サービス層におけるデータ読み出し動作は、下層トランスポート層におけるデータトランスポートも伴うであろう。したがって、サービス層および下層ネットワークのために、同一の課金関連情報を相関させる必要がある。

サービスプロバイダである企業Ａは、図９に示されるように、そのサービス層プラットフォーム９０４を通して家庭用監視サービス９０２を提供する。サービス加入者は、家庭から旅行しているとき、家の内側および外側に固定されたカメラ９０８を介して自分の家を監視するために、携帯電話またはタブレット等のユーザ機器（ＵＥ）９０６上にインストールされたアプリケーションを使用したいと思う。サービス加入者が自分の携帯電話９０６を通してカメラ９０８に画像／ビデオ伝送を要求する場合において、カメラ９０８は、カメラ９０８によって捕捉される画像／ビデオの伝送を自動的に開始することができる。カメラ９０８はまた、カメラによって捕捉される異常（例えば、侵入者）画像がある場合において、サービス加入者の携帯電話９０６に呼び掛けるアラームのために、オーディオ／ビデオ呼び出しを開始するか、またはメッセージを送信することが可能であり得る。

サービスプロバイダ（すなわち、企業Ａ）は、下層アクセスネットワークから分離された課金を行いたいと思う。サービス加入者は、毎月のサービス加入料を支払い、サービス加入料は、例えば、３ＧＰＰネットワーク９１０を通した画像／ビデオの伝送のための無料の１ギガバイトを含む。サービスプロバイダは、３ＧＰＰネットワークオペレータとの合意に基づいて、３ＧＰＰネットワークデータの代金を支払う。データ量が１ギガバイトを超えると、サービスプロバイダは、追加の料金を３ＧＰＰネットワークオペレータに支払い、それに対応して、サービス加入者に追加料金を課金するであろう。この新規課金モデルは、スポンサ付きデータコネクティビティと呼ばれ、それは、最新３ＧＰＰリリースに含まれている。スポンサ（例えば、サービスプロバイダ）は、ユーザがサービスプロバイダのサービスにアクセスすることを可能にするために、ユーザのデータ使用の代金を支払う。この新規モデル（スポンサ付きデータコネクティビティ）は、サービスプロバイダおよび３ＧＰＰネットワークオペレータの両方のための追加の収益機会を可能にする。加えて、３ＧＰＰネットワーク９１０は、データフローベースの課金を行う。言い換えると、異なる価格が、ＱｏＳ（この場合はデータレート）に基づいて適用され、すなわち、より高いデータレートフローが、より低いデータレートフローよりも高い価格を負う。３ＧＰＰネットワーク９１０は、サービスプロバイダに伝送データレートの動的変化を報告し、それによって、サービスプロバイダは、それに応じてサービス加入者に適用されるサービス層課金価格を調節することができるであろう。

この場合、３ＧＰＰネットワーク９１０は、サービス加入者がデータ量閾値に達すると、サービスプロバイダに通知すべきであり、それによって、サービスプロバイダは、サービス加入者に追加料金を課金することを開始することができる。加えて、３ＧＰＰネットワーク９１０は、サービス加入者がサービスにアクセスするためのフローデータレートの変化を報告する必要がある。残念ながら、サービス層９０４が下層ネットワーク９１０において生じるイベントに従ってサービス層課金挙動を動的に調節するために定義された機構はない。この場合、サービスプロバイダは、閾値に達したときを認識していないので、サービス加入者に追加料金を課金しないであろう。さらに、サービスプロバイダは、動的課金報告／構成の欠如に起因して、下層ネットワーク内のサービスデータレートの変化を把握することができないので、常に、下層ネットワーク内のデータレートに対して同一価格をサービス加入者に適用するであろう。３ＧＰＰネットワーク９１０内のポリシーおよび課金実施機能（ＰＣＥＦ）９１２は、これらのアクティビティを監視する主要エンティティであり、それは、ポリシーおよび課金規則機能（ＰＣＲＦ）９１４にコンタクトし、そして、ＰＣＲＦ９１４は、サービス層エンティティに報告するであろうことに留意されたい。

図１０は、従来技術の課金システムに関する問題を示すフロー図である。問題１では、フローデータレートが変化した後、サービス層課金のためにそのイベントを報告するための機構がない。問題２では、スポンサ付きデータ量閾値に達した後、サービス層課金のためにそのイベントを報告するための機構がない。

サービスプロバイダが、サービス層動作（例えば、センサデータ読み取り、データ読み出し）に関連するトランザクションに基づいてサービス加入者に課金する一方で、下層ネットワーク９１０は、データフローのトランスポートに基づいてサービス加入者に課金する。２つの層における動作は、相関性があり、例えば、サービス層におけるデータ読み出し動作は、下層トランスポート層におけるデータトランスポートも伴うであろう。したがって、サービス層および下層ネットワークのために同一の課金関連情報を相関させることが必要である。

より具体的に、サービスプロバイダおよび下層ネットワークオペレータが異なるビジネスユニットであるとき、課金相関が必要とされる。たとえそれらが同一のビジネスユニットに属していても、２つの課金システムがあり得、一方は、下層ネットワーク９１０内のデータをトランスポートするためであり、他方は、サービス層トランザクションのためである。これは、サービスが異なる下層ネットワークを通して提供され得る一方、下層ネットワーク９１０が異なるサービス層プラットフォーム（すなわち、サービスプロバイダ）のためのデータフローをトランスポートし得るからである。例えば、サービスプロバイダは、クラウドサービスを提供し、クラウドインフラストラクチャにアクセスするために使用される下層ネットワークのタイプにかかわらず、サービス層課金記録を収集する。加えて、以下で紹介される使用事例は、３ＧＰＰネットワーク９１０からの課金関連情報がある場合、サービス層９０４は、３ＧＰＰネットワーク９１０内で生じる課金ポリシー変更またはいくつかの特定のトリガイベントに従って課金動作を動的に調節でき、それによって、サービスプロバイダがより正確かつ効率的な課金を達成することができることを実証する。

しかしながら、サービス層９０４が下層ネットワークエンティティから任意の課金相関情報を要求し、サービス層９０４において課金を行うために下層ネットワーク９１０（例えば、３ＧＰＰネットワーク９１０内のＰＣＲＦ９１４、ブロードバンドフォーラム（ＢＢＦ）固定ネットワーク内のポリシー実施点（ＰＥＰ））から取得される情報に基づいてサービス層挙動を調節するための一般的機構は、ない。さらに、既存のサービス層は、サービス層において課金情報（すなわち、以降で定義される課金相関情報）を相関させるためのサポートを欠いている。この機能性の欠如は、いくつかの問題につながり得る。

サービス層課金は、正確ではない。特に、サービスプロバイダは、下層ネットワークにおいて生じる課金ポリシー変更またはトリガイベントに対応して、サービス層課金挙動（例えば、新しい課金可能イベントを捕捉する、新しい課金価格を適用する）を動的に調節することができない。言い換えると、サービス層９０４は、下層ネットワーク９１０からの通知に基づいて課金挙動を調節する機構をサポートしない。これは、サービス加入者への課金不足または過剰課金につながり得る。例えば、図９の使用事例では、サービスプロバイダは、３ＧＰＰネットワーク９１０からデータ量閾値に達するという通知を受けない場合、毎月の料金に加えて、サービス加入者に追加料金を課金することを開始できない。

従来のシステムは、正確なサービス層課金のために情報交換オーバーヘッドを増加させる。サービス層９０４における課金相関機構がないと、サービスプロバイダは、サービス層課金情報を下層ネットワーク９１０に下方にパスすることによって、下層ネットワーク課金システムに頼らなければならない。これは、サービス層課金情報を交換するためにサービス層９０４と下層ネットワークとの間の頻繁な通信を必要とし、特に、Ｍ２Ｍ展開の場合、サービス層９０４上で作動する膨大な数のデバイスおよびアプリケーションが存在し得る。したがって、サービス層課金記録を下層ネットワークにパスすることは、効率的ではない。特に、サービス層９０４は、常にサービス層ＣＤＲを下層ネットワークにパスする必要がある。下層ネットワーク９１０は、下層ネットワーク内の相関情報を考慮することによって、サービス層ＣＤＲを調和させ／処理し、そして、これらのサービス層ＣＤＲを請求システムにパスする。これは、下層ネットワークが、サービス層において行われる相関を促進するための課金関連情報を送信するのみである動作と比較して、下層ネットワークとサービス層９０４との間でより多くのメッセージ交換を生じる。

余分な複雑性を下層ネットワーク９１０に追加する。下層ネットワーク９１０は、それにパスされるサービス層課金情報を解釈することができなければならない。これは、種々のタイプの課金情報を処理する能力を有する下層ネットワークを必要とし、特に、サービス層９０４内で作動する膨大な数のデバイスおよびアプリケーションがあり得る。サービス層９０４に課金を行わせ、そして、結果を下層ネットワーク９１０に下方にパスさせることによって、下層ネットワーク課金機能性は、サービス層課金ポリシー、サービス層課金情報、サービス層ＣＤＲのフォーマット等のものを認識する必要がない。

現在の解決策は、主に、下層ネットワーク９１０（例えば、３ＧＰＰネットワーク）が課金動作（すなわち、サービス層９０４が、サービス層および下層ネットワークの両方のための課金情報を統合する／調和させる責任がある、下層ネットワークに課金関連情報をパスする）を支配することを仮定する。現在のサービス層標準開発機関（ＳＤＯ）（例えば、ｏｎｅＭ２Ｍ）は、下層ネットワーク９１０からの課金情報を相関させることによって、サービス層９０４課金を促進するいかなる機構も定義しなかった。サービス層において行われるより正確かつ効率的な課金のために、下層ネットワーク９１０（例えば、３ＧＰＰネットワーク）からの課金情報を相関させることができるサービスプロバイダのために定義された機構がない。既存のサービス層課金解決策（例えば、図６および図７Ａ−Ｂ）は、下層ネットワークとサービス層との間のいくつかの相互作用を定義するが、下層ネットワークからある課金情報を入手したときにサービス層において課金情報を相関させる動作に対処する機構がない。

以下は、下層ネットワークによって提供される課金相関情報に基づいてサービス層課金挙動を動的に調節する動作として、サービスドメイン課金相関を開示する。

動的課金動作をサポートするために、サービスドメイン課金相関機能（ＳＤ−ＣＣＦ）１１０２は、以下のタイプの機能性のうちのいくつかまたは全てを実施することができるが、それらに限定されない：サービス層課金相関規則を管理すること、下層ネットワークと相互作用すること、およびサービス層課金相関を行うこと。

サービス層課金相関規則を管理（作成、更新、および削除）することは、サービス層課金相関を促進することができる。特に、ＳＤ−ＣＣＦ１１０２は、エンティティ（例えば、課金サービス能力、アプリケーション）からの課金相関規則を作成／更新／削除するための要求を受信することができ、そして、所望の動作を行う。

下層ネットワークと相互作用することは、サービス層課金動作に影響を及ぼし得る、下層ネットワーク内の課金相関トリガを構成することができる。以降で定義されるように、課金相関トリガは、下層ネットワーク１１０６において起こり、下層ネットワーク１１０６内の課金ポリシーまたは課金情報を反映することができる。この機能は、ＳＤ−ＣＣＦ１１０２と下層ネットワークエンティティとの間のメッセージ交換を通して達成される。特に、ＳＤ−ＣＣＦ１１０２は、下層ネットワーク内の課金ポリシーおよび情報に関するいくつかのトリガを構成することができる。下層ネットワーク１１０６から発生通知を受信すると、ＳＤ−ＣＣＦ１１０２は、サービス層課金ポリシーを構成すること、課金動作を更新するために他の課金関連エンティティ（例えば、ＣＴＦおよび課金ＳＣ）に通知すること等の一連のアクションを行い得る。

サービス層課金相関を行うことは、サービス層課金ポリシーを更新し、課金動作およびサービス層ＣＤＲを調節することができる。特に、ＳＤ−ＣＣＦは、例えば、サービス層課金ポリシーを変更する必要がある場合、ある新しいタイプの課金可能イベントを捕捉する必要がある場合等の下層ネットワークからの受信されたトリガへの応答として、いくつかのアクションを行うことによってワークフローを辿る。

図１１に示されるように、サービスドメイン課金相関機能（ＳＤ−ＣＣＦ）１１０２は、例えば、図１１に示されるように、Ｍ２Ｍサービス層インスタンス１１０４内の個別サービス能力として、Ｍ２Ｍサービス層インスタンス１１０４内でホストされることができる。ＳＤ−ＣＣＦ１１０２は、既存の課金ＳＣ内のサブ機能でもあり得る。

サービス層課金相関は、下層ネットワークによって提供される課金相関情報に従って、サービス層課金挙動を調節するプロセスとして定義される。課金相関の実施例は、以下であり得る：サービス層プラットフォームを通してサービスデータを読み出しているとき、サービス加入者が下層ネットワーク１１０６内でクレジットを使い果たす。サービスプロバイダは、下層ネットワーク１１０６から通知を受け、データ読み出しの同一のＱｏＳを維持するために、サービス加入者のサービス層クレジットアカウントから追加料金を課金することを開始する。

サービス層課金相関規則は、サービス層課金相関を行うための規則を定義することができる。課金相関規則は、サービス特定であり、事前構成された方法または動的方法のいずれかでサービスプロバイダによって管理されることができる。規則は、以下のコンテンツを含むことができる：実施可能指示、相関スケジュール、ネットワーク課金相関トリガ組、および下層ネットワークのタイプ。

実施可能指示は、課金相関がサービスのために可能にされるかどうか、すなわち、サービスのための課金ポリシー、課金情報、または両方を相関させるためにそれが許可されるかどうかを示すことができる。相関規則は、サービス特定、すなわち、サービス毎の規則であることに留意されたい。言い換えると、異なるサービスは、異なる課金相関規則を有し得る。

相関スケジュールは、どれだけ頻繁に課金相関が行われるかを示すことができる。

ネットワーク課金相関トリガ組は、サービス層課金相関動作をトリガし得る、下層ネットワークからのトリガの組を示すことができる。

下層ネットワークのタイプは、どのタイプの下層ネットワークが課金相関に関与すると予期されるかを示すことができる。

ネットワーク課金相関トリガは、サービス層１１０４における課金相関動作をトリガする、下層ネットワーク内で生じるトリガイベントを定義することができる。そして、課金相関トリガはさらに、２つのタイプに分類されることができる。

課金ポリシートリガは、サービス層１１０４がサービス層課金ポリシーを変更することを要求し得る、下層ネットワーク１１０６内の課金ポリシー変更を示唆することができる。下層ネットワークは、サービスデータフローをトランスポートするためにその課金ポリシーを変更し、サービス層も、それに応じて課金ポリシーを調節する必要があり得る。この課金ポリシートリガは、以下であり得るが、それらに限定されない：ＱｏＳパラメータ変更、課金率変更、課金測定パラメータ変更、サービス加入者の下層ネットワーク加入変更、および下層ネットワーク課金ディスカウントまたはボーナスの変更。

ＱｏＳパラメータ変更トリガは、下層ネットワーク課金ポリシーに結び付くＱｏＳパラメータが、サービスデータフローをトランスポートするために変更されることを示唆することができる。結果として、サービス層１１０４は、課金ポリシーを更新する必要がある。例えば、３ＧＰＰネットワークオペレータは、サービスデータフローをトランスポートするために、同一課金率で１０Ｍｂｐｓから５Ｍｂｐｓに保証データレートを変更する。スポンサ付きデータコネクティビティモデルの下で、サービスプロバイダは、３ＧＰＰネットワークデータの代金を支払い、サービス加入者に課金し、サービスプロバイダは、同一課金率でサービス層課金ポリシーに結び付くデータレートを減少させることができるか、または元のデータレートを維持して、より高い課金率を適用することができるかのいずれかである。

課金率変更トリガは、課金率が下層ネットワーク内で変更され、その結果として、それがサービス層課金率に影響を及ぼすことを示唆することができる。

課金測定パラメータ変更トリガは、課金測定方法が下層ネットワーク内のサービス層データフローのために変更されることを示唆することができる。例えば、Ｍ２Ｍアプリケーション１１０８が非常に多数のデバイスを展開し、各トランザクションのために少量のデータ量を必要とし得るので、課金測定は、センサデータ読み出しサービスのためにデータ量ベースの課金からトランザクションベースに変更される。

サービス加入者の下層ネットワーク加入変更トリガは、サービス加入者が下層ネットワーク内でその毎月のデータプランを変更するときに起こり、それは、ユーザがサービス層においてサービスを使用するためにより多くの帯域幅（例えば、より高いデータレート）を得ることを可能にし得る。

下層ネットワーク課金ディスカウントまたはボーナスの変更トリガは、サービス層１１０４がサービス層ポリシーを変更すること、または規定時間中にそれが起こるように、そのトラフィックを遅延させる／予定に入れるためにディスカウント率でサービス加入者のために別のポリシーを適用することを可能にすることができる。

課金イベントトリガは、サービス層課金情報記録（例えば、ＣＤＲ）を更新するため、または課金動作を更新するためにサービス層をトリガするイベントを含むことができる。サービスに対して、下層ネットワークからの異なるイベントを用いて、サービス層は、異なる課金ポリシーを動的に適用し、異なる課金可能イベントを収集し得る。例えば、トリガは、以下であり得るが、それらに限定されない：スポンサ付きデータ量閾値への到達、サービス開始／停止、クレジット外、サービスデータフローオフロード、および下層ネットワーク内のディスカウント帯域幅の可用性。

スポンサ付きデータ量閾値への到達トリガは、サービス加入者が下層ネットワーク内のスポンサ付きデータリンクのデータ量閾値に達することを示すことができ、それは、通常、さらなるデータトランスポートのためにサービス加入者に追加料金を負担させる。

サービス開始／停止トリガは、サービスデータフロー開始／停止が特定の下層ネットワークを通してトランスポートされることを示すことができる。

クレジット外トリガは、下層ネットワーク内のユーザのクレジットが、現在のＱｏＳを伴うサービスを使用し続けるために十分ではない場合があることを示すことができる。これは、サービス層が、１）サービスを提供することを停止すること、またはＱｏＳレベルを低下させること、２）サービス層においてユーザにより多く課金することによって同一ＱｏＳを維持することをトリガし得。言い換えると、オプション１が、異なるＱｏＳパラメータを伴う新しい課金ポリシーを適用する一方で、オプション２は、より高い課金率を伴う新しい課金ポリシーを適用する。例として、この情報は、３ＧＰＰによって定義される特定アクション属性値ペア（ＡＶＰ）および最終ユニットアクションＡＶＰを通して表され、交換され得る。

サービスデータフローオフロードトリガに対して、下層ネットワーク１１０６は、下層ネットワーク１１０６がサービスのためのサービスデータフローを別の下層ネットワークにオフロードすることを示し、それによって、サービス層１１０４は、新しい下層ネットワークのために課金動作を調節し得る。オフロードをトリガし得る複数の理由があり、例えば、元の下層ネットワークの混雑、およびモビリティに起因するより良好な伝送品質。

下層ネットワーク内のディスカウント帯域幅の可用性トリガは、ディスカウントで課金されながら、サービス加入者がサービス層においてより高いサービス品質を受け取ることを可能にし得る。サービス層は、このシナリオの下で、サービス加入者に適用されるポリシーを調節し得る。

規則は、ポリシーと同等であり得、トリガは、イベントの発生時に追加の動作を必要とし得る特別なタイプのイベントであり得る。混乱を回避するために、「課金相関規則」という用語は、「課金ポリシー」の従来の概念と区別するために使用され、「課金相関トリガ」という用語は、「課金可能イベント」の概念と区別するために適用される。

ＳＤ−ＣＣＦ１１０２は、サービスのための課金相関規則を作成、更新、および削除する責任があり得る。課金相関規則は、サービスのために事前構成されるか、または、ＳＤ−ＣＣＦ１１０２とサービス層課金エンティティとの間の通信を通して動的に更新されることができる。図１２は、一実施形態において新しい課金相関規則を作成するためのプロシージャを図示するフロー図である。

図１２のステップ１は、課金サービス能力１２０２が、最初に、新しい課金相関規則を作成するための要求（ＣＲＥＡＴＥ）をＳＤ−ＣＣＦ１１０２に発行することを示す。例えば、課金ＳＣ１２０２によって発行される要求をトリガし得るいくつかのイベントがある。

新しいサービスが、サービスプラットフォームに追加され、サービスプロバイダは、新しいサービスのために課金相関規則を作成することを望む。

既存のサービスの新しいバージョンが、新しい機能性を提供され、それが、下層ネットワークとのさらなる課金相関動作を必要とする。この場合、既存の規則が古いバージョンに適用されるであろうので、サービスプロバイダは、既存の規則を更新する代わりに新しい規則を作成することを望む。

下層ネットワーク１１０６は、その課金能力情報、例えば、どのイベントまたはトリガを下層ネットワークがサービス層に送信することができる／送信することを許可されるかをサービス層１１０４と共有する。この情報に基づいて、サービス層は、それに応じて課金相関規則を作成／更新し得る。

要求メッセージでは、課金ＳＣ１２０２は、どのタイプの下層ネットワーク１１０６が相関のために相互作用することになっているか、どのトリガが課金相関のために有効にされるか、および新しい規則がどんなサービスのために作成されるか等の新しい規則についての詳細を規定するであろう。ＳＤ−ＣＣＦ１１０２は、要求についての課金相関規則を作成するであろう。例示的な非限定的課金相関規則が、家庭用監視サービスを参照して、表２に示されている。

課金ＳＣ１２０２は、サービス層において課金する責任があるエンティティ、例えば、図６のＳＤ−ＣＳ６１０を指す。さらに、要求側は、サービス能力エンティティである必要はない。これは、課金相関規則を定義する任意のエンティティ、下層ネットワークエンティティでさえあり得る。例えば、これは、アプリケーションであり得、アプリケーションは、サービスを定義する。

図１２のステップ２は、ＳＤ−ＣＣＦ１１０２が、新しい相関規則を作成するために要求の中のさらなる詳細または欠けている情報について課金ＳＣ１２０２にコンタクトする場合における、随意のステップである。

図１２のステップ３では、新しい規則を作成した後、ＳＤ−ＣＣＦ１１０２は、課金ＳＣ１２０２が将来、課金相関規則にアクセスし得るように、課金ＳＣ１２０２に到達可能アドレスまたはインターフェースを返す。

下層ネットワーク１１０６からの課金相関トリガは、次の節で議論されるであろう新しいサービス層課金ポリシーを作成するＳＤ−ＣＣＦ１１０２も必要とし得る。

類似プロシージャが、要求内のＣＲＥＡＴＥを置換することによって、既存の課金相関規則を更新または削除するために適用され得る。

以下は、課金相関のためのサービス層と下層ネットワークとの間のいくつかの例示的メッセージ交換プロシージャを定義する。ＳＤ−ＣＣＦ１１０２は、本項では例証のために課金ＳＣ１２０２の一部として示される。代替として、ＳＤ−ＣＣＦ１１０２は、独立型機能であり得るか、またはサービス層内の別のＳＣの一部として追加され得る。

図１２に図示されるステップを行うエンティティは、図２２Ｃまたは図２２Ｄに図示されるもののうちの１つ等のデバイス、サーバ、もしくは他のコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであり得ることを理解されたい。すなわち、図１２に図示される方法は、例えば、図２２Ｃまたは２２Ｄに図示されるデバイスもしくはコンピュータシステム等のコンピュータデバイスのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、コンピュータデバイスのプロセッサによって実行されると、図１２に図示されるステップを行う。図１２に図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることも理解されたい。

図１３は、一実施形態の課金ポリシー相関のためのメッセージ交換のプロシージャを図示するフロー図である。

図１３のステップ０では、下層ネットワーク内に課金ポリシートリガを構成する前に、ＳＤ−ＣＣＦ１１０２は、下層ネットワーク１１０６内に構成され得る課金ポリシートリガを得るためにＣＴＦ１３０２と相互作用することができる。これらのトリガは、サービス層課金挙動に影響を及ぼすであろう。

これは、オンデマンド様式で行われ得る。特に、ＣＴＦ１３０２は、これらの所望の課金可能イベントおよびこれらのイベントに含まれる情報をチェックし、任意のそのようなトリガがあるかどうかを決定する。課金ポリシー更新による影響を受け得る任意の情報がある場合、ＣＴＦ１３０２は、課金相関のために必要とされる課金ポリシートリガを規定するために、ＳＤ−ＣＣＦ１１０２にコンタクトするであろう。メッセージには、以下の情報が含まれ得る：サービス情報、課金ポリシーＩＤおよび課金可能イベントＩＤ、ならびに課金属性情報。

サービス情報に対して、ＳＤ−ＣＣＦ１１０２は、課金相関トリガがどんなサービスのために機能するかを理解することができる。

課金ポリシーＩＤおよび課金可能イベントＩＤに対して、ＳＤ−ＣＣＦ１１０２は、課金相関トリガが何を構成するために要求されるかを理解するために、より詳細な課金ポリシーおよび課金可能イベント情報を読み出すためにこの情報を使用することができる。

課金属性情報、例えば、データレートまたは課金測定方法に対して、ＳＤ−ＣＣＦ１１０２は、この情報を通して構成すべきトリガのタイプを理解することができる。

結果として、ＳＤ−ＣＣＦ１１０２は、全てのＣＴＦに１つずつコンタクトする必要はなく、ＳＤ−ＣＣＦ１１０２は、ＣＴＦが規定課金ポリシートリガとの相互作用を開始するときのみに課金ポリシートリガを構成する。

図１３のステップ１では、ＳＤ−ＣＣＦ１１０２は、下層ネットワーク内にいくつかの課金ポリシートリガを構成する。下層ネットワーク内で生じるこれらのトリガは、サービス層課金ポリシーに影響を及ぼし得る。構成メッセージでは、ＳＤ−ＣＣＦ１１０２は、ポリシートリガのリストを規定することができる。サービス層は、トリガ毎のサービス毎の構成情報を維持し、すなわち、サービス層は、どんなサービスがどのトリガを必要とするかを記録する。

下層ネットワークが、サービスが何であるかを認識しない場合があるので、下層ネットワーク１１０６に送信されるメッセージは、トリガ情報のみを含む。加えて、サービス層１１０４はまた、個人またはサービス加入者のグループのためのトリガを構成し得る。言い換えると、下層ネットワークは、構成されたトリガが特定のユーザのために起こるときのみ、サービス層１１０４に通知する。これは、サービス層１１０４と下層ネットワーク１１０６との間の通信オーバーヘッドを低減させる。

ＳＤ−ＣＣＦ１１０２は、それらの各々が異なるサービスに対応する異なるポリシートリガに関する複数の構成を集約し得る。

同一トリガを構成する複数のサービスがあり得る。例として、ＳＤ−ＣＣＦ１１０２は、家庭用監視サービスのための課金相関規則を作成して維持することができる。この規則は、課金相関がサービスのために有効にされる場合、どのトリガの組がこのサービスのために構成されるか、どんな課金ポリシーおよび課金可能イベントがトリガによる影響を受けるであろうかを示すことができる。トリガ／課金ポリシー／課金可能イベントは、それらのＩＤによって識別され得ることに留意されたい。

例として、サービス層１１０４は、事前プロビジョニングを介して、下層ネットワークエンティティのアドレスを把握し得る。

図１３のステップ２では、下層ネットワークエンティティ（例えば、３ＧＰＰネットワーク内のＰＣＲＦ／ＰＣＥＦ、ＢＢＦ固定ネットワーク内のポリシー実施点（ＰＥＰ））が加入トリガの発生を検出すると、それは、どのトリガが起きているかを示す通知をＳＤ−ＣＣＦ１１０２に送信する。加えて、下層ネットワークは、必要な変更されているパラメータを規定すべきである。例えば、新しいスポンサ付きデータ量閾値、既存の課金ポリシーに結びつく新しいデータレート。これらのパラメータは、サービス層１１０４がそれに対応してサービス層課金ポリシーを作成／更新するために必要とされる。

図１３のステップ３では、下層ネットワークから通知を受信すると、同一トリガを構成する複数のサービスがあり得るので、ＳＤ−ＣＣＦ１１０２は、どんなサービスが課金ポリシートリガを構成しているかをチェックし得る（例えば、どんなサービスがどのトリガを構成するかという維持された情報を用いてトリガＩＤとサービスＩＤとを比較する）。報告されたトリガが、あるサービスのために有効にされるかどうかを検証する。そして、どんな課金ポリシーおよび課金可能イベントが報告されたトリガによる影響を受けるかについての情報をチェックする。

そして、ＳＤ−ＣＣＦ１１０２は、通知に含まれるパラメータに基づいて課金ポリシーを更新する。特に、ＳＤ−ＣＣＦ１１０２は、以下のアクションのうちの１つを行うことができる：新しい課金ポリシーの作成、または既存の課金ポリシー内の属性の更新。

新しい課金ポリシーの作成は、下層ネットワーク１１０６がその課金ポリシーを変更することを示唆するが、サービス層は、その変更に対応する既存の課金ポリシーを有していない。例えば、下層ネットワーク１１０６は、空気品質センサデータ読み取りのための課金測定を量ベースからトランザクションベースに変更し、サービス層１１０４は、センサデータ読み取りサービスのためのトランザクションベースの課金ポリシーを確立し、かつ前のデータ量ベースのポリシーを維持する必要があり、前のデータ量ベースのポリシーは、他のタイプの下層ネットワーク１１０６によって使用され得る。

既存の課金ポリシー内の属性の更新は、下層ネットワーク１１０６内の課金ポリシー変更が既存のサービス層課金ポリシーに影響を及ぼすことを示唆し、サービス層１１０４は、ポリシー内のある属性、例えば、スポンサ付きデータ量閾値、課金率を変更する必要がある。

図１３のステップ４は、下層ネットワークからあるタイプのトリガを受信するとき、ＳＤ−ＣＣＦが既存のサービス層ＣＤＲを更新する必要があり得るという随意のステップ１１０２である。例えば、下層ネットワークは、サービスデータフローのための課金率を増加させ、ＳＤ−ＣＣＦ１１０２は、サービス層課金データレコーダ（ＣＤＲ）において課金率を更新することができる。別の例では、下層ネットワーク１１０６が、ある期間中にディスカウント率を全てのデータに適用することを決定し、したがって、サービスプロバイダも、その期間内、より低いサービス層課金価格を適用し得る。

ＣＤＲがデータベース内で維持され、ＳＤ−ＣＣＦ１１０２、ＣＴＦ、および課金ＳＣ１２０２が異なる理由でＣＤＲにアクセスし、処理し得ることに留意されたい。ＳＤ−ＣＣＦ１１０２は、相関動作に起因してＣＤＲを更新し、ＣＴＦは、いくつかの新しい課金可能イベントを捕捉するのでＣＤＲを更新し、課金ＳＣ１２０２は、それがＣＤＲファイルを請求システムにパスすることを要求され得るので、ＣＤＲを更新／処理する。

図１３のステップ５では、ＳＤ−ＣＣＦ１１０２は、新しい課金ポリシーに従って課金挙動を変更すべきことを他のサービス能力内の課金トリガ機能（ＣＴＦ）１３０２に知らせる。通知では、ＳＤ−ＣＣＦ１１０２は、ＣＴＦ１３０２が収集する必要があるイベントＩＤによって規定される課金可能イベントを示す。

そして、ＣＴＦ１３０２は、どんな情報が課金可能イベントのために含まれるはずであるかを理解するために、イベントＩＤを調べる。例えば、下層ネットワークが、データ読み出しサービスのために、課金測定方法をトランザクションベースからデータ量ベースに変更し、したがって、ＳＤ−ＣＣＦ１１０２は、データ読み出しサービスのためにサービスデータフローのデータ量を収集することを開始すべきことをセッション管理ＳＣ内のＣＴＦ１３０２に通知する。

ＳＤ−ＣＣＦ１１０２は、登録プロシージャ中にこれらのＣＴＦ１３０２の存在を把握し得ることに留意されたい。例えば、ｏｎｅＭ２Ｍでは、＜ＣＳＥｂａｓｅ＞、＜ｒｅｍｏｔｅＣＳＥ＞、および＜ＡＥ＞リソースがあり、ＳＤ−ＣＣＦは、これらのリソースをチェックすることによって、どのＣＴＦ１３０２にコンタクトすべきかを把握し得る。

図１３のステップ６は、随意のステップである。ＣＴＦ１３０２は、課金挙動の変更を確認するために確認をＳＤ−ＣＣＦ１１０２に送信し得る。

下層ネットワーク１１０６に完全に依拠する以外に、クライアント（例えば、アプリケーション）自体も、下層ネットワークからいくつかの自動メッセージ（例えば、データ使用リマインダ）を受信し得ることに留意されたい。したがって、クライアントは、相関を行うためのそのような情報をＳＤ−ＣＣＦ１１０２に能動的に報告することができる。この場合、下層ネットワークが、最初にクライアントに通知し、そして、クライアントが、課金ポリシートリガを用いてＳＤ−ＣＣＦ１１０２に通知する。課金イベントトリガは、このシナリオで同様の事例を有する。

図１３に図示されるステップを行うエンティティは、図２２Ｃまたは図２２Ｄに図示されるもののうちの１つ等のデバイス、サーバ、もしくは他のコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図１３に図示される方法は、例えば、図２２Ｃまたは２２Ｄに図示されるデバイスもしくはコンピュータシステム等のコンピュータデバイスのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、コンピュータデバイスのプロセッサによって実行されると、図１３に図示されるステップを行う。また、図１３に図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることも理解されたい。

図１４は、課金情報相関を促進するためのメッセージ交換のプロシージャを図示するフロー図である。

図１４のステップ１では、ＳＤ−ＣＣＦ１１０２が、最初に、下層ネットワーク内でいくつかの課金イベントトリガを構成する。課金ポリシートリガと同様に、これらのトリガは、サービス層課金挙動に影響を及ぼし得るいくつかのイベントを示唆する。課金ポリシー相関シナリオと同様に、ＣＴＦ１３０２は、ＳＤ−ＣＣＦ１１０２が下層ネットワーク内でトリガを構成し得るように、オンデマンド様式で所望の課金相関トリガに関してＳＤ−ＣＣＦ１１０２にコンタクトする。さらなる詳細が、図１３に示されるステップ０の説明で議論されている。

図１４のステップ２は、図１３のステップ２に類似する。

図１４のステップ３では、ＳＤ−ＣＣＦ１１０２が、課金情報トリガを記録し、トリガのタイプおよびトリガを構成するサービスに基づいて、さらなるアクションを決定する（例えば、サービスのための新しい課金率を適用し、データ量情報を収集し始める）。ＳＤ−ＣＣＦ１１０２はまた、報告されたトリガがあるサービスのために有効にされるかどうかを検証し、どんな課金ポリシーおよび課金可能イベントが報告されたトリガによる影響を受けるであろうかについての情報をチェックし得る。

図１４のステップ４では、ＳＤ−ＣＣＦ１１０２が、トリガに基づいて決定される新しい課金アクションについて、他のＳＣ内のＣＴＦ１３０２に通知する。ＳＤ−ＣＣＦ１１０２は、登録プロシージャの結果をチェックすることによって、これらのＣＴＦ１３０２の存在を把握し得る。例えば、ＳＤ−ＣＣＦ１１０２は、家庭用監視サービスに加入してデータ量閾値に達するサービス加入者のためのデータ量を収集することを開始すべきことをセッション管理ＳＣ内のＣＴＦ１３０２に通知する。

図１４のステップ５では、ＳＤ−ＣＣＦ１１０２から構成を受信すると、課金トリガ機能（ＣＴＦ）１３０２が、サービス毎の課金可能イベントのリストを更新する。特に、ＣＴＦ１３０２は、どんなサービスのために、どんな課金可能イベントを収集することが所望されるか、および各課金可能イベントのためにどんな情報が含まれるべきかについて、ある情報を維持する。いくつかの新しいタイプの課金可能イベントが収集することを要求される場合、ＣＴＦ１３０２は、イベントを識別するイベントＩＤに従ってイベント情報をチェックし、新しいイベントをリストに追加し得る。

図１４のステップ６では、随意のステップとして、ＣＴＦ１３０２は、課金挙動の変更を確認するために確認をＳＤ−ＣＣＦ１１０２に送信し得る。

ある場合には、下層ネットワーク１１０６はまた、サービス層１１０４と通信することによって課金相関プロシージャを開始し得る。例えば、下層ネットワーク１１０６（例えば、３ＧＰＰネットワーク）は、ある理由（例えば、ネットワーク混雑、より良好な通信品質）で、サービスデータフローを別のタイプの下層ネットワーク１１０６（例えば、ＷｉＦｉ）にオフロードすることを決定する。この場合、下層ネットワーク１１０６は、構成ステップ（すなわち、図１４のステップ１）を伴わずに、トリガの発生をＳＤ−ＣＣＦに直接報告するであろう。

図１４に図示されるステップを行うエンティティは、図２２Ｃまたは図２２Ｄに図示されるもののうちの１つ等のノードデバイス、サーバ、もしくは他のコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図１４に図示される方法は、例えば、図２２Ｃまたは２２Ｄに図示されるデバイスもしくはコンピュータシステム等のコンピュータデバイスのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、コンピュータデバイスのプロセッサによって実行されると、図１４に図示されるステップを行う。図１４に図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることも理解されたい。

図１５は、サービス層課金相関を行うための例示的方法を図示するフロー図である。相関動作は、下層ネットワークによって捕捉される課金ポリシートリガおよび課金イベントトリガの両方に適用され得る。

図１５のステップ１では、課金相関方法は、ＳＤ−ＣＣＦ１１０２が下層ネットワーク１１０６内の構成されたトリガの発生を示す通知を受信するとき、トリガされる。通知は、トリガＩＤ、および通知を生成する下層ネットワークＩＤを規定する。ＳＤ−ＣＣＦ１１０２は、トリガがポリシー関連であるか、または課金情報関連であるか、どんなイベントが下層ネットワーク内で起きているか等、相関トリガ情報を読み出すために、トリガＩＤを使用し得る。

図１５のステップ２では、ＳＤ−ＣＣＦ１１０２は、課金相関が報告されたトリガに関して有効にされる／許可されるかどうか、すなわち、以前に報告されたトリガがＳＤ−ＣＣＦ１１０２によって構成されたかどうかを決定するために、課金相関規則をチェックする。下層ネットワークが、ある場合には、トリガ報告を開始し得るので、サービス層は、報告されたトリガがどのサービスのために有効にされるかを検証する必要がある。

下層ネットワークがサービス情報を規定しないこともあり、複数のサービスが同一トリガを構成し得るので、ＳＤ−ＣＣＦ１１０２は、どのサービスが報告されたトリガを構成したかも検証する。

特に、ＳＤ−ＣＣＦ１１０２は、どんなサービスがトリガに加入しているか、課金相関動作がサービスによって可能にされるかどうか等のいくつかのことを解明する必要がある。チェックが「いいえ」を返す場合、いかなる課金相関動作も行われていない。このステップは、ＳＤ−ＣＣＦ１１０２によって作成および維持される情報をチェックすることを通して行われ得る。例えば、ＳＤ−ＣＣＦ１１０２は、どんなトリガがどのサービスのために下層ネットワークにおいて構成されているか、相関トリガがサービスのために可能にされる、または許可されるかどうかについての情報を維持するであろう。実施形態の節は、ｏｎｅＭ２Ｍのための相関規則およびトリガに対して、これらの情報の構造を規定するであろう。

図１５のステップ３では、図１５のステップ２におけるアクションに基づいて、課金相関および報告されたトリガがサービスのために有効にされる場合、ＳＤ−ＣＣＦ１１０２は、トリガが課金ポリシーまたは課金情報に関連するかどうかをチェックし続け、その結果として、異なる動作が２つのタイプのトリガのために行われる。

課金相関を行うことが許可されない場合、ＳＤ−ＣＣＦ１１０２は、トリガ情報をチェックし、報告されたトリガをサービスのための相関規則に追加するかどうかをサービスプロバイダに決定させる。トリガが理解可能ではない場合、ＳＤ−ＣＣＦ１１０２は、報告されたトリガの情報を要求するであろう。

図１５のステップ４からステップ１０は、課金ポリシートリガのために行われる。

図１５のステップ４では、トリガが課金ポリシーに関連する場合において、ＳＤ−ＣＣＦ１１０２は、最初に、下層ネットワークからのトリガに対応するサービス層課金ポリシーを更新する。特に、ＳＤ−ＣＣＦ１１０２は、新しい課金ポリシーを作成し得る、または既存の課金ポリシー内の属性を更新し得る。

図１５のステップ５では、ＳＤ−ＣＣＦ１１０２は、ＣＴＦ１３０２が課金可能イベントを収集する方法を調節することができるように、更新された課金ポリシーに関して他のＳＣ内のＣＴＦ１３０２に通知する必要性があるかどうかをさらにチェックする。例えば、トランザクションベースからデータ量ベースへの課金ポリシー変更は、ＣＴＦ１３０２が収集された課金記録にデータ量情報を挿入し、おそらく、トランザクションベースの課金のために必要とされないいくつかの新しい課金可能イベントをＣＴＦ１３０２が収集することを要求する。

ある場合には、課金ポリシー変更がＣＤＲ処理のみに影響を及ぼすので、ＣＴＦ１３０２と通信することは要求されない。例えば、課金率を変更することは、課金可能イベントを収集する任意の挙動および収集された課金記録内の情報を変更することをＣＴＦに要求しないであろう。

この決定を行うために、ＳＤ−ＣＣＦ１１０２は、ＣＴＦ１３０２にコンタクトする必要があるかどうか、および必要であればどのＣＴＦ１３０２がどのエンティティにおいて通知される必要があるかを解明するために、サービス層において維持される情報をチェックし得る。例えば、そのような情報は、以下であり得るが、それらに限定されない：
○ どんな機能性（すなわち、セッション管理）がＣＴＦ１３０２を含むかを示すためのｏｎｅＭ２Ｍで定義される＜ＣＳＥＢａｓｅ＞、＜ｒｅｍｏｔｅＣＳＥ＞、および＜ＡＥ＞リソース
○ サービスのためのサービス層課金ポリシーを含むためのｏｎｅＭ２Ｍで定義されるリソース＜ｓｔａｔｓＣｏｌｌｅｃｔ＞。課金ポリシーが影響を受ける場合、すなわち、報告されたトリガが課金ポリシーリソース内のいくつかの属性を変更する場合、ＣＴＦ１３０２に通知することを要求される。
○ サービスのためのサービス層課金可能イベントを含むためのｏｎｅＭ２Ｍで定義されるリソース＜ｅｖｅｎｔＣｏｎｆｉｇ＞。課金ポリシーと同様に、ＳＤ−ＣＣＦ１１０２は、下層ネットワークからの受信されたトリガに基づいて、ＣＴＦ１３０２に通知することを要求されるかどうかを決定するために、このリソースを調べる。

図１５のステップ６では、ＳＤ−ＣＣＦ１１０２が、課金ポリシーおよび予期される課金可能イベントの変更について、関連ＳＣ内の課金ＳＣ１２０２およびＣＴＦ１３０２に通知する。メッセージは、新しい課金ポリシー、予期される課金可能イベント、サービスＩＤを含む。課金ＳＣ１２０２およびＣＴＦ１３０２は、課金可能イベントを収集する方法を調節するための情報および課金可能イベントのために収集される情報を使用し得る。

図１５のステップ７では、ＳＤ−ＣＣＦ１１０２が、サービスプロビジョニングパラメータを変更することをあるＳＣに通知する必要があるかどうかチェックを行う。例えば、下層ネットワーク課金ポリシーに結び付く最大データレートは、データ読み出しサービスのために変更され、ＳＤ−ＣＣＦ１１０２は、それに応じて最大データレートを調節することをセッション管理ＳＣに通知する必要がある。

図１５のステップ８では、ＳＤ−ＣＣＦ１１０２が、サービスプロビジョニングパラメータの変更について関連ＳＣに通知する。特に、ＳＤ−ＣＣＦ１１０２は、変更されるべきパラメータおよび新しい値を示す。

図１５のステップ９では、ＳＤ−ＣＣＦ１１０２がさらに、その課金ポリシーが更新されるサービスのための既存のＣＤＲを再処理する必要があるかどうかをチェックする。例えば、下層ネットワークは、以前にデータ量ベースであったセンサデータ読み取りサービスのためのサービスデータフローにトランザクションベース課金を適用し、それによって、サービス層は、既存のＣＤＲからデータ量値を除去する必要がある。

図１５のステップ１０では、ＳＤ−ＣＣＦ１１０２が、既存のサービス層ＣＤＲを更新すべきことを課金ＳＣ１２０２に通知する。通知は、どのようにしてＣＤＲを更新するかについての具体的ガイダンス（例えば、データ量情報を除去すること、課金率を更新すること）を含む。一実施形態では、どのようにしてＣＤＲを更新するかは、ＳＤ−ＣＣＦ１１０２によって行われず、課金ＳＣ１２０２の責任である。

図１５のステップ１１からステップ１４は、課金イベントトリガのために行われる。

図１５のステップ１１では、課金イベントトリガを受信すると、ＳＤ−ＣＣＦ１１０２が、下層ネットワーク内で生じているトリガに対応する別の課金ポリシーを適用する必要があるかどうかを決定する。課金情報トリガは、サービス層課金ポリシーのいかなる更新も必要としないであろうが、サービスのための別のポリシーを適用することを必要とし得ることに留意されたい。例えば、データ量閾値に達するトリガは、サービス層が将来のデータ量のために追加料金をサービス加入者に課金することを開始することを要求する。

図１５のステップ１２は、図１５のステップ６に類似する。ＳＤ−ＣＣＦ１１０２は、適用された課金ポリシーの変更について、関連ＳＣ内の課金ＳＣ１２０２およびＣＴＦ１３０２に通知する。

図１５のステップ１３−１４は、図１５のステップ７およびステップ８に類似する。ＳＤ−ＣＣＦ１１０２は、サービスプロビジョニングパラメータを変更すべきことをあるＳＣに通知する必要があるかどうかチェックを行い、必要であれば、サービスプロビジョニングパラメータの変更について関連ＳＣに通知する。

下層ネットワーク１１０６がユーザ毎またはサービス毎に課金挙動を調節し得るように、サービス層１１０４がある情報を下層ネットワーク１１０６に提供することも可能であることに留意されたい。例えば、サービス加入者は、そのサービス層加入をプレミアムアカウントにアップグレードし、プレミアムアカウントは、サービスにアクセスするために３ＧＰＰネットワーク内で無制限の無料データをサービス加入者に与える。サービス層１１０４は、その３ＧＰＰネットワークの毎月のデータプランの中へそのユーザのためのサービスのデータ量を数えないように、３ＧＰＰネットワークに通知する必要がある。

図１５に図示されるステップを行うエンティティは、図２２Ｃまたは図２２Ｄに図示されるもののうちの１つ等のノード、デバイス、サーバ、もしくは他のコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図１５に図示される方法は、例えば、図２２Ｃまたは２２Ｄに図示されるデバイスもしくはコンピュータシステム等のコンピュータデバイスのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、コンピュータデバイスのプロセッサによって実行されると、図１５に図示されるステップを行う。また、図１５に図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることも理解されたい。

図１６は、ｏｎｅＭ２Ｍ機能的アーキテクチャ１６００に基づくサービス課金および会計（ＳＣＡ）ＣＳＦ１６０４の一部として提案されたＳＤ−ＣＣＦ１１０２を実装するための一例示的実施形態を図示する略図である。提案されたＳＤ−ＣＣＦはまた、主に、Ｍｃｎ基準点を経由してネットワークサービス機能にアクセスするために下層ネットワークとの通信を管理する責任がある、ネットワークサービスエクスポージャ、サービス実行、およびトリガリング（ＮＳＳＥ）ＣＳＦ１６０６のサブ機能として追加され得ることに留意されたい。

本節は、ＳＣＡ ＣＳＦ１６０４のための課金相関機能性をサポートするためのｏｎｅＭ２Ｍリソース構造増進を開示する。

リソース構造を説明するためのｏｎｅＭ２Ｍで定義されるグラフィカル表現は、以下であることに留意されたい：正方形のボックスがリソースおよび子リソースに使用される。丸い角を伴う正方形のボックスが、属性に使用される。

図１７は、表３で説明されるサービス層課金相関規則を反映する＜ｃｈａｒｇｉｎｇＣｏｒｒｅｌａｔｉｏｎＲｕｌｅ＞リソース１７０２を図示する略図である。異なるサービスのための複数の課金相関規則があり得、すなわち、課金相関規則は、サービス特定であり、規則ＩＤ１７０４およびサービスＩＤ１７１４属性によって識別される。提案された＜ｃｈａｒｇｉｎｇＣｏｒｒｅｌａｔｉｏｎＲｕｌｅ＞リソース１７０２は、＜ＣＳＥＢａｓｅ＞、＜ｒｅｍｏｔｅＣＳＥ＞、および＜ＡＥ＞リソースのサブリソースとして追加され得る。

図１８は、表４で説明される、サービスのためのサービス層課金相関規則を反映する＜ｃｈａｒｇｉｎｇＣｏｒｒｅｌａｔｉｏｎＴｒｉｇｇｅｒ＞リソース１８０２を図示する略図である。

どのようにしてＳＤ−ＣＣＦ１１０２が課金相関のために下層ネットワーク１１０６とインターワーキングするかについてさらなる詳細を提示するために、３ＧＰＰネットワークが、例証のための例として使用される。

図１９は、どのようにして提案されたｏｎｅＭ２Ｍ ＳＤ−ＣＣＦ１１０２が３ＧＰＰネットワーク内の課金ポリシー変更を相関させるために稼働するかを実証する、３ＧＰＰネットワークとのｏｎｅＭ２Ｍ課金ポリシー相関の例示的実施形態を図示する略図である。この場合、提案されたデータ量閾値が、３ＧＰＰネットワーク内で変更され、３ＧＰＰネットワークは、ｏｎｅＭ２Ｍサービス層に知らせる。その結果として、ｏｎｅＭ２Ｍサービス層プラットフォームは、サービス層課金ポリシーを更新し、新しい課金ポリシーを適用すべきことをＳＤ−ＣＴＦ１９０２に通知する。

図１９のステップ１では、ＳＤ−ＣＣＦ１１０２は、スポンサ付きデータ量閾値変更の課金ポリシートリガがサービスのために有効にされることを確認するために、＜ｃｈａｒｇｉｎｇＣｏｒｒｅｌａｔｉｏｎＴｒｉｇｇｅｒ＞リソースをチェックする。このステップは、ＣＴＦからいくつかの課金ポリシートリガを受信することによってトリガされ得る。特に、ＳＤ−ＣＴＦ１９０２は、収集されるべき課金可能イベントおよびその中の情報をチェックすることによって、課金ポリシートリガを見出し、そして、通知をＳＤ−ＣＣＦ１１０２に送信し得る。例えば、ＳＤ−ＣＴＦ１９０２は、センサデータ読み取りのためのデータ伝送（サービス層セッション管理機能）の開始を示す課金可能イベントを収集するために、データレート情報が所望されることを見出す。ＳＤ−ＣＴＦ１９０２は、３ＧＰＰネットワーク内のサービスデータフローに関するデータレートの任意の変更がサービス層１１０４に報告されるように、下層３ＧＰＰネットワーク内の課金ポリシートリガを構成することをＳＤ−ＣＣＦ１１０２に要求するであろう。

図１９のステップ２では、ＳＤ−ＣＣＦ１１０２が、Ｍｃｎ／Ｒｘ基準点を経由して、加入メッセージを３ＧＰＰネットワーク１９０６内のＰＣＲＦ１９０８に送信する。メッセージは、トリガＩＤと、デバイスの下層ネットワークＩＤ（例えば、トリガに加入するサービスプラットフォームを示す３ＧＰＰネットワーク１９０６への外部ＩＤ）とを含む。

図１９のステップ３では、３ＧＰＰネットワーク１９０６がスポンサ付きデータ量閾値を変更する場合、ＰＣＲＦ１９０８は、Ｍｃｎ基準点を経由して、トリガＩＤ、トリガ加入ＩＤ、および発生タイムスタンプを含む通知をＳＤ−ＣＣＦ１１０２に送信する。この例では、スポンサ付きデータ量閾値が変更されるので、３ＧＰＰネットワーク１９０６は、ｄｉａｍｅｔｅｒプロトコルが３ＧＰＰネットワーク１９０６およびｏｎｅＭ２Ｍサービス層プラットフォーム１９０４にわたって使用されることを仮定する、新しいデータ量閾値（例えば、許可サービスユニット属性値ペア（ＡＶＰ））を送信する。

図１９のステップ４では、３ＧＰＰネットワーク１９０６からトリガ通知を受信すると、ｏｎｅＭ２Ｍサービス層１９０４は、＜ｃｈａｒｇｉｎｇＣｏｒｒｅｌａｔｉｏｎＴｒｉｇｇｅｒ＞リソース内の関連課金ポリシーＩＤ属性に従って課金ポリシーを更新する。例えば、ｏｎｅＭ２Ｍサービス層１９０４は、データ読み出しサービスのために、課金ポリシーに結び付くデータレータを変更することができるか、または家庭用監視サービスのためのスポンサ付きデータ量閾値を変更することができる。より具体的に、変更は、ｏｎｅＭ２Ｍリソース＜ｓｔａｔｓＣｏｌｌｅｃｔ＞ならびに＜ｅｖｅｎｔＣｏｎｆｉｇ＞（それらは、それぞれ、課金ポリシーおよび課金可能イベント情報を維持するために設計される）に行われるであろう。

図１９のステップ５では、そして、ＳＤ−ＣＣＦ１９０２は、課金ポリシーの変更について他のＣＳＦ内のＳＤ−ＣＴＦ１９０２に通知する、すなわち、新しい閾値において追加料金をサービス加入者に課金することを開始する。特に、通知は、サービスＩＤ、新しい適用された課金ポリシーＩＤ、および関連課金可能イベントＩＤを含む。

図１９のステップ６では、ＳＤ−ＣＴＦ１９０２は、課金ポリシーＩＤおよびイベントＩＤによって課金記録を収集することのさらなる詳細について、リソース＜ｓｔａｔｓＣｏｌｌｅｃｔ＞ならびに＜ｅｖｅｎｔＣｏｎｆｉｇ＞にアクセスするであろう。

図１９のステップ７では、随意のステップとして、ＳＤ−ＣＴＦ１９０２が、課金挙動の変更を確認するために確認をＳＤ−ＣＣＦ１１０２に送信し得る。

図１９に図示されるステップを行うエンティティは、図２２Ｃまたは図２２Ｄに図示されるもののうちの１つ等のデバイス、サーバ、もしくは他のコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図１９に図示される方法は、例えば、図２２Ｃまたは２２Ｄに図示されるデバイスもしくはコンピュータシステム等のコンピュータデバイスのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、コンピュータデバイスのプロセッサによって実行されると、図１９に図示されるステップを行う。また、図１９に図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることも理解されたい。

図２０は、３ＧＰＰネットワーク使用事例とのｏｎｅＭ２Ｍ課金情報相関の例示的実施形態を図示する略図であり、どのようにして提案されたｏｎｅＭ２Ｍ ＳＤ−ＣＣＦ１１０２が３ＧＰＰネットワーク１９０６によって提供される課金情報を相関させるために稼働するかを実証する。具体的に、スポンサ付きデータ量閾値が、３ＧＰＰネットワーク内で到達される。その結果として、ＳＤ−ＣＣＦ１１０２は、新しい課金率を将来のサービスデータフローに適用することを決定し、サービスのための課金可能イベントを収集するときにデータ量を含むようにＳＤ−ＣＴＦ１９０２に通知する。

図２０のステップ１は、図１９のステップ１に類似する。ＳＤ−ＣＣＦ１１０２は、スポンサ付きデータ量閾値に達することの課金情報トリガがサービスのために有効にされることを確認するために、＜ｃｈａｒｇｉｎｇＣｏｒｒｅｌａｔｉｏｎＴｒｉｇｇｅｒ＞リソースをチェックする。加えて、ＳＤ−ＣＣＦ１１０２は、ＣＴＦからある情報を受信することによって、このステップを開始するであろう。さらなる詳細が、図１９のステップ１の説明において見出されることができる。唯一の違いは、ＣＴＦがそこで課金ポリシートリガの代わりに課金イベントトリガを報告することである。

図２０のステップ２は、図１９のステップ２に類似する。ＳＤ−ＣＣＦ１１０２は、Ｍｃｎ基準点を経由して、加入メッセージを３ＧＰＰネットワーク内のＰＣＲＦ１９０８に送信する。メッセージは、トリガＩＤと、サービスプロバイダＩＤ（トリガに加入するサービスプラットフォームを示す３ＧＰＰネットワークへの外部ＩＤ）とを含む。そして、ＰＣＲＦ１９０８は、イベントトリガＡＶＰを通してトリガに加入することをＰＣＥＦ２００２に通知する。

図２０のステップ３では、ＰＣＥＦ２００２が閾値に達したことを発見し、そして、使用測定量を示すための使用済みサービスユニットＡＶＰを通してデータ量閾値に達することのイベントを報告する。このステップでは、ＰＣＥＦ２００２が、最初にＰＣＲＦ１９０８に報告し、ＰＣＲＦ１９０８が、Ｍｃｎ／Ｒｘ基準点を経由してイベント通知をＳＤ−ＣＣＦ１１０２に送信する。

図２０のステップ４では、ＳＤ−ＣＣＦ１１０２は、追加のデータ量のために新しい課金率を適用すること、および課金記録にデータ量を含むようにＳＤ−ＣＴＦ１９０２に依頼することを決定する。これは、リソース＜ｓｔａｔｓＣｏｌｌｅｃｔ＞ならびに＜ｅｖｅｎｔＣｏｎｆｉｇ＞上で課金ポリシーおよび課金可能イベントを更新することによって行われ得る。

図２０のステップ５−ステップ７は、図１９のステップ５−ステップ７に類似する。

図２０に図示されるステップを行うエンティティは、図２２Ｃまたは図２２Ｄに図示されるもののうちの１つ等のデバイス、サーバ、もしくは他のコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図２０に図示される方法は、例えば、図２２Ｃまたは２２Ｄに図示されるデバイスもしくはコンピュータシステム等のコンピュータデバイスのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、コンピュータデバイスのプロセッサによって実行されると、図２０に図示されるステップを行う。また、図２０に図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下、ノードの通信回路によって行われ得ることを理解されたい。

上記のように、ｏｎｅＭ２Ｍは、ｏｎｅＭ２Ｍサービス層によってサポートされる能力を定義している。これらの能力は、能力サービス機能（ＣＳＦ）と称される。ｏｎｅＭ２Ｍサービス層は、能力サービスエンティティ（ＣＳＥ）と称される。

図２１は、ＳＤ−ＣＣＦ１１０２が会計（ＡＣＣ）サービスコンポーネント２１０２の一部として挿入される、ｏｎｅＭ２Ｍ ＳｏＡアーキテクチャ２１００における提案されたＳＤ−ＣＣＦ１１０２の実施形態を図示する略図である。他のサービスコンポーネントは、Ｍｓｃ基準点を通して、課金相関問題に関するＳＤ−ＣＣＦ１１０２と通信し得る。別の実施形態では、ＳＤ−ＣＣＦ１１０２は、ＳＤ−ＣＣＦ１１０２が他のサービスコンポーネントおよびアプリケーションのための共通機能として扱われる、サービスエクスポージャコンポーネント２１０４の一部であり得る。

グラフィカルユーザインターフェース（ＧＵＩ）等のインターフェースは、ユーザがサービス層課金相関に関連する機能性を制御および／または構成することを支援するために使用されることができる。インターフェースは、デバイス、ゲートウェイ、またはサーバにあり得る。ユーザインターフェースは、課金可能イベントを生成するようにトリガされるとき、および課金記録に含まれる情報要素を表示することができる。加えて、Ｍ２Ｍサーバと下層ネットワークサーバとの間で交換されるメッセージ等のＡＰＩ動作も表示されることができる。

図２３Ａは、ユーザが課金相関規則およびトリガを設定すること、ならびに課金相関規則およびトリガを閲覧することを可能にするインターフェース２３０２を図示する略図である。図２３Ｂは、ユーザ機器において消費者によって使用されることができる、インターフェース２３０４を図示する略図である。この例では、インターフェース２３０４は、スポンサ付きフローの残りの帯域幅を表示する。インターフェース２３０２および２３０４は、以下で説明される図２２Ｃ−Ｄに示されるもの等のディスプレイを使用して生成され得ることを理解されたい。
（例示的Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム）

図２２Ａは、１つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、もしくはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための基礎的要素を提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントまたはノード、ならびにＩｏＴ／ＷｏＴサービス層等であり得る。通信システム１０は、開示される実施形態の機能性を実装するために使用されることができ、ＰＣＲＦ７０２、９１４、および１９０８、ＭＴＣ−ＩＷＦ７０４、ＰＣＥＦ７０６、９１２および２００２、課金エンティティ９１６、３ＧＰＰ ＣＮ９１０、ＳＤ−ＣＳ６０２、ＳＤ−ＯＤＳ６０８、ＳＤ−ＯＦＣＳ６０６、ＳＤ−ＣＴＦ６１０、１３０２、および１９０２、ＳＤ−ＣＣＦ１１０２、Ｍ２Ｍアプリケーション１１０８、課金ＳＣ１２０２、サービス課金および会計ＣＳＦ１６０４、ネットワークサービスエクスポージャＣＳＦ１６０６、３ＧＰＰ ＣＮ１９０６、サービス層９０４、１６００、１９０４、ＡＣＣ２１０４、サービスエクスポージャコンポーネント２１０４、ＵＥ９０６における論理、ならびにインターフェース２３０２および２３０４等のインターフェースを生成するための論理等の機能性および論理エンティティを含むことができる。

図２２Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク（例えば、イーサネット（登録商標）、ファイバ、ＩＳＤＮ、ＰＬＣ等）もしくは無線ネットワーク（例えば、ＷＬＡＮ、セルラー等）または異種ネットワークのネットワークであり得る。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージング、ブロードキャスト等のコンテンツを複数のユーザに提供する多重アクセスネットワークから成ってもよい。例えば、通信ネットワーク１２は、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）等の１つ以上のチャネルアクセス方法を採用し得る。さらに、通信ネットワーク１２は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワーク等の他のネットワークを備え得る。

図２２Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャドメインおよびフィールドドメインを含み得る。インフラストラクチャドメインは、エンドツーエンドＭ２Ｍ展開のネットワーク側を指し、フィールドドメインは、通常、Ｍ２Ｍゲートウェイの背後にあるエリアネットワークを指す。フィールドドメインおよびインフラストラクチャドメインは両方とも、種々の異なるネットワークノード（例えば、サーバ、ゲートウェイ、デバイス等）を備え得る。例えば、フィールドドメインは、Ｍ２Ｍゲートウェイ１４と、端末デバイス１８とを含み得る。任意の数のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８が、所望に応じて、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれ得ることが理解されるであろう。Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８の各々は、通信回路を使用して、通信ネットワーク１２または直接無線リンクを介して、信号を伝送ならびに受信するように構成される。Ｍ２Ｍゲートウェイ１４は、無線Ｍ２Ｍデバイス（例えば、セルラーおよび非セルラー）ならびに固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）が、通信ネットワーク１２等のオペレータネットワークを通して、または直接無線リンクを通してのいずれかで、通信することを可能にする。例えば、Ｍ２Ｍ端末デバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介して、データをＭ２Ｍアプリケーション２０もしくは他のＭ２Ｍ端末デバイス１８に送信し得る。Ｍ２Ｍ端末デバイス１８はまた、Ｍ２Ｍアプリケーション２０またはＭ２Ｍ端末デバイス１８からデータを受信し得る。さらに、データおよび信号は、以下で説明されるように、Ｍ２Ｍサービス層２２を介して、Ｍ２Ｍアプリケーション２０に送信され、そこから受信され得る。Ｍ２Ｍ端末デバイス１８およびゲートウェイ１４は、例えば、セルラー、ＷＬＡＮ、ＷＰＡＮ（例えば、Ｚｉｇｂｅｅ（登録商標）、６ＬｏＷＰＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標））、直接無線リンク、および有線を含む、種々のネットワークを介して通信し得る。

例示的Ｍ２Ｍ端末デバイス１８は、タブレット、スマートフォン、医療デバイス、温度および天候モニタ、コネクテッドカー、スマートメータ、ゲームコンソール、携帯情報端末、健康およびフィットネスモニタ、照明、サーモスタット、電気器具、車庫のドアおよび他のアクチュエータベースのデバイス、セキュリティデバイス、ならびにスマートコンセントを含むが、それらに限定されない。

図２２Ｂを参照すると、フィールドドメイン内の図示されるＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍ端末デバイス１８、ならびに通信ネットワーク１２のためのサービスを提供する。通信ネットワーク１２は、開示される実施形態の機能性を実装するために使用されることができ、ＰＣＲＦ７０２、９１４、および１９０８、ＭＴＣ−ＩＷＦ７０４、ＰＣＥＦ７０６、９１２および２００２、課金エンティティ９１６、３ＧＰＰ ＣＮ９１０、ＳＤ−ＣＳ６０２、ＳＤ−ＯＤＳ６０８、ＳＤ−ＯＦＣＳ６０６、ＳＤ−ＣＴＦ６１０、１３０２、および１９０２、ＳＤ−ＣＣＦ１１０２、Ｍ２Ｍアプリケーション１１０８、課金ＳＣ１２０２、サービス課金および会計ＣＳＦ１６０４、ネットワークサービスエクスポージャＣＳＦ１６０６、３ＧＰＰ ＣＮ１９０６、サービス層９０４、１６００、１９０４、ＡＣＣ２１０４、サービスエクスポージャコンポーネント２１０４、ＵＥ９０６における論理、ならびにインターフェース２３０２および２３０４等のインターフェースを生成するための論理等の機能性および論理エンティティを含むことができる。Ｍ２Ｍサービス層２２は、例えば、以下で説明される図２２Ｃおよび２２Ｄに図示されるデバイスを含む、１つ以上のサーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウド／記憶ファーム等）等によって実装され得る。Ｍ２Ｍサービス層２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、サーバ、コンピュータ、デバイス等を備え得る、ネットワークの１つ以上のノードによって実装され得る。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワーク内で、クラウド内で等、種々の方法で実装され得る。

図示されるＭ２Ｍサービス層２２と同様に、インフラストラクチャドメイン内にＭ２Ｍサービス層２２’がある。Ｍ２Ｍサービス層２２’は、インフラストラクチャドメイン内のＭ２Ｍアプリケーション２０’および下層通信ネットワーク１２’のためのサービスを提供する。Ｍ２Ｍサービス層２２’は、フィールドドメイン内のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍデバイス１８のためのサービスも提供する。Ｍ２Ｍサービス層２２’は、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ、およびＭ２Ｍデバイスと通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２’は、異なるサービスプロバイダによるサービス層と相互作用し得る。Ｍ２Ｍサービス層２２’は、サーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウドコンピューティング／記憶ファーム等）等を備え得る、ネットワークの１つ以上のノードによって実装され得る。

図２２Ｂも参照すると、Ｍ２Ｍサービス層２２および２２’は、多様なアプリケーションおよびバーティカルが活用することができる、サービス配信能力のコアセットを提供する。これらのサービス能力は、Ｍ２Ｍアプリケーション２０および２０’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、請求、サービス／デバイス発見等の機能を果たすことを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出すコストおよび時間を削減する。サービス層２２および２２’は、Ｍ２Ｍアプリケーション２０および２０’が、サービス層２２および２２’が提供するサービスと関連して、種々のネットワーク１２および１２’を通して通信することも可能にする。

本願の方法は、サービス層２２および２２’の一部として実装され得る。サービス層２２および２２’は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースの組を通して付加価値サービス能力をサポートするソフトウェアミドルウェア層である。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍの両方は、本願の接続方法を含み得るサービス層を使用する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内に実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、特定用途向けノード）上にホストされ得る共通サービスエンティティ（ＣＳＥ）と称される。さらに、本願の接続方法は、本願の接続方法等のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装されることができる。

いくつかの実施形態では、Ｍ２Ｍアプリケーション２０および２０’は、開示されるシステムならびに方法とともに使用され得る。Ｍ２Ｍアプリケーション２０および２０’は、ＵＥまたはゲートウェイと相互作用するアプリケーションを含み得、さらに、他の開示されるシステムならびに方法とともに使用され得る。

一実施形態では、ＰＣＲＦ７０２、９１４、および１９０８、ＭＴＣ−ＩＷＦ７０４、ＰＣＥＦ７０６、９１２および２００２、課金エンティティ９１６、３ＧＰＰ ＣＮ９１０、ＳＤ−ＣＳ６０２、ＳＤ−ＯＤＳ６０８、ＳＤ−ＯＦＣＳ６０６、ＳＤ−ＣＴＦ６１０、１３０２、および１９０２、ＳＤ−ＣＣＦ１１０２、Ｍ２Ｍアプリケーション１１０８、課金ＳＣ１２０２、サービス課金および会計ＣＳＦ１６０４、ネットワークサービスエクスポージャＣＳＦ１６０６、３ＧＰＰ ＣＮ１９０６、サービス層９０４、１６００、１９０４、ＡＣＣ２１０４、サービスエクスポージャコンポーネント２１０４、ＵＥ９０６における論理、ならびにインターフェース２３０２および２３０４等のインターフェースを生成するための論理等の論理エンティティが、図２２Ｂに示されるように、Ｍ２Ｍサーバ、Ｍ２Ｍゲートウェイ、またはＭ２Ｍデバイス等のＭ２ＭノードによってホストされるＭ２Ｍサービス層インスタンス内でホストされ得る。例えば、ＰＣＲＦ７０２、９１４、および１９０８、ＭＴＣ−ＩＷＦ７０４、ＰＣＥＦ７０６、９１２および２００２、課金エンティティ９１６、３ＧＰＰ ＣＮ９１０、ＳＤ−ＣＳ６０２、ＳＤ−ＯＤＳ６０８、ＳＤ−ＯＦＣＳ６０６、ＳＤ−ＣＴＦ６１０、１３０２、および１９０２、ＳＤ−ＣＣＦ１１０２、Ｍ２Ｍアプリケーション１１０８、課金ＳＣ１２０２、サービス課金および会計ＣＳＦ１６０４、ネットワークサービスエクスポージャＣＳＦ１６０６、３ＧＰＰ ＣＮ１９０６、サービス層９０４、１６００、１９０４、ＡＣＣ２１０４、サービスエクスポージャコンポーネント２１０４、ＵＥ９０６における論理、ならびにインターフェース２３０２および２３０４等のインターフェースを生成するための論理等の論理エンティティは、Ｍ２Ｍサービス層インスタンス内で、または既存のサービス能力内のサブ機能として、個々のサービス能力を備え得る。

Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界での用途を含み得る。上記のように、システムのデバイス、ゲートウェイ、サーバ、および他のノードにわたって作動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、請求、場所追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合等の機能をサポートし、サービスとしてこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。

概して、サービス層２２および２２’は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースの組を通して付加価値サービス能力をサポートするソフトウェアミドルウェア層を定義する。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍアーキテクチャの両方は、サービス層を定義する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、ＥＴＳＩ Ｍ２Ｍアーキテクチャの種々の異なるノード内に実装され得る。例えば、サービス層のインスタンスは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内で実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、特定用途向けノード）上にホストされ得る共通サービスエンティティ（ＣＳＥ）と称される。第３世代パートナーシッププロジェクト（３ＧＰＰ）はまた、マシンタイプ通信（ＭＴＣ）のためのアーキテクチャも定義している。そのアーキテクチャでは、サービス層、およびそれが提供するサービス能力は、サービス能力サーバ（ＳＣＳ）の一部として実装される。ＥＴＳＩ Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬ、またはＮＳＣＬで具現化されるかどうか、３ＧＰＰ ＭＴＣアーキテクチャのサービス能力サーバ（ＳＣＳ）で具現化されるかどうか、ｏｎｅＭ２ＭアーキテクチャのＣＳＦまたはＣＳＥで具現化されるかどうか、もしくはネットワークのある他のノードで具現化されるかどうかに関わらず、サービス層のインスタンスは、サーバ、コンピュータ、および他のコンピュータデバイスもしくはノードを含む、ネットワーク内の１つ以上の独立型ノード上で実行される論理エンティティ（例えば、ソフトウェア、コンピュータ実行可能命令等）として、もしくは１つ以上の既存のノードの一部としてのいずれかで実装され得る。例として、サービス層またはそのコンポーネントのインスタンスは、以下で説明される図２２Ｃもしくは図２２Ｄに図示される一般アーキテクチャを有する、ネットワークノード（例えば、サーバ、コンピュータ、ゲートウェイ、デバイス等）上で作動するソフトウェアの形態で実装され得る。

さらに、ＰＣＲＦ７０２、９１４、および１９０８、ＭＴＣ−ＩＷＦ７０４、ＰＣＥＦ７０６、９１２および２００２、課金エンティティ９１６、３ＧＰＰ ＣＮ９１０、ＳＤ−ＣＳ６０２、ＳＤ−ＯＤＳ６０８、ＳＤ−ＯＦＣＳ６０６、ＳＤ−ＣＴＦ６１０、１３０２、および１９０２、ＳＤ−ＣＣＦ１１０２、Ｍ２Ｍアプリケーション１１０８、課金ＳＣ１２０２、サービス課金および会計ＣＳＦ１６０４、ネットワークサービスエクスポージャＣＳＦ１６０６、３ＧＰＰ ＣＮ１９０６、サービス層９０４、１６００、１９０４、ＡＣＣ２１０４、サービスエクスポージャコンポーネント２１０４、ＵＥ９０６における論理、ならびにインターフェース２３０２および２３０４等のインターフェースを生成するための論理等の論理エンティティは、本願のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装されることができる。

図２２Ｃは、Ｍ２Ｍデバイス１８、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍサーバ等のＭ２Ｍネットワークノード３０の例示的ハードウェア／ソフトウェアアーキテクチャのブロック図である。ノード３０は、ＰＣＲＦ７０２、９１４、および１９０８、ＭＴＣ−ＩＷＦ７０４、ＰＣＥＦ７０６、９１２および２００２、課金エンティティ９１６、３ＧＰＰ ＣＮ９１０、ＳＤ−ＣＳ６０２、ＳＤ−ＯＤＳ６０８、ＳＤ−ＯＦＣＳ６０６、ＳＤ−ＣＴＦ６１０、１３０２、および１９０２、ＳＤ−ＣＣＦ１１０２、Ｍ２Ｍアプリケーション１１０８、課金ＳＣ１２０２、サービス課金および会計ＣＳＦ１６０４、ネットワークサービスエクスポージャＣＳＦ１６０６、３ＧＰＰ ＣＮ１９０６、サービス層９０４、１６００、１９０４、ＡＣＣ２１０４、サービスエクスポージャコンポーネント２１０４、ＵＥ９０６における論理、ならびにインターフェース２３０２および２３０４等のインターフェースを生成するための論理等の論理エンティティを実行するか、またはそれらを含むことができる。デバイス３０は、図２２Ａ−Ｂに示されるようなＭ２Ｍネットワークの一部、または非Ｍ２Ｍネットワークの一部であり得る。図２２Ｃに示されるように、Ｍ２Ｍノード３０は、プロセッサ３２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ、タッチパッド、および／またはインジケータ４２と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。ノード３０はまた、送受信機３４および伝送／受信要素３６等の通信回路を含み得る。Ｍ２Ｍノード３０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。このノードは、本明細書に説明されるＳＭＳＦ機能性を実装する、ノードであり得る。

プロセッサ３２は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態マシン等であり得る。一般に、プロセッサ３２は、ノードの種々の要求される機能を果たすために、ノードのメモリ（例えば、メモリ４４および／またはメモリ４６）内に記憶されたコンピュータ実行可能命令を実行し得る。例えば、プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはＭ２Ｍノード３０が無線もしくは有線環境内で動作することを可能にする任意の他の機能性を果たし得る。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムならびに／もしくは他の通信プログラムを実行し得る。プロセッサ３２はまた、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、ならびに／もしくは暗号化動作等のセキュリティ動作を行い得る。

図２２Ｃに示されるように、プロセッサ３２は、その通信回路（例えば、送受信機３４および伝送／受信要素３６）に結合される。プロセッサ３２は、ノード３０に、それが接続されるネットワークを介して他のノードと通信させるために、コンピュータ実行可能命令の実行を通して、通信回路を制御し得る。特に、プロセッサ３２は、本明細書および請求項に説明される伝送および受信ステップを行うために、通信回路を制御し得る。図２２Ｃは、プロセッサ３２および送受信機３４を別個のコンポーネントとして描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップ内にともに組み込まれ得ることが理解されるであろう。

伝送／受信要素３６は、Ｍ２Ｍサーバ、ゲートウェイ、デバイス等を含む、他のＭ２Ｍノードに信号を伝送する、またはそこから信号を受信するように構成され得る。例えば、実施形態では、伝送／受信要素３６は、ＲＦ信号を伝送および／または受信するように構成されるアンテナであり得る。伝送／受信要素３６は、ＷＬＡＮ、ＷＰＡＮ、セルラー等の種々のネットワークならびにエアインターフェースをサポートし得る。実施形態では、伝送／受信要素３６は、例えば、ＩＲ、ＵＶ、もしくは可視光信号を伝送および／または受信するように構成されるエミッタ／検出器であり得る。さらに別の実施形態では、伝送／受信要素３６は、ＲＦおよび光信号の両方を伝送ならびに受信するように構成され得る。伝送／受信要素３６は、無線もしくは有線信号の任意の組み合わせを伝送および／または受信するように構成され得ることが理解されるであろう。

加えて、伝送／受信要素３６は、単一の要素として図２２Ｃに描写されているが、Ｍ２Ｍノード３０は、任意の数の伝送／受信要素３６を含み得る。より具体的に、Ｍ２Ｍノード３０は、ＭＩＭＯ技術を採用し得る。したがって、実施形態では、Ｍ２Ｍノード３０は、無線信号を伝送および受信するための２つまたはそれを上回る伝送／受信要素３６（例えば、複数のアンテナ）を含み得る。

送受信機３４は、伝送／受信要素３６によって伝送される信号を変調するように、および伝送／受信要素３６によって受信される信号を復調するように構成され得る。上記のように、Ｍ２Ｍノード３０は、マルチモード能力を有し得る。したがって、送受信機３４は、Ｍ２Ｍノード３０が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１等の複数のＲＡＴを介して通信することを可能にするための複数の送受信機を含み得る。

プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、その中にデータを記憶し得る。例えば、プロセッサ３２は、上記で説明されるように、セッションコンテキストをそのメモリ内に記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等のＭ２Ｍノード３０上に物理に位置しないメモリから情報にアクセスし、その中にデータを記憶し得る。プロセッサ３２は、ディスプレイまたはインジケータ４２上の照明パターン、画像、もしくは色を制御し、Ｍ２Ｍサービス層セッション移行または共有のステータスを反映するように、もしくはノードのセッション移行または共有能力もしくは設定についての入力をユーザから取得するように、または情報をユーザに表示するように構成され得る。別の実施例では、ディスプレイは、セッション状態に関する情報を示し得る。本開示は、ｏｎｅＭ２Ｍ実施形態においてＲＥＳＴｆｕｌユーザ／アプリケーションＡＰＩを定義する。ディスプレイ上に示され得る、グラフィカルユーザインターフェースは、ユーザが、本明細書に説明される下層サービス層セッション機能性を介して、Ｅ２Ｅセッション、またはその移行もしくは共有を双方向に確立および管理することを可能にするために、ＡＰＩの上部に層化され得る。

プロセッサ３２は、電源４８から受電し得、Ｍ２Ｍノード３０内の他のコンポーネントへの電力を分配および／または制御するように構成され得る。電源４８は、Ｍ２Ｍノード３０に給電するための任意の好適なデバイスであり得る。例えば、電源４８は、１つ以上の乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池等を含み得る。

プロセッサ３２はまた、Ｍ２Ｍノード３０の現在の場所に関する場所情報（例えば、経度および緯度）を提供するように構成されるＧＰＳチップセット５０に結合され得る。Ｍ２Ｍノード３０は、実施形態と一致したままで、任意の好適な場所決定方法を介して場所情報を獲得し得ることが理解されるであろう。

プロセッサ３２はさらに、追加の特徴、機能性、および／または有線もしくは無線コネクティビティを提供する、１つ以上のソフトウェアならびに／もしくはハードウェアモジュールを含み得る他の周辺機器５２に結合され得る。例えば、周辺機器５２は、加速度計、ｅ−コンパス、衛星送受信機、センサ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ等を含み得る。

図２２Ｄは、Ｍ２Ｍサーバ、ゲートウェイ、デバイス、もしくは他のノード等のＭ２Ｍネットワークの１つ以上のノードを実装するためにも使用され得る、例示的コンピュータシステム９０のブロック図である。コンピュータシステム９０は、コンピュータまたはサーバを備え得、主に、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得、どこでもまたはどの手段を用いても、そのようなソフトウェアが記憶もしくはアクセスされる。コンピュータシステム９０は、ＰＣＲＦ７０２、９１４、および１９０８、ＭＴＣ−ＩＷＦ７０４、ＰＣＥＦ７０６、９１２および２００２、課金エンティティ９１６、３ＧＰＰ ＣＮ９１０、ＳＤ−ＣＳ６０２、ＳＤ−ＯＤＳ６０８、ＳＤ−ＯＦＣＳ６０６、ＳＤ−ＣＴＦ６１０、１３０２、および１９０２、ＳＤ−ＣＣＦ１１０２、Ｍ２Ｍアプリケーション１１０８、課金ＳＣ１２０２、サービス課金および会計ＣＳＦ１６０４、ネットワークサービスエクスポージャＣＳＦ１６０６、３ＧＰＰ ＣＮ１９０６、サービス層９０４、１６００、１９０４、ＡＣＣ２１０４、サービスエクスポージャコンポーネント２１０４、ＵＥ９０６における論理、ならびにインターフェース２３０２および２３０４等のインターフェースを生成するための論理等の論理エンティティを実行するか、またはそれらを含むことができる。コンピュータシステム９０は、Ｍ２Ｍデバイス、ユーザ機器、ゲートウェイ、ＵＥ／ＧＷ、または、例えば、モバイルコアネットワーク、サービス層ネットワークアプリケーションプロバイダ、端末デバイス１８、もしくはＭ２Ｍゲートウェイデバイス１４のノードを含む任意の他のノードであり得る。そのようなコンピュータ読み取り可能な命令は、コンピュータシステム９０を稼働させるために、中央処理装置（ＣＰＵ）９１等のプロセッサ内で実行され得る。多くの公知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央処理装置９１は、複数のプロセッサを備え得る。コプロセッサ８１は、追加の機能を果たす、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは異なる随意のプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、セッション証明書の受信またはセッション証明書に基づく認証等のＥ２Ｅ Ｍ２Ｍサービス層セッションのための開示されるシステムおよび方法に関連するデータを受信、生成、および処理し得る。

動作時、ＣＰＵ９１は、命令をフェッチ、復号、および実行し、コンピュータの主要データ転送パスであるシステムバス８０を介して、情報を他のリソースへ、およびそこから転送する。そのようなシステムバスは、コンピュータシステム９０内のコンポーネントを接続し、データ交換のための媒体を定義する。システムバス８０は、典型的には、データを送信するためのデータラインと、アドレスを送信するためのアドレスラインと、割り込みを送信するため、およびシステムバスを操作するための制御ラインとを含む。そのようなシステムバス８０の実施例は、ＰＣＩ（周辺コンポーネント相互接続）バスである。

システムバス８０に結合されるメモリは、ランダムアクセスメモリ（ＲＡＭ）８２と、読み取り専用メモリ（ＲＯＭ）９３とを含む。そのようなメモリは、情報が記憶され、読み出されることを可能にする回路を含む。ＲＯＭ９３は、概して、容易に修正されない記憶されたデータを含む。ＲＡＭ８２内に記憶されたデータは、ＣＰＵ９１または他のハードウェアデバイスによって読み取られること、もしくは変更されることができる。ＲＡＭ８２および／またはＲＯＭ９３へのアクセスは、メモリコントローラ９２によって制御され得る。メモリコントローラ９２は、命令が実行されると、仮想アドレスを物理アドレスに変換するアドレス変換機能を提供し得る。メモリコントローラ９２はまた、システム内のプロセスを隔離し、ユーザプロセスからシステムプロセスを隔離するメモリ保護機能を提供し得る。したがって、第１のモードで作動するプログラムは、その独自のプロセス仮想アドレス空間によってマップされるメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることはできない。

加えて、コンピュータシステム９０は、ＣＰＵ９１からプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５等の周辺機器に命令を伝達する責任がある、周辺機器コントローラ８３を含み得る。

ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピュータシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために要求される電子コンポーネントを含む。

さらに、コンピュータシステム９０は、コンピュータシステム９０がネットワークの他のノードと通信することを可能にするために、例えば、図２２Ａおよび図２２Ｂのネットワーク１２等の外部通信ネットワークにコンピュータシステム９０を接続するために使用され得るネットワークアダプタ９７等の通信回路を含み得る。

ユーザ機器（ＵＥ）は、通信するためにエンドユーザによって使用される任意のデバイスであり得る。これは、手持ち式電話、モバイルブロードバンドアダプタを具備されたラップトップコンピュータ、または任意の他のデバイスであり得る。例えば、ＵＥは、図２２Ａ−ＢのＭ２Ｍ端末デバイス１８または図２２Ｃのデバイス３０として実装されることができる。

本明細書に説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令（すなわち、プログラムコード）の形態で具現化され得、その命令は、例えば、Ｍ２Ｍサーバ、ゲートウェイ、デバイス等を含む、Ｍ２Ｍネットワークのノード等のマシンによって実行されると、本明細書に説明されるシステム、方法、およびプロセスを実施ならびに／もしくは実装することが理解される。特に、ゲートウェイ、ＵＥ、ＵＥ／ＧＷ、またはモバイルコアネットワーク、サービス層、もしくはネットワークアプリケーションプロバイダのノードのうちのいずれかの動作を含む、上記で説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態で実装され得る。ＰＣＲＦ７０２、９１４、および１９０８、ＭＴＣ−ＩＷＦ７０４、ＰＣＥＦ７０６、９１２および２００２、課金エンティティ９１６、３ＧＰＰ ＣＮ９１０、ＳＤ−ＣＳ６０２、ＳＤ−ＯＤＳ６０８、ＳＤ−ＯＦＣＳ６０６、ＳＤ−ＣＴＦ６１０、１３０２、および１９０２、ＳＤ−ＣＣＦ１１０２、Ｍ２Ｍアプリケーション１１０８、課金ＳＣ１２０２、サービス課金および会計ＣＳＦ１６０４、ネットワークサービスエクスポージャＣＳＦ１６０６、３ＧＰＰ ＣＮ１９０６、サービス層９０４、１６００、１９０４、ＡＣＣ２１０４、サービスエクスポージャコンポーネント２１０４、ＵＥ９０６における論理、ならびにインターフェース２３０２および２３０４等のインターフェースを生成するための論理等の論理エンティティは、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令の形態で具現化され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための任意の非一過性（すなわち、有形または物理）方法もしくは技術で実装される、揮発性および不揮発性、取り外し可能および非取り外し可能媒体の両方を含むが、そのようなコンピュータ読み取り可能な記憶媒体は、信号を含まない。コンピュータ読み取り可能な記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、もしくは所望の情報を記憶するために使用され得、コンピュータによってアクセスされ得る任意の他の有形または物理媒体を含むが、それらに限定されない。

図に例証されるような本開示の主題の好ましい実施形態を説明する際に、明確にするために、具体的用語が採用される。しかしながら、請求される主題は、そのように選択された具体的用語に限定されることを意図しておらず、各具体的要素は、類似目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。

本明細書は、最良の様態を含む、本発明を開示するために、また、当業者が、任意のデバイスまたはシステムを作製して使用することと、任意の組み込まれた方法を行うこととを含む、本発明を実践することを可能にするために、実施例を使用する。本発明の特許性のある範囲は、請求項によって定義され、当業者に想起される他の実施例を含み得る。そのような他の実施例は、請求項の文字通りの言葉とは異ならない要素を有する場合に、または請求項の文字通りの言葉とのごくわずかな差異を伴う同等の要素を含む場合に、請求項の範囲内であることを意図している。

Claims (18)

1. 通信ネットワークのサービス層内のノードによって使用される方法であって、前記ノードは、プロセッサとメモリとを含み、前記ノードは、前記メモリ内に記憶されたコンピュータ実行可能な命令をさらに含み、前記命令は、前記プロセッサによって実行されると、
   下層ネットワークにおけるイベントの発生を示す信号を前記下層ネットワークから送信するためのトリガを前記通信ネットワーク内に設定することであって、前記信号は、ユーザ機器のリソース使用に相関する課金情報を含み、前記課金情報は、前記サービス層が課金挙動を変更することを可能にする、ことと、
   前記トリガの結果として前記信号を受信することと、
   前記受信された信号に基づいて前記サービス層における課金動作を更新することと
   を含む方法の機能を果たす、方法。
2. 前記トリガは、課金ポリシートリガである、請求項１に記載の方法。
3. 前記トリガは、課金イベントトリガである、請求項１に記載の方法。
4. 前記課金イベントトリガは、前記サービス層がサービス層課金情報記録（例えば、ＣＤＲ）を更新すべきこと、または、サービス層課金動作を更新すべきことの指示である、請求項３に記載の方法。
5. 前記トリガを設定することは、課金相関規則に従って行われる、請求項１に記載の方法。
6. サービスドメイン−課金相関機能（ＳＤ−ＣＣＦ）が、イベントを報告するために前記トリガを設定することを開始する、請求項１に記載の方法。
7. 前記ＳＤ−ＣＣＦは、課金相関規則を管理する、請求項６に記載の方法。
8. 前記課金相関規則は、前記トリガが設定されるべきことと、前記サービス層課金相関をどのようにして行うかとを示す、請求項７に記載の方法。
9. 通信ネットワークのサービス層内のノードであって、前記ノードは、プロセッサとメモリとを含み、前記ノードは、前記ノードの前記メモリ内に記憶されたコンピュータ実行可能な命令をさらに含み、前記命令は、前記ノードのプロセッサによって実行されると、
   下層ネットワークにおけるイベントの発生を示す信号を前記下層ネットワークから送信するためのトリガを前記通信ネットワーク内に設定することであって、前記信号は、ユーザ機器のリソース使用に相関する課金情報を含み、前記課金情報は、前記サービス層が課金挙動を変更することを可能にする、ことと、
   前記トリガの結果として前記信号を受信することと、
   前記受信された信号を使用して、前記サービス層における課金動作を更新することと
   を前記ノードに行わせる、ノード。
10. 前記トリガは、課金ポリシートリガである、請求項９に記載のノード。
11. 前記トリガは、課金イベントトリガである、請求項９に記載のノード。
12. 前記課金イベントトリガは、前記サービス層がサービス層課金情報記録（例えば、ＣＤＲ）を更新すべきこと、または、サービス層課金動作を更新すべきことの指示である、請求項１１に記載のノード。
13. 前記トリガを設定することは、課金相関規則に従って行われる、請求項９に記載のノード。
14. サービスドメイン−課金相関機能（ＳＤ−ＣＣＦ）が、前記トリガを設定することを開始する、請求項９に記載のノード。
15. 前記ＳＤ−ＣＣＦは、課金相関規則を管理する、請求項１４に記載のノード。
16. 前記課金相関規則は、前記トリガが設定されるべきことと、前記サービス層課金相関をどのようにして行うかとを示す、請求項１５に記載のノード。
17. 通信ネットワーク内のノードによって使用される方法であって、前記ノードは、プロセッサとメモリとを含み、前記ノードは、前記メモリ内に記憶されたコンピュータ実行可能な命令をさらに含み、前記命令は、前記プロセッサによって実行されると、
    前記通信ネットワークのサービス層からトリガを受信することと、
    前記トリガを使用して、下層ネットワーク内のイベントの発生を示す信号を生成することであって、前記信号は、ユーザ機器のリソース使用に相関する課金情報を含み、前記課金情報は、前記サービス層が課金挙動を変更することを可能にする、ことと、
    前記トリガの結果として、前記信号を前記サービス層に送信することと
    を含む方法の機能を果たす、方法。
18. 通信ネットワークのノードであって、前記ノードは、プロセッサとメモリとを含み、前記ノードは、前記ノードの前記メモリ内に記憶されたコンピュータ実行可能な命令をさらに含み、前記命令は、前記ノードのプロセッサによって実行されると、
    前記通信ネットワークのサービス層からトリガを受信することと、
    前記トリガを使用して、下層ネットワーク内のイベントの発生を示す信号を生成することであって、前記信号は、ユーザ機器のリソース使用に相関する課金情報を含み、前記課金情報は、前記サービス層が課金挙動を変更することを可能にする、ことと、
    前記トリガの結果として、前記信号を前記サービス層に送信することと
    を前記ノードに行わせる、ノード。