JP2010534994A

JP2010534994A - Ｒａｃｆ設定情報を提供するための方法およびシステム

Info

Publication number: JP2010534994A
Application number: JP2010518788A
Authority: JP
Inventors: ボドロー、アレイン; ロシェフォルト、スティーブン
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2007-07-27
Filing date: 2008-07-21
Publication date: 2010-11-11
Anticipated expiration: 2028-07-21
Also published as: WO2009016543A2; WO2009016543A3; CN101766007B; ATE534220T1; US7953026B2; EP2174454B1; CN101766007A; JP5355566B2; EP2174454A2; US20090028159A1

Abstract

複数の可能性が存在する場合に、ノードのためのアドレス情報を提供するための、方法およびシステムが説明される。例えば、ＴＩＳＰＡＮ環境において、説明されている技術は、異なったＩＰドメインに関連する複数のＡ−ＲＡＣＦのどれが、ＳＰＤＦが通信する必要があるものかを決定する必要がある場合、ＳＰＤＦへアドレス情報を送信するために用いられうる。
【選択図】図３

Description

本発明は、一般的に電気通信システムに関し、特に、ノード間で識別情報を伝達するための方法およびシステムに関する。

通信システムは成長と進化とを続けている。通信システムの異なる種類、例えばインターネットプロトコル（ＩＰ：Internet Protocol）、接続ベースの音声通信などの間での収束が急速に進展している。近年、“次世代ネットワーク”（ＮＧＮ：Next Generation Network）という言葉が、この進化に関連する様々な活動を説明するために用いられている。国際電気通信連合（ＩＴＵ：International Telecommunications Union）によって定義されるように、ＮＧＮは、パケットベースのネットワークであって、サービス（電気通信サービスを含む）を提供することが可能で、多重広帯域（multiple broadband）を利用することが可能で、サービスの質（ＱｏＳ：Quality of Service）に対応したトランスポート技術（transport technologies）であって、サービス関連の機能は下層のトランスポート関連の技術から独立している。ＮＧＮはまた、おそらく、ユーザによる異なるサービス提供者への無制限のアクセスを提供し、同様にエンドユーザに一貫したサービス供給を提供するであろう、一般化された移動性をサポートするであろう。

様々な標準化グループが、ＮＧＮ設計および実装に影響するであろう技術的な検討事項に関して合意に達することに取り組んでいる。例えば、高度なネットワークのために電気通信およびインターネットに収束されたサービスおよびプロトコル（ＴＩＳＰＡＮ：Telecoms & Internet converged Services & Protocols for Advanced Networks）は、インターネットおよびその他の固定ネットワークにおいて用いられる技術の収束に重点的に取り組む、ヨーロッパ電気通信標準化協会（ＥＴＳＩ：European Telecommunications Standards Institute）標準化グループである。とりわけ、ＴＩＳＰＡＮは、新たな需要およびサービスクラス（service classes）をカバーするために、徐々に新たなサブシステムを追加することを容易にする、モジュール式の（modular）、サブシステム志向の（subsystem-oriented）アーキテクチャを提供することを追及している。ＴＩＳＰＡＮアーキテクチャは、例えば行政界を越えるような、改良された移動性を提供するために、ネットワークリソース、アプリケーション、およびユーザ装置が、様々なサブシステムのすべてにおいて共通であることを確保することを試みている。

ＴＩＳＰＡＮサブシステムの１つは、ネットワーク接続サブシステム（ＮＡＳＳ：Network Attachment Sub System）と呼ばれる。ＮＡＳＳはとりわけ、設定情報、ユーザ認証データ、インターネットプロトコル（ＩＰ）アドレス割り当ての取り扱い、およびユーザ装置（ＵＥ：user equipment）に割り当てられたＩＰアドレスと関連するネットワーク位置情報との間の関連性の登録に関与する。“Telecommunications and Internet converged Services and Protocols for Advanced Networking（TISPAN）；NGN Functional Architecture；Network Attachment Sub-System（NASS）”，ETSI ES 282 004 Vl.1.1（2006-06）と題されたＥＴＳＩ標準化文書における図５．１と同様である、例示的なアーキテクチャが図１において示されている。この例示的なアーキテクチャは、ＮＡＳＳおよびＮＡＳＳ内部の要素と情報を交換するいくつかの外部要素を示している。図１において示された機能的なエンティティに関する簡単な考察が以下で提供されるが、さらなる詳細に興味のある読者は上記の標準化文書に向かわれたい。また、図１において、様々なエンティティの間のリンクはインタフェースを表す。ＮＡＳＳにおけるインタフェースは、関連付けられた小文字と数字の組み合わせ（例えば、“ｅ２”および“ａ３”）をもち、上記の標準化文書において考察される標準化されたインタフェースにあたる。その他のインタフェース、例えばＰｑおよびＧｑ’は、ＮＡＳＳの外部で用いられ、関係のある部分が示されている。

