【誤訳訂正書】
【提出日】平成22年12月8日(2010.12.8)
【誤訳訂正１】
【訂正対象書類名】明細書
【訂正対象項目名】全文
【訂正方法】変更
【訂正の内容】
【発明の詳細な説明】
【発明の名称】ネットワーク
【技術分野】
【０００１】
本発明は、ネットワークに関し、特に、排他的ではないが、次世代ネットワークに関する。
【背景技術】
【０００２】
通信システムは、２つ以上の（モバイルまたは固定）端末機器または他の通信装置および/またはネットワークエンティティと、通信システムに関連する他のノードとの間の通信を可能にする設備である。通信は、例えば、音声、電子メール（Eメール）、テキストメッセージ、データ、マルチメディアなどの通信を含むことが可能である。通信システムは、一般的に、ユーザーとサービスプロバイダとの間の通信のための、およびユーザー装置にコンテンツデータを供給するためのサービスをユーザーに提供するためにも使用することが可能である。
【０００３】
通信システムは、一般的に、システムの様々な要素の何を実行しようとしているのか、およびそれをどのように達成すべきかを設定する、所与の規格または所与の一組の仕様に基づいて運用される。例えば、標準規格は、ユーザーに、より正確にはユーザー機器に回路交換経路、またはパケット交換経路、あるいはその両方を経たアクセスが提供される場合に定義することが可能である。通信システムへのアクセスのために使用すべき通信プロトコルおよび/またはパラメータが、一般的に定義される。例えば、通信をユーザー機器と通信ネットワークの要素との間で実行しなければならない様式は、一般的に、予め定義された通信プロトコルに基づいている。すなわち、通信が基づくことのできる特定の一組の"ルール"は、ユーザー機器が通信システムを経て通信できるように定義する必要がある。
【０００４】
現在、ネットワークは、固定ネットワークおよびモバイルネットワークの２つのカテゴリに分類することができる。なお、固定およびモバイルネットワーク間のコンバージェンスは、TISPAN（Telecommunication and Internet converged Services and Protocols for Advanced Networking）プロジェクトにおけるETSI（European Telecommunications Standards Institute: 欧州電気通信標準化機構）、3GPP（Third Generation Partnership Project: 第３世代パートナーシッププロジェクト）、およびITU-T（Telecommunication Standardisation Section of the International Telecommunication Union: 国際電気通信連合 電気通信標準化部門）のような、世界中の様々な標準化組織によって現在標準化されている。新しいネットワーク概念は、NGN（次世代ネットワーク）と呼ばれる。現在、NGN概念は、すでに3GPPによって標準化されたIMS（IP Multi-media Sub-System: IPマルチメディアサブシステム）コアネットワークに基づいている。
【０００５】
固定およびモバイル変換は、一部欧州委員会の資金提供を受けたMSF（Multi-Services Switching Forum: マルチサービススイッチングシステム）やMUSE（Multi-Service Access Everywhere: マルチサービスアクセスエブリウェア）プロジェクトのような、複数の業界フォーラムによっても開発されている。
【０００６】
提案されたアーキテクチャには、サービスベースのポリシー制御のための論理ポリシー判断エレメントである、サービスポリシー判断機能（Service Policy Decision Function: SPDF）がある。また、リソースおよびアドミッション制御機能もあり、このアーキテクチャでは、例えば、セッションアドミッション制御を提供し、どのネットワークポリシーを特定のアクセスに適用すべきかを決定することが可能である。
【０００７】
本発明者は、現在提案されているアーキテクチャによる問題を特定している。特に問題なのは、特定のユーザーに対して、ポリシー制御機能SPDFが適切なリソースアドミッション制御機能（Resource Admission Control Function: RACF）をどのように見つけるかを定義するための機構が設定されていないことである。これは、SPDFがRACFに情報をプッシュする場合のプッシュ機能のことである。また、RACFがSPDFから情報をリクエストするプルオペレーションを使用した場合に、すなわち、RACFが適切なSPDFをどのように見つけるのか、という問題も生じる。
【０００８】
上記の提案されている機能は、アプリケーション機能（Application function: AF）も有する。アプリケーション機能は、ポリシー判断機能と情報をやりとりする。AFはベアラリソースに対するリクエストを行い、リソースが予約および解放されるときに通知を受信することが可能である。他の機能は、アプリケーション機能によっても提供することが可能である。提案されているアーキテクチャは、ボーダーゲートウェイ機能BGFのようなエッジルーターも有する。ボーダーゲートウェイ機能は、２つのIP（インターネットプロトコル）トランスポートドメイン間のインターフェースを提供する。これは、アクセスネットワークとカスタマー構内機器との間、アクセスネットワークとコアネットワークとの間、または２つのコアネットワーク間の境界となりうる。
【０００９】
提案されている現在のアーキテクチャによる別の問題は、エッジルーター（例、BGF）がSPDFをどのように見つけるべきか、またはSPDFが適切なエッジルーターをどのように見つけるかを決定するために定義された機構がなく、プルまたはプッシュオペレーションが使用されるかどうかに依存していることである。従来技術で、特に、草案ETSI ES2xxxxv.1.1.1.1 "TISPAN NGN functional architecture"（2004年12月）に記載されているような、提案されたNGNの機能的アーキテクチャに関する従来技術は、全くこの問題に対処していない。
【００１０】
同じPDF（Policy Decision function: ポリシー判断機能）をどのように使用するのかを承知しているAFおよびエッジルーターの概念は、以下のように、プルの場合に対して3GPP IMSにおいて取り組まれている。制御プレーンとユーザープレーンとの連結に使用された承認トークンは、セッション確立メッセージにおいて、PDFのアドレスをアプリケーション機能からユーザー機器に担送する。ユーザー機器は、PDP（Packet Data Protocol: パケットデータプロトコル）コンテキストアクティブ化／変更メッセージで、アドレスをエッジルーターに送信する。ルーターは、次いで、PDFに対してプルオペレーションを使用する。なお、制御プレーンおよびNGN端末において、3GPP固有のSIP（Session Initiation Protocol: セッション開始プロトコル）メカニズムを必要とするときは、承認トークンの手法はNGNコンテキストでは不要である。また、ユーザープレーン内にトークンをトランスポートするためのいくつかの新しい機構も必要となる。加えて、トークンを使用しても、NGNアクセスを使用したときに、他の別の連結機構にわたる利点をもたらさない。
【非特許文献１】draft ETSI ES2xxxxv.1.1.1.1 "TISPAN NGN functional architecture"（2004年12月）
【発明のまとめ】
【００１１】
本発明の実施形態の目的は、上述の問題の内の１つ以上に対処することである。
【００１２】
本発明の一側面によれば、アドレスを有する第一のネットワーク機能と、前記第一のネットワーク機能の前記アドレスを必要としている第二のネットワーク機能と、前記第一のネットワーク機能の前記アドレスをメッセージに挿入するように構成された第三のネットワーク機能と、第四のネットワーク機能と、を含み、前記第三のネットワーク機能は、前記第四のネットワーク機能に前記メッセージを送信するように構成され、前記第四のネットワーク機能は、前記アドレスを取り出して、前記アドレスを前記第二のネットワーク機能に送信するように構成される、ネットワークが提供される。
【００１３】
本発明の更なる側面によれば、ネットワークで使用するためのネットワーク機能であって、前記ネットワーク機能は、第一のネットワーク機能のアドレスをメッセージに挿入して、前記メッセージを第四のネットワーク機能に送信するように構成されるネットワーク機能が提供される。
【００１４】
本発明の別の側面によれば、ネットワーク機能であって、前記ネットワーク機能は、第一のネットワーク機能のアドレスを含むメッセージを第三のネットワーク機能から受信するように構成され、前記ネットワーク機能は、前記アドレスを取り出して、前記アドレスを、前記第一のネットワーク機能の前記アドレスを必要としている前記第二のネットワーク機能に送信するように構成される、ネットワーク機能が提供される。
【００１５】
本発明の別の側面によれば、第一のネットワーク機能のアドレスを、前記第一のネットワーク機能の前記アドレスを必要としている第二のネットワーク機能に提供する方法であって、第三のネットワーク機能によって、第一のネットワーク機能のアドレスをメッセージに挿入するステップと、前記メッセージを第四のネットワーク機能に送信するステップと、前記第四のネットワーク機能によって前記アドレスを取り出すステップと、前記第四のネットワーク機能によって、前記アドレスを前記第二のネットワーク機能に送信するステップと、を含む方法が提供される。
【発明の好適な実施形態の説明】
【００１６】
本発明をさらに理解し、本発明をどのように実施するのかを示すために、一例として添付図面を参照する。
【００１７】
以下の実施形態では、モバイル発信とは、固定またはモバイルであってよいユーザー機器によって起動されるセッションまたは接続のことである。モバイル受信とは、ユーザー機器によって行われるが、他の場所で起動される接続のことである。また、ユーザー機器は、固定またはモバイルとすることができる。
【００１８】
概して、第一のネットワーク要素、要素Aのアドレスは、別のネットワーク要素、要素Bによって必要とされている。このアドレスは、ネットワーク要素、要素Cによって、ネットワーク要素、すなわち必要とされているアドレスを知っているネットワーク要素Cを介してトランスポートされるプロトコルメッセージまたはメッセージ内に挿入される。ネットワーク要素Cは、ネットワーク要素Aと同一であってよい。必要とされているアドレスは、更なるネットワーク要素、要素Dによってシグナリングメッセージから取り出され、そのアドレスを必要としているネットワーク要素、要素Bに転送される。ネットワーク要素Dは、ネットワーク要素Bと同一であっても異なっていてもよい。
【００１９】
下記の詳細な実施形態に述べるように、例えば、使用したセキュリティメソッドによって、また、挿入ネットワーク要素、すなわちネットワーク要素Cによるプロトコルの認識によって、異なる方法でアドレスを挿入することが可能である。例えば、アドレスは、特定のプロトコルレベルの特定のメッセージにだけ挿入することが可能である。例えば、メッセージは、SIP INVITEまたはSIP 183 RESPONSEのようなセッション確立メッセージに挿入することが可能である。別様には、アドレスは、特定のプロトコルレベル、例えばIPレベルで連続的に挿入することが可能である。
【００２０】
図１を参照する。図１は、挿入要素、すなわちネットワーク要素CがSIPアウェアであり、セキュリティソリューションが制限的問題ではない場合の一実施形態を示す図である。図１に示される実施形態は、モバイル送信時に関するものである。
【００２１】
図１は、ユーザー機器40と、IPエッジ要素42と、SPDF 44と、AF 46との間のシグナリングフローを示す図である。本実施形態では、IPエッジ要素42はネットワーク要素Cに対応するが、AE要素46はネットワーク要素Dに対応する。SPDF要素44はネットワーク要素Bに対応するが、RACF（図示せず）はネットワーク要素Aに対応する。
【００２２】
したがって、RACFアドレスを必要としているのはSPDF 44である。セッション確立シグナリングは、アクセスネットワーク要素を介してコアネットワークの方へトランスポートされる。シグナリングフローは、以下のように行われる。
【００２３】
ステップS1で、INVITEメッセージがUE 4.0からIPエッジ42に送信される。
【００２４】
ステップS2で、RACFアドレスは、IPエッジ要素42によってサービスリクエストメッセージ内に設定される。本実施形態では、ユーザー機器が送信元セッション確立である。IPエッジ要素42は、関連するRACFによって制御される。
【００２５】
ステップS3で、挿入されたRACFアドレスを有するINVITEメッセージは、AF 46に送信される。
【００２６】
ステップS4で、AF 46は、メッセージからRACFアドレスを取り出す。
【００２７】
ステップS5で、INVITEメッセージは、他のネットワーク要素（図示せず）に転送される。
【００２８】
ステップS6で、AF 46は、一般的に、承認目的のためのセッション関連のパラメータとともに、RACFアドレスをSPDF 44に送信する。
【００２９】
ステップS7で、セッション情報は、AF 46によって受信され、ステップS8で、AF 46によってUE 40に送信される。
【００３０】
AF 46が、例えば承認情報を更新したときに、RACFアドレスがSPDF 44に送信される場合、ステップS6を省略してステップS9と置き換えることができるものと理解されたい。
【００３１】
ステップS10で、情報がSPDF 44からIPエッジ42に送信またはプッシュされる。
【００３２】
図２を参照する。図２は、図１に示されるシナリオに類似しているが、シグナリングシナリオがモバイル受信の場合、すなわち、セッションがユーザー機器によって確立されるが、ユーザー機器によって起動されない場合に対してのものである。図２に示される図１と同じ要素には同じ参照番号が付してある。
【００３３】
ステップT1で、AF 46は、他のネットワーク要素（図示せず）からINVITEメッセージを受信する。
【００３４】
ステップT2で、AFは、そのINVITEメッセージをUE 40に転送する。
【００３５】
ステップT3で、セッションは、UE 40からIPエッジ42へ進む。
【００３６】
ステップT4で、IPエッジ42が、RACFアドレスをセッションメッセージに挿入する。
【００３７】
ステップT5で、RACFアドレスが挿入されたメッセージがAF 46に転送される。
【００３８】
ステップT6で、AF 46は、RACFアドレスを取り出す。
【００３９】
ステップT7は、概ねステップS7に対応する。
【００４０】
ステップT8で、AF 46は、AFが承認情報を更新するときに、RACFアドレスをSPDF 44に送信する。
【００４１】
ステップT9は、概ねステップS10に対応する。
【００４２】
本発明の実施形態は、RACFによって制御されるアクセスネットワーク要素が、AN（Access Node: アクセスノード）またはHG（Home Gateway: ホームゲートウェイ）である場合に、同様に適用されるものと理解されたい。
【００４３】
SPDFがエッジルーターアドレスが必要とされている場合に、類似したシグナリングが行われる。エッジルーターは、例えば、GGSN（Gateway GPRS（General Packet Radio Service: 汎用パケット無線システム） Support Node: ゲートウェイGPRSサポートノード）とすることができる。これは、エッジルーターアドレスが、エッジルーター自体によってサービスリクエストメッセージに挿入されるか、または経路上の別の要素がエッジルーターのアドレスを知っている、という点において図１および2に示される実施形態とは異なる。すなわち、図１および2のIPエッジ要素は、シグナリングフローにおいてエッジルーターと置き換えられ、当該のアドレスはそのエッジルーターのものである。
【００４４】
図３および4を参照する。図３および4は、SPDFアドレスが要求される、プルの場合を示す図である。特に、図３は、セッションがユーザー機器によって起動され、エッジルーターがSPDFアドレスを必要としている場合を説明するものである。エッジルーターは、BGF（Border Gateway Function: ボーダーゲートウェイ機能）とすることが可能である。特に、図３は、UE 40と、エッジルーター48と、SPDF 44と、AF 46との間のシグナリングを示す図である。
【００４５】
ステップA1で、UE 40は、INVITEメッセージをAF 46に送信する。
【００４６】
前記INVITEメッセージは、ステップA2で、AF46によって他のネットワーク要素（図示せず）に送信される。
【００４７】
ステップA3で、AF46は、確立されたセッションに対するSPDFを決定または選択する。これは、例えば、ステップA4に示されるように、AFと１つ以上のSPDF 44との間のシグナリングを伴うことが可能である。
【００４８】
ステップA5で、セッションプログレスおよびAFは、他のネットワーク要素（図示せず）からセッションメッセージを受信する。
【００４９】
ステップA6で、AFは、UEへの適切なメッセージにSPDFアドレスを挿入する。モバイル送信セッションの場合、このアドレスを、例えば、UEへのセッション確立メッセージに存在させることが可能である。前記メッセージは、ステップA7で、AF46からエッジルーター48に送信される。
【００５０】
ステップA8で、SPDFアドレスがエッジルーターによって取り出される。
【００５１】
ステップA9で、セッションメッセージングがエッジルーターA48からUE 40に送信される。
【００５２】
ステップA10で、エッジルーター48は、SPDFアドレスを使用してSPDFから情報をプルすることができる。
【００５３】
本実施形態では、ネットワーク要素Aは、SPDFに対応する。エッジルーターはネットワーク要素BとDに対応し、AF 46はネットワーク要素Cに対応する。
【００５４】
図４を参照する。図４は、図３に示されるシナリオに対応するシグナリングを示すが、セッションがユーザー機器によって起動されない、すなわちモバイル受信の場合のものである。
【００５５】
ステップB1で、AF 46は、他のネットワーク要素（図示せず）からINVITEメッセージB1を受信する。ステップB2、B3、およびB4は、概ね、ステップA3、A4、およびA6にそれぞれ対応する。特に、SPDFアドレスは、ステップB5でエッジルーター48に送信されたINVITEメッセージに挿入される。ステップB6は、概ねステップA8に対応する。ステップB7で、エッジルーター48によってINVITEメッセージがUEに送信される。ステップB8で、セッションはUE 40とAF46との間を進行する。
【００５６】
ステップB9で、更なるセッションメッセージが、AF 46から他のネットワーク要素（図示せず）に送信される。
【００５７】
ステップB10で、AF 46は、更新された承認情報をSPDF 44に送信する。
【００５８】
ステップB11で、エッジルーター48は、SPDF 44から情報をプルする。これは、取り出されたアドレスによって識別されたSPDFからのものである。
【００５９】
図３および4に示される処理では、エッジルーターは、BGF機能と置き換えることができる。
【００６０】
RACFまたはエッジルーターがSPDFアドレスを必要としている場合に、類似したシグナリングが行われるものと理解されたい。
【００６１】
図３に示されるシナリオでは、エッジルーター48をIPエッジ要素42と置き換えている。本実施形態では、SPDFは要素Aであり、RACFは要素Bであり、AFは要素Cであり、IPエッジ42は要素Dである。
【００６２】
AFがSPDFを選択または決定しているか、またはセッションが確立されているときに、AFは、モバイル送信またはモバイル受信の場合のそれぞれに基づいて、UEへのセッション確立／確認応答メッセージにSPDFアドレスを設定する。セッション確立シグナリングは、アクセスネットワーク要素を介してUEへトランスポートされる。関連するRACFによって制御されるアクセスネットワーク要素、例えばIPエッジ要素は、メッセージからSPDFアドレスを取り出して、アドレスをRACFに転送する。RACFは、アドレスを使用して、SPDFから直接またはIPエッジ要素を経て情報をプルすることができる。また、IPエッジ要素は、当該のネットワークに基づいてANまたはHGに置き換えることができる。
【００６３】
以下、更なる変更形態について説明する。
【００６４】
以下の諸例では、挿入要素、すなわち要素Cは、SIP、またはより一般的には上位層プロトコル、アウェアとする必要がない。この場合も、TISPANおよび3GPP Rel-7に述べられているトランスポートレイヤーセキュリティTLSによる影響を受けない。これらの実施形態では、下位層プロトコルを、必要とされているアドレスまたはより一般的には必要とされている情報のトランスポートに使用する。本実施形態では、IPレベルを下位層プロトコルとして用いている。
【００６５】
以下の例、すなわちプッシュする場合では、SPDFがRACFアドレスを必要としている。
【００６６】
セッション確立シグナリングは、場合によりそれら自体のシグナリングパイプ／トンネルを経て、アクセスネットワーク要素を介してコアネットワークへトランスポートされる。
【００６７】
したがって、RACFアドレスは、RACFによって制御されるアクセスネットワーク要素によって、IPプロトコルフレームに設定される。これは、例えばIPエッジ要素、AN要素、またはHG要素とすることが可能である。アドレスは、IPv4の場合にはオプションフィールドにトランスポートし、IPv6場合には拡張ヘッダーにトランスポートすることができる。
【００６８】
提供されている場合、IPエッジ要素とSPDFとの間に配置されたNAT-PT（Network Address Translator-Port Translator: ネットワークアドレストランスレータ-プロトコルトランスレータ）要素は、IPv4オプションヘッダーをIPv6拡張ヘッダーに、およびその逆にトランスレートすることができる。これは、両バージョンのIPプロトコルが使用されている場合にのみ要求される。
【００６９】
AFがセッション確立シグナリングを受信するとき、AFは、IPフレームからRACFアドレスを取り出す。AFが、後にSPDFとコンタクトをとり、一般的に承認目的のためのセッション関連のパラメータを送信またはプッシュするときに、AFは、RACFアドレスをSPDFに送信する。これは、例えば図１に関して記述したシナリオに類似している。なお、図１では、SIPシグナリングを使用している。この改良した実施形態では、情報は、IPレベルメッセージに含まれる。
【００７０】
以下のシナリオでは、SPDFがエッジルーターアドレスを必要としている。セッション確立シグナリングは、アクセスネットワーク要素を介してコアネットワークへトランスポートされる。したがって、エッジルーターアドレスは、エッジルーター自体か、またはエッジルーターのアドレスを知っている経路上の別の要素によって、IPプロトコルフレームに設定される。AFがセッション確立シグナリングを受信するとき、AFは、IPフレームからエッジルーターアドレスを取り出す。AFが、後にSPDFとコンタクトをとり、一般的に承認目的のためのセッション関連のパラメータを送信またはプッシュするときに、AFは、エッジルーターアドレスをSPDFに送信する。
【００７１】
上述のシナリオは、個々に、または組み合わせて適用することができるものと理解されたい。例えば、NGNアーキテクチャでの組み合わせの場合では、要素の内の１つ、例えばエッジルーター／BGFは、プルオペレーションのためにSPDFアドレスを必要とし、SPDFは、情報をプッシュするための別の要素、例えばRACFのアドレスを必要とする。その場合、上述の関連するプロシージャのうちの２つを使用することが可能である。
【００７２】
図５を参照する。図５は、本発明の実施形態を組み込むことが可能なRACFの機能的アーキテクチャを示す図である。これは、TISPANアーキテクチャに対してETSIによって提案されているものである。ユーザー機器UE 2は、ホームゲートウェイHG 4に接続するように配置される。
【００７３】
ホームゲートウェイ4は、アクセスノード6およびCDCF 30に接続される。AN 6は、IPエッジノード8に、およびA-RACF（Admission-Resource and Admission Control Function: アドミッションリソースおよびアドミッション制御機能）28に接続される。CDCF 30もA-RACF 28に接続される。
【００７４】
ネットワークアタッチメントサブシステム32は、A-RACFに接続される。A-RACF 28およびIPエッジ要素8は、第一のサービスプロバイダネットワーク10に接続される。サービスプロバイダネットワーク10は、SPDF 14と、アプリケーション機能AF 16と、A-BGFアクセスボーダーゲートウェイ機能12とを有する。IPエッジ8はA-BGF12に接続され、A-RACF 28はSPDF 14に接続される。
【００７５】
第二のサービスプロバイダネットワーク24は、I-BCF（Interconnection Border Control Function: 相互接続ボーダー制御機能）18と、SPDF 20と、IBGF（Interconnection Border Gateway Function: 相互接続ボーダーゲートウェイ機能）とを有するように示されている。
【００７６】
２つのサービスプロバイダネットワーク10および24は、第一のサービスプロバイダネットワーク10のA-BGF 12、および第二のサービスプロバイダネットワーク24のI-BGF 22によって接続される。第二のサービスプロバイダネットワーク24は、I-BGF 22を経て外部ネットワーク26に接続される。
【００７７】
A-BGFは、パケットゲートウェイに対するパケットである。I-BGFは、SPDFの制御下で、ポリシー強制機能およびネットワークアクセス機能を実行する。
【００７８】
IPエッジ8は、加入リンクをターミネートするように、アップストリームパケットを右側の外部ネットワークへ転送するように、また外部ネットワークからのダウンストリームパケットをIPアドレスに基づいて適切なリンクに転送するように値域が定められる。IPエッジは、各リンクに割り当てられたIPアドレスを知ることになる。IPエッジは、アクセスネットワークにおけるサービスの質の制御のためのダウンストリーム接続に関して、解除および成形を行うことが可能である。
【００７９】
I-BGFは、ネットワークアドレスおよびポートトランスレーションを形成するパケットゲートウェイ要素に対するパケットである。
【００８０】
アプリケーション機能は、SPDFと情報をやりとりする。アプリケーション機能は、ベアラリソースに対するリクエストを行い、リソースが予約および解放されるときに通知を受信することが可能である。
【００８１】
したがって、現在の3GPPトークン機構は、SIPセッション確立においてアドレスをUEにトランスポートし、UEは、ユーザープレーン確立シグナリング（PDPコンテキスト確立）においてアドレスをゲートウェイ（GGSN）にトランスポートする。現在の3GPP機構では、エンティティは、セッションアウェアである。本発明の実施形態では、これは必ずしも必要ではない。上述のように、本発明の実施形態は、SIPセッション確立だけを使用する、および/または下層のベアラレベルプロトコル（例、IP）だけを使用することが可能である。本発明の実施形態は、送信エンティティがセッションおよび／またはSIPアンアウェアとすることが可能であるので、連続的にアドレスを送信することが可能である。すなわち、アドレスは、第三のネットワーク要素によって送信される複数のメッセージに含まれる。本発明の実施形態では、例えば、現在の3GPPの場合とは異なるオペレーション（例えば、AFからPDFにプッシュされる情報）において、最終的なユーザーに移動させることが可能である。さらに、本発明の実施形態では、PDFは、ゲートウェイのアドレスを使用する。IPベースの方法を使用した実施形態では、セッションアウェアネスを必要としない。
【００８２】
ネットワーク要素に対して言及しているものであると理解されたい。本発明の実施形態は、ネットワーク機能によって実行することが可能であり、そのうちの１つ以上は、所与のネットワーク要素に組み込まれる。
【００８３】
また、本願明細書において上述したものは本発明の例示的な実施形態であるが、添付の請求項に記載された本発明の範囲から逸脱することなく、開示されたソリューションを実行することが可能な複数のバリエーションおよび変更形態があることにも留意されたい。
【図面の簡単な説明】
【００８４】
【図１】SPDFがRACFアドレスを必要としている本発明を組み込んだ場合の、モバイル送信におけるシグナリングを示す図である。
【図２】接続がモバイル受信であり、SPDFがRACFアドレスを必要としている本発明を組み込んだ場合のシグナリングを示す図である。
【図３】本発明を組み込み、モバイル送信時にエッジルーターがSPDFを要求する場合のシグナリングを示す図である。
【図４】本発明を組み込み、接続がモバイル受信であり、エッジルーターがSPDFアドレスを必要としている場合のシグナリングを示す図である。
【図５】本発明の実施形態を組み込むことができるRACFアーキテクチャを示す図である。