(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】5796891
(24)【登録日】2015年8月28日
(45)【発行日】2015年10月21日
(54)【発明の名称】ネットワーク
(51)【国際特許分類】
H04M 3/00 20060101AFI20151001BHJP
H04L 12/70 20130101ALI20151001BHJP
【FI】
H04M3/00 B
H04L12/70 A
【請求項の数】6
【全頁数】13
(21)【出願番号】特願2011-219709(P2011-219709)
(22)【出願日】2011年10月4日
(62)【分割の表示】特願2008-507195(P2008-507195)の分割
【原出願日】2006年4月27日
(65)【公開番号】特開2012-44690(P2012-44690A)
(43)【公開日】2012年3月1日
【審査請求日】2011年10月4日
【審判番号】不服2014-16258(P2014-16258/J1)
【審判請求日】2014年8月18日
(31)【優先権主張番号】0508847.1
(32)【優先日】2005年4月29日
(33)【優先権主張国】GB
(73)【特許権者】
【識別番号】398012616
【氏名又は名称】ノキア コーポレイション
(74)【代理人】
【識別番号】100127188
【弁理士】
【氏名又は名称】川守田 光紀
(72)【発明者】
【氏名】ラサネン エー ユハ
【合議体】
【審判長】
新川 圭二
【審判官】
坂本 聡生
【審判官】
山本 章裕
(56)【参考文献】
【文献】
特開2003−258879(JP,A)
【文献】
米国特許出願公開第2005/0026591(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
H04M3/00
H04L12/70
(57)【特許請求の範囲】
【請求項1】
インターネットプロトコルアドレスを有する第1の装置であって、リソースアドミッション制御機能を提供する第1の装置と;
前記第1の装置の前記インターネットプロトコルアドレスを要求する第2の装置と;
前記第1の装置のインターネットプロトコルアドレスをメッセージに挿入する第3の装置と;
第4の装置と;
を備えるシステムであって、前記第1,前記第2,前記第3,前記第4の装置は、それぞれネットワークノードからなり、前記第3の装置は前記第4の装置に前記メッセージを送信するように構成され、前記第4の装置は前記インターネットプロトコルアドレスを抽出して前記第2の装置へ送信し、前記メッセージを前記第2の装置に転送しないように構成され、ただし前記送信された前記インターネットプロトコルアドレスは前記第2の装置に要求されたものであり、前記第4の装置は前記メッセージを第5の装置に転送し、前記第5の装置は前記1の装置,前記2の装置および前記3の装置の何れとも異なり、前記第4の装置による前記転送することは、前記インターネットプロトコルアドレスを抽出した後、前記インターネットプロトコルアドレスを前記第2の装置へ送信する前に、実行される、システム。
【請求項2】
前記第4の装置はアプリケーション機能を提供する、請求項1に記載のシステム。
【請求項3】
前記第3の装置は、アプリケーション機能、アクセスノード、ホームゲートウェイ、および、リソースアドミッション制御機能によって制御される装置のうちの少なくとも1つを含む、請求項1または2に記載のシステム。
【請求項4】
第3の装置が第4の装置に第1の装置のインターネットプロトコルアドレスを送信すること、ただし前記インターネットプロトコルアドレスはメッセージに挿入されたものであり、前記第1の装置はリソースアドミッション制御機能を提供する、前記送信することと;
前記第4の装置が前記第3の装置から受信した前記メッセージから、前記第1の装置の前記インターネットプロトコルアドレスを抽出することと;
前記第4の装置から第2の装置に前記インターネットプロトコルアドレスを送信し、前記メッセージを前記第2の装置に転送しないことと;
を含む方法であって、ただし前記第1,前記第2,前記第3,前記第4の装置は、それぞれネットワークノードからなり、前記第2の装置は前記第1の装置の前記インターネットプロトコルアドレスを要求し、前記第4の装置は前記メッセージを第5の装置に転送し、前記第5の装置は前記1の装置,前記2の装置および前記3の装置の何れとも異なり、前記第4の装置による前記転送することは、前記インターネットプロトコルアドレスを抽出した後、前記インターネットプロトコルアドレスを前記第2の装置へ送信する前に、実行される、方法。
【請求項5】
前記第4の装置はアプリケーション機能を提供する、請求項4に記載の方法。
【請求項6】
前記第3の装置は、アプリケーション機能、アクセスノード、ホームゲートウェイ、および、リソースアドミッション制御機能によって制御される装置のうちの少なくとも1つを含む、請求項4または5に記載の方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ネットワークに関し、特に、排他的ではないが、次世代ネットワークに関する。
【背景技術】
【0002】
通信システムは、2つ以上の(モバイルまたは固定)端末機器または他の通信装置および/またはネットワークエンティティと、通信システムに関連する他のノードとの間の通信を可能にする設備である。通信は、例えば、音声、電子メール(Eメール)、テキストメッセージ、データ、マルチメディアなどの通信を含むことが可能である。通信システムは、一般的に、ユーザーとサービスプロバイダとの間の通信のための、およびユーザー装置にコンテンツデータを供給するためのサービスをユーザーに提供するためにも使用することが可能である。
【0003】
通信システムは、一般的に、システムの様々な要素の何を実行しようとしているのか、およびそれをどのように達成すべきかを設定する、所与の規格または所与の一組の仕様に基づいて運用される。例えば、標準規格は、ユーザーに、より正確にはユーザー機器に回路交換経路、またはパケット交換経路、あるいはその両方を経たアクセスが提供される場合に定義することが可能である。通信システムへのアクセスのために使用すべき通信プロトコルおよび/またはパラメータが、一般的に定義される。例えば、通信をユーザー機器と通信ネットワークの要素との間で実行しなければならない様式は、一般的に、予め定義された通信プロトコルに基づいている。すなわち、通信が基づくことのできる特定の一組の"ルール"は、ユーザー機器が通信システムを経て通信できるように定義する必要がある。
【0004】
現在、ネットワークは、固定ネットワークおよびモバイルネットワークの2つのカテゴリに分類することができる。なお、固定およびモバイルネットワーク間のコンバージェンスは、TISPAN(Telecommunication and Internet converged Services and Protocols for Advanced Networking)プロジェクトにおけるETSI(European Telecommunications Standards Institute: 欧州電気通信標準化機構)、3GPP(Third Generation Partnership Project: 第3世代パートナーシッププロジェクト)、およびITU-T(Telecommunication Standardisation Section of the International Telecommunication Union: 国際電気通信連合 電気通信標準化部門)のような、世界中の様々な標準化組織によって現在標準化されている。新しいネットワーク概念は、NGN(次世代ネットワーク)と呼ばれる。現在、NGN概念は、すでに3GPPによって標準化されたIMS(IP Multi-media Sub-System: IPマルチメディアサブシステム)コアネットワークに基づいている。
【0005】
固定およびモバイル変換は、一部欧州委員会の資金提供を受けたMSF(Multi-Services Switching Forum: マルチサービススイッチングシステム)やMUSE(Multi-Service Access Everywhere: マルチサービスアクセスエブリウェア)プロジェクトのような、複数の業界フォーラムによっても開発されている。
【0006】
提案されたアーキテクチャには、サービスベースのポリシー制御のための論理ポリシー判断エレメントである、サービスポリシー判断機能(Service Policy Decision Function: SPDF)がある。また、リソースおよびアドミッション制御機能もあり、このアーキテクチャでは、例えば、セッションアドミッション制御を提供し、どのネットワークポリシーを特定のアクセスに適用すべきかを決定することが可能である。
【0007】
本発明者は、現在提案されているアーキテクチャによる問題を特定している。特に問題なのは、特定のユーザーに対して、ポリシー制御機能SPDFが適切なリソースアドミッション制御機能(Resource Admission Control Function: RACF)をどのように見つけるかを定義するための機構が設定されていないことである。これは、SPDFがRACFに情報をプッシュする場合のプッシュ機能のことである。また、RACFがSPDFから情報をリクエストするプルオペレーションを使用した場合に、すなわち、RACFが適切なSPDFをどのように見つけるのか、という問題も生じる。
【0008】
上記の提案されている機能は、アプリケーション機能(Application function: AF)も有する。アプリケーション機能は、ポリシー判断機能と情報をやりとりする。AFはベアラリソースに対するリクエストを行い、リソースが予約および解放されるときに通知を受信することが可能である。他の機能は、アプリケーション機能によっても提供することが可能である。提案されているアーキテクチャは、ボーダーゲートウェイ機能BGFのようなエッジルーターも有する。ボーダーゲートウェイ機能は、2つのIP(インターネットプロトコル)トランスポートドメイン間のインターフェースを提供する。これは、アクセスネットワークとカスタマー構内機器との間、アクセスネットワークとコアネットワークとの間、または2つのコアネットワーク間の境界となりうる。
【0009】
提案されている現在のアーキテクチャによる別の問題は、エッジルーター(例、BGF)がSPDFをどのように見つけるべきか、またはSPDFが適切なエッジルーターをどのように見つけるかを決定するために定義された機構がなく、プルまたはプッシュオペレーションが使用されるかどうかに依存していることである。従来技術で、特に、草案ETSI ES2xxxxv.1.1.1.1 "TISPAN NGN functional architecture"(2004年12月)に記載されているような、提案されたNGNの機能的アーキテクチャに関する従来技術は、全くこの問題に対処していない。
【0010】
同じPDF(Policy Decision function: ポリシー判断機能)をどのように使用するのかを承知しているAFおよびエッジルーターの概念は、以下のように、プルの場合に対して3GPP IMSにおいて取り組まれている。制御プレーンとユーザープレーンとの連結に使用された承認トークンは、セッション確立メッセージにおいて、PDFのアドレスをアプリケーション機能からユーザー機器に担送する。ユーザー機器は、PDP(Packet Data Protocol: パケットデータプロトコル)コンテキストアクティブ化/変更メッセージで、アドレスをエッジルーターに送信する。ルーターは、次いで、PDFに対してプルオペレーションを使用する。なお、制御プレーンおよびNGN端末において、3GPP固有のSIP(Session Initiation Protocol: セッション開始プロトコル)メカニズムを必要とするときは、承認トークンの手法はNGNコンテキストでは不要である。また、ユーザープレーン内にトークンをトランスポートするためのいくつかの新しい機構も必要となる。加えて、トークンを使用しても、NGNアクセスを使用したときに、他の別の連結機構にわたる利点をもたらさない。
【非特許文献1】draft ETSI ES2xxxxv.1.1.1.1 "TISPAN NGN functional architecture"(2004年12月)
【発明の概要】
【0011】
本発明の実施形態の目的は、上述の問題の内の1つ以上に対処することである。
【0012】
本発明の一側面によれば、アドレスを有する第一のネットワーク機能と、前記第一のネットワーク機能の前記アドレスを必要としている第二のネットワーク機能と、前記第一のネットワーク機能の前記アドレスをメッセージに挿入するように構成された第三のネットワーク機能と、第四のネットワーク機能と、を含み、前記第三のネットワーク機能は、前記第四のネットワーク機能に前記メッセージを送信するように構成され、前記第四のネットワーク機能は、前記アドレスを取り出して、前記アドレスを前記第二のネットワーク機能に送信するように構成される、ネットワークが提供される。
【0013】
本発明の更なる側面によれば、ネットワークで使用するためのネットワーク機能であって、前記ネットワーク機能は、第一のネットワーク機能のアドレスをメッセージに挿入して、前記メッセージを第四のネットワーク機能に送信するように構成されるネットワーク機能が提供される。
【0014】
本発明の別の側面によれば、ネットワーク機能であって、前記ネットワーク機能は、第一のネットワーク機能のアドレスを含むメッセージを第三のネットワーク機能から受信するように構成され、前記ネットワーク機能は、前記アドレスを取り出して、前記アドレスを、前記第一のネットワーク機能の前記アドレスを必要としている前記第二のネットワーク機能に送信するように構成される、ネットワーク機能が提供される。
【0015】
本発明の別の側面によれば、第一のネットワーク機能のアドレスを、前記第一のネットワーク機能の前記アドレスを必要としている第二のネットワーク機能に提供する方法であって、第三のネットワーク機能によって、第一のネットワーク機能のアドレスをメッセージに挿入するステップと、前記メッセージを第四のネットワーク機能に送信するステップと、前記第四のネットワーク機能によって前記アドレスを取り出すステップと、前記第四のネットワーク機能によって、前記アドレスを前記第二のネットワーク機能に送信するステップと、を含む方法が提供される。
【図面の簡単な説明】
【0016】
本発明をさらに理解し、本発明をどのように実施するのかを示すために、一例として添付図面を載せる。
【
図1】SPDFがRACFアドレスを必要としている本発明を組み込んだ場合の、モバイル送信におけるシグナリングを示す図である。
【
図2】接続がモバイル受信であり、SPDFがRACFアドレスを必要としている本発明を組み込んだ場合のシグナリングを示す図である。
【
図3】本発明を組み込み、モバイル送信時にエッジルーターがSPDFを要求する場合のシグナリングを示す図である。
【
図4】本発明を組み込み、接続がモバイル受信であり、エッジルーターがSPDFアドレスを必要としている場合のシグナリングを示す図である。
【
図5】本発明の実施形態を組み込むことができるRACFアーキテクチャを示す図である。
【0017】
以下の実施形態では、モバイル発信とは、固定またはモバイルであってよいユーザー機器によって起動されるセッションまたは接続のことである。モバイル受信とは、ユーザー機器によって行われるが、他の場所で起動される接続のことである。また、ユーザー機器は、固定またはモバイルとすることができる。
【0018】
概して、第一のネットワーク要素、要素Aのアドレスは、別のネットワーク要素、要素Bによって必要とされている。このアドレスは、ネットワーク要素、要素Cによって、ネットワーク要素、すなわち必要とされているアドレスを知っているネットワーク要素Cを介してトランスポートされるプロトコルメッセージまたはメッセージ内に挿入される。ネットワーク要素Cは、ネットワーク要素Aと同一であってよい。必要とされているアドレスは、更なるネットワーク要素、要素Dによってシグナリングメッセージから取り出され、そのアドレスを必要としているネットワーク要素、要素Bに転送される。ネットワーク要素Dは、ネットワーク要素Bと同一であっても異なっていてもよい。
【0019】
下記の詳細な実施形態に述べるように、例えば、使用したセキュリティメソッドによって、また、挿入ネットワーク要素、すなわちネットワーク要素Cによるプロトコルの認識によって、異なる方法でアドレスを挿入することが可能である。例えば、アドレスは、特定のプロトコルレベルの特定のメッセージにだけ挿入することが可能である。例えば、メッセージは、SIP INVITEまたはSIP 183 RESPONSEのようなセッション確立メッセージに挿入することが可能である。別様には、アドレスは、特定のプロトコルレベル、例えばIPレベルで連続的に挿入することが可能である。
【0020】
図1を参照する。
図1は、挿入要素、すなわちネットワーク要素CがSIPアウェアであり、セキュリティソリューションが制限的問題ではない場合の一実施形態を示す図である。
図1に示される実施形態は、モバイル送信時に関するものである。
【0021】
図1は、ユーザー機器40と、IPエッジ要素42と、SPDF 44と、AF 46との間のシグナリングフローを示す図である。本実施形態では、IPエッジ要素42はネットワーク要素Cに対応するが、AE要素46はネットワーク要素Dに対応する。SPDF要素44はネットワーク要素Bに対応するが、RACF(図示せず)はネットワーク要素Aに対応する。
【0022】
したがって、RACFアドレスを必要としているのはSPDF 44である。セッション確立シグナリングは、アクセスネットワーク要素を介してコアネットワークの方へトランスポートされる。シグナリングフローは、以下のように行われる。
【0023】
ステップS1で、INVITEメッセージがUE 4.0からIPエッジ42に送信される。
【0024】
ステップS2で、RACFアドレスは、IPエッジ要素42によってサービスリクエストメッセージ内に設定される。本実施形態では、ユーザー機器が送信元セッション確立である。IPエッジ要素42は、関連するRACFによって制御される。
【0025】
ステップS3で、挿入されたRACFアドレスを有するINVITEメッセージは、AF 46に送信される。
【0026】
ステップS4で、AF 46は、メッセージからRACFアドレスを取り出す。
【0027】
ステップS5で、INVITEメッセージは、他のネットワーク要素(図示せず)に転送される。
【0028】
ステップS6で、AF 46は、一般的に、承認目的のためのセッション関連のパラメータとともに、RACFアドレスをSPDF 44に送信する。
【0029】
ステップS7で、セッション情報は、AF 46によって受信され、ステップS8で、AF 46によってUE 40に送信される。
【0030】
AF 46が、例えば承認情報を更新したときに、RACFアドレスがSPDF 44に送信される場合、ステップS6を省略してステップS9と置き換えることができるものと理解されたい。
【0031】
ステップS10で、情報がSPDF 44からIPエッジ42に送信またはプッシュされる。
【0032】
図2を参照する。
図2は、
図1に示されるシナリオに類似しているが、シグナリングシナリオがモバイル受信の場合、すなわち、セッションがユーザー機器によって確立されるが、ユーザー機器によって起動されない場合に対してのものである。
図2に示される
図1と同じ要素には同じ参照番号が付してある。
【0033】
ステップT1で、AF 46は、他のネットワーク要素(図示せず)からINVITEメッセージを受信する。
【0034】
ステップT2で、AFは、そのINVITEメッセージをUE 40に転送する。
【0035】
ステップT3で、セッションは、UE 40からIPエッジ42へ進む。
【0036】
ステップT4で、IPエッジ42が、RACFアドレスをセッションメッセージに挿入する。
【0037】
ステップT5で、RACFアドレスが挿入されたメッセージがAF 46に転送される。
【0038】
ステップT6で、AF 46は、RACFアドレスを取り出す。
【0039】
ステップT7は、概ねステップS7に対応する。
【0040】
ステップT8で、AF 46は、AFが承認情報を更新するときに、RACFアドレスをSPDF 44に送信する。
【0041】
ステップT9は、概ねステップS10に対応する。
【0042】
本発明の実施形態は、RACFによって制御されるアクセスネットワーク要素が、AN(Access Node: アクセスノード)またはHG(Home Gateway: ホームゲートウェイ)である場合に、同様に適用されるものと理解されたい。
【0043】
SPDFがエッジルーターアドレスが必要とされている場合に、類似したシグナリングが行われる。エッジルーターは、例えば、GGSN(Gateway GPRS(General Packet Radio Service: 汎用パケット無線システム) Support Node: ゲートウェイGPRSサポートノード)とすることができる。これは、エッジルーターアドレスが、エッジルーター自体によってサービスリクエストメッセージに挿入されるか、または経路上の別の要素がエッジルーターのアドレスを知っている、という点において
図1および2に示される実施形態とは異なる。すなわち、
図1および2のIPエッジ要素は、シグナリングフローにおいてエッジルーターと置き換えられ、当該のアドレスはそのエッジルーターのものである。
【0044】
図3および4を参照する。
図3および4は、SPDFアドレスが要求される、プルの場合を示す図である。特に、
図3は、セッションがユーザー機器によって起動され、エッジルーターがSPDFアドレスを必要としている場合を説明するものである。エッジルーターは、BGF(Border Gateway Function: ボーダーゲートウェイ機能)とすることが可能である。特に、
図3は、UE 40と、エッジルーター48と、SPDF 44と、AF 46との間のシグナリングを示す図である。
【0045】
ステップA1で、UE 40は、INVITEメッセージをAF 46に送信する。
【0046】
前記INVITEメッセージは、ステップA2で、AF46によって他のネットワーク要素(図示せず)に送信される。
【0047】
ステップA3で、AF46は、確立されたセッションに対するSPDFを決定または選択する。これは、例えば、ステップA4に示されるように、AFと1つ以上のSPDF 44との間のシグナリングを伴うことが可能である。
【0048】
ステップA5で、セッションプログレスおよびAFは、他のネットワーク要素(図示せず)からセッションメッセージを受信する。
【0049】
ステップA6で、AFは、UEへの適切なメッセージにSPDFアドレスを挿入する。モバイル送信セッションの場合、このアドレスを、例えば、UEへのセッション確立メッセージに存在させることが可能である。前記メッセージは、ステップA7で、AF46からエッジルーター48に送信される。
【0050】
ステップA8で、SPDFアドレスがエッジルーターによって取り出される。
【0051】
ステップA9で、セッションメッセージングがエッジルーターA48からUE 40に送信される。
【0052】
ステップA10で、エッジルーター48は、SPDFアドレスを使用してSPDFから情報をプルすることができる。
【0053】
本実施形態では、ネットワーク要素Aは、SPDFに対応する。エッジルーターはネットワーク要素BとDに対応し、AF 46はネットワーク要素Cに対応する。
【0054】
図4を参照する。
図4は、
図3に示されるシナリオに対応するシグナリングを示すが、セッションがユーザー機器によって起動されない、すなわちモバイル受信の場合のものである。
【0055】
ステップ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との間を進行する。
【0056】
ステップB9で、更なるセッションメッセージが、AF 46から他のネットワーク要素(図示せず)に送信される。
【0057】
ステップB10で、AF 46は、更新された承認情報をSPDF 44に送信する。
【0058】
ステップB11で、エッジルーター48は、SPDF 44から情報をプルする。これは、取り出されたアドレスによって識別されたSPDFからのものである。
【0059】
図3および4に示される処理では、エッジルーターは、BGF機能と置き換えることができる。
【0060】
RACFまたはエッジルーターがSPDFアドレスを必要としている場合に、類似したシグナリングが行われるものと理解されたい。
【0061】
図3に示されるシナリオでは、エッジルーター48をIPエッジ要素42と置き換えている。本実施形態では、SPDFは要素Aであり、RACFは要素Bであり、AFは要素Cであり、IPエッジ42は要素Dである。
【0062】
AFがSPDFを選択または決定しているか、またはセッションが確立されているときに、AFは、モバイル送信またはモバイル受信の場合のそれぞれに基づいて、UEへのセッション確立/確認応答メッセージにSPDFアドレスを設定する。セッション確立シグナリングは、アクセスネットワーク要素を介してUEへトランスポートされる。関連するRACFによって制御されるアクセスネットワーク要素、例えばIPエッジ要素は、メッセージからSPDFアドレスを取り出して、アドレスをRACFに転送する。RACFは、アドレスを使用して、SPDFから直接またはIPエッジ要素を経て情報をプルすることができる。また、IPエッジ要素は、当該のネットワークに基づいてANまたはHGに置き換えることができる。
【0063】
以下、更なる変更形態について説明する。
【0064】
以下の諸例では、挿入要素、すなわち要素Cは、SIP、またはより一般的には上位層プロトコル、アウェアとする必要がない。この場合も、TISPANおよび3GPP Rel-7に述べられているトランスポートレイヤーセキュリティTLSによる影響を受けない。これらの実施形態では、下位層プロトコルを、必要とされているアドレスまたはより一般的には必要とされている情報のトランスポートに使用する。本実施形態では、IPレベルを下位層プロトコルとして用いている。
【0065】
以下の例、すなわちプッシュする場合では、SPDFがRACFアドレスを必要としている。
【0066】
セッション確立シグナリングは、場合によりそれら自体のシグナリングパイプ/トンネルを経て、アクセスネットワーク要素を介してコアネットワークへトランスポートされる。
【0067】
したがって、RACFアドレスは、RACFによって制御されるアクセスネットワーク要素によって、IPプロトコルフレームに設定される。これは、例えばIPエッジ要素、AN要素、またはHG要素とすることが可能である。アドレスは、IPv4の場合にはオプションフィールドにトランスポートし、IPv6場合には拡張ヘッダーにトランスポートすることができる。
【0068】
提供されている場合、IPエッジ要素とSPDFとの間に配置されたNAT-PT(Network Address Translator-Port Translator: ネットワークアドレストランスレータ-プロトコルトランスレータ)要素は、IPv4オプションヘッダーをIPv6拡張ヘッダーに、およびその逆にトランスレートすることができる。これは、両バージョンのIPプロトコルが使用されている場合にのみ要求される。
【0069】
AFがセッション確立シグナリングを受信するとき、AFは、IPフレームからRACFアドレスを取り出す。AFが、後にSPDFとコンタクトをとり、一般的に承認目的のためのセッション関連のパラメータを送信またはプッシュするときに、AFは、RACFアドレスをSPDFに送信する。これは、例えば
図1に関して記述したシナリオに類似している。なお、
図1では、SIPシグナリングを使用している。この改良した実施形態では、情報は、IPレベルメッセージに含まれる。
【0070】
以下のシナリオでは、SPDFがエッジルーターアドレスを必要としている。セッション確立シグナリングは、アクセスネットワーク要素を介してコアネットワークへトランスポートされる。したがって、エッジルーターアドレスは、エッジルーター自体か、またはエッジルーターのアドレスを知っている経路上の別の要素によって、IPプロトコルフレームに設定される。AFがセッション確立シグナリングを受信するとき、AFは、IPフレームからエッジルーターアドレスを取り出す。AFが、後にSPDFとコンタクトをとり、一般的に承認目的のためのセッション関連のパラメータを送信またはプッシュするときに、AFは、エッジルーターアドレスをSPDFに送信する。
【0071】
上述のシナリオは、個々に、または組み合わせて適用することができるものと理解されたい。例えば、NGNアーキテクチャでの組み合わせの場合では、要素の内の1つ、例えばエッジルーター/BGFは、プルオペレーションのためにSPDFアドレスを必要とし、SPDFは、情報をプッシュするための別の要素、例えばRACFのアドレスを必要とする。その場合、上述の関連するプロシージャのうちの2つを使用することが可能である。
【0072】
図5を参照する。
図5は、本発明の実施形態を組み込むことが可能なRACFの機能的アーキテクチャを示す図である。これは、TISPANアーキテクチャに対してETSIによって提案されているものである。ユーザー機器UE 2は、ホームゲートウェイHG 4に接続するように配置される。
【0073】
ホームゲートウェイ4は、アクセスノード6およびCDCF 30に接続される。AN 6は、IPエッジノード8に、およびA-RACF(Admission-Resource and Admission Control Function: アドミッションリソースおよびアドミッション制御機能)28に接続される。CDCF 30もA-RACF 28に接続される。
【0074】
ネットワークアタッチメントサブシステム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に接続される。
【0075】
第二のサービスプロバイダネットワーク24は、I-BCF(Interconnection Border Control Function: 相互接続ボーダー制御機能)18と、SPDF 20と、IBGF(Interconnection Border Gateway Function: 相互接続ボーダーゲートウェイ機能)とを有するように示されている。
【0076】
2つのサービスプロバイダネットワーク10および24は、第一のサービスプロバイダネットワーク10のA-BGF 12、および第二のサービスプロバイダネットワーク24のI-BGF 22によって接続される。第二のサービスプロバイダネットワーク24は、I-BGF 22を経て外部ネットワーク26に接続される。
【0077】
A-BGFは、パケットゲートウェイに対するパケットである。I-BGFは、SPDFの制御下で、ポリシー強制機能およびネットワークアクセス機能を実行する。
【0078】
IPエッジ8は、加入リンクをターミネートするように、アップストリームパケットを右側の外部ネットワークへ転送するように、また外部ネットワークからのダウンストリームパケットをIPアドレスに基づいて適切なリンクに転送するように値域が定められる。IPエッジは、各リンクに割り当てられたIPアドレスを知ることになる。IPエッジは、アクセスネットワークにおけるサービスの質の制御のためのダウンストリーム接続に関して、解除および成形を行うことが可能である。
【0079】
I-BGFは、ネットワークアドレスおよびポートトランスレーションを形成するパケットゲートウェイ要素に対するパケットである。
【0080】
アプリケーション機能は、SPDFと情報をやりとりする。アプリケーション機能は、ベアラリソースに対するリクエストを行い、リソースが予約および解放されるときに通知を受信することが可能である。
【0081】
したがって、現在の3GPPトークン機構は、SIPセッション確立においてアドレスをUEにトランスポートし、UEは、ユーザープレーン確立シグナリング(PDPコンテキスト確立)においてアドレスをゲートウェイ(GGSN)にトランスポートする。現在の3GPP機構では、エンティティは、セッションアウェアである。本発明の実施形態では、これは必ずしも必要ではない。上述のように、本発明の実施形態は、SIPセッション確立だけを使用する、および/または下層のベアラレベルプロトコル(例、IP)だけを使用することが可能である。本発明の実施形態は、送信エンティティがセッションおよび/またはSIPアンアウェアとすることが可能であるので、連続的にアドレスを送信することが可能である。すなわち、アドレスは、第三のネットワーク要素によって送信される複数のメッセージに含まれる。本発明の実施形態では、例えば、現在の3GPPの場合とは異なるオペレーション(例えば、AFからPDFにプッシュされる情報)において、最終的なユーザーに移動させることが可能である。さらに、本発明の実施形態では、PDFは、ゲートウェイのアドレスを使用する。IPベースの方法を使用した実施形態では、セッションアウェアネスを必要としない。
【0082】
ネットワーク要素に対して言及しているものであると理解されたい。本発明の実施形態は、ネットワーク機能によって実行することが可能であり、そのうちの1つ以上は、所与のネットワーク要素に組み込まれる。
【0083】
また、本願明細書において上述したものは本発明の例示的な実施形態であるが、添付の請求項に記載された本発明の範囲から逸脱することなく、開示されたソリューションを実行することが可能な複数のバリエーションおよび変更形態があることにも留意されたい。