例えば、接続性セッション位置およびリポジトリ機能（ＣＬＦ：Connectivity Session Location and Repository Function）１０は、とりわけ、接続のためにＵＥ１２に割り当てられたＩＰアドレスと、例えばアクセストランスポート機器の特性、行識別子（論理アクセスＩＤ）、ＩＰエッジ識別などのような、ネットワークアクセス設定機能（ＮＡＣＦ：Network Access Configuration Function）１４によって提供される、関連するネットワーク位置情報と間の関連性を登録する操作を行う。従って、ＮＡＣＦ１４は、ＩＰアドレスをＵＥ１２に割り当てる操作を行い、また、例えばＤＮＳサーバのアドレスおよび特定のプロトコルのためのシグナリングプロキシのアドレスなど、他のネットワーク設定パラメータをも提供しうる。ＣＬＦ１０はまた、リソースおよび入場制御サブシステム（ＲＡＣＳ：Resource and Admission Control Subsystem）１６、その他のサービス制御サブシステムおよびアプリケーション１８、およびユーザアクセス権限付与機能（ＵＡＡＦ：User Access Authorization Function）２０と通信する。ＵＡＡＦ２０は、ネットワークアクセスのためのユーザプロファイル（user profiles）に基づいて、ユーザ認証および権限付与チェックを実行する。ＵＡＡＦ２０は、プロファイルデータベース機能（ＰＤＢＦ：Profile Database Function）２２に含まれるユーザネットワークプロファイル情報から、認証データおよびアクセス権限付与情報を検索する。

ＲＡＣＳ１６は、アクセスリソースおよび入場制御機能（Ａ−ＲＡＣＦ：Access-Resource and Admission Control Function）３４およびサービスベースのポリシー決定機能（ＳＰＤＦ：Service-based Policy Decision Function）３６を含む。ＲＡＣＳ１６は、ポリシーベース（policy based）のトランスポート制御サービス、例えば特定のアプリケーションのためのある時間におけるリソース予約を実現するための、ＮＡＳＳとＡＦ３８との間のインタフェースとして振舞う。ＲＡＣＳ１６内の機能的要素は、これらのポリシーベースのトランスポート制御サービスをサポートするために用いられる。より具体的には、Ａ−ＲＡＣＦ３４は入場制御およびネットワークポリシーの組立てをサポートし、ＳＰＤＦ３６は論理ポリシー決定要素であり、例えばリソース要求情報の受信およびチェックのような機能を実行し、トランスポート層からＡＦ３８を隔離する。ＲＡＣＳ３４に関するさらなる情報は、“Telecommunications and Internet converged Services and Protocols for Advanced Networking（TISPAN）；Resource and Admission Control Sub-system（RACS）；Functional Architecture，ETSI ES 282 003 Vl.1.1（2006-06）において見出されるであろう。

アクセス管理機能（ＡＭＦ：Access Management Function）２４は、ＵＥ１２によって発行されたネットワークアクセス要求を翻訳し、ＩＰアドレスと、任意でＮＡＣＦ１４へ／からの追加的なネットワーク設定パラメータとの割り当てのために、それらの要求を転送する。ＡＭＦ２４はまた、ユーザを認証し、ネットワークアクセスを許可または拒否し、またユーザ固有のアクセス設定パラメータを検索するために、ＵＡＡＦ２０へ要求を転送する。ＮＡＳＳアーキテクチャはさらに、顧客ネットワークゲートウェイ（ＣＮＧ：Customer Network Gateway）２８とＮＡＳＳとの間のリレーとして振舞い、ローカル設定情報を挿入するアクセスリレー機能（ＡＲＦ：Access Relay Function）２６を含む。

図１に示されるように、ＵＥ１２は端末装置（ＴＥ：terminal equipment）３０それ自身と、ＣＮＧ２８とに機能的に分割されうる。ＣＮＧ２８は、ＣＮＧ設定機能（ＣＮＧＣＦ：CNG Configuration Function）３２から設定データを受信する。より具体的には、上記の標準化文書において記載されているように、ＣＮＧＣＦ３２は、ＣＮＧ２８に、ＮＡＣＦ１４によって提供されるネットワーク設定データとは異なる設定データである、追加的な設定情報（例えばＣＮＧ２８における内部的なファイアウォールの設定、ＩＰパケットのＱｏＳマーキングなど）をＣＮＧ２８に提供するために、ＣＮＧ２８の初期化および更新の間に用いられる。

上記の要素を活用して、外部のＡＦ３８は、ユーザに代わってアクセスネットワークからトランスポートリソースを予約することができる。ＡＦ３８にとって、このプロセスを実行するための１つの方法は、特定のＳＰＤＦ３６のアドレスを入手するために、ｅ２インタフェースを通して、サービスを提供しているネットワークのＣＬＦ１０の既知のアドレスにコンタクトすることである。ＡＦ３８は次に、ユーザ情報および所望のサービスのために要求されるＱｏＳ特性を伴って、Ｇｑ’インタフェースを通して特定のＳＰＤＦ３６にコンタクトする。ＳＰＤＦ３６は次に、適切なリソースを予約するためにＡ−ＲＡＣＦ３４にコンタクトする。この現行の解決法に伴う問題は、ＳＰＤＦ３６がアクセス領域を供給するために通信することが可能な、複数のＡ−ＲＡＣＦ３４があるときに発生する。この場合、ＳＰＤＦ３６は、ＡＦ３８から与えられた要求をサポートするために通信すべきＡ−ＲＡＣＦ３４がどれか、必ずしも識別できないであろう。どのようにして複数のＡ−ＲＡＣＦ３４のうち適切な１つを識別するかに関する１つのあり得る解決法は、静的ＩＰアドレスドメインをそれぞれのＡ−ＲＡＣＦ３４のために定めることであろう。しかしながら、この解決法は、静的ＩＰアドレスの提供に関連する柔軟性の欠如のために、最適ではないであろう。なお、図１は異なったＩＰアドレスドメインをもつ複数のＡ−ＲＡＣＦ３４を示していないが、ＳＰＤＦ３６が通信する異なったＩＰアドレスドメインをもつ複数のＡ−ＲＡＣＦ３４が存在しうることは理解されるべきである。

しかしながら、与えられたアクセス要求を取り扱うために用いられるべき、アクセス領域を供給する複数のＡ−ＲＡＣＦのうちのいずれかをＳＰＤＦが決定することを可能にするための、現在のところ利用可能である効果的な装置または技術はない。

本発明に係るシステムおよび方法は、通信ネットワークにおけるノード間でのアドレス情報送信を容易にする技術および装置を提供することによって、これらの必要およびその他に対処する。

１つの例示的な実施形態によれば、ネットワークノードは：少なくとも１つのリソース管理ノードに関連する設定情報を受信するためのプロセッサと；上記設定情報を格納するための記憶装置と；を含み、上記プロセッサが別のノードから問い合わせを受信したとき、上記別のノードへ上記プロセッサにより応答メッセージが送信され、上記応答メッセージは上記少なくとも１つのリソース管理ノードの１つのアドレスを含む。

他の例示的な実施形態によれば、ネットワークノードは：所望のリソースに基づくアドレス情報のための問い合わせを送信するためのプロセッサと；上記問い合わせへの応答において受信された情報を格納するための記憶装置と；を含み、上記プロセッサが上記問い合わせへの応答を受信した後、上記プロセッサは、リソース管理ノードに関連するアドレスを含むサービス要求メッセージを送信する。

さらに別の例示的な実施形態によれば、複数のリソース管理ノードの１つから、ネットワークノードによってリソースを要求するための方法は：所望のリソースに基づくアドレス情報を要求する問い合わせメッセージを送信することと；上記アドレス情報を含む応答メッセージを受信することと；リソース管理ノードに関連するアドレスを含むサービス要求メッセージを送信することと；を含む。

さらに別の例示的な実施形態によれば、ネットワークノードによって通信するための方法は：少なくとも１つのリソース管理ノードに関連する設定情報を受信することと；上記設定情報を記憶装置に格納することと；上記少なくとも１つのリソース管理ノードの１つのアドレスを含む応答メッセージを送信することと；を含む。

添付図面は、例示的な実施形態を示している。

例示的な実施形態に係る通信システムを示す図である。例示的な実施形態に係る、複数のアクセスリソースおよび入場制御機能（Ａ−ＲＡＣＦ）と通信接続性をもつサービスベースのポリシー決定機能（ＳＰＤＦ）を示す図である。例示的な実施形態に係るコールフロー図である。例示的な実施形態に係る通信ノードを示す図である。例示的な実施形態に係る通信方法を示すフローチャートである。例示的な実施形態に係る別の通信方法を示すフローチャートである。

以下の例示的な実施形態の詳細な説明は、添付図面を参照する。異なる図面における同一の参照番号は、同一または類似する要素を特定する。また、以下の詳細な説明は発明を限定しない。その代わりに、発明の範囲は添付の請求の範囲によって定義される。

上記のように、ネットワーク接続サブシステム（ＮＡＳＳ）が通信システムにおいて他の要素と通信をする例示的なシステムは、図１において示されている。インスタントアプリケーション（instant application）において特に興味深い、図１において示されるこの例示的なシステムの要素は、接続性セッション位置およびリポジトリ機能（ＣＬＦ）１０、アクセスリソースおよび入場制御機能（Ａ−ＲＡＣＦ）３４およびサービスベースのポリシー決定機能（ＳＰＤＦ）３６を含むリソースおよび入場制御（ＲＡＣＳ）１６、およびアプリケーション機能（ＡＦ：Application Function）３８である。これらの要素の間の通信フロー（communications flow）は、様々な標準化されたインタフェース、例えばｅ２、ｅ４、Ｇｑ’およびＰｑによって描かれている。背景技術の節において簡単に紹介されたように、ＳＰＤＦ３６が区別すべき複数のＡ−ＲＡＣＦ３４が存在する場合、これらの要素の間の通信フローにおいて問題が発生しうる。より具体的には、図２において示されるように、ＳＰＤＦ２０２は、どのＡ−ＲＡＣＦが、ＡＦ３８によって要求される加入者接続（subscriber connection）をサポートするために必要とされるリソースに関連するかに依存して、ＩＰドメイン１をもつＡ−ＲＡＣＦ２０４、ＩＰドメイン２をもつＡ−ＲＡＣＦ２０６およびＩＰドメイン３をもつＡ−ＲＡＣＦ２０８の間で選択する必要があるであろう。複数のＡ−ＲＡＣＦノード選択肢が存在する場合に、所望のノードへ情報を提供するための解決法は、これらの例示的な実施形態に従って、以下でさらに詳細に説明されるであろう。

例示的な実施形態によれば、この問題は、ノード、例えばＳＰＤＦノードが、複数のノード、例えばＡ−ＲＡＣＦノードのうち、どれが所望の通信のために正しいノードであるかの情報を与えられることを必要とする、類似した状況について解決されうる。例えば、第１のノードは、第２のノードへ信号を送ることができる。この信号は、第２のノードを指し示す宛先アドレス、ならびに第３のノードおよび第４のノードの身元（identities）（またはアドレス）を含む情報を含む。第２のノードは、この信号を、第３のノードを指し示す宛先アドレス、および第４のノードの身元を含む情報とともに、第３のノードへ転送する。第３のノードは、次に、この信号を、第４のノードのための複数の宛先選択肢の区別を可能にする、第４のノードを指し示す宛先アドレスとともに、第４のノードへ転送する。ＴＩＳＰＡＮ環境の中でノードを利用する、さらに具体的な例示的な実施形態は、以下で説明されるであろう。

他の例示的な実施形態によれば、ＣＬＦ１０は、ＳＰＤＦ３６コンタクト情報のための要求の一部として、ｅ２インタフェースを通じてＡＦ３８へ、Ａ−ＲＡＣＦ３４のサービス提供インスタンス（serving instance）の身元（アドレス情報を含む）を提供する。この情報は、ｅ４インタフェースを通じて、正しいサービス提供Ａ−ＲＡＣＦ３４へ加入者プロファイル情報を送るために用いられた、事前情報（previous knowledge）に基づくため、ＣＬＦ１０は、特定の加入者がサービス提供されるべきＡ−ＲＡＣＦ３４の正しいインスタンスを知っている。従って、サービス提供Ａ−ＲＡＣＦ３４インスタンス情報は、ＣＬＦ１０によってＡＦ３８へ、続いてＡＦ３８からＳＰＤＦ３６へ送信されるであろう。このことは、ＳＰＤＦ３６が、このセッションのための今後の通信のために、複数のＡ−ＲＡＣＦからのどれを選ぶべきかを知ることを可能にする。この通信プロセスを示す例示的なコールフローが、図３に従って以下で説明されるであろう。

図３は、ノード間の設定情報のやり取りのための例示的なコールフローを表す。最初に、Ａ−ＲＡＣＦ３０８は、ＣＬＦ３０４と設定情報３１０（アクセスプロファイル配信（access profile push）としても知られる）を交換する。ＣＬＦ３０４およびＡ−ＲＡＣＦ３０８が設定情報３１０を交換した後のある時点で、ＣＬＦ３０４は、ＡＦ３０２から、位置情報問い合わせ３１２受信する。この問い合わせメッセージ３１２は、ユーザ識別情報を含む。位置情報問い合わせ３１２に応答して、ＣＬＦ３０４は、ＡＦ３０２へ、ＳＰＤＦ３０６識別子およびＡ−ＲＡＣＦ３０８識別子を含む位置情報応答３１４を送信する。ＡＦ３０２は、次に、位置情報応答メッセージ３１４において識別されたＳＰＤＦ３０６へ、Ａ−ＲＡＣＦ３０８識別子を含むサービス要求メッセージ３１６を送信する。ＳＰＤＦ３０６は、次に、以前に識別されたＡ−ＲＡＣＦ３０８へ、所望のＱｏＳ情報を含むリソース要求メッセージ３１８を送信する。Ａ−ＲＡＣＦ３０８は、次に、ＳＰＤＦ３０６へ、リソース確認メッセージ３２０を送信して返し、ＳＰＤＦ３０６は、次に、ＡＦ３０２へ、確認メッセージ３２２を送信する。

上記で説明された、図３の例示的なコールフローは、ＴＩＳＰＡＮ環境の中に存在する様々なメッセージを用いる。しかしながら、ある例示的なメッセージは、上記で説明された例示的な実施形態を可能にするための追加の情報を含むように変更されている。より具体的には、位置情報応答３１４、リソース予約要求、リソース変更要求およびリソース解放要求メッセージ（メッセージ３１６として示されている）は、Ａ−ＲＡＣＦ３０８識別情報を含むように変更されうる。当業者によって理解されうるように、これらの異なる要求メッセージは、ＡＦ３０２からの単一のメッセージ３１６として示され、セッションの状態に依存して、通信プロセスの間の異なった時間に送られる。これらのメッセージおよびそれらの変更箇所は、以下でさらに具体的に説明されるであろう。

この例示的な実施形態に係る、例示的な位置情報応答メッセージ３１４は、以下に表１において示される。

位置情報応答メッセージ３１４は、ＡＦ３０２からの位置情報問い合わせに応答して、ＣＬＦ３０４によって用いられる。例示的な実施形態に従って変更されたように、位置情報応答メッセージ３１４は、上記の表１において示されたように、ユーザのためのＡ−ＲＡＣＦ３０８エンティティの完全に記述されたドメイン名（ＦＱＤＮ：fully qualified domain name）またはＩＰアドレスのいずれかを提供することにより、Ａ−ＲＡＣＦ３０８インスタンスを供給する（serving）ための情報を含む。このメッセージにおいて、このＡ−ＲＡＣＦ３０８識別情報を提供することによって、ＡＦ３０２は、ＳＰＤＦ３０６へ、サービス要求メッセージ３１６を通じて、所望のＡ−ＲＡＣＦ３０８に関連する識別情報を転送することができる。

セッションの段階、例えばリソース予約、リソース変更、またはリソース解放に依存して、異なった種類のサービス要求メッセージ３１６が、ＡＦ３０２からＳＰＤＦ３０６へ送信されうる。これらのメッセージはそれぞれ、このセッションのために用いられるべきＡ−ＲＡＣＦ３０８のアドレスについて、ＳＰＤＦ３０６へ特定の識別情報を提供する情報を含むであろう。より具体的に、例示的な実施形態に係るリソース予約要求メッセージが表２において示されている。

サービス要求メッセージ３１６によって描かれているようなリソース予約要求メッセージは、リソースの予約を要求するためにＡＦ３０２によって用いられる。加えて、リソース予約要求メッセージは、以後のＡ−ＲＡＣＦ３０８への送信のためにＳＰＤＦ３０６へ送信され、所望のＡ−ＲＡＣＦ３０８の識別情報を含む。この情報は、上記の表２において示されているようなリソース予約要求メッセージにおいて提供され、例えばユーザのためのＡ−ＲＡＣＦ３０８エンティティのＦＱＤＮまたはＩＰアドレスのいずれかを提供することによって、Ａ−ＲＡＣＦ３０８インスタンスを供給するための情報を含む。

他の種類のサービス要求メッセージ３１６は、表３において一例が示される、リソース変更要求メッセージである。

上記で説明されたリソース予約要求と同様に、サービス要求３１６によって示されるようなリソース変更要求メッセージは、リソースの変更を要求するためにＡＦ３０２によって用いられ、今後のＡ−ＲＡＣＦ３０８への送信のためにＳＰＤＦ３０６へ送信される。加えて、所望のＡ−ＲＡＣＦ３０８の識別情報が含まれるであろう。この情報は、上記の表３において示されるように、Ａ−ＲＡＣＦ３０８インスタンスを供給するための情報を提供することと、ユーザのためのＡ−ＲＡＣＦ３０８エンティティのＦＱＤＮまたはＩＰアドレスのいずれかを提供することとによって提供される。なお、しかしながら、ＳＰＤＦ３０６は状態をもつため、初期の予約に伴って受信されたＡ−ＲＡＣＦ識別情報の再利用を可能にするためには、セッションＩＤがあれば十分であろう。従って、他の例示的な実施形態に係るリソース変更要求メッセージからは、Ａ−ＲＡＣＦ識別子フィールドが除かれてもよい。

サービス要求メッセージ３１６の第３の種類は、表４において一例が示される、リソース解放要求メッセージである。

上記で説明されたリソース予約要求メッセージと同様に、サービス要求メッセージ３１６によって描かれるようなリソース解放要求メッセージは、リソースの解放を要求するためにＡＦ３０２によって用いられる。リソース解放要求メッセージは、以後のＡ−ＲＡＣＦ３０８への送信のためにＳＰＤＦ３０６へ送信され、所望のＡ−ＲＡＣＦ３０８のための識別情報を含む。この情報は、上記で表４によって示されているようなリソース予約要求メッセージにおいて、ユーザのためのＡ−ＲＡＣＦ３０８エンティティのＦＱＤＮまたはＩＰアドレスのいずれかを提供することによって、Ａ−ＲＡＣＦ３０８インスタンスを供給するための情報を含むことによって提供される。リソース変更メッセージと同様に、Ａ−ＲＡＣＦ識別情報は、代替的にリソース解放メッセージから除かれ、代わりに初期の予約情報に基づいてＳＰＤＦ３０６によって再利用されてもよい。

上記で説明された例示的な実施形態は、通信ネットワークにおいてノード間で用いられるメッセージを示している。ここで、図４について、例示的なノード４００が説明される。サーバ４００はプロセッサ４０２（または複数のプロセッサコア）、記憶装置４０４、１以上の二次記憶装置４０６およびネットワークノード４００と残りのネットワークとの間の通信を容易にするインタフェースユニット４０８を含むであろう。加えて、サーバ４００はまた、それを通じて通信することができる、潜在的に異なる利用可能なインタフェースを通じた通信を可能にするプロトコルを含んでもよい。記憶装置（または二次記憶）は、それぞれのＩＰアドレスまたはＦＱＤＮおよびＱｏＳ情報を含むハードウェア／ソフトウェア装置についての情報のような、例示的なアイテムの格納のために用いられるであろう。従って、例示的な実施形態に係るネットワークノードは、Ａ−ＲＡＣＦ３４のためのアドレスに関連するメッセージの送信および受信のためのプロセッサを含むであろう。

例示的な実施形態に係る、上記の例示的なシステムを活用して、複数のＡ−ＲＡＣＦからネットワークノードによってリソースを要求するための方法が図５のフローチャートにおいて示されている。最初に、ステップ５０２において、ネットワークノードは、所望のリソースに基づくアドレス情報を要求する問い合わせメッセージを送信する。ネットワークノードは次に、ステップ５０４において、上記のアドレス情報を含む応答メッセージを受信する。上記応答メッセージを受信した上で、ネットワークノードは、ステップ５０６において、アクセスリソースおよび入場制御機能（Ａ−ＲＡＣＦ）に関連するアドレスを含むサービス要求メッセージを送信する。

さらに、例示的な実施形態に係る、上記の例示的なシステムを活用して、少なくとも１つのＡ−ＲＡＣＦのための設定情報をやり取りするための方法が、図６のフローチャートにおいて示されている。最初に、ステップ６０２において、ネットワークノードは、少なくとも１つのＡ−ＲＡＣＦに関連する設定情報を受信する。ネットワークノードは次に、ステップ６０４において、記憶装置に上記の設定情報を格納する。上記の設定情報を格納した後、ネットワークノードは、ステップ６０６において、上記の少なくとも１つのＡ−ＲＡＣＦの１つのアドレスを含む応答メッセージを送信する。

上記の例示的な実施形態は、あらゆる点において、本発明の限定ではなく、むしろ概略であることを意図されている。以下の請求の範囲によって定義されるように、そのようなすべての変化や変更が本発明の範囲および精神の中にあると考えられるべきである。本願の詳細な説明において用いられるいかなる要素、振舞い、または示唆も、その旨の明確な説明がない限り、発明にとって決定的に重要または本質的要素であると解釈されるべきではない。また、ここで用いられるように、冠詞“ａ”は１以上のアイテムを含むことを意図されている。

Claims

ネットワークノードであって：
少なくとも１つのリソース管理ノードに関連する設定情報を受信するためのプロセッサと；
前記設定情報を格納するための記憶装置と；
を含み、
前記プロセッサが別のノードから問い合わせを受信した場合、前記別のノードへ前記プロセッサにより応答メッセージが送信され、前記応答メッセージは前記少なくとも１つのリソース管理ノードの１つのアドレスを含む、ネットワークノード。
前記設定情報は、
前記少なくとも１つのリソース管理ノードのためのアドレス情報を含み、
前記リソース管理ノードは、
アクセスリソースおよび入場制御機能（Ａ−ＲＡＣＦ）である、
請求項１に記載のネットワークノード。
前記問い合わせは、
所望のリソースに基づいて、サービスベースのポリシー決定機能（ＳＰＤＦ）および前記少なくとも１つのＡ−ＲＡＣＦの１つのアドレスのための要求を含む、
請求項２に記載のネットワークノード。
前記応答メッセージは、
前記ＳＰＤＦおよび前記少なくとも１つのＡ−ＲＡＣＦの前記１つの前記アドレスを含む、
請求項３に記載のＣＬＦネットワークノード。
前記ネットワークノードは、
接続性セッション位置およびリポジトリ機能（ＣＬＦ）である、
請求項１に記載のネットワークノード。
前記アドレスは、
インターネットプロトコル（ＩＰ）アドレスおよび完全に記述されたドメイン名（ＦＱＤＮ）の少なくとも１つである、
請求項１に記載のネットワークノード。
ネットワークノードであって：
所望のリソースに基づくアドレス情報のための問い合わせを送信するためのプロセッサと；
前記問い合わせへの応答において受信された情報を格納するための記憶装置と；
を含み、
前記プロセッサが前記問い合わせへの応答を受信した後、前記プロセッサは、リソース管理ノードに関連するアドレスを含むサービス要求メッセージを送信する、
ネットワークノード。
前記応答は、
接続性セッション位置およびリポジトリ機能（ＣＬＦ）から受信され、サービスベースのポリシー決定機能（ＳＰＤＦ）アドレスを含み、前記リソース管理ノードのための前記アドレスは前記問い合わせに基づき、前記リソース管理ノードはアクセスリソースおよび入場制御機能（Ａ−ＲＡＣＦ）である、
請求項７に記載のネットワークノード。
前記サービス要求メッセージは、
前記ＳＰＤＦに向かって送信される、
請求項８に記載のネットワークノード。
前記ネットワークノードは、
アプリケーション機能（ＡＦ）である、
請求項８に記載のネットワークノード。
前記アドレスは、
インターネットプロトコル（ＩＰ）アドレスおよび完全に記述されたドメイン名（ＦＱＤＮ）の少なくとも１つである、
請求項８に記載のネットワークノード。
複数のリソース管理ノードの１つから、ネットワークノードによってリソースを要求するための方法であって：
所望のリソースに基づくアドレス情報を要求する問い合わせメッセージを送信することと；
前記アドレス情報を含む応答メッセージを受信することと；
前記複数のリソース管理ノードの前記１つに関連するアドレスを含むサービス要求メッセージを送信することと；
を含む方法。
前記サービス要求メッセージは、
サービスベースのポリシー決定機能（ＳＰＤＦ）の前記アドレスを含み、
前記リソース管理ノードは、
アクセスリソースおよび入場制御機能（Ａ−ＲＡＣＦ）である、
請求項１２に記載の方法。
前記応答メッセージは、
サービス提供（serving）Ａ−ＲＡＣＦインスタンス情報を含む、位置情報応答メッセージである、
請求項１３に記載の方法。
前記サービス要求メッセージは、
サービス提供Ａ−ＲＡＣＦインスタンス情報を含み、
前記サービス要求メッセージは、
リソース予約要求メッセージ、リソース変更要求メッセージおよびリソース解放要求メッセージの少なくとも１つである、
請求項１３に記載の方法。
前記アドレスは、
インターネットプロトコル（ＩＰ）アドレスおよび完全に記述されたドメイン名（ＦＱＤＮ）の少なくとも１つである、
請求項１３に記載の方法。
前記ネットワークノードは、
アプリケーション機能（ＡＦ）である、
請求項１３に記載の方法。
ネットワークノードによって通信するための方法であって：
少なくとも１つのリソース管理ノードに関連する設定情報を受信することと；
前記設定情報を記憶装置に格納することと；
前記少なくとも１つのリソース管理ノードの１つのアドレスを含む応答メッセージを送信することと；
を含む方法。
前記設定情報は、
前記少なくとも１つのリソース管理ノードのためのアドレス情報を含み、
前記リソース管理ノードは、
アクセスリソースおよび入場制御機能（Ａ−ＲＡＣＦ）である、
請求項１８に記載の方法。
前記問い合わせは、
所望のリソースに基づいて、サービスベースのポリシー決定機能（ＳＰＤＦ）および前記少なくとも１つのＡ−ＲＡＣＦの１つのアドレスのための要求を含む、
請求項１９に記載の方法。
前記応答メッセージは、
前記ＳＰＤＦおよび前記少なくとも１つのＡ−ＲＡＣＦの前記１つの前記アドレスを含む、
請求項２０に記載の方法。
前記ネットワークノードは、
接続性セッション位置およびリポジトリ機能（ＣＬＦ）である、
請求項１９に記載の方法。
前記アドレスは、
インターネットプロトコル（ＩＰ）アドレスおよび完全に記述されたドメイン名（ＦＱＤＮ）の少なくとも１つである、
請求項１９に記載の方法。